| *** bjdooks_ [~ben@trinity.fluff.org] has joined #baserock | 04:30 | |
| *** radiofree_ [radiofree@unaffiliated/radiofree] has joined #baserock | 04:31 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:14 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:54 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:16 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:28 | |
| *** locallycompact [~lc@146.200.27.158] has quit [Ping timeout: 255 seconds] | 09:02 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:33 | |
| persia | I *really* like system-version-manager sometimes. Thank you very much for creating it. | 09:58 |
|---|---|---|
| paulsherwood | what is that? | 09:58 |
| persia | It's the tool that lets you select *which* version of a system you want to run by default, which system you are running now, and remove versions you don't need. | 09:59 |
| Kinnison | It's part of the upgrade stuff | 09:59 |
| paulsherwood | is it in baserock? | 09:59 |
| * Kinnison is glad persia likes it | 09:59 | |
| persia | In normal use, one does an upgrade, and removes the old version. But if something goes wrong, it's really nice to have the entire system effectively version controlled. | 10:00 |
| persia | Kinnison: Don't think I don't have opinions about the interface, or knowledge of bugs :) But yeah, the feature it provides is really nice. | 10:00 |
| Kinnison | :-) | 10:00 |
| persia | paulsherwood: Yes, it's in baserock. As far as I know, it's not anywhere else: I think it depends on the baserock system structure to work. | 10:01 |
| Kinnison | Indeed | 10:01 |
| Kinnison | it's part of the tbdiff set of tooling | 10:01 |
| paulsherwood | would it be possible to have sometging on the wiki, or a video? i seem to have missed this completely | 10:02 |
| persia | It is on the wiki: in http://wiki.baserock.org/devel-with/ | 10:04 |
| Kinnison | paulsherwood: If you want to make a video about it, I'm sure that'd be okay | 10:04 |
| persia | Specifically at the bottom of the section about "Upgrading a Baserock installation" | 10:05 |
| paulsherwood | ah, thank you. i used search on the wiki and it didn't seem to give me results - must be my lack of caffeine | 10:05 |
| persia | For video demo, a sensible model would be to download some reference devel image, branch baserock, `git pull` in definitions.git, build the updated devel image, ugprade into it, and remove the old one. | 10:05 |
| paulsherwood | Kinnison: noted :) | 10:06 |
| persia | Unfortunately, there's a bug in doing this, in that if one messes with the "factory" image, everything falls down. | 10:06 |
| persia | (and all upgrades are against "factory", rather than the currently running or current default systems) | 10:06 |
| paulsherwood | persia: isn't the point that one shouldn't ever mess with the factory image? | 10:07 |
| persia | paulsherwood: I don't understand that point, although that assumption seems to be hardcoded into the implementation. | 10:07 |
| Kinnison | persia: yeah, that's some missing config in the ssh-rsync upgrade method I'd say | 10:08 |
| persia | I really don't care which version of baserock I happened to have installed in my devel machine when I started, and I can't imagine ever caring. | 10:08 |
| paulsherwood | well this is 'traditional' embedded practice - factory is immutable, when all else fails you should definitely be able to revert to that | 10:09 |
| persia | Kinnison: Just config? I don't want to have to think about this: I just want to upgrade, and have that work. With config, I have to keep track of what I'm doing too much. | 10:09 |
| paulsherwood | maybe it's not the right idea here, but i thought it was | 10:09 |
| Kinnison | persia: Hmm, perhaps | 10:09 |
| * Kinnison doesn't want to get into this right now though | 10:09 | |
| * Kinnison goes back to integration code | 10:10 | |
| persia | For classic embedded, I can see the point, but for modern resource-constrained small-factor computing, I think we're beyond that. | 10:10 |
| * paulsherwood can't get into it either | 10:10 | |
| * persia happily goes back to the activities for which using system-version-manager was such a pleasant part of the preamble | 10:11 | |
| Kinnison | :-) | 10:12 |
| richard_maw | it's technically possible to upgrade an existing (btrfs or ext) filesystem to the layout that Baserock's upgrade tooling requires, but it would be tricky | 10:15 |
| radiofree_ is now known as radiofree | 11:55 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 14:33 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:46 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 14:49 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 15:38 | |
| bjdooks_ is now known as bjdooks | 16:26 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving.] | 16:29 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:41 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:00 | |
| tlsa | could I get a quick review for http://pastebin.com/5VtNrYKX ? | 17:00 |
| tlsa | it's a --help documentation fix | 17:01 |
| liw-orc | assuming it's correct to use the worker key, then +2 | 17:01 |
| richard_maw | +2 | 17:01 |
| tlsa | thanks | 17:01 |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 255 seconds] | 17:29 | |
| *** locallycompact [~lc@146.200.27.158] has joined #baserock | 18:16 | |
| *** locallycompact [~lc@146.200.27.158] has quit [Ping timeout: 250 seconds] | 22:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!