| ahoneybun | is there a reason why we don't have a default IRC client? | 00:54 |
|---|---|---|
| RAOF | Probably because it's fairly niche? We also don't have a default IDE :) | 00:55 |
| teward | ahoneybun: ^ that, and also because what would you say should be the default? | 00:55 |
| teward | 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. | 00:55 |
| sarnold | irssi of course | 00:55 |
| teward | sarnold: lol | 00:56 |
| teward | sarnold: that works for server. Answer for Ubuntu Desktop. | 00:56 |
| ahoneybun | but we want people to contribute but no way to talk over IRC | 00:56 |
| jbicha | I remember people were upset when empathy replaced pidgin by default | 00:56 |
| Unit193 | teward: Irssi. | 00:56 |
| sarnold | teward: well you're right, i've been meaning to try out weechat for a few years now | 00:56 |
| ahoneybun | HexChat is what I'm using now | 00:56 |
| Unit193 | ahoneybun: Hexchat generally for GTK, Konvi or Quassel for Qt. | 00:57 |
| ahoneybun | I use Konvi with Kubuntu | 00:58 |
| ahoneybun | but I have Ubuntu on this laptop | 00:58 |
| ahoneybun | broke when moving to yakkety | 00:58 |
| RAOF | I think we primarily want people to find Ubuntu *useful*. | 00:58 |
| RAOF | Contributions are nice, but realistically our contributor base *should* be a tiny tiny fraction of our user-base. | 00:58 |
| ahoneybun | us over at Kubuntu just put Kiwi IRC into our website | 00:59 |
| jbicha | most of the Ubuntu flavors still ship IRC clients but their target audience is a bit different | 00:59 |
| ahoneybun | on the support page | 00:59 |
| RAOF | Yeah, there's no reason Kubuntu can't select and ship a default IRC client. | 00:59 |
| jbicha | and Ubuntu included empathy until 16.04 so maybe the flavors will follow | 00:59 |
| Unit193 | RAOF: 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 |
| ahoneybun | we do | 01:00 |
| ahoneybun | Konvi is the default since 15.10 I believe | 01:00 |
| Unit193 | Xubuntu pretends Pidgin is an IRC client, stopped shipping Xchat a couple releases back. | 01:01 |
| RAOF | Unit193: 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 |
| sarnold | you can use a computer -without- irc? what would you do with it? :) | 01:01 |
| Unit193 | Hah, I'm sure it is, though I believe Freenode is one of, if not the biggest network. | 01:01 |
| RAOF | That's rather my point ☺ | 01:01 |
| Unit193 | sarnold: Hmm. Youtube and reddit I suppose? | 01:02 |
| sarnold | Unit193: oh yes I see links to those all the time ;) | 01:03 |
| * mwhudson rages at quilt | 01:05 | |
| * sarnold quilts at rage | 01:05 | |
| * RAOF is not disappointed to not have to deal with quilt very much anymore :) | 01:06 | |
| teward | sarnold: to answer your question: panic. | 01:07 |
| mwhudson | also dos line endings | 01:07 |
| sarnold | teward: hehe | 01:07 |
| Unit193 | sarnold: Also, I thought I might have killed you with my wall-o-text! :3 | 01:08 |
| sarnold | Unit193: 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 |
| Unit193 | Haha, niiice! Whoops. | 01:09 |
| mwhudson | oh, and, apparently the x11 clipboard and/or vim | 01:10 |
| sarnold | mwhudson: 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 | 01:11 |
| mwhudson | sarnold: i seem to have prevailed but yeah | 01:13 |
| mwhudson | 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 | 01:13 |
| === JanC_ is now known as JanC | ||
| === saurik_ is now known as saurik | ||
| pitti | Good morning | 05:42 |
| Unit193 | pitti: Howdy. | 05:42 |
| pitti | sarnold: they work in general, there is just an exception for this particular one; I added an apport task and the traceback to that bug | 05:46 |
| pitti | hey Unit193 | 05:46 |
| tsimonq2 | o/ pitti, how are you? :) | 05:47 |
| pitti | tsimonq2: I'm good, thanks! how about yourself? | 05:48 |
| tsimonq2 | great pitti :) | 05:48 |
| Unit193 | pitti: Were you testing all the user sessions? And I presume now sctl restart user@1000 is a seriously bad idea now? :P | 06:01 |
| pitti | Unit193: not all of them yet; I tested ubuntu, lubuntu, xubuntu, and kubuntu | 06:01 |
| pitti | unity8 does not run on my system, and mythbuntu and studios are derivatives of xubuntu | 06:01 |
| pitti | I still need to test them and provide .targets for those, but that should be easy | 06:02 |
| pitti | s/derivatives of xubuntu/use an XFCE based session/ I mean | 06:02 |
| Unit193 | I poked studio and myth, seems Myth may stop doing an ISO. And fwiw 'Xfce'. :P | 06:03 |
| pitti | Unit193: 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 | 06:04 |
| pitti | not sure, does xubuntu participate in alpha-2? | 06:04 |
| Unit193 | I don't think so. | 06:04 |
| jbicha | Ubuntu GNOME won't be doing Alpha2 this time either | 06:08 |
| pitti | I'm currently working on some upstart fixes, once they are in I can land the xubuntu conversion | 06:09 |
| Unit193 | Good to know, pushed the change I wanted first. | 06:11 |
| pitti | Unit193: which change do you mean? | 06:11 |
| pitti | tyhicks: 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 | 07:18 |
| pitti | intrigeri did a fine job of merging on the Debian side | 07:18 |
| pitti | tyhicks: 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 |
| pitti | and vcs-bzr: is very outdated, so I'll just drop that | 07:25 |
| === davidcalle|afk is now known as davidcalle | ||
| pitti | tjaalton: 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 |
| ubottu | 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 | 07:58 |
| pitti | tyhicks: FTR, apparmor merge uploaded now | 07:59 |
| tjaalton | pitti: once our kernel supports it | 08:28 |
| tjaalton | not sure it does yet | 08:29 |
| pitti | tjaalton: oh, so that was done in 4.5 or 4.6 in Debian? | 08:29 |
| pitti | right, thanks | 08:29 |
| tjaalton | guess so | 08:29 |
| tjaalton | we're still on 4.4 | 08:29 |
| flexiondotorg | Laney, mate-hud arrived in the 16.10 archive yesterday. | 08:50 |
| flexiondotorg | I've just uploaded an updated ubuntu-mate-meta that seeds mate-hud | 08:50 |
| === marcusto_ is now known as marcustomlinson | ||
| flexiondotorg | Is 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 |
| Laney | flexiondotorg: You get someone on the DMB to re-run their script | 08:51 |
| flexiondotorg | ty | 08:52 |
| pitti | hallyn: hey Serge, how are you? | 09:29 |
| pitti | hallyn: 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_Bloke | infinity: Ah, yes, that should have been backported, yes. | 10:29 |
| Odd_Bloke | infinity: And I'm multi-talented, I can work and frolic. | 10:29 |
| nacc | rbasak: around? | 10:29 |
| rbasak | yes | 10:31 |
| nacc | rbasak: hey, so i was taking a look at LP: #1597414 | 10:32 |
| ubottu | Launchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/1597414 | 10:32 |
| nacc | rbasak: isc-dhcp's publication history in debian is terrible :/ | 10:32 |
| nacc | rbasak: specifically, version going backwards repeatedly, the same version being published multiple times in the same series/pocket | 10:33 |
| rbasak | nacc: if there are only a few packages that do this, then would a complicated override file be OK? | 10:33 |
| nacc | rbasak: 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 |
| nacc | that is, given a version and a package name, for isc-dhcp, i no longer have a unique entry in the publishing history | 10:35 |
| nacc | (and a series) | 10:35 |
| rbasak | OK, but the trees should still be identical I think, right? | 10:35 |
| nacc | they should be yes | 10:35 |
| rbasak | What would happen if we ignored the subsequent publishing history entries of the same version in the same pocket? | 10:36 |
| nacc | i think that could work, but then `git log debian/sid` wouldn't match +publishinghistory | 10:37 |
| rbasak | 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. | 10:38 |
| nacc | agreed | 10:38 |
| rbasak | Hopefully it's rare/historical. | 10:39 |
| nacc | 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) | 10:39 |
| rbasak | 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. | 10:39 |
| nacc | yeah | 10:40 |
| rbasak | Yeah I see the coding difficulty. | 10:40 |
| nacc | but that's ok, i will see if i can sketch someting out | 10:40 |
| Mirv | warp10: thanks! happy to be part of we-love-pitti. | 11:36 |
| mdeslaur | @pilot in | 11: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 dholbach | 12:02 | |
| === utlmming is now known as utlemming | ||
| hallyn | pitti: yeah, that's probably good. what is the process? | 12:24 |
| pitti | hallyn: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning | 12:27 |
| pitti | hallyn: 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 |
| pitti | hallyn: or, if that makes more sense, perhaps file a request to remove the package and RC bugs against the reverse deps | 12:28 |
| pitti | 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" | 12:28 |
| hallyn | pitti: ok thx, i'll think about it. | 12:29 |
| pitti | rdepends> systemd-shim only; libpam-cgm is from cgmanager, lxc is only a recommends (and probably wrong these days) | 12:29 |
| hallyn | i still may change my mind and decide to rewrite it and change the scope a bit :) | 12:29 |
| pitti | hallyn: no hurry or urgency of course, it just caught my eye and I was wondering what the future plan is | 12:30 |
| hallyn | yeah | 12:30 |
| hallyn | 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) | 12:30 |
| hallyn | 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 | 12:32 |
| pitti | there's still sysvinit | 12:33 |
| hallyn | 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 | 12:33 |
| pitti | but nobody really maintains it; but it's the reason why systemd-shim is still a thing in Debian | 12:33 |
| pitti | hallyn: sounds good, thanks! | 12:33 |
| hallyn | pitti: sorry, pls remind me, | 12:34 |
| hallyn | why do sysvinit ppl want systemd-shim? which pice of userspace requires that? | 12:34 |
| pitti | hallyn: pretty well every desktop these days talks to logind for session tracking, suspend, reboot, screensaver management etc. | 12:34 |
| hallyn | all right, made a note, i plan to act on aug 9 :) | 12:34 |
| pitti | hallyn: with systemd-shim you can use logind (and also timedatectl/hostnamectl, for settings) under sysv | 12:35 |
| hallyn | i'm wondering how deep that goes, | 12:35 |
| pitti | that was the main driver for it as CK got abandoned long ago | 12:35 |
| hallyn | i.e. if it's just "kde and gnome", or if it's library pices that even i3 users etc would need | 12:35 |
| pitti | my suspicion is that shim could probably work without cgmanager or cgroups at all | 12:35 |
| hallyn | but you're abandoning shim anyway | 12:36 |
| pitti | and just provide stubs for the calls | 12:36 |
| pitti | yes, me personally, but this is a case where "orphan" is right, not removal | 12:36 |
| pitti | as it's clearly useful still | 12:36 |
| hallyn | ok | 12:36 |
| pitti | I just don't have time/motivation to work on it myself | 12:36 |
| hallyn | \o | 12:38 |
| pitti | hallyn: does lxc need it on sysvinit? (I thought not, it does all the cgroup handling by itself) | 12:39 |
| hallyn | pitti: not if there is cgroup namespaces or lxcfs | 12:52 |
| === gshereme|away is now known as gshereme | ||
| tyhicks | pitti: ah, thanks | 13:24 |
| tyhicks | pitti: I had done the merge, incorporated it with my other pending changes, and was going to test today | 13:24 |
| tyhicks | pitti: it should be easy to rebase them onto your upload though | 13:25 |
| tyhicks | (I'll also make sure that we came to the same conclusions on the merge) | 13:25 |
| pitti | tyhicks: urgh, sorry; feel free to upload over mine, it is (and will still be for a while) stuck in -proposed anyway | 13:37 |
| pitti | tyhicks: most of the work really was about reviewing the delta, and it's just that one which was left | 13:38 |
| pitti | seb128: 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 |
| seb128 | pitti, 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 |
| pitti | seb128: thanks; it's small | 13:47 |
| seb128 | 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) | 14:10 |
| pitti | seb128: ah, I'll add COPYING; LGPL? I intended GPL | 14:11 |
| seb128 | pitti, License: LGPL-3.0+ | 14:12 |
| pitti | seb128: please reject, I'll reupload | 14:12 |
| seb128 | k | 14:12 |
| seb128 | pitti, looks good otherwise | 14:12 |
| seb128 | pitti, just give me a nudge once reuploaded | 14:12 |
| mdeslaur | @pilot out | 14: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: | ||
| pitti | seb128: back in the queue | 14:17 |
| seb128 | pitti, no it's not... | 14:18 |
| * pitti hugs seb128 | 14:18 | |
| seb128 | ;-) | 14:18 |
| * seb128 hugs pitti back | 14:18 | |
| mterry | 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 | 14:18 |
| mterry | I'm looking at yakkety specifically, but it may affect other series | 14:20 |
| cjwatson | good question | 14:21 |
| cjwatson | can't just be a deathrow failure since the packages are still referenced from dists | 14:24 |
| cjwatson | source is deleted, binary not | 14:24 |
| mterry | yeah I thought that was odd | 14:24 |
| pitti | seb128: just saw that I forgot to add copyright/license headers to the source files; done in git now | 14:28 |
| pitti | seb128: and there was an unstable test which caused ftbfs on ppc64el, also fixed | 14:28 |
| cjwatson | grepping logs | 14:30 |
| cjwatson | mterry: 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 | 14:35 |
| cjwatson | mterry: I'll delete them manually | 14:35 |
| mterry | cjwatson, oh cool thanks | 14:37 |
| * mterry is glad LP isn't busted :) | 14:37 | |
| cjwatson | mterry: I don't see the Qt packages you mention though | 14:38 |
| cjwatson | maybe you removed those already? | 14:39 |
| mterry | cjwatson, I didn't... I also don't see them via apt. But u8 is built against them. | 14:39 |
| cjwatson | mterry: link to the build? | 14:39 |
| mterry | cjwatson, ah. qt is in proposed, that's what happened | 14:41 |
| cjwatson | yep | 14:41 |
| cjwatson | mterry: done all the remaining click removals now (pending publisher) | 14:46 |
| mterry | cjwatson, thanks! | 14:46 |
| seb128 | 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 | 14:48 |
| pitti | seb128: the queue has some binaries now | 14:49 |
| seb128 | hum | 14:49 |
| seb128 | pitti, I don't understand https://launchpad.net/ubuntu/+source/nplan/0.1 | 14:50 |
| pitti | still waiting on arm, though; powerpc failed, need a porter box for that (but also, not urgent at all) | 14:50 |
| seb128 | oh, you uploaded 0.2 | 14:50 |
| pitti | seb128: I rejected the two binaries; yes | 14:50 |
| seb128 | k, sorry I was looking at the wrong page | 14:50 |
| seb128 | pitti, 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 |
| pitti | seb128: absolutely | 14:51 |
| philroche | nacc: Could you have another look at lp:1581200 please. I'm in need of an upload for cloud-init on trusty. | 14:51 |
| seb128 | pitti, great, going to look again in half an hour or so then | 14:51 |
| LocutusOfBorg | hi pitti , thanks for the apparmor merge | 14:57 |
| LocutusOfBorg | for next time, can you please think about dropping all the breaks+replaces against apparmor? | 14:57 |
| LocutusOfBorg | Breaks: apparmor-easyprof ( << 2.8.95~2385-0ubuntu1 ), apparmor-utils ( << 2.8.95~2385-0ubuntu1 ) | 14:58 |
| LocutusOfBorg | I think they can be dropped together with the one against debhelper | 14:58 |
| pitti | LocutusOfBorg: this should be done in Debian; I don't want to introduce extra ubuntu delta for such cleanup, as it has no runtime effect | 14:58 |
| pitti | seb128: ok, I now have a nice segfault to debug on arm64 and powerpc :) | 14:59 |
| LocutusOfBorg | I tried to explain that here https://lists.debian.org/debian-backports/2016/07/msg00085.html | 14:59 |
| LocutusOfBorg | but the Debian maintainer didn't understand that | 14:59 |
| LocutusOfBorg | so maybe if you can explain or add your opinion he will drop it :) | 15:00 |
| LocutusOfBorg | I agree about keeping delta minimal | 15:00 |
| LocutusOfBorg | I'll open a bug | 15:01 |
| seb128 | pitti, it failed on arm* so builds done, binNEWed it | 15:04 |
| pitti | seb128: thanks; I'll debug this tonight or tmw on a porter box | 15:04 |
| seb128 | yw! | 15:04 |
| LocutusOfBorg | cheers | 15:07 |
| * LocutusOfBorg leaves | 15:07 | |
| nacc | philroche: ah I see, sorry about that! | 15:22 |
| === dpm is now known as dpm-afk | ||
| philroche | nacc: No problem | 15:23 |
| sarnold | pitti: thanks for investigating the unhappy retracer :) | 17:20 |
| === fginther` is now known as fginther | ||
| pitti | rharper, lool, smoser: FYI: nplan | 0.2 | yakkety/universe | source, amd64, i386, ppc64el, s390x | 17:46 |
| pitti | this should unblock some cloud-init/maas development hopefully? | 17:46 |
| smoser | pitti, well, sure :) | 17:47 |
| smoser | thanks. | 17:47 |
| pitti | smoser: this doesn't have an "apply changes now" button yet, that should follow soon | 17:48 |
| smoser | pitti, ok. i will try to take a look sometime soon | 17:50 |
| === dpm-afk is now known as dpm | ||
| === _salem is now known as salem_ | ||
| smoser | hey... anyone know how i would switch from bzr to git and squash the "merged" commits that would be hidden ? | 19:09 |
| smoser | ie, bzr --include-merged shows a ton of things that i dont want on primary 'git log' | 19:09 |
| smoser | and 'bzr log' would have hidden | 19:09 |
| dobey | smoser: 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 | 19:10 |
| smoser | how woudl i even do that ? | 19:11 |
| smoser | https://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ solves my other desire | 19:11 |
| dobey | git rebase -i with appropriate revision specification arguments i guess? | 19:11 |
| smoser | which is to not lose --fixes | 19:11 |
| dobey | hmm | 19:12 |
| dobey | preserving metadata would indeed be nice when migrating | 19:13 |
| dobey | of course, git commit doesn't have a --fixes :-/ | 19:13 |
| smoser | 3597 commits in total 1258 that are bzr "top level" commits | 19:14 |
| smoser | not something i can do by hand | 19:14 |
| smoser | that link basically just converts the fixes metadata into some string | 19:14 |
| smoser | which is not as nice as specific metadata, but acceptable | 19:14 |
| dobey | right | 19:15 |
| dobey | real metadata would be much nicer | 19:15 |
| rbasak | smoser: 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 |
| dobey | also that, yeah | 19:23 |
| smoser | rbasak, you'd rather see 'fix spelling' , 'whoops' | 19:25 |
| smoser | interwieved with actually useful information | 19:26 |
| smoser | i'd rather not see it. i dont like losing the data either. | 19:26 |
| smoser | but every day usage includes 'git log' and i'd rather not have garbage there. | 19:26 |
| rbasak | smoser: so use git log --first-parent. | 19:29 |
| rbasak | smoser: and ask submitters to squash out mistakes before merging, like the Linux project requires. | 19:30 |
| rbasak | 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. | 19:33 |
| rbasak | Perhaps it should be "Launchpad-Bugs-Fixed" after what we already do in changes files. As a bonus the syntax would be identical. | 19:35 |
| smoser | rbasak, sure. thats fine... and that is waht that fusonic.net url does | 19:36 |
| rbasak | 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. | 19:36 |
| rbasak | smoser: yes, but looks to me that it sticks it into the subject line. | 19:36 |
| rbasak | I wouldn't do that. | 19:36 |
| smoser | well, it has to convert actual metadata into some string | 19:36 |
| smoser | and just put that string in the commit message | 19:36 |
| lool | pitti: \o/ | 19:37 |
| smoser | so it doesnt really matter what it does | 19:37 |
| lool | pitti: well done on landing nplan | 19:37 |
| smoser | i dont care about the specifics. | 19:37 |
| rbasak | It should be in the commit body under some common syntax, since we want tooling to pick it up. | 19:37 |
| pitti | lool: merci | 19:37 |
| rbasak | Otherwise bugs won't auto-close when Launchpad learns how to do that. | 19:37 |
| smoser | rbasak, sure. but i dont really care what that syntax is now. i just care that it isnt lost. | 19:37 |
| rbasak | You 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 |
| smoser | rbasak, well, my option is to wait until some standard is created ? | 19:40 |
| smoser | given "wait a few weeks" compared to "have something acceptable now" i'll take the later | 19:41 |
| rbasak | It looks like it's already defined as it happens. One moment. | 19:43 |
| rbasak | http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/soyuz/enums.py#L40 I think | 19:44 |
| rbasak | From https://code.launchpad.net/~cjwatson/launchpad/git-update-related-bugs/+merge/298369 | 19: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 |
| rbasak | So: "LP: #123" or "LP: #123, #456" I think? | 19:46 |
| rbasak | cjwatson: ^ is that right, please? | 19:46 |
| ubottu | 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 | 19:46 |
| ubottu | Launchpad bug 456 in libgtk-java (Ubuntu) "Unable to upgrade #2" [Medium,Fix released] https://launchpad.net/bugs/456 | 19:46 |
| rbasak | (technically it looks like it's under review, rather than defined) | 19:47 |
| smoser | well, 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 | ||
| smoser | rbasak, first-parent is nice. thank you. | 20:02 |
| cjwatson | rbasak: 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 | ||
| vooze | 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 | 21:08 |
| ubottu | Launchpad bug 1589401 in network-manager (Ubuntu) "cannot view wifi networks after re-enabling wifi" [High,Confirmed] | 21:08 |
| vooze | oh shit, wrong bug report. | 21:08 |
| vooze | https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574324 here you go :D sorry | 21:08 |
| ubottu | Launchpad bug 1574324 in pulseaudio (Ubuntu) "pulseaudio crashes when connecting to bluetooth headphones" [Medium,Confirmed] | 21:08 |
| rbasak | cjwatson: thanks | 21:10 |
| rbasak | vooze: 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 |
| rbasak | vooze: once identified, we can ask the person who introduced the regressing patch to look into it. | 21:12 |
| cjwatson | rbasak: 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 |
| cjwatson | I think this is defensible but it's still a behaviour change. | 21:15 |
| rbasak | cjwatson: 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 |
| cjwatson | rbasak: Since that's very expensive, I'd like to have a compelling reason. | 21:15 |
| rbasak | Why is it expensive? | 21:15 |
| rbasak | 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. | 21:16 |
| cjwatson | There are a lot of very deep histories out there, and it would involve a lot of database rows. | 21:16 |
| rbasak | Or would that be too confusing? | 21:16 |
| cjwatson | The bzr implementation is essentially disastrous. | 21:16 |
| cjwatson | It could be done less badly, but still ... | 21:16 |
| vooze | rbasak: 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 | 21:16 |
| cjwatson | 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. | 21:17 |
| rbasak | Oh, I may be talking about something else. | 21:17 |
| cjwatson | The bit that would be difficult is working out what branch a commit is most relevantly in. | 21:17 |
| rbasak | I'd like auto-close really. I'm not sure linking a branch automatically makes sense in git land unless submitting an MP. | 21:17 |
| rbasak | 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. | 21:18 |
| cjwatson | Ah. We've never done that in bzr because the policy is complicated. | 21:19 |
| cjwatson | Some projects want that kind of thing and some don't. | 21:19 |
| vooze | rbasak: And thanks for the answer. What should I do when I find the patch that's causing it? | 21:19 |
| cjwatson | 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. | 21:19 |
| rbasak | 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. | 21:19 |
| cjwatson | But presumably only new commits on some nominated branch. | 21:20 |
| rbasak | 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. | 21:20 |
| cjwatson | 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. | 21:21 |
| cjwatson | I know GitHub does this, so I'm sure some projects are used to it. | 21:21 |
| cjwatson | 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. | 21:22 |
| rbasak | It wouldn't surprise me if that's what they do. | 21:23 |
| rbasak | But I appreciate your point about doing it right. | 21:23 |
| rbasak | 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". | 21:24 |
| cjwatson | https://help.github.com/articles/closing-issues-via-commit-messages/ says it has to be in the default branch. | 21:24 |
| cjwatson | We do have a similar notion of the default branch for a repository. | 21:25 |
| cjwatson | There are somewhat different scoping issues for Launchpad, though. | 21:25 |
| rbasak | By "enable it for a project", I mean that you specify the project. | 21:25 |
| cjwatson | GitHub tracks issues per-repository; Launchpad tracks them per-project (etc.), and a project may have many repositories. | 21:25 |
| rbasak | Right, so user/group->repository->branch could have a "close *this* project's bugs" option. | 21:26 |
| rbasak | vooze: ping whoever introduced the patch on IRC maybe? Feel free to ping me if you need help with that. | 21:28 |
| cjwatson | 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. | 21:29 |
| cjwatson | Or a similarly small piece of config. | 21:29 |
| rbasak | vooze: see "bisection", eg. with ~28 commits, it should only take about six builds, I think. | 21:29 |
| rbasak | cjwatson: I'd be fine with that too for all my use cases, I think. | 21:30 |
| * rbasak goes to bed | 21:31 | |
| rbasak | Thank you for the discussion. I appreciate it. | 21:31 |
| vooze | rbasak: Awesome. Just to be sure, you mean Like, first patch all with 02XX and then 03xx ? | 21:31 |
| cjwatson | rbasak: 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 | 21:31 |
| cjwatson | rbasak: (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 |
| rbasak | vooze: 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 | 21:33 |
| rbasak | 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. | 21:33 |
| rbasak | vooze: this way, eventually you should pin it down to the addition of a single patch, I think within about six iterations. | 21:34 |
| rbasak | cjwatson: I'll file a bug, thanks. | 21:34 |
| * rbasak leaves himself a reminder for tomorrow | 21:34 | |
| vooze | rbasak: ah, I see :) that's pretty smart. I will for sure do that :) | 21:34 |
| cjwatson | cheers | 21:34 |
| vooze | I was afraid, I had to do like 30 builds ;) | 21:35 |
| cjwatson | Bisection is great. When it works, anyway. | 21:35 |
| vooze | Can I easily reload pulseaudio after installing new build, so I don't have to reboot? | 21:36 |
| vooze | nvm, figured it out.. Anyway, I will do some builds tomorrow. It's late in Denmark, I'm too tired for it now. | 21:39 |
| vooze | Thanks for all your help! | 21:39 |
| === w0rg is now known as b4r | ||
| mwhudson | oh man BranchRevision | 21:50 |
| === salem_ is now known as _salem | ||
| wgrant | mwhudson: It has several rows now. | 23:25 |
| wgrant | Several billion. | 23:25 |
| mwhudson | wgrant: somewhere on the impressive/depressing continuum | 23:26 |
| wgrant | mwhudson: Postgres handles our 1TB DB admirably... | 23:26 |
| wgrant | And more than half of that is BR. | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!