=== blahdeblah_ is now known as blahdeblah
=== simonquigley is now known as tsimonq2
=== lag_ is now known as lag
=== rbalint_ is now known as rbalint
=== DarinMil- is now known as DarinMiller
=== elmo_ is now known as elmo
=== rbalint_ is now known as rbalint
=== geser_ is now known as geser
=== Mirv_ is now known as Mirv
[07:00] <RAOF> Ooops. GPG smartcards work better when you're not accidentally SSH'd into a remote system and wondering why it can't find your smartcard…
=== thegodfather is now known as fabbione
[08:12] <sil2100> oSoMoN: hey! I'm looking at the libreoffice SRU from you - any reason the debian/changelog mentions unreleased versions like 1:5.4.5-0ubuntu0.17.10.1, 5.4.5-0ubuntu0.17.10.5 etc.?
=== cpaelzer_ is now known as cpaelzer
[08:15] <oSoMoN> sil2100, they were released, as security updates
[08:18] <sil2100> oSoMoN: oh
[08:19] <sil2100> oSoMoN: you're right! A new upstream release as a security update? Wow ;)
[08:19] <sil2100> oSoMoN: anyway, thanks!
[08:19] <TJ-> is there an LP 'package' to report issues against the seeds?
[08:19] <oSoMoN> sil2100, they were minor updates, fixing a couple of CVEs
[08:22] <cjwatson> TJ-: historically they've usually gone on the appropriate *-meta package
[08:22] <TJ-> cjwatson: I thought so mut my search-fu was lacking which one ... thanks
[08:26] <TJ-> cjwatson: I'm trying to find the correct package to reassign to for a 'installer should provide XXX VPN not PPTP out of the box' but LP package search isn't helping me. bug #1752417
[08:26] <ubottu> bug 1752417 in network-manager (Ubuntu) "Out of the box, Ubuntu Bionic offers only insecure VPN option" [Medium,Triaged] https://launchpad.net/bugs/1752417
[08:29] <cjwatson> TJ-: from your description that sounds like ubuntu-meta, then.  I haven't spent any time thinking about the bug
[08:30] <TJ-> cjwatson: thanks... weird, recently I've noticed LP searches seem to come up incomplete. I did the package search and that one didnn't show, only ubuntustudio-meta. I feel/see this doing bug searches too the last couple months.
[08:32] <TJ-> to be clear, not a search via the bug tracker 'also affects distro/package' interface, but from e.g. https://launchpad.net/ubuntu/+search?text=-meta
[08:32] <sil2100> oSoMoN: ok, looks good, approving - but eh, again the tools seem to hang on it, will have to do it manually (package too big probably)
[08:32] <cjwatson> TJ-: That's site search, which you probably shouldn't expect to give you accurate package name results ...
[08:33] <TJ-> cjwatson: ahhh!
[08:33] <oSoMoN> sil2100, thanks
[08:33] <TJ-> cjwatson: bug search not matching on phrases in bug titles is something I've been noticing though
[08:33] <cjwatson> TJ-: but the reason it didn't find ubuntu-meta is that it's 'All packages with binaries whose name includes "-meta"' and ubuntu-meta ships no such binaries
[08:34] <cjwatson> TJ-: that's all best-effort, in general, but if you have a specific example we can look
[08:35] <cjwatson> (sorry, not site search, but a binary package name search.  I misread the URL.)
[08:35] <TJ-> cjwatson: Ahhhhh... thank you for the explanation. I'll keep tabs on the bug searches now see if there is a pattern
=== gpiccoli_ is now known as gpiccoli
[11:32] <Nafallo> juliank: hi. do you have time for an apt related Ubuntu 16.04 issue I'm having? :-)
[11:33] <juliank> Nafallo: A bit.
[11:34] <Nafallo> juliank: the apt updates kick in before I have time to set the corporate proxy, which means the lockfiles kick in when I'm trying to use apt through ansible. this is for client installations I'm doing automatically.
[11:35] <Nafallo> juliank: would there be an easy way to stop the processes cleanly before I run my stuff? :-)
[11:35] <juliank> Why can't you set the proxy first?
[11:35] <juliank> and no, if it's running upgrades there's no way to stop it cleanly.
[11:35] <juliank> (if it's just downloading, you can probably send SIGINT to the apt process)
[11:36] <Nafallo> I'm not sure the user is behind the proxy. they may be out of office when installing. I've got a desktop icon for applying the corporate settings when they are in the office or via VPN :-)
[11:36] <Nafallo> well, it should be sitting on network timeouts since it may be in the office after all :-)
[11:37] <Nafallo> the problem is I have both use cases at the same time on hundreds of users across the globe ;-)
[11:38] <Nafallo> SIGINT. I'll try that. thanks :-)
[11:39] <Nafallo> (unless I can figure out a way to work around this problem entirely.)
[11:42] <juliank> Nafallo: I think best might be to set a proxy script for apt that looks at the network state and returns the proxy.
[11:43] <juliank> Now I need to find an example
[11:43] <juliank> The script needs to write http:// URLs, or DIRECT to its stdout
[11:45] <juliank> And then you need to set acquire::http::proxy-auto-detect to it's path.
[11:45] <juliank> e.g. acquire::http::proxy-auto-detect "/usr/local/bin/find-proxy";
[11:49] <seb128> tsimonq2, you should teach your ubiquity triaging script to not set to incomplete other tasks than the ubiquity one
[11:50] <seb128> tsimonq2, it seems to change all the tasks, it reopened some components which were set as invalid to set them incomplete for example
[11:50] <Nafallo> juliank: oh. that's actually nicer then setting it explicitly.
[11:51] <juliank> Nafallo: one caveat is that it does not work for https repos with http proxies prior to artful
[11:52] <juliank> or maybe I fixed that earlier
[11:52] <juliank> hmm
[11:52] <Nafallo> heh, I'm not doing https during the installation :-)
[11:52] <juliank> nah
[11:52] <juliank> good then it works fine for you
[11:52] <Nafallo> I'm already using `wget -q -t 1 -T 10 --spider https://www.ubuntu.com` to figure out network status. so just need to wrap that up :-)
[11:53] <tsimonq2> seb128: ack, sorry
[11:54] <seb128> tsimonq2, np, thanks for fixing!
=== Guest62303 is now known as _hc
[12:11] <Nafallo> juliank: https://paste.ubuntu.com/p/HcVVnst7Zm/ that should do then :-)
=== ahasenac` is now known as ahasenack
=== ahasenack is now known as Guest7888
[12:13] <juliank> Nafallo: Come on, at least use if check_network; then echo "DIRECT"; else echo "http:/..."; fi - checking twice is weird :D
[12:13] <Nafallo> hehe
[12:13] <Nafallo> fine ;-)
[12:15] <tjaalton> I don't understand how git-ubuntu is supposed to work
[12:15] <tjaalton> cannot create user data directory: /home/tjaalton/snap/git-ubuntu/391: Not a directory
[12:15] <tjaalton> while it surely is
[12:15] <juliank> tjaalton: sounds like a snap problem
[12:16] <tjaalton> ok
[12:16] <juliank> tjaalton: so /home/tjaalton/snap/git-ubuntu/391 is an existing directory?
[12:16] <juliank> or /home/tjaalton/snap/git-ubuntu/ is one?
[12:16] <Nafallo> juliank: https://paste.ubuntu.com/p/kSV9ntqhcW/ ;-)
[12:17] <juliank> Nafallo: that's nicer
[12:17] <Nafallo> missed an END :-)
[12:17] <tjaalton> juliank: 391 is, created just now
[12:17] <tjaalton> when I first ran it, I guess
[12:18] <juliank> odd stuff
[12:18] <juliank> mvo: ^
[12:21] <tjaalton> should there be a manpage for git-ubuntu?
[12:23] <tjaalton> nevermind, I'll do it manually
[12:30] <tjaalton> though I don't know how to create a merge proposal..
[12:31] <Guest7888> tjaalton: what are you trying to do? Maybe I can help, I use git-ubuntu
[12:31] <Guest7888> geez, guest?
[12:31]  * Guest7888 fixes that, don't know what happened
[12:32] <tjaalton> trying to create a merge proposal for pam
[12:32] <tjaalton> cloned the ubuntu/devel branch, added a commit, pushed it to lp:tjaalton
[12:33] <Guest7888> tjaalton: there is "git ubuntu submit", but I'm not sure it's working
[12:33] <Guest7888> tjaalton: what I do is go to lp's code page, +git path, find your repository, branch, and click submit merge proposal
[12:33] <Guest7888> then the target should be ubuntu/devel if it's for bionic, or something like ubuntu/xenial-devel for example if it's for xenial
[12:34] <tjaalton> I don't see a way to propose a merge here https://code.launchpad.net/~tjaalton/+git/pam/+ref/ubuntu/devel
=== Guest7888 is now known as ahasenack
[12:36] <cjwatson> you pushed it to the wrong place
[12:36] <cjwatson> that's the URL scheme for personal repositories that aren't connected to anything else
[12:36] <tjaalton> why of course
[12:37] <cjwatson> you need to push to lp:~tjaalton/ubuntu/+source/pam
[12:39] <tjaalton> alright, seems to work now.. thanks
[12:40] <tjaalton> nacc: ^ sent now
=== mhcerri_ is now known as mhcerri
[12:47] <mvo> tjaalton: sorry, missed the earlier messages, is there still a issue with snaps and if so, can you share some more details please?
[12:51] <tjaalton> mvo: "git ubuntu" doesn't work here
[12:51] <tjaalton> it just says "cannot create user data directory: /home/tjaalton/snap/git-ubuntu/391: Not a directory
[12:51] <tjaalton> upgraded to bionic today, installed the snap
[12:52] <tjaalton> first snap on the system
[12:52] <ahasenack> rbasak: ^is that the stable snap?
[12:52] <ahasenack> I have edge 409
[12:53] <tjaalton> git-ubuntu 0.7.4+git16.0a79cbc from 'nacc' installed
[12:53] <tjaalton> installed on my laptop now, seems to work there
[12:54] <tjaalton> both bionic
[13:01] <mvo> tjaalton: oh, first snap - ok, that might be an issue, we have a bug there that we are chasing for first installs
[13:02] <mvo> tjaalton: as a workaround (sorry for this): snap remove git-ubuntu and install it again, does that help?
[13:03] <tjaalton> mvo: didn't help
[13:06] <mvo> tjaalton: thats interessting, I'm in a meeting right now but would love to debug this with you
[13:06] <tjaalton> ok
=== TJ_Remix is now known as TJ-
=== Eleventh_Doctor is now known as Pharaoh_Atem
[13:21] <mvo> tjaalton: does "SNAP_CONFINE_DEBUG=1 git ubuntu" give you useful debug output?
[13:21] <tjaalton> mvo: not really. one thing is that /home itself is a symlink
[13:22] <mvo> tjaalton: aha, thats it
[13:22] <mvo> tjaalton: sitll in a meeting but I think we have forum post describing a fix, the non-standard /home is not well supported right now :/
[13:22] <tjaalton> ok
[13:33] <mvo> tjaalton: the first feedback I got: "when home is a symlink all things fall apart, it's not supported we recommend bind mounts instead" - I think jdstrand has a solution using apparmor tunables to make snaps work when /home is a symlink but I forgot the location of where this is documented
[13:35] <ahasenack> tjaalton: your /home is a symlink because not all apps do the right thing and get a user's home from /etc/passwd or other nsswitch source?
[13:35] <ahasenack> and just assume /home always?
[13:38] <tjaalton> ahasenack: the real target is under nfs rootfs
[13:38] <tjaalton> iirc bind mounts had issues with that
[13:39] <tjaalton> also on a different fs than root
[14:00] <jdstrand> mvo (cc tjaalton): apparmor can be made to handle that with a tunable, the problem is snap-confine harcodes /home and so only the bind mount trick works
[14:01] <jdstrand> I *think* zyga may be looking at that at some point
[14:04] <tjaalton> I have home on a zpool, maybe the symlink was due to bind-mounts happening before zfs was up? can't remember
[14:06] <ahasenack> I also have my home in a zfs dataset
[14:06] <ahasenack> everything but /boot, actually
[14:07] <tjaalton> this is separate from the root disk
[14:08] <tjaalton> and rootfs is ext4
[14:13] <tjaalton> yep, moving the link aside, creating $home and adding a bind mount fixed it
[14:14] <tjaalton> we'll see what happens next boot..
[15:01] <nacc> tjaalton: reading backscroll
[15:02] <tjaalton> nacc: heh, pam pull req
[15:02] <nacc> tjaalton: we create an appropriate remote for your user under the name <lpname>
[15:02] <nacc> tjaalton: ack
=== niedbalski_ is now known as niedbalski
=== herb_ is now known as herb
[17:56] <doko> tjaalton: dogtag ftbfs
[17:57] <tjaalton> doko: yep
[18:43] <awe_> jbicha, any thoughts on the nm test-link failures I'm seeing?
[18:43] <jbicha> awe_: have you used sbuild before?
[18:43] <awe_> yes, but not in a long time
[18:44] <awe_> right, sbuild handles cross-compiles..., and since I'm building native, debuild was my usual default
[18:44] <jbicha> I don't recommend using debuild locally to build packages and I've no experience with pbuilder in a long time so sbuild is it
[18:45] <jbicha> *it is
[18:46] <awe_> ok, I'll give sbuild a try, but will also try on another laptop running 18.04 natively
[18:46] <jbicha> sbuild is basically what the LP and Debian official builds use
[18:46] <awe_> ack
[18:48] <jbicha> there is a way to use nocheck Debian build profile to skip the build tests but I'm a bit fuzzy on how exactly you would set it
[18:48] <awe_> ok, I can look that up. good suggestion
[18:50] <jbicha> it looks like it works for me if I have this line in ~/.sbuildrc
[18:50] <jbicha> $ENV{'DEB_BUILD_OPTIONS'} = 'parallel=4, nocheck'
[18:51] <jbicha> you don't need the    parallel=4,  part but that's useful too :)
[18:51] <jbicha> maybe DEB_BUILD_OPTIONS=nocheck debuild … would work for you?
[18:52] <jbicha> some documention about build profiles can be found at https://wiki.debian.org/BuildProfileSpec
[19:04] <awe_> jbicha, yes that worked (DEB_BUILD_OPTIONS=nocheck debuild -us -uc)
[19:04] <awe_> thanks for the help!
[19:05] <jbicha> cool :)
[19:43] <kasper> hi, i am trying to find build script that created https://packages.ubuntu.com/bionic/liblldb-6.0-dev package on ubuntu side
[19:43] <kasper>  on llvm side, they have cmake, but i want to see what parameters ubuntu package script passed to cmake to build it
[19:45] <kasper> previous versions of this package in ubuntu repos; liblldb-5.0-dev, liblldb-4.0-dev etc. were packaging this directory https://github.com/llvm-mirror/lldb/tree/release_60/include/lldb/API, but this new 6.0 package is missing it (although release_60 branch has it)
[19:45] <kasper> since lldb 6.0 is going to be default package in bionion repo, i am afraid we end up having incomplete package :(
[19:46] <kasper> reported https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009, i was thinking about working on a patch to fix it myself but couldn't find package build script..
[19:46] <ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
[19:46] <sarnold> kasper: if you're already running bionic, you can use "apt-get source liblldb-6.0-dev" to download the thing
[19:46] <sarnold> if you're not, it'll take a bit more work
[19:46] <doko> kasper: https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0
[19:48] <kasper> thanks!
[19:49] <kasper> doko, my cmake skills are not top-notch, but do you think this is a bug in lldb's cmake script (something changed between release_50...release_60) or packaging script that is invoking cmake (some missing/misplaced cmake parameter)?
[19:50] <kasper> i can try troubleshooting it. i am using bionic text-mode atm :)
[19:52] <sarnold> most debian package builds go through debian/rules
[19:52] <sarnold> it's a Makefile in all but name
[19:52] <sarnold> so be careful with those tabs vs spaces :)
[19:53] <kasper> both debian and ubuntu liblldb-6.0-dev packages have this directory 'usr/lib/llvm-6.0/include/lldb/API' but it is empty
[19:54] <kasper> i guess we inherit this problem from llvm-official repos listed here http://apt.llvm.org/
[19:56] <nacc> kasper: it would appear to be oversight, given that llvm-5.0-dev has those files?
[19:56] <nacc> *lilldb-5.0-dev
[19:57] <kasper> yup i can confirm that 3.4, 3.5, 3.6, 3.8, 3.9, 4.0, 5.0 all have headers in this directory
[19:58] <nacc> kasper: should be relatively easy to diff the debian dirs of botyh source packages
[19:59] <kasper> nacc, in fact i reported it upstream few days ago https://bugs.llvm.org/show_bug.cgi?id=36770, was trying to verify on gentoo whether it is a cross distro problem (i.e. something changed in lldb's cmake script).. but gentoo was giving me hard time to get to that point
[19:59] <ubottu> llvm.org bug 36770 in deb packages "LLDB.h is missing from liblldb-6.0-dev package" [Enhancement,New]
[20:01] <kasper> ah, just confirmed on fedor, https://www.rpmfind.net/linux/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/l/lldb-devel-6.0.0-3.fc29.x86_64.rpm their API dir has all the headers
[20:01] <kasper> s/fedor/fedora
[20:08] <kasper> sarnold, 'apt-get source liblldb-6.0-dev' is giving me => Picking 'llvm-toolchain-6.0' as source package instead of 'liblldb-6.0-dev'
[20:08] <kasper> then erroring out => E: Unable to find a source package for llvm-toolchain-6.0
[20:09] <kasper> seems like package makefile sources aren't browsable on web either https://code.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+all-branches
[20:09] <nacc> kasper: works fine here
[20:09] <nacc> kasper: there are no repositories for llvm-toolchain-6.0 (yet)
[20:10] <nacc> kasper: you can also use `pull-lp-source` which does not depend on your apt setup
[20:10] <nacc> kasper: my guess is that you don't have deb-src lines in your apt config
[20:11] <kasper> nacc, it's pretty much stock setup of bionic latest
[20:11] <kasper> basically minimal installation
[20:12] <kasper> docker run -it ubuntu:bionic
[20:12] <nacc> kasper: which isn't necessarily a suitable development environemnt
[20:15] <kasper> nacc, agree. atm i am trying to spot the issue, after that will delve into bionic proper
[20:38] <kasper> nacc, couldn't find sources with pull-lp-source as well :(
[20:38] <nacc> kasper: what did you run?
[20:38] <kasper> pull-lp-source liblldb-6.0-dev --no-conf
[20:38] <nacc> uh
[20:38] <nacc> well, liblldb-6.0-dev is not a source pacakge
[20:38] <nacc> as apt-get source told you
[20:38] <nacc> kasper: pull-lp-source llvm-toolchain-6.0
[20:39] <nacc> tjaalton: did my MP review comment make sense?
[20:39] <kasper> cool, it is downloading tarballs :)
[20:40] <tjaalton> nacc: yes, you'll have it tomorrow
[20:40] <nacc> tjaalton: cool, just wanted to check, thanks!
[20:40] <kasper> i could have fetched it form http://archive.ubuntu.com/ubuntu/pool/main/l/llvm-toolchain-6.0/llvm-toolchain-6.0_6.0.orig-lld.tar.bz2 :)
[20:40] <nacc> tjaalton: otherwise the change looks good
[20:40] <nacc> kasper: well, that's just one orig component tarball
[20:40] <nacc> kasper: so wouldn't have done you any good
[20:44] <kasper> nacc, thanks. `llvm-toolchain-6.0-6.0/lldb/include/lldb/API` has the files. could you please point me where i can find package script, so far i have only found source code of llvm/clang/lldb but not the launchpad script that builds the pacakge
[20:44] <nacc> kasper: debian/rules
[20:54] <kasper> nacc, thanks. nothing jumping out at me when looking at 'diff llvm-toolchain-5.0-5.0.1/debian/rules llvm-toolchain-6.0-6.0/debian/rules'
[20:55] <nacc> kasper: it's not in the pacakging afaict, i think it's an upstrema issue
[20:55] <tjaalton> kasper: file a bug on debian
[20:56] <nacc> kasper: they look to have made some cmake changes upstream that are hard to decide if they are correct
[20:56] <nacc> kasper: i agree with tjaalton though
[20:57] <kasper> nacc, since fedora rpm not missing those files, could be that we need to build some additional cmake target, that wasn't required in v5 and earlier versions
[20:57] <kasper> nacc, correct. i will do that
[20:58] <kasper> can https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009 be moved to debian, or do i have to close this one and open a separate one for deb?
[20:58] <ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
[20:58] <nacc> kasper: you need to file one with debian
[21:00] <kasper> nacc, if debian package is fixed, will ubuntu package pick up the changes automatically? i thought they are separate streams. spotted this issue on their build logs earlier https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-6.0&arch=amd64&ver=1%3A6.0-1&stamp=1520022195&raw=0
[21:00] <nacc> kasper: or fedora is undoing something
[21:00] <nacc> kasper: not automatic, we are after freeze
[21:01] <nacc> kasper: that build also has an empty API directory, afaict
[21:01] <kasper> yup
[21:01] <kasper> 0 files in that dir
[21:03] <nacc> kasper: based upon the upstrema diff of lldb/source/API/CMakeLists.txt, it seems like the old build did some extra work
[21:03] <nacc> tthe new build does something else, and it owuld need some debugging to see if that's the issue
[21:05] <nacc> kasper: it looks like they moved from Headers to FrameworkHeaders
[21:16] <kasper> nacc, lldb had some changes in cmake files between 5..6 but couldn't figure out what change is required from external callsite. was wordering, maybe it's worth checking out the diff between v5.0...v6.0 in rpm too?
[21:17] <kasper> only if i know how to access makefile of rpm packages :D
[21:17] <nacc> kasper: that's up to you :)
[21:17] <kasper> maybe copr has it
[21:42] <kasper> nacc, found this lovely link https://src.fedoraproject.org/rpms/lldb/c/763e3718e9c6339d991554c8c6468b488879beb6. they are using git and their git diff page is awesome :)
[21:43] <kasper> seems like they haven't changed much either
[21:47] <kasper> actually there is https://src.fedoraproject.org/rpms/lldb/c/44958ca9dee94ad785f30ab5b379e740b0d09344
[21:49] <kasper> lldb issue after all :)
[21:49] <kasper> they broke the installation of API headers in cmake
[21:52] <kasper> more authentic/official patch is https://github.com/llvm-mirror/lldb/commit/8f577000b2fe2f5bf5d08e352a2f15f9421f9c82#diff-c6838f2ee3606027bb153637e8024bf5
[21:57] <nacc> kasper: yes, i saw that diff, and wondered about it too
[21:59] <kasper> nacc, would it be possible to ninja this one in before bionic final? *-*
[21:59] <nacc> kasper: well it's a bugfix, so file the bug in ubuntu?
[21:59] <nacc> kasper: and someone can
[21:59] <kasper> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009
[21:59] <ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
[21:59] <kasper> wrote it down in comment 3
[22:00] <kasper> i have done some patchwork in pkgsrc few years ago (for netbsd), but never on Debian/ubuntu, so i might take longer than experts :)
[22:02] <nacc> kasper: i'll build you a PPA version to test, will comment in bug when it's ready
[22:02] <kasper> thank you! <3
[22:04] <nacc> kasper: did you file a bug with debian?
[22:06] <kasper> nope, i was almost going to file it, but then joined fedora-devel to figure out their diffs :D
[22:09] <nacc> doko: fyi, you didn't run update-maintainer onthe last llvm-6.0-toolchain upload :)
[22:11] <doko> nacc: I'm notorious about that :-(
[22:12] <nacc> doko: np, i'll fix it on this upload, presuming it fixes the bug
[22:31] <Faux>  
[22:31] <Faux> ^ typo, ignore.
[22:46] <sarnold> how is it determined what gets seeded? the reporter in 1752417 makes some good points that our default out-of-the-box vpn choice is pretty terrible
[22:47] <Unit193> There's a default VPN choice?
[22:47] <nacc> sarnold: the owning team(s) decide, roughly
[22:47] <nacc> sarnold: based upon technical area
[22:47] <sarnold> apparently PPTP is installed by default :/
[22:48] <nacc> sarnold: pptp-linux ?
[22:49] <sarnold> nacc: or perhaps network-manager-pptp-gnome
[22:50] <nacc> sarnold: network-manager-pptp-gnome is a reverse-recommends of all the desktop metapackages
[22:50] <nacc> it would seem
[22:50] <nacc> so not directly from the seeds
[22:50] <Unit193> ship-live: * pptp-linux                       # client for Microsoft-compatible VPN's, needed for some ISPs
[22:50] <nacc> but there is that one --^
[22:50] <nacc> again, live only, not preinstalled (afaict)
[22:51] <Unit193> network-manager-pptp is under 'Basic network services and Windows integration.'
[23:01] <cjwatson> I mean
[23:01] <cjwatson> it dates back to warty
[23:01] <cjwatson> it's possible it's not the most currently-motivated of choices
[23:02] <sarnold> warty, wow :) I figured it was an old choice that had never been reexamined.. but wow. :)
[23:02] <cjwatson> it's in r1 of the seeds
[23:02] <tsimonq2> O_O
[23:02] <cjwatson> it may be a little difficult to archaeologise a rationale now
[23:03] <sarnold> "needed for some ISPs" was probably reason enough
[23:04] <cjwatson> there was a pre-revision-control wiki seed list but I'm not sure any records of that still exist
[23:05] <cjwatson> yeah, it might be helpful to know who suggested it because it might indicate what country
[23:05] <cjwatson> first mention of it on warthogs@ I can find was Jeff Waugh suggesting it as part of a list of misc VPN software on 2004-05-29
[23:07] <cjwatson> don't really see much serious discussion so I think it was almost certainly just dumped in from a "think of everything people might need to get online" kind of list
[23:08] <jbicha> sarnold: you could probably get network-manager-openvpn-gnome in easily since its source pkg, network-manager-openvpn, is already in main
[23:09] <sarnold> on the one hand we no longer have the "must fit on a CD" pressure to keep the size from going up, but .. I think that's still a self-imposed "lets not go crazy" kind of thing.
[23:12] <robert_ancell> Does anyone know where the canonical-livepatch snap source lives? I want to get it to embed its icon into the snap.
[23:14] <sarnold> lol, launchpad just gave me an OOPS-bad2dcfa884f2f58ab59239854b60434  :)
[23:14] <sarnold> "bad"
[23:14] <sarnold> why yes, I *am* easily amused ..
[23:14] <Unit193> Not just bad, but 'bad2dc'.  You're bad to datacenters!
[23:15] <sarnold> hahah
[23:26] <jbicha> sarnold: I suggest you ask #ubuntu-desktop about default VPN support during work hours or you can use our "mailing list" https://community.ubuntu.com/c/desktop
[23:26] <nacc> robert_ancell: i've pinged the folks who should know, i'll ask them to get in touch
[23:26] <robert_ancell> nacc, thanks!
[23:26] <sarnold> jbicha: somehow I've got a habit of arriving moments after will's "do your hobbies!" quit message :) hehe
[23:27] <jbicha> sarnold: you only have about 3/4 of a second after he posts that before he's gone
[23:27] <sarnold> *nod* :)
[23:27] <jbicha> oh I mean after his "night all" message
[23:28] <jbicha> it's a good strategy, prevents people from giving you more stuff to do on your way out the door
[23:28] <sarnold> and his quit message is a useful reminder :)
[23:34] <Unit193> People /quit?
[23:34] <sarnold> Unit193: will does :)
[23:34] <Unit193> Novel idea.
[23:35] <sarnold> blank irc windows just give me the creeps
[23:35] <tsimonq2> Glad I'm not the only one.
[23:38] <Unit193> sarnold: What about windows that only contain the 'day changed' notice?
[23:38] <sarnold> Unit193: *shudder* like window 4
[23:38] <tsimonq2> I move all of those into one window.
[23:38] <tsimonq2> Those annoy me.
[23:38] <sarnold> I don't visit window 4
[23:39] <Unit193> 'Day changed to 23 Feb 2018' there it is, right there.
[23:39] <tsimonq2> I trust we're all using irssi, *right*? :P
[23:39] <Unit193> Seth is.
[23:39] <tsimonq2> I know, but I think Unit193 uses xchat.
[23:39]  * tsimonq2 runs
[23:42] <Unit193> Ain't no client like the best.
[23:42] <wxl> tsimonq2: no, Unit193 uses silc.
[23:43] <sarnold> haha
[23:43] <sarnold> man that's a blast from the past ..
[23:44]  * tsimonq2 googles
[23:44] <tsimonq2> Oh, hah.
[23:45]  * valorie started on mirc
[23:45] <valorie> :-)
[23:45] <sarnold> blaster from the paster ..
[23:45] <valorie> now konversation
[23:46] <sarnold> mirc was a nice step up from ws_irc
[23:46] <valorie> irssi is fine for the geeks!
[23:46] <wxl> i think my first was ircII
[23:46] <wxl> or maybe EPIC
[23:47] <wxl> whatever cleveland freenet was using way back when
[23:47] <valorie> I remember all those names from making a webpage about them years ago
[23:47]  * wxl beats everyone about the head with his cane
[23:47] <valorie> for genealogists
[23:48] <Unit193> openssl s_client.
[23:48] <sarnold> an ircii script with an embedded backdoor was my introduction to unix security :D
[23:48] <wxl> nice sarnold :)
[23:48] <wxl> Unit193: hey at least you're secure.