[00:04] hurray. [00:04] * pwnguin just switched from ipw to iwl === bmk789 is now known as bmk789_brb [00:33] Heya gang === bmk789_brb is now known as bmk789 [00:40] very happy to be here... this is my first time. [00:41] Thank you my Mentor. === apachelogger_ is now known as apachelogger [01:04] pkern: Are you around? [01:28] Heya persia [01:28] hi bddebian [01:54] anyone seen jcastro ? [01:58] not today [01:58] what's he done now? [02:00] nadda was just gonna ask him bout somethin === greeneggsnospam is now known as jsgotangco [03:20] wich package has the binary shares-admin? [03:21] nevermind i just find it [03:21] nxvl: Try `apt-file search shares-admin`. You may need to precede this with `sudo apt-file update`, or possibly even with `sudo aptitude install apt-file` [03:21] gnome-system-tools [03:22] * persia thinks that nxvl has been hit by no-longer-necessary fish and fishing rods :) [03:23] i used packages.ubuntu.com [03:23] :D [03:23] packages.u.c is grossly out of date most of the time [03:24] imbrandon: For the development distribution, or for everything? [03:24] normaly the dev distro [03:25] imbrandon: i'm parching a gutsy bug [03:25] patching* [03:25] imbrandon: Do you happen to know how often refreshes Contents.gz? [03:25] s/en re/en it re/ [03:25] no ideas, i know at most daily, probbably less [03:26] when i complained about it, they said "just use launchpad" /me forgets who "they" are atm [03:27] nxvl: It's not as important yet, but as hardy develops, it will become increasingly important that you also check against hardy, as otherwise your fixes may not be suitable for the current development release, and may not be able to be applied to the current distributed release as the issue remains in the development release. [03:27] imbrandon: Does LP even have an interface for searching Contents.gz? [03:28] i dont think so, this was wabout searching packages themselfs [03:28] Ah... [03:33] persia: it's kind of important error [03:33] persia: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/157174 [03:33] Launchpad bug 157174 in gnome-system-tools ""browsable" instead of "browseable" in smb.conf " [Undecided,Confirmed] [03:33] persia: it makes that shares-admin don't work [03:34] where do i submit a package that isnt in the repos yet? [03:34] nxvl: Sure. I don't mean to say it shouldn't be fixed in gutsy, only that the policy requires that fixes to gutsy must first be fixed in hardy, so it's good practice to check against hardy when fixing a bug. [03:35] persia: oh! ok, ok [03:35] bmk789: REVU is the typical method, although Debian also works at this point. Some guidelines are available in the Preparing New Packages section of https://wiki.ubuntu.com/MOTU/Contributing [03:36] persia: ill check it out thanks [03:37] how do i change the importance of a bug report? do i can? [03:38] nxvl: You'll need to be a member of the QA Team. If you're not currently a member, try working with the BugSquad for a while (#ubuntu-bugs is a good contact point), and once you can demonstrate good knowledge of the triage process, you'll be approved for the QA team. [03:39] persia: oh, ok, thnx [03:39] i enjoy more patching bugs than triagging them :P [03:40] nxvl: Personally, I tend to do both. Find a bug that needs work. If there's enough information for a fix, mark it triaged / in-progress, and fix it. If there's not enough information, work with the submitter to get enough information, and then proceed from the previous condition. [03:41] persia: yes, i'm doing so too, but i enjoy more fixing bux than triaging them :D [03:41] nxvl: You won't lose any points with the BugSquad if you fix all the bugs you touch - you just have to demonstrate an understanding of the different "Importances". [03:43] where is the difference between "Recommends" and "Suggest" in a debain/control file? [03:44] vileda: "Recommends" is used when any sensible person would install the other package as well. "Suggests" is used when the other package could be useful, but not everyone wants it. [03:44] vileda: More information is available from http://www.debian.org/doc/debian-policy/ch-controlfields.html [03:45] persia: thank you [03:45] Err. Rather http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps [03:46] is a .deb the same format as a .tar or .tar.gz? [03:48] bmk789: No. It's an ar file, with the contents organised in a specific manner. [03:48] ah thats what i needed to know, thanks [03:54] ok i extracted the contents of a deb, modified a configuration file so it would require the dependancy, and now i need to repackage it, how do i turn that folder of the package's files into a deb again? [03:54] mmm [03:55] how do dpatch really work, i don't find anything on packaging guide [03:56] bmk789: That's really not the preferred method of doing things :) You probably want to read the dpkg documentation, which can help automate unpacking and packing, and may want to look at modifying the source package as an alternative. [03:56] nxvl: There's pretty good documentation in /usr/share/doc/dpatch [03:57] thnx [03:58] this package is so different though, theres no debian folder, just a control.tar.gz, a data.tar.gz, and a debian-binary [04:00] Ugh, hideous [04:00] bmk789: You're looking at a binary package. The source package would contain a layout that is more familiar. [04:01] ok i guess ill play with the source tarball and see if i can figure out how to work it [04:02] holy, i confirm that the bug was invalid :( [04:02] moving to next one [04:04] I'm trying to make a package for the liberation font, I was wondering how how to figure out the deforma hints for the package [04:05] nxvl: See: you're triaging :) [04:08] persia: yes, and was kind of inscructive and fun :D === santiago-php is now known as santiago-ve [04:09] how does it work with merges, can i do any merge i want or there are some rules? [04:12] nxvl: There are guidelines. Typically, merges are done by one of the people who typically works on the package. This may be the last person who touched it, or it may be someone else listed in the changelog as having made an Ubuntu change. [04:12] nxvl: It's good manners to allow those parties to merge, as often there are other changes or adjustments the packages could use, and such work will be done together at the beginning of a cycle. [04:13] nxvl: For very trivial merges, this guideline is somewhat relaxed. [04:14] nxvl: Further, it's good practice to always open a bug when working on a merge, to notify package subscribers that the work is being done. lpbugs.py is a great help for this. [04:14] * persia rushes off [04:15] nxvl: You can also see status of a lot of merges on the dad site listed in /topic. In some cases people will mark merges people are free to take over. [04:17] isnt there a tool that generates the rules file automagically? [04:18] For new packages, dh_make will do some of that for you [04:18] ScottK: how do they mark them? [04:19] bddebian: thank you [04:19] There's a comments field. [04:19] I thought as of Gutsy it was a merge free for all? [04:19] If they definitely want to keep them, they sometime say so, if they want someone else to take it, they say so. [04:19] bddebian: I think the agreement was it's nice to ask. [04:19] of course, assuming that everyone uses the same tool [04:20] ajmitch: Of course, which they don't. [04:20] Which is why I don't ascribe any meaning to no information. [04:21] ScottK: Well that certainly wasn't what it felt like ;-) [04:21] bddebian: Understand. [04:58] Is it possible for a non-MOTU to help with merging? === jrs is now known as Jaearess [05:03] Jaearess: Sure, although there's lots else to do as well. [05:05] Hey, I thought you rushed off? :-) [05:06] the packaging 101 log is not right... does anyone have a log file from the repeat of dholback's talk? [05:06] Heya LaserJock [05:07] The state of "rushing off" directly implies motion, and therefore a possible destination, often identical to the starting place in the modern world (although some time may pass in the interim) [05:07] persia: Okay. What's a good way for a newbie to get involved with MOTU/packaging? [05:08] Jaearess: I tend to point at https://wiki.ubuntu.com/MOTU/Contributing, and suggest that one start with looking at bugs. It's likely there is a package you use that either doesn't work, or doesn't do what you want. [05:08] persia: You are making my head hurt :-) [05:08] Making a patch for this is often fairly rewarding, and can be a good introduction to the processes and procedures for getting things done. [05:09] bddebian: My apologies. I'll have to seek an alternate mind control ray provider. [05:09] hehe [05:09] heah, can somebody have a look at bug #124376 [05:09] Launchpad bug 124376 in atomix "package atomix-data 2.14.0-1 failed to install/upgrade: subprocess post-installation script killed by signal (Interrupt)" [Undecided,New] https://launchpad.net/bugs/124376 [05:09] how would you guys triage that? [05:10] persia: Okay, thank you. I'll look into that. :) [05:10] LaserJock: I'd look at the postinst for an obvious issue, and otherwise ask the reporter to try installing again, as it may have been a transient issue. [05:12] Jaearess: If you have any questions, this channel is a good place to ask. If you're having difficulty finding good bugs, the "patch" tag often indicates that there is a patch, which may only need a little attention, the "packaging" tag often means that the necessary work is fairly small, and restricted to the standard packaging files, and the "bitesize" tag indicates that someone thought it would be easy to fix. [05:12] geeze, it's gonna take me a little bit to get used to typing hardy instead of gutsy [05:12] heh [05:12] Now to find the completion term. If gutsy::hardy, then gusty::? [05:16] persia: I have a hard time believing that that bug is real. atomix is in Main and is shipped with Edubuntu. If it's broken I would think we'd hear about it more [05:16] I just install atomix in a hardy pbuilder and it was fine and the postinst looks pretty straightforward [05:16] so should it be Incomplete or Invalid ? [05:17] LaserJock: I suspect that the reported ran into OOM, automatix, or a Ctrl-C, but tend to check the packages to keep my face relatively clear of egg. If the reporter can confirm it cannot be reproduced in their environment, "Invalid" sounds good. If the reporter can confirm, then something odd is happening, and ought to be trapped. [05:17] (and "Incomplete" whilst waiting for the response about reproduction) [05:18] well, manchicken reported it, I doubt he'd be running automatix [05:18] I suspect just something funky :-) [05:30] hello LaserJock :) [05:34] when i suscribe a bug to ubuntu-universe-sponsors i need to change it to Confirmed, didn't i? === zzz is now known as ember [05:37] nxvl: There are guidelines on the appropriate bug status settings available from https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (which someone should hit with the pretty stick) [05:51] lucas: ping [06:08] hi ajmitch [06:12] postfix is preferred over sendmail, correct? [06:12] anything is preferred over sendmail [06:12] Haha. [06:12] heh, ok [06:13] And is Dovecot the program of choice for POP/IMAP server? [06:14] It’s great. [06:14] And its author seems to know what he’s doing security-wise. [06:14] That's always nice === cprov-afk is now known as cprov-zz [06:26] ok, who wants to help me look at an apport-reported bug? [06:27] Bug #117568 [06:27] Launchpad bug 117568 in xaos "[apport] xaos crashed with SIGSEGV in memset()" [Undecided,New] https://launchpad.net/bugs/117568 [06:28] the stacktrace has only 4 lines and only one has any info [06:28] I'm not sure what I'm supposed to get out of that [06:30] That null address and the short stack probably indicate stack corruption, in which case it's useless. [06:32] Hey MOTUs, good morning! [06:32] It may also be that no xaos-dbgsym is available from http://people.ubuntu.com/~ubuntu-archive/ddebs/pool/universe/x/, making retraces stubborn. [06:42] persia: hmm, why would there be no symbols? [06:43] Because it hasn't been rebuilt recently, most likely. [06:43] ohhhh [06:43] right [06:43] our package is from like dapper [06:43] Ahh. [06:43] LaserJock: The most common reason is that it wasn't recompiled since the last reset, but in this case I think it is a case of unfortunate timing (dbgsym hiccup), as it was compiled just in July. [06:44] LaserJock: We have a new package for gutsy: 3.2.5ubuntu1 vs. 3.2.3ubuntu2 for feisty [06:46] oh hmm [06:47] maybe I was looking at another package that hadn't bumped versions since dapper [06:47] in any case [06:47] LaserJock: Can you reproduce the crash? If so, you can make your own -dbgsym with a recompile and pkg-create-dbgsym. [06:47] what do you do with these apport bugs like this? they almost always seems like one-off crashes [06:48] LaserJock: Unless they're reproducible, Invalid them. [06:48] I usually ask the submitter to try again, and if they can reproduce, ask them to install -dbgsym & get a backtrace. If they don't after a couple months, I let the bug die. [06:49] Fujitsu: There's heaps of bugs that are architecture- or configuration- dependent. Just rejecting because you can't reproduce locally is a little firm. [06:49] persia: I meant the submitter reproducing. [06:49] Sorry, should have been more clear. [06:49] Fujitsu: Ah. My apologies. I should have assumed. [06:50] Not really. [06:50] hmm, submitters rarely respond :( [06:50] Has Janitor been accidentally turned on again yet, to help with our bug problem? [06:50] LaserJock: Sometimes they do. Often I find it's another person reporting a duplicate that sends me the information, and I let them hijack the bug. [06:50] it was accidently like a day or two ago [06:51] LaserJock: About 24 hours ago. [06:51] yeah, that might be right [06:51] I asked kiko about it [06:51] I still find it a bit hard to believe that this cron job magically restored itself. [06:51] Twice. [06:51] I think they must've had an "accident" trying to rollout [06:51] * persia imagines it runs in the development environment, and that the release process is still a little wonky [06:52] Did they end up restoring the status of the old lot yet? I didn't see any emails... or was that the point, that it would make more annoying changes silently? [06:53] I believe they've reverted everything [06:53] * persia thought they were supposed to be restored without bugmail notifications, but hasn't seen any automatically reverted bugs yet. [06:53] Grr. [06:53] So they're corrupting the only semi-complete history of bugs. Lovely. [06:55] somehow it's always a little depressing to do Edubuntu bug triage [06:56] LaserJock: Why? [06:56] LaserJock: WHy? [06:56] because [06:56] ... [06:56] nobody looks after the packages and they are in Main [06:56] they'd probably get triaged better in Universe [06:56] Ah, lovely. [06:57] Is there a huge queue of sponsor requests waiting on the packages? If not, I don't understand how main/universe matters. [06:57] * Fujitsu looks at little outside universe/multiverse other than bugs without packages. [06:57] Or bugs that affect me :P [06:58] * persia looks at the RC buglist & subscribed packages only [06:58] persia: people triage Universe bugs, at least some [06:58] LaserJock: Perhaps Edubuntu needs more attention from BugSquad? [06:59] perhaps [06:59] it seems that I'm the only one that does anything [07:00] LaserJock: In that case, you definitely need a team. Grab the next person who asks "How can I help" - reserved just for you :) [07:01] LaserJock: What about the rest of the Edubuntu team? [07:02] Fujitsu: what team? ;-) [07:02] Oliver handles LTSP bugs [07:02] other than that, it's pretty much me [07:03] and well, you know how active I'm not [07:04] there's a decent number of bugs on https://bugs.edge.launchpad.net/~edubuntu-bugs/+packagebugs [07:06] ok, how about a bug where the report just reports general crashing [07:06] * persia grumbles that users who can determine that I am the right person to contact about a package should be able to determine that launchpad is the right place to report bugs. [07:06] LaserJock: ask for a backtrace. [07:07] not just with the package he/she reported against [07:07] Fujitsu: haha [07:07] Ah. [07:07] LaserJock: That's invalid. The submitter has to tell us something... [07:07] persia: You'd think so, but I get contacted at least once a week. [07:08] Fujitsu: What do you think causes that. Changelog entries? [07:08] I think so. [07:08] how do they get changelog entries and not know about Launchpad? [07:08] Last Uploader on LP, perhaps. [07:09] LaserJock: cat /usr/share/doc/blah/changelog.Debian.gz? [07:09] LaserJock: /usr/share/docs/foo/changelog.Debian.gz [07:09] Fujitsu: "Last Uploader" has the pretty "Bugs" button, with the nice "Report a Bug" button, so I'd be suspicious [07:10] persia: True, and it has even been missing for the past month, so probably isn't it. [07:11] I actually sort of liked "last uploader", because it made upstreams send me notes. [07:11] well, yeah, but if you're looking around at changelog.Debian.gz I would think you would know better [07:11] * Fujitsu looks for a couple more PPA bugs so he can take over the `Latest bugs reported' portlet. [07:12] LaserJock: poke nixternal & bluekuja. They're around a lot, and members of your triage team :) [07:12] LaserJock: It may mean they're from a Debian background, in which case the Changed-By is probably the maintainer, so best to email. [07:12] LaserJock: Users ought know better, but perhaps we're missing documentation in the right place. In an attempt to make it easy, we may have missed those who don't expect it to be easy. [07:12] Fujitsu: perhaps, but I'd think they at least look at Maintainer [07:13] well, it's not explicitly the wrong action [07:13] but it doesn't seem like the best action [07:13] The problem is that Maintainer sends them to a moderated list, and they get a note that the email didn't go through, so they might be looking for an alternate solution. [07:13] persia: Ah, that is true. [07:14] yes, that is difficult [07:14] * persia ponders a ubuntu-universe-maintainers mailing list that just feeds an archive bot with spam. [07:14] hmm [07:14] (someone should troll through it occasionally to pull out useful reports, but...) [07:14] And then there are the people who come to MOTU Media for help, because the team maintaining all universe packages is called motumedia... [07:15] Fujitsu: That's just requires someone to change the registered email address for "MOTU Media" [07:16] bah, hasn't that been fixed yet? [07:16] LaserJock: Oh, the team merging code landed in 1.1.10. [07:16] But the person->team conversion code is a while off yet. [07:16] So it's still blocked. [07:17] well, we could at least have some DB fudging [07:17] It hasn't happened yet, so I doubt it would happen now. [07:17] LaserJock: You could ask an Answer :) [07:18] persia: I love their chosen terminology. [07:18] heh [07:18] --with-pthread=yes enables SMP support (experimental) [07:19] does ^^ sound like a ok thing to enable? [07:19] Experimental? I doubt it. [07:19] would it affect non-SMP kernels? [07:19] Yes, because it will probably start a bazillion threads anyway. [07:20] LaserJock: In general, SMP without thread support doesn't get much benefit from SMP. That doesn't mean the developers wrote thread-safe code... [07:20] (all our kernels are SMP but -386, but the SMPness isn't what matters much) [07:21] alright, well I guess I'll wishlist this [07:22] seems like people are just trying to justify the shiny new procs they bought ;-) [07:25] bah [07:26] * LaserJock jumps through the "register a project so you can add a bug tracker" hoop [07:26] LaserJock: Don't forget to repeat the steps every six months :) [07:26] what the heck [07:27] I thought there was a link to do it from the bug tracker part [07:27] Not anymore. That was removed. [07:27] I think the easy registration feature is coming soon, though it has been deferred a couple of times. [07:28] bah [07:28] this evening is giving me plenty of things to talk to kiko about ;-) [07:28] Haha, bug #78911 [07:28] Launchpad bug 78911 in malone "Prohibit epic bug descriptions" [High,In progress] https://launchpad.net/bugs/78911 [07:28] Fujitsu: I'm not in a rush. If the Janitor gets fixed, I'll be fairly happy for a bit. [07:28] Bug #127126 [07:28] Launchpad bug 127126 in malone "Register a product while adding an upstream task" [High,In progress] https://launchpad.net/bugs/127126 [07:29] What! I *really** appreciate it when a user provides all the relevant log files and details when reporting a complex bug. [07:30] persia: Logs more than a few lines don't really fit in the description. [07:31] Fujitsu: Both the bugs that are getting complaints are just standard reportbug output. It's all stuff I want to read. [07:32] (although grep -v '^(no debugging symbols found)$' would help.) [07:32] Ah. Nevermind. The limit will be 50K. That seems reasonable. [07:32] persia: Those files are meant to be attached, and large parts don't want to be read by humans. [07:33] (and they are only from Edgy) [07:33] * persia claims to be human [07:33] You like intepreting base64 coredumps? [07:33] Fujitsu: Not exactly, but I've certainly looked at a few, and gained enlightenment from some. [07:33] it's his "light reading" [07:34] persia: You gained useful information by reading a base64 blob? [07:35] Fujitsu: Oh certainly. Lots of times. Usually it was meta-information to better understand the underlying content for spoofing purposes, but I've collected it from coredumps on rare occasions as well. [07:36] Anyway, aside from the "no debugging symbols found", what in the description of bug #78872 isn't interesting to someone trying to debug it? [07:36] Launchpad bug 78872 in totem "Crash with wmv file" [Medium,Invalid] https://launchpad.net/bugs/78872 [07:37] The coredump isn't human-readable, so humans probably shouldn't be subjected to it on every page view. I like the way the new apport does it. [07:38] hmm, is it logical to mark something as WontFix if there's an upstream bug report and really no way we're going to do it in Ubuntu? [07:38] LaserJock: Yes. [07:38] That's what it's for. [07:39] yeah, just feels so mean [07:40] LaserJock: Will upstream fix it? You might just leave it "triaged", with a note that upstream is doing it, but that won't help your bugstats. [07:40] We ideally need a list of Won't Fix bugs that are fixed upstream. [07:41] I think GNOME usually leaves them open until they're closed upstream (except for vague feature requests) [07:41] persia: I looked at the upstream bug and they seemed at least concerned [07:41] the bug is "xaos doesn't work with beryl/compiz" [07:41] there's just no way we're going to do anything with that [07:42] LaserJock: I'd leave open then. Most of the bugs I file against GTK start as an LP bug against a specific application, and are open until Ubuntu gets the fix. [07:42] hmm, that seems sort of counter to the idea of WontFix [07:42] Yes.. [07:43] Fujitsu: you use qcad at all? [07:43] The GNOME people aren't exactly the best users of statuses (think the use of Fix Committed) [07:43] LaserJock: A few months ago I used it a bit, but not recently. [07:43] I thought "Won't Fix" was for random wild feature requests, requests to configure things in undesireable ways, requests to reduce the security protections, etc. [07:43] persia: No, "Won't Fix" is really "Won't Fix Here" [07:44] Fujitsu: No, but they offer another example. [07:44] I would say those would be Invalid [07:44] Won't Fix is "yes it's a bug but we're not going to do anything about it" [07:44] * persia doesn't like marking "Ship a driver for my mind control interface by default" "Invalid" just because nobody is going to work on it for a while. [07:44] Invalid is "well, that's not really a bug, kthnxbye" [07:45] I'd probably go with leaving it NEW and wishlist [07:45] but I'm not sure if that's right [07:45] LaserJock: Right. Like "well, I don't know how to use the admin tools", or "something crashed, and I don't know what" or "Pressing Ctrl-C in a terminal stopped my program" [07:45] ideally we should go to a 0 NEW state [07:45] Bugs aren't meant to remain at NEW, I don't think [07:46] Bugs are supposed to stop being new quickly: that means nobody looked, which doesn't give the right response. [07:46] maybe that could Confirmed Wishlist then [07:46] Won't Fix *should* be "we aren't going to do anything about it in Ubuntu" [07:46] It should be Won't Fix/Wishlist. [07:47] hmm [07:47] LaserJock: "Confirmed (whatever)" is what GNOME uses for upstream issues (along with an upstream task) [07:47] < mpt> This is why I wanted to call the status "Won't Fix *Here*" [07:47] Fujitsu: sometime when you've got nothing to do you think you could have a look over qcad bugs? [07:48] LaserJock: Sure, but I have very little time in the next ~month, due to final exams. [07:48] * persia cheers mpt, but thinks that there should still be a good way to differentiate "that's a useless bug" from "fixing that breaks too many other things, and we're not going to do so" [07:48] yeah [07:48] persia: Yeah, that'd be good. [07:48] I guess that's where the comment that goes along with the status change is important [07:49] LaserJock: True, but that's hard to search later. I'll never care about useless bug reports again. It may be worth investigating things that we're just not planning to do. [07:50] hmm [07:50] wouldn't those be Confirmed Wishlist though [07:50] For example, xaos/compiz. Since it works in OS X, it's probably a traceable issue, rather than a design issue. We're just not motivated enough, or have better uses for our time. [07:50] the "things that we're just no planning to do" [07:50] LaserJock: Triaged, even. [07:50] Oh, oops. [07:50] Read that the wrong way. [07:50] LaserJock: Like fixing xaos / compiz [07:50] hmm [07:51] I understand what you're saying [07:51] I would like to be as realistic as possible though [07:51] persia: Useless bugs could also be invalid? [07:51] if I have a Confirmed but that seems to indicate to users that we're going to do something about it [07:51] Sure. I just don't like "Won't Fix" for that sort of thing because it hides it by default, and someone interested might give up rather than fixing it. [07:52] pkern: Yes. In my ideal world of bug triage, all useless bugs are "Invalid" [07:52] whereas if I say "Won't Fix" but also "If you've got any patches, etc. feel free to reopen" [07:52] persia: And all of Kmos? :-P [07:52] it seems more realistic [07:52] LaserJock: Hm that "*I* won't fix", not "I am really against that" then, which is the notion of wontfix in Debian. ;) [07:53] LaserJock: Sure, but if you mark it "Won't fix", even with the best comment, the initial summary views will discourage people unless they're really extra motivated. [07:53] * persia has inherited the Debian sense of wontfix [07:53] hmm [07:53] we need like a "future" tag [07:53] well afk, getting taught some tutoring skills. [07:53] "maybe" [07:53] for things that might be something to look at when people have more time, etc. [07:53] As a modifier. [07:54] "maybe" "won't fix"... or... "maybe" "confirmed" [07:54] hmm, I'm not crazy about that [07:54] that sounds like we don't know what the heck we're talking about ;-) [07:54] LaserJock: "Deferred". Especially useful for bugs passed upstream. [07:55] ah, Deferred is more closely what I'm looking for [07:55] (Debian equivalent is "Forwarded", but that doesn't make sense in the context of Malone) [07:55] I just don't want a bazillion statuses [07:55] LaserJock: Could you officially request that? I think the distinction between "Deferred" and "Won't Fix" is important. [07:55] persia: Or "deferred until upstream fixes it, I won't bother" aka "upstream". :-P [07:56] Deferred is overloaded IMHO. [07:56] deferred until vs deferred to a person [07:56] :-P [07:56] pkern: I don't approve of maintainers that do that, but yes, that too. [07:56] so Deferred might be like "Won't Fix" that still shows up in bug listings? [07:57] s/overloaded/ambiguous/ [07:57] pkern: does it matter? [07:57] LaserJock: That sounds good to me. Also, "Deferred" should not be so tightly restricted, but should require an open task to another project. [07:57] pkern: "deferred until upstream fixes it, I won't bother" is what Won't Fix is meant to mean. [07:58] pkern: We're all working together: it's never deferred to a person (although in practice it might seem that way when the teams are small) [07:58] ah, actually we can merge them all into a new state called 'no' [07:58] * persia still doesn't like that meaning of "Won't Fix" [07:58] siretart: hi! [07:58] heyha LaserJock [07:59] away (again) [07:59] persia: so basically you want to shift "Won't Fix" to mean "umm, that's silly, no thanks" and have "Deferred" to mean "We aren't going to fix it here but we'll track upstream"? [08:00] LaserJock: With "Invalid" as "That report doesn't contain a description of a bug that will ever lead to a description" [08:00] nxvl: pong [08:00] err.. "...lead to a solution" [08:00] right "Not a Bug" [08:01] LaserJock: Well, some of them might be bugs, but we can't tell. For example "My computer crashed". [08:01] lucas: i was looking for you becauso of your post about mentors/REVU, but now i'm talking woth Signum, did you want to join us? [08:01] right, but you're saying "This is not a valid bug report" [08:01] for whatever reason [08:02] yes [08:02] where is it? [08:02] LaserJock: Ah. Yes to "Not a Bug Report", maybe to "Not a Bug". [08:02] lucas: #debian-mentors [08:02] lucas: @ oftc [08:02] Then there are attempts to change defaults, or whatever, which should be "Won't Fix". And big things that are definitely upstream things, which are "Deferred" or so. [08:03] Fujitsu: Right. [08:03] Probably need to talk to mpt about this next, or maybe kiko. [08:03] * persia often works on upstream things, sending patches up after testing in Ubuntu [08:03] ok, so I think we need to have definable differences between the statuses [08:04] bah, I gotta get to bed [08:04] Night. [08:04] persia: if you want maybe send an email to -motu outlining your thinking [08:04] ? [08:05] LaserJock: If it can't be understood: "Invalid". If it should not be fixed "Won't Fix". If nobody is going to work on it in the foreseeable future "Deferred" [08:05] right [08:05] those are our meanings [08:05] but we also need to translate that into LP terms, as in what statuses should show up in bug listings [08:05] LaserJock: Sure. I'll stick it on my list - probably be about 5 or 6 hours before I have time to check all the right resources and send out a good mail. [08:05] persia: k, thanks [08:06] I'll follow up in the morning [08:06] "Deferred" should show in the same way that "Confirmed" shows, but just clearly indicate that nothing will happen soon. [08:08] Hello, there used to be a packaging guide with Ubuntu documentation in Dapper [08:08] where is it ? [08:10] AnAnt: There's a transition underway. Try https://wiki.ubuntu.com/PackagingGuide for a snapshot of the migration underway. [08:21] thanks [08:29] good morning folks :) === asac_ is now known as asac [09:35] [09:36] * Fujitsu jumps. [09:37] * ion_ watches Fujitsy gently float back to the ground. [09:41] * Fujitsu lands with a thump. [09:41] * Fujitsu kicks promethium. [09:41] Every second build seems to stall for about 40 minutes before it actually does anything. [09:55] * Hobbsee kicks liferea [09:55] is it just that planet ubuntu hates the world now, or that something broke liferea, with the planet ubuntu feed? [09:56] Hobbsee: liferea don't work today with planet ubuntu [09:56] fair enough [09:56] what's the bug in? [09:57] Hobbsee: i don't know , the feed xlm don't work there is a parsing error on Line Number 20, Column 80: [09:57]