IRC logs for #baserock for Monday, 2015-02-09

*** lachlanmackenzie has joined #baserock00:14
*** lachlanmackenzie has quit IRC00:54
*** mike has joined #baserock07:17
*** mike is now known as Guest237707:17
*** rdale has joined #baserock08:32
*** mariaderidder has joined #baserock08:46
*** bashrc has joined #baserock09:02
*** franred has quit IRC09:03
*** mariaderidder has quit IRC09:06
*** mariaderidder has joined #baserock09:08
*** grahamfinney has joined #baserock09:12
*** franred has joined #baserock09:15
*** grahamfinney has quit IRC09:17
*** sambishop has joined #baserock09:22
*** jonathanmaw has joined #baserock09:25
*** edcragg has joined #baserock09:29
*** grahamfinney has joined #baserock09:31
*** tiagogomes_ has joined #baserock09:39
*** gary_perkins has joined #baserock09:46
*** CTtpollard has joined #baserock09:49
jjardonrobtaylor: 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 project10:02
*** ssam2 has joined #baserock10:08
*** ChanServ sets mode: +v ssam210:08
*** Krin has joined #baserock10:12
robtaylorjjardon: yeah, i thought so too, butit made a difference10:15
richard_mawpaulsherwood: 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_mawAlso upstream recommends against putting symlinks in to autostart services at build time, since it's harder to override them at runtime.10:24
richard_mawInstalling 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
persiaTo be fair, upstream assumes a model where a single image is used to instantiate a wide variety of systems.10:25
persiaI'm not sure they've considered the case of having single-purpose images be default10:25
richard_mawFor 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 presets10:26
*** mauricemoss_ has joined #baserock10:30
richard_mawpersia: 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 default10:31
persiaEntirely.  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
persiaBut 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 #baserock10:35
richard_mawIt'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 IRC10:52
*** inara has quit IRC11:01
*** inara has joined #baserock11:03
persiaI 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
persiaSo 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
persiaThis 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
paulsherwoodi 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
persiaAnd 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
persiapaulsherwood: 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
persiaHowever, 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
paulsherwoodthat would be lovely. and if i understood the issues well enough to write it, i would :)11:17
*** ssam2 has joined #baserock11:28
*** ChanServ sets mode: +v ssam211:28
jjardonpedroalvarez: do you plant to merge your systemd v218 soon?11:34
*** grahamfinney has quit IRC12:02
*** edcragg has quit IRC12:07
*** edcragg has joined #baserock12:09
ssam2paulsherwood: thanks for organising http://wiki.baserock.org/guides/, it was a horrible mess before12:16
Zara+112:17
paulsherwoodssam2, Zara yw :-)12:37
* paulsherwood mainly did it for himself, or course, to keep himself away from more pressing matters :-)12:38
jjardonssam2: 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/enabilegos12:40
pedroalvarezjjardon: yes, I will12:42
ssam2it's fine, but it means that once a branch is force-pushed to, that ref will no longer get updated ever by lorry12:42
ssam2so lots of branches in the mirror at git.baserock.org will become out of date12:42
ssam2but unless someone force-pushes to master, master will be up to date always12:42
ssam2there was talk in GNOME recently of having a naming policy for personal branches, but I can't find it now12:44
jjardonyeah, basically wip/jjardon/feature12:45
ssam2but 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
ssam2so I think that's the best solution12:45
* paulsherwood likes the wip* idea12:46
jjardonssam2: ok, will send the patch to the list12:55
ssam2maybe wip/* instead of wip*12:55
ssam2but cool, please resent12:55
ssam2resend12:55
ssam2don't resent :)12:55
*** grahamfinney has joined #baserock12:56
*** lachlanmackenzie has quit IRC13:00
*** lachlanmackenzie has joined #baserock13:02
*** gary_perkins has quit IRC13:33
*** gary_perkins has joined #baserock13:41
*** lachlanmackenzie has quit IRC14:21
*** lachlanmackenzie has joined #baserock14:24
*** lachlanmackenzie has quit IRC14:42
*** lachlanmackenzie has joined #baserock14:42
edcraggdoes 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
robtayloredcragg: systemd14:50
richard_mawedcragg: the second interface is given a path-based name, so it's stable14:50
robtayloredcragg: things aren't called things like 'eth1' nowadays14:50
robtaylorwhat richard_maw said =)14:50
richard_mawI 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_mawunfortunately google searches for why systemd isn't renaming an interface are swamped by results for why it is renaming an interface14:54
tiagogomes_:)14:54
persiaMy 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
edcraggok, thanks14:57
pedroalvarezedcragg:  does the file /etc/systemd/network/10-dhcp.network have "Name=en*" inside?14:59
edcraggpedroalvarez: it has 'Name=e*'15:00
radiofreei suppose that was changed to match both eth* and en*15:01
pedroalvarezedcragg: 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 up15:05
persiaGenerally 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
persiaThe 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
edcraggpedroalvarez, persia: the interfaces are connectected to separate VLANs, and both interfaces receive DHCP correctly running Ubuntu15:07
persiaRight, so separate networks, which is a good thing.15:08
persiaSo 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 IRC15:12
*** lachlanmackenzie has joined #baserock15:15
*** zoli__ has joined #baserock15:24
*** dabukalam has quit IRC15:27
ssam2perryl. r.e. copyright years, '2012, 2014-2015' does imply copyright was not asserted in 201315:39
ssam2as '2012, 2015' implies it was only asserted in 2012 and 201515:39
rjekIt implements that no new material work was performed in 201315:40
perrylahhh15:40
rjekAnd thus that parts are copyright 2012, others 2014 and 2015.15:40
rjeks/implements/implies/15:40
rjekMy typing's awful today15:40
perrylrjek: that makes sense15:40
pedroalvarezurgh.. 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 IP15:42
ssam2weird, I was just looking at that exact part of the code15:43
ssam2we 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 workers15:50
ssam2using http chunked encoding I guess15:50
ssam2and (2) secure it15:50
pedroalvarezso 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 sense15:50
*** mdunford has quit IRC15:57
*** mdunford has joined #baserock15:58
persiaWhile I like push, it does mean that credentials to store artifacts exist outside the artifact cache server, so anyone can push.16:01
pedroalvarezdo we want anyone pushing there?16:01
persiaThat 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
persiapedroalvarez: I think we only want authorised workers to be able to push cache artifacts.16:02
pedroalvareznote that my knowledge about this is limited, but cannot the authorised workers push the artifacts using rsync (ssh)?16:04
pedroalvarezI mean, the cache-server  has to have the public sshkeys of every authorised worker, etc16:05
persiaI'd probably use a higher-level API.16:05
persiaBut sure, that works.16:05
persiaThe 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 push16:05
pedroalvarezI was also thinking that with a push approach we could host workers somewhere else no public accesible16:07
persiaThat'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 IRC16:12
*** jjardon has joined #baserock16:14
*** zoli__ has quit IRC16:28
franreddid someone merge "Reorganise python packages" patch serires?16:40
franredstraycat, ^^16:41
straycatseriresly?16:42
franred:D - well you have a "serious" +216:42
straycatnot from what i saw on the list16:42
straycatahh cool, will merge it in a bit then16:43
franredthanks straycat16:43
paulsherwoodstraycat, you're one of the folk i'm interested to ask, are you +1, -1 or ambivalent for gerrit here?16:44
straycatI'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
persiagerrit doesn't have "pull requests", rather "review requests", but similar.16:48
paulsherwoodwell i've +1 on the list. needs one more +1 and no detractors, then gerrit becomes law? :)16:51
persiaErm.16:55
persiaAfter review, I think it becomes "policy", and is subject to change at the same level of +1s.16:56
persiaI don't think we yet have precedent of nonconsensual policy such that we have a mechansim to control this more firmly.16:57
franredI 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
persiaI'm a fan of lots-of-separate-lorry-files because it is easier for me to see what is lorried that way.17:01
persiaI'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
persiaI've also read the argument for organise-lorries-by-project as being about fitting the output of `ls` in an 80x25 buffer.17:02
persiaI'm probably not defending those arguments as well as someone else would, as I'm unconvinced :)17:03
franredI 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 tidiness17:06
franredin any case, I will send the patch with the repos in their own lorry file17:10
*** ridgerunner has joined #baserock17:27
ridgerunnerI'm trying to follow the instructions at http://wiki.baserock.org/How_to_install_a_big-endian_Linux_system_to_NVIDIA_Jetson_TK1/?updated17:27
ridgerunnerI've had to update my compiler to make the build work so it, I'll add a note to it about that.17:27
ridgerunnerbut my problem now is that what is happening doesn't correspond to the instructions.17:27
ridgerunneror the instructions are not clear.17:27
ridgerunnerit 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
ridgerunnerbut nothing appears under /media.17:28
ridgerunnerAs 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
ridgerunnerThere's only one screen and keyboard but the results depend upon which particular terminal happens to have the focus.17:28
bashrcridgerunner: what distro are you using?17:28
ridgerunnerFor what?17:29
bashrcwhen looking for /media17:29
ridgerunnerMy PC is running Debian Jessie17:29
bashrcok. I know on jessie things don't necessarily get automounted under medua/user17:30
bashrcridgerunner: have you got serial and USB cables to the Jetson?17:30
ridgerunnerYes, both. And I have a serial screen open in a terminal.17:31
bashrcsounds ok17:31
ridgerunnerIf it's any use, I also have an ethernet link to it as well.17:32
radiofreehmm i would have appreciated some credit on patch 3 there, since it's just my patch cleaned up17:33
radiofreealso, why copy the kernel twice?17:33
radiofreeridgerunner: you have to type `ums 0 mmc 0` before the device shows up, the wiki isn't clear about that17:37
radiofree(on the u-boot console)17:37
*** mariaderidder has quit IRC17:38
ridgerunnerI tried that, it gave me: Unknown command 'ums' - try 'help'17:39
radiofreeyou need to flash a more recent version of u-boot then17:40
ridgerunnerU-Boot is dated Jul 30 2014 - 14:00:1417:40
radiofreei didn't need to know that, the lack of a ums command tells me it needs reflashing17:41
radiofreeit's relatively quick and painless though https://github.com/NVIDIA/tegra-uboot-flasher-scripts17:41
*** tiagogomes_ has quit IRC17:42
ridgerunnerok. Trying that, thank you.17:43
radiofreethere's a build-tools script in there that will take care of the dependencies17:43
radiofreethen use the ./build script to do the rest, can't remember off the top of my head what the command is for that17:44
*** jonathanmaw has quit IRC17:46
jjardonHey! 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 already17:48
radiofreeok17:49
*** grahamfinney_ has joined #baserock17:51
radiofreejjardon: the genivi branch of weston doesn't compile with libinput 0.9.0 when you do --enable-libinput-backend17:52
radiofreehowever, we don't do that, so +117:53
jjardonradiofree: great, thanks!17:53
ridgerunnerradiofree: ./build-tools fails with17:53
ridgerunnerOSError: [Errno 2] No such file or directory: '/home/robjones/develop/uboot/tegrarcm'17:53
*** sambishop has quit IRC17:53
radiofreeridgerunner: try building all the stuff manually then, it's in the NVIDIA repo17:54
*** bashrc has quit IRC17:54
radiofreeridgerunner: http://git.baserock.org/cgi-bin/cgit.cgi/?q=nvidia all of that17:54
*** grahamfinney has quit IRC17:55
ridgerunnerSorry, I'm not sure what you mean by that.17:57
radiofreeyou need to build all of those repos17:58
radiofreecbootimage-configs, cbootimage, tegrarcm17:58
radiofreeyou can ignore pinmux-scripts, and you already have uboot-flasher-scripts17:58
*** grahamfinney_ has quit IRC18:01
*** Guest2377 has quit IRC18:03
*** lachlanmackenzie has quit IRC18:11
*** mdunford has quit IRC18:15
*** gary_perkins has quit IRC18:20
*** rdale_ has joined #baserock19:04
*** rdale has quit IRC19:06
*** lachlanmackenzie has joined #baserock19:08
*** ssam2 has quit IRC19:09
*** lachlanmackenzie has quit IRC19:36
*** rdale has joined #baserock19:47
*** rdale_ has quit IRC19:47
*** rdale has quit IRC19:51
*** rdale has joined #baserock19:54
*** rdale_ has joined #baserock19:58
*** rdale__ has joined #baserock19:59
*** rdale has quit IRC20:01
*** rdale_ has quit IRC20:02
*** rdale has joined #baserock20:04
*** rdale_ has joined #baserock20:05
*** rdale__ has quit IRC20:07
*** rdale has quit IRC20:09
*** rdale has joined #baserock20:19
*** rdale_ has quit IRC20:19
*** rdale_ has joined #baserock20:52
*** rdale has quit IRC20:55
*** rdale has joined #baserock21:02
*** rdale_ has quit IRC21: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 #baserock21:04
*** rdale has quit IRC21:04
jjardonpersia: I guess that will be added in service systems only21:07
persiaThat'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 look21:11
*** rdale_ has quit IRC21:30
*** rdale has joined #baserock21:34
persiaTo be clear, I'm not against that patch, just surprised that this is the first target for fail2ban.21:35
*** rdale_ has joined #baserock21:37
jjardonpersia: I am ;)21:37
persiaAh.  Well I'm not especially for the patch either :)21:39
*** rdale has quit IRC21:40
*** rdale_ has quit IRC21:41
pedroalvarezI'd like to have it in trove, and maybe in build systems given that we use them for distbuild...22:44
pedroalvarezIn other systems too (some from infrastructure.git)22:45
pedroalvarezSo yes, almost everywhere, but maybe is only me, because I'm thinking from the baserock-public-infra point of view22:46
pedroalvarezAnyway, I came here just to say that Mason is red because the latest upgrade of libinput /cc jjardon22:48
persiapedroalvarez: 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/distbuild22:49
*** jjardon has quit IRC23:06
*** jjardon has joined #baserock23:28

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