| *** jmacs_ [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 01:55 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 260 seconds] | 01:55 | |
| *** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 256 seconds] | 02:05 | |
| *** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 02:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:32 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Remote host closed the connection] | 07:27 | |
| *** ridgerun1er [~robjones@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:28 | |
| *** Zara_ [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:47 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:48 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 264 seconds] | 07:52 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 07:55 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:04 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:23 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:25 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:31 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:51 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:28 | |
| *** abdul [~abdul@202.0.77.198] has joined #baserock | 09:33 | |
| jjardon | Systemd's resolved compiled fine with new glibc :) | 09:33 |
|---|---|---|
| persia | Nice. | 09:34 |
| Kinnison | Exciting! | 09:35 |
| abdul | ssam2, 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 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:37 | |
| Mode #baserock +v ssam2 by ChanServ | 09:37 | |
| pedroalvarez | jjardon: yeah!! glad to hear that the glibc update is useful! | 09:37 |
| ratmice________ | definitely useful considering eglibc has recently gone read-only | 09:40 |
| pedroalvarez | abdul: should be like this: http://paste.baserock.org/uwijarukol.sm | 09:41 |
| persia | ratmice________: Consider it an invitation for someone else to take over maintainership :) | 09:43 |
| abdul | pedroalvarez, thanks. now i can execute "morph deploy clusters/wandboard-deploy.morph"? | 09:45 |
| pedroalvarez | abdul: if you have put that file in clusters/wandboard-deploy.morph, yes | 09:46 |
| jjardon | persia: no, eglibc has been merged in glibc | 09:46 |
| jjardon | I think morphlib/exts/simple-network.configure is not needed anymore with the network being automatically configured by systemd? | 09:48 |
| pedroalvarez | I wonder if that means that glibc doesn't need bash anymore | 09:48 |
| pedroalvarez | jjardon: not sure, I believe we have some system definitions without systemd | 09:49 |
| jjardon | pedroalvarez: oh, yeah, the minimal one | 09:49 |
| jjardon | is that being tested/build recently? Seems Its not part of the releases | 09:50 |
| ssam2 | I use it as a basis for container systems | 09:51 |
| ssam2 | and also test that it builds sometimes when reviewing big changes to definitions.git | 09:51 |
| jjardon | oh god, systemd even configure /etc/resolv.conf automatically (symlink to /run/systemd/resolve/resolv.conf) Expect patches soon! | 09:53 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:57 | |
| jjardon | is there any script that shows the delta from upstream in all the chunks you are building in a specific system? | 09:58 |
| Kinnison | Sadly no, we've not written one of those | 09:58 |
| pedroalvarez | I wonder how to check that for only one chunk | 09:58 |
| persia | git diff | 09:58 |
| pedroalvarez | against? | 09:59 |
| persia | upstream master HEAD, presumably | 09:59 |
| abdul | pedroalvarez, getting error while i execute "morph deploy clusters/wandboard-deploy.morph" ...http://paste.baserock.org/sipulejewe.vhdl | 09:59 |
| pedroalvarez | abdul: aaahh! | 09:59 |
| persia | But 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 |
| pedroalvarez | abdul: my mistake, I took this cluster morphology from definitions.git 2 months ago. Let me fix it. | 10:00 |
| abdul | pedroalvarez, okay | 10:01 |
| pedroalvarez | abdul: btw, that error means: you are trying to deploy the devel-system-armv7lhf-wandboard.morph system and I can't find it | 10:01 |
| abdul | okay | 10:02 |
| pedroalvarez | abdul: http://paste.baserock.org/izulifaboz.sm | 10:02 |
| pedroalvarez | wait | 10:02 |
| * pedroalvarez is confused | 10:02 | |
| pedroalvarez | abdul: http://paste.baserock.org/amacoborac.sm | 10:03 |
| jmacs_ is now known as jmacs | 10:04 | |
| abdul | pedroalvarez, okay i will try this | 10:05 |
| jjardon | persia: git diff againt master HEAD will not show our delta | 10:08 |
| jjardon | you have to diff agains the commit you branch | 10:08 |
| persia | jjardon: `git diff ${SHA_FROM_DEFINITIONS}...${UPSTREAM DEVELOPMENT TARGET}` does, if you have an up to date git repo. | 10:09 |
| jjardon | persia: 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 |
| persia | That'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 |
| persia | But 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 |
| jjardon | persia: Im saying "How far am I from the commit where I branched to create my baserock/morph branch" | 10:16 |
| persia | Do you mean "What is the set of changes I have made in my branch that have not been merged upstream"? | 10:18 |
| persia | Or do you mean "What did I do last week?" | 10:18 |
| pedroalvarez | the former I believe | 10:18 |
| jjardon | persia: yeah, the former, thats efectively the delta from upstream | 10:21 |
| persia | Bother. 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 |
| persia | Ah, it is `git log --left-only --full-diff foo..bar` | 10:23 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:24 | |
| abdul | pedroalvarez, http://paste.baserock.org/oharaxotob.rb | 10:28 |
| pedroalvarez | upstream:binutils-redhat should be cached in your system if you have built the wandboard system :/ | 10:30 |
| persia | Maybe try repeating morph build first? | 10:30 |
| abdul | pedroalvarez, from this log http://paste.baserock.org/ratekocaqa.vhdl. i confirmed that build completed successfully | 10:31 |
| persia | Oh, heh, it optimised itself well enough not to cache subobjects | 10:32 |
| pedroalvarez | I'm not sure about what is going on | 10:33 |
| abdul | okay i will repeat the morph build | 10:37 |
| ssam2 | seems like a bug in Morph | 10:37 |
| ssam2 | I thought we had fixed it, though | 10:37 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 10:38 | |
| jjardon | persia: problem is to know what foo or bar is | 10:38 |
| ssam2 | no, 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 distbuild | 10:38 |
| ssam2 | i'll send a patch | 10:39 |
| robtaylor | some folks here might like this https://www.apm.com/products/data-center/x-gene-family/x-c1-development-kits/ | 10:42 |
| robtaylor | quite expenive tho! | 10:42 |
| pedroalvarez | $2.945! | 10:44 |
| persia | jjardon: foo is the ref in definitions. bar is the upstream target ref | 10:44 |
| jjardon | persia: Ah! let me try | 10:45 |
| radiofree | pedroalvarez: do you have a board with a recentish version of the jetson-genivi benchline on it? | 10:45 |
| pedroalvarez | radiofree: I think I have yeah | 10:46 |
| radiofree | can i try something on it? do you have a serial cable? | 10:46 |
| pedroalvarez | radiofree: I do | 10:46 |
| radiofree | pedroalvarez: mouse and keyboard? | 10:47 |
| persia | jjardon: 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 |
| pedroalvarez | radiofree: nope | 10:48 |
| pedroalvarez | radiofree: do I need screen as well? | 10:48 |
| radiofree | pedroalvarez: it's ok i'll deploy it to my devel system to test | 10:48 |
| jjardon | persia: I think I managed to do it with: git log --left-right master..HEAD | 10:51 |
| jjardon | persia: thanks for the tip! | 10:51 |
| persia | git 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 |
| jjardon | doesnt seem to work with git diff though :/ I will keep investigating | 10:52 |
| persia | It doesn't work with git diff, but git log can be convined to show the entire diff | 10:53 |
| jjardon | here it is: git diff master...HEAD | 10:54 |
| persia | And if you want to collapse th set into a combined diff, you can do that with patchutils | 10:54 |
| * persia doesn7t suually work in complex enough git repos to know how to do that with git | 10:54 | |
| * jjardon agree with persia in the coolness of git ;) | 10:55 | |
| persia | jjardon: doesn't `git diff foo..bar` 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 upstream | 10:56 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:57 | |
| jjardon | persia: note the three dots ;) | 10:58 |
| CTtpollard | Has anyone used Upstart on Baserock? | 10:58 |
| persia | oh, heh | 10:58 |
| Kinnison | CTtpollard: Not that we know of | 10:58 |
| richard_maw | CTtpollard: why do you ask? | 10:58 |
| CTtpollard | I'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 |
| radiofree | isn't upstart dead? | 10:59 |
| persia | At least undermaintained | 10:59 |
| Kinnison | CTtpollard: Baserock uses systemd, so look for systemd service files | 10:59 |
| CTtpollard | last update was september 4 radiofree | 10:59 |
| radiofree | persia: i mean in the sense ubuntu will be using systemd soon | 10:59 |
| Kinnison | CTtpollard: failing that, find an upstart file and someone here will help you write a systemd service file I'm sure | 11:00 |
| persia | Well, Baserock systems *often* use systemd: see earlier discussion about ones that do not | 11:00 |
| CTtpollard | I've managed to get a systemd service working for postgres | 11:00 |
| persia | radiofree: Yes, but Ubuntu was neither the first to adopt upstart nor ever the only user. | 11:00 |
| CTtpollard | ok, ty Kinnison, I'll keep digging | 11:01 |
| CTtpollard | ty all | 11:01 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:01 | |
| ssam2 | abdul: I've pushed a branch of morph that I think will fix your issue: 'sam/fix-deploy' | 11:09 |
| ssam2 | are you able to try it out and see if it helps ? | 11:09 |
| richard_maw | ok, 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 writable | 11:21 |
| richard_maw | so now I've got two mysteries | 11:21 |
| richard_maw | why it's doing the wrong thing, and why creating the file wasn't triggering failure | 11:22 |
| jjardon | CTtpollard: normally all the important projects already included the systemd .service upstream: take a look there | 11:22 |
| richard_maw | oh, 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/foo | 11:27 |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:39 | |
| fay is now known as Guest27548 | 11:39 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] 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 chunk | 11:49 | |
| persia | You can use that all you want in your definitions tree. | 11:50 |
| persia | And if anyone tells you otherwise, they are being silly. | 11:50 |
| persia | It 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_maw | but I'll grumble about any attempts to merge it into my definitions tree unless it includes the sha1 | 11:51 |
| persia | And since Baserock master definitions strives to be an example of how to do it right for independent organisations, upstream always needs SHA1s | 11:51 |
| Guest27548 is now known as fay_ | 11:52 | |
| * persia always uses sha1s personally, because of failures that have happened otherwise | 11:52 | |
| jjardon | I understand your concerns, but from a user point of view, its a PITA | 11:58 |
| persia | From 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 |
| persia | And 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 |
| persia | That 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 |
| jjardon | sorry, but SHA are for machines, not humans | 12:01 |
| persia | And 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 |
| jjardon | and tags are not floating refs, at least in theory | 12:01 |
| persia | Yes, but I'm sitting at a machine when I use SHA1s, which is why it is trivial to do so. | 12:01 |
| persia | Whether 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 |
| persia | Same for branches: it is perfectly possible to have a repo policy that prevents branches floating. | 12:02 |
| richard_maw | I've seen some projects use a floating "latest" tag | 12:02 |
| persia | But 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 |
| persia | And 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 |
| jjardon | then we can use sha in those projects. We are using all the user experience much more difficult than it should be because some exceptions | 12:04 |
| persia | Like 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 |
| persia | But I don't believe them to be safe for me, and I don't believe them to be safe for Baserock upstream. | 12:06 |
| abdul | ssam2, ok sam | 12:30 |
| jjardon | persia: 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 |
| persia | In 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 |
| persia | Firstly, 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 | |
| persia | And secondly, I want a tool that says "go update definitions for chunk foo with HEAD of my current git repo" | 12:35 |
| persia | I 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 |
| persia | That 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 |
| persia | Usage 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 |
| persia | Unfortunately, none of the folk who are writing tooling seem to like this model :) | 12:37 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 13:11 | |
| robtaylor | that is a shame, it sounds good to me. Sounds very similar to something Kinnison once proposed, early this year | 13:22 |
| * SotK likes it too | 13:22 | |
| persia | Yes. Several of us have discussed it in detail and proposed several iterations. | 13:22 |
| persia | But none of us has managed to collect enough tuits to be able to cause it to be, sadly | 13:22 |
| robtaylor | the sha's i n defintions was always supposed to be a stopgap until that could happen | 13:23 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:27 | |
| robtaylor | tuits are indeed sadly scarce entities | 13:29 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 13:29 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:29 | |
| fay is now known as Guest77310 | 13:30 | |
| Guest77310 is now known as fay_ | 13:30 | |
| radiofree | i'm starting to think this issue with the graphics are userspace related :\ | 13:40 |
| rdale_ | what does 'unpetrify-ref' do? | 14:03 |
| persia | In 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 |
| persia | I 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 does | 14:06 |
| ssam2 | unpetrify-ref does nothing | 14:19 |
| ssam2 | but, it's useful to have a way of saying 'what branch does this SHA1 come from' | 14:19 |
| persia | Except it is often wrong, because it doesn't get updated when branches merge. | 14:23 |
| persia | So 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 clear | 14:24 |
| persia | As 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 installed | 14:25 | |
| * persia likes tig, but others are also popular | 14: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 |
| rdale_ | ok | 14:28 |
| persia | gitk or gitg or any of the others may be substituted for tig | 14:29 |
| ssam2 | those 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 used | 14:29 |
| ssam2 | or rather, branches | 14:30 |
| ssam2 | enhancing cgit so that when it displayed morphologies you could click links to enter the cgit page for the chunk repo would be a nice solution | 14:31 |
| *** cosm [~Unknown@us1x.mullvad.net] has quit [Ping timeout: 245 seconds] | 14:32 | |
| CTtpollard | is there any updates on the lighttpd to web system patch being merged? | 14:41 |
| persia | I 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 |
| persia | Also, 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 |
| persia | CTtpollard: all of those would appear on the mailing list. | 14:41 |
| Krin is now known as Krin-CT | 14:44 | |
| radiofree | IT WORKS!! | 14:52 |
| radiofree | or maybe not | 14:53 |
| pedroalvarez | hahah | 14:54 |
| jjardon | persia: you have giggle too but its a bit death at the moment | 14:56 |
| persia | hrm? | 14:57 |
| CTtpollard | I have the patch notes email persia, it's just something that would be very beneficial to me right now | 14:59 |
| * persia is very confused | 15:01 | |
| persia | Neither 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 [~Unknown@cspc154.cs.man.ac.uk] has joined #baserock | 15:03 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:13 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:23 | |
| jjardon | persia: giggle is another app similar to gitg or gitk | 16:01 |
| persia | Ah, thanks for the pointer | 16:06 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:13 | |
| *** Krin-CT [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] 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@213.15.255.100] has quit [Quit: Leaving] | 16:51 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:00 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:07 | |
| richard_maw | paulsher1ood: I was looking at it in the morning, but had to pause it to talk to persia in the evening about upgrade stuff | 17:12 |
| pedroalvarez | richard_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 filesystem | 17:13 | |
| paulsher1ood | richard_maw: what about reverting the patch that causes the issue? | 17:13 |
| richard_maw | pedroalvarez: 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 sufficient | 17:13 |
| pedroalvarez | richard_maw: cool! I'll merge it when I have time | 17:14 |
| richard_maw | paulsher1ood: 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/interfaces | 17:15 |
| richard_maw | but I'd support a revert if even one person thought it was necessary | 17: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 afterwards | 17:17 |
| paulsher1ood | richard_maw: is there a fix so that deploy to self works? if not, how can we justify not reverting it? | 17:18 |
| paulsher1ood | sorry, it'ds a build issue isn't it | 17:18 |
| paulsher1ood | is there a fix so that build works? | 17:18 |
| richard_maw | not 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 |
| paulsher1ood | is there a workaround? | 17:19 |
| richard_maw | we're currently working around by not using master of morph to build jetson systems | 17:20 |
| paulsher1ood | hmmm | 17:20 |
| paulsher1ood | what was the purpose of the change here? | 17:20 |
| radiofree | pedroalvarez: what genivi baseline image is your jetson running? | 17:21 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:21 | |
| richard_maw | paulsher1ood: a code tidy to reduce the duplicated logic for running commands in different namespaces | 17:22 |
| richard_maw | it only escaped notice by the test-suite by contrived circumstances | 17:22 |
| richard_maw | I'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 |
| paulsher1ood | ok thanks | 17:23 |
| pedroalvarez | radiofree: the one I deployed when testint the nouveau-drm patch you sent. | 17:24 |
| richard_maw | I at least had the foresight to split the work up such that I didn't have to revert the whole series. | 17:25 |
| paulsher1ood | richard_maw: :-) | 17:25 |
| radiofree | pedroalvarez: could i borrow it for a minute to check something? | 17:27 |
| pedroalvarez | sure | 17:27 |
| paulsher1ood | jjardon: has your coreutils stuff been merged? | 17:29 |
| jjardon | paulsher1ood: nope, need another +1 | 17:30 |
| * paulsher1ood guesses not | 17:30 | |
| * richard_maw throws a +1 to jjardon | 17:30 | |
| jjardon | \o/ thanks Richard! | 17:31 |
| paulsher1ood | richard_maw beat me to my ml response | 17:32 |
| jjardon | pedroalvarez'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_maw | one way to look at the votes is whether you'd be prepared to fix it if it breaks | 17:33 |
| richard_maw | jjardon: he has, and given his query about the nsswitch.conf, I suspect he's currently merging it | 17:33 |
| jjardon | great | 17:33 |
| * pedroalvarez starts the merge given that the people expects him to do so | 17:34 | |
| paulsher1ood | pedroalvarez: :-) | 17:34 |
| pedroalvarez | do not complain when you see a *full* rebuild :) | 17:34 |
| persia | Isn't there a mason running that causes that to be cached, so it just means downloading new cache items? | 17:35 |
| pedroalvarez | persia: 100% true | 17:35 |
| pedroalvarez | not everyone knows that trick to get fresh cash | 17:36 |
| persia | Which architectures are running the Mason? Do we have all of armv7hf, x86_32, and x86_64 yet? | 17:36 |
| pedroalvarez | actually I've forgotten the trick | 17:36 |
| franred | although you have to modify your morph to point to that trove | 17:36 |
| pedroalvarez | persia: only x86_64 | 17:36 |
| persia | That Mason should be populating the default cache | 17:36 |
| paulsher1ood | +1 | 17:36 |
| persia | And we should *definitely* do it for x86_32, if not also armv7hf, as lots of folk use that. | 17:37 |
| persia | How 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 |
| franred | I though mason was a test not a final system | 17:37 |
| pedroalvarez | persia: define "fix the mason" | 17:38 |
| persia | I'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 |
| persia | pedroalvarez: 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 |
| jjardon | franred: is that documented anywhere? seems I missed that | 17:39 |
| persia | Also, 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 [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:39 | |
| franred | jjardon, for fetching cached artifacts from a different trove? | 17:40 |
| franred | let me check | 17:40 |
| persia | Nevermind, 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 [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:43 | |
| franred | jjardon, you could add artifact-cache-server = the_trove_ip_from_where_you_take_the_artifacts to your morph.conf | 17:49 |
| jjardon | franred: ok, what is the ip of that server? | 17:50 |
| paulsher1ood | should we modify the wiki to offer the mason trove cache config by default? | 17:50 |
| jjardon | or is already configured in baserock by default? | 17:50 |
| franred | jjardon, it is not configured by default | 17:51 |
| paulsher1ood | (and maybe email the list to notify folks?) | 17:51 |
| jjardon | yes please! :) | 17:51 |
| pedroalvarez | I sent an email about this while ago | 17:52 |
| franred | maybe worth to add to the wiki - I can't find an entrance for it | 17:52 |
| pedroalvarez | the magic is: | 17:52 |
| pedroalvarez | artifact-cache-server=http://85.199.252.93:8080/ | 17:52 |
| persia | Didn't we give that a real name a couple weeks ago? | 17:54 |
| jjardon | IMHO should be more publicized , as this is one of the major seeling points of baserock, isnt it? | 17:54 |
| pedroalvarez | this is an artifact cache server (trove) | 17:54 |
| pedroalvarez | we put a name to mason | 17:55 |
| pedroalvarez | which is not the saem | 17:55 |
| pedroalvarez | same* | 17:55 |
| persia | jjardon: +1 | 17:55 |
| persia | Ah, hrm. Let's give it cache.baserock.org (or testcache if you insist) | 17:56 |
| paulsher1ood | +1 | 17:56 |
| pedroalvarez | the problem of having 3 mason against this cache.baserock.org, was space in cache.baserock.org | 17: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.org | 17:56 | |
| paulsher1ood | :) | 17:56 |
| persia | Can we not give it a large volume? | 17:56 |
| paulsher1ood | pedroalvarez: is that a matter of bumping space at dc? | 17:56 |
| paulsher1ood | s/bumping/increasing/ | 17:56 |
| persia | And can we do anything to remove everything *except* artifact cache to reduce space requirements? | 17:57 |
| pedroalvarez | I agree with you both, I'll give it more space, and remove the git repos when I do the migration in datacentred | 17:57 |
| pedroalvarez | actually, I'll redeploy it | 17:57 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:57 | |
| persia | Thank you. Do you also have keys to give it a name, or does that still require a Kinnison? | 17:58 |
| pedroalvarez | i can't do it myself, but I can get it done :) | 17:58 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:59 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:59 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:21 | |
| pedroalvarez | glibc 2.20 has been merged now :) | 18:41 |
| persia | And we are rebuilding for three architeftures, so everyone can work tomorrow? | 18:41 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 18:41 | |
| pedroalvarez | just for x86_64 :) | 18:42 |
| paulsher1ood | pedroalvarez: there's a distbuild jetson nework for just this purpose? | 18:43 |
| pedroalvarez | And I want to use it to do that, but I didn't have the time | 18:44 |
| persia | Oh 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 |
| pedroalvarez | i hope the same everytime I do a release :) | 18:48 |
| paulsher1ood | pedroalvarez: can you let me have the password for the distbuild network machines? (i'd like to repoint them myself) | 18:56 |
| paulsher1ood | oh, actually, do i need to be in dc to log in to them? | 18:57 |
| persia | You shouldn't, but you might need to bounce through a host there. | 19:11 |
| paulsher1ood | i think i no longer have one | 19:27 |
| persia | Isn't that why `morph deploy` exists? | 19:28 |
| paulsher1ood | heh | 19:28 |
| paulsher1ood | i gave my machine up because we needed the cores i think | 19:28 |
| paulsher1ood | anyway 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 perhaps | 19:30 |
| paulsher1ood | 14 min 38 sec to be precise (til it updates definitions) | 19:31 |
| paulsher1ood | hmmm.... http://paste.baserock.org/otuxiyolib.mel (using ct-training trove, latest morph, latest definitions) | 19:57 |
| paulsher1ood | must be my vm... same problem with morph build | 20:00 |
| paulsher1ood | but it works fine from gbo... must be something 'interesting' in using ct-training trove | 20:07 |
| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 272 seconds] | 20:27 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 21:04 | |
| pedroalvarez | paulsher1ood: I've repointed them and I'm currently building a genivi system to populate the cache of baserock-clone | 22:57 |
| pedroalvarez | Also I've checked mason-x86-64 and is still progressing | 22:57 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 23:00 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!