[00:05] <rbasak> nacc: it sounds like zabbix-frontend-php shouldn't depend on a DB at all. Can't it leave that for zabbix-server-* to pull in?
[00:06] <rbasak> Oh, that maybe won't fully work.
[00:10] <mwhudson> nacc: will leave it for sponsors then
[00:10] <nacc> rbasak: it doesn't depend itself
[00:11] <nacc> rbasak: the issue is that to use a db with zabbix, you'd install either zabbix-server-<db> or zabbix-proxy-<db>, i think
[00:11] <nacc> that determines, in turn what php-<db> package should be installed
[00:11] <nacc> but afaict, there's no way to communicate those kind of interdependencies
[00:12] <nacc> so you'll just get pgsql not knowing you need to `apt install zabbix-frontend-php php-mysql` if you previously `apt install zabbix-server-mysql`
[00:15] <nacc> rbasak: it's not a serious issue, per se, but i was just curious if there were ways to fix that, as for instance if i had installed zabbix-server-mysql first, then installing php-pgsql won't help me at all with the web ui :)
[00:15] <nacc> mwhudson: woo, tests passed, uploading debdiff
[00:19] <mwhudson> nacc: debdiff? isn't there a new orig?
[00:20] <wgrant> pitti: Huh, are you sure you're logged in correctly? That option is still there, and nothing related has changed in years.
[00:26] <nacc> mwhudson: yeah, sorry, not a debdiff, i just uploaded a new debian tarball
[00:26] <nacc> mwhudson: and new orig comes from `uscan`
[00:37] <mwhudson> nacc: i think the version number should perhaps be 7.0.8-0ubuntu0.16.04 ?
[00:37] <mwhudson> er with another .1 on the end
[00:39] <nacc> mwhudson: i wasn't sure how that worked with MREs. You are right, though, that probably matches better (my undersatnding for the above strings was specifically for backporting a version from Y to X, for instance). In this case, the packaging is the same but we're updating the orig tarball
[00:40] <nacc> i'll review the security team page again, though, please put an update in the bug, if you don't mind?
[00:41] <mwhudson> well i'm fairly new at this too :)
[00:44] <mwhudson> nacc: uploaded https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[00:45] <nacc> mwhudson: thank you very much!
[00:45] <nacc> rbasak: LP: #1569377 for reference
[00:46] <mwhudson> nacc: i guess it's worth mentioning https://launchpad.net/bugs/1596735 on the sru bug too?
[00:46] <mwhudson> er i guess i can do that
[00:48] <nacc> mwhudson: thanks, i can do it if you're otherwise occupied, i should have done that already, my fault
[01:14] <mwhudson> nacc: done
[01:45] <nacc> mwhudson: thanks again!
[02:01] <Logan> nacc: yeah, apt unfortunately doesn't support variants of packages
[02:02] <Logan> or at least that kind of dependency handling, AFAIK
[02:04] <Logan> nacc: well, I guess you could do a debconf kinda thing after install of the frontend to choose which PHP DB connection to install
[02:04] <Logan> but that's gross
[03:40] <mwhudson> dbconfig-common!
[03:40] <mwhudson> and yes, it's horrible
[04:45] <cpaelzer> good morning
[06:10] <smb> cyphermox, uh erm, there is still something wrong with grub-efi-amd64-signed in trusty. I think it is that it still depends on the wrong version: apt-cache info: grub-efi-amd64-signed(1.34.11+2.02~beta2-9ubuntu1.8) depends on grub-efi-amd64 (= 2.02~beta2-9ubuntu1.8) but grub-efi-amd64 in trusty-proposed is 2.02~beta2-9ubuntu1.9
[06:11] <smb> ^ that is all with proposed enabled
[06:38] <pitti> Good morning
[06:40] <pitti> wgrant: I just tried to log out and back in, same result -- no boxes
[06:40] <pitti> wgrant: I'd like to mark yesterday's as current as I uploaded it
[06:55] <wgrant> pitti: What is on the page for you?
[06:59] <pitti> wgrant: http://picpaste.com/p-rA9K20PS.png
[07:02] <wgrant> pitti: ah, I think it's because there's no driver set on xenial (or yakkety)
[07:03] <wgrant> The other series are ~ubuntu-release, which will give you launchpad.TranslationsAdmin. As it stands you only have launchpad.LanguagePacksAdmin on xenial.
[07:04] <pitti> wgrant: that sounds like a bug, no? that's clearly langpack admin, not release engineering
[07:11] <wgrant> pitti: It is probably a bug, but it's a very deliberate one. And regardless, much faster and easier to fix by fixing the series config.
[07:12] <pitti> https://launchpad.net/ubuntu/wily/ keeps timing out, but https://launchpad.net/ubuntu/xenial/ has "Drivers: Ubuntu drivers"
[07:12] <pitti> oh, you mean the missing "Release manager:" I suppose
[07:13] <pitti> ah, /wily loads now, that has ~ubuntu-release indeed
[07:14] <pitti> slangasek: can you please set the release manager to ~ubuntu-release on https://launchpad.net/ubuntu/xenial/ and https://launchpad.net/ubuntu/yakkety/ ?
[07:14]  * pitti supposes that this needs ~techboard powers
[07:15] <wgrant> I believe that is correct.
[07:49] <caribou> pitti: last week, you rejected the SRU for LP: #1529815 since LP: #1568485 was v-failed but bdmurray reverted it back to v-needed
[07:54] <pitti> caribou: ... and?
[07:54] <caribou> pitti: looks like it was not a regression so I don't understand why I'd need to remove the patch
[07:55] <pitti> caribou: right, in this case the ", or..." part would apply :)
[07:55] <caribou> pitti: I don't mind waiting until the first one go through
[07:55] <pitti> caribou: yeah, it's blocked by verification of this bug either way, so the fastest way forward would be to verify this
[07:56] <caribou> pitti: true, I'll look that up
[07:56] <pitti> alternatively you can upload a new one with -V that includes the previous update, then the other fixes can be tested in parallel
[07:56] <pitti> (but that bug still needs to be verified of course)
[07:56] <caribou> k
[08:31] <caribou> pitti: wait I'm not sure I'm following you : what you mean by -V ?
[08:33] <pitti> caribou: dpkg-buildpackage's (or gbp buildpackage etc.) -V4.3.3-5ubuntu12 so that the previous changelog (current version in -proposed) is included into the .changes; same as you do for merges
[08:33] <caribou> pitti: ah ok got it
[08:35] <cjwatson> pitti: that's -v
[08:35] <pitti> err yes, that, sorry
[08:57] <apw> cyphermox, grub2-signed> of course uploading grub2-signed did not help, as the custom upload in question is broken and comes from grub2
[08:58] <apw> cyphermox, so we likley need to upload grub2, or stop grub2-signed using current when it knows which version it is wanting
[09:06] <caribou> pitti: Is foundation taking care of the desktop installer ?
[09:06] <pitti> caribou: yes, mostly cyphermox
[09:06] <caribou> pitti: thought so
[09:07] <caribou> I think I found a bug that got me to reinstall my laptop 3 times yesterday : LP: #1596599
[09:07] <caribou> cyphermox: ^^^
[11:32] <mdeslaur> @pilot in
[11:52]  * dholbach hugs mdeslaur 
[11:52]  * mdeslaur hugs dholbach
[11:53] <dholbach> :-)
[12:07] <justxux> Some hugging party other here :D
[12:10] <apw> cyphermox, ok we've played with grub2 and the practicle upshot is a no-change rebuild is the best way out; i am getting that done now
[12:12] <cjwatson> Odd_Bloke: Can you point me to current-ish cloud image build logs for xenial?  None of the livefs objects I can find on LP seem very current
[12:14] <Odd_Bloke> cjwatson: https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc/+build/66749 is the latest amd64; don't know if you'll have permissions on that though.
[12:23] <tsimonq2> justxux: https://www.youtube.com/watch?v=4jzGIaZcGcM
[12:23]  * tsimonq2 hides
[13:27] <justxux> justxux is glad that everyone had a hug
[14:11] <xnox> as per https://github.com/zyga/os-release-zoo/tree/master/ubuntu kylin has modified os-release file... i thought that is not allowed.
[14:11] <xnox> Laney, cjwatson ^
[14:17] <Laney> That is the least of it
[14:17] <Laney> Or was the last time I had a reason to look
[14:30] <cpaelzer> hi, I'm wondering what of a package delta to send to debian to shrink delta - I was wondering are they usually interested in stuff like apport hooks or ufw profiles?
[14:30] <cpaelzer> or is any of that too ubuntu'ish
[14:31] <cpaelzer> I almost expect an "it depends on the maintainer of the package" answer, but it is certainly better to ask first
[14:31] <pitti> cpaelzer: Debian does have apport, but it has a fairly niche existence
[14:31] <pitti> pretty well the same thing with ufw
[14:31] <pitti> so I guess both can be justified, and as you say it depends on the maintainer; certainly not unreasonable to at least propose it
[14:31] <cpaelzer> pitti: thanks for the feedback, I can easily throw it there and let them decide - but now I know what to expect
[14:31] <pitti> if the maintainer is nice, it can also be installed iff dpkg-vendor --is ubuntu
[14:32] <jdstrand> ufw is used in Debian and isn't Ubuntu-specific
[14:32] <Laney> lxc
[14:32] <Laney> hello12
[14:32] <Laney> ssh x
[14:32] <jdstrand> it is opt in of course, but I doubt you'd have any political issues
[14:32] <pitti> Laney: you have an exceptionally bad password
[14:32] <Laney> haha
[14:32] <Laney> that's my vm password
[14:32] <Laney> but why did that happen????????????????????????
[14:33] <Laney> it's typing into multiple windows
[14:33]  * pitti quietly disables the IRC keylogger again
[14:33] <Laney> wtf
[14:33] <pitti> Laney: iz GTK bug!
[14:33] <Laney> oh terminator "broadcast all"
[14:33] <Laney> SIGH
[14:34] <Laney> at least I only have to change it in one place :)
[14:34] <Laney> that VM is routeable
[14:34]  * Laney makes sure it's not broadcasting before doing that
[14:34]  * Unit193 tries hello13
[14:34] <Laney> goodbye12
[14:34] <Laney> CRAP
[14:35] <Laney> and I just mistyped the new one three times in a row
[14:35] <Laney> this is going to be fun
[14:36]  * pitti just uses "a" as VM passwords, do I win the laziness crown?
[14:36] <Laney> that ^ was my password on the first PDAish thing I got when I was 12
[14:36]  * Laney used it for nostalgia purposes
[14:38] <Laney> http://old-organizers.com/MorePicts/MP185.htm
[14:40] <pitti> I had a PalmPilot III
[14:42] <Saviq> lool, hey, seeing as you're the latest who touched doxyqml in Debian, any chance you would have time to update it to a newer version http://agateau.com/projects/doxyqml/ ?
[14:43] <LocutusOfBorg> pitti, can you please make testsuite of opencv run against auto-multiple-choice and visp / proposed?
[15:14] <stgraber> pitti: hey, any idea where the debug symbols for lxd 2.0.2-0ubuntu1~16.04.1 in xenial are?
[15:14] <stgraber> pitti: not seeing them on ddebs
[15:14] <stgraber> pitti: https://github.com/lxc/lxd/issues/2160
[15:19] <LocutusOfBorg> stgraber, I see them https://launchpad.net/ubuntu/xenial/+package/lxd-dbgsym
[15:19] <stgraber> LocutusOfBorg: yeah but they're not on ddebs.u.c
[15:20] <LocutusOfBorg> not sure, maybe the mirror didn't keep up with the new uploads?
[15:21] <stgraber> yeah, not sure, that's why I pinged pitti. That upload happened a few weeks back, so you'd think it'd be there by now :)
[15:21] <stgraber> oh, that was a security upload, maybe that's somehow confusing something?
[15:21] <cjwatson> ddeb-retriever has been having trouble for a while though I can't remember quite how long
[15:21] <cjwatson> I killed it today to see if it'll catch up
[15:21] <stgraber> ah good to know, thanks
[15:22] <cjwatson> http://ddebs.ubuntu.com/dists/xenial-updates/ says 31 May so ...
[15:22] <cjwatson> at one point it was having trouble because it didn't have permission to fetch one of the files it wanted; I never had a chance to dig into it
[15:25] <Saviq> slangasek, hey, any chance someone could please look at bug #1585517
[15:27] <LocutusOfBorg> jbicha, abiword uploaded on deferred/2
[15:27] <LocutusOfBorg> :)
[15:28] <nacc> Logan: mwhudson: yeah, i was really hoping to avoid dealing with dbconfig-common again. We could do something smarter, though, I think, it's a valid bug/feature request. Right now, it just ends up broken for a less-than-obvious reason
[15:28] <LocutusOfBorg> ubuntu built it :)
[15:30] <Saviq> lool, if you do find time to bump doxyqml, Multi-Arch: foreign would be nice to have (bug #1585517)
[15:32] <mdeslaur> @pilot out
[15:51] <semiosis> hi again.  any suggestions on how I can encourage a review of my merge proposal?  https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
[15:51] <semiosis> or help set my expectations for how long this might be sitting around?
[16:12] <Odd_Bloke> semiosis: Thanks for taking the time to figure that all out!  I'm reviewing it now (though I don't have permissions to actually do the merge).
[16:12] <semiosis> Odd_Bloke: awesome!  thank you
[16:13]  * ogra_ thinks it would really be nice if people could use POSIX shell for patches to official code ... instead of bash
[16:15] <Odd_Bloke> semiosis: Have you been able to test that this builds?  (And how?)
[16:16] <semiosis> hmm good question.  i'll comment on the merge proposal with test instructions
[16:17] <semiosis> i tested it on xenial, building xenial. it works, and solves all problems with the vagrant box i'm aware of
[16:24] <Odd_Bloke> cjwatson: FYI, those initrd changes aren't going to make it in to our yakkety images until we get https://code.launchpad.net/~cloudware/livecd-rootfs/image-consolidation/+merge/297041 merged (so we aren't forked from lp:livecd-rootfs).
[16:24] <Odd_Bloke> (infinity: slangasek: ^)
[16:29] <semiosis> Odd_Bloke: instructions -- https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305/comments/768010
[16:29] <Odd_Bloke> semiosis: Thanks!
[16:30] <semiosis> you're welcome
[16:30] <Odd_Bloke> semiosis: At a high-level, LGTM, I'll give it some actual testing tomorrow, probably. :)
[16:30] <semiosis> sweet!
[16:37] <cjwatson> Odd_Bloke: ah, is there a similar live-build fork for xenial images?
[16:37] <cjwatson> Odd_Bloke: (also, not totally clear on how the existence of a livecd-rootfs fork is relevant to my live-build SRU, but I may be missing something)
[16:39] <kilbith> hello, someone can explain me why the bloated package 'fonts-noto-cjk' is installed by default on ubuntu ?
[16:40] <kilbith> apparenthy these are the chinese/japanese/korean fonts, but would i care if i'm european ?
[16:40] <kilbith> this is a bit painful to download 75 MB whenever i update whereas these fonts aren't used by me
[16:40] <ogra_> kilbith, because your browser might open chinese pages and you dont want weird squares scttered all over it
[16:41] <kilbith> ... but i don't read chinese :/
[16:41] <ogra_> nothing stops you from uninstalling that package
[16:41] <kilbith> sure, i'm just questioning why it's installd by default for non-chinese people
[16:42] <dobey> becasue not everyone is you
[16:42] <dobey> the same reason many things are installed by default. to make the system useful to the widest group of people
[16:42] <tgm4883> ogra_: would that be necessary for the in browser translations such as in google chrome?
[16:43] <ogra_> tgm4883, no idea, but it iss necessary for showing the chars in any case ...
[16:43] <dobey> chinese fonts are more useful to me than some of the applications installed by default, so i uninstalled those applications
[16:43] <ogra_> if someone with a chinese name sends you an email his name will appear in chinese inn your mail app
[16:43] <tgm4883> dobey: I think the question is more, if ubiquity knows where i'm located and my language, why install the package?
[16:43] <ogra_> if you dont have any chinese fonts installed you just get broken squares
[16:44] <nacc> it sounds like, so that *if* you run into any chinese characters in your usage of Ubunut, it will display properly
[16:44] <ogra_> tgm4883, because the internet is intenational
[16:44] <dobey> tgm4883: because chinese characters don't care what your locale or native language are
[16:44] <nacc> given the population sizes, it seems like it could happen :)
[16:44] <cjwatson> Lots of these things are trade-offs; making the livefs as universally useful as possible + making installation quick tends to imply keeping it on the installed system, but there's frequently room for changing font selection etc.
[16:45] <dobey> i see han characters all the time, in my daily usage of the internet
[16:45] <slangasek> pitti: release-manager> fixed, strange that this isn't a default?
[16:45] <ogra_> i'm pretty sure fnts are usually just recommends, so you should always be able to uninstall them without doing much harm
[16:45] <ogra_> *fonts
[16:45] <nacc> this one in particular definitely is
[16:45] <dobey> ogra_: most things are just recommends :)
[16:45] <ogra_> yeah
[16:46] <cjwatson> slangasek: it's part of the NewReleaseCycleProcess
[16:46] <cjwatson> apparently not followed to the letter here
[16:46] <cjwatson> at least I thought it was ... maybe not?
[16:47] <Odd_Bloke> cjwatson: We use recipes to integrate the partner-specific changes which aren't public domain; these are based on bzr branches.  We currently just have a fork of lp:livecd-rootfs as of xenial release for that recipe.
[16:47] <cjwatson> Odd_Bloke: right, so that doesn't relate to my change, I think
[16:47] <Odd_Bloke> Oh, it is in live-build, right?
[16:48] <cjwatson> Odd_Bloke: though if it might be possible to copy live-build from xenial-proposed into the base PPA for your livefs builds, that would be a great way for us to supply QA
[16:48] <Odd_Bloke> I think we only do this for livecd-rootfs.
[16:48] <Odd_Bloke> So live-build should come from the archive.
[16:48] <cjwatson> Odd_Bloke: right, but you have a private PPA that you could copy-package it into if I succeed in persuading you that that's sensible
[16:49] <slangasek> Saviq: bug #1585517> so, apparently someone dropped the Ubuntu patch to apt that would let us build-depend on arch: all packages without having to annotate every single one as M-A: foreign?
[16:51] <cjwatson> Odd_Bloke: (just in order that we can get this into cloud images faster and thus unblock xenial on LP builders)
[16:51] <Odd_Bloke> cjwatson: You mean before it lands in xenial-updates?
[16:52] <Odd_Bloke> (In a meeting, apologies if I'm being nonsensical)
[16:53] <cjwatson> Odd_Bloke: right - I already did https://launchpad.net/~cjwatson/+livefs/ubuntu/xenial/cpc-experimental/+build/66852 to check that it basically worked and produced what looked like sensible results, though I didn't actually try booting that
[16:53] <cjwatson> Odd_Bloke: since in order to get it into xenial-updates we have to QA it somehow anyway
[16:54] <Saviq> slangasek, could be, it works in vivid still
[17:02] <Odd_Bloke> cjwatson: Kicking it around with the team; if we were happy, how would we copy from -proposed?
[17:03] <cjwatson> Odd_Bloke: copy-package --from ubuntu --from-suite xenial-proposed --to ppa:cloudware/ubuntu/cpc-livecd-rootfs --to-suite xenial --include-binaries live-build
[17:05] <Odd_Bloke> cjwatson: Cool; copy requested.
[17:05] <cjwatson> thanks!
[17:22] <nacc> mdeslaur: thanks for the feedback, updated debdiff and submitted that part to debian
[17:22] <mdeslaur> nacc: cool, thanks! :)
[17:53] <tgm4883> nacc: you're aware that's the same guy about RAID in -server right?
[17:54] <tgm4883> nacc: nry2 is hanktheai
[17:54] <nacc> tgm4883: yeah, i'm gathering as much
[17:54] <tgm4883> nacc: he didn't bother cloaking
[17:55] <tgm4883> bah, I meant this for #ubuntu-discuss
[17:55]  * tgm4883 hangs his head in shame
[17:57] <slangasek> Odd_Bloke: looking at image-consolidation branch now.  I thought the plan had actually been to keep the tar.xz in parallel with the squashfs, but drop tar.gz as redundant?
[17:59] <semiosis> Odd_Bloke: oh that ^ reminds me, with my changes vagrant no longer depends on the vmdk, but only on the root disk image, so it could be moved from 042 to something lower.  i didnt mess with that in my changes. figured that decision should be left up to the package maintainers.
[18:01] <semiosis> lower numerically*
[18:03] <slangasek> Odd_Bloke: looking back over the meeting notes to refresh my memory, I see that there is discussion of replacing tar.xz with squashfs, but I don't remember that being concluded in the meeting and am concerned that there may be deps on the .tar.xz that aren't ready to migrate
[18:22] <pitti> slangasek: thanks, now I can do the necessary settings on the +language-packs page
[18:23] <pitti> stgraber: ack, will have a look, added to my todo
[18:35] <dasjoe> Was a containerdays today, sadly everything was quite Docker-centric, I hoped to see some LXD in action
[18:35] <dasjoe> Oh, this isn't #lxcontainers :)
[20:27] <LocutusOfBorg> oops jbicha I was uploading the tidy rebuilds
[20:28] <LocutusOfBorg> BTW https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828902
[20:30] <jbicha> LocutusOfBorg: ok, I asked in #kubuntu-devel for them to rebuild the 2 kde pkgs
[20:30] <LocutusOfBorg> wonderful
[20:30] <LocutusOfBorg> I'll leave the transition to you
[20:30] <jbicha> libhtml-tidy-perl and python-tidylib both have test failures :(
[20:30] <LocutusOfBorg> feel free to check the MIR status
[20:31]  * LocutusOfBorg leaves, lets see tomorrow
[21:18] <slangasek> Odd_Bloke: ok, have re-bootstrapped my brain to the conclusion that both tar.gz and tar.xz should go away.  Are we sure that nothing is consuming the tar.[xg]z downstream that will break by this change?
[21:32] <Grorco> Hi I am just trying to get started on helping with small bugs and I'm a little confused, I got a branch of software-properties using bazaar and don't know where to go from here
[21:34] <Grorco> the developer site says to use edit-patch to get a copy of it to work on but that errors out saying it's not a debian dir
[21:38] <nacc> Grorco: link to said site?
[21:39] <nacc> Grorco: edit-patch is used to modify debian patches inside a source package
[21:39] <Grorco> nacc: http://packaging.ubuntu.com/html/fixing-a-bug.html
[21:40] <nacc> Grorco: what's the bug in question?
[21:41] <Grorco> nacc: alt-tab doesn't bring up the window
[21:42] <Grorco> in unity*
[21:42] <nacc> Grorco: ok, so once you've bzr-branch'd, you'll just go into the directory it was cloned to locally
[21:43] <Grorco> nacc: the .bzr dir seems kind of empty outside of a .pack file
[21:47] <Grorco> nacc: I guess what I'm asking is if I need to depackage that file for the code then fix and repack?
[21:49] <nacc> Grorco: what was the command you ran to branch the bazaar tree?
[21:50] <nacc> Grorco: the .bzr dir is more like the .git dir in a git repository, it's metadata about the repository (aiui). You want the directory that is in (by default)
[21:51] <Grorco> nacc: bzr branch lp:software-properties software-properties.dev
[21:52] <Grorco> which create a dir with the hidden .bzr file
[21:52] <nacc> Grorco: well, you told it to branch to 'software-properties.dev'
[21:52] <nacc> so that's where you should cd to, in order to develop on the source
[21:53] <nacc> that's the 'root' of the source package directory
[21:55] <Grorco> nacc: but it's empty outside of the .bzr file, maybe I should try branching again my internet was being all kinds of stupid yesterday
[21:57] <nacc> Grorco: i ran that command just now and it produced a fully-populated software-properties.dev directory
[21:57] <nacc> Grorco: also .bzr should be a directory, not a file
[21:57] <nacc> Grorco: do you have some local bazaar configuration?
[21:58] <Grorco> nacc: .bzr is a directory sorry if I called it a file, the only configuration I did was setting up my lp account with it
[21:59] <nacc> Grorco: i would try 'rm -r software-properties.dev' and running hte branch command again
[21:59] <nacc> Grorco: it worked for me? :/
[22:02] <Grorco> nacc: It shows it fully populated from terminal after running it again :) but now I can't see the folder in caja?
[22:03] <Grorco> is that normal?
[22:05] <Grorco> nevermind I had other caja windows open closing them fixed that too thank you so much nacc! I felt like a complete idiot :)
[22:06] <nacc> Grorco: dunno what caja is, but glad you are up and running :)
[22:07] <Grorco> nacc: it's the default file explorer that comes with mate
[22:07] <nacc> Grorco: ah ok, don't use mate, so didn't know :)
[22:08] <Grorco> nacc: I'm going to go have a celebitory smoke, thanks again hopefully I'll be helping others soon