| *** ratmice__ has quit IRC | 04:31 | |
| *** ratmice__ has joined #baserock | 04:31 | |
| *** zoli__ has joined #baserock | 05:47 | |
| *** zoli__ has quit IRC | 06:13 | |
| *** zoli__ has joined #baserock | 07:17 | |
| *** zoli__ has quit IRC | 07:23 | |
| *** elevenarms has quit IRC | 07:24 | |
| *** mike has joined #baserock | 07:29 | |
| *** mike is now known as Guest55206 | 07:29 | |
| *** pacon has joined #baserock | 08:11 | |
| *** gfinney has joined #baserock | 08:17 | |
| *** pacon has quit IRC | 08:18 | |
| *** petefoth has quit IRC | 08:24 | |
| *** petefoth has joined #baserock | 08:24 | |
| franred | persia, yes, it builds | 08:34 |
|---|---|---|
| *** mdizzle has joined #baserock | 08:50 | |
| mdizzle | morning all | 08:50 |
| *** gfinney has quit IRC | 08:50 | |
| *** gfinney has joined #baserock | 08:51 | |
| *** bashrc has joined #baserock | 08:59 | |
| *** sambishop has joined #baserock | 09:08 | |
| *** pacon has joined #baserock | 09:10 | |
| *** ssam2 has joined #baserock | 09:22 | |
| *** ChanServ sets mode: +v ssam2 | 09:22 | |
| *** pacon has quit IRC | 09:23 | |
| *** pacon has joined #baserock | 09:24 | |
| *** ssam2 has quit IRC | 09:26 | |
| *** ssam2 has joined #baserock | 09:28 | |
| *** ChanServ sets mode: +v ssam2 | 09:28 | |
| *** jonathanmaw has joined #baserock | 09:33 | |
| straycat | morning mdizzle | 09:38 |
| *** tiagogomes has joined #baserock | 09:39 | |
| *** gary_perkins has joined #baserock | 09:41 | |
| *** edcragg has joined #baserock | 10:01 | |
| *** wschaller has joined #baserock | 10:22 | |
| jjardon | hi, what metadata is currently stored about what is being builded in a baserock system? is there any doc about that? | 10:27 |
| ssam2 | look in /baserock in a Baserock system | 10:29 |
| ssam2 | it should be fairly clear what it all is, I don't think anybody's written anything about it on the wiki | 10:30 |
| ssam2 | jjardon: regards version numbers, there's kind of 3 approaches: (a) use upstream tags, (b) detect from repo contents (c) specify them manually in definitions | 10:39 |
| ssam2 | (a) is ok except that there aren't always usable tags | 10:40 |
| ssam2 | (b) is actually partially implemented already, see the `generate-manifest` command, but it's quite old unloved code | 10:40 |
| ssam2 | (c) is a pain for everyone and might not be accurate | 10:40 |
| jjardon | I guess the solution should be a mix of a and b, will take a look to generate-manifest for now, thanks! | 10:41 |
| ssam2 | we need to be able to get a version number for everything, but since 'version numbers' are really a human-defined concept, I think detecting them will never be 100% automatic | 10:41 |
| jjardon | maybe we can detect what was the last tag for a given commit, then say: "this is version x plus this commits: <>" | 10:43 |
| ssam2 | yes, 'git describe' will be pretty useful in some cases | 10:43 |
| jjardon | in project that do not use tags we need to think in another solution (I hope they are few nowadays) | 10:43 |
| * jjardon will look at "git describe" | 10:44 | |
| ssam2 | it may be handy if there's a way in definitions to manually specify a version number, because sometimes you might want to totally override what goes in the manifest | 10:44 |
| ssam2 | e.g. 'v1.0-plus-my-patch-to-fix-bug-xxxx' | 10:44 |
| jjardon | oh! seems exactly what I was asking for, cheers! | 10:44 |
| ssam2 | not sure though | 10:45 |
| jjardon | it would be a bit confusing to have a ref and also a version parameter in a chunk... maybe we can reuse the unpetrify-ref one for that ? not sure ... | 10:46 |
| ssam2 | would be nice to give unpetrify-ref a more logical name and a reason to exist :) | 10:48 |
| rdale_ | +1 | 10:48 |
| tiagogomes | is there anything better in baserock to create partitions than sfdisk? | 10:52 |
| straycat | cfdisk? | 11:00 |
| Kinnison | I don't think cfdisk is scriptable | 11:01 |
| straycat | i didn't realise that was a requirement for this :( | 11:03 |
| pedroalvarez | sfdisk is, but some people told me that it didn't support GPT partition tables | 11:03 |
| *** wschaller_ has joined #baserock | 11:07 | |
| Kinnison | straycat: sorry, I have hidden knowledge :) | 11:08 |
| tiagogomes | it doesn't, that why I asked whether there is a better alternative | 11:08 |
| tiagogomes | Kinnison, do you know if we need GPT partition tables on the Moonshot? | 11:08 |
| Kinnison | I doubt that it'll be necessary | 11:08 |
| *** wschaller has quit IRC | 11:10 | |
| pedroalvarez | after looking for some commits in util-linux, I think it may support gpt :/ | 11:14 |
| *** tiagogomes has quit IRC | 11:14 | |
| pedroalvarez | I may be wrong | 11:14 |
| *** tiagogomes has joined #baserock | 11:14 | |
| pedroalvarez | erm.. I can't run make in my failed stagging area :/ | 11:17 |
| pedroalvarez | using chroot | 11:17 |
| pedroalvarez | Segmentation fault (core dumped) | 11:17 |
| paulsherwood | ouch | 11:20 |
| straycat | btw, not sure we ever decided what to do about grep -x | 11:24 |
| pedroalvarez | http://paste.baserock.org/raw/qujizaroxa | 11:24 |
| *** a1exhughe5 has joined #baserock | 11:26 | |
| straycat | probably not too important just now though i guess | 11:26 |
| paulsherwood | rjek: http://wiki.baserock.org/meetup/cve-tracking/ | 11:27 |
| rjek | paulsherwood: Thanks | 11:27 |
| tlsa | that reminds me the libpng in baserock should be updated to 1.6.16 to fix CVE-2014-9495 | 11:29 |
| paulsherwood | ok+1 | 11:30 |
| paulsherwood | :-) | 11:30 |
| nowster | I submitted a patch to the mailing list 15 mins ago and it hasn't showed up yet. | 11:33 |
| * SotK is getting other emails on the mailing list, but no patch from nowster | 11:35 | |
| Kinnison | nowster: I don't see mail from you at the ML host yet | 11:35 |
| Kinnison | nowster: I see other people posting to baserock-dev | 11:35 |
| nowster | 2015-03-04 11:16:09 1YT7Hc-0004a5-P7 => baserock-dev@baserock.org R=smarthost T=remote_smtp_smarthost H=mail.codethink.co.uk [192.168.25.1] X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="OU=Domain Control Validated,OU=EssentialSSL Wildcard,CN=*.codethink.co.uk" A=plain C="250 2.0.0 Ok: queued as 7F539460922" | 11:35 |
| Kinnison | it might be sat on that server, or an intermediate then | 11:36 |
| Kinnison | baserock-dev is not on Codethink infrastructure | 11:36 |
| nowster | and the emails I've seen just now have been sent from gmail. | 11:36 |
| pedroalvarez | o.0 | 11:37 |
| tlsa | http://paste.baserock.org/ojepimesoh <-- OK? | 11:37 |
| tlsa | hmm, they have a libpng-1.6.16-signed too | 11:38 |
| pedroalvarez | libpng-1.6.16-master-signed doesn't match that sha1 | 11:39 |
| tlsa | i got it from http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/tag/?id=libpng-1.6.16-master-signed | 11:39 |
| franred | http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=070a616b8275277e18ef8ee91e2ca23f7bdc67d5 | 11:39 |
| tlsa | oh, I see | 11:40 |
| pedroalvarez | tlsa I think that v1.6.16 would be better | 11:41 |
| tlsa | pedroalvarez: as far as I can see, that sha1 I set is the sha1 of the tag? | 11:42 |
| pedroalvarez | tlsa: I'm not sure about that. Maybe someone with more git knowledge... ? :) | 11:42 |
| tlsa | it does show up correctly when I search for that sha1 by range | 11:42 |
| tlsa | on the web interface | 11:43 |
| pedroalvarez | true | 11:44 |
| pedroalvarez | I don't know really :/ | 11:44 |
| straycat | usually you use the sha of the tagged object though, not the sha of the tag, i'm not actually sure whether this matters for morph though | 11:45 |
| tlsa | http://paste.baserock.org/tinozenaye <-- that's for 1.6.16-signed | 11:46 |
| tlsa | but sha1 of the tag | 11:47 |
| ssam2 | I think morph will choke if it's the sha1 of tag, it expects a commit object | 11:47 |
| ssam2 | maybe not though | 11:47 |
| tlsa | does it not just checkout the sha1? | 11:48 |
| paulsherwood | i think it handles sha1 ok | 11:48 |
| franred | tlsa, it still not match with what the web point to it: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=88dd30b232362b65cca374dda39096888163dd6b | 11:48 |
| *** pacon has quit IRC | 11:49 | |
| *** franred has quit IRC | 11:49 | |
| tlsa | franred: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/log/?qt=range&q=df17b602414e82a7bbbaea0aa42bbc21de83a250 | 11:50 |
| *** wdutch has quit IRC | 11:50 | |
| *** franred has joined #baserock | 11:50 | |
| tlsa | franred: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/commit/?id=df17b602414e82a7bbbaea0aa42bbc21de83a250 | 11:52 |
| franred | tlsa, yep so for me the ref would be 88dd30b232362b65cca374dda39096888163dd6b and not df17b602414e82a7bbbaea0aa42bbc21de83a250 | 11:53 |
| pedroalvarez | we can use http://git.baserock.org/cgi-bin/cgit.cgi/delta/libpng.git/tag/?h=libpng16&id=v1.6.16, and finish the discussion :P | 11:53 |
| tlsa | but I've got the tag name in the documentation field, so I put the tag ref in | 11:53 |
| bashrc | getting an account on http://gerrit.baserock.org seems pretty hard | 11:55 |
| pedroalvarez | bashrc: was straight forward to me | 11:55 |
| bashrc | login with google doesn't work | 11:55 |
| franred | tlsa, I won't risked it and use the commit sha that wbo gives to me | 11:55 |
| pedroalvarez | bashrc: that is a known bug in gerrit | 11:56 |
| pedroalvarez | bashrc: and I think they don't care about it | 11:56 |
| pedroalvarez | that's why we set up openid.baserock.org | 11:56 |
| bashrc | ok | 11:56 |
| bashrc | only one thing I notice about openid.baserock.org is that it appears to send credentials over http | 11:57 |
| pedroalvarez | also our storyboard instance needed an openid provider (other reason to create openid.b.o) | 11:57 |
| nowster | still no sign of that patch email... It's probably gone in the moderation queue. :( | 11:57 |
| pedroalvarez | bashrc: true, we are wokring on that | 11:58 |
| straycat | tlsa, have you tried building with that? | 11:58 |
| *** wdutch has joined #baserock | 11:59 | |
| tlsa | no, but when I did the xfce stuff I was upating to tag sha1s right and left | 11:59 |
| tlsa | (I assumed that was what I was supposed to do when I used a tag in the documentation field) | 12:00 |
| straycat | then i guess it's fine, +1, if it does break then i guess that might be considered a bug | 12:01 |
| * pedroalvarez hopes this doesn't break genivi 2 days before a release :) | 12:02 | |
| straycat | don't really have time to check the code, but i just built libpng from that sha so i think it's ok | 12:15 |
| tlsa | pedroalvarez: libpng is in the genivi release, so I think it would be good to fix the CVE (allows attacker to overwrite arbitrary amount of mem with attacker-controlled data) | 12:17 |
| ratmice__ | wrt ABI doesn't the cache key contain all the cppflags, so wouldn't it be possible to define -DBASEROCK_LIBC_SHA1=$(some magic)...(?) when compiling gcc to get the missing dependency stuff included into the cache key? | 12:17 |
| ratmice__ | with $(some magic) probably having to be run by morph rather than the shell :) | 12:18 |
| ratmice__ | suprised it got to stage2 make, thought it wuold have bailed at stage2 glibc running rpcgen or whatever its called | 12:22 |
| ratmice__ | ahh, n/m stage1 is probably still around and binary compatible | 12:24 |
| straycat | richard_maw, thanks for merging that | 12:35 |
| ratmice__ | anyhow this is really why i prefer building gcc+everything else as one big uberbaum tree, but AFAIK nobody has done that with glibc | 12:40 |
| *** zoli__ has joined #baserock | 12:40 | |
| ratmice__ | that is where you check out newlib/binutils/gdb/gcc into one massive checkout and issue one ./configure/make to build the entire thing, you can kind of do so with git-readtree and sparse checkouts, but as I said I don't think the top-level gcc configure supports building glibc | 12:44 |
| *** mdizzle has quit IRC | 12:45 | |
| * nowster thinks baserock-dev hates him. Waahhh! | 12:50 | |
| *** jonathanmaw has quit IRC | 12:57 | |
| persia | nowster: I assure you it doesn't, but why do you think it may? | 12:58 |
| petefoth | What's the morph command to display the help for a specific write extension? | 12:58 |
| * petefoth guesses the answer :) | 12:59 | |
| pedroalvarez | I always forget | 13:00 |
| pedroalvarez | morph help tar.write | 13:00 |
| petefoth | morph help initramfs.write was what I guessed | 13:00 |
| petefoth | and it seemed to work | 13:00 |
| nowster | persia: I wrote it a little letter with a patch in it, and it's thrown it away. | 13:04 |
| persia | When that happens to me, it's usually because either 1) I typoed the address (most common reason), or 2) I sent from a new address and got caught by the "must send from recipient" filter into the moderation queue. #2 seems common for folk who use git-send-email and aren't careful configuring git. | 13:05 |
| ssam2 | i've not received any moderation emails for baserock-dev today | 13:05 |
| nowster | From: Paul Martin <paul.martin@codethink.co.uk> | 13:06 |
| nowster | To: baserock-dev@baserock.org | 13:06 |
| nowster | must be stuck on mail.ct | 13:07 |
| petefoth | I've seen some delays today when sending via mail.ct | 13:07 |
| nowster | the carbon copy got through | 13:07 |
| petefoth | nowster: it was a bcc: to an external address that got delayed for me. the to: to a ct addresss arrived very qucikly | 13:08 |
| *** jonathanmaw has joined #baserock | 13:13 | |
| pedroalvarez | I assume that this error in Weston (Genivi) means that I need xcb in the system? | 13:16 |
| pedroalvarez | http://paste.baserock.org/corilurayu | 13:16 |
| franred | Im moving lxml to python-common, but it does depend on libxml and libxslt which are in core and in foundation, so make sense to add foundation to python-common as a dependecy? | 13:24 |
| persia | Not having foundation as a dependency of python-common means less duplication for alternate toolchains. | 13:27 |
| franred | persia, I can add libxslt to core and python-common will depend on core instead... | 13:28 |
| persia | Same class of problem. | 13:28 |
| persia | For an alternate toolchain for C, we end up with another copy of all the C stuff: build-essential, core, foundation, etc. | 13:29 |
| persia | We can reuse the current python stuff, because it's all python, so as long as there is *some* python interpreter it works. | 13:29 |
| franred | I can add lxml into foundation then | 13:30 |
| persia | That said, I'm still not convinced the right way to add toolchains is by adding more strata. | 13:30 |
| persia | It might be better to fork the repo, so that only build-essential is changed. | 13:30 |
| persia | In which case, your change suddenly doesn't affect things at all. | 13:31 |
| * paulsherwood wonders if that's really better | 13:32 | |
| franred | at the moment foundation depends on C because it has libxslt so I will add lxml there and no C dependencies to python-common | 13:33 |
| persia | That's probably the best compromise path until a decision is taken on the best way to handle multiple C toolchains. | 13:34 |
| *** Krin has quit IRC | 14:41 | |
| *** Krin has joined #baserock | 14:49 | |
| *** tiagogomes has quit IRC | 15:06 | |
| *** tiagogomes_ has joined #baserock | 15:14 | |
| *** inara has quit IRC | 15:17 | |
| *** inara has joined #baserock | 15:24 | |
| paulsherwood | rjek: also you may have missed this... http://wiki.baserock.org/meetup/developing-secure-systems/ ? | 15:27 |
| paulsherwood | rjek: please feel free to amend, or append etc :) | 15:27 |
| rjek | paulsherwood: That bullet list seems very familiar... :) | 15:28 |
| rjek | Thanks. | 15:28 |
| tiagogomes_ | if `$ sfdisk` works, but `/usr/bin/env sfdisk` doesn't; what could be the cause? | 15:30 |
| tiagogomes_ | ok, $PATH is not an exported variable on a installer system | 15:38 |
| *** Guest55206 has quit IRC | 16:01 | |
| paulsherwood | rjek: i daresay. i was only minuting what was discussed in the meeting, since you were doing much of the talking :) | 16:11 |
| rjek | Perhaps I talk too much. | 16:12 |
| paulsherwood | no, i would not say that | 16:12 |
| bashrc | Q: is a chunk an application definition? | 16:13 |
| paulsherwood | bashrc: it's a single upstream project, usually. eg linux, systemd etc | 16:14 |
| richard_maw | so all the plumbing that applications need as well as the applications themselves | 16:15 |
| paulsherwood | http://wiki.baserock.org/glossary/#index10h2 | 16:15 |
| *** zoli__ has quit IRC | 16:22 | |
| bashrc | would .morph files be better named .chunk, or am I missing something | 16:41 |
| persia | There's several kinds of morph files. | 16:43 |
| persia | I think the folk talking about the next version of definitions were talking about using .def | 16:43 |
| persia | Because some are chunk morphologies (component definitions), and some define other sorts of things. | 16:44 |
| Zara | (chunks make up strata, strata make up systems; all of these are .morph files) | 16:44 |
| persia | systems make up clusters | 16:45 |
| *** zoli__ has joined #baserock | 16:45 | |
| bashrc | instead of having a kind field what about having .chunk, .strata, .system, .cluster ? | 16:46 |
| *** zoli__ has quit IRC | 16:47 | |
| persia | Since there's active debate about the entire model, and such a change requires a definitions version change, I don't think there is a point to doing that. | 16:48 |
| Zara | persia: I thought a whole bunch of different things could make up a cluster? (I'm just using the term 'system' here to mean 'things listed in "systems" in definitions') | 16:49 |
| persia | If you'd like to fix that class of annoyance, I encourage you to participate in the discussion on the next version of definitions. | 16:49 |
| persia | Zara: My understanding was that a cluster was always the deployment instructions for one or more systems. | 16:49 |
| persia | As an example, a cluster might define a system for a rootfs and a system for an initramfs, to be depoyed together. | 16:50 |
| persia | Or it might define an entire distbuild network, to be deployed simultaneously to several hardware nodes. | 16:50 |
| persia | I don't know how one might use a stratum or chunk in such a context. | 16:50 |
| *** zoli__ has joined #baserock | 16:53 | |
| Zara | persia: yeah, practically speaking I see it as a system + deployment instructions for that system; I just got confused. | 16:54 |
| persia | I switched mostly to clusters with embedded initramfs a while back, to make things more portable, which forces me to pay more attention to the distinction, but yeah, I can see that. | 16:55 |
| *** jonathanmaw has quit IRC | 17:04 | |
| Krin | quick question, for lorrys are repos following the format "https://github.com/openstack/tempest-lib" acceptable or do they have to start with "git://..." | 17:05 |
| persia | git:// is preferred, https:// is acceptable. | 17:06 |
| perryl | ISTR using git:// with github repos and it not working, though i could be mistaken | 17:07 |
| richard_maw | it usually works for me, though github don't give you the git:// urls by default | 17:08 |
| richard_maw | SotK: your OSTree patch series really baked my noodle | 17:09 |
| richard_maw | I hope I've given you useful feedback | 17:11 |
| Krin | thanks all | 17:11 |
| *** tiagogomes_ has quit IRC | 17:11 | |
| nowster | cloning from github: can be very slow | 17:11 |
| *** tiagogomes_ has joined #baserock | 17:11 | |
| franred | Krin, I would check if http://git.openstack.org/cgit/ has the repository if it is openstack related, although persia may have some concerns about this | 17:13 |
| pedroalvarez | Krin: as you can see in the README of that repo, the official repo is http://git.openstack.org/cgit/openstack/tempest-lib | 17:13 |
| pedroalvarez | snap | 17:13 |
| persia | Generally speaking, I think we should prefer git.openstack.org over the github mirrors. This is true for any project where developers push commits somewhere other than github. | 17:14 |
| Krin | okies, i'll amend those now :) | 17:16 |
| Krin | well spotted | 17:16 |
| bashrc | looking at some morph chunk files, they're almost like Makefiles | 17:46 |
| *** Krin has quit IRC | 17:47 | |
| persia | The key difference is the execution paradigm: there is no parse-time execution, there is no reentrant behaviour, etc. | 17:51 |
| persia | The problem with makefiles is that it is easy to write code that executes at parse-time that totally changes the behaviour of the code that executes at runtime, which is convenient as a oftware developer, but inconvenient from the perspective of a system integrator (because it makes it harder to have things happen twice the same way) | 17:52 |
| bashrc | also, some chunks appear to have no reference to source code, like this http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/tools/gdb.morph | 17:53 |
| bashrc | when it's building, how does the system know where to get the gdb source from? | 17:54 |
| *** gfinney has quit IRC | 17:55 | |
| Zara | bashrc: my guess is it gets the ref from the tools.morph stratum (in 'strata'), though I don't know why tools.morph was chosen over gdb.morph (this kind of thing has confused me before, so if someone understands it I'd appreciate the explanation!) | 17:58 |
| radiofree | bashrc: think of that as the build instructions | 17:58 |
| radiofree | you can see where it gets the source from in the startum http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/tools.morph#n18 | 17:58 |
| persia | The idea is that the ref changes more often than the build instructions. | 17:58 |
| *** ssam2 has quit IRC | 17:58 | |
| persia | So it should be easy to change refs (in strata) without touching the chunk morphologies. | 17:58 |
| radiofree | yep, e.g building xorg | 17:58 |
| *** a1exhughe5 has quit IRC | 18:00 | |
| bashrc | radiofree: ah ok, is there any advantage to specifying that at a higher level, rather than within gdb.morph ? | 18:00 |
| persia | bashrc: Consider the case where you have to change the ref for a large number of components (e.g. Qt or Xorg). How many files do you want to edit? | 18:01 |
| persia | Also, how do you want to read the results of `git diff` to see what you did? | 18:01 |
| bashrc | another point is that I don't see any reference to tools.morph within gdb.morph, but maybe its interpreted the other way around. Still, doesn't seem ver readable (i.e. guess which higher level morph this one is in) | 18:03 |
| persia | tools says "This stratum contains gbd, at this repo, and this ref". | 18:04 |
| persia | Err, gdb. | 18:04 |
| persia | morph looks about to find gdb.morph to figure out how to build gdb. | 18:04 |
| persia | gdb can be included in any stratum: it really doesn't care. | 18:04 |
| bashrc | ok, but just from the human readability point of view it doesn't seem very easy to know how things link together. I suppose that could be done with a tool | 18:05 |
| persia | And there's lots of reasons to have multple strata contain the same component: e.g. building with different build-dependencies for different behaviours(because ./configure behaviour depends on what is installed in the build environment), | 18:05 |
| persia | To be extra clear, gdb.morph does not link anywhere (although it may be used in several places), and this is intentional. | 18:06 |
| persia | grep can tell you in which strata something is used. | 18:06 |
| bashrc | right. seems like a crude solution though | 18:07 |
| bashrc | anyways, that's all my conundrums for now | 18:07 |
| *** zoli__ has quit IRC | 18:07 | |
| *** bashrc has quit IRC | 18:07 | |
| persia | How crude? | 18:07 |
| persia | I really wouldn't want to have gdb.morph understand any higher level, because that makes it hard to include in lots of places. | 18:08 |
| persia | And I don't want the repo/ref in gdb.morph because that makes it annoying to locally fork, deal with lots of simultaneous updates, etc. | 18:09 |
| straycat | we could have components explicitly specifying the components they depend on, but then you'd want to be able to have macros or something to allow you to specify groups of dependencies otherwise it would be unmanageable | 18:09 |
| persia | But I'd be curious to hear how this arrangement might be confusing, or what sort of tooling you imagine would be less crude. | 18:09 |
| radiofree | he left | 18:09 |
| persia | Ah, good point. | 18:09 |
| persia | In an ideal world, he'll read the backscroll on irclogs.baserock.org when he returns :) | 18:10 |
| *** zoli__ has joined #baserock | 18:11 | |
| *** zoli__ has quit IRC | 18:18 | |
| *** edcragg has quit IRC | 18:22 | |
| *** tiagogomes_ has quit IRC | 18:26 | |
| *** franred has quit IRC | 18:31 | |
| pedroalvarez | -= THIS MESSAGE NOT LOGGED =- | 19:20 |
| * pedroalvarez runs away | 19:21 | |
| *** zoli__ has joined #baserock | 19:23 | |
| straycat | -= THIS MESSAGE NOT LOGGED =- | 19:35 |
| straycat | . | 19:36 |
| SotK | It logs that you said something that wasn't logged though I see | 19:39 |
| persia | This is a feature. A proper redacted log is important, so that if folk respond to unlogged discussion, it doesn't appear they are out of their mind. | 19:50 |
| SotK | makes sense | 19:54 |
| *** zoli__ has quit IRC | 20:22 | |
| *** rdale_ has quit IRC | 20:30 | |
| *** rdale has joined #baserock | 20:33 | |
| *** zoli__ has joined #baserock | 20:33 | |
| *** rdale has quit IRC | 20:39 | |
| *** rdale has joined #baserock | 20:44 | |
| *** rdale_ has joined #baserock | 20:46 | |
| *** rdale has quit IRC | 20:48 | |
| *** pacon has joined #baserock | 20:53 | |
| *** rdale has joined #baserock | 21:08 | |
| *** rdale_ has quit IRC | 21:08 | |
| *** rdale_ has joined #baserock | 21:11 | |
| *** rdale has quit IRC | 21:12 | |
| *** gary_perkins has quit IRC | 21:48 | |
| *** pacon has quit IRC | 22:07 | |
| *** zoli__ has quit IRC | 23:08 | |
| *** zoli__ has joined #baserock | 23:09 | |
| *** zoli__ has quit IRC | 23:26 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!