[00:01] <alex-weej> wow, the new update-manager behaviour is fucking annoying
[00:01] <alex-weej> i close it every 20 minutes it seems
[00:01] <alex-weej> i can't update because the mirrors are hosed
[00:01] <alex-weej> and they're not even critical updates
[00:07] <Ampelbein> alex-weej: update-manager just closes here for no reason after i click start upgrade, but only after downloading the required packages, as a quick test with aptitude shows...
[00:09] <Ampelbein> and i ddos'd my server by not specifying an uploade-rate limit in rtorrent. ;-)
[01:00] <alex-weej> oops
[02:54] <tofu_logic> congratulations ubuntu desktop team
[02:54] <tofu_logic> jaunty jackelope is pretty dope
[02:54] <tofu_logic> (lol)
[03:46] <costamatrix> hi everyone
[03:46] <costamatrix> anyone here can help me with a problem on ubuntu 9.04?
[03:47] <costamatrix> my control key does not work...to use with control+c control+v...etc.... but it works on compiz cube to swich workspace....
[07:06] <pitti> Good morning
[08:47] <huats> morning everyone
[08:48] <mvo> good morning huats
[08:49] <seb128> hey huats mvo
[08:49] <huats> morning seb128 and mvo
[08:51] <mvo> hey seb128
[08:52] <seb128> mvo: how are things looking on the upgrade bug reports front today?
[08:53] <mvo> seb128: medium, ~10 new or so
[08:54] <mvo> need to check how bad they are though
[09:51] <seb128> lool: where should unr bugs be assigned?
[09:59] <lool> seb128: Depends; we have various packages: netbook-launcher, maximus...
[09:59] <lool> seb128: bug #?
[10:00] <seb128> lool: bug #365795 for example
[10:00] <lool> seb128: (BTW StevenK wants to handle UNR these days)
[10:00] <lool> seb128: That's probably an ubuntu-cdimage bug, looking
[10:00] <seb128> lool: I'm just looking to the recent bugs list and reassigning things where I can
[10:00] <lool> seb128: Yup, thanks for that; I'm trying to give you the best contact for the future
[10:01] <seb128> thanks
[10:01] <seb128> bug #365846 too
[10:01] <seb128> that one is not really useful, would require debugging from somebody working on UNR
[10:01] <seb128> what is the best way to bring attention of the UNR team on a bug?
[10:02] <seb128> or let the team know "that's on UNR you should have a look"
[10:02] <lool> seb128: That's a good question
[10:02] <seb128> you don't have a component which can be used as triaging point for those?
[10:02] <lool> seb128: In theory, we set the ubuntu-unr tag on these bugs
[10:02] <lool> when reported with apport
[10:02] <seb128> or a team to subscribe
[10:03] <seb128> and you go through tagged bugs?
[10:03] <lool> Many people will also report bug against the upstream project, netbook-remix, but that's incorrect most of the time
[10:03] <lool> seb128: no we don't :-(
[10:03] <lool> seb128: I think we lack a good workflow for bugs, it has been the subject of discussions between UNR upstream and mobile team people
[10:03] <seb128> is there an ubuntu-unr team we can subscribe?
[10:04] <seb128> that would email notify the team members ;-)
[10:04] <lool> There's an upstream netbook-remix team
[10:04] <seb128> ok, seems there is no easy way to notify concerned people there
[10:05] <lool> seb128: I'm trying to think of a comparable project; in practice we differ only by a small number of packages
[10:05] <seb128> I will let the bug where they are for now and assume that people interested in UNR will go through recent bugs having UNR in the title at some point then
[10:05] <lool> seb128: I think the team idea is the best one so far
[10:06] <lool> StevenK: http://irclogs.ubuntu.com/2009/04/24/%23ubuntu-desktop.txt
[10:06] <seb128> hey StevenK
[10:06] <lool> StevenK: Some minutes are still missing there; basically seb128 has a pile of UNR bugs and he's looking for a consistent way to bring our attention to them
[10:06] <seb128> lool: using the netbook-remix upstream one?
[10:06] <lool> StevenK: One suggestion seb128 made was to use an ubuntu-unr team which he would subscribe
[10:07] <lool> seb128: I think a new one makes more sense
[10:07] <seb128> you could have a launchpad mailinglist for the team which would receive the bug emails
[10:07] <seb128> should be easy enough to subscribe or look to the list for people triaging then
[10:07] <StevenK> Mmmm
[10:07] <lool> StevenK: What do you think?  I think a new Ubuntu team makes sense; some bugs are related to cdimage stuff, others to the launcher, others to usability issues...
[10:08] <lool> We could also have an Ubuntu Netbook Remix *in Ubuntu* project
[10:08] <StevenK> Sounds great to me
[10:08] <lool> I personally think a team is a good first step; but I don't mind a project
[10:08] <lool> We also have the ubuntu-unr tag
[10:09] <seb128> ubuntu-unr doesn't email notify you though
[10:09] <lool> The problem I have with a project is that it's not clear when you close the bug, or it's going to be manual
[10:09] <seb128> you have to go pool on the list
[10:09] <lool> seb128: Ack
[10:09] <lool> I think team + tag are good
[10:09] <seb128> the project issue is that the ubuntu task still stay unassigned
[10:09] <lool> new project > sounds like bad workflow, and extra work
[10:09] <seb128> me too
[10:09] <lool> StevenK: Could you set that up?
[10:10] <seb128> yeah, just create an ubuntu-unr launchpad team with a list to get bug emails
[10:13] <StevenK> lool, seb128: Done, and requested mailing list
[10:13] <StevenK> seb128: Do you want to be a member too, or do you get enough bug mail? :-)
[10:14] <seb128> StevenK: I've enough emails thanks ;-)
[10:14] <seb128> StevenK: if you set a mailinglist for the team members will not get emails though
[10:14] <seb128> StevenK: but I don't work on UNR, I just triage recent ubuntu bugs right now so I've no reason to join the team there
[10:14] <StevenK> seb128: Indeed
[10:15] <lool> StevenK: Do we want a ML or just use membership as a mean to get emails?
[10:15] <StevenK> lool: I've requested a mailing list
[10:16] <lool> StevenK: is there a benefit to a ML?
[10:16] <lool> (just curious)
[10:16] <StevenK> lool: Then we can have people in the team who don't get bugmail
[10:16] <lool> StevenK: Just sub-ed the team to its first bug  ;)
[10:17]  * StevenK has cancelled the mailing list request
[10:17] <lool> I was fine either way really
[10:18] <StevenK> Well, the description says the team should get bug mail, so ...
[10:54] <lool> asac: 190227
[10:54] <lool> Weird, I thought ia32-libs had been updated
[11:15] <andreasn> mpt, just discovered a nice thing with the clickthrough on osd, I was in the middle of closing a dialog when thomas wood came online
[11:17] <andreasn> but in contrast to the previous popups, this didn't get in the way of my flow
[11:25] <asac> lool: its fixed. what is left never worked
[11:25] <asac> Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: verkeerde ELF-klasse: ELFCLASS64
[11:25] <asac> lool: needs a gtk fix. they dont look in the abi dir for "normal" directories
[11:26] <asac> so those never worked ... afaik
[11:26] <asac> s/"normal" directories/"normal" modules/
[11:27] <lool> Ok
[11:27] <asac> lool: problem is:
[11:27] <asac> ls /usr/lib/gtk-2.0/2.10.0/
[11:27] <asac> engines  immodule-files.d  immodules  loader-files.d  loaders  printbackends
[11:28] <asac> BUT
[11:28] <asac> ls /usr/lib/gtk-2.0/modules/
[11:28] <asac> libcanberra-gtk-module.so  libdwellmouselistener.so  libferret.so  libgail-gnome.so  libgail.so  libgnomebreakpad.so  libkeymouselistener.so
[11:29] <asac> and only the ones in 2.10.0/ dir is properly done on amd64
[11:29] <lool> Ok; I remember reading these bits in gtk a while ago, and they were completely inconsistent, depending even on the module type
[11:30] <asac> yep
[11:30] <mpt> andreasn, glad you like it
[11:30] <asac> actually i promissed fta to fix that for his chromium ia32 builds
[12:04] <lool> asac: In the mean time you can strip GTK_MODULES from the env if you have a place to do that
[12:11] <asac> lool: hmm. good idea. i will check that
[13:04] <Ampelbein> asac: hi. is there any regression known about network-manager not being able to detect usb-mobile-modems? bug 346835 should be fixed but i get those symptoms here with huawei modem, 0x12d1:0x1003
[13:24] <mnemo> mvo: update-manager is crashing on me with this error --> http://pastebin.com/m2309ad3b   and this is happening on a machine which was re-installed cleanly using the RC and now I'm trying to upgrade to the final...
[13:25] <james_w> mnemo: the "S"s are part of the error message?
[13:25] <mnemo> yes
[13:26] <mnemo> update-manager starts up fine and I get to press the "start upgrade" button
[13:28] <mnemo> strange, now I get another error from update-manager by just re-running it with exact same params
[13:28] <mnemo> http://pastebin.com/m517a3a35
[13:30]  * mvo looks
[13:31] <mvo> mnemo: could you please check "via dpkg -l or synpatic" what version of u-m you have installed ? and what version of update-manager-core ?
[13:31] <mnemo> sure
[13:32] <mnemo> 1:0.111.7
[13:32] <mnemo> i created an LP bug with this info as well --> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/366048
[13:33] <mnemo> (same for u-m-c)
[13:34] <james_w> /usr/share/pyshared/DistUpgrade/DistUpgradeApport.py:        from apport.python_hook import apport_excepthook
[13:34] <james_w> is it not apport_python_hook ?
[13:35] <mvo> mnemo: thanks, I confirmed
[13:35] <mvo> james_w: checking
[13:36] <james_w> the other appears to be
[13:36] <james_w> /usr/share/pyshared/DistUpgrade/DistUpgradeQuirks.py:        self.plugin_manager = PluginManager(self.controller, ["./plugins"])
[13:38] <asac> Ampelbein: sorry. so what do you get when running /lib/udev/nm-modem-probe --export --verbose /dev/ttyUSBX
[13:38] <asac> (X == 0,1, ...)
[13:39] <mvo> james_w: thanks
[13:39] <james_w> yay for dpkg -L | xargs grep :-)
[13:40] <mnemo> :)
[13:41] <Ampelbein> asac: http://paste.ubuntu.com/157185 -> ttyUSB0 http://paste.ubuntu.com/157186 -> ttyUSB1, ttyUSB2+3 time out.
[13:42] <Ampelbein> asac: see also bug 366051, I just opened it a minute prior to your question ;-)
[13:42] <asac> Ampelbein: can you replug your device in between please?
[13:43] <asac> Ampelbein: did it work in intrepid?
[13:43] <mnemo> mvo: let me know if you want me to make some modification and re-run to test something
[13:43] <mvo> mnemo: it should be fixed now in bzr, I prepare a update, thanks again
[13:44] <mnemo> np
[13:44] <Ampelbein> asac: don't know, just got the stick yesterday. what do you mean by replug in between? between what?
[13:44] <asac> nevermind ... let me check something
[13:45] <Ampelbein> asac: network-manager is the current jaunty version, 0.7.1~rc4.1.cf199a964-0ubuntu2
[13:46] <mnemo> james_w, mvo: its probably pretty easy to write a static analysis tool that finds all bugs in all packages of this type?
[13:46] <james_w> mnemo: there are several python static analysers
[13:46] <asac> Ampelbein: please tail syslog and replug your device and post what you get there in a few seconds
[13:46] <james_w> They should be able to catch the first, not really the second
[13:47] <mnemo> right
[13:47] <mvo> the second is more tricky indeed, I will refactor the code there to make it more robust
[13:49] <Ampelbein> asac: http://paste.ubuntu.com/157192/
[14:11] <asac> Ampelbein: udevadm info --query=all --path=/sys/class/tty/ttyUSB1 --attribute-walk
[14:13] <Ampelbein> asac: http://paste.ubuntu.com/157211/
[14:16] <seb128> pitti: should intrepid be changed to jaunty in https://wiki.ubuntu.com/Testing/EnableProposed?
[14:17] <pitti> should be more general, I'll edit it; thanks
[14:19] <seb128> pitti: thank you, can you also specify that uploads might take some hours to be available?
[14:19] <seb128> I've noticed it's a frequent user comment
[14:19] <seb128> there or in your stock reply
[14:20] <pitti> better in the stock reply, I think
[14:24] <seb128> pitti: right
[14:24] <seb128> pitti: btw did you code review the libgweather change?
[14:25] <seb128> pitti: the change is not an upstream backport but a local one so a second look is always welcome ;-)
[14:25] <pitti> I had a quick look only (too many SRUs)
[14:25] <pitti> seb128: I'll remember to give/require more intense testing
[14:26] <seb128> well, it's not especially complicated so it should be fine, let's wait for user testing
[14:26] <seb128> it works here at least
[14:26] <pitti> seb128: sru-accept.py changed accordingly
[14:26] <seb128> danke
[14:26]  * seb128 hugs pitti
[14:27]  * pitti hugs back seb128, thanks for the suggestions
[14:44] <asac> Amaranth: can you unplug; then set udev to debug and past what you get in syslog when pluggin it in?
[14:44] <asac> oops
[14:44] <asac> Ampelbein: ^^
[14:45] <asac> udevadm control --log-priority=debug
[14:52] <Ampelbein> asac: http://paste.ubuntu.com/157233/
[14:54] <asac> Ampelbein: something makes the 77-nm-modem*rules in /lib/udev/rules.d not match your device
[14:54] <asac> i have to compare to what i see i guess
[14:56] <Ampelbein> asac: how can i help you with that?
[14:57] <asac> Ampelbein: http://pastebin.com/f6631b5e6
[14:57] <asac> Ampelbein: replace /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules with that
[14:58] <asac> Ampelbein: and replug
[14:58] <mvo> seb128: does it make sense to get rid of scrollkeeper? it seems we still get segfaults from it (#365606)
[14:59] <mvo> seb128: or at least I suspect it :)
[15:00] <Ampelbein> asac: awesome. that works!
[15:01] <Ampelbein> asac: at least nm now identifies it as a modem, will connect now.
[15:01] <Ampelbein> asac: success! connection works, too.
[15:02] <asac> Ampelbein: great. so you see just one entry in applet and that works?
[15:02] <asac> can you try to replug multiple times and see if that causees issues?
[15:02] <Ampelbein> asac: yeah, only one entry in the applet.
[15:02] <asac> neat
[15:03] <asac> so we just found a previously unknown driver ;) ... that just works with a huawei modem ;)
[15:04] <Ampelbein> asac: tried replugging 3 times now, works like a charm. will reboot to see if it continues to work.
[15:04] <Ampelbein> asac: many many thanks!
[15:05] <asac> Ampelbein: can you file a bug please so i can target that for inclusion in the first SRU?
[15:06] <Ampelbein> asac: bug 366051
[15:06] <Ampelbein> asac: what information should i add to the report? the updated 77-nm-...?
[15:06] <Ampelbein> asac: or do you take care of that?
[15:07] <asac> Ampelbein: just attach the --attribute-walk for ttyUSB0 and state that modem XYZ isnt detected  in bug title
[15:07] <asac> Ampelbein: dont need to attach the 77-
[15:07] <Ampelbein> asac: ok, will do. rebooted and it still works. thanks again.
[15:07] <asac> i will push the change upstream today i guess
[15:12] <mvo> seb128: could you please reject my update-manager upload? I want to include another change as well
[15:27] <pitti> mvo: rejected
[15:27] <pitti> mvo: I won't accept it anyway, since the previous one needs to get verified and to -updates first
[15:28] <pitti> mvo: I'm fine with not waiting for 7 days, as long as the current SRU gets a good testing beating
[15:28] <mvo> pitti: ok
[15:33] <pitti> ArneGoetje: is it still planned to have a GUI to select LC_MESSAGES vs. LC_TIME, etc?
[15:34] <mvo> pitti: I asked on ubuntu-testing if they can do the verification for it, would be nice to get it in early
[15:39] <ArneGoetje> pitti: I think it would make sense, how about you?
[15:40] <pitti> ArneGoetje: I agree; I got reminded by bug 208548
[15:41] <ArneGoetje> pitti: so, I make a GUI for language-selector?
[15:41] <pitti> it's more like a "locale-selector", but it makes sense there, yes
[15:42] <ArneGoetje> pitti: should we discuss the details at UDS?
[15:43] <pitti> ArneGoetje: I thought it was already spec'ed out
[15:43] <ArneGoetje> pitti: not really
[15:44] <ArneGoetje> pitti: the details how it should work with the current locale setting mechanism needs to be fleshed out
[15:44] <pitti> ah, I see
[15:45] <pitti> ArneGoetje: if that's a project that interests you, would you please create a blueprint stub for it (or propose the existing one for karmic uds)?
[15:45] <ArneGoetje> pitti: ok
[16:27] <seb128> re
[16:27] <seb128> mvo: scrollkeeper? are we sure that's the scrollkeeper-update there crashing?
[16:27] <seb128> mvo: rarian-compat also has a scrollkeeper-update command
[16:29] <seb128> mvo: otherwise dropping scrollkeeper in karmic seems ok
[16:29] <mvo> seb128: not sure, unfortuantely it does not show what segfaulted
[16:29] <seb128> that's something we need to fix next cycle
[16:30] <seb128> quite some of those upgrade bugs are random crash without details
[17:05] <josephpiche> hi. i was wondering if someone could point me in the right direction for getting the source for the "Services" control panel--I'm looking to develop a simple UFW control panel
[17:18] <cj> in case you read the backlog, apt-get source gnome-system-tools
[17:23] <pitti> ^ which is unmaintained and pretty out of date, and thus not a good example...
[18:13] <seb128> mpt: I don't understand bug #366194
[18:13] <mpt> seb128, where do you get stuck in the steps?
[18:13] <seb128> you seem to mix gtk fileselector and nautilus
[18:13] <seb128> ie describe 2 bugs
[18:14] <seb128> is your bug "files added to the places list display errors when selected"?
[18:14] <mpt> yes
[18:14] <seb128> that being the case in gtk and nautilus?
[18:14] <mpt> No, only Nautilus
[18:14] <mpt> The filepicker is in the steps to reproduce for two reasons
[18:15] <mpt> 1. because Nautilus doesn't let you add a file to the Places pane, only the filepicker does
[18:15] <seb128> mpt: ok, please try to have clear steps and 1 bug by ticket please
[18:15] <seb128> ie we are not interested by a complex way to get the issue but the easier way you can get
[18:15] <mpt> 2. to show that it's possible for Nautilus to handle the file being there, because the filepicker handles it.
[18:16] <mpt> seb128, it is only one bug.
[18:16] <seb128> hum, no?
[18:16] <seb128> you have 5. and 6. listing issues
[18:16] <seb128> which seem different ones
[18:16] <seb128> oh
[18:16] <seb128> I understand the bug now
[18:17] <seb128> it's "nautlus should act as the fileselector does"
[18:17]  * seb128 tries
[18:17] <seb128> ok
[18:17] <seb128> so steps are
[18:17] <seb128> - add a bookmark to a file
[18:17] <mpt> seb128, I try to avoid making bug summaries assume the solution, I leave the suggested solution to the end of the report
[18:17] <seb128> - try to open this bookmark in nautilus
[18:18] <seb128> well those don't assume the solution
[18:18] <mpt> seb128, I don't see how you can add a bookmark to a file from within Nautilus
[18:18] <mpt> selecting a file and choosing "Add Bookmark" adds the enclosing folder instead!
[18:19] <seb128> right
[18:19] <seb128> so the steps are
[18:19] <seb128> - use a gtkfileselect to add a bookmark to a file
[18:19] <seb128> - try opening it in nautilus place pane
[18:19] <mpt> yep
[18:20] <seb128> gnome bug #561221
[18:20] <seb128> mpt: ^ dup from that
[18:20] <seb128> bug #298425 in launcupad
[18:20] <seb128> launchpad
[18:21] <mpt> Ah, I searched Bugzilla but didn't think to look in something called "Bookmarks"
[18:21] <mpt> Since it's called "Places" in both the filepicker and in Nautilus
[18:22] <mpt> thanks seb128
[18:22] <seb128> you're welcome
[18:22] <seb128> mpt: thanks for the user testing, some suggestion though
[18:22] <seb128> - the shorter the bug description is the better
[18:22] <seb128> we read log of bugs and we want to know what is the issue
[18:23] <seb128> the user story leading to it is not really interesting
[18:23] <seb128> - you can open upstream bugs only upstream ;-) but I guess you want to track those in launchpad too for those user testing?
[18:24] <mvo> pitti: is there a way to make the kernel output the name of the segfaulted app when it prints the "Segmentation fault" message? I want to include that in the apt terminal.log if possible
[18:24] <mpt> seb128, bah, that's like 4 lines out of 20
[18:24] <mpt> :-P
[18:24] <mvo> pitti: alternatively I'm thinking about just adding the dmesg output to a apt failure log if a exit status is 139
[18:25] <pitti> mvo: doesn't it already?
[18:25] <pitti> pr 22 10:52:23 tick kernel: [13255.188232] ekiga[16208]: segfault at 10 ip 00007f95142c79dc sp 00007f9506d4bd00 error 6 in libc-2.9.so[7f951424d000+168000]
[18:25] <mvo> pitti: right, in dmesg
[18:25] <mpt> seb128, yes, I plan to tag them all the same way :-)
[18:25] <mvo> pitti: I would like to have it in the terminal window too :)
[18:25] <seb128> mpt: it took me 2 goods minutes to understand your bug, I first trying to figure why it was about places and started by background and pattern dialog use
[18:26] <seb128> trying -> tried
[18:26] <pitti> mvo: oh, *that* message
[18:26] <mpt> ok
[18:26] <mvo> pitti: including the dmesg output is my fallback plan
[18:26] <pitti> mvo: hm, any chance you could get it from /var/log/apport.log?
[18:26] <mvo> pitti: that would mean to start apport, right?
[18:26] <pitti> (I thought you did that anyway)
[18:26] <mvo> pitti: currently for stable->stable upgrades its not running
[18:26] <pitti> mvo: however, that's only reliable if you parse every line, I gues
[18:26] <seb128> mpt: bug #298425 has a description which seems clearer to me for example
[18:26] <pitti> s
[18:26] <pitti> mvo: OIC
[18:27] <seb128> mpt: but maybe that's only me, or an user view against a bug triager one
[18:27] <pitti> mvo: I don't currently know a way to do that, I'm afraid
[18:27] <mpt> That one doesn't even use complete sentences
[18:27] <pitti> mvo: well, we could always change glibc to do that, of course :)
[18:27] <pitti> but not without such a change
[18:27]  * mpt is just whining now, ignore me
[18:27] <mvo> pitti: no problem, then I just use the dmesg idea then
[18:29] <seb128> mpt: right, I might be complaining a bit, just try to not be too specific if you can, ie if any fileselector do write that rather than describing a specific way to open one in nautilus ;-)
[18:29] <mpt> ok
[18:29] <seb128> thanks
[18:29] <seb128> otherwise thanks for the user testing and the detailed descriptions you do in bugs
[18:29] <seb128> and thanks for opening those upstream too ;-)
[18:51] <alex-weej> can we go back to the normal way of resizing windows in compiz now that it's not as slow as it used to be?
[18:51] <alex-weej> that blue outline isn't even in any theme
[18:52] <mvo> seb128: I added dmesg output to apport package logs now, that should make it possible to see what segfaulted in maintainer scripts
[18:54] <seb128> mvo: excellent
[18:54] <alex-weej> i've changed the patch in the bzr package for compiz
[18:55] <alex-weej> how do i properly get this change sponsored etc.?
[18:55] <alex-weej> do i push the branch to lp myself?
[18:56] <seb128> alex-weej: if there is a bug subscribe ubuntu-main-sponsors
[18:56] <seb128> alex-weej: having either a debdiff on the bug or your bzr with the change
[18:56] <seb128> there is a lp feature to match a bug and a bzr
[18:57] <seb128> alex-weej: are you sure that the changes are faster now? or do you just assume that because it's fast on your box?
[18:58] <alex-weej> i've not seen a recent machine where it's been slow enough to warrant going back to Windows 95 resizing
[18:58] <alex-weej> but i've not conducted a thorough test
[18:59] <alex-weej> i'll put the patch on and it can be closed "when it's ready" if people think not now
[19:01] <seb128> we tried before hardy ie one year ago
[19:02] <seb128> and on some box you could see it jumping when moving the cursor
[19:02] <seb128> I doubt that has changed, the issue is just slow video cards
[19:02] <alex-weej> seb128: jumping?
[19:03] <pitti> good night everyone
[19:03] <seb128> not being smooth
[19:03] <seb128> pitti: 'night
[19:03] <seb128> alex-weej: ie the graphic changes don't follow the mouse and catch up by jumping when they can
[19:03] <alex-weej> it's certainly not "smooth" now
[19:03] <alex-weej> but... a giant blue rectangle?
[19:03] <seb128> the blue rectangle is not smooth for you?!
[19:04] <seb128> well, it gives an indicate of the change
[19:04] <alex-weej> no it is, i just don't see the point of it. if i'm resizing a window to make e.g. a web page FIT, i have no idea when i can stop making it wider if i see a blue rectangle
[19:04] <seb128> nobody complained about that until now
[19:04] <alex-weej> if it's actually resizing live, i can see when to stop
[19:04] <seb128> "live" is the issue
[19:04] <alex-weej> it's not an issue. it's slow, but it's a hell of a lot more usable and less ugly than a blue rectangle
[19:04] <seb128> if you get the view refreshing every second it's highly annoying
[19:05] <alex-weej> it's not that slow
[19:05] <seb128> depends of the video card as said
[19:05] <seb128> on my 5 years old laptop it is
[19:05] <alex-weej> if your graphics hardware is that slow at 2D yet still good enough to run compiz
[19:05] <alex-weej> you got problems
[19:05] <seb128> it runs compiz just fine
[19:05] <alex-weej> every /second/?
[19:05] <alex-weej> are you exaggerating?
[19:06] <seb128> enough to give a jumping effect
[19:06] <seb128> I don't think the eyes are good at make the difference between 600ms and 800ms
[19:06] <seb128> it's just slow enough to not be usable
[19:06] <alex-weej> seb128: 5 years old is out of the scope of ubuntu right?
[19:06] <seb128> no
[19:07] <seb128> ubuntu is working just fine on this box
[19:07] <seb128> it's a 1.5GHz box
[19:07] <alex-weej> why must you penalise people with newer machines with worse usability?
[19:07] <seb128> ubuntu runs on a 500mhz with 512 meg of rams
[19:07] <seb128> because we have no good way to make speed estimation?
[19:07] <seb128> it's not only old machine
[19:08] <seb128> lot of people are describing intel 2.6 drivers being too slow to be used with compiz in jaunty
[19:08] <seb128> on recent hardware
[19:08] <seb128> ie alt-tab and desktop switching are fine
[19:08] <seb128> but extra effects are slooooow
[19:09] <alex-weej> the resizing issue is solely to do with 2D performance
[19:09] <seb128> we can try changing the setting value in karmic and see who complains
[19:09] <alex-weej> and CPU i guess (layout etc.)
[19:09] <seb128> expose too
[19:09] <seb128> and things people describe as slow in jaunty on intel
[19:10] <seb128> ideally we would have a video speed estimation by some way
[19:10] <seb128> and use that to know what to enable
[19:10] <alex-weej> i noticed expose was quite sluggish like 10fps on a fairly recent (~2 years) intel gma
[19:10] <seb128> as said we can try enabling the dynamic content refresh again in karmic
[19:11] <seb128> and see how it goes
[19:11] <seb128> anyway I've to run for now, diner time, bbl
[19:11] <alex-weej> cya
[19:11] <pedro_> is anybody aware of bug 361560 ? seems it's affecting a good quantity of users
[19:12] <james_w> pedro_: chriscoulson was looking at it the other day
[19:13] <pedro_> james_w: ah good to know i was about to ask him or to didrocks since they're touching the package now
[19:14] <james_w> pedro_: yeah, not sure where he got to, but he had a theory of the cause, and is in communication with upstream
[19:15] <pedro_> james_w: awesome, looks worth it for an SRU, let's approve the nomination on the meantime, that's james_w
[19:19] <pedro_> s/that's/thanks ;-)
[19:19] <pedro_> dammit keyboard
[19:37] <pmatulis> how does one report a boot degradation after upgrading to jaunty?  apply toward what package in Launchpad?
[19:59] <james_w> pmatulis: you mean a boot speed degradation?
[20:00] <pmatulis> james_w: yeah, btw, i believe i just apply it towards 'ubuntu' and add a tag somewhere called 'boot-performance'
[20:00] <james_w> that could work
[20:00] <james_w> have you generated a bootchart?
[20:01] <pmatulis> no, but the delay is right after grub: "boot from hd(0,0) .. UUID"
[20:01] <pmatulis> it sits there for about 12 seconds
[20:03] <james_w> ah
[20:03] <james_w> that's more specific
[20:04] <james_w> I'm not sure what component it would be there, but it's probably while searching for the root filesystem
[20:05] <james_w> pmatulis: you don't happen to have a Intel D945 motherboard do you?
[20:06] <james_w> also, a dmesg from the booted system would be good to attach
[20:11] <pmatulis> james_w: it has the intel GM965 chipset, yes, of course dmesg
[20:11] <james_w> I ask because of bug 290153 from the release notes
[21:38] <vix> is it true that every /boot partition must reside on a primary partition?
[21:41] <vix> ?
[23:17] <chrisccoulson> hey didrocks
[23:19] <chrisccoulson> i notice you worked on the gnome-session update (2.26.1). that version actually closes a few bugs on LP
[23:19] <chrisccoulson> gnome-session -> gnome-terminal


[03:39] <mup> PR snapd#8429 opened: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
[05:40] <mborzecki> morning
[06:20] <mborzecki> mvo: hey
[06:21] <zyga> Hey
[06:21] <zyga> Please merge my last PR into master and merge master into your branches.
[06:21] <mborzecki> zyga: hey
[06:22] <jamesh> zyga: here's a simple one porting another job off Travis: https://github.com/snapcore/snapd/pull/8429
[06:22] <mup> PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
[06:22] <mborzecki> zyga: which one is that? this one https://github.com/snapcore/snapd/pull/8428
[06:22] <mup> PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428>
[06:22] <mborzecki> jamesh: thanks!
[06:23] <jamesh> zyga: also, I'm not convinced that the use of actions/cache@v1 for the apt cache actually works
[06:23] <jamesh> (the way it is written, I don't think it will ever get a cache hit)
[06:23] <zyga> That one
[06:24] <zyga> jamesh: I noticed
[06:24] <zyga> Something is off
[06:24] <zyga> Do you know what the issue is?
[06:24] <mvo> hey mborzecki, good morning
[06:25] <mborzecki> jamesh: quick question about gtk2, we have gtk2-common-themes snap, but one would still need the right theme engine to render those, isn't that right?
[06:26] <mborzecki> jamesh: asking in the context of https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 which looks like the snap plugs gtk2-common-themes, but when starting there's a log about missing pixbuf engine to render the adwaita-like theme with gtk2
[06:28] <jamesh> zyga: ah.  you're doing the chown on /var/cache/apt after calling actions/cache, so the action does not have permission to write to that location
[06:29] <zyga> Mmmmm
[06:30] <zyga> So we need two chowns
[06:30] <jamesh> zyga: It's not obvious that it is a good use of caching anyway: the cache key you're using doesn't specify exact revisions of packages, so each user could be testing against a different set of packages
[06:30] <zyga> Or update the action to a version that fixed this and uses sudo
[06:30] <zyga> We rarely rev our dependencies
[06:31] <jamesh> mborzecki: gtk2-common-themes only contains theme engines.  We left the actual theme data files in gtk-common-themes, since most GTK 2 themes are distributed beside their GTK 3 counterpart these days
[06:31] <zyga> So it is not a perfect set but a sufficient set
[06:31] <mborzecki> jamesh: so gtk2-common-themes is effectively dead?
[06:32] <jamesh> mborzecki: no.  You need theme data files plus any engines the theme uses
[06:32] <jamesh> mborzecki: this is also a split between platform independent data files (gtk-common-themes), and platform dependent engines (gtk2-common-themes)
[06:33] <jamesh> maybe we should have named the second package gtk2-common-engines
[06:39] <jamesh> zyga: It might also be a good idea to combine some of the spread tests back into fewer jobs: it's nice not having mingled output, but we're obviously hitting Github's runner limits now
[06:40] <zyga> jamesh: I will surely consider that but over weekend we also hit limits on our account in GCE
[06:40] <zyga> now that we actually run spread when we push stuff
[06:40] <zyga> we run out of capacity quickly
[06:40] <zyga> we need to measure and count and decide
[06:41] <mborzecki> jamesh: hmm so the gtk2-common-themes engines part content is connected, the snap sets GTK_PATH in meta/snap.yaml, but once the process runs GTK_PATH is set to a different path :/ looks like it's coming from desktop-launch
[06:45]  * zyga breakfast
[06:48] <mborzecki> jamesh: looks like GTK_PATH ends up without the location where the engines from gtk2-common-themes snap are, i added a note under https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3
[06:56] <mvo> zyga: when you have a moment, a look/merge of https://salsa.debian.org/debian/snapd/-/merge_requests/5 would be great
[06:58] <mborzecki> ehh 1080p is such a downgrade from 4k
[06:58] <zyga> o/
[06:58] <zyga> at my desk
[06:58] <zyga> mvo: looking
[06:59] <zyga> mborzecki: display change?
[06:59] <pstolowski> morning
[06:59] <mborzecki> zyga: yeah, had to rma the 4k one, so i'm using my old 1080p display now
[07:00] <mvo> zyga: not ugent but it will bring the packaging git trees in sync again
[07:00] <mborzecki> pstolowski: hey
[07:00] <zyga> ta
[07:00] <zyga> good morning pawel
[07:00] <mborzecki> zyga: which is ironic, since it's also lg, 10+ years and not a single bad pixel
[07:00] <zyga> hmm, salsa doesn't load for me, feels like none of the JS bits are getting loaded
[07:03] <zyga> mvo: commits 8482? is this bundled with development history?
[07:04] <zyga> (this explains why js is slow to load)
[07:05] <mvo> zyga: yes, I think that's how we setup our branch
[07:05] <mvo> zyga: it contains all the history
[07:05] <zyga> ta
[07:06] <mvo> zyga: TBH i have no idea why this style is popular, I think it's kinda useless
[07:07] <zyga> maybe easier for cherry picking patches
[07:07] <zyga> libzt uses separate history
[07:07] <zyga> anyway
[07:07] <zyga> approved
[07:07] <mup> PR snapd#8430 opened: packaging: use debian/not-installed to ignore snap-preseed <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8430>
[07:08] <zyga> mvo: I see you have two more extra PRs there
[07:08] <zyga> but I guess they are obsolete now
[07:09] <zyga> mvo: closed both, please shout at me if I was meant to land them instead
[07:10] <mvo> zyga: probably fine, I forgot those
[07:10] <mvo> zyga: that was when we were not directly involved I think
[07:10] <zyga> aha
[07:10] <zyga> looking at 8430
[07:10] <zyga> do you know what's broken in our sid tests?
[07:11] <zyga> mvo: can you review and land https://github.com/snapcore/snapd/pull/8428 please
[07:11] <mup> PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428>
[07:11] <zyga> it will prevent random failures on centos 7
[07:11] <zyga> looking at this branch I also wonder if we should do a pass and review the timers and background services in our images
[07:11] <zyga> who knows what else is randomly running
[07:12] <mvo> zyga: yeah, I have a look soon, just need to finish my current task
[07:12] <zyga> thanks
[07:13] <mvo> zyga: is there anything like "skip-spread" in the new gh-actions world? just an idle thought
[07:13] <zyga> mvo: not yet, we can certainly code it
[07:13] <zyga> actions has enough logic for it
[07:14] <zyga> https://github.community/t5/GitHub-Actions/Labeled-action-on-pull-request/m-p/37839#M3093 has some ideas
[07:14] <zyga> we can just get the context as a json object, select the labels and skip the whole spread part if a particular one is set
[07:14] <zyga> mvo: if it's not urgent I'll do it in the evening
[07:15] <zyga> actually
[07:15] <mvo> zyga: nice, not urgent at all
[07:15] <zyga> https://stackoverflow.com/questions/59588605/how-to-check-for-a-label-in-a-github-action-condition
[07:15] <zyga> is even easier
[07:15] <zyga> if: contains( github.event.pull_request.labels.*.name, 'My Label')
[07:15] <zyga> we could just do
[07:15] <zyga> if: !contains( github.event.pull_request.labels.*.name, 'Skip Spread')
[07:16] <mup> PR snapd#8428 closed: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8428>
[07:16] <zyga> thanks for that mvo ^ !
[07:17] <zyga> pstolowski, jamesh, mborzecki, mvo: gentle reminder to merge master into any branches you push or iterate on
[07:17] <zyga> mainly to get the fail-fast: false part
[07:17] <pstolowski> ack
[07:17] <zyga> I will share details at the standup
[07:22] <pedronis> mvo: pstolowski: hi,  I would appreciate reviews for https://github.com/snapcore/snapd/pull/8427  it's huge but is splitting files up basically, except for reorganizing things such that we can have mutiple store* test suites
[07:22] <mup> PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427>
[07:23] <zyga> over weekend I noticed the ubuntu archive was failing again, I reported this to IS but they asked for more details. If this happens frequently we should cook a patch that prints the IP address of the node in case "apt-get *" fails
[07:23] <pstolowski> pedronis: sure, will do
[07:38] <mvo> pedronis: ok, thanks, I have a look. so this is no code change, just reorg?
[07:38] <pedronis> mvo: yes
[07:40] <pedronis> mvo: description and commit summary should hopefully be understandable
[07:40] <mvo> ta
[07:42] <mborzecki> mvo: can you take another look at https://github.com/snapcore/snapd/pull/8415 ?
[07:42] <mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
[07:43] <mvo> mborzecki: sure thing!
[07:43] <mborzecki> mvo: thanks!
[07:48] <mborzecki> hehe firefox chokes on the full diff in #8427
[07:48] <mup> PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427>
[07:51] <zyga> brb
[07:55] <mvo> fwiw, I updated the branch protection rules for master so that all stable gh actions need to be successful
[08:31] <jamesh> The GH Actions workflow should probably also be updated to run on pushes to master and release branches.  At present, only the unit tests are being run for pushes to master
[08:48] <zyga> re
[08:48] <zyga> jamesh: we had something similar but I agree, we wanted not to test a push and a PR at the same time
[08:48] <zyga> jamesh: but I think we should do tests on PRs for both master and release branches
[08:53] <mup> PR snapd#8431 opened: github: give jobs shorter names <Created by zyga> <https://github.com/snapcore/snapd/pull/8431>
[09:04] <mup> PR snapd#8427 closed: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8427>
[09:08] <pedronis> mvo: mborzecki: thanks
[09:14] <mup> PR snapd#8218 closed: [RFC] cmd/snapd, daemon/snapd: use multi call binary <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8218>
[09:16] <mup> Bug #1871058 opened: Tell how many bytes "install" will take <Snappy:New> <https://launchpad.net/bugs/1871058>
[09:19] <mup> Bug #1871060 opened: Don't hide each step after it completes <Snappy:New> <https://launchpad.net/bugs/1871060>
[09:28] <mup> PR snapd#8432 opened: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432>
[09:32] <pedronis> #8411 needs 2nd reviews
[09:32] <mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
[09:33] <zyga> jamesh: https://github.com/snapcore/snapd/pull/8429#issuecomment-609683448
[09:33] <mup> PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
[09:34] <zyga> mvo: https://github.com/snapcore/snapd/pull/8432#pullrequestreview-388082166
[09:34] <mup> PR #8432: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432>
[09:36] <mborzecki> hmm seems like ijohnson's standup notes were cut short or he didn't manage to publish the snapd branch of grub.cfg on friday
[09:38] <mvo> zyga: thanks, replied
[09:39] <zyga> mvo: I replied twice there, weird stuff
[09:42] <zyga> I think we are leaking session from tests/main/snap-session-agent-service-control
[09:43] <zyga> they break tests/main/snap-confine-undesired-mode-group
[09:47] <mborzecki> pedronis: mvo: looking into adding 'recover' and 'run' modes into system actions, and actually i'm wondering a bit about run, it doesn't make sense to have run for other system than current, does it?
[09:49] <pedronis> mborzecki: no, it's only for current
[09:50] <pedronis> we discussed that in Frankfurt
[09:50] <mborzecki> pedronis: ok, let me check the notes
[09:50] <mvo> mborzecki: +1 - nly relevent for current
[10:05] <mborzecki> mvo: pedronis: doesn't look like we put that down in the notes, nevertheless i take that recover applies to the current system only too
[10:11] <jamesh> zyga: that seems like a good idea, especially since we can't use the job as a prereq for jobs that should run on pushes
[10:11] <zyga> +1
[10:12] <jamesh> zyga: the macos test should be fairly easy to move over  to GH Actions too.  At that point, the main thing the Travis job is doing is coverage
[10:12] <zyga> yeah
[10:13] <zyga> the test coverage provider we use has a dedicated action IIRC - we could adopt it
[10:19] <jamesh> and codecov's first party action also downloads and executes a shell script...
[10:19] <zyga> of course it does :)
[10:26] <zyga> brb
[10:55] <zyga> re
[11:17] <mborzecki> zyga: hm that centos7 session-tool restore is still failing
[11:17] <mborzecki> and travis is green fwiw
[11:18] <zyga> mborzecki: same was as you showed me?
[11:18] <mborzecki> yeah
[11:18] <zyga> session that was running before the test closes during the test
[11:18] <zyga> ok, I'll switch gears to that in a moment
[11:18] <zyga> ta
[11:18] <mborzecki> tbh making gh actions spread jobs as require feels a bit premature
[11:19] <zyga> why?
[11:19] <zyga> note that travis doesn't run spread anymore
[11:20] <mborzecki> zyga: bc we cannot restart just one job
[11:20] <zyga> I see
[11:20] <zyga> I disagree but I wanted to understand
[11:20] <zyga> note that we can collapse all spread runs into one big run
[11:20] <zyga> and have that instea
[11:20] <zyga> *instead
[11:23] <mborzecki> zyga: that'd make it the same as it is now
[11:24] <zyga> we've traded ability to restart half the workers for being able to get tests started faster
[11:24] <zyga> (and having control over how many workers we can run)
[11:25] <morphis> mvo: hey! do you guys saw issues with a not existing /run/snapd-snap.socket on configure hook execution recently? Running quite frequently into https://paste.ubuntu.com/p/qQGSQjRjM7/ with snapd 2.44.1
[11:27] <morphis> to be precise, snapd isn't restart and was active all time.
[11:27] <zyga> morphis: what is the status of the socket?
[11:27] <zyga> I suspect it's in CI but perhaps you know
[11:28] <morphis> I have a shell active so happy to debug
[11:28] <zyga> please start with systemctl status snapd.socket
[11:28] <morphis> zyga: socket is active and happy for >1h
[11:28] <zyga> morphis: both?
[11:29] <zyga>      Listen: /run/snapd.socket (Stream)
[11:29] <zyga>              /run/snapd-snap.socket (Stream)
[11:29] <zyga> ^ that's what I get on my box
[11:29] <morphis> https://paste.ubuntu.com/p/phZ4H7SGXb/
[11:29] <morphis> jepp, same here
[11:29] <zyga> ok
[11:29] <zyga> and is /run/snapd-snap.socket really there on disk?
[11:29] <morphis> yes, touched an hour ago
[11:29] <zyga> ok
[11:29] <zyga> can you jump into the mount namespace of lxd
[11:29] <zyga> and then check if the socket is there
[11:30] <zyga> sudo nsenter -m/run/snapd/ns/lxd.mnt
[11:30] <zyga> this will give you a shell in the mount namespace of lxd
[11:30] <zyga> just check if the sockets are there as well
[11:31] <morphis> yes, exists there too
[11:31] <zyga> can you CURL to it?
[11:31] <zyga> or maybe instead
[11:31] <zyga> can you snapctl to it?
[11:33] <morphis> ah, I think I know what happens here
[11:34] <morphis> it's a race between `snap install lxd` and `snap set ..`
[11:34] <morphis> something we should prevent from the charm side
[11:35] <morphis> that matches with the dates the socket within the lxd ns is created and the snap got installed and the last time the error occurred in the juju output
[11:37] <zyga> morphis: cool
[11:37] <zyga> morphis: are you saying lxd doesn't really work after snap install lxd
[11:37] <zyga> in the sense that snap set is invoked too early?
[11:37] <mup> PR snapd#8433 opened: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433>
[11:38] <morphis> it looks like we invoke `snap set` while performing `snap install`
[11:38] <zyga> as in during?
[11:38] <zyga> yeah that would not work
[11:38] <morphis> jepp
[11:38] <morphis> makes sense that it doesn't work
[11:40] <morphis> zyga: is there a simple `snap wait-until-install lxd` thing?
[11:40] <zyga> I don't think there is
[11:41] <morphis> ok
[11:42] <ogra> well, the configure hook runs after install
[11:42] <ogra> perhaps move your stuff over to it ?
[11:42] <mborzecki> morphis: hmm snap watch --last=install? could work
[11:42] <morphis> mborzecki: interesting
[11:44] <mborzecki> morphis: though it's still racy, since you'd expect the install to be started already to watch it
[11:44] <zyga> morphis: may I ask how do you run the two operations concurrenctly?
[11:48] <morphis> zyga: it's a problem in our charms I can fix on that level, was just looking for a hotfix
[11:48] <zyga> I see
[11:48] <zyga> ok
[11:54] <zyga> mborzecki: testing a fix for what you found now
[11:54] <mborzecki> zyga: cool thanks
[11:55] <zyga> cachio: hey
[11:55] <zyga> cachio: are you around?
[11:55] <cachio> zyga, yes
[11:55] <cachio> hi
[11:55] <zyga> hey
[11:57] <ijohnson> hey mborzecki sorry I didn't finish putting the snapd branch for grub.cfg things in the SU doc
[11:57] <ijohnson> I just put it in there if you wanted to take a look, it's quite simple
[12:05] <mborzecki> ijohnson: no biggie, i worked on adding the recovery/run modes to devicemgr
[12:08] <mup> PR snapd#8431 closed: github: give jobs shorter names <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8431>
[12:10]  * zyga breaks for a moment,
[12:11] <zyga> mborzecki: I've started reviewing 8433
[12:15] <mborzecki> zyga: thanks
[12:16] <ijohnson> hi pedronis did you have a chance to look at how I organized things in #8424 at all ?
[12:16] <mup> PR #8424: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8424>
[12:17] <mup> PR snapd#8434 opened: systemd: move the doc comments to the interface so their are visible <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8434>
[12:17] <pedronis> pstolowski_: ^
[12:20] <pedronis> ijohnson: I skimmed it, I didn't see anything unreasonable... but there's some comments about details from others
[12:21] <ijohnson> pedronis: ok, sure I will continue on with it
[12:21] <ijohnson> pedronis: I just didn't know if you would have opinions on having stuff in the boot package vs in the partition package of snap-bootstrap, etc.
[12:21] <ijohnson> pedronis: I assume you will have opinions on the names of things and that's fine to rename later :-)
[12:28]  * zyga breaks for lunch, see you soon
[12:29] <mup> PR snapcraft#3013 closed: plugins: use v1 import path for all plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3013>
[12:38] <mup> PR snapcraft#3014 opened: meta: migrate get_build_base to Snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3014>
[12:50] <ijohnson> hey ogra, is your zoom-client snap supposed to work with nvidia drivers? I tried it with 440 drivers on Sunday and it crashed on me
[12:51] <mup> PR snapd#8430 closed: packaging: use debian/not-installed to ignore snap-preseed <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8430>
[12:51] <mup> PR snapd#8432 closed: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8432>
[13:34] <ogra> ijohnson, works gret with everything but nvidia-440
[13:34] <ogra> *great even
[13:35] <ogra> ijohnson, https://github.com/ogra1/zoom-snap/issues/2
[13:36] <diddledan> is this an issue with the 440 drivers in general with snaps?
[13:37] <ogra> due to the awful nature of the zoom binary (forcefully setting LD_LIBRARY_PATH to ./zoom (and ./zoom only) on app startup) i actually need to LD_PRELOAD the drivers ... and -440 somehow refuses to load libOpenGL.so for no apparent reason
[13:37] <ogra> diddledan, there used to be one but zyga has fixed that ... i asked people to try snapd from edge but that didnt help
[13:37] <ijohnson> ogra: ack I can try with 390 or 435 then instead
[13:37] <ogra> -400 has a new directory structure and seemingly the linkage between the libs is differet
[13:38] <ogra> err
[13:38] <ogra> -440 indeed
[13:39] <diddledan> aah, yeah, I see that message now on https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/15 - I must have overlooked it
[13:39] <ogra> right ... but that is supposed to be fixed
[13:39] <diddledan> gotcha :-)
[13:39]  * diddledan goes snooping to see what the fix was
[13:39] <ogra> and according to the logs users actually have the proper content in /var/lib/snapd/lib/gl ...
[13:40] <ogra> so it is something with the LD_PRELOAD load order that i need to research to get t going (but for that i need a system that runs -440 ... my nvidia equipped desktop is still on 16.04 for which that driver doesnt exist)
[13:41] <diddledan> I just took my nvidia card out to move it into my plex server
[13:41] <diddledan> I now have reasonable transcoding on the fly for plex though, so WINNING
[13:42] <ogra> but you cant use zoom-client on it !
[13:42] <ogra> :D
[13:42] <diddledan> I had to install the deb variant of plex though. something in the snap config is unable to do hardware transcoding
[13:43] <zyga> mvo: so I guess this means you approve of my incoming valve index :D
[13:43] <zyga> and on the upside - everyone can then test on their nvidia GPUs
[13:43] <mvo> zyga: haha
[13:43] <zyga> man, we will catch all the bugs this way
[13:43] <ijohnson> the quality of nvidia support will skyrocket after this happens
[13:43] <zyga> snapd: add half life alyx support
[13:43] <zyga> snapd: fix level 3, achievement #42
[13:44] <diddledan> I vote for leaving a few gotchas to keep the users on their toes
[13:44] <zyga> snapd: fix 2nd playthrough ...
[13:44] <zyga> ;-)
[13:44] <mup> PR #42: rework filelock to make it less surprising wrt flock(2) semantics <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/42>
[13:53] <mup> PR core20#35 opened: run-snapd-from-snap: log first snap watch better <Created by xnox> <https://github.com/snapcore/core20/pull/35>
[13:55] <mup> Issue core20#36 opened: SSH login shell says the system was minimized and to run "unminimize", but should not <Created by anonymouse64> <https://github.com/snapcore/core20/issue/36>
[13:56] <mup> PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
[14:00] <kenvandine> jdstrand: where's the trello card for the appstream-metadata inteface fixes?  I want to link it to mine card, but must be looking at the wrong board
[14:24] <mup> Issue pc-amd64-gadget#41 opened: Hide the menu by default <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/issue/41>
[14:30] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8433#pullrequestreview-388194361
[14:30] <mup> PR #8433: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433>
[14:39] <zyga> mvo: I wonder if we should add some of my hosted workers to the pool
[14:39] <zyga> to spread the load
[14:40] <ogra> spread the spread ?
[14:40] <zyga> exactly
[14:50] <jdstrand> kenvandine: hey, I privmsg'd you
[14:57] <zyga> jdstrand: hello :)
[14:57] <zyga> jdstrand: thank you for the review from Friday
[14:57] <jdstrand> sure, I need to finish and followup
[14:57] <zyga> jdstrand: the tracking PR will be ready soon, there's a core20 issue still, where some packages related to dbus are missing, but it should be ready soon
[14:57] <jdstrand> and hi
[14:57] <jdstrand> ok
[14:57] <zyga> jdstrand: not end of the story but looking like something we could look at merging soon
[14:58] <zyga> jdstrand: I'll spend some more time on your feedback tomorrow, today I'm trying to wrap up that core20 problem first
[14:59] <jdstrand> great! :)
[15:02]  * cachio lunch
[15:06] <mup> PR snapd#8435 opened: configcore,tests: fix setting watchdog options on UC18/20 <Created by pedronis> <https://github.com/snapcore/snapd/pull/8435>
[15:13] <jdstrand> mvo: hey, so it sounds like you will roll another 2.44 point release for some policy updates?
[15:14] <mvo> jdstrand: if it's just safe policy updates I can do that
[15:14] <mvo> jdstrand: at this point I want to keep the risk minimal
[15:14] <jdstrand> mvo: is later today ok?
[15:14] <mvo> jdstrand: yeah
[15:15] <jdstrand> ok, I'll do a couple low risk PRs then
[15:15] <jdstrand> I'll target 2.44, 2.45 and master
[15:15] <mvo> jdstrand: or in my morning tomorrow
[15:15] <mvo> jdstrand: ok
[15:15] <mvo> jdstrand: 2.44 and master is fine, 2.45 is not branched yet
[15:22] <jdstrand> mvo: ah, ok, thanks
[15:35]  * zyga runs an errand in the office
[15:36] <roadmr> running in place, zyga? 🤔
[15:36] <zyga> roadmr: mainly cleaning and that one box that's open because a cable went loose and I need to solder the power switch back on
[15:37] <diddledan> just rebooted.. getting: `cannot change profile for the next exec call: No such file or directory \n  snap-update-ns failed with code 1: File exists` from running _any_ snaps
[15:38] <zyga> diddledan: I think we debugged that recently
[15:38] <zyga> diddledan: can you please collect your journal and pastebin it
[15:38] <zyga> diddledan: to fix your machine restart apparmor.service
[15:38] <zyga> diddledan: it's *not* fixed though
[15:38] <zyga> popey: ^ can you recall if you reported that on launchpad?
[15:43] <diddledan> is this enough journal, or more needed? https://paste.ubuntu.com/p/RBc2r4xqJY/
[15:44] <mup> PR snapd#8436 opened: configcore,tests: use daemon-reexec to apply watchdog config <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
[15:44] <diddledan> this is everything for this boot: https://paste.ubuntu.com/p/Jyx6gfFc3q/
[15:45] <zyga> diddledan: looking
[15:46] <zyga> diddledan: when you said "just rebooted", roughly what time was there for you?
[15:46] <zyga> is that the start of your log?
[15:46] <diddledan> I used journalctl --no-pager -b | pastebinit
[15:46] <zyga> ok, so 16:32~~
[15:47] <diddledan> yup
[15:47] <mborzecki> /quit/quit
[15:47] <zyga> so I see
[15:47] <zyga> Apr 06 16:32:58 defiant lxd.activate[3329]: cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Iq23MU//dev: No such file or directory
[15:47] <zyga> 16:32:58 - we use snaps already
[15:47] <zyga> and then Apr 06 16:35:02 defiant audit[12031]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.lxd.daemon" pid=12031 comm="apparmor_parser"
[15:48] <zyga> at 16:35 we load the releated profile
[15:48] <zyga> FYI: stgraber ^ (lxd runs before apparmor profiles of snapd are loaded)
[15:48] <zyga> diddledan: please report a bug "services start before apparmor profiles are loaded"
[15:48] <zyga> we have a race
[15:48] <diddledan> ok
[15:48] <zyga> include this journal if you don't mind, please highligh the two lines I mentioned above
[15:48] <zyga> popey: ^ if you reported a bug this this is a dupe, if not please track the one diddledan will open
[15:48] <zyga> mvo: ^ FYI
[15:49] <zyga> mvo: system startup races startup of services and apparmor.service loading profiles
[15:49] <zyga> mvo: observed for LXD here and for a lot of snaps (half of stuff IIRC) on popey's laptop
[15:49] <zyga> FYI: ^ jdstrand
[15:49] <zyga> though not a security issue, more a "it doesn't work" issue
[15:51] <zyga> diddledan: can you confirm that restarting apparmor.service fixed the issue?
[15:53] <diddledan> yes, restarting apprmor fixes it - I've put that info in the bug: #1871148
[15:53] <mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:New> <https://launchpad.net/bugs/1871148>
[15:53] <zyga> thank you
[16:04] <pedronis> #8390 and #8411 need 2nd reviews
[16:05] <mup> PR #8390: state: add state.CopyState() helper <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
[16:05] <mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
[16:10] <stgraber> zyga: oh, interesting, good that it's not something I have to fix for once ;)
[16:11] <zyga> stgraber: yeah, in case someone comes along and says this is broken on their fast server, it's on ous
[16:11] <zyga> *us
[16:16] <diddledan> #blamepopey
[16:18]  * zyga hugs popey
[16:18] <popey> sorry, been in meetings
[16:19]  * popey confirmificates the bug
[16:20]  * diddledan watching terminiser black inevitibility
[16:26] <mup> PR core20#35 closed: run-snapd-from-snap: log first snap watch better <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/pull/35>
[16:28] <mup> PR snapd#8437 opened: tests/session-tool: collect information about services on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/8437>
[16:29] <mup> PR snapd#8438 opened: tests/session-tool: stop anacron.service in prepare <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8438>
[16:31] <mvo> zyga: uh, is this a new thing?
[16:32] <zyga> mvo: no
[16:32] <jdstrand> mvo, zyga: https://bugs.launchpad.net/snapd/+bug/1871148/comments/6
[16:32] <mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
[16:32] <zyga> jdstrand: isn't that the message that is printed from /etc/apparmor.d
[16:32] <zyga> there's a separate one for /var/...
[16:32] <zyga> IIRC
[16:32]  * zyga checks
[16:33] <jdstrand> zyga: what are you talking about?
[16:33] <mvo> zyga: if it's not new I wonder why it's happening now?
[16:33] <jdstrand> zyga: 'Finished loading...'?
[16:33] <mvo> jdstrand: should we have an "After=apparmor" in all our snaps?
[16:33] <zyga> please forgive me for being unclear, let me check and show
[16:33] <jdstrand> mvo: please see my comment
[16:34] <jdstrand> mvo: apparmor was already finished. something else seems to be going on
[16:34] <mvo> oh, ok
[16:35] <ijohnson> mvo will there be a 2.44.3 ?
[16:35] <mvo> zyga: it can't be snapd rebuilding the profiles, right? we stop/disable services before we do that iirc
[16:35] <ijohnson> $CUSTOMER would like https://github.com/snapcore/snapd/pull/8426 asap, but not like super asap
[16:35] <mup> PR #8426: interfaces/docker-support: add overlayfs file access <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8426>
[16:35] <mvo> ijohnson: yes, jdstrand needs some interface updates
[16:35] <zyga> mvo: this is during system boot
[16:35] <ijohnson> mvo: ack cool this is just an interface update too
[16:36] <mvo> ijohnson: yeah
[16:36] <ijohnson> thanks mvo!
[16:36] <jdstrand> oh, that was in my list for today. thanks :)
[16:37] <jdstrand> ijohnson: note, for the other policy updates, mvo asked me to target 2.44 too. can you do the same?
[16:37] <ijohnson> jdstrand: mvo already milestonned 8426 to 2.44
[16:37] <ijohnson> jdstrand: or did you mean to open a release/2.44 PR for 8426 ?
[16:38] <jdstrand> ijohnson: the latter
[16:38]  * ijohnson didn't open a 2.44 PR, but can if desired
[16:38] <ijohnson> ok, I will open a 2.44 PR then
[16:38] <mvo> ijohnson: if it's just a cherry pick I can do that, no need for a PR then
[16:38] <ijohnson> zyga: we have to restart all github actions jobs, right? we can't just restart one ?
[16:38] <zyga> correct
[16:38] <ijohnson> mvo: ok I think a cherry pick should be fine it's literally 1 line change
[16:39] <ijohnson> ok, thanks zyga
[16:39] <mvo> ijohnson: ta, just let me know when i landed and I cherry pick (or feel free to just cherry-pick yourself)
[16:39] <mvo> ijohnson: 8426?
[16:39] <mvo> ijohnson: I think that is green, I can merge now
[16:39] <ijohnson> mvo: oh
[16:40] <ijohnson> mvo: it wasn't green there was a spread failure for nfs-support, which is unrelated
[16:40] <mvo> ijohnson: yeah, I will merge anyway
[16:40] <ijohnson> mvo: I just restarted them, but I suppose you could use your magic powers to merge anyways
[16:40] <mvo> ijohnson: sorry, I meant "green" as in "green-enough"
[16:40] <ijohnson> :-D
[16:40] <zyga> diddledan: can you ls -ld /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop
[16:41] <mvo> ijohnson: and merged and cherry-picked, thank you!
[16:41] <ijohnson> thanks mvo!
[16:41] <mup> PR snapd#8426 closed: interfaces/docker-support: add overlayfs file access <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8426>
[16:41] <diddledan> zyga: -rw-r--r-- 1 root root 53984 Apr  5 19:53 /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop
[16:41] <zyga> april 5 19:53
[16:41] <zyga> thanks
[16:42] <zyga> diddledan: do you have /var/lib/snapd mounted on external disk?
[16:42] <zyga> or something of this kind
[16:42] <diddledan> nopep
[16:42] <zyga> k
[16:43] <diddledan> it's on a fairly normal setup except 20.04.. I do have root-on-zfs as installed by ubiquity's new feature
[16:43] <jdstrand> diddledan: what is the ls -l output for /var/lib/snapd/apparmor/profiles/snap.multipass.*
[16:43] <jdstrand> popey: do you have root on zfs?
[16:43] <zyga> diddledan: you you remember when you ran the command that restarted apparmor.service?
[16:43] <popey> i do
[16:43] <diddledan> https://paste.ubuntu.com/p/cJ8bxBjRjq/
[16:43] <diddledan> zyga, not precisely, no
[16:44]  * ijohnson remembers zyga asked us to setup tests to use zfs when 19.10 was released
[16:44] <zyga> indeed
[16:44] <zyga> popey: are you using zfs on your machine that exhibited this problem?
[16:45] <popey> yes
[16:45] <zyga> (restarting apparmor.service)
[16:45] <zyga> aha
[16:45] <zyga> I feel a trend
[16:45] <diddledan> rpool/ROOT/ubuntu_t60y5t/var/snap on /var/snap type zfs (rw,relatime,xattr,posixacl)
[16:45] <zyga> diddledan: can  you provide your /etc/fstab
[16:45] <diddledan>  /var/snap is a separate mount from the zfs
[16:45] <diddledan> https://paste.ubuntu.com/p/Z7TJpV5TmT/
[16:46] <jdstrand> diddledan: /var/snap is a separate thing
[16:46] <jdstrand> diddledan: /var/lib/snapd is the thing
[16:46] <diddledan> oops, sorry, misread
[16:46] <jdstrand> diddledan: can you attach to the bug: sudo systemd-analyze plot > ./1871148.svg
[16:46] <diddledan> rpool/ROOT/ubuntu_t60y5t/var/lib on /var/lib type zfs (rw,relatime,xattr,posixacl)
[16:46] <zyga> jdstrand: great idea
[16:46] <zyga> hmm
[16:47]  * zyga also uses zfs on his 20.04 desktop but that machine sees very little use
[16:49] <jdstrand> diddledan: can you also attach: sudo systemd-analyze dot snap.multipass.multipassd.service > ./1871148-multipass.dot
[16:50] <diddledan> both added
[16:50] <zyga> hmm
[16:51] <zyga> no apparmor.service at all??
[16:51] <zyga> WAT?
[16:51] <jdstrand> zyga: which are you looking at?
[16:51] <zyga> jdstrand: the .svg
[16:51] <zyga> full system stuff
[16:52] <zyga> diddledan: can you journalctl -u apparmor.service
[16:52] <zyga> I wonder if it ran once or twice
[16:52] <zyga> (during this boot)
[16:53] <jdstrand> uh
[16:53] <zyga> maybe I should boot that desktop
[16:53] <jdstrand> that is real weird
[16:53] <zyga> jdstrand: if you don't have ZFS I can try that
[16:53] <diddledan> looks like it only ran once until I restarted it manually: https://paste.ubuntu.com/p/W8bzwDpcR3/
[16:53] <jdstrand> I do not
[16:53] <zyga> !!!
[16:54] <zyga> diddledan: can you reboot
[16:54] <zyga> diddledan: and see if it starts then
[16:54] <zyga> diddledan: if no, do not start it please
[16:54] <diddledan> roger. gimme a sec
[16:54] <zyga> thank you
[16:54] <zyga> jdstrand: I guess it didn't run and why is the whole mystery
[16:54] <jdstrand> zyga: it did run
[16:54] <jdstrand> Apr 06 16:32:56 defiant systemd[1]: Finished Load AppArmor profiles.
[16:55] <zyga> jdstrand: yeah but it was invoked manually
[16:55] <zyga> or could have been
[16:55] <zyga> why is it not in the .svg file?
[16:55] <jdstrand> zyga: the restarting apparmor was the manual one
[16:55] <diddledan> ok. back. snaps are broken :-)
[16:56] <jdstrand> zyga: the one I pointed at is from the paste in the bug that I mentioned
[16:56] <jdstrand> but why isn't it in the svg file, indeed
[16:56] <zyga> diddledan: ok
[16:56] <zyga> please don't restart apparmor.service
[16:56] <zyga> diddledan: systemctl status apparmor.service
[16:56] <zyga> diddledan: I bet there's a reason it was not started
[16:56] <zyga> and that's the big mystery
[16:57] <jdstrand> yeah
[16:57] <diddledan> https://paste.ubuntu.com/p/h69jvBV6Kd/
[16:57] <zyga> huh
[16:57] <zyga> jdstrand: is there some debug switch to get a list of things loaded?
[16:58] <zyga> diddledan: can you edit /lib/apparmor/apparmor.systemd and add set -x up top
[16:58] <zyga> and restart apparmor.service
[16:58] <diddledan> that'll make everything start working, remember..
[16:59] <zyga> yes but we will see that it works and the log of what happened
[16:59] <zyga> if that log is useful
[16:59] <zyga> then let's reboot again
[16:59] <zyga> and see the early -boot log
[16:59] <jdstrand> I still suspect the profiles weren't there at the time the service was start
[16:59] <jdstrand> wait!!
[16:59] <zyga> then we might know what to do
[16:59] <jdstrand> don't reboot yet
[16:59] <zyga> ok
[16:59] <jdstrand> diddledan: can you update /lib/apparmor/rc.apparmor.functions to comment out:
[16:59] <jdstrand>   if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then
[16:59] <jdstrand>           PARSER_OPTS="$PARSER_OPTS --quiet"
[16:59] <jdstrand>   fi
[17:00] <jdstrand> diddledan: then reboot
[17:01] <diddledan> restarting apparmor with those changes BEFORE rebooting: https://paste.ubuntu.com/p/HHQsFPZpYP/
[17:01] <jdstrand> diddledan: actually
[17:01]  * diddledan holds
[17:01] <jdstrand> diddledan: let's change that to be:
[17:01] <jdstrand>   #if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then
[17:01] <jdstrand>   #        PARSER_OPTS="$PARSER_OPTS --quiet"
[17:01] <jdstrand>   #fi
[17:01] <jdstrand>   PARSER_OPTS="$PARSER_OPTS -k"
[17:02] <jdstrand> that will show cache hits and misses
[17:02] <zyga> mmm
[17:02] <diddledan> ok. made the change. going for reboob
[17:03] <zyga> jdstrand: like a good mystery novel
[17:03] <zyga> the murderer is about to be revealed
[17:04] <diddledan> here we go: https://paste.ubuntu.com/p/dMMdZRZBbN/
[17:04] <zyga> Apr 06 18:03:26 defiant apparmor.systemd[2717]: + [ -d /var/lib/snapd/apparmor/profiles ]
[17:05] <zyga> it didn't find snapd profiles
[17:05] <zyga> PROFILE_DIRS is only assigned to once
[17:05] <jdstrand> huh
[17:05] <zyga> wow
[17:05] <zyga> right/
[17:05] <zyga> diddledan: can you pastebin /proc/self/mountinfo please
[17:05] <zyga> maybe there's some zfs magic we didn't anticipate
[17:05] <jdstrand> why isn't /var/lib/snapd/apparmor/profiles being looked at
[17:05] <zyga> jdstrand: ^ because it's not there at the time
[17:05] <diddledan> https://paste.ubuntu.com/p/7783bjqXNF/
[17:06] <zyga> line 13 of the paste
[17:06] <jdstrand> oh, yes
[17:06] <jdstrand> ok, that part of the mystery is solved
[17:06] <zyga> 143 31 0:53 / /var/lib rw,relatime shared:79 - zfs rpool/ROOT/ubuntu_t60y5t/var/lib rw,xattr,posixacl
[17:06] <zyga> it's a separate volume
[17:06] <zyga> we don't have requires mounts for
[17:06] <zyga> so ... bummer
[17:06] <zyga> we need to rev apparmor.service
[17:06] <zyga> to have that
[17:06] <jdstrand> that is probably not satisfied by local-fs
[17:07] <zyga> diddledan: can you please create
[17:07] <zyga> diddledan: /etc/systemd/system/apparmor.service.d
[17:07] <zyga> diddledan: there create a file fixes.conf
[17:07] <zyga> with contents:
[17:07] <zyga> [Unit]
[17:07] <zyga> RequiresMountsFor=/var/lib/snapd/apparmor/profiles
[17:07] <zyga> then reboot
[17:07] <zyga> that should be it
[17:08] <zyga> I wonder what local fs thing is
[17:08] <diddledan> ok. rebooting
[17:08] <zyga> or what makes that zoo of pools
[17:08] <zyga> do we know someone in foundations that works on zfs?
[17:09] <zyga> I wonder why is everything in /var/* a separate pool
[17:09] <zyga> and how does zfs interact with local-fs.target
[17:09] <zyga> it feels like a bug that's deeper than RequiresMountsFor
[17:10] <diddledan> dingdingding! we have a weiner!
[17:10] <zyga> xnox: (sorry for pinging you, I just recall you as a foundations member that's very well connected), do you know who works on zfs on ubuntu?
[17:10] <zyga> diddledan: cool!
[17:10] <jdstrand> zyga: we definitely need foundations to advise
[17:10] <zyga> jdstrand: agreed
[17:10] <zyga> mvo: ^ it's a bug introduced by zfs
[17:10] <zyga> popey: ^ a workaround for you is spelled out above
[17:10] <jdstrand> fyi, I summarized in https://bugs.launchpad.net/snapd/+bug/1871148/comments/10
[17:10] <mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
[17:10] <zyga> super, thanks!
[17:11] <jdstrand> I did not put in the workaround
[17:11] <zyga> I read
[17:11] <zyga> ok, I need to take the dog out
[17:11] <zyga> it's been hours now
[17:11] <zyga> but we should definitely ask foundations to help
[17:11] <zyga> it's a RC blocker IMO
[17:11] <jdstrand> RequiresMountsFor=/var/lib/snapd/apparmor/profiles is probably fine
[17:11] <zyga> god knows what else is broken
[17:11] <zyga> yeah, I think we should have that
[17:11] <jdstrand> I can do a quick upload
[17:12] <zyga> jdstrand: can you upload new apparmor package to add that?
[17:12] <zyga> super ^ 2
[17:12] <zyga> :D
[17:12] <Saviq> zyga, jdstrand: didrocks / jibel are your zfs-on-root / zsys experts
[17:12] <xnox> zyga:  we don't do zfs on ubuntu-core today, nor in cloud. the only place it's available is on ubuntu desktop => which is desktop team stuff, i.e. jibel and friends. Not foundations thing =)
[17:12] <zyga> jibel: ^
[17:12] <zyga> thanks guys!
[17:12] <jdstrand> xnox: do you agree that RequiresMountsFor=/var/lib/snapd/apparmor/profiles is reasonable to upload?
[17:12] <zyga> jibel: we may have a problem with zfs-on-root and local-fs.target
[17:13] <Saviq> let's ping jibel again so he doesn't get a heart attack at all :D
[17:13] <zyga> the details are in https://bugs.launchpad.net/snapd/+bug/1871148
[17:13] <mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
[17:13] <xnox> jdstrand:  complete context switch =) que? =)
[17:13] <diddledan> should we ping jibel?
[17:13] <zyga> diddledan: I did :) ^
[17:13] <diddledan> :-p
[17:13] <zyga> super
[17:13] <zyga> I'll leave you guys to it
[17:13] <diddledan> yeah I was trolly
[17:13] <zyga> my dog is looking at me with those puppy eyes
[17:13] <xnox> jdstrand:  you probably want rbalint
[17:14] <diddledan> what idiot gave puppies puppyeyes?!
[17:14] <jdstrand> xnox: so, zfs-on-root does different pools for /var such that local-fs.target is satisfied but /var/lib/snapd/apparmor/profiles does not exist at the time the service starts
[17:14] <zyga> diddledan: puppy conspiracy :)
[17:14] <zyga> jdstrand: I wonder if zfs mounts are done by systemd
[17:14] <diddledan> it's the poopscoop industrial complex!
[17:14] <zyga> I guess it must be
[17:14] <zyga> because the requirement was enough to fix it
[17:15]  * zyga afk
[17:15] <zyga> o/
[17:15] <jdstrand> xnox: ack
[17:15]  * jdstrand -> ubuntu-devel
[17:15] <xnox> jdstrand:  and AppArmorProfile= key doesn't synthesize such a dep already? it should?
[17:15] <xnox> &> #ubuntu-devel
[17:16] <Saviq> zyga: https://github.com/openzfs/zfs/tree/master/etc/systemd/system
[17:16] <mup> PR snapd#8439 opened: [RFC] secboot: import secboot on ubuntu, provide dummy on !ubuntu <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8439>
[17:17] <mvo> pedronis: I started looking into the tpm PR finally and the above is a first RFC to help moving it into master (cc cmatsuoka). hope this is vaguely the right direction, please let me know if you would like to see tags used differently or some totally different approach
[17:17] <zyga> https://github.com/openzfs/zfs/blob/5a42ef04fd390dc96fbbf31bc9f3d05695998211/etc/systemd/system/zfs-mount.service.in#L8
[17:19] <mvo> cmatsuoka: feel free to pickup/improve 8439, I have dinner now
[17:19] <jdstrand> xnox: it might be able to synthesize it, but that is in the snapd units. by that time, the apparmor unit already ran and finished, ignoring the dir
[17:20] <jdstrand> xnox: but, we aren't using AppArmorProfile in the units anyway (snap-confine handles it)
[17:25] <cmatsuoka> mvo: ack
[17:29] <pedronis> mvo: that looks painful once types enter the picture
[17:31] <pedronis> but I'm probably missing something
[17:34] <xnox> jdstrand:  hm, apparmor.service (or whatever it is) really should require mounts for dirs it uses, i.e /var/lib/foo/bar/baz/ which systemd will correctly resolve as to which ones are needed (i.e. /var, or /var/lib, or /varlib/foo, etc.)
[17:35] <xnox> jdstrand:  and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called)
[17:35] <pedronis> cmatsuoka: I made some comments there
[17:35] <cmatsuoka> pedronis: thanks, will check asap
[17:36] <mup> PR snapd#8415 closed: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
[17:36] <jdstrand> xnox: ok, so it sounds like you answered my question about RequiresMountsFor=/var/lib/snapd/apparmor/profiles
[17:50]  * zyga EODs and goes to set up some DNS at home
[18:11] <pedronis> jdstrand: so this needs both an apparmor package fix and a snapd snap services fix?
[18:23] <jdstrand> pedronis: no. snapd does not need a change. I am going to make a change to apparmor since it is the correct thing for it. it should address this issue. it sounds like jibel is going to perhaps adjust zsys in some manner
[18:23] <mvo> pedronis: re 8439> it should be enough to get the current tpm PR in progress working everywhere but yes, will not scale well. I guess it all depends on how much of the secboot code will be used outside of cmd/snap-bootstrap (which is skipped entirely on !ubuntu)
[18:23] <mvo> pedronis: anyway, totally happy about idea, just wanted to help unblock things
[18:23] <cmatsuoka> mvo: ok, working on that. I refactored it a little bit to have CheckEncryptionAvailability() in different versions
[18:24] <mup> PR pc-amd64-gadget#40 closed: gadget.yaml: reduce data partition size to 1G <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/40>
[18:25] <pedronis> jdstrand: don't we need this:  <xnox> jdstrand:  and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called)
[18:25] <mvo> cmatsuoka: sounds great
[18:25] <mvo> cmatsuoka: fwiw, I'm not attached to this at all, just wanted to draft something to help us moving forward which can land in isolation to unblock the rest of the tpm work
[18:26] <cmatsuoka> mvo: shall I push my version to the same PR so we can discuss it better?
[18:26] <mvo> cmatsuoka: it looks also like my govendor changes are busted, sorry for that (https://travis-ci.org/github/snapcore/snapd/jobs/671744586?utm_medium=notification&utm_source=github_status) - I can look at it now unless you are already on this
[18:26] <mvo> cmatsuoka: yeah, go for it!
[18:27] <mvo> cmatsuoka: just push to the open PR or open a new one, like I said, no attachment to htis partical version :)
[18:30] <cmatsuoka> mvo: pushed it, we can always revert it if necessary
[18:31] <mvo> cmatsuoka: thanks! appreciated
[18:32] <cmatsuoka> oops, I didn't read the last comment from pedronis before pushing it
[18:32] <mvo> cmatsuoka: I ran "govendor remove +unused" just now
[18:33] <mvo> cmatsuoka: it seems like you adressed his comment, no?
[18:33] <cmatsuoka> I think it's in the same line
[18:33] <cmatsuoka> I renamed the function but ok, it's not important now
[18:34] <mvo> cmatsuoka: aha, I see
[18:35] <ijohnson> mvo I see that google:ubuntu-core-20-64:tests/core/writablepaths failed because /etc/machine-id was not writable, do we need to port that patch to release/2.44 ?
[18:36] <ijohnson> i.e. https://github.com/snapcore/snapd/pull/8422 might not have been applied to 2.44 iiuc
[18:36] <mup> PR #8422: tests: skip "/etc/machine-id" in "writablepaths" test <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8422>
[18:38] <mvo> ijohnson: in 2.44? yeah, I think there is a cherry pick missing
[18:38] <ijohnson> mvo: yes
[18:38] <ijohnson> I don't see that commit on 2.44
[18:39] <ijohnson> and the 2.44 travis run failed on that
[18:39] <mvo> ijohnson: just picked it
[18:39] <mvo> ijohnson: *hopefully* that's enough
[18:39] <ijohnson> cool :-)
[18:39] <mvo> ijohnson: thanks for noticing!
[18:39]  * ijohnson crosses fingers
[18:39] <mup> PR snapd#8440 opened: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
[20:11] <cmatsuoka> ijohnson: did you work with the microk8s snap recently?
[20:11] <cmatsuoka> ijohnson: you may want to have a look at https://bugs.launchpad.net/snapd/+bug/1871189
[20:11] <mup> Bug #1871189: Snapd `cannot update snap namespace` when connecting / disconnecting interfaces <snapd:New> <https://launchpad.net/bugs/1871189>
[20:13] <ijohnson> cmatsuoka: yes I will add a reproducer there today, it is what was reported in #snappy-internal the other day
[20:13] <cmatsuoka> ijohnson: ah ok, should I assign that to you then?
[20:14] <ijohnson> sure
[20:14] <cmatsuoka> thanks
[20:38] <cmatsuoka> zyga: have you seen trap invalid opcode error messages in xdg-open invoked from a snap?
[20:56] <mup> PR snapd#8441 opened: interfaces: add case for rootWritableOverlay + NFS <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8441>
[21:03] <mup> PR snapd#8442 opened: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
[21:06] <mup> PR snapcraft#3015 opened: [WIP] ros2 (colcon) extension preview <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3015>
[21:46] <pedronis> ijohnson: I marked #8442 blocked, *util packages should really depend only on stdlib or other util packages (there might be counterexamples but we should fix them), so importing dirs into osutil is not a solution as is to your conundrum
[21:46] <mup> PR #8442: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
[21:51] <mup> PR snapd#8434 closed: systemd: move the doc comments to the interface so they are visible <Reviewed> <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8434>
[22:19] <zyga> cmatsuoka: not that I recall
[22:43] <mup> PR snapd#8443 opened: interfaces/many: miscellaneous policy updates xliv <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8443>
[22:48] <mup> PR snapd#8444 opened: interfaces/many: miscellaneous policy updates xliv - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8444>
[23:03] <cmatsuoka> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1870861 shows some instances of that happening
[23:03] <mup> Bug #1870861: chromium-browser is unable to open downloads <snapd (Ubuntu):New> <https://launchpad.net/bugs/1870861>


[13:05] <haronas> test
[15:05] <Guest6872> Hello, does anyone here is receiving "failed to load session "gnome-classic" with gdm and gnome 3.8?
[15:14] <Guest6872> help
[15:40] <Hx2> Hello, does anyone here is receiving "failed to load session "gnome-classic" with gdm and gnome 3.8?