| *** toscalix has joined #baserock | 08:34 | |
| *** paulwaters_ has joined #baserock | 08:42 | |
| *** CTtpollard has quit IRC | 08:52 | |
| *** rdale has joined #baserock | 08:52 | |
| *** toscalix_ has joined #baserock | 08:53 | |
| *** toscalix has quit IRC | 08:53 | |
| *** CTtpollard has joined #baserock | 08:57 | |
| *** ctbruce has joined #baserock | 08:58 | |
| *** bashrc_ has joined #baserock | 09:00 | |
| tiagogomes | http://www.phoronix.com/scan.php?page=news_item&px=Booting-Linux-1-Second | 09:25 |
|---|---|---|
| pedroalvarez | interesting! | 09:35 |
| VLetrmx | [gerrit2@salo:~]$ java -jar gerrit-2.2.2.war init --batch -d ~/gerrit_testsite | 09:36 |
| VLetrmx | ... | 09:36 |
| VLetrmx | Executing /home/gerrit2/gerrit_testsite/bin/gerrit.sh start | 09:36 |
| VLetrmx | Starting Gerrit Code Review: OK | 09:36 |
| VLetrmx | ... | 09:36 |
| VLetrmx | sometimes i am a bit of a moron | 09:36 |
| *** franred has joined #baserock | 09:49 | |
| pedroalvarez | VLetrmx: no! | 09:51 |
| pedroalvarez | :) | 09:51 |
| pedroalvarez | does that mean that you gave up and you are doing it outside of baserock? | 09:51 |
| *** gtristan has joined #baserock | 09:52 | |
| VLetrmx | it could've worked in baserock really | 10:04 |
| VLetrmx | i build a devel system + java | 10:04 |
| VLetrmx | but then this simple gerrit setup still failed because we have busybox start-stop-daemon | 10:04 |
| VLetrmx | so i'm running it on my host system | 10:05 |
| pedroalvarez | much easier | 10:05 |
| *** edcragg has joined #baserock | 10:05 | |
| VLetrmx | well yes but only because we have busybox start-stop-daemon | 10:05 |
| *** ssam2 has joined #baserock | 10:06 | |
| *** ChanServ sets mode: +v ssam2 | 10:06 | |
| pedroalvarez | I don't exactly understand why that makes it fail. And if I should be worried about that as a possible error in the future in our current deployment for infra | 10:07 |
| franred | VLetrmx, I made gerrit worked in baserock, but it got removed, but maybe you can have a look how we did it in the pass | 10:10 |
| pedroalvarez | nah, go for what you are doing, and stop wasting time :) | 10:11 |
| VLetrmx | hey, my "time-wasting" gave us baserock 15.47 :p | 10:13 |
| pedroalvarez | and I really thank you for that :) | 10:14 |
| VLetrmx | :3 | 10:14 |
| persia | Happiness is a hairless yak. | 10:15 |
| rdale | i have some definitions checked out in my baserock vm, and i want to build a system from them. when i use 'morph build ...' it wants to clone a temporary copy of the original definitions repo, but i don't have permission to do that from within the vm. is it possible to tell morph to clone the local copy of defintions? | 10:20 |
| VLetrmx | if you don't have permission to clone, how did you clone the original repo? | 10:21 |
| *** Lachlan1975 has joined #baserock | 10:22 | |
| rdale | i mounted /src with sshfs and cloned it | 10:23 |
| VLetrmx | okay if you cloned over ssh, then your vm needs your public key so possibly ssh in with -A, else do a new clone over git:// or add another remote with git:// ? | 10:24 |
| VLetrmx | actually adding a new remote like that probably won't work | 10:24 |
| pedroalvarez | I agree it's confusing that `morph` needs to pull before building? | 10:24 |
| VLetrmx | you could possible set origin though | 10:24 |
| *** toscalix_ has quit IRC | 10:25 | |
| SotK | I think doing `--local-changes=include` on your morph command forces it to clone the local checkout | 10:25 |
| * SotK could be wrong | 10:25 | |
| rdale | ok, i'll try that | 10:26 |
| tiagogomes | morph clones definitions to do a checkout | 10:26 |
| tiagogomes | but it should clone from the local repo | 10:26 |
| SotK | also if you don't have all the other repos required for the build cached already you'll need to be able to clone them from the git server you're using | 10:26 |
| *** toscalix_ has joined #baserock | 10:27 | |
| rdale | using '--local-changes=include' doesn't fix it | 10:28 |
| *** toscalix_ has quit IRC | 10:44 | |
| *** gtristan has quit IRC | 11:19 | |
| *** gtristan has joined #baserock | 11:26 | |
| *** jonathanmaw has joined #baserock | 11:33 | |
| *** CTtpollard has quit IRC | 11:34 | |
| *** CTtpollard has joined #baserock | 11:35 | |
| *** toscalix_ has joined #baserock | 11:38 | |
| rdale | is there a simple way to migrate a defintions repo from version 1 to the current version for 15.47.1? | 12:26 |
| tiagogomes | rdale have you tried to run ./migrations/run-all ? That script is on the latest definitions | 12:28 |
| pedroalvarez | my approach when doing it was: | 12:28 |
| pedroalvarez | - Merge tag | 12:28 |
| pedroalvarez | - Given that merging the tag modifies the file VERSION, modifiy it again to set it to "1" | 12:28 |
| pedroalvarez | - run ./migrations/run-all | 12:28 |
| pedroalvarez | if your definitions have only a few patches on top, might be easier to rebase? | 12:29 |
| rdale | it isn't the baserock definitions repo | 12:29 |
| *** toscalix_ has quit IRC | 12:30 | |
| pedroalvarez | that's why the first step of my approach is to merge latest tag | 12:30 |
| ssam2 | i'd suggest: manually copy the migrations/ dir from git.baserock.org/baserock/baserock/definitions into your repo; run migrations/run-all; then merge latest tag of baserock definitions (if you want) | 12:31 |
| rdale | yes, that sounds a good idea | 12:31 |
| rdale | the code to migrate shouldn't belong to a specific definitions repo really - nor should it belong to a build tool if we have multiple build tools | 12:33 |
| tiagogomes | that looks the sensible approach. Maybe we should document it somewhere in definitions? | 12:33 |
| ssam2 | it should be documented in README already | 12:37 |
| ssam2 | it kind of is, but could do with tweaking if anyone has time | 12:38 |
| ssam2 | I agree that it's not ideal having the code living in our definitions repo -- just seemed the simplest means to the end at the time | 12:38 |
| rdale | in the forked repo i'm working on we've been using the master branch for changes, which seems a bad idea wrt respect to keeping it in line with the baserock master | 12:42 |
| ssam2 | yeah, i wouldn't recommend that | 12:42 |
| ssam2 | easy to fix though | 12:43 |
| ssam2 | the README should probably mention that too | 12:43 |
| rdale | ah ok | 12:43 |
| ssam2 | the same situation exists with Buildroot, but there doesn't seem to be any text in the buildroot manual that we could nick | 12:44 |
| richard_maw | note to self: Expand all in gerrit doesn't provide a unidiff of all the changes | 12:52 |
| tiagogomes | I think that if the migration scripts were in a different repo, it actually would be simpler to update some definitions | 12:53 |
| jjardon | kudos for the one that implemented a progress bar in morph! | 12:58 |
| tiagogomes | that was Mr Ipsum | 12:59 |
| ssam2 | tiagogomes: yes... i think so too | 13:00 |
| ssam2 | on reflection | 13:00 |
| *** locallycompact has joined #baserock | 13:00 | |
| * tiagogomes tries gerrit edit mode to replace "have been" by "has been" | 14:26 | |
| tiagogomes | Today is a remarkable day in Morph's history. Branch-and-merge is dead | 14:30 |
| ssam2 | wow | 14:30 |
| tiagogomes | thanks richard_maw and VLetrmx for the reviews | 14:30 |
| franred | tiagogomes, good!! | 14:31 |
| ssam2 | i think that was the first task I was given to do when joining the Baserock project :-) | 14:31 |
| ssam2 | (writing it, not killing it) | 14:31 |
| persia | tiagogomes: Thank you. | 14:31 |
| ssam2 | seemed quite a good idea at the time :-) | 14:31 |
| ssam2 | although it was a total nightmare even then, at that time you could still have an infinite number of definitions repos all pointing to different refs of each other | 14:32 |
| tiagogomes | hehe :) | 14:32 |
| tiagogomes | yeah, when the strata and systems had repo and ref | 14:32 |
| tiagogomes | well, you couldn't say that it lacked flexibility at that time :) | 14:33 |
| tiagogomes | s/couldn't/can't | 14:33 |
| VLetrmx | "+[[change.submitWholeTopic]]change.submitWholeTopic (*Experimental*)::" | 14:50 |
| VLetrmx | yes! | 14:50 |
| rdale | when i try to build a system in my forked definitions repo, i get an error about cloning a lorry repo: http://paste.baserock.org/joceyocole | 14:53 |
| richard_maw | VLetrmx: wassat mean? | 14:53 |
| VLetrmx | for those interested, we're now down to 23,000 lines from 25,000 according to sloccount | 14:53 |
| rdale | do i need to specify a local lorry in morph.conf or some other config file? | 14:53 |
| VLetrmx | richard_maw, seems gerrit has an experimental feature for submitting entire topics | 14:54 |
| ssam2 | rdale: seems that the definitions are referring to a ref that doesn't exist in your Trove's version of baserock/baserock/lorry.git | 14:54 |
| ssam2 | could it be that your mirror is out of date? | 14:54 |
| ssam2 | fwiw that commit is the latest one on git.baserock.org: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/commit/?id=d64da0cb16679f0791077ff5e1f9d03fa16a745f | 14:55 |
| rdale | i don't know how the mirrored lorry repo is kept in step with the baserock one, or how often | 14:55 |
| rdale | i rebased the local definitions repo on the upstream baserock definitions repo. but i see that sha1 in the definitions repo: ./strata/lorry.morph: ref: d64da0cb16679f0791077ff5e1f9d03fa16a745f | 14:57 |
| pedroalvarez | which is: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/commit/?id=d64da0cb16679f0791077ff5e1f9d03fa16a745f | 14:58 |
| pedroalvarez | and exists | 14:58 |
| VLetrmx | ( https://gerrit.googlesource.com/gerrit/+/master/ReleaseNotes/ReleaseNotes-2.12.txt ) | 15:01 |
| pedroalvarez | 'New change submission workflows, "Submit Whole Topic" and "Submitted Together"' | 15:04 |
| tiagogomes | VLetrmx 23,000 is still a lot :| | 15:11 |
| pedroalvarez | I will need to tweak some scripts that use morph-edit | 15:13 |
| rdale | the last commit in my local version of baserock:baserock/lorry with a missing sha1, was 10th november - has something changed since then | 15:14 |
| pedroalvarez | rdale: yes, I linked the commit before | 15:15 |
| pedroalvarez | I looked at the trove you are using and looks like it's lorrying slowly things | 15:15 |
| VLetrmx | tiagogomes, i guess we can improve | 15:16 |
| rdale | ah ok, it's a couple of weeks behind | 15:16 |
| VLetrmx | speaking of which is there any reason we still have the exts in morphlib? | 15:16 |
| pedroalvarez | rdale: that commit was done yesterday I believe | 15:16 |
| SotK | VLetrmx: I left them there for backwards compatibility ages ago, and never had time to get rid of them | 15:17 |
| pedroalvarez | nuke them!!!!!! | 15:17 |
| rdale | pedroalvarez: i assume there were lots of other commits between 10-24th november, which i'm not getting | 15:17 |
| pedroalvarez | rdale: oh, i thought you were referring to commits in lorry.git | 15:18 |
| pedroalvarez | sorry | 15:18 |
| VLetrmx | SotK, okay, it should be safe to get rid of them now, given we only support versions 6 and 7 | 15:18 |
| ssam2 | VLetrmx, SotK: it might be good to do a migration for the exts.. although that boat has kind of sailed already | 15:18 |
| ssam2 | so never mind | 15:18 |
| SotK | I thought we did make it need a new version? | 15:19 |
| ssam2 | anyone who hasn't updated the 'configure-extensions' and deployment 'type' fields to prepend 'extensions/' to all of them will have already got weird errors | 15:19 |
| ssam2 | SoTK: i don't think so | 15:19 |
| rdale | pedroalvarez: yes, it is a commit in lorry.git, but my cloned cached version doesn't have any commits after 10th november | 15:19 |
| SotK | perhaps we hijacked a different version number and didn't put it in the migration though | 15:19 |
| VLetrmx | that's a good point | 15:19 |
| ssam2 | yeah, see: http://wiki.baserock.org/definitions/historical/ | 15:20 |
| ssam2 | version 5 *allows* new-style extensions, but we never officially *disallowed* the old style | 15:20 |
| ssam2 | even though the old style is actually broken | 15:20 |
| ssam2 | so, whatever, things already broke | 15:20 |
| jjardon | Hi, Im getting this error when loggin in baserock wiki through openid: "Error: OpenID failure: naive_verify_failed_return: Direct contact invalidated ID provider response. " known bug? | 15:24 |
| pedroalvarez | which openid? | 15:25 |
| jjardon | launchpad | 15:25 |
| pedroalvarez | hm.. idk | 15:27 |
| pedroalvarez | that should work | 15:27 |
| pedroalvarez | jjardon: that just workedfor me | 15:33 |
| * tiagogomes never tried logging in to the wiki with OpenID | 15:35 | |
| jjardon | pedroalvarez: with a OpenID launchpad provider? | 15:36 |
| pedroalvarez | yes | 15:37 |
| pedroalvarez | ( https://launchpad.net/~palvarez89 ) | 15:37 |
| jjardon | pedroalvarez: it doesnt here: Imactually getting another error now: "Error: OpenID failure: time_bad_sig: Return_to signature is not valid." | 15:40 |
| pedroalvarez | :( | 15:40 |
| jjardon | :(( I will try the mail login | 15:41 |
| pedroalvarez | or baserock openid! | 15:43 |
| *** franred has quit IRC | 15:49 | |
| tiagogomes | It worked for me | 15:53 |
| pedroalvarez | jjardon: oh, thats because we banned you from editing the wiki! | 15:55 |
| pedroalvarez | (jk) | 15:55 |
| tiagogomes | morph help tar.write is giving me a stacktrace | 16:08 |
| VLetrmx | helpful | 16:08 |
| tiagogomes | :) | 16:09 |
| tiagogomes | sighs, when I try to fix one thing, I find out more things to fix | 16:09 |
| VLetrmx | heh | 16:12 |
| gtristan | So I think this is a bug but I'm not sure... I have pulseaudio's system integration hooks running twice | 16:15 |
| gtristan | gnome.morph pulls in audio-bluetooth.morph and also pulls in multimedia-gstreamer.morph, which also pulls in audio-bluetooth.morph | 16:15 |
| gtristan | then I get errors in my new system integration hooks saying the pulse user already exists | 16:16 |
| pedroalvarez | hm... this might be a bug in ybd | 16:16 |
| gtristan | so what is the bug ? is gnome.morph at fault for redundantly pulling in audio-bluetooth ? | 16:16 |
| pedroalvarez | I actually don't know how that is done in ybd | 16:16 |
| gtristan | maybe that | 16:17 |
| pedroalvarez | I implemented that in morph | 16:17 |
| perryl | i've pushed a quick change to my cgit filter patches...apologies for not being too visible in here, i've been bogged down trying to get the URL redirect working! i'm away for the next two weeks so won't be able to implement any changes until mid December probably... | 16:19 |
| *** toscalix has joined #baserock | 16:19 | |
| gtristan | now, will removing the audio-bluetooth.morph reference in gnome.morph cause a webkit rebuild... | 16:19 |
| jjardon | I think there is not a bug in the definitions: gnome depens on those 2 stratum because the components in gnome depends on stuff present on those stratums; I prefer to be explicit than implicit in the dependencies | 16:19 |
| jjardon | gtristan: yes | 16:19 |
| *** gtristan has quit IRC | 16:21 | |
| *** gtristan has joined #baserock | 16:22 | |
| ssam2 | yeah, seems like ybd is wrong to me | 16:24 |
| gtristan | holy crap | 16:25 |
| gtristan | removing audio-bluetooth.morph from the dependency list of gnome.morph causes a rebuild | 16:25 |
| * gtristan facerock | 16:25 | |
| pedroalvarez | faceybd | 16:25 |
| gtristan | that is certainly a bug | 16:25 |
| SotK | why is that a bug? | 16:26 |
| pedroalvarez | I can explain how it works in morph | 16:26 |
| * tiagogomes heard that morph is getting in shape | 16:26 | |
| gtristan | SotK, because multimedia-gstreamer.morph also depends on audio-bluetooth | 16:26 |
| pedroalvarez | oh yes indeed, this shouldn't trigger a rebuild | 16:27 |
| gtristan | so gnome.morph builds exactly the same thing with or without explicitly mentioning that dependency | 16:27 |
| SotK | ah, sounds like ybd is confused a bit there then | 16:27 |
| gtristan | nod | 16:27 |
| pedroalvarez | but but | 16:27 |
| pedroalvarez | I believe that the cache key is calculated with the contents of the yaml file | 16:27 |
| pedroalvarez | morph file | 16:27 |
| gtristan | pedroalvarez, that cannot be exactly true | 16:27 |
| pedroalvarez | idk to be honest :S | 16:27 |
| gtristan | I think it takes into account the content of build & install commands | 16:28 |
| gtristan | but conveniently does not change for system-integration hooks | 16:28 |
| gtristan | since those do not require rebuilds | 16:28 |
| pedroalvarez | they do require rebuilds in morph | 16:28 |
| gtristan | ouch | 16:28 |
| pedroalvarez | (but they might be different implementations) | 16:28 |
| * gtristan found that to be quite convenient ;-) | 16:28 | |
| * richard_maw double checks whether system-integrations are included in the cache keys | 16:29 | |
| pedroalvarez | richard_maw: they are part of the chunk artifact, so they should be in the cache key | 16:29 |
| * richard_maw thought we stopped doing the implementation that dropped files in /baserock somewhere | 16:30 | |
| richard_maw | at which point they have no effect on the chunk itself | 16:30 |
| pedroalvarez | richard_maw: it seems that was done in ybd | 16:30 |
| gtristan | pedroalvarez, morph runs system integration hooks on each artifact ? | 16:30 |
| gtristan | pedroalvarez, not the case in ybd, only runs all system integration at the end | 16:30 |
| pedroalvarez | gtristan: no, morph generates scripts in /baserock/system-integration, for every chunk that has some of them. And then at the end, morph executes all of them | 16:31 |
| richard_maw | pedroalvarez: it used to at least, can't remember if it still does that | 16:31 |
| richard_maw | ah, I changed it to not use run-parts, I didn't change it to not run the scripts | 16:32 |
| * richard_maw got confused as to whether these were changes he wanted to make or changes he had made | 16:32 | |
| pedroalvarez | right so it's almost the same | 16:32 |
| *** toscalix_ has joined #baserock | 16:35 | |
| *** toscalix has quit IRC | 16:35 | |
| *** gtristan has quit IRC | 16:42 | |
| *** gtristan has joined #baserock | 17:01 | |
| gtristan | hmmm, scratch that it's actually not a bug in ybd | 17:02 |
| gtristan | for "some reason" the pulse user/group exists already, I suspect that pulse make install did something | 17:02 |
| gtristan | not sure what | 17:02 |
| gtristan | but system-integration does not run twice, anyway | 17:03 |
| richard_maw | IMO it's a deficiency in morph, since it doesn't *have* to make system-integration commands part of the key, as you can implement it without putting data in the artifact. | 17:03 |
| gtristan | richard_maw, right we're talking about two separate things though | 17:03 |
| richard_maw | so we are! | 17:04 |
| * richard_maw got confused | 17:04 | |
| gtristan | the bug I suspected existed in ybd, was that if you indirectly depended on the same strata twice, system integration would run twice | 17:04 |
| gtristan | :) | 17:04 |
| richard_maw | ah | 17:04 |
| pedroalvarez | gtristan: right, look at this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/fhs-dirs.git/tree/passwd | 17:09 |
| *** ssam2 has quit IRC | 17:14 | |
| * gtristan looks | 17:18 | |
| gtristan | aha | 17:18 |
| gtristan | pedroalvarez, probably best to factor that out eventually ? | 17:19 |
| *** ctbruce has quit IRC | 17:19 | |
| jjardon | this is exactly the reason why I suggested this https://gerrit.baserock.org/#/c/563/ | 17:19 |
| pedroalvarez | gtristan: note that changes there will trigger a full rebuild :) | 17:20 |
| gtristan | pedroalvarez, bah, rebuilds are ok in the winter time | 17:20 |
| pedroalvarez | I think that "creating users" is a topic that we need to discuss | 17:20 |
| pedroalvarez | users, and ownership of files, etc | 17:20 |
| gtristan | I think clearly its more desirable if everything is cleanly split into their own components/chunks | 17:21 |
| gtristan | probably we want to abolish install-files and the like as well | 17:22 |
| gtristan | even in those odd cases where the files one needs is not provided by an upstream repo, that would be more cleanly handled by a chunk that does not build a repo | 17:23 |
| gtristan | jjardon, I still have a browser tab open on that systemd thingamajig | 17:24 |
| gtristan | I dont particularly like it mostly because I dont like the idea of tying down definitions to be 'systemd only' | 17:25 |
| VLetrmx | which is where richard_maw's multiple sources could come in | 17:25 |
| VLetrmx | since you'd just have a chunk that doesn't define a source | 17:26 |
| gtristan | in any case, it's a little orthogonal, because whether a user is created in a system-integration hook with useradd, or by installing some systemd-foo and expect systemd to create it... it can be done in the respective chunk | 17:26 |
| gtristan | VLetrmx, yes that is a good thing, and elegantly handles the git submodules problem as well | 17:27 |
| pedroalvarez | The thing is that in the sandbox environment we can't set ownership on file, and thus, creating users might be impossible | 17:28 |
| pedroalvarez | at least with linux-user-chroot in Morph | 17:28 |
| gtristan | pedroalvarez, then gnome is broken in morph ? | 17:28 |
| pedroalvarez | creating a file for systemd to make it create the user later "solves" this limitation | 17:29 |
| gtristan | pedroalvarez, it heavily relies on the useradd/groupadd statements in the existing system-integration hooks | 17:29 |
| pedroalvarez | gtristan: I don't think so given that Mason has been building it | 17:29 |
| pedroalvarez | gtristan: I guess that if you are not creating home folders for them, then it doesn't fail | 17:29 |
| gtristan | one thing we cannot do reliably it seems though, is file capabilities | 17:29 |
| VLetrmx | rjek suggested fakeroot for that | 17:29 |
| gtristan | setcap in a system-integration hook doesnt work, but would be nice to have that work | 17:29 |
| pedroalvarez | see, all these things we need to discuss :) | 17:30 |
| richard_maw | gtristan: unless tar records file capabilities, I'm not sure there's any value in doing so | 17:31 |
| gtristan | I dont believe tar does that, I'm just noting that it's something one typically needs to do when installing some software | 17:32 |
| gtristan | something we have no present solution for | 17:32 |
| richard_maw | I think it's something not supported in package based systems either generally, I heard debs would strip all that out anyway and require a post-install script to sort out permissions | 17:33 |
| richard_maw | (for us that would have to be a first-boot thing) | 17:33 |
| gtristan | richard_maw, right, it's supported by debian as post scripts - which is something we dont really have | 17:34 |
| gtristan | unless I'm unaware of something that does exist ;-) | 17:34 |
| gtristan | but I think we stop at the image, once the image is created there is nothing that runs on the system for integration in a first-boot scenario or such | 17:35 |
| richard_maw | hm, it'd have to be a disk image creation hook or first-boot | 17:35 |
| *** locallycompact has quit IRC | 17:36 | |
| richard_maw | hmm, doing it on first boot would be incompatible with having an immutable /usr mount too… | 17:38 |
| *** tiagogomes has quit IRC | 17:38 | |
| gtristan | richard_maw, well, it's not a fire "right now" until it becomes one... I think this system-integration in general probably "should" be run in a live system, and that is probably something to consider when thinking of the distribution/upgrade problem | 17:39 |
| * richard_maw doesn't want deployers to have to run code from the system they are deploying | 17:41 | |
| gtristan | sheesh, lots of problems to solve huh... if we actually had to upgrade live systems, we would then need system-unintegration hooks ! | 17:41 |
| persia | Debian's "post-install" maintainer script content is usually Baserock's "system-integration" script. | 17:41 |
| persia | first-boot stuff is different (and exists for both Debian and Baserock, so that a single image can have multiple instantiations safely) | 17:41 |
| persia | gtristan: Why system-unintegration? | 17:41 |
| gtristan | persia, for when we upgrade a system to a version which say, no longer includes chunk "foo", but chunk "foo" has left some debris via it's integration hook | 17:42 |
| gtristan | or, just for a reliable upgrade path for the same chunk "foo", to cleanly uninstall the older version before integrating the new one | 17:43 |
| persia | gtristan: Ah, right. | 17:43 |
| richard_maw | atomic updates | 17:43 |
| * richard_maw hides | 17:43 | |
| persia | https://wiki.debian.org/MaintainerScripts documents the set of scripts Debian supports | 17:43 |
| pedroalvarez | yeah, I think our upgrades handle that case, we don't need system-unintegration things | 17:45 |
| gtristan | hmmm, 20 odd GB of free space is not enough to deploy a 6GB gnome image :-/ | 17:45 |
| persia | I thought we fixed that: it used to take 3+ copies to deploy, but isn't it down to 2 now? | 17:46 |
| gtristan | not sure... ybd here... | 17:46 |
| * gtristan just hit 2 'no space left on device' errors in a row, made some more space now I have 30GB | 17:47 | |
| *** toscalix_ has quit IRC | 17:49 | |
| *** gtristan has quit IRC | 17:49 | |
| *** jonathanmaw has quit IRC | 18:00 | |
| *** bashrc_ has quit IRC | 18:07 | |
| *** rdale has quit IRC | 18:51 | |
| *** Lachlan1975 has quit IRC | 19:35 | |
| *** edcragg has quit IRC | 19:40 | |
| *** edcragg has joined #baserock | 22:57 | |
| *** edcragg has quit IRC | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!