| *** gtristan has quit IRC | 04:27 | |
| *** gtristan has joined #baserock | 04:52 | |
| petefoth1ringham | wiki.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 petefotheringham | 05:58 | |
| petefoth | Investigations in another place blame nac.net: | 07:55 |
| petefoth | [07:51am] Kinnison: okay, actually the lossy link seems to be nac.net | 07:55 |
| petefoth | [07:52am] Kinnison: both from work and from the camstay network linx.peer.nac.net seems to be very lossy | 07:55 |
| *** tiagogomes__ has quit IRC | 09:05 | |
| *** tiagogomes_ has joined #baserock | 09:05 | |
| *** bashrc has joined #baserock | 09:07 | |
| *** gunnarx has joined #baserock | 09:12 | |
| *** gunnarx has quit IRC | 09:12 | |
| *** gunnarx has joined #baserock | 09:12 | |
| *** toscalix__ has joined #baserock | 09:19 | |
| *** nowster has joined #baserock | 09:20 | |
| *** petefoth has left #baserock | 09:40 | |
| *** jonathanmaw has joined #baserock | 09:40 | |
| *** ssam2 has joined #baserock | 09:41 | |
| *** ChanServ sets mode: +v ssam2 | 09:41 | |
| *** edcragg has joined #baserock | 10:08 | |
| *** gtristan has quit IRC | 10:08 | |
| *** tiagogomes_ has quit IRC | 10:09 | |
| *** tiagogomes_ has joined #baserock | 10:10 | |
| *** petefotheringham has quit IRC | 10:20 | |
| pedroalvarez | gah! http://paste.baserock.org/tazizujate | 10:26 |
| SotK | :( | 10:27 |
| ssam2 | ouch | 10:27 |
| SotK | what is `type` set to in the cluster? | 10:27 |
| pedroalvarez | SotK: that should be it | 10:29 |
| ssam2 | oh yeah | 10:29 |
| * pedroalvarez un-gah's | 10:29 | |
| ssam2 | i guess the problem is we never did a migration script for the change to add extensions/ in extension names | 10:29 |
| ssam2 | so any cluster .morph files outside upstream definitions.git have to be manually fixed | 10:30 |
| pedroalvarez | yes, the problem is that I remembered to update the configure extensions list, but not the type? | 10:31 |
| *** gunnarx has quit IRC | 10:31 | |
| pedroalvarez | SotK: this is wokring, thatks for the hint :) | 10:31 |
| pedroalvarez | working even | 10:31 |
| SotK | no problem | 10:32 |
| *** gtristan has joined #baserock | 10:49 | |
| *** ssam2 has quit IRC | 11:09 | |
| *** ssam2 has joined #baserock | 11:11 | |
| *** ChanServ sets mode: +v ssam2 | 11:11 | |
| *** edcragg has quit IRC | 11:15 | |
| *** edcragg has joined #baserock | 11:17 | |
| jjardon | pedroalvarez: do you remember why ca-certificates was added to core? the commit message doesnt say: http://paste.baserock.org/oqovexaran | 11:51 |
| pedroalvarez | jjardon: they need to be installed before curl | 11:51 |
| straycat | i've patched certdata2pem.py now and it seems to do the right thing, just waiting on the build | 11:52 |
| persia | I remember adding ca-certificates early to allow git to clone https | 11:52 |
| jjardon | and curl is only there because git, rigth? | 11:52 |
| jjardon | straycat: fantastic! :) | 11:53 |
| *** gunnarx has joined #baserock | 11:53 | |
| *** gunnarx has quit IRC | 11:53 | |
| *** gunnarx has joined #baserock | 11:53 | |
| straycat | persia, 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 chunks | 11:54 |
| persia | straycat: At the time ca-certificates was added, most folk were using Baserock as the host | 11:55 |
| *** mariaderidder has joined #baserock | 11:55 | |
| straycat | oh sorry, i misunderstood your response :/ | 11:55 |
| persia | No worries :) | 12:00 |
| jjardon | straycat: 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 system | 12:00 |
| ssam2 | yes, anything that wants to be able to do SSL needs ca-certificates | 12:13 |
| ssam2 | and anything that wants to connect to the web/internet should be able to SSL, really | 12:13 |
| persia | And, 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 IRC | 12:32 | |
| persia | gtristan: 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 |
| gtristan | persia, 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 undesirable | 12:38 | |
| persia | gtristan: 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 |
| persia | To 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 |
| persia | If we are semantically equivalent to e.g. Debian, I'd rather use the more mature tooling Debian has for building systems. | 12:40 |
| persia | As 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 |
| gtristan | I 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 toscalix | 12:42 | |
| persia | gtristan: 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 |
| gtristan | currently, 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 coupling | 12:43 |
| persia | I just create new strata from scratch, ignoring anything anyone else is doing, because they are too hard to reuse. | 12:43 |
| gtristan | then you have lots of duplication | 12:43 |
| persia | But yes, I also don't like strata :) | 12:43 |
| gtristan | we could go the buildroot way as well, and duplicate everything for every build too :) | 12:44 |
| persia | But if I encode that into chunk dependencies, I don't see how I benefit from not using Debian. | 12:44 |
| gtristan | which is not completely insane, but sharing the definitions is interesting | 12:44 |
| gtristan | What we gain from not using debian is an interesting question | 12:45 |
| gtristan | my point of view, honestly | 12:45 |
| persia | (or, more technically, chunk relations, as one may want build-depends, source-depends, runtime-depends, runtime-feature-extends, etc.) | 12:45 |
| gtristan | is 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 repository | 12:45 |
| ssam2 | Baserock is still several orders of magnitude simpler than Debian | 12:46 |
| persia | ssam2: How so? | 12:46 |
| * persia finds Baserock more complex in some ways and simpler in others | 12:46 | |
| gtristan | Debian on the other hand is very rigid in the systems it provides, however it does do an excellent job providing those | 12:46 |
| persia | gtristan: How is Debian rigid? | 12:46 |
| ssam2 | persia: in terms of how complex the build instructions are | 12:47 |
| gtristan | Well, 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 platform | 12:47 |
| ssam2 | persia: 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 |
| gtristan | I dont see much in terms of variants there | 12:47 |
| persia | ssam2: More than 40% of packages in Debian have build instructions consisting of "# /usr/bin/make -f¥n¥n%:¥n¥tdh $@¥n" | 12:48 |
| richard_maw | s/¥/\\/ ? | 12:48 |
| persia | richard_maw: Blame my charset, but yes | 12:48 |
| ssam2 | if I could write that to a file and get Debian to make me a package and put it in my system, that would be nice | 12:48 |
| ssam2 | but I think it's a little more complex than that | 12:48 |
| persia | ssam2: Honestly it isn't. | 12:48 |
| persia | Well, 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 |
| persia | Oh, and in most cases one also needs a file naming the package and describing the dependencies. | 12:49 |
| jmacs | Having spent about the same time with Baserock and the Debian build system, I find Baserock an order of magnitude easier. | 12:49 |
| persia | And that is really all. | 12:49 |
| ssam2 | so all of https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf is totally irrelevant ? | 12:50 |
| persia | gtristan: 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 |
| persia | ssam2: Mostly. | 12:50 |
| ssam2 | interesting! | 12:51 |
| persia | ssam2: 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 |
| ssam2 | thanks, didn't know about that | 12:53 |
| persia | ssam2: Ask me more if you wonder about debian format packaging (but perhaps not in this channel :) ) | 12:54 |
| persia | To 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 |
| ssam2 | the way I understand the 'variants' proposal is that it's basically syntactic sugar to save writing out the same(ish) .morph file 4 times | 12:57 |
| ssam2 | which I agree is not quite what Tristan's email says :-) but I figure we can debate the details later on | 12:58 |
| * gtristan was interrupted... | 12:59 | |
| gtristan | sorry it's 10pm, catching up... | 12:59 |
| persia | I'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 |
| persia | gtristan: Apologies: feel free to respond tomorrow if that is better for you :) | 12:59 |
| *** gunnarx has joined #baserock | 13:00 | |
| persia | My 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 IRC | 13:01 | |
| gtristan | persia, 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 |
| persia | Yes, which I think is important to encode in the definitions. | 13:02 |
| gtristan | while the recipe can vary, its possible (but usually undesirable), that a given chunk can be built with a specific "ref" for another system | 13:02 |
| gtristan | normally, 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 |
| gtristan | but there are cases where divergence is necessary; enter variants | 13:04 |
| * gtristan did not bring up "stable branches" as that is a whole other can of worms | 13:04 | |
| persia | Right, which social construct is what I oppose. | 13:04 |
| persia | If we strive towards a single recipe, we can succeed in achieving compromise, but that means the systems are not optimised. | 13:05 |
| gtristan | persia, a huge part of this is being able to work with shared packages with systems having different goals; but at the same time eliminating duplication | 13:05 |
| persia | And with such compromise, I see no benefit to Baserock. | 13:05 |
| gtristan | right | 13:05 |
| gtristan | well, there is a balance | 13:05 |
| *** nowster has quit IRC | 13:05 | |
| persia | As soon as you say "shared packages", I reiterate that I think that with such a social model, there isn't a point. | 13:05 |
| gtristan | I see, in that case; I have to wonder; why share strata *at all* | 13:06 |
| gtristan | why not start every single system as a completely separate strata ? | 13:06 |
| *** paulwaters_ has joined #baserock | 13:06 | |
| *** nowster has joined #baserock | 13:06 | |
| gtristan | in 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 |
| gtristan | I suppose I see baserock as different mostly *because* it lives in the middle | 13:08 |
| persia | That is how I use strata :) | 13:08 |
| ssam2 | but not, I think, how anyone else does? | 13:09 |
| gtristan | well, systemd lives down in foundation afaics, are there existing systems and strata which do not include foundation ? | 13:09 |
| *** paulwaters_ has quit IRC | 13:09 | |
| jjardon | only the minimal systems | 13:09 |
| richard_maw | gtristan: the one we use in initramfs | 13:09 |
| gtristan | in GNOME, stuff is mostly all over the place | 13:09 |
| SotK | I 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-levels | 13:10 |
| gtristan | and 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 GNOME | 13:10 |
| paulsher1ood | one of the constant dangers is we can make it more complex at any time :) | 13:10 |
| gtristan | I 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 |
| gtristan | honestly, if systemd and all userspace all the way up the stack were simply duplicated inside the gnome.morph strata, including X11 and wayland and everything | 13:12 |
| *** paulwaters_ has joined #baserock | 13:12 | |
| gtristan | there would be much less of a problem, builds would be more optimized, etc | 13:12 |
| gtristan | but 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 |
| persia | And if you want something else, you derive from that, using that as a reference. | 13:14 |
| gtristan | but then you get GNOME Shell right ? | 13:14 |
| gtristan | I 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 me | 13:15 |
| persia | The 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 |
| gtristan | I 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 sense | 13:17 |
| gtristan | of course, you wouldnt be able to "rebase your downstream Baserock product on top of the next stable upstream definitions branch" very easily in that case | 13:17 |
| paulsher1ood | which would be bad | 13:21 |
| persia | I've argued against the value of releases for years now, so I'm delighted by that consequence. | 13:22 |
| persia | The 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 |
| gtristan | Well, 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 there | 13:23 |
| gtristan | persia, I dont think any amount of automated validation will ever be enough to constitute reliable | 13:24 |
| jjardon | FWIW: yocto has a core layer that is shared by all the projects on top (oe-core): http://www.openembedded.org/wiki/OpenEmbedded-Core | 13:24 |
| gtristan | persia, 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 on | 13:25 |
| persia | gtristan: 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 |
| gtristan | There is one area where I will definitely choose debian first | 13:25 |
| paulsher1ood | jjardon: i believe more layers than that are shared... the whole of poky for example | 13:25 |
| persia | There are also yocto projects that don't share those: it is up to the implementor | 13:25 |
| paulsher1ood | i believe official Yocto projects share poky by default. there are clearly projects using bitbake that don't share poky. however i may be wrong | 13:27 |
| gtristan | persia, 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 else | 13:27 |
| paulsher1ood | i agree | 13:28 |
| gtristan | persia, 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 |
| persia | paulsher1ood: Yes, the official ones all share Poky, to the best of my knowledge. | 13:28 |
| persia | gtristan: 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 |
| persia | That 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 |
| gtristan | I want "baserock diff <branch>", I want to maintain my downstream deltas of the whole OS | 13:30 |
| gtristan | not just definitions deltas, deltas against the trove | 13:31 |
| SotK | gtristan: does `morph diff` help there? | 13:31 |
| gtristan | If 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 stack | 13:31 |
| gtristan | and rebase them, as if my entire OS was one git repository | 13:31 |
| gtristan | this makes baserock distinctly awesome | 13:31 |
| gtristan | SotK, right, the point was just to demonstrate what I personally feel is potentially awesome about baserock, and different & distinct from other systems | 13:32 |
| gtristan | if we have that distinction already today, there is absolutely NO reason to try to be different in every single way possible | 13:33 |
| gtristan | if 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 IRC | 13:34 | |
| *** paulwaters_ has joined #baserock | 13:36 | |
| *** toscalix has quit IRC | 13:38 | |
| persia | I 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 IRC | 13:47 | |
| persia | I 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 |
| gtristan | So, 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 |
| persia | To 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 |
| gtristan | we will, and have so far I am sure, innovated some pretty cool things with baserock | 13:48 |
| *** toscalix has joined #baserock | 13:51 | |
| *** paulwaters_ has joined #baserock | 14:12 | |
| *** ssam2 has quit IRC | 14:13 | |
| *** ssam2 has joined #baserock | 14:27 | |
| *** ChanServ sets mode: +v ssam2 | 14:27 | |
| *** ssam2 has quit IRC | 14:35 | |
| *** toscalix has quit IRC | 14:36 | |
| *** ssam2 has joined #baserock | 14:38 | |
| *** ChanServ sets mode: +v ssam2 | 14:38 | |
| jjardon | paulsher1ood: 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 here | 14:40 |
| *** toscalix has joined #baserock | 14:40 | |
| jjardon | http://www.openembedded.org/wiki/OpenEmbedded-Core | 14:40 |
| ssam2 | i'm actually interested if anyone uses BitBake without oe-core/poky, though | 14:41 |
| paulsher1ood | jjardon: persia was talking about yocto, not oe. yocto projects include oe and poky iiuc | 14:41 |
| ssam2 | since almost all of the required functionality is implemented in oe-core/poky | 14:41 |
| paulsher1ood | ssam2: i'm aware of at least one organisation adopting bitbake but creating new recipes completely from scratch | 14:42 |
| ssam2 | are they using the base classes from oe-core/poky, though? | 14:42 |
| ssam2 | or implementing all of the 'fetch source', 'compile', 'generate rootfs', etc. stuff themselves ? | 14:42 |
| CTtpollard | there's quite a few that don't use poky | 14:42 |
| ssam2 | could you point me to any of them? | 14:43 |
| CTtpollard | tizen-distro | 14:45 |
| CTtpollard | it uses oe-core though | 14:45 |
| ssam2 | right. | 14:45 |
| zoli_ | I'm looking into adding gclient support between fetchers. Any thoughts, wishes? | 14:52 |
| ssam2 | which fetchers are these? | 14:56 |
| zoli_ | ssam2: sorry, wrong window. | 14:57 |
| pedroalvarez | :) | 14:57 |
| *** paulwaters_ has quit IRC | 15:12 | |
| *** paulwaters_ has joined #baserock | 15:12 | |
| *** ssam2 has quit IRC | 15:12 | |
| *** fay_ has quit IRC | 15:12 | |
| *** paulwaters_ has quit IRC | 15:12 | |
| *** paulwaters_ has joined #baserock | 15:13 | |
| *** toscalix has quit IRC | 15:15 | |
| *** toscalix__ has joined #baserock | 15:15 | |
| *** fay_ has joined #baserock | 15:17 | |
| *** paulwaters_ has quit IRC | 15:20 | |
| *** paulwaters_ has joined #baserock | 15:20 | |
| *** gunnarx has quit IRC | 15:28 | |
| *** paulwaters_ has quit IRC | 15:29 | |
| *** paulwaters_ has joined #baserock | 15:31 | |
| *** ssam2 has joined #baserock | 15:31 | |
| *** ChanServ sets mode: +v ssam2 | 15:32 | |
| *** gunnarx has joined #baserock | 15:37 | |
| *** gunnarx has quit IRC | 15:37 | |
| *** gunnarx has joined #baserock | 15:37 | |
| *** paulwaters_ has quit IRC | 15:40 | |
| *** tiagogomes_ has quit IRC | 15:43 | |
| *** tiagogomes has joined #baserock | 15:43 | |
| *** tiagogomes has quit IRC | 15:45 | |
| *** tiagogomes has joined #baserock | 15:45 | |
| *** ssam2 has quit IRC | 15:46 | |
| *** ssam2 has joined #baserock | 15:48 | |
| *** ChanServ sets mode: +v ssam2 | 15:48 | |
| *** fay_ has quit IRC | 15:48 | |
| *** fay_ has joined #baserock | 15:48 | |
| *** paulwaters_ has joined #baserock | 16:08 | |
| *** paulwaters_ has joined #baserock | 16:10 | |
| *** gunnarx has quit IRC | 16:39 | |
| *** Walkerdine has joined #baserock | 16:55 | |
| Walkerdine | Hello | 16:56 |
| pedroalvarez | hi! | 17:01 |
| Walkerdine | I'm currently trying to figure out where the artifact cache setting is on the baserock website for morph.conf | 17:06 |
| paulsher1ood | Walkerdine: i think the answer you're seekign is on http://wiki.baserock.org/quick-start/#index4h2 | 17:09 |
| paulsher1ood | artifact-cache-server = http://cache.baserock.org:8080/ | 17:09 |
| Walkerdine | Thank you! yes that was it | 17:14 |
| Walkerdine | I overlooked it | 17:14 |
| *** nowster has quit IRC | 17:18 | |
| paulsher1ood | Walkerdine: how are you getting on? | 17:18 |
| *** tiagogomes has quit IRC | 17:18 | |
| Walkerdine | Everything is going good. I'm going to be picking back up some more here soon | 17:18 |
| Walkerdine | I stopped for awhile cause school | 17:19 |
| paulsher1ood | cool! | 17:19 |
| *** mariaderidder has quit IRC | 17:19 | |
| Walkerdine | I got an error recently that said pre-configure failed for the HMI portion of the GDP | 17:20 |
| pedroalvarez | we will need more information to help you with that error | 17:20 |
| pedroalvarez | like, what version of definitions are you building | 17:21 |
| Walkerdine | genivi-demo-platform-0.1-rebase | 17:22 |
| Walkerdine | genivi-demo-platform-armv7lhf-jetson.morph | 17:22 |
| pedroalvarez | right | 17:23 |
| pedroalvarez | these definitions were merged on master a week ago :) | 17:23 |
| Walkerdine | Does anything change by doing that | 17:24 |
| *** toscalix__ has quit IRC | 17:25 | |
| *** toscalix__ has joined #baserock | 17:25 | |
| pedroalvarez | With that I mean that we have been testing it, and fixing some things, but in different branches | 17:25 |
| pedroalvarez | now is in the master branch | 17:26 |
| pedroalvarez | I don't know exactly what the status was in the "genivi-demo-platform-0.1-rebase" branch | 17:26 |
| Walkerdine | Could that be why everything was downloaded again when I deployed it recently | 17:29 |
| pedroalvarez | hm.. not sure about what "everything" is in this context | 17:31 |
| Walkerdine | Well no not everything I mean it came up with quite a few things it was cloning | 17:31 |
| Walkerdine | [systems/devel-system-armv7lhf-jetson.morph]Cloning upstream:rpcbind | 17:31 |
| Walkerdine | And it couldn't find some of them | 17:32 |
| Walkerdine | ERROR: Cannot find remote git repository: upstream:pyiso8601 | 17:32 |
| pedroalvarez | that's weird | 17:35 |
| paulsher1ood | Walkerdine: can you ping git.baserock.org from there? | 17:35 |
| pedroalvarez | Well, 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 downloaded | 17:35 |
| pedroalvarez | regarding that error, maybe is what paulsher1ood says, and you couldn't see git.baserock.org from there | 17:36 |
| *** Walkerdine has quit IRC | 17:41 | |
| pedroalvarez | this day trying to upgrade gerrit is being fun | 17:52 |
| pedroalvarez | now gerrit seems to not like that the certificate of our openid is not trusted | 17:52 |
| pedroalvarez | oh right, now I understand why that extra playbook is needed Sam, sorry for the noise | 17:56 |
| paulsher1ood | what would be the simplest/best way to automate ongoing syncing a git repo with its upstream? | 18:00 |
| * paulsher1ood is guessing just a cron job | 18:01 | |
| jmacs | Assuming nothing ever conflicts, yes, that sounds appropriate | 18:02 |
| *** bashrc has quit IRC | 18:02 | |
| richard_maw | simplest yes, lorry-controller worked like that initially, but more interesting scheduling was required for the large set of repositories | 18:02 |
| paulsher1ood | scheduling because some are very long operations, so bottlenecks ensued? | 18:03 |
| richard_maw | there was that, plus the need to be able to bump a new one to the front of the queue | 18:04 |
| paulsher1ood | ah, yes | 18:04 |
| paulsher1ood | there'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_maw | no, and no autosync either | 18:05 |
| paulsher1ood | ok, sounds like a cron job, then | 18:05 |
| paulsher1ood | thanks | 18: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 unit | 18:07 | |
| paulsher1ood | ooh, interesting... thanks | 18:07 |
| richard_maw | is this perhaps an attempt to have a proactive git cache rather than an on-demand one? :) | 18:08 |
| paulsher1ood | s/git/artifact/ | 18:10 |
| *** ssam2 has quit IRC | 18:11 | |
| *** jonathanmaw has quit IRC | 18:12 | |
| *** Walkerdine has joined #baserock | 18:14 | |
| Walkerdine | I could see the server it had gone through several other clones before it reached that one | 18:15 |
| paulsher1ood | strange, then.... maybe intermittent network issue? | 18:16 |
| Walkerdine | Could be | 18:17 |
| paulsher1ood | have you rerun it? | 18:18 |
| Walkerdine | I'll have to when I get home again | 18:19 |
| Walkerdine | Yeah its definitely a network issue: Unable to look up git.baserock.org (port 9418) | 18:20 |
| *** toscalix__ has quit IRC | 18:20 | |
| *** edcragg has quit IRC | 18:22 | |
| *** toscalix__ has joined #baserock | 18:26 | |
| persia | On git mirror scheduling: some git servers produce an event stream, to which clients can subscribe to be notified of updates. | 18:28 |
| paulsher1ood | clients means something other than git, though, i assume | 18:29 |
| *** Walkerdine has quit IRC | 18:30 | |
| persia | L | 18:31 |
| persia | paulsherwood: yes, but a script wrapped around git would be a reasonable client. | 18:31 |
| *** gary_perkins has quit IRC | 18:35 | |
| *** gary_perkins has joined #baserock | 18:36 | |
| *** toscalix__ has quit IRC | 18:51 | |
| *** toscalix__ has joined #baserock | 18:51 | |
| *** toscalix__ has quit IRC | 19:23 | |
| *** paulwaters_ has quit IRC | 20:31 | |
| *** edcragg has joined #baserock | 23:18 | |
| *** edcragg has quit IRC | 23:28 | |
| *** edcragg has joined #baserock | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!