IRC logs for #baserock for Sunday, 2014-10-26

*** zoli_ [~zoli_@linaro/zoli] has joined #baserock06:30
*** franred [~franred@host-89-240-75-201.as13285.net] has joined #baserock07:45
*** franred [~franred@host-89-240-75-201.as13285.net] has quit [Quit: Leaving]07:57
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]08:05
radiofreeIs there any morph/bash too for "copy the cache for this system somewhere else"?09:06
radiofreeS/too/foo09:06
straycatNothing special really, it's just a directory with artifacts and git repos09:13
radiofreestraycat: yeah but on my development system i have a lot of artefacts, how do i copy out the ones from the system i just built? by date? 09:14
straycatyou could use morph list-artifacts to get a list of artifacts a system produces09:15
radiofreethat sounds like what i want, thanks09:16
ratmice_______"GraphViz is not currently part of Baserock so you need to run `dot` on another system." is there any particular reason for that (I can't recall the particulars of the graphviz license)10:22
* ratmice_______ imagines it probably has to do with the pulling in of all the image generation dependencies10:26
jjardonHi! Is there any work related to port the baserock code to Python3?10:40
KinnisonThe main issue is the dependencies of morph10:41
Kinnisonrichard_maw has said that morph's codebase itself ought to be a mostly mechanical conversion to python310:41
Kinnisonbut that we depend on a number of libraries which are harder to port10:42
* Kinnison gets on with his sunday10:42
straycatratmice_______, probably, and there's not much demand to add it10:50
ratmice_______straycat: well, i was thinking ogdf may help if it was a license issue, (though not if its just a pulling in too much stuff issue), anyhow it has more stuff available for dealing with large graphs, but is also less easy to use (being a library vs a command), but if keeping 'run on another system' it's going to be less convenient given dot has a much wider install base...11:09
straycatgraphviz seems to have an eclipse license, so that should be okay?11:18
ratmice_______ahh, they've changed it used to be "at&t source code agreement"11:22
straycatso we could add graphviz to baserock, i just didn't realise people would want it11:24
straycatodgf also looks pretty cool11:24
ratmice_______i wonder if the python bindings from gsoc are going to make it in the next release (I wish these guys would put up a repo)11:25
* radiofree begins the fetchining11:31
radiofreedoes backrock cache arm builds on gbo now?11:32
radiofreeapparently only up to cpython!11:33
paulsherwoodonly release builds11:33
radiofreeah, i'm building from master11:33
paulsherwoodit's a niggle11:34
paulsherwoodone of many11:34
* paulsherwood is surprised to see node has been added to devel11:34
radiofreewhat do you think I should be doing here, this is for Gavin McCall's request on the mailing list btw11:35
radiofreebuild from master, push the cache, build from release tag, not much to push11:35
paulsherwoodwhatever is least work for you :)11:36
radiofreethey're both pretty easy, it's just two commits on top of a branch, i'll use the release tag though, should be faster11:36
paulsherwoodok. remember to push your result :) i'm due to do a tutorial on jetson today, i'll use your stuff if i can find it :-)11:37
radiofreeit's already push11:40
radiofreehttp://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-unified-kernel11:40
radiofreeand now http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-unified-kernel-14.40.111:41
paulsherwoodok thanks11:41
radiofreethis contains a new kernel which i'm hoping we can use for both the devel and jetson systems11:42
radiofreeso we can use the same version of u-boot on them11:42
paulsherwoodcool11:42
radiofreeooh this is much better11:48
paulsherwoodhowso?11:50
radiofreecached!11:50
*** De|ta_ [~arc@195.242.156.171] has joined #baserock12:53
*** ridgerun1er [~robjones@access.ducie-dc1.codethink.co.uk] has joined #baserock12:53
*** De|ta [~arc@195.242.156.171] has quit [Ping timeout: 260 seconds]12:55
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds]12:55
*** ridgerunner [~robjones@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 260 seconds]12:55
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock12:58
*** ratmice________ [bosshog@nightfall.forlorn.net] has joined #baserock13:32
*** pdar_ [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock13:32
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock13:34
radiofreewe should really benchmark this properly but 2014-10-26 14:57:37 [Build 141/145] [linux-jetson-tk1] Elapsed time 00:09:3715:01
radiofreewith the new kernel, seems... faster15:01
paulsherwoodseems about right15:11
paulsherwoodbut yes, a little faster. maybe ccache is helping?15:12
radiofreeinterestingly the same kernel just took 2014-10-26 15:19:46 [Build 94/227] [linux-jetson-tk1-genivi] Elapsed time 00:15:2815:19
radiofreeah15:20
radiofreethe genivi one has 5 minutes of install commands!15:20
radiofree(installing kernel sources)15:20
paulsherwoodwhoa! :)15:22
cyndisah, are you using the upstream kernel on all jetson builds? :) nice15:23
cyndisbtw, you don't need the long kernel cmdline args when running on upstream15:23
paulsherwoodreally?15:23
radiofreecyndis: yes i noticed that15:23
cyndisgood :)15:24
radiofreecyndis: the plan is to use an upstream kernel for our devel images, thanks to your cpufreq patches :)15:24
radiofreewe're using upstream on our genivi images already15:25
cyndiswell, i'm just maintaining them, but great :)15:25
radiofreejjardon: disable-glx is definitely causing libGL not to be built15:27
radiofreehowever the pkgconfig entries get installed15:27
* paulsherwood has posted two new tutorial videos on wiki.baserock.org15:55
persia_ is now known as persia16:35
persiaFollowing backscroll:16:39
persiaOn not tagging morph on baserock releases: I don't think morph should be tagged because I don't think morph should be special as an upsteam.  The desire to tag morph is mostly a workaround for morph not having a sensible branch or release strategy for itself.16:40
persiaOn systems being examples: yes, every system, even those used every day should only be considered examples.  Most developers should consider having private definitions branches containing a minor variation from the examples to include the tools they prefer that others care little about (most of the examples contain too much, to avoid people finding them not containing enough).16:41
persiaOn readline: it probably makes sense to have a set of example definitions for a readline-inclusive system, and another for a readline-exclusive system.  This doesn't fit well with the current directory structure, as there are reasons one would want to have similarly named strata.16:43
persiaBranching would be one solution, but most folk don't feel comfortable working on multiple "primary" branches simultaneously (despite git being fairly good at this), so as long as there is a desire for "master" to have meaning, layout probably needs thought.16:43
straycatA genivi branch doesn't seem like such a bad idea to me16:44
persiaOn conditional inclusion of chunks: I'd be violently against this.  Rather, I'd like to see the strata even more fragmented than they are currently, so we don't need to have logic therein.  The simple declarative nature of definitions is very powerful, and conditionals break this.16:44
straycateek16:45
* straycat hides16:45
persiastraycat: In the special case of GENIVI, I almost agree with you, as the needs of GENIVI folk are fairly different from the needs of non-GENIVI folk.16:45
persiaThe interesting question then becomes whether there is one "definitions" project, or if there are several definitions projects, each reaching towards some need.16:46
persiaIf the latter, I imagine at least "genivi", "baserock-infra", and "development"16:46
persia(actually, thinking about this more, having this split as part of "Baserock" might help folk who host their own definiitions feel more included, as they aren't forking, just hosting yet another definitions repo as part of the wider whole)16:47
paulsherwoodpersia: on tagging morph - my issue is that (because of other weaknesses in interdepends in baserock) i often find myself needing to know which version of morph was delivered with a given release. failing to tag morph makes this a pita.16:47
straycatI did feel that conditional inclusion of chunks was a naive solution to the problem that wouldn't be popular exactly because we seem to be trying to keep definitions simple16:47
* persia apologises for being scary, and hunts around for cream16:47
persiapaulsherwood: How so?  It's in the definitions for the release.16:48
straycatpersia, :)16:48
persiastraycat: I'd agree with that analysis.  Unfortunately, most of us come from a background of the converging linux distribution model, and it's hard to force the mind away from what seem like easy solutions (yet have annoying implications when it comes to reliability, reproducibilty, and traceability)16:50
persias/yet have/despite/16:51
paulsherwoodpersia: you're right. still more of a fiddle around than necessary imo, but i drop my point16:55
persiaI usually just grep for the repo, but isn't there a manifest tool that is supposed to report that directly?16:55
persiaIf not, we ought do one, because it's a sensible thing to need to check.16:56
persiaMind you, for misbehaving upstreams without sensible release strategies (like morph), "version" doesn't mean very much.16:56
paulsherwoodgah... you've reminded me i need to wade through at least a week's worth of 'freezing upstream tags for reproducibility' mails17:02
paulsherwoodpersia: did you read http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-October/008682.html17:03
persiaYes, but re-reading in case I missed an implication at the time.17:04
persiaRight.  I assert that the build system (morph) should care not one whit about any of this.17:05
paulsherwoodagreed17:05
persiaAlso that the archive curation suite (lorry) should be tunable to give 1, 2a, or 2b, depending on the implementing organisation.17:05
paulsherwoodagreed17:05
persiaAnd I think the baserock project should use solely SHA1 refs for the definitions of systems used for baserock infrastructure.17:06
persiaI'm less certain about the right answer for GENIVI systems.17:06
persiaFor infrastructure, my reasoning is that 1) we never care about the headline versions of anything for our infrastructure, only the actual code, and 2) we need tooling that can inject and process this sort of thing anyway, and if we let ourselves get distracted by tags, we'll never be able to describe what tooling we need, so never build it.17:08
persiaOther organisations managing definitions have different constraints: some do care about headline versions, some are happy to track moving targets in some contexts, etc.  For those, limiting use to SHA1 would be wrong.17:08
persia(this is why I was so easily convinced by straycat that my idea of avoiding branching definitions was wrong-headed: it behooves the project to also provide examples of graceful forking and collaboration)17:09
paulsherwoodin a situation where most of those SHA1s are being updated by mason/firehose, i agree. except i think they should be the (short, unique) SHA1s for the trees, not the commits.17:10
persiaWhy?  That's just extra computation to generate them to make them more human-readable, except the systems in question are automation who will find SHA1s easier to parse.17:11
persiaAlso, commit SHA is more useful than tree SHA, because there's not a one-to-one relation between commits and trees, and it is useful to be able to identify the parentage of the tree, as well as the tree used, to be able to traverse the merge path in a sane way if one wishes to have a series of automated checks.17:12
paulsherwoodbecause humans have to read them too, from time to time17:13
persiaYes, but not as much as automation, and it's more expensive for the automation than the human.17:13
persiaBecause the human really doesn't want to know either the SHA or the short-tag-sha-thing, but rather, to be able to navigate into history sanely.17:13
paulsherwoodi'm not convinced, but ok17:14
persiaWHich means that whatever info is stored, the user is unhappy until they are given tooling.17:14
persiaI'm not going to argue too heavily against using some fancy tagname, as long as it's a commit tag, rather than a tree tag, because without tooling, using more human-comprehensible data makes a sensible compromise in the computational complexity balance between humans and robots.17:15
persiaIf we can ease this for the use, I'd suggest we ease it by processing SHAs, because it's cheaper, and trivial to move from some half-human-readable value to SHA again.17:15
persiaErr s/for the use/for use/17:16
persia(or maybe I wanted to add a "of humans in there")17:16
paulsherwoodi thought you meant s/the use/the user/ :)17:16
persiaThat works too.  I suspect I meant something between the three, and my fingers faithfully expressed the vagueness of my thoughts :)17:18
persia(Douglas Hofstadter has a brilliant talk about this phenomena hosted on youtube: part of a generalised assertion that human thought is driven by analogy)17:19
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]17:22
* paulsherwood gets bogged down replying to just the first of the 'Freezing' emails, and questions the value of commenting at all17:51
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock17:52
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]17:52
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock17:52
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]17:55
persiaLooking at my thread list: there's interesting stuff in there, but yeah, the actual thread seems to have become a mess: I was mostly ignoring it until I was invoked directly.17:59
* paulsherwood struggles through his meail, and launches it18:08
* paulsherwood then notices that persia launched in the meantime...18:09
* persia had a prod and nothing better to do than read email while avoiding eating four-rivers styly cuisine again and procrastinating $work :)18:10
paulsherwoodheh18:11
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock18:24
radiofreepaulsherwood: if you're going to use baserock/james/jetson-unified-kernel-14.40.1 it does work19:16
radiofreeyou'll want to use it on either a system with the genivi-jetson u-boot, or reflash the image with the u-boot that's in /boot/19:16
radiofreetook forever to copy it via access though (jetson on desk -> access was slooooooow)19:17
rjekBoo, it appears liballegro does not have a Wayland backend, only X19:17
* rjek wants to build a system that boots into RISC OS, damnit!19:17
* rjek supposes he has been meaning to submit a patch to RPCEmu to make it use SDL instead.19:18
rjek(For years I've been meaning to.)19:18
radiofreeRISC OS uses wayland? oO19:18
rjekradiofree: No!  That's the problem :)19:18
rjekRPCEmu uses liballegro, which is like a nasty pustulent version of SDL.19:18
rjekAnd liballegro has no Wayland backend.19:19
rjek(RPCEmu being a RiscPC emulator with JIT)19:19
radiofreei wanted to purge X from baserock but i didn't think i was successful19:19
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:19
rjekI would like to keep X in Baserock :)19:19
radiofree^ debian user19:19
radiofreejoke!!19:19
robtaylorrjek: ooi, how does its speed comapre to qemu?19:19
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock19:20
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]19:20
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:20
rjekWayland has been "ready in 6 months" for years now, and doesn't actually do what I want for a graphical stack :)19:20
radiofreewell wayland is only the protocol, blame weston19:20
rjekrobtaylor: The JIT?  It's probably slower.  But it can do 26 bit modes.19:20
rjekradiofree: Does the protocol allow for network transparency and centralised window management?19:20
rjekI was under the impression that it does not19:20
persiaThe protocol allows for centralised window management.19:21
robtaylorrjek: the protocol's inherently estensivle19:21
persiaNetwork transparency is specifically excluded as a design goal19:21
radiofreethere are patches for weston that support network transparency19:22
robtaylorrjek: the confusion is usally between specific implmengtations and the wayland protocol itself19:22
persiaReally?19:22
radiofreepersia: yes, i used that a year or so ago19:22
rjekrobtaylor: I thought all the implementations were Weston or a fork of Weston :)19:22
radiofreerjek: see clutter19:22
rjekWhy does modern GTK want to be the window manager? :(19:22
robtaylorrjek: nope,i coulnt at least 3, and that's without the commercial ones19:22
rjekradiofree: I thought clutter was a GL toolkit ontop of Gtk.  Has that changed?19:22
persiaradiofree: My search engines are being unhelpful: do you happen to have a reference other than "weston" and "network transparency"?19:22
robtaylor(3 root code bases, that is)19:23
radiofreebecause people have adopted the lack of the wayland spec saying "it's up to the compositor/window manager to handle decoration"19:23
radiofreeand decided that means every app has to handle it19:23
rjekThis makes me sad.19:23
radiofreewhich is ludicrous19:23
persiaEvery app?  That's broken.19:23
radiofreepersia: gtk does it at the toolkit level, so does qt19:23
persiaThe *window manager* and or the *compositor* should handle decoration, not the apps.19:23
rjekGtk now even handles the windows under X.  It's a travesty.19:23
robtaylorhttp://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/19:23
radiofreepersia: i aggree entirely19:23
persiaradiofree: I know.  It's easier to do cross-platform that way.  It's still broken.19:24
* persia hugs the ghost of Xerox19:24
rjekpersia: Modern Gtk handles the windows even under X :(19:24
radiofreeNothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations19:24
radiofreefrom robtaylor's link19:24
persiarjek: I knew there was a reason I stopped using GTK apps.  Now I just have to stop using Qt without falling into another hole.19:24
radiofreeit's just for some reason everyone has decided to run with the "it's up to the app to deal with decoration"19:24
robtaylorkde does server side decorations on wayland19:24
rjek"decoration" belittles their purpose.  I prefer "furniture"19:25
radiofreekde is also implementing using a weston plugin19:25
rjekIf only because it's a nicer word :)19:25
radiofreerather than reimplement weston...19:25
persiaradiofree: I thought the KDE solution was to back kwin with wayland directly (although I've not been following in some time)19:25
robtaylorthe gtk guys wanted to to do client side for more flexible furniture. that could of course be done server side with a suitable protocol extension19:26
rjekOOI, what problems do I have that Weston/Wayland/Whatever solves?  Debian Jessie will have some support for it.  Should I bother with it?19:26
rjek(I only make use of X's network transparency one or twice a week...)19:26
robtaylorbut they wanted to start moving way before that could happen19:26
radiofreei suppose debian jessie has support for it via gnome 3.14?19:26
rjekradiofree: Something like that.19:26
radiofreein which case that's wayland/clutter19:26
rjekIt's packaged and included, IIRC19:26
robtaylorrjek: you, probably not so many19:26
radiofreehowever it doesn't really work very well19:26
radiofreemost things use xwayland19:26
radiofreewayland works great on a phone though :)19:27
persiarjek: You can't do 3D sensibly: you need to have two paths, and hardcode info about your GL implementation separately from where you hardcode your video server configuration, and hope they match.  Iff you can find a rooted X implementation (rootless X doesn't actually solve the problem).19:27
* rjek is really pleased with X's multihead support now. It used to be an utter ballache and I would have begged for something different.19:27
rjekpersia: 3D is not really a problem I have :)19:27
rjekWhat's missing from X still, AFAICT, is the ability to have GPUs come and go.19:28
rjek(Handy for dual-GPU systems, and USB-attached displays)19:28
persiarjek: It would be if you used kwin, clutter, or cinnamon.  It will be so if you want to use modern "GNOME", "KDE", or "XFCE"19:28
persiaX has that, it's the GL-side that is broken.  Wayland fixes this (and X can't in X11: needs X12, and nobody was willing to talk about that).19:28
persiaNote that X display driver hotplug is currently broken for USB- and 1394- connected displays for other annoying X11 reasons (which also need X12).19:29
persia(Annoyingly, PCI/PCIe/TB hotplug seems to work, but spawns a separate X server, which can be just as annoying for users)19:30
persiaNote that X does work for the special case of two coldplug GPUs, both of which can use mesa, as long as you have a special wrapper GL library, and some userspace magic to handle environment variables being made available to launching processes (although unfortunately you can't switch which GPU a process runs on without restarting the process).19:32
* persia stops ranting about historical X issues, and gladly welcomes the new world, only wishing someone would implement anything that made it more useful than a Windows XP clone19:33
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]19:34
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock19:35
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]19:35
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock19:35
persiaradiofree: Reading more on the subject (search engine still not helping): *how* does this weston patch support remote rendering?  Wayland can't do it (on purpose), which makes me wonder which communications and rendering APIs were used in the patches you mention.19:37
radiofreepersia: http://www.youtube.com/watch?feature=player_detailpage&v=L8zwnqKysfI#t=432519:45
persiaradiofree: Thanks.19:55
persiaOh, ugh.  That's not pretty at all.  I'd almost rather run a rootless X server as a Weston client, or a VNC/RDP weston client.20:02
persiaThe entire benefit of X network transparency is *supposed* to be that the X server does the draws based on network primitives (which is why client-side decoration is annoying).20:03
persiaNote that the window sharing feature is somewhat nifty, although it reintroduces most of the X security problems, without introducing Xhost guarding.20:04
radiofreewell i quite like how it just sends the damage over tcp/ip20:05
radiofreebut anyway i need to eat dinner, whilst trying to test this jetson image20:05
persiaThat's the same as VNC/RDP, but without the optimisation20:05
persiaEnjoy your meal20:06
radiofreeit'll be quicker for me to build the image i want to test on this board rather than transfer it via access20:06
radiofreeis rsync slower than scp?20:06
persiaDepends on the network and content.20:06
radiofreeoh wait20:07
radiofreei'll compress it on the board20:07
* radiofree slaps head20:07
persiaMost folk rsync over ssh tunnels, for which rsync can be faster if compression helps, and they should be about the same if rsync isn't compressing.20:07
persiaIf you're working locally, and you trust your local network, rsync over an unencrypted link, uncompressed is generally fastest (but remember to close your ports when you are done).20:08
radiofreewell i'm sure it's going to be faster to transfer ~500M than 4G20:08
persiaNot necessarily.  If you compress it in a way that is storage optimised, that might not be transport-optimised.  rsync with native compression is generally faster than rsync of storage-optimised compressed data.20:09
persiaAnd if you're using an ssh tunnel to transport any compressed data, be sure to turn off ssh compression, because it tries to recompress everything, which usually makes the transfer slower if you have a link speed higher than 19.2k20:10
radiofreeoh yeah i always forget about that, is it on by default though?20:10
persiaDepends on the build, and shipping config.  In most distros, both rsync and ssh are uncompressed by default, but lots of guides on using the tools provide config snippets that turn it on.20:11
radiofreesometimes these tools are "too clever for their own good"20:12
persiaMy quibble with that sentence is your use of "sometimes", as that implies there are tools that are not overly clever in the toolbox20:12
radiofreewell there are, but that's not what i meant. For example ssh compression is great by default when you want to use it, but when it causes you problems it's "too clever for it's own good"20:13
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]20:38
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock20:38
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]20:50
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock20:50
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host]20:50
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock20:50
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]21:07
radiofreehmm failed to boot, i had a theory as to way though, hopefully it's not true21:20
radiofrees/had/have 21:20
radiofreereflashing21:20
radiofreeerg21:31
radiofreeit's because i deployed with     FSTAB_SRC: LABEL=src /src auto defaults,rw,noatime 0 221:32
radiofreeand didn't have a drive connected with the source src21:32
radiofreenot a baserock issue btw21:32
radiofreewhy can't it just continue past that? (i know if i had a serial cable it would have asked me to Ctrl+D past it)21:33
robtaylorsystemd21:57
persiaDoes it need "... 0 0" to just skip it, or does it no longer honor those flags?22:04
juergbiiirc, it needs nofail (or noauto)22:06
radiofreejuergbi: thanks22:14
radiofreemainline jetson development image - http://seriousinternetbusiness.com/james/baserock/jetson-devel.img.gz + mainline (ish) u-boot  http://seriousinternetbusiness.com/james/baserock/u-boot.img22:55
radiofreei'll post the details of that to the ml tomorrow22:55
radiofree(replace Linux_for_Tegra/baserock/u-boot.bin with that u-boot, extact jetson-devel.img.gz to somewhere and use baserock-jetson-flash to flash that image)22:56
radiofrees/mainline/upstream22:57
persiaCool!23:00
jjardonradiofree: thats expected. libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies23:18
jjardon(thats why walyand use GLES2 for now)23:19
jjardonrjek: clutter is not a toolkit on top of GTK+, but a completely independent one23:20
jjardonand about client side decorations, you can disagree with the decission to include them, but csd was pushed in GTK+ by Wayland author, Kristian Høgsberg (after being rejected previously)23:27
jjardonradiofree: no neeed to purge X from baserock "examples", you can build wayland-only systems now ;)23:34
jjardonFor anyone interesed in Wayland and X, I highly recommend this talk by ont of the main X/Wayland devs: https://www.youtube.com/watch?v=RIctzAQOe4423:36
jjardonpersia: ok, so you are against conditional inclusion: can you tell me how to solve this use case: "only build llvm if Im building llvmpipe driveer in mesa" you can not resolve that fragmenting the strata more (mesa-common and llvm-common are already a 1-chunk strata)23:41
persiaWhat is the use case for wanting to do that?23:42
persiaIf it is the case that there exist two distinct classes of system, some of which should have llvm+mesa(llvmpipe), and others that should have !llvm+mesa(!llvmpipe), then the solution is two have two different definitions branches.23:43
persiaIf it is something else, I need to think about it more (and maybe I'll be convinced), but I need to understand the data point as a source for thought.23:44
jjardonpersia: currently we are building llvm in arm systems (and it takes quite a while to build) for nothing as we do not use llvmpipe in ARM23:45
jjardonpersia: check strata/mesa-common.morph23:45
persiaSo there are two distinct classes of system?23:45
jjardonwe cant conditionally set the llvm dependency23:46
jjardonpersia: we are supporting x86 and ARM with the sama set of definitions, if thats what you mean23:46
persiaTo be clear, I am increasingly of the opinion that the reference systems are interesting examples, but that if the goal is to produce a set of tools that allow organisations to easily create definitions, it would make it easier to understand user problems if there were multiple definitions branches, so there is a motivation for doing it that way, even if this specific ARM/llvm thing isn't the point of separation.23:48
persiaSo I think it's actively against our interest to try to have a single definitions branch that supports all targets.23:48
persiaWith that said, is it likely the case that users all always want llvmpipe on !ARM and !llvmpipe on ARM?23:49
persiaAlso, I thought there was further support for some MIPS variants and POWER, rather than just being ARM+x8623:50
jjardonpersia: as you said, thats a specific use case for a general problem. Dont stick with the example23:50
jjardonso you are suggesting to have different branches that would be almost identical but for a difference of one line in one strata definittion?23:51
persiaThen I ask again: do you imagine using this conditional facility to have a single set of definitions that support different classes of systems?23:51
jjardonpersia: yeah23:52
persiaI'd rather two nearly parallel branches to conditionals, yes.  This more closely maps to the sorts of minor variations our initial users will have from our reference definitions, so will expose a large class of usability issues related to coordination between branches.23:52
persiaIf you're comfortable with this being a distinguishing feature of classes, then let's do it with branches, rather than conditionals.23:52
persiaA large part of my concern is that if we tangle definitions too much, it becomes very hard to derive therefrom.23:53
jjardonso every time you upgrade, lets say, glibc; you have to update the ref in several branches? that would be a maintenaince mess23:53
persiaLast week I spoke to a lot of users of other build systems, who generally were well behind upstream (because they couldn't figure out how to merge sanely), and were unhappy with the level of metaprogramming and complexity that had entered into their build description notation.23:53
persiajjardon: You've identified the first issue: we need tooling that can help coordinate changes between definitions branches.23:54
persiagit does most of this for us, but we need to think about how it makes sense to do that.23:54
persiaNote that this problem exists for every single Baserock user, so not having the problem within the project doesn't mean that we don't have to solve it with significant priority.23:55
jjardonpersia: you assume it will make the system more complex, I disagree: jhbuild implements this in a IMHO nice way: https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.16.modules#n31823:56
persiaEven if it doesn't make it more complex, unless we expose ourselves to the many-definitions-branches problem, nobody can usefully derive anything, which significantly weakens the baserock story.23:56
jjardonwith conditions like that we support linux and *bsd with the same set of definitions23:57
persiaAnd given that I heard lots of complaints about notation complexity, I want to start from the position that there is no logic in the definitions, because once there is *any* logic, it's hard to draw another sane line.23:57
persiaNote that I've mostly been thinking from the viewpoint of an enduser building systems.  From an upstream perspective, only building systems for validation, testing, etc., I can see the advantages of the logic.23:59
persiaI still want multiple branches, and I still think logic in definitions should be avoided, but I agree that it is interesting to make it easy to build upstream sources against a variety of targets.23:59

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