| michagogo | So what’s next? The Abnormal Abalone? | 00:05 |
|---|---|---|
| michagogo | (I guess there are a lot of “ab” adjectives, actually. | 00:05 |
| michagogo | ) | 00:05 |
| === Sir_Gallantmon is now known as Son_Goku | ||
| === Laney is now known as Guest5394 | ||
| juliank | slangasek: I just want to note again (I just sent a comment to the bug) that SuggestsImportant=true was not my idea, I just present the arguments for it. The compromise I just posted seems reasonable, but I'm not strongly opposed to setting it to false (DonKult may be), I just want everyone to have a complete view of the problem. | 11:00 |
| mardy | acheronuk: hi! GNOME certainly does not depend on signon-ui, but Unity should, if you want to have the Online Accounts panel in it | 11:00 |
| mardy | acheronuk: Unity8 does not require it, though | 11:01 |
| juliank | Oh, I see DonKult also replied. | 11:03 |
| juliank | Currently, you could basically run autoremove in a cron job and be safe. | 11:05 |
| juliank | With SuggestsImportant=false, that's not really the case :D | 11:05 |
| acheronuk | mardy: well, it's reverse depends seem to show nothing for unity 7 | 11:29 |
| mardy | acheronuk: it's required by unity-control-center-signon, IIRC | 11:29 |
| acheronuk | mardy: anyway, at the moment it's completely broken for KDE, who are the only ones who will continue to use it | 11:30 |
| mardy | acheronuk: do you have links to any bugs? | 11:30 |
| acheronuk | mardy: https://gitlab.com/accounts-sso/signon-ui/issues/1 | 11:31 |
| acheronuk | mardy: unity-control-center-signon was a removed in artful | 11:32 |
| acheronuk | mardy: trailing comments on bug #1070873 | 11:34 |
| ubottu | bug 1070873 in signon-ui (Ubuntu) "kde-telepathy, impossible to connect to gmail accounts" [Undecided,Confirmed] https://launchpad.net/bugs/1070873 | 11:34 |
| acheronuk | mardy: plus one or 2 others that are marked private at the moment, like #1723230 | 11:35 |
| mardy | acheronuk: well, AFAIK gmail's chat has long been broken with XMPP, it has very little to do with signon-ui | 11:37 |
| acheronuk | mardy: well, at the moment only KDE used it. and it crashes. only solution I have is to re-upload 0.17+17.10.20170606-0ubuntu1 | 11:39 |
| acheronuk | 0.17+17.10.20160406-0ubuntu1 I mean | 11:40 |
| acheronuk | mardy: I will make a new bug if required | 11:41 |
| acheronuk | mardy: will be getting kio-gdrive into 18.04 which requires a working version of signon-ui that doesn't crash when invoked by KDE's systemsettings, so need to fix this one way or another | 11:45 |
| mardy | acheronuk: let me comment on https://gitlab.com/accounts-sso/signon-ui/issues/1, I'm afraid I know what the problem is | 11:45 |
| acheronuk | anyway, will have to come back to this. Sunday lunch calls | 11:45 |
| acheronuk | mardy: ok | 11:45 |
| mardy | acheronuk: | 12:00 |
| mardy | acheronuk: ops, I meant to say: if I provide you with a signon-ui branch, will you be able to test it in KDE? | 12:01 |
| acheronuk | mardy: yep. really have to go now. will be around all the coming week | 12:07 |
| KeepItInside | !history launchpad test | 16:49 |
| ubottu | KeepItInside: I am only a bot, please don't think I'm intelligent :) | 16:49 |
| KeepItInside | LP: #1714989 | 16:50 |
| ubottu | Launchpad bug 1714989 in GNOME Shell "gnome-shell crashed with SIGSEGV in g_type_check_instance_cast() from st_label_set_text() (dash-to-panel specific?)" [Critical,Confirmed] https://launchpad.net/bugs/1714989 | 16:50 |
| KeepItInside | sorry on my HTC desire :( | 16:50 |
| KeepItInside | ikonia hows xubuntu aardvark ? | 16:56 |
| slangasek | juliank: yeah; considering our stock Ubuntu package management stack does *not* call autoremove at any point except between release upgrades, and aptitude cli has a pathological resolver, I stand by my position here | 20:57 |
| slangasek | juliank: it's clear that we shouldn't change this setting in SRU, but we should get it fixed for 18.04 so that we can get everyone cleaned up on the next upgrade | 20:58 |
| juliank | slangasek: What about the compromise I proposed? | 20:59 |
| juliank | It would protect the careless users, and it also gives the careful users the control they want | 21:01 |
| === not_phunyguy is now known as phunyguy | ||
| juliank | Of course, apt autoremove could also ask: Do you also want to remove the packages still Suggested? or something. Then you have two bool prompts | 21:05 |
| juliank | kind of odd | 21:05 |
| slangasek | juliank: what I care about is what the Ubuntu system does by default; if this has to be implemented upstream by adding yet another knob to apt because no one wants to change the behavior of the existing interfaces, then that's acceptable, I just think it's a waste of effort | 21:09 |
| juliank | slangasek: I'd say: Removing packages with reverse suggests on a release upgrade should require confirmation with each package being listed with its reverse suggests. But I think people are already used to release upgrades breaking their system, so it's not that much of an issue there as it is with autoremove. | 21:12 |
| slangasek | I have a seriously hard time with any of this being termed "breaking the system" | 21:13 |
| slangasek | it's expected that the default behavior is different after a release upgrade and that the user might have to make adjustments | 21:14 |
| juliank | slangasek: It's just an overstatement :D | 21:14 |
| juliank | More accurate would be: Removing functionality they might be relying on that has been deprecated | 21:14 |
| slangasek | I also think that it would be appropriate to change the default behavior of apt autoremove in a new release, while definitely not SRUing it backwards | 21:15 |
| slangasek | because then you have gone through a release upgrade and dealt with the autoremoval once | 21:15 |
| slangasek | and either manually re-added those removed packages or not | 21:15 |
| slangasek | and once upgraded, package dependencies aren't going to change, so you're not going to have new autoremovals suggested as a result of changed deps within the release | 21:16 |
| slangasek | only as a result of you specifically removing something and then wanting to clean up | 21:16 |
| juliank | Oh, it would be appropriate. But I'd rather have two stages of autoremovals for the apt(-get) usage I think. The release upgrading code is free to run with suggestsimportant set to false | 21:17 |
| juliank | Imagine if we could reach a point where we can just do autoremove in unattended-upgrades. that's the goal, but we're not there yet. | 21:19 |
| slangasek | juliank: well, as the recent discussion on the other bug wrt auto-marking of metapackage deps, we seem to have moved quite far away from it being safe to run autoremove as part of unattended upgrades :/ | 21:27 |
| juliank | slangasek: Not sure what you're referring to. The only thing I remember is that the metapackage handling improved so "remove metapackage" also keeps the dependencies auto, but if the metapackage is removed implicitly, then they're not. And that's really the best of both worlds. | 21:31 |
| juliank | So, yes, if you do apt remove ubuntu-desktop and then autoremove, ubuntu-desktop is completely gone. | 21:31 |
| juliank | But you just asked apt to remove ubuntu-desktop so ... | 21:31 |
| slangasek | juliank: well, I don't think it's the best of both worlds that you could 'apt remove ubuntu-desktop' and have it keep running, until the next time unattended upgrades runs :) | 21:36 |
| juliank | slangasek: So, let's automatically do autoremovals, like aptitude? | 21:36 |
| slangasek | maybe | 21:37 |
| slangasek | not sure that would make it SRUable still; and we do need to fix behavior in stable releases wrt lack of autoremoval of kernel packages | 21:37 |
| juliank | Well, autoremove removes kernel packages. | 21:38 |
| juliank | But unattended-upgrade has its own handling I think | 21:39 |
| juliank | slangasek: apt's next release cycle is starting *now*, BTW. Adds seccomp() sandboxing to methods, so I'd expect some breakage outside amd64. | 21:41 |
| juliank | I think the compressed index change has to move to 18.10, there's a security issue it would open up (or a regression in file:/ repositories not accessible by _apt) | 21:42 |
| slangasek | seccomp itself is well supported on !amd64, provided you don't wrongly encode an x86-specific list of syscalls :) | 21:46 |
| juliank | slangasek: I basically took a list of all syscalls on amd64, and a list of all syscalls that differ between architectures, and combined that. | 21:48 |
| juliank | libseccomp has some magic in there, so I hope it works out fine | 21:48 |
| juliank | And you can turn it off or allow or trap additional syscalls via config options :D | 21:49 |
| juliank | so, you could do apt -o APT::Sandbox::Secomp::Trap::=read and the read syscall causes SIGSYS :D | 21:49 |
| juliank | So for example, I have whitelisted both fchown and fchown32 | 21:53 |
| === Guest54675 is now known as RAOF | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!