[00:21] hmm [00:22] looks like someone misspelled cache in the description of the packagekit packages :P === pgquiles__ is now known as pgquiles [01:53] * nhandler is away: Away === nhandler is now known as nhandler_AFK [02:13] * nhandler_AFK is back (gone 00:20:39) === nhandler_AFK is now known as nhandler [02:20] hmmm [02:21] opps sorry erong window [02:21] wrong* === asac_ is now known as asac [04:02] * nhandler is away: Away === nhandler is now known as nhandler_AFK === santiago-php is now known as santiago-ve [04:32] bah. jono's gone [04:33] given the time, I'm not surprised [04:35] well it was 7.36am local time of the ping [04:37] maybe he looked at the thread on ubuntu-devel-discuss & gave up in despair [04:37] poor nixternal, being a microvell shill [04:43] It was pretty ironic that he got singled out. [04:44] He dared to defend opensuse [04:44] That Mark Fink fellow does seem slightly irrational though [04:45] For some large definition of slightly, yes. [04:45] Could be a short definition too. "very" works well. [04:46] well, it provided some entertainment this morning when I sat down to read email :) [04:57] Hobbsee: ping? [04:58] ah, there he goes [05:00] Hobbsee was around just 25 minutes ago [05:01] man, I wonder what power that pointy stick of doom holds that she can summon people half a world away ;-) [05:01] It can even summon people from on vacation [05:01] heh [05:01] ajmitch: Never underestimate the power of the Long Pointy Stick [05:02] jono: pong [05:02] LaserJock: hah. it's very powerful. [05:02] Hobbsee: :) [05:02] * ScottK considers popcorn. [05:03] persia: it's certainly scary, that's for sure [05:04] ajmitch: it's been known to almost set someone's house on fire, too [05:04] uh oh [05:05] * ajmitch had better get home quick [05:09] * imbrandon hides his flamable house [05:10] imbrandon: you have an *in*flammible house? [05:11] nope the stick could bring its wrath down on it if wanted, thus i hid it [05:12] hello imbrandon [05:12] heya ajmitch [05:12] * imbrandon replaced his xbox with ubuntu+xbmc :) === joejaxx_ is now known as joejaxx === gaurdro_ is now known as gaurdro [06:58] good morning [07:01] hi dholbach [07:01] hi ajmitch [07:08] good morning dholbach [07:08] hi geser [07:13] morning! [07:13] dholbach: i was looking for you [07:14] hi nxvl [07:14] dholbach: did you have the gobby document we use on the Packaging Jam on Prague? [07:14] i going to run some packaging Jams here [07:14] and i want to merge some docs [07:14] nxvl: no I'm sorry - I didn't save it [07:14] to prepare my material [07:14] nxvl: https://wiki.ubuntu.com/PackagingGuide/HandsOn should be a good start though [07:14] mm [07:15] dholbach: yes, i was looking at this doc, i just want some more for the examples [07:15] nxvl: try fixing a bitesize bug [07:16] dholbach: yep, i will [07:16] if i have time [07:16] since it's a conference i have been invited i don't know how much time i have [07:16] i'm going to have some sleep [07:16] nxvl: I'm sure it's going to be great! :) [07:16] see you later! [07:17] dholbach: i hope! [07:17] * dholbach hugs nxvl [07:17] * nxvl HUGS dholbach back [07:36] <\sh> why nobody tells me, that I'm now a member of motu sru team? [07:37] \sh: Well, you're supposed to be subscribed to ubuntu-motu@ ... [07:37] <\sh> persia: it's monday morning...and I'm trying to catch up [07:37] <\sh> :) [08:04] <\sh> hmm.... [08:09] <\sh> I shouldn't read email in the morning... [08:12] anybody up for http://revu.tauware.de/details.py?package=libdc1394-22 [08:13] revu? [08:15] anybody? [08:15] :D [08:15] * theseinfeld feeling anxious today... [08:17] dholbach? :) [08:18] hiya theseinfeld [08:18] lool LucidFox Hobbsee persia? It should be quite ready by now... [08:18] howdy ho :) [08:18] how is your monday morning dholbach :) [08:19] theseinfeld: fine, but quite busy [08:19] theseinfeld: Why ping us? [08:19] theseinfeld: ? [08:19] damn, mine is quite quiet :) dholbach. Well, I guess I can wait for a better morning :) [08:20] You were reviewing the package earlier... Thought to give it a try since is there, dead since the feature freeze :) [08:20] hello theseinfeld [08:20] hell o LucidFox [08:20] I'll review your package when I have some free time - which I currently don't have, sorry [08:21] ok [08:21] * Hobbsee doesn't recall reviewing it, per se. [08:22] * theseinfeld might be wrong. He must recall the name from some other things... [08:23] theseinfeld: I still don't see the point of parallel source packages, especially for a new cycle. [08:23] it was well explained... [08:24] basically, to put it short, until we get all the rdeps to change to new one, we have to use both [08:24] there are big packages like mplayer and blender [08:25] I don't think I can get those guys to change the dependency to the new API in one increment :) [08:26] * theseinfeld wonders as persia [08:26] perisia, you in Tokyo? [08:26] * lool waves [08:27] theseinfeld: The point is that for intrepid, there's absolutely no value to releasing in the middle of a transition. Just push the updated API with the new binary package name, and rebuild all the rdepends. [08:27] For Hardy, it made some sense, as the package was being discussed late in the cycle. [08:28] it will not work === persia_ is now known as persia [08:28] the rdepends [08:28] to rebuild [08:28] it has a different API [08:28] ABI [08:28] everything is changed in the new package [08:28] well, almost [08:28] so... [08:28] theseinfeld: Right, so we port it. [08:29] I have no power to rebuild all the rdepends [08:29] :D [08:29] and the idea was to have them both working together [08:29] theseinfeld: As much as you have power to include a package. [08:29] the new one will work later also with the Juju stack in the kernel [08:29] Right, so let's just use the new one [08:29] * persia wants more juju [08:30] it is like saying lets just use KDE4 [08:30] you still can go one round in parallel [08:30] theseinfeld: Right, and for intrepid, we are saying that. [08:30] yes, persia, it was quite an effort to get it run in parallel [08:31] I guess they could be in parallel. I just don't see the point. [08:31] LOL [08:31] the point is that we cannot just take the old one yet [08:31] * Hobbsee beats persia with a stick. [08:31] OK. When you introduce a source package for a library with changed binary package names, the rdepends show on NBS. [08:31] persia: now you're green. stop it. go back to light blue. [08:32] Then, it just takes clearing NBS. [08:32] Hobbsee: I can be any color I want! [08:32] persia: no you can't! [08:32] * Hobbsee gets out the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ [08:32] theseinfeld: As proof of concept, try the rdepends builds in a PPA. I suspect that the failures ought be easy to clean. [08:33] Further, I'd rather consider them bugs. We still ship wx2.4, which is unfixable outside en_US, as a result of trying to have things in parallel. [08:33] \o/. persia is now light blue again. [08:33] * persia is *always* in awe of the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ [08:34] hehe [08:34] * theseinfeld is confused...so which colour is the package then? [08:35] theseinfeld: packages don't have colours, although they may be components of flavours [08:35] LOL [08:36] seriously, persia, I don't think there is going to be easy way with rdepends as the library is completely rewritten. I mean, there are different headers, different API, different functions, structures [08:36] I can try, and if it fails :) [08:36] then, what do I get? [08:37] persia, what is the price? Can I be yellow :) [08:37] interested in MOTU! [08:37] dave_: What do you like to do? [08:37] Beryl-Compiz [08:37] theseinfeld: Sure. It requires porting some apps. Why not do it between now and September? [08:38] dave_: Hmm. I didn't think we shipped that anymore. How about just compiz? [08:38] Have no Idea were to start! Kinda of a newbie. [08:39] I find Beryl easier to use. Have Issues getting compiz to work well! [08:39] dave_: Well, MOTU is resposible for the Universe and Multiverse repositories. With the help of about 300 other people (of which you could be one), we try to fix all the outstanding bugs, handle library transitions, ensure everything can install, and generally keep the software up-to-date. [08:39] persia, did you check that debian has it like this? [08:39] http://packages.debian.org/lenny/libdc1394-22 [08:40] https://wiki.ubuntu.com/MOTU/Contributing has some hints to get you started. Basically, pick a package, fix it, and get it into the repos. Then find another package. [08:40] Ok i'll give that a try thanks! [08:40] maybe dave_ could do the blender with libdc1394-22 [08:40] :D [08:40] theseinfeld: I didn't. I still don't agree it should be a separate source package. Further, if Debian has it like that, I don't see any point to something on REVU: hasn't it already been sync'd from Debian? [08:41] nope [08:41] it was not sync'ed as they got it a bit wrong, and since I couldn't get it through to them, I wanted to get through to ubuntu [08:42] * persia looks at https://launchpad.net/ubuntu/+source/libdc1394-22 , and doesn't trust that assertion. [08:42] Mind you, I still think it's wrong, but that argument is apparently already lost... [08:43] so, all my effort is gone the drains? [08:43] * theseinfeld is totally confussed now... [08:45] theseinfeld: Submit a patch against the current libdc1394-22 in intrepid. [08:47] where to? persia [08:48] theseinfeld: If you want to implement a change, submit a patch against the current package in intrepid. [08:48] to the libdc1394 project? [08:48] To a bug in launchpad against the libdc1394-22 source [08:48] all righty then [08:49] For best chance of success, submit the patch in debdiff format against an update, and subscribe the universe sponsors. [08:49] anyone can review a package on REVU? [08:49] devfil: Anyone can review a package, but not everyone can advocate. [08:51] Someone can review and advocate a package in REVU? [08:52] devfil: If you're seeking review, best to include the URL to the package, and the number of current advocates. [08:52] persia: I wrote bad [08:52] devfil: No worries :) [08:52] persia: is a new package [08:52] http://revu.ubuntuwire.com/details.py?package=galaxium [09:08] persia, can you help me with the debdiff bug reporting? [09:09] theseinfeld: What sort of help do you require? [09:09] ok [09:09] so, I am the maintainer in launchpad for the libdc1394 project which is related to the libdc1394 [09:09] now [09:10] report bug, what do I fill there to get into the right place for the source? [09:10] like, https://edge.launchpad.net/libdc1394/+filebug-advanced [09:10] You want soemthing like https://launchpad.net/ubuntu/+source/libdc1394-22/+filebug-advanced. [09:11] It's important that it gets filed against the Ubuntu project if you want to change something in Ubuntu, and important that you use the correct source name (as we have this split, especially designed to support lazy upstreams) [09:12] it won't be lazy if I am in [09:12] :D [09:12] do I need any tags there? [09:13] theseinfeld: Not specifically you, but all the various applications for whom porting will now not be RC for intrepid, as the old API is still available. [09:15] persia, you mean rdepends? [09:15] theseinfeld: precisely [09:16] apt-cache rdepends libdc1394-13, persia, to be more prcise, for the old library and not for the new -22 library [09:16] theseinfeld: It doesn't matter, as we have two source packages. I'd like to see libdc1394-13 dropped, end encourage anything towards that goal. [09:18] ok, so it is better to include every old rdepends to get people acknowledge the new upstream API [09:19] theseinfeld: For what? Now I'm afraid I've confused you. [09:19] for the tags in the bug report [09:19] :D [09:19] You don't need any tags (I think) [09:20] persia, do you agree that I should put all the rdepends pkgs ? [09:20] theseinfeld: For what? [09:20] OK [09:20] no, I got it all wrong [09:20] I asked if I need any tags and you answer something that left me think I should use the apps from rdepends [09:20] ;D [09:21] * theseinfeld too fast... [09:23] persia, check this out: https://bugs.edge.launchpad.net/ubuntu/+source/libdc1394-22/+bug/238492 [09:23] Launchpad bug 238492 in libdc1394-22 "Changes to allow better integration in Ubuntu" [Undecided,New] [09:23] morning everyone [09:26] theseinfeld: 1) Possible improvements: describe the specific improvements from using the changes in the bug description, 2) try to find something a little more "in-between" for a candidate (as that's a massive diff, and some to no clear benefit (e.g. CDBS) [09:28] persia, you mean I should add those? [09:29] theseinfeld: I was thinking more in terms of modification than addition, but it would increase the chances that such a change would be accepted. [09:35] added some comments [09:35] check again bug 238492 [09:35] Launchpad bug 238492 in libdc1394-22 "Changes to allow better integration in Ubuntu" [Undecided,New] https://launchpad.net/bugs/238492 [09:36] persia, have to go lunch... [09:36] persia see you after... === Hewus is now known as Hew [09:57] hi folks [09:58] <\sh> moins sistpoty|work [09:58] hi \sh [10:29] Someone can review galaxium package on REVU? http://revu.ubuntuwire.com/details.py?package=galaxium [10:43] Someone can review galaxium package on REVU? http://revu.ubuntuwire.com/details.py?package=galaxium [10:47] devfil: I'd encourage you not to ask about a given package more than once a day. [10:47] Some people use this as a criteria for packages to skip. [10:47] persia: ok [10:47] Also, be especially careful when there isn't much other traffic in the channel: some people mute parts/joins and so they see things as duplicate. [10:47] persia: I love and I hate you :P [10:49] sebner: Then I'm doing things correctly :) (cf. De Principatibus) [10:50] persia: hrhr. nexuiz \o/, but less time for school ^^ === gnomefre1k is now known as gnomefreak [11:20] persia, I am back... === ogra_ is now known as ogra === LucidFox_ is now known as LucidFox [12:26] <\sh> guys, is anyone familiar with ggz and especially ggz-config? === directhex is now known as directhex|work [13:16] Someone can review galaxium package on REVU? http://revu.ubuntuwire.com/details.py?package=galaxium [13:25] Hi guys, I'm an ubuntu enthusiast and would like to get involved with ubuntu as a contributing developer. I have read the docs on wiki.ubuntu.com and would like practical advice on skills to master (programming language(s), paradigms, e.t.c, - anything you deem useful/important) in order to get involved. What say ye? [13:26] x_dimitri: It really depends on what you want to do. [13:26] If you want to maintain packages, the best skills to develop are make and shell. [13:26] Beyond that familiarity with any and all programming languages is beneficial. [13:27] As is an understanding of how the various bits fit together into the whole. [13:28] As a way to get started, I'd recommend looking through triaged bugs. When you find one you understand, develop a solution. After a few of these, the answers you get here, and the things you research towards a solution will probably help guide your next bug. [13:29] persia: ok... [13:29] x_dimitri: Good luck, and please ask if you have any questions. We're generally glad to help, although more likely to provide pointers to things than actually explain them. [13:30] persia: yup, I noticed that [13:31] I guess go through the wiki again, but what I seem to understand so far, is that bug reporting is the only way in... i.e. as an Ubuntero.. [13:31] is that correct? [13:32] you can report bugs, fix bugs, update packages, etc [13:35] joaopinto: it appears there's different levels of involvement: ubuntero, motu, e.t.c [13:38] x_dimitri: There are different levels of involvement, but aside from "Ubuntero", all are granted as recognition of past work done. [13:38] The first step is to declare yourself bound by the code of conduct, and beholden to the Community Council (Ubuntero). [13:38] That done, you are welcome to do anything, and if you do it well, your work will become part of Ubuntu. [13:38] With a body of well-done work, you may be granted additional roles or titles. [13:42] persia: ok, thank you [13:43] How is that declaration done? I didn't find any web-based means to do this (a form maybe). There was a document that was meant to be downloaded... Could you point me in the right direction? [13:44] x_dimitri: Download and sign the Code of Conduct from your launchpad account. Be sure that you take care to keep your GPG key once you've done so, as GPG is used for authentication in a number of places. [13:48] persia: ok, thank you. [13:48] * ScottK suggests reading it before you sign it. [13:48] ;-) [13:49] ScottK: :-) [13:55] I fixed bug 198292. Would anyone like to sponsor it as an update? I posted the debdiff in launchpad. [13:55] Launchpad bug 198292 in motion "Hardy upgrade - motion halts upgrade" [Medium,Triaged] https://launchpad.net/bugs/198292 [14:03] mouz: Generally it's best practice to attach debdiffs for both the current development release and an SRU candidate. I'd recommend ubuntu0.1 for hardy and ubuntu1 for intrepid: beyond that the fix ought be essentially the same. [14:03] Also, motu-sry has yet to indicate whether this patch is acceptable for upload. Until that happens, it will not be uploaded to hardy-proposed. [14:10] ScottK: clamav 0.93.1 is out ... [14:14] persia: ok thanks. I will create those. [14:18] if I do "apt-get build-dep firefox", and then later want to remove those build-deps, what apt incantation can i use? [14:24] popey: deborphan? [14:24] there is no apt removal for build-deps [14:24] <\sh> grmpf.. [14:25] <\sh> has anyone problems with mono on intrepid? [14:25] <\sh> looks like mono is somehow b0rked [14:26] hmm, thats a shame [14:30] popey: i have seen them show up in autoremove but i dont remember what triggers it [14:31] \sh: mono is used system wide can you give an example? [14:32] popey: pbuilder IIRC removes them once package is done but i dont use pbuilder i use chroots [14:32] problem is if you used neither, you have lots of build deps kicking around [14:32] and no way to identify / remove them easily [14:33] maybe removing *.dev === directhex|work is now known as directhex [14:33] <\sh> gnomefreak: I'm trying to build muine [14:33] <\sh> gnomefreak: and it failes because of not installable b-ds [14:33] but that is a long shot, and you should always use one or the other when building packages since there is no easy way to remove the clutter [14:34] * \sh uses sbuild , as it's used by our buildds :) [14:34] \sh: i havent tried to build anything with mono since most if not all mozilla apps dont use it [14:35] * nhandler_AFK is back (gone 10:32:19) === nhandler_AFK is now known as nhandler [14:37] popey: A recipe that works for me is to always use aptitude to install anything I want, and make everything else as automatically installed. I only use apt-get for build-dep, so everything apt-get installed is automatically marked for removal next time I run aptitude. [14:37] hmm [14:37] thats an idea === _neversfelde is now known as neversfelde [14:51] leonel: I saw. Am about to look to see if there are any security fixes. === directhex is now known as directhex|work === directhex|work is now known as directhex [14:53] nhandler: please turn off that away message [14:54] Hobbsee, I think I disabled it now. It was an xchat setting [14:54] nhandler: yeah, i realised. [14:54] nhandler: thanks [14:55] Hobbsee, np === emgent_ is now known as emgent [15:15] leonel: One security fix. Do you have time to work on it? [15:18] ScottK: any cve ?? [15:18] leonel: Not that I can find. [15:19] ok I'll check that [15:19] Changelog says fix possible memory access and they committed it at the same time as the release, so it's a security fix. [15:20] libclamav/petite.c: fix possible invalid memory access (bb#1000) [15:20] Reported by Damian Put <-- is this ?? [15:21] Yes. [15:21] The bug is also marked private in their bugzilla. [15:21] ScottK: ok I'll check it and see any diff with 0.93 [15:21] leonel: I've looked at the source already [15:22] leonel: If you diff libclamav/petite.c between 0.93 and 0.93.1 you'll get a diff that looks like it will apply cleanly to our 0.92.1 package. [15:22] perfect ! [15:23] ScottK: I'll start workin on in in 2 hours it's ok with you ?? [15:24] leonel: Yes. [15:31] leonel: I'll file a bug for you to work on. [15:31] ScottK: ok [15:38] leonel: Bug #238575 - The diff is in the bug, it just needs to be packages for each release. [15:38] Launchpad bug 238575 in clamav "Possible invalid memory access in versions before 0.93.1" [Undecided,New] https://launchpad.net/bugs/238575 [15:38] ScottK: Thanks .. [15:38] I start in 2hours [15:39] Great. I'm assigning it to you .... === nhandler is now known as nhandler_AFK === nhandler_AFK is now known as nhandler [16:10] slangasek: w00t [16:10] slangasek: Any idea why virtualbox-ose-modules is built against -17 in intrepid instead of -16? [16:11] I'm adding lpia support to it, but it wont build for me as there's no -17 kernel package in intrepid [16:12] slangasek: Also, I'd be tempted to do the same in hardy-proposed if you don't mind :) [16:20] any idea when soren will be on? PS [16:20] er, dang, wrong channel. === huats is now known as TartePoireauxCra === TartePoireauxCra is now known as huats [16:24] TartePoireauxCra? TartePoireauxGras!? [16:25] TartePoireauxCravattes! [16:31] * ScottK doesn't know what norsetto is one, but he might like to have some of it. [16:32] ScottK: neah, I don't think you will like my version, huats one might be better [16:32] * Hobbsee force feeds ScottK automatix. [16:32] (3) [16:34] norsetto: :) [16:34] sorry guys for the change of nick :) [16:35] and it was TartePoireauxCrabe [16:35] :) [16:38] huats!!! [16:38] norsetto !!! [16:40] * ScottK gets ill and spews === tacone1 is now known as tacone [17:24] Heya gang [17:27] lool: er, no, I have no idea of anything wrt virtualbox-ose-modules in intrepid [17:29] slangasek: Ok, ogra hinted me at you [17:29] slangasek: Nevermind then; thanks [17:30] lool, i thought i saw a conversation about vbox last week, apparently wrongly, sorry [17:30] sure, I had a conversation with blueyed about vbox in hardy-proposed... [17:31] yeah, thats what i meant [17:31] lool was asking why he didnt do a -19 instead [17:32] I'll go and fix vbox in intrepid then [17:32] * sistpoty|work heads home... cya [17:32] well, neither -17 nor -19 is present in intrepid currently [17:33] indeed [17:33] so I don't know what the upload in intrepid is about at all [17:33] enabling lpia [17:33] we cant use vbox for lpia at 800x480 bwithout the vbox video driver which is in the guest modules [17:33] what's so special about lpia? is it different from i386? [17:34] yes [17:34] ogra: blueyed uploaded a new version to intrepid to move from -16 to -17 [17:34] But -17 never made it to intrepid AFAIK [17:34] lool, right and currently we have -19 [17:34] I noticed while adding lpia that it simply wouldn't build ATM [17:34] ogra: That's hardy; intrepid still has -16 I think [17:34] you need to add lpia to the configure script [17:34] its not an accepted arch without that hack [17:36] which is all my patch does, changing control everywhere from s/i386/i386 lpia/ and adding lpia to the x86 list of arches [17:36] ogra: I'm interested in that last part [17:36] I also updated control and rules [17:37] I'm looking at configure ATM, I also had a look at the modules/virtualbox-ose Makefile, but I didn't get where the arches came from [17:37] (yet :) [17:40] lool, line 254 [17:40] must be: i[3456789]86|x86|i86pc|lpia) [17:40] trivial :) [17:40] the first part of that regex is pretty optimistic *grin* [17:41] ogra: Well I checked this part and connected to my lpia Q1 and uname -m would return i686 [17:41] dpkg hands over lpia i think [17:41] during build [17:41] ogra: BUILD_CPU=`uname -m` 2 lines above? [17:42] not sure which source you are using there [17:42] mine as [17:42] has [17:42] BUILD_CPU=`dpkg --print-architecture` [17:42] ogra: aha [17:42] I had my pbuilder on a gutsy install that gutsy got upgraded to hardy .. the pbuilder install ... was moved to hardy or is still for gutsy ??? [17:42] (not added by me) [17:42] ogra: I'm looking at 1.5.6-dfsg-6ubuntu1 [17:43] hmm [17:43] same here [17:43] from april 9 [17:43] ogra: Oh, yours is probably patched [17:43] ogra: Got it now [17:44] lala [17:45] ogra: IMO it should be using dpkg-architecture -qDEB_HOST_GNU_CPU instead of dpkg --architecture, what do you think? [17:45] sounds good [17:49] what the hell ass balls [17:49] if X gets killed you cannot log in again until you reboot [17:49] #define killed [17:50] rm -rf /tmp doesn't fix it, neither does killall $(ps -e u | grep id -un | awk '{print $2}') [17:50] laga: ctrl+alt+backspace, which happens fairly often by accident through confusion [17:50] i.e. switching virtual desktops, deciding to backspace over a character [17:51] I tried killing all the user's processes and removing all temporary files owned by the user to no end [17:51] doesnt happen here [17:52] laga: ctrl+alt+bs doesn't kill X there? [17:53] it does, but i can still login afterwards [17:53] doesn't let me in, I get a blank desktop with a white box in the top left with nothing in it [17:55] also virtualbox seems to be unsupported <_< [17:55] its modules are in main for an old kernel, universe for a newer kernel, and not present for current o_o [17:55] oh, I'm on proposed, ok [17:57] the updated kernel (2.6.24-18, hardy-updates) still has a matching universe virtualbox driver though, instead of main [17:57] though, the 2.6.24-17 driver says it's in main but maintained by Ubuntu MOTU [18:20] persia: about bug 198292. The version queued for the development release is patched in Debian for the same bug. So my reasoning is: it need not be patched for Ubuntu (for this bug). Am I right? Does that mean posting a debdiff for 1ubuntu0.1 suffices, or is there still a need for 2ubuntu1 then? [18:20] Launchpad bug 198292 in motion "Hardy upgrade - motion halts upgrade" [Medium,Triaged] https://launchpad.net/bugs/198292 [18:28] kees: so I was looking at getting mutt to help me with bug triage, and came acroos 'pipe-message'-- have you used it much with macros? [18:28] jdstrand: to some extent, yeah. I think the USN builder, for example, uses it. [18:29] kees: actually it does not [18:29] oh? [18:29] kees: I was using it as an example, and then came across something that would be better [18:29] ah, you're right, i use "editor" to do the evilness [18:29] kees: with usn builder, you use a trick with the set editor [18:29] kees: check this out: [18:30] macro index \cB "~/ubuntu/security/scripts/lp-status" [18:30] cool, yeah [18:30] kees: that macro pipes the message (or tagged messages) to that command [18:30] I have some really old stuff: [18:30] macro index \cu "unset wait_key\nurlview\nset wait_key\n" [18:30] kees: yeah [18:30] I think bdmurray has a ton of these kinds of things for doing his triage-via-email stuff [18:32] kees: what is nice is that I have a script called 'bug-status.py', so I then wrote lp-status to be http://paste.ubuntu.com/18838/ [18:33] kees: this then outputs various stuff in mutt that I can use to start processing things [18:33] kees: anyhoo-- I knew you liked 'stupid mutt tricks' so thought I'd pass it along [18:34] nice, yeah, thanks :) [18:41] Hey guys are we going to to have the RC2 of firefox on Hardy or you guys waiting for the final? === pgquiles__ is now known as pgquiles [19:15] vbabiy-laptop: #ubuntu-mozillateam would be a more likely place to get an answer to that question. [19:21] thanks ScottK === Spec[x] is now known as Spec === blueyed_ is now known as blueyed [19:50] kees: do you have a script for approving 'nominate for release' bugs? [19:50] * jdstrand likes to glom onto kees' scripts [19:53] Is it really necessary to add the "patch" tag to a bug that you patch? Or is it sufficient to just check the box that says, "This attachment is a patch"? === Czessi__ is now known as Czessi [20:14] nhandler: I think the patch tag is just to make searching easier. [20:16] jpds, Does that mean that it isn't a requirement. If that is the case, someone should update https://wiki.ubuntu.com/MOTU/Contributing. [20:18] nhandler: I think you may wish to tag it, yeah [20:18] jpds, Ok, thanks. [20:37] what parameters i need to use in lintian to know a package is compilant? [20:38] and how can i open a itp bug? [20:40]