| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:30 | |
| *** franred [~franred@host-89-240-75-201.as13285.net] has joined #baserock | 07: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 | |
| radiofree | Is there any morph/bash too for "copy the cache for this system somewhere else"? | 09:06 |
|---|---|---|
| radiofree | S/too/foo | 09:06 |
| straycat | Nothing special really, it's just a directory with artifacts and git repos | 09:13 |
| radiofree | straycat: 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 |
| straycat | you could use morph list-artifacts to get a list of artifacts a system produces | 09:15 |
| radiofree | that sounds like what i want, thanks | 09: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 dependencies | 10:26 | |
| jjardon | Hi! Is there any work related to port the baserock code to Python3? | 10:40 |
| Kinnison | The main issue is the dependencies of morph | 10:41 |
| Kinnison | richard_maw has said that morph's codebase itself ought to be a mostly mechanical conversion to python3 | 10:41 |
| Kinnison | but that we depend on a number of libraries which are harder to port | 10:42 |
| * Kinnison gets on with his sunday | 10:42 | |
| straycat | ratmice_______, probably, and there's not much demand to add it | 10: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 |
| straycat | graphviz 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 |
| straycat | so we could add graphviz to baserock, i just didn't realise people would want it | 11:24 |
| straycat | odgf also looks pretty cool | 11: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 fetchining | 11:31 | |
| radiofree | does backrock cache arm builds on gbo now? | 11:32 |
| radiofree | apparently only up to cpython! | 11:33 |
| paulsherwood | only release builds | 11:33 |
| radiofree | ah, i'm building from master | 11:33 |
| paulsherwood | it's a niggle | 11:34 |
| paulsherwood | one of many | 11:34 |
| * paulsherwood is surprised to see node has been added to devel | 11:34 | |
| radiofree | what do you think I should be doing here, this is for Gavin McCall's request on the mailing list btw | 11:35 |
| radiofree | build from master, push the cache, build from release tag, not much to push | 11:35 |
| paulsherwood | whatever is least work for you :) | 11:36 |
| radiofree | they're both pretty easy, it's just two commits on top of a branch, i'll use the release tag though, should be faster | 11:36 |
| paulsherwood | ok. 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 |
| radiofree | it's already push | 11:40 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-unified-kernel | 11:40 |
| radiofree | and now http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-unified-kernel-14.40.1 | 11:41 |
| paulsherwood | ok thanks | 11:41 |
| radiofree | this contains a new kernel which i'm hoping we can use for both the devel and jetson systems | 11:42 |
| radiofree | so we can use the same version of u-boot on them | 11:42 |
| paulsherwood | cool | 11:42 |
| radiofree | ooh this is much better | 11:48 |
| paulsherwood | howso? | 11:50 |
| radiofree | cached! | 11:50 |
| *** De|ta_ [~arc@195.242.156.171] has joined #baserock | 12:53 | |
| *** ridgerun1er [~robjones@access.ducie-dc1.codethink.co.uk] has joined #baserock | 12: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 #baserock | 12:58 | |
| *** ratmice________ [bosshog@nightfall.forlorn.net] has joined #baserock | 13:32 | |
| *** pdar_ [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 13:32 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 13:34 | |
| radiofree | we should really benchmark this properly but 2014-10-26 14:57:37 [Build 141/145] [linux-jetson-tk1] Elapsed time 00:09:37 | 15:01 |
| radiofree | with the new kernel, seems... faster | 15:01 |
| paulsherwood | seems about right | 15:11 |
| paulsherwood | but yes, a little faster. maybe ccache is helping? | 15:12 |
| radiofree | interestingly the same kernel just took 2014-10-26 15:19:46 [Build 94/227] [linux-jetson-tk1-genivi] Elapsed time 00:15:28 | 15:19 |
| radiofree | ah | 15:20 |
| radiofree | the genivi one has 5 minutes of install commands! | 15:20 |
| radiofree | (installing kernel sources) | 15:20 |
| paulsherwood | whoa! :) | 15:22 |
| cyndis | ah, are you using the upstream kernel on all jetson builds? :) nice | 15:23 |
| cyndis | btw, you don't need the long kernel cmdline args when running on upstream | 15:23 |
| paulsherwood | really? | 15:23 |
| radiofree | cyndis: yes i noticed that | 15:23 |
| cyndis | good :) | 15:24 |
| radiofree | cyndis: the plan is to use an upstream kernel for our devel images, thanks to your cpufreq patches :) | 15:24 |
| radiofree | we're using upstream on our genivi images already | 15:25 |
| cyndis | well, i'm just maintaining them, but great :) | 15:25 |
| radiofree | jjardon: disable-glx is definitely causing libGL not to be built | 15:27 |
| radiofree | however the pkgconfig entries get installed | 15:27 |
| * paulsherwood has posted two new tutorial videos on wiki.baserock.org | 15:55 | |
| persia_ is now known as persia | 16:35 | |
| persia | Following backscroll: | 16:39 |
| persia | On 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 |
| persia | On 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 |
| persia | On 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 |
| persia | Branching 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 |
| straycat | A genivi branch doesn't seem like such a bad idea to me | 16:44 |
| persia | On 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 |
| straycat | eek | 16:45 |
| * straycat hides | 16:45 | |
| persia | straycat: 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 |
| persia | The interesting question then becomes whether there is one "definitions" project, or if there are several definitions projects, each reaching towards some need. | 16:46 |
| persia | If 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 |
| paulsherwood | persia: 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 |
| straycat | I 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 simple | 16:47 |
| * persia apologises for being scary, and hunts around for cream | 16:47 | |
| persia | paulsherwood: How so? It's in the definitions for the release. | 16:48 |
| straycat | persia, :) | 16:48 |
| persia | straycat: 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 |
| persia | s/yet have/despite/ | 16:51 |
| paulsherwood | persia: you're right. still more of a fiddle around than necessary imo, but i drop my point | 16:55 |
| persia | I usually just grep for the repo, but isn't there a manifest tool that is supposed to report that directly? | 16:55 |
| persia | If not, we ought do one, because it's a sensible thing to need to check. | 16:56 |
| persia | Mind you, for misbehaving upstreams without sensible release strategies (like morph), "version" doesn't mean very much. | 16:56 |
| paulsherwood | gah... you've reminded me i need to wade through at least a week's worth of 'freezing upstream tags for reproducibility' mails | 17:02 |
| paulsherwood | persia: did you read http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-October/008682.html | 17:03 |
| persia | Yes, but re-reading in case I missed an implication at the time. | 17:04 |
| persia | Right. I assert that the build system (morph) should care not one whit about any of this. | 17:05 |
| paulsherwood | agreed | 17:05 |
| persia | Also that the archive curation suite (lorry) should be tunable to give 1, 2a, or 2b, depending on the implementing organisation. | 17:05 |
| paulsherwood | agreed | 17:05 |
| persia | And I think the baserock project should use solely SHA1 refs for the definitions of systems used for baserock infrastructure. | 17:06 |
| persia | I'm less certain about the right answer for GENIVI systems. | 17:06 |
| persia | For 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 |
| persia | Other 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 |
| paulsherwood | in 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 |
| persia | Why? 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 |
| persia | Also, 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 |
| paulsherwood | because humans have to read them too, from time to time | 17:13 |
| persia | Yes, but not as much as automation, and it's more expensive for the automation than the human. | 17:13 |
| persia | Because 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 |
| paulsherwood | i'm not convinced, but ok | 17:14 |
| persia | WHich means that whatever info is stored, the user is unhappy until they are given tooling. | 17:14 |
| persia | I'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 |
| persia | If 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 |
| persia | Err s/for the use/for use/ | 17:16 |
| persia | (or maybe I wanted to add a "of humans in there") | 17:16 |
| paulsherwood | i thought you meant s/the use/the user/ :) | 17:16 |
| persia | That 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 all | 17:51 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:52 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 17:52 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:52 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:55 | |
| persia | Looking 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 it | 18: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 | |
| paulsherwood | heh | 18:11 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:24 | |
| radiofree | paulsherwood: if you're going to use baserock/james/jetson-unified-kernel-14.40.1 it does work | 19:16 |
| radiofree | you'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 |
| radiofree | took forever to copy it via access though (jetson on desk -> access was slooooooow) | 19:17 |
| rjek | Boo, it appears liballegro does not have a Wayland backend, only X | 19: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 |
| radiofree | RISC OS uses wayland? oO | 19:18 |
| rjek | radiofree: No! That's the problem :) | 19:18 |
| rjek | RPCEmu uses liballegro, which is like a nasty pustulent version of SDL. | 19:18 |
| rjek | And liballegro has no Wayland backend. | 19:19 |
| rjek | (RPCEmu being a RiscPC emulator with JIT) | 19:19 |
| radiofree | i wanted to purge X from baserock but i didn't think i was successful | 19:19 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:19 | |
| rjek | I would like to keep X in Baserock :) | 19:19 |
| radiofree | ^ debian user | 19:19 |
| radiofree | joke!! | 19:19 |
| robtaylor | rjek: ooi, how does its speed comapre to qemu? | 19:19 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:20 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:20 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:20 | |
| rjek | Wayland has been "ready in 6 months" for years now, and doesn't actually do what I want for a graphical stack :) | 19:20 |
| radiofree | well wayland is only the protocol, blame weston | 19:20 |
| rjek | robtaylor: The JIT? It's probably slower. But it can do 26 bit modes. | 19:20 |
| rjek | radiofree: Does the protocol allow for network transparency and centralised window management? | 19:20 |
| rjek | I was under the impression that it does not | 19:20 |
| persia | The protocol allows for centralised window management. | 19:21 |
| robtaylor | rjek: the protocol's inherently estensivle | 19:21 |
| persia | Network transparency is specifically excluded as a design goal | 19:21 |
| radiofree | there are patches for weston that support network transparency | 19:22 |
| robtaylor | rjek: the confusion is usally between specific implmengtations and the wayland protocol itself | 19:22 |
| persia | Really? | 19:22 |
| radiofree | persia: yes, i used that a year or so ago | 19:22 |
| rjek | robtaylor: I thought all the implementations were Weston or a fork of Weston :) | 19:22 |
| radiofree | rjek: see clutter | 19:22 |
| rjek | Why does modern GTK want to be the window manager? :( | 19:22 |
| robtaylor | rjek: nope,i coulnt at least 3, and that's without the commercial ones | 19:22 |
| rjek | radiofree: I thought clutter was a GL toolkit ontop of Gtk. Has that changed? | 19:22 |
| persia | radiofree: 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 |
| radiofree | because people have adopted the lack of the wayland spec saying "it's up to the compositor/window manager to handle decoration" | 19:23 |
| radiofree | and decided that means every app has to handle it | 19:23 |
| rjek | This makes me sad. | 19:23 |
| radiofree | which is ludicrous | 19:23 |
| persia | Every app? That's broken. | 19:23 |
| radiofree | persia: gtk does it at the toolkit level, so does qt | 19:23 |
| persia | The *window manager* and or the *compositor* should handle decoration, not the apps. | 19:23 |
| rjek | Gtk now even handles the windows under X. It's a travesty. | 19:23 |
| robtaylor | http://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/ | 19:23 |
| radiofree | persia: i aggree entirely | 19:23 |
| persia | radiofree: I know. It's easier to do cross-platform that way. It's still broken. | 19:24 |
| * persia hugs the ghost of Xerox | 19:24 | |
| rjek | persia: Modern Gtk handles the windows even under X :( | 19:24 |
| radiofree | Nothing 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 decorations | 19:24 |
| radiofree | from robtaylor's link | 19:24 |
| persia | rjek: 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 |
| radiofree | it's just for some reason everyone has decided to run with the "it's up to the app to deal with decoration" | 19:24 |
| robtaylor | kde does server side decorations on wayland | 19:24 |
| rjek | "decoration" belittles their purpose. I prefer "furniture" | 19:25 |
| radiofree | kde is also implementing using a weston plugin | 19:25 |
| rjek | If only because it's a nicer word :) | 19:25 |
| radiofree | rather than reimplement weston... | 19:25 |
| persia | radiofree: I thought the KDE solution was to back kwin with wayland directly (although I've not been following in some time) | 19:25 |
| robtaylor | the gtk guys wanted to to do client side for more flexible furniture. that could of course be done server side with a suitable protocol extension | 19:26 |
| rjek | OOI, 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 |
| robtaylor | but they wanted to start moving way before that could happen | 19:26 |
| radiofree | i suppose debian jessie has support for it via gnome 3.14? | 19:26 |
| rjek | radiofree: Something like that. | 19:26 |
| radiofree | in which case that's wayland/clutter | 19:26 |
| rjek | It's packaged and included, IIRC | 19:26 |
| robtaylor | rjek: you, probably not so many | 19:26 |
| radiofree | however it doesn't really work very well | 19:26 |
| radiofree | most things use xwayland | 19:26 |
| radiofree | wayland works great on a phone though :) | 19:27 |
| persia | rjek: 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 | |
| rjek | persia: 3D is not really a problem I have :) | 19:27 |
| rjek | What'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 |
| persia | rjek: 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 |
| persia | X 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 |
| persia | Note 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 |
| persia | Note 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 clone | 19:33 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:34 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:35 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:35 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:35 | |
| persia | radiofree: 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 |
| radiofree | persia: http://www.youtube.com/watch?feature=player_detailpage&v=L8zwnqKysfI#t=4325 | 19:45 |
| persia | radiofree: Thanks. | 19:55 |
| persia | Oh, 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 |
| persia | The 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 |
| persia | Note that the window sharing feature is somewhat nifty, although it reintroduces most of the X security problems, without introducing Xhost guarding. | 20:04 |
| radiofree | well i quite like how it just sends the damage over tcp/ip | 20:05 |
| radiofree | but anyway i need to eat dinner, whilst trying to test this jetson image | 20:05 |
| persia | That's the same as VNC/RDP, but without the optimisation | 20:05 |
| persia | Enjoy your meal | 20:06 |
| radiofree | it'll be quicker for me to build the image i want to test on this board rather than transfer it via access | 20:06 |
| radiofree | is rsync slower than scp? | 20:06 |
| persia | Depends on the network and content. | 20:06 |
| radiofree | oh wait | 20:07 |
| radiofree | i'll compress it on the board | 20:07 |
| * radiofree slaps head | 20:07 | |
| persia | Most 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 |
| persia | If 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 |
| radiofree | well i'm sure it's going to be faster to transfer ~500M than 4G | 20:08 |
| persia | Not 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 |
| persia | And 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.2k | 20:10 |
| radiofree | oh yeah i always forget about that, is it on by default though? | 20:10 |
| persia | Depends 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 |
| radiofree | sometimes these tools are "too clever for their own good" | 20:12 |
| persia | My quibble with that sentence is your use of "sometimes", as that implies there are tools that are not overly clever in the toolbox | 20:12 |
| radiofree | well 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 #baserock | 20:38 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:50 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:50 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:50 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:50 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:07 | |
| radiofree | hmm failed to boot, i had a theory as to way though, hopefully it's not true | 21:20 |
| radiofree | s/had/have | 21:20 |
| radiofree | reflashing | 21:20 |
| radiofree | erg | 21:31 |
| radiofree | it's because i deployed with FSTAB_SRC: LABEL=src /src auto defaults,rw,noatime 0 2 | 21:32 |
| radiofree | and didn't have a drive connected with the source src | 21:32 |
| radiofree | not a baserock issue btw | 21:32 |
| radiofree | why 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 |
| robtaylor | systemd | 21:57 |
| persia | Does it need "... 0 0" to just skip it, or does it no longer honor those flags? | 22:04 |
| juergbi | iirc, it needs nofail (or noauto) | 22:06 |
| radiofree | juergbi: thanks | 22:14 |
| radiofree | mainline jetson development image - http://seriousinternetbusiness.com/james/baserock/jetson-devel.img.gz + mainline (ish) u-boot http://seriousinternetbusiness.com/james/baserock/u-boot.img | 22:55 |
| radiofree | i'll post the details of that to the ml tomorrow | 22: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 |
| radiofree | s/mainline/upstream | 22:57 |
| persia | Cool! | 23:00 |
| jjardon | radiofree: thats expected. libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies | 23:18 |
| jjardon | (thats why walyand use GLES2 for now) | 23:19 |
| jjardon | rjek: clutter is not a toolkit on top of GTK+, but a completely independent one | 23:20 |
| jjardon | and 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 |
| jjardon | radiofree: no neeed to purge X from baserock "examples", you can build wayland-only systems now ;) | 23:34 |
| jjardon | For 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=RIctzAQOe44 | 23:36 |
| jjardon | persia: 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 |
| persia | What is the use case for wanting to do that? | 23:42 |
| persia | If 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 |
| persia | If 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 |
| jjardon | persia: 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 ARM | 23:45 |
| jjardon | persia: check strata/mesa-common.morph | 23:45 |
| persia | So there are two distinct classes of system? | 23:45 |
| jjardon | we cant conditionally set the llvm dependency | 23:46 |
| jjardon | persia: we are supporting x86 and ARM with the sama set of definitions, if thats what you mean | 23:46 |
| persia | To 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 |
| persia | So I think it's actively against our interest to try to have a single definitions branch that supports all targets. | 23:48 |
| persia | With that said, is it likely the case that users all always want llvmpipe on !ARM and !llvmpipe on ARM? | 23:49 |
| persia | Also, I thought there was further support for some MIPS variants and POWER, rather than just being ARM+x86 | 23:50 |
| jjardon | persia: as you said, thats a specific use case for a general problem. Dont stick with the example | 23:50 |
| jjardon | so 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 |
| persia | Then 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 |
| jjardon | persia: yeah | 23:52 |
| persia | I'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 |
| persia | If you're comfortable with this being a distinguishing feature of classes, then let's do it with branches, rather than conditionals. | 23:52 |
| persia | A large part of my concern is that if we tangle definitions too much, it becomes very hard to derive therefrom. | 23:53 |
| jjardon | so every time you upgrade, lets say, glibc; you have to update the ref in several branches? that would be a maintenaince mess | 23:53 |
| persia | Last 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 |
| persia | jjardon: You've identified the first issue: we need tooling that can help coordinate changes between definitions branches. | 23:54 |
| persia | git does most of this for us, but we need to think about how it makes sense to do that. | 23:54 |
| persia | Note 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 |
| jjardon | persia: 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#n318 | 23:56 |
| persia | Even 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 |
| jjardon | with conditions like that we support linux and *bsd with the same set of definitions | 23:57 |
| persia | And 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 |
| persia | Note 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 |
| persia | I 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.15.3 by Marius Gedminas - find it at mg.pov.lt!