[00:00] directhex: this is not the right channel for OSX support ;) [00:01] superm1: yeah, it has been very fun gleaning that from the Windows INFs :-) [00:02] mok0, on ubuntu, of course. it's been running ubuntu since dapper [00:03] binarymutant: check with jmarsden, who wrote the text [00:03] directhex: heh [00:03] How do I get something into main? [00:04] cyberix, is there a compelling reason for canonical to give it commercial support? [00:04] mok0, you think it should be changed to? or am I just crazy? === leonel_ is now known as leonel [00:04] mok0, http://www2.apebox.org/wordpress/wp-content/gallery/00-single/IMG_0120.JPG [00:05] directhex: ttf-mph-2b-damase would add to main the missing fonts that are required for being able to display wikipedia.org front page correctly [00:05] directhex: that's an Apple monitor alright [00:05] s/monitor/computer/ [00:05] hehe [00:06] binarymutant: I think you need to check with jmarsden and ask what the meaning is [00:06] will do mok0 [00:06] binarymutant: thx [00:07] directhex: Apple computer with Microsoft keyboard and mouse running on Linux, funny mix [00:08] stgraber, yes! ^_^ [00:14] universe's sponsor queue is back to being smaller than main's [00:14] let's try and keep it that way :-) [00:15] good effort! [00:15] james_w: got any specs you want to discuss at UDS? [00:15] not really, I'm feeling pretty un-inspired this cycle [00:15] apart from bzr stuff of course [00:16] I always enjoy joining in to random sessions though [00:16] james_w: well, the bzr stuff should probably get added to the tracker, so it does get scheduled, and so people can subscribe to it, and get less clashes. Please do it ASAP :) [00:16] Hobbsee: yeah, I should. Not sure what specs it will have yet though :-) [00:16] I'll work on that tomorrow, thanks for the reminder [00:17] Hobbsee: what specs are you proposing? [00:17] james_w: think quickly. You can always refine later. ;) [00:17] james_w: probalby one on retaining ubuntu developers, and making it easier to contribute [00:17] good ones, I'd like to contribute to those [00:18] * directhex wonders if anyone at UDS will be in a position to mention the ubuntu-archive-friendly consequences of the mono 2.0 transition currently underway [00:19] what consequences? [00:21] lifeless, less disk consumption, mainly [00:21] StevenK: do you recall why libxi-dev was added to build-depends in your upload to [00:21] https://edge.launchpad.net/ubuntu/+source/anyremote [00:22] nellery: Because it uses headers from it, I believe. [00:23] debian NEW permitting, anyway [00:23] StevenK: ok thanks a lot. [00:24] james_w: would ^^ answer your question to why libxi-dev was added to build-debs [00:24] for Bug 298496 [00:24] Launchpad bug 298496 in anyremote "Please merge anyremote 4.6-1 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/298496 [00:25] If it #include it requires libxi-dev [00:27] ./src/xemulate.c:#include [00:27] ./src/xemulate.c:#include [00:27] they are the only X11 related includes from a quick grep [00:29] And XTest includes XInput [00:29] You know, headers being recursive and such? :-) [00:30] StevenK: 'if it includes XTest | Xinput' [00:30] :) [00:32] but it doesn't use any symbols from XInput from what I can see [00:34] Mmmm, armel builds in progress... nice [00:35] NCommander: poke? [00:42] right. Spec added. [00:42] \sh: please check open sponsor requests before uploading a package. [00:45] thanks Hobbsee [00:45] james_w: you're welcome [00:54] hmm when did the encoding of the diff files @ revu changed to text/plain ? [01:05] * jdong finishes boiling his blood over unsupported flash installer scripts at the forums. [01:05] I tried. and I failed. sort of like my recent academic career [01:06] just nuke the forums. [01:07] sounds good to me [01:23] jdong, i noticed that thread [01:23] i wonder WHY i noticed that thread. [01:31] directhex: yeah I hope the rest of the peanut gallery can see that it's not a great script to be running. [01:31] I'm through arguing with him. [01:32] jdong, but using -y with apt is always the right thing to do! [01:34] and so is using rm -f, just in case you changed those perms for a reason. and using remove/install [01:52] jdong: we'll be discussing the future of flashplugin-nonfree at UDS. [01:52] crimsun: neat. What kind of future, like whether or not we're gonna punt it out of the repository, or better support for it? [01:53] jdong: those issues are on the table [01:54] (I suspect the discussion will involve hacking nspluginwrapper to not hog cpu, too.) === vorian is now known as heHATEme [01:56] crimsun: very nice. Well I wish the best of success... comparing my Ubuntu experience to OS X on the same system, flash and sound are the two biggest day-to-day discrepancies I see === heHATEme is now known as vorian [01:58] well, the alpha 64-bit plugin of non-Free Flash is already a huge step forward in lessening the cpu nastiness, but there's quite some ways to go [02:19] jdong: What sound issues do you have? [02:25] TheMuso: mostly distortion -- blipping sometimes associated with system load [02:25] it's better when I disable ondemand CPU frequency scaling, dunno if that's placebo effect or not [02:27] jdong: Is your hda codec fully supported in Linux? [02:29] jdong: ah, another distortion person! [02:31] TheMuso: it's an ALC885 I believe, iMac 8,1 [02:31] TheMuso: to get any sound I have to set model to mbp3 [02:31] jdong: Yeah thats been fixed in later alsa code, i.e 1.0.18 I think so the mbp3 flag is not needed. [02:31] My MacBook Pro is in the same position, although I don't get distortion at all. [02:31] Not that I've noticed anyway. [02:32] TheMuso: well the last time I used 1.0.18 I had a beautiful kernel panic in alsa code :) [02:32] so I might hold off for a bit. I'm somewhat gun-shy now [02:32] heh [02:33] jdong: Was that the final 1.0.18 release? [02:33] TheMuso: yeah [02:33] I'm running the 20081116 snapshot with nary a panic. Where did it splode? [02:34] Nov 2 18:32:59 droptop kernel: [77439.410052] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [02:34] Nov 2 18:32:59 droptop kernel: [77439.410066] IP: [] snd_hda_codec_amp_read+0xc4/0x150 [snd_hda_intel] [02:34] let me know if the rest is useful to pastebin [02:34] yes, the entire thing. (Please file a bug affecting linux if you haven't.) [02:34] crimsun: affecting Linux for... a self-compiled alsa 1.0.18 failing? [02:35] jdong: good point. Well, it needs to get looked at somehow. [02:36] crimsun: fwiw full pastebin at http://paste.ubuntu.com/73630/ [02:36] jdong: ok. [02:36] crimsun: at the time I was using Skype [02:37] it seems like the skype auto-microphone-gain-adjustment feedback loop triggered that call path [02:39] TheMuso: I'm looking redoing the source package for alsa-driver. It's madness ATM. Will send e-mail to pkg-alsa-devel once I have something less vapourware. [02:39] looking at* [02:39] crimsun: I made an attempt at DKMS'ing alsa-driver... [02:39] then I realized dkms actually makes you list all the .ko's and where to install them. [02:39] slightly overkill? [02:39] then it went on a "TODO: perl hack" list and never got touched :D [02:40] ajmitch: *shrug* guess Dell never had to package something with 50+ .ko's? [02:40] the Fedora dkms RPM of alsa-driver definitely listed out every .ko and an install path for each. [02:40] crimsun: Ok, I guess what we want to be able to do is track it in git, and pull/merge commits from upstream as we want them. [02:40] it looked painful. [02:40] especially if they change in a future release [02:40] jdong: besides, the answer to that is Python :) [02:41] DKMS is not the answer for alsa kernel modules. [02:41] ajmitch: oh they CHANGE depending on ./configure flags :) [02:41] IMO [02:42] yeah, I considered dkms some bit ago, and while it makes sense for an upstream vendor with a known subset of codecs to support, it's not feasible at package install. [02:43] I even had the usual madness of "oh, let's anticipate which audio devices the user /might/ insert". Yeah, crack. [02:44] which would include any usb or bluetooth devices? [02:46] yeah, like "hda-intel" + "usb-audio" + "snd-bt-sco" and whatnot. The problem is, what if I hotplug something requiring a more specific driver (e.g., usb-usx2y or usb-caiaq)? [02:46] snd-bt-sco is still in existence with 2.6.27+ though? [02:46] crimsun: Or you insert a PCI card into a desktop that you want to use, say ice1712/24 [02:46] TheMuso: precisely [02:47] superm1: well, it's still shipped in intrepid [02:48] (as in, since this work is going into pkg-alsa-devel, we don't have just Ubuntu kernels to consider) [02:48] That makes things even more hairy. [03:19] directhex: does bug 175273 still affect you in a recent Ubuntu release? [03:19] Launchpad bug 175273 in mjpegtools "Conflicting type definition in mjpeg_types.h" [Undecided,New] https://launchpad.net/bugs/175273 [03:20] (bah, should have checked /wi first) [03:23] if anyone has any time on their hands I would appreciate very much an advocation for my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :) [03:48] i installed Banshee and the restricted codec set from the repos, and i cannot get anything to play, Banshee just gives me an orange box with an "x" in it on every song in my library, anyone have any ideas as to why? [03:49] did you restart banshee? [03:49] yeah [03:49] did you change the address of the library? [03:50] nope, still the same drive [03:50] hm. Then i don't know ;) [03:50] hehe, damn [03:51] now, i have to remount the drive manually everytime i restart my machine, and i built my library, restarted, and then remounted, could that have anything to do with it? [03:56] possibly, if it's given it a different mount point [03:57] O:) [03:58] yay [03:58] now we can live free from the threat of impending doom [03:58] * Hobbsee throws mneptok into some hot lava [03:58] * mneptok extrudes an igneous crust [03:59] ajmitch: there's always impending doom.. [03:59] yeah, this *IS* -motu [03:59] * mneptok scampers [03:59] mostly harmless [04:00] * mneptok is not to be fed after midnight [04:03] should I just ditch everything after the first paragraph in my readme.source? [04:06] or is dpatchhttps://wiki.ubuntu.com/README.sourceHowTo [04:06] binarymutant: Pick the relevant bit of that wiki page for the patch system you are using [04:07] jmarsden, well I was using the entire dpatch example, should I just ditch everything after the first paragraph of it though? [04:07] oh, so that's where that was from [04:07] binarymutant: It's up to you ... the page was just some examples to help people create the file easily. [04:08] jmarsden, also it's dpatch deapply-all [04:08] Hobbsee: I plead guilty? [04:08] * Hobbsee still doesn't agree with part of it [04:08] Care to propose a fix? [04:10] jmarsden: something to the effect of: "To undo patches that have been previously applied to the source package, run:" [04:11] wininst.exe [04:11] jmarsden: it's probably a little pedant-ish, but it doesn't fulfil the role of dh_clean, or any of that, iirc. [04:13] Hobbsee: Is it supposed to? Per Policy 4.1.4 it is supposed to say how to "Remove source modifications that are currently being applied when building the package." [04:13] jmarsden: well, check with persia, but i thought the only thing it did was undo the patches. [04:13] maybe it has changed, and i'm out of date [04:13] Right, and those are the only source modifications being made, right? [04:14] Well, depends on the package. lsdiff -z *.diff.gz is a good way to double-check. [04:14] I was a *total* beginner when I wrote that wiki page, BTW and in many ways I still am one... [04:14] i wouldn't bet on it [04:15] I think it makes sense the way it is...except for the dpatch unapply-all should be dpatch deapply-all [04:15] mneptok, It's a policy violation to use extensions for programs in the default path. Please patch your application to use "wininst" instead. [04:15] persia: so *that's* why i got a lot of crap for "mnep.tok" [04:16] Hobbsee, repoke [04:17] slytherin: nuking doesn't need a REVU Hacker. Any REVU Admin can do it. [04:24] binarymutant: OK, s/unapply-all/deapply-all/ fix is now applied to the wiki :-) [04:26] very cool jmarsden, I also think your right about the way it reads [04:26] Maybe. I need to think a bit more about the more philosophical change _Hobsee and _persia seem to be suggesting... [04:27] jmarsden, It's probably better to insert the '_' in the middle :) [04:27] Ah, oops... :) [04:27] Give me props for at least *trying* not to alert you unnecessarily! [04:28] Doesn't matter. I read everything here anyway, and the other isn't spelled with two 'b's. Anyway, which philosophical change am I suggesting? [04:29] Well, via Hobb_see, that the "Remove source modifications that are currently being applied when building the package" language which Policy 4.1.4 says the README.source is supposed to document, may not be 100% fulfilled by the stuff I have put in there... [04:29] The key instructions are 1) How to get the source from the unpacked state into a good state for review of the build target, and 2) How to get the source in the state for review of the build target into the preferred state for uploading. [04:30] The fact that this doesn't necessarily get the source into a pristine upstream state is irrelevant. [04:30] OK... so better to keep it simple and leave that part as is, you are hinting? [04:31] * persia hunts for a URL, and actually reviews the document [04:32] https://wiki.ubuntu.com/README.sourceHowTo and http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource [04:32] I find the language very confusing. [04:32] It's as close to policy as I could get... or that was my intent. [04:33] Essentially, you *don't* want to "generate the fully patched source" before you "modify the source and save those modifications" when following the dpatch or cdbs examples. [04:33] You've covered the base use case for policy, but it's hard to read. [04:33] The quilt example works well, except/unless you want to insert patches into the stack at a different level. [04:34] Also, if I remember the ML discussions about this, there were supposed to be default snippets in quilt, dpatch, CDBS, etc., so debian/README.source could say "This package uses quilt. Please see /usr/share/doc/quilt/patching-with-quilt for further information". [04:35] I'd be opposed to adding any of the examples to any new packages. [04:35] nellery: ping [04:35] That level of detail is only required if the package constructs it's own patch system, else we have lots of duplicated content in the archives, and need to patch in lots of places if the behaviour of a patch system changes. [04:36] OK. Would you be opposed to adding them to any of quilt/dpatch/CDBS that don't yet have such examples included? That was actually a thought of mine at the time I first created the page. [04:36] Elbrus, In nearly all cases, it's better to provide some context with a ping, and often it's better to ask things generally. [04:36] nellery: I am trying to understand why the changes are needed in nedit... [04:36] jmarsden, No, not at all. I think there's already some work done in Debian to that effect though: it may not be worth duplicating the effort. [04:36] * persia is not entirely up-to-date on this particular issue. [04:37] OK. I don't see one in dpatch in Intrepid, for example [04:37] Might have gotten caught by the Lenny freeze. Check Debian VCS. [04:37] (and BTS) [04:37] OK, can do. [04:37] nellery: my version runs on my machine so I wonder if/why the lesstif2 is not enough [04:38] jmarsden, If they don't appear there, submitting good texts as patches to the BTS would probably make sense. Once there, applything them in Ubuntu is mostly a question of timing. [04:39] OK. I'm still mroe comfortable in the Ubuntu world than the Debian one... I need to grow up and start learning how to deal with upstream stuff :-) [04:39] persia: sorry, I see. [04:40] was just looking at bug 299318 and try to learn something from it [04:40] Launchpad bug 299318 in nedit "Please merge nedit 1:5.5-3 (multiverse) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/299318 [04:40] * Elbrus did the QA for Debian on nedit [04:47] Elbrus, Thanks for catching that. The Maintainer change is clearly a result of cut&paste, and wrong. [04:48] Considering the only change to lesstif2 in Ubuntu is a scrollwheel inversion patch, I don't know why it wouldn't work, and suspect that's leftover cruft as well. [04:49] Elbrus, Are you sure you don't need to build-dep on libxext-dev and libxp-dev ? [04:50] persia: it builds on sid... haven't tested yet on Ubuntu [04:50] Hobbsee, Can you shed any light on this? [04:50] persia: I can try if you want. [04:50] Elbrus, Last change to Ubuntu before the merge was April 2007, so things may have changed :) Given you recently looked at the package, I suspect you're right. [04:51] persia: well, I just don't want to create regression because of me nosing around... [04:51] persia: have i modified it? [04:52] Hobbsee, You're the last uploader. [04:52] oh. damn. [04:52] Hobbsee, From what Elbrus says, looks like a sync, but I'm hoping you can remember that far back. The current merge doesn't look carefully tested. [04:53] oh, of nedit. [04:53] i was thinking that i didnt' remember lesstif2... [04:54] Right. The question is about bug #299318 [04:54] Launchpad bug 299318 in nedit "Please merge nedit 1:5.5-3 (multiverse) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/299318 [04:54] Is the bug about update-notifier being broken known? [04:54] It's clearly a bad merge, but whether it should be fixed as a merge or sync'd remains an open question. [04:54] (jaunty)root@liquified:~# /usr/share/update-notifier/notify-reboot-required.: 8: gettext.sh: not found [04:54] persia: why is it a bad merge? [04:55] Hobbsee, At least, failed to include maintainer change properly. Given lesstif2 changelogs, I suspect the motif change may not be required (also based on Elbrus' testing). [04:56] persia: oh right, his merge. not my changes. [04:56] * Elbrus did not very extensive testing, but at least nedit runs and performs tasks... [04:56] Hobbsee, No. I'm not criticising your past work in any way. [04:56] persia: not critism - just still trying to get context on what the question is, how i'm involved, and what actual bit is wrong. However, i think i've almost accomplished that ;) [04:57] Hobbsee, Yeah. It's been a while since you last looked at that one :) [04:57] persia: maintainer change isn't required - it got orphaned after we touched it. [04:57] can I build against jaunty already using pbuilder? [04:57] Elbrus, Certainly. [04:58] bug 81103 [04:58] I get: E: No such script: /usr/share/debootstrap/scripts/jaunty [04:58] Launchpad bug 81103 in nedit "nedit fails to launch with an X error" [High,Fix released] https://launchpad.net/bugs/81103 [04:58] Hobbsee, Right, but we should reflect that in Original Maintainer. [04:58] StevenK: in what? [04:58] persia: indeed. [04:58] Hobbsee: Hm? [04:59] [15:54] Is the bug about update-notifier being broken known? [04:59] StevenK: in..intrepid? jaunty? [04:59] Hobbsee: Oh. Jaunty [05:00] StevenK: then yes, i think so. assuming you mean 'break' by "wanting to upgrade you to intrepid" [05:00] Hobbsee: update-notifier, not update-manager [05:01] persia: I can't see a patch for the README.source for dpatch in Debian BTS... where can I find its VCS? And in general, how can one find a VCS for a given package, come to that -- is there a neat way to know where to find the VCS? [05:01] StevenK: oh, right. [05:01] persia: if it runs, and builds, then it's probably fine to drop the changes now. [05:01] (jaunty)root@liquified:~# /usr/share/update-notifier/notify-reboot-required [05:01] jmarsden, apt-cache showsrc $(package) would have a Vcs-* entry. [05:01] .: 8: gettext.sh: not found [05:02] persia: beyond that, i don't remember specifics [05:02] * Elbrus just remembered reading somewhere you need to add a link to gutsy... [05:02] Hobbsee, Thanks for double-checking. I'll repurpose the merge, and request the sync. [05:02] persia: Aha, I did apt-cache show not showsrc Thanks. [05:03] Elbrus: Right [05:03] * Elbrus is starting building nedit in jaunty now [05:03] persia: cool, OK [05:12] binarymutant: dpatch in Jaunty (dpatch 2.0.30) has a default file at /usr/share/doc/dpatch/README.source.gz which you can (and therefore should) point to instead of using text from my wiki page === fabrice_sp_ is now known as fabrice_sp [05:16] sebner, When you get a chance, could you check to see if binfmt_misc solves https://blueprints.launchpad.net/ubuntu/+spec/hellboy195 and update the status accordingly? [05:27] persia: nedit build without changes and seems to run exactly like on debian... again: no extensive testing, but writing and saving works [05:34] thanks jmarsden [05:35] No problem. Now I'll have to see about submitting by CDBS one as a patch to its maintainers, I suppose :-) [05:35] s/by/my/ [05:38] hi. who maintains revu? [05:39] http://revu.ubuntuwire.com/feed.py?package=codelite <-- MOD_PYTHON ERROR [05:40] if i downloaded eclipse from the website, am i also going to need all the dependencies that were required for the version from the repo? [05:41] hyperair, The REVU Hackers maintainer REVU. [05:42] Elbrus, Thanks for checking. I've requested a sync of your upload to the repos. [05:42] persia: and where do i find them? [05:42] hyperair, Usually here. [05:42] sjdurfey, Quite likely, although you'll want to check the upstream website to determine which packages you need. [05:42] ok, thanks [05:44] persia: um so how do i ping them or whatever? [05:45] hyperair, You already have. [05:45] uh i did? [05:46] The main issue is that it's night for most of them. The one awake at this hour is probably either commuting, or in a foul mood due to a late evening of work. [05:47] Yeah. Most of them ping on "REVU" or "REVU Hackers". [05:47] In general, it's a handy thing to have an alert on a team. [05:47] hyperair: So, you can retry maybe every 4 hours until someone responds :-) [05:48] i see [05:48] okay [05:48] what does "REVU Day" mean? [05:48] * persia recommends every 6-8 hours, to avoid annoying people [05:49] It's the day the REVU Coordinator tries to get every MOTU to review some packages. [05:49] i see [06:22] good morning [06:27] Morning Daniel. [06:27] hi iulian [06:33] howdy dholbach and iulian [06:33] hi highvoltage [06:34] Hey highvoltage. [06:36] g'night all [07:47] could someone explain to me what this lintian warning means? W: codelite: possible-unindented-list-in-extended-description [07:50] hyperair: Run lintian -v on the package. That should give you a very detailed explanation. [07:50] ScottK: k thanks [07:52] ScottK: doesn't seem any more detailed than earlier [07:52] OK. Sorry I'm out the door right now and don't have time to give detailed help. [07:53] hyperair: Try -i instead [07:53] wgrant: alrighti 'll try that thanks [07:53] hyperair: Could you put the entire control file on pastebin? [07:55] http://revu.ubuntuwire.com/details.py?package=codelite [07:55] soren: it's there [07:55] soren: i'm fixing a bunch of lintian errors right now, and that popped up. [07:56] soren: http://pastebin.com [07:56] shit [07:56] wrong url [07:56] hyperair: I see it now. [07:56] hyperair, Package descriptions have a very distinct way to handle lists. [07:56] Right, lintian explains it pretty well. [07:56] And links to debian policy which explains it even better :) [07:56] soren: yeah it does, but i don't get it. i don't have any unindented lines! [07:56] It's not indented enough :) [07:56] Read 5.6.13 of debian policy. [07:56] soren: eh what? [07:56] soren: got a link? [07:57] http://www.debian.org/doc/debian-policy/ch-controlfields.html [07:57] hyperair, After removing the indent for the description, you don't have any indent left. [07:57] soren: thanks [07:57] 4 seconds of google. Bam! [07:58] persia: i don't understand. what indent? [07:58] hyperair: Have you read 5.6.13 yet? [07:59] soren: yeah. but i still don't get what's wrong with my control file =\ [07:59] One space at the start of the line (which all of your lines have) just means "this line is part of the extended description). [07:59] soren: yes, i know that. i have one space at the start of my lines. so what's wrong? [08:00] hyperair, You have a list that doesn't meet the criteria for lists (second bullet point in the description of the extended description) [08:00] Any application presenting this data is allowed (probably even encouraged) to reformat these lines by removing the linefeeds you added and use something more fitting for the way it's presenting it. [08:00] Obviously, that'll mess up your list. [08:01] soren: so what should i do? [08:01] Any line beginning with two (or more) spaces will be left as is. [08:01] oh so i should indent it with one more space? [08:01] Yes. [08:01] soren: okay thanks [08:02] now i just have to figure out how to write manpages [08:02] soren, Not only "encouraged" but "mandated" by policy: "Successive lines of this form will be word-wrapped when displayed." [08:02] and then write 5 of them [08:02] and figure out a way to shfit /usr/share/codelite/plugins to /usr/lib/codelite/plugins [08:03] persia: "will" makes it a prophecy which in my book is less than a mandate :) [08:04] soren, Was policy proscriptive, I'd agree. As policy is supposed to be descriptive, I suspect that all current tools do wordwrap. [08:05] hmm is there a lintian that won't complain about this? E: codelite_1.0.2432-0ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file jaunty [08:05] RAOF:just so you know, almost done with updating the changes for miro [08:05] hyperair: the jaunty one itself, probably. [08:06] hyperair: you can just ignore it, though [08:06] hyperair: Yeah, don't worry about that one. [08:06] alright [08:10] Yasumoto: Cool. I was wondering about that ;) [08:10] RAOF: I was down at a Usenix conference repping the SoCal linux expo last week, it through off my schedule [08:10] sorry :-X [08:11] No problem at all, it's not like the deadline's pressing. [08:11] yeah, true [08:11] thanks for the advice so far :) [08:11] Thanks for taking an interest in Miro. [08:17] if i'd like to add a bunch of diversions for a package, should i use dpkg-divert in preinst and postrm or what? [08:17] Yeah. [08:17] You should probably try to make the package not need them though. They are *very* annoying to get right. [08:17] ok [08:18] persia: well, you see, there's this package i'm thinking of packaging.. which is geany-dark-scheme or something of that sort [08:18] So to properly update the changelog,I should just walk through the changes from the last ubuntu releases(since the last merge) and double-check if they're in the vanilla debian package? [08:18] persia: the thing is that the stuff in it overrides the data files for geany,, but at the same time, without geany, it's useless [08:19] Yasumoto, If you're doing a merge, preserve *all* the previous Ubuntu changelog entries, but then only report on the preserved changes by examining how your package differs from Debian. [08:19] persia: any suggestions besides dpkg-divert? [08:19] hyperair, Then surely that's a bug in geany: that it doesn't have a facility to allow for additional data to be added post-install. [08:21] persia: unfortunately so. the colour schemes for the files are all in /usr/share/geany, and they have to be overriden if it is to be changed [08:21] persia: thank you, yeah, I'm working on a merge. By "report", does that mean I should delete anything that's included in debian, include notes on what's found in the ubuntu package? I feel like I'm not grokking this right, sorry :/ [08:22] Yasumoto, Your final changelog should be the old Ubuntu changelog + any new changelog entries from Debian + a new changelog entry from you. [08:23] In the new changelog entry, you want to have one item "merged with Debian. Remaining Ubuntu changes:" and list the specific changes you are preserving. [08:23] ohhhh [08:23] thank you [08:25] morning everyone === not_rly is now known as orly_owl [08:30] if someone has time to review my package, i wld be verry happy :p ( http://revu.ubuntuwire.com/details.py?package=sqliteman ) [08:36] good morning huats [08:36] morning Yasumoto [08:44] RAOF: if you have some time, mind looking at my preliminary changelog? http://pastebin.ubuntu.com/73754/ [08:45] jk, update: http://pastebin.ubuntu.com/73756/ [08:58] persia: imho that was not very useful to add a watch file to xfce-mcs-plugins-extra, as it'll be deprecated with xfce 4.6 ;) [08:58] Yasumoto: Looks about right, although you're missing the dropping of the needless democracyplayer-data package. [08:59] mr_pouit, Oh, then yes, it was probably useless. I just found it when I was cleaning up ~/src/scratch today, and pushed it to help clear UEHS. [09:01] RAOF: good, catch, I didn't see that [09:06] Yasumoto: I always debdiff my merges against the Debian base while reviewing my changelog; that makes it easy to spot. [09:09] persia: do you have GCJ installed at present? [09:09] slytherin, No. [09:12] persia: ok. Whenever you get time, can you please check if omegat starts with GIJ runtime? My last changelog entry indicates it should run, but it was not working yesterday. I am working on putting changes back into Debian. [09:14] slytherin, Do you need that tested in intrepid, jaunty, sid, or lenny? [09:15] persia: intrepid is fine. [09:16] RAOF: attached to the bug [09:16] thanks for your patience, lemme know if there's anything else I can fix [09:17] I'm off to bed, I'll see you guys tomorrow [09:21] slytherin, Fails to startup because I don't have ~/.omegat/omegat.prefs [09:22] persia: Wow. On my machine it simply throws a null pointer exception. Are you using version from repositories? [09:23] slytherin, Yep. Intrepid version, intrepid repos. update-alternatives adjusted to always use gcj. [09:23] (mind you, it's all purged now, but I was using that) [09:39] persia, hello. is this a right place to ask why i get an error usin pbuilder? [09:39] *using [09:40] voland, It can be. Ask your question. If it's not the right place, someone will point you elsewhere. [09:41] I've got such error 'fb2parser.c:27:51: error: /usr/include/libxml2/libxml/xmlmemory.h: No such file or directory' I have libxml2 packge installed [09:41] There is such file [09:42] persia: I wonder what is wrong with my machine. I will check once again when I go home. [09:42] voland: you need libxml2-dev installed [09:42] mok0, I have tem installed [09:42] voland, Is it in your build-dependencies? [09:43] yes [09:43]