[00:50] <ubotu> New bug: #198216 in launchpad "An open question doesn't show up in the question list " [Undecided,New] https://launchpad.net/bugs/198216
[04:16] <ubotu> New bug: #198253 in launchpad "Cannot specify 'Launchpad' as a project's bugtracker" [Undecided,New] https://launchpad.net/bugs/198253
[04:25] <ubotu> New bug: #198255 in launchpad "Subscribe to bug mail action not on bugs facet" [Undecided,New] https://launchpad.net/bugs/198255
[07:49] <cyberixae> One of my series is marked as "Current development focus". How do I change that?
[07:52] <jamesh> cyberixae: pick "Change details" from the actions menu on the project page, and pick a different series as development focus
[07:53] <cyberixae> thanks
[08:17] <carlos> morning
[08:18] <mdke> morning carlos
[10:21] <ubotu> New bug: #198305 in ubuntu "Several projects have open translations in launchpad and this cause very bad translation quality." [Undecided,New] https://launchpad.net/bugs/198305
[14:01] <ubotu> New bug: #198361 in malone "Bug page issues one query per comment" [High,In progress] https://launchpad.net/bugs/198361
[14:04] <TomaszD> hey carlos could you take a moment and see if totem's translation template is being updated without any problems? I have some doubts
[14:04] <TomaszD> https://translations.launchpad.net/ubuntu/hardy/+source/totem/+imports
[14:05] <TomaszD> all imports fail
[14:06] <carlos> TomaszD: indeed, the .pot file is not being regenerated on build time
[14:07] <carlos> TomaszD: I'm working on prepare a report of all packages with that problem so we can fix them ASAP
[14:07] <TomaszD> carlos, ok so this was useful for you yes? Please add this package to the list :]
[14:07] <carlos> could you file a bug about it against totem package?
[14:07] <TomaszD> yeah sure, one moment
[14:07] <carlos> TomaszD: well, is not that I'm doing the list manually
[14:07] <carlos> but trying to get the list automatically
[14:08] <carlos> if you want it fixed right now, file the bug
[14:08] <carlos> otherwise, once I have that automatic report, we will get it :-)
[14:08] <carlos> it should happen any time this week
[14:09] <TomaszD> carlos, https://bugs.launchpad.net/ubuntu/+source/totem/+bug/198366
[14:09] <ubotu> Launchpad bug 198366 in totem ".pot file isn't regenerated on build time" [Undecided,New]
[14:09] <carlos> TomaszD: thanks
[14:09] <TomaszD> np
[14:09] <TomaszD> bbl
[14:30] <ubotu> New bug: #198372 in launchpad "Needs "Needs Info"" [Undecided,New] https://launchpad.net/bugs/198372
[15:30] <ChrisW> hey all, is there any way I can find out permissions I have on a project and/or tag projects I'm interested in so I can find them again easilly?
[15:54] <Odd_Bloke> ChrisW: Ctrl-D? ;)
[15:54] <ChrisW> yeah, 'cos bookmarks work so well across multiple computers, especially those on customer sites :-(
[15:55] <ChrisW> and that also doesn't help me find out what roles, if any, I have in a particular project
[15:55] <Odd_Bloke> ChrisW: I don't really know, I'm afraid.  There are a couple of hacks I can think of, but waiting for a Launchpad person to give you a better answer is probably a better idea. :)
[15:55] <ChrisW> yeah, where are they all
[15:55] <ChrisW> ?
[15:56] <Odd_Bloke> ChrisW: There's a Bazaar sprint going on ATM, so some of them are tied up with that.
[15:56] <ChrisW> that in London?
[15:56] <Odd_Bloke> ChrisW: Yup.
[15:56] <ChrisW> that would explain why the dodgy kiwi is in town...
[15:57] <Vadi> If someone has a program written in Python, and wants them to be translated in launchpad - where would they be writing the strings that describe what a certain string means? Launchpad then puts that explanation below the strings that needs translation with an (i) attached to it
[15:58] <Odd_Bloke> ChrisW: If you go to the page of the team related to a project, it has a section entitled "Your involvement"...
[15:58] <Odd_Bloke> Vadi: If it's with gettext, it's presumably in the .pot file (or wherever you'd normally put it).
[15:58] <ChrisW> how do I see the team related to a project>
[15:58] <ChrisW> ?
[16:00] <Odd_Bloke> ChrisW: Go to the project page and look around.
[16:00] <Odd_Bloke> There's not necessarily a related team, it may be a related person.
[16:00] <ChrisW> ah, okay, got it now
[17:13] <bard> hi, dumb question: can answers be edited by project admin or author? user just typed uncloaked email addresses in answer :(
[18:05] <VladimirMelo> hi there, I'm brazilian team translator (administrator), could anyone tell me if there is a kind of Rosetta channel?
[18:09] <matsubara> VladimirMelo: you're in it
[18:10] <VladimirMelo> matsubara: so, here we can talk about rosetta, that's it?
[18:10] <matsubara> yes
[18:16] <VladimirMelo> from one release to the next, does rosetta import any translation from upstream?
[18:16] <VladimirMelo> or this procedure should be done always by a translator?
[18:17] <matsubara> carlos and danilos would be able to answer that for you.
[18:18] <carlos> VladimirMelo: we import any translation released with the code that is in ubuntu's archive
[18:18] <carlos> so we should match latest released tarball that is available from Ubuntu
[18:18] <carlos> which may not be latest version in upstream's svn/cvs or other source control version
[18:19] <VladimirMelo> carlos: so, the translation team always translate, nothing is automatic, right?
[18:21] <carlos> what do you mean by 'nothing is automatic' ?
[18:22] <VladimirMelo> carlos: I mean the rosetta will never import strings by itself from upstream, right?
[18:22] <carlos> not right now, we depend on the version uploaded into Ubuntu
[18:23] <VladimirMelo> carlos: brazilian team is working on taking po files from upstream always
[18:24] <VladimirMelo> carlos: and translating just those strings which are not translated there
[18:24] <carlos> VladimirMelo: we are going to work on such sync, but nothing is started yet
[18:25] <VladimirMelo> carlos: so, there is an idea about it?
[18:25] <carlos> yes
[18:25] <carlos> for gnome, for instance, we would like to integrate with damned lies
[18:25] <carlos> so we get latest version
[18:26] <VladimirMelo> great!
[18:26] <carlos> as soon as a translator 'release' it
[18:26] <carlos> but we don't have dates for that yet
[18:26] <VladimirMelo> carlos: I appreciate this idea, the brazilian team does!
[18:27] <VladimirMelo> carlos: thanks for all
[18:28] <carlos> you are welcome
[18:47] <Tuv0k> Not allowed here
[18:48] <Tuv0k> Sorry, you don't have permission to access this page
[18:48] <Tuv0k> I'm signed in..whats the deal?
[18:49] <Tuv0k> I'm trying to unsubscribe to duplicate bugs
[18:49] <Tuv0k> please assist
[19:46] <gabaug> hi, I am subscribed to https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131679
[19:46] <ubotu> Launchpad bug 131679 in compiz "compiz.real crashed with SIGSEGV when attempting to unlock screen" [High,Confirmed]  - Assigned to compiz packagers (compiz)
[19:46] <gabaug> but it doesn't show up in https://bugs.launchpad.net/~gabaug/+subscribedbugs
[19:46] <gabaug> I believe this is a bug
[20:24] <tsaitgaist> hi. how to get a gpg key from a ppa launchpad repository ?
[20:25] <afflux> I don't receive any bug notification emails since monday, 17:00 UTC, but I still receive emails from MLs. Any ideas?
[20:26] <afflux> tsaitgaist: I'm not sure, but IIRC ppas are unsigned
[20:28] <tsaitgaist> afflux: how to get aptittude/apt-get trust ppa then ?
[20:30] <afflux> tsaitgaist: you'll need to confirm manually
[20:32] <tsaitgaist> afflux: will there be an improvement for this ? (I'm asking this becaus I'm writing a script and try to avoid to ask user for confirmation for various installations)
[20:32] <afflux> wow. I just received *loads* of emails at once. Something's weird here :)
[20:32] <afflux> tsaitgaist: there's a bug report on this: https://bugs.edge.launchpad.net/ubuntu/+bug/181462
[20:32] <ubotu> Launchpad bug 181462 in ubuntu "scheda video trident" [Undecided,Incomplete]  - Assigned to Brian Murray (brian-murray)
[20:32] <afflux> err
[20:32] <afflux> sorry, wrong link
[20:32] <afflux> https://bugs.edge.launchpad.net/soyuz/+bug/125103
[20:32] <ubotu> Launchpad bug 125103 in soyuz "ppa archives are not signed" [High,Confirmed]  - Assigned to Celso Providelo (cprov)
[20:35] <tsaitgaist> afflux: thanks. then I will force yes and wait until this bug finds a solutions. thanks a lot
[20:36] <afflux> tsaitgaist: you're welcome
[20:39] <tsaitgaist> afflux: aptitude's -s does not set yes to the trust question, is there another force yes (i can't see in the man)
[20:40] <tsaitgaist> afflux: -y I mean
[20:45] <afflux> tsaitgaist: sorry for the delay. apt-get has "--yes --force-yes", I'm not sure if there's an equivalent for aptitude
[20:48] <tsaitgaist> afflux: yes, apt has it, but it's not recommended to mixe apt-get and aptitude. aptitude has -y, but it does not work for the trust question
[20:48] <afflux> what do you mean with "mix apt-get and aptitude"?
[20:50] <tsaitgaist> afflux: apt-get and aptitude have 2 different database, so i you use apt-get, aptitude will not know what was installed and does not have the additionnal info to cleanly remove it. if I understodd corretly
[20:50] <mwhudson> uh
[20:50] <afflux> I don't think so
[20:51] <afflux> they both use the dpkg database
[20:52] <tsaitgaist> afflux: from the ubuntu doc : aptitude - Curses viewer of packages installed or available. Aptitude can be used from the command-line in a similar way to apt-get, but only for some commands - install and remove being the most common. However, because aptitude keeps track of more information than apt-get does, it can be considered better at install and remove operations.
[20:54] <tsaitgaist> afflux: other howto pages recommend to only use aptitude if you begin with it
[20:54] <afflux> I'm not sure if this should be discussed in #launchpad, but this doesn't say that mixing them both is dangerous or not recommended, but that aptitude is in general the preferred way to install
[20:55] <tsaitgaist> afflux: i will use apt-get for ppa then
[21:52] <ubotu> New bug: #198535 in malone "subcribe to project announcements via email" [Undecided,New] https://launchpad.net/bugs/198535
[22:50] <bard> hello all, is there a way to edit answers on answers.sameplace.cc, either for proj admin or he who wrote the answer?
[22:51] <thumper> bard: I'm assuming you mean answers.launchpad.net
[22:51] <ubotu> New bug: #198566 in launchpad-bazaar "register-branch barfs with traceback when registering a branch	twice" [Undecided,New] https://launchpad.net/bugs/198566
[22:53] <bard> thumper: lol, yes. too little coffee
[22:54] <thumper> bard: I think admins can (somehow), but the person who wrote the answer cannot
[22:54] <bard> thumper: is there a way? a user just handed out a few email addresses to spammers :(
[22:55] <bard> admins as in launchpad admins? as a proj admin, I can't see a way...
[22:55] <thumper> bard: admins as in launchpad admins
[22:55] <thumper> bard: do you want to privmsg me the question url?
[22:56] <bard> yup
[22:58] <thumper> bard: if you actually logout and look at the question, you'll notice that the email addresses are hidden
[22:58] <thumper> for exactly this reason
[23:02] <bard> I hadn't noticed. super!
[23:57] <mpt> Goooooooooooooooood afternoon Launchpadders!


[03:38] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-dict 0.8.4 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-dict-0-8-4-released-tp59498.html (by André Miranda)
[04:10] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-cpufreq-plugin 1.2.2 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-cpufreq-plugin-1-2-2-released-tp59501.html (by André Miranda)
[08:36] <max12345> hello everyone, I wanted to change my default editor that's being used with 'open' and I'm sure there is a cmd thing or some config file I can edit. But there is also this GUI that offer some things but not text editors. Now I'm wondering how I would contribute and add a text editor selection to that.
[08:37] <max12345> https://docs.xfce.org/xfce/exo/4.14/preferred-applications


[12:03] <corden> hello guys
[12:03] <corden> its posible to install ubuntu mid on vbox?
[12:03] <corden> i've tried it but i failed
[12:06] <corden> i mean virtual box


[01:50] <Flumpy> Hey, when I try to login to an account (MSN, Google, Facebook) via the Contacts Setup in Gnome, the page never loads for any of them. What's up?
[10:48] <edgy> hi, I cannot search any pdf with okular, is it only me?
[10:49] <edgy> okular 0.14.90
[11:29] <BluesKaj> Hey all
[11:32] <penguin42> Hey BK
[11:40] <BluesKaj> hi penguin42
[11:48] <edgy> can someone please try okular and confirm search is not working?
[11:56] <penguin42> edgy: Agreed
[11:56] <penguin42> edgy: It just sits and spins even on a small doc
[11:57] <edgy> penguin42: exactly, is this a regression on quantal or kde or it was like this before but we didn't notice?
[11:57] <penguin42> edgy: Don't know, my only KDE install is quantal
[11:58] <edgy> ok shall I file a bug?
[11:58] <penguin42> yes!
[11:58] <penguin42> tell us the bug number and I'll confirm it
[11:58] <penguin42> actually, best to file it on the kde bugzilla
[12:00] <edgy> penguin42: ok, ...
[12:25] <edgy> penguin42: https://bugs.kde.org/show_bug.cgi?id=303843
[12:28] <penguin42> edgy: You say 'Actual Results: Nothing found' - for me it just keeps spinning and never finishes the search
[12:28] <edgy> penguin42: yes, it justs keeps spinning and never finishes the search and nothing found.
[12:29] <edgy> penguin42: because other bugs complaining that they get the spinning but results found
[12:30] <edgy> penguin42: e.g https://bugs.kde.org/show_bug.cgi?id=238674
[12:31] <penguin42> yeh that sounds different
[12:33] <edgy> ok leaving now, thanks
[14:10] <xnox> what happened to libreoffice loading spash!!!! 8)
[14:10]  * xnox is scared
[14:26] <edgy> hi, dstat --mysql-io shows nothing, is this  a bug or I am not using it properly?
[17:00] <IdleOne> oh wow. updates to xchat
[17:00]  * IdleOne is excited
[18:33] <Daekdroom> Is anyone else having a held-back oss-compat for weeks?
[18:34] <penguin42> Daekdroom: Certainly not on my install I did a few days ago
[18:35] <trism> Daekdroom: bug 992991
[18:35] <penguin42> Daekdroom: But yes, on my older would
[21:55] <paulo_gomes> hi all, anyone installed amd proprietary drivers in 12.10?
[22:31] <Daekdroom> Oh no.
[22:32] <Daekdroom> It seems nautilus no longer sorts folder items like: folder by names then files by names.
[22:32] <Daekdroom> Is that because some people can't tell folders apart from files?
[22:45] <smallfoot-> is this 12.10 gonna have weston?
[22:45] <smallfoot-> cuz i tried it in vm
[22:45] <smallfoot-> and it sucks
[22:46] <smallfoot-> and the weston package doesnt look like its getting updated
[22:47] <penguin42> trying wayland stuff in a vm is probably a really bad idea
[22:47] <penguin42> Does anyone know if there is a ppa or debs of current kde4.9 rc1/rc2 - I'm on a KDE bug that's in QQ and the KDE guys are asking me to try rc1 or rc2
[22:55] <smallfoot-> http://tinyurl.com/bsfwt86
[22:55] <smallfoot-> idk anythin
[23:01] <Daekdroom> I think the wayland stuff is getting tested separately instead of getting into the repos.
[23:01] <penguin42> I'm sure stuff will be in the repos, I doubt any of it will be default/expected to be used
[23:01] <Daekdroom> Also, VMs usually don't support KMS and GL ES, which are requirements for Wayland if I recall correctly.
[23:05] <penguin42> that kitty looks very sad, and I think I understand why
[23:06] <Arnold> penguin42, do you mean something like this?: https://launchpad.net/~neon/+archive/ppa
[23:07] <Arnold> I only actually noticed that it has a different package naming.
[23:08] <penguin42> Arnold: Hmm possibly, I wonder if that actually corresponds to a particular KDE rc though?
[23:10] <Arnold> penguin42, should be fine, since the release is good (Quantal) and it's being built daily ("Aiming to provide you with nightly builds of KDE")
[23:12] <penguin42> Arnold: Right, that's one for tomorrow I think then - it's bound to make one heck of a mess of my desktop :-(
[23:14] <Arnold> penguin42, practically installing it as we speak :P
[23:16] <penguin42> right, time to finish watching Avatar....
[23:21] <Arnold> Actually penguin42, you could go with something official, like: https://launchpad.net/~kubuntu-ppa/+archive/beta/
[23:22] <Arnold> ... what am I saying? That's for Oneiric...


[05:17] <mborzecki> morning
[05:30] <mup> PR snapd#8763 closed: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
[06:03] <mborzecki> quick errand
[06:25] <mup> PR snapd#8758 closed: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8758>
[06:30] <mvo> zyga: I see "2020-05-27T16:45:02.9982589Z invariant-tool: crashed-snap-confine not-ok" in some tests, most recently in https://github.com/snapcore/snapd/pull/8744/checks?check_run_id=713534659
[06:30] <mup> PR #8744: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <https://github.com/snapcore/snapd/pull/8744>
[06:30] <mup> PR snapd#8744 closed: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8744>
[06:41] <pedronis> mborzecki: mvo: hi, #8763 needs to be ported to master?  (I didn't notice it was target at 2.45 only)
[06:41] <mup> PR #8763: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
[06:43] <mvo> pedronis: I think there were two, let me quickly check (one for master, one for 2.45)
[06:44] <mvo> pedronis: oh, you are right, let's fix this :(
[06:47] <pedronis> mvo: does the test in #8762 works?
[06:47] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[06:48] <mvo> pedronis: yes, I'm reworking it now though to put the files into the right places, i.e. simulate more closely what we really do (/run/mnt/ubuntu-seed/keyfile, /run/mnt/ubuntu-data/system-data/var/lib/snapd/fde/... for the rest)
[06:48] <pedronis> ah, good
[06:50] <mup> PR snapd#8765 opened: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8765>
[06:53] <pedronis> mvo: btw the comment in the description was wrong, given that the note mentions reboot, I don't think it's just a creation-time issue
[06:54] <zyga> Good morning
[06:55] <mborzecki> re
[06:55] <mborzecki> mvo: pedronis: zyga: hey
[06:55] <pedronis> mvo: and sorry for the many rounds of comments on #8762, I wasn't concetrating properly last night
[06:55] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[07:01] <mvo> pedronis: thank you for the comments, the opposite - my stuff was not coherent enough :( but I will push an updated version soon that is hopefully good
[07:02] <pstolowski> morning
[07:04] <mvo> good morning pstolowski
[07:17] <zyga> mvo: I need to look, I think it's not really that but leftover from package upgrade, trying to reproduce now
[07:18] <zyga> offtopic, I was thinking, that 8GB pi may be just able to run run spread with qemu backend
[07:33] <mvo> zyga: finally a arm spread runner?
[07:33] <zyga> mvo: we'll see, but I think given the low cost and 8GB of ram, might be possible
[07:37] <mborzecki> zyga: do ou know what's the status of kvm and virtio-* on aarch64?
[07:37] <mborzecki> i would guess it's a major factor for making the tests run smoothly
[07:38] <pstolowski> i'd appreciate a second review for #8710, test only
[07:38] <mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[07:39] <mborzecki> pstolowski: i can take a look
[07:39] <pstolowski> mborzecki: thanks!
[07:45] <zyga> mborzecki: not really, I think 32 bit kvm was removed but 64 bit should be ok
[07:52] <pstolowski> mvo: i was talking to Sergio yesterday about uc20 model assertions and the TODO you have in gadget-config-defaults-vitality spread test; apparently it's not possible yet to port this to uc20? i'd like a similiar test for nested uc20
[07:55] <mvo> pstolowski: I need to look again, but iirc the simulation of firstboot is slightly diffreent on uc20
[08:01] <pedronis> we need to think
[08:02] <pedronis> pstolowski: can you explain what you mean with similar but for nested?
[08:02] <pedronis> those tests are not nested
[08:03] <pstolowski> pedronis: i'm repacking the gadget,  but not cheating about firstboot (booting for real)
[08:03] <pstolowski> *i mean
[08:05] <pedronis> pstolowski: I see, you need a dangerous model, you need to your unasserted snaps into the seed partition in /systems/SYSTEM/snaps and you need a /systesm/SEED/options.yaml which is a bit like seed.yaml but only for overrides
[08:10] <pedronis> pstolowski: about options.yaml see seed/internal/options20.go
[08:12] <mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/8271 ? the failure on 19.10 is unratelated to the change
[08:12] <mup> PR #8271: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
[08:12] <mvo> mborzecki: sure
[08:13] <pstolowski> pedronis: thanks for pointers, that helps!
[08:13] <mvo> mborzecki: does it have two +1 ?
[08:13] <mvo> mborzecki: nevermind, I have a look
[08:14] <mborzecki> mvo: ah no ;) jdstrand_ gave +1, but i can't cause i pushed some changes there
[08:16] <mup> PR snapd#8271 closed: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8271>
[08:20] <pstolowski> pedronis: do you have a moment to talk about sysconfig changes?
[08:20] <pedronis> pstolowski: yes
[08:23] <pstolowski> pedronis: ok, coming to standup ho
[08:28] <mborzecki> mup is asleep?
[08:28] <mborzecki> fairly simple fix in daemon: https://github.com/snapcore/snapd/pull/8766
[08:28] <mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[08:31] <mup> PR snapd#8766 opened: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[08:36] <abeato> mborzecki, hey, thanks for taking care of the hugepages PR - I should really have done those changes, but got trapped with other things
[08:37] <zyga> mvo: I spent some time looking at the log you referenced and it does seem like something is randomly failing in that test
[08:41] <mborzecki> abeato: hey, np, we're here to help land things too :)
[08:54] <mvo> zyga: thanks, yeah, it looks like 19.10 and 20.04 are a bit more unhappy today than earlier this week :/
[08:55] <zyga> I'll try to do something about that :)
[08:55] <zyga> call in 5, let me prepare
[08:56] <mup> PR snapd#8767 opened: snap: refactor download code for testing/extending <Created by mvo5> <https://github.com/snapcore/snapd/pull/8767>
[08:59] <zyga> ah
[08:59]  * zyga is dummy
[08:59] <zyga> that's not today :0
[08:59] <zyga> ok :)
[09:00] <zyga> back to original task
[09:22] <zyga> journal logs don't show failures from snapd-session-agent
[09:22] <zyga> but
[09:22] <zyga> mvo: this is the failure
[09:22] <zyga> May 28 20:06:30 may281929-399859 snapd[27253]: May 28 19:59:05 may281929-399859 systemd[1273]: snapd.session-agent.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
[09:23] <zyga> I suspect those are branches without https://github.com/snapcore/snapd/pull/8753 but let me verify
[09:23] <mup> PR #8753: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
[09:24] <zyga> hmm, no, that patch is present
[09:24] <zyga> curious
[09:24] <zyga> let's dig deeper
[09:25] <zyga> hmm
[09:25] <zyga> actually
[09:25] <zyga> just reading the error message
[09:25] <zyga> it seems to suggest the problem is not daemon-reload
[09:25] <zyga> but the fact that the socket needs restarting as wel
[09:25] <zyga> *well
[09:26] <zyga> that might be it
[09:26] <zyga> we'll know soon
[09:26] <mvo> zyga: thanks!
[09:31] <mup> PR snapd#8749 closed: configcore: show better error when disabling services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8749>
[09:31] <mup> PR snapd#8757 closed: tests: update statx test to run on all LTS releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8757>
[09:41] <pedronis> mvo: oops, there was confusion, my proposal was to replace the second line of the comment, not all of it
[09:41] <pedronis> in #8782
[09:41] <mvo> pedronis: oh, sorry. let me fix that
[09:41] <pedronis> heh
[09:41] <pedronis> #8762
[09:41] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[09:44] <mvo> pedronis: updated again
[09:45] <pedronis> thanks
[09:50] <zyga> pedronis: nitpick, can we call $TESTTOOLS $TESTTOOLS instead?
[09:50] <zyga> er
[09:50] <zyga> TESTSTOOLS -> TESTTOOLS
[09:50] <zyga> the  env vra
[09:50] <zyga> *var
[09:53] <pedronis> we have TESTSLIB not TESTLIB
[09:53] <zyga> the var mimicks path
[09:53] <zyga> but the name sounds bad if you think about it
[09:53] <zyga> both plural
[09:54] <pedronis> I'm worried about TESTSLIB TESTTOOLS
[09:54] <zyga> that they differ?
[09:54] <zyga> test libs would be better for english var
[09:54] <zyga> the path can stay as is
[09:54] <zyga> TESTLIBS
[09:54] <zyga> TESTTOOLS
[09:55] <pedronis> plural in programming are always trouble
[09:55] <pedronis> as I said I'm more worried about consistency than english here
[09:55] <zyga> we can do both ;)
[09:55] <zyga> I mean we can rename both while we are at it
[09:56] <zyga> $TESTTOOLS/foo reads better than $TESTSTOOLS/foo
[09:56] <pedronis> I don't  know, not a fan of TESTLIBS
[10:01] <pedronis> zyga: I fear TESTSLIB and TESTSTOOLS, anyway my nature we shouldn't need to use the latter that much
[10:01] <pedronis> s/my nature/by nature/
[10:01] <zyga> not sure what you mean by feal
[10:01] <zyga> fear *
[10:01] <pedronis> I mean, that we go with those
[10:02] <pedronis> mvo: I re-reviewed #8762
[10:02] <mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Skip spread> <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[10:04] <pedronis> anyway on unrelated note the user service stuff seems still fragile, I think we could tweak the tests more, but probably the fragility is real and the code need some changes
[10:05] <mvo> pedronis: thanks! so your suggestion is to run the same tests as for the install case in the reinstall case?
[10:05] <pedronis> mvo: either that because it seems cheap (at least code wise), or to at least run a small subset related to the encrypted partition
[10:06] <mvo> pedronis: yeah, it makes sense
[10:06] <mvo> pedronis: do you prefer duplication of the code or should I move it into a helper like with "prepare.sh" ?
[10:07] <pedronis> mvo: sorry, you don't need to duplicate code
[10:08] <pedronis> you can just reduce the scope of the if, no?
[10:08] <zyga> pedronis: it's a test bug, I fixed it just now
[10:08] <zyga> pedronis: (user service stuff)
[10:08] <mvo> pedronis: aha, nice
[10:08] <mvo> pedronis: yeah, I think this will work
[10:08] <pedronis> zyga: I doubt is just a test bug
[10:08] <zyga> apart from the known TODO, I think it is
[10:09] <zyga> the TODO being that removing snapd doesn't properly clean up user session services
[10:10] <zyga> you'll see in a moment
[10:10] <pedronis> zyga: there's a deeper issue, the existence of the snapd.session-agent.socket used by the code, doesn't really tell much about the state of the session
[10:11] <zyga> what kind of state are you referring to?
[10:13] <pedronis> we are going to ask to do it things with services in the session but the session, might be just starting up
[10:14] <pedronis> we don't know if the session overall in in a steady state
[10:15] <zyga> I think there's no such thing as a stady state, there are concurrently running processes that may stop or start as they please; I think it depends on what kind of ops we'd like the agent to perform
[10:15] <pedronis> I understand that
[10:16] <pedronis> but the existence of the socket is not here nor there
[10:16] <mborzecki> mvo: can we land https://github.com/snapcore/snapd/pull/8520 ? the failure on 20.04 is the user service again
[10:16] <pedronis> in terms of a barrier related to the state of other services
[10:16] <mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Simple 😃> <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
[10:17] <zyga> pedronis: the problem we are seeing in tests right now is related to the particular handling of socket units by systemd; I think that's a separate issue from what you are describing
[10:17] <zyga> our tests continously remove and reinstall snapd, making the socket definition in memory wrong, that was fixed (for tests) recently; what we are seeing now is that when a socket is removed from disk you must perform additional actions, more than just daemon-reload, for it to go away
[10:18] <zyga> and oddly enough installing a new definition of the socket is not sufficient
[10:21] <mup> PR snapd#7869 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7869>
[10:23] <zyga> I also wonder if this is not the same problem we had with pulseaudio, without realizing it
[10:23] <zyga> it's just there are so few tests that touch it it may not be triggered often
[10:39] <pedronis> zyga: btw, related question, does the refresh-awareness tracking for services also works for user services?
[10:39] <zyga> yes
[10:39] <zyga> fortunately :)
[10:40] <mborzecki> anyone tried the liferea snap? the font cache from the host is not mounted inside the snap, but i still get boxes
[10:42] <mborzecki> all i get is https://i.imgur.com/rNFMezE.png
[10:42] <zyga> hmmm
[10:42] <zyga> mborzecki: nsenter and poke around
[10:42] <zyga> wonder if there's something more going on
[10:42] <zyga> at some point fontconfig will figure out how to IPC the boxes around
[10:47] <mborzecki> hm i mounted a tmpfs over /usr/share/fonts in the mount ns of a snap and there's no more boxes
[10:47] <zyga> what's in /usr/share/fonts?
[10:47] <zyga> maybe a read only cache?
[10:47] <zyga> mborzecki, pedronis: please check this out https://github.com/snapcore/snapd/pull/8768
[10:47] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[10:48] <mborzecki> what if the fontconfig from gnome runtime is jsut buggy?
[10:48] <zyga> is there any configuration in /usr/share/fonts that is read by fontconfig?
[10:49] <mborzecki> zyga: there shouldn't be, i have a tmpfs on /etc/fonts and /usr/share/fonts
[10:49] <zyga> I mean
[10:49] <zyga> before you do the tmpfs
[10:50] <zyga> before you hide stuff there
[10:50] <zyga> what do you see if you find /usr/share/fonts
[10:50] <zyga> mborzecki: alternatively strace and explore
[10:50] <mborzecki> just fonts in directories
[10:51] <zyga> or ltrace
[10:51] <zyga> so are you saying those fonts cannot be rendered?
[10:51] <mborzecki> zyga: yeah, either boxes or segfaults again
[10:51] <zyga> hmmm
[10:51] <zyga> what kind of fonts do you have there
[10:51] <mup> PR snapd#8768 opened: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[10:51] <zyga> maybe bisect
[10:52] <zyga> and see which file triggers it
[10:52] <zyga> I think there must be something more than that
[10:52] <mborzecki> nothign special, looks like i need 18.04 desktop vm
[10:52] <zyga> maybe some font has a special hint bytecode that is disabled in arch
[10:52] <zyga> and then without a build option that crashes
[10:53] <mborzecki> zyga: but fontconfig is from the snap, if it can't handle arbitrary fonts the all hope is lost ;P
[10:53] <zyga> ahhh
[10:53] <zyga> interesting
[10:53] <zyga> yeah
[10:53] <zyga> but I think bisecting is the way to go
[10:53] <zyga> how many files do you have there?
[10:54] <pedronis> zyga: is tests cleanup meant to be on the PATH?
[10:54] <zyga> mborzecki: or maybe another idea: are there any duplicates?
[10:54] <pedronis> zyga: sorry, tests.cleanup
[10:54] <zyga> pedronis: I don't think so, it's only going to be used in prepare-restore in two places
[10:54] <pedronis> zyga: then it shouldn't have the tests. prefix
[10:54] <zyga> it's not something I expect to see in any task.yaml
[10:54] <zyga> oh? I misread the readme then
[10:54] <zyga> yeah, I see the fragment now
[10:55] <zyga> "commands that expect to be on PATH should follow more speicfic naming conventions"
[10:55] <zyga> I'll correct that, it's just a draft :)
[10:55] <zyga> so just $TESTSTOOLS/clenaup?
[10:55] <zyga> *cleanup
[10:55] <pedronis> or state-cleanup
[10:55] <zyga> ok
[10:55] <zyga> we should think about session services more
[10:56] <zyga> I think without handling the remove story we should be very careful
[10:58] <zyga> mborzecki: what do you think about the agent socket
[10:58] <zyga> I think this is actually a property of any unit
[10:59] <zyga> it's just sockets seem worse as "hey, it's there, let me talk to it"
[10:59] <zyga> and for non-session stuff we do stop services and sockets so it's not something we've seen before
[10:59] <mvo> pedronis: I reworked 8762, test is much nicer now and shares a ton. silly me for not thinking about this earlier :)
[11:05] <mborzecki> zyga: hmm making /usr/share/fonts/adobe-source-code-pro available inside the snap causes boxes and segfaults :P
[11:06] <zyga> awesome
[11:06] <zyga> now put that font on a 18.04 vm
[11:06] <zyga> what's the base of the snap you tried?
[11:06] <zyga> maybe strace/gdb the app
[11:06] <zyga> and get fontconfig-dbg
[11:06] <mborzecki> zyga: funny, i don't even use any of that fonts
[11:06] <mup> PR snapd#8765 closed: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8765>
[11:07] <mborzecki> zyga: the backtrace is the same as before https://forum.snapcraft.io/t/gimp-and-glimpse-editor-snaps-segfault-on-arch/17100
[11:08] <zyga> where's the backtrace?
[11:08] <zyga> that's just some log
[11:12] <zyga> time to take Bit out for a walk
[11:12] <zyga> back in a bit
[11:12] <mborzecki> zyga: SourceCodeVariable-Roman.otf this font is causing a problem
[11:12] <mborzecki> wodner what's so special about it
[11:12] <zyga> mborzecki: developers and their fancy pantsy fonts ;)
[11:12] <zyga> mborzecki: yeah, it's curious
[11:12] <zyga> if you can reporduce the crash outside of snaps
[11:12] <zyga> we should report those
[11:12] <mborzecki> zyga: but i'm not even using this font
[11:13] <zyga> and even debug and fix them, if possible
[11:13] <zyga> mborzecki: so what, it's there
[11:13] <zyga> it gets scanned
[11:13] <mborzecki> glimpse-editor and gimp segfault, probably because the load up all info about fonts
[11:13] <zyga> yeah
[11:13] <ogra> try inkscape
[11:13] <mborzecki> apps that aren't so interested get boxes?
[11:13] <ogra> from the edge channel
[11:13] <zyga> mborzecki: maybe boxes are for another reason
[11:13] <zyga> the cache is corrupted
[11:13] <ogra> it has this new fancy font handling hack
[11:13] <mborzecki> ogra: oh, right
[11:13] <zyga> try generating the cache
[11:13] <zyga> and see if that crashes
[11:14] <ogra> try inkscape first to see if the hack works !
[11:14] <zyga> mvo: please check this out
[11:14] <zyga> https://github.com/snapcore/snapd/pull/8768
[11:14] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[11:14] <zyga> now really afk
[11:14] <mborzecki> yeah, inkscape edge works
[11:14] <ogra> awesome
[11:15] <ogra> it throws some font.conf errors on startup though ... (unknown options) ... but i see it working in zoom as well
[11:25] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:26] <pstolowski> pedronis: i've updated #8567, let me know if this is what you had in mind. image_linux became slightly ugly
[11:26] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[11:29] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8766 ?
[11:29] <mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
[11:31] <mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:34] <ijohnson> morning folks
[11:37] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:43] <mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:46] <mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
[11:49] <mborzecki> zyga: so the same font works in ubuntu, even in the same snap on ubuntu
[11:49] <mborzecki> i've mounted tmpfs over the fonts cache and /etc/fonts
[11:49] <mborzecki> and it still works, wtf??
[11:58] <zyga> Hmmmmm
[11:58] <zyga> Drop font cache
[11:58] <zyga> Does it crash?
[12:04] <mborzecki> no
[12:04] <mborzecki> it's dropped already
[12:04] <mborzecki> no /var/cache/fontconfig, no /etc/fonts
[12:05] <ogra> and ~/.local/fonts ... etc ?
[12:06] <ogra> (iirc the desktop launchers pick these up too)
[12:06] <pedronis> pstolowski: I reviewed #8567
[12:06] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[12:07] <pstolowski> pedronis: thanks
[12:07] <pedronis> thank you
[12:10] <mborzecki> heh, wiped ~/.cache/fontconfig/ and it's working now
[12:10] <mborzecki> damn, i don't see how we can make it work if there's even a slightest bit of fontconfig cache being shared
[12:12] <ijohnson> mborzecki: re 8766, if you do `snap restart lxd.daemon` now we don't pass in inst.Names though, we always pass in namesToSnapNames(...) so how could the names on the task get set to the inst.Names
[12:12] <mup> PR snapd#8639 closed: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[12:14] <mborzecki> ijohnson: i clarified in a comment there, what meant by `names` in the comment is inst.Names
[12:14] <mborzecki> ijohnson: anyways, i rephrased the comment, please check if it makes sense now
[12:14] <ijohnson> mborzecki: ahhhhh sorry I'm a bit slow this morning it seems
[12:14]  * ijohnson looks now
[12:14] <ijohnson> thank you makes sense now
[12:15] <mborzecki> cool
[12:17] <zyga> mborzecki: so which part of our code makes your ~/.cache/fontconfig available to the snap?
[12:18] <zyga> mborzecki, mvo: please review https://github.com/snapcore/snapd/pull/8768 to unbreak master
[12:18] <mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
[12:21] <mborzecki> zyga: desktop-launch copies over the cache from $HOME/.cache/fontconfig, it works because the snap uses `home`
[12:21] <mborzecki> zyga: so outside of our control apaprently
[12:21] <zyga> mborzecki: wait, cannot we block the cache somehow?
[12:21] <zyga> we could also add a user mount namespace directory to mask ~/.cache/fontconfig
[12:21] <zyga> make it empty
[12:22] <zyga> right?
[12:22] <mborzecki> zyga: sounds like slippery slope
[12:22] <zyga> why?
[12:22] <mborzecki> feels too fiddly
[12:23] <mborzecki> it's probably ok as some temporar fix
[12:23] <zyga> but that's not a good answer :) on one hand side we have crashes and boxes
[12:23] <mborzecki> but it'd really prefer to have the right fix
[12:23] <zyga> on the other "feels too fiddly"?
[12:23] <zyga> sure, what's the right fix?
[12:23] <zyga> (I'm with you on that)
[12:24] <zyga> I would love to know if it's a specific font
[12:24] <zyga> or just any cache
[12:24] <mborzecki> zyga: didn't we discuss that? have snaps build their own cache during install, find a way to share that maybe witht the gnome content snap
[12:24] <zyga> mborzecki: we did discuss that but I think we ought to fix the crashes without requiring all snaps to rebuild
[12:33] <pedronis> mborzecki: we discusses something like that platform snaps taking care of this for snaps that use them, or possibly individual snaps
[12:33] <pedronis> *discussed
[12:36] <mborzecki> zyga: hmm, w8, we can't really expand $HOME in user mounts, can we?
[12:36] <zyga> mborzecki: so, not yet but I kind of wrote a patch for that
[12:36] <mborzecki> xD
[12:36] <zyga> not sure if you noticed a QFG1 themed tweet a few weekends ago
[12:36] <zyga> I added support for all the goodies required to have ~ available
[12:37] <zyga> today is too late but I can post them next week with some cleanups
[12:39] <mborzecki> i recall i had a patch for $HOME too at some point, but for some reason we didn't do it
[12:39] <zyga> it was somewhat fiddly
[12:39] <zyga> anyway, I will post it later
[12:39] <mborzecki> perhaps it was aroudn the time of parallel installs and mapping $HOME/snap/foo_bar $HOME/snap/foo ?
[12:40] <cachio> zyga, could you please take a look to https://github.com/snapcore/spread/pull/107
[12:40] <mup> PR spread#107: Use GitHub actions to test spread <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/107>
[12:40] <cachio> zyga, and hi
[12:40] <cmatsuoka> zyga: I have snapd using 10% of CPU and constantly writing on disk for some time, any idea on what is happening there? https://pasteboard.co/JaC0JzY.png
[12:40] <zyga> cachio: ah, right you asked me yesterday
[12:40] <zyga> sure
[12:41] <cachio> zyga, thanks a lot
[12:41] <zyga> cachio: snap changes
[12:41] <mborzecki> cmatsuoka: snap changes?
[12:41] <zyga> I meant cmatsuoka :)
[12:41] <mborzecki> maybe it'd downloading something and rewriting state.json all the time
[12:41] <cmatsuoka> zyga, mborzecki: no changes, no logs
[12:41] <mborzecki> what was that fs tool
[12:41] <zyga> there are _no_ changes
[12:41] <zyga> mborzecki: which one?
[12:41] <zyga> forkstat?
[12:41] <zyga> or iotop?
[12:41] <mborzecki> zyga: fs<something>stat
[12:42] <cmatsuoka> i used iotop and fatrace
[12:42] <cmatsuoka> fatrace interestingly doesn't show anything
[12:42] <mborzecki> fnotifystat
[12:42] <zyga> ah
[12:42] <pstolowski> ijohnson: hi! thanks for looking at services PRs
[12:43] <mborzecki> cmatsuoka: maybe it's the same problem as https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1831629
[12:43] <mup> Bug #1831629: snapd hammers SSD for long periods <amd64> <apport-bug> <disco> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1831629>
[12:43] <cmatsuoka> let me see...
[12:43] <zyga> cmatsuoka: run forkstat too
[12:43] <zyga> I wonder if we fail on something
[12:44] <mborzecki> heh almost standup time
[12:44] <cmatsuoka> not much information there but it could be the same thing
[12:45] <zyga> cmatsuoka: maybe join ho and screen share
[12:45] <zyga> I can hop
[12:45] <cmatsuoka> zyga: yeah, going there
[12:46] <mborzecki> standup ho?
[12:57] <mup> PR snapd#8643 closed: wrappers: add RestartServices function and ReloadOrRestart to systemd (3/N) <Services ⚙> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8643>
[13:17] <mup> PR snapd#8768 closed: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8768>
[13:22] <mup> PR snapd#8769 opened: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
[13:32] <mup> PR snapd#8710 closed: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[13:47] <mup> PR snapd#8770 opened: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
[14:05] <pstolowski> zyga: if you have a moment, that's the PR from yesterday: https://github.com/snapcore/snapd/pull/8640
[14:05] <mup> PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
[14:36] <ackk> jdstrand_, hi, around?
[14:48] <zyga> re
[14:48] <zyga> back to reviews
[14:48] <zyga> pstolowski: sure!
[14:50] <zyga> pstolowski: looks good
[14:52] <zyga> pstolowski: review sent
[14:52] <pstolowski> dzięki!
[14:53] <zyga> proszę :)
[14:54] <mvo> 8762 needs a second review
[14:58] <zyga> can someone please look at https://github.com/snapcore/snapd/pull/8769/checks?check_run_id=720464127 and explain what failed in snap-repair?
[14:58] <mup> PR #8769: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
[15:08] <zyga> cachio: that change is somewhat big, I will probably not finish reviewing it today
[15:08] <zyga> cachio: my mild preference would be to split it up into separate cunks
[15:08] <zyga> chunks
[15:08] <zyga> I don't understand why some things are done; I have a few pending questoins
[15:08] <zyga> *questions
[15:09] <cachio> zyga, ok, let me check
[15:10] <zyga> cachio: but please, if you can, open separate PR for the reorg
[15:10] <zyga> as 37 changed files is a bit too much to follow coupled with actions
[15:11] <cachio> zyga, well, most of the things are just moved
[15:12] <cachio> I had to move a test suite
[15:12] <cachio> so all the tests are moved
[15:12] <cachio> not changed
[15:12] <cachio> and it is the same for the prepare in the spread.yaml
[15:12] <zyga> but the reason for that move is not clear from the diff or description alone
[15:13] <cachio> zyga, I think the best is to split in 2
[15:13] <cachio> fist github actions
[15:13] <cachio> then in a second pr
[15:13] <cachio> put all the migration
[15:13] <cachio> zyga, does it make sense?
[15:13] <cachio> I just need to revert a commit for that
[15:13] <zyga> or the other way around, whatever is easier
[15:14] <zyga> the reorg can probably land faster
[15:14] <cachio> sure
[15:14] <cachio> I'll make it
[15:14] <zyga> thanks
[15:17] <mup> PR snapd#8771 opened: bootloader/ubootenv: don't panic with an empty uboot env <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8771>
[15:18] <jdstrand_> ackk: hey, yes
[15:20] <ackk> jdstrand, hi, I have a quesion for you: given snap A and B with a container interaface slot/plug (from the same publisher, if that matters), is it possible to get them autoconected if they're both installed? can it be done through a store assertion?
[15:21] <ackk> jdstrand, no default-provider though, as we don't want to get B automatically installed if A is installed
[15:21] <jdstrand> ackk: by container interface, you mean content interface?
[15:21] <ackk> jdstrand, yes, sorry, muscle memory :)
[15:21] <jdstrand> ackk: the content interface should autoconnect from the same publisher
[15:22] <jdstrand> without needing to create a snap decl
[15:22] <pedronis> it should happen already, unless there's more than one slot with the same content label
[15:23] <ackk> oh, really? I thougth that would only happen for default-provider
[15:23]  * ackk tries
[15:24] <pedronis> default-provider has zero effects on connections
[15:24] <pedronis> it just pulls in the sanp
[15:24] <pedronis> *snap
[15:24] <ackk> I'm not seeing this with maas and maas-test-db
[15:24] <ackk> snap install maas --edge + snap install --channel=2.8 maas-test-db
[15:26] <zyga> ackk: could you paste the relevant plug and slot definitions from the snap.yaml's
[15:26] <zyga> snap.yamls
[15:26] <ackk> https://paste.ubuntu.com/p/s3R9GcqJRK/ are connections I see after installing as above
[15:26] <ogra> wow ... looks like we have some racyness
[15:26] <ogra> https://paste.ubuntu.com/p/jQZsVpQy67/
[15:26] <ackk> zyga, sure, one sec
[15:27] <ogra> (this board has not been booted since about 5 months)
[15:27] <ogra> (later calls to the snap command seem to work again)
[15:27] <ackk> zyga, https://paste.ubuntu.com/p/wX6C3ZVZfs/
[15:27] <ackk> zyga, do names need to match?
[15:28] <zyga> I don't think so
[15:28] <zyga> btw, do you need write? I think read should suffice for sockets
[15:28] <zyga> does it work if you connect manually?
[15:28] <zyga> (can you connect at all, I guess, is the question)
[15:28] <ackk> zyga, readonly doesn't work, no
[15:29] <zyga> I'd be interested in denials later on
[15:29] <ackk> zyga, yes, works fine if I connect it. reason I'm asking is purely to save one extra steps for users
[15:29] <zyga> do you have other provides of "db-socket"?
[15:29] <zyga> (installed)
[15:30] <ackk> no
[15:30] <zyga> do we log anything in snapd.service about tihs?
[15:31] <ackk> zyga, I only see this when installing maas-test-db (with maas installed):
[15:32] <ackk> May 29 15:31:22 maas snapd[368]: api.go:985: Installing snap "maas-test-db" revision unset
[15:32] <zyga> I see
[15:32] <zyga> oh well, someone needs to dig
[15:32] <zyga> could you please ping me on Monday
[15:32] <ackk> zyga, sure, thanks
[15:32] <zyga> I'm wrapping up a branch and I'd like to EOD
[15:32] <zyga> it's probably something silly
[15:32] <zyga> I wonder if we can get better debugging of cases like that
[15:33] <pedronis> ackk: I installed maas --edge and I don't see the slot
[15:33] <pedronis> in the yaml
[15:33] <pedronis> or the plug
[15:33] <cachio> zyga, updated the pr
[15:33] <ackk> weird, lemme see
[15:34] <cachio> zyga, about the version of go used to build spread
[15:34] <zyga> pedronis: I'm preparing the tools reorg pr
[15:34] <pedronis> ackk: did mean 2.8/edge in your instructions?
[15:34] <cachio> we already are builing with this version
[15:35] <ackk> pedronis, I was just testing thatm it seems 2.8/edge does work
[15:35] <cachio> so I just put that version on the actions
[15:35] <ackk> pedronis, weird, we added that a long time ago and both revisions don't seem far off
[15:35] <pedronis> ackk: yea, --edge is 2.7/edge and doesn't have any of that
[15:35] <cachio> zyga, not sure which kind of comment you would add there
[15:35] <zyga> cachio: about the significance of that particular version,
[15:35] <ackk> pedronis, no, 2.7 doesn't, but --edge should be latest/edge which is based on CI. for some reason it must have been behind
[15:35] <ackk> sorry for the noise, it seems it works then
[15:36] <zyga> it's a fixed number, maybe we should test with latest instead?
[15:36] <ackk> zyga, ^
[15:36] <ackk> zyga, pedronis thanks
[15:36] <zyga> ackk: woot :)
[15:36] <pedronis> ackk: no you have a default track, so --edge is 2.7/edge
[15:36] <pedronis> if you want latest you need install --channel=latest/edge
[15:38] <mup> PR snapd#8766 closed: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8766>
[15:41] <ackk> pedronis, ah, right! that always tricks me :)
[15:42] <pedronis> zyga: I would prefer that we land #8759 and #8691 with some final scaffolding in it first though
[15:42] <mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[15:42] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[15:42] <zyga> oh, I forgot about that entirely
[15:42]  * zyga looks now
[15:43] <pedronis> zyga: also we need to add TESTTOOLS to debian/tests/integrationtests
[15:43] <pedronis> TESTSTOOLS
[15:43] <pedronis> or autopkgtests might get broken
[15:44] <zyga> pedronis: good point, I'll check that
[15:45] <zyga> pedronis: any specific reason for [[ ]] over regular [ ] ?
[15:46] <pedronis> it was used already for something
[15:46]  * zyga Hmm, we only use it for the regexp matching behavior.
[15:50] <pedronis> if not super consistent
[15:50] <pedronis> we are not super consistent
[15:50] <pedronis> if [[ -d ./mnt ]]
[15:54] <zyga> pedronis: would you mind if I push a change to convert the additions to [ ] ?
[15:55] <zyga> I really like [[ but I prefer to use it only when ther'es no simpler alternative, mainly to remove the "why is this used" question
[15:55] <pedronis> zyga: yes, mostly because it has consumed already too many spread cycles
[15:55] <pedronis> it can be changed later
[15:55] <zyga> ok
[15:55] <zyga> I'll bundle that in the next PR with tool changes
[15:56] <pedronis> zyga: which changes are you doing in that new PR?
[15:58] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8759/files#r432582187
[15:58] <mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[15:58] <zyga> pedronis: moving tools to tests/lib/tools, adding symlinks to tests/bin, renaming each tool one by one, removing compatibility hacks
[16:01] <zyga> pedronis: that question I linked to above is the only thing I'd like to understand before approving
[16:01] <pedronis> zyga: I answered
[16:02] <pedronis> zyga: cleanup-state is a bit too new to know a final answer
[16:02] <zyga> ok
[16:03] <zyga> +1
[16:03] <mup> PR snapd#8760 closed: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8760>
[16:03] <zyga> let's merge when it's green
[16:03] <pedronis> zyga: related to your wip PR, I'll try to do mimimal things then in #8691, just create the dirs, and change spead.yaml (and integration tests)
[16:03] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[16:04] <pedronis> I still would like for it to land first
[16:04] <zyga> the readme PR?
[16:04] <pedronis> yes
[16:04] <zyga> yeah, LGTM!
[16:04] <zyga> it's a draft
[16:04] <zyga> please open it for review
[16:07] <zyga> with the TODO merged we can chop parts off it in each commit
[16:07] <zyga> maybe mvo can just merge it
[16:07] <zyga> there's no point in testing it
[16:07] <zyga> mvo: ^ could you please merge https://github.com/snapcore/snapd/pull/8691
[16:07] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[16:07] <mvo> zyga: sure
[16:07] <zyga> super
[16:07] <zyga> thanks!
[16:08] <mvo> zyga: should it be promoted to "ready for review" at least?
[16:08] <mvo> zyga: it's still draft
[16:08] <zyga> yeah, I think pedronis should do that
[16:08] <pedronis> mvo: please don't merge it
[16:08] <zyga> oh?
[16:08] <mvo> pedronis: set it to blocked
[16:08] <pedronis> as I said I want to do some things in it
[16:08] <zyga> ah, I missed that
[16:08] <zyga> ok, in that case I'll review it again when it's open
[16:12]  * zyga EODs and goes for a walk
[16:36] <Saviq> humpf
[16:36] <Saviq> https://travis-ci.com/github/MirServer/mir/jobs/341502620#L247
[16:36] <Saviq> All snaps up to date.; try to update snapd and refresh the core snap
[16:41]  * cachio lunch
[16:58] <ijohnson> jdstrand: thanks for the review on #8724, so to be clear you are now requesting I add all of the accesses, changes, etc. requested by you there to block-devices? or should I still be adding a nvme-control interface ?
[16:58] <mup> PR #8724: interfaces/block_devices: add NVMe subsystem devices, support multipath paths <Needs security review> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8724>
[16:58] <jdstrand> ijohnson: the former
[16:58] <ijohnson> jdstrand: sounds good thanks
[16:58] <jdstrand> ijohnson: but a description change is in order to mention something about controller devices
[16:59] <ijohnson> right
[16:59] <jdstrand> ijohnson: well, maybe not 'description' like with 'snap interface block-devices', but definitely a code comment above the description and a policy comment
[17:00] <ijohnson> sure
[17:01] <jdstrand> ijohnson: the idea is that these controller devices allow manipulating the block devices that we want to expose, so grouping them together makes sense. we don't group partitions since we determined a separate interface (raw-volume) is a nice place to split the policy
[17:01] <ijohnson> jdstrand: yes that all makes sense, I'll try to update that this afternoon I think
[17:02] <jdstrand> (manipulating a raw device (and its controller) is a significantly different operation than manipulating an individual partition)
[17:02] <jdstrand> ijohnson|lunch: cool thanks!
[17:03] <jdstrand> ijohnson|lunch: sorry that it wasn't clear. I had a strong conviction and then convinced myself I was wrong
[17:03] <jdstrand> :)
[17:09] <ijohnson|lunch> jdstrand: haha yes I know the feeling quite well
[17:53] <mup> PR snapd#8771 closed: bootloader/ubootenv: don't panic with an empty uboot env <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8771>
[17:58] <mup> PR snapd#8762 closed: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[18:04] <mvo> quick eyeball on 8772 would be great
[18:08] <mup> PR snapd#8772 opened: snap-bootstrap: remove sealed key file on reinstall (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8772>
[18:25] <pedronis> mvo: +1
[18:25] <mvo> pedronis: thank you!
[18:26] <pedronis> we are getting mountinfo differences again :/
[18:26] <mvo> oh no
[18:26] <pedronis> 2020-05-29T18:07:04.4844746Z -+0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw,nsdelegate
[18:26] <pedronis> 2020-05-29T18:07:04.4845221Z ++0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw
[18:26] <pedronis> on 18.04
[18:27] <mvo> meh, I hope zyga has time to have a look
[18:28] <mup> PR snapd#8772 closed: snap-bootstrap: remove sealed key file on reinstall (2.45) <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8772>
[18:31]  * cachio afk
[19:43] <mup> PR snapd#8759 closed: tests: move *-tool tests to their own suite <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[19:56] <cmatsuoka> cachio: got a new error in opensuse: https://github.com/snapcore/snapd/pull/8591/checks?check_run_id=721480264
[19:56] <mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Needs Samuele review> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
[19:56] <cachio> cmatsuoka, checking
[19:57] <pedronis> cmatsuoka: I forgot to mention, I will get to review #8591 on Tuesday
[19:57] <cachio> cmatsuoka, it is new
[19:57] <cachio> I'll research it
[19:57] <cachio> thanks for the info
[19:58] <cmatsuoka> pedronis: ok, thanks
[21:27] <mup> PR snapcraft#3149 opened: elf: search dynamic tags within sections, not segment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3149>