[00:46] ubiquity does segfault on lucid amd64 desktop daily-live iso image , at the last summary window [00:48] Feb 6 01:38:21 ubuntu kernel: [ 500.847290] ubiquity[12571]: segfault at 7f64b29e3840 ip 00007f64c63d1d64 sp 00007fff67769140 error 4 in libglib-2.0.s o.0.2302.0[7f64c6392000+c9000] [00:51] if ubiquity segfaults then it is a bug in some other piece of software [00:52] ubiquity is pure-python [00:54] i found the bug in launchpad [00:54] i'm subscribing to it and i'm posting my logs [00:54] it seems to only affect me and 2 other people [00:54] or maybe there are duplicates of this bug [00:55] argh [00:55] don't do that [00:55] do not *ever* piggyback on somebody else's crash bug [00:55] it's a bug that Launchpad semi-encourages you to do that [00:56] oops [00:56] what do you mean by piggyback ? [00:56] 00:54 i'm subscribing to it and i'm posting my logs [00:56] what should i do ? [00:57] the result of people doing this is that developers give up on that bug because it is now composed of several people's unrelated problems [00:57] file a new bug [00:57] ok [00:57] and i mark it as a duplicate ? [00:57] no, why would you do that? [00:57] that is for a developer to determine [00:57] because it's the same bug [00:57] it is not in general possible for a user to determine that [00:57] you have the same symptoms [00:58] what steps have you taken to prove that it is the same cause? [00:58] i have exactly the same symptoms, same log message, and a segfault from glibc [00:58] and it's in the same software (ubiquity) [00:58] in other words, you havenm't proven anything :) [00:58] a segfault can occur for all kinds of reasons [00:58] and the log message says little more than that it's a segfault somewhere in a large library [00:59] yes sure but you must agree that here the probability that it's the same bug are really high [00:59] no, I mustn't [00:59] if you think it's the same bug, just don't file it [00:59] that's fine, I don't really mind. but I do mind when people jump into an existing bug, because that does actually cause problems, even when they're well-intentioned [01:00] ok sorry [01:00] ubiquity: evand * r3725 plugins-conversion/ (9 files in 5 dirs): Initial plugin conversion work on partman and summary. [01:00] i posted my comment, i read you on irc too late, and i don't think i can remove my comment [01:00] I'm not saying you're deliberately causing a problem here, but I have years of experience in disentangling bugs full of multiple people who think they have the same bug and turn out to be wrong, and I want to discourage people from doing this [01:00] yes i fully understand your concern [01:01] i'm sorry [01:01] ok [01:01] i'm gonna fill a new bug [01:01] and if some developper thinks it's related, he's gonna mark it as duplicate [01:02] one of these days I'll convince the Launchpad people to encourage this behaviour too. :) [01:03] Haha, good luck [01:13] ubiquity: evand * r3726 plugins-conversion/ubiquity/ (components/ubi-usersetup.py frontend/gtk_ui.py): [01:13] ubiquity: * Properly call hostname_error. [01:13] ubiquity: * Remove dead process_identification code from gtk_ui. [01:15] launchpad sucks so hard [01:15] it failed to register the new bug [01:19] ok it failed again ... [01:19] (Error ID: OOPS-1498L141) [01:19] https://lp-oops.canonical.com/oops.py/?oopsid=1498L141 [01:19] great [01:22] good night [01:30] ubiquity: evand * r3727 plugins-conversion/ubiquity/components/ubi-partman.py: Wrap partman gtk_ui initialization so it doesn't crash ubiquity on error. [11:26] hello [11:26] need some help [11:26] is there some one to help [17:32] ubiquity: cjwatson * r3743 ubiquity/ (bin/ubiquity debian/changelog): [17:32] ubiquity: In cdebconf mode, initialise the templates database if necessary as a [17:32] ubiquity: workaround for cdebconf's packaging not doing this itself. [20:21] I have been having an issue with the 64 bit install that I do not with the 32 bit staller, was wondering if this is the place to go to bounce around ideas of what the issue could be.