[00:00] <Eickmeyer> No prob. :)
[02:18]  * guiverc sees an updated base-files now in -proposed
[02:50] <Eickmeyer> I have added Lubuntu's newsfeed back to Planet Ubuntu and updated the logo. You're all welcome. Accepting donations at ubuntustudio.org/contribute. 🤣 j/k
[02:57] <guiverc> thanks Eickmeyer & :)
[03:26]  * guiverc my machine finally reports itself as running 23.10 (not development) :)
[04:50] -queuebot:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Mantic Final] has been updated (20231010)
[04:50] <guiverc> :)
[12:56] <tsimonq2> Looks like good news all around while I was asleep :)
[13:00] <guiverc> We could do with a secure-uEFI install test; the only one listed I think is a mis-file as it's that sony thingy I use & I've not enabled secure-uEFI on it for two cycles
[13:00]  * guiverc is thinking of https://phab.lubuntu.me/w/release-team/testing-checklist/
[13:56] <tsimonq2> xdg-desktop-portal-lxqt, vim, lxqt-session building in Backports Staging, to land in Backports soon
[13:58] <tsimonq2> I always forget about the darn libproc2-dev thing XD
[14:19] <tsimonq2> @guiverc @kc2bez: Do we have anything that prompts the user for a new release upgrade?
[14:20] <tsimonq2> I think I've found out how to do just that
[14:21] <tsimonq2> Cool. On it.
[14:22] <tsimonq2> Let's work on SRU justification for that >XD
[14:23] <tsimonq2> In all seriousness, here's what I'm thinking...
[14:24] <tsimonq2> do-release-upgrade -c will give me an exit code that I can work with (just ignoring the output)
[14:24] <tsimonq2> If I have update notifier check that before it checks for updates, then prompt the user (yes/no/never), that would surely solve the issue
[14:25] <tsimonq2> At that point it would pass off to a `pkexec do-release-upgrade -m desktop -f DistUpgradeViewKDE` launching the upgrade
[14:26] <tsimonq2> Now, eventually we'll need to implement *some* kind of config for updates...
[14:26] <tsimonq2> I'm just not 100% sure on how systemd timers can externally source their timer value...
[14:26] <tsimonq2> (And that's outside of the scope of what I might be able to squeeze in this cycle, which probably isn't this.)
[14:28] <tsimonq2> Since it's just all PyQt5, I'm going to backport what we have now to Jammy and play with it there.
[14:28] <tsimonq2> (If that works, I'll try with some special sauce on a Lunar instance, or something.)
[15:03] <jbicha> Does Lubuntu have a graphical way to upgrade to a pre-release version of Lubuntu?
[15:04] <jbicha> trying to do http://iso.qa.ubuntu.com/qatracker/milestones/449/builds/288254/testcases/1310/results but update-manager is not pre-installed
[15:25] <Eickmeyer> jbicha: It's likely do-release-upgrade -d -m desktop -f DistUpgradeViewKDE
[15:25] <tsimonq2> ^ That's currently correct.
[15:25] <Eickmeyer> As DistUpgradeViewKDE is simply a Qt frontend.
[15:26] <tsimonq2> jbicha: I'm actually currently in the process of refining all of that. You do have to call it from the CLI; that's exactly what I'm trying to fix.
[15:26] <Eickmeyer> Honestly, that should be in the manual as the beta release notes don't mention it. (@lynorian)
[15:26] <tsimonq2> It's there somewhere iirc
[15:26] <Eickmeyer> It's not. I just looked.
[15:26] <tsimonq2> harumph
[15:27] <tsimonq2> Kay. Well, like I said, literally in the middle of fixing this XD
[15:27] <Eickmeyer> hehe
 https://matterbridge.lubuntu.me/28d14c9d/file_9960.jpg
[16:19] <tsimonq2> That pops up with the upgrader window
[16:19] <tsimonq2> Now, that's *only* the case *after* an upgrade has been completed.
[16:19] <tsimonq2> (Since it complains otherwise.)
[16:20] <tsimonq2> Now, I'd like to see what happens if we have 0:0 returned from apt_check but there is a new release to upgrade to...
[16:20] <tsimonq2> Lastly, we'll need *some* kind of "stop asking me" box, but that can come after this functionality is implemented
 Plus, I implemented threading, so the original update manager window doesn't freeze
[16:37] <tsimonq2> Kay, so this update is big enough where I'd probably call it a "
[16:38] <tsimonq2> next release" thing.
[16:38] <tsimonq2> Does anyone have differing opinions, that this should be in this release?
[16:40]  * tsimonq2 rereads bug 2002255 and starts to have second thoughts...
[16:40] -ubottu:#lubuntu-devel- Bug 2002255 in lubuntu-update-notifier (Ubuntu Jammy) "lubuntu-update-notifier provides no good way to resolve a forcibly terminated system update" [Critical, Fix Released] https://launchpad.net/bugs/2002255
 Still need to end up calling a plumber
 Oops
 So this is a last minute request that hasn't been in a previous version?
 Or have I messed it this whole time
 tsimonq2 does this need to be done by Thursday for release or no
 No huge rush I'd say
 @lynorian Just from an outsider's perspective, I agree, no rush. It only applies to beta or upgrades from the current release to the development branch. Since we're 🤏this close to release, no rush at all.
[19:14] -queuebot:#lubuntu-devel- Unapproved: lubuntu-update-notifier (jammy-proposed/universe) [0.5.1~22.04.3 => 0.5.1~22.04.4] (lubuntu)
[19:14] -queuebot:#lubuntu-devel- Unapproved: lubuntu-update-notifier (mantic-proposed/universe) [0.5.4 => 0.6.0] (lubuntu)
[19:14] -queuebot:#lubuntu-devel- Unapproved: lubuntu-update-notifier (lunar-proposed/universe) [0.5.4 => 0.6.0~23.04.1] (lubuntu)
[19:19] <tsimonq2> For non-IRC users, I just uploaded lubuntu-update-notifier to Jammy, Lunar, and Mantic.
[19:19] <tsimonq2> Bug 2038958 is there to track it.
[19:19] -ubottu:#lubuntu-devel- Bug 2038958 in lubuntu-update-notifier (Ubuntu) "[SRU] Add support for release upgrading" [Undecided, New] https://launchpad.net/bugs/2038958
[21:35] <tsimonq2> Okay, so I've also started on the backend bits for that installer widget.
[21:36] <tsimonq2> It's been a bit... dicey to figure out passing values back and forth between QML and C++, but I'm starting to get a handle of it.
[22:13]  * lubot [matrix] <arraybolt3> passes tsimonq2 to teward by const reference
 I just did the upgrading section for graphical and then did the adding upgrading section for development release at the very bottom.
 Thanks Lyn!
[23:03] <tsimonq2> Lubuntu.me is down. We've poked the hoster on the backend but there is a possibility we'll need a rebuild, depending on what's up.
[23:08] <tsimonq2> (I mean, this is all the more reason to *do* a full rebuild behind a CDN, but that's not something I plan on doing pre-release :P )
[23:09] <wxl> yeah well i didn't plan on making a wallpaper sooooo
[23:09] <tsimonq2> #fax
[23:09] <Eickmeyer> #no paper
[23:10] <tsimonq2> Eickmeyer: #noprinter XD
[23:10] <Eickmeyer> #no-dialtone
[23:32] <tsimonq2> Connecting QML and C++ in a way that makes sense (for the first time on an original project) is kinda throwing me for a loop, not gonna lie.
[23:59] <guiverc> I've added some text re: `firefox` during *release-upgrade* to 23.10 release notes on discourse (in staff section; all beta references gone I believe on that version EXCEPT the manual link reminder)


[12:31] <pavel_> hi guys
[12:31] <pavel_> quick question, is there any way to configure ec2 root disk size?
[12:32] <pavel_> I mean when I launch it with juju
[13:18] <ehg> hmm, is there a way to manually remove a service that refuses to die?
[13:18] <ehg> with goju
[13:35] <ehg> e.g. do i have to manually edit a DB to remove zombie services? and how do i do that? :)
[13:57] <jcastro> marcoceppi: hey, the mysql charm, once you flavor=percona, there's no going back is there? I get a config-changed error
[13:57] <marcoceppi> jcastro: I guess so, haven't written tests/checked that yet
[13:57] <marcoceppi> what do the logs say?
[13:58] <jcastro> I didn't look, it was a few days ago
[13:58] <jcastro> I just remembered
[14:11] <marcoceppi> jcastro: open a bug and I'll make sure to check it when I finish writing tests for mysql
[14:11] <jcastro> yeah I am going to check it out
[14:11] <jcastro> but we should test that
[14:11] <jcastro> someone from Maria finally wrote me back!
[14:11]  * marcoceppi nods
[14:20] <arosales> question on juju status in 1.11
[14:20] <arosales> say I didn't know which port mongdb (or any given charm was exposing over)
[14:20] <arosales> juju status in 1.0 > doesn't show the exposed port
[14:20] <arosales> http://paste.ubuntu.com/5755016/
[14:21] <arosales> I am pretty sure the port output was there before, is there a suggested way to find the exposed port?
[14:22] <mgz_> arosales: bug 1173093
[14:22] <_mup_> Bug #1173093: status should report ports <juju-core:Confirmed> <https://launchpad.net/bugs/1173093>
[14:22] <arosales> ah, thank you mgz_
[14:26] <arosales> mgz_, I also added a comment.
[14:26] <arosales> mgz_, any gut feeling on when this bug may get an owner to address?
[14:30] <arosales> I _think_ the open port status is still shown in the juju gui, but I think they are communicating over the web socket.  But the data should be there . .  .
[14:31] <mgz_> arosales: not really, perhaps along with fixing other addressing issues (which will also be a compat change in the json output of some kind)
[14:32] <arosales> mgz_, ok. thanks for the reply on the bug too
[14:39] <jcastro> there's another thing expose needs
[14:39] <jcastro> I put it in a bug
[14:40] <jcastro> it needs to return "service exposed on: http://blah blah" when you first expose it
[14:40] <jcastro> so I don't have to do another status command
[14:41] <mgz_> yup.
[14:48] <marcoceppi> jcastro: that brings some oddities though. What if you expose prior to open-port being called?
[14:50] <jcastro> then wait I think
[14:50] <jcastro> it sucks to expose, then status
[14:50] <marcoceppi> I wouldn't want to block the expose, so many people's scripts will cry
[14:54] <jcastro> evilnickveitch: confused, do I base my new page off my existing branch or do I wait for you to commit to trunk?
[15:00] <evilnickveitch> jcastro, pull the latest version, because I fixed a lot of your bits...
[15:02] <jcastro> evilnickveitch: it's dated from june 6th
[15:02] <evilnickveitch> hmmm
[15:02] <jcastro> lp:juju-core/docs right?
[15:03] <evilnickveitch> that's not right - it is revision 39 now
[15:03] <jcastro> https://code.launchpad.net/juju-core says 31
[15:04] <evilnickveitch> ah... sorry. grab my branch
[15:04] <evilnickveitch> we are changing the juju/core one so it is owned by ~charmers
[15:04] <jcastro> ah ok
[15:04] <evilnickveitch> so this will be a lot easier after tomorrow
[15:05] <evilnickveitch> grab ~evilnick/juju/go-juju-docs if you want to work on anything
[15:05] <jcastro> ack
[15:13] <jcastro> evilnickveitch: hey, do we have like a sidebar class or something for the docs?
[15:13] <jcastro> something for like, a side comment or something I want to tell the audience, but not be in the text block
[15:14] <evilnickveitch> jcastro, you can use an <aside>. i haven't created a style for that yet, but I will need to soon anyhow
[15:14] <jcastro> ah, perfect
[15:14] <evilnickveitch> or you can use the "Note" or "Warning" styles for like footnotes
[15:49] <jcastro> evilnickveitch: ok, best practices done, but when I propose to merge it says "This branch is not mergeable into lp:~evilnick/juju/go-juju-docs."
[15:51] <evilnickveitch> jcastro, it's okay, i don't know why it says that, but i can merge it myself
[15:51] <jcastro> ok
[15:51] <evilnickveitch> where is the branch? same place?
[15:51] <jcastro> branch is pushed to ~jorge/juju-core/best-practice
[15:57] <evilnickveitch> jcastro, yay!
[15:57] <evilnickveitch> okay, i merged that. as you see there isn't a style as such for the aside, but it's cool to have one to work with. I will sort it out
[15:58] <evilnickveitch> AND you didn't mix your spaces and tabs this time :)
[15:58] <jcastro> \o/
[16:16] <jcastro> evilnickveitch: ok, after that I have some updates to both, but that will post meeting and post-lunch
[19:48] <jcastro> m_3: http://codeascraft.com/2013/06/11/introducing-loupe/
[19:51] <m_3> jcastro: sweet


[13:02] <jo-erlend> hi. I was wondering why #ubuntu-app-devel is now set as invite only, and what is required in order to get invited.
[13:02]  * Pici looks
[13:03] <Pici> hrm
[13:04] <jo-erlend> I've noticed it's been that way for a while now.
[13:04] <popey> oooer
[13:05] <Pici> I don't like that it has been set private as well.
[13:05] <popey> I was last in there in May
[13:06] <Pici> I'd ask jono, it looks like it was his channel.
[13:06] <popey> +1
[13:06] <ubot4> Factoid '1' not found
[13:07] <Pici> ...
[13:07] <jo-erlend> oh, ok. I'll send him an email then.
[13:08] <popey> I wouldn't do that
[13:08] <jo-erlend> oh.
[13:08] <popey> I'd poke him in #ubuntu-community-team when he wakes
[13:08] <popey> jonos inbox is where emails go to die
[13:08] <jo-erlend> hehe, ok :)
[14:06] <tsimpson> jo-erlend: it was closed, due to it being inactive
[14:13] <jo-erlend> :/
[14:14] <jo-erlend> then where do I meet others who are interested in application development on Ubuntu? Closing down an IRC channel because users aren't chatting much, seems like a really bad idea to me.
[14:15] <tsimpson> jo-erlend: questions were asked with no response, it was a dead channel :(
[14:18] <jo-erlend> then the solution should be to get people to answer, not to lock down the channel. This is annoying. Application development is one of the big things about Ubuntu, as I see it.
[14:19] <k1l> but this is not how irc works. most people just idle and you cant force them to answer
[14:19] <popey> jo-erlend: askubuntu?
[14:19] <popey> be good to get a body of developer type questions out there documented rather than lost in irc logs
[14:19] <popey> IMO
[14:20] <tsimpson> jo-erlend: that was tried, and it failed
[14:20] <jo-erlend> oh.
[14:20] <tsimpson> we didn't just decided to shut it down for no reason
[14:20] <jo-erlend> but I'm fairly sure I subscribe to the ubuntu-irc mailinglist and I don't think I've read anything about it?
[14:23] <tsimpson> jo-erlend: no, we don't post about every action we take, though it should have probably been on the team report
[14:24] <Pici> tsimpson: It should have been removed from https://wiki.ubuntu.com/IRC/ChannelList as well. :/
[14:25] <jo-erlend> every action? No, that's understandable. But closing down a channel isn't like changing the topic. I think it would've been nice with an email. But ok. Done is done. I was really just wondering if there is a place to get notified of changes to developer.ubuntu.com.
[14:25] <tsimpson> wiki's are evil
[14:28] <tsimpson> jo-erlend: does jono have anything to do with developer.ubuntu.com?
[14:29] <jo-erlend> I have no idea.
[14:30] <serfus> he does, you might as well want to contact David Planella
[14:30] <jo-erlend> I expected #ubuntu-app-devel to be the irc-side of developer.ubuntu.com.
[14:31] <tsimpson> well jono agreed the channel should close before we closed it, so I was just wondering if he could be poked to update the page


[00:27] <valorie> yikes, I use flatpaks!
[00:28] <valorie> snaps have been a disaster for me and I've purged it
[12:52] <yofel> I've made my peace with snaps ever since they got the message that forcing application upgrades while an app is in use might not be such a great idea. These days there's not too much difference between either one looking from a user perspective.
[12:52] <yofel> I do prefer flatpaks, but that's more because of "project background", than technical reasons.
[21:13] <valorie> yofel: the snaps were causing extreme system load
[21:13] <valorie> they might have improved it, but I've already moved on
[21:14] <valorie> I don't see Debian picking 'em up
[21:14] <valorie> not that I'm religious about debs or anything
[21:22] <mparillo> Setting aside the religious debate, if you have loads of memory and a big, fast SSD, snaps are not so bad. But if one of your use cases is running the live USB to (say) access your banking website, the difference between the FF Snap versus non-snap is huge. Maybe 15-30 seconds to load the snap from a live USB.
[21:41] <valorie> and I have the loads of memory and storage
[21:41] <valorie> if the name is snap, I expect it to snap
[21:42] <valorie> not drag like lead wieghts


[10:36] <RawChid> dpm: Hey, did ou had any time to look into my MP? https://code.launchpad.net/~rachidbm/ubuntu-translations-stats/bug-971432
[10:44] <dpm> hi RawChid, I'm sorry, I haven't had time :( These days I'm working more on the app developers side than on translations. But I'll see if I can spend some time on it this Thursday and then I'll come back to you
[10:45] <dpm> brb, I need to reboot
[14:51] <RawChid> Ack
[14:52] <dpm> thanks RawChid
[14:54] <RawChid> No worries.. It's not that important. But I like to finish/complete open stuff :)
[14:55] <RawChid> If there are more feature requests for the app, I'm glad to look into it... Just ping me
[14:55] <RawChid> Have to go now, bye
[14:55] <dpm> ok, cool, thanks again :)


[12:58] <BluesKaj> Hi folks
[13:50] <bregma> another grisly day today
[13:58] <s-fox> Freezing
[13:58] <BluesKaj> hey bregma ..grisly ?
[13:59] <bregma> you know, grey and hard, like the nasty bits in a cut of meat
[14:01] <BluesKaj> ok :) ...clearing up here, maybe +4C at best
[14:02] <s-fox> Hello BluesKaj & bregma , you guys okay?
[14:04] <bregma> yesterday was unpleasant, even the dog didn't like going outside
[14:04] <bregma> he sure liked the fire in the stove though
[14:09] <BluesKaj> yup, just browsing for a way to hack my pvr into a networked device
[14:10] <BluesKaj> Hi , s-fox, how're you doing
[14:11] <s-fox> I am okay thank you. Waiting for starcraftman to wake up ;)
[17:41] <BluesKaj> BBL, stuff to do


[09:52] <seb128> could somebody review some of the trusty SRUs? the unapproved queue is over 30 items with some waiting for over 15 days
[09:52] <seb128> slangasek, bdmurray, arges, stgraber: ^
[12:11] <mlankhorst> infinity: are you doing the 12.04.5 updates?
[13:12] <bdmurray> seb128: I can have a look later today
[13:19] <seb128> bdmurray, thanks, nautilus should be an easy one if you want to start somewhere ;-)


[00:06] <hallyn> thanks
[00:09] <TJ-> Do we have any tools for intelligently comparing dmesg logs ignoring timestamps and slight numeric-value differences? I'm /trying/ to debug a loss of all USB devices when kexec-ing (4.13.0-25-lowlatency - but affects all versions tested so far)
[00:26] <TJ-> With 16.04 and hwe (4.13) I've just noticed on 1 system that the symlinks /vmlinuz -> 4.4.0-111-lowlatency and /vmlinuz.old -> 4.13.0-25-lowlatency whereas on another it's /vmlinux -> 4.15.0-041500rc7-lowlatency and /vmlinuz.old -> 4.4.0-110-lowlatency. Shouldn't the first pair be reversed so /vmlinux.old ->  4.4.0-111-lowlatency ?
[01:18] <TJ-> It seems as if the vmlinuz symlink issue was due to having the hwe-16.04-edge package instead of hwe-16.04
[06:56] <alkisg> Good morning everyone
[06:58] <alkisg> apw, jsalisbury: I managed to reproduce the "kernel reboots immediately" issue here in my office. I semi-bisected it using the mainline ppa, and I saw that:
[06:58] <alkisg> v4.15-rc4 = good, v4.15-rc5 = bad, v4.15-rc5 +nokpti = bad (although afaik rc5 is before meltdown patches, it didn't hurt to test)
[06:59] <alkisg> Anything else I could try? Should I start git-based kernel bisection? Is it time to file a bug now even though all I have is "kernel reboots on certain hardware between rc4 and rc5"?
[07:05] <alkisg> I have an almost identical hardware in the office that is NOT affected, the difference being i5-4440 (affected) vs i3-4150 (not affected) on the same motherboard Gigabyte B85M-HD3
[07:13]  * alkisg reboots to test maxcpus=2...
[07:16] <alkisg> ....it didn't help
[07:30] <alkisg> rc5 64bit works fine...
[07:35] <alkisg> Adding acpi=off works around the issue
[07:53] <alkisg> No other kernel parameter from https://wiki.ubuntu.com/DebuggingACPI worked, only acpi=off
[07:59] <alkisg> I'm reading https://wiki.ubuntu.com/Kernel/KernelBisection, and I believe I can follow the instructions for the xenial git tree.
[08:00] <alkisg> Will this tell me the offending commit, or should I bisect using 4.15 instead, and if so, what is the git URL for that?
[08:13] <f_g> alkisg: there are only 262 non-merge commits between those RCs, bisecting should be easily possible
[08:15] <alkisg>  f_g, cool, if I only knew how :)
[08:15] <f_g> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git is the upstream git repo
[08:15] <alkisg> I'm reading various sources, but I'm not sure which one to follow
[08:15] <alkisg> Ah, will this build me a debian package, or an initramfs anyway?
[08:16] <alkisg> I think https://wiki.ubuntu.com/Kernel/KernelBisection is using the ubuntu git trees that also contain a debian/ dir?
[08:16] <f_g> https://wiki.ubuntu.com/Kernel/KernelBisection#Bisecting_upstream_kernel_versions
[08:16] <f_g> and what is linked there
[08:17] <alkisg> f_g: so a rough idea is that git bisect will compile the kernel for me, and I'll then need to manually install it and calll update-initramfs ?
[08:19] <f_g> alkisg: git bisect just tells you which commits to test, the instructions tell you how you get the kernels from those commits. the generated kernel deb will call update-initramfs automatically after installing, just like a regular kernel from Ubuntu would
[08:19] <alkisg> f_g: what I can't understand in that workflow is how a kernel.org git will know to produce a .deb...
[08:20] <alkisg> I won't have the debian/ dir there, will it?
[08:20] <f_g> alkisg: the kernel build scripts have simple support for creating packages, both for .deb and .rpm
[08:20] <alkisg> Oh very nice, thank you
[08:21] <f_g> they are nowhere near as fancy as what RH/Debian/Ubuntu do, but for quick testing with integration into the package manager (especially for clean removal) they are sufficient
[08:21] <alkisg> OK, on to my first real kernel bisection then :)
[08:22] <f_g> alkisg: if you manage to compile one kernel successfully, bisecting is basically just repeating that over and over in a strategic manner.
[08:22] <alkisg> Oh the bisection logic was very easy to understand, it was the .deb part that I was missing
[08:53] <alkisg> f_g: I'm unsure what to put in series, in "build-mainline-one tag series". I tried "xenial" but it fails.
[08:53] <alkisg> Would that be "master"?
[08:55] <alkisg> http://termbin.com/rwuf
[09:01] <f_g> alkisg: not sure what you did there. running git bisect and then following https://wiki.ubuntu.com/KernelTeam/GitKernelBuild minus the clone and checkout (git bisect already gets you each commit checked out) should "just work"
[09:02] <alkisg> f_g: with a first look, I think the previous page that you linked required having a debian/ dir, and this one doesn't... trying this method now...
[09:04] <f_g> alkisg: the KernelBisection page I linked to has the link to GitKernelBuild right at the place where I linked to ;)
[09:06] <alkisg> f_g: but if you read that page, instead of following the second link to the second page, it says to use the mainline-build-one script, and it has instructions for bisecting etc, which I supposed was what I wanted :D Ty, trying...
[09:10] <f_g> alkisg: it does say to use, it says you can use ;) mainline-build-one is more Ubuntu-ish, GitKernelBuild is closer to upstream. both should be fine to find the culprit (provided your own build of rc5 shows the issue, and the one of rc4 does not - it's always good to verify this before starting a long bisect only to find out that your kernel config for bisecting does not match what Ubuntu used to build
[09:10] <f_g> their mainline PPA kernel deb ;))
[09:10] <alkisg> Gotcha. On an i5-4440, how long a compilation would take? Half an hour? Two hours?
[09:27] <alkisg> Whoops disk space became an issue before compilation time :/ 10 GB may not be enough :(
[09:36] <f_g> alkisg: no clue, but once you built your first one you know ;) it's very consistent if your system is otherwise idle
[09:37] <alkisg> f_g: I hope I don't need to `make clean` on each bisection step, do I? (trying to save time...)
[09:38] <f_g> since you are potentially going back in time, you need to
[09:38] <alkisg> Whoops. I'll need another pc to work on while my good one compiles :D
[09:38] <alkisg> Thanks again
[09:39] <f_g> if compiling a single kernel takes > 45 minutes, maybe you can convince jsalisbury or apw to play bisect ping pong with you using Ubuntu build machines?
[09:40] <f_g> on a fast server a single kernel build is doable in a few minutes, but you need lots of cores for that ;) e.g., our EPYC with 16*2*2 threads does it in 6 minutes or so
[09:43] <apw> f_g, the exact config used is included in the patches in the output
[09:45] <alkisg> apw, I copied /boot/config...rc5 as a starting point, hope that's good enough for the bisection...
[09:45] <apw> alkisg, sound be the same indeed
[09:45] <alkisg> Cool, I hope each build will only take about half an hour on my i5, let's see...
[09:47] <alkisg> ...although now that I switched to the hdd instead of the ssd due to space issues, it seems to go much slower... :(
[09:49] <thresh> if you have 32G ram or so, the build should fit into that
[09:49] <f_g> apw: yep. IMHO still a good idea to verify the bisect assumption holds for your local build env before doing a whole bisect run for nought ;)
[09:50] <thresh> IIRC it takes me more than 20 gigabytes disk space to do a build
[09:50] <thresh> (also yeah epyc and nvme ssds are awesome)
[09:50] <alkisg> thresh: just 8 GB RAM here :/
[09:51] <alkisg> Do builds produce both amd64 and i386 debs? Can I do the build itself from either an amd64 or i386 installation?
[09:52] <alkisg> (I'm currently using i386 because I wasn't sure if it produced both or just the running one)
[10:23] <alkisg> Yey, 46 minutes :) Rebooting...
[10:24] <lorddoskias> guys i just got the following message from latest HWE kernel: https://paste.ubuntu.com/26409755/
[10:24] <lorddoskias> Linux fisk 4.13.0-26-generic #29~16.04.2-Ubuntu
[10:26] <alkisg> Yey, test kernel booted. Oh no, I misttyped 4.5 instead of 4.15 and it was a wasted effort. apw, since it takes 46 minutes, do you think it would be worth it to use the ubuntu builders for that?
[16:47] <alkisg> f_g: I've completed the first step of the bisection, "good". Now before continuing with the bisection, I'd like to test that "rc5=bad", any hint on how to do that without losing the current bisection progress?
[16:58] <alkisg> Hmm, although restarting the bisection doesn't mean I need to rebuild the first step, I can just answer it's good and get to step 2... :)
[19:42] <hallyn> jjohansen: just to confirm, your kernel fixed the issue - thanks!
[19:48] <jjohansen> ack
[20:40] <chiluk> Hey apw bjf, what's the plan on the Spectre_v2 mitigation?  Are you guys planning on doing IBRS/IBPB or Retpoline compilation changes or both?
[20:41] <apw> ibrs to start with, then retpoline + ibrs when upstream catches up
[20:41] <chiluk> is upstream still working on repoline patches?  I was under the impression that they had made it to stable now.
[20:42] <chiluk> yeah it really looks like retpoline is in linux-stable now.  It should get pulled in with stable updates.
[20:43] <chiluk> also isn't retpoline + ibrs duplicate effort?  even though you might have retpoline compiled in, only one gets used at run time.
[20:43] <chiluk> ^^ that's supposed to be a question
[20:49] <chiluk> I guess I should move to hardened.
[20:51] <apw> no some things need ibrs as well, and we'll wait for that to settle out
[20:53] <chiluk> apw are you referring to unrecompiled userspace?
[20:53] <chiluk> also is there any plan to enable gcc with retpoline and do a full archive recompile?
[20:53] <apw> I Amelia referring to CPUs which are not necessarily fixed with retpoline only
[20:54] <chiluk> I was unaware such cpus existed...
[20:55] <chiluk> retpoline is effectively simply disables speculitive execution for indirect branches
[21:51] <apw> retpoline makes it hard for the CPU speculate to useful code, skylake at least  may be able to still speculate even with retpoline forms
[22:36] <chiluk> That'd be pretty impressive given my understanding of how retpoline functions.. it basically sandboxes the speculative branch in sleeps
[22:42] <ratliff> https://lwn.net/Articles/744193/


[17:42] <soee> mamarley: NVIDIA 367.35 Released, Supports 8K H.265 Video Decoding
[18:04]  * mamarley slaps soee around a bit with a large trout.
[18:05] <soee> ;D
[18:07] <mamarley> That said, I have been expecting this all week. :)
[19:58] <mamarley> ricotz: nvidia-graphics-drivers-367.35 is packaged in ppa:mamarley/staging.  nvidia-settings is in ppa:mamarley/updates this time because I accidentally uploaded an incorrect orig.tar.gz to staging and I couldn't overwrite it.


[05:10] <arnatious> I'm almost done snapping up qbittorrent but I'm running into an issue where it's showing no network connection. I fed it a torrent via a url and it fetched that fine. It's on strict confinement and I've attached network, network-bind, and network-manager and connected the last one.
[05:11] <arnatious> Fetched the torrent metadata* it hasn't been able to start downloading it
[06:23] <zyga> arnatious: this is insufficient information to debug, do you see any confinement denials in you log files?
[06:48] <mborzecki> morning
[06:57] <mborzecki> out for a bit to do groceries, before there's more people arriving at the store
[07:04] <zyga> mborzecki: o/
[07:10] <zyga> mvo: good morning :)
[07:11] <mvo> zyga: good morning
[07:12] <zyga> how are you feeling today?
[07:13] <mvo> zyga: good, thanks
[07:13] <mvo> zyga: you?
[07:13] <zyga> yeah, I'm trying to sleep more recently
[07:13] <zyga> I think it works
[07:14] <mvo> zyga: totally agreed, the right sleep is important :)
[07:14] <mvo> zyga: what's new? how are the gh actions doing?
[07:14] <zyga> I'm looking at https://github.com/snapcore/snapd/pull/8350
[07:14] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[07:15] <zyga> mvo: not much new yet, I would like to work on feature stuff today
[07:15] <zyga> mvo: and squeeze one more github action that runs C unit tests and various misc chcecks
[07:15] <zyga> mvo: and combine the actions into dependency chains, so that we don't spin up spread for sure-failing PRs
[07:16] <zyga> mvo: I was also wondering if we could move one of the non-failing spread runs over, something that would help others with quick feedback
[07:16] <zyga> core20?
[07:16] <zyga> or something like that
[07:17] <zyga> mvo: apart from that I need to just focus on stuff I have pending
[07:17] <mvo> zyga: yeah, I think dep-chain is super welcome
[07:18] <zyga> I noticed that each .yaml file is a separate workflow
[07:18] <zyga> and you can only have dependency chains within one
[07:19] <mvo> hm, slightly sad
[07:19] <zyga> why?
[07:19] <zyga> it's okay, just splice yaml together
[07:20] <zyga> speaking about load, I was wondering if having a master commit action useful
[07:20] <zyga> we test each PR
[07:20] <zyga> then it lands and gets tested again
[07:20] <zyga> probably not useful
[07:20] <zyga> I would much rather have this on the release branches
[07:20] <zyga> where it is more prudent to be careful
[07:21] <mvo> zyga: yeah, the master merge test is mostly wasteful
[07:24] <mup> PR snapd#8337 closed: cmd/snap-bootstrap/initramfs-mounts/tests: use dirs.RunMnt over s.runMnt <Simple 😃> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8337>
[07:25] <zyga> mvo: https://github.com/snapcore/snapd/pull/8354 quick one to start the day then
[07:25] <mup> PR #8354: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
[07:26] <mup> PR snapd#8354 opened: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
[07:28] <mup> PR snapd#8339 closed: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8339>
[07:33] <mup> PR snapd#8344 closed: overlord/devicestate,boot: do not hold to the originally read modeenv <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8344>
[07:34] <mup> PR snapd#8349 closed: tests: cleanup security-private-tmp properly <Simple 😃> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8349>
[07:40] <mup> PR snapd#8353 closed: interfaces/docker-support: make containerd abstract socket more generic <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8353>
[07:41] <mvo> zyga: hm, I just noticed something like "skip-spread" would be nice in the actions :)
[07:41] <zyga> yeah
[07:41] <zyga> but it couldn't have been in the initial run which also set skip :)
[07:41] <zyga> you can read labels
[07:41] <mup> PR snapd#8355 opened: github: run C unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8355>
[07:41] <zyga> let me just check the syntax on how to skip jobs that have a label
[07:41] <zyga> it's nice that this doesn't have the API bottleneck problem
[07:41] <zyga> we can just check whatever property we need to
[07:44] <mvo> yeah
[07:58] <mup> PR snapd#8354 closed: github: run spread tests on PRs only <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8354>
[07:59] <zyga> thanks :)
[08:01] <zyga> mvo: I replied on https://github.com/snapcore/snapd/pull/8350
[08:01] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[08:09] <mup> PR snapd#8356 opened: cmd/snap: Implement a "snap routine file-access" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8356>
[08:13] <zyga> jamesh: ^ reviewed
[08:13] <zyga> jamesh: if you rebase on master there will be less failing tests
[08:17] <jamesh> zyga: thanks.  I think it already is instance aware though
[08:17] <zyga> ah, snap.Name has both parts?
[08:18] <jamesh> yeah.  see cmd/snapinfo.go
[08:21] <mborzecki> re
[08:21] <mborzecki> turns out there was more people than i anticipated
[08:31] <pstolowski> morning
[08:35] <mborzecki> pstolowski: hey
[08:37] <mborzecki> zyga: when you restart the spread workflow in gh action, does it restart all jobs or just one?
[08:37] <mborzecki> zyga: i mean all jobs of that workflow (if it's a matrix)
[08:39] <mborzecki> damn, my trackball buttons are malfunctioning
[08:40] <mborzecki> zyga: btw failure in spread test that checks file group ownership https://paste.ubuntu.com/p/Y5RrfjxhY6/
[08:44] <zyga> mvo has fixed that one
[08:44] <zyga> Currently everything is restarted. Restarting fine grained bits is on the roadmap
[08:44] <mborzecki> aah
[08:45] <mvo> uh, that's bit of a downer
[08:45] <mborzecki> what if we use separate workflows for each system instead of matrix?
[08:45] <zyga> Same
[08:45] <zyga> All fine grained bits are coming
[08:45] <zyga> Although
[08:46] <zyga> You may be right with separate workflows
[08:46] <zyga> But then no dependencies
[08:51] <mborzecki> hmm bummer
[08:51] <mborzecki> thn maybe we should wait a bit before doing a complete switch
[08:51] <zyga> trading some for some :)
[08:51] <zyga> if spread is one big fat target we could restart that
[08:57] <dot-tobias> hi everyone
[08:57] <pstolowski> so, wrt https://bugs.launchpad.net/snapd/+bug/1868706 i've tested with lxd & microk8s snaps installed and snapd deb upgraded without issues (along with lots of other debs as i was again testing with a slightly outdated focal). also, Mark wrote that there were no snaps installed
[08:57] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Confirmed> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1868706>
[09:02] <pstolowski> so perhaps it's something with one of snapd's own services
[09:03] <mborzecki> interesting
[09:23] <zyga> re
[09:23] <zyga> okay let's get to coding
[09:24] <zyga> mvo: can I convince you to +1 https://github.com/snapcore/snapd/pull/8350 ?
[09:24] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[09:24] <zyga> it saves a little bit of time
[09:24] <zyga> and will be more prominent with the next cache PR where go unit tests runtime will shrink
[09:24] <zyga> (so go tests << 1 minute)
[09:27] <zyga> uh, I need to pick up a delivery
[09:27] <zyga> AFK for 15
[09:27] <pstolowski> wrt 1868706 just tested without any snaps (snap-mgmt purge, and removed all seeds), the upgrade worked as well
[09:50] <zyga> back now
[09:50] <zyga> pstolowski: I saw a police patrol checking why people are outdoors
[09:50] <zyga> that's a new for me!
[09:51] <pstolowski> zyga: right, they announced it yesterday
[09:52] <zyga> too bad they are ignoring the hobos hanging around benches :P
[10:00] <mup> PR snapd#8355 closed: github: run C unit tests <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8355>
[10:05] <mvo> mborzecki: do you think 8342 needs a samuele review? it looks pretty good from my pov
[10:05] <mup> PR snapd#8309 closed: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[10:06] <mborzecki> mvo: we can always tweak the naming later, but the endpoint and data POSTed there was discussed and agreed on, so i think it's fine to land it with another review
[10:06] <mborzecki> pstolowski: maybe you could take a look at #8342 as well?
[10:06] <mup> PR #8342: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[10:06] <mvo> mborzecki: +1
[10:07] <pstolowski> mborzecki: sure
[10:07] <mborzecki> pstolowski: thanks!
[10:14] <zyga> mvo: I've changed how we cache .deb files, seems to be passing;
[10:14] <zyga> mvo: I'll send one more patch that runs spread after unit tests
[10:14] <zyga> mvo: and that's all from me on gh actions today
[10:20] <mvo> zyga: ok
[10:21]  * zyga pushes to see if it uses the cache
[10:21] <mup> PR snapd#8335 closed: many: introduce naming.WellKnownSnapID <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8335>
[10:22] <dot-tobias> mvo: quick ping about zyga's https://github.com/snapcore/snapd/pull/8089#issuecomment-599914100 from affected snap developer :)
[10:22] <mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
[10:22] <zyga> dot-tobias: what about it?
[10:24] <zyga> dot-tobias: it needs to be reviewed and merged
[10:31] <mup> PR snapd#8277 closed: asserts,o/devicestate: support model specified alternative serial-authority <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8277>
[10:33] <zyga> pstolowski: ping
[10:33] <pstolowski> zyga: pong
[10:33] <zyga> pstolowski: should I push a tiny branch with this change: https://github.com/snapcore/snapd/pull/8352/files#diff-08088787360fb3ca74a0aed4c6103b22R264
[10:33] <mup> PR #8352: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
[10:33] <zyga> the part after, and including &&
[10:36] <mborzecki> zyga: yeah, jsut had to restart the spread run on opensuse-15 and all spread jobs in gh action got restarted :(
[10:36] <pstolowski> zyga: ah, this is the err cleanup bug you pinged me about some time ago? yes, it's fine, thank you!
[10:36] <zyga> mborzecki: right
[10:36] <zyga> pstolowski: k, doing so
[10:36] <pstolowski> zyga: it escaped me
[10:37] <mborzecki> zyga: so the question now is, can we still merge the PRs when one of the unstable systems fails?
[10:37] <dot-tobias> zyga: Yes, maybe I should've been more elaborate: Just wanted to ask if that's on the plate for 2.44, as I'm getting quite a few requests from wpe-webkit-mir-kiosk users after the last snap revision release. Most of them struggle with the required console commands to discard the namespace and refresh again, but at least I could tell them that this won't be an issue after snapd 2.44. Sorry if I came across bugging! I know that things slip under the
[10:37] <zyga> mborzecki: note that those are not mandatory
[10:37] <dot-tobias>  radar quickly, and thought like with 7655 a friendly ping might help 😊
[10:38] <zyga> mborzecki: you can totally ignore it
[10:38] <mborzecki> ah ok
[10:38] <zyga> dot-tobias: I don't know, it's a question to mvo
[10:38] <zyga> dot-tobias: maybe?
[10:38] <zyga> mborzecki: there's a way to set passing/failing status and other thing via actions but I didn't go that deep yet
[10:38] <zyga> mborzecki: so we could have a run matrix that chooses what must pass
[10:38] <zyga> mborzecki: or what cannot fail
[10:39] <zyga> mborzecki: but instead of having YAML for it there's just the API you can reach
[10:39] <dot-tobias> zyga: That's who the ping msg was intended for, should've left out your handle – sorry
[10:39] <pstolowski> mborzecki: one wondering re your PR, otherwise +1
[10:39] <zyga> dot-tobias: no worries, I hope you can get it in
[10:40] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8357
[10:40] <mup> PR #8357: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
[10:40] <zyga> mvo: ^ for 2.44
[10:40] <mup> PR snapd#8357 opened: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
[10:45] <zyga> man, this is so weird
[10:45] <zyga> you push something
[10:45] <zyga> and green tick shows up a moment later
[10:45] <zyga> that's too werid
[10:45] <zyga> can we go back to days of waiting for the red cross?
[10:46] <mborzecki> zyga: you mean the 1940s?
[10:47] <zyga> mborzecki: is that what travis is?
[10:47] <mborzecki> zyga: it feels like it at times
[10:52] <mborzecki> pstolowski: hmm good question about the label, right now we only check whether it's not empty
[10:52] <pstolowski> mborzecki: a-zA-Z check or some such would do
[10:53] <mborzecki> pstolowski: we should probably enforce some validity checks, probably [a-zA-Z0-9]+
[10:53] <pstolowski> yeah
[10:53] <ogra> zyga, mvo, should i make a minor commit (adding a full stop to the end of the comment or whatnot) to the usbprinter PR so the auto-testing kicks in again ?
[10:53] <zyga> ogra: please do
[10:53] <ogra> ok
[10:53] <zyga> I was unable to restart testing
[10:53] <zyga> ogra: or better
[10:53] <zyga> ogra: merge master
[10:53] <mborzecki> pstolowski: looked at seed, but there's no checks either
[10:55] <mborzecki> pstolowski: hm it probably makes most sense to add it in the seed 'seed' packge, in a follow up though
[10:56] <ogra> zyga, bah i hadn't reloaded the page ... seems mborzecki already managed to restart the test anyway
[10:56] <zyga> cool, that's ok
[10:56] <zyga> I need to improve caching today
[10:56] <mborzecki> ogra: yeah, though i doubt it stated given the usual job queue length
[10:56] <zyga> most of the extra waste is each spread run checking out a git tree
[10:57] <ogra> it seems to be running
[10:57] <zyga> I need to just have a local copy as accelerator
[10:57] <ogra> interesting though that you are the only one being able to trigger them
[10:57] <zyga> ogra: me or maciek?
[10:57] <ogra> maciek
[11:11] <jamesh> mvo: fyi, checks for https://github.com/snapcore/snapd/pull/8289 have passed except for OpenSUSE 15.1 -- there it is the unrelated session-tool spread test that failed
[11:11] <mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
[11:16] <zyga> jamesh: I am close to fixing the session-tool issue
[11:16] <zyga> jamesh: please just ignore that test failure
[11:17] <zyga> jamesh: also, sessions are hard :)
[11:17] <jamesh> zyga: I wonder if it would be better to implement this kind of thing in spread itself?
[11:18] <zyga> jamesh: not sure, it's a bit of a volatile problem
[11:18] <zyga> jamesh: only if we can be perfect about it
[11:18] <jamesh> zyga: e.g. have a task marked as requiring a user session, and have its prepare/execute/restore run as a user in a session
[11:18] <zyga> jamesh: and I doubt we can
[11:18] <zyga> jamesh: that would be nice but that's a bigger change and it's still unclear how to _get_ a user session reliably
[11:19] <mup> PR snapd#8358 opened: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
[11:19] <mborzecki> pstolowski: mvo: ^^
[11:19] <pstolowski> ty
[11:24] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8358#pullrequestreview-381913798
[11:24] <mup> PR #8358: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
[11:57] <mup> PR snapd#8359 opened: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <https://github.com/snapcore/snapd/pull/8359>
[12:18] <cachio> xnox, hey
[12:21] <pstolowski> cachio: hi! did you have time to try reproduce https://bugs.launchpad.net/snapd/+bug/1868706 ?
[12:21] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
[12:22] <cachio> pstolowski, yesterday I ran lot of tests but no luck
[12:22] <cachio> now I am going to run in a desktop vm
[12:22] <cachio> pstolowski, this test https://paste.ubuntu.com/p/FxXDys9KkT/
[12:23] <zyga> hmm
[12:23] <cachio> pstolowski, if you want to take a look and propose anything else should be great
[12:23] <zyga> we cannot create warnings through the API, can we?
[12:23] <pstolowski> cachio: ok. note Mark said in the comments that there are no snaps when this happened
[12:24] <zyga> pstolowski: could it be seeding
[12:24] <zyga> pstolowski: when using focal you may end up with bad seeding
[12:24] <zyga> pstolowski: and then snap update from the deb archive will indeed "hang"
[12:24] <zyga> pstolowski: as the postinst script waits for seeding to complete
[12:24] <pstolowski> zyga: it's an existing system afaiu
[12:24] <zyga> pstolowski: I know
[12:24] <zyga> pstolowski: but think if this is possible
[12:24] <cachio> pstolowski, ah, yerday I cloneed a vm
[12:24] <cachio> and started upgrading
[12:24] <zyga> pstolowski: normally seeding being broken shows up as 1) no snaps 2) hang during update
[12:24] <cachio> like 10 times
[12:24] <cachio> but coulnd reproduce
[12:26] <cachio> zyga, something that I noticed is that postinst script tahngs like 1 minute or more until it finishes
[12:26] <cachio> it happened many times
[12:26] <cachio> but then it finishes
[12:26] <zyga> cachio: did you check what was going on then?
[12:26] <pstolowski> zyga: hmm that's an interesting observation. i thought about seeding but then the fact it wasn't a new installation (apparently) confused me. otoh, no snaps at all looks weird as well nowadays. indeed if seeding never completed then perahps it's causing an issue
[12:27] <zyga> yeah
[12:27] <zyga> I'm 90% sure that's that
[12:27] <zyga> 0 snaps
[12:27] <cachio> yes, but didnt see the error reported by mark
[12:27] <zyga> unless he actually removed snaps
[12:27] <cachio> I can check that again
[12:33] <zyga> mvo: can we land https://github.com/snapcore/snapd/pull/8350 now?
[12:33] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[12:33] <zyga> all green and adjusted
[12:38] <pstolowski> zyga: thanks for the idea, i'll try to break seeds and see
[12:38] <zyga> pstolowski: I have 20.04 seed that's broken
[12:38] <zyga> if you want it
[12:38] <zyga> tarballed it u0
[12:38] <zyga> in case I needed to :)
[12:38] <zyga> it's the one from one of the broken dailies
[12:38] <zyga> daily images
[12:39] <pstolowski> zyga: thanks, i'll quickly try to break it myself, will ask you for image if that doesn't work ;)
[12:39] <zyga> k
[12:58] <mup> PR snapd#8360 opened: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>
[13:03] <pstolowski> zyga: hmm i cannot provoke seed error, i'm probably breaking it wrong ;). share your tarball pls
[13:03] <zyga> pstolowski: sure
[13:03] <zyga> pstolowski: it's ~300MB
[13:03] <zyga> pstolowski: let me try something
[13:03] <pstolowski> zyga: it's fine, i'm on fiber here
[13:03] <zyga> man really?
[13:03] <zyga> you should run the spread cluster then ;D
[13:03] <zyga> I'm on LTE
[13:04] <pstolowski> 300Mb/s, from orange
[13:04] <zyga> I wish it was on my street
[13:04] <zyga> anyway
[13:04] <zyga> I have the file now
[13:05] <zyga> sending away
[13:10] <mup> PR snapd#8342 closed: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[13:17] <zyga> brb
[13:21] <cachio> zyga, when postinit script runs I see this
[13:21] <cachio> root       10026    9998  0 10:20 pts/0    00:00:00 /bin/systemd-tty-ask-password-agent --watch
[13:21] <cachio> it hangs for some seconds
[13:21] <zyga> cachio: ha
[13:21] <zyga> that's polkit
[13:21] <zyga> mborzecki: ^
[13:21] <zyga> remember what you told me yesterday
[13:21] <zyga> is that what you saw?
[13:21] <mborzecki> ouch
[13:21] <mborzecki> wow
[13:22] <mborzecki> perhaps it's always started (doesn't make sense though?)
[13:22] <mborzecki> cachio: have you seen it on focal only?
[13:23] <cachio> also I see this
[13:23] <cachio> message+     429       1  0 10:08 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
[13:23] <cachio> just checked that on focal
[13:24] <zyga> mborzecki: mvo told us recently that apt (or dpkg) always creates a pty
[13:24] <zyga> so perhaps systemd thinks, gee let me ask the user
[13:24] <zyga> and spawns some text polkit prompt
[13:24] <zyga> anyway
[13:24] <zyga> I need to brb
[13:24] <zyga> for real
[13:24]  * zyga afk
[13:30] <mborzecki> hm idk, maybe it systemctl shoudl be called with --no-ask-password?
[13:31] <mborzecki> zyga: looking at the code it's started always if you're on local bus (i.e. talking to the local systemd) and there wa no --no-ask-password
[13:31] <mborzecki> hmmmm
[13:37] <pstolowski> zyga: you were right!!
[13:38] <pstolowski> how can i buy you a beer? ;)
[13:38] <pstolowski> mvo: ^ mistery of Mark's bug solved i think
[13:39] <zyga> pstolowski: ha
[13:39] <zyga> pstolowski: I could use a coffee :D
[13:39] <zyga> I just tried making one
[13:39] <zyga> but my son, Janek, is upstairs with remote teacher video call
[13:40] <zyga> I guess it's the age were everyone pretty much does what I do, sit in front of a screen all day
[13:40] <zyga> write type talk to people
[13:40] <zyga> I need to move the coffee machine here :D
[13:40] <pstolowski> apt is now hanging on snapd debs
[13:40] <zyga> lovely
[13:40] <pstolowski> pstree shows similiar output
[13:43] <zyga> pstolowski: what does pstree show?
[13:44] <pstolowski> zyga: it matches the one from bug report https://pastebin.ubuntu.com/p/74XywhJfwc/
[13:44] <zyga> yeah
[13:44] <pstolowski> snapd.seeded.service makes it wait i presume
[13:44] <zyga> the problem is that we should not start the seeding unit
[13:45] <zyga> it's a debhelper thing
[13:45] <zyga> it's not sane in our case
[13:45] <pstolowski> mhm. we should probably do something sane
[13:45] <zyga> I think we need to adjust that debhelper line
[13:50] <pstolowski> cachio: so, problem understood ^
[13:51] <zyga> mvo: 2.44.1 is failing to build in the edge ppa
[13:52] <mvo> zyga: uh, all of it?
[13:52] <zyga> https://www.irccloud.com/pastebin/yjTrMeXv/
[13:52] <zyga> just this test
[13:52] <zyga> we've seen it before, didn't you say it was some package in the archive thing?
[13:52] <mvo> pstolowski: oh, mystery solved? I like that!
[13:53] <mvo> pstolowski: can you give me the tl;dr summary please? or explain in the standup maybe
[13:56] <ijohnson> good work pstolowski
[13:56] <ijohnson> and zyga too :-)
[13:56] <ijohnson> and morning folks
[13:57] <zyga> good morning :)
[13:57] <zyga> oh
[13:57] <zyga> standup time
[13:57] <pstolowski> mvo: focal image with broken seeds; seeds never completes; snapd deb update blocks on snapd.seeded.service
[13:58] <pstolowski> i've updated https://bugs.launchpad.net/snapd/+bug/1868706
[13:58] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
[13:58] <pstolowski> hey ijohnson
[13:59] <mvo> pstolowski: ha! fun, just like last time. also *so* sad
[13:59]  * ijohnson stands up while sitting down
[14:03] <zyga> mvo: /dev/fuse has a new meaning
[14:03] <zyga> there's an IOCTL to explode the pC
[14:14] <mvo> zyga: haha
[15:18] <zyga> I wrote the instructions for github actions runner
[15:18] <zyga> who wants to work with me to try it ouy?
[15:19] <zyga> degville: perhaps you? (it's a wall of text)
[15:19] <zyga> but anyone who wants to is totally welcome to
[15:19] <degville> zyga: yes, of course.
[15:22] <zyga> mvo: ok, it's in progress :)
[15:26] <ijohnson> mvo is it okay for me to de-conflict #8010 now ?
[15:26] <mup> PR #8010: snap-bootstrap: add support for "recover" mode <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
[15:29] <mvo> ijohnson: sure
[15:29] <ijohnson> ack
[15:44]  * zyga -> food
[15:58] <mup> PR snapd#8358 closed: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8358>
[15:59] <mup> PR snapd#8357 closed: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8357>
[16:00] <mup> PR snapd#8361 opened: o/devicestate: rename readMaybe* to maybeRead* <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8361>
[16:00] <zyga> re
[16:02] <mup> PR snapd#8350 closed: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8350>
[16:02] <zyga> ta!
[16:02] <zyga> I'll propose the last step in a sec, let me just organize myself after the break
[16:10] <mup> PR snapd#8362 opened: github: fix order of go get caches <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8362>
[16:14] <mup> PR snapd#8363 opened: github: combine tests into one workflow <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8363>
[16:17] <ijohnson> mborzecki: is #8305 ready to review now?
[16:17] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[16:18] <mborzecki> ijohnson: yes, there will be some tweaks to the data that's passed back, but the overall shape should not change at this point
[16:18] <ijohnson> ack I'll review that today then
[16:19] <Saviq> zyga: you should know this… following https://snapcraft.io/docs/installing-snap-on-fedora on F31
[16:19] <zyga> yeah?
[16:19] <Saviq> $ snap install hello-world
[16:19] <Saviq> error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
[16:19] <Saviq>        /tmp/sanity-mountpoint-444060033: unknown filesystem type 'squashfs'.
[16:19] <zyga> yeah
[16:19] <zyga> also known as rpm sucks at dependencies
[16:20] <zyga> you are installing the modules for the kernel
[16:20] <zyga> but not the one you are running
[16:20] <zyga> IIRC rebooting will fix it
[16:20] <zyga> because now kernel and modules match
[16:20] <Saviq> DUH
[16:21] <Saviq> https://forum.snapcraft.io/t/installing-snap-on-fedora/6755/9?u=saviq
[16:22] <zyga> Saviq: try rebooting and tell me if that helped
[16:22] <Saviq> nope
[16:23] <Saviq> zyga: ↑
[16:23] <zyga> Saviq: hmmmmmm
[16:23] <zyga> Saviq: is that a cloud vm?
[16:23] <zyga> or a desktop system
[16:23] <Saviq> zyga: cloud
[16:23] <zyga> ah
[16:24] <zyga> so cloud is more complex - their kernel seems to lack that
[16:24] <zyga> and we cannot express the dependency clearly IIRC
[16:24] <zyga> there's a package you should be able to install though, one moment
[16:24] <Saviq> zyga: ack, I will reply to the forum thread with a reproducer
[16:24] <zyga> Saviq: try installing kernel-modules
[16:24] <Mirv> you may be interested in checking if this is something on snap side or fwupd side: https://github.com/fwupd/fwupd/issues/1915
[16:25] <Saviq> whois Mirv
[16:25] <Saviq> Timo!
[16:25] <Saviq> o/
[16:25] <Mirv> (likely fwupd, as it's a regression, but I guess something in snap when using classic mode could also assume ubuntuish ca-certifates)
[16:25] <Mirv> :D Saviq!!
[16:25] <zyga> Mirv: opensuse uses different /etc/ssl layout than debian
[16:26] <zyga> Mirv: perhaps we need to look
[16:26] <zyga> it' a classic snap?
[16:26] <zyga> so it should be less so but still
[16:26] <Mirv> zyga: yes it does, I haven't bumped into such problem before with any snap though, and fwupd also used to work correctly
[16:26] <zyga> can you reproduce that or is that someone else reporting?
[16:26] <Mirv> it's my report
[16:26] <zyga> does /etc/ssl/certs/ca-certificates.crt exist?
[16:27] <Mirv> so simply installing fwupd currently on Tumbleweed shows it
[16:27] <Mirv> no, there's no such thing on openSUSE
[16:27] <zyga> do you know what is trying to read that file?
[16:27] <zyga> is it some kind of hard-coded feature of the library bundled in the snap/
[16:27] <zyga> I'm also surprised it worked before
[16:27] <zyga> nothing changed in that regard in many months
[16:28] <Mirv> not really.
[16:29] <Mirv> it was my guess it'd be something changed in fwupd, but thought to mention here too if it'd immediately ring some bell
[16:30] <Mirv> strace https://pastebin.ubuntu.com/p/FRzNVPM9QJ/
[16:30] <zyga> Mirv: where are the certs on your system?
[16:30] <zyga> Mirv: IIRC it's just a "hard thing" to make classic snaps
[16:31] <zyga> I don't think snapd can do anything about this
[16:34]  * cachio lunch
[16:34] <mup> PR snapd#8364 opened: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364>
[16:35] <Mirv> zyga: around /usr/share/pki/trust/ , the system is very different from Debian/Ubuntu indeed
[16:35] <zyga> Mirv: can you try to summarize how it looks like, perhaps it will allow us to come up with some ideas
[16:35] <Mirv> zyga: right, thanks, that's mostly what I wanted to hear that it's up to snap package to (try to) keep cross-distro compatibility in a classic snap
[16:35] <zyga> Mirv: and it is also useful because mvo is working on a ssl-related feature CC mvo  ^
[16:36] <Mirv> zyga: I'm not very familiar with that either https://unix.stackexchange.com/questions/80131/how-do-i-install-a-system-wide-ssl-certificate-on-opensuse
[16:38] <zyga> Mirv: can you respond to https://github.com/fwupd/fwupd/issues/1915
[16:38] <zyga> Mirv: I'm not familiar with the snap
[16:41] <Mirv> Access by specifying a revision is not allowed for this Snap. ... hmm, ok, I'd have liked to triage
[16:42] <Mirv> answered yes, maybe superm1 can debug it if he's maintaining the snap
[16:51] <ijohnson> zyga: have you ever looked at `spread -abend` ?
[16:51] <ijohnson> seems to do what you were wanting in this morning's SU
[16:51] <zyga> yeah
[16:52] <zyga> can you remind me?
[16:52] <zyga> ah
[16:52] <zyga> the log?
[16:52] <zyga> or ... no?
[16:52] <zyga> I don't recall
[16:52] <ijohnson> you wanted a way to stop the spread run on the first failure
[16:52] <zyga> ah
[16:52] <zyga> oh!
[16:52] <zyga> then I must have not remembered the name right, I dind't know it exits
[16:53] <zyga> oh that's perfect
[16:53] <zyga> I'll use that
[16:53] <zyga> thank you  :)
[16:53] <ijohnson> :-)
[16:59] <Mirv> zyga: turns out I was able to install older versions after all, which also failed.. so then it turned out it's actually openSUSE bug of some sort, to which I documented a workaround
[17:00] <cachio> zyga, did yo usee the values I left in the standup doc?
[17:00] <zyga> cachio: yes but they are too opaque, we should check out what's taking that time
[17:00] <zyga> yes numbers are bigger
[17:00] <zyga> why?
[17:01] <cachio> zyga, do you know a way to trace systemd and get times?
[17:02] <zyga> cachio: I would look at perf
[17:02] <zyga> I think it is not systemd
[17:02] <zyga> but many components of the system and their interaction
[17:02] <zyga> cachio: if you work with maciek on this he should be able to help you, he's pretty good at using perf
[17:02] <cachio> zyga, sure
[17:03] <zyga> ok, I need to EOD soon
[17:03] <cachio> mborzecki, do you have any suggestion to see what's going on with systemd calls?
[17:03] <mup> PR snapcraft#2984 closed: plugins: move the existing plugin to a new package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2984>
[17:06] <mup> PR snapcraft#2993 closed: repo: remove dead code from deb implementation <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2993>
[17:06] <mup> PR pc-amd64-gadget#35 closed: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
[17:07] <mborzecki> cachio: not really, probably we'd have to start with a single call, eg systemctl <some>.service and then observe the bus traffic between the old version and new one, probably gather a bunch of samples too
[17:08]  * zyga EODs
[17:08] <mborzecki> yeah, me too
[17:09] <mborzecki> now the 'home schooling' shift starts :/
[17:09] <mup> PR snapcraft#2994 closed: repo: move filtered package list from manifest.txt into a python list <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2994>
[17:40] <mup> PR snapd#8361 closed: o/devicestate: rename readMaybe* to maybeRead* <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8361>
[17:41] <mup> PR snapd#8359 closed: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8359>
[18:15] <mup> PR snapcraft#2995 opened: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2995>
[20:26] <mup> PR snapd#8365 opened: seed: add Info() method for seed.Snap <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8365>
[20:26] <mup> PR snapd#8366 opened: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
[20:59] <mup> PR snapd#8367 opened: snap/cmd: the model command needs just a client, no waitMixin <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8367>
[21:33] <mup> PR snapd#8345 closed: boot,overlord: rename operating mode to system mode  <Reviewed> <Skip spread> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8345>
[22:17] <mup> PR snapd#8360 closed: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>


[06:12] <pitti> Good morning
[06:14] <pitti> desrt: the one commit we reverted that makes the "close last tab" crash go away is now causing the critical that we see in deja-dup's test
[06:15] <pitti> desrt: pythonpath> really? that seems to work for me, e. g. in jhbuild I get
[06:15] <pitti> $ PYTHON=python3 jhbuild run python3 -c 'import gi; print(gi._overridesdir)'
[06:15] <pitti> /home/martin-scratch/gnome/lib/python3.3/site-packages/gi/overrides
[06:16] <pitti> desrt: there is no "list", there's only one override dir per python version
[06:37] <robru> pitti, good morning! Thanks for merging my dbusmock stuff. we really needed that ;-)
[06:37] <pitti> hey robru, good morning
[06:37] <robru> pitti, just curious, when do you think dbusmock 0.4.0 will be officially released?
[06:37] <pitti> robru: my pleasure!
[06:38] <pitti> robru: fun thing, another Canonicalizen pinged me yesterday about the daily packages, and said "they are great, but they would be perfect with logging over D-BUS" :-)
[06:38] <robru> pitti, haha, great
[06:39] <pitti> robru: if you just need packages, you can always use the debs from https://code.launchpad.net/~pitti/+archive/daily-builds
[06:39] <pitti> robru: but if you need it as a build dep, I can release it this week still if it's urgent
[06:40] <robru> pitti, not urgent; I already backported the package for a PPA that we're using in quantal. just curious how long it will be before I can drop that backport and use an official package ;-)
[06:40] <pitti> robru: I want to work on some more g-s-d test cases this week, for that I'm probably going to need some more templates
[06:41] <pitti> so I think I'll release next week
[06:41] <robru> pitti, cool, no worries.
[06:41] <robru> pitti, take the time to make it great ;-)
[06:41] <pitti> heh
[06:41] <robru> pitti, I mean, it's already great, but you know what I mean ;-)
[06:42] <robru> don't rush it ;-)
[07:27] <jibel> good morning
[07:37] <robru> hey pitti, since I'm now trying to write a vala wrapper around this dbusmock api you just merged... do you have any guesses as to what the vala method signature definition would look like for a method that returns 'a(tsav)'? I'm quite new to Vala so I really don't have a clue here.
[07:40] <pitti> robru: hm, I'm afraid my Vala exercises have been quite a while ago, and I didn't get beyond a 50 liner :(
[07:40] <pitti> so not off the top of my head
[07:40] <robru> pitti, hehe, ok. I'm also much more comfortable with python ;-)
[07:41] <robru> pitti, but I'm trying to learn and I can't seem to find much documentation here ;-)
[07:41] <pitti> but for C, a() maps to a normal array, t to guint64, s to a normal string in vala; for av I'm not sure, how Vala maps variants
[07:41] <pitti> robru: I had expected that you'd use GDBus and that this just gives you a single Variant?
[07:41] <robru> pitti, not sure...
[07:42] <robru> pitti, I'm expanding some existing code that was written by kenvandine, and it seems he's made a new object that inherits directly from GLib.Object, and somehow this is able to make dbus calls...
[07:43] <robru> pitti, http://bazaar.launchpad.net/~super-friends/libfriends/trunk/view/head:/tests/vala/dbusmock.vala
[07:43] <pitti> wow, that is all? magic
[07:44] <pitti> seems Vala has GDBus built in then? nice
[07:44] <robru> pitti, so that I've already successfully expanded to cover ClearCalls, which is nice and easy with void return value, but yeah, I have no idea how to define the return value for this crazy a(tsav) thing
[07:44] <pitti> robru: I guess once you figured out how Vala represents multiple return values in general, it should be rather easy
[07:44] <robru> pitti, yes, vala is very magical, and it makes it somewhat difficult to learn :-(
[07:46] <robru> pitti, are you aware of any documentation for vala, specifically about return values? All I've been able to find is like 'string[]' or 'int[]' and those don't even begin to encompass this object...
[07:46] <pitti> I guess you can always start with directly calling the GDBus methods, like dbusmock.call_sync()
[07:46] <robru> pitti, I'm not familiar with call_sync
[07:47] <pitti> robru: standard glib API: http://developer.gnome.org/gio/2.26/GDBusProxy.html#g-dbus-proxy-call-sync
[07:47] <pitti> but that requires you to assemble and disassemble the GVariants yourself, so if vala provides some syntactic sugar around it it's certainly interesting to find out how that works
[07:50] <robru> pitti, I wonder if I could just say GVariant[]
[07:53] <robru> pitti, https://live.gnome.org/Vala/DBusServerSample comes close to giving a hint:  a(ii) maps to Foo[] where Foo might be defined as
[07:53] <robru> struct Foo { public int a; public int b };
[07:54] <pitti> oh, clever
[07:54] <robru> pitti, so it sounds like I need to make a struct of 'tsav'
[07:54] <robru> but what does 'av' map to?
[07:54] <robru> Variant[] I guess
[07:54] <pitti> right
[07:55] <pitti> so a struct Call { gint64, string, Variant[] }, and then let it return Call[] ?
[07:55] <robru> so: struct CallSignature { public int a; public string b; public Variant[] c } or something
[07:55] <robru> hehe
[07:55] <robru> pitti, ok, I'll play with this, and if I can get it to work I'll let you know (and also update that wiki...
[07:55] <pitti> ok, tuples mapping to structs makes perfect sense (that's what they are really)
[07:56] <robru> pitti, any thoughts on where that struct definition goes in the vala file? should it be in the class level, namespace level, or toplevel?
[07:56] <pitti> robru: I'd put it right above the d-bus interface definition, i. e. where you define GetCalls()
[07:56] <pitti> but it shouldn't matter much
[07:56] <robru> pitti, ok, thanks
[08:02] <pitti> robru: NB that it's really a guint64, not just int
[08:02] <pitti> 't', not 'i'
[08:06] <robru> pitti, valac tells me 'guint64' type name could not be found. maybe vala calls it something different?
[08:06] <pitti> http://references.valadoc.org/#!api=glib-2.0/uint64
[08:06] <pitti> robru: uint64
[08:06] <robru> pitti, ah, thanks
[08:07] <robru> pitti, ok, I seem to be getting somewhere... it almost compiles ;-)
[08:19] <robru> pitti, ok, so let's say I got this to compile and I'm able to get this Call struct from dbus... now how do I create a new instance of the struct with the expected values in order to compare it against the returned struct?
[08:19] <robru> pitti, basically, "how do I instantiate a struct"?
[08:19] <robru> ;-)
[08:20] <pitti> robru: the vala tutorial shows that, too
[08:20] <pitti> https://live.gnome.org/Vala/Tutorial#Structs
[08:20] <robru> pitti, thanks. Dunno why this isn't showing up on the googles.
[08:50] <Sweetsha1k> morning all!
[08:51] <Sweetshark> LibreOffice 4.0 beta1/raring build succeeded on armel \o/
[08:52] <pitti> hey Sweetshark
[08:52] <pitti> Sweetshark: niice! after only a week or so? :-)
[08:53] <Sweetshark> pitti: two days
[08:55] <chrisccoulson> good morning everyone
[08:56] <Laney> hey
[08:56] <Sweetshark> one lib is 64MB alone.
[08:57] <Laney> mvo: Hey ;-) I was looking at errors.u.c yesterday and it seems that two popular s-c bugs are fixed in the 5.2 branch but it's not released to precise yet
[08:57] <Laney> are you waiting on some more changes there? I'd be happy to upload it otherwise ...
[09:01] <mvo> Laney: not waiting for anything else, go ahead with the upload if you want
[09:01] <Laney> great
[09:01] <Laney> mvo: university life treating you well?
[09:02] <chrisccoulson> hi Laney, Sweetshark, pitti
[09:02] <chrisccoulson> mvo! Hi :)
[09:02]  * pitti waves to chrisccoulson and mvo
[09:02] <Laney> ahoy there
[09:02] <pitti> hey Laney
[09:03]  * Laney sees snow is forecast all tomorrow and over the weekend
[09:03] <robru> pitti, ok, so this seems to be working, not just compiling but actually tests passing: http://bazaar.launchpad.net/~robru/libfriends/dbusmock/revision/53
[09:03] <mvo> Laney: takes a bit to get used to it (again) but its a interessting change
[09:03] <mvo> hey chrisccoulson
[09:03] <mvo> and hey pitti
[09:03] <Sweetshark> chrisccoulson: good morning. Now we only need qengho to complete the fat apps crew.
[09:04] <pitti> robru: that looks beautiful!
[09:04] <pitti> robru: err, comparing raw hash values?
[09:04] <robru> pitti, well, it's littered with FIXME's, but other than that it's pretty slick I guess ;-)
[09:04] <pitti> robru: why not comparing strings?
[09:05] <robru> pitti, yeah, I dunno why, but if I compared the string value it would just fail. wouldn't say why, but the assertion would just fail
[09:05] <pitti> or variant types and values?
[09:05] <pitti> robru: well, it's a Variant, so you need to call .get_string() or .get_int() or whatever the argument type is
[09:06] <robru> pitti, I tried comparing variants to strings, I tried constructing string variants and comparing those, I tried extracting the string from the variant and comparing strings, just could *not* get it to compare equally. the hash value was all that would work
[09:06] <pitti> robru: what's the result of myvariant.get_string()? does that assert?
[09:06] <pitti> about wrong data type or so?
[09:07]  * Laney sees "use gstreamer1.0
[09:07] <Laney> " in LO \o/
[09:07] <pitti> \o/++
[09:08] <robru> pitti, test-service.vala:137.21-137.51: error: The name `to_string' does not exist in the context of `GLib.Variant'
[09:08] <robru>             assert (calls[0].call_args[0].to_string() == "twitter");
[09:08] <pitti> robru: get_string, not to_string :)
[09:08] <robru> d'oh!
[09:08] <pitti> http://developer.gnome.org/glib/2.28/glib-GVariant.html
[09:08] <pitti> devhelp FTW
[09:09] <robru> pitti, ah, better. other objects in vala use to_string, so I was confused ;-)
[09:09] <pitti> robru: well, to_string is the Vala API; g_variant_get_string() is GLib
[09:09] <pitti> Vala is by and large just syntactic sugar around C and GLib
[09:10] <pitti> a lot of tasty sugar admittedly, but still
[09:15] <Laney> I think you can also cast to the appropriate type to dereference GVariants in vala too :-)
[09:15] <robru> pitti, yeah, the trick is that I have no background in C, so Vala is basically indecipherable magic to me. Too many layers of misdirection going on, totally inscrutable ;-)
[09:15] <robru> I'm sure for C programmers it's like the slickest thing.
[09:15] <pitti> Laney: oh, so you can do "(string) my_variant" ?
[09:15] <Laney> yeah
[09:15] <pitti> robru: oh my, yes
[09:15] <pitti> more sugar then :)
[09:19] <robru> pitti, ok, here's the overall diff here, cleaned up, with both GetCalls and ClearCalls in play: https://code.launchpad.net/~robru/libfriends/dbusmock/+merge/143649
[09:19] <pitti> :)
[09:56] <pitti> Laney: desrt's patch in https://bugzilla.gnome.org/show_bug.cgi?id=690118 works very well
[09:56] <ubot2`> Gnome bug 690118 in general "Crash when closing last tab of a window using Ctrl-w" [Normal,New]
[09:56] <pitti> Laney: I guess I'll drop the revert in svn and add that patch instead, and reupload?
[09:56] <pitti> that ought to fix déja-dup
[09:57] <Laney> yay
[09:57] <Laney> revert the revert and apply that sounds good to me
[10:00] <pitti> having to wait for all the autopkgtest to succeed makes the update take very long, but IMHO it's so worth it
[10:02] <Laney> yeah I look forward to the day when all the automation works seamlessly
[10:02] <pitti> it's also a nice system to prevent the temptation of "yeah, we'll fix it later"
[10:04] <pitti> Laney: pushed to svn, and glib2.0_2.35.4-0ubuntu3 uploaded; crossing fingers
[10:04]  * Laney wonders how cdimage.u.c manages to be consistently so fast
[10:05] <Laney> 13009 kBps
[10:05] <pitti> no release nor milestone these days?
[10:05] <Laney> zsyncing a precise daily
[10:43] <pitti> glib/i386 built and succeeded all tests
[13:40] <Laney> pitti: deja-dup blue again \o/
[13:45] <pitti> Laney: and all built now: https://launchpad.net/ubuntu/+source/glib2.0/2.35.4-0ubuntu3
[13:45] <Laney> yep
[13:45] <Laney> good to unblock you think?
[13:45] <pitti> looks like all the reverse dependency tests succeede
[13:45] <pitti> d
[13:45] <pitti> Laney: rumble!
[13:48]  * Laney fired ze missiles
[13:57] <desrt> Laney: hey.  did you see https://bugzilla.gnome.org/show_bug.cgi?id=690118#c21 ?
[13:57] <ubot2`> Gnome bug 690118 in general "Crash when closing last tab of a window using Ctrl-w" [Normal,New]
[13:57] <desrt> Laney: would be fun to give that a run through the autopkgtests before i commit it.  is that possible?
[13:58] <Laney> desrt: pitti uploaded that this morning and confirmed that the tests pass immediately before your question :-)
[13:58] <pitti> desrt: many thanks for that fix!
[13:58] <desrt> oh
[13:58] <desrt> great :)
[13:58] <desrt> i'll commit it then.  thanks, guys :)
[13:59] <Laney> thank you for the fix!
[13:59] <desrt> i introduced the problem.  i owed it :p
[13:59] <pitti> desrt: we just gave it green light to make it into raring
[13:59] <pitti> yay for glib 2.35!
[14:00] <desrt> sweet!
[14:01]  * Laney → lunchwards
[14:01] <Laney> need to go out to the shop to get some food... freezing cold...
[14:01]  * Laney dreads
[14:02] <pitti> it has snowed non-stop since yesterday evening here
[14:02] <pitti> biking to Taekwondo was "fun"
[14:37] <cyphermox> morning
[15:11] <Laney> only one dubious sliding incident :-)
[15:12] <Laney> hey cyphermox
[15:12] <cyphermox> Hey Laney
[16:59] <achiang> kenvandine: what are the chances of getting this guy SRU'
[16:59] <achiang> ed into 12.04 - https://bugs.launchpad.net/xchat-indicator/+bug/587902
[16:59] <ubot2> Launchpad bug 587902 in XChat Indicator "PM alert remains in indicator if sender changes his nickname" [Undecided,Fix released]
[17:01] <kenvandine> achiang, i can give it a shot
[17:01] <kenvandine> achiang, can you test it on precise?
[17:02] <achiang> kenvandine: i am in fact, tortured daily by that bug since i run precise. :)
[17:02] <kenvandine> :)
[17:02] <achiang> kenvandine: i will be the first to test it for you!
[17:02] <kenvandine> achiang, cool
[17:02] <kenvandine> i'll give it a shot then
[17:02] <achiang> hurray!
[17:02] <kenvandine> achiang, i can't run anything in virtualbox atm, which is killing me!
[17:03] <achiang> kenvandine: i'll run it on my "actualbox" ;)
[17:12] <desrt> seb128: will is complaining that you tried to make him do packaging :p
[17:13] <kenvandine> desrt, packaging is good for the soul
[17:15] <desrt> like flagellation?
[17:15] <kenvandine> haha
[17:38] <attente> hey cyphermox
[17:39] <attente> i'm not really sure how one would go about writing an automated test for this
[17:39] <attente> https://code.launchpad.net/~attente/indicator-appmenu/indicator-appmenu/+merge/143531
[17:44] <attente> maybe pitti can advise
[17:54] <alesage> attente, possibly I can help :)
[17:54] <attente> alesage, recommendations welcome :)
[17:55] <seb128> desrt, heh, packaging is a desktop team skill ;-)
[17:56] <alesage> attente, I think we can write an autopilot test for this, just trying to grok the MP
[18:13] <desrt> seb128: what happened to "we have more than enough packagers!"? :)
[18:21] <seb128> desrt, doing a package once is different from being a full time packager...
[18:22] <desrt> seb128: i know.  i tease.
[18:22] <desrt> i'm just jealous... i still haven't learnt packaging yet :p
[18:22] <seb128> I can give you some packaging work!
[18:22] <desrt> uh... brb
[18:40] <chrisccoulson> desrt, you want some packaging work?
[18:41] <desrt> uh... brb
[18:41] <chrisccoulson> heh
[18:41] <chrisccoulson> desrt, i've got this browser here....
[18:41] <chrisccoulson> ;)
[18:43] <chrisccoulson> kenvandine, i thought you said virtualbox didn't work?
[18:43] <kenvandine> chrisccoulson, i can't boot anything in virtualbox on any of my raring machines
[18:43] <kenvandine> it just hangs
[18:43] <chrisccoulson> kenvandine, hmmm, it works fine here
[18:43] <chrisccoulson> it booted the first time i tried it ;)
[18:43] <kenvandine> :/
[18:43]  * kenvandine cries
[18:44] <kenvandine> chrisccoulson, do you have an SSD?
[18:44] <chrisccoulson> kenvandine, yeah
[18:44] <desrt> you guys need to get with libvirt
[18:44] <desrt> that's some _seriously_ awesome stuff
[18:44] <kenvandine> desrt, will it do unity 3d?
[18:45] <desrt> oh.  maybe not :)
[18:45] <kenvandine> not so awesome :)
[18:45] <desrt> well, it does unity 3d
[18:45] <desrt> but i think it's llvmpiped
[18:46]  * desrt has a fedora, win32 and ubuntu-unity box in there
[18:46] <desrt> the best part is that they just run in the background and i can ssh in
[18:46] <desrt> you can even set them to boot up when your machine boots up
[18:46] <chrisccoulson> heh, i wouldn't want that. my machine boots slow enough already ;)
[18:46] <sarnold> I once discovered that I had five kvm VMs running for a while that I'd forgotten about. I was impressed :)
[18:47] <chrisccoulson> heh
[18:47] <kenvandine> virtualbox can run them headless
[18:47] <chrisccoulson> i don't use vm's that much at all, what with only having a 120GB SSD ;)
[18:47] <chrisccoulson> space is scarce
[18:47] <chrisccoulson> like, <100MB scarce most of the time ;)
[18:49] <chrisccoulson> kenvandine, oh, it hung on shutdown
[18:49] <kenvandine> nothing will boot for me
[18:49] <kenvandine> even a new VM
[18:51]  * desrt has a 120GB SSD, 4 vms and more space than he knows what to do with
[18:51] <desrt> this is my working laptop, though -- lots of code but no movies, music, etc.
[19:44] <jbicha_> seb128: do we still need to keep the pcsc-lite diff? http://bugs.debian.org/531592 has been marked fixed for a while
[19:45] <ubot2> Debian bug 531592 in libpcsclite1 "libpcsclite1: move to /lib" [Normal,Fixed]
[19:46] <seb128> jbicha_, I don't know, I did the merge because it was an easy one but I'm not familiar with the source, better to ask cjwatson
[20:18] <bcurtiswx> is anyone doing a PPA build of empathy 3.7.X for raring ?
[20:18] <bcurtiswx> maybe it's in the GNOME3 PPA i didn't look
[20:22] <bcurtiswx> I guess that would be where it would go if there was one, sry for the noise :)
[20:22] <ricotz> bcurtiswx, i was looking into it, not ready though
[20:23] <bcurtiswx> ricotz, great. I suspect lots of dep issues :) thx!
[20:24] <ricotz> bcurtiswx, actually not ;)
[20:24] <ricotz> no dep issues that is
[20:25] <bcurtiswx> ricotz, sweet
[21:16] <kenvandine> achiang, lp:~ken-vandine/xchat-indicator/lp_587902
[21:16] <kenvandine> achiang, can you build that package locally and test it?
[21:20] <achiang> kenvandine: building
[21:20] <kenvandine> achiang, thx
[21:30] <achiang> kenvandine: do you want to try torturing me? :)
[21:30] <achiang> kenvandine: send me a private /msg
[21:30] <achiang> kenvandine: then change your /nick
[21:30] <kenvandine> i would love to :)
[21:31] <achiang> kenvandine: the old behavior was that if you changed your /nick before i could respond to the old /nick, the indicator got stuck blue
[21:31] <achiang> ken[torture]: but it's all good now. i am torture free!
[21:31] <ken[torture]> :)
[21:31] <ken[torture]> thanks
[21:34] <ken[torture]> achiang, ok, uploaded
[21:34] <ken[torture]> now it is up to the SRU team :)
[21:35] <achiang> w00t!
[21:39]  * cyphermox goes to get dinner
[21:41] <achiang> ken[torture]: even if they dont' accept it, i've already installed it on my system and will happily run this until 14.04 is released. :)
[23:12] <tkamppeter> jasoncwarner, hi


 It hurts and bleeds but I think it is better than yesterday evening
[07:37] <zyga> Had a rough night but I am trying to get back to my feet
[07:43] <pstolowski> zyga: sounds scary, hope it's not too terrible.. get some rest
[08:07] <pstolowski> mvo: hey, ok to close #7000? i'll propose a new one
[08:10] <mvo> pstolowski: yes, thats fine
[08:10] <jamesh> pedronis: hi.  Re: the user session agent PR, I was able to put something together to have xenial's dbus-daemon launch a systemd version of "snap userd" with the right environment.
[08:10] <jamesh> pedronis: the problem comes when adding unix socket activation, since that provides a new method of starting the service that bypasses the environment load
[08:11] <pedronis> jamesh: I see, we should be able to do something about that, no?
[08:17] <jamesh> pedronis: the normal way the environment gets populated is through /etc/X11/Xsession.d/95dbus_update-activation-env
[08:18] <jamesh> pedronis: and the dbus-update-activation-environment helper program doesn't seem to handle the case when the systemd user instance is not present on the bus
[08:18] <mvo> pstolowski: looking forward to see the new one, but fwiw, I think we should not make the perfect the enemy of the good, just dealing with missing "core/current" will already help even though we don't deal with "snapd" yet
[08:19] <pedronis> jamesh: my point, can't setup something that runs on sessions that can talk to the systemd userd ?
[08:19] <pedronis> sorry
[08:19] <jamesh> it's not clear where we should get the environment from in this case
[08:20] <pedronis> jamesh: ?
[08:20] <jamesh> hmm.  maybe within the "snap userd --autostart" call?
[08:20] <pedronis> for example
[08:20] <jamesh> pedronis: systemctl can talk to the user instance because it has some private back channel for this case
[08:21] <pedronis> jamesh: my main point is that exept userd instances to be able to somehow setup talking to each other
[08:21] <pedronis> they could talk over sume /run files
[08:21] <pedronis> or something else
[08:21] <pedronis> *some
[08:23] <jamesh> pedronis: I'm still not entirely sure what the benefit of having these two separate tasks colocated in the same process is though.
[08:23] <pedronis> jamesh: how do we do user notifications if they are not?
[08:23] <pedronis> it one of the things you said we cannot do we they aren't
[08:23] <pedronis> maybe I misunerstood you
[08:24] <jamesh> pedronis: we can do that with just the session bus address, which I think I can work out a way to get
[08:24] <pstolowski> mvo: in the new version of 7000 i'm simply comparing snapd version string and got rid of the entire current symlink & refresh time logic
[08:24] <jamesh> being able to do xdg-open relies on a lot more
[08:25] <pedronis> jamesh: but in bionic we could have signle process though?
[08:25] <pedronis> *single
[08:25] <jamesh> pedronis: yes.
[08:26] <pedronis> jamesh: as I said I'm a bit worried to have a design that is more meant to accomodate xenial, than bionic
[08:26] <pedronis> but I understand there a trade offs
[08:27] <jamesh> pedronis: I'd see it more as allowing existing functionality to continue as is.
[08:28] <mvo> pstolowski: sweet
[08:28] <mvo> pstolowski: that sounds like the right approach, thank you!
[08:28] <jamesh> pedronis: also, having some separation between a service performing actions on behalf of untrusted apps and a service performing actions on behalf of snapd doesn't sound like a bad thing
[08:29] <pedronis> jamesh: you wrote this: "This also means that we will likely won’t be able to have the REST service post desktop notifications on Xenial. "
[08:29] <pedronis> you are saying this doesn't need to be true?
[08:31] <jamesh> pedronis: yes.  I noticed afterwards that the Upstart job is writing the bus address to $XDG_RUNTIME_DIR/dbus-session
[08:32] <jamesh> pedronis: so a hack sufficient to get notifications working on Xenial would be to check for that file when $DBUS_SESSION_BUS_ADDRESS is not set
[08:32] <pedronis> jamesh: if it's to fiddly to get one process on xenial, I'm ok with two processes, as long as we keep it can keep their functionality clearly separate, we don't have things we want to do that we can't
[08:33] <jamesh> that doesn't generalise to the xdg-open case though (I don't think)
[08:33] <pedronis> notifications and getting user input on them is one of them
[08:34] <pedronis> pstolowski: thanks for #7014
[08:34] <pedronis> I'l try to look at it soon
[08:34] <pstolowski> yw, ty
[08:34] <jamesh> that's another issue: Unity 7's notifications design explicitly doesn't support actions
[08:34] <pedronis> I imagine it's fairly mechanic
[08:35] <pedronis> ^ this was about #7014 (to be clear)
[08:36] <jamesh> that said, I don't think popping up dialogs will be particularly popular as an alternative
[08:36] <jamesh> anyway.  That's something to test down the road
[08:38] <pedronis> yes, in theory it would be better if it was up to the snaps
[08:38] <pedronis> to display things
[08:38] <pedronis> not snapd itself
[08:38] <pedronis> but we'll have to see
[08:41] <pedronis> jamesh: can you write something about notifications and how to get hold of the session dbus on xenial and bionic in the forum topic
[08:42] <jamesh> sure.
[08:43] <jamesh> I need to check what notify-osd actually does if I post a notification with actions.  At one point it converted it to a dialog itself.  Not sure about now.
[08:43] <pedronis> jamesh: thank you
[08:45] <seb128> jamesh, it still does that, notify-osd didn't change for like 7 years :)
[08:45] <jamesh> seb128: that's probably a good thing in this case.  Thanks
[08:46] <seb128> yw!
[08:55] <jamesh> pedronis: fwiw, it looks like CentOS 7 doesn't have a user instance of systemd at all, so it is like Ubuntu 14.04 in that respect
[08:57] <pedronis> jamesh: ok, we'll need to think about degradation of these features
[08:58]  * zyga just spilled coffee over *everything* on his desk
[08:58] <zyga> this is not my day
[08:59] <jamesh> pedronis: if you only care about CentOS 7 on servers it is probably fine.  CentOS 8 is just around the corner too
[10:05]  * pstolowski school end & early lunch, bbl
[10:13] <Chipaca> pedronis: should 'snapctl set-health' be usable as non-root?
[10:14] <pedronis> Chipaca: do we even have that concept for snapctl commands ?
[10:14] <pedronis> Chipaca: anyway if the cookie is right I don't see why not
[10:16] <pedronis> Chipaca: am I missing something?
[10:16] <Chipaca> pedronis: I'm not sure what you're wanting to ask wrt your 1st question
[10:17] <Chipaca> pedronis: currently 'snapctl set-health' fails with 'error: cannot use "set-health" with uid 1001, try with sudo'
[10:17] <pedronis> Chipaca: mmh ?
[10:17] <pedronis> did we change something
[10:17] <pedronis> was it always like that?
[10:17] <pedronis> I thought for snapctl we used a different socket
[10:17] <pedronis> and only the cookie counted
[10:17] <Chipaca> overlord/hookstate/ctlcmd/ctlcmd.go:	return &ForbiddenCommandError{Message: fmt.Sprintf("cannot use %q with uid %d, try with sudo", f.Name, f.Uid)}
[10:18] <Chipaca> (which is funny because how is sudo going to work 'inside')
[10:18] <Chipaca> (from a hook i mean)
[10:18] <Chipaca> bah, hooks are run as root i guess?
[10:18] <pedronis> yes
[10:18] <pedronis> hooks are run as root
[10:19] <Chipaca> pedronis: there's a whitelist of not-root things
[10:19] <Chipaca> right now it's "get" and "services" that are whitelisted
[10:19] <pedronis> where is it?
[10:19] <pedronis> apparently I didn't know about this
[10:19] <Chipaca> pedronis: overlord/hookstate/ctlcmd/ctlcmd.go line 124
[10:20] <pedronis> interesting
[10:20] <pedronis> but ok
[10:20] <pedronis> Chipaca: I sort feel like setting healt should be ok not from root
[10:20] <pedronis> though
[10:21] <pedronis> *health
[10:25] <Chipaca> ok done
[10:25] <Chipaca> hmm, revision is _not_ getting set :-(
[10:25]  * Chipaca hmms
[10:29] <pedronis> Chipaca: ephemeralContext sets snap name but not revision
[10:29] <pedronis> see hookmgr.go
[10:31] <Chipaca> pedronis: but I'm also getting unset when it's not ephemeral (ie when it's a hook)
[10:31] <pedronis> ah
[10:31] <pedronis> I feared that, I thought we discussed that
[10:31] <Chipaca> yeah
[10:31] <Chipaca> I got a revision in there at some point
[10:31] <Chipaca> oh wait
[10:31] <Chipaca> pedronis: i'm using 'try', which don't do revisions there
[10:32] <alan_g> sergiusens, we thought (apparently wrongly) that the LP builders could handle "layouts", so we dropped "passthrough" for the Mir related snaps and started seeing "Issues while validating snapcraft.yaml: Additional properties are not allowed ('layout' was unexpected)". Any thoughts?
[10:32] <alan_g> Here's an example: https://launchpadlibrarian.net/429275346/buildlog_snap_ubuntu_bionic_i386_mir-test-tools-edge_BUILDING.txt.gz
[10:41] <cjwatson> alan_g: This doesn't sound like something where Launchpad has much of an opinion either way ...
[10:41] <cjwatson> alan_g: Looks like you're not using a base?  In that case you'll be using the snapcraft .deb package rather than the snap
[10:42] <cjwatson> alan_g: That probably accounts for whatever difference you're seeing
[10:43] <cjwatson> alan_g: Oh, huh, you are using a base.  How are you requesting these builds exactly?
[10:43] <cjwatson> I think you're probably using an old API method
[10:47] <alan_g> Saviq, ^ you probably know how we're starting these
[10:47] <Saviq> that's very likely
[10:48]  * Saviq waits for github
[10:49] <Saviq> cjwatson: https://github.com/MirServer/mir/blob/master/tools/process_snaps.py#L247
[10:50]  * Saviq missed the memo that there's new API
[10:52] <cjwatson> OK, so the problem with the API you're using is that it's synchronous so we can't fetch snapcraft.yaml from the source repository and inspect it to decide what to do without a serious risk of timeouts
[10:53] <cjwatson> (This was a mistake but we didn't realise it when we designed that API the first time round)
[10:54] <cjwatson> Saviq: You want https://launchpad.net/+apidoc/devel.html#snap-requestBuilds - so instead of "builds = snap_recipe.requestAutoBuilds()", use "snap_recipe.requestBuilds(archive=snap_recipe.auto_build_archive, pocket=snap_recipe.auto_build_pocket, channels=snap_recipe.auto_build_channels)"
[10:55] <cjwatson> (Or different values of archive/pocket/channels if you like, but that will preserve existing behaviour)
[10:55] <Saviq> cjwatson: ack, thank you
[10:55] <cjwatson> Note that this doesn't and can't return the list of created builds (because it's asynchronous), but you weren't using them anyway
[10:55] <Saviq> indeed
[11:30] <zyga> I collected my notes from the sprint and published them to the forum: https://forum.snapcraft.io/t/snapcraft-summit-2019-montreal-a-snapd-perspective/11905
[11:32] <zyga> Wimpress: ^  feedback welcome, I specifically made this separate from the main thread because those are things that are mainly of interest to the snapd development and design team
[11:32] <zyga> break for some water
[11:34] <zyga> mvo: ^ more less complete
[11:52] <popey> zyga: tweet out a link with a nice description and a photo of your montreal summary and I'll get it shared from snapcraftio
[11:56] <zyga> popey: sure, will do :-)
[11:57] <Wimpress> Nice write up zyga :-)
[12:00] <popey> ok, just ping us a link when done
[12:02] <pstolowski> re
[12:07] <sergiusens> zyga: nice, typo alert (Gotod)
[12:08] <zyga> sergiusens: thanks! I will fix that shortly
[12:08] <zyga> popey: https://twitter.com/zygoon/status/1141316717899071489?s=21
[12:09] <popey> haha.. that's an interesting photo!
[12:09] <Wimpress> Eye catching you might say :-)
[12:09] <zyga> Eye popping
[12:09] <Wimpress> I've replied to my post on the internal mailing list with a link to your forum post zyga
[12:10] <popey> thanks!
[12:10] <cwayne> it feels like zyga is staring into my soul
[12:10] <cwayne> and im worried he doesn't like what he sees
[12:10] <Wimpress> Well, it me stood behind him; so a fair assessment.
[12:11] <cmatsuoka> mvo: did you just resolve a comment in the slides?
[12:13] <cmatsuoka> (it disappeared in front of my eyes)
[12:41] <Pharaoh_Atem> zyga: you look like you've drank too much coffee
[12:41] <mvo> cmatsuoka: I didn't, at least not just now, just returned from lunch :)
[12:42] <cmatsuoka> mvo: hm, strange, perhaps I deleted it by mistake but undo can't bring it back so -- it was the one about the separate recovery kernel
[12:43] <cmatsuoka> mvo: I added that because we would need a separate extracted kernel for u-boot, otherwise selecting a new kernel for recovery would affect the next normal boot
[12:43] <cmatsuoka> (if it overwrites the existing extracted kernel)
[12:44] <cmatsuoka> does it make sense? otherwise I can just remove that entry from the slides
[12:46] <mvo> cmatsuoka: aha, I think I know what you mean - but please update and mention it only affects uboot at this point
[12:46] <cmatsuoka> mvo: done that already
[12:47] <mvo> ta
[14:40]  * cachio lunch
[15:01] <abeato> jdstrand, hey, I have a couple of minor MPs related to interfaces: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975
[15:07] <jdstrand> abeato: done, thanks! :)
[15:09] <abeato> jdstrand, thank you!
[15:28] <mvo> pedronis: just fyi, I'm triggering a new edge core build now (will take a little bit until all the bits are ready)


[00:00] <BhAwN> Ohh sure
[06:47] <rww> @mark #ubuntu PerfM
[06:47] <rww> (I just did a dramatic reading of it to elky. She giggled.)
[13:58] <ikonia> @login
[23:16] <k1l> hi grendal_prime