| *** lachlanmackenzie has joined #baserock | 00:14 | |
| *** lachlanmackenzie has quit IRC | 00:54 | |
| *** mike has joined #baserock | 07:17 | |
| *** mike is now known as Guest2377 | 07:17 | |
| *** rdale has joined #baserock | 08:32 | |
| *** mariaderidder has joined #baserock | 08:46 | |
| *** bashrc has joined #baserock | 09:02 | |
| *** franred has quit IRC | 09:03 | |
| *** mariaderidder has quit IRC | 09:06 | |
| *** mariaderidder has joined #baserock | 09:08 | |
| *** grahamfinney has joined #baserock | 09:12 | |
| *** franred has joined #baserock | 09:15 | |
| *** grahamfinney has quit IRC | 09:17 | |
| *** sambishop has joined #baserock | 09:22 | |
| *** jonathanmaw has joined #baserock | 09:25 | |
| *** edcragg has joined #baserock | 09:29 | |
| *** grahamfinney has joined #baserock | 09:31 | |
| *** tiagogomes_ has joined #baserock | 09:39 | |
| *** gary_perkins has joined #baserock | 09:46 | |
| *** CTtpollard has joined #baserock | 09:49 | |
| jjardon | robtaylor: by dolt you mean the libtool replacement? I though most of the benefits were merged in libtool and there were no more activity on that project | 10:02 |
|---|---|---|
| *** ssam2 has joined #baserock | 10:08 | |
| *** ChanServ sets mode: +v ssam2 | 10:08 | |
| *** Krin has joined #baserock | 10:12 | |
| robtaylor | jjardon: yeah, i thought so too, butit made a difference | 10:15 |
| richard_maw | paulsherwood: we can put systemd units in at build time or configure time. Build time is either in-lined into the morphology or provided by the chunk. I'm not a fan of putting units in at configure time, and am unsure whether we should be putting units in /etc instead if they're configuration. | 10:23 |
| richard_maw | Also upstream recommends against putting symlinks in to autostart services at build time, since it's harder to override them at runtime. | 10:24 |
| richard_maw | Installing symlinks at build-time is supposed to only be for core services that it doesn't make sense to make their start configurable. | 10:25 |
| persia | To be fair, upstream assumes a model where a single image is used to instantiate a wide variety of systems. | 10:25 |
| persia | I'm not sure they've considered the case of having single-purpose images be default | 10:25 |
| richard_maw | For everything else systemd recommends prestart files, probably because in a package-based world, it makes it easier to do distro respins by having distros ship a package with presets | 10:26 |
| *** mauricemoss_ has joined #baserock | 10:30 | |
| richard_maw | persia: yeah, it means we don't need to care about the symlinks vs preset files option, but it may make sense to split service enablement from chunks that provide the service so we don't need to rebuild chunks if all we change is whether the services are enabled by default | 10:31 |
| persia | Entirely. I'm a big fan of separate foo-config chunks, so that one doesn't need to rebuild binaries to change config during development. | 10:32 |
| persia | But I'd much rather do that in chunks, rather than at configure time, because otherwise there's too much uncertainty as to whether a given system is the same when deployed in different environments (e.g. to a VM vs. to hardware). | 10:33 |
| *** lachlanmackenzie has joined #baserock | 10:35 | |
| richard_maw | It's currently an open question how presets interact with local configuration on the systemd mailing list, since they work by installing the symlinks to /etc on first-boot. There's call for a way to re-run the installation of presets on update, as new services may want to be enabled by default, or no longer enabled by default. I think we don't need to care too much about that if we're including symlinks though. | 10:40 |
| *** ssam2 has quit IRC | 10:52 | |
| *** inara has quit IRC | 11:01 | |
| *** inara has joined #baserock | 11:03 | |
| persia | I think the right way to solve it upstream is to have some sort of update-systemd tool that will consume information from some configuration location, and apply it to a system-specific configuration. | 11:11 |
| persia | So we could have service chunks in component repos related to the service, and drop them in a safe place, and then apply the specific configuration later. | 11:12 |
| persia | This model should work for packages (which run update-systemd in a post-install script), or image-based (which run update-systemd in configuration). | 11:12 |
| paulsherwood | i guess in my role as uninformed user i just want clear instructions on how to do this kind of thing, on the wiki? | 11:13 |
| paulsherwood | (both for systemd and in general) | 11:13 |
| persia | And for image-based, the safe way is to drop the configuration as a chunk, so that when update-systemd runs, it doesn't cause differences for different times. | 11:13 |
| persia | paulsherwood: Until upstream finishes the debate, it's hard. I believe the right answer is to have a generic service be provided by component upstream (making it a sensible chunk patch, because it is upstreamable), with config at a system level. | 11:14 |
| persia | However, it will take years for the debate to conclude, so it probably makes sense to have a menu of mechanisms on the baserock wiki, with some guidance on which one to select for a given state of upstream component and systemd. | 11:15 |
| paulsherwood | that would be lovely. and if i understood the issues well enough to write it, i would :) | 11:17 |
| *** ssam2 has joined #baserock | 11:28 | |
| *** ChanServ sets mode: +v ssam2 | 11:28 | |
| jjardon | pedroalvarez: do you plant to merge your systemd v218 soon? | 11:34 |
| *** grahamfinney has quit IRC | 12:02 | |
| *** edcragg has quit IRC | 12:07 | |
| *** edcragg has joined #baserock | 12:09 | |
| ssam2 | paulsherwood: thanks for organising http://wiki.baserock.org/guides/, it was a horrible mess before | 12:16 |
| Zara | +1 | 12:17 |
| paulsherwood | ssam2, Zara yw :-) | 12:37 |
| * paulsherwood mainly did it for himself, or course, to keep himself away from more pressing matters :-) | 12:38 | |
| jjardon | ssam2: Hi, the other day we were discussion about this but I do not remember if this patch to change the GTK lorry was ok or not in the end? http://paste.baserock.org/enabilegos | 12:40 |
| pedroalvarez | jjardon: yes, I will | 12:42 |
| ssam2 | it's fine, but it means that once a branch is force-pushed to, that ref will no longer get updated ever by lorry | 12:42 |
| ssam2 | so lots of branches in the mirror at git.baserock.org will become out of date | 12:42 |
| ssam2 | but unless someone force-pushes to master, master will be up to date always | 12:42 |
| ssam2 | there was talk in GNOME recently of having a naming policy for personal branches, but I can't find it now | 12:44 |
| jjardon | yeah, basically wip/jjardon/feature | 12:45 |
| ssam2 | but we could set e.g. "refspecs": ["+refs/heads/wip*", "refs/heads/*", "refs/tags/*"] to follow force pushes only on branches that begin with 'wip' | 12:45 |
| ssam2 | so I think that's the best solution | 12:45 |
| * paulsherwood likes the wip* idea | 12:46 | |
| jjardon | ssam2: ok, will send the patch to the list | 12:55 |
| ssam2 | maybe wip/* instead of wip* | 12:55 |
| ssam2 | but cool, please resent | 12:55 |
| ssam2 | resend | 12:55 |
| ssam2 | don't resent :) | 12:55 |
| *** grahamfinney has joined #baserock | 12:56 | |
| *** lachlanmackenzie has quit IRC | 13:00 | |
| *** lachlanmackenzie has joined #baserock | 13:02 | |
| *** gary_perkins has quit IRC | 13:33 | |
| *** gary_perkins has joined #baserock | 13:41 | |
| *** lachlanmackenzie has quit IRC | 14:21 | |
| *** lachlanmackenzie has joined #baserock | 14:24 | |
| *** lachlanmackenzie has quit IRC | 14:42 | |
| *** lachlanmackenzie has joined #baserock | 14:42 | |
| edcragg | does anyone know why the second network interface on a moonshot cartridge running Baserock would be registered as 'enp1s0d1' rather than eth1? (enp1s0d1 has no connectivity, where eth0 is configured and works correctly) | 14:48 |
| robtaylor | edcragg: systemd | 14:50 |
| richard_maw | edcragg: the second interface is given a path-based name, so it's stable | 14:50 |
| robtaylor | edcragg: things aren't called things like 'eth1' nowadays | 14:50 |
| robtaylor | what richard_maw said =) | 14:50 |
| richard_maw | I came across the reason why the first interface is still called eth0 recently, but I don't remember exactly what it is. | 14:50 |
| richard_maw | unfortunately google searches for why systemd isn't renaming an interface are swamped by results for why it is renaming an interface | 14:54 |
| tiagogomes_ | :) | 14:54 |
| persia | My memory is that there was a hack to cause the first interface to be *both* eth0 and something else, to deal with migration pain, because so much else assumed "eth0" had meaning. | 14:55 |
| * persia fondly remembers when tools assumed "le0" had meaning, and all broke for "ethN" | 14:56 | |
| edcragg | ok, thanks | 14:57 |
| pedroalvarez | edcragg: does the file /etc/systemd/network/10-dhcp.network have "Name=en*" inside? | 14:59 |
| edcragg | pedroalvarez: it has 'Name=e*' | 15:00 |
| radiofree | i suppose that was changed to match both eth* and en* | 15:01 |
| pedroalvarez | edcragg: then the only reason I can think of is that the interfaces are not connected to the same network. Check that with whoever set that up | 15:05 |
| persia | Generally speaking, if one has two interfaces, one doesn't want to connect them to the same segment (which may or may not be what is meant by "network" there). | 15:05 |
| persia | The exception is when one is bonding interfaces, but for servers, one typically only wants to do that when one has four or more interfaces, to avoid failure cases. | 15:06 |
| edcragg | pedroalvarez, persia: the interfaces are connectected to separate VLANs, and both interfaces receive DHCP correctly running Ubuntu | 15:07 |
| persia | Right, so separate networks, which is a good thing. | 15:08 |
| persia | So yeah, you just need your DHCP client to listen on both interfaces. Comparison to Ubuntu is hard, because most folk here don't use upstart or ifupdown to manage interfaces. | 15:08 |
| persia | (you could define such a system, but it is probably an easier path to assume separate logical networks and manage it that way) | 15:09 |
| *** lachlanmackenzie has quit IRC | 15:12 | |
| *** lachlanmackenzie has joined #baserock | 15:15 | |
| *** zoli__ has joined #baserock | 15:24 | |
| *** dabukalam has quit IRC | 15:27 | |
| ssam2 | perryl. r.e. copyright years, '2012, 2014-2015' does imply copyright was not asserted in 2013 | 15:39 |
| ssam2 | as '2012, 2015' implies it was only asserted in 2012 and 2015 | 15:39 |
| rjek | It implements that no new material work was performed in 2013 | 15:40 |
| perryl | ahhh | 15:40 |
| rjek | And thus that parts are copyright 2012, others 2014 and 2015. | 15:40 |
| rjek | s/implements/implies/ | 15:40 |
| rjek | My typing's awful today | 15:40 |
| perryl | rjek: that makes sense | 15:40 |
| pedroalvarez | urgh.. I think that the current imlementation of distbuild makes it impossible to deploy in an environment where the cache-server can't access to the wokrers by their internal IP | 15:42 |
| ssam2 | weird, I was just looking at that exact part of the code | 15:43 |
| ssam2 | we need to do two things: (1) make the distbuild 'push' artifacts to the remote artifact cache instead of having the remote artifact cache 'fetch' them from the workers | 15:50 |
| ssam2 | using http chunked encoding I guess | 15:50 |
| ssam2 | and (2) secure it | 15:50 |
| pedroalvarez | so the problem I'm facing is that when a worker asks the cache-server to fetch an artifact, it's telling to the cache-server to pull from its private IP.. that's why (1) makes sense | 15:50 |
| *** mdunford has quit IRC | 15:57 | |
| *** mdunford has joined #baserock | 15:58 | |
| persia | While I like push, it does mean that credentials to store artifacts exist outside the artifact cache server, so anyone can push. | 16:01 |
| pedroalvarez | do we want anyone pushing there? | 16:01 |
| persia | That said, unless the artifact cache server is already monitoring the worker, that possibility exists anyway, because a request to pull followed by a pull is indistinguishable from a push in terms of AAA. | 16:01 |
| persia | pedroalvarez: I think we only want authorised workers to be able to push cache artifacts. | 16:02 |
| pedroalvarez | note that my knowledge about this is limited, but cannot the authorised workers push the artifacts using rsync (ssh)? | 16:04 |
| pedroalvarez | I mean, the cache-server has to have the public sshkeys of every authorised worker, etc | 16:05 |
| persia | I'd probably use a higher-level API. | 16:05 |
| persia | But sure, that works. | 16:05 |
| persia | The key thing is that if you have an API that says "I'm. ${IDENTITY}, go get ${BLOB} from ${IP}", it isn't really that different from a push | 16:05 |
| pedroalvarez | I was also thinking that with a push approach we could host workers somewhere else no public accesible | 16:07 |
| persia | That's an interesting use case. Saves IPs for cloud environments. Allows silcon vendors to host clusters of pre-release hardware for testing, etc. | 16:07 |
| *** jjardon has quit IRC | 16:12 | |
| *** jjardon has joined #baserock | 16:14 | |
| *** zoli__ has quit IRC | 16:28 | |
| franred | did someone merge "Reorganise python packages" patch serires? | 16:40 |
| franred | straycat, ^^ | 16:41 |
| straycat | seriresly? | 16:42 |
| franred | :D - well you have a "serious" +2 | 16:42 |
| straycat | not from what i saw on the list | 16:42 |
| straycat | ahh cool, will merge it in a bit then | 16:43 |
| franred | thanks straycat | 16:43 |
| paulsherwood | straycat, you're one of the folk i'm interested to ask, are you +1, -1 or ambivalent for gerrit here? | 16:44 |
| straycat | I'm not really sure tbh, I haven't tried gerrit yet - it would be nice to have pull requests and automatic merging, automatic execution of tests etc though. | 16:47 |
| persia | gerrit doesn't have "pull requests", rather "review requests", but similar. | 16:48 |
| paulsherwood | well i've +1 on the list. needs one more +1 and no detractors, then gerrit becomes law? :) | 16:51 |
| persia | Erm. | 16:55 |
| persia | After review, I think it becomes "policy", and is subject to change at the same level of +1s. | 16:56 |
| persia | I don't think we yet have precedent of nonconsensual policy such that we have a mechansim to control this more firmly. | 16:57 |
| franred | I need to add lbmnl and ipset as a lorries, these are netfilter packages as ebtables and iptables. ebtables and iptables has their own lorry file, does make sense to create an netfilter-projects lorry and add all of them there? or I should just create 2 separate lorry files for libmnl and ipset? | 17:00 |
| persia | I'm a fan of lots-of-separate-lorry-files because it is easier for me to see what is lorried that way. | 17:01 |
| persia | I've read the argument for organise-lorries-by-project as being about the ability to support forks when two projects use the same tool, but with different versions. | 17:02 |
| persia | I've also read the argument for organise-lorries-by-project as being about fitting the output of `ls` in an 80x25 buffer. | 17:02 |
| persia | I'm probably not defending those arguments as well as someone else would, as I'm unconvinced :) | 17:03 |
| franred | I like to have the things organized rather than every repo in its own lorry file but I can not defend this because it is a personal opinion - just for tidiness | 17:06 |
| franred | in any case, I will send the patch with the repos in their own lorry file | 17:10 |
| *** ridgerunner has joined #baserock | 17:27 | |
| ridgerunner | I'm trying to follow the instructions at http://wiki.baserock.org/How_to_install_a_big-endian_Linux_system_to_NVIDIA_Jetson_TK1/?updated | 17:27 |
| ridgerunner | I've had to update my compiler to make the build work so it, I'll add a note to it about that. | 17:27 |
| ridgerunner | but my problem now is that what is happening doesn't correspond to the instructions. | 17:27 |
| ridgerunner | or the instructions are not clear. | 17:27 |
| ridgerunner | it says to "Press the reset button on the Jetson (the middle one of three), then hit any key to stop the boot. You will see a new drive become available and select it to mount it. It should then be visible under /media/$USER" | 17:28 |
| ridgerunner | but nothing appears under /media. | 17:28 |
| ridgerunner | As an aside, when you are dealing with two machines like thus, I suggest it be made clearer which particular machine you are talking about. | 17:28 |
| ridgerunner | There's only one screen and keyboard but the results depend upon which particular terminal happens to have the focus. | 17:28 |
| bashrc | ridgerunner: what distro are you using? | 17:28 |
| ridgerunner | For what? | 17:29 |
| bashrc | when looking for /media | 17:29 |
| ridgerunner | My PC is running Debian Jessie | 17:29 |
| bashrc | ok. I know on jessie things don't necessarily get automounted under medua/user | 17:30 |
| bashrc | ridgerunner: have you got serial and USB cables to the Jetson? | 17:30 |
| ridgerunner | Yes, both. And I have a serial screen open in a terminal. | 17:31 |
| bashrc | sounds ok | 17:31 |
| ridgerunner | If it's any use, I also have an ethernet link to it as well. | 17:32 |
| radiofree | hmm i would have appreciated some credit on patch 3 there, since it's just my patch cleaned up | 17:33 |
| radiofree | also, why copy the kernel twice? | 17:33 |
| radiofree | ridgerunner: you have to type `ums 0 mmc 0` before the device shows up, the wiki isn't clear about that | 17:37 |
| radiofree | (on the u-boot console) | 17:37 |
| *** mariaderidder has quit IRC | 17:38 | |
| ridgerunner | I tried that, it gave me: Unknown command 'ums' - try 'help' | 17:39 |
| radiofree | you need to flash a more recent version of u-boot then | 17:40 |
| ridgerunner | U-Boot is dated Jul 30 2014 - 14:00:14 | 17:40 |
| radiofree | i didn't need to know that, the lack of a ums command tells me it needs reflashing | 17:41 |
| radiofree | it's relatively quick and painless though https://github.com/NVIDIA/tegra-uboot-flasher-scripts | 17:41 |
| *** tiagogomes_ has quit IRC | 17:42 | |
| ridgerunner | ok. Trying that, thank you. | 17:43 |
| radiofree | there's a build-tools script in there that will take care of the dependencies | 17:43 |
| radiofree | then use the ./build script to do the rest, can't remember off the top of my head what the command is for that | 17:44 |
| *** jonathanmaw has quit IRC | 17:46 | |
| jjardon | Hey! can someone take a look to my patch to upgrade libinput? Some of the stuff Im working on is blocked on it and It has a +1 already | 17:48 |
| radiofree | ok | 17:49 |
| *** grahamfinney_ has joined #baserock | 17:51 | |
| radiofree | jjardon: the genivi branch of weston doesn't compile with libinput 0.9.0 when you do --enable-libinput-backend | 17:52 |
| radiofree | however, we don't do that, so +1 | 17:53 |
| jjardon | radiofree: great, thanks! | 17:53 |
| ridgerunner | radiofree: ./build-tools fails with | 17:53 |
| ridgerunner | OSError: [Errno 2] No such file or directory: '/home/robjones/develop/uboot/tegrarcm' | 17:53 |
| *** sambishop has quit IRC | 17:53 | |
| radiofree | ridgerunner: try building all the stuff manually then, it's in the NVIDIA repo | 17:54 |
| *** bashrc has quit IRC | 17:54 | |
| radiofree | ridgerunner: http://git.baserock.org/cgi-bin/cgit.cgi/?q=nvidia all of that | 17:54 |
| *** grahamfinney has quit IRC | 17:55 | |
| ridgerunner | Sorry, I'm not sure what you mean by that. | 17:57 |
| radiofree | you need to build all of those repos | 17:58 |
| radiofree | cbootimage-configs, cbootimage, tegrarcm | 17:58 |
| radiofree | you can ignore pinmux-scripts, and you already have uboot-flasher-scripts | 17:58 |
| *** grahamfinney_ has quit IRC | 18:01 | |
| *** Guest2377 has quit IRC | 18:03 | |
| *** lachlanmackenzie has quit IRC | 18:11 | |
| *** mdunford has quit IRC | 18:15 | |
| *** gary_perkins has quit IRC | 18:20 | |
| *** rdale_ has joined #baserock | 19:04 | |
| *** rdale has quit IRC | 19:06 | |
| *** lachlanmackenzie has joined #baserock | 19:08 | |
| *** ssam2 has quit IRC | 19:09 | |
| *** lachlanmackenzie has quit IRC | 19:36 | |
| *** rdale has joined #baserock | 19:47 | |
| *** rdale_ has quit IRC | 19:47 | |
| *** rdale has quit IRC | 19:51 | |
| *** rdale has joined #baserock | 19:54 | |
| *** rdale_ has joined #baserock | 19:58 | |
| *** rdale__ has joined #baserock | 19:59 | |
| *** rdale has quit IRC | 20:01 | |
| *** rdale_ has quit IRC | 20:02 | |
| *** rdale has joined #baserock | 20:04 | |
| *** rdale_ has joined #baserock | 20:05 | |
| *** rdale__ has quit IRC | 20:07 | |
| *** rdale has quit IRC | 20:09 | |
| *** rdale has joined #baserock | 20:19 | |
| *** rdale_ has quit IRC | 20:19 | |
| *** rdale_ has joined #baserock | 20:52 | |
| *** rdale has quit IRC | 20:55 | |
| *** rdale has joined #baserock | 21:02 | |
| *** rdale_ has quit IRC | 21:02 | |
| * persia is reading baserock-dev and vaguely wonders why anyone would want fail2ban on a development system (it makes *lots* of sense for service systems) | 21:02 | |
| *** rdale_ has joined #baserock | 21:04 | |
| *** rdale has quit IRC | 21:04 | |
| jjardon | persia: I guess that will be added in service systems only | 21:07 |
| persia | That's not the patch on the ML though. I see no proposals to add it to trove, etc., just the devel system (and just x86_64: the devel system most likely to be run under virtualisation) | 21:09 |
| * jjardon taking a look | 21:11 | |
| *** rdale_ has quit IRC | 21:30 | |
| *** rdale has joined #baserock | 21:34 | |
| persia | To be clear, I'm not against that patch, just surprised that this is the first target for fail2ban. | 21:35 |
| *** rdale_ has joined #baserock | 21:37 | |
| jjardon | persia: I am ;) | 21:37 |
| persia | Ah. Well I'm not especially for the patch either :) | 21:39 |
| *** rdale has quit IRC | 21:40 | |
| *** rdale_ has quit IRC | 21:41 | |
| pedroalvarez | I'd like to have it in trove, and maybe in build systems given that we use them for distbuild... | 22:44 |
| pedroalvarez | In other systems too (some from infrastructure.git) | 22:45 |
| pedroalvarez | So yes, almost everywhere, but maybe is only me, because I'm thinking from the baserock-public-infra point of view | 22:46 |
| pedroalvarez | Anyway, I came here just to say that Mason is red because the latest upgrade of libinput /cc jjardon | 22:48 |
| persia | pedroalvarez: I'd be delighted to see it in the infra systems: that's why I was surprised, because I thought the patch would be about adding it to trove/distbuild | 22:49 |
| *** jjardon has quit IRC | 23:06 | |
| *** jjardon has joined #baserock | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!