[02:26] <kayvee> Hi there!
[02:26] <kayvee> Does anyone know how to get new emoji sets installed on pidgin? I copied unicode-emojis to .purple/smileys/ folder but they don't show up in Pidgin Preferences > Themes > Smileys
[02:35] <valorie> hmmm, there seems to be no pidgin channel on freenode
[02:35] <valorie> it's not KDE software so we don't really support it
[02:35] <valorie> kayvee: so you might try #ubuntu in hopes that someone there uses it
[02:39] <kayvee> thanks but i am using this on kubuntu. I figured I will ask here in case someone has an idea...
[07:14] <lordievader> Good morning
[12:15] <BluesKaj> Hey folks
[13:27] <SubCool> Hey, So.. i followed a bad guide. https://askubuntu.com/questions/900308/plasmashell-keeps-crashing-kubuntu - and im trying to get away from it. I am using this at this point, https://askubuntu.com/questions/307/how-can-ppas-be-removed - but during the KDE upgrade it used a upgrade full command which im not sure how to backtrace from.
[13:27] <SubCool> I am already removed the ppa, but- is there a way or key to use the purge and get away from the KDE beta? Its become very hindering.
[13:29] <hateball> SubCool: lets start with which version of kubuntu you are on
[13:29] <SubCool> 16.04 hateball
[13:29] <SubCool> whats the command to check again, uname - >
[13:30] <hateball> SubCool: cat /etc/issue or "lsb_release -a"
[13:31] <hateball> so you installed the kubuntu backports ppa and you want to remove it? or like you said you already removed it, how did you do that?
[13:31] <SubCool> yeah, 16.04.3
[13:31] <hateball> if you used ppa-purge that should have put you back to stock Kubuntu
[13:31] <hateball> !ppapurge
[13:36] <SubCool> I tried.. it said something went wrong.
[13:36] <SubCool> Itried to follow that command, but it said to follow it and insert a package name, which is where my question came in. Because i didnt have a particular package to install, it was a system upgrade.
[13:37] <SubCool> I am trying to backtrack away from the KDE Beta, its killing my resources and systems
[13:39] <BluesKaj> SubCool, you can check in /etc/apt/sources.list.d  for any ppas you'd like to delete, then update and upgarde afterwards
[13:39] <SubCool> BluesKaj, i saw that, i did the remove ppa command to remove it, but- how do i downgrade back?
[13:39] <lordievader> SubCool: What did it say exactly?
[13:41] <SubCool> The following information may help to resolve the situation:
[13:41] <SubCool> The following packages have unmet dependencies:
[13:41] <SubCool> appstream : Depends: libappstream4 (>= 0.10.2) but it is not going to be installed
[13:41] <SubCool> E: Unable to correct problems, you have held broken packages.
[13:41] <SubCool> Warning:  Something went wrong, packages may not have been reverted
[13:42] <lordievader> Hmm, and then ppapurge failed?
[13:42] <SubCool> There is a huge log its trace, but that was the ending fail msg.
[13:42] <SubCool> it traced*
[13:43] <lordievader> Could you pastebin the full output?
[13:43] <lordievader> !pastebin
[13:45] <SubCool> https://paste.ubuntu.com/26451336/
[13:46] <lordievader> You may want to install `aptitude` and run the command again.
[13:46] <lordievader> Do you have other ppa's enabled?
[13:47] <SubCool> I installed it, and it says the ppa is not there.
[13:47] <SubCool> lordievader i dont know about others, i mess with this machine only once every few months. it generally lays dormant unless something goes wrong. - which occured recently.
[13:48] <lordievader> Yeah, it was commented. Check `/etc/apt/sources.list.d/` I think it should still be there (just commented out).
[13:50] <SubCool> Youre right, its in there. and not commented out either.
[13:50] <lordievader> Not? Hmm, then an `sudo apt update && sudo ppa-purge <address>` should do.
[13:56] <SubCool> https://paste.ubuntu.com/26451399/
[13:56] <SubCool> But, i have to go... ill take this up again later. THanks guyS!
[14:01]  * lordievader starts to think that removing all gui packages from a tty is a good idea
[16:12] <user|21691> ahoy there good folks of the interwebs!
[16:13] <user|21691> i have a slight problem, after a power outage, my kubuntu ssd wont boot at all, it freezes on the startup picture... any of you have some idea as to what to do now_
[16:55] <user|13228> Hello - can someone tell me where the chat app settings for telepathy are stored? Whenever I try to click on Settings > Configure Chat Application in the menu, the chat app crashes.
[17:52] <slayerbrk> So for some reason on kubuntu every time i reboot kate gets readded to my favorites. Any idea how to prevent this?
[18:54] <SlayerBRK> im having an issue with my favorites, every time I rebbot kate is added to to favorites even though i removed it.
[18:55] <SlayerBRK> reboot*
[20:26] <BluesKaj> SlayerBRK, looks like it's there by default
[22:20] <Alumin> how can I adjust the mouse sensitivity of my Trackpoint mouse?  I can't find anything in the control panel, and listing the properties with xinput doesn't show anything that seems to help (although I did try fiddling with a few values)
[22:21] <Alumin> right now it's so fast all the time that I can hardly click on small icons and window controls
[22:25] <valorie> I usually get to the right place with krunner, which is alt+space
[22:25] <valorie> or alt+f2
[22:26] <valorie> type mouse
[22:26] <valorie> should get you to the right place
[22:27] <valorie> Alumin: ^^^
[22:28] <Alumin> valorie: where are you suggesting I check, besides the mouse section of System Settings?
[22:29] <valorie> afaik that's it
[22:29] <valorie> there should be maybe an advanced section?
[22:29] <valorie> or so
[22:30] <Alumin> nope


[02:35] <JohnnyL> Did anyone see the article about Ubuntu concerning RMS on slashdot?
[02:36] <JohnnyL> http://linux.slashdot.org/story/12/12/07/1527225/rms-speaks-out-against-ubuntu
[02:36] <yescalona> discuss with the wall
[02:36] <yescalona> http://www.theregister.co.uk/2012/12/07/stallman_on_ubuntu_spyware/


[04:42] <Unit193> gcr-viewer.desktop:X-GNOME-Bugzilla-Component=gcrX-Ubuntu-Gettext-Domain=gcr  that looks correct! :D
[08:48] <rbasak> xnox: o/
[08:50] <rbasak> xnox: wearing my server team hat, rather than my SRU hat: how do you plan to proceed with intel-microcode please?
[09:08] <xnox> rbasak, yo. it's in the unapproved queue. Waiting for accept or a reject with a snarky comment.
[09:08] <xnox> which is the usual responses i get with most of my sru upload.
[09:09] <xnox> (then again maybe snarky comments are only from a pw & i nfinity.... and maybe only for me....)
[09:11] <rbasak> xnox: I hadn't rejected in case SRU consensus was the opposite of my opinion.
[09:12] <rbasak> xnox: but I've had +1 and no opinion from anyone else.
[09:12] <xnox> rbasak, my expectation is for SRU review be more trigger happy - one way or the other.
[09:12] <rbasak> Fair enough
[09:12]  * rbasak pulls the trigger
[09:17] <mwhudson> Laney: based on touched-it-last do you want to figure out why session-migrate ftbfs with python 3.6?
[09:17] <mwhudson> Laney: https://launchpadlibrarian.net/324067009/buildlog_ubuntu-artful-amd64.session-migration_0.3_BUILDING.txt.gz
[09:18] <mwhudson> (or decide it's irrelevant now and remove it from the archive)
[09:18] <mwhudson> didrocks: you too? ^^
[09:18] <Laney> haha
[09:18] <Laney> it's certainly not irrelevant
[09:20] <mwhudson> boo!
[09:21] <xnox> rbasak, awww my proposed srus got rejected. But i think what i have prepared was right. I have no other updates to propose for this package to upload. Removing assignee.
[09:21] <mwhudson> hasn't built since y so let's see if it's broken in artful already
[09:21] <mwhudson> yes it is
[09:23]  * Laney nods
[09:23] <mwhudson> the failure is not very transparent
[09:28] <Laney> it's complaining about the " somehow
[09:30] <rbasak> xnox: you want me to ask my manager to ask the foundations manager to assign someone as I think it's important for server users?
[09:30] <xnox> rbasak, i believe intel-microcode is not actually subscribed by any team =/ and there was confusion whether kernel, foundations or server should be taking care of it.
[09:31] <rbasak> xnox: Zesty would be OK, but then it'd be inconsistent with the other upcoming SRUs.
[09:31] <rbasak> xnox: understood. I think one of those three teams needs to start taking care of it. I'll ask my manager to hammer it out with the other teams.
[09:31] <xnox> rbasak, at least zesty can be used as a canary to check this microcode doesn't kill puppies.
[09:33] <mwhudson> Laney: yeah
[09:33] <rbasak> xnox: I don't like it, but OK.
[09:33] <mwhudson> Laney: some unicode nonsense?
[09:37] <mwhudson> no the stderr really does contain ? not "
[09:37] <mwhudson> why would that be...
[09:46] <rbasak> xnox: do you know if microcode updates are persistent or do they need re-application on every reboot?
[09:47] <mwhudson> Laney: looks like glib changed:
[09:47] <mwhudson> mwhudson@aeglos:/opt/opensource/deb/py36$ grep "Failed to exec" -r glib2.0-2.*/glib/gspawn.c
[09:47] <mwhudson> glib2.0-2.48.2/glib/gspawn.c:                           _("Failed to execute child process \"%s\" (%s)"),
[09:47] <mwhudson> glib2.0-2.53.3/glib/gspawn.c:                           _("Failed to execute child process “%s” (%s)"),
[09:47] <mwhudson> Laney: not sure why that's getting mangled to ? though
[09:47] <Laney> that's not a ? though
[09:47] <Laney> :)
[09:47] <mwhudson> jinx
[09:50] <Laney> mwhudson: maybe a missing setlocale(LC_ALL, "")?
[09:50] <mwhudson> yeah something like that maybe
[09:50] <Laney> and setting of a UTF-8 locale
[09:50] <mwhudson> in session-migrate itself
[09:50] <mwhudson> ?
[09:50] <Laney> in main, yeah
[09:51] <Laney> the tests are decoding things to UTF-8 so probably running in C.UTF-8 would be expected?
[09:55] <xnox> rbasak, they are not persistent. On each boot stock microcode is loaded, then uefi firmware may update the microcode, then we get a chance to update the microcode in the initramfs, and then on recent kernels microcode can be updated at runtime, and then all of that is lost on reboot.
[09:56] <mwhudson> Laney: sounds plausible at least, i have an anglophone's confusion when it comes to locales
[09:56] <xnox> rbasak, hence e.g. in the SRU bug i'm asking for journalctl -k / dmesg output, it should be similar to http://paste.ubuntu.com/24971121/ when a relevant microcode has been applied.
[09:56] <xnox> mwhudson, it's mostly s/s/z/
[09:58] <rbasak> xnox: thanks, that's very useful to know. What's the the difference between early initramfs and normal runtime from the kernel/hardware perspective? I didn't think there was any distinction? But there has been talk of Trusty not having early initramfs support. I don't follow why that's a thing.
[09:59] <xnox> rbasak, early micocode loading means that microcode is appended to the initramfs as an extra cpio archive. The kernel looks at the initramfs, notices there is microcode appended, and then it loads the microcode before executing init of the initramfs.
[09:59] <xnox> rbasak, meaning that microcode is loaded "early", before any userspace process is started.
[10:00] <xnox> rbasak, this is relevant in the context of e.g. lock ellision where microcode update _removes CPU instructions_
[10:00] <rbasak> Ah. That makes sense - thanks!
[10:00] <xnox> and e.g. loaded shared libraries already did the checks if they can use something, continue to try to use them, and segfault.
[10:04] <Laney> didrocks: mwhudson: something like https://paste.debian.net/973679/ ?
[10:08] <mwhudson> Laney: +1 (is the "Run the tests in C.UTF-8" part really necessary, it's not in my sbuild at least...)
[10:08] <Laney> mwhudson: I don't know what you're guaranteed
[10:08] <Laney> when I entered an schroot I was in the POSIX locale
[10:08] <mwhudson> Laney: belt and braces it is then!
[10:09] <Laney> and it fails there obvs
[10:09] <Laney> it's didrocks project really so I'll wait for his review
[10:16] <mwhudson> Laney: ok
[10:45] <mwhudson> xnox: are you going to end up looking at botch for the ocaml transition?
[10:49] <xnox> mwhudson, yes. it is a lie that it is in the second round, as it clearly fails to install things from like round six.
[10:49] <xnox> mwhudson, i still have a bit to do to get there http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
[10:50] <mwhudson> xnox: ok
[10:50] <xnox> sorry level 7, as botch wants dose3 to be installable.
[10:50] <xnox> i have been uploading level 3 fixes today
[10:50] <mwhudson> xnox: python 3.6 does something odd to it but i can't look into that until it's build-deps install again :)
[10:51] <xnox> mwhudson, its build-deps should be installable in the -release pocket; e.g. you should be able to install botch and all the build-deps in the release pocket without -proposed.
[10:51] <xnox> mwhudson, and then get python 3.6 into there. No?
[10:51] <mwhudson> ah yea that might work
[10:51] <mwhudson> i also have a lot of other things i could look at first
[10:51] <xnox> that is also true
[11:00] <mwhudson> xnox: i owe you an email about subiquity stuff, will have to be tomorrow now
[11:00] <mwhudson> xnox: was going to suggest maybe implementing vlan support first
[11:02] <xnox> mwhudson, could do.
[11:03] <xnox> mwhudson, at the moment i'm fixing livecd-rootfs to give me something sensible on s390x. At the moment build success; no contents. As the binary hooks ignore errors from snap download =)
[11:03] <mwhudson> ha
[11:03] <xnox> mwhudson, i, at the moment, still have plenty of things i could be doing with subiquity.
[11:04] <xnox> mwhudson, any tips / documentation on how you rebuild subiquity and re-run it in development would be helpful. So far I am improvising as I go along.
[11:04] <mwhudson> xnox: there is an inscrutable script in installer/geninstaller
[11:04] <mwhudson> but it's very different from the livecd-rootfs process so yeah
[11:04] <xnox> mwhudson, tah! will look.
[11:05]  * xnox picked the devil i know - livecd-rootfs path =)
[11:05] <mwhudson> this area is not really idea
[11:05] <mwhudson> if you can come up with instructions to make an image with livecd-rootfs on my machine, that'd be great
[11:06] <xnox> i am using launchpad builders at the moment, but it should be possible to use Odd_Bloke's cloud builder to do a completely local build with local shnaps and local livecd-rootfs
[13:30] <didrocks> Laney: sorry, having water infiltration and a specialist came, checking in
[13:38] <decci> Hi
[13:38] <decci> Is there any way one can pass DKMS module for my storage RAID controller card using live PXE environment
[13:46] <didrocks> Laney: mwhudson: ok, the patch looks good to me, and indeed, C.UTF-8 fun :) mind doing a PR against https://code.launchpad.net/~ubuntu-desktop/session-migration/trunk ? (you can even upload it yourself if you want, I don't mind)
[14:04] <Laney> didrocks: oh dear
[14:17] <decci> Any idea how can one pass DKMS driver during the PXE boot installation
[14:17] <decci> Ubuntu trusty lacks RAID controller driver and I need to pass it during the installation phase
[14:18] <decci> usually I use driver disk to pass it
[14:18] <decci> But now I have Live PXE boot environment
[15:05] <xnox> doko, this is known / transient?
[15:05] <xnox> dpkg: error processing archive /tmp/apt-dpkg-install-VAxZ47/32-gcc-6_6.3.0-20ubuntu1_ppc64el.deb (--unpack):
[15:05] <xnox>  trying to overwrite '/usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3
[15:46] <juliank> apt 1.5~alpha1 should hit artful tomorrow, making libgnutls28 a dependency of the apt package, because the http method gains native https support.
[15:47] <juliank> That's still very early now, so it's opt-in (set dir::bin::methods::https to "http")
[15:47] <juliank> Very early as in: I wrote this yesterday
[16:02] <juliank> in anticipate it becoming the default in a few weeks, though, so please test :) [and I forget to syncpackage it from experimental it would be great if somebody else does]
[16:03] <juliank> Once the new https method is default, apt-transport-https will then install an curl+https variant or something
[16:04] <juliank> and we drop it next release cycle
[16:04] <xnox> so 18.04 LTS is a test monkey for bustler?! =)
[16:05] <juliank> xnox: Yeah. Like 16.04 is for stretch, mostly :)
[16:06] <juliank> stretch was the first time apt > 1.1 was shipped in Debian, I'm not sure when we started shipping that in Ubuntu
[16:06] <LocutusOfBorg> "buster" not "bustler" :D
[16:07] <LocutusOfBorg> we started with xenial, 16.04
[16:07] <LocutusOfBorg> 1.2.10-1.2.20
[16:07] <juliank> Did willy still have 1.0.something?
[16:07] <juliank> ehm, wily, and yes
[16:08] <juliank> So, we put one of the biggest releases in APT's history into an LTS release without even having a single test release before it....
[16:08] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/apt/+publishinghistory?batch=75&direction=backwards&memo=150&start=75
[16:08] <juliank> Luckily that went well
[16:08] <LocutusOfBorg> xenial I would say
[16:08] <LocutusOfBorg> with a shiny 1.1.3
[16:09] <juliank> LocutusOfBorg: I just looked at https://launchpad.net/ubuntu/wily/+source/apt, and that was <IP_ADDRESS>ubuntu1
[16:09] <juliank> so, yes, xenial
[16:09] <LocutusOfBorg> publishinghistory keeps tracks also of removals
[16:09] <LocutusOfBorg> in case some AA removed it after being copied from unstable/experimental or whatever
[16:09] <LocutusOfBorg> but who would remove that lovely apt 1.1? :D
[16:11] <juliank> 1.5 will be artful's series, and it surely will be artful.
[16:14] <juliank> infinity: I just disabled test-apt-download-progress in my master branch, I thought you'd like to know
[16:18] <jbicha> laughing as we mangle each other's release code names
[16:45] <infinity> juliank: Just gave up trying to make it reliable? :P
[17:03] <juliank> infinity: Too annoyed that 1.4.6 has not migrated yet
[17:03] <juliank> Can make it more reliable later, but want to have reasonable situation now
[17:07] <infinity> juliank: Oh.  Let me bump that hint for 1.4.6 :P
[17:08] <infinity> juliank: (But yay if I never have to hint that test again)
[17:08] <juliank> Do we have https enabled Ubuntu mirrors?
[17:09] <infinity> juliank: None that Canonical hosts.
[17:09] <infinity> juliank: We do, however, rely heavily on apt-transport-https for private PPAs.
[17:09] <infinity> juliank: (1.4.6 hinted)
[17:10] <infinity> Of course, won't migrate until the alpha freeze is lifted tomorrow.
[17:10] <juliank> infinity: But that's not a huge set of users to test the new https method, then :)
[17:10] <juliank> infinity: thx
[17:10] <infinity> juliank: It's not an insignificant number, but certainly not as huge as https-everywhere mirrors would be, no.
[17:11] <infinity> juliank: OTOH, I'm fundamentally opposed to people who think bulk traffic should go over https "just because" :P
[17:11] <infinity> "I don't want the gubmint to spy on me and know that I install moon-buggy on all my servers."
[17:12] <juliank> infinity: Ah, not just because, people want to make it harder to figure out which packages you download, so they don't know which software versions you have installed.
[17:12] <juliank> or even which packages
[17:12] <infinity> juliank: Yeah, I covered that. ;)
[17:12] <infinity> juliank: And yes, it's a plausible attack vector, sort of, except that people who are that paranoid should also be installing the latest security updates ANYWAY.
[17:12] <infinity> juliank: So, it kinda negates itself.
[17:13] <juliank> infinity: Not sure. But I guess it also helps with some "helpful" firewalls
[17:13] <juliank> Unless they are too "helpful"
[17:14] <infinity> juliank: Unless what they're really saying is "I don't want people to know that it takes me three months to evaluate a security update before rolling it out" in which case, I think they get to keep aaaaaall the pieces left to them from their inevitable intrusion.
[17:14] <rbasak> xnox: can I retry your systemd upload builds? I'm running artful :-/
[17:14] <juliank> infinity: And well, there are also https proxies, which we'll soon be able to support :)
[17:15] <juliank> I have my experiences with https proxies....
[17:15] <infinity> Oh look, doko broke gcc.
[17:16] <doko> never
[17:16] <nacc> has anyone tried to use the autopkgtest-virt backends with sbuild successfully? Specifically trying ot use autopkgtest-virt-lxd
[17:16] <infinity> juliank: Right.  So, none of the above was in any way meant to discourage you from improving https support.  Just a bit of a tangential rant about https archives.
[17:16] <infinity> Unpacking gcc-6 (6.3.0-20ubuntu1) over (6.3.0-14ubuntu3) ...
[17:16] <infinity> dpkg: error processing archive /tmp/apt-dpkg-install-OLqr6Z/37-gcc-6_6.3.0-20ubuntu1_amd64.deb (--unpack):
[17:16] <infinity>  trying to overwrite '/usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so.0.0.0', which is also in package cpp-6 6.3.0-14ubuntu3
[17:16] <infinity> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[17:16] <infinity> doko: ^
[17:17] <infinity> doko: I'm going to delete it from proposed, so it stops breaking builds.
[17:17] <rbasak> Ta
[17:17] <doko> ok
[17:17] <doko> hmm, it should have a replaces ...
[17:17] <juliank> infinity: Would be good if we can drum up some people that check over the code from a security perspective, it's only about 300 lines of gnutls calling now, that seems a bit easy.
[17:18] <juliank> That's the TLS support: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6
[17:18] <infinity> juliank: You might see if sarnold (or someone else from his team) is down to do a review/audit for you.
[17:19] <infinity> rbasak: I'll retry all the builds that broke when it's gone.
[17:19] <rbasak> Thanks!
[17:19] <juliank> Eww, I accidentally squashed the SOCKS refactoring in there
[17:19] <juliank> So, only below the whole socks part
[17:20] <juliank> If somebody wants to be silly, we can run SOCKS on TLS if there is demand.
[17:21] <doko> infinity: do you have a binary package, or a build log? can't find it in lp
[17:21] <infinity> doko: https://launchpadlibrarian.net/325906551/buildlog_ubuntu-artful-amd64.systemd_233-8ubuntu2_BUILDING.txt.gz
[17:21] <infinity> doko: Can't find what in LP?
[17:21] <doko> infinity: no, the gcc-6 build log
[17:21] <infinity> doko: https://launchpad.net/ubuntu/+source/gcc-6/6.3.0-20ubuntu1
[17:22] <doko> ok, that link doesn't exist anymore from the gcc-6 page
[17:22] <infinity> doko: Indeed, because I deleted the package.
[17:24] <infinity> doko: So, indeed, there's no Replaces there.
[17:52] <doko> infinity: uploaded -21. the patch backported from gcc-7 applied to the wrong chunk :-/
[17:54] <infinity> doko: Oops.
[17:56] <infinity> doko: "cpp-6 (<< 7.1.1-8)" <-- Shouldn't that be 6.3.0-20 for cpp-6?  Using a 7 version there means you'll have that Replaces "active" for the life of gcc-6.
[17:57] <doko> ohh, sure. I'll fix that. but that shouldn't hurt for the upload
[17:57] <jbicha> xnox: Ubuntu's systemd has been kept in sync, so have you discussed your change with Debian? https://bugs.debian.org/761658
[17:57] <infinity> doko: Yeahp, should be fine for now.
[18:34] <rbasak> jbicha, xnox: Debian's position is clear, no? What is there to discuss? Note that they justify their position in part by systemd-resolved not being enabled by default. I think it is in Ubuntu now?
[18:36] <jbicha> rbasak: maybe resolved would be enabled in unstable too? I think it's at least polite to let the Debian maintainer know when Ubuntu intends to diverge
[18:37] <jbicha> it's about communication; I'm not saying Ubuntu shouldn't diverge when it makes sense
[18:40] <jbicha> IIRC mbiebl wasn't interested in changing the setting since it didn't seem to be a practical problem since nobody used resolved; that basis is no longer true now
[18:40] <jbicha> oh, I didn't realize he was in this channel, hi!
[18:41] <jbicha> IMO it's the person who makes the change who should start the conversation :)
[19:07] <mbiebl> jbicha: can you give me some context?
[19:08] <jbicha> mbiebl: https://launchpad.net/ubuntu/+source/systemd/233-8ubuntu2
[19:14] <mbiebl> xnox: I assume if no fallback server is defined, the DNS servers acquired via dhcp are tried again (in order)?
[19:15] <mbiebl> not sure if I understand https://github.com/systemd/systemd/issues/5755 correctly, but it seems, resolved switches to alternative DNS servers (and the fallback) very quickly
[19:15] <mbiebl> and sticks with them
[19:16] <mbiebl> i.e. it doesn't retry the servers in order like defined in /etc/resolv.conf on a new request
[19:17] <mbiebl> in light of that, it seems resolved uses the google name servers more often then necessary
[20:20] <juliank> Hmm, so looking at bug 1522675, AFAICT all that needs to happen is for update-notifier to Pre-Depend on apt (>= 1.1~) and then change the owner of /var/lib/update-notifier/package-data-downloads/partial/ to _apt
[20:22] <juliank> Or is that owned by update-notifier-common
[20:23] <juliank> I'm not entirely sure where the dir is created
[20:23] <juliank> nvm
[20:39] <jbicha> juliank: I'm annoyed that I see the warning when I use "apt install ./foo.deb" as a subsitute for "dpkg -i" or gdebi
[20:40] <sarnold> you can do that? o_O
[20:41] <jbicha> the ./ is a bit annoying too but that's a different issue
[20:41] <juliank> jbicha: The ./ is really annoying IMO
[20:41] <juliank> But not my decision
[20:42] <juliank> Well, I did not make the decision
[20:42] <juliank> jbicha: I hope we can drop the ./ when we turn of regex and glob matching, and switch to a stricter CLI
[20:44] <juliank> jbicha: Where do you see that, I don't see that in zesty
[20:45] <juliank> Hmm, but I guess _apt seems to have read access to my files
[20:45] <juliank> Now
[20:46] <juliank> jbicha: It's fairly silly for file:/, I agree
[20:46] <juliank> Or well, there is no download at all I think
[20:46] <jbicha> juliank: https://paste.debian.net/973798/
[20:47] <jbicha> I did mention this on that LP bug :) would you like me to file a new bug somewhere?
[20:53] <juliank> jbicha: Well, this issue was "scary message" and that's "solved"
[20:53] <juliank> So yes, another issue might be a good idea
[20:54] <juliank> Anyhow, let's hope I did not break update-notifier-common :)
[20:55] <juliank> I tested it, and it seems fine, but there might be issues
[20:55] <juliank> The diff is tiny: https://launchpadlibrarian.net/325943314/update-notifier_3.180_3.181.diff.gz
[20:57]  * juliank used the same setup apt uses, so he's hopeful it works out


[00:01] <CaMason_> ack I just did a revert when I didn't mean to. Can I undo that?
[00:02] <CaMason_> nv I found a way to fix it
[00:17] <ym1> I would like to know if there is a place where the installation/configuration of loggerhead is documented
[00:18] <ym1> In fact I am looking for a bzr branch explorer
[00:18] <ym1> Based on what I read on Internet it seems that loggerhead is the defacto standard for this
[02:28] <GPHemsley> is there a way to convert an existing repository to use --no-trees?
[02:30] <evarlast> yes, bzr remove-tree
[03:36] <ryanakca> Could one have a ``safepoint'' commit that doesn't show up in the commit log, but only acts as an ``Oh !&^#%, why did I do that... at least I can revert to what I had 5 minutes ago instead of having to revert to the previous commit''... or should I just commit more often?
[03:37] <ryanakca> Use case: When you're trying to fix something through trial and error
[04:49] <spiv> ryanakca: well, you can commit and then later uncommit then commit again.
[04:49] <spiv> ryanakca: But really, why not just keep the commit?
[04:52] <ryanakca> spiv: well, if you're going by trial and error, you might endup with 3-4 ``safepoints'' that are absolute rubbish and have no use in a commit log, at least not in a public one :)
[04:54] <spiv> ryanakca: maybe.  They might not be totally worthless, and there isn't much harm from leaving them there.
[04:54] <ryanakca> spiv: *nod*
[04:55] <spiv> ryanakca: especially if this is happening on a branch, when the branch is merged to trunk the details of how that branch evolved aren't very prominent in the history.
[04:56] <spiv> If you're working directly on trunk then that's a different matter, but then I'd argue you should be taking advantage of a DVCS and using branches instead :)
[04:56] <spiv> You could even manage your experimental work on your branch as another branch, but that workflow is probably a bit too heavyweight for what you're after.
[05:04] <ryanakca> spiv: well, I'm the only one working on it at the moment... but it will eventually end up being used in my school, and most likely other schools in my school board...
[05:04] <ryanakca> spiv: Anyways, I probably ought to branch when I go by trial and error :)
[05:04] <ryanakca> G'night :)
[05:04] <spiv> ryanakca: g'afternoon ;)
[05:04] <spiv> (It's a bright and sunny 4pm here in Sydney)
[08:06]  * thumper votes for default log to be short (no merge details)
[08:07] <spiv> thumper: bzr alias log="log --short"
[08:07] <thumper> spiv: yes I know#
[08:07] <spiv> :)
[08:07] <thumper> spiv: I'm thinking of all the new users
[08:08] <thumper> all those people who go "gee bzr log is slow compared to xyz"
[08:08] <spiv> "Won't somebody think of the newbies?"
[08:08] <thumper> spiv: that way people can go "bzr log --merges" to show merges (or something)
[08:08] <spiv> (Sunday afternoon perhaps not the best time to get a completely serious opinion from me)
[08:09] <thumper> and they can take the hit of the graph sort or whatever
[08:09]  * thumper was reading traceback
[08:10] <spiv> We don't get many people saying the log is slow (although we do get some).  And arguably the solution there is to make it fast, not change the output.
[08:11] <thumper> spiv: yeah, but one is easier and allows for better comparison of apples
[08:11] <spiv> I do think the default log should make the existence of merges visible, so that the way merges are tracked is reasonably discoverable.
[08:11]  * thumper goes to make brownies
[08:11] <spiv> Well, we're not trying to build a tool that's the same as $other_vcs, we're trying to build a better tool :)
[08:11] <spiv> So I don't think that's automatically a good reason to change how we work.
[08:12] <hiredman> a better tool that interoperates so I can pull stuff from github?
[08:12] <spiv> Personally I use --line most of the time.
[08:12] <thumper> I think someone should check to see who actually cares to see the merges by default
[08:12] <thumper> spiv: I use --line too
[08:12] <thumper> hiredman: that is in progress
[08:13]  * thumper really leaves now
[08:13] <hiredman> I know
[08:13] <hiredman> I am just being an asshole today
[08:13] <spiv> And then "bzr viz" for more in-depth exploration of history, but not every user will have the bzr-gtk plugin (or the ability to install it).
[13:27] <epsy> Hi, how do I cleanup the .~n~ files?
[13:43] <AfC> $ find . -name '*~*'
[13:43] <AfC> $ find . -name '*~*' | xargs rm
[13:50] <marcus-b> better: find . -name "*~*" -print0 | xargs -0 rm
[13:56] <epsy> brb
[14:22] <LarstiQ> beuno: hmm, I wouldn't say I'm the mastermind
[14:22] <LarstiQ> marcus-b: hey! :)
[14:24] <LarstiQ> epsy, marcus-b: `bzr clean-tree --detritus` would also remove the .~n~ files
[14:32] <marcus-b> LarstiQ: I don't know bzr well, but I do know my unix tools :)
[14:32]  * LarstiQ nods
[15:05] <pygi> hi hi
[15:14] <DimmuR> Hello i'm trying to run bzr+ssh. I've created directory on server, and i have entry in authorized-keys to copy files without giving passwords, but when i try to init repo i get error: http://wklej.to/MV3 (when i use scp to copy files it works)
[16:01] <CaMason_> I just got a commit error regarding x11 initialisation whilst commiting via SSH
[16:01] <CaMason_> I installed extdiff earlier. Perhaps that's causing the issues?
[16:11] <dash> I've got a large branch I've cloned from a remote source, and now i'm wishing I'd created a repository for it to go in. Is too late? Can I create a repo without having to re-fetch all that history?
[16:17] <pbor> create a new repo and then fetch from the one you cloned locally
[16:17] <dash> oh. of course :)
[16:17] <CaMason_> my commit actions etc are causing "X11 initialization failed" errors when used via SSH
[16:18] <pbor> CaMason_: no idea, sorry
[16:22] <CaMason_> it was a problem with dbus. Removing it, as I don't use it
[16:28] <ryanakca> marcus-b: <offtopic> 'find . -name "*~*" -print0 | xargs -0 rm'    vs    'find . -name "*~*" -exec rm {} \;'    ? </offtopic
[16:44] <dash> Hmm =/
[16:44] <dash> I am attempting to branch from an svn repo on sourceforge, using bzr-svn
[16:45] <dash> and i'm consistently getting "Could not read response body: Connection reset by peer" after several minutes
[16:45] <dash> is there something I can do to make bzr not give up so easily? :)
[16:45] <jelmer> dash, it's the svn libraries that are giving up
[16:45] <jelmer> dash, are you fetching over https?
[16:45] <dash> jelmer: no.
[16:46] <jelmer> your best bet is probably to wait until the sf svn servers are less heavily loaded
[16:47] <dash> I suspect a contributing factor is that /trunk (which I am branching from) in this repository was moved from a different url in an early revision
[16:47] <dash> different path, I mean
[16:47] <jelmer> that shouldn't be relevant
[16:47] <dash> well
[16:47] <dash> it looks like bzr-svn does a lot of PROPFINDs for nonexistent paths
[16:47] <dash> I didn't know if that mattered.
[16:48] <jelmer> you mean it's actually getting 404's back?
[16:48] <dash> yes
[16:49] <jelmer> what's the URL you're trying to import?
[16:49] <dash>  http://posterita.svn.sourceforge.net/svnroot/posterita/trunk
[16:51] <dash> so i'm seeing a lot of things like "PROPFIND /svnroot/posterita/trial/posterita"
[16:51] <dash> to which 404s are given
[16:52] <dash> I'm just guessing that this is making it take longer, so make it have more chance to disconnect :)
[16:54] <jelmer> it doesn't ignore unexpected errors like that, I suspect that's all happening deep down in the svn libraries
[16:55] <dash> right
[17:22] <jelmer> dash, it seems to be working with the 0.5 branch for me, though it's very slow because of sf
[17:23] <dash> aha, the secret version ;)
[17:23] <dash> well i'm not in a hurry, I just want to get it eventually.
[17:25] <dash> hmm if that were true I would just wait until 0.5 was released
[17:26] <dash> I guess I am in a hurry, a little.
[17:40] <dash> jelmer: so, think I should try 0.5?
[19:37] <lifeless> moin
[20:33] <thumper> ah lifeless, you back this week right?
[20:35] <thumper> lifeless: can I have a quick voice call with you?
[20:37] <lifeless> sure
[20:37] <lifeless> skype, now?
[20:38] <thumper> ok
[20:41] <lifeless> ?win 38
[21:11] <lifeless> Peng: I wonder if I could convince you to do me a favour?
[21:11] <Peng_> lifeless: I dunno. What's the favor? :)
[21:11] <lifeless> Peng: to decide on a good batch size, I need a graph with two measurements, for different batch sizes, and different project sizes
[21:11] <lifeless> the measurements are memory peak, and time
[21:12] <Peng_> I did that for a few different sizes on a copy of bzr.dev.
[21:12] <lifeless> the axes are group_size and project_size
[21:12] <lifeless> Peng_: yah, which I am thankful for, and is why I know I need to fix it
[21:13] <lifeless> Peng_: but I don't currently know things like 'how bad is it at 1000 on openoffice'
[21:13] <lifeless> Peng_: nor what the minima for bzr.dev is.
[21:13] <Peng_> OpenOffice.org? I imagine that's "Peng's machine would die swapping" bad. :P
[21:13] <lifeless> Peng_: so I'm thinking of a little script to reindex a branch several times with a different group size, and report the results in csv or similar output
[21:14] <lifeless> Peng_: of course, I'll run this on a canonical datacentre machine
[21:14] <lifeless> Peng_: the favour is to write the script
[21:14] <Peng_> Ah.
[21:15] <lifeless> then I can throw it at ooo, at mysql, at bzr, at bzrtools
[21:16] <lifeless> Peng_: if you are interested this would be really useful.
[21:18] <Peng_> I'm sure I could write some little hack of a script, but I dunno if you'd like it. :P
[21:18] <Peng_> I guess it would need to be possible to set group_size. I just edited index.py a bunch of times.
[21:19] <lifeless> Peng_: just has to work. Heck, I was considering a massive printf to replace the index.py file
[21:19] <lifeless> Peng_: sed would probably be nicer :P
[21:22] <Peng_> Or making it an attribute on Index objects that you could change from Python.
[21:23] <lifeless> hi poolie
[21:23] <lifeless> Peng_: sure.
[21:23] <lifeless> Peng_: or even - shock - a global
[21:24] <lifeless> so you don't have to get access to a specific index
[21:25] <Peng_> Oh, different methods have different group_sizes.
[21:26] <lifeless> yeah there are two
[21:26] <lifeless> there is 'how many revisions', where the inventory text size will chew up memory
[21:27] <lifeless> and there is 'how many file versions at once', where text sizes (isos!) will chew up memory
[21:29] <Peng_> I've never changed it in _terms_for_file_terms.
[21:29] <lifeless> sure
[21:29] <lifeless> whats in my head is to not guess about what works well for users
[21:29] <lifeless> but to graph it out, and choose the place that works best
[21:30] <lifeless> the two group sizes are independent
[21:30] <lifeless> well, not quite.
[21:30] <Peng_> Well...do you want to test both, or just the _index_revisions one?
[21:30] <lifeless> the file terms is capped by the index revisions one (can't index morefile changes than occured in a given set of revisions)
[21:30] <lifeless> I'd start with the index revisions one, that should give plenty of data
[21:31] <lifeless> though it may be confounded (a large index revisions one might use little memory, if the file terms one is driving the peak)
[21:32] <mwhudson> does anyone have any recommendations for good conflict resolution tools?
[21:33] <lifeless> guns
[21:33] <lifeless> lots and lots of guns
[21:33] <lifeless> It worked in the matrix.
[21:33] <mwhudson> hmm
[21:34] <mwhudson> i think i want meld and a much larger monitor
[21:35] <bob2> sdiff/ediff in emacs is nice if you already use emacs
[21:36] <mwhudson> ediff confuses me a bit
[21:36] <mwhudson> what's sdiff?
[21:36] <mwhudson> i think the problem is that one branch has moved things around and the other has made small edits to the things being moved
[21:37] <bob2> simple mode that highlights in-file conflicts, with some keybindings to pick one or the other or both for each hunk
[21:38] <bob2> ah, out of that league, then
[22:08] <lifeless> spiv: shall we converse?
[22:18] <poolie> lifeless: spiv is away at osdc today
[22:18] <poolie> you and i could talk though
[22:18] <lifeless> oh!
[22:18] <lifeless> didn't realise osdc was here
[22:18] <lifeless> should I go down?
[22:19] <lifeless> poolie: you're on leave no? but perhaps a quick call could be useful
[22:19] <lifeless> poolie: I'll ring your house?
[22:19] <spm> poolie: osdc doesn't start till tomorrow? Or is spiv on the org committee or similar?
[22:20] <poolie> yes, call
[22:20] <mwhudson> osdc starts for realz on wes
[22:20] <mwhudson> weds
[22:21] <mwhudson> spiv just took the week off anyway i think
[22:26] <poolie> planning to look at bug 302698
[22:44] <Peng_> lifeless: OK, I wrote an evil little script for the bzr-search thing. I hope you weren't joking about running "sed" over index.py. ;)
[22:44] <Peng_> lifeless: Also, if it gets interrupted, things will probably be left in a horrible mess.
[22:44] <mathrick> hmm, does anyone here know (and is willing to explain) the difference between a transplant and a normal merge, or do I need to pester #hg?
[22:46] <Peng_> mathrick: AIUI, transplants can cherrypick, but it'll create a different revision with different revids and parents and whatever.
[22:46] <Peng_> (if we're talking about hg)
[23:00] <mathrick> Peng_: hmm, I'll guess I'll just ask the hg guys then
[23:02] <Peng_> Good idea. :)
[23:14] <lifeless> Peng_: thanks!
[23:15] <lifeless> poolie: I need to shoot off to the doctors too today, I forgot to mention it in all the kufuffle
[23:16] <mathrick> any idea how hard it'd be to implement "add-on branches" (as mentioned in https://lists.ubuntu.com/archives/bazaar/2008q4/050022.html )? It strikes me as something you'd really want to have to keep your distro work in sync with upstream
[23:16] <mathrick> or is there something I'm not seeing that makes it not a good / redundant idea?
[23:19] <Peng_> lifeless: http://paste.pocoo.org/show/YkaM3FCdH5ILeNUOlV0h/ -- did I mention that it's an evil dirty hack and you probably won't like it? :)
[23:19]  * Peng_ is trying to lower expectations as much as possible.
[23:19] <poolie> mathrick: it's probably not technically super hard, more a matter of deciding how you want it to work
[23:19] <poolie> robert's idea of having marks of files or regions would probably be good
[23:20] <mathrick> poolie: oh, link?
[23:20] <mathrick> also, I was thinking about strands of development a'la threads in loom
[23:20] <mathrick> just with the opposite effect on your working area
[23:20] <lifeless> mathrick: using a loom and cherrypicking down would do it
[23:21] <mathrick> lifeless: could you elaborate? I tried to use loom, but decided it does exactly what I don't want with the history when I change threads
[23:21] <lifeless> mathrick: well the root problem you have is that its impossible to do a full merge/push from 'development' to 'mainline' *excluding data*.
[23:21] <mathrick> yes
[23:21] <lifeless> full merge/push always include everything committed
[23:22] <lifeless> so you have to cherrypick repeated - do merges specifying paths to merge, or specific revisions
[23:23] <mathrick> yup
[23:25] <mathrick> I could do it using loom by hand, but it'd require me to switch between threads to get "development" and "testing" views all the time, which is a pain
[23:25] <lifeless> Peng_: sweet
[23:25] <mathrick> ie. I couldn't actually run any code when in development thread, and I couldn't edit any when in testing thread
[23:26] <lifeless> mathrick: I don't understand why you couldn't run code
[23:26] <mathrick> lifeless: sec, lemme sketch that
[23:33] <mathrick> lifeless: http://pastebin.com/m23f854c8
[23:37] <lifeless> mathrick: edit and commit in testing
[23:37] <mathrick> lifeless: but then the changes will be only visible in testing, which means the pushes won't see them. They will be treated as if they were my local conf changes
[23:37] <lifeless> mathrick: when you are done, you can go to main, merge -r testing path1 path2
[23:38] <mathrick> hmm, lemme parse that
[23:38] <mathrick> what's path1 and path2?
[23:38] <lifeless> mathrick: you have to cherry pick testing to main, regardless of the toolchain you use, for your stated desire
[23:38] <lifeless> paths that you want to merge within the branch
[23:38] <lifeless> another way of spelling it is
[23:38] <lifeless> switch main; merge -r thread:testing
[23:38] <lifeless> bzr revert --forget-merges
[23:39] <lifeless> bzr revert server.conf
[23:39] <lifeless> bzr commit -m 'whatever'
[23:39] <lifeless> mathrick: have you considered 'shelve' though?
[23:39] <mathrick> right, but that's exactly what I wanted to avoid. It's heaps of manual work, and if I forget it only once, I have unwanted commits in the mainline I have to deal with
[23:40] <mathrick> hence the desire to have a tool which keeps track of what I want and don't want to merge for me
[23:41] <mathrick> loom is very nice for when you only merge downstream, but it fails to enable a nice workflow for pushes to the upstream without polluting them with distro patches
[23:41] <lifeless> mathrick: so, loom isn't finished; I think this would be great to have streamlined in loom
[23:41] <lifeless> there are missing components in bzr core to do a *great* job, but a servicable one should be doable
[23:42] <mathrick> lifeless: right, I'd love to have it in loom, although it'd really turn it upside down in some regards
[23:42] <lifeless> the current theory is that you would keep one or more threads for 'never send upstream'
[23:42] <lifeless> as for how you do the commits, I'd like a commit like 'commit -t main'
[23:42] <lifeless> to commit a change to a specific thread
[23:43] <mathrick> right
[23:43] <lifeless> it probably would want to merge-it-up on the fly
[23:43] <mathrick> what does merge-it-up mean?
[23:44] <mathrick> now, for something completely different, I have a repo that bzr serve completely dies on -- it uses 500+ MB RAM, then dies with some exceptions when clients try to access the repo. How do I debug it?
[23:44] <lifeless> merge each thread to the one above, so that the change does not appear as a change any more
[23:44] <mathrick> I guess I'll start for finding 1.9 debs for intrepid
[23:45] <lifeless> mathrick: well, firstly, newer bzr has fixed some memory issues from 1.6/1.7/1.8
[23:45] <lifeless> mathrick: file a bug with the exceptions though
[23:46] <mathrick> lifeless: you mean before I upgrade to 1.9?
[23:46] <lifeless> yah
[23:46] <mathrick> ok
[23:46] <lifeless> if the server side is dying
[23:46] <lifeless> (and the server is already running 1.9)
[23:46] <mathrick> no, that's the 1.6
[23:46] <lifeless> upgrade the server first then
[23:46] <mathrick> I'm trying to serve from my machine
[23:47] <lifeless> there are debs in the bzr ppa
[23:53] <mathrick> oh, interesting
[23:53] <mathrick> it dies right away now
[23:54] <mathrick> http://pastebin.com/d73b4f039
[23:55] <lifeless> mathrick: ugh
[23:55] <lifeless> mathrick: uhm, can you run with BZR_PDB=1
[23:55] <mathrick> sure
[23:55] <lifeless> then you can print self._sockname
[23:56] <mathrick> (Pdb) self._sockname
[23:56] <mathrick> ('::', 4155, 0, 0)
[23:56] <mathrick> humm
[23:56] <lifeless> I'd certainly start by filing a bug, but it does look ... odd
[23:56] <mathrick> it's getting an ipv6 socket?
[23:57] <lifeless> yeah that would fit
[23:57] <lifeless> definitely file that bug
[23:57] <mathrick> will do
[23:57] <mathrick> still, it'd be useful if I could serve in the meantime :)
[23:59] <lifeless> comment out that line, or just print the _sockname, rather than prettyising it
[23:59] <lifeless> e.g.
[23:59] <lifeless> return "%s" % self._sockname


[08:32] <gimpnixon> hey everyone, I did a recent update for my focal foosa build and it caused issue with wine specifically d3dadapter, now wine no longer launches at first it was saying that it was a polygonoffset issue and after removing libdedadapter9-mesa I no longer get the polygonoffset error but wone still refuses to load with "X Error of failed request: BadMatch" here is the pastebin of my update log with the
[08:32] <gimpnixon> recomended autoremove after update https://pastebin.com/ZMGmTeyf
[08:38] <gimpnixon> https://pastebin.com/y8rgpZcd