[00:33] <doko> jamespage, coreycb: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  shows almost all server/openstack issues. tomorrow is feature freeze. please could you have a look?
[00:49] <coreycb> doko: yes i'll sort those out
[00:51] <coreycb> xnox: doko: we also have a number of autopkgtests blocked by https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1691096
[00:51] <ubottu> Launchpad bug 1691096 in systemd (Ubuntu Artful) "mysql in lxd fails to start with systemd 233: failed at step KEYRING" [High,Triaged]
[00:52] <slangasek> doko: speaking of, do you mind looking at the last comments on https://bugs.launchpad.net/ubuntu/+source/ppc64-diag/+bug/1417608 ?
[00:52] <ubottu> Launchpad bug 1417608 in iprutils (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [High,Incomplete]
[00:52] <xnox> coreycb, yes, we also have all of images broken due to not working networkd/resolvconf.
[00:52] <xnox> coreycb, once we have images out with networkd/resolvconf working properly, i'll be looking into fixing keyring.
[00:53] <xnox> unfortunately breaking the $world is not helping fix that regression =/
[00:53] <coreycb> xnox: thanks, never a dull moment :/
[00:54] <slangasek> xnox: did re-promoting ifupdown fix things as expected?  now we just have other autopkgtest failures to sort out?
[00:54] <xnox> slangasek, it has, and we have cloud images out on 23rd
[00:54] <slangasek> ok
[01:30] <doko> slangasek: I've assigned the issue to me. will have a look
[05:03] <LocutusOfBorg> Unit193, freeze was approaching
[05:03] <Unit193> Indeed. :/
[05:22] <blahdeblah> cpaelzer: Please PM when you have a sec
[05:32] <cpaelzer> blahdeblah: back in a sec and PM you then
[05:32] <blahdeblah> ta - not urgent
[08:30] <Laney> mwhudson: weeeeee
[08:30] <Laney> maybe I can avoid having to kill these jobs again
[08:30] <Laney> slightly annoying procedure
[08:30] <Laney> good work
[08:30] <mwhudson> Laney: do they really get stuck indefinitely?
[08:30] <Laney> no, but it times out and then retries
[08:31] <mwhudson> ah
[09:18] <Unit193> LocutusOfBorg: Gah!  Sorry I didn't see the LP comments, it seems it no longer emails me. :/
[09:34] <mwhudson> Laney: does it make sense to kill off most of the docker.io/ppc64 autopkgtests?
[09:34] <mwhudson> not the ones with containerd in the triggers though
[09:35] <mwhudson> (the new containerd does seem to fix the problem too \o/)
[09:41] <Laney> mwhudson: I guess when it migrates they'll get the new containerd at the next retry?
[09:41] <mwhudson> Laney: ah yes, true
[09:43] <mwhudson> i love(*) that thing where there is a delay between tests finishing and the result appearing on the test list (*) may be a lie
[09:53] <Laney> you shall have results!
[09:53] <Laney> even went green on ppc64el, how about that
[10:03] <mwhudson> hurrah!
[10:14] <mwhudson> woop containerd migrated
[10:15] <mwhudson> so other bits should go through on next retry
[10:17] <Laney> ^_^
[10:31] <andyrock> hey bdmurray
[10:31] <andyrock> I'm wondering if I can use git ubuntu clone update-manager to send a SRU patch (xenial and trusty)
[10:32] <andyrock> instead of debdiff
[10:51] <LocutusOfBorg> Unit193, fossfreedom please get the budgie packages uploaded in debian too
[10:51] <LocutusOfBorg> if they are useful
[10:51] <Unit193> Howdy, I'm not with Budgie.  But I have seen certain packages flowing into Debian recently that were.
[10:52] <fossfreedom> LocutusOfBorg, aye - budgie-indicator-applet will be proposed once budgie-desktop has cleared the new queue.
[10:53] <LocutusOfBorg> ack thanks
[10:53] <LocutusOfBorg> I sponsored 4 budgie packages
[10:53] <LocutusOfBorg> fossfreedom, you should apply for PPU and Debian Maintainer
[10:53] <LocutusOfBorg> Unit193, please write some MOTU application paperwork
[10:54] <LocutusOfBorg> I find a waste of time reviewing your packages, you know the job better than me, I just sign and upload
[10:54] <tsimonq2> LocutusOfBorg: If the DMB meeting had gone through with, fossfreedom already has a PPU application ready ;)
[10:55] <Unit193> LocutusOfBorg: Yeah, I need to get to that.  DMB members keep not showing up to meetings so hard to tell when I can make one. :/
[10:55] <Unit193> But yes, sorry.  I really need to.
[10:56] <LocutusOfBorg> tsimonq2, oh indeed, I missed (and I even looked at the agenda lol)
[10:56] <LocutusOfBorg> Unit193, you need to write the application, or did you already?
[10:56] <Unit193> I need to write it still.
[10:57] <LocutusOfBorg> so you are blocked a step before :)
[10:57] <LocutusOfBorg> no need to be sorry, I'm just saying you are more than ready
[10:57] <Unit193> I keep meaning to ask one of the people if "things you're proud of" count from Debian packages too.
[10:58] <LocutusOfBorg> yes
[10:58] <LocutusOfBorg> they count, specially if I sponsored them and are no-change sync in Ubuntu :)
[10:58] <Unit193> Eg, got Deluge sync'able.
[10:59] <LocutusOfBorg> virtualbox-ext-pack work
[10:59] <LocutusOfBorg> some ruby I sponsored
[10:59] <Unit193> The ruby-net-ssh transition, yeah.
[11:00] <LocutusOfBorg> I did today some mini ruby-transition I might need help
[11:01] <LocutusOfBorg> depending on how autopkgtests performs
[11:07] <LocutusOfBorg> acheronuk, tsimonq2 mitya57
[11:07] <LocutusOfBorg>     * ppc64el: gnucash, kjots, kmymoney, kmymoney-dev, libertine-manager-app, libertine-qt-common, libreoffice-pdfimport, libubuntugestures5, libubuntutoolkit5, notes-app, orthanc-wsi, python-gnucash, qml-module-ubuntu-components, qml-module-ubuntu-components-labs, qml-module-ubuntu-layouts, qml-module-ubuntu-settings-components, qml-module-ubuntu-test, qtdeclarative5-gsettings1.0, qtdeclarative5-render2d-plugin,
[11:07] <LocutusOfBorg> qtdeclarative5-ubuntu-push-plugin, qtdeclarative5-ubuntu-settings-components, qtdeclarative5-ubuntu-ui-extras0.2, qtdeclarative5-ubuntu-ui-toolkit-plugin, ubuntu-budgie-desktop, ubuntu-filemanager-app, ubuntu-keyboard, ubuntu-keyboard-arabic, ubuntu-keyboard-azerbaijani, ubuntu-keyboard-bosnian, ubuntu-keyboard-catalan, ubuntu-keyboard-chinese-chewing, ubuntu-keyboard-chinese-pinyin, ubuntu-keyboard-croatian,
[11:07] <LocutusOfBorg> ubuntu-keyboard-czech, ubuntu-keyboard-danish, ubuntu-keyboard-dutch, ubuntu-keyboard-emoji, ubuntu-keyboard-english, ubuntu-keyboard-esperanto, ubuntu-keyboard-finnish, ubuntu-keyboard-french, ubuntu-keyboard-german, ubuntu-keyboard-greek, ubuntu-keyboard-hebrew, ubuntu-keyboard-hungarian, ubuntu-keyboard-icelandic, ubuntu-keyboard-italian, ubuntu-keyboard-japanese, ubuntu-keyboard-korean, ubuntu-keyboard-latvian,
[11:07] <LocutusOfBorg> ubuntu-keyboard-norwegian-bokmal, ubuntu-keyboard-persian, ubuntu-keyboard-polish, ubuntu-keyboard-portuguese, ubuntu-keyboard-romanian, ubuntu-keyboard-russian, ubuntu-keyboard-scottish-gaelic, ubuntu-keyboard-serbian, ubuntu-keyboard-slovenian, ubuntu-keyboard-spanish, ubuntu-keyboard-swedish, ubuntu-keyboard-tests, ubuntu-keyboard-ukrainian, ubuntu-printing-app, ubuntu-system-settings, ubuntu-ui-toolkit-autopilot,
[11:07] <LocutusOfBorg> ubuntu-ui-toolkit-examples, ubuntu-ui-toolkit-tools, ubuntukylin-desktop, unity-greeter-session-broadcast, url-dispatcher, url-dispatcher-tools, url-dispatcher-tools-gui, utopia-documents, utopia-documents-dbg
[11:07] <LocutusOfBorg> we are just missing them?
[11:09] <tsimonq2> LocutusOfBorg: bug 1711204
[11:09] <ubottu> bug 1711204 in checkbox (Ubuntu) "Remove ubuntu-ui-toolkit from the archive" [Undecided,In progress] https://launchpad.net/bugs/1711204
[11:10] <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871373
[11:10] <ubottu> Debian bug 871373 in src:kmymoney "kmymoney: FTBFS: CMakeFiles/Makefile2:4181: recipe for target 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen.dir/all' failed" [Serious,Open]
[11:16] <acheronuk> LocutusOfBorg: cmake 3.9 borkage?
[11:20] <acheronuk> LocutusOfBorg: possibly? https://cgit.kde.org/kmymoney.git/commit/?h=4.8&id=b0a68ca075928aa29ee1e0007bfb14d714f5a948
[11:37] <mdeslaur> xnox: ha! was just about to upload nss too :)
[11:37] <xnox> mdeslaur, snap
[11:37] <xnox> =)
[11:37] <mdeslaur> xnox: thanks
[11:37] <xnox> mdeslaur, i was like we must migrate all the things for the freeze
[11:37] <xnox> hence retried adt tests; uploaded that; pinged about vanished binutils publication; etc. =)
[11:37] <mdeslaur> now you TIL, the nss curse has been broken
[11:38] <mdeslaur> I AM FREEEEEEE
[11:38] <mdeslaur> ;)
[11:39] <cjwatson> doko: did you intend to delete binutils 2.29-6ubuntu3/s390x?  I see you deleted 2.29-6ubuntu2 on other arches
[11:53] <cjwatson> stgraber: Do you happen to remember if your buildd chroot->lxd proof of concept had a specific reason for using privileged containers?
[11:53] <ricotz> xnox, hi
[11:53] <xnox> ricotz, hello
[11:54] <ricotz> xnox, could you merge the last util-linux changes from debian?
[11:54] <xnox> ricotz, the fdisk split et.al?
[11:54] <ricotz> xnox, yes, it blocks clonezilla
[11:54] <xnox> yeah sure
[11:55] <ricotz> thanks
[13:40] <juliank> xnox: Is there a way to get access to a ppc64el artful? The apt tests fail weirdly in config handling there, but they work fine in Debian's ppc64el port. I assume there is either a gcc optimization bug or a bug in the function starting here https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/configuration.cc#n96
[13:41] <juliank> For testing, it basically reads in configure-index and uses that to check that all options are documented.
[13:41] <juliank> It does not understand the * and ** wildcards on ppc64el builds, but the loop there is complicated.
[13:42] <mitya57> acheronuk, LocutusOfBorg: I can take care of kmymoney
[13:42] <tsimonq2> mitya57: Thanks :)
[13:42] <juliank> There also is a regression in  ~beta2 where another test fails on all non-amd64 architectures, but that's a different topic
[13:43] <juliank> The test fail in line 137 with the "Using unknown config option »%s« of type %s" warning
[13:45] <xnox> juliank, qemu-static should work
[13:45] <xnox> juliank, i have access to it, but i don't think i can expose it to you
[13:47] <cpaelzer> juliank: also I can retry something on ppc64 if you don't need direct access
[13:47] <cpaelzer> direct access has all the authoentication and other hurdles, but if you have a command or script to try let us know
[13:47] <cpaelzer> otherwise as xnox said, static should do the job mostly
[13:47] <juliank> Right
[13:50] <juliank> xnox: One main difference with Debian's ppc64el is that it builds with -O3 instead of -O2 right?
[13:50] <xnox> juliank, yes
[13:51] <juliank> I'll just do a -O3 build on Debian and see if that fails first :D
[13:51] <juliank> That's really fast on the plummer machine :D
[13:52] <juliank> I feel like there might be some undefined behavior in there and it thus just drops the inner loops handling the wildcards...
[13:55]  * xnox likes this juliank c++ compiler validator
[13:56] <xnox> it's like if i see apt ftbfs i'm like - oh noes, we have a compiler bug.
[14:00] <juliank> xnox: Can reproduce with -O3 on Debian ...
[14:02] <juliank> And yes, that's exactly what happens - we don't enter the loop
[14:03] <xnox> compiler 0 - 1 juliank -> no g++, there really _are_ things to do here
[14:05] <juliank> xnox: Heh, apparently that code is not the problem, it's StringSplit(name, "::") not splitting the string
[14:07] <juliank> Split apt::compressor::xz::binary into 1parts
[14:07] <juliank> yeah, lol
[14:09] <juliank> xnox: It's a compiler bug.
[14:09] <juliank> StringSplit takes a std::string const &
[14:09] <juliank> we pass in a "::" literal
[14:09] <juliank> but inside string split, we receive garbage
[14:10] <juliank> doko: ^
[14:11] <juliank> doko: The function call at https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/configuration.cc#n108 for function https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/strutl.cc#n1308 fails to pass a temporary string by constant reference (std::string const & parameter, supplied a string literal "::")
[14:12] <juliank> This is a regression from the gcc 7 update on ppc64el (with -O3)
[14:12] <doko> juliank: test case?
[14:12] <juliank> doko: Let me try to minimize it
[14:19] <juliank> doko: Can't reproduce in a small test case, unfortunately.
[14:20] <doko> juliank: please file a bug report. irc is no good for that
[14:21] <juliank> doko: Right. JFTR: Moving the separator argument literal into a variable fixes the problem ... https://paste.ubuntu.com/25383149/
[14:23] <juliank> doko: I guess it's best to just report that directly upstream to the gcc people, as with all the other bugs .
[14:24] <juliank> Maybe somebody there directly knows what went wrong
[14:25] <doko> juliank: would be good to know if that happens with -O3 on other archs as well
[14:25] <juliank> Yeah
[14:39] <juliank> doko: Uh, StringSplit() had __attribute__((const)). Probably references are handled like pointers - so this means the compiler can assume that we only use their addresses, and thus discards any variable content.
[14:42] <juliank> Sorry for the noise then
[14:43] <juliank> We should really not be playing with these attributes
[15:00] <juliank> I now redefined APT_CONST from __attribute__((const)) to __attribute__((pure)), so we won't have these problems anymore
[15:01] <juliank> Over optimization...
[15:01] <xnox> **/ end black magic
[15:03] <cjwatson> might want to rename it from APT_CONST too :)
[15:03] <juliank> cjwatson: I switched all users to APT_PURE, but I'll keep the macro around as it's in a public header
[15:04]  * cjwatson nods
[15:04] <juliank> xnox: __attribute__((const)) is really black magic.
[15:04] <juliank> xnox: And fairly useless anyway. If you have such functions, chances are very high you have inlined them
[15:05] <juliank> __attribute__((pure)) on the other hand is not really dangerous
[15:05] <juliank> So, now I only need to fix the non-amd64 test case failure, and it should finally worj
[15:22] <stgraber> cjwatson: I can't recall of a particular reason for using privileged containers other than the goal at the time was to have it behave like a chroot but with an init system running which is why I turned off just about every confinement feature we have.
[15:24] <cjwatson> stgraber: I get to choose between working around https://bugs.launchpad.net/snapd/+bug/1712808 and working around https://bugs.launchpad.net/snapd/+bug/1709536
[15:24] <ubottu> Launchpad bug 1712808 in snapd "udev interface fails in privileged containers" [Undecided,New]
[15:24] <ubottu> Launchpad bug 1709536 in systemd (Ubuntu Xenial) "snapd 2.26.14 on ubuntu-core won't start in containers anymore" [Medium,Confirmed]
[15:26] <cjwatson> stgraber: looking at 1712808 I wasn't sure what else snap-related would fail in priv containers
[15:26] <cjwatson> stgraber: or indeed what else the udevadm symlink hack would break ...
[15:27] <stgraber> cjwatson: so we can make the container even more privileged to fix that one :)
[15:27] <cjwatson> wouldn't it risk breaking thehost?
[15:29] <stgraber> yes, but it already can right now. Right now there is no apparmor confinement so the container could remount /sys read/write if it wanted
[15:29] <cjwatson> I mean I assumed that was why /sys is ro in privileged containers
[15:29] <stgraber> adding this to raw.lxc should do the trick:
[15:29] <stgraber> lxc.mount.auto=
[15:29] <stgraber> lxc.mount.auto=proc:rw sys:rw
[15:30] <cjwatson> ah, and I just thought of a reason launchpad-buildd shouldn't use unprivileged containers: it would stop it being able to use lxd for livefs builds
[15:30] <stgraber> At which point liblxc won't do any fancy partial read-only mounts of proc and sys
[15:30] <cjwatson> thanks, I'll give that a try
[15:39] <cjwatson> (my acceptance test cycle is at least ten minutes so can take a while)
[16:04] <juliank> https://launchpad.net/ubuntu/+source/apt/1.5~rc1~ubuntu1 I hope everything works now...
[16:40] <coreycb> doki: i've fixed the openstack component mismatches. for python-zunclient i've moved that to Suggests in heat, and I'd like to have python-zunclient moved back to universe.
[16:41] <coreycb> doko: ^
[17:06] <juliank> Hmm, we should remove apt-transport-https on upgrades to artful
[17:07] <juliank> given that https support is now in the apt package.
[17:12] <nacc> juliank: breaks/replaces that can be dropped after 18.04?
[17:13] <nacc> juliank: not questioning you, testing my own recollection :)
[17:13] <juliank> nacc: Oh, it's still around providing a curl binary, so you should be able to reinstall it (in case there is some bug in the new https code you need to work around). So rather something in the do-release-upgrade script thingy
[17:14] <nacc> juliank: oh i see
[17:14] <Mirv> doko: can you ack bug #1708428 now before Feature Freeze comes into effect so that I could still sync libvoikko too from Debian before FF?
[17:14] <ubottu> bug 1708428 in hfst-ospell (Ubuntu) "[MIR] hfst-ospell" [Undecided,Confirmed] https://launchpad.net/bugs/1708428
[17:15] <juliank> I don't know where that is actually done
[17:15] <Mirv> or cyphermox ^
[17:15] <Mirv> didier seems gone for today
[17:16] <Mirv> 3.5h is plenty of time!
[17:17] <Mirv> anyway, the new hfst-ospell is in ubuntu now too and ~desktop-bugs subscribed
[17:18] <juliank> cjwatson: What's your opinion about .deb delta upgrades for Ubuntu, archive wise?
[17:18] <juliank> I'm not sure if you've seen the ML post over in {debian{-devel,dpkg},deity}
[17:20] <juliank> Deltas require two changes server side, essentially: Builders must fetch the current package version(s) and build deltas for the newly built package; and the delta debs need to be added to the archives (probably uploaded in the changes files along with the rest).
[17:20] <cjwatson> juliank: saw but haven't had much time to form an opinion; it would be a non-trivial amount of work that I don't know when we'd find time for
[17:20] <cjwatson> Why does delta-building belong on builders?
[17:21] <cjwatson> That seems like a publisher task to me
[17:21] <juliank> cjwatson: It's slow (like 1 minute for libreoffice-core on a laptop), running it on archive building hosts is probably to much of a bottleneck.
[17:22] <cjwatson> Perhaps it should be something we do asynchronously and upload separately
[17:23] <juliank> Yeah, the delta building does not have to be done as part of the package build, and I guess LP keeps old versions around anyway, so it should be easy to create deltas later on
[17:23] <doko> Mirv: done
[17:23] <doko> coreycb: ok, what about asn1crypto?
[17:24] <Mirv> doko: thank you! and unping cyphermox
[17:30] <juliank> cjwatson: I guess implementation wise it probably makes more sense to have a separate Deltas file rather than storing deltas for a package version as a field in the Packages file entry. Also allows us to publish deltas in a different repo than packages :D
[17:32] <cjwatson> juliank: so I mean one good thing about debdelta was that it was on a separate host so could be scaled separately
[17:34] <cjwatson> juliank: and there are questions about expiry policy which aren't really obvious
[17:36] <cjwatson> (I haven't read the full thread though)
[17:38] <juliank> cjwatson: Ah yeah, expiry policy is interesting. For Debian, my idea was to just keep "immediate" delta essentially (given an upload to release-{security,updates} generate  deltas against the latest release, release-security, release-update versions. When a new version comes in, drop old deltas.
[17:39] <juliank> Does not catch everything of course :D
[17:39] <juliank> Well for security it should be fine due to unattended-upgrades
[17:39] <juliank> it's unlikely you miss one security update and thus not get a delta
[17:40] <cjwatson> juliank: that's the sort of reason I'd rather not do deltas via uploads - hard to make it flexible enough.  and if you do them asynchronously then you have the opportunity to refine the way they're generated
[17:40] <cjwatson> juliank: you might want to look at http://www.tech-foo.net/snap-updates-are-getting-smaller-heres-why.html
[17:41] <juliank> Doesn't this essentially do what I describe?
[17:41] <cjwatson> obviously that situation is a bit different because there's an active store webservice rather than a passive flat-file mirror, but I'm sure there are still useful lessons to be learned
[17:42] <cjwatson> it's certainly somewhat similar
[17:42] <cjwatson> perhaps Thomi would have useful advice to give
[17:43] <juliank> I'm curious about the xdelta3 choice, bsdiff is usually much more efficient (but, well, a lot slower when generating the diff)
[17:44] <juliank> Or rather my fork of bsdiff, https://github.com/julian-klode/jkdiff/ which has well defined memory requirements and can apply patches streamingly :D
[17:44] <cjwatson> juliank: I wasn't much involved but I know they did extensive data analysis
[17:44] <cjwatson> so worth asking
=== NCommander is now known as mcasadevall
[17:55] <Mirv> libvoikko synced from Debian and built
[18:17] <doko> mapreri: https://launchpad.net/ubuntu/+source/audacious/3.9-1~build1 (not yet accepting the new binaries)
[19:25] <coreycb> doko: ok i've opened an MIR bug for asn1crypto: https://bugs.launchpad.net/ubuntu/+source/asn1crypto/+bug/1712904
[19:25] <ubottu> Launchpad bug 1712904 in asn1crypto (Ubuntu) "[MIR] asn1crypto" [Undecided,New]
[20:05] <Unit193> chrisccoulson: Howdy.  It seems firefox was missed for artful last couple uploads?
[20:07] <Unit193> Welp, guess not.
[20:08] <mapreri> doko: right, after some iterations I got the symbols files right
[20:13] <sarnold> Unit193: he's on vacation for a while
[20:13] <Unit193> Oh OK, thanks.
[20:14] <sarnold> Unit193: last I saw he was having trouble getting rustc built on all our architectures; every arch was throwing different errors. It sounded unfun.
[20:14] <sarnold> Unit193: .. especially because some arches can take more than 32 hours to build the thing
[20:15] <Unit193> sarnold: Ouch yes very much so.  I'm used to seeing it FTBFS in -proposed, but it wasn't there.  Thanks very much for answering.
[20:16] <Unit193> Specifically since I noticed quite a speed up in FF, so pulled the built package from zesty. :3
[21:29] <Umeaboy> Hi!
[21:30] <Umeaboy> Is there a fix coming for the screen settings being wrong when changing the resolution?
[21:31] <Umeaboy> The desktop turns very big when changing from 3840 x 2160 (16:9) to 1920 x 1080 (16:9).
[21:32] <nacc> Umeaboy: did you mean to ask in #ubuntu+1 or #ubuntu?
[21:32] <Umeaboy> I'm using the Xorg driver that was installed as standard.
[21:33] <Umeaboy> Isn't this the right place to ask the developers of the Xorg driver in Zesty?
[21:33] <Umeaboy> nacc: ^^
[21:33] <Umeaboy> Or should I go to #xorg instrad?
[21:33] <Umeaboy> instead
[21:34] <nacc> Umeaboy: this is for development of Ubuntu itself. I think you want support, which is in #ubuntu. Or if you have a specific developer in mind, ping them? Asking this  channel on Feature Freeze day is probably not going to get you far :)
[21:34] <nacc> (my opinion)
[21:35] <Umeaboy> OK.
[21:35] <nacc> Umeaboy: is there a bug filed?
[21:36] <nacc> Umeaboy: or perhaps you have hidpi settings still enabled when you got a normal resolution?
[21:37] <mwhudson> what happened here? https://lists.ubuntu.com/archives/artful-changes/2017-August/008930.html
[21:39] <xnox> mwhudson, it's a sync or a copy or a ressurect (copy from deleted)
[21:39] <xnox> mwhudson, in this particular instance, i do believe it is undelete that was discussed on #ubuntu-release
[21:39] <mwhudson> ah ok
[21:40] <mwhudson> yes seems so
[21:40] <mwhudson> a new bit of ubuntu trivia :)
[21:40]  * xnox wishes i didn't know this stuff
[21:40] <nacc> heh
[21:40] <xnox> or maybe i should take up alcohol as a hobby.
[21:44] <Umeaboy> xnox: I quit drinking alcoholic beverages about 16 years ago. I don't regret doing that at all.
[21:51] <mwhudson> xnox: gotta get ready for NYC
[21:52] <xnox> mwhudson, i'm from Hull, but even up there we did not pre-load for travelling a month in advance!
[21:52] <mwhudson> i was thinking more stamina training but ok :)
=== nacc_ is now known as nacc