| *** cosm [~Unknown@cspc154.cs.man.ac.uk] has quit [Ping timeout: 255 seconds] | 00:17 | |
| *** cosm [~Unknown@host-78-150-56-250.as13285.net] has joined #baserock | 00:35 | |
| *** petefoth [~petefoth@host-78-151-29-232.as13285.net] has joined #baserock | 07:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:25 | |
| SotK | paulsher1ood: I made the commits on the system I was testing Mason with and forgot to fix my git config, I can fix it and force push if its an issue | 08:15 |
|---|---|---|
| paulsher1ood | SotK: it would be an issue at the point of seeking reviews... so if these patches are expected to survive, probably yes, worth fixing sooner rather than later? | 08:16 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:17 | |
| SotK | I wasn't expecting these patches to survive until review :) | 08:19 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:22 | |
| pedroalvarez | jjardon: no worries, I just wanted to know how worried should I be :) | 08:29 |
| pedroalvarez | jjardon: btw, well done with systemd! | 08:30 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:37 | |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 08:39 | |
| paulsher1ood | SotK: np | 08:44 |
| jmacs | I want to make a change to ceph.configure which is in the root of git://git.baserock.org/baserock/baserock/definitions; do I need to use morph edit to do this, or is it something else now? | 08:47 |
| paulsher1ood | jmacs: you can just edit that file in your baserock/baserock/definitions branch | 08:48 |
| paulsher1ood | then run build/deploy | 08:49 |
| paulsher1ood | these days i tend to just work in a constant /src/workspace/mymachine/baserock/baserock/definitions checkout. | 08:49 |
| pedroalvarez | yes, easy like that, and not morph commands involved | 08:50 |
| jmacs | Sure, where would I push that change? I want to work in public | 08:50 |
| paulsher1ood | if you have push access to gbo... branch baserock/jmac/foo | 08:50 |
| paulsher1ood | otherwise, github? | 08:50 |
| paulsher1ood | or your favourite git host | 08:50 |
| jmacs | OK. | 08:53 |
| * paulsher1ood should write up the rest of his current 'workflow' | 08:56 | |
| jjardon | jmacs: I used to use Gitorious before I get gbo git access | 09:04 |
| radiofree | gitorious' uptime has been a bit dodgy lately | 09:06 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| jmacs | It's OK, I've finally remembered my github password | 09:07 |
| jmacs | Can you push a repository that doesn't already exist on github? | 09:16 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:17 | |
| straycat | SotK, *facepalm* | 09:34 |
| straycat | thanks for pointing that out, I'll sort the deploy commands out when I get a moment | 09:35 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:35 | |
| Mode #baserock +v ssam2 by ChanServ | 09:35 | |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 09:45 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:47 | |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 09:52 | |
| jmacs | Hmm, no, I can't seem to clone a baserock repo into github or push a new branch. Someone must have done baserock work on github before, right? | 09:57 |
| Kinnison | jmacs: There's no reason you couldn't push a brand new (to github) piece of content | 09:57 |
| Kinnison | jmacs: Have you created a repo to push it into? | 09:57 |
| jmacs | No; do you think it would help if I made a blank repo to overwrite? | 09:58 |
| Kinnison | Yes you have to make the repo | 09:58 |
| Kinnison | github hangs all its access control off the repo existing | 09:58 |
| Kinnison | just tell it you want a blank repo (i.e. without licence or readme) | 09:59 |
| Kinnison | and it should work | 09:59 |
| jmacs | It worked, thanks Kinnison | 10:00 |
| Kinnison | No probs | 10:01 |
| robtaylor | gitlab public rather than github though - keep it libre! | 10:01 |
| jmacs | Bit late for that | 10:02 |
| robtaylor | ah well | 10:08 |
| jmacs | I see your point, though. | 10:08 |
| * robtaylor is making a concerted effort himself on such things | 10:10 | |
| * Kinnison write his own F/LOSS git hosting solution first | 10:13 | |
| Kinnison | :-) | 10:13 |
| radiofree | paulsher1ood: how do i actually use a docker? | 10:13 |
| radiofree | a docker? docker? a docker container? | 10:13 |
| radiofree | i built a genivi image on a jetson, have installed docker stuff, want to see if i can run weston in the docker container | 10:14 |
| radiofree | is that something i'd want to do? | 10:14 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 10:15 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
| robtaylor | richard_maw: i think a more capable pivot_root would maybe look like pivot_namespace and pivot_cgroup | 10:16 |
| ssam2 | radiofree: I'm not sure how much use Docker is for graphical stuff | 10:17 |
| ssam2 | containers are intended to communicate through the host with sockets | 10:17 |
| ssam2 | although you can bind in device nodes and whatever if you want to get funky | 10:18 |
| ssam2 | but then I'm not sure it can /share/ the device with the host, it'd need to take over graphics completely | 10:19 |
| radiofree | ssam2: yeah i saw that, i saw some discussion on it being usable | 10:19 |
| radiofree | erm.. usable for CUDA at least | 10:19 |
| ssam2 | oh, cool | 10:19 |
| radiofree | i'm thinking i could share the drm device, then.. magic? | 10:19 |
| ssam2 | it's worth a try, anyway :) | 10:20 |
| ssam2 | I'd start with `docker run --device=/dev/drm:/drv/drm-host --interactive --tty --rm myimage /bin/bash` or something | 10:21 |
| radiofree | i see, how do i get to "myimage", is that just a folder? | 10:21 |
| ssam2 | that needs to be a docker image | 10:21 |
| richard_maw | robtaylor: the former pivots all processes in one namespace into another and the latter pivots all processes in a cgroup into another? | 10:22 |
| radiofree | ssam2: how would one go about turning a rootfs tarball into a docker image? | 10:22 |
| ssam2 | radiofree: you can import a tarball by doing: `cat system.tar | docker import - mynewimage` | 10:22 |
| radiofree | ooh | 10:22 |
| ssam2 | it should then show up in `docker images` | 10:22 |
| robtaylor | richard_maw: maybe more like moves a non root namespace to the root namespace, ditto chgroup | 10:22 |
| robtaylor | *cgroup | 10:22 |
| richard_maw | my brain hasn't sufficiently warmed up enough yet to be able to join that up with how to atomically migrate processes into a new version of their mount tree | 10:26 |
| franred | I want to add rebar and erlang-sd_notify to the Trove would be better if they are under erlang.lorry or do you want me to create a erlang-packages.lorry ? | 10:38 |
| franred | note: rebar is a erlang compiler | 10:39 |
| pedroalvarez | ah.. you mean you want to lorry new things | 10:42 |
| franred | pedroalvarez, yes | 10:43 |
| paulsher1ood | radiofree: you could try 'docker pull baserock/14.29' | 10:43 |
| paulsher1ood | https://registry.hub.docker.com/u/baserock/14.29/ | 10:43 |
| * paulsher1ood will push a 14.46 at some point | 10:43 | |
| * franred will lorry the erlang packages creating erlang-package.lorry file | 10:46 | |
| franred | s/package/packages/ | 10:46 |
| paulsher1ood | can/did we standardise naming for strata to contain 'foo and common things that use foo or are required by foo' ? | 10:49 |
| paulsher1ood | eg ruby-stuff, erlang-stuff, go-stuff etc? | 10:49 |
| franred | paulsher1ood, it is better to standarize for lenguage packages, because requirements could be a little bit mess | 10:54 |
| franred | for example this erlang packages that I want to lorry are for rabbitmq which is a python package which is required by openstack... but why could not be required for other package/s in the future? | 10:55 |
| paulsher1ood | franred: i'm not fully understanding you. but in any case, the word 'package' is not currently used in baserock i think, and we should continue to avoid it? | 10:56 |
| rdale | 'ruby environment'? | 10:58 |
| franred | paulsher1ood, it is not used in baserock but for refering to them we should continue use "python-packages" "erlang-packages" because their systems/users call them in that way and will be easy for us to find them | 10:58 |
| paulsher1ood | do others agree? i'm in disgreement with franred here i think | 10:58 |
| SotK | we currently have a python-packages.lorry file, so erlang-packages.lorry makes sense to me | 11:00 |
| richard_maw | packages have implications that I didn't fully understand until I needed to think about how to do online updates without them | 11:01 |
| * paulsher1ood surrenders to SotK's logic | 11:01 | |
| * richard_maw doesn't | 11:01 | |
| richard_maw | they should be python-modules IMO | 11:01 |
| paulsher1ood | works for me :) | 11:02 |
| rdale | SotK is talking about names of lorries though not names of strata, although maybe they are always supposed to be the same | 11:02 |
| franred | that is also my point rdale | 11:02 |
| * SotK agrees that we should *not* have a foo-packages stratum | 11:04 | |
| * franred renames erlang-packages.lorry to erlang-modules.lorry | 11:05 | |
| pedroalvarez | rdale: re qtwebengine-chromium. How big is it? | 11:05 |
| straycat | what's wrong with erlang-packages ? | 11:05 |
| straycat | we have python-packages | 11:05 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 11:06 | |
| rdale | does it have the python interpreter in it? | 11:06 |
| straycat | no that's in core | 11:06 |
| franred | From Erlang documentation: Erlang code is divided into modules - so I don't have any reason to continue called erlang-packages | 11:07 |
| straycat | okay | 11:08 |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:09 | |
| ssam2 | paulsher1ood: have you pushed ARM images to the Docker registry? if not, 'docker pull' will not be much help to radiofree | 11:09 |
| fay is now known as fay_ | 11:09 | |
| rdale | pedroalvarez: i've just checked out the qtwebengine-chromium git repo and it is 1.2G | 11:20 |
| paulsher1ood | jmacs: nice work on https://vimeo.com/112157682 :-) | 11:22 |
| paulsher1ood | ssam2: ah! no | 11:23 |
| jmacs | I'm not so happy with it | 11:23 |
| paulsher1ood | jmacs: why? | 11:23 |
| * paulsher1ood has produced a reasonable number of films, and feels qualified to +2 it | 11:23 | |
| jmacs | I described a build result as an 'image' and there's background noise in the audio | 11:24 |
| paulsher1ood | jmacs: it's readable, and the audio is clear | 11:24 |
| jmacs | Mostly, yes, but there's a big thunk from a door slamming near the end | 11:25 |
| paulsher1ood | jmacs: i think your artistic temperament is showing :-) | 11:26 |
| paulsher1ood | seriously, it's easy to follow what you're doing, does the job. | 11:26 |
| jmacs | OK, well I can't really argue with your judgement on films, so thank you. | 11:26 |
| paulsher1ood | heh :) | 11:27 |
| rdale | it looks fine to me to - audio ok, and i could read the text on the terminals | 11:28 |
| paulsher1ood | jmacs: one question - why is the deploy so slow? | 11:29 |
| jmacs | Good question. I haven't had a chance to look into it yet. | 11:30 |
| paulsher1ood | np | 11:30 |
| paulsher1ood | franred: i've +1 your lorries... you need 1 more... | 11:31 |
| franred | paulsher1ood, cheers | 11:32 |
| straycat | franred, where's the patch? | 11:33 |
| paulsher1ood | on the ml | 11:33 |
| franred | straycat, on the mailing list | 11:33 |
| straycat | franred, so we don't strictly speaking need both rabbitmq repos, but if we have the fork we may as well carry the original? | 11:37 |
| franred | straycat, we may or may not so I would like to lorry both just in case anyone wants to use the original for other reasons in the future | 11:38 |
| straycat | mkay | 11:38 |
| franred | we don't know if/how the fork get synchronized | 11:38 |
| straycat | looks fine to me, +1 | 11:39 |
| franred | cheers | 11:39 |
| paulsher1ood | franred: notice ssam2's comment before merge please | 11:40 |
| * paulsher1ood was too quick with his +1 | 11:40 | |
| straycat | yeah i agree with ssam2 | 11:41 |
| straycat | i actually misread and thought the fork was fork_rabbitmq >.> | 11:43 |
| * DavePage wants rabbit on a fork now :( | 11:43 | |
| petefoth | A welsh one for me please | 11:46 |
| pedroalvarez | hm... I've just deployed a system with new systemd and it doesn't have network connection | 11:48 |
| Kinnison | is it missing the unit we wrote to do the ifups ? | 11:49 |
| pedroalvarez | i believe that Javier said that it wasn't needed | 11:50 |
| Kinnison | Oh | 11:50 |
| ssam2 | I don't think that unit is needed, jjardon gave an example of the new configuration required | 11:50 |
| ssam2 | I forget where though | 11:50 |
| pedroalvarez | ssam2: thanks, I didn't know about that | 11:51 |
| jjardon | pedroalvarez: check /etc/systemd/network | 11:51 |
| * ssam2 finds http://www.freedesktop.org/software/systemd/man/systemd.network.html | 11:51 | |
| pedroalvarez | jjardon: it's present in the system | 11:51 |
| jjardon | pedroalvarez: the default configuration will only configure the ethernet interfaces with dhcp | 11:52 |
| pedroalvarez | jjardon: so "Name=en*" should only match in ethernet interfaces? | 11:53 |
| paulsher1ood | ssam2: you mentioned on the list 'we may as well use the btrfs storage backend'... but https://blog.docker.com/2013/05/btrfs-support-for-docker/ ? | 11:53 |
| paulsher1ood | is btrfs officially supported? | 11:54 |
| robtaylor | yep | 11:54 |
| jjardon | pedroalvarez: yeah | 11:54 |
| paulsher1ood | oh, cool. is there some magic, robtaylor ? | 11:54 |
| * paulsher1ood googles harder | 11:54 | |
| richard_maw | you also benefit from btrfs even if you haven't got docker configured to use the btrfs backend, since the vfs backend uses btrfs' clone ioctl to do fast file copies | 11:55 |
| ssam2 | paulsher1ood: in the 18 months since that blog post there has been some progress :) | 11:55 |
| robtaylor | paulsher1ood: google 'docker graph backends' | 11:55 |
| paulsher1ood | ssam2: i expect so. but google 'docker btrfs' doesn't really show it :-) | 11:55 |
| pedroalvarez | jjardon: hm.. that didn't work with eth0 in openstack.. | 11:55 |
| paulsher1ood | robtaylor: thanks | 11:55 |
| richard_maw | pedroalvarez: hm, it sounds like you're not getting the deterministing device naming then | 11:56 |
| * richard_maw can't remember how that is configured | 11:56 | |
| richard_maw | ah, pedroalvarez: look in /etc/udev/rules.d for persistent-net.rules | 11:57 |
| jjardon | eth0 doesnt exist in systemd | 11:57 |
| jjardon | pedroalvarez: ^ | 11:57 |
| * paulsher1ood was meaning to say, updating to latest systemd seems to drop his network config | 11:58 | |
| paulsher1ood | (still working network, but not the expected eth0 and fixed ip) | 11:58 |
| richard_maw | paulsher1ood: ah, your custom networking setup would need to be translated to networkd config, rather than /etc/network/interfaces | 11:59 |
| richard_maw | I don't think anyone here has much experience with it though | 11:59 |
| paulsher1ood | richard_maw: aha, thanks | 12:00 |
| richard_maw | jjardon: we need to keep things working between updates, can we have networking configuration which will work for eth0? | 12:01 |
| jjardon | paulsher1ood: check /etc/systemd/network, this is the only thing you need: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/foundation/systemd.morph#n21 | 12:03 |
| jjardon | to configure all the ethernet interfaces with dhcp | 12:04 |
| richard_maw | jjardon: that only works if you've got the deterministic interface nameing | 12:04 |
| richard_maw | if you've still got the config file in udev that makes it stay as eth0, then that config won't work | 12:05 |
| jjardon | richard_maw: remove that udev file then? | 12:05 |
| richard_maw | that's a manual step for updating though, as-is if anyone upgrades rather than re-deploying, they have a broken system | 12:06 |
| pedroalvarez | richard_maw: what file is this? I only have one under rules.d which contains 'KERNEL=="fuse", MODE="0666"' | 12:06 |
| richard_maw | if we'd put all these config files in /usr, rather than /etc we wouldn't be having this problem | 12:07 |
| jjardon | pedroalvarez: whatd the output of ifconfig -a? | 12:07 |
| pedroalvarez | jjardon: http://paste.baserock.org/ozemejajas.sm | 12:08 |
| * Kinnison notes that with the new systemd this means the simple network configure extension will no longer work as expected | 12:08 | |
| Kinnison | breaking virtualbox deployment etc | 12:08 |
| pedroalvarez | jjardon: note, I've modified the networkd config and restarted | 12:08 |
| jjardon | Kinnison: that extension has been removed from all the systems with systemd | 12:09 |
| richard_maw | pedroalvarez: ah, what we've actually got for our systemd config to prevent it renaming devices is we emptied 80-net-name-slot.rules | 12:09 |
| Kinnison | jjardon: without a replacement offered? | 12:09 |
| richard_maw | pedroalvarez: http://git.baserock.org/cgi-bin/cgit.cgi/delta/systemd.git/commit/systemd.morph?h=baserock/morph&id=d7498df6813b97f60aa04efc16c561804f30a9dc | 12:09 |
| jjardon | Kinnison: networkd was the replacement | 12:10 |
| pedroalvarez | jjardon: I believe that Kinnison is talking about this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/exts/simple-network.configure | 12:12 |
| pedroalvarez | richard_maw: thanks! so by removing that file we avoid the renaming of (e.g) eth* to en*? | 12:14 |
| jjardon | pedroalvarez: yeah, I think we are talking about the same? http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=54f36e8b4a5a58d872980c13aba5bcc4726283f9 | 12:15 |
| pedroalvarez | jjardon: oh, yeah sorry | 12:16 |
| pedroalvarez | but yes, I think we should test the virtualbox deployment and check if a replacement is needed | 12:17 |
| pedroalvarez | note that I've no idea what networkd is doing now, and if simple-network is not needed anymore | 12:18 |
| jjardon | pedroalvarez: "systemd-networkd is a system service that manages networks. It detects and configures network devices as they appear, as well as creating virtual network devices." http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html | 12:20 |
| robtaylor | should do a much better job thanb simple-network ;) | 12:26 |
| robtaylor | richard_maw: would you like to dicsuss those ideas from yesterday further at some point? | 12:27 |
| radiofree | i upgrade from a factory image to a new systemd image and the network worked for me | 12:27 |
| radiofree | it was en* | 12:27 |
| jjardon | uh, ok to commit this? we are compiling master of libndp: http://paste.baserock.org/ahujovigud.sql | 12:30 |
| radiofree | looks ok to me | 12:30 |
| franred | jjardon, looks ok to me too | 12:31 |
| rdale | can unpetrify-ref: refer to a tag as well as a branch? | 12:32 |
| franred | rdale, yes | 12:32 |
| rdale | ok thanks | 12:32 |
| ssam2 | jjardon: +1 | 12:33 |
| jjardon | radiofree, franred thanks, pushed | 12:33 |
| jjardon | sorry ssam2 , too late to add you! | 12:34 |
| * ssam2 sulks | 12:36 | |
| paulsher1ood | radiofree: it worked for me, but not with the config i was expecting ;) | 13:04 |
| richard_maw | robtaylor: sure, you just happened to ping me while I was at lunch | 13:05 |
| richard_maw | jjardon: simple-network is still needed for things like VirtualBox deployments, where you sometimes need static IPs. | 13:06 |
| richard_maw | To do this properly we need a migration strategy to convert /etc/network/interfaces into /etc/systemd/network and to fix up simple-network to generate /etc/systemd/network config if networkd is available | 13:07 |
| richard_maw | we can drop the former if we declare we don't care about upgrading, but we need the latter, rather than your patch to drop simple-network.configure | 13:08 |
| richard_maw | IMO simple-network.configure should be generating the /etc/systemd/network config, rather than putting it in the chunk | 13:09 |
| richard_maw | we should avoid putting files in /etc during chunk builds when we could put them in /usr/ | 13:09 |
| ssam2 | i didn't realise that, I apologise for saying in review that only the minimal-system would be affected | 13:10 |
| richard_maw | it's intricate, I don't blame anyone for making this mistake, but we need to fix it | 13:12 |
| Kinnison | jjardon: networkd is not a drop-in replacement for simple-network.configure | 13:16 |
| Kinnison | jjardon: in fact, networkd clearly needs just as much configuration | 13:16 |
| jjardon | richard_maw: yeah, I agree with you simple-network.configure should be generating the /etc/systemd/network/*.network files | 13:22 |
| jjardon | Kinnison: what use cases baserock used to support apart from configuring the ethernet network interface with dhcp? | 13:23 |
| richard_maw | static ip config | 13:24 |
| Kinnison | paulsher1ood will likely be very sad if he can't configure interfaces statically like we used to for multi-virtualbox deployments | 13:24 |
| paulsher1ood | Kinnison: actually, i'll live... | 13:25 |
| jmacs | I'll also be sad if I can't set up ceph clusters that way | 13:25 |
| pedroalvarez | i'm sad because openstack instances read the cloud-config script doing a GET request to an http server | 13:27 |
| pedroalvarez | (impossible to do without network) | 13:27 |
| jjardon | richard_maw: any system with a example of that config in definitions? | 13:29 |
| franred | could someone have a look what happens with the erlang-modules lorry file? how could I check why is failing to clone it? (they are not in g.b.o) | 13:30 |
| franred | s/\? /\? or/ | 13:31 |
| richard_maw | franred: I'll have a poke around | 13:31 |
| pedroalvarez | jjardon: there is an example of static ip here: http://wiki.baserock.org/devel-with/#index5h2 | 13:32 |
| pedroalvarez | not sure if was that what you were asking for | 13:32 |
| franred | richard_maw, cheers | 13:32 |
| jjardon | mmm, I think a easy way to have <eth0> back is using a .link : http://www.freedesktop.org/software/systemd/man/systemd.link.html | 13:35 |
| jjardon | but let me investigate more | 13:35 |
| richard_maw | franred: your lorry file is invalid json, because you missed out the " on the sd_notify name | 13:40 |
| franred | richard_maw, :/ ouch, sorry, Im going to fix this | 13:41 |
| franred | and cheers | 13:41 |
| jjardon | pedroalvarez: ok, thanks. So none of the systems in definitions is broken, rigth? | 13:45 |
| *** jjardon [sid723@gateway/web/irccloud.com/x-kcnlxhpledlirbpg] has quit [] | 13:55 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-hioklikdbudulumq] has joined #baserock | 13:56 | |
| richard_maw | jjardon: maybe, but definitions doesn't contain the sum total of deployments. paulsher1ood used to do custom NETWORK_CONFIG | 13:59 |
| paulsher1ood | richard_maw: correct | 14:02 |
| paulsher1ood | but actually, my customization is manual, so not sure that baserock needs to support it by default? | 14:02 |
| robtaylor | richard_maw: when would be good for you? | 14:19 |
| richard_maw | 20-25 minutes from now, I've got a bunch of stuff I need to do now, then a short meeting | 14:20 |
| robtaylor | richard_maw: cool, that should be good for me. ping when you're ready | 14:21 |
| *** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:27 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 14:29 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:29 | |
| Mode #baserock +v ssam2 by ChanServ | 14:29 | |
| richard_maw | robtaylor: ping | 14:44 |
| robtaylor | kpong | 14:45 |
| richard_maw | I didn't know there was an in-kernel implementation of that | 14:45 |
| robtaylor | of? | 14:45 |
| richard_maw | pong | 14:45 |
| richard_maw | lame joke | 14:45 |
| richard_maw | anyway | 14:45 |
| robtaylor | ah hah :) | 14:45 |
| robtaylor | so, does my crazy idea still seem cool after a nights cognition? | 14:46 |
| richard_maw | we could have systemd do a pivot and re-exec, but then the entire userland needs to be able to handle graceful re-exec | 14:46 |
| robtaylor | yeah | 14:47 |
| richard_maw | freezing, pivoting and using gdb to make processes re-open directory fds might work, but that's just scary | 14:47 |
| robtaylor | i'd have it so pid 1 is a syustsem d, but with only one unit, that nspawns the rest of the sysystem | 14:47 |
| robtaylor | when you want to run a new system, you ask pid 1 to nspawn the new system, and we have some way to handover the sockets between 1st container and the 2nd | 14:48 |
| robtaylor | (probably by the systemd in 1 communicating with the systemd in 2 - you can bindmount the systemd socket from root into 1, root into 2, and 2 into 1 | 14:49 |
| robtaylor | then bring down 1 when it's quiesecent (maybe with a snapshot before killing for added live rollback magic) | 14:50 |
| richard_maw | you can socket activate through nspawn, so for a subset of the available services you don't need to do any clever socket migration | 14:50 |
| robtaylor | ooh yes | 14:51 |
| robtaylor | you just have the root sytemd own the sockets, and activate in the container | 14:51 |
| robtaylor | don't think that'll work out of the box - i think it just supports starting a new container for a given socket activated service at the moment | 14:52 |
| richard_maw | hm, yeah, you'd need to have one service nspawn, and the rest depend on that, and nsenter | 14:54 |
| robtaylor | yeah, that sounds like a good way to prototype it | 14:55 |
| robtaylor | its mostly doable in shell, i think | 14:55 |
| richard_maw | I just fear there's be little interest in actually doing the work required for atomic online update if the majority of userland needs patching to support graceful re-exec | 14:55 |
| robtaylor | hmm | 14:57 |
| robtaylor | it may be possible to make it work nicely | 14:57 |
| robtaylor | you know how systemd delays the accept until the service is up and running? | 14:58 |
| robtaylor | it could delay accept until the old service is down and the new service is up | 14:58 |
| robtaylor | (if a service can't be graceful with itself) | 14:59 |
| robtaylor | I epcet apache will just work anyhow | 14:59 |
| robtaylor | if you graceful-stop in conatiner 1 and start it in conatiner 2 | 15:00 |
| robtaylor | and that's the usecase everyone cares about =) | 15:00 |
| robtaylor | actually, any service that support graceful restart should be able to cope with itself being launched while its still gracefully shutting down | 15:00 |
| robtaylor | otherwise there'd be a bunch of cases in the normal packaged world that would be problematic | 15:01 |
| richard_maw | I'd like if we could handle desktop and shell server cases too | 15:02 |
| robtaylor | hmm | 15:03 |
| ssam2 | rdale: are you blocked on having fribidi and crman and qtwebengine-chromium merged? I guess I can give you a +2 if so and merge the thing now | 15:04 |
| *** apespace [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:04 | |
| robtaylor | richard_maw: how would you see desktops working? | 15:04 |
| richard_maw | robtaylor: terminals could re-exec with the scrollback, pwd and env set, but there's a lot of state that would need the shell to support it natively | 15:04 |
| rdale | fribidi and bullet3 are needed for enlightenment, which is part of the qt5 system. the qtwebengine-chromium isn't needed until qt5.4 is released at the beginning of december | 15:05 |
| robtaylor | I think if you have a service still runnig in the old system, and you want to leave it running, that's up to you | 15:05 |
| robtaylor | richard_maw: thats just the same case as a normal packaged system | 15:05 |
| robtaylor | richard_maw: if im running irssi in a screen and i upgrade package upgrade irssi, it doesnt reload itself | 15:06 |
| robtaylor | and its got stuff loaded in memory that's still on disk | 15:06 |
| robtaylor | there's no memory or cache cost to that being the last process running in a container against it being the last process running with the old binaries mmaped | 15:08 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:08 | |
| richard_maw | the weird bit is that user-directed file-system browsing is different to the packaged online update method, as the working directory and any directory fds are still referring to the old version | 15:08 |
| robtaylor | yep | 15:08 |
| richard_maw | so after initiating an atomic update, the shell in your sshd doesn't see the update unless you log back in | 15:09 |
| robtaylor | hmm, can we just have a way to setns things you want to migrate? | 15:09 |
| robtaylor | so old stuff is still in the old cgroup, so you know they're still 'tainted', but can be pulled into the new namespace | 15:11 |
| richard_maw | just changing the mount namespace they're in is not sufficient on its own, since cwd, root and open fds still refer to the old version, independent of the namespace | 15:11 |
| robtaylor | desktops, it think you just have a 'apply upgrade' popup (which in the new system bring the desktop up to gdm in the background, then pressing apply upgrade just logs you out and switches to teh new system) | 15:12 |
| richard_maw | if you wanted to move processes around you'd probably have to inject code to get it to reopen directory fds, but you can change cwd and root with pivot_root in most cases | 15:12 |
| robtaylor | richard_maw: you can't pivot_root arunning process | 15:13 |
| robtaylor | richard_maw: at least not when i last saw it | 15:13 |
| * richard_maw looked at the code and couldn't see anything preventing it working for running processes | 15:14 | |
| robtaylor | the syscall is for a process to pivot_root itself, no? | 15:14 |
| richard_maw | historically, and currently if I understand it correctly, it moves multiple processes. The manpage sugggests that you shouldn't rely on it working for other processes as it's functionality that may be deprecated | 15:15 |
| robtaylor | richard_maw: man 2 pivot_root | 15:16 |
| richard_maw | yep, been there, that's where it warns that it may not change other processes | 15:17 |
| richard_maw | I'll have to check what do_each_thread iterates over though. | 15:18 |
| richard_maw | i.e. whether it's _every_ thread in the system, or just those associated with the process | 15:18 |
| robtaylor | its just the process | 15:18 |
| robtaylor | that bit you're reading is 'make sure that when you kill you're old rootfs you don't have any processes left using it' | 15:19 |
| robtaylor | but that doesnt really matter so much on a modern system | 15:19 |
| richard_maw | I think I've got older manpages on my Debian system, since it explicitly says it may or may not change it for all processes in the namespace | 15:20 |
| richard_maw | ok, so they've deprecated that finally | 15:20 |
| robtaylor | anyhow, you *can* do all that with setns | 15:21 |
| robtaylor | but yeah, moving things between filesystems without their cooperation is going to get messy | 15:22 |
| richard_maw | are you suggesting we can setns another process, or are we relying on cooperation? | 15:23 |
| robtaylor | you *can* setns another process | 15:23 |
| robtaylor | but it's cwd will be interesting, i expect | 15:23 |
| richard_maw | using setns on another process is news to me | 15:24 |
| robtaylor | this may rewuire some kernel reading to figure the nitty gritty | 15:24 |
| robtaylor | oh, seems i've imagined that | 15:24 |
| richard_maw | so we're on either injecting code into the frozen process to make it move itself, writing a syscall to move every process, or having systemd pivot and restart the processes, which isn't much better than running the apps in containers | 15:28 |
| robtaylor | yep | 15:28 |
| richard_maw | syscall is unlikely to be accepted, as it's probably a massive security risk | 15:28 |
| robtaylor | yep | 15:29 |
| richard_maw | injecting code is scary, but potentially workable | 15:29 |
| robtaylor | use criu? | 15:29 |
| rjek | ptrace | 15:29 |
| rjek | I think you can use ptrace to execute system calls on behalf of other processes | 15:29 |
| richard_maw | I've done it before with gdb | 15:30 |
| rjek | You can certainly use gdb to... yes | 15:30 |
| robtaylor | yep, ptrace | 15:30 |
| richard_maw | which is how criu does it, but actually using criu for this may be overkill, since AIUI you'd have to serialise and deserialise, and you'd probably lose the sockets you were using in the process | 15:31 |
| robtaylor | you can probably modify it to do less | 15:32 |
| robtaylor | but i'd see that as definitly secondary | 15:32 |
| rjek | Although, won't the process still have file handles open to files in the old root? | 15:32 |
| rjek | (Please tell me if I've got the wrong end of the stick) | 15:32 |
| robtaylor | a 'nice to have' tool that you can use to move a process from the old system to the new | 15:32 |
| robtaylor | rjek: indeed | 15:33 |
| richard_maw | rjek: you are correct | 15:33 |
| robtaylor | its all sorts of scary | 15:33 |
| rjek | You can probably do something evil for files it has open read-only by freopening them | 15:33 |
| richard_maw | rjek: but that's not really any more of a problem than a package based online update | 15:33 |
| robtaylor | and potential security risks.. | 15:33 |
| rjek | And just hope the process isn't keeping state :) | 15:33 |
| rjek | robtaylor: I suppose in packaged-based systems the packager knows if they need to restart the service, or just send it a HUP for it to gracefully reload. | 15:33 |
| rjek | And that information is carried in the upgrade itself. | 15:34 |
| richard_maw | unless it's firefox, which notices if it's referring to files that no longer exist | 15:34 |
| rjek | Yeah, some things behave quite nicely in that respect. | 15:34 |
| rjek | Lots of web frameworks do it when in development mode, but don't in production. Which kinda makes me sad, as it means a brief glimer of downtime. | 15:35 |
| robtaylor | I kinda see the case richard_maw wants to support though. It'd be good if you could do the sort of 'upgrade this thing, test if my stuff works now' that package systems allow you to do | 15:36 |
| rjek | Nod. | 15:37 |
| richard_maw | there's also the question of whether you _can_ run injected code in a frozen process | 15:38 |
| rjek | richard_maw: ptrace, then unfreeze, then inject? | 15:39 |
| rjek | Assuming a) you can ptrace a frozen process, and b) the process promptly does something that you can trap and trigger on. | 15:40 |
| straycat | Our setuptools bootstrap stuff differs from what's suggested in their READMEs, I guess this is because we don't allow access to the net when building. Problem is the same process doesn't work for the 'new' setuptools. | 15:42 |
| robtaylor | richard_maw: http://lwn.net/Articles/454304/ | 15:45 |
| richard_maw | rjek: I think PTRACE_{SEIZE,INTERRUPT,LISTEN} mean you don't need to stop them like that any more | 15:45 |
| rjek | Oh cool | 15:45 |
| richard_maw | robtaylor: already there :-) | 15:45 |
| robtaylor | heh | 15:45 |
| robtaylor | and http://lwn.net/Articles/525675/ as well, i presume? ; | 15:45 |
| robtaylor | ;) | 15:45 |
| richard_maw | not that one | 15:46 |
| robtaylor | first cut prototype could just use criu as is, mind you | 15:46 |
| robtaylor | then optimise | 15:46 |
| richard_maw | assuming criu gracefully handles being restored in a different tree to that it left | 15:47 |
| robtaylor | yeahhh | 15:47 |
| * robtaylor no know | 15:47 | |
| * richard_maw goes to find if they've got an IRC channel | 15:48 | |
| robtaylor | yeah | 15:49 |
| robtaylor | it seems it will work, but ymmv depending on how the process behaves wrt the filesystem changing underneath it | 15:50 |
| robtaylor | so should be fine for all the normal 'package upgrade' cases | 15:50 |
| robtaylor | The things that it expects to be there are the things you have open() in the process, i *think* | 15:51 |
| * richard_maw is asking in #criu | 15:51 | |
| richard_maw | there may be interest in cheap migration of processes between containers on the same system, so if it acceptably handles files being different on the target to the source, then it may even be upstreamable | 15:56 |
| robtaylor | yep, i think thre's enough with criu's infrastructure to do it | 15:56 |
| robtaylor | and i think the criu guys will take patches for lots of odd usecases, judging from their wiki | 15:57 |
| richard_maw | mmm, rebootless kernel upgrade | 15:58 |
| robtaylor | richard_maw: with criu? | 15:59 |
| richard_maw | it's one of the listed weird usage scenarios | 15:59 |
| robtaylor | ok, well i shall leave you with that for a while. bbiab | 15:59 |
| apespace | any idea what "Nonexistent host networking interface" means when starting a VM with http://wiki.baserock.org/guides/no-frills/ | 16:01 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 264 seconds] | 16:03 | |
| paulsher1ood | apespace: i think it's a vbox issue. click on network settings on the vbox ui... then try booting it? | 16:03 |
| jmacs | apespace: You probably don't have a host-only network present - it's usually a one-time thing when you install VirtualBox | 16:03 |
| apespace | "nonexistent host networking interface, name ''" | 16:04 |
| paulsher1ood | apespace: were you able to try what i suggested? | 16:05 |
| paulsher1ood | i believe i had the same experience in the video i made of the no-frills steps | 16:06 |
| ssam2 | straycat: how does it not work ? what's the error? | 16:07 |
| straycat | there's no error, setuptools just doesn't seem to be installed correctly | 16:07 |
| ssam2 | oh, so it's the installation of setuptools itself that doesn't work | 16:07 |
| straycat | #pypa have pointed me at https://pip.pypa.io/en/latest/installing.html#install-pip for bootstrapping | 16:07 |
| perryl | apespace: in modifyvm, have you added '--hostonlyadapter2 vboxnet0'? | 16:08 |
| straycat | if we have to do it using that, then it's going to be a little more complex than what we're doing now | 16:08 |
| straycat | so i might try and see if there's a simpler way | 16:08 |
| ssam2 | ouch, yeah | 16:08 |
| apespace | perryl: no I havn't added that | 16:09 |
| richard_maw | ooh, criu has a mode to run syscalls in another process | 16:09 |
| perryl | apespace: i had a similar issue with networking when creating a vm myself, if that solves the issue it may be worth updating no-frills | 16:10 |
| ssam2 | straycat: the fedora packaging seems to still use setuptools' setup.py | 16:11 |
| apespace | I'll try it | 16:11 |
| ssam2 | straycat: http://pkgs.fedoraproject.org/cgit/python-setuptools.git/tree/python-setuptools.spec (although that's a pretty unreadable spec file) | 16:11 |
| straycat | ssam2, what version of setuptools is that though? | 16:11 |
| straycat | ssam2, I admit I'm finding it hard to believe this can't be done more simply. | 16:12 |
| apespace | "Couldn't start the virtual machine because the following physical interfaces were not found: vboxnet0 (adapter 2)" | 16:13 |
| perryl | argh :( must be a different issue to what i had... | 16:14 |
| apespace | one thing I notice in virtualbox is that under network settings there is no host-only adaptor | 16:15 |
| jmacs | apespace: Add one in the GUI; the default settings should be OK | 16:15 |
| jmacs | I suspect those instructions aren't tested often because it's a pain for developers to uninstall and reinstall virtualbox | 16:16 |
| ssam2 | straycat: seems to be v7.0 | 16:16 |
| apespace | jmacs: is there any way to do that from the commandline? | 16:17 |
| straycat | ssam2, yeah i noticed | 16:17 |
| jmacs | apespace: There is, but I'd have to look it up. Hang on... | 16:17 |
| jmacs | apespace: "vboxmanage hostonlyif create" should do it | 16:18 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:21 | |
| *** apespace [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 16:26 | |
| radiofree | baserock systems that use an initramfs, are they upgradable? | 16:27 |
| paulsher1ood | richard_maw: ^^ ? | 16:27 |
| richard_maw | they certainly used to be, and should still be, why do you ask? | 16:28 |
| paulsher1ood | radiofree: is this to do with jetsons? i'm currently wondering whether my bricking was me, or something else | 16:31 |
| *** apespace [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:31 | |
| radiofree | paulsher1ood: the btrfs patches are pretty flakey, so i doubt it was you | 16:41 |
| radiofree | richard_maw: so we wouldn't need a u-boot with btrfs support then? | 16:41 |
| *** petefoth [~petefoth@host-78-151-29-232.as13285.net] has quit [Quit: petefoth] | 16:43 | |
| *** br_logger2 [~ubuntu@85.199.252.189] has joined #baserock | 16:44 | |
| richard_maw | radiofree: u-boot still needs to load the initramfs and kernel from btrfs | 16:45 |
| radiofree | yeah that's why i'm thinking it won't be useful :\ | 16:46 |
| apespace | the hostonlyif worked, but virtualbox still stops with "error: Failed to open/create the internal network 'HostInterfaceNetworking-' (you might need to modprobe vboxnetflt to make it accessible)" | 16:47 |
| radiofree | hmm.. or maybe we could specific "BOOTLOADER_INSTALL" as well? | 16:47 |
| radiofree | so on the jetson mmcblk0p1 is the bootloader partition (ext), which the kernels, device trees ext.. + extlinux.conf | 16:47 |
| radiofree | mmcblk0p2 is the actual btrfs partition | 16:47 |
| radiofree | how is BOOTLOADER_INSTALL currently use i wonder | 16:49 |
| * radiofree should know since he wrote it | 16:49 | |
| br_logger2 is now known as br_logger | 16:49 | |
| persia | Would anyone else find checksums for the images at download.baserock.org useful? I'm currently having fun with proxy servers for the images at http://download.baserock.org/cloud/ , and would like to be able to verify I have the right data. | 16:50 |
| *** br_logge1 [~ubuntu@85.199.252.110] has quit [Quit: Lost terminal] | 16:50 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 16:50 | |
| radiofree | richard_maw: would you have any massive objections to adding a "jetson-tk1" type for "BOOTLOADER_INSTALL" | 16:50 |
| apespace | persia: sha256 | 16:50 |
| radiofree | currently there is only "extlinux", which goes off and runs extlinux --install real_root | 16:50 |
| radiofree | i was thinking the jetson-tk1 one could mount /dev/mmcblk0p1, copy over the new kernel/dtb, update the extlinux.conf | 16:51 |
| persia | apespace: Works for me, if I can get real data. Personally, I prefer to have multiple checksums, to reduce the chance of collision | 16:51 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:51 | |
| richard_maw | radiofree: I thought `extlinux --install` was why we decided to split BOOTLOADER_INSTALL up into installing the config and installing the bootloader itself | 16:53 |
| apespace | persia: maybe gpg sign + sha256 | 16:54 |
| radiofree | richard_maw: indeed, we want to use an extlinux.conf on a jetson (BOOTLOADER_CONFIG_FORMAT) but not to actually install it | 16:54 |
| radiofree | so for the jetson, rather than "none" for INSTALL (it defaults to "extlinux), we set it to "jetson-tk1", which installs the extlinux.conf/kernel on a ext2 partition for u-boot to use | 16:55 |
| persia | apespace: That gives me two algorithms, so I like it, but requires me to accept the authenticity of a key: how do I know which is the role key (i.e. who certifies, and why do I trust the certifier) | 16:55 |
| persia | But seriously, only md5sums would meet my immediate need | 16:55 |
| rjek | md5+sha256 in a manifest file, the manifest file having been signed | 16:56 |
| jmacs | Will systemd start an ExecStart job as root by default? | 16:56 |
| robtaylor | richard_maw: so, do you think we have a plan? :) | 16:56 |
| persia | rjek: Sure, although that raises the certification issue again. | 16:56 |
| ssam2 | jmacs: I'm not sure, actually, I struggled with this the other day | 16:56 |
| richard_maw | radiofree: I forsee a lot of patching of the write extension for every dev board if we were to go down that route | 16:56 |
| jjardon | mmm, seems since baserock-14.29 we are not using annotated tags. Is this intended? | 16:57 |
| radiofree | richard_maw: i wrote it like that :\ | 16:57 |
| jmacs | ssam2: I'm seeing some odd problems whereby the same bash script works fine if executed by root on the console, but not if run by systemd | 16:57 |
| persia | But does anyone have permissions to write checksums? Could they do so? I'd be happy with any scheme, but it ought be done an environment where the authenticity of the source is known. | 16:57 |
| radiofree | there's a "install_function_dict" that has the functions for each type | 16:57 |
| radiofree | so it involves adding the new type + the implementation function | 16:57 |
| franred | jmacs, if you don't specify user, it would use root, tough | 16:58 |
| radiofree | i don't see it as a *terrible* thing to write specific bootloader implementation things | 16:58 |
| jmacs | franred: That's what I expected. | 16:58 |
| richard_maw | radiofree: I'd prefer something generic, like a pre configuration extension step which makes the disk image, partitions and formats, then when morph is writing the rootfs the kernel automatically goes in the right place | 16:59 |
| radiofree | this would be a massive benefit for us, it would mean we don't have to patch u-boot | 16:59 |
| franred | jmacs, maybe shell problems? bash - sh? | 16:59 |
| radiofree | richard_maw: what about for upgrades? | 16:59 |
| richard_maw | radiofree: but that idea's not yet mature, so I suspect we may have to put the per-device badgering in | 16:59 |
| jmacs | I'm executing it with bash -c "/root/setup-things | tee /root/setuplog" | 16:59 |
| richard_maw | radiofree: how does putting the kernel and config on /boot work with upgrades in your model? | 16:59 |
| jmacs | ...and setuplog looks fine; it exactly matches what comes out when I run manually | 17:00 |
| radiofree | that's essentially what i want to change it over to, mmcblk0p1 will become /boot | 17:00 |
| richard_maw | robtaylor: I'm going to try criu for migrating processes to the new tree | 17:00 |
| richard_maw | robtaylor: criu even has a mode for just running syscalls in the target process, so I may not need the whole checkpoint logic | 17:01 |
| radiofree | stock u-boot reads the extlinux.conf from that partition, boots into btrfs | 17:01 |
| robtaylor | richard_maw: cool! | 17:01 |
| radiofree | the jetson-tk1 "BOOTLOADER_INSTALL" updates the extlinux.conf file in /boot, copies the new kernel/dtb there etc.. | 17:01 |
| richard_maw | radiofree: you'd also need to change the system-version-manager script again to do that then | 17:01 |
| radiofree | richard_maw: is that currently hardcoded to look for extlinux.conf in the very root of the btrfs device? | 17:02 |
| richard_maw | and to copy the kernels and initramfs into paths relative to the root of the btrfs device, since that's how we specified upgrades to work | 17:03 |
| radiofree | would prioritising the presence of /boot/extlinux.conf be considered acceptable? | 17:04 |
| jmacs | Thanks franred - looks like I might need an "After=network.target" in my systemd script | 17:04 |
| franred | jmacs, cool :) | 17:05 |
| jmacs | Just mentioning it so we have a log :) | 17:05 |
| jjardon | pedroalvarez: Any reason to not use annotated tags in the latest baserock releases? | 17:06 |
| pedroalvarez | jjardon: nope, i thought it was only needed in morph when we were versioning it | 17:07 |
| richard_maw | radiofree: I'd rather we fixed up the btrfs patches, but if we can't do that then I think the system-version-manager script should check for BOOTLOADER_INSTALL = jetson-tk1 in /baserock/deployment.meta, and if that's set copy the kernel, initramfs and update the config in /boot | 17:07 |
| radiofree | ok! | 17:08 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:09 | |
| jjardon | pedroalvarez: AFAIK whitout annotated tags is not possible to know who made the tag, or when | 17:11 |
| richard_maw | even with you can't know, since that data can be faked | 17:11 |
| jjardon | richard_maw: I can know who faked | 17:12 |
| richard_maw | how? | 17:13 |
| jjardon | or at least when | 17:13 |
| richard_maw | nope, that's also fakeable | 17:13 |
| jjardon | anyway, I think you are putting an extreme case as an example | 17:13 |
| jjardon | richard_maw: what about if you sign the tag? | 17:14 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:15 | |
| richard_maw | I don't know the details of how signing works, but if it's done properly you can know who was faking the commit author and date | 17:15 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 17:15 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:15 | |
| persia | Rather, you can know which key. Translating a key into a person requires a chain of trust of the certifiers | 17:15 |
| straycat | ssam2, I think this is a bug in setuptools | 17:20 |
| straycat | ssam2, I just checked out 7.0 and it installs fine | 17:20 |
| jjardon | so, please: I think its a good idea to annotate (and sign) the releases ;) | 17:20 |
| richard_maw | you need a key infrastructure that we currently don't have to make that worthwhile | 17:21 |
| straycat | I guess this means for now we can base our patch off 7.0 | 17:21 |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 17:21 | |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 17:22 | |
| jjardon | richard_maw: ? simple sign with your pgp key | 17:22 |
| ssam2 | straycat: cool! | 17:23 |
| richard_maw | jjardon: we don't all have them, nor a web of trust to make our keys useful for identifying that we were the ones to sign it | 17:23 |
| richard_maw | I'd be happy to see a proposal for how we should sign our artifacts | 17:24 |
| richard_maw | but we've got a few proposals that seem to have become stuck in the mailing list as it is | 17:25 |
| *** simonh_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:26 | |
| jjardon | richard_maw: create a gpg key is trivial; Im sure several members of the team already have keys and would be happy to sign other peoples keys if needed | 17:26 |
| persia | richard_maw: For signing, the public key infrastructure mostly works: the key is having the signing key be certified by individuals known to be reasonably trusted. | 17:27 |
| persia | But I agree, the right place for this discussion is the mailing list. | 17:29 |
| richard_maw | I'm happy for this discussion to continue, but I don't know enough about the implications to make a reasonable contribution. | 17:29 |
| persia | As a side effect, we can usefully identify the membership of the release team, where heretofore has been somewhat blurrily defined. | 17:29 |
| jjardon | richard_maw: when you became a GNOME maintainer, you have to sign your releases: only condition is to create a key and use it, thats all | 17:29 |
| apespace | binary releases are in general signed | 17:31 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:45 | |
| *** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has joined #baserock | 17:58 | |
| *** tiagogomes [~tiagogome@host-92-16-23-104.as13285.net] has quit [Client Quit] | 17:59 | |
| *** apespace [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:00 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:03 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:03 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:05 | |
| pedroalvarez | great, I migrated paste.b.o, testirclogs.b.o, and testgerrit.b.o | 18:19 |
| pedroalvarez | I found many problems when doing a new mason deployment, I hope to send patches tomorrow with the fixes | 18:19 |
| * straycat think it might be nice to have some tweaks so that morph can do more when you're offline | 18:24 | |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 18:24 | |
| straycat | so have a stage at the start where you update the caches you need to update, fetch the things you need and then start building, perhaps | 18:25 |
| *** rdale [~quassel@92.Red-88-20-2.staticIP.rima-tde.net] has joined #baserock | 18:26 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:31 | |
| persia | straycat: Could that be a --download-only argument to morph, perhaps with an --offline argument to tell it not to even try getting more cache? | 18:32 |
| straycat | persia, I was thinking more that it'd be useful to do the cache stuff upfront, so that once your build starts you can be offline | 18:35 |
| persia | For how I use it, I wouldn't want to start a build, and then go offline midway through (although, thinking about it, I'd like more parallelism, so that downloads were happening even when a build was happening). | 18:35 |
| persia | My thought was that the --download-only option would update all the caches (both gits and objects) for the artifact to be built, so that when one made changes, one would only do the local building, keeping the cache. | 18:36 |
| persia | Note that this usage model may differ from that of other users | 18:36 |
| straycat | Oh I see, yeah a --download-only would be just as useful for my case I think. So I could run --download-only then continue offline later | 18:39 |
| persia | Or immediately, if you liked. | 18:40 |
| persia | It also lets you test if everything is cached. | 18:40 |
| persia | So if I was working on an ARM laptop and deploying to a PPC board, I might want to use --download-only to make sure I had all the artifacts for a system in the cache, so I could then fiddle with different deployments offline. | 18:41 |
| persia | (because distributed build systems don't work as well offline :) ) | 18:41 |
| * straycat nods | 18:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:01 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:39 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 19:39 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 19:54 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 20:04 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:42 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:42 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 21:10 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:10 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 21:44 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 22:30 | |
| *** ChanServ [ChanServ@services.] has quit [shutting down] | 23:11 | |
| *** ChanServ [ChanServ@services.] has joined #baserock | 23:14 | |
| Mode #baserock +o ChanServ by card.freenode.net | 23:14 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!