[00:25] <tjaalton> mdeslaur, slangasek: do you have plans to merge pam for bionic?
[00:32] <slangasek> tjaalton: no plans on my part
[00:32] <slangasek> tjaalton: well, I should amend that
[00:33] <slangasek> tjaalton: I do actually have a merge staged in https://git.launchpad.net/~vorlon/ubuntu/+source/pam
[00:33] <slangasek> tjaalton: which the Server Team asked for some changes to
[00:34] <tjaalton> slangasek: ok, was just hoping to get the changes from -3.7 in bionic
[00:34] <slangasek> yeah
[00:34] <tjaalton> I can finish it
[00:35] <slangasek> tjaalton: well, the changes requested involve rewriting history, so it may be best if I finish that work
[00:35] <tjaalton> sure, wfm
[00:36] <nacc> slangasek: ack
[00:36] <nacc> tjaalton: do you know when 1.0.0-3 will end up in sid/bionic?
[00:36] <nacc> tjaalton: re: libglvnd
[00:36] <tjaalton> nacc: it's not uploaded yet
[00:37] <tjaalton> waiting for a new upstream bugfix release
[00:37] <nacc> tjaalton: ack, i just saw that's the upload/future version with the tests enabled
[00:37] <xevious> Tests: 768, Assertions: 666, Errors: 178, Failures: 26, Skipped: 9, Incomplete: 8, Risky: 18.
[00:37] <xevious> I dunno about that assertion count...
[00:38] <nacc> xevious: heh, which pkg is this? kolab-storage?
[00:38] <xevious> Yeah
[00:38] <xevious> Obviously something I tried didn't work (Errors: 178)
[00:38] <tjaalton> nacc: right, I'll upload that if there isn't anything more to add in a week or two
[00:39] <nacc> xevious: yeah :) i was down to failures 10 .. do you want my debdiff?
[00:39] <nacc> tjaalton: ack
[00:40] <nacc> xevious: what were you trying, btw?
[00:40] <xevious> nacc: I just had a typo in a recursive search and replace. Doh!
[00:40] <nacc> heh, I've done that a few times now :)
[00:40] <xevious> Just different ways of building the mock classes.
[00:40] <nacc> xevious: ah ok
[00:40] <xevious> To deal with the expectation counts.
[00:53] <nacc> cyphermox: in the case like above, where tjaalton is going to upload a version with the tests enabled at abuild-time, is it ok to approve the MIR now? or do I wait for that version to be available?
[01:05] <nacc> xevious: any luck?
[01:08] <xevious> nacc: Getting there...
[01:09] <nacc> xevious: cool :)
[02:04] <cyphermox> nacc: yes
[02:25] <xevious> nacc: Got it. Just cleaning up the patches...
[02:43] <xevious> Running tests...
[02:56] <xevious> I've created 3 patches while working on this quilt package. If I want to make some changes and refresh the second patch, how do I do that?
[02:59] <sarnold> xevious: probably along the the lines of quilt pop, quilt edit, quilt refresh, quilt push, and quilt refresh if the top-most patch needs it ..
[02:59] <xevious> I think I `quilt pop`, make changes, `quilt refresh`, then `quilt push -a`. Does that sound right?
[03:01] <sarnold> that's roughly the same, yes; the 'make changes' step may need the quilt edit if you're changing a file that isn't already in that patch
[03:02] <xevious> Awesome. Thanks for explaining!
[03:03] <tsimonq2> xevious: My bookmarked ref is https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
[03:04] <xevious> Yeah, I've read bits and pieces of that. I really need to read it end-to-end.
[03:06] <tsimonq2> I'd say DEP-3 is especially important if you haven't read up on it already because imho it's a good, standard way to do patch descriptions, and my sponsors also insisted on it ;)
[03:18] <nacc> xevious: thanks! i'll look for the debdiff
[03:18] <nacc> cyphermox: yes to whch one? :)
[03:19] <nacc> xevious: the most difficult part about quilt, to me, is remembering to tell it which files are about to change :)
[03:20] <sarnold> I've screwed that up more than once.
[03:20] <xevious> Yeah, I've forgotten and gotten like 30 files deep into modifications several times.
[03:20] <xevious> I need to remember to use `quilt edit` instead of `vim`
[03:20] <sarnold> it's especially easy to do when I use 'gf' to go to a file named under the cursor in vim for making additional changes ..
[03:26] <cyphermox> nacc: yes to approving it now
[03:27] <xevious> nacc: FYI, it came down to session-related stuff again.
[03:39] <nacc> xevious: that's reassuring on some level
[03:39] <nacc> cyphermox: and thank you
[03:40] <nacc> xevious: there are some git->quilt tools that make it a bit easier to do, as well
[03:40] <nacc> guilt, iirc
[03:46] <xevious> guilt... what an awesome name
[03:47] <xevious> nacc: https://bugs.launchpad.net/ubuntu/+source/php-horde-kolab-storage/+bug/1749783/comments/24
[03:49] <nacc> xevious: thanks, reviewing it now
[03:50] <xevious> nacc: Is there anything else to look at that isn't listed under php-defaults on the 'excuses...' page?
[03:51] <nacc> xevious: not right now, i think we're going to just have to remove cakephp and gosa for now
[03:51] <nacc> xevious: upstream cakephp +1'd its removal, as they don't want people using that version
[03:51] <nacc> xevious: and gosa will probably get a fix in debian, and we can sync it back down later
[03:51] <xevious> Good news
[03:52] <nacc> xevious: i think all of the horde ones just need retries (I had to upload a few more)
[03:54] <Unit193> sforshee: Can confirm 1737750 builds and functions.
[03:55] <nacc> xevious: looks good, uploaded
[03:55] <xevious> I finally got the LP tag right!
[03:55]  * xevious is very proud.
[03:56] <nacc> xevious: nicely done :)
[04:10] <xevious> brb
[04:17] <nacc> tjaalton: did you see that libglvnd is stuck in bionic-proposed with regressions in nvidia?
[05:11] <tjaalton> nacc: it's part of the transition
[05:12] <tjaalton> nvidia 390 got uploaded, 340 will be after xorg-server is through
[05:57] <nacc> tjaalton: ack
[05:58] <xevious> Are armhf, ppc64el, and s390x tests stalled on autopkgtest.ubuntu.com? I see a ton queued, but none running.
[06:45] <xevious> Yeah... unless they only run between certain hours or something, it looks like something's preventing the armhf, ppc64el, and s390x tests from running on autopkgtest.ubuntu.com.
[08:34] <sunweaver> why that is, I am currently investigating...
[08:34]  * sunweaver is gosa maintainer for Debian
[08:50] <jibel> cpaelzer, Hi, I've bug 1751222 again on bionic
[09:09] <cpaelzer> jibel: hmm
[09:09] <cpaelzer> jibel: we really have this fixed (apparmor wise) both ways now
[09:09]  * cpaelzer reads the bug details
[09:12] <jibel> cpaelzer, yes and I verified that the apparmor rules are there
[09:16] <cpaelzer> jibel: I checked the deny vs the rule but it shoudl match (as it did in the tests)
[09:16] <cpaelzer> jibel: do you have any extra info that could affect this
[09:17] <cpaelzer> jibel: maybe - could you tweak the rule in /etc/apparmor.d/usr.sbin.libvirtd until you found the minimal change that is needed?
[09:17] <cpaelzer> maybe the wildcards, but made no sense working before and it seems good when looking at Deny vs Rule
[09:23] <jibel> cpaelzer, sure, I'll have a closer look today
[09:24] <cpaelzer> jibel: I just tried to recreate - but it works for me
[09:24] <cpaelzer> jibel: sorry, we need to find what is different for you
[09:25] <seb128> cjwatson, good morning. Do you know if the translations import is still stucked processing libreoffice?
[09:27] <acheronuk> jbicha: hi. could we maybe get this fix into network manager? https://bugzilla.gnome.org/show_bug.cgi?id=793324
[09:28] <acheronuk> for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1572244
[10:24] <cjwatson> seb128: It's been making progress through the queue, but every time it hits a libreoffice import it sits there thinking about it for four hours and then times out
[10:24] <cjwatson> I wonder if changing that job to download the file from the librarian to a tempfile on disk rather than keeping it in memory would help
[11:11] <ogra_> sil2100, slangasek, i would appreciate if someone could take a look at bug 1751249
[11:37] <sil2100> ogra_: hm, noted
[12:15] <seb128> cjwatson, k, as long as it doesn't keep retrying the one that timeout and get stucked on it
[12:23] <cjwatson> seb128: No, it doesn't seem to be doing that
[12:24] <seb128> cjwatson, k, well let's see, if those packages are still not imported by monday I might ping you again
[12:25] <seb128> cjwatson, thanks for the help/explanations in any case!
[12:26] <cjwatson> I pushed https://code.launchpad.net/~cjwatson/launchpad/ptuj-via-disk/+merge/338894 in a slightly speculative attempt to speed it up
[12:28] <seb128> thx
[13:24] <ddstreet> smoser hey, i had asked nacc if he could sponsor lp #1718568 but since it's patching code you added it probably makes more sense if you could sponsor it into bionic, you have time for that?  I can sru once it's in bionic
[13:26] <ddstreet> unless nacc is already in the middle of sponsoring it, but i think he's been pretty busy lately
[13:34] <smoser> well, xnox, good news and bad news.
[13:35] <smoser> good news is that the timeout worked (thanks for 'timeout' i didn't know of that tool)
[13:35] <smoser> http://autopkgtest.ubuntu.com/packages/o/open-iscsi/bionic/amd64
[13:35] <smoser> bad news is no new image yet.
[13:35] <xnox> smoser, well, it would be bad news if the new image failed =) new image will be later on today, i believe.
[13:37] <xnox> smoser, pipeline starts at about 3:45 PM
[13:37] <xnox> and it's 1:37PM now.
[15:49] <nacc> ddstreet: sorry! if smoser can't, i can do it today
[15:53] <smoser> ddstreet: i can do that right now.
[15:53] <ddstreet> awesome thnx!
[15:54] <smoser> ddstreet: /me *really* likes git-ubuntu :)
[15:54] <smoser> hint for next time
[15:54] <ddstreet> instead of debdiffs, eh, ok
[15:54] <ddstreet> been meaning to start using it
[15:54] <smoser> once you do, you'll never want to do it the other way
[15:55] <cpaelzer> smoser: xnox: what is the decision on open-iscsi for the time being
[15:55] <cpaelzer> I saw the timeout change come in and work
[15:55] <cpaelzer> but the image is still broken
[15:55] <cpaelzer> do we wait until it is working and retry
[15:55] <cpaelzer> or do we temporarily mask the test?
[15:56] <smoser> cpaelzer: xnox sent a Mp to "bad test" it. but the fix should come in an image numbered 20180223
[15:56] <smoser> so we can bad test or wait hopefully short-number-of-hours
[15:56] <cpaelzer> thanks for the update smoser
[15:57] <smoser> cpaelzer: fix is at https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1750851
[15:57] <smoser> ddstreet: do you mind if i wrap your changelog entries at < 80 ?
[15:58] <ddstreet> smoser did i go over?  sorry i usually check that
[15:58] <ddstreet> go for it
[15:58] <smoser> man that file really needs tabs to spaces consistency
[15:58] <smoser> tabs interspaced randomly
[15:59] <ddstreet> smoser do you have a script/tool you use for the various sponsor checks?
[15:59] <smoser> no
[15:59] <nacc> ddstreet: smoser: there is sponsor-patch
[16:00] <ddstreet> i tried that but it seemed rather heavyweight...and does it check stuff like trailing spaces, line lengths...should look at it more tho
[16:00] <ddstreet> nacc do you use sponsor-patch only for stuff you sponsor?
[16:01] <nacc> ddstreet: it catches most stuff i care about, tbh, i also do a visual inspection of the debdiff and chekc the build and dep8
[16:01] <nacc> ddstreet: and yes to the latter
[16:01] <nacc> ddstreet: well, for some parse of what you wrote. I only use sponsor-patch when sponsoring
[16:01] <xevious> nacc: You're up early!
[16:02] <nacc> xevious: sick kid :)
[16:02] <xevious> Aw, shucks. I'm sorry to hear that.
[16:02] <nacc> xevious: looks like php-defaults migrated ^5
[16:02] <xevious> Awww yiss!
[16:02] <nacc> xevious: thanks :)
[16:02] <smoser> ddstreet: uploaded
[16:02] <xevious> You're welcome. Let me know if there's anything else I can help out with.
[16:03] <nacc> xevious: it will take a bit for it to clear excuses out
[16:03] <ddstreet> smoser thnx!
[16:04] <nacc> xevious: speaking of which, I did hit a weird case with php-horde-crypt: https://bugs.horde.org/ticket/14780
[16:04] <nacc> xevious: i don't think it can possibly work without some relatively invasive cod eupdates
[16:08] <nacc> xevious: but, i don't want to use up more of your time. I can figure it out eventually :)
[16:16] <ddstreet> nacc this is the latest doc i could find on git-ubuntu, is there more details anywhere?  https://insights.ubuntu.com/2017/08/09/git-ubuntu-clone/
[16:16] <nacc> ddstreet: there's a wiki page and manpages
[16:17] <ddstreet> ok
[16:17] <nacc> ddstreet: in general `git ubuntu clone <srcpkg>; cd <srcpkg>; do stuff`
[16:17] <nacc> ddstreet: if that makes sense
[16:17] <ddstreet> yeah, i was looking more for 'process to created commits for sponsorship'
[16:17] <ddstreet> using git-ubuntu instead of manual debdiffs
[16:18] <nacc> ddstreet: right, so you do the normal git stuff
[16:18] <nacc> like it's a real software proejct :)
[16:18] <nacc> and then `git ubuntu submit` in theory
[16:18] <ddstreet> aha ok
[16:18] <nacc> the latter is still in flux a bit, but i think should work
[16:35] <xevious> nacc: I just looked at that ticket for php-horde-crypt. That's definitely a significant change.
[16:35] <bdmurray> juliank: You sponsored the patch in bug 1722411 but I see there have been some updates to it. Do you want to continue with it?
[16:38] <xevious> nacc: The Horde team shouldn't be shelling out to interact with GPG, though. There's a GPG extension, which uses gpgme (which is compatible with both gpg 1 and 2)
[16:48] <juliank> bdmurray: I guess I should sponsor that 1.3
[16:49] <juliank> or rather, it might need to be updated with the actual upstream patch, rather than having the different downstream patch
[17:18] <ddstreet> nacc any plans to include ubuntu-cloud-archive versions in usd-imports (so git-ubuntu has their history as well)?  i assume no...
[17:24] <rbasak> ddstreet: currently not in our plans.
[17:24] <rbasak> We could do it in the end I suppose. There's nothing in our design that rules it out.
[17:25] <nacc> xevious: i agree
[17:25] <nacc> xevious: but i don't know how to do that on my own and it seems like an invasive change to switch its calling methods
[17:25] <xevious> Oh yeah, it's totally a "they should do that" situtation.
[17:25] <nacc> ddstreet: as rbasak said, not curently; but it's relatively easy for us to add a new source of information (curently the Launchpad Debian and Ubuntu publishing information is the only source)
[17:26] <nacc> ddstreet: it would need a feature request, and presumably would require some knowledge of what branches should exist there
[17:26] <ddstreet> nacc rbasak thnx, i was just wondering; the cloud guys have their own whole process so probably not really needed anytime soon
[17:27] <nacc> ddstreet: right
[17:27] <nacc> ddstreet: in theory, if they are basically doing stuff 'after' the existing publish pockets
[17:27] <nacc> we can import those publishes easily, if they have a definitive source publication recorde we can look at
[17:27] <nacc> ddstreet: we just wouldn't necessarily have branches for it
[18:04] <smoser> slangasek: could you tell me what i did wrong really quick ?
[18:04] <smoser> https://code.launchpad.net/~smoser/ubuntu/+source/walinuxagent/+git/walinuxagent/+merge/336244
[18:05] <smoser> installing my package doesnt delete the conf file.
[18:05] <slangasek> smoser: interesting, your diff looks correct to me
[18:06] <slangasek> smoser: can you point me at a binary package that I can poke into?
[18:07] <smoser> slangasek: https://smoser.brickies.net/ubuntu/misc/
[18:07] <slangasek> smoser: the added line in debian/maintscript should result in some really obvious code being output into preinst,postinst,postrm scripts
[18:08] <slangasek> smoser: and it does appear to be there
[18:08] <nacc> isn't the version incorrect?
[18:08] <slangasek> oh
[18:09] <nacc> i mean if there is a published version of walinuxagent in bionic with the config file
[18:09] <slangasek> right, what version are you upgrading *from*?
[18:09] <nacc> it won't remove it
[18:09] <nacc> since it's at 2.2.21+really2.2.20-0ubuntu1
[18:09] <nacc> (at least that's my recollection of the versioning)
[18:09] <slangasek> smoser: if the version number argument is too low, the migration doesn't trigger when upgrading from a version newer than this
[18:09] <nacc> i would think you'd want '2.2.21+really2.2.20-0ubuntu2', but i might be wrong
[18:10] <nacc> err, with a ~ on the end
[18:10] <slangasek> "prior-version> Defines the latest version of the package whose upgrade should trigger the operation" dpkg-maintscript-helper(1)
[18:10] <slangasek> yes, I think that's so
[18:10] <slangasek> or possibly even 2.2.21+really2.2.20-0ubuntu2
[18:10] <nacc> yeah and since this version was backported to all releases, you'd not see the conffile removal for sure without that change
[18:11] <nacc> 'this version' = 2.2.21+really2.2.20-0ubuntu1
[18:11] <slangasek> because it's safer to have it double-trigger when this exact package version is upgraded from, than to miss the removal because someone published a 2.2.21+really2.2.20-0ubuntu2~pre1 that didn't have this code
[18:11] <nacc> slangasek: yep, good call
[18:11] <slangasek> (otoh, people shouldn't do that, so YMMV)
[18:17] <smoser> slangasek, nacc . thank you. MP updated.
[18:18] <nacc> smoser: yw
[18:57] <mdeslaur> slangasek: are you working on a python-django merge?
[18:58] <acheronuk> tjaalton: building against the mesa and libglvnd in -proposed seems to have broken Kubuntu's desktop acceleration. On intel we now only get llvmpipe
[18:59] <acheronuk> if I purge libglvnd0 and libegl off the system (which are new on our iso we did not have before) we get full desktop hardware opengl back
[19:06] <nacc> xevious: lol https://github.com/horde/horde/pull/221
[19:06] <nacc> xevious: "Yes, key generation doesn't work with GnuPG 2 yet, and probably never will."
[19:07] <tjaalton> acheronuk: transition is in flux
[19:08] <tjaalton> but if you have issues with upstream mesa then file a bug there
[19:08] <tjaalton> it shouldn't matter if glvnd is used or not
[19:09] <tjaalton> debian has had it for six months
[19:11] <acheronuk> tjaalton: yeah. hopefully it will be ok when it all sits in the same pocket!
[19:12] <tjaalton> -proposed should work, as does ppa:canonical-x/testing
[19:12] <acheronuk> at the moment I may have to do a fudge to stop it being pulled in. just until it all sorts itself
[19:13] <acheronuk> tjaalton: yeah. I have one report from someone who madly uses -proposed, that they have no issue
[19:33] <nacc> xevious: fwiw, i'm skipping that test, it passes fine with that
[19:35] <nacc> slangasek: pacemaker ftbfs in artful due to binutils changes there (libqb?). Who from foundations might be able to help? It seems unresolved in Debian (the bugs slashd has found), but it obviously does build in bionic
[19:52] <acheronuk> tjaalton: probably matters little, but the offending lib is libeg1. the -release version of that being installed breaks it all
[19:54] <tjaalton> it's too old
[19:56] <slangasek> mdeslaur: I had not been working on a python-django merge, but it's a trivial delta so I'll knock it out now
[19:56] <acheronuk> tjaalton: for stuff which was compiled against -proposed then moved to release you mean?
[19:56] <slangasek> nacc: pacemaker> hmm maybe infinity has some cycles right now to look
[19:57] <tjaalton> acheronuk: maybe, dunno how you could get that otherwise
[19:57] <nacc> infinity: that would help me a ton, this is a rabbit hole i've never gone down before
[19:58] <slangasek> mdeslaur: done
[19:58] <nacc> infinity: it apparenlty has to do with orphan symbols on certain architectures
[19:59] <acheronuk> tjaalton: ok. just don't want to do a temp fix, only to have it bite us (kubuntu) harder later. sorry for all the queries
[20:00] <tjaalton> acheronuk: it should be sorted next week
[20:00] <acheronuk> cool. thanks
[20:07] <slangasek> nacc: is there a build log in lp for this pacemaker failure?
[20:07] <nacc> slangasek: i don't think so, because slashd and i only have it locally while trying to sru a fix back
[20:09] <slashd> nacc, slangasek, I *think* it was never trigger before because the package has been copied from zesty to artful (probably when artful has been first created) and package never been build again (no other upload nor SRU since then)
[20:10] <mdeslaur> slangasek: awesome, thanks!
[20:12] <slangasek> slashd, nacc: ah, which means it shows up on http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-gcc7-artful.html
[20:13] <nacc> slangasek: sort of
[20:13] <nacc> slangasek: yes, that's an error, but not hte one i need help with :)
[20:13] <slashd> nacc, right this one I have found the fix for ^, but once fix the libqb arise
[20:13] <slashd> slangasek, ^
[20:13] <nacc> slashd: https://github.com/ClusterLabs/pacemaker/commit/a7476dd96e79197f65acf0f049f75ce8e8f9e801.patch
[20:14] <nacc> fixes that upstream and is in debian
[20:14] <nacc> but then it fails due to a symbols change, which slashd narrowed down to libqb
[20:14] <slangasek> slashd, nacc: ok, so, not only is there not a build failure in lp for this, but the source code you want debugged is also not in lp... where's the pointer for that?
[20:14] <nacc> LP: #1740892
[20:14] <nacc> has some info, i believe
[20:15] <slangasek> surely the server team has a git branch for this WIP that we can pull ;)
[20:15] <nacc> slangasek: would you rather we did an upload we know would fail? just trying to understand
[20:15] <nacc> i can put one up for artful, i did for xenial
[20:17] <slangasek> nacc: I'm asking for enough concrete details for someone (e.g. infinity or myself) to be able to help you efficiently.  Even a pastebin of the toolchain error output?
[20:17] <slangasek> mdeslaur: ahhh you tricked me into merging a python-django that ftbfs
[20:20] <slangasek> mdeslaur: the test failure seems unrelated to any debian-ubuntu differences in core packages; I'm stabbing the retry button to see what happens, but if it still ftbfs I'm not following up on it today fwiw
[20:21] <nacc> slangasek: fair, above patch results in https://paste.ubuntu.com/p/hb68G8rpMw/
[20:22] <slangasek> oh is that all
[20:22] <slashd> slangasek, if that can help -> https://launchpadlibrarian.net/357655127/buildlog_ubuntu-artful-amd64.pacemaker_1.1.16-1ubuntu1.2_BUILDING.txt.gz
[20:22] <slangasek> nacc: those are pretty clearly internal symbols which are not part of the ABI and you should just mark them (optional) instead of doing an architecture-based exclusion list
[20:23] <slangasek> nacc: there's a new pacemaker version in bionic vs. artful, isn't this what was done there?
[20:23] <slangasek> and when I say mark them (optional), I mean mark them '(optional)'
[20:25] <nacc> slangasek: i believe debian just dropped the symbols
[20:25] <nacc> because the debian bugs are not yet fixed :)
[20:26] <nacc> but i don't know
[20:26] <nacc> slangasek: we can do tht in the sru too
[20:26] <slangasek> nacc: dropping the symbols, or marking them optional, both valid.  (optional) would make the same source package more cleanly backportable to older toolchains
[20:26] <nacc> slashd: --^
[20:26] <nacc> slangasek: ok
[20:27] <slangasek> but a symbol that starts with a __ and isn't listed in the public headers for the library, and especially that doesn't originate in the source of this library, can be assumed safe to drop from .symbols
[20:27] <nacc> slangasek: thanks that makes sense
[23:42] <sarnold> flexiondotorg: it's hard to figure out what's going on here, but it vaguely feels like do-release-upgrade isn't happy with something in mate: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1751386
[23:46] <Unit193> ("The cache has no package named 'ubuntu-mate-core'")  that's odd, but the version numbers for other things are a bit off, ~xenial stuff.
[23:48] <sarnold> and all those [origin: unknown] messages usually means apt is pretty unhappy
[23:49] <Unit193> apt-forktracer is an amazing too, fyi.
[23:49] <sarnold> it feels like the sort of thing where nothing on this computer is going to work quite right, and I don't know what to suggest, but ten minutes with it would probably be enough to sort it out.
[23:50]  * tsimonq2 takes a wild guess at it being the software boutique and something not being right irt PPAs
[23:51] <Unit193> I read that email.  Also laughed since it came from the same person that seeded the calc as a snap. :P
[23:52] <tsimonq2> Unit193: Huh?
[23:52] <tsimonq2> Martin's the one who seeded the calculator as a snap...
[23:52] <tsimonq2> :P
[23:52] <sarnold> Unit193: apt-forktracer is neat. thanks.
[23:54] <Unit193> tsimonq2: Only half accurate: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.bionic/revision/2632
[23:55] <Unit193> sarnold: Bases them off 'origin', so Canonical's repo also gets picked up.  But, finds ppas.  apt list | grep ed,loc is interesting too.
[23:55] <tsimonq2> Unit193: But for 17.10 it was indeed a hack in the cdimage tooling
[23:55] <sarnold> Unit193: wow, I haven't seen apt list either. handy :D
[23:57] <Unit193> sarnold: I'm going to presume you know about debsums and deborphan?
[23:58] <Unit193> ...As well as dpkg -l | awk '/^rc/{print $2}'  and  dpkg-query -W -f='${Conffiles}\n' | grep obso  ?
[23:59] <sarnold> Unit193: aha! those two I know well :)
[23:59] <sarnold> Unit193: (debsums, deborphan.. and of course dpkg -l | awk .. I'm sure I've got the dpkg-query thing written down somewhere, but no used often enough to remember :)
[23:59] <jbicha> sarnold: uh, maybe reassign that bug to LibreOffice, could be a bug in their ppa