[00:59] <kenvandine> jbicha, it was for backports of 3.24 for the gnome platform snap for xenial
[01:00] <kenvandine> we need to build debs in a ppa and build the platform snap from it
[01:11] <jbicha> kenvandine: oh neat, will that work?
[02:15] <Trevinho> muktupavels: yes... + shell
[02:36] <duflu> robert_ancell: If lightdm runs on Xorg right now, what will it run on in future?
[02:36] <duflu> Native DRM?
[02:37] <robert_ancell> duflu, well, it doesn't run on Xorg, but it launches it for the sessions
[02:37] <robert_ancell> The sessions can also run on u-s-c (RIP) and nothing (i.e. Wayland)
[02:39] <duflu> robert_ancell: Yeah that's what got me thinking. Mir/USC provided a future base for lightdm to run on. Now that's gone... you need the same foundations as gnome-shell itself. Which becomes tricky with Nvidia-binary surely
[02:39] <robert_ancell> duflu, yes, gnome-shell on Wayland requires the new Nvidia drivers, the old binary stuff will never work
[02:40] <duflu> Also, if lightdm isn't using Xorg, why is Xorg running before I log in? Just for the transition animation?
[02:43] <duflu> robert_ancell: It appears to me lightdm is running on Xorg:
[02:43] <duflu> root      1046  0.0  0.3 312204 56164 tty7     Ssl+ 09:52   0:00 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[02:43] <robert_ancell> duflu, unity-greeter is an X based greeter, so it uses Xorg
[02:43] <duflu> Oh
[02:44] <duflu> I recall you already had native DRM backends so I guess that's what we'll use
[02:44] <duflu> a native DRM backend
[02:46] <duflu> I guess we just rely on every driver supporting KMS (and dumb buffers?)
[02:46] <robert_ancell> yes
[03:01] <duflu> I still need to get used to the idea that Wayland is attempting to solve fewer problems than Mir
[05:53] <RAOF> Yup. We were quite ambitious!
[06:37] <didrocks> good morning
[07:44] <duflu> Morning didrocks
[07:44] <didrocks> hey duflu
[07:44] <duflu> \o....
[07:44] <duflu> ....o/
[07:45] <duflu> Hmm, no that just looks like two people drowning
[07:46] <didrocks> :p
[08:01] <willcooke> morning
[08:02] <Laney> HI
[08:03] <Laney> willcooke: good meal/
[08:03] <Laney> ?
[08:04] <andyrock> good morning
[08:06] <didrocks> hey willcooke, Laney
[08:07] <willcooke> Was great!  I had pie & chips.  Goooooood pie.
[08:09] <RAOF> Hey didrocks, willcooke, Laney!
[08:09] <willcooke> Howdy RAOF
[08:09] <didrocks> morning RAOF!
[08:10] <RAOF> Hey ho yay!
[08:13] <Laney> hey didrocks hey RAOF hey andyrock!
[08:13] <Laney> how are you all?
[08:13] <Laney> happy friday / end of friday depending on your upside down state
[08:14] <RAOF> I've got a sleeping baby strapped to my chest, so that's nice.
[08:14] <willcooke> :) Saw the pics on Twitter :)
[08:15] <RAOF> Although she seems to have decided to start pulling out my chest hair, which is less excellent.
[08:15] <Laney> Saves money on going to get it waxed
[08:16] <didrocks> I'm good! rainy Friday, but we'll live with it :)
[08:16]  * didrocks is lost on amazon doc
[08:16]  * Laney got very wet last night
[08:16] <Laney> but 16 sweetcorn went in
[08:17] <didrocks> argh :) I was at the Golang meetup yesterday, and escaped the rain just when walking back!
[08:18] <Laney> \o/
[08:19] <seb128> good morning desktopers
[08:19] <didrocks> hey seb128
[08:19] <willcooke> salut seb128
[08:19] <willcooke> mange tout
[08:19]  * willcooke embraces the culture you know
[08:20] <seb128> re didrocks, hey willcooke Laney RAOF andyrock
[08:20] <RAOF> Hey, and a bonus Seb!
[08:21] <didrocks> willcooke: desktop team never had that many frenchies :p
[08:22] <willcooke> :))
[08:22] <seb128> RAOF, I saw the picture, how old is your baby now?
[08:23] <RAOF> seb128: she's 6 weeks on Sunday!
[08:23] <didrocks> waow, didn't know, congrats RAOF :)
[08:24] <seb128> RAOF, nice, and congrats :-)
[08:24] <flexiondotorg> Morning desktopers
[08:24] <RAOF> Thanks!
[08:24] <Laney> hey seb128!
[08:24]  * RAOF should really send a warthogs email.
[08:25] <oSoMoN> good morning
[08:30] <willcooke> morning oSoMoN
[08:30] <oSoMoN> hey willcooke
[08:38] <seb128> hey oSoMoN
[08:42] <oSoMoN> hey seb128, how goes?
[08:46] <duflu> Wow. There are important things on warthogs. I hadn't looked in months
[08:46] <willcooke> evening duflu
[08:47] <duflu> willcooke: Morning
[08:47] <willcooke> s/evening/afternoon
[08:47] <duflu> Happy this side of the sun
[08:47] <duflu> For some months
[08:48] <duflu> Just don't have an existential crisis wondering what "side of the sun" means
[08:48] <duflu> Because it's relative
[08:49] <seb128> oSoMoN, good! you?
[08:50] <oSoMoN> seb128, yeah, very good. Sun is shining and it’s Friday, what could go wrong? :)
[08:51] <oSoMoN> and with any luck
[08:51] <oSoMoN> my house will be finished and I can move in just before summer
[08:56] <duflu> koza: Would you suggest laptop radios are more reliable than cheap USB radios?
[08:56] <duflu> :)
[08:59] <muktupavels> Trevinho: https://git.gnome.org/browse/mutter/tree/src/ui/theme.c#n739
[08:59] <muktupavels> Trevinho: 1031 / 2 = 515 and when cairo scales up you get 1030.
[09:03] <koza> duflu, hey
[09:03] <koza> duflu, what do you mean by more reliable?
[09:04] <duflu> koza: I'm wondering if I would hit fewer unrelated bugs on an Intel wifi chip compared to a dirt cheap USB dongle
[09:04] <koza> duflu, the laptop radios might be even cheaper ;-)
[09:04] <koza> duflu, ah, so this is wifi not bt?
[09:05] <duflu> koza: Bluetooth
[09:05] <duflu> I mean I can confirm A2DP is silent on startup, but also multiple other problems that make it really hard to separate single issues
[09:06] <duflu> Although I would hazard a guess that's just old (xenial) Pulse
[09:08] <koza> duflu, I'm using laptop radio and a usb dongle at the same time. been using usb dongles exclusively previously and never had more issues with any. of course depends on controller however I have not been buying a fancy ones - just whatever is in the store. there might be issues though when laptop radio is a combo one and supports wifi and linux at the same time. coexistence might cause throughput issues.
[09:08] <duflu> koza: OK thanks. I won't bother switching from desktop to a laptop then
[09:09] <duflu> These past few weeks have already taught me to trust bluez more than pulseaudio
[09:09] <koza> duflu, no, does not make sense. easier with dongles especially if you have a few that differ by controller manufacturer: broadcom, csr, etc.. then you get a nice market coverage.
[09:09]  * duflu checks
[09:10] <koza> duflu, haha :-) bluez and bluetooth in general is suprisingly healthy (and they said it will die by 2020)
[09:10] <duflu> koza: I'm looking at xenial though. :)
[09:10] <koza> :-)
[09:11] <duflu> koza: Heard of ISSC?
[09:11] <koza> duflu, no, what is it?
[09:11] <duflu> koza, my chip manufacturer
[09:12] <koza> international seismic safety centre?
[09:12] <koza> ah :D
[09:13] <koza> duflu, do you know that you can dig the details of your controller like supported profiles, versions, etc on the Bluetooth website?
[09:16] <duflu> koza, Yes, but I would not rely on a chip spec given all the software in the middle. It's likely and apparent there are multiple software problems
[09:20] <koza> duflu, true but in case you would like to know what to expect from your dongle or product. this is useful then.
[09:20] <duflu> koza: Unrelated: I encounterd major problems a few years ago with CSR when I was fixing an Apple Magic Touchpad bug. Do you still find CSR a problem?
[09:20] <duflu> Turned out all other users with CSR had problems
[09:21] <duflu> So I never plugged CSR in again
[09:21] <koza> haha :-)
[09:22] <koza> did that touchpad had problems only with csr?
[09:25] <duflu> koza: CSR was just super glitchy and created secondary bugs. With other dongles the glitches stopped and I could work on the real bug
[09:26] <duflu> ... in the touchpad driver
[09:26] <duflu> IIRC, CSR just fell over if you asked it to transmit four touches concurrently
[09:28] <duflu> Bandwidth profile = soggy shoelace
[09:41] <koza> now i understand why you dislike csr
[09:50] <duflu> Whee, Friday night monsoon
[09:51] <koza> good or bad?
[09:52] <duflu> Heavy and wet
[11:29] <willcooke> Laney, thanks for your comments on the newsletter.  What is the usual route for folk going from LTS to non-LTS after the intermediate releases are EOL?  I don't think I've ever done that.  Should it be supported?
[11:30] <Laney> willcooke: You know I thought about that and I'm not sure - I guess that the route is by skipping the EOLed release
[11:31] <Laney> I think it has to be supported or else you can't get off 16.04 to 17.04 after 16.10 goes EOL
[11:31] <Laney> I don't know if this has historically been tested though ...
[11:31] <Laney> jibel: ^- do you know?
[11:35]  * flocculant thought it was tested when you changed support length to 9 months - but not seen anything since then
[11:35]  * flocculant is interested though
[11:36] <Laney> I don't expect it's a hugely used upgrade path
[11:37] <Laney> but still, should be kept working
[12:06] <jibel> Laney, it is not supported IIRC, but I don't remember how they are supposed to upgrade. There was some doc on the wiki, let me check
[12:15] <jibel> Laney, https://help.ubuntu.com/community/EOLUpgrades
[12:15] <jibel> willcooke, ^
[12:15] <jibel> i'll try it
[12:15] <willcooke> thansk jibel
[12:17] <Laney> jibel: That's about when the release you're on goes EOL isn't it?
[12:24] <jibel> Laney, yes, but it should work for LTS too, if you switch from LTS to LTS to LTS to Normal release upgrade
[12:24] <Laney> It's talking about manual hacking of sources.list and stuff
[12:27] <jibel> Laney, yeah, let me try
[12:27] <jbicha> you might want to ask bdmurray too about your non-LTS upgrade questions
[12:29] <Laney> Doubt he's up at 05:29
[12:29] <jibel> Laney, in any case you can either upgrade from LTS to LTS or release to release +1
[12:31] <Laney> I can believe we might say that LTS to intermediate release apart from the next one isn't supported
[12:36] <jbicha> I don't have the chat log, but I think bdmurray told me recently that once 16.10 is EOL, you'll be able to just upgrade straight from 16.04 to 17.04
[12:38] <Laney> There's also a window where you'd be able to go from 16.04 -> 17.10
[12:39] <seb128> is anyone really testing those/making them work?
[12:39] <Laney> Both answers are fine, but if it's that they are supported paths then they should be tested
[12:39] <seb128> we usually just do n to n+1 or lts to lts+1
[12:39] <Laney> seb128: That's the conversation.
[12:39] <seb128> right, sorry if that was too subtle as a comment
[12:39] <seb128> I wanted to say
[12:39] <seb128> "I don't think we do work on making sure upgrades to n+>1 work"
[12:40] <seb128> I understood that was the topic :-)
[12:40] <Laney> ya
[12:40] <Laney> That's why I pinged j i b e l about it mainly
[12:40] <Laney> he might have said "yeah we totally test that, there has never been a bug"
[12:40] <seb128> one can wish :-)
[12:41] <Laney> tbh I don't expect that many bugs from doing it
[12:41] <seb128> there doesn't need to be, one package conflict is enough to make an upgrade derail
[12:42] <Laney> I know, but those kind of things are usually kept until the next LTS
[12:42] <Laney> because you have to support that upgrade path already
[12:42] <seb128> yeah, but sometime package are renamed and renamed again
[12:42] <seb128> and the intermediate name was not in the LTS
[12:42] <Laney> I get there are cases where bugs could happen
[12:42] <seb128> so it's required
[12:42] <Laney> I'm just saying that I don't expect there to be that many in reality
[12:43] <seb128> we had cycles where we looked at n -> n+3 for whatever reason I don't remember now, it has been a while
[12:43] <seb128> it's not a lot of work to get working
[12:43] <seb128> but there was some work involved
[12:43] <seb128> resolver issues, some conflicts
[12:44] <Laney> we'll need that now, it's an issue for this problem
[12:44] <seb128> so if we want that to be reality supported I think we need to account some work for it
[12:44] <Laney> it's just work that comes up on a 2 year cycle
[12:44] <seb128> do we delete unsupported series from the archive?
[12:45] <seb128> because even if 16.10 is not on support anymore, if upgrading though was working and the archive doesn't change there is no reason it should stop working
[12:45] <Laney> you're suggesting hopping through unsupported releases?
[12:45] <seb128> so that might still be easiest way to tell people to do that jump
[12:45] <Laney> what if you expose yourself to a security bug in the meantime?
[12:45] <Laney> sorry, lunch is ready, back in a bit
[12:46] <seb128> that's a tradeoff I guess
[12:46] <seb128> I'm not saying it's the right solution, just listing our options
[12:46] <seb128> enjoy lunch!
[12:46] <jbicha> since we're talking upgrades, was it an intentional decision for us to disable ppas on updates, but not try to run ppa-purge?
[12:46] <seb128> yes
[12:47] <seb128> we disable ppas because they add an unstable variable to the upgrade path and it makes things more like to go wrong
[12:48] <seb128> enabling ppa-purge could be a valid wishlist, it would need to be a tool we officially support/ship/trust
[12:48] <jbicha> right, it would need a MIR
[12:48] <seb128> and to be tested/trusted enough
[12:48] <seb128> does it always work? can it lead to uninstall part of your system?
[12:48] <jbicha> but I think it's a major reason why upgrades fail and users don't trust Ubuntu upgrades because they expect Ubuntu to handle those details for them
[12:50] <seb128> right
[12:50] <seb128> go explain to users that it they use ppas they sign in for such issue
[12:51] <seb128> hopefully snaps solves that for us
[12:53] <jbicha> our solution is that they should run ppa-purge first, but instead of telling people to do something in documentation somewhere, I think we should just look at doing it for them
[12:53] <seb128> how does ppa-purge work?
[12:53] <jibel> well, common PPAs are xorg edgers or Gnome, the problem will take time to solve with snaps
[12:54] <seb128> does it require the ppa to still exist to look at its status/list of packageS?
[12:54] <jbicha> maybe with a prompt, like the "do you want to remove these obsolete packages?" to "do you want to downgrade these packages to official Ubuntu versions"
[12:55] <jbicha> yes, unfortunately, the ppa must still exist with all its packages for that series for ppa-purge to successfully purge everything it is supposed to
[12:55] <jbicha> but even if it only helps some cases, it would still help
[12:56] <jbicha> it checks what packages the ppa provides and then downgrades those to the system versions
[12:56] <jbicha> maybe ubuntu-release-upgrader could just check *all* packages?
[12:57] <seb128> anyway, that would be a welcome improvement if somebody wants to work on that
[12:57] <seb128> I don't think we have much people working on the upgrade tools nowadays
[12:57] <jibel> it is not that trivial as the PPA can install dependencies that are not in the archive and you'll quickly enter a dependency nightmare
[12:57] <seb128> right
[12:57] <seb128> even downgrades are not safe
[12:58] <seb128> if packages moved between binaries then the Conflicts/Replaces are not adapted for the reverse way
[12:58] <jibel> especially if you're on an old release and installed the latest fancy packages from a PPA
[12:58] <seb128> if files moved*
[12:58] <jibel> including core packages like the display server
[12:58] <jibel> absolutely
[12:59] <seb128> not to mention that new versions of e.g GNOME might write user configs that the version you downgrade to can't understand
[13:00] <seb128> imho the easiest way to support those users is for ppa owners to test upgrades from their ppa to new ubuntu series and fix issues
[13:00] <jibel> An option would be to have proper documentation, detects if packages from a PPA are installed, point the user to the doc and let him take an informed decision "1. Upgrade without PPA 2. Cancel and fix the situation manually"
[13:01] <jbicha> jibel: that would at least be better than now where the upgrader apparently assumes that the only thing in PPAs is backports from the very next Ubuntu release
[13:49] <jbicha> Laney: https://git.gnome.org/browse/gnome-software/commit/?id=974cc2a79 isn't very useful now that we're switching to GNOME
[13:49] <jbicha> we could go back to https://git.gnome.org/browse/gnome-software/commit/?h=wip/ubuntu-3-22&id=4c6ea9310
[13:50] <Laney> what is the problem it causes?
[13:50] <jbicha> do we want to see "Software Updates Available" notifications from GNOME Software or not?
[13:52] <Laney> Yes
[13:52] <Laney> I think it should not offer updates to distribution packages though.
[13:52] <Laney> As long as we have update-manager
[13:57] <davmor2> Laney No no you don't because gnome will only update certain bits not the whole system as I found out so you might think you are up-to-date and safe and not be in reality :P
[13:57] <jbicha> ok, so we should just drop that patch for now then?
[13:57] <davmor2> Laney: also it will get confusing when you get pings from two places as to if there is an update or not :D
[13:57] <jbicha> davmor2: could you file a bug with more details about that?
[13:58] <davmor2> Nope on holiday only have my laptop so I can view pre-course videos :)
[13:58] <jbicha> davmor2: part of the problem is that GNOME Software can update things that update-manager can't, like firmware, Flatpaks, snaps
[13:59] <gQuigs> aiming for Gnome Software to be the one and only updater makes sense to me..  not sure how much work that is
[13:59] <Laney> Enough
[13:59] <Laney> jbicha: I don't see why you would
[13:59] <davmor2> jbicha: from memory I've had gnome software telling me there was one update and on update manager there were 120 so hard to tell what it is finding and not finding
[13:59] <Laney> But if you really want to make Unity users have a fallback dialog then you can
[14:00] <seb128> it's not quite there though
[14:00] <jbicha> Laney: the patch doesn't do anything except hide notifications on Unity which doesn't seem to make much sense now
[14:00] <seb128> I think we should keep "software updates available" notifications off
[14:01] <seb128> it's always misleading/noisy
[14:01] <jbicha> teaching gnome-software to hide distro upgrades sounds fairly complex?
[14:01] <Laney> No
[14:01] <seb128> since we handle security uploads through unattended upgrades nowadays
[14:01] <seb128> and auto-spawn update-manager
[14:01] <seb128> or let me reword
[14:02] <seb128> we should not make it notify about deb updates which we handle with other tools
[14:02] <Laney> I just said that
[14:02] <Laney> so that sounds like agreement
[14:02] <seb128> I didn't say you didn't :)
[14:02] <seb128> and yes
[14:04] <seb128> unsure if it would be misleading to have gnome-software install debs but not list updates availables in the corresponding tab though
[14:04] <seb128> it's a bit tricky
[14:04] <Laney> a bit probably
[14:04] <Laney> but less bad than it not working properly
[14:05] <Laney> and with PK you only get offline updates anyway, so actually to keep it in place we'd need to do work
[14:05] <gQuigs> if the debs are auto installed, shouldn't nothing prompt about them?
[14:05] <seb128> ?
[14:07] <gQuigs> since we handle security uploads through unattended upgrades nowadays => Gnome software shouldn't have time to find out about them?
[14:07] <seb128> that's not how things work though
[14:08] <seb128> step 1 is that the apt index is refreshed
[14:08] <seb128> then tools get notified about available updates and do $things
[14:08] <seb128> unattended-upgrade thing is to install security updates
[14:08] <seb128> gnome-software one is to notify about updates available
[14:10] <gQuigs> seb128: so that sounds like a timing issue..  have gnome-software wait until unattended-upgrades is done before alerting the user?
[14:13]  * gQuigs just really wants one plus to rule all updates
[14:13] <seb128> gQuigs, unsure that would the right fix, it hads dependencies between components
[14:13] <gQuigs> *one place
[14:13] <seb128> adds
[14:13] <seb128> we just need to define what component does what
[14:13] <seb128> if gnome-software notifications are not useful to us we should disable that
[14:14] <seb128> or actually as L_aney said, if having it handling deb updates is wrong for us then we should disable that
[14:14] <seb128> gnome-software
[14:14] <seb128> ups
[14:14] <seb128> gnome-software still need lot of work to provide a smooth upgrade experience
[14:14] <seb128> or we need to revisit how we handle upgrades and do offline upgrades through packagekit
[14:15] <seb128> but in any case it needs non trivial work
[14:15] <gQuigs> gotcha, thanks for explaining!
[14:15] <seb128> yw!
[14:15] <Laney> If somebody wanted to work on online upgrade support in gnome-software's PackageKit plugins that would be a start
[14:16] <Laney> Richard said he would accept that
[14:17] <seb128> (not going to start ranting also about g-s quality there, but installing some updates from the list is workling really poorly on my box, tab is getting emptied, then it gets a spinning cursor animation in the corner for like a minute with no other feedback, then refresh the screen, then sometime list the package as to update still when it has been updated)
[14:18] <seb128> Laney, yeah, I don't know where we stand and what we want to do
[14:18] <seb128> offline updates might make sense
[14:18] <seb128> in any case we have work to plan if we want to work on that
[14:18] <jbicha> seb128: when are you going to upgrade to 17.10 ;) because g-s is working better on 17.04 and even better for me in 17.10
[14:19] <Laney> That was a suggestion for someone else, not part of an official plan
[14:19] <Laney> I personally think offline updates would make sense for release upgrades, might be a more of a hard sell for normal package updates
[14:19] <Laney> anyways, not something we're going to do any time soon
[14:21] <gQuigs> offline updates would make more sense if we were going to the base install, I'm guessing that isn't happening (or at least not planned for 18.04)?
[14:23]  * gQuigs can't type today.. . if we were going to ***snap*** the base install
[14:56] <seb128> jbicha, that comment was based on 17.04 testing, but I plan to try 17.10 today or monday
[14:56] <seb128> jbicha, let's see how much things improved since april :-)
[15:12] <jbicha> seb128: for instance, I wasn't able to duplicate LP: #1551599 any more with the latest version
[15:13] <seb128> yeah, I'm sure some issues are fixed
[15:13] <seb128> also need to try with the packagekit backend
[15:13] <seb128> but it is feature incomplete compared to update-manager, and UI feels weird at times
[15:25] <seb128> xnox, hey, do you plan to submit back your indicator change to the vcs?
[15:30] <xnox> seb128, no =)
[15:30] <seb128> xnox, good team playing work, thanks
[15:30] <xnox> seb128, are we not going to like remove all the indicators?
[15:30] <seb128> why?
[15:30] <xnox> once unity7 -> gnome switch is done?
[15:30] <seb128> xfce uses some iirc
[15:31] <seb128> and unity is still going to be in universe
[15:31] <xnox> can use iirc, but did not use them by default. E.g. not datetime, they use xfce-datetime thing
[15:31] <seb128> well unity in universe still stand
[15:31] <seb128> also did we move ubiquity away from using those yet?
[15:31] <xnox> seb128, apart from mark commiting that on g+, which imho was in error, not a mandate; i don't see why would be keeping unity in universe
[15:31] <xnox> seb128, who is going to maintain it?
[15:32] <seb128> community
[15:32] <xnox> seb128, i will move ubiquity away from indicators once gnome-shell is on the ISO. Is that the case already?
[15:32] <seb128> not yet
[15:32] <xnox> seb128, "community" - i'd like to see names =)
[15:32] <seb128> anyway for now that indicator is still on the ubuntu iso
[15:32] <xnox> seb128, imho if there is no community supporting unity7 stack, it should be removed from the archive.
[15:33] <seb128> so whatever you think it would be nice to use the vcs
[15:35] <seb128> xnox, it's funny how people focus on wanting to remove working things from the archive but only when those are things we used, like why don't you go chasing down removing xdm from the archive or any of the stack of packages that didn't get touched for years before looking at used and working code?
[15:36] <jbicha> off-topic, but Unity in an Artful live iso was unusable for me earlier this week when I tried it
[15:37] <seb128> what is/was the issue?
[15:37] <seb128> is that fixed?
[15:37] <ogra_> seb128, dude! someone might want to use xdm to log into unity!
[15:37] <ogra_> dont remove it :P
[15:37] <xnox> seb128, eeeh. although xdm has an ubuntu patch, it's not canonical-upstream project.
[15:37] <ogra_> (and happy friday)
[15:37] <jbicha> in VBox, the DAsh and menu bar was flickering and I think CPU was 100%
[15:37] <xnox> seb128, if we do not have maintainers, and are no longer supporting things we cannot simply move them from main to universe, and pretend life is awesome.
[15:37] <seb128> xnox, what does it change if upstream is canonical or not? it's still free software and useful
[15:37] <ogra_> and working fine
[15:38] <seb128> xnox, why not?
[15:38] <xnox> seb128, either it should be in main and supported; or removed from the archive and packaged in debian/reintroduced by somebody else.
[15:38] <xnox> seb128, because of perception and expectations.
[15:38] <ogra_> you would have to remove half of universe ...
[15:38] <seb128> xnox, is that a written rule?
[15:38] <xnox> e.g. this is why we removed src:upstart from the archive, ratehr than simply demote to universe.
[15:39] <xnox> ogra_, is half of universe canonical-upstream for what mark has stopped paying maintainance for?
[15:39] <jbicha> xnox: I think I generally agree with the questionability of keeping Unity7 around
[15:39] <xnox> ogra_, i'm talking about things that are ex-main in unity-touch, unity8, unity7 seeds.
[15:39] <ogra_> well, not half of ... but yeah, there is a lot
[15:39] <seb128> xnox, why hating on Canonical code more than other upstreams?
[15:39] <seb128> jbicha, ^
[15:39] <jbicha> xnox: maybe it would help if you compiled a list of things that are broken enough for removal if they aren't fixed
[15:39] <seb128> same question :p
[15:40] <gQuigs> it's not uncommon to do Canonical maintained - main -> universe - > removed
[15:40] <xnox> seb128, and for example if we have to do security or bugfix updates it would be nice to only do it for only stable releases; without requiring to land it in artful too.
[15:40] <gQuigs> but it is another step..
[15:40] <seb128> xnox, we don't give security support for universe anyway
[15:40] <gQuigs> offtopic - https://bugs.launchpad.net/ubuntu/+source/ldap-auth-client/+bug/1646954  is a win for removing formally Canonical maintained packages
[15:40] <xnox> seb128, correct - but unity7 is in main in xenial.
[15:41] <xnox> and we will support that there.
[15:41] <xnox> but not in 18.04.
[15:41] <seb128> xnox, that's not going to change
[15:41] <seb128> right
[15:41] <xnox> hence we should remove, as we are retiring it.
[15:41] <seb128> you should remove xdm as well then
[15:41] <seb128> we have lightdm
[15:41] <gQuigs> for the ldap bug, we moved it to universe for one LTS release , and then the above bug is to remove it before 18.04
[15:41] <jbicha> LP: #1686081 is one particularly difficult bug to solve if we aren't allowed to remove -synaptics from Ubuntu
[15:41] <xnox> i don't want unity7 stack for 5 years in 18.04 with people expecting support and updates because it is available and still supported in 16.04
[15:42] <xnox> seb128, this is first time i hear about xdm - is xdm canonical upstream? and what is that patch for?
[15:42] <xnox> seb128, for many things that were in ubuntu-touch seed, i will be dropping touch-delta and syncing packages from debian.
[15:42] <seb128> xnox, so even if there is a community group taking it back and wanting to upload it to debian/ubuntu you are going to block that because old canonical code should just deleted?
[15:42] <xnox> because there is no need to maintain and cary delta for the android dev tools for example.
[15:42] <xnox> seb128, no, i will not block such efforts.
[15:42] <seb128> k
[15:43] <seb128> so I'm going to go reupload it with my debian email
[15:43] <xnox> seb128, but as far as i can tell there is zero community efforts around unity7 =)
[15:43] <xnox> seb128, sure.
[15:43] <seb128> you realize it's just creating stupid round of delete/reupload?
[15:43] <xnox> removing Ubuntu Dev teams from maintainer field is a good thing.
[15:43] <seb128> but not changing the situation?
[15:43] <ogra_> xnox, where the the mailing list thread where the community spoke up to say they will never maintain unity7 ?
[15:43] <jbicha> seb128: if there are people that step up to maintain Unity7, but so far that community is sadly, vaporware
[15:43] <seb128> we could change the maintainer info without deleting
[15:43] <ogra_> xnox, the one where you told them you will remove it if no MOTU steps up
[15:44] <seb128> jbicha, it's a true statement for a good part of the archive
[15:44] <seb128> jbicha, why hating more on unity than e.g xdm?
[15:44] <xnox> seb128, i hope you do realise that i only uploaded a bug fix to keep inidicator-datetime buildable in the current state of affairs. I did not remove indicator-datetime.
[15:44] <ogra_> xnox, just blindly removinbg stuff without even giving the community a chance is pretty rude IMHO
[15:44] <xnox> because we removed ubuntu-touch language packs.
[15:44] <jbicha> seb128: xdm is not causing possibly difficult issues or decision for the default desktop
[15:44] <seb128> jbicha, neither are indicators
[15:44] <xnox> ogra_, i have not yet removed anything from unity7 stack; nor proposed or started consultation for that.
[15:44] <seb128> they work under xfce and don't hurt anyone
[15:45] <xnox> ogra_, i'm not sure where seb128 is getting the idea that i have already removed things without consultations =) but i am voicing my upcoming plans.
[15:45] <ogra_> xnox, so why this discussion then ?
[15:45] <jbicha> I don't personally hav ea problem with indicators, I do see some problems with unity-settings-daemon/conrol-center
[15:45] <ogra_> xnox, voice it with the community ...
[15:45] <ogra_> xnox, get feedback ... and based on that decide on removal
[15:45] <xnox> ogra_, clearly you missed the convesation.... please re-read.
[15:47] <seb128> jbicha, those are different topics
[15:47] <xnox> seb128, if you want to keep unity7 stack in universe; when moving ubuntu-desktop to gnome-shell please create a seed / metapackage in universe of something like "unity-desktop" to make sure things don't end up unseeded in universe.
[15:48] <seb128> xnox, you realize you are not in charge of that stack and don't need to have destructive plans for it right? :-)
[15:49] <xnox> seb128, because at the moment, i am looking into things that are dropping out of main, become unseeded, and will not be maintained going into the future.
[15:49] <xnox> seb128, i do realise that..... however i was asked to prepare lists of things to remove from the archive things that will no longer be supported.
[15:49] <seb128> xnox, you should better look at things we maintain and need work :-)
[15:50] <xnox> seb128, which did come through from the responsible people for it.
[15:50] <jbicha> xnox: do you have any specific problem with indicators? as far as I know, they work and can be used in other desktops like GNOME Flashback (or maybe even GNOME Shell if someone wrote an extension for that)
[15:51] <xnox> seb128, i guess i am weird. but i do believe ubuntu as a whole, would be in a much better shape if we did not have gtk2, qt4, python2 in the archive at all.
[15:51] <seb128> xnox, yeah, would be better without libreoffice, firefox, chromium :-)
[15:51] <jbicha> what concerns me more are the parts of Unity that don't work or will stop working
[15:51] <xnox> jbicha, i have no problems with indicaotrs. but it seems that seb128 has a problem with me uploading a change to indicator-datetime to not build-depend on a package which no longer exists in artful; but does exist in all prior releases =)
[15:51]  * mdeslaur votes for removing the kernel
[15:52] <seb128> xnox, I've a problem with you uploading a package that has a vcs and not merging/submitting your changes back
[15:52] <seb128> it's poor taste and team work
[15:52] <xnox> seb128, but i do recognise that libreoffice, firefox, chromium are important. Hence I am subscribed to all the bugs about porting those to newer toolkits. E.g. there has been work recently on chrome front.
[15:52] <jbicha> mdeslaur: it was my understanding that Security wanted to remove everything ;)
[15:53] <mdeslaur> jbicha: we think our users would be better off :)
[15:53] <jbicha> mdeslaur: well, at least Security would have an easier job ;)
[15:54] <jbicha> xnox: I think we could almost remove gtk2 from the default 17.10 install (not sure about Firefox) LP: #1585903
[15:55] <xnox> seb128, my problem is, that it is entirely irrelevant in this case. as it is highly inlikely that indicator-datetime will change apart from build fixes. And the last two uploads are just that.
[15:55] <xnox> it is beyond trivial change, which would be incorporated by the next upload.
[15:56] <chrisccoulson> Feel free to remove anything I've worked on. Just remember to not tell me in advance
[15:57] <jbicha> xnox: you're making extra work for other people by basically forcing someone else to push those build fixes to the vcs for you
[16:01] <xnox> chrisccoulson, =))))))))))))
[16:02]  * mdeslaur bulldozes chrisccoulson's garden
[16:02] <chrisccoulson> lol
[16:03] <jbicha> does everyone in the UK have a garden?
[16:04] <Laney> England's green & pleasant land
[16:05] <chrisccoulson> And everyone drinks tea
[16:12] <oSoMoN> :)
[16:42] <DalekSec> In favor of removing python2?  Byebye ubuntu-dev-tools!
[17:03] <seb128> have a good w.e desktopers
[17:03] <willcooke> night  seb128
[17:03] <oSoMoN> seb128, thanks, you too!
[17:04] <willcooke> Oh, just seen that network manager 1.8 is out, and has been for over a week
[17:04] <seb128> bye willcooke oSoMoN
[17:04] <willcooke> Will dig in to it more next week, because it's quitin' time
[17:04] <willcooke> night all
[17:04] <oSoMoN> have a good one willcooke
[17:04]  * oSoMoN makes pizza
[17:04] <willcooke> o/
[17:05] <jbicha> wow, there was more than 30 seconds between his saying bye and leaving :)
[17:07] <oSoMoN> he was indecisive
[17:49] <oSoMoN> have a good week-end everyone!
[17:50] <kenvandine> even faster :)