[02:59] <JackFrost> https://wiki.documentfoundation.org/ReleaseNotes/6.2#Icon_Theme
[07:28] <knome> mhm.
[20:24] <ochosi> JackFrost: yeah, it's pretty nice, the extended the theme i did by quite a bit
[20:24] <ochosi> the initial push really paid off
[20:24] <ochosi> even my app and mimetype icons survived :)


[18:50] <chris_uk[m]> Greetings. I have Ubuntu Studio 20.04 installed and things are OK but the periodic system updates have stopped appearing for installtion every week or so. I have not seen an update appear on the screen for a two or three months.  If I run Software Updater, it tells me that 'not
[18:50] <chris_uk[m]> all updates can be installed' and offers a 'partial upgrade' instead. But it warns me that it will be a large download. What is the best course of action? Btw, I have had the Ardour 6 and US backports repositories activated since day 1.
[18:53] <Eickmeyer[m]> chris_uk: Try "sudo apt full-upgrade" in a terminal, that might solve that. Also, "partial upgrade" is nothing to be concerned about. :)
[18:53] <Eickmeyer[m]> It's due to an update in the way lsp-plugins are packaged.
[18:55] <Eickmeyer[m]> !ubuntustudio-backports | chris_uk Hence, these official instructions explain "full-upgrade" is necessary
[18:59] <chris_uk[m]> The Ubuntu Studio -backports and ardour - backports ppas are already added.
[19:00] <Eickmeyer[m]> chris_uk: But the instructions say to use "sudo apt full-upgrade", that's all I'm pointing out.
[19:00] <Eickmeyer[m]> Read the link.
[19:01] <chris_uk[m]> Ok, many thanks.
[19:01] <Eickmeyer[m]> I guess it doesn't say it for 20.04.
[19:01] <Eickmeyer[m]> Partial upgrade basically does the same as full-upgrade.
[19:01]  * Eickmeyer[m] goes to fix the doc
[21:11] <chris_uk[m]> Thanks Eickmeyer. I upgraded and everything is ship shape and Bristol fashion.


[10:02] <doko> mitya57: there are some build-deps on python-numpy-doc :-(  networkx pycuda dask dask.distributed pandas pyepr pyopencl python-hdf5storage scikit-learn statsmodels
[10:03] <mitya57> doko: Do you know why exactly it needs newer Sphinx? Maybe you can revert some changes that added this dependency, or maybe I can backport some missing features to 1.8?
[10:05] <mitya57> Maybe reverting dedc4178fc334329 and 5d5ce4ccb89f0b30 will be enough.
[10:06] <doko> I'll have a look later
[10:06] <mitya57> Both these commits are from https://github.com/numpy/numpy/pull/14356.
[19:54] <Logan> is it kosher to sync over a package  that has been traditionally uploaded by CI Train or PS Jenkins bot? In this specific example I'm looking at properties-cpp, which is now packaged in Debian and uses the newer UBports source (and doesn't FTBFS)
[20:19] <vorlon> Logan: yes; packages that were previously uploaded through the CI Train are de facto unmaintained, and most of them have been removed from Ubuntu since they were part of an EOL product and in many cases ftbfs.  So if there's a newer version in Debian that fixes bugs, don't let the upload history from 2014 stop you
[20:20] <Logan> awesome, thanks!
[22:58] <Ark74> Hello guys!
[22:59] <Ark74> I'm trying to backport libreoffice 6.4 to bionic, but even when all dependencies seems to be satisfied
[22:59] <Ark74> I keep getting errors like this; https://paste.ubuntu.com/p/VsysHvcv8n/
[23:00] <Ark74> that's only a the lines that have the error, the whole build log is around 45 mb long
[23:30] <nickgaw> Hi, I have bzr installed and was just trying to checkout the latest version of the ubuntu installer what command do I run for this after I have the debian-installer also checked out?


[13:18] <hazmat> g'morning
[13:39]  * niemeyer waves
[13:44] <hazmat> niemeyer, g'morning
[14:04] <niemeyer> hazmat: Heya
[14:40] <pindonga> morning... so I am trying to use juju for managing lxc containers for development (I know this is not the primary use case for it)
[14:40] <pindonga> the problem I'm facing is that containers do not survive a reboot (I have to destroy the whole env and rebootstrap)
[14:40] <pindonga> I know this is a known issue, but I was wondering if there is a workaround for it
[14:42]  * noodles775 is interested too. I thought by putting my juju-dir somewhere other than /tmp I could avoid that.
[14:42] <hazmat> hmm
[14:42] <pindonga> noodles775, no, I have my data-dir in /home and this is still the case
[14:43] <pindonga> btw I'm running a freshly installed oneiric
[14:43] <hazmat> so there are two issues here, one for hibernation (which is problematic in a different way) and one for reboot, the first one is a work in progress, the second one doesn't have a workaround, it can be done by hand though, albeit its a pretty tedious process
[14:44] <pindonga> another issue I have is that I don't get lxc containers to start (for some reason cgroup is not mounted automatically by juju)
[14:44] <hazmat> it requires starting zookeeper by hand, and the machine agent, and then starting all the containers
[14:44] <pindonga> hazmat, is this written down somewhere?
[14:45] <hazmat> juju will need to write out an upstart job per environment to make this a bit cleaner
[14:45] <hazmat> and automatic
[14:47] <hazmat> pindonga, its not written down, i'm finishing up an email atm, i'll see if i can put together a workaround after
[14:47] <pindonga> hazmat, awesome
[14:47] <pindonga> hazmat, another thing: can you think of a reason why the cgroup is not mounted automatically by juju?
[14:48] <pindonga> may it be that I bootstrapped using distro-series: lucid? (I'm running on oneiric though)
[14:49] <hazmat> pindonga, only the host distro matters regarding the cgroup mount, and juju doesn't handle mounting it, it should be automatic though
[14:50] <pindonga> hazmat, automatic as in? if juju doesn't handle it, does lxc handle it? do I need a cgroup entry in /etc/fstab?
[14:57] <hazmat> pindonga, automatic as its handled by the cgroup-bin package's upstart job
[14:57] <hazmat> pindonga, see /etc/init/cgconfig
[14:57] <hazmat> pindonga, it does not need to be in fstab
[14:57] <pindonga> hazmat, don't have that file., but I have /etc/init/cgoup-lite
[14:57] <pindonga> I run cgroups-mount manually and it's now mounted I think
[14:57] <hazmat> pindonga, yeah.. i think the other one might have been an old natty file.. cgroup-lite looks correct
[14:57]  * hazmat pokes at the packages
[14:58] <hazmat> ah.. ic. cgroup-lite is a minimal set which can support lxc, cgroup-bin also suffices for lxc but has additional cgroup tools
[15:03] <pindonga> ok, got one container up \o/
[15:03] <pindonga> however, the sources file still reads oneiric as the distro
[15:03] <pindonga> :(
[15:04] <pindonga> even though I had lucid in environemtns.yaml
[15:04]  * niemeyer => lunch
[15:04] <hazmat> pindonga, yeah.. there was a bug filed about that
[15:04] <hazmat> bug 886364
[15:04] <pindonga> ah, ok
[15:04] <_mup_> Bug #886364: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 >
[15:04] <pindonga> tx
[15:15] <brtsz> hi guys
[15:17] <hazmat> brtsz, greetings
[15:56] <hazmat> pindonga, i'm looking at what a workaround would take, doesn't seem like its something that's doable cleanly as a manual script it would need some patching of libraries to record port information, better to just implement per desired direction of using upstart
[15:57] <pindonga> hazmat, yeah... I think I found a workaround for the time being
[15:57] <pindonga> just use plain lxc without juju for my dev lxc containers :)
[15:57] <pindonga> as I don't need juju really for that
[15:57] <pindonga> it was just nice to have it manage my lxc containers too
[15:57] <pindonga> thanks for the help though, it's been really useful so far
[16:08] <hazmat> pindonga, np
[16:13]  * hazmat lunches
[16:30] <noodles775> Is this a known bug? (specifying a config.yaml results in charm not being found, move it out of the way and it deploys): http://paste.ubuntu.com/731083/
[16:30]  * noodles775 can't see any bugs on bugs.launchpad.net/juju for config.yaml
[16:54] <_mup_> Bug #887194 was filed: charm not found on config.yaml parse error <juju:New> < https://launchpad.net/bugs/887194 >
[17:02] <hazmat> noodles775, it was reported with a fix in bug 885515
[17:02] <_mup_> Bug #885515: More verbose error when issue occurs in config.yaml <juju:In Progress by hazmat> < https://launchpad.net/bugs/885515 >
[17:03] <noodles775> hazmat: ah, nice (LP's bug search didn't turn it up, but great that the fix is there already :) ).
[17:03] <hazmat> noodles775, not merged yet, but yeah.. should be in soon
[17:04]  * noodles775 marks his new bug as a dupe.
[19:06] <hazmat> jimbaker, ping
[19:09] <hazmat> hmm.. riak didn't make the hot and hairy list
[20:50] <nolan_d> I'm trying to understand Juju. I'm in a situation where we have a bunch of servers we'll wish to deploy various services on, and I'm wondering if I should recommend it.
[20:50] <nolan_d> Is it still limited to one service per machine as a FAQ I read seems to state?
[20:51] <nolan_d> Feel free to tell me to RTFM, I just need to find a FM to read. :) The one on the Ubuntu wiki seems a bit fragmentary and doesn't really address my questions.
[20:52] <nolan_d> Also, how does it handle the situation where I might want to, say, host a bunch of services at various domains on a cloud? "expose" is nice, but does it give me any way to say "expose this service at this domain/port/service type?"
[21:07] <nolan_d> Back later.
[21:13] <jcastro> https://plus.google.com/b/103184405956510785630/103184405956510785630/posts
[21:13] <jcastro> juju G+ page is up!
[21:37] <hazmat> jcastro, nice
[21:38] <jcastro> adding videos
[21:38] <jcastro> as soon as I figure out how to make it a team manageable page I'll let you know. :)


[05:15] <bzoltan> cjwatson: thank you
[12:12] <Mirv> tvoss ^ converted to tri-landing, would be very nice to have for location in OTA-13
[12:12] <Mirv> no tvoss around though
[13:05] <jgdx> Mirv, hey, would it be possible to bump the qt layouts plugin to ~5.5? It's 5.4 currently, and doesn't bring the sweet Layout.margins attached props.
[13:22] <Mirv> jgdx: you'd probably mean having qtquickcontrols-opensource-src 5.5.1 to vivid. sure, I can check if it'd build against otherwise Qt 5.4 and have a silo for testing.
[13:22] <Mirv> ..at some point, now out of silos but I could test it locally tomorrow
[13:22] <jgdx> Mirv, okay, thanks
[13:46] <jgdx> trainguards: hey, could you take a look at the failures in [1]? Not sure this branch introduced those, and they are consistent. [1] https://requests.ci-train.ubuntu.com/#/ticket/1672
[13:47] <sil2100> jgdx: hey! Let me re-run the test, it's an old issue that we fixed
[13:47] <jgdx> sil2100, thanks
[13:47] <sil2100> jgdx: I mean, it's caused by the repowerd landing but we reverted it from vivid
[13:47] <sil2100> So a re-run of vivid autopkgtests should help
[13:47] <sil2100> And this is now running
[13:47] <jgdx> sil2100, I've run it 5 times
[13:48] <sil2100> Today?
[13:48] <jgdx> something like that
[13:48] <sil2100> That hm, doesn't make much sense
[13:48] <sil2100> Oh, or maybe someone landed unity-system-compositor in the meantime
[13:49] <sil2100> hm, no, actually not
[14:48] <kdub> the last few releases I've done, the builders seem to pick up my personal email address instead of the canonical one in the debian changelog... any idea where the builder gets the email address from?
[14:56] <dobey> kdub: primary e-mail address specified in your ubuntu sso account
[14:56] <kdub> dobey, ah, thats where I need to change it then... thanks!
[15:17] <kenvandine> rvr, i have a bacon2d landing in silo 80, doesn't affect anything in any of the phone images
[15:18] <kenvandine> can you mark it as QA NA?
[15:18] <rvr> kenvandine: Let me take a look
[15:18] <kenvandine> rvr, it's just in the overlay so game developers can easily pull in the binary into their click
[15:18] <kenvandine> rvr thx
[15:18] <rvr> https://requests.ci-train.ubuntu.com/#/ticket/1689
[15:19] <kenvandine> rvr, plus the only changes are build related :)
[15:19]  * kenvandine really needs to spend more time on bacon2d :)
[15:21] <rvr> kenvandine: I think you need to sign it first
[15:21] <kenvandine> done
[15:24] <rvr> kenvandine: Does it have autopkg tests?
[15:25] <rvr> kenvandine: Automated Signoff Queued... I'll sign it when this is finished.
[15:28] <kenvandine> rvr, it doesn't
[15:28] <kenvandine> cool, thx
[15:29] <kenvandine> i didn't realize that couldn't be set until after the autopkgtests
[15:34] <mterry> rvr, did any testing happen on https://requests.ci-train.ubuntu.com/#/ticket/1525 last week?
[15:34] <rvr> mterry: Nope
[15:35] <mterry> rvr, OK, cool.  we had a slight hiccup with ci train and are going through autopkgtests again, just wanted to check in and say no rebuilds happened, but that doesn't matter if no testing happened   :)
[15:49] <rvr> mterry: Ok
[15:50] <rvr> mterry: I was asking tsdgeos for the test results
[17:30] <kenvandine> rvr, automated signoff complete for silo 80
[18:09] <rvr> kenvandine: Dine
[18:09] <rvr> Err, done!
[18:16] <kenvandine> rvr, thx
[18:23] <slangasek> cjwatson: fooey - cady's chroot is sorted, and the haskell-http-conduit build failure isn't reproducible there either.  But consistently reproducible in LP
[18:24] <slangasek> hmm wrong channel ;)


[07:16] <zyga> Good morning
[08:21] <zyga> a bit empty today...
[08:21] <zyga> wonder if netsplit
[08:21] <zyga> or flu
[08:31] <mvo> zyga: vacation, swap days, ...
[08:31] <zyga> hey :)
[08:31] <zyga> mvo: indeed
[08:31] <zyga> mvo: welcome back!
[08:31] <mvo> zyga: I will probably also swap at least half a day but wanted to double check how things are
[08:31] <zyga> mvo: we had some humps
[08:32] <mvo> zyga: yeah, was reading what you did on friday
[08:32] <zyga> mvo: lxd candidate started handing out i386 containers
[08:32] <mvo> zyga: thanks for digging into all this!
[08:32] <zyga> mvo: one test needs investigation as it breaks on core20
[08:32] <mvo> zyga: yeah, read that too, that was hillarious
[08:32] <zyga> mvo: I'm just looking at results
[08:32] <mvo> zyga: yeah, I suspect we stopped using shadow for the user tools
[08:32] <zyga> mvo: and I found a few leaks
[08:32] <zyga> mvo: no progress on reviews from security team yet
[08:33] <mvo> zyga: I remember there was a switch planned to something else that also provides userdel but a) I may misremember b) I can't remember what the other source package was :/
[08:33] <zyga> hmm
[08:33] <zyga> I see
[08:33] <zyga> I tried to make all of my branches green though I didn't manage to for the few oldest
[08:33] <mvo> zyga: nice
[08:33] <mvo> zyga: I investigate this userdel issue
[08:36] <mvo> zyga: what is confusing is that this test fails on core20 but not on ubuntu-20.04-64
[08:36] <zyga> oh, indeed
[08:36] <zyga> ppa skew?
[08:37] <mvo> zyga: could be, I will just try to reproduce, also strange that it just started recently to fail - oh well
[08:38] <zyga> yeah, it failed on Friday
[08:53] <zyga> mvo: skipping 1:1 today?
[08:53] <mvo> zyga: see /msg
[09:01] <mup> PR snapd#8050 opened: tests: add marker tag for core 20 test failure <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8050>
[09:02] <zyga> mvo: given that you are here still - can I merge https://github.com/snapcore/snapd/pull/8047
[09:02] <mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
[09:05] <mup> PR snapd#8034 closed: overlord/snapstate: fix for lp:1860324 for 2.43 <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8034>
[09:06] <zyga> mvo: any news about 2.43 revert for /writable?
[09:06] <zyga> mvo: should we revert?
[09:06] <mvo> zyga: no update yet so I think we should
[09:07] <mvo> zyga: or I missed a mail which is quite possible
[09:07] <mvo> zyga: I think I will do 2.43.2 tomorrow morning
[09:07] <zyga> the branch is sitting green, let's wait until we get some news today
[09:07] <zyga> and pick the decision tomorrow
[09:07] <zyga> I'll check the bug report
[09:08] <mvo> zyga: thank you!
[09:09] <zyga> mvo: the customer is okay with the workaround but the timing is that they would rather have a revert now
[09:10] <mvo> zyga: sure thing
[09:10] <zyga> mvo: I'll grab a coffee and do some reviews and merges
[09:11] <mvo> zyga: sounds great, I will leave irc for a bit, availalbe on tg for emergencies
[09:16] <sdhd-sascha> hey, zyga - "markstos" seems to be very interrested in termite on classic. And also likes sway and i3. Maybe we can bring the gnome-extension into classic-mode, so the termite's snapcraft.yaml didn't need to much environments and scripts...
[09:16] <sdhd-sascha> (just for your information. )
[09:25] <Chipaca> 👋
[09:36] <zyga> re
[09:36] <zyga> sdhd-sascha: it's probably silly but I don't follow - gnome-extension classic mode?
[09:36] <zyga> Chipaca: hello
[09:37] <zyga> how are you? are you off today or working>.
[09:39] <sdhd-sascha> zyga: i know. What i want to say is, that there are some one more, which could help. And i know you are good in social connections. So i just want inform you. Nothing more ;-)
[09:40] <Chipaca> zyga: working today
[09:45]  * zyga nods
[09:48] <Chipaca> not sure when I'm going to get a break tbh :)
[09:48] <mup> PR snapd#8022 closed: cmd/snap-confine: Revert #7421 (unmount /writable from snap view) <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8022>
[09:48] <zyga> Chipaca: anytime you feel like it
[09:48] <zyga> it's a bit of tumbleweed territory here today
[09:48] <zyga> maciek and pawel are off
[09:48] <Chipaca> s/break/swap/
[09:48] <zyga> mvo and samuele are off too
[09:48] <zyga> cachio is off
[09:49] <zyga> ian will come around in a few hours
[09:49] <Chipaca> zyga: I've come back from za with a rather hard deadline for some things i need to get done :)
[09:49] <zyga> I see
[09:50] <Chipaca> zyga: thank you for the note on #7421
[09:50] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7421>
[11:17] <zyga> Chipaca: I sent small tweaks to https://github.com/snapcore/snapd/pull/8045
[11:17] <zyga> Chipaca: and removed my review since I changed it now
[11:17] <mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
[11:17] <zyga> Chipaca: do you want to do a second review?
[11:17] <zyga> I tried to document my patches as best as I could
[11:19] <Chipaca> zyga: will do in a bit
[11:19] <zyga> thank you, it's not urgent though
[11:19] <Chipaca> "a bit" → a while (knee-deep in users right now, and then have a manpages meeting, and then standup...)
[11:19] <Chipaca> zyga: speaking of which, do you want to come to the manpages meeting?
[11:20] <zyga> yeah
[11:20] <zyga> I was about to ask
[11:20] <Chipaca> is that something that interests you?
[11:20] <Chipaca> ok :)
[11:20] <zyga> yeah, greatly
[11:20] <zyga> over the past few weekends I've been hand-writing manual pages :)
[11:20] <zyga> (seriously)
[11:20] <mup> PR snapd#8050 closed: tests: add marker tag for core 20 test failure <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8050>
[11:20] <Chipaca> zyga: FWIW manpages is black, so unless I can do it this week it's not getting done, but I'd rather somebody else in the snapd team knew about what needed to be done
[11:28] <sdhd-sascha> Is it a goal, that classic and strict snaps should work the same in future ?
[11:28] <zyga> sdhd-sascha: in which sense
[11:28] <zyga> sdhd-sascha: there's a fundamental difference between them
[11:30] <sdhd-sascha> For the user, who creates a snap.
[11:30] <zyga> no, they will always be different then
[11:31] <sdhd-sascha> Oh :-( Then it would be nice, if a git-branch can be used as a track on snapstore, at least.
[11:31] <zyga> git branch?
[11:34] <mup> PR snapd#8051 opened: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
[11:36] <sdhd-sascha> zyga: i mean - the store people. Could implement a feature, that per "github" branch, a automated build and publish pipeline to a "track" exist. So, in git there is a "classic", "devmode" and "strict" branch.
[11:36]  * sdhd-sascha afk
[11:36] <Chipaca> sdhd-sascha: the ability to be classic is a per-snap attribute
[11:36] <Chipaca> sdhd-sascha: so tracks for classic are not typically approved
[11:36] <Chipaca> sdhd-sascha: recommendation is to use a different name for classic vs non-
[11:37]  * Chipaca takes a break
[11:37] <sdhd-sascha> Chipaca: i know. That's why i started to upload snaps on github... Would it make sense to have a community store, with lesser restrictions ?
[11:38] <zyga> sdhd-sascha: no, because that would be an enormous effort and why?
[11:38] <zyga> community store becomes curl | sudo sh
[11:38] <zyga> that's not useful
[11:38] <zyga> and not responsible
[11:39] <sdhd-sascha> hmm, maybe a case for a cmdline option for `snap install <url>`
[11:39] <zyga> classic?
[11:39] <zyga> wget && snap install --dangerous
[11:39] <zyga> but that's not better either
[11:40] <sdhd-sascha> zyga: like it is now. `--dangerous` makes sense
[11:40] <zyga> this is not a technical limitation, it's a design that prioritizes safety
[11:40] <sdhd-sascha> yes
[11:58] <Chipaca> zyga: added you to the manpages meet, but it has not meet url atm
[11:58] <zyga> Chipaca: is there a video ?
[11:58] <zyga> aj
[11:58] <zyga> ah
[11:58] <zyga> ok
[11:58] <Chipaca> zyga: cjwatson can add that, i can't
[11:58] <Chipaca> :-)
[11:59] <Chipaca> cjwatson: thanks
[11:59] <cjwatson> I just did
[12:18] <mup> PR snapcraft#2895 opened: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2895>
[12:24] <zyga> that was fun :)
[12:25] <Chipaca> zyga: actually i said wednesday but pedronis is back tomorrow afaik so i'll chat then
[12:25] <Chipaca> calendar allowing
[12:25] <Chipaca> zyga: you want in on that meeting as well?
[12:25] <zyga> yeah
[12:26]  * Chipaca adds
[12:28] <cjwatson> Chipaca,zyga: https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
[12:29] <zyga> Chipaca: check out the standup doc please
[12:29] <zyga> Chipaca: I added one bit that we didn't discuss
[12:30] <zyga> highlighted now
[12:30]  * Chipaca looks
[12:31] <zyga> Chipaca: if we go and model manual pages, I wonder if this is a one-off
[12:31] <zyga> or is this "snap ships content to unconfined world"
[12:31] <Chipaca> zyga: meta/man would also be backwards compatible :)
[12:31] <zyga> Chipaca: yes
[12:31] <zyga> Chipaca: but not $SNAP/man (that was my only point)
[12:32] <Chipaca> zyga: updated the meeting description with this as well
[12:33] <Chipaca> cjwatson: <3
[12:34] <Chipaca> ok, i need to go get veggies to go with my lunch
[12:34]  * Chipaca vegs out
[12:34] <zyga> o/
[12:35] <cmatsuoka> Chipaca: interesting test error in the users refactoring PR
[12:39] <cjwatson> Chipaca,zyga: Hm, I forgot to check, does the name mediation bit require any store changes?
[12:39] <cjwatson> I never found out how that worked before I mostly stopped working on the store
[12:39] <zyga> cjwatson: I suspect it would - which is also easier if it's explicit rather than fished from the filesystem structure
[12:41] <cjwatson> Somebody who has a clue what's involved should loop in Bret ASAP then
[12:41] <zyga> cjwatson: I think we should do that after the call tomorrow
[12:41] <cjwatson> But if that doesn't happen then <snap-name> and <snap-name>.* will still work, right?
[12:41] <zyga> it's probably not the store as much as review tools
[12:41] <cjwatson> Er right, maybe Jamie then
[12:42] <cjwatson> I won't release man-db for a week or so, just in case
[12:48] <zyga> Chipaca: daemon/api_users_test.go:220:42: "potatos" is a misspelling of "potatoes"
[12:48] <zyga> 862
[13:03] <Chipaca> cjwatson: re name mediation, if it goes beyond what aliases does, yes -- i'll add that to the meeting with samuele tomorrow
[13:03] <cjwatson> Ta
[13:04] <Chipaca> I expect it'd look like another assertion type, with snapd needing to do some work but not the store
[13:05] <zyga> I think so too
[13:05] <Chipaca> but I might be over-optimistic wrt the store side of assertions
[13:13] <zyga> I'm off for a walk with Bit
[13:16] <cmatsuoka> Chipaca: could you have a look at https://bugs.launchpad.net/snapd/+bug/1860773? It seems that we have a problem in default track error messages
[13:16] <mup> Bug #1860773: Default track not in error message when branch requested <snapd:New> <Snap Store:New> <https://launchpad.net/bugs/1860773>
[13:16] <Chipaca> cmatsuoka: that was filed at my behest
[13:17] <cmatsuoka> Chipaca: ah good, thanks
[13:17] <Chipaca> cmatsuoka: IOW, yes yes we do -- I knew we did, although I didn't predict this exact flavour
[13:18] <cmatsuoka> Chipaca: should I assign it to you, or leave it unassigned?
[13:18] <Chipaca> cmatsuoka: there's a store-side component to that because the error from the store doesn't let us tell the user the right thing
[13:18] <cmatsuoka> hmm
[13:18] <Chipaca> cmatsuoka: leave it unsigned -- i doubt i'll have time to get to it
[13:18] <cmatsuoka> ok
[13:19] <Chipaca> cmatsuoka: the quick fix would be to make snapd not tell the user the channel it was looking for
[13:19] <Chipaca> cmatsuoka: the better fix would be to make the channel mapper default-track-aware, and pass in the default track from the error response (that's the bit that's missing)

[13:21] <Chipaca> cjwatson: about https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
[13:22] <Chipaca> cjwatson: note in redhat etc that'd be /var/lib/snapd/snap/man
[13:23] <Chipaca> "redhat etc" is release.DistroLike("fedora", "arch", "archlinux", "manjaro", "antergos")
[13:23] <cjwatson> Chipaca: I'll try to remind those packagers that they need to patch that
[13:23] <Chipaca> cjwatson: 👍
[13:23] <cjwatson> I think it's reasonable for upstream man-db to refer to upstream snapd's path, though
[13:24] <Chipaca> cjwatson: fair
[13:25] <Chipaca> cjwatson: also while those distros don't like /snap/, most of their users will have it anyway because without it they don't get classic snaps
[13:27]  * Chipaca looks athttps://github.com/rydal/tuxconfig-frontend and is terrified
[13:58] <zyga> re
[14:01] <zyga> Chipaca: standup?
[14:01] <Chipaca> zyga: omw
[14:48] <ijohnson> hmm one of the case fans on my desktop has stopped spinning :-/
[14:48]  * ijohnson reboots
[15:09] <ackk> hi, does anyone have an opinion on https://bugs.launchpad.net/snapcraft/+bug/1860884 ?
[15:09] <mup> Bug #1860884: Python plugin: paths for from the snapcraft snap in sys.pat break dependencies <Snapcraft:New> <https://launchpad.net/bugs/1860884>
[15:22] <zyga> Chipaca: quick review on https://github.com/snapcore/snapd/pull/8051#pullrequestreview-348743013
[15:22] <mup> PR #8051: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
[15:31] <mup> PR snapcraft#2896 opened: Fix the package 'python3-distutils' not found on Ubuntu Xenial <Created by khiemdoan> <https://github.com/snapcore/snapcraft/pull/2896>
[15:41] <mup> PR snapd#8045 closed: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8045>
[15:43] <ijohnson> cmatsuoka: mind giving a quick re-review to #8044 ? I merged master so the diff should is pretty small now
[15:43] <mup> PR #8044: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
[15:43]  * zyga looks as well
[15:46] <cmatsuoka> ijohnson: sure, checking it now
[15:46] <ijohnson> thanks!
[15:56] <cmatsuoka> ijohnson: done
[15:59] <Chipaca> zyga: thank you for the review
[15:59] <zyga> :)
[16:04] <mup> PR snapd#8052 opened: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
[16:04] <ijohnson> thanks cmatsuoka, I just opened ^ which is the followup you requested
[16:05] <zyga> the leftovers would be the temporary files, right
[16:05] <zyga> ?
[16:14] <Chipaca> zyga: pushed changes you suggested to the 8051
[16:14] <zyga> mmm
[16:27] <ijohnson> zyga: yes that's what I meant by leftovers
[16:27]  * ijohnson is bad at puns
[16:37] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/8052#pullrequestreview-348804159
[16:37] <mup> PR #8052: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
[16:40] <ijohnson> zyga: thanks, I think I'll leave it as is (but also I responded in the PR)
[16:40] <zyga> that's fine
[17:53] <mup> PR snapd#8044 closed: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
[18:27] <mup> PR snapd#8052 closed: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8052>
[18:38]  * zyga goes to install focal on bare metal
[18:38] <zyga> with nvidia
[18:38] <zyga> this will be fun
[18:55] <zyga> bah, contention
[18:56] <zyga> popey: is the new shiny theme hitting the daily anytime soon?
[18:57] <zyga> jdstrand_: hey, how is the review queue looking this week?
[18:58] <jdstrand_> zyga: same as last week since I haven't started the push yet
[18:58] <zyga> jdstrand_: but you still plan to this week?
[18:59] <jdstrand> zyga: that is still my plan, yes
[18:59] <zyga> good, that's all I wanted to check
[19:06]  * zyga has focal usb but goes for supper first
[20:06] <mup> PR snapd#8051 closed: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8051>
[21:15] <cmatsuoka> ijohnson: are we still packing .go files inside the snapd snap? if so, there's an easy way to fix that
[21:15] <ijohnson> cmatsuoka: you mean in the snapd snap in the store?
[21:15] <ijohnson> cmatsuoka: I hope we aren't
[21:16] <cmatsuoka> ijohnson: I think we were, many months ago, let me check that...
[21:17] <ijohnson> cmatsuoka: I don't see any .go files in the snapd snap
[21:17] <cmatsuoka> ijohnson: we're still doing it. look what's inside the snap directory in the snapd snap
[21:17] <ijohnson> cmatsuoka: that dir is empty for me
[21:18] <ijohnson> cmatsuoka: actually you know what I'm looking at a snapd snap I built myself, not one from the store
[21:18] <cmatsuoka> hmm, I just ran snap download snapd and unsquashed the snap
[21:19] <cmatsuoka> ijohnson: could you try it and check the snap subdir for a bunch of .go files?
[21:20] <ijohnson> cmatsuoka: yeah I see it with what's built from the store
[21:20] <ijohnson> FWIW, I have been building local snapd snaps with my branch: https://github.com/snapcore/snapd/pull/7904 which doesn't suffer this problem
[21:20] <mup> PR #7904: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
[21:22] <cmatsuoka> ijohnson: ah ok, then it was fixed in snapcraft and the fix was used when you added base: core
[21:22] <ijohnson> cmatsuoka: yes IIUC the current snapd snap is still built with legacy snapcraft
[21:22] <cmatsuoka> ijohnson: it used to happen because snap/ is special and one way to fix that was to use build-aux/snap but if it's not necessary it's even better
[21:23] <ijohnson> cmatsuoka: my branch also uses build-aux/snap so perhaps that's why
[21:23] <cmatsuoka> ah right ok, you already have the fix then :D
[22:51] <mup> PR snapd#8053 opened: osutil: implement deluser <Created by chipaca> <https://github.com/snapcore/snapd/pull/8053>


[19:32] <carbonzero> just got asked if there's support for an HP Pavilion 23 all-in-one monitor PC. I'm looking up specs to see what it's got onboard.
[19:48] <aidian> i mean.. "probably"?
[19:50] <carbonzero> aidian, ok. I looked at the specs online and it's 64 bit AMD so shouldn't be a problem