IRC logs for #baserock for Tuesday, 2014-11-11

*** jmacs_ [] has joined #baserock01:55
*** jmacs [] has quit [Ping timeout: 260 seconds]01:55
*** perryl [] has quit [Ping timeout: 256 seconds]02:05
*** perryl [] has joined #baserock02:05
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock06:32
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Remote host closed the connection]07:27
*** ridgerun1er [] has joined #baserock07:28
*** Zara_ [] has joined #baserock07:28
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]07:47
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock07:48
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 264 seconds]07:52
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock07:55
*** wdutch [] has joined #baserock08:04
*** franred [] has joined #baserock08:23
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock08:25
*** tiagogomes [~tiagogome@] has joined #baserock08:31
*** jonathanmaw [] has joined #baserock08:51
*** mariaderidder [] has joined #baserock09:09
*** mauricemoss_ [] has joined #baserock09:28
*** abdul [~abdul@] has joined #baserock09:33
jjardonSystemd's resolved compiled fine with new glibc :)09:33
abdulssam2, hi sam. wandboard system build in our target is completed. Now we want to create a tarbal. i searched in cluster folder, there is no specific cluster for wandboard. do i need to create a new cluster for it?09:36
*** ssam2 [] has joined #baserock09:37
Mode #baserock +v ssam2 by ChanServ09:37
pedroalvarezjjardon: yeah!! glad to hear that the glibc update is useful!09:37
ratmice________definitely useful considering eglibc has recently gone read-only09:40
pedroalvarezabdul: should be like this:
persiaratmice________: Consider it an invitation for someone else to take over maintainership :)09:43
abdulpedroalvarez, thanks. now i can execute "morph deploy clusters/wandboard-deploy.morph"?09:45
pedroalvarezabdul: if you have put that file in clusters/wandboard-deploy.morph, yes09:46
jjardonpersia: no, eglibc has been merged in glibc09:46
jjardonI think morphlib/exts/simple-network.configure is not needed anymore with the network being automatically configured by systemd?09:48
pedroalvarezI wonder if that means that glibc doesn't need bash anymore09:48
pedroalvarezjjardon: not sure, I believe we have some system definitions without systemd09:49
jjardonpedroalvarez: oh, yeah, the minimal one09:49
jjardonis that being tested/build recently? Seems Its not part of the releases09:50
ssam2I use it as a basis for container systems09:51
ssam2and also test that it builds sometimes when reviewing big changes to definitions.git09:51
jjardonoh god, systemd even configure /etc/resolv.conf automatically (symlink to /run/systemd/resolve/resolv.conf) Expect patches soon!09:53
*** Krin [] has joined #baserock09:57
jjardonis there any script that shows the delta from upstream in all the chunks you are building in a specific system?09:58
KinnisonSadly no, we've not written one of those09:58
pedroalvarezI wonder how to check that for only one chunk09:58
persiagit diff09:58
persiaupstream master HEAD, presumably09:59
abdulpedroalvarez, getting error while i execute "morph deploy clusters/wandboard-deploy.morph" ...
pedroalvarezabdul: aaahh!09:59
persiaBut I want something more generic: as well as showing delta between build and upstream master, I want to be able to see delta between build foo and build bar.10:00
pedroalvarezabdul: my mistake, I took this cluster morphology from definitions.git 2 months ago. Let me fix it.10:00
abdulpedroalvarez, okay10:01
pedroalvarezabdul: btw, that error means: you are trying to deploy the devel-system-armv7lhf-wandboard.morph system and I can't find it10:01
* pedroalvarez is confused10:02
jmacs_ is now known as jmacs10:04
abdulpedroalvarez, okay i will try this10:05
jjardonpersia: git diff againt master HEAD will not show our delta10:08
jjardonyou have to diff agains the commit you branch10:08
persiajjardon: `git diff ${SHA_FROM_DEFINITIONS}...${UPSTREAM DEVELOPMENT TARGET}` does, if you have an up to date git repo.10:09
jjardonpersia: what do you mean by "UPSTREAM DEVELOPMENT TARGET"? To make more clear my point: what if upstream is in version 3.10 and you branched in a random commit between version 3.4 and 3.6?10:13
persiaThat's fine.  git can track down and up and show the total variance.10:14
persia(it also works in seriously non-linear ways, over complex many-limbed merges, etc.)10:14
persiaBut if you are saying "How far am I from the stable branch" or similar, just use that as the second part of the range.10:15
jjardonpersia: Im saying "How far am I from the commit where I branched to create my baserock/morph branch"10:16
persiaDo you mean "What is the set of changes I have made in my branch that have not been merged upstream"?10:18
persiaOr do you mean "What did I do last week?"10:18
pedroalvarezthe former I believe10:18
jjardonpersia: yeah, the former, thats efectively the delta from upstream10:21
persiaBother.  I'm not finding the command today.  I've done it previously, and think I remember it being passing some options to git diff to indicate mine or yours.10:21
persiaAh, it is `git log --left-only --full-diff`10:23
*** locallycompact [] has joined #baserock10:24
pedroalvarezupstream:binutils-redhat should be cached in your system if you have built the wandboard system :/10:30
persiaMaybe try repeating morph build first?10:30
abdulpedroalvarez, from this log i confirmed that build completed successfully10:31
persiaOh, heh, it optimised itself well enough not to cache subobjects10:32
pedroalvarezI'm not sure about what is going on10:33
abdulokay i will repeat the morph build10:37
ssam2seems like a bug in Morph10:37
ssam2I thought we had fixed it, though10:37
*** franred [] has quit [Quit: Leaving]10:38
jjardonpersia: problem is to know what foo or bar is10:38
ssam2no, it's still there. We disable updating gits in the `morph deploy` command, which was once a useful performance improvement, but also causes `morph deploy` to break if the previous `morph build` command used some cached artifacts or used distbuild10:38
ssam2i'll send a patch10:39
robtaylorsome folks here might like this
robtaylorquite expenive tho!10:42
persiajjardon: foo is the ref in definitions.  bar is the upstream target ref10:44
jjardonpersia: Ah! let me try10:45
radiofreepedroalvarez: do you have a board with a recentish version of the jetson-genivi benchline on it?10:45
pedroalvarezradiofree: I think I have yeah10:46
radiofreecan i try something on it? do you have a serial cable?10:46
pedroalvarezradiofree: I do10:46
radiofreepedroalvarez: mouse and keyboard?10:47
persiajjardon: Note that I may be confused: you might have wanted --right-only, or similar.  Check `git help log` for more details, and play a bit.10:47
pedroalvarezradiofree: nope10:48
pedroalvarezradiofree: do I need screen as well?10:48
radiofreepedroalvarez: it's ok i'll deploy it to my devel system to test10:48
jjardonpersia: I think I managed to do it with: git log --left-right master..HEAD10:51
jjardonpersia: thanks for the tip!10:51
persiagit is really, really cool and flexible.  In fact, so much so that if we all spent the rest of our lives learning and teaching each other all the features, we would still not get enough sleep.10:52
jjardondoesnt seem to work with git diff though :/ I will keep investigating10:52
persiaIt doesn't work with git diff, but git log can be convined to show the entire diff10:53
jjardonhere it is: git diff master...HEAD10:54
persiaAnd if you want to collapse th set into a combined diff, you can do that with patchutils10:54
* persia doesn7t suually work in complex enough git repos to know how to do that with git10:54
* jjardon agree with persia in the coolness of git ;)10:55
persiajjardon: doesn't `git diff` include everything, rather than just the diff of the local commits?10:56
* persia thought the goal was to ignore any upstream changes not merged locally, and only show local changes not merged upstream10:56
*** CTtpollard [] has joined #baserock10:57
jjardonpersia: note the three dots ;)10:58
CTtpollardHas anyone used Upstart on Baserock?10:58
persiaoh, heh10:58
KinnisonCTtpollard: Not that we know of10:58
richard_mawCTtpollard: why do you ask?10:58
CTtpollardI'm looking into having a few systems start at boot time, and most of the information I can find for them points to Upstart 10:59
radiofreeisn't upstart dead?10:59
persiaAt least undermaintained10:59
KinnisonCTtpollard: Baserock uses systemd, so look for systemd service files10:59
CTtpollardlast update was september 4 radiofree10:59
radiofreepersia: i mean in the sense ubuntu will be using systemd soon10:59
KinnisonCTtpollard: failing that, find an upstart file and someone here will help you write a systemd service file I'm sure11:00
persiaWell, Baserock systems *often* use systemd: see earlier discussion about ones that do not11:00
CTtpollardI've managed to get a systemd service working for postgres11:00
persiaradiofree: Yes,  but Ubuntu was neither the first to adopt upstart nor ever the only user.11:00
CTtpollardok, ty Kinnison, I'll keep digging 11:01
CTtpollardty all11:01
*** franred [] has joined #baserock11:01
ssam2abdul: I've pushed a branch of morph that I think will fix your issue: 'sam/fix-deploy'11:09
ssam2are you able to try it out and see if it helps ?11:09
richard_mawok, I'm even more puzzled about what's going on with the read-only system integrations, since I've checked my test, and it does check whether file creation works, which ought to be sufficient for testing whether the staging area was writable11:21
richard_mawso now I've got two mysteries11:21
richard_mawwhy it's doing the wrong thing, and why creating the file wasn't triggering failure11:22
jjardonCTtpollard: normally all the important projects already included the systemd .service upstream: take a look there11:22
richard_mawoh, it slipped through because the top-level directories are left writable, but subdirs aren't, so you can write to /etc/passwd, but not /etc/network/foo11:27
*** fay [] has joined #baserock11:39
fay is now known as Guest2754811:39
*** fay_ [] has quit [Ping timeout: 250 seconds]11:40
* jjardon really hopes we can agree on something so he can use upstream tags and doesnt have to change them for hashes and unpetrify-ref in every chunk11:49
persiaYou can use that all you want in your definitions tree.11:50
persiaAnd if anyone tells you otherwise, they are being silly.11:50
persiaIt isn't actually safe to do so unless you can trust upstream behaviour, so for organisations working with upstreams controlled by other organisations, it is wiser not to do so.11:51
richard_mawbut I'll grumble about any attempts to merge it into my definitions tree unless it includes the sha111:51
persiaAnd since Baserock master definitions strives to be an example of how to do it right for independent organisations, upstream always needs SHA1s11:51
Guest27548 is now known as fay_11:52
* persia always uses sha1s personally, because of failures that have happened otherwise11:52
jjardonI understand your concerns, but from a user point of view, its a PITA11:58
persiaFrom a user point of view, I argued passionately for only using SHA1s only six months ago, after people kept breaking my builds and merging or testing different things than I had sent to the mailing list.11:59
persiaAnd as a user, I still stand by my opinions there.  It is trivial to generate the SHA1s given anything else, and not using SHA1s is a recipe for pain.12:00
persiaThat said, I also firmly believe that we should support floating refs for folk who have not yet burnt themselves enough to be willing to track SHA1s.12:00
persia(because this is the sort of thing that must be learned, but is hard to teach)12:00
jjardonsorry, but SHA are for machines, not humans12:01
persiaAnd in some *very special* circumstances, it is even better to use floating refs (e.g. tracking current state of an internal repo, etc.)12:01
jjardonand tags are not floating refs, at least in theory12:01
persiaYes, but I'm sitting at a machine when I use SHA1s, which is why it is trivial to do so.12:01
persiaWhether a tag floats or not is a matter of policy for the repo in question: there's no technical reason for them not to floar.12:02
persiaSame for branches: it is perfectly possible to have a repo policy that prevents branches floating.12:02
richard_mawI've seen some projects use a floating "latest" tag12:02
persiaBut unless I'm in control of the relevant repo policy, I want SHA1s, because of the issues I personally experienced as a user in the past.12:03
persiaAnd if I am in control of the repo policy, I want floating refs, so I don't have to fuss about it (and I would rather morph wasn't all fussy about reproducibility in these cases, because it messes up my definitions repo when I clearly don't care or can control the source repo enough to provide the guarantee morph can't see)12:04
jjardonthen we can use sha in those projects. We are using all the user experience much more difficult than it should be because some exceptions12:04
persiaLike I said before: feel free to use SHA1 if you like.  If anyone says you can't, I'll help you yell at them.12:06
persiaBut I don't believe them to be safe for me, and I don't believe them to be safe for Baserock upstream.12:06
abdulssam2, ok sam12:30
jjardonpersia: of course this is in the context of contributing to baserock, dont think nobody can come to my laptop and tell me what to use ;)12:33
persiaIn that context, I think the most useful thing would be to have better tooling to use SHA1s, so that humans don't have to think about them as much.12:34
persiaFirstly, I don't see any value to unpetrify-ref, and think it ought be dropped entirely.12:34
* jjardon just sent systemd patches :)12:34
persiaAnd secondly, I want a tool that says "go update definitions for chunk foo with HEAD of my current git repo"12:35
persiaI think the best way to implement this would be to pull all the ref: entries out of the structural files entirely, and just have a mapping of component names to refs in a separate file.12:35
persiaThat way tooling can trivially update the file, as can those few humans who want to care about refs, or have a specific need to use floating refs, and everyone else can ignore it.12:36
persiaUsage becomes just cloning or fetching a repo, getting what one wants committed, and telling morph to use it.12:36
persia(without needing to copy & paste the SHA1, but with all the safety of SHA1s)12:37
persiaUnfortunately, none of the folk who are writing tooling seem to like this model :)12:37
*** Krin [] has quit [Remote host closed the connection]13:11
robtaylorthat is a shame, it sounds good to me. Sounds very similar to something Kinnison once proposed, early this year13:22
* SotK likes it too13:22
persiaYes.  Several of us have discussed it in detail and proposed several iterations.13:22
persiaBut none of us has managed to collect enough tuits to be able to cause it to be, sadly13:22
robtaylorthe sha's i n defintions was always supposed to be a stopgap until that could happen13:23
*** Krin [] has joined #baserock13:27
robtaylortuits are indeed sadly scarce entities13:29
*** fay_ [] has quit [Quit: Leaving]13:29
*** fay [] has joined #baserock13:29
fay is now known as Guest7731013:30
Guest77310 is now known as fay_13:30
radiofreei'm starting to think this issue with the graphics are userspace related :\13:40
rdale_what does 'unpetrify-ref' do?14:03
persiaIn certain special use cases that I have not encountered, one can use this to cause one to create a local branch with a matching name against the ref: in a managed checkout.14:04
persiaI think it has something to do with morph edit, which I believe to be unnecessary (and which discussion about on the mailing list indicated that it was an incomplete implementation of something that didn't work).14:05
rdale_ok, thanks but i'm still not actually sure what it does14:06
ssam2unpetrify-ref does nothing14:19
ssam2but, it's useful to have a way of saying 'what branch does this SHA1 come from'14:19
persiaExcept it is often wrong, because it doesn't get updated when branches merge.14:23
persiaSo if I have a long-lived feature branch, and I push it once, using that as unpetrify, and someone merges that, and I continue my work in that branch, the user may be confused if they track me rather than master.14:23
rdale_ah ok, haven't just a hash certainly isn't very clear14:24
persiaAs a result we have a practice of abandoning all merged branches, which makes the history less pretty than it might be.14:24
* persia strongly suspects that anyone who gets confused by checking out a hash doesn't have any of the wonderful git visualisation tools installed14:25
* persia likes tig, but others are also popular14:25
rdale_how to you get from seeing a hash in a morph to seeing something visual?14:26
persia`git clone foo; git checkout ${mysha}; tig`14:27
persiagitk or gitg or any of the others may be substituted for tig14:29
ssam2those tools are nice, but it is inconvenient to have to clone a bunch of repos just to find the name of the stable branch that is being used14:29
ssam2or rather, branches14:30
ssam2enhancing cgit so that when it displayed morphologies you could click links to enter the cgit page for the chunk repo would be a nice solution14:31
*** cosm [] has quit [Ping timeout: 245 seconds]14:32
CTtpollardis there any updates on the lighttpd to web system patch being merged?14:41
persiaI suppose.  I have never needed to determine the branch name from a definitions set, nor particularly cared either I already knew I wanted to replace it with something else, or I didn't really care.14:41
persiaAlso, I don't much like web-based tools, so the idea of changing cgit like that never occured, but I can see the benefit indeed.14:41
persiaCTtpollard: all of those would appear on the mailing list.14:41
Krin is now known as Krin-CT14:44
radiofreeIT WORKS!!14:52
radiofreeor maybe not14:53
jjardonpersia: you have giggle too but its a bit death at the moment14:56
CTtpollardI have the patch notes email persia, it's just something that would be very beneficial to me right now14:59
* persia is very confused15:01
persiaNeither of the last two highlights managed to convey enough information to cause a response, but both are structured in a way that implies they ought.15:02
* rjek is finding being constantly confused his natural state.15:02
*** cosm [] has joined #baserock15:03
*** Krin [] has joined #baserock15:13
*** Krin [] has quit [Remote host closed the connection]15:13
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]15:23
jjardonpersia: giggle is another app similar to gitg or gitk16:01
persiaAh, thanks for the pointer16:06
*** CTtpollard [] has quit [Ping timeout: 245 seconds]16:13
*** Krin-CT [] has quit [Read error: Connection reset by peer]16:35
* paulsher1ood has been away today... is there a solution for the read-only system integration thing ?16:49
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]16:51
*** Krin [] has joined #baserock17:00
*** ssam2 [] has quit [Quit: Leaving]17:07
richard_mawpaulsher1ood: I was looking at it in the morning, but had to pause it to talk to persia in the evening about upgrade stuff17:12
pedroalvarezrichard_maw:  I wonder if you have any suggestions about what to do with nsswitch.conf?17:12
* richard_maw thinks it _might_ actually be possible to do an atomic update of a filesystem17:13
paulsher1oodrichard_maw: what about reverting the patch that causes the issue?17:13
richard_mawpedroalvarez: I think we diverged into speculation about a hypothetical best way to handle it. For now just moving myhostname to immediately after files ought to be sufficient17:13
pedroalvarezrichard_maw: cool! I'll merge it when I have time17:14
richard_mawpaulsher1ood: unsure, it only breaks for the kernel module system integration command because the bug makes directories two levels deep read-only, e.g. you can still write to /etc/passwd, just not /etc/network/interfaces17:15
richard_mawbut I'd support a revert if even one person thought it was necessary17:15
richard_maw/etc/passwd still being writable is how it managed to slip past my testing, since while there was a bug in the error code reporting of test-shell, I was explicitly testing for the file's existance afterwards17:17
paulsher1oodrichard_maw: is there a fix so that deploy to self works? if not, how can we justify not reverting it?17:18
paulsher1oodsorry, it'ds a build issue isn't it17:18
paulsher1oodis there a fix so that build works? 17:18
richard_mawnot for systems that use system-integration commands that need to touch directories two levels deep, but not all our systems need it, unfortunately it's the Jetson system that does.17:19
paulsher1oodis there a workaround?17:19
richard_mawwe're currently working around by not using master of morph to build jetson systems17:20
paulsher1oodwhat was the purpose of the change here?17:20
radiofreepedroalvarez: what genivi baseline image is your jetson running?17:21
*** wdutch [] has quit [Quit: Quit]17:21
richard_mawpaulsher1ood: a code tidy to reduce the duplicated logic for running commands in different namespaces17:22
richard_mawit only escaped notice by the test-suite by contrived circumstances17:22
richard_mawI'll go ahead and revert, I assumed it was a quick fix, which hasn't proven to be the case, especially given I had to pause it.17:23
paulsher1oodok thanks17:23
pedroalvarezradiofree: the one I deployed when testint the nouveau-drm patch you sent.17:24
richard_mawI at least had the foresight to split the work up such that I didn't have to revert the whole series.17:25
paulsher1oodrichard_maw: :-)17:25
radiofreepedroalvarez: could i borrow it for a minute to check something?17:27
paulsher1oodjjardon: has your coreutils stuff been merged?17:29
jjardonpaulsher1ood: nope, need another +117:30
* paulsher1ood guesses not17:30
* richard_maw throws a +1 to jjardon17:30
jjardon\o/ thanks Richard!17:31
paulsher1oodrichard_maw beat me to my ml response17:32
jjardonpedroalvarez's glibc patches conflict with mines, so I will wait for him to merge the glibc stuff. I think he already have a +2?17:33
richard_mawone way to look at the votes is whether you'd be prepared to fix it if it breaks17:33
richard_mawjjardon: he has, and given his query about the nsswitch.conf, I suspect he's currently merging it17:33
* pedroalvarez starts the merge given that the people expects him to do so17:34
paulsher1oodpedroalvarez: :-)17:34
pedroalvarezdo not complain when you see a *full* rebuild :)17:34
persiaIsn't there a mason running that causes that to be cached, so it just means downloading new cache items?17:35
pedroalvarezpersia: 100% true17:35
pedroalvareznot everyone knows that trick to get fresh cash17:36
persiaWhich architectures are running the Mason?  Do we have all of armv7hf, x86_32, and x86_64 yet?17:36
pedroalvarezactually I've forgotten the trick17:36
franredalthough you have to modify your morph to point to that trove17:36
pedroalvarezpersia: only x86_6417:36
persiaThat Mason should be populating the default cache17:36
persiaAnd we should *definitely* do it for x86_32, if not also armv7hf, as lots of folk use that.17:37
persiaHow much effort is it to fix the Mason before we merge the glibc and coreutils stuff (which requires rather a lot of rebuilds)?17:37
franredI though mason was a test not a final system17:37
pedroalvarezpersia: define "fix the mason"17:38
persiaI'm not happy with the architecture of the deployed solution for Mason, let alone any of the code, but I'm even more unhappy about not taking advantage of the functionality we have today.17:38
persiapedroalvarez: heh, in this case I only mean "cause the mason to run against three architectures, instead of one", or even "run three masons, all populating the same cache, for three architectures"17:38
jjardonfranred: is that documented anywhere? seems I missed that 17:39
persiaAlso, when rebuilding the world, we ought drop in the cache key change to insert the architectures, or we just have to rebuild the world again.17:39
*** Krin [] has quit [Remote host closed the connection]17:39
franredjjardon, for fetching cached artifacts from a different trove?17:40
franredlet me check17:40
persiaNevermind, that is more complicated than I want, so we do need two full rebuilds (as getting the morph with the cache key change requires rebuilding to have that morph be available to rebuild other things)17:40
*** Krin [] has joined #baserock17:43
franredjjardon, you could add artifact-cache-server = the_trove_ip_from_where_you_take_the_artifacts to your morph.conf17:49
jjardonfranred: ok, what is the ip of that server?17:50
paulsher1oodshould we modify the wiki to offer the mason trove cache config by default?17:50
jjardonor is already configured in baserock by default?17:50
franredjjardon, it is not configured by default17:51
paulsher1ood(and maybe email the list to notify folks?)17:51
jjardonyes please! :)17:51
pedroalvarezI sent an email about this while ago17:52
franredmaybe worth to add to the wiki - I can't find an entrance for it17:52
pedroalvarez the magic is:17:52
persiaDidn't we give that a real name a couple weeks ago?17:54
jjardonIMHO should be more publicized , as this is one of the major seeling points of baserock, isnt it?17:54
pedroalvarezthis is an artifact cache server (trove)17:54
pedroalvarezwe put a name to mason17:55
pedroalvarezwhich is not the saem17:55
persiajjardon: +117:55
persiaAh, hrm.  Let's give it (or testcache if you insist)17:56
pedroalvarezthe problem of having 3 mason against this, was space in cache.baserock.org17:56
* persia isn't excited about anything in that trove except the artifact cache, and is actively unexcited about the state of the artifact cache at git.baserock.org17:56
persiaCan we not give it a large volume?17:56
paulsher1oodpedroalvarez: is that a matter of bumping space at dc?17:56
persiaAnd can we do anything to remove everything *except* artifact cache to reduce space requirements?17:57
pedroalvarezI agree with you both, I'll give it more space, and remove the git repos when I do the migration in datacentred17:57
pedroalvarezactually, I'll redeploy it17:57
*** mariaderidder [] has quit [Quit: Ex-Chat]17:57
persiaThank you.  Do you also have keys to give it a name, or does that still require a Kinnison?17:58
pedroalvarezi can't do it myself, but I can get it done :)17:58
*** jonathanmaw [] has quit [Quit: Leaving]17:59
*** Krin [] has quit [Remote host closed the connection]17:59
*** mauricemoss_ [] has quit [Quit: Leaving]18:21
pedroalvarezglibc 2.20 has been merged now :)18:41
persiaAnd we are rebuilding for three architeftures, so everyone can work tomorrow?18:41
*** genii [~quassel@ubuntu/member/genii] has joined #baserock18:41
pedroalvarezjust for x86_64 :)18:42
paulsher1oodpedroalvarez: there's a distbuild jetson nework for just this purpose?18:43
pedroalvarezAnd I want to use it to do that, but I didn't have the time18:44
persiaOh well.  We need to get better at this, or we'll be needing to do more releases (and I hope the last one was the last ever, as I always do when a release happens)18:47
pedroalvarezi hope the same everytime I do a release :)18:48
paulsher1oodpedroalvarez: can you let me have the password for the distbuild network machines? (i'd like to repoint them myself)18:56
paulsher1oodoh, actually, do i need to be in dc to log in to them?18:57
persiaYou shouldn't, but you might need to bounce through a host there.19:11
paulsher1oodi think i no longer have one19:27
persiaIsn't that why `morph deploy` exists?19:28
paulsher1oodi gave my machine up because we needed the cores i think19:28
paulsher1oodanyway in other news, i think that the training trove may get pedro's rebuild-the-world patch soon, so i could run the jetson build overnight perhaps19:30
paulsher1ood14 min 38 sec to be precise (til it updates definitions)19:31
paulsher1oodhmmm.... (using ct-training trove, latest morph, latest definitions)19:57
paulsher1oodmust be my vm... same problem with morph build20:00
paulsher1oodbut it works fine from gbo... must be something 'interesting' in using ct-training trove20:07
*** cosm [] has quit [Ping timeout: 272 seconds]20:27
*** cosm [] has joined #baserock21:04
pedroalvarezpaulsher1ood: I've repointed them and I'm currently building a genivi system to populate the cache of baserock-clone22:57
pedroalvarezAlso I've checked mason-x86-64 and is still progressing22:57
*** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection]23:00

Generated by 2.15.3 by Marius Gedminas - find it at!