IRC logs for #baserock for Monday, 2014-09-29

*** violeta [] has joined #baserock07:25
*** dutch_ [] has joined #baserock07:52
*** tiagogomes [~tiagogome@] has joined #baserock07:59
*** dutch_ [] has quit [Ping timeout: 244 seconds]08:10
*** dutch_ [] has joined #baserock08:12
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]08:24
*** tiagogomes [~tiagogome@] has joined #baserock08:24
*** jonathanmaw [] has joined #baserock08:28
*** fay_ [] has joined #baserock08:58
pedroalvarezI 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 patch09:23
Kinnison_ is now known as Kinnison09:23
* Kinnison docks himself09:23
*** liw-orc [] has joined #baserock09:38
straycatpaulsherwood, 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 yawns10:04
straycatedinburgh sure is pretty10:04
rjekstraycat: Doesn't it then convert them to an arbitrary-precision format?10:10
straycatI thought it converted them to a long10:10
rjekI think Python "long" is not the same as C "long".10:11
rjekI think "long" is python for "arbitrary-precision"10:11
rjekor bigint, at least.10:11
straycatAhh yeah10:12
*** liw_ [] has joined #baserock10:14
liw_ is now known as liw10:14
pedroalvarezrichard_maw, liw: in case that any of you are interested
KinnisonLooks like 32bit vs. 64bit issues10:22
liwis the BR Python built with Large File Support?10:27
KinnisonHow would we tell?10:28
richard_mawthe only extra config we pass to it is --enable-shared10:28
richard_mawthe 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
juergbichecking whether to enable large file support... yes10:34
juergbishould be the default on 32-bit linux10:34
juergbiand on 64-bit linux, it's not needed, afaik10:34
richard_mawhm, I'll see where the exception comes from10:36
liwpython -c 'import sysconfig; print sysconfig.get_config_var("HAVE_LARGEFILE_SUPPORT")'10:36
liwthat prints 010:36
liwon x86-64, so that's probably ok, as juergbi points out10:37
liwcopy_slice_from_file should not try to read that much at a time anyway10:39
liwsilly me10:39
pedroalvarezliw: if you have any suggestion to fix it I can try to do that change in my systsem and try again10:40
liwpedroalvarez, just a sec10:41
richard_mawlooking at the cpython source, it's not a large file issue, the `` function is limited to an int in size, rather than a size_510:42
liwpedroalvarez, can you try this patch:
liwrichard_maw, good catch10:43
pedroalvarezshould I try that then?10:43
liwpedroalvarez, yes please10:43
pedroalvarezliw: deploying, the test can take ~10 minutes10:45
pedroalvarezliw: :(11:25
richard_maws/max/min/ ?12:28
* richard_maw has often made that mistake12:28
richard_mawthere's something about the confusion of "you have a value which is the maximum" and the choice betwen max and min for me12:29
liwerh, yeah, min instead of max12:30
liwpedroalvarez, could you change the max() to min() in copy_slice_from_file and try again?12:31
* paulsherwood is building latest bash, again12:38
KinnisonI've not seen anything come out of Debian's security lists yet12:39
pedroalvarezliw: that worked, and transferred the around 6G of disk in a couple of seconds12:45
pedroalvarez6G of 0's I guess12:45
liwpedroalvarez, nice -- could you send a patch for that? I won't have time in the next few days12:46
pedroalvarezI will :)12:46
pedroalvarezthanks for your help12:48
liwno worries, I made the bug12:49
*** violeta [] has quit [Read error: Connection reset by peer]12:51
*** violeta [] has joined #baserock12:52
SotKdoes morph deal with needing to do `git submodule update` when building?13:03
richard_mawit uses the submodules defined in the tree13:04
SotKcan it cope with nested submodules too?13:05
richard_mawIIRC, yes13:05
SotKgreat :)13:05
paulsherwoodonly that ref actually exists, afaict13:46
KinnisonCould you check your local git cache?13:47
paulsherwoodfatal: bad object 8a62115bad2c0615fdf40f4e54a41454ae6e469813:49
Kinnisongit fsck?13:49
paulsherwoodafter that13:49
paulsherwood(aasuming you mean /src/cache/gits/*common*13:49
* Kinnison did13:49
paulsherwoodi can blow it away13:49
Kinnisonthat would likely fix it, but I wonder how it became corrupt13:50
paulsherwoodunclear. i blew away my whole src disk this weekend (on purpose) and started frest13:50
paulsherwoodunclear. i blew away my whole src disk this weekend (on purpose) and started fresh13:50
paulsherwoodoops... :)13:51
paulsherwoodmaybe corrupted during download... this is my first attempt to build that repo13:53
paulsherwoodbuh.... same result after blowing it away13:53
paulsherwoodcorruption on gbo?13:53
Kinnisonsu - su - dangling commit 8a62115bad2c0615fdf40f4e54a41454ae6e469813:54
Kinnisonyay for typos13:54
paulsherwoodis there some other cache i'm not aware of?  i assume build pulls from gbo => /src/cache/gits/foo13:54
Kinnisonthat commit is dangling13:54
Kinnisonwhat that means is they're likely to have force-pushed something on the relevant branch13:55
Kinnisonor dropped the ref13:55
KinnisonA similar looking commit ref has shown up at 1d83eb38e546e0165f1ad6821f04445b2b9b19d2  in the 2.1.6 history13:56
KinnisonI can anchor the commit on gbo for you, or you can change your ref13:57
Kinnisonis that sha in use in master of definitions?13:57
paulsherwoodthat's the commit from master definitions13:57
KinnisonI'll anchor it on gbo, pleas ehold13:57
paulsherwoodit's time i started blogging13:57
KinnisonThere you go13:58
KinnisonI hope that works for you13:58
paulsherwoodwe should document this little episode13:59
rjekA screen play, perhaps.13:59
paulsherwooda comedy of errors14:00
* Kinnison continues to battle wayland14:00
paulsherwoodERROR: Failed to check out ref 53d9341444ff9a31b9cc551b10fd0b341207937b in /src/tmp/staging/tmpLceL6e/genivi-common-api-dbus-runtime.build14:09
paulsherwoodthese chaps have been fiddling with their repo, i believe14:09
Kinnisondbus... thats a different repo14:11
Kinnisonwant me to investigate?14:11
paulsherwoodyes please. different repo, same upstream people iiuc14:13
* Kinnison looks14:14
KinnisonThere's an entire dangling tag in that repo14:14
* richard_maw raises an eyebrow14:14
KinnisonI'll reacquire it, pleas ehold14:15
KinnisonThere you go14:15
paulsherwoodthank you14:16
paulsherwoodshould i email mr gehring and ask him what happened?14:17
pedroalvarezso this is what happens when we use upstream tags..14:17
Kinnisonpaulsherwood: it'd be good to know14:17
paulsherwoodKinnison: do we have any way of tracking how/when the tags got mangled?14:17
KinnisonNot usefully, no14:18
paulsherwoodwell, at least this would break mason... so we'd catch folks at it :)14:18
paulsherwood(if mason were building genivi)14:18
KinnisonProblem is, the objects are present for the resolver to use14:18
Kinnisonso it's hard to know if it'd be caught14:19
Kinnisonwithout a forced full local build14:19
paulsherwoodactually, good point. my cloud build will probably sail through this14:19
pedroalvareza script to check the ref's of the morphologies?14:20
KinnisonA script would be good, but again it'd *have* to clone14:20
Kinnisonto be certain14:20
pedroalvarezso is not possible to do it withoud cloning.. 14:20
KinnisonWell, regular 'git fsck' would also help spot things14:21
Kinnisonsome kind of watcher on the trove14:21
paulsherwoodall along the smoking watchertower14:21
KinnisonBut it'd need to have a human because sometimes rebases happen deliberately and safely14:21
* paulsherwood will diff the old tags vs the new ones14:22
violetaI have to fetch from a github repo, but my CA is out of date, how can I update it?14:33
KinnisonI think you can tell git to ignore that error14:33
Kinnisongit config --global http.sslverify false14:33
KinnisonOnce pedroalvarez has sorted the ca-certificates stuff you won' tnee dto do that14:34
violetaKinnison, it works! thanks14:34
*** violeta [] has quit [Remote host closed the connection]14:47
*** violeta [] has joined #baserock14:51
pedroalvarezI want to send a patch for that tomorrow14:51
*** genii [~quassel@ubuntu/member/genii] has joined #baserock15:11
violetapedroalvarez, I was told to ask you how to change a chunk to build an out-of-tree kernel module15:24
pedroalvarezvioleta: to change a chunk? or create one/15:25
violetapedroalvarez, erhm... maybe create?15:26
pedroalvarez:) ok15:26
pedroalvarezI have here around an example of chunk morphology15:26
pedroalvarezvioleta: here
pedroalvarezreplace module1 with the name of the chunk that you are going to add, and it should work15:29
pedroalvarezit has to build depend in the kernel15:29
pedroalvarezbtw, are you doing this for x86?15:30
pedroalvarezthen your linux chunk has to install also the kernel soure needed to build kernel modules, as we do with the linux chunk of x86_6415:32
*** tiagogomes [~tiagogome@] has quit [Quit: Leaving]15:50
SotKcan I get a quick review of some lorries please?
richard_mawSotK: I'm fine with you pushing that, so long as you've checked that we've not already got those components15:54
pedroalvarezsame opinion here :)15:54
SotKrichard_maw, pedroalvarez: thanks, I'm pretty certain we don't, I have checked on multiple occasions :)15:56
paulsherwoodSotK: are you sure ++ will get through lorry/lc ? no sign of it on lc-status16:09
* Kinnison doesn't think it's a valid name16:11
Kinnisonbetter to call it dbus-cpp16:11
pedroalvarezlorry controllar says:16:14
pedroalvarezJSON problem in /home/lorry/confgit/open-source-lorries/sigc++.lorry16:14
pedroalvarezJSON problem in /home/lorry/confgit/open-source-lorries/dbus-c++.lorry16:14
Kinnisonmissing comma16:15
Kinnisonafter the url16:15
pedroalvarezSotK: ^16:16
pedroalvarezregardin ++ vs pp, we already have gtk+16:16
violetapedroalvarez, I have everything set, but my mind is a bit too tired now16:26
violetaif i do now "morph build systems/devel-system-armv7lhf-jetson.morph", would it build the whole system? including u-boot ?16:27
pedroalvarezvioleta: yes16:27
violetaand 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_ [] has quit [Quit: Quit]16:27
pedroalvarezhere is when I say: I've never touched a jetson16:28
violetathanks :-)16:28
pedroalvarezI've used them, but never flashed, etc16:28
violetaI'm going to build it and continue tomorrow16:29
violetasorry paulsherwood, we'll see what happens tomorrow16:29
violetapedroalvarez, you said that the build wouldn't take very long this time, would it?16:29
pedroalvarezaround... 20 min max I guess16:30
pedroalvarezbut don't be sad when you see it failing16:30
pedroalvarezbut please, go ahead with morph build, failing is learning16:31
*** jonathanmaw [] has quit [Quit: Leaving]16:34
*** violeta [] has quit [Ping timeout: 272 seconds]16:38
paulsherwoodit depends whether violeta needs to update u-boot or not.16:52
paulsherwood(whether a re-flash is required)16:52
pedroalvarezthen I'm 100% sure she needs to reflash ;)16:52
*** tlsa [EwSz9lfVxe@gateway/shell/pepperfish/x-nsbtiexqeqjbdljr] has quit [Ping timeout: 244 seconds]18:31
*** tlsa [REVts2I8rW@gateway/shell/pepperfish/x-aftcrstyufiffyre] has joined #baserock18:32
jjardonHi, 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 2.15.3 by Marius Gedminas - find it at!