[03:43] <davidstrauss> lifeless, When, exactly, did it become acceptable for Ubuntu/Launchpad admins to reply with dismissive, pre-fab responses to legitimate tickets? https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/775842
[03:44] <davidstrauss> There's pretty much no way to piss me off and send me hunting for a different distro than this sort of corporate dumbness.
[03:45] <lifeless> so, I find those responses pretty annoying myself
[03:45] <davidstrauss> lifeless, I included quite precise reproduction instructions.
[03:45] <lifeless> I can see that
[03:45] <lifeless> theres a couple of possibilities
[03:45] <davidstrauss> lifeless, Who can I talk to change this sort of dismissive policy?
[03:46] <lifeless> the ubuntu bug squad
[03:46] <ScottK> That's pretty standard for Pedro.
[03:46] <lifeless> brian murray is a good person to start with
[03:46] <ScottK> (and I agree pretty infuriating)
[03:46] <lifeless> ScottK: he pissed my dad off totally with a similar thing
[03:47] <davidstrauss> lifeless, This is only going to drive away Ubuntu users. I'm also not a big fan of having to play hunt to file bug reports for Ubuntu without looking for the "no redirect" link
[03:47] <StevenK> lifeless: As an aside, I think it's awesome your father is filing bugs.
[03:47] <lifeless> StevenK: *was*. See prior comment.
[03:47] <StevenK> Ah
[03:48] <davidstrauss> Regardless of anything else, the correct bug state for this sort of response is "incomplete," not "invalid."
[03:48] <lifeless> he now emails me because the reception his bugs get is sufficiently poor he can't be assed.
[03:48] <StevenK> :-/
[03:48] <lifeless> davidstrauss: so, I agree.
[03:49] <lifeless> davidstrauss: what pedro wants I think is the crashdump you should be able to generate which is -extremely- useful for diagnosing issues like this.
[03:49] <lifeless> I think the presentation and nuance around this is easy to get wrong.
[03:49] <davidstrauss> lifeless, I agree, but making it "Invalid" is pretty much saying, "bugger off."
[03:49] <lifeless> Ubuntu bugsquad really is the folk driving this; most actual devs are pretty solid about working from clear instructions rather than crash reports.
[03:50] <ScottK> I think people who do a lot of triage often lose sight of the fact that good bug metrics are only meaningful if they are based on shit not being broken.
[03:50] <davidstrauss> If the standard is that I'm *required* to submit this sort of crash dump, then that should be more clear.
[03:50] <wgrant> davidstrauss: I believe the motivation for closing it is that it's easier to file a new bug with the crash data than it is to add it to an existing one. But I think it's fairly easy to add it to an existing one too...
[03:51] <lifeless> ubuntu-bug bugnumber
[03:51] <wgrant> https://help.ubuntu.com/community/ReportingBugs
[03:51] <lifeless> IIRC if you have a crash for the package, will attach it. IMBW
[03:51] <wgrant> ubuntu-bug is the way you should be filing bugs.
[03:51] <wgrant> Not directly through the web UI.
[03:52] <ScottK> We disabled apport for KDE packages and use the upstream bug reporting tool to report bugs in the KDE bug tracker.  Nothing against LP, but Kubuntu doesn't have the people to manage the bugs and then when regular bug squad people 'helped' it wasn't particularly helpful.
[03:52] <davidstrauss> wgrant, Whatever was supposed to happen with apport didn't happen when Evolution crashed on me.
[03:54] <wgrant> davidstrauss: I believe it's disabled by default after release. The comment in the bug gives instructions for reenabling it.
[03:54] <wgrant> (it would be nice to leave it on, but that would result in a *lot* of bugs)
[03:54] <lifeless> davidstrauss: apport-collect apparently
[03:55] <lifeless> (just been man page spelunking)
[03:55] <lifeless> davidstrauss: so I think there are two issues; lets get this report back on track, and the social issue really does need folk affected speaking up
[03:55] <davidstrauss> lifeless, I agree, and thanks for helping out here.
[03:56] <lifeless> davidstrauss: have a look in /var/crash/
[03:56] <davidstrauss> lifeless, I did. Nothing there.
[03:56] <lifeless> if you have an evo* crash file, then 'apport-collect 775842' might do what you need
[04:00] <davidstrauss> lifeless, I'll take care of collecting crash data if I can reproduce it. (Unfortunately, the race condition went away once I turned on Evolution debugging.)
[04:01] <lifeless> -win-
[04:01] <davidstrauss> lifeless, Where can I send feedback on the social side of this.
[04:01] <davidstrauss> ?
[04:01] <spm> more to the point, where can I +1 davidstrauss's feedback. :-)
[04:01] <lifeless> bdmurray
[04:01] <lifeless> uhm
[04:02] <ScottK> lifeless: Will you be at UDS?
[04:02] <lifeless> possibly file a bug but I suspect it would be invalidated; you could go straight to the developer council
[04:02] <lifeless> where by developer I'm not sure which board would be right, so I'm being generic
[04:02] <lifeless> ScottK: no; my wife and I are expecting soon - I'm not travelling this year basically
[04:03] <ScottK> lifeless: Congratulations (both on the impending arrival and avoiding the long flight)
[04:03] <lifeless> :)
[04:05] <spm> the rest of us are just hanging for the inevitable nic change: s/lifeless/lifefull/ ;-)
[04:05] <ScottK> davidstrauss: I moved it from invalid to incomplete.
[04:05] <ScottK> We'll see if that starts a 'dialogue'.
[04:05] <davidstrauss> ScottK, Thanks. In the mean time, I'll try and reproduce this in a way to get the dump files.
[04:07] <ScottK> It's been a while now since anyone at Canonical accused me of being a poisonus personality, so this could be fun.
[04:07] <davidstrauss> ScottK, lol
[04:13] <micahg> the reason why that's marked invalid as opposed to incomplete is because it's supposed to produce a new bug w/the crash report
[04:14] <micahg> I think it was just an error on pedro's part in this specific instance
[04:14] <davidstrauss> micahg, I realize that, but the workflow should be "new -> incomplete -> duplicate" if that happens
[04:14] <micahg> davidstrauss: with the volume of bugs we go through, it's usually easier to ignore the first one
[04:15] <micahg> ugh, that came out wrong
[04:15] <micahg> it's easier to close the old one and not have to worry about marking it a duplicate later
[04:15] <davidstrauss> micahg, So set it to "incomplete" and let it expire if I don't follow up with either a new one or additional info
[04:16] <micahg> davidstrauss: there's a bugsquad meeting tomorrow I think in #ubuntu-meeting at 17:00 UTC, you're welcome to discuss your ideas there
[04:17] <davidstrauss> micahg, I'm also convinced this wasn't just a mistake on Pedro's part considering the "I'm closing this bug report..." comment at the end.
[04:18] <ScottK> micahg: This is standard fair for Pedro.
[04:18] <micahg> davidstrauss: yeah, I didn't notice that it crashes, that's why he asked for the crash report so that a proper backtrace could be found
[04:18] <ScottK> fair/fare
[04:19]  * ScottK is personally convinced that bugsquad thinks the goal is zero bugs, not working software.
[04:19] <micahg> ScottK: I've been on the receiving end of these as well
[04:19] <micahg> ScottK: I don't think so, but we're almost at 100k open bugs w/out many more people to go through them
[04:20] <davidstrauss> micahg, But there's a world of difference between, "It's unlikely we can reproduce or solve this issue unless you provide X. Marking this bug as incomplete in the hope that it gets added." and "Your bug fails to meet my personal standards. Invalid."
[04:20] <ScottK> And with automatic bug expiry, in 60 days it amounts to the same thing.
[04:21] <micahg> davidstrauss: I would suggest if you're available to come to the meeting tomorrow, unfortunately, I will not be there
[04:21] <davidstrauss> When marked as "invalid," it also reduces almost any chance anyone else will stuble upon my bug as the issue *they* encountered, too.
[04:21] <ScottK> Absolutely.
[04:22] <davidstrauss> This behavior smacks of Pedro treating the bug queue as his personal inbox.
[04:22] <davidstrauss> micahg, I'll add the meeting to my calendar. Fortunately, the calendar doesn't seem to be crashing on me in Evolution. ;-)
[04:23] <micahg> davidstrauss: no, this was a policy agreed on previously, policies can be changed with good reason (or sometimes w/out good reason), so I would suggest coming to the meeting and airing your grievances in a polite manner there since that's the forum where a change in policy can most likely be had
[04:27] <ScottK> micahg: There's a policy that bugs which lack crash information should be marked invalid?
[04:27]  * davidstrauss also thinks it's odd for the official policy to have such semantic mismatch with Launchpad's workflow
[05:41] <micahg> ScottK: https://wiki.ubuntu.com/Bugs/Responses#Missing%20a%20crash%20report%20or%20having%20a%20.crash%20attachment
[05:42] <ScottK> micahg: That is just insane.
[05:42] <ScottK> It's almost as if we don't actually want users.
[05:42] <ScottK> That would also help keep the bug count low, BTW.
[05:42] <micahg> ScottK: without a stacktrace most crash reports are useless
[05:42] <ScottK> micahg: So mark it incomplete and tell them how to add the data.
[05:43] <ScottK> Incomplete, please help is a lot more socially inviting than closing the bug.
[05:43] <micahg> ScottK: BTW, this was implemented before the auto expiring of bugs, now it might make sense to do that, also idk if the retracer will work on bugs where crash reports are added, they need to be private by default and most of the bugs are public
[05:44] <ScottK> Treating incomplete bugs as invalid is just wrong.
[05:45] <ScottK> I've made it a policy to completely ignore bug squad and it's policies for the last few years.  I think this supports that being a good policy.
[05:45] <spiv> Surely the retracer can be made to work with that case if it doesn't already?  It would seem to be a shame to ignore data added via ubuntu-bug --update-report
[05:46] <micahg> spiv: yes, but you can't make a bug private with restricted subscribers again, the policy makes sense
[05:47] <micahg> at least as far as requiring a new bug for a crash, how to handle the old one can be debated
[06:00] <ScottK> I think invalid and incomplete have very clear definitions and it's clear which one this is.
[07:06] <lifeless> micahg: why require a new bug?
[07:06] <lifeless> micahg: apport is completely capable of attaching data to an existing bug
[07:06] <StevenK> lifeless: Except when the existing bug is private and you didn't report it.
[07:07] <lifeless> StevenK: not at all the case here, as you know
[07:07] <spiv> lifeless: see micahg's reply to me; apport can't attach a private crash dump to an existing public dump
[07:07] <lifeless> so, making a bug private *should* restrict the subscribers
[07:08] <spiv> s/public dump/public bug/
[07:08] <lifeless> bug 181329
[07:30] <micahg> lifeless: if you fix that bug, that would change quite a few things :)
[07:30] <micahg> lifeless: BTW, do you want OOPS reports still?
[07:33] <wgrant> micahg: For package copying?
[07:35] <micahg> wgrant: I've been hitting them at various times, builder list has been very common lately
[07:40] <wgrant> Hmm.
[07:45] <lifeless> micahg: we do see them in the reports
[07:46] <lifeless> but as always if there isn't a filed bug, file one
[07:46] <micahg> lifeless: k, will keep check them then
[11:08] <trijntje> Hi all, how can I see the import queue for a given program in LP without importing something myself to get the link?
[11:09] <henninge> trijntje: the translations import queue?
[11:09] <trijntje> henninge, yes
[11:09] <henninge> trijntje: https://translations.launchpad.net/program/+imports
[11:10] <trijntje> henninge, thanks a lot! I've been trying to do stuf with the url, but I couldnt get it right
[11:10] <henninge> trijntje: you can also get there the clicky way.
[11:10] <henninge> There is a link on http://translations.launchpad.net/program AFIAK.
[11:12] <trijntje> henninge, cool, so I was just looking in the wrong place, thanks again
[11:12] <henninge> trijntje: pleasure ;)
[12:27] <Laibsch> the list of subscribers in bug 713922 is empty and apparently not only when I look at it.  Apparently this is the case for all gtk bugs.  Is that a bug in Launchpad itself?  A known one?
[12:58] <henninge> Laibsch: having a look
[12:58] <Laibsch> cool, thanks
[12:59] <henninge> Laibsch: are you aware of bug 777766?
[13:00] <Laibsch> yes, I am
[13:00] <Laibsch> I filed it ;-)
[13:00] <henninge> Laibsch: I wondered if you did ... ;-)
[13:01] <henninge> Laibsch: so I guess you have your answer in wgrant's comment.
[13:01] <Laibsch> yes, thanks
[13:01] <Laibsch> I only saw it now
[13:02] <Laibsch> thanks guys
[13:02] <Laibsch> bye
[13:02] <henninge> Laibsch: it's set to Critical, so it should not be too long before it gets worked on.
[13:02] <Laibsch> yeah, I saw that with some satisfaction
[13:02] <Laibsch> I'd hope all my bugs would be set to critical ;-)
[13:02] <wgrant> You just have to file the right ones :)
[13:02] <henninge> Launchpad has 235 Critical bugs which we try to drive to zero currently.
[13:02] <Laibsch> well, actually I could do that myself for quite a number of them, hehe
[13:03] <Laibsch> wgrant: bugs affecting me are always critical :-D
[13:03] <Laibsch> probably true for any iteration of "me"
[13:03] <henninge> ;-)
[13:04] <Laibsch> bye
[13:08] <maxb> shipova is stuck - https://launchpad.net/~neon/+archive/ppa/+buildjob/2525566 - Can someone stab it?
[13:43] <wgrant> maxb: Stabbed.
[13:43] <wgrant> Successfully, too.
[13:52] <maxb> wgrant: Hmm. Well, if you define the builder disabling itself as "successful" :-/
[13:53] <wgrant> maxb: Yeah, it went a bit bad after I said that :(
[13:53] <wgrant> I have poked lamont to poke it harder.
[13:53] <wgrant> But that build is no longer stuck.
[13:55] <maxb> bohrium looks in need of stabbing too - https://launchpad.net/~neon/+archive/ppa/+buildjob/2521325
[13:57] <maxb> Hmm... the Launchpad builders unpack a chroot tarball fresh for every build, right?
[13:57] <wgrant> Bah, why is bohrium backk?
[13:57] <wgrant> It is not meant to be here, for exactly that reason.
[13:57] <wgrant> It hangs.
[13:57] <wgrant> maxb: Yes.
[13:58] <maxb> Seems like we could save a lot of build time by teaching lp's sbuild to not purge the packages from the chroots after each build
[13:58] <bigjools> maxb, wgrant: only the virtual builders, the non-virts keep a cache
[13:58] <maxb> a cached what?
[13:58] <wgrant> bigjools: They still unpack it fresh.
[13:58] <wgrant> bigjools: They just don't redownload it.
[13:58] <wgrant> maxb: Yes :(
[13:58] <wgrant> But sbuild.
[13:58] <bigjools> oh, *unpack*
[13:58] <maxb> natty's in-archive sbuild understands not to do this for disposable chroots
[13:58] <wgrant> For virt builders we should indeed not purge.
[13:59] <wgrant> maxb: Yes, but our sbuild is forked from dak's from 2004 or so :)
[14:00] <maxb> Somehow I knew you were going to say that :-/
[14:00] <bigjools> when you say "not purge the packages" do you mean to save time apt-get updateing?
[14:00] <wgrant> bigjools: Save time at the end of the build.
[14:00] <wgrant> At the moment it finishes building, then decides to clean up the chroot by removing all the build-deps.
[14:00] <wgrant> ... and then the VM is destroyed 5 seconds after that's done.
[14:00] <bigjools> ah right, yeah that's useless in a VM
[14:01] <maxb> What purpose does it serve on non-virt?
[14:01] <wgrant> maxb: Stopping daemons, for one, but then the kill-everything-in-the-chroot bit should catch them.
[14:01] <wgrant> So it may be pointless there too.
[14:02] <bigjools> it could be optimised for sure
[15:00] <deryck> adeuring, I'll take IRC now, and we can do our call now, too.  If you're ready.
[15:00] <adeuring> deryck: thanks!
[15:01] <adeuring> deryck: and, let's do the call now
[15:01] <deryck> ok
[15:24] <Sweetshark> Hi there, would there be a way to join/merge projects on LP? https://launchpad.net/df-libreoffice and https://launchpad.net/libreoffice are a bit unfortunate esp. as df-libreoffice has the better name, but little activity.
[15:46] <mortenoh> hi, anyone here ever used the "upgrade format" feature on launchpad? it has been stuck in upgrade mode for over 30 hours now...
[16:23] <wschaub> I'm working on getting launchpad-buildd going on an arm machine (to support arm builds) I know this channel isnt arm specific but I'm basically looking for where I can find the "buildd-slave-chroot-tool" mentioned in the readme in the launchpad-buildd source dir for making a chroot tarball for launchpad-buildd. is that README out of date? or is there some package I need to install. I cant find it in the launchpad source tree.
[16:23] <wschaub> is it safe to use pbuilder to generate a chroot tar for it instead?
[16:23] <deryck> abentley, I am calls, can you help some of the folks here?  ^^
[16:24] <deryck> abentley, I'll swap you time later.
[16:24] <abentley> deryck: sure.
[16:25] <abentley> Sweetshark: I don't think there's a way to merge projects on Launchpad, but you could write a script to migrate all bugs from one project to the other, for example.
[16:26] <abentley> mortenoh: I can investigate.  What branch were you upgrading?
[16:26] <mortenoh> abentley: https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
[16:26] <mortenoh> abentley: (we also have a question on #156031)
[16:32] <kyleN> deryck, ping
[16:33] <deryck> hi kyleN. on call, and then I can help you.  sorry.
[16:34] <kyleN> deryck, thx ping me when you can
[16:35] <abentley> mortenoh: FWICT, the operation was terminated abnormally.  I'm trying to determine why.
[16:36] <mortenoh> abentley: ok, thank you
[16:36] <lamont> wgrant: I stabbed both
[16:37] <SqRt7744> Could someone explain to me how to get an application uploaded to my ppa to compile for both 10.10 *and* 11.04? I tried uploading it twice, once with "maverick" in the name and once with "natty", which kinda worked (at least the rejection note for the second upload mentioned the correct version)... the rejection claimed "already exists .. but uploaded version has different contents"
[16:37] <bigjools> SqRt7744: you need to either upload 2 versions, or use the copy-package menu
[16:38] <bigjools> pool-based repos won't let you have >1 binary of the same version
[16:38] <SqRt7744> bigjools, will look, thanks. where is this copy-package menu of which you speak?
[16:38] <bigjools> SqRt7744: look at the top right of the PPA +packages page
[16:39] <bigjools> you can copy intra-archive to a new series, it copies the same binaries into the other series
[16:39]  * bigjools really needs to make this a FAQ
[16:39] <SqRt7744> bigjools, aaahhh... cool.
[16:39] <SqRt7744> common question I take it?
[16:39] <bigjools> very
[16:42] <SqRt7744> problem solved. Cool. Impressed.
[16:43] <SqRt7744> thanks  :-)
[16:45] <deryck> kyleN, Hi.  sorry about that.  what's up?
[16:46] <kyleN> deryck, side channel please
[16:48] <abentley> mortenoh: Okay, it looks like the upgrade took more than an hour, and the database dropped the connection.  So we weren't able to indicate the operation was complete.
[16:50] <mortenoh> abentley: so, did the upgrade complete successful?
[16:50] <abentley> mortenoh: It looks like it would have.  I can check what the format is.
[16:50] <mortenoh> abentley: are you able to clear the upgrade notice on the trunk?
[16:51] <abentley> mortenoh: I can have it done, but it may take a little while.
[16:52] <mortenoh> abentley: ok, thats fine.. :) thanks for the help
[16:52] <abentley> mortenoh: The format is 2a, so it looks like the upgrade succeeded.
[16:52] <abentley> mortenoh: You're welcome.
[16:52] <mortenoh> abentley: good, how will this affect current local branches that are in the old format?
[16:53] <abentley> mortenoh: if they were in an old rich-root format like --1.14-rich-root, you'll be able to push and pull, and the data will be upgraded on the fly.
[16:54] <abentley> mortenoh: if they were in a non-rich-root format, they will need to be upgraded before they can interoperate.
[16:54] <mortenoh> abentley: we were using the version that was compatible with 0.93
[16:54] <mortenoh> abentley: version 6
[16:54] <mortenoh> abentley: Bazaar pack repository format 1 (needs bzr 0.92)
[16:55] <abentley> mortenoh: You'll need to upgrade.
[16:55] <mortenoh> abentley: ok, thanks. I will let the developers know (I'm assuming this is a simple bzr upgrade job)
[16:56] <abentley> mortenoh: Yes, it is.
[16:56] <mortenoh> abentley: ok, good. Thanks again for your help.
[16:57] <abentley> mortenoh: You're welcome.
[17:10] <abentley> mortenoh: I filed this bug to track the root cause: https://bugs.launchpad.net/launchpad/+bug/777958
[17:13] <abentley> lamont: do you know the answer to wschaub's question, "I'm basically looking for where I can find the "buildd-slave-chroot-tool" mentioned in the readme in the launchpad-buildd source dir for making a chroot tarball..."
[17:14] <lamont> abentley: lp:~lamont/launchpad-buildd/chroot-scripts
[17:15] <abentley> lamont: Thanks!
[17:15] <lamont> which, if launchpad-buildd lived in its own project, ....
[17:15] <abentley> wschaub: lp:~lamont/launchpad-buildd/chroot-scripts
[17:17] <wschaub> thanks.
[17:18] <wschaub> why wouldn't that stuff just be under lib/canonical/buildd in the launchpad tree in the first place?
[17:23] <mortenoh> abentley: ok, good. We did have a lot of weird stuff happen before this event (we suddenly had negative revisions on our branch, which really messed up bzr). We did fix it pushing a slightly older revision on to the branch though (using push --overwrite), and it seems ok now. Not sure if it was related.
[18:03] <abentley> mortenoh: from what I see, it doesn't look related.
[18:39] <abentley> thumper: just noticed that the job ID has hit 8.2M.  Cool, eh?
[19:03] <deryck[lunch]> abentley, tag. :-)
[19:04] <abentley> deryck[lunch]: ack
[22:34] <thumper> abentley: yeah, that is pretty cool
[22:56] <chrisccoulson> could someone please block this users account: https://bugs.launchpad.net/~bil65klo3
[22:56] <chrisccoulson> he's filling bugs with spam
[22:56] <chrisccoulson> i've had nearly 50 e-mails in the last 20 minutes or so
[23:04] <chrisccoulson> b'ah, 70 e-mails and counting now