[00:05] is it possible to get packages added to the intrepid freeze at any point (except the next freeze) during intreoids life span? [00:05] *intrepids [00:05] or the life span of any release for that matter [00:05] wait.. sorry, stupid question [00:05] ignore that === ScottK-vacation is now known as ScottK [00:24] superm1: Oops. Hadn't even thought about that. Much better. [00:36] persia, i sent the collective of our patches to the upstream mailing list. they're pretty slow at responding though, so i wouldnt expect to see them accepted upstream before they're determined at our level [00:37] superm1: Thanks! I'm not worried about when they accept/reject them, but getting them there should make this easier for jaunty. [00:37] persia, ack [01:39] I heard people use debdiff to see differences between uploads to mentors... [01:40] But if I read the man-page it talks about changed files in the package.. How to see changes in the debian dir with debdiff? [01:41] Elbrus: You can use filterdiff to extract only the changes in the debian/ directory. For packages where patches are applied at build-time, it's a good idea to review changes outside debian/ to make sure there aren't any. For packages that apply patches at packaging-time, it's important to also inspect the changes outside debian/ to see the effects of these patches. [01:46] persia: aren't patches always unapplied (that is reversed) on packaging-time? At least with pdebuild? [01:46] Elbrus: Well, sorta, but not necessarily. [01:47] Essentially, all the patches live in the diff.gz, so no matter how patches are applied in a package, it is true that patches are applied at build time, just because the package is unpacked. [01:48] Some people use something like quilt, or dpatch, or cdbs's simple-patchsys to manage their patches. In this case, the patches are applied from the diff.gz into debian/patches/* or ./patches/*, and then later applied against the code at build-time. [01:48] persia: so I want to see the differences in the diff.gz file, but how to do that in a sensible sense (if it is large)? [01:49] Other people use other techniques to manage patches (e.g. layered VCS), and so the patches apply to the sources directly in the diff.gz [01:49] persia, Marcel (whom just commented on that bug) is upstream. his comment makes this whole problem most curious [01:49] persia: the package I am now talking about uses quilt, but I did not come up with it, but I need a bug patched to build my package [01:50] Elbrus: lsdiff, debdiff, filterdiff, and similar help, but really it's a matter of either reading all the changes, or determining that you don't have to read some somehow (this is often dangerous) [01:50] Elbrus: If it uses quilt, you oughtn't see any changes outside debian/ but also there shouldn't be any changes outside debian/ : if there are, quilt isn't being used in the typical fashion. [01:51] persia: I do want to see the difference, to check if I ONLY changed the debian/patches directory [01:51] Elbrus: Right. debdiff foo.dsc bar.dsc | lsdiff will show you the files you changes. [01:51] s/s\./d./ [01:52] superm1: OK. In that case we simply don't know why it's broken. Have you heard anything else to indicate any way it could be fixed for 0.28? [01:53] persia, well we've *tried* it with 0.28 [01:53] persia, and it didn't work [01:54] superm1: Right. 0.28 is broken. 1.5 works. On the other hand, based on what Marcel says, I'm not sure that we've identified the reason. It may be possible to write a patch that fixes 0.28. [01:55] On the other hand, I think the general state of 1.5 is better than the general state of 0.28 at this point: it's a matter of time to track down the issue (I *much* prefer crashes to this sort of thing: nice map), and fix it vs. the risk of BlueZ 4.x in intrepid. [01:56] If you heard something to indicate not only that the problem has nothing to do with btusb, but that the problem is known, or there is a solution, I think 0.28 is the safer choice. If you've not heard anything, then 1.5 at least has the benefit of working. [01:56] persia, well the question then is what is the risk of bluez 4.x at this point [01:57] that's not elaborated on the bug right now [01:57] Well, it's a new version that hasn't gotten much testing, vs a version that has gotten a bunch of testing (and doesn't happen to work). [01:58] persia, well given that i've not seen reports of this failed keyboard pairing - yet we both saw it immediately, i'm not so sure that its gotten a much of testing... [01:58] persia, but "theoretically" has received more testing :) [01:58] We don't know what bugs may lurk. It works better for you and I and crevette and mlind, but that's not exactly widespread testing. [01:58] right [01:58] Right :) [01:59] Personally, I don't think anyone really tested 3.x in intrepid properly, except for a bunch of us looking at Symbian obex testing back in June. [01:59] * Hobbsee waves [01:59] from coming into this late, it looks like the bluetooth stack isn't properly triaged much either [01:59] there's still bugs from feisty marked as "New" [02:00] No. slytherin has been trying to keep track since mid-Hardy, but nobody has really been on top of it. [02:03] superm1, yup, thats a problem with public bug trackers [02:10] csilk: No, rather it's an issue when nobody is watching a subsystem. Having it public doesn't automatically mean people don't track things. [02:11] persia, having it public means you get alot of reports and there is never enough people to triage effectivelt never mind fix [02:11] *effectively [02:12] csilk: I disagree. Find me open untriaged bugs against wildmidi or freqtweak :) It's a matter of having someone who cares, not about whether it's public. [02:19] persia, when its public there will always be a report that no one cares about [02:20] csilk: I disagree, but it's not worth arguing about. It's just that some people care for some packages, and when that happens, it works. [02:21] sounds about write, my intention over the next 3 weeks is to get stuck in with some of the less cared about bugs and hack away at some fixes [02:21] university workload is really kicking my arse right now though [02:21] ***right [02:33] persia, quick question, does feature freeze also mean bugfix freeze? [02:34] i'm not talking about system critical bugs here of course, i'm talking about old-ish bugs that havent really been looked at in any detail yet [02:35] csilk: i don't think so? [02:35] csilk: Depends on the bugs. If it's broken, you can fix it. If it ought to include support for freon collection devices, you'll want to wait for Jaunty. [02:37] ok [03:18] anyone looking for a bug to fix? === zpowers is now known as Milyardo [03:48] persia, well unfortunately can't test the dist-upgrade still. update-manager wants to have all it's packages authenticated for some silly reason. I'll have to poke more in update-manager code to find out how to disable that i think [04:07] good morning [04:31] Good morning dholbach [04:33] hi nhandler === bddebian2 is now known as bddebian [05:17] I just filed bug 275688 with patch because it would allow my to build a new package WinFF (bug 172804). Would anybody be interested in syncing with Debian? [05:17] Launchpad bug 275688 in fpc "Please sync fpc 2.2.2-3 (universe) with patch from bug #260464 and lazarus 0.9.24-0-12 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/275688 [05:17] Launchpad bug 172804 in ubuntu "[needs-packaging] winff - GUI ffmpeg batch video converter" [Wishlist,In progress] https://launchpad.net/bugs/172804 [05:19] WinFF is a graphical user interface for FFmpeg. [05:36] dholbach: wow, this should be a record, what time is it in berlin? 5 am? [05:36] dholbach: good morning! [05:37] nxvl: now it's 6:38 [05:37] any MOTU Release around? [05:38] dholbach: but ypu are here since 5 [05:38] nxvl: yeah, didn't sleep so well, so I thought "why not get up early and get some work done?" :) [05:39] crazy! [05:39] heh, i always do the same "why not stay until late and get some work done" [05:39] but now i use to sleep well [05:39] :D [05:40] LaserJock: when you have so much fun at work it starts to be normal [05:40] :D [05:41] does anybody know what the current FF status is regarding upstream bug fix only releases? [05:41] LaserJock: file a bug and upload it, iirc. [06:24] Good morning. [06:27] james_w: Congratulations! === macd_ is now known as macd [07:51] any idea why does an opensuse user reports a problem on launchpad? bug #275699 [07:52] Launchpad bug 275699 in bluez-utils "HFP Testing " [Undecided,New] https://launchpad.net/bugs/275699 [07:54] james_w: welcome, mate! :) [08:05] james_w: congratulations! [08:06] james_w: Congratulations. :-) [08:21] Hobbsee: I see you've noticed that anjuta needs more than just a rebuild :) [08:54] RAOF: Are forum people really thick enough to miss three bold requests for their Xorg log, or am I missing something? [08:54] I wonder who is maintaining the Anjuta IDE package? [08:55] Nobody in particular, but it is known that it is broken. [08:55] wgrant: Yes. Forum people are thick enough to miss three bold requests for their Xorg log. [08:55] RAOF: Sigh. [08:56] And then there's that guy complaining that monitors aren't detected properly, and then refusing to report bugs to get quirks added... [08:56] Lovely, lovely. [08:56] It seems that many forum denizens are not particularly interested in helping, but much more in bitching. [08:57] Admittedly it might be a good idea to have an "Add resolution" button in gnome-display-properties, but still... [08:57] There's perhaps something to those complaints, though; we'll likely never inhabit a world where all monitors report correct DDC values. Screen Resolution should probably have some sort of 'advanced' tab for adding extra resolutions. [08:57] Heh. [08:58] Indeed. [08:58] xrandr exposes it, so it can't be impossible. [08:58] It'd actually be pretty easy, I think. [08:58] As would I. [08:58] You'd call out to xrd or whatever it is that calculates a modeline, pipe that to xrandr, and hope the monitor doesn't explode. [08:58] It might also be a good idea to scrape the hwdb data out of LP. [08:59] Oh, _that's_ where the hardware information database goes? [08:59] It is. === dholbach_ is now known as dholbach [08:59] It's also exposed, but the pages aren't linked. [08:59] http://launchpad.net/~wgrant/+hwdb-submissions [09:00] I can't work out if there's a full index under /+hwdb, unfortunately... [09:06] Woah! Crazy. There's my laptop. [09:12] HOla motus! [09:17] morning everyone [09:18] morning huats :) [09:19] huats, didrocks hi !:p [09:20] hey DKcross [09:20] plop didrocks [09:20] :) [09:20] huats, hey!:p [09:20] speak spanish ? [09:21] just a little [09:21] but there are lots of guys here who speak spanish [09:21] nxvl, by instance [09:21] :) [09:21] (and hello by the way nicolas) [09:32] huats, sorry [09:33] i go..:$ my english isnt very well.. [09:33] goodbye man [09:33] talk soon [09:33] james_w: congratulations !!! you really really deserve it :) [09:34] thanks huats [09:41] grats james_w! [10:01] bobbo: why did your upload close #273586 ? [10:05] persia: hi, could I be added to u-u-s please? [10:06] james_w: Indeed. Congratulations. [10:06] thank you === Ng_ is now known as Ng [10:28] coo, james_w gets to be my personal pet sponsor for universe. neato! [10:29] * james_w runs [10:29] if only i worked on packages in universe [10:29] james_w: Never fear - directhex's main targets are mono, which you can't sponsor. You're safe! [10:30] Also, grats. [10:30] thanks [10:44] We can still do FFE's for universe stuff - right? [10:48] aren't we in beta freeze? i forget the timetable [10:50] Beta freeze doesn't practically affect universe. [10:58] Except that uploads need a manual shove (which doesn't require any authorisation, just an archive admin to press the button), right? [11:11] anyone willing to test DVD playing with totem-gstreamer with a fix backported from gstreamer CVS? I don't have access to a DVD drive right now. [11:11] this is on intrepid [11:12] RAOF: yeah. damn. [11:12] RAOF: did you want to fix it? :) [11:17] Hobbsee: Not particularly; autofoo patching isn't my idea of a good time. [11:17] :) [11:17] slytherin: Yeah, I'll bite. [11:18] RAOF: give me 5 minutes. The build has failed. Trying to debug. [11:19] slytherin: Cool. Are you considering updating to the new core & base releases? Looks like they should be done in a couple of days. [11:19] slytherin: Or are you just cherrypicking a couple of patches to fix dvd subpicture autoplugging? [11:20] RAOF: Chery picked a fix so that it will go in beta. [11:20] RAOF: I am not a core dev. seb128 said he will look into updates after beta [11:20] Cool. [11:21] Yeah, seb's likely to be on top of the soon-to-be gstreamer releases, if they're worth breaking freeze for. [11:23] what is meaning of this - Architecture: @linux@ [11:23] james_w: Congratulations. [11:23] thanks ScottK [11:23] slytherin: Some context? [11:23] slytherin: The meaning seems pretty obvious - the architecture is Linux :) [11:24] RAOF: gst-plugins-base also build alsa plugin. But looks liek @linux@ in control.in file is not getting replaced. And hence build failure. [11:25] Oh, that's debian/control autogeneration madness? [11:26] huats: but, does it actually work? [11:26] RAOF: Yes. Any idea how could I fix it? [11:27] Not really; autogeneration is very much a per-package thing, because it's heavily discouraged in general. [11:27] Hobbsee: the fact that the new anjuta does not depend on libgdl-gnome-1-0 is true [11:27] huats: well, even the rebuild did that. I asked if it ran. [11:27] huats: i added a debian bug to that bug. [11:28] Hobbsee: it was working on my computer [11:28] huats: good. [11:28] but I still need to work on it [11:29] Err.. Beta has affected several parts of universe since hardy. Please be careful when uploading anything that is a reverse dependency of any of the binary packages of xubuntu-meta, mythbuntu-meta, ubuntustudio-meta, or mobile-meta. [11:29] (and I would rather wait on the debian sync, since I have talked with the DM and the next version is about to be available) [11:30] huats: fair enough. I just saw the grave bug in debian, and didn't know if you'd seen it [11:30] :) [11:30] no pb :) [11:32] right now, the libgdl update had some other side effects... I am trying to work on that and after I ping the DM again... [11:38] RAOF: it might be the case that debhelper 7.x provides appropriate substitution for @linux@ [11:57] RAOF: ping [12:18] hi folks [12:22] sistpoty|work: heys! [12:22] hi stefanlsd [12:23] hey sistpoty|work! how are you? [12:23] sistpoty|work: i wanted to ask, when you have some time to maybe read something I wrote about symbols, and just check i am on the right track... [12:23] hi siretart.. I'm fine, how about you? [12:24] stefanlsd: if it's not too long, just show it to me ;) [12:25] sistpoty|work: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols [12:25] thanks Laney [12:25] james_w: Hm? [12:25] (and congrats) [12:26] sistpoty|work: I'm doing okay [12:26] Laney: you provided my first upload [12:26] james_w: The Geordi rebuild? [12:26] aye [12:26] \o/ [12:26] sistpoty|work: might be a bit long. heh. seems like the symbol stuff isnt that well known. [12:26] assuming I didn't mess it up :-) [12:26] ;) [12:27] (I don't mind if you accidently stole the credit, apparently that's easy to do if you miss some flag) [12:28] http://paste.ubuntu.com/52058/ [12:28] james_w: do you have a work plan for the MOTU school stuff? Like, how could we get involved etc? [12:28] \o [12:28] * Laney high fives james_w [12:29] * james_w high fives Laney [12:29] stefanlsd: no, I don't really. You would like to run sessions? [12:32] stefanlsd: I must admit, that I haven't used dpkg-gensymbols yet myself, but what you've written looks quite good [12:32] james_w: i would like to get involved. just not sure how. i enjoy teaching in general. writing docs about something etc. [12:33] stefanlsd: however the main use for symbol files afaict is in debian to ease the transition from unstable to testing, so it's not that relevant for ubuntu [12:34] sistpoty|work: Don't we gain the same benefit of proper dependency tracking in terms of determining if everything is ready for release? [12:34] persia: hm? [12:35] stefanlsd: cool, if you have a session you would like to run then we can set it up easily. [12:35] sistpoty|work: While we don't have an unstable->testing model, I'd think that the results of the symbol files would still improve the accuracy of our package relationships, so we could presumably better identify packages that needed adjustment prior to release. [12:36] Hi [12:36] hi geser [12:36] Hi sistpoty|work [12:36] persia: well, the only real benefit I can see is that symbol files means that someone touching a library *must* check the abi [12:37] persia: others than that, I see no real benefit [12:37] sistpoty|work: i guess its also useful to see if the ABI has remove anything, and then upstream can be notified and asked to please not break the ABI [12:37] sistpoty|work: Right, which strikes me as a *huge* benefit when it comes to our haphazard manner of syncing some stuff from experimental, some from unstable, some from testing, pulling stuff from upstream, and throwing it all together. [12:38] sistpoty|work: it can also help us determine that we can move the ABI lib forward (by depends) and we would know that the functionality is actually still there, or why we cant... [12:39] but it seems kinda like the use of symbol files etc is optional, and not many packages do it.. [12:39] stefanlsd: yes, but you should do this when maintaining a library anyway ;) [12:42] stefanlsd: A large part of that is because symbol files are a relatively recent innovation. [12:43] broonie: yeah. do you know if its a debian lib standard now? im not sure. i think not many people know how to work with them also. (i didnt at all, and now i know a little). [12:43] It's certainly best practice. [12:44] broonie: ok, cool. so maybe we'll be seeing more of them... [12:44] i guess i'll see if i can link my doc somewhere better so devs / motu's can find it better... [12:44] mr_pouit: you seem to be in charge about ffmpeg in medibuntu. please contact me before you do the next merge. [12:45] sistpoty|work: As well as testing transitions the symbol files are also there to help make upgrades, especially if someone's doing a partial upgrade. [12:46] sistpoty|work: They don't *force* ABI checks, sadly (they only check for changed symbol names, not for anything else). [12:47] broonie: yeah, that's true, but I must admit that even that alone is s.th. which I've seen a few library maintainers not doing :/ [12:48] checking for changed symbol names is a big step forward, and may well hit some percentage of ABI changes. partial upgrades are more of a boon for developers than target users, who are expected to (but may not) upgrade from release to release. [12:49] persia: indeed, but practically speaking the most common partial upgrade case is pulling in some core tools first so that the rest of the upgrade goes more smoothly. [12:50] broonie: True. It's the testing to try to make that never required for Ubuntu Release -> Ubuntu Release that is supposed to obviate that, but there's certainly *lots* of people who track development, or use alphas & betas. [12:52] Plus you have your upgrade manager tool for desktop users which can do things like that with nasty tricks if it has to. [12:54] The other thing symbol files can help spot is unneeded dependencies - if no version is identified then the dep isn't needed. [12:55] That's something I'd like to see. I'm unhappy with the volume of packages some packages pull, and don't need. [13:44] Hi [13:44] james_w: congrats! [13:44] thanks RainCT [13:54] RainCT: Do you know of any reason for lines 110-113 in pbuilder-dist.new in u-d-t? They seem to break stuff [13:57] Laney: that self.base should be a self.proxy o_O [13:57] haha [13:58] RainCT: That doesn't seem to be needed anyway. I'm behind a proxy and with just commenting out those lines it still works fine [13:59] Laney: I guess pbuilder will already know about your proxy if you created the tgz with the bash pbuilder-dist [13:59] I didn't [13:59] pbuilder seems to detect it fine itself [14:00] oh, I'll delete it then [14:00] Laney: is pbuilder-dist.new working fine for you (beside that)? [14:02] RainCT: I nailed another bug (bzr merge lp:~laney/ubuntu-dev-tools/dev) [14:02] With the code in that branch it's running great [14:04] doh, accidently added an unrelated line in my latest commit :( [14:04] (still needed though) [14:19] Laney: merged, thanks :) [15:18] Can I tell distutils not to place my data_files in /usr/foo but in /etc/foo? [15:20] amikrop: You don't want data_files in /etc. I forget what things are to be called that go there, but it's a different name. [15:47] Adri2000: sorry I didnt have time to change the debdiff and it was uploaded earlier. I have re-opened the bug. [15:47] james_w: thanks for all the sponsoring today :) [15:47] bobbo: no problem, really glad I am able to help :-) [15:48] bobbo: have you had a chance to look at bzr? [15:49] james_w: not yet, but i'll have a look today or tomorrow. I'll send you an email with a list of things I think look important when I have a look at it [15:49] bobbo: great, thanks [15:50] james_w: Congrats. I thought you were MOTU ages ago. :) [15:50] thanks bddebian, I was it's been like 8 hours now, that's ages [15:54] Hi. Is there any way to install recommends for a package after the package has already been installed (with --no-recommends)? [15:54] Err, --no-install-recommends, rather... [15:56] fbond: sudo apt-get install --fix-policy --install-recommends [15:56] (will get all uninstalled recommends) [15:56] Laney: Hm. I really only want to install recommends for certain (already installed) packages. [15:56] Maybe if I name those packages for that command? [15:56] possily [15:56] b^ [15:58] otherwise known as the "where's my tomboy gone?" fix for lenny [16:01] hello! is there a guide for making patches in the Ubuntu kosher way? I tried diff -crB but it isn't giving me something comparable to the original patch I was working with [16:02] mrooney: debdiff old.dsc new.dsc [16:04] Laney: oh my then I am going about it all wrong [16:04] I was just trying to generate a patch from the source folders [16:05] that is how the upstream patch was, it seems like I should keep it that way for them to consider it [16:05] specifically bug 42686 [16:05] Launchpad bug 42686 in rhythmbox "audioscrobbler password saved configuration file" [Medium,In progress] https://launchpad.net/bugs/42686 [16:08] mrooney: Are you using an SVN copy of rhythmbox? [16:09] mrooney: diff -urN is the common way used to generate patches, although the means by which they are applied to packages differs on a per-package basis (but there are only 6 or 7 common ones) [16:11] Laney: well I am patching based on an apt-get source [16:11] which I believe is based on an SVN checkout [16:11] mrooney, look in the debian/ folder. if there's a patches folder in there, then that package uses a patch system [16:11] mrooney, svn-maintained packages are VERY unlikely to accept non-patchsys patches [16:12] directhex: Note that some packages use ./patches as well. [16:12] persia, really? which patchsys does that? [16:12] directhex: dpatch and quilt both support it. I think it was the recommended default for DBS (but very few people like DBS anymore) [16:13] (mind you, "support" in the sense that it works if you fiddle things properly) [16:14] persia, within pkg-mono, *every* package in svn has only a "debian" folder. upstream remains unmolested outside that folder. [16:14] directhex: That's a common way to do things in pkg-foo on alioth when using SVN. [16:15] persia, i do pkg-foo on alioth using SVN! [16:15] mrooney: Anyway, if you're wanting to submit a patch to upstream I'd get it applying cleanly and working on a fresh SVN checkout, then use "svn diff [files]" to generate the patch to attach to the bug. [16:16] well I am trying to do the first part :) [16:16] I need to generate the patch [16:16] directhex: Yep :) [16:16] svn diff will give you the patch [16:16] ahh ok [16:17] it seems like, rhythmbox just has rhythmbox_0.11.6svn20080916.orig.tar.gz and rhythmbox_0.11.6svn20080916-0ubuntu1.diff.gz [16:17] persia, apparently my monodoc update is finally uploaded, albeit in UNAPPROVED [16:17] and then the resulting directory [16:17] Excellent. Now you need approval. [16:18] persia, it's not beta-critical. it's certainly release-embarrassing though should it be missed [16:18] directhex: Does it fix a bug? Is the bug milestoned? [16:20] persia, 256853 [16:21] directhex: Hmm. Perhaps I wasn't clear :) I'm not motu-release or ubuntu-release, so I can't help much. [16:21] Essentially, uploads are approved if they fix bugs that in the eyes of the release managers ought to be fixed for beta. [16:22] persia, i'm less stressed about intrepid shipping with an embarrassing mono stack than i was. as long as it's in the release, then i'm not fussy [16:22] For Universe they are supposed to just shove stuff through. [16:22] If your bug is milestoned, this is nearly guaranteed. If your bug is in universe, this is nearly guaranteed. If your bug does not match these criteria, it's best to ask. [16:22] persia: thanks, I think -urN was what I was looking for! [16:23] urNad! [16:23] I wonder what that means. [16:24] Output NUM (default 3) lines of unified context. [16:24] Recursively compare any subdirectories found. [16:24] Treat absent files as empty. [16:24] Treat all files as text. [16:24] Try hard to find a smaller set of changes. [16:25] thanks :) [16:25] are you suggesting that is the preferred method? [16:27] directhex: That's cleaner, but it's not what debdiff does (last I looked) [16:28] persia, i rarely use debdiff. i contribute upstream to pkg-foo ;) [16:28] infact, dpatch-template is what i use a lot more than anything else ;) [16:28] Hrm. OK. I use debdiff even when I am committing to pkg-foo on alioth. [16:28] Not so much to generate the patches, but to review my work. [16:44] bobbo: ok, thanks === superm1 is now known as superm1|away [16:52] superm1|away: That's a pleasing surprise. I've just gotten a desktop install up for testing, and the updates look great! === asac_ is now known as asac === superm1|away is now known as superm1 [17:08] persia, yeah upstream accepted variations of a few of the patches I put together. they're still on the edge about the hbox patch of yours, but i updated it nonetheless for the new version and more feedback [17:14] superm1: Understandably. Unless you're actually trying to use it at 800x600 on a high-DPI device, it's not clear why being horizontal is better. [17:14] persia, I bounced upstream's latest feedback about the hbox patch to you if you'd like to provide some more input on it [17:14] Sure. [17:14] * persia first finishes the latest test report. [17:18] superm1: Ah. Looks great for me, but I see the point of the complaint with http://launchpadlibrarian.net/18041980/gnome_bt_too_large.png [17:19] persia, well try with the latest stuff on the PPA though. upstream took off the labels from those buttons [17:19] did you pair w/ a person not a device btw? [17:20] jdong, ^ robot theories..... [17:20] That makes it *much* better for me, but I don't have any currently working low-DPI environments. [17:20] I'm looking to package two pieces of web software. Kohana, a PHP5 framework and LimeSurvey. I've looked into how to package and have created folders for each module of Kohana (kohanaphp2.2, kohanaphp2.2-modules and kohanaphp2.2-vendor) including the creation of DEBIAN/{control, copyright, postinst, prerm}, but I'm stuck on what to do with postinst and prerm. [17:20] Can anyone help me? [17:23] what do you mean, what to do? [17:23] ya, just not sure what to program in there? [17:23] brettalton: also note that DEBIAN/* files usually get autocreated by debhelper scripts [17:23] superm1: Which is the communication from upstream? I still seem not to have it. [17:23] azeem: oh, then I may be lost in how to actually create .deb files. Can you send me a link to a tutorial by chance? [17:24] persia, I bounced it to your @canonical.com addy from my @dell.com address [17:24] it should have come from Bastien Nocera [17:24] Ah. I'll see if I can find out where it went then. [17:24] brettalton: see https://wiki.ubuntu.com/PackagingGuide/ I guess [17:25] !packaging-guide [17:25] Sorry, I don't know anything about packaging-guide [17:25] !packaging guide [17:25] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [17:25] persia, hadess is the suffix to the email [17:25] superm1: volume isn't the issue, it's destination. @ubuntu.com is easy. Other addresses are harder and less reliable. [17:26] persia, i'll rebounce then to @ubuntu.com [17:26] ubottu: thank you! [17:26] Sorry, I don't know anything about thank you! [17:26] Thanks, as I don't seem to have received it anywhere else. [17:26] is he a bot? [17:27] brettalton: Indeed. [17:27] hahaha [17:27] odd. Thank you [17:27] !backports [17:27] If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [17:27] It's the u[bot]tu that ought give it away :) [17:28] * sistpoty|work heads home... cya [17:30] persia: that and he didn't pass the Turing test ;) [17:30] brettalton: I suspect you'll want to read the turning test. Assigning gender means that ubottu wins. [17:31] s/turning/Turing/ [17:38] Hi [17:42] Hi iulian [17:43] hi geser :) [17:44] Hi sebner [17:46] Hello geser. === DrKranz is now known as DktrKranz [19:44] siretart: okay, no pb === fabrice_sp_ is now known as fabrice_sp === smarter_ is now known as smarter [20:04] if I need to find out where a package came from (ie; main, universe, etc) what tool can I use? [20:05] apt-cache policy $PACKAGE [20:07] I prefer "apt-cache madison $PKG" === mterry is now known as mterry_afk [20:08] oh, nice [20:08] didn't know that one [20:10] hm. should i add lpia support to my mono repo, considering the debs are built already? [20:18] thank you. [20:27] Uploading pool/main/m/mono/mono-runtime_1.9.1+dfsg-3ubuntu2~dhx3_lpia.deb: [....] done. [20:39] james_w: congratulations!! [20:41] anyone know of a good guide to setting up a buildd? === mterry_afk is now known as mterry [21:04] directhex: IIRC NCommander did setup a buildd, perhaps he knows a good guide for it [21:05] geser, found a slightly old one on debian.org, an associate is hacking on it to make it good for hardy [21:05] geser, stupid xen and lack of powerpc [21:06] thanks nxvl [21:20] james_w: congratulations :D [21:22] thanks sebner [21:24] * NCommander wakes up [21:24] Who has summoned my buildd knowledge [21:24] NCommander: geser ;) [21:25] * NCommander pokes geser's beard with the point stick of DOOM [21:25] hrm [21:25] my l and y keys are brokend [21:25] *broken [21:25] well, it was sorta me [21:26] what do you want to know Mr. Directhex [21:26]