| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 00:19 | |
| * persia thinks the needs of web developers differ from the needs of GUI developers differ from the needs of service developers differ from the needs of tool developers, leading to "devel-system" being nomenclature that encourages discussions of paint colour | 01:06 | |
| *** cosm [~Unknown@us1x.mullvad.net] has quit [Ping timeout: 264 seconds] | 01:43 | |
| *** cosm [~Unknown@us1x.mullvad.net] has joined #baserock | 01:45 | |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:50 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 01:51 | |
| petefoth_ is now known as petefoth | 01:51 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 02:47 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:22 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 04:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 245 seconds] | 06:09 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 06:38 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 06:38 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:38 | |
| paulsher1ood | heh | 07:10 |
|---|---|---|
| paulsher1ood | in other news, the databases stratum builds fine on jetson | 07:10 |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:21 | |
| mike is now known as Guest39703 | 07:21 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:36 | |
| * persia likes infinite scrollback, but trying to download 6 months of messages looking for something specific 200 lines at a time makes me very happy to have logging (can we take it out of test?) | 08:02 | |
| * persia finds a discussion with paulsher1ood and pedroalvarez about factory upgrades being broken from August | 08:12 | |
| * persia thanks ssam2 for having provided excellent instructions | 08:13 | |
| pedroalvarez | Time to fix them! | 08:22 |
| pedroalvarez | Regarding to improving the logs, I'm researching in my spare time about it. | 08:24 |
| persia | The start is lovely. For all that things could be better, I believe I now have a better interface for #baserock logs from now. | 08:30 |
| persia | And as long as we have the data, we can get everything from when logging started into the right format | 08:31 |
| persia | (and for that matter, once we have a final format, several of us can probably donate logs for rationalisation into that format to reach further back) | 08:31 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:37 | |
| paulsher1ood | cool :) | 08:47 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
| Kinnison | jjardon: gcc.git took me 30 minutes to clone | 08:58 |
| Kinnison | jjardon: I'm loathe to add it unless you really want to be working from git | 08:58 |
| Kinnison | jjardon: I'd rather you just updated the tarball lorry to pull a newer version | 08:58 |
| Kinnison | jjardon: Also it's a 1.5G git repo, which is a little on the large side | 08:58 |
| persia | What is the slow thing here? | 09:01 |
| Kinnison | it's a GNU project | 09:01 |
| * persia really doesn't like tarballs, because there is not good automation to update | 09:02 | |
| Kinnison | GNU projects are, almost universally, the worst thing for git | 09:02 |
| Kinnison | esp. long lived ones | 09:02 |
| persia | That's not enough. Is it that the server is slow, is it that the latency is high, is it conversions, etc.? | 09:02 |
| Kinnison | We're not converting, their server is reasonably fast, as is my laptop. of the 90m, nearly 45m was CPU time on my laptop | 09:02 |
| Kinnison | GNU projects tickle a pathological behaviour in Git -- specifically with their insistence on a reverse-order 'ChangeLog' | 09:03 |
| Kinnison | every commit (nearly) alters a file by making it longer at the top -- Git is "not good" (tm) at that | 09:03 |
| Kinnison | it makes the delta compression stuff for packs take aaaaaages | 09:04 |
| persia | Isn't the pack delta algorithm selectable? Are they all horrid? | 09:05 |
| Kinnison | No idea if it's selectable or not, or how you would, and I've not experimented beyond trying to clone from gcc.git where one would assume they had selected an algorithm which was the best option for their repo | 09:06 |
| persia | Is it faster with -a-d? | 09:08 |
| Kinnison | pardon? | 09:08 |
| paulsher1ood | could we somehow .gitignore their changelog? :) | 09:09 |
| persia | My apologies: that doesn't actually work with clone. | 09:09 |
| persia | paulsher1ood: That wouldn't cause the set of objects on their server to be different, and partial clones are annoying | 09:10 |
| Kinnison | paulsher1ood: no, richard_maw and I had a brief chat about filter-branch becoming part of lorry, but that makes contribution back hard | 09:10 |
| * Kinnison just doesn't want to add a half-hour clone time to anyone building gcc | 09:10 | |
| paulsher1ood | +1 | 09:10 |
| Kinnison | it's bad enough with linuc | 09:10 |
| Kinnison | linux | 09:10 |
| paulsher1ood | ah, hold on. | 09:11 |
| Kinnison | persia: If you want to +1 the gcc lorry, I'll not stop you, I intend to -0 it | 09:11 |
| Kinnison | (I don't like it, but not strongly enough to veto) | 09:11 |
| persia | People building gcc don't need everything: a shallow clone ought be enough | 09:11 |
| paulsher1ood | for someone who *wants* to build gcc (eg will fiddle with it themselves)... the clone time seems unavoidable | 09:11 |
| paulsher1ood | for others, if we have continuous-everything, they should get a cached gcc anyway? | 09:12 |
| Kinnison | paulsher1ood: and someone who cares not a whit for gcc but needed to alter fhs-dirs? | 09:12 |
| persia | I want to solve the problem. I don't actually care about the gcc lorry, and I don't think random votes on it help other than postponing the issue. | 09:12 |
| Kinnison | persia: there's tradeoffs everywhere | 09:12 |
| paulsher1ood | sorry, for mere mortals, what's fhs-dirs got to do with it? | 09:12 |
| persia | I'd like to see if a different pack algorithm would make it faster, although repacking for lorry can be expensive. | 09:12 |
| Kinnison | persia: a 'shallow clone' doesn't help the next time you need to build a different SHA | 09:12 |
| Kinnison | paulsher1ood: it's lower in the stack | 09:12 |
| persia | Kinnison: Depends which SHA, and how shallow :) | 09:12 |
| Kinnison | IIRC git can't pull updates into a shallow clone without deepening it, no? | 09:13 |
| paulsher1ood | can we tweak our stack? pretty sure we haven't got all the ordering fully optimised? | 09:13 |
| persia | Grr. Seems git doesn't do what I want. If I want a fast pack, I need to have the fast pack on the server already, rather than there being ways I can ask the server to give me a fast pack, or somehow magically receive a different pack than the server provides. | 09:14 |
| persia | But even if upstream made a perfect pack, it would quickly go bad unless every person who pushes uses a pack algorithm that works well with add-text-to-massive-file-at-the-top | 09:14 |
| * paulsher1ood notes that the 'failed to find tarball message' we killed last week may indicate that we used to have something to mitigate part of this, that may no longer be working | 09:15 | |
| Kinnison | We do have something which helps to mitigate the initial clone, but with a GNUish set of content, any time git decides to trigger a gc we're likely waiting for 45m to an hour | 09:16 |
| Kinnison | and the tarball thing works | 09:16 |
| petefoth | I believe that we just killed the error message, and we still lookf firts for a tarball and only go for git if we can’t find one (but I could easily be wrong about that) | 09:16 |
| Kinnison | petefoth: You're not wrong | 09:17 |
| Kinnison | and we didn't kill an error message, we reworded an informational/warning | 09:17 |
| petefoth | \o/ | 09:17 |
| persia | I guess what I want from tarball is a richer syntax, like that for watch files, that would generate a git repo with one commit per release, or similar | 09:17 |
| Kinnison | persia: to my mind, that's for something like (but not exactly like) firehose | 09:17 |
| persia | Ideally a model that would add tags to the repo for every release of every branch of gcc, so one would swap versions and microreleases by changing shas. | 09:18 |
| persia | Kinnison: I consider that *input* for something like firehos | 09:18 |
| Kinnison | persia: our tarball import supports changing the tarball and thusly getting a new sha without losing the old one | 09:18 |
| persia | I want that in *lorry*, because I want to get new commits when upstream releases new tarballs. | 09:18 |
| Kinnison | persia: yes, clearly the watch file is input | 09:18 |
| paulsher1ood | Kinnison: if it works, why would i ever have seen that message? | 09:18 |
| Kinnison | paulsher1ood: because lorry generates the tarballs, so you don't get them for stuff which is inside your trove prefix | 09:19 |
| persia | To be clearer, I want the watch file as input to lorry, and lorry as input to integration automation | 09:19 |
| Kinnison | persia: I suppose we could extend lorry's tarfile support to have watch input | 09:19 |
| paulsher1ood | Kinnison: for gbo, which tarballs should i expect it to find? | 09:19 |
| Kinnison | paulsher1ood: anything in upstream: | 09:19 |
| * paulsher1ood believes he has seen that message often, for upstream: | 09:20 | |
| persia | Kinnison: That's my thought of the least-surprise solution. Not that it isn't a bunch of work :) | 09:20 |
| * paulsher1ood can be wrong of course | 09:20 | |
| Kinnison | persia: I suggest you put a suggestion on the ML -- perhaps someone will pick it up. If we had a storyboard instance we could put it in there :-( | 09:20 |
| Kinnison | paulsher1ood: If your trove configurations were wrong you may have, but it usually works and works well | 09:21 |
| Kinnison | paulsher1ood: There's some work we could do to reduce the brittleness of the configuration | 09:21 |
| pedroalvarez | I believe that the message only happened with our repos | 09:21 |
| persia | Kinnison: Heh. I'll refine it a bit and do that indeed, now that I have more confidence it isn't entirely insane. | 09:21 |
| paulsher1ood | checking logs, i see most of my examples relate to the baserock-clone at datactentred | 09:26 |
| Kinnison | Then your trove configuration is probably incorrect | 09:26 |
| Kinnison | you need to ensure that the trove hostname and id match properly at both ends of the system (trove and morph) otherwise it can't find the tarball files | 09:27 |
| Kinnison | This is the brittleness I said we could do some work to reduce | 09:27 |
| paulsher1ood | but i can find one for g.b.o i think: http://fpaste.org/148017/15179702/ | 09:27 |
| paulsher1ood | trove and morph? all i do is fix /src/morph.conf - is there something else? | 09:28 |
| Kinnison | It depends on how lorry etc is configured on the trove | 09:28 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:33 | |
| ratmice________ | fwiw, from the perspective of someone bootstrapping non-linux stuff off of baserock, we have quite a few patches to gcc, and a) making sure these don't break linux b) maintaining 'em is very helpful OTOH it is a complete hog so i understand, but i was a bit dissapointed to be honest to see the tarball import | 09:33 |
| Kinnison | ratmice________: useful perspective, ta | 09:37 |
| * Kinnison wonders if he should get some shears out to trim ratmice's tail | 09:38 | |
| ratmice________ | they did that to my friend uma :( | 09:40 |
| * Kinnison promises these'll be clean ones, no rust or tetanus in sight | 09:42 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 10:10 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:21 | |
| Mode #baserock +v ssam2 by ChanServ | 10:21 | |
| *** perryl [~lauren@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 10:22 | |
| *** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:27 | |
| *** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 10:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 10:42 | |
| pedroalvarez | franred, ssam2: what do you think about http://85.199.252.87/ and calling it paste.baserock.org? | 11:08 |
| franred | pedroalvarez, I like it | 11:09 |
| jmacs | Nice. | 11:10 |
| pedroalvarez | the good thing about this piece of infra, is that we don't need to back it up :) | 11:11 |
| radiofree | hi, regarding the issue with upgrading on newever jetson kernels, using ROOT_DEVICE would solve the problem (at least on the jetson) | 11:12 |
| radiofree | i was thinking of sending a patch to use ROOT_DEVICE (if available | 11:12 |
| radiofree | if not, do the same thing - read /proc/mounts | 11:13 |
| pedroalvarez | radiofree: how close are we to have our devel system with a newer kernel? | 11:13 |
| pedroalvarez | that also would solve the issue :) | 11:13 |
| radiofree | pedroalvarez: no it wouldn't? | 11:13 |
| radiofree | these newever kernels seem to be the cause of the problem | 11:14 |
| pedroalvarez | then, I'm not sure about what issue are we talking about, sorry :/ | 11:14 |
| radiofree | s/newever/newer | 11:14 |
| radiofree | /proc/mounts lists /dev/root as /, bbut /dev/root doesn't exist | 11:14 |
| radiofree | so upgrade fails trying to mount that | 11:14 |
| radiofree | however, for jetson upgrades/deploys you always need to set the ROOT_DEVICE anyway | 11:14 |
| pedroalvarez | radiofree: I believe that i fixed the need of setting ROOT_DEVICE | 11:15 |
| radiofree | how? | 11:16 |
| pedroalvarez | the issue was fstab with /dev/sda, wasn't it? | 11:16 |
| radiofree | yep | 11:16 |
| radiofree | and the kernel cmdline | 11:16 |
| radiofree | "root=/dev/sda" previously | 11:17 |
| pedroalvarez | radiofree: this one fixed the fstab one: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/commit/?id=558b7dbfb6a62490e65bb4a4667ab8bf03495f68 | 11:18 |
| radiofree | oh right | 11:19 |
| radiofree | i believe that *broke* upgrading | 11:19 |
| franred | when we update morph should we update strata/morph-utils.morph and strta/cross-bootstrap.morph's sha1 ? | 11:19 |
| richard_maw | for anything other than changes to the test-suite, yes | 11:20 |
| radiofree | pedroalvarez: now, on a jetson, it can't get the uuid from /dev/root, so it fails | 11:20 |
| ssam2 | pedroalvarez: makes me a bit sad that it requires javascript, but better than nothing | 11:20 |
| pedroalvarez | hm... | 11:20 |
| ssam2 | and good that it can be used from the console like sprunge.us ! | 11:21 |
| pedroalvarez | ssam2: yup! we can update http://85.199.252.87/about.md to write some instructions :) | 11:22 |
| pedroalvarez | radiofree: is that kernel stable? | 11:22 |
| radiofree | pedroalvarez: http://85.199.252.87/likiqanodo.vhdl | 11:22 |
| radiofree | yes it's pretty stable i've been using it for a week now | 11:22 |
| pedroalvarez | radiofree: I believe that that is a bug in that kernel :/ | 11:23 |
| jmacs | Is the extension auto-detected? | 11:24 |
| radiofree | pedroalvarez: do you have an old jetson devel board around? | 11:25 |
| radiofree | with 3.10 running on it | 11:25 |
| pedroalvarez | yup | 11:25 |
| radiofree | that has a /dev/root i suppose | 11:26 |
| pedroalvarez | jmacs: the colours of the paste depends on the extension you use in the url. | 11:26 |
| jmacs | Oh, I see | 11:26 |
| radiofree | btw my laptop doesn't have a dev/root | 11:26 |
| radiofree | so i'd hardly call it a kernel bug | 11:26 |
| jmacs | So http://85.199.252.87/likiqanodo.python is the same paste with different highlighting. Cool. | 11:27 |
| pedroalvarez | jmacs: also: http://85.199.252.87/raw/likiqanodo | 11:27 |
| pedroalvarez | radiofree: http://85.199.252.87/asexacamaq | 11:32 |
| radiofree | heh | 11:32 |
| radiofree | do you have a /dev/root? | 11:32 |
| pedroalvarez | nope | 11:33 |
| radiofree | it actually get's the correct /dev/mmcblk0p1 device from proc/mounts there | 11:33 |
| radiofree | on this kernel - /dev/root / btrfs rw,noatime,ssd,space_cache 0 0 | 11:34 |
| petefoth | Kinnison: did you have time to look at the latest version of the glossary that I pushed yesterday? | 11:36 |
| Kinnison | I ran out of brain | 11:36 |
| Kinnison | And this morning I forgot | 11:36 |
| * Kinnison is a bad man, and he should feel bad | 11:37 | |
| pedroalvarez | regarding this comment I made yesterday: <pedroalvarez> as a side note, I think cross-bootstrap is broken | 11:37 |
| pedroalvarez | please, ignore it, it was a full-disk issue. | 11:37 |
| * Kinnison shall look now | 11:37 | |
| petefoth | Kinnison: ta! | 11:37 |
| Kinnison | want review here or by email? | 11:37 |
| petefoth | Kinnison: whichever is easiest for you | 11:37 |
| * Kinnison clones | 11:38 | |
| Kinnison | :-) | 11:38 |
| Kinnison | Argh, non wordwrapped text | 11:38 |
| * Kinnison sobs | 11:38 | |
| * Kinnison does it the less pleasant way | 11:38 | |
| * petefoth and Kinnison arfe clearly incompatible on the text-wrapping issue :( | 11:39 | |
| Kinnison | It makes it *very* hard to review and very hard to understand diffs if the text isn't hard-wrapped | 11:39 |
| Kinnison | This is why we have line-length limits in code | 11:39 |
| straycat | Mutually conflicting versions of eggs are apparently fine, so perhaps that's why they haven't bothered with dependency resolution. | 11:42 |
| franred | straycat, you mean that different version of python packages can live in the same system? | 11:43 |
| straycat | If the package is distributed as an egg then apparently yes | 11:44 |
| radiofree | hmm this 3.18 kernel fails to mount the emmc | 11:50 |
| petefoth | ssam2: there’s already a story in http://wiki.baserock.org/stories-for-storyboard/ for updating the Trove Reference manual. Ive changed the line ‘need to add building and updating’ to ‘need to add *installing*, building and updating’, which should cover what we discussed | 11:50 |
| ssam2 | straycat: the same is true of RubyGems, but you can still have a case where there is no valid dependency graph for a specific version of a Gem. E.g. if it depends on A and B and both require differing versions of C | 11:50 |
| petefoth | ssam2: not yet psuhed though | 11:51 |
| ssam2 | petefoth: OK, I'm planning on sending an email to baserock-dev@ summarising the problems | 11:51 |
| petefoth | ssam2: great! | 11:51 |
| ssam2 | which should pretty much all fall under that story | 11:51 |
| Kinnison | petefoth: I remain unconvinced about the last sentence in the Chunk section | 11:52 |
| Kinnison | petefoth: As far as Baserock is concerned a chunk's source comes from one or more git repositories | 11:52 |
| petefoth | Kinnison: yes - that’s one from the last review that I missed. Good spot! | 11:53 |
| straycat | ssam2, good point | 11:55 |
| Kinnison | petefoth: in definitions, a stratum defines what chunks to include and also where they come from | 11:56 |
| Kinnison | petefoth: not sure if that's worth adding | 11:56 |
| Kinnison | petefoth: in deployment, you have a "targte" | 11:57 |
| * Kinnison still dislikes the distributed build text but is having difficulty coming up with replacement text | 11:59 | |
| petefoth | Kinnison: I also missed the comment about ‘tools typically used” ratehr than “tools needed” | 12:00 |
| Kinnison | petefoth: I assumed you'd chosen to ignore that one | 12:00 |
| petefoth | Kinnison: no - it got lost in the backscroll :) | 12:01 |
| * Kinnison also isn't sure about the Git description | 12:01 | |
| Kinnison | we don't use git to control artifacts | 12:01 |
| Kinnison | Not really | 12:01 |
| Kinnison | petefoth: I'd suggest a mention that the git cache server is typically found on the Trove, and also a full stop at the end of the sentence. | 12:02 |
| Kinnison | Then again, fullstoppage seems to be inconsistent in the glossary in general, so perhaps that bit is less important | 12:02 |
| straycat | Kinnison, which distbuild text? | 12:05 |
| petefoth | straycat: we’re discussing / revieiowing the latest http://wiki.baserock.org/glossary/ | 12:05 |
| straycat | I'd use the word parallel rather than concurrent. | 12:06 |
| Kinnison | Again I'm concerned by the text for staging area, but unsure how to clarify it | 12:07 |
| petefoth | straycat: ta! | 12:07 |
| * Kinnison remains against the lego/duplo analogy | 12:08 | |
| straycat | There's some existing text on distbuild here http://wiki.baserock.org/guides/distbuild/ as well | 12:08 |
| * pedroalvarez announces: http://paste.baserock.org/ | 12:09 | |
| radiofree | yay! | 12:10 |
| franred | pedroalvarez, \o/ | 12:10 |
| franred | cheers :) | 12:11 |
| Kinnison | petefoth: otherwise it seems okay | 12:11 |
| * straycat likes the colours | 12:12 | |
| straycat | they happen to fit the scheme i use for everything else | 12:12 |
| straycat | well, roughly | 12:12 |
| pedroalvarez | straycat: I was actually thinking in change some, but keeping the same colours | 12:12 |
| pedroalvarez | s/in change/of changing/ | 12:13 |
| abdul | ssam2: i did some changes in morph file and try to rebuild the image. it is taking long time to start building that particular morph file package lets say kernel | 12:15 |
| ssam2 | abdul: ok, as a starting point could you paste the console output somewhere? | 12:19 |
| ssam2 | maybe to the new http://paste.baserock.org/ :) | 12:19 |
| Kinnison | petefoth: Let me know if you ever rationalise the raw content enough that I can review it properly :-) | 12:19 |
| pedroalvarez | ssam2: how do you use it from the console? | 12:21 |
| abdul | ssam2, http://fpaste.org/148058/19014714/ | 12:22 |
| ssam2 | pedroalvarez: read http://paste.baserock.org/about.md :) | 12:23 |
| pedroalvarez | aha! it says that it needs a client, but we can use this one: http://paste.baserock.org/hastebinit | 12:24 |
| radiofree | hehe http://85.199.252.87/deqodogemu | 12:26 |
| pedroalvarez | radiofree: oh yeah, I have to change the client to show paste.baserock.org instead of the ip | 12:28 |
| ssam2 | abdul: thanks! | 12:30 |
| ssam2 | abdul: that is very slow (about 7 minutes before it starts building), I think mostly due to the slow IO on the system you're building on | 12:31 |
| ssam2 | there are some inefficient parts of Morph that we know about, so it could definitely be better | 12:31 |
| ssam2 | but I don't know how much faster we'd really be able to make it, if /src is on NFS it's always going to be quite slow | 12:32 |
| perryl | i'm following the wiki setup instructions and having trouble with one of the commands; 'mkfs.btrfs -L src /dev/sdb' throws a 'no such file or directory' error | 12:33 |
| pedroalvarez | perryl: I think it's because you haven't attached a secondary disk to the vm | 12:33 |
| ssam2 | abdul: it's great to have timings, anyway, if I get the chance I might try building over NFS myself and see if there are any obvious improvements to be made | 12:33 |
| pedroalvarez | perryl: what are you using, virtualbox. libvirt, openstack? | 12:34 |
| pedroalvarez | a jetson tk1, docker? | 12:35 |
| pedroalvarez | :) | 12:35 |
| perryl | pedroalvarez: i think kvm via virt-manager | 12:35 |
| pedroalvarez | perryl: aha, it's easy to add another disk using virt-manager | 12:36 |
| pedroalvarez | perryl: let me know if you need help with that | 12:36 |
| petefoth1 | 11:53 < Kinnison> petefoth: As far as Baserock is concerned a chunk's source comes from one or more git repositories | 12:36 |
| petefoth1 | sorry - paste into wrong window :( | 12:36 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:40 | |
| abdul | ssam2, but why it is doing "cp -a /src/cache/gits/git___git_baserock_org_delta_linux /src/tmp/staging/tmp6Pe_qq/linux-armv7-wandboard.build/.git", "git checkout 9573986cf27ff44814f3efb1f1e95638406db456", "git cat-file blob" again and again which is consuming more time | 12:40 |
| abdul | ssam2, even if i make a small change | 12:41 |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 12:42 | |
| ssam2 | abdul: this is because Morph does a clean build every time, and constructs a clean staging area to do the build in every time | 12:56 |
| ssam2 | all of the 'git rev-parse' and 'git cat-file blob' stuff is calculating the build graph, that part is waay too slow and on our list of things to fix | 12:57 |
| ssam2 | the 'cp -a' could be replaced if we used some kind of 'union filesystem' to create the build area. That's a bit further in the future though | 12:58 |
| richard_maw | w | 13:02 |
| richard_maw | oops, wrong window | 13:02 |
| petefoth | Kinnison: (and straycat) biff in response to the comments | 13:06 |
| Kinnison | :-) | 13:33 |
| Kinnison | petefoth: new format is much easier to read/review \o/ | 13:34 |
| petefoth | Kinnison: I will try to remember to stick with that editor configuration when I’m working on stuff that is likely to be subject to change or review (despit it neign a pain in the arse for most of what I do) | 13:35 |
| Kinnison | :-) | 13:35 |
| petefoth | s/neign/being/ | 13:35 |
| Kinnison | People tell me off when I whinge about websites having narrow columns, and yet tell me off when I whinge about non wrapped lines in plain text | 13:36 |
| Kinnison | bah | 13:36 |
| petefoth | Most proper modern tools will handle wrapping for you ;) | 13:37 |
| * petefoth ducks | 13:37 | |
| Kinnison | Yeah, but then people whinge when my review comments start with "I have reflowed your document to make it easier to review" | 13:37 |
| Kinnison | Also my nice proper modern tool is explicitly set to not wrap lines | 13:38 |
| Kinnison | :-) | 13:38 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 14:13 | |
| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has joined #baserock | 14:14 | |
| *** cosm [~Unknown@us1x.mullvad.net] has quit [Ping timeout: 272 seconds] | 14:23 | |
| radiofree | pedroalvarez: ok, so found and am testing a 3.18-rc3 based kernel that seems to work pretty well :D | 14:35 |
| radiofree | /dev/mmcblk0p1 / btrfs rw,noatime,ssd,space_cache 0 0 | 14:36 |
| pedroalvarez | radiofree: great! | 14:36 |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 14:39 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:41 | |
| radiofree | is it fine for me to keep creating varius kernel branches for jetsons? | 14:44 |
| rjek | Where might I find information about the process of creating and applying updates/upgrades to a BR system? I can't spot anything appropriate on the wiki | 14:44 |
| radiofree | this one is 3.18-rc3 + gpu + cpufreq | 14:44 |
| radiofree | so we're getting closer to just mainline | 14:44 |
| Kinnison | radiofree: cool | 14:45 |
| ssam2 | rjek: if there's nothing on the wiki that matches what you want, the information probably only resides in people's heads | 14:47 |
| ssam2 | sadly | 14:47 |
| * rjek gets the trepanning tools out. | 14:47 | |
| ssam2 | `morph help deploy` has relevant information, probably not in a very useful format | 14:47 |
| ssam2 | `morph help ssh-rsync.write` would be useful except that nobody wrote it yet | 14:47 |
| Kinnison | The Baserock project, at this time, has no end-to-end for creating updates independently of deploying them to a target device | 14:48 |
| petefoth | ssam2: shoudl i add sh-rsync to the list of write extensions that need documenting? | 14:48 |
| rjek | what's the likelyhood of me able able to upgrade my 14.26 VM to 14.40? | 14:48 |
| ssam2 | petefoth: yes please! | 14:48 |
| ssam2 | rjek: quite high, many of us do that | 14:48 |
| ssam2 | rjek: see http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/scripts/cycle.sh | 14:49 |
| * rjek assumes this is not just a case of typing "morph upgrade" in the VM | 14:49 | |
| petefoth | ssam2: Done - see https://trello.com/c/SxCfpsq5/25-documentation-for-write-and-config-extensions | 14:49 |
| ssam2 | rjek: not yet | 14:49 |
| ssam2 | the script I linked to shows how to deploy an upgrade with version label TEST | 14:49 |
| * rjek isn't sure what that means. | 14:50 | |
| ssam2 | if you do the same but change version label to, say, '14.40', and make sure you run it in a system-branch created with `morph checkout baserock:baserock/definitions 14.40.1`, you should build and upgrade to the 14.40.1 release | 14:50 |
| ssam2 | I don't think I can convey more information through IRC, but I'm happy to explain in person if you want | 14:50 |
| rjek | Ah, I'm just running a downloaded image from baserock.org | 14:53 |
| rjek | I don't have any branches or anything, I just wanted to upgrade what I already have while keeping the files I'd changed in /etc and such | 14:54 |
| ssam2 | currently the only way of upgrading that we have requires you to have used 'morph build' to build the new system | 14:58 |
| pedroalvarez | it should be fast to build it since everything is built in g.b.o | 14:59 |
| ssam2 | we seem to generally consider the released images solely as a way of bootstrapping a devel environment from nothing | 14:59 |
| ssam2 | so I imagine nobody I am aware of will work on implementing an 'upgrade-from-built-image' mechanism for Baserock | 15:00 |
| ssam2 | although I personally would welcome one if someone did create such a thing | 15:00 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:01 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:02 | |
| straycat is now known as vletrmx21 | 15:09 | |
| *** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Remote host closed the connection] | 15:10 | |
| perryl | pedroalvarez: am i right in thinking that to add storage to a vm with virt-manager, i just need to set up a storage pool with a volume inside, or is there more to it? | 15:18 |
| richard_maw | you can also press something like "browse local" which lets you pick a file that isn't in any pre-defined storage pool | 15:19 |
| * Kinnison tends to set up an LVM storage pool out of his spare disk and then use that, since those seem to perform better | 15:20 | |
| pedroalvarez | perryl: I think that the "browse local" way is the easiest | 15:21 |
| rjek | lvm++ | 15:22 |
| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 15:34 | |
| paulsher1ood | pedroalvarez: i've tried your patch but it doesn't seem to be working for me | 15:40 |
| pedroalvarez | paulsher1ood: same error? | 15:41 |
| paulsher1ood | yup... i'm wondering if i've somehow confused morph altogether | 15:41 |
| paulsher1ood | what does morph --version return these days? | 15:42 |
| pedroalvarez | the sha1 | 15:42 |
| paulsher1ood | ah, it's me | 15:42 |
| paulsher1ood | because i've booted into a new system, i'm getting the system morph :) | 15:42 |
| *** moss_maurice [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:43 | |
| vletrmx21 | hello moss_maurice | 15:43 |
| moss_maurice | hi vletrmx21 | 15:43 |
| pedroalvarez | paulsher1ood: let me know if it works | 15:44 |
| moss_maurice | I'm trying to set up a baserock VM, but the fallocate command from the wiki gives me "fallocate failed: Operation not supported", is there a nicer way of allocating space then with dd? | 15:48 |
| paulsher1ood | pedroalvarez: it does ! +1 | 15:48 |
| Kinnison | moss_maurice: You could try truncate(1) instead of fallocate(1) | 15:49 |
| Kinnison | although I don't think that'll allocate the blocks, just set the size of the file | 15:49 |
| moss_maurice | ok, I'll give it a try. | 15:50 |
| pedroalvarez | paulsher1ood: great! | 15:50 |
| * pedroalvarez merges | 15:50 | |
| paulsher1ood | :-) | 15:51 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:56 | |
| perryl | i'm noticing issues with rebooting my baserock vm in accordance with these instructions: http://wiki.baserock.org/guides/no-frills/ | 16:03 |
| persia | perryl: What sort of issues? | 16:04 |
| perryl | i'm not sure if it's mkfs.btrfs or modifying /etc/fstab but upon rebooting i get a timeout message waiting for device dev-disk-by\x2dlabel-src.device, and it boots to emergency mode | 16:04 |
| perryl | i'm guessing with label-src it's the line added to /etc/fstab? | 16:05 |
| pedroalvarez | perryl: yup | 16:05 |
| Kinnison | perryl: when you did the mkfs, did you label the disc? | 16:05 |
| perryl | Kinnison: i inputted the commands exactly as they're written on the wiki; is label defined as -L? | 16:07 |
| Kinnison | I believe so | 16:07 |
| perryl | in that case yes | 16:07 |
| radiofree | perryl: we need to patch the defaults (wherever they are used..) to use nofail | 16:07 |
| radiofree | http://www.freedesktop.org/software/systemd/man/systemd.mount.html | 16:07 |
| *** moss_maurice [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:09 | |
| perryl | it might help if after -L i include 'src'...thanks, Kinnison! | 16:09 |
| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has joined #baserock | 16:11 | |
| *** moss_maurice [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:13 | |
| petefoth1 | perryl: please update the nof-frills wiki page if what's writen there doesn't work for you | 16:54 |
| perryl | petefoth1: it was me mistyping, i believe no-frills is currently fine :) | 16:55 |
| petefoth1 | perryl: :) That's all right then! | 16:56 |
| Kinnison | franred: regarding dmidecode -- eww CVS | 16:57 |
| franred | Kinnison, ummm, I found a git repo: https://github.com/arapov/dmidecode | 17:00 |
| franred | from http://www.nongnu.org/dmidecode/ --> "and is now maintained by Anton Arapov" | 17:01 |
| Kinnison | that seems to lack recent commits to the CVS | 17:01 |
| franred | ummm yep :/ | 17:02 |
| franred | the CVS repository is from: http://savannah.nongnu.org/cvs/?group=dmidecode | 17:03 |
| franred | which is the one which they post in their webpage, so I think I will stick with CVS for the moment | 17:03 |
| radiofree | hi jjardon,what was the GDK env to always use opengl? | 17:05 |
| jjardon | radiofree: GDK_ALWAYS_USE_GL | 17:07 |
| radiofree | thanks | 17:07 |
| jjardon | Kinnison: about gcc: thanks! I only though it could be useful for some dev in the future, but I guess a tarball is fine for now | 17:09 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:24 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:25 | |
| *** moss_maurice [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:52 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:59 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:03 | |
| *** Guest39703 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:03 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:21 | |
| vletrmx21 is now known as straycat | 18:38 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:05 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:25 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 19:52 | |
| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] | 20:33 | |
| *** rdale [~quassel@55.Red-88-17-108.dynamicIP.rima-tde.net] has joined #baserock | 20:37 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:43 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:44 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:47 | |
| *** abdul [~abdul@202.0.77.198] has quit [Remote host closed the connection] | 21:06 | |
| robtaylor | paulsher1ood: you may be interested to know that cosm has figured out how to upgrade the jetson to 4g :) | 22:24 |
| cosm | yeah, actually it's been running a memory tester for about 24hrs now | 22:28 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:28 | |
| robtaylor | cosm: nice! | 22:29 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!