[01:41] <Trevinho> duflu: hey, yeah... that check is now handled :)
[02:39] <duflu> Trevinho, I might log a separate bug (which doesn't mention mutter) for Nvidia to look at. Although I recall in the past few weeks seeing the same error in some other users' Xorg logs in bug reports
[03:27] <Trevinho> k
[04:02] <Trevinho> duflu: can you re-review the merge request on the pkg too?
[04:12] <duflu> Trevinho, yes I was going to after lunch and running to the shop...
[05:50] <didrocks> good morning
[05:52] <duflu> Morning didrocks
[05:53] <didrocks> hey duflu
[05:55] <Trevinho> morning didrocks
[05:56] <Trevinho> if you can have a look in sponsoring mutter would be nice :)
[05:56] <Trevinho> later in the day I mean
[05:57] <didrocks> hey Trevinho
[05:57] <jibel> morning all
[05:57] <didrocks> Trevinho: any luck debugging the scaling issue?
[05:57] <didrocks> Trevinho: final freeze is in 48h
[05:57] <didrocks> hey jibel
[05:58] <didrocks> starting to get stressed, and we may argue it's a blocker
[05:58] <didrocks> Trevinho: the hope was for you to debug/fix and we include this fix in one upload, not 2
[06:04] <didrocks> Trevinho: to be clear: I'm going to ask for a revert of the scaling factor patch during the AOB of our weekly meeting
[06:04] <didrocks> on Thursday, if no fix is provided
[06:05]  * didrocks opens the bug, why I don't receive updates with this?
[06:05] <didrocks> Trevinho:ok, I see that you tried a patch
[06:06] <didrocks> Trevinho: when you say, "landing mutter", you mean, landing mutter with https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3695 ?
[06:06] <Trevinho> didrocks: nope, I did that for having users to tests
[06:07] <didrocks> Trevinho: do you have the corresponding bileto ticket?
[06:07] <Trevinho> didrocks: but that's not for uploading, I've pushed the MP
[06:07] <didrocks> ah
[06:07] <didrocks> Trevinho: do you have the link for the MP? I can do more testing and land the 2 fixes at the same time then
[06:07] <Trevinho> didrocks: https://code.launchpad.net/~3v1n0/ubuntu/+source/mutter/+git/mutter/+merge/365624
[06:07] <Trevinho> didrocks: it's all in one upload
[06:08] <didrocks> Trevinho: thanks! Will test and if all good (as it seems it fixed it as well for 2 people on the bug) I will land all of that
[06:08] <didrocks> thx! Sorry, as I didn't receive the bug updates, I thought this was stalled
[06:09] <Trevinho> didrocks: nope, was an easy fix... I pushed it last friday and asked users to test, and so far it was all ok
[06:10] <Trevinho> I didn't prepare another bileto since was just faster for you to merge and upload I suppose
[06:11] <duflu> Morning jibel
[06:11] <duflu> And it is morning Trevinho ;)
[06:13] <duflu> Trevinho, sounds like maybe Nvidia isn't a factor here? bug 1823793
[06:13] <ubot5`> bug 1823793 in mutter (Ubuntu) "[regression] Font scaling not working on gnome startup" [Undecided,Confirmed] https://launchpad.net/bugs/1823793
[06:16] <didrocks> Trevinho: yeah, fast to merge and test
[06:20] <Trevinho> duflu: on that, should be fixed again by the branch
[06:21] <Trevinho> TBH there's an issue that is not dependent on the branch itself for the way the font scaling is computed as it depends on scaling too
[06:21] <Trevinho> and there could be some recursion
[06:21] <Trevinho> however, that bug is just a duplicate I think
[06:27] <didrocks> $ gbp clone lp:~ubuntu-desktop/ubuntu/+source/mutter
[06:27] <didrocks> gbp:info: Cloning from 'lp:~ubuntu-desktop/ubuntu/+source/mutter'
[06:27] <didrocks> gbp:error: Git command failed: Error running git checkout: error: le spécificateur de chemin 'master' ne correspond à aucun fichier connu de git
[06:28] <didrocks> hum :/
[06:32] <Trevinho> didrocks: I expect someone changed the default branch in lp not to be ubuntu/master?
[06:32] <Trevinho> or...
[06:32] <Trevinho> didrocks: actually no one ever set it
[06:33] <didrocks> yeah, could be, that's weird
[06:33] <Trevinho> edit the repo and set master as it
[06:33] <Trevinho> well ubuntu/master
[06:33] <didrocks> nope
[06:33] <didrocks> ubuntu/master is set
[06:33]  * didrocks git clone for now
[06:48] <duflu> Trevinho, yeah it sounds like the fix is a duplicate, so no new fixes required. Only pointed it out because it sounds like it's not an Nvidia problem when I thought it was. Using font scaling instead of display scaling is something I didn't test which is why I never noticed that
[06:49] <Trevinho> nope, I duflu I think it's related to the fact that the font scaling is computed every time ui scaling is computed and this could cause some race, but but I've not looked too furhter on it
[06:56] <oSoMoN> good morning desktoppers
[06:59] <Trevinho> hi oSoMoN
[07:00] <Trevinho> and.... good night from this side of the World, see you soon
[07:00] <oSoMoN> hey Trevinho, good night!
[07:01] <duflu> Hi oSoMoN
[07:10] <didrocks> hey oSoMoN
[07:11] <oSoMoN> hey duflu
[07:11] <oSoMoN> salut didrocks
[07:11] <oSoMoN> I put my laptop to sleep last night, and when I opened the lid again this morning, it resumed without a lock screen and without a dock either
[07:12] <oSoMoN> the top panel is there, though
[07:22] <duflu> oSoMoN, did you see it lock before sleeping?
[07:22] <didrocks> either mutter is extra slow to build in a ppa or the builders are stalled
[07:23] <didrocks> or launchpad is hunging, cancelling the build is stuck as well
[07:23] <didrocks> let's try in a non virt ppa
[07:23] <oSoMoN> duflu, no, I simply closed the lid to put it to sleep, and usually when I wake it the screen is locked (as I would expect)
[07:24] <duflu> oSoMoN, yeah I know we've declared that kind of bug fixed before but some people keep reporting similar. I guess generally you should make sure the lock screen is on before closing. As a workaround.
[07:25] <duflu> Although upstream mutter has also been working on unblocking rendering during power management modes recently. That might help
[07:26] <duflu> Ideally sleeping needs to be blocked until locking is confirmed
[07:26] <duflu> I have no idea what the parts are that should do that though
[07:32] <duflu> Maybe related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
[07:32] <gitbot> GNOME issue (Merge request) 506 in mutter "Power save and KMS error handling fixes" [5. Backend: Native, Merged]
[07:33] <duflu> (in mutter 3.32.1)
[07:34] <oSoMoN> duflu, ack, thanks
[07:45] <seb128> good morning desktopers
[07:57] <duflu> Morning seb128
[07:59] <willcooke> morning
[08:03] <duflu> Morning willcooke
[08:03] <seb128> hey duflu willcooke
[08:04] <Laney> yo
[08:04] <duflu> Hi Laney. How you feeling?
[08:04] <Laney> moin duflu
[08:04] <Laney> acceptable
[08:05] <Laney> you?
[08:05] <duflu> Yes, good.
[08:05] <duflu> Laney, I mean compared to yesterday
[08:05] <Laney> yeah, yesterday would have been unacceptable :>
[08:05] <Laney> perhaps the hotfix worked
[08:08] <seb128> hey Laney
[08:13] <Laney> hi seb128
[08:13] <didrocks> hey willcooke, seb128, Laney
[08:13] <seb128> lut didrocks, en forme ?
[08:13] <willcooke> hi duflu seb128 didrocks Laney
[08:14] <didrocks> seb128: angine + conjonctivite, donc bon… :p
[08:14] <didrocks> un poil de fièvre pour couronner le tout
[08:15] <seb128> outch
[08:15] <seb128> didrocks, get some rest and get better!
[08:15] <willcooke> popey, morning!  Reminder to raise your big font problem
[08:15] <willcooke> get well didrocks
[08:15] <didrocks> seb128:thx, still need to finishing up some things and advance on subject, but no run, nothing outside
[08:15] <didrocks> thx willcooke
[08:16] <seb128> willcooke, he did yesterday evening I think? which sounded like the same issue than didrocks is having just reversed
[08:16] <seb128> the fixes from Marco which are pending upload hopefully fix that
[08:16] <didrocks> yeah, the ppa farm is down though :(
[08:16] <didrocks> and building on mutter on my nvidia is a PITA
[08:16] <willcooke> ah good, I thought it was the same problem and L_aney said it sounded like it too
[08:17] <didrocks> I wanted to testproof it before uploading
[08:18] <seb128> does #launchpad/#is know about the ppas issue?
[08:18] <didrocks> didn't ping yet, but image builds are stuck as well
[08:19] <Laney> hey didrocks hey willcooke
[08:20] <seb128> didrocks,
 tjaalton: buildd-manager has got stuck; I've requested a restart (though there's no IS vanguard around just now, so it may take a while)
[08:20] <seb128> just as a fyi
[08:32] <didrocks> seb128: thx for asking
[08:32] <seb128> didrocks, I didn't need to, TImo already had ... anyway hopefully sorted out soon!
[08:33] <didrocks> :)
[08:34] <tjaalton> :P
[08:36] <didrocks> ah, unstuck! let's test this mutter
[08:38] <didrocks> 2 boots without any issues! As it was on each boot before, I think it's fixed
[08:38] <didrocks> let me keep mutter running for a little while to ensure no obvious regression and I'll sponsor
[08:39] <seb128> wooot
[08:39] <seb128> good work Marco
[08:39] <seb128> thx didrocks for testing/sponsoring!
[08:39] <seb128> (we should probably think about maybe giving Marco ppu for the gnome-shell stack this cycle?)
[08:41] <didrocks> yeah, would be easier, under the condition that things are carefully tested before upload :)
[08:42] <didrocks> but sounds logical to me
[08:42] <seb128> yeah, I think we didn't have much untested mps problem recently so worth at least considering it
[08:46] <willcooke> tseliot, can you tell me if this behaviour is expected? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-418/+bug/1823758
[08:46] <ubot5`> Ubuntu bug 1823758 in nvidia-graphics-drivers-418 (Ubuntu) "Release upgrade didn't update nvidia driver" [Undecided,New]
[08:52] <jibel> is there a tool that shows where on the screen is the touch event happening?
[08:56] <seb128> libinput-debug-events ?
[08:59] <seb128> or evemu-record
[09:05] <willcooke> jibel, evtest might help too
[09:15] <jibel> Trevinho, I tested mutter 3.32.0-1ubuntu2 from didrocks's PPA with your fixes and touch with screen rotation is still broken.
[09:15] <jibel> Trevinho, the screen rotates physically but the coordinates of the pointer do not.
[09:16] <jibel> note that it doesn't really work either with 3.32.0-1
[09:19] <seb128> that's not supposed to be fixed with the ppa
[09:19] <seb128> but in upstream 3.32.1
[09:19] <seb128> which wasn't released yet
[09:19] <jibel> k
[09:20] <didrocks> FYI, jibel and I didn't spot any obvious regression, so 3.32.0-1ubuntu2 now in UNAPPROVED
[09:20] <seb128> great
[09:20] <seb128> thx guys!
[09:20] <seb128> I guess we get another update/upload to do with .1 is out, hopefully today
[09:21] <didrocks> let's hope so :)
[09:21] <didrocks> between 2 zfs discussions, was time to test it ;)
[09:22] <seb128> didrocks, btw unsure if you saw, I assigned you 2 of the disco-archive-rebuild bugs, ubuntu-reports hitting a go listed by dh_missing and session-migration
[09:23] <didrocks> seb128: yeah, will do them at lunch time, should be easy for both
[09:23] <seb128> great
[09:23] <didrocks> so, I saw, but thanks for the reminder :)
[09:23] <seb128> thx :)
[09:23] <seb128> np!
[09:23] <didrocks> go was upgraded to 1.11 and now ship mod files
[09:24] <didrocks> session-migration is just 2 tests failing due to python config file changing its sorting behavior (grrrr)
[09:24] <seb128> python :/
[09:25] <didrocks> "backward behavior compatibility" :p
[09:40] <k_alam> seb128: Hi, can you cherry pick the log out fix for systemd ?
[09:40] <k_alam> https://github.com/systemd/systemd/pull/11697
[09:40] <gitbot> systemd issue (Pull request) 11697 in systemd "Notify about Job property change when job is uninstalled" [Pid1, Closed]
[10:25] <tseliot> willcooke: yes, it is expected. The 418 driver doesn't support some of the GPU series that the 390 supports, hence we avoid upgrading users to something that might not work for them. Also, we don't do hardware detection when upgrading drivers.
[10:28] <tseliot> willcooke: let me reply in the bug report
[10:29] <willcooke> thanks tseliot
[10:29] <duflu> It's never ending :/  (I've been using the Nvidia driver since around 1998 and regularly lose support for my current GPU)
[10:30]  * duflu shrugs and fades into the night
[10:32] <tseliot> willcooke: done. So, that would be either a "won't fix", or a "wishlist" thing, assuming that anybody wants to work on it on the system updater side (I can help with the detection side)
[10:34] <willcooke> tseliot, oki.  I think we need to have another discussion about how we want the general nvidia drivers story to improve.  Making newer drivers more easily installable/findable etc.  I'm going to see Brad in a couple of weeks so I will bring it up with him then and see what we can work out.
[10:35] <tseliot> willcooke: all right
[11:35] <popey> willcooke: who was i going to speak to about big font fun?
[11:36] <willcooke> popey, d_idrocks but it's known and should be fixed
[11:36] <popey> ok, collio
[11:36] <popey> *coolio
[11:43] <seb128> popey, see backlog for a ppa to test (or wait for the upload to be approved from disco queue)
[11:43] <popey> kk, thanks
[11:57] <seb128> tjaalton, do you think it's worth syncing the libxcursor new version from debian? looking to https://gitlab.freedesktop.org/xorg/lib/libxcursor/commits/master it fixes a segfault and add support for xdg dir and that's it, sounds like bugfix enough?
[11:59] <tjaalton> seb128: fine by me
[11:59] <seb128> tjaalton, thx
[13:03] <kenvandine> oSoMoN: yay... your firefox policy patch was merged
[13:22] <Trevinho> Morning
[13:22] <seb128> hey trevinho!
[13:22] <Trevinho> didrocks: thanks for testing and uploading, jibel testing too (but as said my side of the problem should be done)
[13:23] <Trevinho> seb128: hi
[13:23] <seb128> how are you?
[13:23] <Trevinho> seb128: muy bien!
[13:23] <seb128> trevinho, do you know if upstream shell plan to roll their 3.32.1 tarballs today?
[13:23] <seb128> we are on a tight schedule for disco and we need those
[13:24] <Trevinho> seb128: no I saw Laney asked. but...
[13:24] <seb128> they fix several important bugs (like touch coordinate being buggy on X)
[13:24] <seb128> ah
[13:24] <didrocks> Trevinho: yw! Great to have the fix :)
[13:25] <didrocks> seb128: usbguard isn't for disco, right?
[13:25] <didrocks> (been asked in the MIR team)
[13:25] <seb128> didrocks, no, it's maybe for next cycle
[13:25] <didrocks> ack
[13:25] <seb128> depends if GNOME merge the work which is pending review
[13:26] <seb128> Laney, the "tech debt" about search provider you are talking about are the app patches we have for a few of our sources?
[13:26] <didrocks> ok! it will be off the list for now
[13:26] <seb128> for one week? :p
[13:26] <Trevinho> didrocks: yeah was nothing huge, but I actually I'm happy to have triggered it since it's just an issue that is there because of a race I want to fix anyways (and not dependent on the fractional thing itself)
[13:26] <didrocks> seb128: well, I doubt it will be looked at until we have the confirmation it's going to be needed soon
[13:26] <seb128> I should adjust my replies
[13:27] <seb128> tell them it's for disco :p
[13:27] <didrocks> ahah
[13:27] <seb128> but that's how we end up having things put on side until mid-next-cycle
[13:27] <seb128> and then missing the cycle :/
[13:27] <didrocks> I guess move that back to early next week
[13:27] <seb128> no hurry
[13:27] <seb128> I guess we will discuss the topic in Lyon
[13:28] <didrocks> having an accurate list and not a 30 items long one, knowing "it's really the ones we need to work on" this cycle helps
[13:28] <Trevinho> seb128: I have to ping again florian.... 😔
[13:28] <seb128> then we can re-bump priorities and ping MIR/security team if needed
[13:28] <seb128> Trevinho, DOIT :)
[13:28] <didrocks> like dlna which is up for mutliple cycles
[13:28]  * Trevinho doesn't like to bother
[13:28] <didrocks> but yeah, a little bit of better coordination
[13:28] <seb128> didrocks, yeah, chrisccoulson is sleeping on that one :(
[13:30] <Laney> seb128: yes, and there's a patch to Shell too
[13:30] <Laney> but if you don't care then ignore my comment, that's fine
[13:30] <seb128> Laney, k
[13:30] <willcooke> bah, why didnt I get a calendar reminder
[13:30] <seb128> Laney, I do care, I just wanted to make sure I've the details right
[13:30] <seb128> willcooke, DST?
[13:30] <willcooke> maybe I just closed it without reading
[13:30] <willcooke> anyway
[13:31] <willcooke> #startmeeting Desktop Team Meeting 2019-04-09
[13:31] <meetingology> Meeting started Tue Apr  9 13:31:03 2019 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[13:31] <meetingology> Available commands: action commands idea info link nick
[13:31] <seb128> Laney, and I agree it's time to sort that out (though I'm afraid it's another one where we need Florian to comment/review and fail to get traction, but let's see)
[13:31] <willcooke> Roll call: andyrock, dgadomski, didrocks, duflu (out), jamesh (out), jibel, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[13:32] <didrocks> hey
[13:32] <Laney> rather that bracketed stuff be left out of replies if possible
[13:32] <Laney> hi there
[13:32] <jibel> o/
[13:32] <kenvandine> o/
[13:32] <willcooke> I failed to send out the rls bugs email this morning, sorry.  I had meetings and got busy with release PR stuff
[13:32] <seb128> Laney, k, fair enough, I just think Marco failed to get traction in previous cycle but let's be positive and have a fresh try again :)
[13:32] <Trevinho> o/
[13:33] <willcooke> Let's look at incoming BB bugs
[13:33] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[13:33] <willcooke> 1 new one, but already fixed by the looks of it
[13:33] <willcooke> https://bugs.launchpad.net/ubuntu-gnome/+bug/1592177
[13:33] <ubot5`> Ubuntu bug 1592177 in gtk+3.0 (Ubuntu) "Focus drops from search input in GtkFileChooserDialog after first character, which stops searching (broken behaviour)" [Undecided,Fix released]
[13:33] <seb128> yeah, I'm untagging
[13:33] <willcooke> thx
[13:34] <seb128> I need to talk to bdmurray about filtering the fix commited out
[13:34] <seb128> well accepted/fix commited should be out
[13:34] <willcooke> We can just ignore them for now
[13:34] <seb128> I think we said if it's nominated then it's not making sense on the incoming list (rather than the status)
[13:34] <seb128> yeah
[13:34] <seb128> just it did remind me I said I would talk ot him
[13:34] <willcooke> On to CC:
[13:34] <seb128> anyway
[13:34] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[13:34] <andyrock> o/
[13:35] <willcooke> Quite a few FTBFS
[13:35] <seb128> hey andyrock, get off this phone :p
[13:35] <willcooke> I saw a conversation about that on the mailing list
[13:35] <seb128> willcooke, I vote rls-not-fixing them all
[13:35] <seb128> edontcareaboutcosmicatthispoint
[13:35] <andyrock> seb128: I'm on my laptop :P
[13:35] <willcooke> anyone against that idea?
[13:35] <seb128> even d_oko seemed to agree on the list that it was not a priority
[13:35] <willcooke> Sounds right to me, based on the ml
[13:35] <didrocks> agreed, time for fixing, SRU, get that migrated… probably shouldn't care. Or maybe reviewing the list and see if they apply to disco?
[13:36] <seb128> he filed bugs for disco
[13:36] <seb128> we had a full test rebuild there as well
[13:36] <seb128> rls-dd-incoming has them
[13:36] <didrocks> perfect then :)
[13:36] <willcooke> ok, if no one objects to the CC ones I will fix them in a mo
[13:36] <seb128> thx
[13:36] <willcooke> On to DD then:
[13:36] <willcooke> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html
[13:37] <willcooke> there is one non-FTB
[13:37] <seb128> that one is more interesting :)
[13:37] <willcooke> Robert has fixed it
[13:37] <seb128> right, I emailed nagged him about it yesterday, worked out :)
[13:37] <willcooke> :)
[13:37] <willcooke> on to the FTB ones then
[13:38] <willcooke> Do we want to find owners for them all now?  I assume that we want to get them fixed
[13:38] <seb128> I wouldn't bother reviewing the list here
[13:38] <seb128> just ask people to grab some of they can
[13:38] <Laney> dish them out
[13:38] <seb128> and if they don't we do assignement in our managers meeting tomorrow?
[13:38] <Laney> I'll take deja-dup
[13:38] <willcooke> thanks Laney
[13:38] <seb128> Laney, thx, as a fyi I reported https://gitlab.gnome.org/World/deja-dup/issues/22
[13:38] <gitbot> World issue 22 in deja-dup "Tests fail with glib 2.60" [Opened]
[13:39]  * didrocks handles as told session-migration and ubuntu-report
[13:39] <seb128> I poked enough to figured out it's not happening with glib 2.58 but stopped there because ENOCLUE
[13:39] <Trevinho> mh, also is it a think to SRU just a build failure? mhmh
[13:39] <willcooke> seb128, can I assign you on that one?
[13:39] <seb128> Laney, .4 has the vala fixes we need
[13:39] <Laney> hmm, did you want that one then if you've looked a lot?
[13:40] <seb128> willcooke, deja-dup? Laney stepped in, I didn't get anywhere with the glib issue so I'm happy for him to poke
[13:40] <willcooke> I meant rsvg
[13:40] <willcooke> oh
[13:40] <willcooke> I missread
[13:40] <seb128> Laney, I got nowhere on why the mock thing/glib might fail to I would welcome you to poke at that bit
[13:40] <Laney> k
[13:40] <seb128> thx
[13:40] <willcooke> i386 only - do we want to fix those?
[13:40] <seb128> we need to
[13:40] <Laney> I vote give the rest out now, one per person, shouldn't take any time at all
[13:40] <willcooke> kk
[13:41] <seb128> yeah
[13:41] <willcooke> ok, librsvg
[13:41] <seb128> willcooke, let's review post meeting/assign?
[13:41] <seb128> no need of the team to assign imho
[13:41] <willcooke> I'd like to just get it done
[13:41] <seb128> k
[13:41] <seb128> oSoMoN, can you look at librsvg? it's something with rust
[13:41] <oSoMoN> yup
[13:41] <kenvandine> i can take shotwell
[13:41] <seb128> thx
[13:41] <seb128> kenvandine, thx
[13:42] <willcooke> https://bugs.launchpad.net/ubuntu/+source/openexr/+bug/1823432
[13:42] <ubot5`> Ubuntu bug 1823432 in openexr (Ubuntu) "openexr ftbfs in disco (i386 only)" [High,New]
[13:42] <Laney> shotwell has a link to a commit, CHEATER!
[13:42] <willcooke> ha
[13:42] <kenvandine> lol
[13:42] <didrocks> Laney: no, it's just that he's going to take 2 :)
[13:42]  * kenvandine hides
[13:42] <seb128> willcooke, I can take openexr and cogl
[13:43] <seb128> (done)
[13:43] <willcooke> https://bugs.launchpad.net/ubuntu/+source/guile-2.2/+bug/1823459
[13:43] <ubot5`> Ubuntu bug 1823459 in guile-2.2 (Ubuntu) "guile-2.2 ftbfs in disco (arm64 only)" [High,New]
[13:43] <seb128> andyrock, want to poke at that one?
[13:44] <andyrock> sure thing
[13:44] <seb128> thx
[13:44] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1823464
[13:44] <ubot5`> Ubuntu bug 1823464 in gnome-keyring (Ubuntu) "gnome-keyring ftbfs in disco (s390x only)" [High,New]
[13:44] <willcooke> s390 only
[13:44] <willcooke> so !fix
[13:44] <seb128> give it to xnox :p
[13:44] <willcooke> ?
[13:44] <seb128> well, we sort of need to fix build issues imho
[13:44] <seb128> or make it stop building on the arch
[13:45] <seb128> (or skip tests on that arch to "fix" the build...)
[13:45] <willcooke> same for gnome-keyring
[13:45] <seb128> that's gnome-keyring we were talking about?
[13:45] <willcooke> ffs. My tabs are out of order. sorry
[13:46] <Laney> I wouldn't dismiss those kind of bugs out of hand without investigating them at least a bit first ...
[13:46] <seb128> yeah
[13:46] <willcooke> Anyone want to offer to look at that one?
[13:46] <seb128> kenvandine, does Robert has time to poke maybe at that one?
[13:46] <seb128> lol
[13:46] <willcooke> he's on hols
[13:46] <kenvandine> nope
[13:47] <seb128> ah :/
[13:47] <willcooke> jamesh perhaps?
[13:47] <seb128> jamesh?
[13:47] <willcooke> seems like we all agree :)
[13:47] <kenvandine> sure
[13:47] <Laney> people who are accepting bugs, don't forget to target to series
[13:48] <Laney> otherwise they will not be on tracking
[13:48] <willcooke> k, I'm going to assign jamesh, if he can't loop back
[13:48] <willcooke> Laney, thx, I will go anf fix
[13:48] <willcooke> *and
[13:48]  * Laney fixed dd incoming already
[13:48] <willcooke> fixed for that last one
[13:48] <Laney> thx
[13:49] <willcooke> one last one for DD tracking...
[13:49] <willcooke> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1823175
[13:49] <ubot5`> Ubuntu bug 1823175 in gnome-shell (Ubuntu Cosmic) "Battery status shows "Estimating..." when fully charged" [Medium,Triaged]
[13:49] <willcooke> unassigned
[13:49] <willcooke> looks like it needs untagging
[13:49] <seb128> or marked invalid for upower
[13:50] <seb128> it seems it was fixed in gnome-shell
[13:50] <willcooke> The Unity 7 team might want to fix it still
[13:51] <willcooke> but it's incomplete anyway
[13:51] <kenvandine> there's a unity 7 team?
[13:51] <willcooke> k_alam & co
[13:51] <kenvandine> cool
[13:51] <seb128> well not rls in any case at this point I think
[13:51] <willcooke> yeah
[13:52] <willcooke> I will catch up with k_alam and sort it
[13:52] <willcooke> proposed migrations looks clear.  Anything you want to add Laney?
[13:54] <willcooke> Let's do AOB
[13:54] <Laney> nope
[13:54] <willcooke> thanks Laney
[13:54] <willcooke> #topic AOB
[13:54] <willcooke> Anyone got anything?
[13:54] <didrocks> nothing
[13:54] <willcooke> 1 min....
[13:54] <seb128> release is coming as a reminder
[13:55] <willcooke> :)
[13:55] <Trevinho> nope, I just will try to get some appindicator fixes, so might need sponsor :)
[13:55] <seb128> there are still some GNOME  3.32.1 updates that we should still try to get in
[13:55] <seb128> but otherwise I think we are mostly in good shape
[13:55] <andyrock> nope
[13:56] <Trevinho> ah, there are g-s changes pushed to vcs...
[13:56] <Trevinho> do we want to release them if no .1 is there?
[13:56] <seb128> Trevinho, finding a sponsor should be possible here :)
[13:56] <Trevinho> a11y mouse fix
[13:56] <seb128> we want a .1
[13:56] <seb128> if we don't have one I say we do a snapshot
[13:56] <Trevinho> k, that would be included anyways
[13:57] <Trevinho> let's define a deadline?
[13:57] <Trevinho> in waiting I mean
[13:57] <seb128> Laney, any opinion on that?
[13:57] <seb128> from a r-t perspective
[13:57] <seb128> I guess the sooner the better, I would say eod for tarball and we upload tomorrow what we have, snapshot or .1
[13:59] <willcooke> Let's continue that in a mo, and end the meeting...
[13:59] <willcooke> #endmeeting
[13:59] <meetingology> Meeting ended Tue Apr  9 13:59:27 2019 UTC.
[13:59] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2019/ubuntu-desktop.2019-04-09-13.31.moin.txt
[13:59] <willcooke> thanks all
[13:59] <seb128> thx
[13:59] <didrocks> thx
[13:59] <oSoMoN> thx
[14:00] <Laney> seb128: no, doesn't really matter, would still do those via debian as normal if possible though
[14:01] <seb128> right
[14:02] <Trevinho> indeeds
[14:27] <seb128> didrocks, did you maybe want to look at the gnome-boxes update this week? the libosinfo update landed but Jeremy vanished so he didn't do the .90 -> .0 update (which includes the new Ubuntu support)
[14:29] <didrocks> seb128: sure, will probably do tomorrow
[14:29] <seb128> no hurry, it's in universe so I guess it's fine until later in the week probably
[14:29] <seb128> thx didrocks!
[14:29] <didrocks> yw
[14:38] <tkamppeter> kenvandine, seb128, willcooke, I have updated the debdiff of bug 1763520 (the GTK print dialog patch) with the current patch from https://gitlab.gnome.org/GNOME/gtk/merge_requests/717. Could someone of you sponsor the upload before FF on Thursday? Thanks.
[14:38] <ubot5`> bug 1763520 in gtk+3.0 (Ubuntu Cosmic) "after upgrade to bionic, printing fails without explanation / logs / debuggability" [High,In progress] https://launchpad.net/bugs/1763520
[14:38] <gitbot> GNOME issue (Merge request) 717 in gtk "Print dialog, CUPS: Check unknown option values whether they are actually custom settings - Backport to GTK 3.24" [Merged]
[14:39] <seb128> tkamppeter, thx
[16:54] <GunnarHj> seb128: The "Manage Installed Languages" button is no longer visible in Region & Languages, even if ubuntu-language-support.patch is still there.
[17:02] <GunnarHj> jbicha: You are the author of that patch. ^ Any idea of what happened?
[17:03] <seb128> GunnarHj, hey, no idea about that, maybe ask robert_ancell when he gets online, he worked on the changes to that panel this cycle
[17:03] <seb128> jbicha is not around much recently I think, best to not wait for him
[17:04] <GunnarHj> seb128: Ok, I'll ask Robert. Thanks!
[17:05] <seb128> yw!
[17:07] <GunnarHj> seb128: I saw it when I was about to dig into bug #1823778. Any offhand thoughts about that bug?
[17:07] <ubot5`> bug 1823778 in gnome-control-center (Ubuntu) "Unable to set Serbian as Language" [Medium,Confirmed] https://launchpad.net/bugs/1823778
[17:12]  * kenvandine just enabled portals in gedit master (edge branch)
[17:12] <kenvandine> what could possibly go wrong :)
[17:13] <kenvandine> i didn't remove the home interface just yet
[17:39] <willcooke> night all o/
[19:25] <seb128> ricotz, I saw that someone uploaded your vala update to Debian, I synced it to disco now (it's in unapproved queue, still needs to get reviewed)
[20:18] <ricotz> seb128, ok, thank you
[20:51] <Trevinho> Laney: tomorrow when you want, please sync with https://tracker.debian.org/news/1037751/accepted-gnome-shell-extension-appindicator-28-1-source-into-experimental/


[03:26] <blackboxsw> rharper: volley for tomorrow https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/371895
[08:58] <matthiasbaur> Hey, I try to contribute to cloud-init and been told that I have to sign a CLA. As I'm not sure if the company I working for signed one, may I talk to you in private smoser?
[12:20] <smoser> matthiasbaur: talk to powersj .
[12:42] <matthiasbaur> powersj may I talk to you in private?
[18:04] <iliv> hey guys
[18:06] <powersj> o/
[18:08] <iliv> I have run into what probably is a well-known issue by know but new to me, which is if I use root EBS volume that is greater than 250G (e.g. >= 300G) for a Debian Jessie AMI based EC2 instance, that root EBS volume is partitioned with what seems like a default fallback option. Namely, 2 partitions: swap and 8GB root partition. As I undersatnd cloud-init is responsible for doing the partitioning. Is that correct?
[18:19] <rharper> iliv: cloud-init can do partitioning, and I believe certain platforms have some defaults; let me look at the ec2 datasource;   do you know what version of cloud-init is in your image? do you have a /var/log/cloud-init.log from the instance ?
[18:20] <iliv> Cloud-init v. 0.7.7
[18:20] <iliv> this is Debian Jessie AMI
[18:22] <rharper> iliv: look at our code; couldn't init doesn't do any partitioning of the root device (by default) ; it may grow or resize a root partition and it can enable/create swap;
[18:23] <rharper> iliv: typically images will have the root partition be the last partition on the disk, so that cloud-init can grow the last partition size to end of disk adn resize the rootfs as well
[18:23] <rharper> so I wonder if the AMI partition layout is the source of the issue;
[18:25] <iliv> it's kinda weird that it grows it only if ebs root volume size is <=250G
[18:26] <rharper> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784004
[18:26] <rharper> could be related
[18:26] <iliv> just to be clear, when using 500G root EBS volume I get 2 partitions: 1 swap and 1 8GB root partition. the remaining disk space is simply unallocated.
[18:27] <rharper> yes, this sounds like the above bug
[18:28] <rharper> well, maybe something else but related, so ebs size of 200G and you get the right size ?
[18:28] <rharper> in any case; the bug mentions a downlevel version of growpart in Debian Jessie which was the source of the root partition not being resized correctly
[18:29] <rharper> there are a couple workaround mentions w.r.t including an updated version of growpart in the image
[18:32] <iliv> > so ebs size of 200G and you get the right size ? // up to 250G
[18:32] <iliv> I tested 500G, 400G, 300G, 250G and 200G
[18:33] <iliv> if it's <=250G I get a 250G ext4 root partition
[18:33] <iliv> if it's >= 300G, I get only 8GB ext4 root partition
[18:34] <rharper> could be a new bug then; including the /var/log/cloud-init.log will be help, whether you file a downstream or an upstream bug;  if you use newer debian AMI (with newer cloud-inti) do you see the same issue ? or is it jessie only ?
[18:35] <iliv> https://dpaste.de/Zvbt/raw
[18:36] <iliv> I tested this with the Jessie AMI only
[18:37] <rharper> https://github.com/andsens/bootstrap-vz/issues/359
[18:37] <rharper> looks like that issue
[18:38] <rharper> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868875
[18:38] <rharper> already filed in debian
[18:38] <rharper> and it looks related to the util-linux version in Jessie;
[18:39] <iliv> you do all the dirty work for me :D
[18:39] <iliv> thanks, appreciate it!
[18:39] <rharper> np
[18:42] <iliv> "No longer marked as found in versions cloud-init/0.7.7~bzr1156-1~bpo8+1."
[18:43] <iliv> does that mean this bug was fixed in that version of cloud-init?
[18:49] <rharper> doubtful
[18:49] <rharper> it was a growpart issue (which cloud-init executes) and is part of the cloud-guest-utils package
[18:53] <iliv> so, nothing cloud-init can do here as long as we're stuck with this particular AMI?
[18:53] <iliv> I saw a reference to cloud-initramfs-growroot in one of the bug reports
[18:53] <iliv> not sure if that could help
[18:54] <iliv> but the theory goes that the growing would happen very early in the process before the filesystem is mounted
[18:54] <iliv> so on the surface sounds like an option to explore
[18:54] <rharper> you can disable growpart via cloud-config and then perform it manually
[18:54] <rharper> however, if the issue is related to the tools in the OS (util-linux package) being downlevel, then you'd somehow need to get the newer version of the tools and use them instead
[18:54] <iliv> oh, I tried that but it failed
[18:58] <rharper> https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1244662
[18:58] <rharper> this was fixed in newer util-linux
[18:58] <rharper> so, likely need t pull in a newer util-linux into the image and then try the growpart again manually
[19:05] <iliv> Installed: 2.25.2-6
[19:05] <iliv> "This bug was fixed in the package util-linux - 2.20.1-5.1ubuntu12"
[19:06] <iliv> however, that is ubuntu package
[19:07] <rharper> yes, but 2.25 is > 2.20
[19:08] <rharper> it was forwarded to upstream, I can see if we still have delta, but I suspect it was accepted upstream
[19:10] <iliv> well, if that's the case I saw exactly the same error message as shown in that Launchpad bug report when I tried to run growpart /dev/xvda 2
[19:11] <iliv> https://dpaste.de/NiFr/raw
[19:17] <rharper> https://github.com/karelzak/util-linux/commit/84ac311212c06963d616b1b9a40644842f9adabd ; landed upstream and released in 2.24,  https://lwn.net/Articles/581276/
[19:50] <blackboxsw> tribaal: if you have time next week, cloud-init SRU v 19.2-24-ge7881d5c-0ubuntu1 got re-queued for Xenial/Bionic and Disco with the Exoscale fixes for cloud_config_modules which we published in tip this week to Eoan.   If you get a chance to enable <series>-proposed on an Xenial or Bionic instance you have, then you can sudo cloud-init clean --logs;  apt-get remove --purge cloud-init; apt-get install cloud-init
[19:51] <blackboxsw> #version 19.2-24 sudo reboot   to test that Exoscale comes up properly
[19:51] <blackboxsw> I'll send an email about that too.
[20:11] <blackboxsw> rharper: thanks on SRU, minor comments and please land https://github.com/cloud-init/ubuntu-sru/pull/36/files and https://github.com/cloud-init/ubuntu-sru/pull/35/files .   Or your could file a 3rd PR that just updates all sru-templates with the new "local" template variables
[20:12] <blackboxsw> I'm adding it the the ec2 manual run I've kicked off now.
[20:25] <rharper> blackboxsw: ill check, I'll likely put up a separate PR for the template file
[20:33] <blackboxsw> +1 rharper


[04:58] <mup> PR snapcraft#1312 opened: state: fix the name of the source details <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1312>
[06:24] <mup> PR snapd#3290 closed: add support for `snap install foo --channel=3.4` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3290>
[06:51] <mup> PR snapd#3307 opened: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
[06:56] <Chipaca> *yawn*
[07:04] <mup> PR core#39 opened: add version-script <Created by mvo5> <https://github.com/snapcore/core/pull/39>
[07:04] <mup> PR snapd#3308 opened: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
[07:13] <Chipaca> ohhhhh
[07:13]  * Chipaca figured out why so many tests failed
[07:13] <Chipaca> MATCH *must* take the thing it's matching from via stdin
[07:13] <Chipaca> ah well
[07:14] <Chipaca> school run now, fix later
[07:16] <zyga> re
[07:16] <zyga> good morning
[07:21] <morphis> zyga: morning!
[07:21] <morphis> zyga: pushed two PRs this morning which start introducing things necessary for fedora/suse spread testing
[07:27] <zyga> morphis: I saw, I'm reading one now! :)
[07:29] <morphis> zyga: :-)
[07:32] <zyga> morphis: commented on 3308
[07:36] <pstolowski> morning
[07:37] <zyga> morphis: commented on 3307 now
[07:38] <zyga> o/
[07:39] <zyga> pstolowski: if you remove this part of https://github.com/snapcore/snapd/pull/3282/files#r115504625 we can land that branch right away
[07:39] <mup> PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282>
[07:39] <zyga> pstolowski: then the extra change can be made in a separate PR
[07:40] <pstolowski> zyga, the change from 5 to 10?
[07:40] <zyga> pstolowski: yes
[07:40] <pstolowski> zyga, ok, doing
[07:40] <zyga> thank you!
[07:40] <zyga> morphis: can you do a quick review of (tiny) https://github.com/snapcore/snapd/pull/3262
[07:40] <mup> PR snapd#3262: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
[07:41] <morphis> zyga: sure
[07:41] <zyga> mvo: does https://github.com/snapcore/snapd/pull/3111 need more work or is that a definite +1?
[07:41] <mup> PR snapd#3111: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
[07:41] <morphis> zyga: replied on both PRs
[07:41] <zyga> thanks
[07:41] <mvo> zyga: it fails in tests currently
[07:41] <mvo> zyga: in myserious ways
[07:42] <mvo> zyga: let me have a look at it now
[07:42] <morphis> zyga: done
[07:43] <mvo> zyga: oh, looks like test-failure are gone
[07:43] <mvo> zyga: strange
[07:45] <zyga> morphis: replied
[07:46] <zyga> mvo: I spent some time last night on gardening PRs, maybe that fixed it
[07:48] <morphis> zyga: my point for the package installation barely is, when I add a new distribution I just have to edit a single file and not have to touch hundreds of test cases. If a test case needs a specific package there it should express that in a common way "netcat" and the layers below will map that correctly. The really becomes a maintenance burden. Also respect variants of distribution with different package names etc.
[07:49] <zyga> morphis: that assumes that it is sufficient. My point is that it is a magic assumption that may not hold. What if you need two packages?
[07:49] <zyga> morphis: I bet you will need to edit all files anyway
[07:49] <morphis> why that?
[07:49] <zyga> morphis: and this introduces extra layer that feels wrong
[07:49] <zyga> morphis: because something may be installed by default on one distro and not in another
[07:50] <morphis> zyga: I take this really like an "interface" which has different implementations
[07:50] <zyga> morphis: I think there is no such thing because those packages can have different content
[07:50] <zyga> morphis: (maybe not snapd but certainly true for others)
[07:50] <zyga> morphis: anyway, I think another review is needed
[07:51] <morphis> zyga: so if you express "netcat" and that is shipped by default the apt-get call will either do nothing or we tweak the install function to detect that an do nothing
[07:51] <morphis> right now it falls back to the supplied name but we can also ignore any errors
[07:51] <morphis> zyga: actually it feels wrong to me to express all these distribution specifics in the test cases we have
[07:52] <morphis> zyga: but yeah, lets have another review :-)
[07:53] <mvo> zyga: re the next cloud update - this only happens inside lxd apparently
[07:53] <mvo> zyga: just fyi
[07:53] <zyga> mvo: thanks for the hint!
[07:54] <mvo> zyga: I could not reproduce on a regulra system and kyrofa also could not reproduce the nextcloud failure on a regular system, but it failed for him inside lxd. I will update the title of the post
[07:55] <zyga> mvo: I honestly don't have a good feeling for lxd; I don't use it daily and we don't test it at all so there may be dragons of any sizes lurking inside
[08:01] <Chipaca> TFW you're looking at a test and wondering how it ever passed before
[08:04] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/3289 needs a 2nd review if you are in review mood
[08:04] <mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
[08:05] <Chipaca> zyga: got a lot of MATCH-related state right now
[08:05] <zyga> Chipaca: stay there then :) that branch would be great to land too :)
[08:19]  * zyga -> breakfast
[08:19] <mup> PR snapd#3262 closed: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3262>
[08:22] <morphis> zyga: do you have time today to check https://github.com/snapcore/snapd/pull/3222 again?
[08:22] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[08:27] <zyga> morphis: yes, I certainly will; is the discussion there resolved? I recall gustavo had some questions/comments
[08:27] <morphis> zyga: he didn't responded yet, will ping him as well when he comes online
[08:34] <morphis> zyga: when you have a few min: https://build.opensuse.org/request/show/494796
[08:37] <zyga> morphis: done, you may want to disable leap 42.1 on your branch
[08:38] <morphis> zyga: yeah, this branch will be removed anyway once you merge :-)
[08:39] <morphis> zyga: you had any time for the Yocto review?
[08:42] <zyga> morphis: not quite, it's still open it my tab; I'll do my best to review it before the end of week today
[08:42] <morphis> zyga: we're not in a hurry
[08:43] <morphis> zyga: https://github.com/morphis/meta-snappy/pull/10 will only take a minute :-)
[08:43] <mup> PR morphis/meta-snappy#10: snapd: update to 2.25 release <Created by morphis> <https://github.com/morphis/meta-snappy/pull/10>
[08:52] <morphis> zyga: thanks!
[08:56]  * zyga switches to coding mode
[09:40] <Chipaca> zyga: ping
[09:46] <zyga> Chipaca: yes?
[09:47] <Chipaca> zyga: were you aware that in one of the tests, what used to be “! grep expr /sys/some/file” worked because /sys/some/file did not exist?
[09:47] <zyga> nope
[09:47] <zyga> Chipaca: are you uncovering a can of worms just now?
[09:47] <Chipaca> zyga: /sys/fs/cgroup/devices/snap.test-snapd-tools.env/devices.list in particular
[09:48] <Chipaca> zyga: should I change the test to check for nonexistance directly, or is it conceivable that the file could sometimes exist, depending on test ordering?
[09:48] <zyga> Chipaca: I don't know, let me look at the test quickly
[09:49] <Chipaca> zyga: main/security-device-cgroups/
[09:49] <Chipaca> I think the file is removed by the cleanup, but I don't know if that is mandatory or incidental
[09:50] <Chipaca> and “if [ -e /sys/yadda ]; then MATCH -v expr /sys/yadda; fi” DTRT AFAIK
[09:50] <zyga> Chipaca: that's cgroup, not a real file
[09:50] <zyga> Chipaca: and I don't know how it behaves very well honestly
[09:50]  * zyga looks
[09:50] <Chipaca> sure looks like a file to sh :-)
[09:50] <Chipaca> zyga: meh, then i'll leave the if [ -e
[09:50] <zyga> sure, my point is that cleanup that removes it is whereR?
[09:51] <zyga> I actually didn't read the cgroup code much
[09:51]  * zyga looks
[09:51] <Chipaca> zyga: in the same yaml
[09:51] <Chipaca> udevadm --potato
[09:53] <zyga> udev-support nees some refactoring love
[09:53] <zyga> we spawn a shell for each device /o\
[09:54] <zyga> Chipaca: so this looks like a layered can of worms, can you please add a FIXME there and I will get back to it
[09:54] <zyga> this code has not changed at all since ubuntu-app-launcher
[09:54] <zyga> and that particular test was written by jdstrand
[09:54] <Chipaca> zyga:     # FIXME: this is, apparently, a layered can of worms. Zyga says he needs to fix it.
[09:55] <Chipaca> zyga: (or tell me what to put so you remember)
[09:55] <zyga> so I need to look at it for some time before I can make heads or tails
[09:55] <zyga> Chipaca: yes, that's fine :)
[10:08] <morphis> ogra_: what is the state on https://bugs.launchpad.net/snappy/+bug/1650688 ?
[10:08] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[10:10] <ogra_> morphis, well, i'm not sure mvo's suggestion will work (symlinking a bind-mount) ...
[10:11] <zyga> ogra_: symlinking a bind mount?
[10:11] <morphis> ogra_: just wondering as it was set to be fixed for 2.25 and we now released 2.26 and it is still not fixed and two customers are already asking for it
[10:11] <ogra_> morphis, i guess what could work is to patch systemd to not handle it as link at all and write the data into it ...
[10:12] <ogra_> zyga, https://bugs.launchpad.net/snappy/+bug/1650688/comments/25
[10:12] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[10:12] <morphis> ogra_: so what prevents us from patching systemd?
[10:13] <ogra_> having to carry that patch ...
[10:13] <ogra_> we're just at the point where we can drop systemd from the PPA
[10:13] <morphis> something we could sent upstream?
[10:13] <ogra_> (having it there caused quite some probs regarding libusb (there is a fixed version dependency)
[10:14] <morphis> ogra_: yeah, ran into that problem multiple times
[10:14] <ogra_> morphis, right, it must either be upstreamable or at least suitable for a distro patch we can hand to foundations
[10:15] <morphis> ogra_: argument for distro patch would be already that Ubuntu Core is a first class citizen in our ecosystem, isn't it?
[10:15] <ogra_> yes, but it must still be suitable :)
[10:15] <morphis> sure, so what is the plan, get it fixed for 2.27?
[10:15] <ogra_> we can work towards that, yeah
[10:16] <morphis> just saying, we should fix it by 2.27, this is now delayed for two releases ..
[10:16] <ogra_> right
[10:26] <Chipaca> so, there's an important difference between "grep foo | wc -l" and "grep -c foo"
[10:28] <ogra_> morphis, mvo .... oooh ... http://paste.ubuntu.com/24559979/ we already carry a patch, i guess we just need to adjust it
[10:34] <mup> PR snapd#3309 opened: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
[10:34] <mup> PR snapd#3310 opened: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[10:39] <Chipaca> ogra_: “Forwarded: OMGno, this is a rather nasty hack until we fix system-image to get a writable /etc”
[10:39]  * Chipaca giggles
[10:39] <ogra_> Chipaca, well :)
[10:39] <ogra_> the point is that we have a patch and it doesnt seem to work ....
[10:39] <mup> PR core#39 closed: add version-script <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/39>
[10:40] <zyga> mvo: I just merged the version script, cannot wait to see this in snap list!
[10:40] <ogra_> and i think the reason is:
[10:40] <ogra_> 96         if (r >= 0 && startswith(realfile, "/etc/writable")) {
[10:40] <ogra_> because ...
[10:41] <ogra_> ogra@pi3:~$ ls -l /etc/localtime
[10:41] <ogra_> lrwxrwxrwx 1 root root 18 May 12 04:20 /etc/localtime -> writable/localtime
[10:41] <ogra_> it looks for an absolute name
[10:44] <Chipaca> ogra_: what package is that patch for btw?
[10:44] <ogra_> systemd
[10:45] <Chipaca> ah
[10:48] <Chipaca> ogra_: note that the filename is passed through readlink_and_make_absolute first
[10:48]  * Chipaca looks at how that one works
[10:48] <ogra_> yes, i''m just digging into that ... it calls readlinkat() in the end
[10:50] <Chipaca> ogra_: maybe it should be changed to readlink_and_canonicalize?
[10:51] <ogra_> because that calls chase_symlinks() ?
[10:52] <ogra_> i have the feeling just making the link itself absolute would be sufficient
[10:53] <ogra_> funnily the subsequent link *is* absolute
[10:53] <ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
[10:53] <ogra_> lrwxrwxrwx 1 root root 27 May 11 06:35 /etc/writable/localtime -> /usr/share/zoneinfo/Etc/UTC
[10:54] <Chipaca> ah, fair enough
[10:55] <ogra_> https://github.com/snapcore/core/blob/master/live-build/hooks/08-etc-writable.chroot#L14
[11:00] <mup> PR core#40 opened: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
[11:00] <ogra_> :)
[11:01]  * zyga requests a review for one-liner https://github.com/snapcore/snapd/pull/3310/files
[11:01] <mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[11:02] <zyga> pstolowski: I think you could review this quickly https://github.com/snapcore/snapd/pull/3309/files
[11:02] <mup> PR snapd#3309: interfaces/mount: keep track of kept mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3309>
[11:02] <mup> PR snapd#3311 opened: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
[11:02] <pstolowski> k
[11:02] <zyga> mvo: and this is for you (no C :) https://github.com/snapcore/snapd/pull/3311/files
[11:02] <mup> PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
[11:06] <pstolowski> i'm not sure what's going on with travis test on my #3282.. seems to be infra issue:
[11:06] <pstolowski> Error preparing linode:ubuntu-core-16-64:tests/regression/ : kill-timeout reached, cannot reconnect to linode:ubuntu-core-16-64 (Spread-15) after reboot: dial tcp <IP_ADDRESS>:22: i/o timeout
[11:06] <mup> PR snapd#3209 closed: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3209>
[11:06] <zyga> pstolowski: I:m looking too
[11:06] <zyga> just restarted
[11:06] <zyga> ogra_: question about https://github.com/snapcore/core/pull/40 -- why were those relative in the first place?
[11:06] <mup> PR core#40: make links to /etc/writable absolute <Created by ogra1> <https://github.com/snapcore/core/pull/40>
[11:07] <pstolowski> zyga, I restarted it an hour ago.. with smiliar failure again
[11:07] <ogra_> zyga, i have not idea :)
[11:07] <ogra_> zyga, that patch came originally from pitti irc
[11:08] <zyga> ogra_: maybe he remembers, could you ask him?
[11:08] <zyga> ogra_: just in case we're missing something magic
[11:09] <ogra_> zyga,  but i assume because he expectes readlink_and_make_absolute() to read a link and make it absolute :P
[11:09]  * zyga hates expect tests :(
[11:09] <ogra_> *expected
[11:09]  * zyga goes for lunch and small break
[11:10] <ogra_> zyga, i'm just ruling out the potential that it doesnt with this change ...
[11:10] <ogra_> there is no guarantee it fixes anything
[11:10] <ogra_> and it wont do any harm either (nothing else cares if the link is relative or absolute)
[11:30] <zyga> fgimenez:     - linode:ubuntu-16.04-64:tests/main/interfaces-openvswitch failed here: https://travis-ci.org/snapcore/snapd/builds/231504228?utm_source=github_status&utm_medium=notification
[11:30] <zyga> fgimenez: there's no good information there
[11:30] <zyga> fgimenez: do you know if that is a massive package that has lots of IO during installation?
[11:31] <mup> PR core#40 closed: make links to /etc/writable absolute <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/40>
[11:32] <fgimenez> zyga: i don't think so according to https://travis-ci.org/snapcore/snapd/builds/231504228#L3487 it is just 1820kb
[11:33] <fgimenez> zyga: thanks a lot, i didn't have luck trying to reproduce, will try again
[11:34] <zyga> fgimenez: it's just random, I don't know if the cause is the same
[11:35] <fgimenez> zyga: ok, now with the seed it may be easier to confirm/discard the ordering cause, let's see
[11:35] <zyga> note that it died on timeout so we don't really know what happened :/
[11:50] <zyga> Chipaca: do you know MATCH sometimes works with an argument?
[11:50] <zyga> Chipaca: could it be something as silly as missing -- ?
[11:51] <Chipaca> zyga: stdin handling in that shell might be wonky
[11:51] <Chipaca> zyga: like, if you do a match, the second match finds stdin closed (and so reads the args)
[11:51] <Chipaca> that's an unproven hypothesis right now
[11:51] <Chipaca> but you asked :-)
[11:53] <zyga> thanks
[11:53] <Chipaca> zyga: also, note grep always reads the args
[11:53] <zyga> I think we should grok this, we rely on match too much :)
[11:54] <Chipaca> the problem is that MATCH uses 'cat' to read stdin unconditionally
[11:54] <Chipaca> so if cat is not connected, it hangs
[11:54] <Chipaca> if cat is closed, it doesn't hang
[11:54] <Chipaca> i mean if stdin is closed
[11:54] <Chipaca> because cat returns immediately
[11:55] <Chipaca> zyga: makes sense?
[11:55] <Chipaca> needs testing but makes sense to me :-)
[11:55] <zyga> mhm
[11:55]  * zyga would like to see MATCH in C
[11:55] <Chipaca> wat
[11:55] <Chipaca> no dude
[11:55] <Chipaca> i mean, it can be improved, sure
[11:55] <pstolowski> #3282 failed again, this time on create-key test
[11:56] <Chipaca> and probably should be, but "write it in c" is a whole new class of pain
[11:59] <Chipaca> zyga: my pet peeve with it right now is that sometimes we really need the expressiveness of pcre, but we're stuck with -E
[12:00] <Chipaca> this stdin is just a quirk
[12:00] <Chipaca> (compared to that)
[12:01] <zyga> me nods
[12:01] <Chipaca> heh, somebody kicked off the test suite again
[12:01] <Chipaca> but i'm working through the bugs :-)
[12:02] <Chipaca> (just took me a bit because i didn't have a 32-bit image for local qemu)
[12:02] <zyga> Chipaca: spread.zygoon.pl
[12:02] <zyga> :D
[12:03] <Chipaca> zyga:<PHONE_NUMBER> bytes transferred in 451 seconds (2.55 MiB/s)
[12:04] <Chipaca> my network is lazy today
[12:04] <zyga> lazy as in slow?
[12:04] <zyga> my network is never this fast
[12:05] <Chipaca> yeah, it should be about 4 times that
[12:06] <Chipaca> (on paper i mean; in practice it's usually 2x)
[12:16] <zyga> heh
[12:16] <zyga> so my one character change PR keeps failing
[12:16] <zyga> snap-sign this time
[12:16] <zyga> because expect sucks :/
[12:18] <zyga> what I find surprising is that travis fails way way more often than autopkgtests
[12:18] <zyga> I wonder why that may be
[12:18] <zyga> since the infra is actually dedicated, not shared
[12:19] <zyga> I wonder if I should merge the private-interfaces branch now
[12:19] <zyga> (now == just after release) :)
[12:21] <Chipaca> zyga: which is your one character change PR?
[12:23] <zyga> https://github.com/snapcore/snapd/pull/3310
[12:23] <mup> PR snapd#3310: interfaces/mount: spell unmount correctly <Created by zyga> <https://github.com/snapcore/snapd/pull/3310>
[12:24] <Chipaca> aw, i wanted to see the expect failure
[12:25] <zyga> Chipaca: just killed by timeout
[12:25] <Chipaca> zyga: expect timeout is how expect fails, always
[12:26] <Chipaca> it times out waiting for a match
[12:26] <Chipaca> (well, it can also fail with a syntax error :-) )
[12:27] <Facu> sergiusens_, elopio, reading this https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347 and wondering if it should mention something about https://bugs.launchpad.net/snapcraft/+bug/1670471 or https://bugs.launchpad.net/snapcraft/+bug/1686162
[12:27] <mup> Bug #1670471: Bad message after failed release <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1670471>
[12:27] <mup> Bug #1686162: Support "branch"es in Store responses <Snapcraft:Fix Committed by facundo> <https://launchpad.net/bugs/1686162>
[12:27] <jdstrand> zyga, Chipaca: iirc, once a cgroup is setup the dirs and files stay until after a reboot. I recall trying to cleanup but being unable to. aiui, all you can do is reset the cgroup but the files are still there. it's possible there is a way that I didn't find
[12:29] <zyga> jdstrand: interesting, I will look into this after working on namespaces
[12:31] <pedronis> mvo: hi, I updated the forum entry about the repair assertion to match the state of your branch
[12:31] <mvo> pedronis: thank you very much
[12:33] <Chipaca> man, tests/main/interfaces-openvswitch needs to be hacked into shape
[12:33] <Chipaca> it takes _ages_
[12:33] <Chipaca> (to the point that it often times out entirely)
[12:34] <zyga> Chipaca: yep
[12:34] <Chipaca> in _prepare_
[12:34]  * Chipaca looks
[12:36] <mup> PR core#41 opened: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <https://github.com/snapcore/core/pull/41>
[12:38] <zyga> Chipaca: apt-get install
[12:39] <Chipaca> zyga: maybe it's just that the base prepare takes ages
[12:39] <Chipaca> and this will push it over the edge
[12:39] <Chipaca> zyga: because that apt-get got the stuff in 0s
[12:39] <Chipaca> then, sure, it needs to dance the install dance
[12:39] <Chipaca> but, we probably should bump the prepare timeout overall if it's this close
[12:40] <zyga> can we do that for a particular test case?
[12:40] <mvo> pedronis: also thanks a bunch for your review, I will add the missing test now
[12:41] <Chipaca> zyga: yes
[12:41] <Chipaca> niemeyer: is kill-timeout for the whole test, or separately for prepare and execute?
[12:44] <niemeyer> Yo
[12:44] <niemeyer> Chipaca: for each script individually
[12:45] <Chipaca> niemeyer: and prepare and execute are scripts?
[12:45] <Chipaca> niemeyer: hello! good morning :-)
[12:47] <ogra_> mvo, so that rsyslog removal ...
[12:47] <ogra_> mvo, any opinion yet ?
[12:53] <Chipaca> huh, another test that was psasing who-knows-how
[12:53] <zyga> ogra_, mvo: tests broken because of the version script on core snap
[12:53] <zyga> mvo: specifically tests/main/listing
[12:55] <kyleN> hi ara
[12:56] <Chipaca> mvo: fgimenez: question about tests/main/ubuntu-core-create-user
[12:56] <zyga> hmm
[12:56] <zyga> or maybe not?
[12:57] <Chipaca> mvo: fgimenez: the test currently purports to check that the output of create-user on a managed device (without the --force-managed flag) is “error: while creating user: cannot create user<EMAIL_ADDRESS>[12:58] <Chipaca> mvo: fgimenez: but that's not the output from that command (and it hasn't been that for a while)
[12:58] <Chipaca> I don't pretend to understand how this test passed in the past
[12:58] <Chipaca> but i want to know if the current message is what it should be, in which case i will make the test check for that
[12:58] <Chipaca> and if it ins't, i'll fix the message
[12:58] <Chipaca> mvo: fgimenez for the record the message currently is “error: while creating user: cannot create user: device already managed”
[12:59] <MrGeneral> howdy
[13:00] <MrGeneral> Is it possible to run snap @ debian jessie?
[13:00] <zyga> MrGeneral: hello
[13:00] <zyga> ah standup time
[13:00]  * zyga never remembers debian codenames
[13:00] <zyga> testing is OK
[13:00] <MrGeneral> All good.
[13:00] <zyga> before is too old
[13:00] <MrGeneral> hmhm I see
[13:00] <MrGeneral> so I need to enable testing I guess.
[13:00] <MrGeneral> too old?
[13:00] <MrGeneral> hmhm
[13:00] <pedronis> Chipaca: the test is wrong it seems, it should try the wrong user before it sets up a real one
[13:01] <pedronis> Chipaca: I mean it seems to be mixing up failure modes
[13:01] <zyga> MrGeneral: yes, kernel and systemd and perhaps something else
[13:02] <fgimenez> Chipaca: something is indeed wrong there, is a "$" missing https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L39 ?
[13:02] <Chipaca> fgimenez: hah!
[13:02] <Chipaca> omg
[13:03] <Chipaca> fgimenez: yes, that is missing a $, but, even that does not fail
[13:03] <Chipaca> fgimenez: it never reaches there
[13:03] <Chipaca> fgimenez: (or if it reaches, it isn't enough to time out)
[13:03] <Chipaca> to error out I mean
[13:05] <mup> PR snapd#3312 opened: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <https://github.com/snapcore/snapd/pull/3312>
[13:05] <MrGeneral> Got it, thank you zyga :)
[13:08] <mup> PR snapd#3312 closed: DO NOT MERGE YET: add coveralls.io integration <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3312>
[13:13] <mup> PR snapcraft#1305 closed: Use architectures field which existed in older LXD <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1305>
[13:14] <mup> PR snapd#3313 opened: send things to codecov.io <Created by mvo5> <https://github.com/snapcore/snapd/pull/3313>
[13:16] <mup> PR snapcraft#1249 closed: Add Linux Mint support <Created by nefelim> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1249>
[13:28] <ogra_> morphis, do we have any snap that uses the timedatectl dbus call that i could use to test https://bugs.launchpad.net/snappy/+bug/1650688 ?
[13:28] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[13:29] <ogra_> calling it locally will not use dbus but directly call the tool whihc works fine
[13:29] <morphis> ogra_: not really
[13:30] <ogra_> i'm pretty sure the missing line for /etc/localtime in the interface will also have some effect here
[13:31] <mup> PR snapcraft#1306 closed: recording: record global build-packages installed on the host <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1306>
[13:32] <mup> PR snapd#3314 opened: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[13:33] <mup> PR snapd#3315 opened: rename host's http proxy env vars <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3315>
[13:36] <mup> PR snapd#3316 opened: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
[13:53] <morphis> ogra_: I got a basic qemu snap going which gives me latest git with raspi2 machine and got the kernel from the pi2-kernel snap booting
[13:53] <morphis> ogra_: however didn't got uboot started yet and because of that the kernel fails to find its rootfs
[13:54] <ogra_> push it to edge .... happy to poke at it
[13:55] <diddledan> what is that error supposed to mean?: [Error 21] Is a directory: '/build_corebird/prime/usr/lib/locale' <-- I told it I wanted 'usr/lib/locale' in the prime section of my yaml
[14:02] <ogra_> jdstrand, i'd appreciate a review of https://github.com/snapcore/snapd/pull/3316
[14:02] <mup> PR snapd#3316: make /etc/localtime writable in timezone_control <Created by ogra1> <https://github.com/snapcore/snapd/pull/3316>
[14:03] <mup> PR core#41 closed: limit the version string to 32chars (this is what the store allows) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/41>
[14:09] <zyga> mvo: can you review https://github.com/snapcore/snapd/pull/3314 to unbreak master
[14:09] <mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:24] <pedronis> niemeyer: this is the first issue(s) about auto-connect to address right? https://forum.snapcraft.io/t/what-should-the-auto-connect-logic-be-like/312
[14:26] <zyga> pedronis: one thing that is perhaps related is that I want to add a small tweak to interfaces to give them a way to share more meta-data
[14:27] <zyga> pedronis: we could then share more useful things, like auto-connect 1-no-N flags or anything else we need internally
[14:27] <zyga> pedronis: (and useful things like human readable descriptions we just keep as code comments)
[14:27] <ogra_> niemeyer, in case you feel like reading it https://lists.ubuntu.com/archives/ubuntu-devel/2017-January/039634.html ... (for a boring afternoon or so)
[14:28] <ogra_> niemeyer, thats the discussion about dropping syslog from the distro
[14:28] <niemeyer> ogra_: Can you please mention that in the forum thread? It's good background.
[14:28] <ogra_> yep
[14:28] <niemeyer> pedronis: Yeah
[14:30] <Chipaca> looks like we ran out of travis coin
[14:30] <pedronis> zyga: that's interesting but as niemeyer says on the forum, I think we should start fixing the initial bug before adding stuff
[14:30] <niemeyer> Chipaca?
[14:31] <zyga> pedronis: yes, as I said it's not directly related (my motivation is to get the user visible interface descriptions available in the API) but once we have a hold of the problem and know what to do it may be a handy mechanism
[14:31] <pedronis> at the moment all auto-connecting interfaces are 1-to-N afaik
[14:32] <pedronis> I mean from slot (1) to plugs (N)
[14:33] <mup> PR snapd#3317 opened: many: start implenting "base" snap type on the snapd side <Created by mvo5> <https://github.com/snapcore/snapd/pull/3317>
[14:34] <zyga> pedronis: perhaps
[14:35] <zyga> pedronis: things like gpio and other hardware might not be
[14:35] <zyga> (it may be but might not be)
[14:38] <zyga> we need to land https://github.com/snapcore/snapd/pull/3314 to fix master
[14:38] <mup> PR snapd#3314: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:38] <zyga> please review
[14:42]  * zyga just lands it
[14:43] <mup> PR snapd#3314 closed: tests: allow 16-X.Y.Z version of core snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3314>
[14:48] <ogra_> niemeyer, hmm, is there a way that a non-creator of a topic could set a category in discourse (perhaps via a config option) ...
[14:49] <ogra_> niemeyer, i.e. https://forum.snapcraft.io/t/3g-usb-modems-compatible-with-modem-manager-snap-on-ubuntu-core/582 would fit into "device" but the original creator didnt set it ... would be a cool feature if others could add a category in that case
[14:49] <pedronis> ogra_: let me see
[14:49] <mvo> zyga: nice one, thank you
[14:49] <pedronis> ogra_: done
[14:50] <pedronis> ogra_: I can change categories, it's one of those things discourse grants after some use afaict
[14:50] <ogra_> pedronis, oh
[14:50] <pedronis> part of one of the badges
[14:51]  * ogra_ thought he did earn enough badges yet ... seems not :P
[14:51] <pedronis> ogra_: I got it with "Regular"
[14:51] <pedronis> you should have it too
[14:51] <pedronis> afaict
[14:51] <pedronis> https://forum.snapcraft.io/badges/3/regular
[14:52] <zyga> mvo: OK to land https://github.com/snapcore/snapd/pull/3295 ?
[14:52] <mup> PR snapd#3295: interfaces/builtin: make all interfaces private <Created by zyga> <https://github.com/snapcore/snapd/pull/3295>
[14:52] <pedronis> ogra_:  "You can now recategorize and rename topics..."
[14:52] <niemeyer> ogra_: Yeah, moderators can do it
[14:53] <pedronis> niemeyer: also Regulars
[14:53] <niemeyer> pedronis: Ah, indeed!
[14:53] <niemeyer> discourse++
[14:53] <pedronis> ogra_: click the pencil on the right of topic titles
[14:53] <ogra_> oh man
[14:53] <ogra_> yeah, i can
[14:53] <diddledan> how do I get snapcraft to prime a directory? it's complaining that: [Error 21] Is a directory: 'path I want included'
[14:53] <ogra_> it didnt strike me that i need to edit the headline for it
[14:54] <pedronis> you should click all that is shiny :)
[14:54] <morphis> ogra_: can we change https://bugs.launchpad.net/snappy/+bug/1650688 to be in-progress?
[14:54] <mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[14:54] <ogra_> diddledan, catching the snapcraft guys might be easier on rocket.ubuntu.com
[14:54] <ogra_> morphis, done
[14:55] <morphis> ogra_: thanks
[14:55] <morphis> niemeyer: you have time to have another look on https://github.com/snapcore/snapd/pull/3222 today?
[14:55] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[14:55] <diddledan> really? why have they moved over therE?!
[14:55] <niemeyer> morphis: Yeah
[14:56] <diddledan> I hate this replacing with shiny just because
[14:56] <pedronis> morphis: the icon here seems broken (or a cache issue?):  https://forum.snapcraft.io/badges/101/fedora
[14:56] <morphis> niemeyer: thanks!
[14:56] <diddledan> there wasn't anything wrong with IRC! </rant>
[14:56] <morphis> pedronis: hm, didn't created that badge so not sure where it takes the icon from
[14:56] <morphis> niemeyer: ^^
[14:56] <morphis> pedronis: https://snapforum.s3.amazonaws.com/original/1X/bfb1e013ef4b1f1276a1ca3d38a40a789a056bb8.png -> doesn't exist ..
[14:57] <niemeyer> Wow.. strange
[14:57] <niemeyer> Let me check that
[14:57] <ogra_> diddledan, nobody says there is anything wrong with it (and they are still idling here but probably dont check it as often as rocket)
[15:02] <niemeyer> Apparently I screwed up by removing a reference to the image, and Discourse is smarter than I expected and removed the image that had no references
[15:07] <niemeyer> morphis: Fixed, thanks for the note
[15:08] <niemeyer> pedronis: ^
[15:08] <pedronis> thx
[15:08] <pedronis> I just noticed because I went to the badges page
[15:18]  * niemeyer => lunch
[15:24] <pedronis> niemeyer: we should remember to remove upcoming from stuff that is done (I think you listed that in the process post)
[15:31] <pedronis> mvo: Chipaca: is this resolved  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198 ?
[15:32] <Chipaca> I don't think so
[15:37] <pedronis> niemeyer: mvo: I removed the "upcoming" tag from some stuff that was done
[15:47] <morphis> pedronis: are you planing to solve and implement https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409/4  for 2.27?
[15:48] <pedronis> morphis: yes (https://forum.snapcraft.io/t/next-snapd-2-27/572 )
[15:48] <pedronis> morphis: have a plan, should have PR(s) on Mon or Tue
[15:48] <morphis> pedronis: awesome!
[16:19] <pstolowski> pedronis, do you know from top of your head where do we create 'update-aliases' task? for some reason I can only find it in tests... but not where it's created
[16:20] <niemeyer> pedronis: +1
[16:20] <niemeyer> pedronis: Thanks for cleaning it up
[16:26] <pstolowski> 2017-05-12 15:40:57 Failed tasks: 1
[16:26] <pstolowski>     - linode:ubuntu-16.04-32:tests/main/create-key
[16:26] <pstolowski> 2017-05-12 15:40:57 Failed task prepare: 1
[16:26] <pstolowski>     - linode:ubuntu-16.04-32:tests/main/completion
[16:26] <pstolowski> #3282 failed again ^ ...
[16:38] <pedronis> pstolowski: there is no such task
[16:38] <pedronis> pstolowski: aliasesv2.go has a comment listing all the aliases tasks
[16:39] <pedronis> pstolowski: why the question?
[16:40] <pedronis> pstolowski: ah, update-aliases, it's a backend operation, not a task
[16:40] <pstolowski> pedronis, cause I unexpectedly get this in of the my failing tests; and grepping master gives a bunch of those..
[16:40] <pedronis> lots of aliases tasks end up creating those
[16:41] <pedronis> pstolowski: I fear I need to see the test to help
[16:42] <pedronis> pstolowski: anyway under normal circucmstances (refresh/install etc) it comes from setup-aliases
[16:42] <pstolowski> pedronis, i see. thanks
[16:43] <pedronis> also I misremembered the comment listing tasks is in handlers.go
[16:46] <mup> PR snapcraft#1313 opened: Meta: Version from deb <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1313>
[16:59] <zyga> 2017-05-12 16:53:57 Cannot allocate linode:ubuntu-16.04-64: cannot create Linode disk with ubuntu-16.04-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)
[18:28] <niemeyer> Fixed.. that was Spread-06 FWIW
[18:28] <niemeyer> All others are clean
[18:47] <mup> PR snapd#3295 closed: interfaces/builtin: make all interfaces private <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3295>
[18:47] <mup> PR snapd#3310 closed: interfaces/mount: spell unmount correctly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3310>
[21:43] <mup> PR snapcraft#1314 opened: catkin plugin: add support for rosinstall files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1314>
[22:44] <nacc> sigh, i think i've found a relatively serious issue with the store, on a friday :)
[22:44] <nacc> oh nm, it's a bug in my snapcraft.yaml in the process of renaming a snap
[22:44] <nacc> it does feel like the store should not try to cross-build/upload snaps: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
[22:45] <nacc> snap is git-ubuntu, but the generated snap is usd-nacc, and yet it tried to upload it :)
[22:53] <nacc> hrm, but it does seem like lp is a bit confused: https://launchpad.net/~nacc/+snap/git-ubuntu/+build/37953
[22:54] <nacc> the 'manage this package in the store' url ends up pointing to the wrong snap (the one built, admittedly)