User1: is there a reason why we don't have a default IRC client?
User2: Probably because it's fairly niche? We also don't have a default IDE :)
User3: User1 ^ that, and also because what would you say should be the default?
User3: xchat?  HexChat?  irssi?  KVirc?  Quassel?  There's too many to choose from, and individual users will have their own preferences of what they want to install.
User4: irssi of course
User3: User4 lol
User3: User4 that works for server.  Answer for Ubuntu Desktop.
User1: but we want people to contribute but no way to talk over IRC
User5: I remember people were upset when empathy replaced pidgin by default
User6: User3 Irssi.
User4: User3 well you're right, i've been meaning to try out weechat for a few years now
User1: HexChat is what I'm using now
User6: User1 Hexchat generally for GTK, Konvi or Quassel for Qt.
User1: I use Konvi with Kubuntu
User1: but I have Ubuntu on this laptop
User1: broke when moving to yakkety
User2: I think we primarily want people to find Ubuntu *useful*.
User2: Contributions are nice, but realistically our contributor base *should* be a tiny tiny fraction of our user-base.
User1: us over at Kubuntu just put Kiwi IRC into our website
User5: most of the Ubuntu flavors still ship IRC clients but their target audience is a bit different
User1: on the support page
User2: Yeah, there's no reason Kubuntu can't select and ship a default IRC client.
User5: and Ubuntu included empathy until 16.04 so maybe the flavors will follow
User6: User2 Well, IRC isn't just for Ubuntu, there's a lot more channels on Freenode alone, not to mention other networks.  Though yes, it's still a decently small userbase.
User1: we do
User1: Konvi is the default since 15.10 I believe
User6: Xubuntu pretends Pidgin is an IRC client, stopped shipping Xchat a couple releases back.
User2: User6 Absolutely; but I'd hope that the userbase of Ubuntu is at least a couple of orders of magnitude larger than the freenode userbase.
User4: you can use a computer -without- irc? what would you do with it? :)
User6: Hah, I'm sure it is, though I believe Freenode is one of, if not the biggest network.
User2: That's rather my point âº
User6: User4 Hmm.  Youtube and reddit I suppose?
User4: User6 oh yes I see links to those all the time ;)
 * mwhudson rages at quilt
 * sarnold quilts at rage
 * RAOF is not disappointed to not have to deal with quilt very much anymore :)
User3: User4 to answer your question: panic.
User7: also dos line endings
User4: User3 hehe
User6: User4 Also, I thought I might have killed you with my wall-o-text! :3
User4: User6 it came close, I spent way too much time reading the specs and assorted docs and then fell asleep. (not kidding, it was warm, I was full..)
User6: Haha, niiice!  Whoops.
User7: oh, and, apparently the x11 clipboard and/or vim
User4: User7 dos lineendings may be worth a "starter" patch in the series to remove all those terrible things in the whole project first, so all the other patches can then be normal
User7: User4 i seem to have prevailed but yeah
User7: well i don't know, i'm entirely making the patches by backporting commits from upstream master so i'm not sure if that would actually be less pain overall
User8: Good morning
User6: User8 Howdy.
User8: User4 they work in general, there is just an exception for this particular one; I added an apport task and the traceback to that bug
User8: hey Unit193
User9: o/ pitti, how are you? :)
User8: User9 I'm good, thanks! how about yourself?
User9: great pitti :)
User6: User8 Were you testing all the user sessions?  And I presume now  sctl restart user@1000  is a seriously bad idea now? :P
User8: User6 not all of them yet; I tested ubuntu, lubuntu, xubuntu, and kubuntu
User8: unity8 does not run on my system, and mythbuntu and studios are derivatives of xubuntu
User8: I still need to test them and provide .targets for those, but that should be easy
User8: s/derivatives of xubuntu/use an XFCE based session/ I mean
User6: I poked studio and myth, seems Myth may stop doing an ISO.  And fwiw 'Xfce'. :P
User8: User6 but before that makes sense I'd first like to land the xubuntu conversion; I pushed it into xubuntu-default-settings, but didn't upload yet
User8: not sure, does xubuntu participate in alpha-2?
User6: I don't think so.
User5: Ubuntu GNOME won't be doing Alpha2 this time either
User8: I'm currently working on some upstart fixes, once they are in I can land the xubuntu conversion
User6: Good to know, pushed the change I wanted first.
User8: User6 which change do you mean?
User8: User20 the apparmor merge looks very simple (just adding handle_system_policy_package_updates in the init script and dropping notify-group.patch), I'll do that now
User8: intrigeri did a fine job of merging on the Debian side
User8: User20 actually, notify-group.patch is correct -- /var/log/kern.log *is* owned by group "adm"; "admin" has been obsolete for may years; so even less delta :)
User8: and vcs-bzr: is very outdated, so I'll just drop that
User8: User11 xserver-xorg-input-vmmouse was removed in Debian bug 831420; but xserver-xorg-input-all still Depends: on this; do we want to follow suit and drop it from -all?
User10: Debian bug 831420 in ftp.debian.org "RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel" [Normal,Open] http://bugs.debian.org/831420
User8: User20 FTR, apparmor merge uploaded now
User11: User8 once our kernel supports it
User11: not sure it does yet
User8: User11 oh, so that was done in 4.5 or 4.6 in Debian?
User8: right, thanks
User11: guess so
User11: we're still on 4.4
User12: Laney, mate-hud arrived in the 16.10 archive yesterday.
User12: I've just uploaded an updated ubuntu-mate-meta that seeds mate-hud
User12: Is anything else required to recognise mate-hud as part of the Ubuntu MATE package set so I can upload updates in the future?
User13: User12 You get someone on the DMB to re-run their script
User12: ty
User8: User19 hey Serge, how are you?
User8: User19 as I just orphaned systemd-shim in Debian, do you intend to orphan cgmanager in Debian? (https://s3hh.wordpress.com/2016/06/18/whither-cgmanager/)
User14: infinity: Ah, yes, that should have been backported, yes.
User14: infinity: And I'm multi-talented, I can work and frolic.
User15: User16 around?
User16: yes
User15: User16 hey, so i was taking a look at LP: #1597414
User10: Launchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/1597414
User15: User16 isc-dhcp's publication history in debian is terrible :/
User15: User16 specifically, version going backwards repeatedly, the same version being published multiple times in the same series/pocket
User16: User15 if there are only a few packages that do this, then would a complicated override file be OK?
User15: User16 right, i think it's fine, but the issue is how do i tell the override file *which* 4.2.2.dfsg.1-5 has as publish parent 4.2.2.dfsg.1-4 and which has 4.2.4-4?
User15: that is, given a version and a package name, for isc-dhcp, i no longer have a unique entry in the publishing history
User15: (and a series)
User16: OK, but the trees should still be identical I think, right?
User15: they should be yes
User16: What would happen if we ignored the subsequent publishing history entries of the same version in the same pocket?
User15: i think that could work, but then `git log debian/sid` wouldn't match +publishinghistory
User16: I can't think of anything we can do about that. My gut feel is that working around it would corrupt the data structure too much.
User15: agreed
User16: Hopefully it's rare/historical.
User15: the tricky part is, though, i now would need to see if a version has already been imported -- in distro/series/pocket. But I don't do that check now, so it will need some new code (not a big deal, but not as trivial as I had hoped)
User16: If you wanted to be really tidy you could add a git note to the commit to note that the version reappeared in the pocket and wasn't re-imported.
User15: yeah
User16: Yeah I see the coding difficulty.
User15: but that's ok, i will see if i can sketch someting out
User17: warp10: thanks! happy to be part of we-love-pitti.
User18: @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur 
 * mdeslaur hugs dholbach
User19: User8 yeah, that's probably good.  what is the process?
User8: User19 https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning
User8: User19 it's filing an "orphaned" (or "rfa") bug and uploading the package to change the maintainer (or not if you just set it as RFA)
User8: User19 or, if that makes more sense, perhaps file a request to remove the package and RC bugs against the reverse deps
User8: depends on what the future should be -- is it "I don't want to maintain this any more", or "it does not make sense to keep this"
User19: User8 ok thx, i'll think about it.
User8: rdepends> systemd-shim only; libpam-cgm is from cgmanager, lxc is only a recommends (and probably wrong these days)
User19: i still may change my mind and decide to rewrite it and change the scope a bit :)
User8: User19 no hurry or urgency of course, it just caught my eye and I was wondering what the future plan is
User19: yeah
User19: the plan is *probably* to either orphan it, or expand its scope to be a more complete complement to upstart (i.e. offer a bit more management)
User19: although if i do the latter it may not be appropriate for debian since it appears to have actively turned against anything alternative to systemd
User8: there's still sysvinit
User19: yeah i'm going to let this thought sit in the back of my head and leave a note to do it in two weeks
User8: but nobody really maintains it; but it's the reason why systemd-shim is still a thing in Debian
User8: User19 sounds good, thanks!
User19: User8 sorry, pls remind me,
User19: why do sysvinit ppl want systemd-shim?  which pice of userspace requires that?
User8: User19 pretty well every desktop these days talks to logind for session tracking, suspend, reboot, screensaver management etc.
User19: all right, made a note, i plan to act on aug 9 :)
User8: User19 with systemd-shim you can use logind (and also timedatectl/hostnamectl, for settings) under sysv
User19: i'm wondering how deep that goes,
User8: that was the main driver for it as CK got abandoned long ago
User19: i.e. if it's just "kde and gnome", or if it's library pices that even i3 users etc would need
User8: my suspicion is that shim could probably work without cgmanager or cgroups at all
User19: but you're abandoning shim anyway
User8: and just provide stubs for the calls
User8: yes, me personally, but this is a case where "orphan" is right, not removal
User8: as it's clearly useful still
User19: ok
User8: I just don't have time/motivation to work on it myself
User19: \o
User8: User19 does lxc need it on sysvinit? (I thought not, it does all the cgroup handling by itself)
User19: User8 not if there is cgroup namespaces or lxcfs
User20: User8 ah, thanks
User20: User8 I had done the merge, incorporated it with my other pending changes, and was going to test today
User20: User8 it should be easy to rebase them onto your upload though
User20: (I'll also make sure that we came to the same conclusions on the merge)
User8: User20 urgh, sorry; feel free to upload over mine, it is (and will still be for a while) stuck in -proposed anyway
User8: User20 most of the work really was about reviewing the delta, and it's just that one which was left
User8: User21 any chance I can bribe you to source-NEW review nplan?
User8: (not sure if you are still doing archive admin)
User21: pitti, I sortof do, no official shifts but every now I pick some reviews and I'm happy to help/reply to ping ... looking!
User8: User21 thanks; it's small
User21: pitti, looks fine, no COPYING but I guess debian/copyright cover it ... but don't we usually use license 3 rather than 3+ for Canonical projects? (also why LGPL and not GPL if it's a standalone generator)
User8: User21 ah, I'll add COPYING; LGPL? I intended GPL
User21: pitti, License: LGPL-3.0+
User8: User21 please reject, I'll reupload
User21: k
User21: pitti, looks good otherwise
User21: pitti, just give me a nudge once reuploaded
User18: @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
User8: User21 back in the queue
User21: pitti, no it's not...
 * pitti hugs seb128
User21: ;-)
 * seb128 hugs pitti back
User22: cjwatson, so...  I have this testing silo PPA (landing-030).  It has only a few unity8 packages in it, and LP agrees.  But apt sees (abandoned?) click packages and LP built the u8 in the PPA against some beta version of Qt that isn't in the PPA.  I was clearing some of the click binaries out of it before I realized I should probably ask what is happening in there
User22: I'm looking at yakkety specifically, but it may affect other series
User23: good question
User23: can't just be a deathrow failure since the packages are still referenced from dists
User23: source is deleted, binary not
User22: yeah I thought that was odd
User8: User21 just saw that I forgot to add copyright/license headers to the source files; done in git now
User8: User21 and there was an unstable test which caused ftbfs on ppc64el, also fixed
User23: grepping logs
User23: User22 ah, I see.  nothing sinister; the problem is that the landing was abandoned while stuff was still in the process of publishing, so the binaries weren't quite there for LP to delete
User23: User22 I'll delete them manually
User22: cjwatson, oh cool thanks
 * mterry is glad LP isn't busted  :)
User23: User22 I don't see the Qt packages you mention though
User23: maybe you removed those already?
User22: cjwatson, I didn't...  I also don't see them via apt.  But u8 is built against them.
User23: User22 link to the build?
User22: cjwatson, ah.  qt is in proposed, that's what happened
User23: yep
User23: User22 done all the remaining click removals now (pending publisher)
User22: cjwatson, thanks!
User21: pitti, ok, I noticed the lack of header in the sources but didn't want to nitpick on it since they are all under the same author/license/copyright
User8: User21 the queue has some binaries now
User21: hum
User21: pitti, I don't understand https://launchpad.net/ubuntu/+source/nplan/0.1
User8: still waiting on arm, though; powerpc failed, need a porter box for that (but also, not urgent at all)
User21: oh, you uploaded 0.2
User8: User21 I rejected the two binaries; yes
User21: k, sorry I was looking at the wrong page
User21: pitti, I usually wait for all the archs to be done, queue estimate is ~10minutes for the armhf/64, ok to wait for those?
User8: User21 absolutely
User24: User15 Could you have another look at lp:1581200 please. I'm in need of an upload for cloud-init on trusty.
User21: pitti, great, going to look again in half an hour or so then
User25: hi pitti , thanks for the apparmor merge
User25: for next time, can you please think about dropping all the breaks+replaces against apparmor?
User25: Breaks: apparmor-easyprof ( << 2.8.95~2385-0ubuntu1 ), apparmor-utils ( << 2.8.95~2385-0ubuntu1 )
User25: I think they can be dropped together with the one against debhelper
User8: User25 this should be done in Debian; I don't want to introduce extra ubuntu delta for such cleanup, as it has no runtime effect
User8: User21 ok, I now have a nice segfault to debug on arm64 and powerpc :)
User25: I tried to explain that here https://lists.debian.org/debian-backports/2016/07/msg00085.html
User25: but the Debian maintainer didn't understand that
User25: so maybe if you can explain or add your opinion he will drop it :)
User25: I agree about keeping delta minimal
User25: I'll open a bug
User21: pitti, it failed on arm* so builds done, binNEWed it
User8: User21 thanks; I'll debug this tonight or tmw on a porter box
User21: yw!
User25: cheers
 * LocutusOfBorg leaves
User15: User24 ah I see, sorry about that!
User24: User15 No problem
User4: User8 thanks for investigating the unhappy retracer :)
User8: rharper, lool, User26 FYI: nplan | 0.2 | yakkety/universe | source, amd64, i386, ppc64el, s390x
User8: this should unblock some cloud-init/maas development hopefully?
User26: pitti, well, sure :)
User26: thanks.
User8: User26 this doesn't have an "apply changes now" button yet, that should follow soon
User26: pitti, ok. i will try to take a look sometime soon
User26: hey... anyone know how i would switch from bzr to git and squash the "merged" commits that would be hidden ?
User26: ie, bzr --include-merged shows a ton of things that i dont want on primary 'git log'
User26: and 'bzr log' would have hidden
User27: User26 you'd have to manually go through and squash them i guess. not sure if bzr-git or git-bzr would have something for it
User26: how woudl i even do that ?
User26: https://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ solves my other desire
User27: git rebase -i with appropriate revision specification arguments i guess?
User26: which is to not lose --fixes
User27: hmm
User27: preserving metadata would indeed be nice when migrating
User27: of course, git commit doesn't have a --fixes :-/
User26: 3597 commits in total 1258 that are bzr "top level" commits
User26: not something i can do by hand
User26: that link basically just converts the fixes metadata into some string
User26: which is not as nice as specific metadata, but acceptable
User27: right
User27: real metadata would be much nicer
User16: User26 squashing them doesn't really seem right. bzr doesn't show them by default but has the info. git also has the info but does show them by default. So it's just the default view mode, and to me that doesn't justify changing the commit graph itself.
User27: also that, yeah
User26: rbasak, you'd rather see 'fix spelling' , 'whoops'
User26: interwieved with actually useful information
User26: i'd rather not see it. i dont like losing the data either.
User26: but every day usage includes 'git log' and i'd rather not have garbage there.
User16: User26 so use git log --first-parent.
User16: User26 and ask submitters to squash out mistakes before merging, like the Linux project requires.
User16: As for bug number metadata, in the git world we create a pseudo-header in the commit message for this kind of thing. Ideally Launchpad would define the header name, and then all tooling could use that.
User16: Perhaps it should be "Launchpad-Bugs-Fixed" after what we already do in changes files. As a bonus the syntax would be identical.
User26: rbasak, sure. thats fine... and that is waht that fusonic.net url does
User16: It might be worth filing a bug against Launchpad asking for a commitment to a particular syntax, so that we can start using it now, eg. for your import.
User16: User26 yes, but looks to me that it sticks it into the subject line.
User16: I wouldn't do that.
User26: well, it has to convert actual metadata into some string
User26: and just put that string in the commit message
User28: User8 \o/
User26: so it doesnt really matter what it does
User28: User8 well done on landing nplan
User26: i dont care about the specifics.
User16: It should be in the commit body under some common syntax, since we want tooling to pick it up.
User8: User28 merci
User16: Otherwise bugs won't auto-close when Launchpad learns how to do that.
User26: rbasak, sure. but i dont really care what that syntax is now. i just care that it isnt lost.
User16: You don't care about losing consistency when you have to change to a different syntax in the future? That surprises me, but OK :)
User26: rbasak, well, my option is to wait until some standard is created ?
User26: given "wait a few weeks" compared to "have something acceptable now" i'll take the later
User16: It looks like it's already defined as it happens. One moment.
User16: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/enums.py#L40 I think
User16: From https://code.launchpad.net/~cjwatson/launchpad/git-update-related-bugs/+merge/298369
User16: "I've intentionally used the same regexes that Soyuz uses to parse changelogs, for compatibility with package branches and because it's reasonably compact in commit messages."
User16: So: "LP: #123" or "LP: #123, #456" I think?
User16: User23 ^ is that right, please?
User10: Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
User10: Launchpad bug 456 in libgtk-java (Ubuntu) "Unable to upgrade #2" [Medium,Fix released] https://launchpad.net/bugs/456
User16: (technically it looks like it's under review, rather than defined)
User26: well, LP: # is what i probably woudl have picked anyway :)
User26: rbasak, first-parent is nice. thank you.
User23: User16 That's correct.
User23: (Under review, as you say.)
User29: Hi, I have found a big bug in pulseaudio, and I have found out the ubuntu-touch patches are the reason for the break. How can I get some focus on it? Here is bug report with fix: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1589401
User10: Launchpad bug 1589401 in network-manager (Ubuntu) "cannot view wifi networks after re-enabling wifi" [High,Confirmed]
User29: oh shit, wrong bug report.
User29: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324 here you go :D sorry
User10: Launchpad bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones" [Medium,Confirmed]
User16: User23 thanks
User16: User29 it would probably help if you can identify which of those patches causes the regression. It's difficult for developers to do if they don't have your exact hardware.
User16: User29 once identified, we can ask the person who introduced the regressing patch to look into it.
User23: User16 The other thing to note is that in general, or at least to start with, LP will only bother scanning for bug links in commit messages when you make a merge proposal, unlike the bzr behaviour where we (very expensively) scan and link every commit in every branch.
User23: I think this is defensible but it's still a behaviour change.
User16: User23 OK. I appreciate the work you're doing on this. It would be nice if the bzr behaviour arrived for git repos in the end though.
User23: User16 Since that's very expensive, I'd like to have a compelling reason.
User16: Why is it expensive?
User16: Could it be made cheaper if it were only done on pushes that were fast forwards of relatively few commits? Even then it'd be very useful.
User23: There are a lot of very deep histories out there, and it would involve a lot of database rows.
User16: Or would that be too confusing?
User23: The bzr implementation is essentially disastrous.
User23: It could be done less badly, but still ...
User29: User16 I see.. That's gonna take a long time. But I guess I will do it if i'm bored tomorrow. That was the answer I was afraid of :D
User23: The other complexity is that git branches may pretty much go away at any time, from Launchpad's point of view, so we don't link objects to them in persistent ways.
User16: Oh, I may be talking about something else.
User23: The bit that would be difficult is working out what branch a commit is most relevantly in.
User16: I'd like auto-close really. I'm not sure linking a branch automatically makes sense in git land unless submitting an MP.
User16: But if I push a branch to a repo that closes a bug, I'd like the bug to autoclose. Without an MP, I'd be happy to not also have a linked branch.
User23: Ah.  We've never done that in bzr because the policy is complicated.
User23: Some projects want that kind of thing and some don't.
User29: User16 And thanks for the answer. What should I do when I find the patch that's causing it?
User23: Launchpad itself probably wouldn't, for instance; we only want to close bugs when we actually deploy the fixes, not just when they land on master.
User16: So, a naive implementation that would make me happy is just effectively a post-receive hook that scans new commits for bug references and autocloses those bugs. No need for branch links there, so I imagine that would be fairly independent of your branch linking work.
User23: But presumably only new commits on some nominated branch.
User16: I see. The policy difficulties you mention do make sense. So I guess it's non-trivial to work out a scheme that allows per-branch configuration of this.
User23: I'm not ruling it out or anything, just saying that it isn't actually the bzr behaviour and it is indeed somewhat complex to work out.
User23: I know GitHub does this, so I'm sure some projects are used to it.
User23: I wonder what they do in terms of policy.  Surely can't just be that pushing a commit to any branch with the right kind of commit message does it.
User16: It wouldn't surprise me if that's what they do.
User16: But I appreciate your point about doing it right.
User16: How about: it is configured per-branch, and you explicitly enable it for a project, and specify for that enablement whether it should auto "Fix Committed" or "Fix Released".
User23: https://help.github.com/articles/closing-issues-via-commit-messages/ says it has to be in the default branch.
User23: We do have a similar notion of the default branch for a repository.
User23: There are somewhat different scoping issues for Launchpad, though.
User16: By "enable it for a project", I mean that you specify the project.
User23: GitHub tracks issues per-repository; Launchpad tracks them per-project (etc.), and a project may have many repositories.
User16: Right, so user/group->repository->branch could have a "close *this* project's bugs" option.
User16: User29 ping whoever introduced the patch on IRC maybe? Feel free to ping me if you need help with that.
User23: My inclination would be to make it be a thing that only works for the default branch in the default repository for the target (both concepts we already have), and to be a checkbox.
User23: Or a similarly small piece of config.
User16: User29 see "bisection", eg. with ~28 commits, it should only take about six builds, I think.
User16: User23 I'd be fine with that too for all my use cases, I think.
 * rbasak goes to bed
User16: Thank you for the discussion. I appreciate it.
User29: User16 Awesome. Just to be sure, you mean Like, first patch all with 02XX and then 03xx ?
User23: User16 I won't get to this very immediately since it's not on the critical path for converting Launchpad itself to git (which was my motivation for the work so far), so I'd appreciate a reminder bug with a summary of this, when you get a chance
User23: User16 (I mentioned that the bzr implementation is expensive - we estimate that the cost of the infrastructure for all this for Launchpad itself's branches is something on the order of a couple of hundred GB of database space, so we very much want to get ourselves off it!)
User16: User29 the patches stack on top of each other and may not be independent. So I'd patch the first half but not the second half. If that succeeds, patch the first three quarters and not the last quarter, or if it failed, patch the first quarter and not the the last three quarters. And then go to eighths, and so forth. See http://manpages.ubuntu.com/manpages/xenial/en/man1/git-bisect.1.html. You'd do
User16: the same thing, except that it's probably easier to do by hand then try and crowbar git into doing it for you in this case.
User16: User29 this way, eventually you should pin it down to the addition of a single patch, I think within about six iterations.
User16: User23 I'll file a bug, thanks.
 * rbasak leaves himself a reminder for tomorrow
User29: User16 ah, I see :) that's pretty smart. I will for sure do that :)
User23: cheers
User29: I was afraid, I had to do like 30 builds ;)
User23: Bisection is great.  When it works, anyway.
User29: Can I easily reload pulseaudio after installing new build, so I don't have to reboot?
User29: nvm, figured it out.. Anyway, I will do some builds tomorrow. It's late in Denmark, I'm too tired for it now.
User29: Thanks for all your  help!
User7: oh man BranchRevision
User30: User7 It has several rows now.
User30: Several billion.
User7: User30 somewhere on the impressive/depressing continuum
User30: User7 Postgres handles our 1TB DB admirably...
User30: And more than half of that is BR.
ubuntu-devel
Ubuntu IRC