IRC logs for #baserock for Monday, 2015-12-21

*** edcragg has quit IRC00:17
*** gtristan has quit IRC01:44
*** gtristan has joined #baserock02:08
*** toscalix has joined #baserock07:53
*** ctbruce has joined #baserock08:30
*** tiagogomes_ has joined #baserock08:46
*** gtristan has quit IRC08:54
*** gtristan has joined #baserock09:39
*** ctgriffiths_ has joined #baserock09:44
*** SotK_ has joined #baserock09:45
gtristanRegarding 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
gtristanis there anything anyone would like me to test regarding that ?09:47
radiofreenice work gtristan09:47
gtristanthanks09:48
gtristanit's pretty complete now09:48
gtristansend/receive email, browse web, watch videos, chat09:48
gtristangood reference platform, few interesting things we can use that for, put baserock to the test :)09:49
*** SotK has quit IRC09:49
*** ctgriffiths has quit IRC09:49
*** gtristan has quit IRC09:58
*** brlogger` has joined #baserock09:59
*** gtristan_ has joined #baserock10:01
gtristan_hmmm10:02
gtristan_ceph-service, is most definitely unmaintained10:02
gtristan_it doesnt build, and that's not because of my nss patches10:02
gtristan_it tries to build boost, which fails.10:03
*** ssam2 has joined #baserock10:07
*** ChanServ sets mode: +v ssam210:07
*** rjek_ has joined #baserock10:08
*** trnv2 has joined #baserock10:11
*** gtristan has quit IRC10:12
*** trn has quit IRC10:12
*** bfletcher has quit IRC10:12
*** perryl has quit IRC10:12
*** benbrown_ has quit IRC10:12
*** brlogger has quit IRC10:12
*** rjek has quit IRC10:12
*** benbrown_ has joined #baserock10:15
*** trnv2 is now known as trn10:20
*** gtristan_ is now known as gtristan10:30
*** perryl has joined #baserock10:31
*** bfletcher has joined #baserock10:37
*** rjek_ is now known as rjek10:39
gtristanAny reason why we are not building/including libgmp ?11:01
persiaIn which target?11:02
tiagogomes_AFAIK, we are only including it to build gcc11:03
tiagogomes_I mean, it is included in the gcc-tarball repo, but I don't think it is installed into the system11:06
ssam2oh yeah... which is nice for making the bootstrap simpler11:06
ssam2but a pain if you want to use libgmp :-)11:06
persiaRepo or chunk?11:06
ssam2repo11:06
persiaAh, 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=b3c9b176c1f10ebeff5700eb3760e9511f23fa0611:08
gtristanno... we dont11:08
gtristansorry... no, we dont install it :)11:08
gtristanok so the answer is just basically, we have it setup so that gcc includes it's own and we just never install it11:10
gtristanbut, there is no intentional reason behind this11:10
gtristanok11:11
ssam2for stage1-gcc and stage2-gcc it makes a lot of sense11:11
ssam2for the final gcc, might make more sense to build and install libgmp separately so it can be used11:11
gtristanssam2, so while I have you here, do we have prior work towards cross compiling with baserock ?11:12
gtristanI heard it through the grape vine, that you might know :)11:12
ssam2right11:13
persiaIndeed: 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
ssam2give me a second :-)11:13
gtristantiagogomes_, 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 be11:15
ssam2gtristan: what we have is a cross-toolchain stratum for armv711:15
ssam2gtristan: 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-toolchain11:15
ssam2that exists so that you can build an 'SDK' system with a cross-toolchain for your device11:16
tiagogomes_Bi11:17
tiagogomes_wrong window syndrome11:17
ssam2maybe 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 work11:17
gtristanssam2, so currently we can cross compile to armv7lhf, using that ?11:18
ssam2theoretically, yeah11:18
persiaRather, we can generate an SDK that can cross compile.11:18
gtristanoh, but we havent even tried that far, I see11:18
gtristanssam2, basically *that* works to build a system which boots and has a cross compiler ?11:18
persiaYou need to worry about things like tpath and include directories separately, which means different chunk definitions.11:19
gtristanssam2, but then, you cant just use it as a build-essential replacement right ?11:19
persiaErr, rpath11:19
gtristanright, 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 automatically11:20
ssam2gtristan: the SDK is a 'system' only because Baserock forces everything to be a system11:20
ssam2gtristan: 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
gtristanssam2, 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 system11:22
ssam2yes11:23
ssam2no11:23
ssam2the 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 bits11:23
gtristanoh wait no, I got confused sorry11:24
gtristanof course it wouldnt do anything useful11:24
persiaWhy not?11:24
gtristanssam2, it would end up building a system for your own host, which would include a cross compiler11:24
gtristanthe system would not be "cross compiled"11:24
ssam2yeah11:24
gtristansure, it would be useful in some measure of useful11:24
persiaWhich cross compiler one could build depend upon11:24
gtristanits a start11:25
ssam2for autotools chunks, passing --host=armv7lhf-baserock-gnueabi to configure might be enough11:25
ssam2the problem with trying to teach build tools to do this... is there's no 'lingua franca' for architectures, of course11:26
gtristanyeah11:26
gtristanyou'd have to have some kind of database/table for that11:27
persiaYAML in definitions, by preference, to ease adding new architectures.11:27
*** edcragg has joined #baserock11:29
* gtristan builds armv7lhf-cross-toolchain and buildroot at the same time11:30
*** tiagogomes_ has left #baserock11:31
*** tiagogomes_ has joined #baserock11:31
jjardongtristan: hi, building master, gdm keeps crashing when building along with gnome-initial-support; do this happen to you before?11:59
gtristanjjardon, no, all that comes to mind is that fontconfig issue12:04
gtristanjjardon, how does it crash ? are you building the GNOME stratum vanilla or have some change ?12:05
gtristans/gnome-initial-support/gnome-initial-setup ... right ?12:07
jjardonyeah, GNOME stratum vanilla; let me take an screenshot12:11
gtristanI believe you :)12:12
gtristanhehe12:12
gtristanjjardon, so what could possibly be different ?12:12
gtristanmaybe you are building with morph !? I'd be surprised if that causes it to not work12:13
jjardonoh, yeah, that can be a different12:13
jjardondifference*12:13
jjardonThis is the error Im getting https://usercontent.irccloud-cdn.com/file/FxAYequ9/Screenshot%20from%202015-12-21%2012-13-10.png12:14
jjardonIf I do not build gnome-initial-setup, gdm runs without problems12:14
ssam2my first guess would be system-integration commands behaving differently...12:15
gtristanyes12:15
ssam2https://storyboard.baserock.org/#!/story/54 is relevant12:16
gtristancould be that the useradd commands arent working properly ?12:16
ssam2that's my guess12:17
ssam2although if so, gdm is also at fault, because it shouldn't just be segfaulting12:17
gtristannote that I ended up running into problems with linux-user-chroot and have since been using ybd with chroot only12:18
gtristanbut nothing like this12:18
persiaThat is not a safe way to build, but that is probably unrelated.12:18
gtristanso what is error 612:19
persiaFrom what?12:20
gtristanpersia, the screenshot12:21
gtristanaudit message12:21
gtristanI know what's going on jjardon12:21
gtristanI am "pretty" sure12:21
gtristanerror 6 is SIGABRT12:21
gtristanjjardon, and without gnome-initial-setup, you dont have any user12:22
gtristanso, you are *never* trying to run a gnome-session12:22
gtristanyou just have gdm without gnome-initial-setup and a completely useless system ;-)12:22
persiaAccording to `errno -l`, on my system error 6 is ENXIO : maybe check on the target?12:22
jjardonI can run a gnome session with root12:22
gtristancan you ?12:23
gtristanit works ?12:23
jjardonat least the wayland one yes12:23
gtristanright, that fits with what I'm thinking12:23
gtristanbtw, there is no wayland working in vanilla gnome stratum by default12:24
gtristanthat is a side project of yours :)12:24
gtristanso... this is a little bit of a disgusting thing the gnome-session guys did12:24
gtristanthey try the wayland session12:24
gtristanand then they intentionally do g_error()12:24
gtristancausing SIGABRT12:24
gtristanwhen that fails, they try X12:24
gtristanso this is a guess, but I recall pulling my hair out for a while wondering why the hell it was segfaulting12:25
gtristanand found that it was an intentional segfault12:25
persiaThe code should be patched to trap that better, so it doesn't escape to the user.12:26
gtristanHere, it segfaults and things continue on gracefully as expected12:26
gtristanpersia, right, there is certainly a lot of "should" :)12:26
jjardongtristan: 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
gtristanjjardon, could be, what we have is something ahead of 3.18 for gnome-session and mutter12:27
gtristanit 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
jjardongtristan: nah, we are only use 2 commits above 3.18.0, wich dont include that change12:29
gtristan3 commits for gnome-session, 25 for mutter12:30
gtristanit might be exactly that change12:30
gtristanno, not gnome-session anyway12:31
gtristangnome-session hasnt done anything significant in those 3 commits12:31
ssam2tiagogomes, straycat: any thoughts about how to fix the problem with Mason log files?12:33
ssam2tiagogomes: still seeing progress bars in them: https://mason-x86-64.baserock.org/log/d471751fa5c8b01aefcc09a648e52588041ce175--2015-12-21%2010:20:54.log12:33
gtristanjjardon, an output of journalctl could be telling12:33
gtristanjjardon, but it's probably got to do with system-integration differences12:34
jjardonmmm, interesting, after start gdm and trying to login again changing the tty, Im not able to login anymore with root12:36
gtristan /etc/securetty is setup, yeah12:37
gtristanjjardon, 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 does12:39
gtristanmy 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.morph12:40
gtristanthe sshd_config does not allow logging in with password-less root12:40
jjardonrigth, seems the problem is that the gnome-initial-setup user doesnt exists12:41
gtristanif it does not, then neither do any others12:41
jjardongtristan: yeah, thats what I did12:41
gtristanah12:41
gtristanso that means that useradd is not working in morph12:42
ssam2but the 'useradd' command doesn't return an error? great...12:42
gtristanyay12:42
gtristanssam2, yes it does !12:42
gtristanwell, just not in this case12:42
gtristanI guess12:42
ssam2it could be Morph being doubly broken, if it ignores the failure..12:43
gtristanssam2, I explicitly ignore the error of adding the 'pulse' user, because we still need to refactor out the users file from essential-files12:43
gtristani.e. useradd at least in ybd, is known to cause an error "when the user already exists"12:44
gtristanbut its not known to cause an error in ybd "when whatever the hell is happening in morph" happens :)12:44
gtristanjjardon, 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
jjardonhang on, other users are being created, seems the only that is not is gnome-initial-setup12:45
gtristanjjardon, maybe it wants the /run/gnome-initial-setup directory to exist or smth ?12:46
ssam2useradd vs. adduser ?12:46
gtristanssam2, adduser is a debian think I believe12:47
gtristanwe dont have useradd afaik12:47
gtristans/think/thing12:47
gtristansorry... we dont have "adduser"12:48
gtristanblah12:48
jjardongtristan: let me check12:48
gtristanalso be careful, when you say "other users are being created", is gdm one of them ?12:49
gtristanor only the static hacked users hard coded into the /etc/passwd file in essential-files ?12:49
jjardonah!12:51
jjardonI found the problem12:51
gtristanwe're on the edge of our seats12:51
jjardongtristan: https://gerrit.baserock.org/#/c/1693/12:53
jjardonnot sure its a bug or a feature of ybd :)12:53
jjardon(or morph)12:54
gtristaneh ??12:54
gtristanthat word is significant somehow ??12:54
gtristanok12:54
persiaSo 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
gtristanjjardon, so... if you create the user manually ? ... and start gdm... does it do anything ??12:54
gtristanpersia, or rather, is prefixed with the artifact name12:55
gtristan(or chunk name ? because that chunk doesnt declare any specific artifacts)12:55
persiagtristan: 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 now12:56
persia"-misc" is in the defaults.12:56
gtristanaha, so even -misc means something !12:56
persiaSo ${CHUNK_NAME}+${ARTIFACT_NAME}="gnome-initial-setup-misc"12:56
gtristanI ran the risk of calling it gnome-initial-setup-pony and would not have been the wiser12:56
ssam2wow, so much brokenness12:57
persiaIf 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
jjardongtristan: yeah, if I create the user everything works12:57
gtristanjjardon, thanks, I was hoping that :D12:57
jjardonId 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 good12:58
persiaBother.  My Baserock OpenID won't let me log in :(12:58
gtristanjjardon, 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 specifically12:59
persiaNo, 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
gtristanand not be some relation which is joined by some suffix matching rule12:59
persiaI'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
gtristanright13:00
ssam2persia: what is the error?13:01
ssam2I think both morph and YBD are wrong... Morph should raise an error in this case13:01
ssam2and in fact... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/builder.py#n44813:02
ssam2there is exactly the code that should generate a warning in this case13:02
persiassam2: Yes, when parsing the definition, morph should complain if there are system-integration commands defined that do not match any generated artifact.13:02
ssam2jjardon: any chance you might have not spotted the warning?13:02
ssam2could be that it's just not visible enough...13:02
ssam2gtristan: longer term, it's plausible that system-integration should live in the 'artifact' section...13:03
persiassam2: 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
ssam2ok :)13:04
ssam2i did mean the openid error13:04
persiaI no longer think morph is buggy, given the quoted line, assuming it generates a message.13:04
ssam2tiagogomes_: seems the tty detection works when I run Morph locally13:07
ssam2scripts/release-build has been quite broken by recent Morph changes13:13
ssam2fixable though13:21
tiagogomes_ssam2 I don't know how mason runs morph. I pointed out that the scripts in definitions are broken here in this channel13:21
ssam2Mason runs Morph via the scripts/release-build script13:23
ssam2which we also use to make releases13:23
tiagogomes_ah13:24
tiagogomes_then, this https://gerrit.baserock.org/#/c/1110/ and running morph with `--progress=never` is a way to handle the problem13:26
ssam2right13:26
ssam2i actually think the problem is distbuild forwarding the progress messages13:26
ssam2that patch looks mergable, by the way, you could do the fix richard maw suggested13:28
ssam2has 3 recent +1s13:28
ssam2as for https://gerrit.baserock.org/#/c/1451/4 , I don't have a clue what's going on13:28
tiagogomes_but depends on a patch that is not mergable yet13:29
ssam2yeah13:29
jjardongtristan: 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 lunch13:29
gtristanhmmm13:34
gtristanjjardon, I have had some issues, but they seem to have gone away by themselves13:34
gtristanjjardon, 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 time13:35
gtristanhavent seen that for a while though13:35
gtristanmaybe ibus related13:36
* gtristan out for the night13:36
gtristangah, webkit is building... need to rebuild 2 webkits again after changing the nss.morph build commands ;-)13:37
gtristanhehe13:37
persiaWhy 2 webkits?13:37
gtristanone of them for evolution and empathy, and another one for gnome-online-accounts and epiphany13:38
gtristanpersia, parallel installable versions API/ABI change13:38
persiaBoth are consumed by maintained systems?13:39
gtristanboth are consumed by GNOME13:39
gtristanrunning gnome requires 2 webkits, yeah13:39
* persia is surprised the large distos haven't already patched that away13:40
gtristan(in the same way that it normally requires 2 GTK+s and 2 pythons)13:40
gtristannot exactly trivial13:40
gtristanif the evolution folks have not ported, it's less likely that a downstream integration engineer has the know-how to do it13:40
gtristanfor GTK+, at least you have pages and pages of "porting guide"13:41
persiaAs someone who used to be a "downstream integration engineer", I think you think too little of them :)13:41
gtristanhehe ok sorry, no offense intended13:42
gtristanit's a dogs life but I guess it pays to have someone experienced do the job13:42
persiaMy 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
persiaWhereas 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
persiaAnd 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
persiaOf course, that doesn't always work :)13:45
gtristanAlso when it comes to complex libraries, when you *do* eventually break API/ABI, you want to do it dramatically13:46
gtristanbecause you'll be stuck with that new API for another 5-10 years13:46
persiaOnly if you behave yourself.  I know of several libraries that change API a couple times a year.13:47
gtristanyes, that sucks, I have been disappointed in this change from GTK+2 -> GTK+313:48
gtristananyway13:48
gtristanalmost 11, gonna run to the gym13:48
* tiagogomes_ is disappointed that firefox, chrome and gimp are still not using gtk3 after all these years13:49
*** gtristan has quit IRC13:53
*** tiagogomes_ has quit IRC15:00
ssam2r.e. GIMP: http://libregraphicsworld.org/blog/entry/gimp-is-20-years-old-what-is-next15:01
ssam2for 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
jjardonpersia: surprised? in my experience large distros contribute very little upstream (with the exception of redhat in GNOME, of course)15:09
persiajjardon: 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
jjardonproblem 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-gst315:10
persiaAt least in Debian, issues like that get RC bugs filed by the security team, and everyone pitches in.15:11
jjardonwell, if you can find anyone that can help with this it would be extremely helpful: https://bugzilla.gnome.org/show_bug.cgi?id=74900115:13
*** tiagogomes_ has joined #baserock15:15
*** ctgriffiths_ has quit IRC15:29
*** ctgriffiths has joined #baserock15:29
radiofreedo we have a "genivi-gdp-sdk" type image anywhere?15:32
radiofreei.e a genivi-gdp image + devel image15: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 painful15: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 make15:44
ratmice______then for upstream you just have the main project dir, and upstream+consumers you add downstreams along side that...15:45
ssam2i'm totally confused by what you mean ratmice  :-)15:46
ssam2i'm not sure how a directory could simultaneously be stupid but also able to figure out build orders15: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 find15: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 process15:50
* ratmice______ unfortunately lacks any hope of seeing it happen :(15:51
*** ssam2 has quit IRC15:52
*** toscalix has quit IRC16: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 way16:09
persiajjardon: (or proxy) Could you give me a non-empathy example GNOME component that has been ported to the webkit2 API?16:16
jjardonEpiphany, devhelp16: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 conflict16:18
ratmice______anyhow, I'll shut up, happy holidays :)16:18
jjardonpersia: more complete list here: https://wiki.gnome.org/Initiatives/GnomeGoals/Webkit2Porting16:19
persiaAha: libwwebkitgtk-3.0-dev vs. libwebkit2gtk-4.0-dev16:19
persiajjardon: 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 #baserock16:20
*** ChanServ sets mode: +v ssam216:20
persiaratmice______: 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
persiaSeparately, 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
ssam2so the subdirectories would contain the information on what depends on what? that would be nice, indeed16:27
ssam2i did a sort of thing like that using CMake recently16:28
ssam2which is not an ideal tool, but it does let you arbitrarily add subdirectories, and depend on things which may or may not be defined16:28
ssam2can anyone do a quick review of https://gerrit.baserock.org/#/c/1697/ to fix scripts/release-build ?16:30
ssam2i want to update Morph on mason-x86-64 to fix the hideous logs16:30
ssam2but if I update it without #1697, the build will break because scripts/release-build won't run against the new morph16: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 system16:33
persiaThe difficulty is that many components have variable dependencies.  Some detect things at build-time, others at run-time.16:34
persiaSo, as an integrator, one makes a choice about what features to enable/support.16:34
persiaI don't understand how that could be inferred from an upstream-provided file.16:35
persiaThat 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 exist16:36
persiaWhat things are evil?16:37
ratmice______variable dependencies specifically, there needs an explicit split at each dependency16:38
persiaSo 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 sth16:41
ratmice______there should be no in between where... 'oh you need libsoundfile linked against libwav' as it introduces human error16:42
persiaTo be fair, "you need libsoundfile coinstalled with libsndfile-libwav (which depends on libwav)" is just as prone to human error.16:43
persiaIn 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 error16:44
persiaFor 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
persiaHrm?  How is a coinstallation requirement a compile-time error?16:44
persiaIf I compile everything against everything else, I end up with hopelessly bloated systems.16:45
persiaIf I compile everything with plugins against everything else, I end up with coinstallation requirements that are not expressed by binary inspection.16:46
persiaIf I compile anything not against something else, I end up with missing functionality.16:46
persiaTo 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 them16:48
persiaLike 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
persiajjardon: 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-audit16:53
ratmice______but yes, persia I find that your jab is true albeit frustrating16:54
persiaratmice______: 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
jjardonpersia: errr, did you work with Matthias Clasen?17:04
persiaEmilo17:04
jjardonpersia: ah, yeah he was the last one to edit that page but neither that page or patches have been done by him17:08
persiaAh.17:08
*** ctbruce has quit IRC17:21
*** gtristan has joined #baserock18:12
*** ctgriffiths has quit IRC18:23
*** ssam2 has quit IRC18:28

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!