[04:14] <mup> PR snapd#9586 closed: update-pot: include file locations in translation template, and extract strings from desktop files <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/9586>
[04:45] <mup> PR snapd#9592 opened: [wip] many: implement degraded recover mode <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9592>
[06:58] <zyga> timothy, this is expected, that part of the sandbox is based on apparmor which doesn't exist on fedora
[07:24] <mborzecki> morning
[07:38] <mborzecki> mvo: hey
[07:38] <mvo> good morning mborzecki
[07:39] <mborzecki> mvo: looks like some bits of rpm spec we share between fedora/rhel/aamzon do not expand correctly on amazon linux
[07:40] <mvo> mborzecki: oh no! is that hard to fix?
[07:41] <mborzecki> mvo: not really, it's about the session agent and the session agent socket, though i think it's safe to assume one will not be runnig user sessions on amazon linux
[07:41] <mborzecki> (as in a graphical sessions)
[07:42] <mvo> mborzecki: aha, ok
[07:42] <mvo> mborzecki: that sounds not too bad then
[07:42] <mvo> mborzecki: anything I should look at right away?
[07:42] <mborzecki> i mean, it's also a bit weird, i thought they were supposed to pull in stuff from rhel, it looks like they did but just once, the relevant macros made their way to rhel7, but not to amzn2
[07:44] <mborzecki> mvo: hm one last look at  https://github.com/snapcore/snapd/pull/9577 ?
[07:44] <mup> PR #9577: many: seal a fallback object to the recovery boot chain <Run nested> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9577>
[07:44] <mvo> mborzecki: sure
[07:44] <mvo> mborzecki: I think there were just minor test issue but let me look (followup material)
[08:00] <mvo> mborzecki: fwiw, the gentoo fix/change is in
[08:00] <mborzecki> yay
[08:00] <mvo> mborzecki: it seems to take ~24h for the mechanics to propergate a CLA change
[08:00] <mup> PR snapd#9588 closed: dirs: add "gentoo" to altDirDistros <Created by zmedico> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9588>
[08:01] <mborzecki> mvo: maybe some cron job that runs once a day
[08:03] <mvo> yeah
[08:03] <pstolowski> morning
[08:03] <mvo> good morning pstolowski !
[08:05] <pstolowski> o/
[08:27] <mborzecki> pstolowski: hey
[08:27] <pstolowski> heya
[08:28] <mborzecki> mvo: so i did some more digging, and imo we should not fix anything for amzon linux 2, but rather pusht he users to file bugs or request support with amazon, the systemd package they have is outdated with buggy macros
[08:29] <sil2100> Hey guys! Is there any reason why the amd64 UC20 images are 8GB big? Was it only to workaround the ubuntu-image bug with not properly calculating the final image size?
[08:29] <sil2100> (hard-coded to 8GB big)
[08:35] <mvo> mborzecki: +1
[08:35] <mvo> sil2100: iirc yes
[08:55] <mvo> mborzecki: hrm, hrm, nested core18 in 9577 failed
[09:14] <mborzecki> mvo: heh the log is not that useful
[09:32] <pstolowski> mvo: interesting thoughts https://ahmet.im/blog/golang-json-decoder-pitfalls/ and related https://github.com/google/go-github/pull/317
[09:32] <mup> PR google/go-github#317: Drain Response.Body to enable TCP/TLS connection reuse (4x speedup) <Created by FiloSottile> <Merged by willnorris> <https://github.com/google/go-github/pull/317>
[09:33] <pstolowski> maybe harmless in our cases, otoh we do use Decode on the body a lot (this is unrelated to the issue we talked about yesterday, but might be a separate problem)
[09:34] <pstolowski> having extra json data isn't a big deal i think, but maybe not draining the response is
[09:35] <mvo> pstolowski: interessting, thanks for this
[10:09] <mborzecki> mvo: so i rerun the test a couple of times locally and it is passing
[10:10] <mvo> mborzecki: ok - in a meeting right now so can't really reply but it sounds like we could re-run one more time
[10:10] <mborzecki> mvo: also tried to have snapd log to journal+console on core18, but for some reason it's no being picked up
[10:26] <mup> PR snapd#9591 closed: gadget, gadget/install: move helpers to install package, refactor unit tests <Run nested> <Simple 😃> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9591>
[10:36] <mup> PR snapd#9593 opened: tests/lib/nested: enable snapd logging to console for core18 <Run nested> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9593>
[10:45] <mvo> mborzecki: thanks (still in a meeting)
[11:47] <mup> PR snapd#9577 closed: many: seal a fallback object to the recovery boot chain <Run nested> <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9577>
[12:02] <mup> PR snapd#9594 opened: findpartitions rewrite <Created by xnox> <https://github.com/snapcore/snapd/pull/9594>
[12:06] <pstolowski> hmmm
[12:06] <pstolowski> mborzecki: do you know why sc_check_rootfs_dir in snap-confine doesn't need any core18/20 logic?
[12:10] <mborzecki> pstolowski: afaiu the typical case is that the base snap (which bescomes rootfs exists) which is true for core/core18/core20
[12:11] <mborzecki> the rest is some fallback code for ubuntu-core (?), and core16 which can be used as base, but had no stable release, so the fallback goes to core
[12:11] <pstolowski> mborzecki: ah, because it falls into if (access(inv->rootfs_dir, F_OK) == 0, i misread this
[12:11] <pstolowski> thanks
[12:17] <rogpeppe> pstolowski: hiya. just FYI that raspberry pi has crashed again without recovering (the machine itself is running, but the snap isn't running and /snap/snapd/current has gone again)
[12:17] <rogpeppe> zyga: ^
[12:18] <mborzecki> pstolowski: ^^
[12:18] <rogpeppe> pstolowski: if there's anything i can do to help out with logs or anything else, let me know. you still have access to the machine.
[12:24] <pstolowski> rogpeppe: hi. i believe the problem is understood and it's a low-level issue outside of snapd that prevents upgrade, zyga menaged to reproduce it, i think it's in the hands of foundation team now. mvo do you know a bug for this?
[12:25] <rogpeppe> pstolowski: thanks
[12:25] <pstolowski> rogpeppe: also, btw, zyga quit a few days ago (but still shows up here ;))
[12:25] <rogpeppe> pstolowski: do you know of a quick way to fix the issue on my machine, at least temporarily?
[12:25] <rogpeppe> pstolowski: i.e. to get the service running again.
[12:26] <rogpeppe> pstolowski: oh, that's a shame! zyga: good luck in your future endeavours!
[12:28] <pstolowski> rogpeppe: you are already holding refreshes for a month or so right?
[12:28] <rogpeppe> pstolowski: what do you mean?
[12:29] <pstolowski> rogpeppe: the setting that delays automatic refreshes for a bit
[12:29] <rogpeppe> pstolowski: i haven't changed any settings at all
[12:29] <pstolowski> rogpeppe: ok
[12:29] <mvo> rogpeppe, pstolowski I think part of the problem is/was that the uboot in the pi-gadget is outdated and does not have a fix for sd-card writing. not sure if zyga manually applied the fixed uboot to your device though
[12:30] <rogpeppe> mvo: would it help to reinstall everything on a fresh sd card with the latest ubuntu core?
[12:31] <pstolowski> rogpeppe: yes, that is what i was going to suggest.. the problem affects some old images & old uboot
[12:31] <rogpeppe> pstolowski: ok, i'll do that. but it'll take a few days to send the card by post. is there a way to get the snap services running in the meantime?
[12:32] <mvo> rogpeppe: I would wait a tiny bit, the pi gadget is not updated yet
[12:32] <mvo> rogpeppe: let me quickly double check the state of this
[12:34] <pstolowski> rogpeppe: yes, there is a temporary workaround, i've just logged onto your pi3 to check bash history because I did it once before
[12:34] <rogpeppe> pstolowski: thanks!
[12:35] <mvo> pstolowski: did zyga apply the fix?
[12:35] <mvo> pstolowski: or what exactly does "temporary workaround" mean (sorry for being a bit irgnorant)
[12:35] <pstolowski> rogpeppe: /snap/snapd/9169/usr/bin/snap enable snapd
[12:35] <pstolowski> rogpeppe: this brings snap command back
[12:35] <pstolowski> rogpeppe: i just did it
[12:36] <mvo> ta
[12:36] <pstolowski> rogpeppe: i havern't done anything about services, you may want to check if they are fine and start if needed
[12:36] <pstolowski> mvo: i don't know about any uboot fixes, no idea if zyga applied anything
[12:37] <mvo> rogpeppe: I asked "waveform" to join us here, he maintains the pi gadget, will ask him about the status of the uboot SRU that contains the fix
[12:37] <mvo> pstolowski: that's fine, was just curious
[12:37] <mvo> pstolowski: probably risky anyway before we have the snap
[12:37] <pstolowski> mvo: actaully, most likely not because only I have access to rogpeppe's box
[12:38]  * mvo nods
[12:40] <rogpeppe> pstolowski: ok, good call. the service was active but not running. now it's running again
[12:47] <pstolowski> rogpeppe: sorry for all the trouble. this was a tricky bug related to uboot and the only way to investigate was to have physical access & see the uboot error (remote access wasn't enough)
[12:48] <rogpeppe> pstolowski: that's ok. hopefully when i reinstall, this won't happen again for a while at least.
[12:49] <pstolowski> rogpeppe: just note what mvo said about availability of new pi gadget
[12:49] <rogpeppe> pstolowski: what's the "pi gadget" ?
[12:50] <pstolowski> rogpeppe: it's pi3 support package (a snap) that includes files for booting
[12:51] <rogpeppe> pstolowski: ack
[13:00] <mborzecki> the fallback mount handling in s-b has become quite complex now
[13:45] <mvo> rogpeppe: waveform may have more details about when we get a new uboot that has the sd-card writing bug fixed
[14:59]  * cachio lunch
[15:01] <pstolowski> cachio: hey, did you see questions under https://github.com/snapcore/snapd/pull/9567 ?
[15:01] <mup> PR #9567: tests: using the nested-state tool in nested tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9567>
[15:41] <pstolowski> rogpeppe: fyi, i found the bug: https://bugs.launchpad.net/snapd/+bug/1900693
[15:41] <mup> Bug #1900693: snapd cannot refresh on some SD cards due to uboot bug <snapd:New> <u-boot (Ubuntu):New> <https://launchpad.net/bugs/1900693>
[15:44] <rogpeppe> pstolowski: thanks! interesting to see the underlying bug too. BTW, which part of the system is this about? https://github.com/u-boot/u-boot/commit/b1125802a524641ad1ac803b4a617756d26f007d
[15:45] <rogpeppe> ah, maybe the SD card driver?
[15:45] <ogra> not sure how much you guys watch the #ubuntu channel ...
 home and removable-media
 I *can't* do ls ~/.ssh but I *can* do ls ~/.ssh/*
 which seems broken
[15:46] <ogra> should a user be able to list content of ~/.ssh when using globbing (while listing without globbing is properly blocked by apparmor)
[15:48] <pstolowski> rogpeppe: i'm not sure
[16:07] <niemeyer> ogra: I cannot list ~/.ssh/* here
[16:07] <niemeyer> ogra: The behavior is not about globbing.. it just means he's got read access to ~/ but has to ~/.ssh/, which sounds wrong
[16:07] <ogra> niemeyer, that user is inside a multipass VM running the lsd snap .... it is a bit more than just ls on a normal hist it seems https://gist.github.com/bhechinger/e2fdb1e4e4ab636287c265806ab3dabf
[16:07] <ogra> *host
[16:08] <pstolowski> Saviq: hey, re https://bugs.launchpad.net/snapd/+bug/1902230, the issue didn't get away and it was stuck for good right?
[16:08] <mup> Bug #1902230: Tasks stuck if api.snapcraft.io not found <snapd:New> <https://launchpad.net/bugs/1902230>
[16:08] <pstolowski> *didn't go
[16:09] <niemeyer> ogra: removable-media is not even connected.. it's just nome
[16:09] <niemeyer> home
[16:09] <ogra> yep
[16:09] <niemeyer> This is a relevant bug if it was just allowing access to .ssh, but my bet is that there's something else fishy in that environment
[16:09] <niemeyer> mvo: The restarting state is another area that might benefit from some attention
[16:10] <ogra> yes, my suspicion was that multipass bind mounts content from outside the VM there or similar
[16:10] <niemeyer> mvo: It's currently distributed over several packages, with internals leaking thorugh
[16:10] <ogra> niemeyer, ijohnson is looking deeper into it
[16:11] <niemeyer> mvo: We had a pretty small surface in the state package itself, with all responsibility lying in the backend, but now there's quite a bit about that inside the state itself, with the settings being known inside state, in overlord, and all the way to the daemon package
[16:11]  * ijohnson got pulled into a meeting
[16:13] <niemeyer> This kind of logic seems to make sense in the overlord, since it's about orchestration..
[16:14] <ogra> ijohnson, niemeyer ... another datapoint ... this multipass instance is running on top of windows (hyper-v) ...
[16:15] <ogra> (do we actually expect proper confinement there at all ???)
[16:19] <niemeyer> ogra: snap debug confinement
[16:21] <zyga> rogpeppe, re
[16:23] <ogra> niemeyer, interestingly that seems to returns "strict" ...
[16:23] <niemeyer> ogra: Maybe it's just not working properly.. is that a Canonical kernel?
[16:25] <ogra> niemeyer, looks like "kernel  5.4.0-52-generic" ... (from https://gist.github.com/bhechinger/e2fdb1e4e4ab636287c265806ab3dabf)
[16:25] <ogra> at least if snap version gets the correct info
[16:26] <niemeyer> It's clear snapd thinks the environment is strict given the data it has.. the question is whether this is a real kernel/apparmor bundle
[16:26] <ogra> yeah ... thats probably a question to Saviq
[16:27] <niemeyer> Also, is the snap in devmode?
[16:27] <ogra> (i'm not using multipass .... passionate lxd user here)
[16:27] <niemeyer> Ah, and that's the *lxd* snap?
[16:28] <ogra> no, "lsd"
[16:28] <niemeyer> LXD has plenty of access into the system to be able to do all it does
[16:28] <cachio> pstolowski, checking
[16:28] <pstolowski> cachio: thanks
[16:28] <ogra> niemeyer, he is using the "lsd" snap (ls on steroids) inside a multipass VM on a windows machine
[16:29] <niemeyer> Ah, ok
[16:29] <ogra> no lxd involved (that was just about me not using multipass, sorry for confusing)
[16:29] <pstolowski> cachio: i also reviewed your other PR re boot-state, but please take a look at the small suggestion
[16:29] <niemeyer> ogra: Can you reproduce the issue on a vm?
[16:29] <cachio> pstolowski, nice, I'll take a look to all of them
[16:29] <cachio> thanks for the reviews
[16:30] <ogra> i can try ... but that takes a bit ...
[16:35] <ijohnson> ogra: I can reproduce the issue on my native focal machine
[16:35]  * ijohnson is back from meetings now
[16:36] <ijohnson> my guess is that this snap is doing some stat syscall trickery
[16:36] <ogra> ijohnson, gah ... now my multipass has finally downloaded that image !
[16:36] <ogra> okay, so seems we have an actual bug
[16:36] <ijohnson> ogra: and indeed if I do `snap run --shell lsd` and do a normal `ls ~/.ssh/*` that does not work
[16:37] <ogra> thats so strange
[16:39] <ogra> ubuntu@primary:~$ lsd ~/.ssh/
[16:39] <ogra> cannot access '/home/ubuntu/.ssh/': Permission denied (os error 13)
[16:39] <ogra> ubuntu@primary:~$ lsd ~/.ssh/*
[16:39] <ogra>   authorized_keys
[16:39] <ogra> yep, same here .... i can repro ...
[16:40] <ogra> and i can even reproduce it on my native machine
[16:40] <ogra> ogra@acheron:~$ lsd ~/.ssh/
[16:40] <ogra> cannot access '/home/ogra/.ssh/': Permission denied (os error 13)
[16:40] <ogra> ogra@acheron:~$ lsd ~/.ssh/*
[16:40] <ogra>   config    id_rsa    id_rsa.keystore    id_rsa.pub    known_hosts    known_hosts.old
[16:42] <ogra> so yeah, there is a real bug
[16:42] <ijohnson> I think it's essentially using stat to get the inode, then incrementing the inode to get what the file name is so it is an information leak, but it's probably not a CVE
[16:43] <ogra> yeah
[16:48] <Nemesis> Hello everyone, I have fresh Manjaro install and most of my snap installed applications won't open. can someon assist me to fix that issue?
[16:48] <ogra> Nemesis, are you using wayland ?
[16:48] <ijohnson> ogra: ah I know what it is
[16:49] <ijohnson> ogra: try `lsd '~/.config/*'`
[16:49] <ijohnson> ogra: or `lsd '~/.ssh/*'` as compared to `lsd ~/.ssh/*`
[16:51] <Nemesis> ogra:  i am not that good in linux, and this is my first try arch based system
[16:51] <Nemesis> usually I mostly use debian based
[16:51] <Nemesis> and also I am not familliar with wayland
[16:52] <ogra> ijohnson, so a quoting issue you think ?
[16:52] <ijohnson> ogra: it's bash giving away all your secrets!
[16:52] <ogra> hah !
[16:52] <ijohnson> ogra: when I strace that command, I see this:
[16:52] <ijohnson> [pid 44201]<PHONE_NUMBER>.123092 execve("/snap/lsd/62/command-lsd.wrapper", ["/snap/lsd/62/command-lsd.wrapper", "/home/ijohnson/.ssh/authorized_keys", "/home/ijohnson/.ssh/config", "/home/ijohnson/.ssh/id_rsa", "/home/ijohnson/.ssh/id_rsa-lxd", "/home/ijohnson/.ssh/id_rsa-lxd.pub", "/home/ijohnson/.ssh/id_rsa.pub", "/home/ijohnson/.ssh/known_hosts", "/home/ijohnson/.ssh/known_hosts.old"], 0xc420178300 /* 95 vars */
[16:52] <ijohnson> <unfinished ...>
[16:53] <ijohnson> so bash expands the "*" to all the files there and then those are all passed as args to `snap run`, and lsd then proceeds to work, because it uses stat on those files
[16:53] <Nemesis> I have installed Manjaro KDE
[16:53] <ijohnson> and stat syscall always works
[16:53] <ogra> Nemesis, https://forum.snapcraft.io/t/completely-broken-snapd-environment-in-manjaro-20-1-2/20900 ...
[16:54] <ogra> ijohnson, hah lovely
[16:55] <Nemesis> i can see that, so that's mean snap is broken and i cannot use it and respectively fix it?
[16:55] <ogra> though i think thats not bash specific ... POSI shell would do the same
[16:56] <ogra> Nemesis, probably use an older manjaro image (but perhaps also tell the guy in the forum that he is not alone (which he is asking))
[16:56] <ijohnson> ogra: right I think all shells do this
[16:56] <ogra> yeah
[16:56] <Nemesis> ok, I understand
[17:01] <cachio> pstolowski, I answered questions
[17:01] <cachio> I hope it is more clear nowe
[17:01] <cachio> now
[17:03] <pstolowski> checking
[17:03] <ijohnson> mvo: so I spoke with xnox about the disk PR, that is now ready to go, there are improvements we want/should do sometime but the pr as-is fixes the issue about parent <-> child device mapping so we should merge that with normal snapd reviews
[17:03] <ijohnson> there are lp bugs filed for the improvements I assigned to me that I think we should do sooner rather than later, but aren't necessary for 1.0 I think
[17:13] <mvo> ijohnson: cool, I'm happy to merge your PR, it got my +1 already
[17:13] <pstolowski> cachio: +1
[17:14] <cachio> pstolowski, thanks
[17:14] <ijohnson> mvo: ok, I did slightly adjust the logic so I dismissed your review so if you want to just quickly give it another review then maybe maciej can review it tomorrow morning
[17:14] <pstolowski> cachio: btw, did you see https://github.com/snapcore/snapd/pull/9533#issuecomment-719501270 ?
[17:14] <mup> PR #9533: tests: new systemd-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9533>
[17:15] <cachio> pstolowski, yes, I am trying to fix that for trusty, if I cant so I'll skip it in the test
[17:16] <pstolowski> ok
[17:17] <cachio> pstolowski, I'll let you know when I test it
[17:17] <cachio> thanks for the heads up
[17:17] <pstolowski> cachio: sure. is there any other PR you need reviewed?
[17:18] <cachio> pstolowski, you already reviewed the 3 most important ones
[17:18] <cachio> so thanks for that
[17:19] <cachio> pstolowski, well I have #9276
[17:19] <mup> PR #9276: tests: new backend for desktop and external classic <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9276>
[17:20] <cachio> it is a pretty old one
[17:20] <cachio> but not so important
[17:21] <zyga-mbp> hey cachio :)
[17:21] <cachio> zyga-mbp, hey zyga
[17:21] <cachio> how is it going?
[17:21] <zyga-mbp> good, rapid pace for sure
[17:21] <pstolowski> cachio: right, i saw that.. could be nice though. i may have a look tomorrow. could you please merge master in it just to have it up-to-date?
[17:22] <cachio> pstolowski, sure, thanks
[17:22] <pstolowski> ok. cu
[17:22] <zyga-mbp> cachio any reviews I can help you with?
[17:24] <cachio> zyga-mbp, I think the only one missing is #9533
[17:24] <mup> PR #9533: tests: new systemd-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9533>
[17:24] <cachio> zyga-mbp, the rest is already covered
[17:24] <ijohnson> hey zyga-mbp how are things going?
[17:24] <zyga-mbp> ijohnson hey!
[17:24] <cachio> zyga-mbp, still need to make f33 work
[17:24] <zyga-mbp> ijohnson different :)
[17:24] <zyga-mbp> ijohnson but I EOD at 16:30 which is just amazing
[17:24] <cachio> zyga-mbp, #9556
[17:24] <mup> PR #9556: tests: testing new fedora 33 image <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9556>
[17:25] <ijohnson> zyga-mbp: nice :-) having an early EOD is nice
[17:25] <zyga-mbp> the 31->33 patch looks good
[17:25] <zyga-mbp> ijohnson: lots of corpo stuff to figure out
[17:25] <zyga-mbp> but really easy to communicate as well, that's surprising to me
[17:25] <ijohnson> yeah always happens at new jobs
[17:29] <ijohnson> anyways zyga-mbp it was good to "see" you here again, I need to get back into some code :-)
[17:33] <zyga-mbp> thank you :-)
[17:35] <mvo> ijohnson: is the comment in 9541 still in sync with the code? just asking before I do a proper review
[17:35]  * mvo will have dinner first before doing a deeper dive
[17:35] <ijohnson> mvo: which comment? the ones in the code yes, and I responded to all thecomments in the PR so everything  should be in sync
[17:36] <ijohnson> the comment in LP bug is not editable so you need to look at the other comments further down in the bug report if you are referring to that
[17:36] <mvo> ijohnson: these comments https://github.com/snapcore/snapd/pull/9541/files#diff-db994f6207a7cf0f7df752561b677c6816387fe42bec335ede11f6a46d411169R341 I mean but great if they are :)
[17:36] <mup> PR #9541: osutil/disks: re-implement partition searching for disk w/ non-adjacent parts <Bug> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9541>
[17:37] <ijohnson> mvo: yes those comments are about future improvements, but not needed for the pr
[17:37] <ijohnson> mvo: I will look into sorting those out in a followup PR, probably not for 1.0
[17:37] <ijohnson> mvo: I will leave responses to those to make it clear though
[17:38] <ijohnson> mvo: ok responded hopefully that makes it more clear
[17:44] <zyga-mbp> cachio https://github.com/snapcore/snapd/pull/9533#pullrequestreview-522723935
[17:44] <mup> PR #9533: tests: new systemd-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9533>
[17:44] <zyga-mbp> cachio I'm somewhat -1 on this, left ideas and some comments but mainly look at the first comment
[17:47] <cachio> zyga-mbp, thanks, well the idea of this was to move the helper we already have to a tool
[17:47] <cachio> which we can test
[17:47] <zyga-mbp> yeah but not everything should be a helper like that
[17:48] <zyga-mbp> it's a very shallow helper on top of systemd commands
[17:48] <zyga-mbp> with custom syntax and behavior
[17:48] <zyga-mbp> it will not replace our use of systemd tools directly
[17:48] <zyga-mbp> I would not go there
[17:48] <zyga-mbp> as I said in the review, I would keep two commands
[17:48] <zyga-mbp> but slim them to work well with repeat
[17:48] <zyga-mbp> and really not implement the rest as a utility but instead put it in the few spots that need it
[17:49] <zyga-mbp> and each time, consider if you can systemd-run something instead
[17:49] <cachio> and the rest should stay in systemd-sh?
[17:49] <cachio> systemd.sh?
[17:49] <zyga-mbp> no, just move it to the places that use those
[17:49] <zyga-mbp> how many tests call those functions?
[17:50] <cachio> zyga-mbp, 17
[17:50] <cachio> which are creating systemd units
[17:51] <zyga-mbp> I've opened a random test that imports systemd.sh
[17:51] <zyga-mbp> and it wasn't using it
[17:51] <zyga-mbp> I'd suggest going through the tests and filtering out those first
[17:52] <zyga-mbp> it may be a bad sample (I looked at tests/core/remodel-base)
[17:52] <cachio> zyga-mbp, I listed the tests which are using the function systemd_create_and_start
[17:52] <cachio> there are 17 creating systemd units through this function
[17:52] <zyga-mbp> but that doesn't change what my comment said: those helpers are not doing complex things, they are wrapping systemd tools with new syntax one has to learn, I'm not sure that's worth doing
[17:52] <zyga-mbp> I see
[17:53]  * zyga-mbp looks
[17:53] <zyga-mbp> I see 12 task.yaml files
[17:54] <zyga-mbp> I've opened tests/core/snap-set-core-config
[17:54] <zyga-mbp> and instead of what that is doing, it's a really one liner: systemd-run --unit rsyslog.service  sleep 2h
[17:54] <zyga-mbp> and similarly systemctl stop to remove it
[17:55] <zyga-mbp> this has some nice advantage, it goes through the dbus api
[17:55] <zyga-mbp> and doesn't require reloading systemd
[17:55] <zyga-mbp> (reloading is only needed when you change files from under systemd)
[17:55] <zyga-mbp> anyway, I cannot -1 it for real anymore but think over my advice
[17:55] <zyga-mbp> IMO using systemd-run instead will make most of that obsolete
[17:56] <zyga-mbp> and also more readable, as it's a well known command and not our custom helper
[17:56] <zyga-mbp> you can also couple that with tests.cleanup defer systemctl stop to make sure it is not leaking in any way, and put that right next to each other
[17:56] <cachio> zyga-mbp, systemd-run supports a reboot?
[17:57] <zyga-mbp> cachio no, but most tests don't need that
[17:57] <zyga-mbp> systemd-run creates units in memory
[17:57] <zyga-mbp> those that do can just make the units, it's not like two printf calls are somehow special
[17:57] <zyga-mbp> and you don't need to learn new tool and how to use it exactly
[17:58] <cachio> zyga-mbp, using systemd-run makes sense to me
[17:58] <cachio> I would need up update the tests for that
[17:58] <zyga-mbp> yeah, just change a few  and see how it feels like
[17:59] <cachio> zyga-mbp, I'll try that, just need to make sure it works well in all the supported systemd
[17:59] <cachio> version
[17:59] <zyga-mbp> cachio systemd-run works on 16.04+
[17:59] <zyga-mbp> 14.04 is not supported since our broken systemd version there is detached from dbus
[18:00] <zyga-mbp> I would not sacrifice readability for support over 14.04
[18:00] <cachio> zyga-mbp, agree
[18:01] <cachio> zyga-mbp, thanks for the advise
[18:01] <zyga-mbp> good luck!
[19:51] <mvo> ijohnson: 9541 looks fine, one question/suggestion but needs a second review still :/
[19:52] <ijohnson> mvo: yeah I was thinking maybe maciej could take a look in the AM
[19:52] <ijohnson> thanks for the review, I will go look at your question now
[19:52] <ijohnson> also sorry I did respond to those comments, but they didn't show up because they were part of a review apparently, but I just switched them to normal comments now
[19:52] <mvo> ijohnson: yeah, I will coordinate with him in the morning
[19:52] <ijohnson> ok
[19:53] <mvo> ijohnson: no worries
[19:55] <ijohnson> mvo: also I discussed with maciej after SU how to refactor 9592, I think we have a cleaner way to implement it now, and a way that should make testing easier as well, so I will try to get that updated today
[19:55] <mvo> ijohnson: nice!
[19:55] <mvo> ijohnson: thanks for this update
[19:56] <ijohnson> mvo: also also, we talked about transitioning from run -> recover automatically in the case where we couldn't unlock data partition and all fallbacks fail, I think it's reasonable thing to do and slightly helps us avoid the problem of being unable to trigger the chooser when the recovery key prompt swallows input
[19:57] <ijohnson> mvo: this specific change shouldn't be too complex, but before we pull that in I think pedronis needs to have a look so it will have to wait until Thursday anyways
[19:58] <mvo> ijohnson: fallabck run->recover> agreed
[20:00] <ijohnson> ok, I will maybe open that today, maybe tomorrow
[21:17] <mup> PR snapcraft#3347 opened: Create an extra 'build' directory for plugins <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3347>
[21:27] <mup> PR snapcraft#3348 opened: ROS plugins use plugins' build directory <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3348>
[21:39] <mup> PR snapd#9595 opened: interfaces/greengrass-support: minimize to enable 1.11 no-container lambdas <Needs security review> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9595>


[07:57] <lordievader> Good morning
[08:01] <hwpplayer1> lordievader : Good morning
[08:01] <lordievader> waveform:
[08:01] <lordievader> Whoops, I meant 👋
[09:47] <Repox> Hello. I'm having some issues with Ubuntu 18.04 and netplan (apparently). After doing some package updates on my server, network is now unreachable. I don't have much experience with netplan and now my hosting provider stopped responding as they "don't provide software support". I've been down for the past three hours, sadly.
[10:05] <lordievader> If you don't have experience with netplan you can ditch it for something you do know.
[10:07] <Repox> I wasn't aware. Can I just disable it? ifupdown isn't installed currently, and because I can't get online I can't install that package.
[10:23] <kiokoman> Repox: you can still create/modify /etc/network/interfaces and reboot/restart networkmanager
[10:25] <Repox> kiokoman I tried adding /etc/network/interfaces and wrote a manual config and did systemctl restart systemd-networkd, but I still can't reach the network?
[10:27] <weedmic> i wrote a user creation programme that prompts the details for netplan
[10:29] <kiokoman> Repox: check with -> ip address <- if it's configured
[10:30] <kiokoman> or try ro reboot
[11:11] <deadrom> hi
[11:12] <deadrom> in 18.04, what's the preferred method to create regular full backups for bare metal restore to a network storage?
[11:16] <deadrom> ...of the OS
[12:56] <qman__> deadrom: rsync
[13:00] <lordievader> Or a frontend of rsync: dirvish
[13:10] <rbasak> ahasenack: how's the MySQL my_bool change looking? Do you have any remaining packages that need fixing?
[13:11] <ahasenack> rbasak: I'm https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295working on the zoneminder runtime issues now,
[13:12] <ahasenack> rbasak: maybe take a look at clickhouse?
[13:12] <ahasenack> these are the two remaining ones (clickhouse and zonemindeR)
[13:12] <ahasenack> rbasak: for clickhouse, I have these notes: "clickhouse: my_bool typedef wasn't enough, it failed elsewhere now. Check LP #1840938"
[13:15] <rbasak> ahasenack: OK, I'll loock at clickhouse
[13:16] <ahasenack> rbasak: my build attempt from the ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-bool-removal/+packages?field.name_filter=clickhouse&field.status_filter=published&field.series_filter=
[13:59] <cgi> anyone here who has setup a mongodb cluster recently?
[14:00] <cgi> When I do IP whitelisting - how secure is that to outside attacks? I am trying to run a dabase with 3 local machines, only accessible to 192.168.*
[14:02] <Ussat> How positive are you that no bad actor will ever have one of those ip's ?
[14:32] <tomreyn> cgi: i would not want to run mongodb or any database on a system with an internet connected network interface without a firewall. but YMMV, in the end it all comes down to "how sensitive is this data", and what's your effort / benefit evaluation?
[14:32] <rbasak> I would say that it's not just your data at risk, but your entire system.
[14:33] <rbasak> Plus your hosting/connection if a system is compromised and use for abuse
[14:33] <rbasak> used for abuse
[14:33] <rbasak> eg. spam
[14:37] <tomreyn> good point
[14:47] <cgi> tomreyn, if the port is closed for outside IPs - how does one attack it?
[14:50] <tomreyn> cgi: in the scenario you described, the port would not be closed to ingress traffic from the internet (unless there would be an additional firewall between the host and the internet)
[14:53] <tomreyn> cgi: should vulnerabilities become known which allow for circumventing source IP address based ACLs, or should software lack such in the first place (mongodb is well known for having had this specific issue), then (or should i say in general) you'll better have network segemntation in place.
[14:55] <alfatau> hi everybody. I'm planning to install a new ubuntu 18.04 server edition. Actually I'm running an old 12.04 that has been out of support since 2017. Can you advise me some free very-concise-and-practical documentation to basically learn the main differences and advantages between "legacy" administrative tools and newest one (e.g. ifconfig vs
[14:55] <alfatau> netplan, apt-get vs snap, ...). My target is to have an overview of what's new and why some tools have been replaced. Then I'll deepen each new tool when needed. thank you in advance
[14:55] <tomreyn> cgi: scenarios where you rely just on ACLs (but network connectivity is enabled FROM ANY) can also still be subject to traffic amplification attacks, potentially brute force attacks.
[15:02] <teward> rbasak: re: your reply on 1743592 today - I think it's too late in the cycle to consider that change - if only because there may be automated log parsers that are not configured properly for this (fail2ban for instance) which will detect a v6 IP and use ip6tables which might not catch the v4 traffic properly.
[15:02] <teward> I think any major fundamental change to the nginx logging mechanism in the default setup like this needs to happen way earlier in the cycle.
[15:02] <teward> and not 3 days before FF
[15:03] <teward> (my two cents as the nginx maintainer)
[15:03] <teward> which is why I had said in the bug that we should consider that as a 20.10 change
[15:03] <teward> i don't want to have to go fixing fail2ban, etc. this late in the cycle
[15:04] <teward> i don't disagree it's a 'good solution' but this close to FF and this late in the cycle I think it's too late to contemplate changing default logging format for IPs.
[15:04] <rbasak> teward: fail2abn is a good shout
[15:04] <rbasak> Though I would argue that this is what feature freeze is for - to stop changing things like default log formats, so other tooling can have bugs in their parsing fixed, etc
[15:04] <rbasak> I don't disagree with you though - it's an important consideration. I remain on the fence
[15:05] <teward> good point, I don't disagree, but i'm still hesitant making this the default 3 days before FF, and because I use F2B in many environments where nginx runs, I'm reallllllll hesitant to make this change until I do heavy-duty testing in a dev environment
[15:05] <teward> so I think for 20.04 I'm going to say "Let's defer the discussion of this change to 20.10, until we do more in-depth testing on how this will affect f2b and others we're aware of that parse logs for security purposes"
[15:06] <teward> because I'm realllllllllllllll hesitant changing that this late in the cycle (even though it's not FF< that's still 3 days away...)
[15:06] <teward> not opposed ot the discussion for 20.10 and beyond, but fully opposed to making that change for 20.04 at the moment
[15:06] <teward> 'cause I want to see what F2B does with that change in place from a logging perspective - it might "just work" or it might barf hard, but I want to make sure stuff "works" for the LTS :P
[15:07] <teward> rather than introduce a change and scrable to fix F2B and other Universe items (though I don't think their autopkgtests will catch it)
[15:07] <rbasak> I understand
[15:07] <teward> granted, I have no true say in it, but I'm thinking it's better to err on the side of caution :p
[15:08] <rbasak> You absolutely do have a say
[15:08] <rbasak> It'll be a collective decision
[15:08] <teward> forgive E:FailToMakeSense, I'm not caffeinated yet.
[15:08] <rbasak> But your opinion does weigh in
[15:08] <teward> E:BusyMorning
[15:08] <teward> glad to know it does :)
[22:22] <cgi> is there a good place to install redis 5 for ubuntu 18.04LTS?
[22:22] <pragmaticenigma> can you be more specific in your question cgi?
[22:23] <pragmaticenigma> define "good place" for us
[22:23] <cgi> pragmaticenigma, I can install from source. Is there a better way to get redis 5?
[22:25] <pragmaticenigma> !info redis
[22:26] <pragmaticenigma> cgi, redis v5 is already available in the repositories... no need to install from source
[22:26] <pragmaticenigma> cgi, "sudo apt-get install redis-server" should get you up and running
[22:28] <cgi> pragmaticenigma, 5:4.0.9-1ubuntu0.2 - which version is that 4.0.9? or 5.x?
[22:32] <tomreyn> upstream 4.0.9
[22:34] <cgi> tomreyn, is there a place I can get 5.x redis for ubuntu 18.04LTS?
[22:35] <tomreyn> cgi: possibly, but not in ubuntu
[22:35] <tomreyn> i believe in your ability to run a web search
[22:36] <pragmaticenigma> cgi, Also, you can wait a couple months as redis 5 will be available in Ubuntu 20.04
[22:41] <cgi> pragmaticenigma, is 20.04 an LTS coming out in april?
[22:43] <teward> cgi: yes
[22:44] <pragmaticenigma> !YY.MM | cgi


[00:54] <Unit193> brainwash: Having your fun for the evening?
[09:26] <brainwash> bug 1222021
[09:27] <brainwash> xfpm needs to inhibit the systemd lock-on-lid-close trigger
[09:30] <brainwash> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/gnome-settings-daemon/saucy/revision/248/debian/patches/logind_support.patch
[09:31] <brainwash> ehm, sleep-on-lid-close I mean
[11:50] <brainwash> is it always that silent in this channel after a release? :)
[11:53] <Unit193> Well I'm busy trying to patch something in a language I don't know. :D
[12:05] <brainwash> sounds familiar :)
[12:28] <olbi> hello, do you know when will be fixed that bug with sound indicator? :)
[12:34] <forestpiskie>  /list
[12:34] <forestpiskie> whoops
[12:36] <forestpiskie> olbi: not at the moment I don't - but it's unlikely that anything will happen very soon
[12:37] <olbi> that sounds bad :(
[12:42] <Unit193> brainwash: Except you know what you're doing. :P
[12:48] <brainwash> Unit193: I'm not an expert and I get confused by all the different APIs pretty easily
[12:50] <brainwash> yes, we did it! we hit the 500 heat mark
[13:07] <olbi> so how I can using now sound without this strange fix? :P
[13:08] <olbi> only PulseAudio?
[13:08] <olbi> GUI?
[13:10] <brainwash> this workaround isn't strange
[13:10] <brainwash> it's straightforward
[13:11] <brainwash> apply it and the indicator will work just like in 13.04
[13:12] <olbi> I know that it work, but some says that it could cause some trauble :P
[13:12] <brainwash> the "comment 5" fix?
[13:13] <olbi> comment 27
[13:14] <brainwash> comment 41
[13:14] <brainwash> this one is only needed if you run unity/gnome3 side by side with xubuntu/xfce
[13:15] <brainwash> otherwise use the simple version (comment 5)
[13:15] <olbi> ok
[13:16] <GridCube> brainwash, you understand the things said in comment 41?
[13:16] <GridCube> can you make a simple explaination so i can point people to it to read it? maybe a .sh they can run?
[13:17] <olbi> it could be sh with gksudo :)
[13:17] <GridCube> that would be nice
[13:18] <brainwash> it executes a shell command: test if Xfce is running, if yes -> load the gtk2 sound indicator, if no -> load the gtk3 indicator
[13:19] <olbi> maybe today do it and I could test it
[13:19] <olbi> than send it to mailing list
[13:19] <GridCube> olbi, i dont want to impose him to do anything :)
[13:20] <olbi> this was suggestion :]
[13:20] <GridCube> i don't understand this but its something we eagerly need
[13:21] <olbi> ok, I have another question with translations, in Preferences there are Additional Drivers and Printers, from where they take PO files?
[13:22] <brainwash> to be honest, don't expect any official fix for it, the main goal is to provide a new version of xfce4-panel with the gtk3 indicator wrapper in the backports repository
[13:23] <GridCube> brainwash, i know, but for the moment we need a workaround, and comment 41 seems the most reasonable, if only we can make it user friendly :/
[13:25] <brainwash> it is user friendly
[13:25] <brainwash> or you mean some sort of 1 click script
[13:25] <brainwash> maybe even an extra PPA o.o
[13:28] <GridCube> brainwash, that workaround needs to be run everytime an user start an xfce session? or is it a one time only?
[13:28] <GridCube> no, i dont think a ppa is needed, maybe just a script that can be run
[13:28] <brainwash> one time (until the file gets changes by an update)
[13:28] <brainwash> changed
[13:29] <GridCube> like a "official fix this thing script" from us
[13:30] <brainwash> unofficial
[13:31] <GridCube> well if i can get knome to put in on the xubuntu.org blog that would do it "semi-official" :P
[13:31] <brainwash> the bug report is already linked (known issues list)
[13:31] <GridCube> yes
[13:32] <GridCube> im talking about a script that puts the workaround to work, not just a link to something alien to non programer users
[13:35] <Unit193> Workarounds are always unofficial, the official fix is to wait for the fix.
[13:35] <GridCube> yes
[13:35] <GridCube> true that
[13:36] <GridCube> then i need an unofficial person who understand to make a safe script that i can like people without fear
[13:44] <olbi> Are there Daily Build of stable ISO or it is doing once for some time?
[13:44] <smartboyhw> olbi, for non-LTS releases there will not be any builds after the released image. For LTS releases there will still be daily builds, and releases of images with updates
[13:45] <olbi> smartboyhw: thx
[13:50] <ali1234> GridCube: just link people to the gtk3 instructions :/
[13:51] <GridCube> ali1234, where them?
[13:51] <brainwash> bug 1238997
[13:51] <GridCube> thats confusing
[13:51] <brainwash> link included
[13:51] <ali1234> GridCube: then help to put it in a ppa
[13:51] <GridCube> but thats the fix, that will eventually come anyway
[13:52] <ali1234> yeah, in 14.04
[13:52] <GridCube> yes
[13:52] <ali1234> have fun waiting
[13:52] <GridCube> thats not what im talking about, im talking about giving plain user a simple way to have a working desktop in 5 seconds
[13:52] <ali1234> by editing some configuration files?
[13:52] <ali1234> every time they upgrade?
[13:53] <GridCube> the workaround does that, if i knew how to do the .sh file i would but im afraid ill make mistakes
[13:53] <GridCube> and i don't know what i would be doing
[13:54] <GridCube> thats why i asked if someone who knew could do it, if not then its not really an issue, i will keep pointing people to the bug report and leave them in their own frustration
[13:54] <ali1234> why is it that people want sill workarounds instead of a proper fix?
[13:57] <brainwash> I'll ignore this issue from now on
[14:03] <GridCube> alright then
[16:50] <bluesabre> parole-0.5.90 (dev release for 0.6.0) finally released: http://www.smdavis.us/2013/10/19/parole-media-player-0-5-90/
[16:50] <bluesabre> not that we don't have enough to do around here :)
[16:53] <olbi> :)
[16:53] <olbi> so many changes :D
[16:54] <bluesabre> ochosi and I have been working hard on it for a while now :)
[17:18] <astraljava> ochosi: or anyone really, can you confirm the missing browser text field suggestion list index highlight on Greybird theme? I can see it on Bluebird.
[17:19] <astraljava> Tried on Chrome, will give it a go on Firefox next.
[17:35] <astraljava> Oh well, seems to affect Chrome only.
[17:35] <astraljava> Tough luck
[18:19] <soundnowork> sound no work :(
[18:19] <ali1234> yeah, we know
[18:24] <brainwash> soundnowork: go away
[18:24] <soundnowork> ok, bye
[18:30] <brainwash> ali1234: still no comment on your patch for xfce4-terminal :/
[18:30] <ali1234> i might have the ability to commit it myself, not sure :)
[18:31] <brainwash> go for it! :)
[19:09] <skellat> Some received static: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1208204/comments/66
[19:15] <brainwash> untested is the wrong word :)
[19:16] <brainwash> someone published a "patch" in the previous comment
[20:34] <knome> brainwash, what was that (re: soundnowork)?
[20:55] <brainwash> knome: dunno
[20:56] <brainwash> ochosi: interesting, "dm-tool switch-to-greeter" triggers gnome-screensaver in the active session, but the label shown in the greeter is still labeled "login"
[20:58] <brainwash> ochosi: ah, so it's basically user-switching and screen locking


[03:51] <wxl> infinity: did anyone think to add a testcase for the minimal install. i'm not seeing anything right off hand but… (cc flocculant)
[03:52] <tsimonq2> I don't think it crossed anyone's mind, to be frank.
[03:52] <tsimonq2> Although I would highly encourage it (and would write it myself if nobody else wants to).
[03:53] <wxl> there's https://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-manual-tests/trunk/view/head:/testcases/image/1640_Install_Minimal_System but i'm pretty sure that's something different
[03:54] <wxl> …given it's from 2014 XD
[03:55] <wxl> tsimonq2: fwiw i don't see that same error but yeah it's got all the apps
[03:55] <tsimonq2> wxl: Wrong chan.
[03:55] <wxl> bah
[03:55] <tsimonq2> (We're also discussing Lubuntu-specific issues in #lubuntu-devel.)
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [amd64] (cosmic-proposed) [0.8.4-1]
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [armhf] (cosmic-proposed) [0.8.4-1]
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [ppc64el] (cosmic-proposed) [0.8.4-1]
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [arm64] (cosmic-proposed) [0.8.4-1]
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [s390x] (cosmic-proposed) [0.8.4-1]
[03:59] -queuebot:#ubuntu-release- New: accepted nftables [i386] (cosmic-proposed) [0.8.4-1]
[04:37] -queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4 => 3.28.1-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[04:59] <tsimonq2> O_o what's up with the cosmic huge autopkgtest queue?
[04:59] <tsimonq2> cosmic<PHONE_NUMBER> - 993 -
[04:59] <tsimonq2> armhf is disproportionally large.
[04:59] <tsimonq2> (disproportionately maybe)
[05:03] -queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.28.1-0ubuntu5 => 3.28.1-0ubuntu6] (ubuntu-desktop)
[05:37] -queuebot:#ubuntu-release- Unapproved: command-not-found (cosmic-proposed/main) [18.04.4 => 18.10.0~pre1] (core)
[05:52] <flocculant> wxl tsimonq2 - if we'd used this minimal install thing then I would have thought of a testcase and added it to our testsuites :)
[05:53] <wxl> flocculant: isn't it in your installer though?
[05:53] <flocculant> nope
[05:53] <wxl> oh hm
[05:53] <flocculant> we do the semi-official core iso thing instead
[05:53] <wxl> yeah and that's what we've always done and what i expected, so i was surprised to see it there
[05:53] <wxl> what did you need to do to remove it?
[05:54] <wxl> s/it/minimal install option on the installer/
[05:55] <flocculant> didn't do anything to remove it
[05:56] <wxl> ah it must be you have to have the remove file in the seed in order for it to appear
[05:56] <wxl> ^^ that said, tsimonq2, if we want, we may just want to opt to get rid of the minimal install altogether
[05:56] <flocculant> afaik that's the case
[05:57] <tsimonq2> wxl: JFDI.
[05:57] <wxl> tsimonq2: is that what we want, though? i mean you went through the trouble of putting us on the list.. think about it and reply to that bug tomorrow after you've had some sleep
[06:30] <valorie> wxl, tsimonq2 - talk to acheronuk about it
[06:31] <valorie> the kubuntu one worked flawlessly
[06:31] <valorie> minimal install
[06:31] <wxl> well, we have a theory i think...
[06:41] -queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.32.6+18.10ubuntu1 => 2.32.6+18.10ubuntu2] (desktop-core, ubuntu-server)
[06:46] -queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (cosmic-proposed) [18.10.0~pre1]
[06:46] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.32.6+18.10ubuntu2]
[06:46] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.28.1-0ubuntu6]
[07:29] -queuebot:#ubuntu-release- Unapproved: tomcat8 (cosmic-proposed/universe) [8.5.30-1ubuntu1 => 8.5.30-1ubuntu2] (kubuntu)
[07:40] -queuebot:#ubuntu-release- Unapproved: mesa (cosmic-proposed/main) [18.0.2-2ubuntu1 => 18.0.2-2ubuntu2] (core, xorg)
[08:32] <tjaalton> huh, cosmic isn't really open yet?
[08:49] <acheronuk> pre-release freeze :/
[09:20] -queuebot:#ubuntu-release- Unapproved: cloudcompare (cosmic-proposed/universe) [2.9.1+git20180223-1 => 2.9.1+git20180223-1build1] (no packageset)
[09:24] -queuebot:#ubuntu-release- Unapproved: gr-gsm (cosmic-proposed/universe) [0.41.2-2build1 => 0.41.2-2build2] (no packageset)
[09:24] -queuebot:#ubuntu-release- Unapproved: openggsn (cosmic-proposed/universe) [0.92-2build1 => 0.92-2build2] (no packageset)
[09:24] -queuebot:#ubuntu-release- Unapproved: openbsc (cosmic-proposed/universe) [1.0.0-2build1 => 1.0.0-2build2] (no packageset)
[09:29] -queuebot:#ubuntu-release- Unapproved: baresip (cosmic-proposed/universe) [0.5.7-1build1 => 0.5.7-1build2] (no packageset)
[09:29] -queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (cosmic-proposed/universe) [1.14.0-1ubuntu1 => 1.14.0-1ubuntu2] (kubuntu)
[09:29] -queuebot:#ubuntu-release- Unapproved: libheif (cosmic-proposed/universe) [1.1.0-2 => 1.1.0-2build1] (no packageset)
[09:29] -queuebot:#ubuntu-release- Unapproved: ffmpeg (cosmic-proposed/universe) [7:3.4.2-2 => 7:3.4.2-2build1] (kubuntu)
[09:29] -queuebot:#ubuntu-release- Unapproved: xpra (cosmic-proposed/universe) [2.1.3+dfsg-1ubuntu1 => 2.1.3+dfsg-1ubuntu2] (no packageset)
[09:29] -queuebot:#ubuntu-release- Unapproved: handbrake (cosmic-proposed/universe) [1.1.0+ds1-1ubuntu1 => 1.1.0+ds1-1ubuntu2] (no packageset)
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted baresip [source] (cosmic-proposed) [0.5.7-1build2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [source] (cosmic-proposed) [1.14.0-1ubuntu2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted libheif [source] (cosmic-proposed) [1.1.0-2build1]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted ffmpeg [source] (cosmic-proposed) [7:3.4.2-2build1]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted xpra [source] (cosmic-proposed) [2.1.3+dfsg-1ubuntu2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted handbrake [source] (cosmic-proposed) [1.1.0+ds1-1ubuntu2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted cloudcompare [source] (cosmic-proposed) [2.9.1+git20180223-1build1]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (cosmic-proposed) [18.0.2-2ubuntu2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted openggsn [source] (cosmic-proposed) [0.92-2build2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted gr-gsm [source] (cosmic-proposed) [0.41.2-2build2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (cosmic-proposed) [8.5.30-1ubuntu2]
[09:32] -queuebot:#ubuntu-release- Unapproved: accepted openbsc [source] (cosmic-proposed) [1.0.0-2build2]
[09:39] -queuebot:#ubuntu-release- Unapproved: gnuradio (cosmic-proposed/universe) [<IP_ADDRESS>-2 => <IP_ADDRESS>-2build1] (no packageset)
[09:39] -queuebot:#ubuntu-release- Unapproved: gqrx-sdr (cosmic-proposed/universe) [2.9-2 => 2.9-2build1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-air-modes (cosmic-proposed/universe) [0.0.2.c29eb60-2ubuntu1 => 0.0.2.c29eb60-2ubuntu2] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-fosphor (cosmic-proposed/universe) [<IP_ADDRESS>.7b6b996-3 => <IP_ADDRESS>.7b6b996-3build1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-iqbal (cosmic-proposed/universe) [0.37.2-11 => 0.37.2-11build1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-radar (cosmic-proposed/universe) [<IP_ADDRESS>61018-3build1 => <IP_ADDRESS>61018-3build2] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: sdrangelove (cosmic-proposed/universe) [<IP_ADDRESS>50707-2build3 => <IP_ADDRESS>50707-2build4] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-fcdproplus (cosmic-proposed/universe) [<IP_ADDRESS>b6464b-5 => <IP_ADDRESS>b6464b-5build1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-osmosdr (cosmic-proposed/universe) [0.1.4-14build1 => 0.1.4-14build2] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-hpsdr (cosmic-proposed/universe) [1.2-1 => 1.2-1build1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gr-rds (cosmic-proposed/universe) [<IP_ADDRESS>.a542331-2 => <IP_ADDRESS>.a542331-2build1] (no packageset)
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted gnuradio [source] (cosmic-proposed) [<IP_ADDRESS>-2build1]
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted gr-air-modes [source] (cosmic-proposed) [0.0.2.c29eb60-2ubuntu2]
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted gr-fosphor [source] (cosmic-proposed) [<IP_ADDRESS>.7b6b996-3build1]
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted gr-iqbal [source] (cosmic-proposed) [0.37.2-11build1]
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted gr-radar [source] (cosmic-proposed) [<IP_ADDRESS>61018-3build2]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted sdrangelove [source] (cosmic-proposed) [<IP_ADDRESS>50707-2build4]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted gqrx-sdr [source] (cosmic-proposed) [2.9-2build1]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted gr-hpsdr [source] (cosmic-proposed) [1.2-1build1]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted gr-rds [source] (cosmic-proposed) [<IP_ADDRESS>.a542331-2build1]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted gr-fcdproplus [source] (cosmic-proposed) [<IP_ADDRESS>b6464b-5build1]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted gr-osmosdr [source] (cosmic-proposed) [0.1.4-14build2]
[10:17] -queuebot:#ubuntu-release- Unapproved: r-bioc-s4vectors (cosmic-proposed/universe) [0.18.1-2 => 0.18.1-2ubuntu1] (no packageset)
[10:32] -queuebot:#ubuntu-release- Unapproved: accepted r-bioc-s4vectors [source] (cosmic-proposed) [0.18.1-2ubuntu1]
[11:23] -queuebot:#ubuntu-release- New binary: m2crypto [amd64] (cosmic-proposed/universe) [0.27.0-6] (no packageset)
[11:40] -queuebot:#ubuntu-release- New: accepted m2crypto [amd64] (cosmic-proposed) [0.27.0-6]
[11:58] <LocutusOfBorg> tjaalton, hello, ping wrt ext-pack?
[11:59] <tjaalton> LocutusOfBorg: huh?
[13:10] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (bionic-proposed) [18.04.0]
[13:49] -queuebot:#ubuntu-release- Unapproved: ocrmypdf (cosmic-proposed/universe) [6.1.2-1ubuntu2 => 6.2.0-1] (no packageset) (sync)
[13:52] -queuebot:#ubuntu-release- Unapproved: r-cran-optparse (cosmic-proposed/universe) [1.4.4-1ubuntu1 => 1.4.4-2] (no packageset) (sync)
[13:53] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [<IP_ADDRESS>]
[13:59] -queuebot:#ubuntu-release- Unapproved: node-foreground-child (cosmic-proposed/universe) [1.5.6-4ubuntu2 => 1.5.6-6] (no packageset) (sync)
[13:59] <doko> LocutusOfBorg: your cmake merge seems to break the vtk7 autopkg tests
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted node-foreground-child [sync] (cosmic-proposed) [1.5.6-6]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted r-cran-optparse [sync] (cosmic-proposed) [1.4.4-2]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted ocrmypdf [sync] (cosmic-proposed) [6.2.0-1]
[14:07] -queuebot:#ubuntu-release- Unapproved: gnss-sdr (cosmic-proposed/universe) [0.0.9-5build3 => 0.0.9-5build4] (no packageset)
[14:07] -queuebot:#ubuntu-release- Unapproved: soapyuhd (cosmic-proposed/universe) [0.3.4-1build1 => 0.3.4-1build2] (no packageset)
[14:07] -queuebot:#ubuntu-release- Unapproved: osmo-trx (cosmic-proposed/universe) [0.2.0-2 => 0.2.0-2build1] (no packageset)
[14:09] -queuebot:#ubuntu-release- Unapproved: accepted gnss-sdr [source] (cosmic-proposed) [0.0.9-5build4]
[14:09] -queuebot:#ubuntu-release- Unapproved: accepted soapyuhd [source] (cosmic-proposed) [0.3.4-1build2]
[14:09] -queuebot:#ubuntu-release- Unapproved: accepted osmo-trx [source] (cosmic-proposed) [0.2.0-2build1]
[14:32] <wxl> flocculant: crazy thought i hadn't considered: what about making the "minimal install" actually produce your xubuntu core? any reason you didn't do that?
[14:32] <flocculant> well
[14:32] <flocculant> wxl: we started looking at core a long long time ago
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.4-0ubuntu1.1]
[14:41] -queuebot:#ubuntu-release- Unapproved: rejected tomcat8 [source] (bionic-proposed) [8.5.30-1ubuntu1.1]
[14:42] <wxl> flocculant: so no good reason? :)
[14:46] <flocculant> wxl: so you mean this new thing that apparently doesn't work for lubuntu?
[14:46] <flocculant> ;)
[14:46] <flocculant> anyway - I don't decide on those things - just ack or nack when we vote
[14:47] <wxl> flocculant: well with us having a split seed, i'm sort of not surprised it doesn't work. it's working fine for everyone else. so you all did vote on whether or not to be included?
[14:48] <flocculant> nope - not sure we took much notice of the option
[14:49] <wxl> well we also have had a "core" option and though i had originally thought maybe we should keep to what desktop team envisioned core to be, i'm more inclined to think that maybe this is the easy way for someone to install core as we have done it rather than using the mini.iso
[14:50] <flocculant> mmm
[14:50] <wxl> i meant what the desktop team envisioned "minimal" to be
[14:54] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1]
[14:54] <didrocks> minimal is supposed to be normal image without large applications
[14:54] <flocculant> ack
[14:54] <didrocks> basically, I added the support to ubiquity for every flavors
[14:54] <flocculant> ack that too
[14:55] <didrocks> you only need to ensure you produce a file at the right place with the list of packages to be removed from minimal
[14:55] <didrocks> no reason it doesn't work for you ;)
[14:55] <flocculant> we just haven't looked because we do something else
[14:55] <didrocks> sure, just telling it's supposed to work for you, if not, just ping us :)
[14:55] <flocculant> pre 16.04 iirc
[14:55] <didrocks> I took care the option doesn't impact you if you don't want to support it
[14:56] <flocculant> didrocks: well it hasn't done that :D
[14:56] <didrocks> good ;)
[14:56] <didrocks> hasn't as "didn't create any negative impact", right?
[14:57] <flocculant> yea - I'd have said something a long time ago if it has lol
[14:57] <flocculant> s/has/had
[14:57] <didrocks> heh
[14:59] <flocculant> and now I know it was you I know where to go in future :p
[15:00] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (artful-proposed) [3.186.2]
[15:06] <ddstreet> bdmurray re: ifupdown bionic upload in unapproved queue, can you reject that and i'll re-upload with corrected version number?  (or can i just re-upload over the existing upload?)
[15:07] <bdmurray> ddstreet: you can just reupload and there'll be 2 in the queue
[15:07] <bdmurray> ddstreet: I'll reject the first one though
[15:08] <ddstreet> ok ack, will do thnx
[15:08] <ddstreet> bdmurray and to confirm, i don't need to worry about cosmic (yet) right
[15:09] -queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (artful-proposed) [1.26.0-0ubuntu2]
[15:09] <bdmurray> ddstreet: I haven't seen an email about it being opened yet
[15:09] <ddstreet> k
[15:11] -queuebot:#ubuntu-release- Unapproved: rejected ifupdown [source] (bionic-proposed) [0.8.17ubuntu2]
[15:20] -queuebot:#ubuntu-release- Unapproved: gpgme1.0 (cosmic-proposed/main) [1.10.0-1ubuntu1 => 1.11.1-1ubuntu1] (core)
[15:25] -queuebot:#ubuntu-release- Unapproved: ifupdown (bionic-proposed/main) [0.8.17ubuntu1 => 0.8.17ubuntu1.1] (ubuntu-desktop, ubuntu-server)
[15:35] -queuebot:#ubuntu-release- Unapproved: wget (cosmic-proposed/main) [1.19.4-1ubuntu2 => 1.19.5-1ubuntu1] (core)
[15:45] <ddstreet> sil2100 hello sru vangaurd, if you have time can you review ifupdown and vlan in the bionic queue, for lp #1701023?  thnx!
[15:46] <ddstreet> i just reuploaded ifupdown with corrected version number as discussed above
[15:57] <sil2100> ddstreet: ok o/
[15:57] <ddstreet> thnx!
[15:58] <sil2100> I see the description has been modified, looking at those now
[16:03] -queuebot:#ubuntu-release- Unapproved: zsh (cosmic-proposed/main) [5.4.2-3ubuntu4 => 5.5.1-1ubuntu1] (core)
[16:06] -queuebot:#ubuntu-release- Unapproved: ryu (cosmic-proposed/main) [4.15-0ubuntu2 => 4.24+dfsg1-4ubuntu1] (ubuntu-server)
[16:10] -queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (bionic-proposed) [1.9-3.2ubuntu6]
[16:13] -queuebot:#ubuntu-release- Unapproved: accepted ifupdown [source] (bionic-proposed) [0.8.17ubuntu1.1]
[16:38] -queuebot:#ubuntu-release- Unapproved: rasdaemon (bionic-proposed/universe) [0.6.0-1 => 0.6.0-1ubuntu0.1] (no packageset)
[17:09] <jbicha> doko: how's that cosmic opening announcement email coming? :)
[17:15] <wxl> jbicha: according to mark's blog it seems like the codename will be Cosmic sCam
[17:16] <jbicha> wxl: I read it as Cosmic Cryptocurrency but I guess it has about the same meaning, right?
[17:16] <wxl> XD
[17:17]  * wxl waits for cosmocoin ICO
[17:18] <jbicha> as long as that email doesn't come from Mark… :)
[17:18] <wxl> hey i don't know maybe that's how canonical can make a little extra dosh :)
[17:18] <infinity> Pass.
[17:22] <LocutusOfBorg> tjaalton, the virtualbox-ext-pack sru
[17:23] -queuebot:#ubuntu-release- New binary: libncursesada [amd64] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: libncursesada [ppc64el] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: libncursesada [i386] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[17:23] <LocutusOfBorg> I can change the versioning, but I don't think there is a real need for it
[17:25] -queuebot:#ubuntu-release- New binary: limesuite [ppc64el] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: limesuite [s390x] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: limesuite [i386] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [ppc64el] (cosmic-proposed/none) [1.2.4-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ruby-cucumber-expressions [amd64] (cosmic-proposed/none) [5.0.13-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [s390x] (cosmic-proposed/none) [1.2.4-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: limesuite [amd64] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ruby-erubi [amd64] (cosmic-proposed/none) [1.7.1-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [amd64] (cosmic-proposed/none) [1.2.4-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: aravis [amd64] (cosmic-proposed/none) [0.5.11-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [i386] (cosmic-proposed/none) [1.2.4-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-minitest-focus [amd64] (cosmic-proposed/none) [1.1.2-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-process-daemon [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-rollout [amd64] (cosmic-proposed/none) [2.4.3-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ros-genpy [amd64] (cosmic-proposed/universe) [0.6.7-2] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-omniauth-jwt [amd64] (cosmic-proposed/none) [0.0.2-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-statsd [amd64] (cosmic-proposed/none) [1.4.0-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-googleapis-common-protos-types [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: ruby-rack-timeout [amd64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: libncursesada [arm64] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: libncursesada [armhf] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[17:31] -queuebot:#ubuntu-release- New binary: tiled-qt [s390x] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- Unapproved: evolution-data-server (cosmic-proposed/main) [3.28.1-1ubuntu1 => 3.28.2-1] (ubuntu-desktop) (sync)
[17:33] -queuebot:#ubuntu-release- New binary: tiled-qt [ppc64el] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: tiled-qt [amd64] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[17:38] -queuebot:#ubuntu-release- New binary: limesuite [armhf] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: limesuite [arm64] (cosmic-proposed/universe) [18.04.1+dfsg-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [arm64] (cosmic-proposed/universe) [1.2.4-1] (no packageset)
[17:40] -queuebot:#ubuntu-release- New binary: ruby-ed25519 [armhf] (cosmic-proposed/universe) [1.2.4-1] (no packageset)
[17:43] -queuebot:#ubuntu-release- New binary: tiled-qt [i386] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[17:53] -queuebot:#ubuntu-release- Unapproved: keyutils (cosmic-proposed/main) [1.5.9-9.2ubuntu2 => 1.5.9-9.2ubuntu3] (core)
[17:57] -queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [sync] (cosmic-proposed) [3.28.2-1]
[17:57] -queuebot:#ubuntu-release- Unapproved: accepted keyutils [source] (cosmic-proposed) [1.5.9-9.2ubuntu3]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [amd64] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [armhf] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [ppc64el] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [arm64] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [s390x] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-ed25519 [i386] (cosmic-proposed) [1.2.4-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-cucumber-expressions [amd64] (cosmic-proposed) [5.0.13-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-googleapis-common-protos-types [amd64] (cosmic-proposed) [1.0.1-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-omniauth-jwt [amd64] (cosmic-proposed) [0.0.2-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-rack-timeout [amd64] (cosmic-proposed) [0.4.2-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-statsd [amd64] (cosmic-proposed) [1.4.0-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-erubi [amd64] (cosmic-proposed) [1.7.1-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-process-daemon [amd64] (cosmic-proposed) [1.0.1-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-minitest-focus [amd64] (cosmic-proposed) [1.1.2-1]
[17:58] -queuebot:#ubuntu-release- New: accepted ruby-rollout [amd64] (cosmic-proposed) [2.4.3-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [amd64] (cosmic-proposed) [18.04.1+dfsg-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [armhf] (cosmic-proposed) [18.04.1+dfsg-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [ppc64el] (cosmic-proposed) [18.04.1+dfsg-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [arm64] (cosmic-proposed) [18.04.1+dfsg-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [s390x] (cosmic-proposed) [18.04.1+dfsg-1]
[17:59] -queuebot:#ubuntu-release- New: accepted limesuite [i386] (cosmic-proposed) [18.04.1+dfsg-1]
[18:00] -queuebot:#ubuntu-release- New binary: tesseract-lang [amd64] (cosmic-proposed/universe) [1:4.00~git30-7274cfa-1] (no packageset)
[18:01] -queuebot:#ubuntu-release- New: accepted ros-genpy [amd64] (cosmic-proposed) [0.6.7-2]
[18:01] -queuebot:#ubuntu-release- New binary: tiled-qt [arm64] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[18:03] -queuebot:#ubuntu-release- New binary: libncursesada [s390x] (cosmic-proposed/universe) [6.1.20180127-1] (no packageset)
[18:03] -queuebot:#ubuntu-release- New binary: tiled-qt [armhf] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [amd64] (cosmic-proposed) [6.1.20180127-1]
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [armhf] (cosmic-proposed) [6.1.20180127-1]
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [ppc64el] (cosmic-proposed) [6.1.20180127-1]
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [arm64] (cosmic-proposed) [6.1.20180127-1]
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [s390x] (cosmic-proposed) [6.1.20180127-1]
[18:03] -queuebot:#ubuntu-release- New: accepted libncursesada [i386] (cosmic-proposed) [6.1.20180127-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tesseract-lang [amd64] (cosmic-proposed) [1:4.00~git30-7274cfa-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [arm64] (cosmic-proposed) [1.1.5-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [i386] (cosmic-proposed) [1.1.5-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [s390x] (cosmic-proposed) [1.1.5-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [amd64] (cosmic-proposed) [1.1.5-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [ppc64el] (cosmic-proposed) [1.1.5-1]
[18:04] -queuebot:#ubuntu-release- New: accepted tiled-qt [armhf] (cosmic-proposed) [1.1.5-1]
[18:45] -queuebot:#ubuntu-release- Unapproved: gummi (cosmic-proposed/universe) [0.6.6-4build1 => 0.6.6-4ubuntu1] (no packageset)
[18:54] -queuebot:#ubuntu-release- Unapproved: accepted gummi [source] (cosmic-proposed) [0.6.6-4ubuntu1]
[19:05] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (cosmic-proposed/main) [20ubuntu4 => 20ubuntu5] (ubuntu-desktop)
[19:16] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (cosmic-proposed/main) [20ubuntu4 => 21ubuntu1] (ubuntu-desktop)
[19:20]  * tumbleweed wonders if we'll ever get a name
[19:20] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (cosmic-proposed/universe) [16ubuntu4 => 17ubuntu1] (no packageset)
[19:26] <tsimonq2> tumbleweed: Cosmic CANIMAL. :P
[19:26] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7-cross-ports [source] (cosmic-proposed) [17ubuntu1]
[19:26] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7-cross [source] (cosmic-proposed) [21ubuntu1]
[19:26] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (cosmic-proposed/main) [20ubuntu4 => 21ubuntu2] (ubuntu-desktop)
[19:26] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7-cross [source] (cosmic-proposed) [20ubuntu5]
[19:27] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (cosmic-proposed/universe) [16ubuntu4 => 17ubuntu2] (no packageset)
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [source] (cosmic-proposed) [17ubuntu2]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted gpgme1.0 [source] (cosmic-proposed) [1.11.1-1ubuntu1]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted wget [source] (cosmic-proposed) [1.19.5-1ubuntu1]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [source] (cosmic-proposed) [21ubuntu2]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted zsh [source] (cosmic-proposed) [5.5.1-1ubuntu1]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted ryu [source] (cosmic-proposed) [4.24+dfsg1-4ubuntu1]
[19:42] <ErichEickmeyer> tsimonq2: My son used to watch that show.
[19:42] <tsimonq2> ErichEickmeyer: hehe
[19:50] -queuebot:#ubuntu-release- Unapproved: clipper (cosmic-proposed/universe) [2.1.20130601-2.1ubuntu1 => 2.1.20130601-2.1ubuntu2] (no packageset)
[19:50] -queuebot:#ubuntu-release- Unapproved: gpp4 (cosmic-proposed/universe) [1.3.1-0ubuntu5 => 1.3.1-0ubuntu6] (no packageset)
[19:52] -queuebot:#ubuntu-release- Unapproved: deal.ii (cosmic-proposed/universe) [8.5.1-3 => 8.5.1-3build1] (no packageset)
[19:52] -queuebot:#ubuntu-release- Unapproved: getdp (cosmic-proposed/universe) [2.11.3+dfsg1-1 => 2.11.3+dfsg1-1build1] (no packageset)
[19:52] -queuebot:#ubuntu-release- Unapproved: dolfin (cosmic-proposed/universe) [2017.2.0.post0-3 => 2017.2.0.post0-3build1] (no packageset)
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted clipper [source] (cosmic-proposed) [2.1.20130601-2.1ubuntu2]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted dolfin [source] (cosmic-proposed) [2017.2.0.post0-3build1]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted gpp4 [source] (cosmic-proposed) [1.3.1-0ubuntu6]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted deal.ii [source] (cosmic-proposed) [8.5.1-3build1]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted getdp [source] (cosmic-proposed) [2.11.3+dfsg1-1build1]
[19:56] <tsimonq2> infinity: Kylin and Budgie did their Git conversions so far.
[19:56] <tsimonq2> So I guess some tooling bits need to have tweaks.
[19:57] <tsimonq2> I'd expect bashfulrobot to get something for that, but I haven't heard from handsonme_feng yet.
[19:57] <tsimonq2> *handsome_feng
[20:01] <bashfulrobot> infinity: just a FYI. I'm Midway through the conversion. It's not yet completed. I'm mostly doing double duty while I'm at work. :-)
[20:02] <tsimonq2> Right; I'm about to run away for a few hours myself.
[21:02] <enyc> hrrm I can't remember which channel this discussion happened in...  e2fsprogs in bionic did get resolved, and at the time (SOME) people were talking of supprting a xenial-SRU in e2fsprogs.
[21:02] <enyc> https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874   ....  was talk of sortin out a SRU after bionic got released, at the time.
[21:03] <enyc> maybe robbie basalisk or whoenver it is could pickup and create SRU bug similarly to dealing with bionic FFE ...
[21:40] -queuebot:#ubuntu-release- Unapproved: xfce4-power-manager (cosmic-proposed/universe) [1.6.1-0ubuntu1 => 1.6.1-1] (xubuntu) (sync)
[21:42] -queuebot:#ubuntu-release- Unapproved: xfce4-whiskermenu-plugin (cosmic-proposed/universe) [2.1.5-0ubuntu1 => 2.1.7-1] (xubuntu) (sync)
[23:22] -queuebot:#ubuntu-release- New binary: hoel [ppc64el] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: hoel [s390x] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: hoel [i386] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: hoel [amd64] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: ulfius [ppc64el] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: ulfius [s390x] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:29] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.15.0-21.22~16.04.1]
[23:29] -queuebot:#ubuntu-release- New binary: ulfius [amd64] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:30] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (xenial-proposed) [4.15.0-21.22~16.04.1]
[23:30] -queuebot:#ubuntu-release- New binary: ulfius [i386] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: ruby-rjb [amd64] (cosmic-proposed/universe) [1.5.5-3] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: ruby-rjb [i386] (cosmic-proposed/universe) [1.5.5-3] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: hoel [arm64] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: hoel [armhf] (cosmic-proposed/universe) [1.4.2-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- Unapproved: plymouth (artful-proposed/main) [0.9.2-3ubuntu19 => 0.9.2-3ubuntu20] (core)
[23:45] -queuebot:#ubuntu-release- Unapproved: plymouth (xenial-proposed/main) [0.9.2-3ubuntu13.4 => 0.9.2-3ubuntu13.5] (core)
[23:46] -queuebot:#ubuntu-release- New binary: ulfius [arm64] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:47] -queuebot:#ubuntu-release- New binary: ulfius [armhf] (cosmic-proposed/universe) [2.3.4-3] (no packageset)
[23:53] -queuebot:#ubuntu-release- Unapproved: plymouth (trusty-proposed/main) [0.8.8-0ubuntu17.1 => 0.8.8-0ubuntu17.2] (core)


[01:40] <BlueProtoman> Slight problem.  I'm trying to upgrade from Ubuntu 13.04 to 13.10.  I'm doing so by running "update-manager -c" via the terminal.  But even though I'm prompted to upgrade to 13.10, I'm just told "No new release found".  Any tips?
[01:44] <wilee-nilee> BlueProtoman, set the software sources to all releases and use the software updater
[01:45] <wilee-nilee> remove any ppa's with ppa-purge
[01:45] <BlueProtoman> wilee-nilee: I'm not getting any package conflicts or anything.  I can install software just fine, I can even get upgrades.  It's just Ubuntu itself.  (Though I will try your suggestion.)
[01:45] <wilee-nilee> a pray, lol
[01:46] <wilee-nilee> and*
[01:46] <wilee-nilee> I think the -c is old
[01:47] <BlueProtoman> I already have those settings enabled, no luck.
[01:48] <BlueProtoman> Thoughts, wilee-nilee?
[01:48] <wilee-nilee> BlueProtoman, https://help.ubuntu.com/community/SaucyUpgrades try this wiki
[01:48] <wilee-nilee> I have to go see a talk in a minute or so is all
[01:48] <wilee-nilee> Bill Ayer's an original weatherman
[01:50] <BlueProtoman> Who?
[01:51] <odium> halp. happy halloween too.
[01:51] <BlueProtoman> wilee-nilee: Also, the wiki worked, thanks!
[01:51] <odium> I tried to write a init script, but I only used my rudimentary understanding of bash scripts.
[01:51] <wilee-nilee> BlueProtoman, Cool, I noticed the -d, enjoy
[01:51] <BlueProtoman> wilee-nilee: Thank you very much!
[01:51] <odium> it works great but one thing that wont work is this line COMMAND="/bin/dd if=${DEV} bs=512 count=64 | /sbin/cryptsetup luksOpen ${DEV}3 -- --key-file=- ${MAPPER}"
[01:51] <odium> start-stop-daemon --start --exec ${COMMAND}
[01:52] <wilee-nilee> odium, Not much going on here, with the transition to 14.04
[01:52] <wilee-nilee> BlueProtoman, no prob. ;)
[04:55] <SuperLag> Malinux: seems to me like the daily image is the same as it was on 10/21, nothing has been done with it since then
[04:56] <SuperLag> How I arrive at that conclusion (perhaps faulty, who knows?) is I have a script set to download the latest .zsync file for the daily, and run zsync against my current downloaded file.
[04:57] <SuperLag> The date stamp says 10/21, and for the last several days... no changes.
[04:57] <SuperLag> Perhaps the devs are taking a much needed/deserved break ;)
[04:59] <SuperLag> oh yep... same thing on the website
[04:59] <SuperLag> since someone here... I think it was penguin42, intro'd me to zsync, I haven't gone to the website to look... all scripted
[07:54] <alkisg> In Trusty with gnome-flashback, in the main menu, there's a new "Utilities" submenu where most of the 12.04 "Accessories" submenu entries have moved into
[07:55] <alkisg> But there are a few left in the "Accessories" submenu, e.g. contacts, gedit...
[07:55] <alkisg> Should I file a bug report for all programs that still use the Accessories submenu?
[08:19] <Fudge> g'day folks, so looking forward to Trusty
[09:03] <Malinux> SuperLag: If I install the daylybuilds and they upgrade it will I get an upgrade via softwarecenter, or do I have to reinstall ? I hope the first :)
[09:05] <wilee-nilee> Malinux, at release you can upgrade there, there are 14.04 dailies.
[09:06] <wilee-nilee> is that what you meant?
[09:06] <Malinux> I meant. If I install 14.04 dayily on my computer, Do I have to reinstall 14.04 everytime when there is a new daily build?
[09:08] <wilee-nilee> Malinux, nope just update it it is the daily up to release, no reinstalls unless it goes south and you can't fix it.
[09:10] <wilee-nilee> I would have 14.04 as a dual boot is all, not recommended for your main OS
[09:12] <Malinux> wilee-nilee: I know it's not recomanded for main os yet. I want to dualboot it for testing it and reporting bugs.
[09:13] <wilee-nilee> Malinux, Cool, hop onboard I have been running it since a day or so past the 13.10 release.
[09:13] <Malinux> the question is  still. Do I have to reinstall it for every update, or is it updated through update manager as normal befor it goes alpha and beta and so on?
[09:13] <Malinux> wilee-nilee: okey :)
[09:14] <wilee-nilee> Malinux, There are tester that reinstall often to do special testing, but no a regular user just run updates and reports any anomalies.
[09:14] <wilee-nilee> some install daily to test the install
[09:16] <wilee-nilee> it updates normally, you just want to watch for partial updates and not run them is all, you will see them announced in the update manager.
[09:17] <Malinux> okey. thanx :)
[09:17] <wilee-nilee> no prob
[11:21] <BluesKaj> Hey folks
[11:32] <elfy> hi BluesKaj


[00:04]  * luke-jr gives up on snaps for now
[01:57] <AlexPortable> How do I solve launch failed: CPU does not support KVM extensions
[07:11] <mup> PR snapd#6827 closed: packaging: fix changelog typo <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6827>
[11:41] <mup> PR snapd#6828 opened: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
[11:43] <mup> PR snapd#6829 opened: devicestate: use deviceCtx in checkGadgetOrKernel <Created by pedronis> <https://github.com/snapcore/snapd/pull/6829>
[12:24] <antis> Hey, has anyone experience with building snaps on manjaro? I read on the documentation (https://docs.snapcraft.io/build-on-docker) and wonder if the "Multipass" works (better?)…
[15:39] <tooijar> Is there an easy way to get X11 connectivity for a service running as a daemon? I'm starting my app as a daemon but the logs are showing Unable to open X display.
[15:39] <tooijar> I have app.environment.DISPLAY=":0"
[15:54] <brlin> antis: Currently only Multipass is fully supported AFAICT
[16:34] <zyga> tooijar: hey, it's in general hard-ish
[16:34] <zyga> tooijar: in a portable way, that is
[16:38] <tooijar> zyga: what about a non-portable way :)    Even just Ubuntu1804 LTS would be nice for now.
[16:44] <ogra> tooijar, thats trivial ... you need to use mir-kiosk and can then use XWayland on top of it
[16:44] <ogra> well ... FSVO "trivial" :)
[16:45] <ogra> tooijar, not sure how outdated this is (some things might have changed since it was published) https://tutorials.ubuntu.com/tutorial/x11-kiosk#0
[16:45] <tooijar> Seems like a permission problem because after 'xhost +' it started up just fine
[16:47] <ogra> note though that the combination of X11 and "daemon" will make your snap get stuck in manual review when uploading to the store ... it needs one initial approval typically
[16:50] <tooijar> ogra: thanks...maybe I can just go with a desktop file that has autostart in it.
[16:54] <tooijar> ogra: Perhaps you could clarify....if I end up using mir-kiosk (which as far as I understand adds additional security since it isn't traditional X) would I still need manual review with the daemon option?
[23:25] <mup> PR snapcraft#2554 closed: release: 3.4.1 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2554>
[23:46] <mup> PR snapcraft#2553 closed: ci: use --destructive-mode to build snap in travis <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2553>


[04:20] <rmcadams> With "Add Chassis" - with the type virsh - should it add all libvirt machines it finds on a host?
[04:21] <rmcadams> I can't find anything that covers it via my google searches... or in the docs.
[09:31] <mup> Bug #1657375 opened: RFE: DNS and DHCP <MAAS:New> <https://launchpad.net/bugs/1657375>
[09:31] <mup> Bug #1657378 opened: RFE: SSH Port and Listen <MAAS:New> <https://launchpad.net/bugs/1657378>
[13:38] <n8behavior> Anyone getting "failed to detect a valid IP address from -1"?  This is a fresh install of MaaS 2.1.1+bzr5544 on a fresh/update-to-date Ubuntu server 16.04.1.
[13:39] <n8behavior> Also have more deets here: http://askubuntu.com/questions/873106/failed-to-detect-a-valid-ip-address-from-1
[13:39] <n8behavior> Thought I'd run the table before filing a bug report
[14:25] <mup> Bug #1657471 opened: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
[14:34] <mup> Bug #1657471 changed: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
[14:37] <mup> Bug #1657471 opened: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
[15:20] <mup> Bug #1657491 opened: Several IPs assigned to the same iface in the DB due to 'free' leases <sts> <MAAS:New> <https://launchpad.net/bugs/1657491>
[16:50] <mup> Bug #1657520 opened: Cannot add device with static IP via the API <MAAS:New> <https://launchpad.net/bugs/1657520>
[17:02] <mup> Bug #1657520 changed: Cannot add device with static IP via the API <MAAS:New> <https://launchpad.net/bugs/1657520>
[17:14] <mup> Bug #1657520 opened: Cannot add device with static IP via the API <MAAS:Triaged> <https://launchpad.net/bugs/1657520>
[18:17] <capncrunch4me> I have 400 servers to provision using MAAS, can I do this over a single L2 VLAN on a /22 network using MAAS?
[18:54] <capncrunch4me> what am I going to need to scale out to accomodate this?
[19:01] <pmatulis> capncrunch4me, i don't see any problem using maas for what you want to do
[19:01] <capncrunch4me> normal 2-node HA install should do the trick?
[19:01] <capncrunch4me> i mean, it strikes me that maas really is only hit hard is during provisioning a node
[19:01] <capncrunch4me> im not suggesting mass’ing up 400 nodes at once, we would stagger provisioning
[19:03] <pmatulis> capncrunch4me, there are docs for implementing HA in maas but, apart from that, i don't think you'll need anything special
[19:05] <capncrunch4me> k cool, thanks
[19:05] <capncrunch4me> just wanted to make sure it scaled out of the box
[19:05] <capncrunch4me> 400 nodes is quite a bit different than 50
[19:06] <pmatulis> capncrunch4me, i think you you should consider a 2nd rack controller after 1000 nodes
[19:07] <capncrunch4me> ok
[20:41] <n8behavior> Fresh install of MaaS on 14.04 does not work out-of-the-box.  Anyone able to successfully package install?
[20:45] <mup> Bug #1657577 opened: 2.1.3: Dashboard page crashes <oil> <MAAS:New> <https://launchpad.net/bugs/1657577>


[03:08] <HoppingMadMan> Am I crazy but the Ubuntu Software Center has been getting bugger and bugger with ever version of Ubuntu
[03:15] <HoppingMadMan> I find if I try to cue up any more then 10 packages I find it crashes on me
[03:39] <darkxst> HoppingMadMan, its being replaced with gnome-software in 16.04
[03:39] <HoppingMadMan> That is good to hear, something has been done
[03:42] <HoppingMadMan> Everything I have been reading about 16.04 is getting me excited, I wish they would do something about Unity, maybe drop it all together
[03:43] <darkxst> why? lots of people like Unity, and there are the flavours for those that don't
[03:44] <HoppingMadMan> Oh I agree, but I feel they really need to work on Unity, it just seem to have its faults and when the community bring it up they tend to ignore it
[03:44] <HoppingMadMan> That is my own personal expenses
[03:47] <darkxst> well they are mainly working on Unity 8, but there has been work on Unity 7 this cycle also
[03:48] <HoppingMadMan> Yeah, maybe it is going to be better we still have awhile to wait, hold of judgment for Unity 8 till then
[03:49] <HoppingMadMan> And at the end of the day, really shouldn't judge as I don't think I could even begin to program a UI
[03:53] <darkxst> still, unity 7 has loads of bug fixes coming for the LTS
[03:55] <HoppingMadMan> Ok, yeah.. But Linux hay, if you don't like it change it
[03:56] <HoppingMadMan> I have been using Linux for such a long time now, I really need to teach myself to be a better programmer so I can give back
[03:59] <darkxst> there are plenty of other ways to give back, apart from just programming!
[03:59] <HoppingMadMan> Yeah, see dumb me, I only think about programing. It's just hard to find a place to jump in, or maybe I am not looking in the right places
[04:00] <darkxst> HoppingMadMan, testing 16.04 beta next week
[04:02] <HoppingMadMan> Yeah only got the laptop at the moment only, and testing it in a VM is that fare
[04:03] <darkxst> and plenty of other areas, documentation/wiki, artwork/design, reporting/triage bugs
[04:03] <darkxst> HoppingMadMan, yes VM is ok
[04:03] <darkxst> just make sure to report that when adding reports on http://iso.qa.ubuntu.com/
[04:04] <HoppingMadMan> Thanks darkxst, your much kinder than most on IRC
[04:04] <darkxst> (beta candidate images will be available monday
[04:05] <HoppingMadMan> Cool I will start taking a look
[04:11] <darkxst> HoppingMadMan, I think you will find most Ubuntu devs are friendly
[04:11] <darkxst> except perhaps in the case where people come along with threats/demands etc that are completely unreasonable!
[04:12] <HoppingMadMan> Yeah yeah, hopping when I get back to Australia with the wife, get a bit more time, to do IT stuff and show her all the beautiful places
[04:13] <darkxst> HoppingMadMan, where in Aus? I'm near Melbourne
[04:14] <HoppingMadMan> I am originally from Adelaide, but now living in Mexico with my wife she was born here
[04:15] <darkxst> ah yeh
[04:16] <HoppingMadMan> We are going through the visa process
[04:17] <HoppingMadMan> And well this government has changed the laws, made it a little harder
[04:17] <darkxst> should be easy if you are an Australian citizen?
[04:17] <HoppingMadMan> It is and it isn't
[04:19] <HoppingMadMan> It's just Mexicans are not trusted around the world sadly
[04:19] <darkxst> one of my mates wife is Mexican, but she was here on PR already when they married
[04:19] <darkxst> gtg, be back later
[04:20] <HoppingMadMan> Ok, I will talk at some point
[05:14] <lindol> hi all
[05:23] <HoppingMadMan> hey lindol, how are you
[05:28] <lindol> HoppingMadMan, hi :) I am some tired because i have drunk last night.. :)
[05:28] <lindol> how about you
[09:24] <darkxst> ricotz, feel free to test nautilus git snapshot on ppa:darkxst/x320
[09:41] <ricotz> darkxst, what is the reason for doing a snapshot?
[09:43] <darkxst> ricotz, they didnt release a tarball since 2 months ago
[09:45] <ricotz> darkxst, hmm, did you try to ask why?
[09:45] <ricotz> g-i is a similar case though
[09:45] <darkxst> not yet
[09:45] <ricotz> I might try to do one
[09:46] <ricotz> (sometimes specific bugs can delay a release)
[09:48] <darkxst> 3.19.2 was the last nautilus release and there has been loads of fixes since then
[09:48] <ricotz> I see
[09:49] <ricotz> going to push a new gtk+ for this wayland-protocol change
[09:49] <darkxst> ricotz, k thanks, yet is a bit broken since debian didnt follow your naming
[09:50] <darkxst> s/yet/yeh/
[09:50] <ricotz> appending -dev to an obviously development package made sense
[09:52] <darkxst> apparently not for the debian guys ;)
[09:56] <ricotz> darkxst, is there something hard-depending on vala 0.31.x yet?
[09:57] <ricotz> (I guess only gnome-builder is)
[09:57] <darkxst> I've not seen anything
[09:57] <darkxst> (not looked at -builder yet)
[09:57] <ricotz> due the unification of the vala package I haven't put it in the ppa yet
[09:58] <ricotz> in case they can be copied from https://launchpad.net/~vala-team/+archive/ubuntu/next/+packages
[09:59] <darkxst> ok
[10:01] <ricotz> although it includes a bug-fix for owned delegates which has an positive effect on quite some gir-to-vapi builds
[10:05] <darkxst> it should be fine to include it, I imagine most of upstream are building against it?
[10:06] <darkxst> jhbuild certainly is
[10:06] <ricotz> it should be yeah, I building several projects to test binding updates/changes
[10:07] <ricotz> I am ..
[11:56] <octoquad> darkxst, hi! What do you think of this https://answers.launchpad.net/ubuntu-gnome/+question/257365 pretty interesting idea, but looks like quite a bit of work.
[12:22] <octoquad> darkxst, is this possible or even feasible: https://answers.launchpad.net/ubuntu-gnome/+question/250197
[14:50] <LinDol> hi all
[15:07] <lindol> hi all
[21:26] <craysiii> i gotta say so far 16.04 has been good to me
[23:16] <tristan957> Does anyone know where I can download and that 16.04 daily build?