ahoneybunis there a reason why we don't have a default IRC client?00:54
RAOFProbably because it's fairly niche? We also don't have a default IDE :)00:55
tewardahoneybun: ^ that, and also because what would you say should be the default?00:55
tewardxchat?  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.00:55
sarnoldirssi of course00:55
tewardsarnold: lol00:56
tewardsarnold: that works for server.  Answer for Ubuntu Desktop.00:56
ahoneybunbut we want people to contribute but no way to talk over IRC00:56
jbichaI remember people were upset when empathy replaced pidgin by default00:56
Unit193teward: Irssi.00:56
sarnoldteward: well you're right, i've been meaning to try out weechat for a few years now00:56
ahoneybunHexChat is what I'm using now00:56
Unit193ahoneybun: Hexchat generally for GTK, Konvi or Quassel for Qt.00:57
ahoneybunI use Konvi with Kubuntu00:58
ahoneybunbut I have Ubuntu on this laptop00:58
ahoneybunbroke when moving to yakkety00:58
RAOFI think we primarily want people to find Ubuntu *useful*.00:58
RAOFContributions are nice, but realistically our contributor base *should* be a tiny tiny fraction of our user-base.00:58
ahoneybunus over at Kubuntu just put Kiwi IRC into our website00:59
jbichamost of the Ubuntu flavors still ship IRC clients but their target audience is a bit different00:59
ahoneybunon the support page00:59
RAOFYeah, there's no reason Kubuntu can't select and ship a default IRC client.00:59
jbichaand Ubuntu included empathy until 16.04 so maybe the flavors will follow00:59
Unit193RAOF: 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.01:00
ahoneybunwe do01:00
ahoneybunKonvi is the default since 15.10 I believe01:00
Unit193Xubuntu pretends Pidgin is an IRC client, stopped shipping Xchat a couple releases back.01:01
RAOFUnit193: Absolutely; but I'd hope that the userbase of Ubuntu is at least a couple of orders of magnitude larger than the freenode userbase.01:01
sarnoldyou can use a computer -without- irc? what would you do with it? :)01:01
Unit193Hah, I'm sure it is, though I believe Freenode is one of, if not the biggest network.01:01
RAOFThat's rather my point ☺01:01
Unit193sarnold: Hmm.  Youtube and reddit I suppose?01:02
sarnoldUnit193: oh yes I see links to those all the time ;)01:03
* mwhudson rages at quilt01:05
* sarnold quilts at rage01:05
* RAOF is not disappointed to not have to deal with quilt very much anymore :)01:06
tewardsarnold: to answer your question: panic.01:07
mwhudsonalso dos line endings01:07
sarnoldteward: hehe01:07
Unit193sarnold: Also, I thought I might have killed you with my wall-o-text! :301:08
sarnoldUnit193: 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..)01:08
Unit193Haha, niiice!  Whoops.01:09
mwhudsonoh, and, apparently the x11 clipboard and/or vim01:10
sarnoldmwhudson: 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 normal01:11
mwhudsonsarnold: i seem to have prevailed but yeah01:13
mwhudsonwell 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 overall01:13
=== JanC_ is now known as JanC
=== saurik_ is now known as saurik
pittiGood morning05:42
Unit193pitti: Howdy.05:42
pittisarnold: they work in general, there is just an exception for this particular one; I added an apport task and the traceback to that bug05:46
pittihey Unit19305:46
tsimonq2o/ pitti, how are you? :)05:47
pittitsimonq2: I'm good, thanks! how about yourself?05:48
tsimonq2great pitti :)05:48
Unit193pitti: Were you testing all the user sessions?  And I presume now  sctl restart user@1000  is a seriously bad idea now? :P06:01
pittiUnit193: not all of them yet; I tested ubuntu, lubuntu, xubuntu, and kubuntu06:01
pittiunity8 does not run on my system, and mythbuntu and studios are derivatives of xubuntu06:01
pittiI still need to test them and provide .targets for those, but that should be easy06:02
pittis/derivatives of xubuntu/use an XFCE based session/ I mean06:02
Unit193I poked studio and myth, seems Myth may stop doing an ISO.  And fwiw 'Xfce'. :P06:03
pittiUnit193: 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 yet06:04
pittinot sure, does xubuntu participate in alpha-2?06:04
Unit193I don't think so.06:04
jbichaUbuntu GNOME won't be doing Alpha2 this time either06:08
pittiI'm currently working on some upstart fixes, once they are in I can land the xubuntu conversion06:09
Unit193Good to know, pushed the change I wanted first.06:11
pittiUnit193: which change do you mean?06:11
pittityhicks: 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 now07:18
pittiintrigeri did a fine job of merging on the Debian side07:18
pittityhicks: 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 :)07:21
pittiand vcs-bzr: is very outdated, so I'll just drop that07:25
=== davidcalle|afk is now known as davidcalle
pittitjaalton: 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?07:58
ubottuDebian bug 831420 in ftp.debian.org "RM: xserver-xorg-input-vmmouse -- RoQA; obsolete and conflicts with kernel" [Normal,Open] http://bugs.debian.org/83142007:58
pittityhicks: FTR, apparmor merge uploaded now07:59
tjaaltonpitti: once our kernel supports it08:28
tjaaltonnot sure it does yet08:29
pittitjaalton: oh, so that was done in 4.5 or 4.6 in Debian?08:29
pittiright, thanks08:29
tjaaltonguess so08:29
tjaaltonwe're still on 4.408:29
flexiondotorgLaney, mate-hud arrived in the 16.10 archive yesterday.08:50
flexiondotorgI've just uploaded an updated ubuntu-mate-meta that seeds mate-hud08:50
=== marcusto_ is now known as marcustomlinson
flexiondotorgIs anything else required to recognise mate-hud as part of the Ubuntu MATE package set so I can upload updates in the future?08:51
Laneyflexiondotorg: You get someone on the DMB to re-run their script08:51
pittihallyn: hey Serge, how are you?09:29
pittihallyn: 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/)09:30
Odd_Blokeinfinity: Ah, yes, that should have been backported, yes.10:29
Odd_Blokeinfinity: And I'm multi-talented, I can work and frolic.10:29
naccrbasak: around?10:29
naccrbasak: hey, so i was taking a look at LP: #159741410:32
ubottuLaunchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/159741410:32
naccrbasak: isc-dhcp's publication history in debian is terrible :/10:32
naccrbasak: specifically, version going backwards repeatedly, the same version being published multiple times in the same series/pocket10:33
rbasaknacc: if there are only a few packages that do this, then would a complicated override file be OK?10:33
naccrbasak: 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?10:34
naccthat is, given a version and a package name, for isc-dhcp, i no longer have a unique entry in the publishing history10:35
nacc(and a series)10:35
rbasakOK, but the trees should still be identical I think, right?10:35
naccthey should be yes10:35
rbasakWhat would happen if we ignored the subsequent publishing history entries of the same version in the same pocket?10:36
nacci think that could work, but then `git log debian/sid` wouldn't match +publishinghistory10:37
rbasakI 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.10:38
rbasakHopefully it's rare/historical.10:39
naccthe 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)10:39
rbasakIf 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.10:39
rbasakYeah I see the coding difficulty.10:40
naccbut that's ok, i will see if i can sketch someting out10:40
Mirvwarp10: thanks! happy to be part of we-love-pitti.11:36
mdeslaur@pilot in11:39
=== 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 12:00
* mdeslaur hugs dholbach12:02
=== utlmming is now known as utlemming
hallynpitti: yeah, that's probably good.  what is the process?12:24
pittihallyn: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning12:27
pittihallyn: 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)12:27
pittihallyn: or, if that makes more sense, perhaps file a request to remove the package and RC bugs against the reverse deps12:28
pittidepends 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"12:28
hallynpitti: ok thx, i'll think about it.12:29
pittirdepends> systemd-shim only; libpam-cgm is from cgmanager, lxc is only a recommends (and probably wrong these days)12:29
hallyni still may change my mind and decide to rewrite it and change the scope a bit :)12:29
pittihallyn: no hurry or urgency of course, it just caught my eye and I was wondering what the future plan is12:30
hallynthe 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)12:30
hallynalthough if i do the latter it may not be appropriate for debian since it appears to have actively turned against anything alternative to systemd12:32
pittithere's still sysvinit12:33
hallynyeah i'm going to let this thought sit in the back of my head and leave a note to do it in two weeks12:33
pittibut nobody really maintains it; but it's the reason why systemd-shim is still a thing in Debian12:33
pittihallyn: sounds good, thanks!12:33
hallynpitti: sorry, pls remind me,12:34
hallynwhy do sysvinit ppl want systemd-shim?  which pice of userspace requires that?12:34
pittihallyn: pretty well every desktop these days talks to logind for session tracking, suspend, reboot, screensaver management etc.12:34
hallynall right, made a note, i plan to act on aug 9 :)12:34
pittihallyn: with systemd-shim you can use logind (and also timedatectl/hostnamectl, for settings) under sysv12:35
hallyni'm wondering how deep that goes,12:35
pittithat was the main driver for it as CK got abandoned long ago12:35
hallyni.e. if it's just "kde and gnome", or if it's library pices that even i3 users etc would need12:35
pittimy suspicion is that shim could probably work without cgmanager or cgroups at all12:35
hallynbut you're abandoning shim anyway12:36
pittiand just provide stubs for the calls12:36
pittiyes, me personally, but this is a case where "orphan" is right, not removal12:36
pittias it's clearly useful still12:36
pittiI just don't have time/motivation to work on it myself12:36
pittihallyn: does lxc need it on sysvinit? (I thought not, it does all the cgroup handling by itself)12:39
hallynpitti: not if there is cgroup namespaces or lxcfs12:52
=== gshereme|away is now known as gshereme
tyhickspitti: ah, thanks13:24
tyhickspitti: I had done the merge, incorporated it with my other pending changes, and was going to test today13:24
tyhickspitti: it should be easy to rebase them onto your upload though13:25
tyhicks(I'll also make sure that we came to the same conclusions on the merge)13:25
pittityhicks: urgh, sorry; feel free to upload over mine, it is (and will still be for a while) stuck in -proposed anyway13:37
pittityhicks: most of the work really was about reviewing the delta, and it's just that one which was left13:38
pittiseb128: any chance I can bribe you to source-NEW review nplan?13:45
pitti(not sure if you are still doing archive admin)13:45
seb128pitti, I sortof do, no official shifts but every now I pick some reviews and I'm happy to help/reply to ping ... looking!13:46
pittiseb128: thanks; it's small13:47
seb128pitti, 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)14:10
pittiseb128: ah, I'll add COPYING; LGPL? I intended GPL14:11
seb128pitti, License: LGPL-3.0+14:12
pittiseb128: please reject, I'll reupload14:12
seb128pitti, looks good otherwise14:12
seb128pitti, just give me a nudge once reuploaded14:12
mdeslaur@pilot out14:13
=== 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:
pittiseb128: back in the queue14:17
seb128pitti, no it's not...14:18
* pitti hugs seb12814:18
* seb128 hugs pitti back14:18
mterrycjwatson, 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 there14:18
mterryI'm looking at yakkety specifically, but it may affect other series14:20
cjwatsongood question14:21
cjwatsoncan't just be a deathrow failure since the packages are still referenced from dists14:24
cjwatsonsource is deleted, binary not14:24
mterryyeah I thought that was odd14:24
pittiseb128: just saw that I forgot to add copyright/license headers to the source files; done in git now14:28
pittiseb128: and there was an unstable test which caused ftbfs on ppc64el, also fixed14:28
cjwatsongrepping logs14:30
cjwatsonmterry: 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 delete14:35
cjwatsonmterry: I'll delete them manually14:35
mterrycjwatson, oh cool thanks14:37
* mterry is glad LP isn't busted :)14:37
cjwatsonmterry: I don't see the Qt packages you mention though14:38
cjwatsonmaybe you removed those already?14:39
mterrycjwatson, I didn't...  I also don't see them via apt.  But u8 is built against them.14:39
cjwatsonmterry: link to the build?14:39
mterrycjwatson, ah.  qt is in proposed, that's what happened14:41
cjwatsonmterry: done all the remaining click removals now (pending publisher)14:46
mterrycjwatson, thanks!14:46
seb128pitti, 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/copyright14:48
pittiseb128: the queue has some binaries now14:49
seb128pitti, I don't understand https://launchpad.net/ubuntu/+source/nplan/0.114:50
pittistill waiting on arm, though; powerpc failed, need a porter box for that (but also, not urgent at all)14:50
seb128oh, you uploaded 0.214:50
pittiseb128: I rejected the two binaries; yes14:50
seb128k, sorry I was looking at the wrong page14:50
seb128pitti, I usually wait for all the archs to be done, queue estimate is ~10minutes for the armhf/64, ok to wait for those?14:51
pittiseb128: absolutely14:51
philrochenacc: Could you have another look at lp:1581200 please. I'm in need of an upload for cloud-init on trusty.14:51
seb128pitti, great, going to look again in half an hour or so then14:51
LocutusOfBorghi pitti , thanks for the apparmor merge14:57
LocutusOfBorgfor next time, can you please think about dropping all the breaks+replaces against apparmor?14:57
LocutusOfBorgBreaks: apparmor-easyprof ( << 2.8.95~2385-0ubuntu1 ), apparmor-utils ( << 2.8.95~2385-0ubuntu1 )14:58
LocutusOfBorgI think they can be dropped together with the one against debhelper14:58
pittiLocutusOfBorg: this should be done in Debian; I don't want to introduce extra ubuntu delta for such cleanup, as it has no runtime effect14:58
pittiseb128: ok, I now have a nice segfault to debug on arm64 and powerpc :)14:59
LocutusOfBorgI tried to explain that here https://lists.debian.org/debian-backports/2016/07/msg00085.html14:59
LocutusOfBorgbut the Debian maintainer didn't understand that14:59
LocutusOfBorgso maybe if you can explain or add your opinion he will drop it :)15:00
LocutusOfBorgI agree about keeping delta minimal15:00
LocutusOfBorgI'll open a bug15:01
seb128pitti, it failed on arm* so builds done, binNEWed it15:04
pittiseb128: thanks; I'll debug this tonight or tmw on a porter box15:04
* LocutusOfBorg leaves15:07
naccphilroche: ah I see, sorry about that!15:22
=== dpm is now known as dpm-afk
philrochenacc: No problem15:23
sarnoldpitti: thanks for investigating the unhappy retracer :)17:20
=== fginther` is now known as fginther
pittirharper, lool, smoser: FYI: nplan | 0.2 | yakkety/universe | source, amd64, i386, ppc64el, s390x17:46
pittithis should unblock some cloud-init/maas development hopefully?17:46
smoserpitti, well, sure :)17:47
pittismoser: this doesn't have an "apply changes now" button yet, that should follow soon17:48
smoserpitti, ok. i will try to take a look sometime soon17:50
=== dpm-afk is now known as dpm
=== _salem is now known as salem_
smoserhey... anyone know how i would switch from bzr to git and squash the "merged" commits that would be hidden ?19:09
smoserie, bzr --include-merged shows a ton of things that i dont want on primary 'git log'19:09
smoserand 'bzr log' would have hidden19:09
dobeysmoser: you'd have to manually go through and squash them i guess. not sure if bzr-git or git-bzr would have something for it19:10
smoserhow woudl i even do that ?19:11
smoserhttps://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ solves my other desire19:11
dobeygit rebase -i with appropriate revision specification arguments i guess?19:11
smoserwhich is to not lose --fixes19:11
dobeypreserving metadata would indeed be nice when migrating19:13
dobeyof course, git commit doesn't have a --fixes :-/19:13
smoser3597 commits in total 1258 that are bzr "top level" commits19:14
smosernot something i can do by hand19:14
smoserthat link basically just converts the fixes metadata into some string19:14
smoserwhich is not as nice as specific metadata, but acceptable19:14
dobeyreal metadata would be much nicer19:15
rbasaksmoser: 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.19:21
dobeyalso that, yeah19:23
smoserrbasak, you'd rather see 'fix spelling' , 'whoops'19:25
smoserinterwieved with actually useful information19:26
smoseri'd rather not see it. i dont like losing the data either.19:26
smoserbut every day usage includes 'git log' and i'd rather not have garbage there.19:26
rbasaksmoser: so use git log --first-parent.19:29
rbasaksmoser: and ask submitters to squash out mistakes before merging, like the Linux project requires.19:30
rbasakAs 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.19:33
rbasakPerhaps it should be "Launchpad-Bugs-Fixed" after what we already do in changes files. As a bonus the syntax would be identical.19:35
smoserrbasak, sure. thats fine... and that is waht that fusonic.net url does19:36
rbasakIt 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.19:36
rbasaksmoser: yes, but looks to me that it sticks it into the subject line.19:36
rbasakI wouldn't do that.19:36
smoserwell, it has to convert actual metadata into some string19:36
smoserand just put that string in the commit message19:36
loolpitti: \o/19:37
smoserso it doesnt really matter what it does19:37
loolpitti: well done on landing nplan19:37
smoseri dont care about the specifics.19:37
rbasakIt should be in the commit body under some common syntax, since we want tooling to pick it up.19:37
pittilool: merci19:37
rbasakOtherwise bugs won't auto-close when Launchpad learns how to do that.19:37
smoserrbasak, sure. but i dont really care what that syntax is now. i just care that it isnt lost.19:37
rbasakYou don't care about losing consistency when you have to change to a different syntax in the future? That surprises me, but OK :)19:38
smoserrbasak, well, my option is to wait until some standard is created ?19:40
smosergiven "wait a few weeks" compared to "have something acceptable now" i'll take the later19:41
rbasakIt looks like it's already defined as it happens. One moment.19:43
rbasakhttp://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/enums.py#L40 I think19:44
rbasakFrom https://code.launchpad.net/~cjwatson/launchpad/git-update-related-bugs/+merge/29836919:45
rbasak"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."19:46
rbasakSo: "LP: #123" or "LP: #123, #456" I think?19:46
rbasakcjwatson: ^ is that right, please?19:46
ubottuLaunchpad 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/12319:46
ubottuLaunchpad bug 456 in libgtk-java (Ubuntu) "Unable to upgrade #2" [Medium,Fix released] https://launchpad.net/bugs/45619:46
rbasak(technically it looks like it's under review, rather than defined)19:47
smoserwell, LP: # is what i probably woudl have picked anyway :)19:47
=== Unit193 is now known as TheMaster
=== krytarik is now known as Unit193
=== TheMaster is now known as krytarik
smoserrbasak, first-parent is nice. thank you.20:02
cjwatsonrbasak: That's correct.20:30
cjwatson(Under review, as you say.)20:30
=== Unit193 is now known as krycek
=== krytarik is now known as Unit193
=== krycek is now known as krytarik
voozeHi, 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/158940121:08
ubottuLaunchpad bug 1589401 in network-manager (Ubuntu) "cannot view wifi networks after re-enabling wifi" [High,Confirmed]21:08
voozeoh shit, wrong bug report.21:08
voozehttps://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324 here you go :D sorry21:08
ubottuLaunchpad bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones" [Medium,Confirmed]21:08
rbasakcjwatson: thanks21:10
rbasakvooze: 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.21:12
rbasakvooze: once identified, we can ask the person who introduced the regressing patch to look into it.21:12
cjwatsonrbasak: 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.21:14
cjwatsonI think this is defensible but it's still a behaviour change.21:15
rbasakcjwatson: 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.21:15
cjwatsonrbasak: Since that's very expensive, I'd like to have a compelling reason.21:15
rbasakWhy is it expensive?21:15
rbasakCould 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.21:16
cjwatsonThere are a lot of very deep histories out there, and it would involve a lot of database rows.21:16
rbasakOr would that be too confusing?21:16
cjwatsonThe bzr implementation is essentially disastrous.21:16
cjwatsonIt could be done less badly, but still ...21:16
voozerbasak: 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 :D21:16
cjwatsonThe 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.21:17
rbasakOh, I may be talking about something else.21:17
cjwatsonThe bit that would be difficult is working out what branch a commit is most relevantly in.21:17
rbasakI'd like auto-close really. I'm not sure linking a branch automatically makes sense in git land unless submitting an MP.21:17
rbasakBut 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.21:18
cjwatsonAh.  We've never done that in bzr because the policy is complicated.21:19
cjwatsonSome projects want that kind of thing and some don't.21:19
voozerbasak: And thanks for the answer. What should I do when I find the patch that's causing it?21:19
cjwatsonLaunchpad 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.21:19
rbasakSo, 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.21:19
cjwatsonBut presumably only new commits on some nominated branch.21:20
rbasakI 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.21:20
cjwatsonI'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.21:21
cjwatsonI know GitHub does this, so I'm sure some projects are used to it.21:21
cjwatsonI 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.21:22
rbasakIt wouldn't surprise me if that's what they do.21:23
rbasakBut I appreciate your point about doing it right.21:23
rbasakHow 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".21:24
cjwatsonhttps://help.github.com/articles/closing-issues-via-commit-messages/ says it has to be in the default branch.21:24
cjwatsonWe do have a similar notion of the default branch for a repository.21:25
cjwatsonThere are somewhat different scoping issues for Launchpad, though.21:25
rbasakBy "enable it for a project", I mean that you specify the project.21:25
cjwatsonGitHub tracks issues per-repository; Launchpad tracks them per-project (etc.), and a project may have many repositories.21:25
rbasakRight, so user/group->repository->branch could have a "close *this* project's bugs" option.21:26
rbasakvooze: ping whoever introduced the patch on IRC maybe? Feel free to ping me if you need help with that.21:28
cjwatsonMy 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.21:29
cjwatsonOr a similarly small piece of config.21:29
rbasakvooze: see "bisection", eg. with ~28 commits, it should only take about six builds, I think.21:29
rbasakcjwatson: I'd be fine with that too for all my use cases, I think.21:30
* rbasak goes to bed21:31
rbasakThank you for the discussion. I appreciate it.21:31
voozerbasak: Awesome. Just to be sure, you mean Like, first patch all with 02XX and then 03xx ?21:31
cjwatsonrbasak: 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 chance21:31
cjwatsonrbasak: (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!)21:32
rbasakvooze: 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 do21:33
rbasakthe 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.21:33
rbasakvooze: this way, eventually you should pin it down to the addition of a single patch, I think within about six iterations.21:34
rbasakcjwatson: I'll file a bug, thanks.21:34
* rbasak leaves himself a reminder for tomorrow21:34
voozerbasak: ah, I see :) that's pretty smart. I will for sure do that :)21:34
voozeI was afraid, I had to do like 30 builds ;)21:35
cjwatsonBisection is great.  When it works, anyway.21:35
voozeCan I easily reload pulseaudio after installing new build, so I don't have to reboot?21:36
voozenvm, figured it out.. Anyway, I will do some builds tomorrow. It's late in Denmark, I'm too tired for it now.21:39
voozeThanks for all your  help!21:39
=== w0rg is now known as b4r
mwhudsonoh man BranchRevision21:50
=== salem_ is now known as _salem
wgrantmwhudson: It has several rows now.23:25
wgrantSeveral billion.23:25
mwhudsonwgrant: somewhere on the impressive/depressing continuum23:26
wgrantmwhudson: Postgres handles our 1TB DB admirably...23:26
wgrantAnd more than half of that is BR.23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!