| === Guest94094 is now known as RAOF | ||
| FourDollars | Hi, I would like to solve https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1685062. Could you help to review my merge proposal? | 04:50 |
|---|---|---|
| ubottu | Launchpad bug 1685062 in unity-settings-daemon (Ubuntu) "Brightness step down can not reach the lowest brightness level." [Undecided,In progress] | 04:50 |
| === JanC is now known as Guest10980 | ||
| === JanC_ is now known as JanC | ||
| === maclin1 is now known as maclin | ||
| === dja is now known as dja|away | ||
| === JanC is now known as Guest18582 | ||
| === JanC_ is now known as JanC | ||
| === alan_g_ is now known as alan_g | ||
| bdrung | pitti, hi. how do you detect duplicates? do you just use StacktraceAddressSignature? | 09:30 |
| pitti | bdrung: the client side uses that, unless a hook set a custom DuplicateSignature:; the server side uses a signature built from the symbolic stack trace, which is usually more reliable | 09:38 |
| pitti | bdrung: see apport/report.py crash_signature() | 09:39 |
| * juliank finally remembered to verify the apt SRU for yakkety, and just did it :) | 09:45 | |
| bdrung | pitti, would be nice if apport-retrace would add the crash signature to the crash file | 09:49 |
| === CRogers_________ is now known as CRogers | ||
| ricotz | infinity, hi, looks like dpkg in artful generates invalid *.changes files, the Files section doesnt list *.buildinfo as in Checsums-* | 13:26 |
| infinity | ricotz: http://launchpadlibrarian.net/316412144/dpkg_1.18.23ubuntu1_1.18.23ubuntu2.diff.gz | 13:27 |
| infinity | ricotz: Entirely intentional, as there was a bug in launchpad's handling of buildinfo files on upload. | 13:28 |
| infinity | ricotz: The feature will be restored in a few days when the LP fix is QAed and deployed. | 13:28 |
| infinity | ricotz: Though, I'm curious what you mean by "invalid". | 13:29 |
| infinity | Perhaps you meant "unexpected"? :P | 13:29 |
| ricotz | infinity, launchpad rejected my upload which looks like https://paste.debian.net/plain/928699 with 1.18.23ubuntu3 | 13:30 |
| ricotz | so Files does not contain buildinfo | 13:30 |
| infinity | ricotz: Oh. I didn't check source builds. Binaries are behaving correctly. Bother. | 13:31 |
| infinity | Although. Huh. | 13:32 |
| ricotz | yeah, this is a source build | 13:32 |
| infinity | The testsuite does check source builds. | 13:32 |
| infinity | And it works correctly. | 13:32 |
| infinity | ricotz: How did you generate that? | 13:32 |
| ricotz | with "dpkg-buildpackage -S -sd -d" | 13:33 |
| infinity | ricotz: Oh, gross. If you sign with dpkg-buildpackage, it screws up. If you don't (ie: pass -uc), then it DTRT. | 13:38 |
| infinity | ricotz: Might fix, or might not care, since I can revert that bit Very Soon anyway. | 13:38 |
| === alan_g is now known as alan_g|afk | ||
| ricotz | infinity, I would prefer a fix ;) | 13:39 |
| infinity | ricotz: :P | 13:39 |
| infinity | ricotz: Quick workaround for now is to build with "-uc -us", and then "debsign foo.changes" | 13:40 |
| ricotz | hmm, not really applicable here, I want to avoid altering my scripts | 13:41 |
| ricotz | infinity, what is "Very Soon"? | 13:41 |
| * ricotz downgraded to the zesty packages already | 13:42 | |
| infinity | ricotz: Early next week at the latest. Not sure how long it'll take to QA and deploy the LP fix. | 13:42 |
| ricotz | alright | 13:42 |
| cjwatson | I'll get it deployed today | 13:45 |
| cjwatson | Assuming nothing explodes horribly | 13:45 |
| cjwatson | BTW do we have a new enough debsign that signs buildinfo? | 13:47 |
| cjwatson | infinity: ^- | 13:47 |
| infinity | cjwatson: Possibly not. | 13:53 |
| infinity | cjwatson: Definitely not. I'll sort that. | 13:54 |
| infinity | ricotz: http://paste.ubuntu.com/24426912/ might solve your issue for right now. But looks like we'll be fixing things properly by EOD. | 13:55 |
| ricotz | infinity, thanks, dropping buildinfo from changes works too ;) | 14:01 |
| infinity | cjwatson: New devscripts uploaded. | 14:20 |
| infinity | cjwatson: Well, devscripts uploaded, but it'll be FTBFS until you do your thing to LP and I do my thing to dpkg. :P | 14:37 |
| cjwatson | Yeah, just QAing stuff in https://dogfood.paddev.net/~cjwatson/+archive/ubuntu/dogfood-buildinfo/+packages now | 14:40 |
| infinity | cjwatson: Shiny. I'm going to go find a very large coffee and install it in my face. Back soon. | 14:47 |
| mdeslaur | chiluk: FYI, I agree with your comment in the qemu bug, but I saw it too late | 15:10 |
| === alan_g|afk is now known as alan_g | ||
| === maclin1 is now known as maclin | ||
| nacc | rbasak: fyi, i'm starting up the importer job again, using the snap only :) | 16:05 |
| rbasak | \o | 16:24 |
| rbasak | \o/ | 16:24 |
| cjwatson | buildinfo should be fixed on LP production now. | 17:57 |
| infinity | ricotz: dpkg 1.18.23ubuntu4 should behave correctly now (and LP will accept the uploads, too!) | 18:32 |
| juliank | slangasek: re bug 1615482 - not sure why we ended up with 6am/6pm +/- 12 hours randomized delay. It's kind of odd. I think there's an IRC backlog for it in #debian-apt, but not looked yet. I suggested some improvements I recently thought about in the bug. | 18:56 |
| ubottu | bug 1615482 in apt (Ubuntu) "apt-daily timer runs at random hours of the day" [High,Triaged] https://launchpad.net/bugs/1615482 | 18:56 |
| slangasek | juliank: right; long before this code landed in apt upstream, Ubuntu had integrated a carefully designed experience and this has very much regressed | 18:57 |
| juliank | slangasek: Well no | 18:57 |
| juliank | slangasek: I mean, we shared the cron job before. mvo replaced that with the systemd timer. | 18:58 |
| juliank | Because people complained that the apt cron job was delaying other cron jobs by up to 30 mins | 18:58 |
| slangasek | juliank: shared a cronjob that began in Ubuntu, was merged upstream to Debian, and then regressed without discussion in Ubuntu ;) | 18:58 |
| juliank | slangasek: Well, mvo switched from the cron job to the timer mostly to fix a ton of bugs in launchpad :D | 18:59 |
| slangasek | heh | 18:59 |
| juliank | There was also the funny ones like cron job runs sleep, that sleep process eats to much memory | 18:59 |
| slangasek | juliank: aiui the move to the systemd timer also loses the anacron support for catching up if the system was offline at the appointed time | 19:00 |
| juliank | slangasek: No, that's built into systemd (see the Persistent option) | 19:00 |
| slangasek | s/offline/powered off/ | 19:00 |
| juliank | systemd will retry at resumes and boots | 19:00 |
| juliank | I think anacron only does boots | 19:00 |
| slangasek | er, anacron absolutely did on resume also | 19:01 |
| slangasek | though it's not impossible that *that* regressed as well :P | 19:01 |
| juliank | Hey, I don't know, I just guessed :D | 19:01 |
| slangasek | (that may have been a pm-utils integration that got lost in a migration; I don't know if it was lost, just saying it's possible) | 19:01 |
| juliank | So the idea is to go down from 12 hours of randomized delay to like 30 mins and have the accuracy reduced too | 19:02 |
| juliank | like 5 minutes or so | 19:02 |
| slangasek | Persistent=true - cool, that makes sense | 19:03 |
| slangasek | but AFAICS, on boot this will start before the network is up | 19:03 |
| slangasek | because timers.target is DefaultDependencies=no | 19:03 |
| slangasek | whereas cron starts much later (runlevel 2 / multi-user.target) | 19:03 |
| juliank | slangasek: Yes. We can add an After=network.target. That does not help with resumes, though. | 19:03 |
| juliank | anacron also delays these catch up events by 5 minutes, which systemd does not https://github.com/systemd/systemd/issues/5659 | 19:04 |
| juliank | That's a reason why we run twice a day, BTW. | 19:04 |
| juliank | The script itself checks a stamp file too, so it will only run actual stuff once a day | 19:05 |
| slangasek | yeah, but running twice a day is a bad workaround | 19:05 |
| juliank | slangasek: If we find consensus on some better values, then we can probably push that into a 1.4.1 release :) - if Debian RT says it's OK - I'd like to get this improved a few weeks ago, but I forgot about it | 19:08 |
| juliank | Then we can also SRU that back into yakkety and xenial with another fix pending from 1.4 | 19:09 |
| juliank | (after the current SRUs migrated) | 19:10 |
| slangasek | juliank: can we agree that being able to assert that timers running on resume can rely on the network being up first is something that systemd should be guaranteeing? (<-- xnox) | 19:11 |
| juliank | Well, it sort of does with network.target, but that does not really cover non-server use cases | 19:11 |
| juliank | Like on a laptop with NetworkManager, network.target by default does not wait for you being connected | 19:12 |
| juliank | And on resumes, the target is considered started already, so no wait at all | 19:12 |
| juliank | You can work around the resume scenario with this job: https://github.com/julian-klode/dotfiles/blob/master/.config/systemd/user/nm-online-exit.service | 19:13 |
| juliank | This is like the normal NetworkManager-wait-online.service, but with RemainAfterExit=no instead of RemainAfterExit=yes | 19:14 |
| slangasek | juliank: you want network-online for this, not network.target | 19:14 |
| slangasek | it's perfectly appropriate to say "don't try to do apt updates unless you're online" | 19:15 |
| juliank | Ah makes sense. | 19:15 |
| slangasek | so that's just After=network-online.target | 19:15 |
| slangasek | which the network provider will implement | 19:15 |
| juliank | Yes. | 19:16 |
| juliank | Only for boots though | 19:16 |
| slangasek | yes; the resume case is more difficult | 19:16 |
| juliank | And I think it the NetworkManager one might be disabled by default, not sure | 19:16 |
| slangasek | but I think that needs to be solved in systemd, *not* in this uint | 19:16 |
| slangasek | unit | 19:16 |
| juliank | slangasek: Sure. We need a target that shuts down when there is no network. And then we can bind network needing jobs to that | 19:17 |
| juliank | So, after a resume, the target comes back once the network is up again, and then network-needing units get started again | 19:17 |
| juliank | slangasek: OK, so that seems to be the right thing to do: https://github.com/Debian/apt/compare/master...julian-klode:lp1615482?expand=1 | 19:23 |
| juliank | After + Wants on network-online.target | 19:24 |
| juliank | We can also start it After=multi-user.target to get some more delay during boot to fix "slow" boots | 19:25 |
| slangasek | juliank: fwiw I don't see any reason to use a non-default value for AccuracySec vs. the default of 1m | 19:25 |
| juliank | "slow" = 5 second slower on an HDD machine... | 19:25 |
| slangasek | juliank: yeah, I responded to that comment on the bug log - as far as I'm concerned "my boot is slower because my machine has to check for critical security updates" should be wontfix | 19:26 |
| juliank | slangasek: It's just that we don't really need that kind of accuracy, so we decided back than to just be generous and allow it to merge with any hourly cron job in the near time | 19:26 |
| ricotz | infinity, works, thanks! | 19:27 |
| juliank | manual page says: "To optimize power consumption, make sure to set this value as high as possible and as low as necessary." | 19:27 |
| juliank | But 5m vs 1m does not make a huge diff | 19:28 |
| slangasek | juliank: we don't want millions of Ubuntu machines to all wake up on exactly the 5 minute mark and hit the mirrors | 19:28 |
| juliank | Well sure, with a 30m randomize, 1m probably makes sense. | 19:29 |
| juliank | I think we can calculate this out, how many machines on average would update at the same time | 19:29 |
| slangasek | my point is we want it smoothed as much as possible over the interval, and this swamps any benefit of reducing wakeups... especially when we're talking about a single wakeup per day per machine | 19:30 |
| juliank | Assuming an update takes about 1m, with 30m random delay, we would have N/30 machines hitting at the same time (or well, more like N/60, as the job runs twice a day) | 19:31 |
| slangasek | (the fine controls of the systemd timer design are useful, just not for this) | 19:31 |
| juliank | That's like it was before, basically, just running at 6/18 instead of 0. | 19:31 |
| juliank | (I think cron ran at midnight, right?) | 19:32 |
| slangasek | no | 19:32 |
| slangasek | this was *always* in the 6am-7am window | 19:32 |
| slangasek | 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) | 19:32 |
| juliank | Ah, OK, great | 19:32 |
| slangasek | and, I do think the 2x-daily frequency needs to be dropped back down to 1x | 19:33 |
| sarnold | I suspect even 30m smearing isn't 'enough' -- our network always gets saturated start of every europe work day, heh | 19:33 |
| slangasek | sarnold: there are some hotspots based on population centers, but that part is a conscious tradeoff | 19:34 |
| juliank | slangasek: I think that needs some more digging in the backlog and possibly interrogating mvo to figure out why we have 2 tries at all | 19:34 |
| sarnold | slangasek: heh, I guess i'm only ever awake for the one hotspot then :) | 19:34 |
| drab | hi, anybody familiar with the process of starting ssh in a chroot from an ubuntu-install? | 19:35 |
| slangasek | sarnold: I think you can ask IS for graphs that show the big EU peak, followed by two smaller US-East/US-West peaks | 19:35 |
| drab | I'm trying to automate one last step that requires ssh install, but starting ssh from late-command fails | 19:36 |
| slangasek | drab: basically unsupported | 19:36 |
| drab | so preseed does its job, fires off late-command which creates a user, installs a pub key part and then tries to start ssh | 19:36 |
| slangasek | you could start the daemon manually, but you can't start services via systemd units inside of a chroot | 19:37 |
| slangasek | (and certainly not within d-i, which does not run systemd as init AFAIR) | 19:37 |
| juliank | slangasek: Another fancy alternative would be to have unattended-upgrades drop in some overrides to tighten things up, but have apt run randomly during the day if u-u is not installed | 19:37 |
| drab | slangasek: yeah, so I tried to just run /usr/sbin/sshd | 19:37 |
| slangasek | juliank: I disagree that this behavior should be tied to unattended-upgrades | 19:37 |
| drab | and in fact, it also works if I do /etc/init.d/ssh start | 19:37 |
| drab | but it doesn't work if I do it from the late-command | 19:38 |
| drab | or rather | 19:38 |
| juliank | Well, the other stuff (running update and maybe clean up) is not that hurtful, it could have more flexibility than running an upgrade | 19:38 |
| drab | if I run /usr/sbin/sshd it actually runs, process is there, but ssh in fails | 19:38 |
| juliank | Probably not as much as now, but still | 19:38 |
| drab | slangasek: complaining that /var/run/sshd does not exist even tho I just mkdir'ed it | 19:38 |
| drab | so I'm really confused because if I do it manually it works, but if I do it from the script it doesn't | 19:39 |
| drab | and I don't see the difference | 19:39 |
| drab | especially for something as simple as mkdir, which btw works to create stuff in the homedir of the user I create | 19:39 |
| slangasek | juliank: I have in fact had an apt update in the middle of the day on my laptop disrupt my work when it was *not* installing any packages, just because of the memory usage of all of the bits involved with updating indices | 19:39 |
| slangasek | juliank: that was what prompted my comment on the bug back in March | 19:40 |
| slangasek | (the apt indices themselves are probably fine, but then there are supplementary things like apt-xapian-index and appstream(?)) | 19:40 |
| juliank | yep | 19:43 |
| juliank | slangasek: I think the reason not to do 1800 is that the admins go home at that point, rather than arrive at work around that time, so it takes longer to fix breakage? | 19:45 |
| slangasek | juliank: for my part, the reason not to do 1800 is that I'm still using my computer at 1800 ;) | 19:48 |
| juliank | slangasek: That makes sense too | 19:49 |
| juliank | slangasek: I hope mvo is around next week, he has insight | 19:50 |
| juliank | Unless it was pitti's idea to run twice a day | 19:50 |
| juliank | slangasek: sarnold: If 30 minutes turns out to be a bit low, it might make sense to just go to 5:30 with a 1 hour random delay | 19:55 |
| juliank | That's basically 6:00 +/- 30 minutes then | 19:56 |
| sarnold | I like the sound of that | 19:56 |
| juliank | The imaginary queue for the next SRUs has https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2ce15bdeac6ee93faefd4b42b57f035bef80c567 and https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5094697fe4b2459ff6f706a22006d3028369f3fa for now basically | 19:59 |
| juliank | + the timer change would make a nice short SRU :D | 20:00 |
| juliank | (The config change is only needed for yakkety) | 20:02 |
| juliank | (that is, the "Fix and avoid quoting in CommandLine::AsString") | 20:03 |
| juliank | It will be really fun to see how many stable apt series I can maintain longer term. 2 works OK, soon it's 3 for a few months. | 20:11 |
| juliank | I think I have a sheet somewhere | 20:12 |
| juliank | Yeah at https://docs.google.com/spreadsheets/d/12C3rcJBYc3tUHYUVOW_6Z_mqGqmFmGh4kV921ClbiJs/edit?usp=sharing | 20:12 |
| juliank | Well, I also do security updates and on-demand critical bug fixing for 1.0.9.something in addition to the 1.2 and 1.3 stable series. | 20:14 |
| juliank | I'd be happy to hear some more opinions on how the 1.2 and 1.3 series went so far. I know I sometimes waited too long between updates, causing a larger amount of fixes to accumulate, but if there's anything else to improve, let me know. | 20:18 |
| infinity | juliank: I've had no complaints about the stable series' in general. Given we used to have pretty much 0 apt updates except for security and when we encountered a world-ending critical, it can't get worse. :P | 21:47 |
| infinity | juliank: If you're worried about signing up for too much work there, though, you might want to dial back the knob for what you consider a critical enough bug to warrant a cherry-pick, especially for non-LTS/non-Debian-stable release branches. | 21:48 |
| rbasak | While we're talking about apt, nacc and I have a feature request. "apt-cache bin2src". Trivial enough I think, or would apt-cache be the wrong place? | 21:56 |
| infinity | grep-dctrl? | 21:56 |
| infinity | rbasak: I assume you mean "tell me this binary's source"? | 21:57 |
| rbasak | Right, like chdist does it. | 21:57 |
| juliank | infinity: I think the load is OK on my side. It will mostly be interesting to see how the cherry-picking scales :) | 21:57 |
| rbasak | I appreciate that other tools exist, and I can easily use them. | 21:57 |
| rbasak | But for new contributors, it seems like a simple enough question that should have a one command answer, instead of having to look up Packages files or set up other tooling. | 21:58 |
| rbasak | As for grep-dctrl, it also needs a "well, if there's a Source header, then it's that, otherwise it's the same as the binary name" logic that isn't present there. | 21:59 |
| juliank | rbasak: more source based stuff will come with the next ABI break. I want to add Source fields into the cache | 21:59 |
| juliank | or rather, a source hash table. | 21:59 |
| juliank | Although, that does not really help here as it's Src -> Binary | 21:59 |
| juliank | we already have the information for Binary -> Source, I wasn't sure of tha | 22:00 |
| rbasak | Thanks. Just thought I'd mention it as it came up in a conversation just now, and I saw you were here :) | 22:00 |
| cjwatson | It *is* actually in grep-dctrl (-XFSource:Package), but I agree it would be useful to have a simple way to query the apt cache for it | 22:01 |
| juliank | rbasak: I'm always here. If I'm not actually connected to my ZNC, it's supposed to send me a push message if someone highlights me, but that seems broken right now. | 22:01 |
| rbasak | Oh, you can do that? Useful to know, thanks. | 22:01 |
| juliank | :D | 22:01 |
| cjwatson | If only because grep-dctrl often isn't installed in the sort of minimal contexts I want this | 22:01 |
| infinity | To be fair, just adding "Source" to every binary stanza, even when it's identical to Package, would clear up a lot of confusion. People's concerns about their 2400 baud modems likely shouldn't trump useful data in 2017. | 22:02 |
| infinity | I get why it was deemed redundant data, but people have been confused about it since 1999. | 22:02 |
| juliank | well it's just ${source:-$package} | 22:03 |
| juliank | after you read both source and package fields into variables (in shell syntax) | 22:03 |
| infinity | juliank: Sure. The people discussing this know that. | 22:03 |
| infinity | juliank: People new to it don't seem to find it so obvious. ;) | 22:03 |
| nacc | and we want it for the case of a drive-by developer who wants to help provide a fix for a binary package and may not necessarily realize the distinction -- or know about the mapping and we'd like like to do something like "We couldn't find that source package, but did find a binary package with that name, that is built from this source package. Maybe you meant that one." | 22:03 |
| infinity | "Why do some binary packages not have a Source field?" | 22:04 |
| juliank | We should synthesize the field in apt show output | 22:04 |
| nacc | we can just wrap grep-dctrl for this case in the meanwhile :) | 22:04 |
| infinity | nacc: Well, apt-get source does that. | 22:04 |
| nacc | infinity: good point! :) | 22:04 |
| juliank | That makes the automatic lookup easier. | 22:04 |
| infinity | juliank: Right, that's do it. No need to have it on the disk or wire, if you can synthesize it at lookup time. | 22:05 |
| infinity | s/that's/that'd/ | 22:05 |
| infinity | I don't think complicated tooling is needed when we *should* be encouraging people to read and understand "apt-cache show", but that one tiny change would be a large quality of life improvement for first-timers. | 22:06 |
| infinity | And even for people attempting to do quick shell loops. | 22:06 |
| infinity | Well, look at that, proposed-migration works. | 22:08 |
| infinity | And autopkgtests are autopkgtesting. | 22:08 |
| infinity | Will wonders never cease. | 22:09 |
| infinity | juliank: SPEAKING OF... | 22:09 |
| infinity | juliank: I *still* have a hint in place for test-apt-download-progress sucking. | 22:09 |
| infinity | juliank: I feel like the time you've wasted on that test could have been better applied to perhaps several more graduate degrees or perhaps starting a few families around the world. | 22:10 |
| juliank | infinity: that is an odd test for sure | 22:13 |
| infinity | "odd" is probably not the adjective I'd choose. | 22:13 |
| juliank | Yay, push notifications work again | 22:14 |
| juliank | infinity: There actually is of course a somewhat fix for that: Throttling in the web server. | 22:15 |
| juliank | But that's a situation where unit tests would be much nicer | 22:16 |
| juliank | The test was to check that One method was called when downloading stuff | 22:16 |
| juliank | Speaking of autopkgtests, the failures in reverse deps for the 1.3.5 and 1.2.19 SRUs are the usual unrelated ones. | 22:17 |
| infinity | juliank: But it is entertaining that autopkgtest fails its autopkgtests. | 22:18 |
| juliank | Yes, it sure is. | 22:18 |
| juliank | The fix is probably simple but I never bothered looking at it. | 22:19 |
| juliank | The autopkgtest autopkgtests fail as soon as the next development cycle has started | 22:19 |
| juliank | infinity: I feel like that always delays the SRUs a bit | 22:21 |
| infinity | Yeah, it does. | 22:21 |
| infinity | I investigated the sbuild "regression", and that looks like a simple enough fix. | 22:21 |
| infinity | The autopkgtest one, I'm not as intimately familiar with. | 22:21 |
| * infinity scratches his head at britney's logs... | 22:23 | |
| infinity | I: [Fri Apr 21 22:16:14 2017] - gcc-4.7-arm-linux-gnueabihf on s390x has no source (NBS?) | 22:23 |
| infinity | I mean, sure, it has no source. But it also has no binary. So what are you on about? | 22:23 |
| juliank | The current SRU got a bit weird because 1.2 entered proposed a week before 1.3 and was verified quickly, but then nothing happened when 1.3 was accepted, because I was busy doing Android development | 22:24 |
| juliank | infinity: lol | 22:24 |
| juliank | Android community is a lot more different and more engaged than anything I've seen before | 22:27 |
| infinity | Young communities usually have a very different feel. | 22:28 |
| infinity | Not enough grumpy old guys like me (or just the right number). | 22:28 |
| juliank | But the engagment is mostly testing and feature requests, not code contributions. | 22:28 |
| juliank | Will aptdaemon go away this cycle? | 22:44 |
| juliank | or rather, is someone trying to make it go away? | 22:45 |
| juliank | it's like vampire code or something | 22:47 |
| infinity | juliank: I think people wanted it to die, but I'm not entirely clear on what one replaces it with. | 22:47 |
| juliank | Well, drop sessioninstaller, switch g-s to packagekit, live with the reboot-to-upgrade nonsense, and call it a day? | 22:48 |
| infinity | juliank: update-notifier and update-manager are the two interesting ones I see. | 22:48 |
| jbicha | bug 1673258 bug 1643134 | 22:48 |
| ubottu | bug 1673258 in update-notifier (Ubuntu Artful) "Remove aptdaemon and drop or port its reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1673258 | 22:48 |
| ubottu | bug 1643134 in gnome-software (Ubuntu) "Switch gnome-software to use PackageKit backend" [Wishlist,Triaged] https://launchpad.net/bugs/1643134 | 22:48 |
| jbicha | juliank: I expect the reboot-to-upgrade feature could be patched out but there are other concerns about switching GNOME Software to PK | 22:50 |
| juliank | Honestly, I'd basically just kill update-notifier and update-manager, and just have a special tool for release upgrades. | 22:50 |
| jbicha | I like the idea of switching it to PK but apparently it's slower for some use cases | 22:51 |
| juliank | (Not sure if there was anything else in there that's really needed, have not looked at that in a long time) | 22:51 |
| juliank | jbicha: Well, yes, it's likely slower, but at least it's more maintained than just kept barely alive :) | 22:52 |
| jbicha | and the Ubuntu Desktop team is somewhat risk-averse so they would rather not knowingly introduce regressions if they can avoid it | 22:52 |
| infinity | juliank: update-manager is pretty iconic part of the Ubuntu experience, IMO. gnome-software is super clunky in comparison. | 22:52 |
| jbicha | juliank: you're welcome to bring up the topic on the ~ubuntu-desktop list or wherever | 22:52 |
| juliank | infinity: I'm not a huge fan of gnome-software either. But I'm not sure it's worth it to fight it. There's also something to gain by potentially having one software center like thing where you can schedule/do upgrades for all kind of formats (not sure if snap backend exists yet, does it?) | 22:58 |
| juliank | I only ever used gnome-software to update flatpaks, though | 22:59 |
| jbicha | juliank: if you have questions about gnome-software in Ubuntu, you should talk to Lan_ey or robert_ancell | 22:59 |
| juliank | sure. Or I could look it up myself :) | 22:59 |
| jbicha | well I mean to say that Ubuntu's Desktop Team is putting work into integrating g-s into Ubuntu but it's a big project | 23:01 |
| juliank | I know | 23:01 |
| infinity | juliank: snaps upgrade without human intervention. | 23:02 |
| juliank | infinity: oh yes, right. otherwise my "server" laptop would have had issues ... | 23:03 |
| infinity | But aside from the update-manager UI being about 1000 times better, I also have no idea what an "apt upgrade via packagekit" actually looks like. | 23:04 |
| infinity | Does it abide by the same resolver constraints we carefully chose in update-manager? Can it be made to? | 23:04 |
| juliank | infinity: I only know the UX: It's click, it reboots, applies updates, and then boots to the system. | 23:04 |
| infinity | Uhm. Ew. | 23:05 |
| juliank | I know, it takes some time to get used to that. | 23:05 |
| infinity | Even Windows doesn't force me to reboot for most updates anymore. | 23:05 |
| infinity | That feels like a step rather far backward for apt/dpkg systems. | 23:05 |
| juliank | I don't use it, but I do almost always reboot after an upgrade | 23:05 |
| infinity | I've decided I need to go eat a whole pizza and wallow in software-induced depression. | 23:06 |
| juliank | because library changed and were loaded, or kernel changed, or well, just to see if the machine still boots | 23:06 |
| infinity | juliank: If we did a "patch Tuesday" thing like Microsoft, that might be acceptable. Given that we push SRUs daily, however, and you may well get one a day, it's pretty much a non-starter to suggest that users be forced to reboot when it's not necessary. | 23:07 |
| jbicha | I think that feature was driven by Fedora where maybe upgrade problems are more common? I don't really know enough about rpm/yum/dnf | 23:07 |
| juliank | jbicha: basically *Everything* is driven by Fedora :D | 23:08 |
| === Foxtrot is now known as foxtrot | ||
| infinity | rpm, in theory, is about as error-prone (or not) as dpkg. RPM distros (especially Fedora) have historically lacked the policy and general anal retention of the Debian community that insisted on smooth upgrades. | 23:08 |
| jbicha | lol | 23:09 |
| infinity | Honestly, most Debian people consider it a bug if you're doing a release upgrade and you can't keep working through it. | 23:09 |
| infinity | Me, I think our release upgrader should actually bounce you to a minimal session. | 23:10 |
| infinity | But taking that logic to daily updates is not sane, IMO. | 23:10 |
| juliank | infinity: You have to see it like this: If an update gets pushed that breaks boots, you'll immediately notice it! :D | 23:11 |
| jbicha | yeah, the Unity>GNOME upgrade in particular would be nice to do offline | 23:11 |
| sarnold | heh, I once upgraded a machine to oldstable, then stable, then unstable, all in one go, and it didn't disrupt the machine's use. (minimal at the time, but still.) | 23:11 |
| juliank | I fail quite spectacularly at Debian upgrades. Hit Ctrl+C at the wrong moment, dpkg gets interrupted, and I play half an hour with --force and --unpack and -i options recovering from my mess. | 23:12 |
| jbicha | infinity: you should try the GNOME Software offline upgrade feature in like Fedora 25 or Debian stretch, I believe it uses systemd to apply the upgrade | 23:12 |
| infinity | juliank: Have you considered not doing that? | 23:13 |
| juliank | But it's probably still smoother than a Windows update. | 23:13 |
| jbicha | it might be something we would be interested in for release upgrades | 23:13 |
| sarnold | juliank: you like living on the edge :D | 23:13 |
| juliank | infinity: It's not that bad. Last time I just run dpkg --unpack --recursive /var/cache/apt/archives a few times, and then the system was OK enough for apt to function again and calculate the rest. | 23:14 |
| infinity | jbicha: Of course it does. If systemd isn't involved (and if we can't make up more excuses for jamming it in the initrd while we're at it), it's not modern Linux, right? | 23:14 |
| infinity | juliank: Still, not interrupting it sounds like it would be a better option. :P | 23:14 |
| * infinity -> pizza. | 23:14 | |
| juliank | infinity: true. but it's like "oh, it's still reading package lists for a huge upgrade and I just noticed something I missed" | 23:15 |
| Unit193 | infinity: What type? | 23:15 |
| juliank | a round one? | 23:15 |
| Unit193 | Square ones are rather sub-par, yes. | 23:15 |
| * Unit193 waves to juliank. | 23:16 | |
| * juliank does not eat much pizza. And most people might not even consider something without cheese and only vegatables on top of it a pizza. | 23:17 | |
| sarnold | at that point it's just vegetables on flat bread | 23:18 |
| sarnold | might be alright as it goes but i'm not sure you still get to call it pizza ;) | 23:18 |
| juliank | sarnold: I think the core point of the pizza is the bread, and just a drop of vegetables for fun. | 23:18 |
| Unit193 | What about "white" pizzas? White chicken, ranch, etc? | 23:19 |
| jbicha | juliank: if you add a piece of bread on top, that sounds like a sandwich to me | 23:19 |
| juliank | Pizza is basically just Focaccia with stuff on top that's baked with it | 23:21 |
| * juliank should visit his pizza baker tomorrow | 23:22 | |
| juliank | they speak Italian | 23:23 |
| juliank | or maybe they just pretend, I can't tell :D | 23:24 |
| sarnold | it's all in the hands anyway, right? :) | 23:24 |
| Unit193 | sarnold: There's a place here that bakes them in a stone/wood oven, I hear that's sooo much better. | 23:25 |
| sarnold | Unit193: that's almost always a good sign | 23:25 |
| tsimonq2 | I think it's annoying that my mom cuts pizzas into squares sometimes... | 23:25 |
| juliank | You basically need like 500C to bake pizza | 23:25 |
| tsimonq2 | It just bugs me because someone has to get the corner pieces | 23:25 |
| juliank | and then bake at something like 60 to 90 seconds | 23:26 |
| tsimonq2 | With triangle pizza, you have to share it :P | 23:26 |
| juliank | Let's make Ubuntu pizza | 23:27 |
| juliank | the logo should work fine as a pizza | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!