=== Class7_ is now known as Class7
[06:03] <seb128> good morning desktopers
[06:23] <seb128> cyphermox, thx for the wip casper vcs
[06:31] <duflu> Umm hi seb128
[06:31] <seb128> hey there duflu :)
[07:23] <didrocks> good morning
=== ecloud is now known as ecloud_wfh
[07:29] <duflu> Morning didrocks
[07:36] <didrocks> hey duflu
[07:48] <oSoMoN> good morning desktoppers
[07:53] <duflu> Hi oSoMoN
[07:53] <oSoMoN> hey duflu
=== pstolowski|afk is now known as pstolowski
[08:55] <willcooke> Happy Black Friday Eve, consumers
[09:02]  * Laney buys something
[09:03] <willcooke> morning Laney
[09:03] <Laney> what is up willcooke
[09:03] <willcooke> not much.
[09:03] <willcooke> Had the heating on before getting out of bed this morning
[09:04] <Laney> the humanity
[09:04] <willcooke> :)
[09:05] <willcooke> The new carpet in my office is helping though, it's pretty warm in here now and I dont have to wrap a blanket around me
[09:05] <Laney> hahah
[09:05] <Laney> you did that?
[09:05] <willcooke> nah, a man
[09:05] <willcooke> I tried doing carpet once, it was a bit of a mess
[09:05] <Laney> I mean the blanket thing
[09:06] <Laney> my mum once did the carpet in my bedroom
[09:06] <willcooke> Oh, ha
[09:06] <Laney> it sucked
[09:06] <Laney> don't think she used any carpet grips so it sort of shrank
[09:06] <willcooke> Yeah, it was reallllly cold in here before
[09:07] <duflu> Oh, morning willcooke and Laney
[09:07] <willcooke> hi duflu
[09:11] <seb128> re
[09:11] <seb128> hey willcooke Laney didrocks oSoMoN
[09:11] <seb128> how is everyone today?
[09:12] <oSoMoN> hey seb128
[09:13] <oSoMoN> I'm good, how are you?
[09:14] <didrocks> hey seb128!
[09:14] <Laney> hey duflu seb128 oSoMoN didrocks!!!
[09:14] <Laney> all people who I would pick for my football team
[09:14]  * Laney wonders if that is a transferrable cultural reference or not
[09:15] <willcooke> hi seb128
[09:15] <seb128> it makes sense translated in french I think
[09:16] <seb128> oSoMoN, ça va, a bit tired, I've been trying to get up at 6:45am to start early and shift some hours, it makes for more productive days but man, waking up early is not my thing :/
[09:19] <oSoMoN> heh
[09:21] <oSoMoN> I’ve been waking up at 6am for the past month or so, to get work done before the rest of the family wakes up, but it's hard, and the 1.5 hours it buys me go by way too fast, I'd have to wake up at 5am to feel like I'm getting stuff done
[09:25] <oSoMoN> didrocks, I'd welcome your opinion on https://github.com/ubuntu/snapcraft-desktop-helpers/issues/167 , when you have a moment (not urgent)
[09:25] <gitbot> ubuntu issue 167 in snapcraft-desktop-helpers "File open/save dialogs show $SNAP_USER_DATA instead of $HOME when selecting the home shortcut" [Open]
[09:30] <seb128> oSoMoN, need more hours in the day :)
[09:31] <oSoMoN> yeah, and a couple more at night wouldn't hurt either :)
[09:32] <oSoMoN> or maybe I just need to be more efficient
[09:34] <seb128> I don't think you are being un-efficient, it's just tricky to fit so much to do in a day
[09:37] <seb128> oSoMoN, I commented on the desktop helper issue, to me it sounds like it's not desktop specific but rather deciding what's the right userdir to point to by default and that also apply to command line utilities
[09:38] <seb128> I mean the right default when the real user dir is available through an interface
[09:38] <didrocks> oSoMoN: yeah, I was wondering about that one for a while, still in a HO with j_ibel working on the installer. Mind if I think about it for EOW?
[09:38] <didrocks> we need to think about potential impacts though, but I agree with seb128
[09:39] <didrocks> unsure about impacts in "HOME"/.* files
[09:39] <seb128> oSoMoN, it would be the same question to ask where a screenshot application should store the file by default for example
[09:39] <oSoMoN> yeah
[09:39] <seb128> yeah, also ~/.<nnn> are blocked by default I think
[09:39] <seb128> so changing the return of the glib function might lead to have apps trying to write configs to dir they can't access
[09:40] <didrocks> exactly
[09:40] <didrocks> hence "we need to test/think about the impacts" ;)
[09:40] <didrocks> but in the file opener, that would be great
[09:40] <didrocks> unsure how we can decorellate those
[09:41] <seb128> gtk patch :p
[09:41] <oSoMoN> snaps connected to the home plug would expect files to be save to the real $HOME by default I guess, but we need to be wary of this interfering with writing/reading config files (many apps still check/fallback to $HOME/.config instead of using the XDG user dirs spec)
[09:41] <didrocks> decorrelate*
[09:41] <didrocks> yeah… patch
[09:42] <oSoMoN> a gtk patch for just the file dialogs would be easy and self-contained, but how likely is it to be accepted upstream?
[09:42] <seb128> we can try suggesting one
[09:42] <seb128> I've a feeling it's going to be "thanks but no thanks" though :p
[09:42] <didrocks> yeah, they will say, it's a portal thing
[09:43] <didrocks> and everyone should use the standard API for getting through the portal
[09:43] <didrocks> so your java app or whatever… :/
[11:25] <juliank> Trevinho: I actually prepared a fix for the nautilus crash, but I get all sorts of hunk formatting changes due to using quilt vs whatever you used, so I'll leave it to you to remove the extra g_object_unref at the end of recent_thread_func
[11:26] <juliank> seems you forgot to remove the unref when converting the declaration of the variable to autoptr
[11:26] <Laney> it's gbp-pq
[11:29] <juliank> Laney: i thought so
[11:29]  * juliank should have looked at Vcs-git
[11:30] <Laney> :>
[11:30] <juliank> Let me upload that fix then
[11:32] <Laney> might want to do a merge proposal to get it reviewed
[11:35] <juliank> doing so
[11:36] <Laney> 😘
[11:37] <juliank> Laney: did you type an emptyl ine, or do I have a unicode problem?
[11:37] <Laney> I'd say the second one
[11:37] <juliank> ugh
[11:38] <Laney> it could be that *I* have one of those though
[11:38] <juliank> I'm running weechat from stretch-backports in a tmux, and both of that is in a proot on a centos6 system
[11:39] <juliank> I see it in the log file
[11:39] <Laney> 🤷
[11:41] <Laney> if you want to be fully millenial compliant then you should fix that :P
[11:41] <juliank> I'll try
[11:42] <Laney> that setup sounds interesting though
[11:42] <juliank> here's the merge: https://code.launchpad.net/~juliank/ubuntu/+source/nautilus/+git/nautilus/+merge/359188
[11:42] <juliank> Laney: it is
[11:42] <juliank> Laney: I'm considerign switching from shared hosting to a vps
[11:43] <Laney> thx, I'll request Marco on that
[11:46] <juliank> oh it's my tmux
[11:47] <juliank> hell, it's actually mosh
=== cpaelzer__ is now known as cpaelzer
[12:43] <andyrock> seb128: I was taking a look at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1796622
[12:43] <ubot5> Ubuntu bug 1796622 in network-manager (Ubuntu) "NetworkManager IPv6 DAD lifetime behavior introduce security risk" [High,Confirmed]
[12:44] <andyrock> wouldn't be better to wait for upstream to release 1.12.6 ?
[12:44] <andyrock> not sure what's their timeline
[12:46] <seb128> andyrock, that's not their current stable serie so unsure they plan to even do that
[12:48] <seb128> andyrock, there has been a CVE fix is there so maybe it would make sense to ask them if they plan to get a .6 out?
[12:48] <andyrock> let me ask
[12:51] <andyrock> kk I asked on #nm if they're planning a new 1.12 release and what's the timeline (if any)
[13:02] <andyrock> seb128: "let's do 1.12.6 then either tomorrow or next week." that's what they told me
[13:02] <seb128> andyrock, \o/
[13:03] <seb128> andyrock, where did you ask? they have an irc channel?
[13:03] <andyrock> seb128: #nm
[13:03] <seb128> ah, you said that, #nm
[13:03] <andyrock> seb128: do you know if we're going to switch to nm 1.14 in disco?
[13:03] <seb128> yes
[13:03] <seb128> possibly directly 1.15
[13:04] <andyrock> he just said that 1.16 is close
[13:04] <andyrock> we might consider it
[13:05] <seb128> I was expecting them to follow GNOME's schedule and just start on 1.15?
[13:06] <andyrock> for what I understand 1.15 is a dev release?
[13:10] <andyrock> seb128: so bionic is using nm 1.10.6 and there is already a nm 1.10.14 release with the fix
[13:11] <andyrock> what should we do?
[13:11] <andyrock> release the new version or keep the changes to the minimum (so releasing  1.10.6-2ubuntu2)
[13:24] <seb128> andyrock, we should update n-m to current 1.10 in bionic, unsure if we consider that ipv6 bug important enough to go by itself in a SRU round before though, I would like to get willcooke's/security team opinion about that
[13:24] <seb128> andyrock, I can handle the 1.10 update in bionic if we go for the full version update directly
[13:25] <willcooke> Reading along in #nm sounds like that 1.10 update could be done pretty soon, right?
[13:28] <andyrock> it's already released so should be quick
[13:31] <willcooke> If there won't be weeks of delay, then seems reasonable to go directly to the new nm instead of SRUing and then SRUing again
[13:37] <seb128> willcooke, you clearly having more confidence than me than doing a jump of 6 versions including new feature is going to go smoothly through without any regression/verification issue on the way :)
[13:39] <Laney> not covered by the SRU exception though, so you get to do separate convincing of the team that it should go in
[13:42] <willcooke> Well, that's makes the decision a bit easier then :)
[13:43] <seb128> willcooke, you just changed your mind? ;)
[13:43] <willcooke> yeah
[13:43] <seb128> haha
[13:43] <willcooke> I'm sure that the ipv6 issue was important, so lets move forward with that at least
[13:44] <seb128> k, good
[13:44] <willcooke> I'm running o_SoMoN's  PPA, so far it's been ok, except for some wifi funnies yesterday.  I need to go mobile though and test on a few different wifi Aps
[13:45] <willcooke> APs
[13:45] <willcooke> perhaps a trip to the office and back
[13:45] <willcooke> Train wifi, coffee wifi, office wifi, and back again
[13:45] <seb128> :)
[13:45] <willcooke> I'll do that next week
[13:45] <willcooke> I nice little day out
[13:48] <oSoMoN> andyrock, seb128: 1.10.14 for bionic is in https://launchpad.net/~osomon/+archive/ubuntu/nm-lp1754671/+packages , if you feel adventurous and want to give it some testing
[13:48] <willcooke> please do :)
[13:48] <andyrock> seb128: I created a gbp repo for network manager
[13:49] <andyrock> should we use it?
[13:51] <seb128> andyrock, https://git.launchpad.net/network-manager/log/?h=bionic ?
[13:51] <seb128> or what do you mean "created"?
[13:51] <seb128> you mean you have a branch for the update?
[13:51] <seb128> oSoMoN, was that the one to test the other fix you handed to will yesterday?
[13:52] <oSoMoN> seb128, yes
[13:52] <seb128> k
[13:53] <andyrock> seb128: ah there is already one nice. I could not find it
[13:53] <seb128> my pesonal preference would go to do several rounds, starting by one including just important/safe changes that can be verified
[13:53] <oSoMoN> that sounds reasonable
[13:54] <seb128> andyrock, tip on that, usually you can start by looking to Vcs- info in debian/control
[13:54] <seb128> (or use debcheckout which does that)
[13:54] <oSoMoN> the fix for bug #1754671 requires pretty intrusive changes that cannot be easily cherry-picked on top of 1.10.6, though
[13:54] <ubot5> bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,Confirmed] https://launchpad.net/bugs/1754671
[13:55] <oSoMoN> but maybe bug #1796622 is easier in that regard?
[13:55] <ubot5> bug 1796622 in network-manager (Ubuntu) "NetworkManager IPv6 DAD lifetime behavior introduce security risk" [High,Confirmed] https://launchpad.net/bugs/1796622
[13:58] <andyrock> oSoMoN: it's not super-clear which commits need to be cherry-picked
[14:00] <seb128> andyrock, oSoMoN, k, I try to have a look to what we can include in that first round of SRU, I probably do that next week
[14:00] <seb128> I let you know
[14:04] <Laney> it's risky in a different way, that gives you combinations of changes that haven't been tested together - and if the cherry-picks aren't clean then you have the chance of introducing new bugs
[14:06] <seb128> right, it depends of what you include in the SRU
[14:06] <seb128> I was going to do a first one with some segfault & obvious fixes
[14:06] <seb128> landing more complex changeset is trickier indeed
[14:07] <seb128> also easy/selected fixes make it easy to go through SRU review & validations
[14:07] <seb128> when including new versions with a stack of changes without LP bugs is going to be more challenging
[14:07] <seb128> especially without ffe
[14:07] <seb128> standaing exception I mean
[14:07] <Laney> k
[14:09] <Laney> sounds from what the people who looked at the bugs that are targetted were saying like they are not easy to take in isolation
[14:09] <seb128> yeah, that's probably true for the main ones we discussed in the rls- bugs reviews
[14:09] <seb128> looking at the NEWS from those updates there are also a bunch of other LP bugs fixes that are segfaults and such
[14:10] <seb128> no ideal situation, maybe trying to go for the full set directly is more efficient (though more likely to lead to nothing landing and the obvious bugs to not get fixed soon)
[14:11] <Laney> not sure about the bracketed part, I would think that something could be worked out with the SRU team
[14:11] <Laney> or on the other side confirmation that it would be a problem
[14:12] <Laney> anyway, it's not me doing the work, so just my empty opinion
[14:15] <seb128> thx for the input
[14:15] <seb128> but yeah, I'm not too concerned about the SRU team
[14:15] <seb128> it's just a matter of doing enough paperwork to please them basically
[14:16] <seb128> it's just that we don't have high confidence atm that some of those complex changesets are going to be validated without regression
[14:16] <seb128> if it turns out they break some usecase/have some issues that's going to rightly block the SRU
[14:17] <seb128> we really need to find/hire a n-m maintainer :)
[14:17] <Laney> k, I would argue that taking a random mix of commits is also quite risky too
[14:17] <Laney> going for lunch now, see you
[14:17] <seb128> true
[14:17] <seb128> enjoy!
[14:30] <seb128> tjaalton, unsure if you saw, but the xserver-xorg-video-intel sync from Debian is blocked in disco-proposed because it makes xserver-xorg-video-intel-hwe-18.04-dbg uninstallable ... unsure if that should be delete from disco, updated, ...?
[14:31] <tjaalton> seb128: I'll check
[14:31] <seb128> thx
[14:31] <tjaalton> -dbg should probably be removed
[14:37] <tjaalton> new xorg-lts-transitionals uploaded, should fix this
[14:40] <seb128> tjaalton, thx!
[14:54] <andyrock> didrocks: do you mind creating an ubuntu-dock-cosmic branch?
[14:54] <andyrock> I don't have write permissions
[15:28] <didrocks> andyrock: sure, one sec
[15:28] <didrocks> andyrock: based on which commit?
[15:28] <didrocks> sorry, still in the HO, so not responsive :p
[15:29] <andyrock> https://github.com/micheleg/dash-to-dock/commit/73297451a0941a4c5bd98760bfd860ce7f284701 ?
[15:29] <didrocks> ack
[15:29] <didrocks> oh
[15:29] <didrocks> I can't either btw
[15:29] <didrocks> you need to ask Michele
[15:29] <didrocks> as he's the branch owner
[15:29] <andyrock> kk I'll send him an email
[15:56] <seb128> willcooke, did you have issues on bionic with your iphone, like it not being detected/properly handled if you disconnect it from the computer and plug it in again?
[15:56] <seb128> jbicha, congrats for making it to lwn :p
[15:57] <seb128> the man who screwed the debian non-main-arches :)
[16:01] <willcooke> seb128, nope, it just worked
[16:01] <willcooke> seb128, as far as browsing photos went
[16:01] <seb128> willcooke, :/
[16:01] <willcooke> I'll see if elmo is in the office next week when/if I go in, he's not replied to my mails
[16:01] <seb128> willcooke, well, the device should not be seen after being disconnected/reconnected, but that's for those which needs ubmuxd which might be only more recent models
[16:02] <seb128> willcooke, the issue I was talking about is another one I just did a SRU for (bug #1778767)
[16:02] <ubot5> bug 1778767 in usbmuxd (Debian) "iPhone doesn't charge when plugged in after disconnect" [Unknown,New] https://launchpad.net/bugs/1778767
[16:02] <seb128> or maybe it's the same and I didn't understand the problem from elmo when you described it
[16:07] <willcooke> one sec, let me try it
[16:07]  * willcooke goes to look for a cable
[16:10] <willcooke> Plugged in phone, phone told me to unlock to use the accessory
[16:10] <willcooke> unlocked and phone is chargine
[16:10] <willcooke> g
[16:11] <willcooke> and I can see photos
[16:11] <seb128> I guess by "doesn't charge" it means "isn't being handled"
[16:11] <seb128> good
[16:11] <seb128> can you eject/disconnect and try to plug it again now?
[16:11] <willcooke> I need to reconnect it now to see if it will still charge
[16:11] <willcooke> ah
[16:12] <willcooke> it made the charging noise, but it isnt actually charging
[16:13] <willcooke> trying the work around from: https://ubuntuforums.org/showthread.php?t=2376741&p=13722029#post13722029
[16:13] <willcooke> and yes, the work around makes it charge again
[16:13] <willcooke> so legit
[16:13] <willcooke> It could be that's what elmo's problem was all along
[16:13] <willcooke> I will verify that fix once it's in proposed
[16:17] <seb128> great, thx for testing
[16:17] <seb128> will ping you again once the SRU is approved :)
[16:17] <willcooke> glad to be of service
[16:23] <jbicha> seb128: I sign autographs for a nominal charge ;)
[16:24] <seb128> hehe
=== caravena_ is now known as caravena
[18:23] <willcooke> night all
=== pstolowski is now known as pstolowski|afk