IRC logs for #baserock for Tuesday, 2015-11-03

*** gtristan has quit IRC04:27
*** gtristan has joined #baserock04:52
petefoth1ringhamwiki.baserock.org is horribly slow for me atm. Similar problems with other sites hosted at Branchable (branchable.com, yakking, liw.fi)05:57
*** petefoth1ringham is now known as petefotheringham05:58
petefothInvestigations in another place blame nac.net:07:55
petefoth[07:51am] Kinnison: okay, actually the lossy link seems to be nac.net07:55
petefoth[07:52am] Kinnison: both from work and from the camstay network linx.peer.nac.net seems to be very lossy07:55
*** tiagogomes__ has quit IRC09:05
*** tiagogomes_ has joined #baserock09:05
*** bashrc has joined #baserock09:07
*** gunnarx has joined #baserock09:12
*** gunnarx has quit IRC09:12
*** gunnarx has joined #baserock09:12
*** toscalix__ has joined #baserock09:19
*** nowster has joined #baserock09:20
*** petefoth has left #baserock09:40
*** jonathanmaw has joined #baserock09:40
*** ssam2 has joined #baserock09:41
*** ChanServ sets mode: +v ssam209:41
*** edcragg has joined #baserock10:08
*** gtristan has quit IRC10:08
*** tiagogomes_ has quit IRC10:09
*** tiagogomes_ has joined #baserock10:10
*** petefotheringham has quit IRC10:20
pedroalvarezgah! http://paste.baserock.org/tazizujate10:26
SotK:(10:27
ssam2ouch10:27
SotKwhat is `type` set to in the cluster?10:27
pedroalvarezSotK: that should be it10:29
ssam2oh yeah10:29
* pedroalvarez un-gah's10:29
ssam2i guess the problem is we never did a migration script for the change to add extensions/ in extension names10:29
ssam2so any cluster .morph files outside upstream definitions.git have to be manually fixed10:30
pedroalvarezyes, the problem is that I remembered to update the configure extensions list, but not the type?10:31
*** gunnarx has quit IRC10:31
pedroalvarezSotK: this is wokring, thatks  for the  hint :)10:31
pedroalvarezworking even10:31
SotKno problem10:32
*** gtristan has joined #baserock10:49
*** ssam2 has quit IRC11:09
*** ssam2 has joined #baserock11:11
*** ChanServ sets mode: +v ssam211:11
*** edcragg has quit IRC11:15
*** edcragg has joined #baserock11:17
jjardonpedroalvarez: do you remember why ca-certificates was added to core? the commit message doesnt say: http://paste.baserock.org/oqovexaran11:51
pedroalvarezjjardon: they need to be installed before curl11:51
straycati've patched certdata2pem.py now and it seems to do the right thing, just waiting on the build11:52
persiaI remember adding ca-certificates early to allow git to clone https11:52
jjardonand curl is only there because git, rigth?11:52
jjardonstraycat: fantastic! :)11:53
*** gunnarx has joined #baserock11:53
*** gunnarx has quit IRC11:53
*** gunnarx has joined #baserock11:53
straycatpersia, git clone is going to be done with the host tools i think, so that shouldn't be an issue. i think git is in core for generating version numbers for some chunks11:54
persiastraycat: At the time ca-certificates was added, most folk were using Baserock as the host11:55
*** mariaderidder has joined #baserock11:55
straycatoh sorry, i misunderstood your response :/11:55
persiaNo worries :)12:00
jjardonstraycat: I was thinking on moving ca-certificates/curl to where we build the complete git chunk, but they seems to be something that should go in almost every system12:00
ssam2yes, anything that wants to be able to do SSL needs ca-certificates12:13
ssam2and anything that wants to connect to the web/internet should be able to SSL, really12:13
persiaAnd, frustratingly, that means we need ca-certificates at a rather low level, or we end up not being able to build things with SSL support, which breaks all sorts of things.12:23
*** gunnarx has quit IRC12:32
persiagtristan: I've finally managed to read through your runtime-depends/flavours proposal.  To my eyes, this reads like a refactoring such that we end up with one-true-chunk-defintion for each chunkname.  As such, how do you imagine such a layout differs from a package-based model?12:32
gtristanpersia, not sure I understand the question, what do you mean by a "package-based model" ?12:37
* gtristan is unsure, also, if it does *not* differ from a package-based model, why that would be undesirable12:38
persiagtristan: Something like Debian or Fedora, where one has a description of what to do to convert a given source into one or more binary blobs, where each binary blob has a known API to be able to integrate it into a system.12:39
persiaTo me, the interesting thing about Baserock is that I can define two systems that use the same source in two different ways, with two very different builds (and different build-dependencies), to achieve tighter control over what is present.12:40
persiaIf we are semantically equivalent to e.g. Debian, I'd rather use the more mature tooling Debian has for building systems.12:40
persiaAs an example, depending on my target system, I might want to build bluez with or without audio support, which is tricky to do with the one-true-chunk or package model.12:41
gtristanI am not interested in it being different for the sake of difference, however I do believe the proposed model offers you greater granularity and flexibility in defining very different builds, while flavors/variants allow for divergences of dependencies - but also keep package definitions nicely isolated into their own files.12:42
*** toscalix__ is now known as toscalix12:42
persiagtristan: I agree with the granuarity and flexibility you describe, except that I don't see the point of Baserock as a concept if it is adopted, as I don't see why we don't use Debian if we have that model.  I hope I am missing something subtle.12:43
gtristancurrently, when defining a linux build for a specific purpose build, you end up with a huge overhead of refactoring existing strata, due to their tight coupling12:43
persiaI just create new strata from scratch, ignoring anything anyone else is doing, because they are too hard to reuse.12:43
gtristanthen you have lots of duplication12:43
persiaBut yes, I also don't like strata :)12:43
gtristanwe could go the buildroot way as well, and duplicate everything for every build too :)12:44
persiaBut if I encode that into chunk dependencies, I don't see how I benefit from not using Debian.12:44
gtristanwhich is not completely insane, but sharing the definitions is interesting12:44
gtristanWhat we gain from not using debian is an interesting question12:45
gtristanmy point of view, honestly12:45
persia(or, more technically, chunk relations, as one may want build-depends, source-depends, runtime-depends, runtime-feature-extends, etc.)12:45
gtristanis that ultimately, I think Baserock should be a way that you can view your entire embedded OS build + applications, as if it were a single git repository12:45
ssam2Baserock is still several orders of magnitude simpler than Debian12:46
persiassam2: How so?12:46
* persia finds Baserock more complex in some ways and simpler in others12:46
gtristanDebian on the other hand is very rigid in the systems it provides, however it does do an excellent job providing those12:46
persiagtristan: How is Debian rigid?12:46
ssam2persia: in terms of how complex the build instructions are12:47
gtristanWell, it perhaps does allow for defining a system as a toaster or a simple embedded device, but afaik it does a single build for a single platform12:47
ssam2persia: if you wrote out all the possible layouts and contents of debian/rules and every supplementary file, how long would the resulting document be?12:47
gtristanI dont see much in terms of variants there12:47
persiassam2: More than 40% of packages in Debian have build instructions consisting of "# /usr/bin/make -f¥n¥n%:¥n¥tdh $@¥n"12:48
richard_maws/¥/\\/ ?12:48
persiarichard_maw: Blame my charset, but yes12:48
ssam2if I could write that to a file and get Debian to make me a package and put it in my system, that would be nice12:48
ssam2but I think it's a little more complex than that12:48
persiassam2: Honestly it isn't.12:48
persiaWell, technically, one also needs a changelog entry, a file describing the licensing of the source, and 2 static files that can be templated.12:49
persiaOh, and in most cases one also needs a file naming the package and describing the dependencies.12:49
jmacsHaving spent about the same time with Baserock and the Debian build system, I find Baserock an order of magnitude easier.12:49
persiaAnd that is really all.12:49
ssam2so all of https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf is totally irrelevant ?12:50
persiagtristan: So, exploring the idea of single-build-for-single-platform: how do you imagine chunk builds happening in Baserock that would cause variance of builds?12:50
persiassam2: Mostly.12:50
ssam2interesting!12:51
persiassam2: http://ubuntulinuxtipstricks.blogspot.com/2010/08/is-packaging-new-software-hard.html is a quick guide expanded from a 3-minute tutorial I used to give on IRC.12:51
ssam2thanks, didn't know about that12:53
persiassam2: Ask me more if you wonder about debian format packaging (but perhaps not in this channel :) )12:54
persiaTo be clear, I think Baserock is nifty and interesting, and I don't much like packages anymore, so while I mention the simplicity and flexibility of Debian tooling, I'm mostly doing so to try to understand what is being proposed, in hopes we aren't just repeating what was done before.12:54
persia(for me, problems with packages include update ordering issues, "maintainer scripts", build timing issues not promising single libary inclusion, etc.)12:55
ssam2the way I understand the 'variants' proposal is that it's basically syntactic sugar to save writing out the same(ish) .morph file 4 times12:57
ssam2which I agree is not quite what Tristan's email says :-) but I figure we can debate the details later on12:58
* gtristan was interrupted...12:59
gtristansorry it's 10pm, catching up...12:59
persiaI'm happy with that idea, so long as build-depends are also per-flavour (as many build systems autodetect what to build depending on what is present in the build system)12:59
persiagtristan: Apologies: feel free to respond tomorrow if that is better for you :)12:59
*** gunnarx has joined #baserock13:00
persiaMy fear is mostly that we may end up with the resultant artifacts being considered meaningful (e.g. binary packages), such that we end up with the potential to have two chunks built against differing versions of a library, etc.13:01
*** paulwaters_ has quit IRC13:01
gtristanpersia, what would cause variance of builds is mostly that one cannot state with certainty that the recipe for building a given package is correct for more than one end-user's use case, i.e. the same recipe is not correct for every "system"13:02
persiaYes, which I think is important to encode in the definitions.13:02
gtristanwhile the recipe can vary, its possible (but usually undesirable), that a given chunk can be built with a specific "ref" for another system13:02
gtristannormally, I would envision this in conjunction with stable branches and development branches of baserock - for instance, every system has a maintainer, and those maintainers of each baserock system should find as much agreement as possible as to what build recipe is appropriate to share for commonly shared packages in "baserock stable"13:04
gtristanbut there are cases where divergence is necessary; enter variants13:04
* gtristan did not bring up "stable branches" as that is a whole other can of worms13:04
persiaRight, which social construct is what I oppose.13:04
persiaIf we strive towards a single recipe, we can succeed in achieving compromise, but that means the systems are not optimised.13:05
gtristanpersia, a huge part of this is being able to work with shared packages with systems having different goals; but at the same time eliminating duplication13:05
persiaAnd with such compromise, I see no benefit to Baserock.13:05
gtristanright13:05
gtristanwell, there is a balance13:05
*** nowster has quit IRC13:05
persiaAs soon as you say "shared packages", I reiterate that I think that with such a social model, there isn't a point.13:05
gtristanI see, in that case; I have to wonder; why share strata *at all*13:06
gtristanwhy not start every single system as a completely separate strata ?13:06
*** paulwaters_ has joined #baserock13:06
*** nowster has joined #baserock13:06
gtristanin that case, we achieve the same stability (changes to system A never compromise system B), and we never have stop energy deciding "in what strata a chunk should live"13:07
gtristanI suppose I see baserock as different mostly *because* it lives in the middle13:08
persiaThat is how I use strata :)13:08
ssam2but not, I think, how anyone else does?13:09
gtristanwell, systemd lives down in foundation afaics, are there existing systems and strata which do not include foundation ?13:09
*** paulwaters_ has quit IRC13:09
jjardononly the minimal systems13:09
richard_mawgtristan: the one we use in initramfs13:09
gtristanin GNOME, stuff is mostly all over the place13:09
SotKI think that strata become less useful the higher up the software stack you get... we don't have the same "lets split this into a new stratum" trouble so much at low-levels13:10
gtristanand deciding what goes into which strata is a disaster - trying to change/refactor it is a huge work, re: the days I spent moving webkit outside of GNOME13:10
paulsher1oodone of the constant dangers is we can make it more complex at any time :)13:10
gtristanI added cracklib to gnome strata where it clearly does not belong, as pushing it down in foundation is questionable ("Who includes foundation ?" I would have to ask myself, this is an experimental change: is it safe ?)13:11
gtristanhonestly, if systemd and all userspace all the way up the stack were simply duplicated inside the gnome.morph strata, including X11 and wayland and everything13:12
*** paulwaters_ has joined #baserock13:12
gtristanthere would be much less of a problem, builds would be more optimized, etc13:12
gtristanbut then all of the chunk definitions would not really let you define systems flexibly, you would just be stuck with "the gnome system"13:13
persiaAnd if you want something else, you derive from that, using that as a reference.13:14
gtristanbut then you get GNOME Shell right ?13:14
gtristanI mean, speaking with my GNOME hat on, I couldn't care less about the GNOME Desktop - it's the stack and platform which is interesting to me13:15
persiaThe alternative is t have shared components, but if I am building a system based on QML, I may not want some of the low-level choices you made for GNOME, because I expect to have entirely different libraries present.13:15
gtristanI think that derivation with "strata as we know it" is not useful, as it invariably pulls in chunks you dont need for your resulting OS - while, on the other hand, copy/pasting a strata and diverging from it here and there may make some sense13:17
gtristanof course, you wouldnt be able to "rebase your downstream Baserock product on top of the next stable upstream definitions branch" very easily in that case13:17
paulsher1oodwhich would be bad13:21
persiaI've argued against the value of releases for years now, so I'm delighted by that consequence.13:22
persiaThe trick is to finsh the project to be able to update components in a system under continuous validation to the point where it is typically safe to confidently have a recent system, rather than deriving from known good states because one lacks appropriate validation mechanisms.13:23
gtristanWell, honestly I do stand by my proposal based on it's own merit - the question of how unique baserock is when compared to something else is destabilizing to be sure, I only proposed that based on my short experience working with what is there13:23
gtristanpersia, I dont think any amount of automated validation will ever be enough to constitute reliable13:24
jjardonFWIW: yocto has a core layer that is shared by all the projects  on top (oe-core): http://www.openembedded.org/wiki/OpenEmbedded-Core13:24
gtristanpersia, this is something I definitely feel strongly about: I dont see any reason why I would start using baserock myself, to build my own product, if there is no shared stable reference platform to base my work on13:25
persiagtristan: Your proposal is strong, and while I agree that the choices there constitute a good system, I am unconfident that it is usefully distinct from other systems, and I think that exploring new things is more worthwhile.13:25
gtristanThere is one area where I will definitely choose debian first13:25
paulsher1oodjjardon: i believe more layers than that are shared... the whole of poky for example13:25
persiaThere are also yocto projects that don't share those: it is up to the implementor13:25
paulsher1oodi believe official Yocto projects share poky by default. there are clearly projects using bitbake that don't share poky. however i may be wrong13:27
gtristanpersia, I think whether or not we explore other things as things which make Baserock unique, the proposal brings up some pain points which need to be addressed before anything else13:27
paulsher1oodi agree13:28
gtristanpersia, whether it be by way of implementing the proposal, or by a strict policy change to say that "every system has it's own strata, period"13:28
persiapaulsher1ood: Yes, the official ones all share Poky, to the best of my knowledge.13:28
persiagtristan: I think your proposal covers more pain points than just the strata mess, and yes, I agree we need to resolve them: I'm just not sure that resolving them as you suggest leads to differentiated useful tooling.13:29
persiaThat said, if everyone else likes your proposal, I'm happy to help explore how we can migrate everything to a package format in a reliable manner, and perhaps merge with one of the package-based projects.13:30
gtristanI want "baserock diff <branch>", I want to maintain my downstream deltas of the whole OS13:30
gtristannot just definitions deltas, deltas against the trove13:31
SotKgtristan: does `morph diff` help there?13:31
gtristanIf I can see my whole OS as a branch of an upstream stable baserock OS of a selected system, and make changes all the way across the stack13:31
gtristanand rebase them, as if my entire OS was one git repository13:31
gtristanthis makes baserock distinctly awesome13:31
gtristanSotK, right, the point was just to demonstrate what I personally feel is potentially awesome about baserock, and different & distinct from other systems13:32
gtristanif we have that distinction already today, there is absolutely NO reason to try to be different in every single way possible13:33
gtristanif we choose the technique based on it's merits and we find out that we have some advantage, we will have something strong - if we find out that we are exactly debian, we can move on and develop something else, right ?13:34
*** paulwaters_ has quit IRC13:34
*** paulwaters_ has joined #baserock13:36
*** toscalix has quit IRC13:38
persiaI chose Debian as one example, but in my mind, if we discover we are exactly Debian, we ought continue to be that, only under different branding.13:43
*** paulwaters_ has quit IRC13:47
persiaI like the idea of being able to diff and rebase, but as I was doing that against Debian in 2005, I hope for something richer from Baserock.13:47
gtristanSo, I guess my answer to the original question is: Lets do what ultimately seems correct and optimal, and be careful to not let our practical decisions be influenced by a perceived necessity to be different :)13:47
persiaTo be clear: I don't think we *need* be different, but only that if we aren't different, we should participate as part of something else, rather than attempting to have a separate identity.13:48
gtristanwe will, and have so far I am sure, innovated some pretty cool things with baserock13:48
*** toscalix has joined #baserock13:51
*** paulwaters_ has joined #baserock14:12
*** ssam2 has quit IRC14:13
*** ssam2 has joined #baserock14:27
*** ChanServ sets mode: +v ssam214:27
*** ssam2 has quit IRC14:35
*** toscalix has quit IRC14:36
*** ssam2 has joined #baserock14:38
*** ChanServ sets mode: +v ssam214:38
jjardonpaulsher1ood: oe-core is used outside yocto, in the open.embedded project, for example. And poky is only a snapshot of bitbake+recipes, so not sure we are comparing the same thing here14:40
*** toscalix has joined #baserock14:40
jjardonhttp://www.openembedded.org/wiki/OpenEmbedded-Core14:40
ssam2i'm actually interested if anyone uses BitBake without oe-core/poky, though14:41
paulsher1oodjjardon: persia was talking about yocto, not oe. yocto projects include oe and poky iiuc14:41
ssam2since almost all of the required functionality is implemented in oe-core/poky14:41
paulsher1oodssam2: i'm aware of at least one organisation adopting bitbake but creating new recipes completely from scratch14:42
ssam2are they using the base classes from oe-core/poky, though?14:42
ssam2or implementing all of the 'fetch source', 'compile', 'generate rootfs', etc. stuff themselves ?14:42
CTtpollardthere's quite a few that don't use poky14:42
ssam2could you point me to any of them?14:43
CTtpollardtizen-distro14:45
CTtpollardit uses oe-core though14:45
ssam2right.14:45
zoli_I'm looking into adding gclient support between fetchers. Any thoughts, wishes?14:52
ssam2which fetchers are these?14:56
zoli_ssam2: sorry, wrong window.14:57
pedroalvarez:)14:57
*** paulwaters_ has quit IRC15:12
*** paulwaters_ has joined #baserock15:12
*** ssam2 has quit IRC15:12
*** fay_ has quit IRC15:12
*** paulwaters_ has quit IRC15:12
*** paulwaters_ has joined #baserock15:13
*** toscalix has quit IRC15:15
*** toscalix__ has joined #baserock15:15
*** fay_ has joined #baserock15:17
*** paulwaters_ has quit IRC15:20
*** paulwaters_ has joined #baserock15:20
*** gunnarx has quit IRC15:28
*** paulwaters_ has quit IRC15:29
*** paulwaters_ has joined #baserock15:31
*** ssam2 has joined #baserock15:31
*** ChanServ sets mode: +v ssam215:32
*** gunnarx has joined #baserock15:37
*** gunnarx has quit IRC15:37
*** gunnarx has joined #baserock15:37
*** paulwaters_ has quit IRC15:40
*** tiagogomes_ has quit IRC15:43
*** tiagogomes has joined #baserock15:43
*** tiagogomes has quit IRC15:45
*** tiagogomes has joined #baserock15:45
*** ssam2 has quit IRC15:46
*** ssam2 has joined #baserock15:48
*** ChanServ sets mode: +v ssam215:48
*** fay_ has quit IRC15:48
*** fay_ has joined #baserock15:48
*** paulwaters_ has joined #baserock16:08
*** paulwaters_ has joined #baserock16:10
*** gunnarx has quit IRC16:39
*** Walkerdine has joined #baserock16:55
WalkerdineHello16:56
pedroalvarezhi!17:01
WalkerdineI'm currently trying to figure out where the artifact cache setting is on the baserock website for morph.conf17:06
paulsher1oodWalkerdine: i think the answer you're seekign is on http://wiki.baserock.org/quick-start/#index4h217:09
paulsher1oodartifact-cache-server = http://cache.baserock.org:8080/17:09
WalkerdineThank you! yes that was it17:14
WalkerdineI overlooked it17:14
*** nowster has quit IRC17:18
paulsher1oodWalkerdine: how are you getting on?17:18
*** tiagogomes has quit IRC17:18
WalkerdineEverything is going good. I'm going to be picking back up some more here soon17:18
WalkerdineI stopped for awhile cause school17:19
paulsher1oodcool!17:19
*** mariaderidder has quit IRC17:19
WalkerdineI got an error recently that said pre-configure failed for the HMI portion of the GDP17:20
pedroalvarezwe will need more information to help you with that error17:20
pedroalvarezlike, what version of definitions are you building17:21
Walkerdinegenivi-demo-platform-0.1-rebase17:22
Walkerdinegenivi-demo-platform-armv7lhf-jetson.morph17:22
pedroalvarezright17:23
pedroalvarezthese definitions were merged on master a week ago :)17:23
WalkerdineDoes anything change by doing that17:24
*** toscalix__ has quit IRC17:25
*** toscalix__ has joined #baserock17:25
pedroalvarezWith that I mean that we have been testing it, and fixing some things, but in different branches17:25
pedroalvareznow is in the master branch17:26
pedroalvarezI don't know exactly what the status was in the "genivi-demo-platform-0.1-rebase" branch17:26
WalkerdineCould that be why everything was downloaded again when I deployed it recently17:29
pedroalvarezhm.. not sure about what "everything" is in this context17:31
WalkerdineWell no not everything I mean it came up with quite a few things it was cloning17:31
Walkerdine[systems/devel-system-armv7lhf-jetson.morph]Cloning upstream:rpcbind17:31
WalkerdineAnd it couldn't find some of them17:32
WalkerdineERROR: Cannot find remote git repository: upstream:pyiso860117:32
pedroalvarezthat's weird17:35
paulsher1oodWalkerdine: can you ping git.baserock.org from there?17:35
pedroalvarezWell, if you didn't change anything in your system, and you were building the same system from the same branch, it shouldn't have downloaded anything that you have previously downloaded17:35
pedroalvarezregarding that error, maybe is what paulsher1ood says, and you  couldn't see git.baserock.org from there17:36
*** Walkerdine has quit IRC17:41
pedroalvarezthis day trying to upgrade gerrit is being fun17:52
pedroalvareznow gerrit seems to not like that the certificate of our openid is not trusted17:52
pedroalvarezoh right, now I understand why that extra playbook is needed Sam, sorry for the noise17:56
paulsher1oodwhat would be the simplest/best way to automate ongoing syncing a git repo with its upstream?18:00
* paulsher1ood is guessing just a cron job18:01
jmacsAssuming nothing ever conflicts, yes, that sounds appropriate18:02
*** bashrc has quit IRC18:02
richard_mawsimplest yes, lorry-controller worked like that initially, but more interesting scheduling was required for the large set of repositories18:02
paulsher1oodscheduling because some are very long operations, so bottlenecks ensued?18:03
richard_mawthere was that, plus the need to be able to bump a new one to the front of the queue18:04
paulsher1oodah, yes18:04
paulsher1oodthere's no way to configure a git repo to check for upstream updates itself?18:04
paulsher1ood(no hidden server in git)?18:04
richard_mawno, and no autosync either18:05
paulsher1oodok, sounds like a cron job, then18:05
paulsher1oodthanks18:05
* richard_maw wrote http://yakking.branchable.com/posts/systemd-7-crontab-and-timers/ recently, which might be of interest if you'd rather do it with a systemd timer unit18:07
paulsher1oodooh, interesting... thanks18:07
richard_mawis this perhaps an attempt to have a proactive git cache rather than an on-demand one? :)18:08
paulsher1oods/git/artifact/18:10
*** ssam2 has quit IRC18:11
*** jonathanmaw has quit IRC18:12
*** Walkerdine has joined #baserock18:14
WalkerdineI could see the server it had gone through several other clones before it reached that one18:15
paulsher1oodstrange, then.... maybe intermittent network issue?18:16
WalkerdineCould be18:17
paulsher1oodhave you rerun it?18:18
WalkerdineI'll have to when I get home again18:19
WalkerdineYeah its definitely a network issue: Unable to look up git.baserock.org (port 9418)18:20
*** toscalix__ has quit IRC18:20
*** edcragg has quit IRC18:22
*** toscalix__ has joined #baserock18:26
persiaOn git mirror scheduling: some git servers produce an event stream, to which clients can subscribe to be notified of updates.18:28
paulsher1oodclients means something other than git, though, i assume18:29
*** Walkerdine has quit IRC18:30
persiaL18:31
persiapaulsherwood: yes, but a script wrapped around git would be a reasonable client.18:31
*** gary_perkins has quit IRC18:35
*** gary_perkins has joined #baserock18:36
*** toscalix__ has quit IRC18:51
*** toscalix__ has joined #baserock18:51
*** toscalix__ has quit IRC19:23
*** paulwaters_ has quit IRC20:31
*** edcragg has joined #baserock23:18
*** edcragg has quit IRC23:28
*** edcragg has joined #baserock23:28

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