| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:25 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:52 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:59 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 08:10 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:12 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 08:24 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:24 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:28 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
| pedroalvarez | I have a plan for the integration of ca-certificates, but implies modifying upstream a bit to add DESTIDR in the update-ca-certificates. | 09:21 |
|---|---|---|
| Kinnison_ | Done neatly, I imagine upstream might take the patch | 09:23 |
| Kinnison_ is now known as Kinnison | 09:23 | |
| * Kinnison docks himself | 09:23 | |
| *** liw-orc [~liw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:38 | |
| straycat | paulsherwood, btw python converts ints to longs in the event they exceed the max for ints, so then you have a much larger range depending on your platform. | 10:04 |
| * straycat yawns | 10:04 | |
| straycat | edinburgh sure is pretty | 10:04 |
| rjek | straycat: Doesn't it then convert them to an arbitrary-precision format? | 10:10 |
| straycat | I thought it converted them to a long | 10:10 |
| rjek | I think Python "long" is not the same as C "long". | 10:11 |
| rjek | I think "long" is python for "arbitrary-precision" | 10:11 |
| rjek | or bigint, at least. | 10:11 |
| straycat | Ahh yeah | 10:12 |
| *** liw_ [liw@xvm-166-37.ghst.net] has joined #baserock | 10:14 | |
| liw_ is now known as liw | 10:14 | |
| pedroalvarez | richard_maw, liw: in case that any of you are interested http://pastebin.com/0NseUHnc | 10:21 |
| richard_maw | :-/ | 10:22 |
| Kinnison | Looks like 32bit vs. 64bit issues | 10:22 |
| liw | is the BR Python built with Large File Support? | 10:27 |
| Kinnison | How would we tell? | 10:28 |
| richard_maw | the only extra config we pass to it is --enable-shared | 10:28 |
| richard_maw | the only integer related configure option I see is: | 10:31 |
| richard_maw | --enable-big-digits[=BITS] | 10:31 |
| richard_maw | use big digits for Python longs [[BITS=30]] | 10:31 |
| juergbi | richard_maw: | 10:34 |
| juergbi | checking whether to enable large file support... yes | 10:34 |
| juergbi | should be the default on 32-bit linux | 10:34 |
| juergbi | and on 64-bit linux, it's not needed, afaik | 10:34 |
| richard_maw | hm, I'll see where the exception comes from | 10:36 |
| liw | python -c 'import sysconfig; print sysconfig.get_config_var("HAVE_LARGEFILE_SUPPORT")' | 10:36 |
| liw | that prints 0 | 10:36 |
| liw | on x86-64, so that's probably ok, as juergbi points out | 10:37 |
| liw | copy_slice_from_file should not try to read that much at a time anyway | 10:39 |
| liw | silly me | 10:39 |
| pedroalvarez | liw: if you have any suggestion to fix it I can try to do that change in my systsem and try again | 10:40 |
| liw | pedroalvarez, just a sec | 10:41 |
| richard_maw | looking at the cpython source, it's not a large file issue, the `os.read` function is limited to an int in size, rather than a size_5 | 10:42 |
| richard_maw | s/size_5/size_t/ | 10:42 |
| liw | pedroalvarez, can you try this patch: http://pastebin.com/qudHbtry | 10:42 |
| liw | richard_maw, good catch | 10:43 |
| pedroalvarez | should I try that then? | 10:43 |
| liw | pedroalvarez, yes please | 10:43 |
| pedroalvarez | liw: deploying, the test can take ~10 minutes | 10:45 |
| liw | ack | 10:46 |
| pedroalvarez | liw: http://pastebin.com/v3MUENP1 :( | 11:25 |
| richard_maw | s/max/min/ ? | 12:28 |
| * richard_maw has often made that mistake | 12:28 | |
| richard_maw | there's something about the confusion of "you have a value which is the maximum" and the choice betwen max and min for me | 12:29 |
| liw | erh, yeah, min instead of max | 12:30 |
| liw | pedroalvarez, could you change the max() to min() in copy_slice_from_file and try again? | 12:31 |
| pedroalvarez | yup | 12:31 |
| * paulsherwood is building latest bash, again | 12:38 | |
| Kinnison | :-) | 12:38 |
| Kinnison | I've not seen anything come out of Debian's security lists yet | 12:39 |
| pedroalvarez | liw: that worked, and transferred the around 6G of disk in a couple of seconds | 12:45 |
| Kinnison | cool | 12:45 |
| pedroalvarez | 6G of 0's I guess | 12:45 |
| liw | pedroalvarez, nice -- could you send a patch for that? I won't have time in the next few days | 12:46 |
| pedroalvarez | I will :) | 12:46 |
| pedroalvarez | thanks for your help | 12:48 |
| liw | no worries, I made the bug | 12:49 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 12:51 | |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:52 | |
| SotK | does morph deal with needing to do `git submodule update` when building? | 13:03 |
| richard_maw | yes | 13:04 |
| richard_maw | it uses the submodules defined in the tree | 13:04 |
| SotK | can it cope with nested submodules too? | 13:05 |
| richard_maw | IIRC, yes | 13:05 |
| SotK | great :) | 13:05 |
| paulsherwood | hmmm.... | 13:46 |
| paulsherwood | http://fpaste.org/137380/ | 13:46 |
| paulsherwood | only that ref actually exists, afaict | 13:46 |
| Kinnison | Could you check your local git cache? | 13:47 |
| paulsherwood | fatal: bad object 8a62115bad2c0615fdf40f4e54a41454ae6e4698 | 13:49 |
| Kinnison | git fsck? | 13:49 |
| paulsherwood | after that | 13:49 |
| Kinnison | hmm | 13:49 |
| paulsherwood | (aasuming you mean /src/cache/gits/*common* | 13:49 |
| * Kinnison did | 13:49 | |
| paulsherwood | i can blow it away | 13:49 |
| Kinnison | that would likely fix it, but I wonder how it became corrupt | 13:50 |
| paulsherwood | unclear. i blew away my whole src disk this weekend (on purpose) and started frest | 13:50 |
| paulsherwood | unclear. i blew away my whole src disk this weekend (on purpose) and started fresh | 13:50 |
| paulsherwood | oops... :) | 13:51 |
| Kinnison | :-( | 13:52 |
| paulsherwood | maybe corrupted during download... this is my first attempt to build that repo | 13:53 |
| paulsherwood | buh.... same result after blowing it away | 13:53 |
| paulsherwood | corruption on gbo? | 13:53 |
| Kinnison | su - su - dangling commit 8a62115bad2c0615fdf40f4e54a41454ae6e4698 | 13:54 |
| Kinnison | yay for typos | 13:54 |
| paulsherwood | is there some other cache i'm not aware of? i assume build pulls from gbo => /src/cache/gits/foo | 13:54 |
| Kinnison | that commit is dangling | 13:54 |
| Kinnison | what that means is they're likely to have force-pushed something on the relevant branch | 13:55 |
| Kinnison | or dropped the ref | 13:55 |
| Kinnison | A similar looking commit ref has shown up at 1d83eb38e546e0165f1ad6821f04445b2b9b19d2 in the 2.1.6 history | 13:56 |
| paulsherwood | yes | 13:57 |
| Kinnison | I can anchor the commit on gbo for you, or you can change your ref | 13:57 |
| Kinnison | is that sha in use in master of definitions? | 13:57 |
| paulsherwood | that's the commit from master definitions | 13:57 |
| Kinnison | bugger | 13:57 |
| Kinnison | I'll anchor it on gbo, pleas ehold | 13:57 |
| paulsherwood | it's time i started blogging | 13:57 |
| Kinnison | http://git.baserock.org/cgi-bin/cgit.cgi/delta/genivi-common-api-runtime.git/log/?h=baserock/genivi-anchor-missing | 13:58 |
| paulsherwood | heh | 13:58 |
| Kinnison | There you go | 13:58 |
| Kinnison | I hope that works for you | 13:58 |
| paulsherwood | yup | 13:59 |
| paulsherwood | working | 13:59 |
| paulsherwood | we should document this little episode | 13:59 |
| rjek | A screen play, perhaps. | 13:59 |
| paulsherwood | a comedy of errors | 14:00 |
| Kinnison | Enjoy | 14:00 |
| * Kinnison continues to battle wayland | 14:00 | |
| paulsherwood | ERROR: Failed to check out ref 53d9341444ff9a31b9cc551b10fd0b341207937b in /src/tmp/staging/tmpLceL6e/genivi-common-api-dbus-runtime.build | 14:09 |
| paulsherwood | these chaps have been fiddling with their repo, i believe | 14:09 |
| Kinnison | dbus... thats a different repo | 14:11 |
| Kinnison | want me to investigate? | 14:11 |
| paulsherwood | yes please. different repo, same upstream people iiuc | 14:13 |
| * Kinnison looks | 14:14 | |
| Kinnison | There's an entire dangling tag in that repo | 14:14 |
| * richard_maw raises an eyebrow | 14:14 | |
| Kinnison | I'll reacquire it, pleas ehold | 14:15 |
| Kinnison | http://git.baserock.org/cgi-bin/cgit.cgi/delta/genivi-common-api-dbus-runtime.git/tag/?id=2.1.6-was-dangling | 14:15 |
| Kinnison | There you go | 14:15 |
| paulsherwood | thank you | 14:16 |
| paulsherwood | should i email mr gehring and ask him what happened? | 14:17 |
| pedroalvarez | so this is what happens when we use upstream tags.. | 14:17 |
| Kinnison | paulsherwood: it'd be good to know | 14:17 |
| paulsherwood | Kinnison: do we have any way of tracking how/when the tags got mangled? | 14:17 |
| Kinnison | Not usefully, no | 14:18 |
| paulsherwood | well, at least this would break mason... so we'd catch folks at it :) | 14:18 |
| Kinnison | aye | 14:18 |
| Kinnison | ish | 14:18 |
| paulsherwood | (if mason were building genivi) | 14:18 |
| Kinnison | Problem is, the objects are present for the resolver to use | 14:18 |
| Kinnison | so it's hard to know if it'd be caught | 14:19 |
| Kinnison | without a forced full local build | 14:19 |
| paulsherwood | actually, good point. my cloud build will probably sail through this | 14:19 |
| pedroalvarez | a script to check the ref's of the morphologies? | 14:20 |
| Kinnison | A script would be good, but again it'd *have* to clone | 14:20 |
| Kinnison | to be certain | 14:20 |
| pedroalvarez | so is not possible to do it withoud cloning.. | 14:20 |
| pedroalvarez | sigh.. | 14:20 |
| pedroalvarez | expensive | 14:21 |
| Kinnison | Well, regular 'git fsck' would also help spot things | 14:21 |
| Kinnison | some kind of watcher on the trove | 14:21 |
| paulsherwood | all along the smoking watchertower | 14:21 |
| Kinnison | But it'd need to have a human because sometimes rebases happen deliberately and safely | 14:21 |
| * paulsherwood will diff the old tags vs the new ones | 14:22 | |
| violeta | I have to fetch from a github repo, but my CA is out of date, how can I update it? | 14:33 |
| Kinnison | I think you can tell git to ignore that error | 14:33 |
| Kinnison | git config --global http.sslverify false | 14:33 |
| Kinnison | Once pedroalvarez has sorted the ca-certificates stuff you won' tnee dto do that | 14:34 |
| violeta | Kinnison, it works! thanks | 14:34 |
| Kinnison | :-) | 14:34 |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 14:47 | |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:51 | |
| pedroalvarez | I want to send a patch for that tomorrow | 14:51 |
| Kinnison | woot | 14:52 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:11 | |
| violeta | pedroalvarez, I was told to ask you how to change a chunk to build an out-of-tree kernel module | 15:24 |
| pedroalvarez | violeta: to change a chunk? or create one/ | 15:25 |
| pedroalvarez | ? | 15:25 |
| violeta | pedroalvarez, erhm... maybe create? | 15:26 |
| pedroalvarez | :) ok | 15:26 |
| pedroalvarez | I have here around an example of chunk morphology | 15:26 |
| pedroalvarez | violeta: here http://pastebin.com/wSFYPvSb | 15:28 |
| pedroalvarez | replace module1 with the name of the chunk that you are going to add, and it should work | 15:29 |
| pedroalvarez | ah | 15:29 |
| pedroalvarez | it has to build depend in the kernel | 15:29 |
| pedroalvarez | btw, are you doing this for x86? | 15:30 |
| violeta | nope | 15:30 |
| violeta | arm | 15:31 |
| pedroalvarez | then your linux chunk has to install also the kernel soure needed to build kernel modules, as we do with the linux chunk of x86_64 | 15:32 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 15:50 | |
| SotK | can I get a quick review of some lorries please? http://pastebin.com/zzZLz1DT | 15:51 |
| richard_maw | SotK: I'm fine with you pushing that, so long as you've checked that we've not already got those components | 15:54 |
| pedroalvarez | same opinion here :) | 15:54 |
| SotK | richard_maw, pedroalvarez: thanks, I'm pretty certain we don't, I have checked on multiple occasions :) | 15:56 |
| SotK | pushed | 15:57 |
| paulsherwood | SotK: are you sure ++ will get through lorry/lc ? no sign of it on lc-status | 16:09 |
| * Kinnison doesn't think it's a valid name | 16:11 | |
| Kinnison | better to call it dbus-cpp | 16:11 |
| pedroalvarez | lorry controllar says: | 16:14 |
| pedroalvarez | JSON problem in /home/lorry/confgit/open-source-lorries/sigc++.lorry | 16:14 |
| pedroalvarez | JSON problem in /home/lorry/confgit/open-source-lorries/dbus-c++.lorry | 16:14 |
| Kinnison | missing comma | 16:15 |
| Kinnison | after the url | 16:15 |
| pedroalvarez | indeed | 16:16 |
| pedroalvarez | SotK: ^ | 16:16 |
| pedroalvarez | regardin ++ vs pp, we already have gtk+ | 16:16 |
| violeta | pedroalvarez, I have everything set, but my mind is a bit too tired now | 16:26 |
| violeta | if i do now "morph build systems/devel-system-armv7lhf-jetson.morph", would it build the whole system? including u-boot ? | 16:27 |
| pedroalvarez | violeta: yes | 16:27 |
| violeta | and then, if I want to deploy/whatever it, can I just deploy it as normal or do I have to flash it? (because I need to flash u-boot) | 16:27 |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:27 | |
| pedroalvarez | here is when I say: I've never touched a jetson | 16:28 |
| violeta | xD | 16:28 |
| violeta | thanks :-) | 16:28 |
| pedroalvarez | I've used them, but never flashed, etc | 16:28 |
| violeta | I'm going to build it and continue tomorrow | 16:29 |
| pedroalvarez | cool | 16:29 |
| violeta | sorry paulsherwood, we'll see what happens tomorrow | 16:29 |
| violeta | pedroalvarez, you said that the build wouldn't take very long this time, would it? | 16:29 |
| pedroalvarez | around... 20 min max I guess | 16:30 |
| pedroalvarez | but don't be sad when you see it failing | 16:30 |
| pedroalvarez | :) | 16:30 |
| pedroalvarez | but please, go ahead with morph build, failing is learning | 16:31 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:34 | |
| *** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 16:38 | |
| paulsherwood | it depends whether violeta needs to update u-boot or not. | 16:52 |
| paulsherwood | (whether a re-flash is required) | 16:52 |
| pedroalvarez | right | 16:52 |
| pedroalvarez | then I'm 100% sure she needs to reflash ;) | 16:52 |
| paulsherwood | yup | 16:54 |
| *** tlsa [EwSz9lfVxe@gateway/shell/pepperfish/x-nsbtiexqeqjbdljr] has quit [Ping timeout: 244 seconds] | 18:31 | |
| *** tlsa [REVts2I8rW@gateway/shell/pepperfish/x-aftcrstyufiffyre] has joined #baserock | 18:32 | |
| jjardon | Hi, can someone take a look to my dbus-glib, llvm and libdrm proposed patch series? They already have a +1 by richard (jjardon/libdrm in definitions includes all the patches in case someone wants to test them) | 20:34 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 23:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!