| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 04:54 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:54 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:43 | |
| mike is now known as Guest59245 | 07:44 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| * pedroalvarez reads about libisofs, python-libisofs, etc | 09:36 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 09:38 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:38 | |
| * persia wonders whether most baserock targets have optical drives | 09:38 | |
| * Kinnison imagines he's considering faking up an ISO for IPMI | 09:39 | |
| pedroalvarez | no, I was just researching after reading the "Deploying to ISO" email | 09:40 |
|---|---|---|
| petefoth | It's easy to add one to a VirtualBox VM (as described in my response to Gavin's email). I imagine something similar would be feasible in other virtualisation systems, but I have no idea how :) | 09:43 |
| persia | The issue with ISOs is that either one has to deal with read-only root, or one has to perform an "install". We know how to do the latter, but should avoid it for optimisation purposes most of the time (because it requires an additional data duplication operation) | 09:44 |
| * persia goes to read mail, expecting to find lots of things for which a reply may be useful | 09:45 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 09:49 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 09:49 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:49 | |
| mauricemoss_ | I started creating a new system for our acer chromebook (it should run gnome in the end). I was wondering, is it sensible to create a cross bootstrap system or better to build everything natively on the chromebook? | 09:50 |
| persia | Depends on the architecture of the chromebook. | 09:50 |
| mauricemoss_ | tegra k1, same as in the jetson | 09:50 |
| persia | If it is a supported architecture, then I'd recommend either a native build or distbuild. | 09:50 |
| persia | If it is unsupported, you need cross-bootstrap to get a system in a shape where you can complete a native build or distbuild. | 09:51 |
| persia | If it is the same as a jetson, it should be good for building. | 09:51 |
| mauricemoss_ | ok :) | 09:51 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:53 | |
| Mode #baserock +v ssam2 by ChanServ | 09:53 | |
| persia | I seem to remember jjardon doing something towards a GNOME/Weston system, which might be a sensible point of collaboration (if only because it increases the chances that things are cached on cache.baserock.org, reducing your build time) | 09:53 |
| pedroalvarez | Yeah, I also suggest using a jetson to as devboard and the chromebook as target, but I don't know the croomebook so maybe is easy to use as development environment and as a target at the same time | 09:53 |
| persia | Two makes life easier, but with self-upgrade, one can swap in and out of a development system as well. | 09:54 |
| mauricemoss_ | persia, I was speaking to jjardon yesterday about gnome. some fixes are still to be commited. | 09:57 |
| persia | Excellent, then you probably know more than I about the current state of affairs. | 09:58 |
| mauricemoss_ | I'll try self update first and see how I get on | 10:00 |
| SotK | regarding faster feedback from Zuul, we currently have a single "pipeline" which runs the build and test when a new change is pushed to Gerrit. Perhaps it is worth going with the Verified label being +1 builds, +2 tested, and having two pipelines defined in our config, one which runs the build then reports, one which tests things if there is a successful build report? | 10:04 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 10:11 | |
| persia | It is a balance-of-resources question. If we expect scarce resources, we should encourage developers to discover if things work locally (and give them tools to do so). If we expect plentiful resources, we should encourage developers to publish often, and give them fast feedback when things are not working. | 10:11 |
| persia | A potential middle ground would be to find a way to notify the submitter that the test had started, and pass them some means to look at the log-in-progress. | 10:12 |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 10:12 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 10:13 | |
| persia | That said, we ought fail early and visibly if we know we are failing, so that the -1 can be posted soonest. | 10:13 |
| persia | But until there is a -1 or a +1, there is no particularly useful information available, because we have not yet found a test that failed, but we cannot yet assert that all tests pass. | 10:14 |
| SotK | the current setup exposes the logs-in-progress at http://ZUUL_IP/logs, but our Mason is not exposed to the internet | 10:14 |
| persia | (and I think we'd want to discourage developers from watching the log, when they could be doing something useful) | 10:14 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 10:15 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:16 | |
| jjardon | persia: a reference weston system already exist and its being builded for x86 and arm, so all the components are available in the cache | 11:52 |
| persia | mauricemoss_: ^^ | 11:52 |
| jjardon | for GNOME xwayland is needed (will send patches today or tomorrow) and tzdata, that seems to be inside eglibc but now its a separate package | 11:53 |
| jjardon | Probably more things more thats what its in my list rigth now | 11:53 |
| Krin | has anyone got time to take a look at what I'm hoping is the final patch for the zookeeper work? | 13:16 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 13:17 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:31 | |
| Mode #baserock +v ssam2 by ChanServ | 13:31 | |
| *** tpollard_ [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:09 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 14:11 | |
| *** tpollard_ [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 14:12 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:12 | |
| mauricemoss_ | system-version-manager throws an error: https://ducie-dc1.codethink.co.uk/pnopaste/?2103 how can I fix this? | 14:14 |
| persia | Could you paste that somewhere public, like paste.baserock.org? | 14:26 |
| pedroalvarez | mauricemoss_: ^^ | 14:29 |
| radiofree | mauricemoss_: since you're using stock u-boot i'm assuming this isn't a btrfs partition | 14:29 |
| mauricemoss_ | http://paste.baserock.org/rifeqelate | 14:29 |
| radiofree | mauricemoss_: i changed system-version-manager to support non btrfs boot paritions | 14:30 |
| radiofree | however you'll need a recent version of baserock | 14:30 |
| radiofree | and your patition structure will have to be p1 = ext2/3/4, p2=btrfs | 14:30 |
| radiofree | put the baserock image in p2, and copy over extlinux.conf into p1 (e.g mmcblk0p1) /extlinux/extlinux.conf | 14:31 |
| mauricemoss_ | radiofree, ok, deploying works only with btrfs? | 14:31 |
| persia | Upgrades work only with btrfs today | 14:31 |
| persia | And system-version-manager only matters when one has upgraded a system (otherwise it is just factory) | 14:31 |
| radiofree | mauricemoss_: if you can make sense of https://gitlab.com/jamesthomas/baserock-flashing-tools/blob/master/flashscripts/jetson-tk1-flash.sh#L25 | 14:32 |
| persia | There was some talk of supporting ZFS, but I haven't seen patches for that yet. | 14:32 |
| mauricemoss_ | my idea was to upgrade the rootfs to different partitions to have a fall back | 14:32 |
| radiofree | persia: i don't think u-boot supports zfs either | 14:32 |
| mauricemoss_ | I'm not using uboot atm | 14:32 |
| mauricemoss_ | booting into a chromiumos kernel partition | 14:32 |
| radiofree | no idea sorry, but baserock needs btrfs to upgrade | 14:32 |
| persia | radiofree: From http://paste.baserock.org/rifeqelate I thought the problem was only with system-version-manager: how is u-boot related? | 14:33 |
| radiofree | if you're using master, you can now have a separate boot partition though | 14:33 |
| radiofree | persia: because he's almost certainly not using a btrfs partition? | 14:33 |
| radiofree | i might be wrong about that mauricemoss_? | 14:33 |
| persia | Ah. I see. | 14:33 |
| * persia leaves this to folk who understand more | 14:33 | |
| mauricemoss_ | I used the rootfs you created for the chroot/crouton demo | 14:34 |
| radiofree | that's just a tarball, what is the partition you extracted it to formated as? | 14:34 |
| mauricemoss_ | it's ext4, I'll change it to btrfs | 14:34 |
| mauricemoss_ | and then swapping between two btrfs partitions after deploying | 14:35 |
| radiofree | well you can't just extract the tarball onto a btrfs partition | 14:35 |
| radiofree | you need a rawdisk image and you need to dd it | 14:35 |
| radiofree | also you need to check your bootloader can read from a btrfs partition | 14:36 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 14:36 | |
| mauricemoss_ | radiofree, ok will check | 14:36 |
| pedroalvarez | so that's why is not working then | 14:37 |
| pedroalvarez | maybe we should improve the code to catch an exception there | 14:37 |
| radiofree | mauricemoss_: http://fpaste.org/160590/18827081/ | 14:38 |
| radiofree | that's the expected layout of a boot partition | 14:38 |
| radiofree | you can copy all of those files from a rawdisk image | 14:38 |
| radiofree | so for the jetson (using u-boot) i have mmcblk0p1 as an ext4 partition with that layout | 14:38 |
| radiofree | and mmcblk0p2 as a btrfs partition with the baserock image | 14:38 |
| mauricemoss_ | can I just deplot a rootfs to a btrfs partiton and change the kernel parameters from chromiumos? it's needs to be signed with a google tool anyway | 14:39 |
| mauricemoss_ | s/deplot/deploy | 14:39 |
| radiofree | i'm going to go with no | 14:39 |
| radiofree | but someone else is probably more qualified to answer that | 14:39 |
| radiofree | the btrfs partition needs to be a specific format (subvolumes created etc...) | 14:40 |
| *** Guest59245 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 14:40 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 14:41 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 244 seconds] | 14:41 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:41 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:41 | |
| Mode #baserock +v ssam2 by ChanServ | 14:41 | |
| *** Guest59245 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:41 | |
| radiofree | how can i btrfsck my baserock partition? | 14:50 |
| radiofree | after running "resize max" on it the partition will eventually end up being remounted read only | 14:51 |
| radiofree | maybe after a day, maybe after a few hours... | 14:51 |
| radiofree | i only notice it because systemd-journald spams the kernel log about how it can't write | 14:51 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:51 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 14:57 | |
| robtaylor | radiofree: sounds like its screwed, im afriad | 15:03 |
| robtaylor | someone really needs to make a systmd timer unit that does a defrag | 15:06 |
| robtaylor | (or at least, the deploy scripts should do a defrag and a balance if they don't already) | 15:07 |
| ssam2 | that'd be great (except no doubt it'd run whenever I was trying to do something else and use up all the IO) | 15:07 |
| robtaylor | ssam2: thats kinda the reason tht btrfs doesnt do it automatically | 15:09 |
| robtaylor | (thogh it does run as a low prio background thread) | 15:09 |
| robtaylor | ssam2: a timer unit for 5am should do the job for most folk ;) | 15:09 |
| robtaylor | though a balance and defrag after deploy is really a must-have, i'd say | 15:10 |
| radiofree | apparently i can't run it at boot? | 15:11 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:11 | |
| radiofree | i can mount the emmc using u-boot and run it from my laptop i suppose | 15:11 |
| robtaylor | you can set it to auto defrag as a mount option, i think | 15:11 |
| radiofree | i never see this issue until i use btrfs filesystem resize max / | 15:11 |
| ssam2 | robtaylor: oh! that'd be good enough for me, probably | 15:11 |
| robtaylor | radiofree: it sounds like your file system is screwed i'm afraid - i've had that before | 15:12 |
| robtaylor | ssam2: yeah! | 15:12 |
| radiofree | rebooting fixes it :\ | 15:12 |
| robtaylor | radiofree: oh, thats lucky | 15:12 |
| radiofree | it'll happen again | 15:12 |
| robtaylor | radiofree: back it up now if you need it | 15:12 |
| radiofree | there's nothing critical on it, this is a jetson | 15:12 |
| robtaylor | radiofree: and then either blow it away or defrag and rebalance | 15:12 |
| radiofree | ok | 15:12 |
| robtaylor | but ime rebalancing at this point just goes horribly wrong... | 15:12 |
| radiofree | is filesystem resize a bit iffy then? | 15:12 |
| robtaylor | it *shouldn't* be, tbh | 15:13 |
| robtaylor | but the remount read-only is what btrfs does when things are wrong. you'll probably see some scary messages in dmesg | 15:13 |
| ssam2 | (about autodefreg: https://btrfs.wiki.kernel.org/index.php/Mount_options promises that 'Once the developers make sure it doesn't defrag files over and over again, they'll move this toward the default.') | 15:13 |
| robtaylor | yep | 15:14 |
| robtaylor | its' said that for quite a long while :( | 15:14 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 15:14 | |
| radiofree | before it happens i get | 15:15 |
| radiofree | [385101.169536] mmcblk0: timed out sending r/w cmd command, card status 0x900 | 15:15 |
| radiofree | then a couple of [385101.176741] blk_update_request: I/O error, dev mmcblk0, sector 7638400 | 15:15 |
| radiofree | then finally a [385101.231274] BTRFS: bdev /dev/mmcblk0p2 errs: wr 4, rd 0, flush 0, corrupt 0, gen 0 | 15:15 |
| robtaylor | radiofree: oh. | 15:16 |
| radiofree | we're running btrfs on the jetsons for the mason right | 15:16 |
| robtaylor | radiofree: thats your mmc getting screwed then | 15:16 |
| radiofree | but we *didn't* use resize max there | 15:16 |
| radiofree | robtaylor: i see this on two boards, both of which i ran resize max on | 15:17 |
| robtaylor | radiofree: sounds like a bad interaction between resize max and the (e)mmc firmware | 15:17 |
| radiofree | actually, i only did resize 8G on this other one and that has been fine | 15:18 |
| robtaylor | sounds like the emmc fireware things its out of space, or is having problems finding good free underlying blocks | 15:18 |
| radiofree | maybe the emmc is buggered on this other board then | 15:18 |
| radiofree | ok, i'll just reflash it and run it for a bit without resizing | 15:18 |
| robtaylor | yeah, that might do the job | 15:19 |
| radiofree | as i said, it could be an hour, a day, a week.. before i see that message | 15:19 |
| persia | Unless the FTL supports btrfs, it is probably best not to use more than 80% of the capacity. | 15:19 |
| robtaylor | persia: that sounds like good advice | 15:19 |
| radiofree | 80% it is then | 15:19 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:19 | |
| persia | Note that btrfs has explicit support for some FTLs, in which case it doesn't matter, but that ought be considered the rare case. | 15:19 |
| persia | And inexpensive SD cards or eMMC tends to have FAT-optimised FTLs. | 15:20 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 15:28 | |
| * paulsher1ood wonders if it's too late to propose 'brie' as a name for firehose | 16:09 | |
| perryl | it'd save time on typing the name! | 16:10 |
| persia | Not at all: anything other than "firehose" would be lovely. Why "brie"? | 16:10 |
| Kinnison | paulsher1ood: it's a tad cheesy | 16:10 |
| paulsher1ood | it's already called that... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/firehose.git/log/?h=baserock/lauren/firehose | 16:10 |
| paulsher1ood | baserock robotic integration engineer :) | 16:11 |
| pedroalvarez | brrie? | 16:11 |
| * paulsher1ood would be happy to send a global replace patch series | 16:11 | |
| paulsher1ood | s/ series// | 16:11 |
| persia | Seems namespace-safe | 16:12 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 16:12 | |
| perryl | i like it; it's short, memorable, doesn't clash with nomenclature | 16:12 |
| paulsher1ood | do i take that as 2 x +1 ? :) | 16:12 |
| pedroalvarez | I'd like to hear that word first | 16:13 |
| * Kinnison dislikes it but not enough to -1 it, so -0 from me | 16:13 | |
| paulsher1ood | 'bree' as in the cheese, pedroalvarez | 16:13 |
| ssam2 | i don't like it but won't oppose it | 16:13 |
| persia | paulsher1ood: If there was a posted patch series, with an explanation of the name change, I'd +1 it. | 16:13 |
| paulsher1ood | ok. how do we get perryl's latest patchset merged first? | 16:13 |
| persia | Kinnison: ssam2: Do either of you have anything else? Or do you expect we'll get a new name in the near future otherwise? | 16:14 |
| * paulsher1ood doesn't want to cause others to rebase | 16:14 | |
| ssam2 | I don't have any better ideas :) | 16:14 |
| Kinnison | persia: I like 'firehose' as a name | 16:14 |
| Kinnison | otherwise I'd not have picked it | 16:14 |
| Kinnison | :-) | 16:14 |
| ssam2 | i think Firehose is a good name too | 16:14 |
| * paulsher1ood is ok with firehose | 16:14 | |
| persia | I've commented on why I think that is a poor name, and nobody wrote anything in opposition on the mailing list. | 16:14 |
| pedroalvarez | I think that brie is not better than firehose | 16:14 |
| paulsher1ood | enough bikeshedding. persia - are you -1 on firehose? | 16:15 |
| paulsher1ood | or -0? | 16:15 |
| persia | paulsher1ood: -1. | 16:15 |
| pedroalvarez | but firehose is already there! :) | 16:15 |
| mwilliams_ct | I don't think it's a bad name, but I'd be concerned that it doesn't give any more information than the name Firehose does about what the purpose is. unless you know the abreviation already | 16:15 |
| persia | pedroalvarez: Yes, but over several statements from me disagreeing. I still don't like it, and won't be made to like it, but I defer to consensus objection. | 16:16 |
| Kinnison | persia: I, as a rule, do not get involved in any positive or negative way in bikeshedding discussions because I find I get riled up too easily | 16:16 |
| ssam2 | about merging lauren's branch: I'm kind of deep in Node.js at the moment, I don't really want to drop it to review firehose today unless it's deemed more urgent | 16:16 |
| Kinnison | persia: as such, I declined to comment either way on your mail | 16:16 |
| pedroalvarez | I agree with mwilliams_ct. I like baserock robot integrator engineer, though | 16:16 |
| paulsher1ood | ssam2: no, not urgent | 16:16 |
| persia | Kinnison: I generally follow that process, but I believe it actually important in this case, rather than being a bikeshed-color class of issue. | 16:16 |
| ssam2 | Node.js does not make me happy, if anyone was wondering. It's like someone ported all the bad bits of GLib async programming to Javascript | 16:17 |
| Kinnison | persia: Also, IIRC the crux of your mail was that 'firehose' was a term already understood to mean something vastly different in the community | 16:17 |
| persia | Yes. | 16:17 |
| Kinnison | persia: and since I know that my "understanding" of terms is usually pretty unique, I declined to be involved at that level too | 16:17 |
| persia | And that is my source of dislike for the word. | 16:17 |
| Kinnison | since I personally chose 'firehose' because of what I understood it to mean in the community | 16:18 |
| Kinnison | :-) | 16:18 |
| Kinnison | But then gain, I *like* the morphology/chunk/stratum terminology too, so I'm known-dodgy wrt. nomenclature | 16:18 |
| persia | I usually see it applied to bug streams and request streams, not patch streams. | 16:18 |
| paulsher1ood | :-) | 16:18 |
| jmacs | To me, 'firehose' suggests an unfiltered source, and a huge volume of information | 16:18 |
| Kinnison | jmacs: and the 'firehose' tool works with that | 16:19 |
| persia | I'm also a fan of the stone-related terminology, which is why I suggested alternate stone-related names for this tool. | 16:19 |
| Kinnison | jmacs: so to me it fits :-) | 16:19 |
| persia | Except it filters. | 16:19 |
| persia | Or it ought filter. | 16:19 |
| Kinnison | But now I'm being drawn into a discussion I dislike, so I'mma stop now and go to do something else | 16:19 |
| pedroalvarez | wasnt the stone-related terminology going to disappear? | 16:20 |
| paulsher1ood | firehose is a catchy name (which is in part why it has stuck), but does not really describe what this does imo | 16:20 |
| Kinnison | paulsher1ood: if the open source world used names which described what things did, turbo-hipster would never exist | 16:20 |
| persia | nor, because it is a word with meaning, is it available to be a noun describing a project | 16:21 |
| pedroalvarez | Kinnison: or maybe it would be doing something really different | 16:21 |
| * persia also prefers non-descriptive names | 16:21 | |
| Kinnison | pedroalvarez: accelerating hipsters to high velocities? we can but hope | 16:21 |
| * perryl ponders dropping stone-related naming schemes in favour of cheese-related | 16:23 | |
| * pedroalvarez cures cheddar-cheese-x86_64 to openstack | 16:24 | |
| Kinnison | pedroalvarez: no, you "lay down" cheese | 16:25 |
| * Kinnison likes the idea of systems being called 'truckles' though | 16:25 | |
| pedroalvarez | Kinnison: right, thanks! | 16:25 |
| radiofree | how about "Mitzy" | 16:25 |
| Kinnison | that's a good cat name, so I approve | 16:25 |
| jmacs | That sounds like drugs. | 16:25 |
| pedroalvarez | I was pondering "integra" for firehose to have a descriptive name, but there are already some projects called like that | 16:26 |
| radiofree | is there any particular reason rsync isn't on a genivi image? | 16:27 |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has quit [Ping timeout: 255 seconds] | 16:27 | |
| pedroalvarez | radiofree: the reason is that is not mandatory | 16:28 |
| paulsher1ood | radiofree: i think genivi images are supposed to be more like a target than a devel environment. shouldn't leave tools lying around on a target? | 16:28 |
| pedroalvarez | rsync is in tools.morph | 16:28 |
| radiofree | i see, but you can't upgrade a genivi image then? | 16:28 |
| radiofree | i have to keep switching back to factory | 16:28 |
| pedroalvarez | that is indeed an issue if we want it to be upgradable | 16:29 |
| * persia likes "truckles", as it nicely avoids "systems", "packages", and other overloaded terms | 16:29 | |
| radiofree | ._. | 16:30 |
| perryl | truckles is close to truffles. chocolate related naming schemes! | 16:30 |
| persia | truffles are not chocolate: they are tasty mold | 16:30 |
| radiofree | pedroalvarez: would moving rsync to foundation make sense? | 16:30 |
| persia | And mould-related nomenclature isn't as pleasing | 16:30 |
| radiofree | it's not so much a "tool" when the upgrade process depends on it being there | 16:31 |
| Kinnison | persia: that old chestnut [mushroom] | 16:31 |
| pedroalvarez | radiofree: I agree, I was actually thinking about that | 16:31 |
| paulsher1ood | given i made the same argument about adding foundation to zookeeper systems, i have to agree :) | 16:33 |
| paulsher1ood | but can i show my ignorance, and ask... is rsync needed on both sides? if i'm upgrading a target, do i need rsync on the target, or just the host? | 16:34 |
| pedroalvarez | erm.. re foundation in zookeeper systems. Now I think that is needed, and not only for upgrades | 16:35 |
| paulsher1ood | (i appreciate that if i'm doing a self-upgrade, they're both the same) | 16:35 |
| pedroalvarez | rsync is needed on both I believe | 16:35 |
| persia | paulsher1ood: Depends how we rsync, but it is better if it is present on both sides. | 16:35 |
| * paulsher1ood thinks Krin claimed/established foundation wasn't needed | 16:35 | |
| ssam2 | rsync > 3.0.0 is GPLv3 so can't be in GENIVI baselines | 16:35 |
| pedroalvarez | ssam2: good catch | 16:36 |
| radiofree | :( | 16:36 |
| pedroalvarez | we can maybe improve the upgrade process to try rsync and if not, scp? | 16:37 |
| pedroalvarez | or another alternative? | 16:37 |
| Krin | I made no such claim. I don't know the function of foundation, so I'm going of the judgement of my better informed peers there, and added it back in with the latest of the patch series :) | 16:37 |
| pedroalvarez | Krin: without foundation, no systemd. So I believe that is needed | 16:38 |
| Krin | ahh, then yes it is indeed needed, as part of zookeeper uses systemd :) | 16:39 |
| Krin | well, part of the server implementation of zookeeper anyway | 16:39 |
| persia | rsync can work with no rsync on the remote: it is just slower. | 16:39 |
| radiofree | can we use tbdiff? | 16:39 |
| radiofree | i have no idea what tbdiff really is btw, but i seem to remember it upgrading something | 16:39 |
| radiofree | or i'm thinking of trebuchet? | 16:40 |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has joined #baserock | 16:40 | |
| ssam2 | tbdiff creates and applies binary diffs | 16:41 |
| ssam2 | trebuchet is a fuzzy name only right now I think | 16:41 |
| perryl | paulsher1ood: firehose notes are on w.b.o | 16:42 |
| paulsher1ood | ooh, cool... | 16:42 |
| paulsher1ood | http://wiki.baserock.org/firehose-notes/ | 16:42 |
| paulsher1ood | better come up with a better name *quick* or persia will be forever disgruntled | 16:43 |
| franred | I need to add psycopg2 which is a python adapter for postgresql - should I add to databases or add it to openstack which is the one which is going to use it? | 16:46 |
| persia | I might just submit the patch to name it "Lugger" or "Hod" myself. | 16:47 |
| franred | "databases.morph" and "openstack-services.morph" | 16:47 |
| paulsher1ood | openstack, franred i think? unless openstack systems already use dataases.morph? | 16:47 |
| franred | paulsher1ood, openstack system needs to use databases.morph | 16:47 |
| paulsher1ood | then databases please | 16:48 |
| pedroalvarez | franred: IMO, you shouldn't end up using databases.morph. Maybe we should create a postgres.morph stratum with postgres, dependencies, and utilities like that python library | 16:48 |
| paulsher1ood | +1 for that | 16:48 |
| CTtpollard | I'd +1 a separate postgres morph | 16:49 |
| persia | THat sounds like a better plan then | 16:49 |
| paulsher1ood | what did we decide to call foo-and-the-things-usually-needed-with-foo? | 16:50 |
| pedroalvarez | foo-utils? | 16:50 |
| * pedroalvarez is not sure | 16:50 | |
| persia | A stratum? | 16:50 |
| pedroalvarez | hahahahaha | 16:50 |
| paulsher1ood | persia: i meant naming standard. pedroalvarez may be right. or foo-tools ? | 16:51 |
| persia | I don't remember | 16:52 |
| paulsher1ood | looks like we have more *-utils than *-tools. so let's go for that? | 16:53 |
| *** Guest59245 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:53 | |
| pedroalvarez | yeah, postgres-utils sounds ok to me | 16:54 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:14 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:36 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:55 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:01 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:13 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 18:22 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:23 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:23 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:23 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 18:54 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:54 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:55 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:55 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:55 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:56 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:03 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 19:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:29 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:33 | |
| *** rdale_ [~quassel@127.Red-2-137-106.dynamicIP.rima-tde.net] has joined #baserock | 20:01 | |
| *** rdale [~quassel@166.Red-88-13-224.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:02 | |
| *** rdale [~quassel@118.Red-88-13-225.dynamicIP.rima-tde.net] has joined #baserock | 20:33 | |
| *** rdale_ [~quassel@127.Red-2-137-106.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds] | 20:36 | |
| *** rdale_ [~quassel@200.Red-83-59-206.dynamicIP.rima-tde.net] has joined #baserock | 20:44 | |
| *** rdale [~quassel@118.Red-88-13-225.dynamicIP.rima-tde.net] has quit [Ping timeout: 258 seconds] | 20:47 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 21:58 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:22 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 23:04 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 23:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 23:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 23:04 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!