| *** edcragg has quit IRC | 00:17 | |
| *** gtristan has quit IRC | 01:44 | |
| *** gtristan has joined #baserock | 02:08 | |
| *** toscalix has joined #baserock | 07:53 | |
| *** ctbruce has joined #baserock | 08:30 | |
| *** tiagogomes_ has joined #baserock | 08:46 | |
| *** gtristan has quit IRC | 08:54 | |
| *** gtristan has joined #baserock | 09:39 | |
| *** ctgriffiths_ has joined #baserock | 09:44 | |
| *** SotK_ has joined #baserock | 09:45 | |
| gtristan | Regarding https://gerrit.baserock.org/#/c/1687/ and https://gerrit.baserock.org/#/c/1688/... they are used only by GNOME and ceph-service... is ceph-service maintained ? | 09:47 |
|---|---|---|
| gtristan | is there anything anyone would like me to test regarding that ? | 09:47 |
| radiofree | nice work gtristan | 09:47 |
| gtristan | thanks | 09:48 |
| gtristan | it's pretty complete now | 09:48 |
| gtristan | send/receive email, browse web, watch videos, chat | 09:48 |
| gtristan | good reference platform, few interesting things we can use that for, put baserock to the test :) | 09:49 |
| *** SotK has quit IRC | 09:49 | |
| *** ctgriffiths has quit IRC | 09:49 | |
| *** gtristan has quit IRC | 09:58 | |
| *** brlogger` has joined #baserock | 09:59 | |
| *** gtristan_ has joined #baserock | 10:01 | |
| gtristan_ | hmmm | 10:02 |
| gtristan_ | ceph-service, is most definitely unmaintained | 10:02 |
| gtristan_ | it doesnt build, and that's not because of my nss patches | 10:02 |
| gtristan_ | it tries to build boost, which fails. | 10:03 |
| *** ssam2 has joined #baserock | 10:07 | |
| *** ChanServ sets mode: +v ssam2 | 10:07 | |
| *** rjek_ has joined #baserock | 10:08 | |
| *** trnv2 has joined #baserock | 10:11 | |
| *** gtristan has quit IRC | 10:12 | |
| *** trn has quit IRC | 10:12 | |
| *** bfletcher has quit IRC | 10:12 | |
| *** perryl has quit IRC | 10:12 | |
| *** benbrown_ has quit IRC | 10:12 | |
| *** brlogger has quit IRC | 10:12 | |
| *** rjek has quit IRC | 10:12 | |
| *** benbrown_ has joined #baserock | 10:15 | |
| *** trnv2 is now known as trn | 10:20 | |
| *** gtristan_ is now known as gtristan | 10:30 | |
| *** perryl has joined #baserock | 10:31 | |
| *** bfletcher has joined #baserock | 10:37 | |
| *** rjek_ is now known as rjek | 10:39 | |
| gtristan | Any reason why we are not building/including libgmp ? | 11:01 |
| persia | In which target? | 11:02 |
| tiagogomes_ | AFAIK, we are only including it to build gcc | 11:03 |
| tiagogomes_ | I mean, it is included in the gcc-tarball repo, but I don't think it is installed into the system | 11:06 |
| ssam2 | oh yeah... which is nice for making the bootstrap simpler | 11:06 |
| ssam2 | but a pain if you want to use libgmp :-) | 11:06 |
| persia | Repo or chunk? | 11:06 |
| ssam2 | repo | 11:06 |
| persia | Ah, so we never install it anywhere? | 11:07 |
| tiagogomes_ | This is how I updated GCC to 4.9.2: http://git.baserock.org/cgi-bin/cgit.cgi/delta/gcc-tarball.git/commit/?h=baserock/tiagogomes/update-toolchain&id=b3c9b176c1f10ebeff5700eb3760e9511f23fa06 | 11:08 |
| gtristan | no... we dont | 11:08 |
| gtristan | sorry... no, we dont install it :) | 11:08 |
| gtristan | ok so the answer is just basically, we have it setup so that gcc includes it's own and we just never install it | 11:10 |
| gtristan | but, there is no intentional reason behind this | 11:10 |
| gtristan | ok | 11:11 |
| ssam2 | for stage1-gcc and stage2-gcc it makes a lot of sense | 11:11 |
| ssam2 | for the final gcc, might make more sense to build and install libgmp separately so it can be used | 11:11 |
| gtristan | ssam2, so while I have you here, do we have prior work towards cross compiling with baserock ? | 11:12 |
| gtristan | I heard it through the grape vine, that you might know :) | 11:12 |
| ssam2 | right | 11:13 |
| persia | Indeed: we should build our own post-bootstrap if we want it in some systems. | 11:13 |
| tiagogomes_ | stage1-gcc should use libgmp from the host no? | 11:13 |
| ssam2 | give me a second :-) | 11:13 |
| gtristan | tiagogomes_, yes it is a fun subject :) | 11:13 |
| tiagogomes_ | gtristan, working on build-essential is not fun when some libraries don't end up in the location that you need them to be | 11:15 |
| ssam2 | gtristan: what we have is a cross-toolchain stratum for armv7 | 11:15 |
| ssam2 | gtristan: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/armv7lhf-cross-toolchain.morph and http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/armv7lhf-cross-toolchain | 11:15 |
| ssam2 | that exists so that you can build an 'SDK' system with a cross-toolchain for your device | 11:16 |
| tiagogomes_ | Bi | 11:17 |
| tiagogomes_ | wrong window syndrome | 11:17 |
| ssam2 | maybe it would work to add some strata that depend on the cross-toolchain, and try to use it. Morph/YBD wouldn't handle passing --target correctly, or any such thing, but it might just work | 11:17 |
| gtristan | ssam2, so currently we can cross compile to armv7lhf, using that ? | 11:18 |
| ssam2 | theoretically, yeah | 11:18 |
| persia | Rather, we can generate an SDK that can cross compile. | 11:18 |
| gtristan | oh, but we havent even tried that far, I see | 11:18 |
| gtristan | ssam2, basically *that* works to build a system which boots and has a cross compiler ? | 11:18 |
| persia | You need to worry about things like tpath and include directories separately, which means different chunk definitions. | 11:19 |
| gtristan | ssam2, but then, you cant just use it as a build-essential replacement right ? | 11:19 |
| persia | Err, rpath | 11:19 |
| gtristan | right, it would be nice to specify an arch, build the cross compiler for that arch, and have the chunks built with the appropriate CFLAGS holding the -m${arch} args etc, all automatically | 11:20 |
| ssam2 | gtristan: the SDK is a 'system' only because Baserock forces everything to be a system | 11:20 |
| ssam2 | gtristan: it works like Yocto SDK, it has an 'unpacker' script that extracts it somewhere and patches the rpath of everything within using 'patchelf' | 11:21 |
| gtristan | ssam2, so basically, if I were to extend that system and add a bunch of stuff to it, without modifying the chunk morphs... it would have a chance of working ? | 11:22 |
| * gtristan starts by building that system | 11:22 | |
| ssam2 | yes | 11:23 |
| ssam2 | no | 11:23 |
| ssam2 | the chunk morphs would need to be modified so they use 'armv7lhf-baserock-gnueabi-gcc' instead of 'gcc' | 11:23 |
| * persia continues to worry about configuration paths, dlopen paths, and other bits | 11:23 | |
| gtristan | oh wait no, I got confused sorry | 11:24 |
| gtristan | of course it wouldnt do anything useful | 11:24 |
| persia | Why not? | 11:24 |
| gtristan | ssam2, it would end up building a system for your own host, which would include a cross compiler | 11:24 |
| gtristan | the system would not be "cross compiled" | 11:24 |
| ssam2 | yeah | 11:24 |
| gtristan | sure, it would be useful in some measure of useful | 11:24 |
| persia | Which cross compiler one could build depend upon | 11:24 |
| gtristan | its a start | 11:25 |
| ssam2 | for autotools chunks, passing --host=armv7lhf-baserock-gnueabi to configure might be enough | 11:25 |
| ssam2 | the problem with trying to teach build tools to do this... is there's no 'lingua franca' for architectures, of course | 11:26 |
| gtristan | yeah | 11:26 |
| gtristan | you'd have to have some kind of database/table for that | 11:27 |
| persia | YAML in definitions, by preference, to ease adding new architectures. | 11:27 |
| *** edcragg has joined #baserock | 11:29 | |
| * gtristan builds armv7lhf-cross-toolchain and buildroot at the same time | 11:30 | |
| *** tiagogomes_ has left #baserock | 11:31 | |
| *** tiagogomes_ has joined #baserock | 11:31 | |
| jjardon | gtristan: hi, building master, gdm keeps crashing when building along with gnome-initial-support; do this happen to you before? | 11:59 |
| gtristan | jjardon, no, all that comes to mind is that fontconfig issue | 12:04 |
| gtristan | jjardon, how does it crash ? are you building the GNOME stratum vanilla or have some change ? | 12:05 |
| gtristan | s/gnome-initial-support/gnome-initial-setup ... right ? | 12:07 |
| jjardon | yeah, GNOME stratum vanilla; let me take an screenshot | 12:11 |
| gtristan | I believe you :) | 12:12 |
| gtristan | hehe | 12:12 |
| gtristan | jjardon, so what could possibly be different ? | 12:12 |
| gtristan | maybe you are building with morph !? I'd be surprised if that causes it to not work | 12:13 |
| jjardon | oh, yeah, that can be a different | 12:13 |
| jjardon | difference* | 12:13 |
| jjardon | This is the error Im getting https://usercontent.irccloud-cdn.com/file/FxAYequ9/Screenshot%20from%202015-12-21%2012-13-10.png | 12:14 |
| jjardon | If I do not build gnome-initial-setup, gdm runs without problems | 12:14 |
| ssam2 | my first guess would be system-integration commands behaving differently... | 12:15 |
| gtristan | yes | 12:15 |
| ssam2 | https://storyboard.baserock.org/#!/story/54 is relevant | 12:16 |
| gtristan | could be that the useradd commands arent working properly ? | 12:16 |
| ssam2 | that's my guess | 12:17 |
| ssam2 | although if so, gdm is also at fault, because it shouldn't just be segfaulting | 12:17 |
| gtristan | note that I ended up running into problems with linux-user-chroot and have since been using ybd with chroot only | 12:18 |
| gtristan | but nothing like this | 12:18 |
| persia | That is not a safe way to build, but that is probably unrelated. | 12:18 |
| gtristan | so what is error 6 | 12:19 |
| persia | From what? | 12:20 |
| gtristan | persia, the screenshot | 12:21 |
| gtristan | audit message | 12:21 |
| gtristan | I know what's going on jjardon | 12:21 |
| gtristan | I am "pretty" sure | 12:21 |
| gtristan | error 6 is SIGABRT | 12:21 |
| gtristan | jjardon, and without gnome-initial-setup, you dont have any user | 12:22 |
| gtristan | so, you are *never* trying to run a gnome-session | 12:22 |
| gtristan | you just have gdm without gnome-initial-setup and a completely useless system ;-) | 12:22 |
| persia | According to `errno -l`, on my system error 6 is ENXIO : maybe check on the target? | 12:22 |
| jjardon | I can run a gnome session with root | 12:22 |
| gtristan | can you ? | 12:23 |
| gtristan | it works ? | 12:23 |
| jjardon | at least the wayland one yes | 12:23 |
| gtristan | right, that fits with what I'm thinking | 12:23 |
| gtristan | btw, there is no wayland working in vanilla gnome stratum by default | 12:24 |
| gtristan | that is a side project of yours :) | 12:24 |
| gtristan | so... this is a little bit of a disgusting thing the gnome-session guys did | 12:24 |
| gtristan | they try the wayland session | 12:24 |
| gtristan | and then they intentionally do g_error() | 12:24 |
| gtristan | causing SIGABRT | 12:24 |
| gtristan | when that fails, they try X | 12:24 |
| gtristan | so this is a guess, but I recall pulling my hair out for a while wondering why the hell it was segfaulting | 12:25 |
| gtristan | and found that it was an intentional segfault | 12:25 |
| persia | The code should be patched to trap that better, so it doesn't escape to the user. | 12:26 |
| gtristan | Here, it segfaults and things continue on gracefully as expected | 12:26 |
| gtristan | persia, right, there is certainly a lot of "should" :) | 12:26 |
| jjardon | gtristan: mmm, I think that logic is in gnome-session master, not 3.18? | 12:26 |
| jjardon | (wayland is the dedault in master now, falling back to X) | 12:27 |
| gtristan | jjardon, could be, what we have is something ahead of 3.18 for gnome-session and mutter | 12:27 |
| gtristan | it could be the problem is solved by backing down those 2 package versions, but the question remains; how come your gdm doesnt fallback properly while mine does ? | 12:28 |
| jjardon | gtristan: nah, we are only use 2 commits above 3.18.0, wich dont include that change | 12:29 |
| gtristan | 3 commits for gnome-session, 25 for mutter | 12:30 |
| gtristan | it might be exactly that change | 12:30 |
| gtristan | no, not gnome-session anyway | 12:31 |
| gtristan | gnome-session hasnt done anything significant in those 3 commits | 12:31 |
| ssam2 | tiagogomes, straycat: any thoughts about how to fix the problem with Mason log files? | 12:33 |
| ssam2 | tiagogomes: still seeing progress bars in them: https://mason-x86-64.baserock.org/log/d471751fa5c8b01aefcc09a648e52588041ce175--2015-12-21%2010:20:54.log | 12:33 |
| gtristan | jjardon, an output of journalctl could be telling | 12:33 |
| gtristan | jjardon, but it's probably got to do with system-integration differences | 12:34 |
| jjardon | mmm, interesting, after start gdm and trying to login again changing the tty, Im not able to login anymore with root | 12:36 |
| gtristan | /etc/securetty is setup, yeah | 12:37 |
| gtristan | jjardon, honestly I dont have a solution for accessing a GNOME system that doesnt boot properly through gdm the first time, other than creating a build which does | 12:39 |
| gtristan | my preferred way, if I get a build which is "bricked" in that way, is to rebuild without the systemctl enable gdm command in strata/gnome/gdm.morph | 12:40 |
| gtristan | the sshd_config does not allow logging in with password-less root | 12:40 |
| jjardon | rigth, seems the problem is that the gnome-initial-setup user doesnt exists | 12:41 |
| gtristan | if it does not, then neither do any others | 12:41 |
| jjardon | gtristan: yeah, thats what I did | 12:41 |
| gtristan | ah | 12:41 |
| gtristan | so that means that useradd is not working in morph | 12:42 |
| ssam2 | but the 'useradd' command doesn't return an error? great... | 12:42 |
| gtristan | yay | 12:42 |
| gtristan | ssam2, yes it does ! | 12:42 |
| gtristan | well, just not in this case | 12:42 |
| gtristan | I guess | 12:42 |
| ssam2 | it could be Morph being doubly broken, if it ignores the failure.. | 12:43 |
| gtristan | ssam2, I explicitly ignore the error of adding the 'pulse' user, because we still need to refactor out the users file from essential-files | 12:43 |
| gtristan | i.e. useradd at least in ybd, is known to cause an error "when the user already exists" | 12:44 |
| gtristan | but its not known to cause an error in ybd "when whatever the hell is happening in morph" happens :) | 12:44 |
| gtristan | jjardon, so please tell us... if you create the gnome-initial-setup user the way it's created in the system-integration commands... and then systemctl start gdm... does it work ? | 12:45 |
| jjardon | hang on, other users are being created, seems the only that is not is gnome-initial-setup | 12:45 |
| gtristan | jjardon, maybe it wants the /run/gnome-initial-setup directory to exist or smth ? | 12:46 |
| ssam2 | useradd vs. adduser ? | 12:46 |
| gtristan | ssam2, adduser is a debian think I believe | 12:47 |
| gtristan | we dont have useradd afaik | 12:47 |
| gtristan | s/think/thing | 12:47 |
| gtristan | sorry... we dont have "adduser" | 12:48 |
| gtristan | blah | 12:48 |
| jjardon | gtristan: let me check | 12:48 |
| gtristan | also be careful, when you say "other users are being created", is gdm one of them ? | 12:49 |
| gtristan | or only the static hacked users hard coded into the /etc/passwd file in essential-files ? | 12:49 |
| jjardon | ah! | 12:51 |
| jjardon | I found the problem | 12:51 |
| gtristan | we're on the edge of our seats | 12:51 |
| jjardon | gtristan: https://gerrit.baserock.org/#/c/1693/ | 12:53 |
| jjardon | not sure its a bug or a feature of ybd :) | 12:53 |
| jjardon | (or morph) | 12:54 |
| gtristan | eh ?? | 12:54 |
| gtristan | that word is significant somehow ?? | 12:54 |
| gtristan | ok | 12:54 |
| persia | So the issue is that the system-integration commands in morph only run when the name matches an artifact name, but in ybd they always run, because artifacts are not split? | 12:54 |
| gtristan | jjardon, so... if you create the user manually ? ... and start gdm... does it do anything ?? | 12:54 |
| gtristan | persia, or rather, is prefixed with the artifact name | 12:55 |
| gtristan | (or chunk name ? because that chunk doesnt declare any specific artifacts) | 12:55 |
| persia | gtristan: There are default splitting rules. | 12:55 |
| tiagogomes_ | ssam2 I guess the right thing to do is to now show the progress bar if the process is not running on a tty, but I don't have time to do a patch right now | 12:56 |
| persia | "-misc" is in the defaults. | 12:56 |
| gtristan | aha, so even -misc means something ! | 12:56 |
| persia | So ${CHUNK_NAME}+${ARTIFACT_NAME}="gnome-initial-setup-misc" | 12:56 |
| gtristan | I ran the risk of calling it gnome-initial-setup-pony and would not have been the wiser | 12:56 |
| ssam2 | wow, so much brokenness | 12:57 |
| persia | If my diagnosis is correct (which was a guess), then -pony would work in ybd (because of a ybd bug), and not work in morph. | 12:57 |
| jjardon | gtristan: yeah, if I create the user everything works | 12:57 |
| gtristan | jjardon, thanks, I was hoping that :D | 12:57 |
| jjardon | Id say is more a bug in morph; or you are relaxed with the name or you fail when the name is not corrent; keep running silently is not good | 12:58 |
| persia | Bother. My Baserock OpenID won't let me log in :( | 12:58 |
| gtristan | jjardon, the jury is out on that one; my knee-jerk opinion on this is that; if it's specific to a given artifact, it should be declared *in* the artifact section specifically | 12:59 |
| persia | No, it is a bug in ybd. One needs a mechanism to run *different* system-integration commands on a per-artifact basis. Running everything defined for a chunk may cause conflicting behaviour for certain sorts of chunks. | 12:59 |
| gtristan | and not be some relation which is joined by some suffix matching rule | 12:59 |
| persia | I'm not oposed to semantic clarification along the lines of gtristan's description, but I'd prefer not to "fix" it to just run everything blindly. | 13:00 |
| gtristan | right | 13:00 |
| ssam2 | persia: what is the error? | 13:01 |
| ssam2 | I think both morph and YBD are wrong... Morph should raise an error in this case | 13:01 |
| ssam2 | and in fact... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/builder.py#n448 | 13:02 |
| ssam2 | there is exactly the code that should generate a warning in this case | 13:02 |
| persia | ssam2: Yes, when parsing the definition, morph should complain if there are system-integration commands defined that do not match any generated artifact. | 13:02 |
| ssam2 | jjardon: any chance you might have not spotted the warning? | 13:02 |
| ssam2 | could be that it's just not visible enough... | 13:02 |
| ssam2 | gtristan: longer term, it's plausible that system-integration should live in the 'artifact' section... | 13:03 |
| persia | ssam2: On logging in? Seems either the username or password isn't the one I recorded. I will reset it: I don't think anything is actually broken. | 13:04 |
| ssam2 | ok :) | 13:04 |
| ssam2 | i did mean the openid error | 13:04 |
| persia | I no longer think morph is buggy, given the quoted line, assuming it generates a message. | 13:04 |
| ssam2 | tiagogomes_: seems the tty detection works when I run Morph locally | 13:07 |
| ssam2 | scripts/release-build has been quite broken by recent Morph changes | 13:13 |
| ssam2 | fixable though | 13:21 |
| tiagogomes_ | ssam2 I don't know how mason runs morph. I pointed out that the scripts in definitions are broken here in this channel | 13:21 |
| ssam2 | Mason runs Morph via the scripts/release-build script | 13:23 |
| ssam2 | which we also use to make releases | 13:23 |
| tiagogomes_ | ah | 13:24 |
| tiagogomes_ | then, this https://gerrit.baserock.org/#/c/1110/ and running morph with `--progress=never` is a way to handle the problem | 13:26 |
| ssam2 | right | 13:26 |
| ssam2 | i actually think the problem is distbuild forwarding the progress messages | 13:26 |
| ssam2 | that patch looks mergable, by the way, you could do the fix richard maw suggested | 13:28 |
| ssam2 | has 3 recent +1s | 13:28 |
| ssam2 | as for https://gerrit.baserock.org/#/c/1451/4 , I don't have a clue what's going on | 13:28 |
| tiagogomes_ | but depends on a patch that is not mergable yet | 13:29 |
| ssam2 | yeah | 13:29 |
| jjardon | gtristan: more problems; after creating a user with g-i-s, I can not login with it; seems like the password is not stored correctly or something. I will investigate after lunch | 13:29 |
| gtristan | hmmm | 13:34 |
| gtristan | jjardon, I have had some issues, but they seem to have gone away by themselves | 13:34 |
| gtristan | jjardon, what I have observed is rather; sometimes logging in works, sometimes it doesnt, and restarting the system fixes it, something to do with how the keys are interpretted at gdm login time | 13:35 |
| gtristan | havent seen that for a while though | 13:35 |
| gtristan | maybe ibus related | 13:36 |
| * gtristan out for the night | 13:36 | |
| gtristan | gah, webkit is building... need to rebuild 2 webkits again after changing the nss.morph build commands ;-) | 13:37 |
| gtristan | hehe | 13:37 |
| persia | Why 2 webkits? | 13:37 |
| gtristan | one of them for evolution and empathy, and another one for gnome-online-accounts and epiphany | 13:38 |
| gtristan | persia, parallel installable versions API/ABI change | 13:38 |
| persia | Both are consumed by maintained systems? | 13:39 |
| gtristan | both are consumed by GNOME | 13:39 |
| gtristan | running gnome requires 2 webkits, yeah | 13:39 |
| * persia is surprised the large distos haven't already patched that away | 13:40 | |
| gtristan | (in the same way that it normally requires 2 GTK+s and 2 pythons) | 13:40 |
| gtristan | not exactly trivial | 13:40 |
| gtristan | if the evolution folks have not ported, it's less likely that a downstream integration engineer has the know-how to do it | 13:40 |
| gtristan | for GTK+, at least you have pages and pages of "porting guide" | 13:41 |
| persia | As someone who used to be a "downstream integration engineer", I think you think too little of them :) | 13:41 |
| gtristan | hehe ok sorry, no offense intended | 13:42 |
| gtristan | it's a dogs life but I guess it pays to have someone experienced do the job | 13:42 |
| persia | My experience is that relatively stable upstream communities tend to have more experienced downstream folk (as the downstream folk have to train the less experienced upstreams, and don't have much interest in things that work properly, as they are focused on the bugs in their integrations). | 13:44 |
| persia | Whereas very active and complex upstreams (e.g. webkit) tend to have less experienced downstream, just because of the complexity (in this case, evolution folks would be downstream of webkit). | 13:44 |
| persia | And in such situations, the security teams for the downstream integrations make a huge fuss unless the better integrators try to reduce to one version of everything. | 13:45 |
| persia | Of course, that doesn't always work :) | 13:45 |
| gtristan | Also when it comes to complex libraries, when you *do* eventually break API/ABI, you want to do it dramatically | 13:46 |
| gtristan | because you'll be stuck with that new API for another 5-10 years | 13:46 |
| persia | Only if you behave yourself. I know of several libraries that change API a couple times a year. | 13:47 |
| gtristan | yes, that sucks, I have been disappointed in this change from GTK+2 -> GTK+3 | 13:48 |
| gtristan | anyway | 13:48 |
| gtristan | almost 11, gonna run to the gym | 13:48 |
| * tiagogomes_ is disappointed that firefox, chrome and gimp are still not using gtk3 after all these years | 13:49 | |
| *** gtristan has quit IRC | 13:53 | |
| *** tiagogomes_ has quit IRC | 15:00 | |
| ssam2 | r.e. GIMP: http://libregraphicsworld.org/blog/entry/gimp-is-20-years-old-what-is-next | 15:01 |
| ssam2 | for firefox, i'd rather they worked on fixing the absurdly high memory usage, before to a new toolkit (that will possibly increase memory usage further :-) | 15:02 |
| jjardon | persia: surprised? in my experience large distros contribute very little upstream (with the exception of redhat in GNOME, of course) | 15:09 |
| persia | jjardon: Considering the number of times I participated in an ABI or API transition sprint, yes. Whether the patches get sent upstream is a different issue. | 15:10 |
| jjardon | problem here is that empathy is a semi-unmaintained status for almost 2 years, do there is nobody available to do the port to webkit2 or clutter-gst3 | 15:10 |
| persia | At least in Debian, issues like that get RC bugs filed by the security team, and everyone pitches in. | 15:11 |
| jjardon | well, if you can find anyone that can help with this it would be extremely helpful: https://bugzilla.gnome.org/show_bug.cgi?id=749001 | 15:13 |
| *** tiagogomes_ has joined #baserock | 15:15 | |
| *** ctgriffiths_ has quit IRC | 15:29 | |
| *** ctgriffiths has joined #baserock | 15:29 | |
| radiofree | do we have a "genivi-gdp-sdk" type image anywhere? | 15:32 |
| radiofree | i.e a genivi-gdp image + devel image | 15:32 |
| ratmice______ | I always wished it was easier (as upstream) to build/send patches to downstream consumers, but as it is, the number of steps/manual process involved in building something against a modified/unreleased variation of upstream can be painful | 15:43 |
| ratmice______ | the ideal i think is some stupid empty top-level directory that you put projects into as subdirectories, it figures out the build order and builds everything in one make | 15:44 |
| ratmice______ | then for upstream you just have the main project dir, and upstream+consumers you add downstreams along side that... | 15:45 |
| ssam2 | i'm totally confused by what you mean ratmice :-) | 15:46 |
| ssam2 | i'm not sure how a directory could simultaneously be stupid but also able to figure out build orders | 15:47 |
| ratmice______ | ssam2: it is stupid in that it has zero top-level knowledge of the subdirectories, but has the ability to find dependency order from whatever subdirectories it does find | 15:48 |
| ratmice______ | part of this is that I hate that you even need to go through various stages of 'make install', to build against a particular change set, which leads to either post cleanup, or build-a-whole-distro process | 15:50 |
| * ratmice______ unfortunately lacks any hope of seeing it happen :( | 15:51 | |
| *** ssam2 has quit IRC | 15:52 | |
| *** toscalix has quit IRC | 16:04 | |
| ratmice______ | pkg-config can iirc almost get it via $foo-uninstalled.pc, but iirc the pkg-config interface presents itself in such a way as to only really be usable by users wishing to build against uninstalled libraries, rather than projects cooperating to link that way | 16:09 |
| persia | jjardon: (or proxy) Could you give me a non-empathy example GNOME component that has been ported to the webkit2 API? | 16:16 |
| jjardon | Epiphany, devhelp | 16:18 |
| ratmice______ | the problem is that the distro's you end up with the whole union of {a, b} U {a, c} U {d, c} = {a,b,c,d} and as upstream I don't care a lick about 'd', limiting the number of interested paries is crucial to avoiding tangential conflict | 16:18 |
| ratmice______ | anyhow, I'll shut up, happy holidays :) | 16:18 |
| jjardon | persia: more complete list here: https://wiki.gnome.org/Initiatives/GnomeGoals/Webkit2Porting | 16:19 |
| persia | Aha: libwwebkitgtk-3.0-dev vs. libwebkit2gtk-4.0-dev | 16:19 |
| persia | jjardon: Thanks. Next is to see if the team that used to do that is still active, or if I have to find a new team. | 16:20 |
| *** ssam2 has joined #baserock | 16:20 | |
| *** ChanServ sets mode: +v ssam2 | 16:20 | |
| persia | ratmice______: Happy holidays :) Your insight is interesting, making me curious about the sort of implementation you would seek for the "set of directories" model. | 16:25 |
| persia | Separately, I think that integration will always happen by the image builders: nobody else cares about as wide a set of coinstalled stuff. Finding the right way to share patches/solutions between integrators and project developers has always been a mess, especially when integrators branch from an existing integration, rather than consuming upstream directly (as most do). | 16:26 |
| ssam2 | so the subdirectories would contain the information on what depends on what? that would be nice, indeed | 16:27 |
| ssam2 | i did a sort of thing like that using CMake recently | 16:28 |
| ssam2 | which is not an ideal tool, but it does let you arbitrarily add subdirectories, and depend on things which may or may not be defined | 16:28 |
| ssam2 | can anyone do a quick review of https://gerrit.baserock.org/#/c/1697/ to fix scripts/release-build ? | 16:30 |
| ssam2 | i want to update Morph on mason-x86-64 to fix the hideous logs | 16:30 |
| ssam2 | but if I update it without #1697, the build will break because scripts/release-build won't run against the new morph | 16:31 |
| ratmice______ | persia: basically just recurse through subdirectories, look for a file (that contains the dependencies, cflags, ldflags), to build the complete graph, and expanding the *flags variables to full paths so you don't need a different relative path for each depth, if something *isnt* found in the build tree, then look for it in the system | 16:33 |
| persia | The difficulty is that many components have variable dependencies. Some detect things at build-time, others at run-time. | 16:34 |
| persia | So, as an integrator, one makes a choice about what features to enable/support. | 16:34 |
| persia | I don't understand how that could be inferred from an upstream-provided file. | 16:35 |
| persia | That aside, I'd love to migrate to machine-readable INSTALL files that expose the choices for post-processing outside human brains. | 16:35 |
| ratmice______ | ahh, yes im my opinion those things are evil and shouldn't exist | 16:36 |
| persia | What things are evil? | 16:37 |
| ratmice______ | variable dependencies specifically, there needs an explicit split at each dependency | 16:38 |
| persia | So everything is required to be present at build-time, but most things built are built in such a way to minimise dependencies, and at runtime the core attempts to dlopen() all the features, so that artifact splitting is sufficient to represent the integrator choices? | 16:39 |
| ratmice______ | something like a sound library, is a good example, if i have libsoundfile (and it magically links against some 'libwav', and then magically can work with wav files, and I write a program which depends on libsoundfile, there are 2 cases, I magically get wav support (yay!), and I really depend on wav support and should have the ability to request dependency on it, so i can send some generated wav file to some other program or sth | 16:41 |
| ratmice______ | there should be no in between where... 'oh you need libsoundfile linked against libwav' as it introduces human error | 16:42 |
| persia | To be fair, "you need libsoundfile coinstalled with libsndfile-libwav (which depends on libwav)" is just as prone to human error. | 16:43 |
| persia | In Debian, maintainers play games with dependencies vs. recommendations vs. suggestions all the time to deal with those sorts of bugs. | 16:43 |
| ratmice______ | right, but its compile time error, it's not a runtime error | 16:44 |
| persia | For most custom integrations, people just decide to coinstall or not coinstall without needing as may iterations because the end-user is more well-defined. | 16:44 |
| persia | Hrm? How is a coinstallation requirement a compile-time error? | 16:44 |
| persia | If I compile everything against everything else, I end up with hopelessly bloated systems. | 16:45 |
| persia | If I compile everything with plugins against everything else, I end up with coinstallation requirements that are not expressed by binary inspection. | 16:46 |
| persia | If I compile anything not against something else, I end up with missing functionality. | 16:46 |
| persia | To me, these are all runtime problems. | 16:46 |
| persia | (or image-build-time, depending on one's point of view)~ | 16:46 |
| ratmice______ | right, I kind of have issue with ld.so in this regard, the elf dynamic section is impure (as is dlopen), you can do dynamic loading pure, via specifying the dependencies explicitly, but only lazily loading them | 16:48 |
| persia | Like some of your other ideas, you raise excellent points that only require retraining millions of people to implement, rather than any actual changes in the software :) | 16:50 |
| persia | jjardon: I haven't heard back from the admin of that team, but that may be because of holidays. I'll note that the person who wrote that webpage is someone who used to be one of the downstream porters with whom I worked. | 16:52 |
| persia | (unless it is a common name somewhere, and it wasn't pochu2) | 16:52 |
| ratmice______ | the question IMO is whether we can wrest control of the dynamic section from 'make', that should allow us to simulate purity (even at dlopen time) using rtld-audit | 16:53 |
| ratmice______ | but yes, persia I find that your jab is true albeit frustrating | 16:54 |
| persia | ratmice______: You have my sympathy in every one of these: I'd really like to live in your alternate development universe. I just do not know how to get there without rewriting nearly every upstream and training them all in the new paradigm. | 16:56 |
| jjardon | persia: errr, did you work with Matthias Clasen? | 17:04 |
| persia | Emilo | 17:04 |
| jjardon | persia: ah, yeah he was the last one to edit that page but neither that page or patches have been done by him | 17:08 |
| persia | Ah. | 17:08 |
| *** ctbruce has quit IRC | 17:21 | |
| *** gtristan has joined #baserock | 18:12 | |
| *** ctgriffiths has quit IRC | 18:23 | |
| *** ssam2 has quit IRC | 18:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
