IRC logs for #baserock for Thursday, 2015-10-29

*** edcragg has quit IRC00:07
*** cosm has quit IRC00:21
*** cosm has joined #baserock00:30
*** gtristan has quit IRC04:09
*** gtristan has joined #baserock04:44
gtristanjjardon, you !05:36
gtristanbroke the build !05:36
gtristanjjardon, please git add strata/xdg-app-common/xdg-app.morph05:36
gtristanjjardon, any reason why we hate wacom ?06:53
gtristanummm, any idea why we have strata in master that doesnt build ?07:34
gtristanpython change ?07:38
* gtristan git logs07:38
gtristanpython2 and python3 are parallel installable... right ?07:38
gtristanaha !07:45
gtristanof course, samba requires python2 - removed from foundation.morph -> breaks build07:45
gtristanwe need better validation07:45
gtristanhmmm, samba still craps out with this:
* gtristan was *so* close07:53
gtristaneesh, one of those simple -fPIC problems, in some obscure WAF build system07:54
*** edcragg has joined #baserock08:03
* gtristan tries cheap CFLAGS trick08:03
jjardongtristan: that was from the time I was trying to have a wayland-only gnome system; wacom support depends on having a complete xorg xserver08:10
jjardongtristan: is the wayland session currently working, btw?08:11
gtristanI will care about wayland when gnome runs08:15
gtristanone thing at a time :)08:15
jjardongtristan: does the wayland session appear as an option in gdm at least?08:16
* jjardon didnt have time to check this08:16
gtristangdm crashes when trying wayland and reverts to X08:16
gtristanor gnome-session does08:16
gtristanit appears that g_error() was chosen as the method to indicate that mutter could not start with wayland08:17
* gtristan strangles samba08:17
gtristan[3099/3492] Linking default/source4/heimdal_build/ <-- hilarious08:18
gtristanoddly, with CFLAGS=-fPIC make... samba seems to put -fPIC on the command line everywhere, and then fails with the same complaint08:22
gtristansaying "recompile with -fPIC"08:22
* gtristan thinks; better eat lunch and meditate on this; it's literally the *last* in a long line of dependencies leading up to gnome-control-center08:22
*** persia has quit IRC08:24
*** gtristan has quit IRC08:25
*** persia has joined #baserock08:27
*** bashrc_ has joined #baserock09:03
*** gtristan has joined #baserock09:05
paulsher1oodgtristan: [3099/3492]... is that morph?09:08
pedroalvarezouch, I was wondering why my build of gnome system was failing...09:10
pedroalvarezit's failing in syslinux!09:10
pedroalvarezamazingly, it managed to build the x86_64 linux kernel09:11
* pedroalvarez changes the bsp09:11
paulsher1oodpedroalvarez: i assume you're not on x8609:12
pedroalvarezI'm not09:12
pedroalvarezI wanted to check that it builds in arm09:12
pedroalvarezand maybe if I have some time, if it boots09:12
*** ssam2 has joined #baserock09:19
*** ChanServ sets mode: +v ssam209:19
gtristanpaulsher1ood, no that's the WAF build scripts of samba09:26
*** jonathanmaw has joined #baserock09:27
*** toscalix has joined #baserock09:29
*** edcragg has quit IRC09:36
*** paulwaters_ has joined #baserock09:37
*** mariaderidder has joined #baserock09:37
* pedroalvarez sends
pedroalvarezmy armv7lhf Mason is failing because of that09:45
*** franred has joined #baserock09:45
*** edcragg has joined #baserock09:54
jjardonpedroalvarez: do we have a arm mason?10:06
pedroalvarezjjardon: I have one on my desk, and it uploads things to cache.baserock.org10:06
jjardonpedroalvarez: any way to see if the build is broken or not?10:07
*** paulwaters_ has quit IRC10:07
jjardonlike the x86 one?10:07
pedroalvarezjjardon: it is not publicly accesible10:08
gtristanhrm... samba is going to be a problem10:08
jjardonpedroalvarez: :(10:08
pedroalvarezgtristan: can you check that my fix makes sense?
jjardonpaulsher1ood: do you have a stratum for ybd?10:08
paulsher1oodjjardon: not so far10:09
* gtristan looks10:09
gtristanpedroalvarez, I'll fix... sorry for that10:10
paulsher1oodwin 4510:10
pedroalvarezgtristan: it's already fixed :)10:10
pedroalvarez(by me)10:10
pedroalvarezjjardon: I know, not ideal, but at least I'm looking at it some times to fix errors, and it populates the cache10:10
* gtristan aborts the rebase/review10:11
pedroalvarezgtristan: I just wanted a double check from you before merging10:12
gtristanyeah that's an obvious mistake :-S10:12
gtristan /usr/lib/libcom_err.a ... is this produced by samba ?10:13
gtristanor, is this a gcc'ism ?10:13
gtristannot from gcc... ok I wonder what to do about this10:14
jjardonpedroalvarez: nice, but can we make it public? Id like to help in case the build brake10:15
jjardonpaulsher1ood: is there a cache generated by ybd somewhere?10:18
jjardongtristan: seems its part of e2fsprogs10:21
gtristanreally ?10:22
gtristanI think its a gccism, but not installed in the artifact10:22
gtristanjjardon, it looks like ld is just saying that the error message itself is being printed by libcom_err.a10:23
gtristantake a closer look:
jjardongtristan: no idea really, a quick search in google brought me here:
gtristangoogle brings this interesting thread up:'-can-not-be-used-when-making-a-shared-error-783491/10:24
gtristanwhich says that basically, -fPIC is not enough only when creating the shared object, but should also be added when creating the archive :-/10:25
gtristanjjardon, I see, perhaps thats it then10:26
pedroalvarezjjardon: we can either put a jetson in somewhere with a public IP, or try to put Mason on a moonshot node10:26
gtristanjjardon, I do have a libcom_err.a, maybe I need to fix e2fsprogs to create the archive with -fPIC, and samba will compile10:26
gtristanjjardon, indeed, thanks for pointing that out10:27
* gtristan gives it a shot :-/10:27
paulsher1oodjjardon: - but there is nothing currently building master definitions with ybd in public10:29
*** dabukalam has quit IRC10:39
*** dabukalam has joined #baserock10:40
*** nowster has joined #baserock10:41
jjardonpedroalvarez: that wold be nice, I would  not want to tell people they can build gnome systems for arm to then discover is actually broken10:42
pedroalvarezjjardon: I think I'll be able to tell you today if that works10:48
* gtristan thinks he's got it... e2fsprogs fails to run ranlib... I think...10:51
* gtristan checks objdump10:51
jjardonpedroalvarez: great; thanks! :)10:52
jjardonpaulsher1ood: right, how can we make that happen? without the cache is not really useful use ybd10:54
gtristanah no, but the objects which go into libcom_err... are *not* compiled with -fPIC !11:01
gtristanbam !11:01
gtristanthere we are11:02
lostduckcan we not simply make the caches compatible?11:03
*** franred has quit IRC11:04
pedroalvarezlostduck: ybd doesn't want to be morph compatible :P11:04
* Kinnison doesn't care about either of ybd or morph.11:04
* Kinnison wants something better than both11:04
KinnisonSadly I simply don't have the time/bandwidth to write it11:04
* pedroalvarez simply wants to move forward11:05
* rjek pushes pedroalvarez gently forward11:06
*** locallycompact has joined #baserock11:06
* pedroalvarez falls down cliff11:06
* gtristan collects a tasty organic chicken spread for his toast11:12
*** paulwaters_ has joined #baserock11:14
gtristanok, I have a patch that will make samba build11:15
gtristanthoughts on this patch: ?11:17
* gtristan is testing the theory, but is 99% certain that it will solve the samba build error11:18
gtristanit's possible that samba previously built on 32bit systems without this11:18
*** paulwaters_ has quit IRC11:19
pedroalvarezI wonder if there is anything else blocking this patch-set:
jjardonpedroalvarez: looks good11:36
pedroalvarezyay, closer than ever to get gdp merged  in master :)11:37
jjardonpedroalvarez: Id recommend you to replace genivi baseline bt gdb in the ci, so your work doesnt get bitrotten11:37
pedroalvarezit has qtwebkit on it.. :/11:38
pedroalvarezbut you are right11:38
gtristansamba builds11:43
*** franred has joined #baserock11:53
gtristanOk so put samba fixes up, and rebased the gnome-control-center branch on top of that11:53
gtristanbut still have to verify the build, it's the last dependency but I'd rather see g-c-c build and run before pushing those11:53
gtristananyway, that means a webkit rebuild, so it will take some hours...11:55
gtristanthat should be the final touch on this milestone really, currently it boots up but when trying to access volume controls and stuff from gnome-shell it just doesnt do anything11:56
gtristanit will be a pretty-fully-functional gnome-shell11:56
*** toscalix has quit IRC12:26
*** toscalix__ has joined #baserock12:34
*** gary_perkins has quit IRC12:55
*** gary_perkins_ has joined #baserock12:55
*** gtristan has quit IRC13:42
*** gtristan has joined #baserock13:55
pedroalvarez"mutter" failed in arm:
tiagogomes__which arm is that?14:35
tiagogomes__Fedora has a armv8 spin-off14:36
pedroalvareztiagogomes__: hard question..14:37
pedroalvarezdifficult times14:37
pedroalvarezis a moonshot14:38
pedroalvarezbut acting as armv714:38
pedroalvarezand inside of an armv7lhf chroot14:38
tiagogomes__pedroalvarez if you disable werror what happens?14:40
pedroalvarezI'm going to try that14:40
pedroalvarezit builds in x86 though14:40
tiagogomes__odd, the same compiler detects different amount of warnings on different archs14:41
KinnisonThat's not odd at all14:41
Kinnisoncompiler warnings are often related to the optimisers14:41
Kinnisonand different architectures have different optimisers, alignments, etc.14:42
Kinnisonwhich result in different warnings14:42
tiagogomes__fair enough14:42
KinnisonBut it can be confusing, yes14:45
pedroalvarezgood to know :)14:50
pedroalvarezignoring warnings is enough15:00
* pedroalvarez sees in the logs: "armv8l-unknown-linux-gnueabihf"15:00
*** mariaderidder has quit IRC15:02
ssam2weird... so the compiler has armv8l in its name, on an armv7l machine ?15:03
*** mariaderidder has joined #baserock15:03
pedroalvarezis a armv7l chroot running inside an armv7l machine15:03
radiofreeshouldn't say "armv8l-unknown-linux-gnueabihf" then15:11
KinnisonIf you compiled the 32bit code on an armv8 machine I wouldn't be surprised if it did15:11
paulsher1oodit's a moonshot cartridge iiuc15:12
* Kinnison noted back when you were playing with linux32 on armv8l64 systems that you'd have armv8l32 not armv7lhf if you weren't careful15:12
radiofreeif you followed my guide (Building armv7 on aarch64) then it shouldn't say armv815:12
radiofreepaulsher1ood: where is the location of your ybd build logs again?15:12
radiofreei mean in github, got it15:13
paulsher1oodah, sorry15:13
*** edcragg has quit IRC15:13
radiofreehmm.. not that useful for this15:14
paulsher1oodwhat are you seeking?15:14
radiofreeto see if my toolchange was armv7.... inside the chroot15:14
radiofreeare you using morph pedroalvarez?15:14
paulsher1oodyes, from his log15:15
*** edcragg has joined #baserock15:15
radiofreei was using ybd and manually specifying armv7lhf as the arch ` systems/devel-system-jetson-armv7lhf.morph armv7lhf`15:15
pedroalvarezradiofree: yes15:17
Kinnisonif you used morph you likely build armv8l32 not armv7lhf15:17
pedroalvarezI expect everything to be fine tbh15:18
Kinnisonunless you used setarch armv7l -B15:18
KinnisonI don't, armv8l32 has some instruction behaviours armv7lhf lacks15:18
Kinnisonif you're lucky it'll work15:18
Kinnisonbut I wouldn't stake any kind of bet on it15:18
* Kinnison did say back when you started15:18
* Kinnison pointed you at setarch15:18
Kinnisonand everything15:18
paulsher1oodpedroalvarez: use ybd... you know it works :)15:19
Kinnisonybd works by accident rather than by design, and who knows what kinds of horrors other build systems did when ybd wasn't running in the right personality15:19
Kinnison(for the 32bit thing)15:19
pedroalvarezboth of them have worked for me here15:19
Kinnisonanyway, I have other things to do, I recommend using setarch even if you use ybd15:19
Kinnisonotherwise chunk build systems which use uname might cock up15:19
pedroalvarezthing is that Morph doesn't complain about the arch15:20
pedroalvarezthat was my concerning15:20
nowsterlinux32 and linux64 are handy aliases IIRC15:21
pedroalvarezsetarch: armv7lhf: Unrecognized architecture15:21
Kinnisonpedroalvarez: drop the hf15:21
Kinnisonpedroalvarez: you may also need to drop the l15:21
pedroalvarezsorry, tried both, pasted the confusing one15:21
* Kinnison isn't sure15:22
pedroalvareztried that too15:22
Kinnisonhmm, persia was working with setarch15:22
Kinnisonyou should poke him15:22
Kinnisonit might need a newer $blahutils15:22
Kinnisonfor whichever blah15:22
*** radiofree has quit IRC15:33
*** radiofree has joined #baserock15:34
persiaI do not have the patch handy, but essentially, one needed to tell util-linux that ARMv8 could emulate ARMv715:53
persiaThe patch I wrote did not meet the pretestrequirenents to get upstream, but was mostly just adding entries to a mapping table.15:54
* radiofree +1's 'use ybd'15:54
persiaIf someone tried from current util-linux, I could sight-review a patch, or if someone wants to link me to what might lil15:55
persiaLook like the right file, I could suggest the set of changes.15:55
persiaUsing fakery to pretend arch without setting personality will break for certain instructions, for sources with certain build systems, and you get to keep the pieces.15:57
lostduckyou know i'd appreciate it if, as a community, we could get over the fact that we have 2 tools and that some people prefer one over the other, it's getting old.16:09
lostducknix has like 3 python import tools16:09
lostduckand people there aren't constantly doing this whole "use whatever tool i happen to be using right now!!!!" thing16:10
radiofreewell in this case the +1 is valid, since it actually works for this usecase where morph doesn't16:11
pedroalvarezerm.. Morph works fine16:14
*** franred has quit IRC16:14
pedroalvarezboth work fine I'd say16:14
pedroalvarezhm.. gocd has plugins for gerrit16:28
persiapedroalvarez: Hrm?  I thought ybd had an architecture override feature that morph didn't have (that kinda worked, except for the caveats I mentioned above).16:37
paulsher1oodiiuc no-one had got around to actually testing building armv7 stuff on armv8 using morph. maybe pedroalvarez has done that now16:40
paulsher1oodi said 'use ybd.. you know it works' because pedroalvarez and i both actually used that config in anger last week16:41
pedroalvarezI tested armv7 on armv8 but in a linux32 armv7 chroot16:42
pedroalvarezwith ybd and morph16:43
pedroalvarezand both have worked so far16:43
paulsher1oodcool :)16:43
*** CTtpollard has quit IRC16:44
pedroalvarezbut I feel like it might fail16:44
pedroalvarez"<Kinnison> otherwise chunk build systems which use uname might cock up"16:45
pedroalvareznot fail, but build wrong things16:45
pedroalvarezI don't know, this is a bit complex16:45
radiofreepedroalvarez: did the built image boot tho?17:17
radiofreeOn a jetson for example17:17
pedroalvarezwell, I have to say that maybe not everything was built in this system, maybe some parts were reused from cache.baserock.org17:21
paulsher1oodnot for the ybd images17:22
pedroalvareznope, ybd images were built 100% here17:23
pedroalvarezbut persia said that "ybd had an architecture override feature"17:23
pedroalvarezI'm not sure about what that is17:23
radiofreeYes that's what I used17:24
radiofreeYou just tell it its building armv7lhf and it works very nicely17:24
pedroalvarezradiofree: what exactly is that17:24
radiofreeI sent an email to the list about it17:27
radiofreeThat was on a mustang but it should work exactly the same on moonshot17:27
pedroalvarezI'm really confused about why `morph print-architecture` says armv8l, and doesn't complain when building a system for armv7lhf17:27
pedroalvarezradiofree: I believe I'm using those instructions17:28
ssam2pedroalvarez: morph knows that they are compatible, see
*** jonathanmaw has quit IRC17:29
radiofreeIt might boot, and work, I just think it would be a bit odd to have my tool chain named armv8 on a jetson17:29
radiofreeybd works because it'll use whatever you pass to it, rather than getting it from uname17:30
pedroalvarezdoes morph uses whatever uname says? or whatever you put in the system morphology?17:30
pedroalvarezif the latter, then it's the sam17:30
radiofreeWhen building gcc etc u think it goes back to naming these things based on morph_arch17:31
radiofreeor whatever that was called17:31
*** mariaderidder has quit IRC17:31
pedroalvarezit will be the same for ybd and morph in that case17:34
pedroalvarezsame behaviour17:34
radiofreeI'm pretty sure it wasn't if your tool chain was called armv817:35
pedroalvarez"MORPH_ARCH": "armv7lhf",17:35
pedroalvarez"TARGET": "armv7lhf-baserock-linux-gnueabi",17:35
radiofreeLooks good then! :)17:35
pedroalvarezradiofree: I think this is just a case of a chunk trying to figure out the name of the toolchain, using uname17:35
pedroalvareznothing with the name of "armv8" in this system17:36
radiofreeGood stuff then17:36
pedroalvarezand ssam2, thanks for pointing that out, I was failing to find the magic17:38
pedroalvarezI agree that safest way to do this is to make "uname" return armv7l17:39
gtristanjjardon, too bad we didnt keep WebKitGtk outside of gnome17:47
gtristannow I lose an extra hour every time I add something like samba or cups as a requirement of the gnome stratum17:48
gtristanjust for a simple test17:48
gtristanat least compiling WebKitGtk helps to keep the room temperature a bit higher, now that it's getting cold outside :)17:51
gtristangotta keep those i7's working :)17:51
ssam2hmm, yeah, i remember someone putting qtwebkit in its own stratum for similar reasons17:53
radiofreeI thought of doing a hack in the morph file to detect the free memory and if suffienct use a reasonable max jobs amount17:54
gtristanpretty lame actually, I spent a good amount of time properly refactoring out bits and pieces from gnome so that they would each have their own strata17:55
radiofreeso it wouldn't take a million years to build17:55
* gtristan checks if at least the branch is still around17:55
radiofreeBut maybe some support for that might be worth while... required - mem or something and if not met use max - jobs 117:56
jjardongtristan: you can rebuild samba in the GNOME stratum if you only want to test17:56
*** bashrc_ has quit IRC17:56
*** nowster has quit IRC17:57
gtristanyup, I have still a branch which isolates libsecret, libnotify, json-glib, geocode-glib, libgweather, polkit & geoclue into separate strata17:57
* gtristan keeps it handy17:57
gtristanjjardon, well, it's a test that is 'make-or-break', it has to be done really, I guess "just a test" is an understatement17:57
gtristanI could "try" it, but I'd still hit the rebuild17:58
*** tiagogomes__ has quit IRC17:59
*** ssam2 has quit IRC18:01
jjardongtristan: probably we should conclude that the current baserock model doesnt work and we should to come back to chunk=strata (so packages)18:03
gtristanI think that's the short-term solution18:03
gtristanwhile I was spending lots of time building today, I spent more time on that proposal18:04
gtristanbut I think the right migration path, before performing an ultimate refactor, is at least a policy of one-module-one-strata for anything added to definitions18:04
jjardonThat means a user has to know all the interdependencies between strata, to build the system/ morph18:06
gtristanthat is how it should be18:06
gtristanwhen adding a package, we *know* why a given package depends on something hidden behind a "foundation.morph" wall18:07
gtristanthe direct dependencies of a package are limited anyway18:07
gtristanhowever that information is currently lost after the package/chunk gets added (at least the parts of it which bleed into dependant strata)18:08
gtristanwe shouldnt lose that information18:08
jjardonWhat about keep stratum but chunks still have to keep their dependencies, even from other strata?18:08
gtristanin my proposal, strata does not *contain* chunks, but only refers to them, chunks are kept in an entirely separate directory18:09
gtristanstrata are allowed to overlap in what they include, and they are mostly a convenience for building systems18:09
gtristani.e., you dont need 'vi' as a build dependency of anything; but it sucks when you complete and deploy a build, and forget to include it (and that's actually a quite typical mistake)18:10
gtristanjjardon, give me another day to work on it; I'm getting close18:11
jjardongtristan: looking forward for it; sorry if I'm slowing your work sometimes18:12
pedroalvarezgtristan: have you thought about switching from a 2 levels model (chunk - stratum) to a multi level model?18:12
*** toscalix__ has quit IRC18:12
gtristanjjardon, its not your fault18:12
gtristanpedroalvarez, what would it do ?18:12
pedroalvarezadd flexibility18:13
gtristanI think I have all the flexibility we need with flavors, without blowing up morph files exponentially18:13
gtristanpedroalvarez, note we actually already have chunk, stratum and system18:13
gtristan*and* cluster, but that's a different breed18:13
pedroalvarezwell, yes, 3 levels18:14
pedroalvarezbut I don't know, it might be useful to say that you want in this system these strata, and then this chunk18:14
gtristannot sure what flexibility is added by adding levels18:14
pedroalvarezor just to say that this stratum is the same as this other stratum but with an extra chunk18:14
gtristanpedroalvarez, oh yeah indeed, I think a system can refer to a chunk or a stratum directly, and it shouldnt matter18:14
gtristanin any case the morph itself has a "kind" attribute18:15
gtristanpedroalvarez, that doesnt matter because they can overlap, including 2 similar strata like that would result in the accumulation of chunks being included in the system18:15
gtristanpedroalvarez, ah interesting18:16
gtristanpedroalvarez, so basically what I am saying about systems, you point out is also valid for stratum18:16
gtristanone can refer to a chunk or a stratum, it makes no difference, good point18:16
gtristanpedroalvarez, it can actually also apply to a chunk, but I would rather disallow that, or have a strict policy to restrict that to 'build-essential'18:17
pedroalvarezI'm looking forward to see that proposal :)18:17
* pedroalvarez has to go to play some basketball18:18
gtristanhave fun :)18:18
gtristannow that I think of it - it makes more sense to just abolish the 'system' "kind", I dont see why a stratum could not be a drop-in replacement18:21
gtristanand it's possibly interesting to have separate stratum which include their own configuration extensions18:22
gtristanI think the 'arch' and it's (probable) relation to the bsp is the only thing to iron out there18:23
*** edcragg has quit IRC18:49
*** locallycompact has quit IRC18:49
jjardonpedroalvarez: so, did any of them work in the end or not? :) 10:26 <•pedroalvarez> jjardon: we can either put a jetson in somewhere with a public IP, or try to put Mason on a moonshot node19:01
pedroalvarezWe used to have Jetsons in DC19:15
pedroalvarezRegarding the moonshot I have tried19:15
pedroalvarezThere is also scaleway19:18
pedroalvarezBut that would be really slow19:18
paulsher1oodjjardon: i believe* is now serving armv7lhf components from ci.morph19:22
paulsher1oodcurrently that doesn't include any gnome-system, though19:22
jjardonpaulsher1ood: :) and :(19:32
jjardonpaulsher1ood: are you not building master of definitions?19:32
jjardongnome system is in ci.morph19:32
jjardonpedroalvarez: so its that yes or not? :)19:52
paulsher1oodjjardon: that's building for armv7lhf. if someone wants to add a gnome system for that arch, i can build it19:54
paulsher1oodi guess i should also setup a minimal ci for this, and do x8619:55
jjardonpaulsher1ood: oh rigth, expect a patch soon :)20:11
*** edcragg has joined #baserock20:23
*** edcragg has quit IRC20:46
persiapaulsher1ood: I tested it last November.  The state of things may have changed now, but then it required personality to be reliable.21:49
persia(oops: PgUp problem: "it" in this context being building armv7 on armv8)21:51
persiaTo be fair, I tested it on some experimental hardware over ssh to a vendor lab, which may behave differently than the current stuff.21:51
paulsher1oodjjardon: can't wait :)22:04

Generated by 2.14.0 by Marius Gedminas - find it at!