=== anzenketh|brb is now known as anzenketh [00:07] A bug in non-english, mark it as invalid or incomplete ? [00:12] dupondje: Ask in #ubuntu-bugs [00:18] * Laney spanks whoever gave ghc6 back on armel [00:31] Is there a way you can install a icon on the desktop dh_desktop says it does something with icons but does not install them to the desktop. [01:46] I get a error when I try to run override_dh_auto_build was that removed in a newer version? [01:58] I just fixed a bug in debian. Need to wait till it gets to testing before sycning? [01:58] nigelb: No. [01:58] You just need to explain why we want it in the sync request. [01:58] ok. The trouble is I dont see the new version in packages.debian.org. I only see the old version [01:59] How long ago did it get uploaded? [01:59] 1 day [01:59] What package? [02:00] http://packages.debian.org/sid/galrey [02:00] I keep seeing 3rd rev here [02:01] oh, wait. its just my cache not refreshing. bah [02:01] nigelb: rmadison knows about -4, so it'll show up there. Sometimes it takes a little while. [02:01] rmadison -u debian galrey [02:01] okay :) [02:10] If I'm building a package that has no debian version, should I still add ubuntu1 to the package version? [02:10] yep 0ubuntu1 [02:10] thanks [02:11] there we go - all uploaded [02:13] err - I guess it's supposed to close a launchpad bug.. [02:14] what's teh right way to make a bug report like that? [02:14] apport or just make it myself? [02:14] sync request? [02:15] new package [02:15] new package need not close a bug report. thats in debian I guess [02:16] The changelog does not close a bug from Launchpad. New packages should have a needs-packaging bug and the upload close it using the syntax "(LP: #nnnn)". [02:17] New package would need a feature freeze exception at this point. [02:17] I could upload it for +2 too, doesn't matter to me [02:18] I just want to remove it from my ppa and make it easier for the rest of the world [02:18] If I'm not uploading for lucid, what should I upload for? [02:19] MTecknology: oh yeah. just open a normal bug. but you need ffe though [02:19] or else wait for lucid+1 [02:19] or, get it into debian [02:19] if you get it into debian, will be synced for lucid+1 [02:19] It's been waiting in debian for a long time, i took it off once (forgot why) [02:19] I just created a new rules file I get the error make: override_dh_auto_build:: Command not found was that command removed? [02:20] MTecknology: waiting in debian for what? [02:20] new maintainer? [02:20] ya [02:20] point me to the bug, I'll take over [02:21] I should have it close the ITP bug, shouldn't I? [02:21] yes [02:21] I'll fix that up [02:22] okay great :) [02:23] how do I search for an ITP? [02:24] MTecknology: http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=wnpp [02:25] I kinda wish it was easier to navigate their bug tracking :( [02:25] confuses me frequently [02:25] even worse is the bug reporting [02:25] nigelb: thanks [02:25] np :) [02:25] Just * Closes #xxxx ? [02:26] http://www.debian.org/devel/wnpp/ [02:26] there is some detailed instruction if you scroll down [02:27] Closes: #11111 [02:27] ooh - pretty hilighting must mean it's right [02:27] nigelb: no " * " before it like the rest of the lines? [02:28] 1472 outstanding ITP's in debian [02:28] MTecknology: you're taking over as new maintainer? [02:28] then say "* New maintainer (Closes: #1234)" [02:29] it's not in debian at all [02:29] hold on [02:30] then Initial Release would be good I think [02:31] E: lal source: debian-revision-should-not-be-zero 1.1-0 [02:31] lintain complained about that [02:31] should it me -1 isntead? [02:31] it should be 1 since its in debian [02:31] or rather it will be once you get it in [02:32] is -0 only if it's new to ubuntu and not in debian? [02:33] yup [02:33] makes sense too :) [02:34] nigelb: http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=lal [02:35] MTecknology: great :) mail the mentors and get it in :) [02:35] nigelb: I sent an RFS for the older package not too long ago [02:36] didn't get a sponsor? [02:36] nope [02:36] give me a minute [02:36] change the needs sponsor to Yes [02:36] ya, I had that until I uploaded the new package just now [02:36] ya, my last RFS was thursday [02:37] strange. I uploaded a package to mentors and got picked up in like few hours [02:37] before that was 01/30/10 [02:37] I had one person interested for a while but they seem to have disappeared [02:37] ah, yes. I see the mail in my mailbox [02:38] ask in mentors channel in oftc? [02:38] I am packaging a software that has never been packaged before I am using rules.tiny from the examples. I needed to overide dh_auto_build so I put it in but I am getting a error make: override_dh_auto_build:: Command not found [02:38] 21:36 -MentorSeeker:#debian-mentors-/Package 'lal' from 'Michael Lustfield' needs a sponsor (http://mentors.debian.net/debian/pool/main/l/lal/lal_1.1-1.dsc) [dockable clock appler for various window managers] [02:38] nigelb: I just saw that pop up [02:38] MTecknology: I know. just ask if someone is willing to sponsor there [02:43] Anzenketh: paste your makefile [02:44] Anzenketh: (to a pastebin, not to IRC) [02:44] lfaraone: shure I can past the rules file. [02:46] http://pastebin.ubuntu.com/398568/ there you go [02:47] nigelb: are you a sponsor at all? [02:47] MTecknology: nope. or else I would have sponsored you :P [02:47] oh [02:47] nigelb: thanks for the tips [02:47] I'm just someone like you :) [02:48] MTecknology: np. :) [02:49] lfaraone: http://pastebin.ubuntu.com/398568/ there you go [03:01] nigelb: there we go, replied to that message with more information about why it's useful to others [03:04] nigelb: now I just need to wait - hopefully less than another ~4mo [03:04] :( [03:05] MTecknology: hehe [03:10] * MTecknology wonders what the chances are of this being uploaded [03:12] What's this stuff about getting my key signed? [03:32] I am working on packaging a project that has never been packaged before I need to create directories with specific permittions what is the best way to do that [03:33] For example I need to create a directory /var/project/files that can be left empty. [03:33] But it needs to belong to the users group [03:35] Anzenketh: I think the install command does that [03:35] yup [03:35] So do I just put that in my rules file? [03:36] I am a bit new [03:36] it should be aprt of the Makefile [03:36] otherwise the rules file is a good place for it [03:36] This package has no upstream makefile [03:36] Long story [03:37] Anzenketh: I encountered that once, I made a makefile for them with other work and got it merged upstream, was nice [03:38] Ya that is my next project [03:38] I'd make it the first project ;) [03:38] it'll make writing the rules file much easier [03:38] The upstream author is demanding that the rules file be writting first [03:38] personally [03:38] :S [03:39] what project? [03:39] I would generaly agree with you. [03:39] amahi [03:39] it is a fedora native project. [03:39] amahi.org? [03:39] yep [03:40] not a fan of the navigation - that's a very odd requirement.... considering it's really odd that there's not makefileto begin with [03:40] how do you install it? [03:41] gcc commands? [03:45] Anzenketh: sorry I'm no help, just interested [03:46] Currently it is installed via rpm [03:46] so there is a .spec file [03:47] It is a mostly ruby project [03:47] oh... [03:47] there is only one c file [03:47] maybe holding in rules and no makefile is the better idea :S [03:48] The .spec file *should* be something like control+rules+maintainer-scripts all mixed together. One ought be able to extract the relevant bits (although this may require some understanding of RPM packaging) [03:48] yes it is [03:48] that is how i am getting all this information [03:48] once I understood that it was a brease [03:49] MTecknology: No, always better to have an upsteam build system, so that one doesn't have *two copies* of everything (one in the .spec file, one in the rules file) [03:49] persia: ok [03:49] The other reason why I am doing this is becouse I do not fully understand make files yet [03:50] persia: out of curiousity and no pestering following - are you DD? [03:50] No. [03:50] Once I understand this my guess is that all I will need to do is basicly copy the %install of the .spec file and put that in a makefile [04:06] persia: by the way thanks for your help last night however overide_dh_auto_install gave me a error when I tried the tiny one [04:06] What sort of error? [04:08] hold on. [04:11] http://pastebin.ubuntu.com/398584/ that is the error I get [04:11] ugh wrong one [04:12] Had to recreate the file [04:12] That does't say "override_dh_auto_install" :) [04:12] Also, "override" is spelled with two 'r's [04:15] http://pastebin.ubuntu.com/398585/ [04:15] there [04:15] fixed that and still got the error command not found??? I am perplexed [04:15] paste that rules file? [04:17] http://pastebin.ubuntu.com/398587/ thre is the rules file. [04:21] Anzenketh: Aha. Replace the tab character before override_dh_auto_install with a carriage return. [04:21] Anzenketh: Also, you probably want to invoke dh_auto_install in override_dh_auto_install [04:21] Anzenketh: And you want the `make hdactl-hup` call in an override_dh_auto_build: rule, not in override_dh_auto_install: [04:30] Thanks that fixed that. now to deal with those two pesky files. [04:39] Ok now trying to make it a tiny script need to invoke the command mv $(CURDIR)/debian/hdactl/usr/bin/hdactl.debian $(CURDIR)/debian/hdactl/usr/bin/hdactl [04:39] it used to work but now it states that the file does not exist. [04:39] Why do you want to do that? [04:40] From where do the .debian entries come? [04:41] source [04:42] OK. [04:42] but int he program they are called by hdactl when it is run [04:42] Thus the need to rename [04:42] So why don't you do mv hdactl.debian hdactl [04:42] And then just only put hdactl in debian/amahi.install to put it in the right place. [04:42] becouse hdactl is the fedora version hdactl.debian is the ubuntu version [04:42] There's just no point installing the files unless they are already correct. [04:44] Personally, I'd do something like `mv ${CURDIR}/hdactl ${CURDIR}hdactl.fedora && mv ${CURDIR}/hdactl.debian ${CURDIR}/hdactl` in override_dh_auto_build: [04:51] Yay that worked a lot better [04:52] got a question when I run debuilder it compiles the c file but does not remove the compiled version from the source tree when it is done [04:52] This is causing problems for when I want to compile again how to i fix that [04:54] Nevermind I figured it out [04:55] Anzenketh: Please add any extra cleanup you need to an override_dh_auto_clean: rule. [04:56] Lots of folks use sbuild or pbuilder to build in a clean chroot environment. [04:56] sbuild is set up with `mk-sbuild lucid` and pbuilder with `pbuilder-dist lucid create` in the simple form. [05:00] That works a lot better [05:00] Yay now I think I know enough about package managment that I can help make patches for ubutu bugs [05:01] Thanks a ton persia === yofel_ is now known as yofel [05:44] if in control the depends line gets too long I need to put in a / right? [05:47] Nevermind I figured out the answer is no [08:25] can someone familiar with bzr let me know what i get this?: http://pastebin.ubuntu.com/398648/ [08:38] ddecator: That's the the fun that is rich-root. :( [08:38] RAOF: any ideas on what i need to do? this is the first time i've tried to upload a branch to request a merge [08:41] ddecator: Complain bitterly to #bzr, but productive options include: (a) asking mozillateam to upgrade their branch to 2a, or (b) rebranch into a directory that's not a subdirectory of a directory containing a 2a (or any rich-root) repository and then redo your changes. [08:42] RAOF: alright, thanks. i have a mozillateam member helping me out, so i'll let him know what you said =) [09:54] I am porting over a package to ubuntu that has never been done before when I attempt to run debuilder I get a error stating that the binary contents have changed. [09:59] how does distutils name its build dir? I need to set PYTHONDIR to it, but it looks to be dynamic according to arch and host [10:07] anyone here? === ShadowChild is now known as lukjad86 === lukjad007 is now known as lukjad86 [14:28] nigelb: got a minute? [14:33] persia: please, could you renew my membership in ~ubuntu-universe-sponsors? [14:33] warp10: No. But I'll add you to ~ubuntu-sponsors [14:35] Done. [14:37] persia: will ubuntu-universe-sponsors be deleted ASAP, or when everybody is expired? [14:37] At some point after everyone else expires, I'll get around to deleting it. [14:37] But I didn't want to spam everyone with join/remove notices. [14:39] persia: Indeed. Anyway, thank you for your help! [14:39] Thanks for being a sponsor [14:42] shadeslayer: yes [14:42] nigelb: pm [14:42] persia: Would you please add me to ~ubuntu-sponsors. [14:44] ScottK: Done. [14:44] Thanks. [14:51] persia: Whilst you're at it, would you mind adding me to the team as well? [14:52] * persia needs to get less good at closing browser windows [14:52] Grrr. LP logged me out again! [14:53] iulian: Done. [14:53] persia: Thank you. [14:55] what would be the prerequisite for someone looking for motu membership? i.e. something like minimum requirements [14:57] people will start telling you to apply :) [14:57] aha ;) [14:57] nigelb: It's deliberately undefined, and typically specific to each individual. The key determinant is being perceived as part of the MOTU team by other MOTU. Most folks are expected to have been working in development for at least a full development cycle. [14:58] so lucid+1 should do the trick :) [14:58] Well, like Laney said :) [14:58] * hyperair has seen nigelb working very hard already =p [14:59] * persia was working on development for 4 cycles before becoming MOTU [14:59] hyperair: you can say that on my wiki when I go for MOTU application ;) [14:59] nigelb: heh. right =p [14:59] oh, btw anyone with some deep python knowledge around? [14:59] !ask :) [14:59] nigelb: but i haven't perceived you as a MOTU yet (because i've seen your launchpad page recently) [15:00] !ask | nigelb [15:00] nigelb: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [15:00] =p [15:01] hyperair: well, I just wanted to know for future knowledge [15:01] oh so that was the question =p [15:01] nigelb: there's DktrKranz. [15:01] give me time to frame [15:02] nigelb: generally if you have python packaging questions, drop by #debian-python on OFTC> [15:02] I'm creating an apport hook for cheese and running into some trouble getting debug info. [15:02] I think this is has something to do with subprocess.Popen command but I dont know wnough [15:03] I know pitti's area but I wanted to know if someone else could help figure out what I'm doing wrong [15:04] GST_DEBUG=*cheese*:3 cheese -v through apport.hookutils.command_output() [15:04] does popen grab things things from stderr? [15:05] hyperair: my knowledge of python is limited. I've never tried the subprocess module directly [15:06] nigelb: my knowledge of python is even more limited than yours. i'm just throwing out random ideas for checking [15:06] I've got the apport source and python reference open [15:06] still lost though ;) [15:06] * hyperair is even less familiar with apport [15:06] I'm familiar with apport, I made the rhythmbox hook :) [15:07] (if it does something wrong, you know who to /kick ;) ) [15:07] heh [15:08] Hi all... someone has news about bug 521834 ? [15:08] Launchpad bug 521834 in moin "[FFe] Please merge moin to 1.9.2-2 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/521834 [15:08] I guess I'll ping pitti on monday about apport [15:09] hyperair: um, how should a potential MOTU's launchpad page look btw ;) [15:09] nigelb: what? [15:10] nigelb: well, +related-software should have loads of things. but the reason i knew you weren't a MOTU was because i saw you weren't a member of ~motu or ~ubuntu-motu or something like that [15:10] hyperair: "i haven't perceived you as a MOTU yet (because i've seen your launchpad page recently)" [15:10] nigelb: There's not much point in that class of question. Do what you do: if what you do makes MOTU want you to be MOTU, you'll be MOTU. Anything else is just pushing against the lack of definition. [15:10] * hyperair agrees with what persia said [15:10] nigelb: According to help(subprocess.Popen) is listens to both stin and stderr. [15:11] (if I'm reading it correctly) [15:11] I kind of stopped seeing upload rights as a goal in themselves a while before I was pushed to apply [15:11] just continue developing. someday whoever you work with will tell you "eh wait, you aren't a motu yet?" and then you know you're ready =p [15:12] hyperair: hehe :) [15:12] That or "I'm sick of uploading your stuff, please apply so I don't have to do it anymore" [15:12] hehehe that too [15:12] persia: oh, it was a harmless query ;) [15:12] nigelb: Yes and no. Yes, because since there's no answer it doesn't matter, and no, because it means you still believe there are objective criteria :) [15:12] i think Laney got sick of me bugging him to upload my things. =p [15:13] ScottK: the trouble is I can't figure how apport deals with this particular situation (I can't see error messages) [15:13] nigelb: OK, I'd wait for pitti then. [15:14] situation = the gnome type debugging things [15:14] persia: its like ubuntu membership I guess. You know you're ready when people ask you "hey you're not a member yet?" [15:15] I think that's how most of the better-organised teams in Ubuntu work. [15:15] yeah :) Most of them === shadeslayer is now known as shadeslayer_ [15:57] Looking for a kind soul who can test build this fix pkg ** on ia64 **: https://launchpad.net/~kamalmostafa/+archive/test-builds/+files/gnome-color-manager_2.29.2-1ubuntu1.dsc (I just need to know if this actually fixes the FTBFS on ia64). Any takers? [16:01] * persia wishes someone would support ia64 as a qemu guest [16:05] I will load anyone wanting to do that the linux kernel ia-64 book. [16:05] which discusses a lot of useful stuff for doing that [16:07] kamalm: Just be aware that it may take a while for someone to help you. I know of only three active developers who have ia64 hardware, and of those one is very firm about not turning it on in the interests of saving electricity. [16:07] kamalm: You might ask in #ubuntu-ports, not because there are more folk there, but because there is almost no other traffic, so there's a greater chance if it being prominent in backscroll. [16:08] ah, thanks for the warning. well, I suppose I can just propose the fix as-is, and hope for the best. at worst, it will just continue to FTBFS on ia64 for some subsequent reason. [16:08] i'll try #ubuntu-ports first, but won't wait long ;-) [16:11] trying #ubuntu-ports and not waiting long is pointless. That channel tends to get <100 posts a week. [16:11] (but most folk idle a long time and may respond days later to backscroll) [16:14] persia: ah, okay. Well, posted there anyway. Maybe I'll get lucky. Any other general advice for testing platform-specific fixes like the issue I'm chasing (it *only* FTBFS on ia64)? [16:15] kamalm: There's usually folk with i386/amd64/armel/powerpc/sparc hardware around to help. [16:16] ah, okay -- i just picked an ugly one then. :-) [16:18] hi guys, I am software developer, I would like to make my software available for the Ubuntu crowd, it is already packagedd for red hat like systems, any pointers? [16:18] kamalm: You could have done worse. hppa had 6 users at the time it was retired, only two of which were active developers. === apachelogger is now known as fedoralogger [16:21] rgs_: Ubuntu uses a Debian style packaging system, so any documentation about "debian packaging" will be relevant. Specifically, you might take a look at: https://wiki.ubuntu.com/PackagingGuide [16:22] rgs_: if you can work towards getting your package, it would be great. we could then sync it quite easily [16:22] getting your packge *in debian* [16:24] yeah, I am looking for some documentation that will let me map my .spec hacking logic into .deb creation logic [16:24] sort of when you migrate from subversion to git style of doc :) [16:24] ah, I dont think I know of any. [16:25] you can see the debian new maintainer's guide, which is kinda easy [16:27] rgs_: IIRC the alien package will ~ do this, but that would just give you a starting place to work towards an actual package worth uploading. [16:27] It's certainly not possible to do a complete conversion (in either direction) [16:28] doesn't alien convert binary packages (and not source)? [16:33] Not sure. [16:33] The only think I've ever used it for is to alien --tgz a srpm to get the patches out of it. [16:33] It gives you a nice tarball with one patch per text file ready to examine. [16:39] the description contains [16:39] This is a tool only suitable for binary packages. [16:40] but I've never tried to use it with source packages [16:40] OK. Nevermind then. [16:44] rgs_, my guess is it should be possible to write a script to grab the various parts of a .spec and massage them into the prerm/postinst/etc. files necessary and a few other chunks of texts that would then make a basis for a debian/rules file. That's if that hasn't already been done, but I've never heard of it before === kirkland` is now known as kirkland === shadeslayer_ is now known as shadeslayer [17:14] thoughts on this debdiff? http://launchpadlibrarian.net/40924067/chromium-browser_5.0.307.9~r39052-0ubuntu2.debdiff === yofel_ is now known as yofel [17:17] nigelb: I'd like to know if it requires an FFe as I need to make a similar change to Thunderbird [17:18] micahg: I dont know. Since I didn't get reply here, I just subscribed sponsors. their call now === azeem_ is now known as azeem [18:30] please MOTU open task on karmic @ bug 421684 [18:30] Launchpad bug 421684 in obexd "bluetooth send malformed files " [Undecided,Fix released] https://launchpad.net/bugs/421684 [18:38] ari-tczew: is there a clear patch available, or are you still awaiting/working on a patch? [18:39] crimsun: I'm working on a patch [18:39] so directly I can be assigned to task on karmic [18:40] accepted for karmic [18:41] thanks [18:42] yw [18:46] ari-tczew: are you working on the libjdic-java upgrade for xul192 support? [18:48] micahg: I can't fix the FBTFS :-/ [18:49] ari-tczew: do you have a build link? [18:50] micahg: do you want see a buildlog from merging libjdic-java 0.9.5-7? [18:51] ari-tczew: sure [18:52] w8 plz [19:18] micahg: is it right? export JAVA_HOME=/usr/lib/jvm/java-6-openjdk [19:18] IMO should be changed to JAVA_HOME=/usr/lib/jvm/default-java [19:20] ari-tczew: idk [19:20] micahg: huh? idk? jdk? [19:21] ari-tczew: I don't know [19:21] ahh [19:30] I'm not up to date: what happens with sponsors? ubuntu-sponsors? wtf? [19:36] ari-tczew: yeah, sponsors merges [19:36] ari-tczew: is there an FTBFS still? [19:37] micahg, yes, I'm getting a buildlog for you, but pbuilder doesn't like me today :-/ [19:37] ari-tczew: k, you can email to me if you like.. my nick at ubuntu dot com [19:38] wrrrrrr what's the right command for pbuilder and output buildlog? [19:38] I did: sudo pbuilder build libjdic-java_0.9.5-7ubuntu1.dsc --logfile buildlog.txt and file buildlog.txt doesn't exist! [19:38] Put it between build and the .dsc [19:40] ari-tczew: try sudo pbuilder build libjdic-java_0.9.5-7ubuntu1.dsc > buildlog.txt [19:41] BlackZ, I'm not sure about your command, but ScottK propose works, thanks! [19:41] ari-tczew: yeah, it works too [19:43] Hello, I got a problem when I done : sudo pbuilder update --distribution lucid --override-config, I got this error: E: Internal Error, Could not perform immediate configuration (2) on mountall [19:44] what's that ? [19:45] micahg, I have sent email to you [19:47] ari-tczew: yeah, it looks like it's not passing the right flags for 192...let me pull the source [19:48] ari-tczew: have you changed it at all? [19:48] micahg, I'll send to you my debdiff; but this is not a 192 problem. with 191 FTBFS exist too [19:49] ari-tczew: ah, that's bad.... [19:49] AnAnt: are you able to do apt-get -f install ? [19:49] micahg: I'm looking on Debian WebSVN, what's the different between -3 series and younger [19:49] BlackZ: where ? [19:50] AnAnt: in a terminal [19:50] with sudo, sorry [19:50] BlackZ: yes, it doesn't say that I need to fix anything (please note that the problem is in pbuilder) [19:53] ari-tczew: I think it might be a failure with xul>=\1.9.1.7 [19:54] ari-tczew: -fshort-wchar was added then [19:54] ari-tczew: maybe we can get flags/libs from pkg-config? [19:54] micahg: I don't know [19:57] If a python package foo requires A) another package bar to be set up previously and B) python-support triggers for bar need to be run before foo can be set up, how do I enforce that? [19:58] micahg: my eyes sees these differents since -3 series: B-D on openjdk-6-jre-headless; debian/rules got export JAVA_HOME=/usr/lib/jvm/java-6-openjdk; Add patches/Tray.diff; bumped from xulrunner-devel-1.9 to xulrunner-devel-1.9.1 [19:58] (per: http://launchpadlibrarian.net/41539627/DpkgTerminalLog.txt) [20:05] ari-tczew: try this, replace line 67 in the build.diff patch with: LIBS_PROG += `pkg-config libxul --libs` [20:12] micahg: doesn't help [20:13] micahg: I don't have any ideas :-/ [20:13] ari-tczew: probably need the same on line 58, but leave -lgtksuperwin [20:14] micahg: so: LIBS_PROG += `pkg-config libxul --libs`-lgtksuperwin is it right? [20:15] add a space before -lgtksuperwin [20:15] I think so... [20:19] micahg: FTBFS... [20:21] ari-tczew: yeah, it's not getting all the flags [20:21] micahg: beside your suggestion I did some changes like bump to xulrunner 1.9.2, replace java-6-openjdk with default-java [20:25] ari-tczew: you probably need to expand the build patch to get cflags from libxul from pkg-config [20:26] micahg, ehh I can't do this [20:26] ari-tczew: do we need the merge? [20:29] micahg: not necessarily, current ubuntu's version builds fine, so +1 from me for only rebuild for xulrunner 1.9.2 is enough [20:30] ari-tczew: fine, I'll work on getting that ported and upstream the pkg-config changes so the next merge should be easy....sound good? [20:32] micahg: "next merge should be easy", but before we need to merge this once, right? [20:33] ari-tczew: well, you said Ubuntu version is fine, so I'll fix that upstream, and next merge will be for Lucid + 1 [20:34] micahg, OK, I'll waiting, merge request is open so you can own it whenever you want [20:35] ari-tczew: I'm not going to touch it... [20:36] mivahg: you will fix it upstream - upstream what? libjdic-java? [20:36] ari-tczew: debian [20:36] ah [20:37] ok [20:37] ari-tczew: I'm only merging now if upstream has xul192 support [20:37] so, I'll patch current Ubuntu version and if you want, you can merge or wait [20:38] micahg: as I said previously, merge now is not necessarily, so I'll merge or sync in lucid+1 [20:47] ari-tczew: k, will you be able to test once I port it? [20:48] Question for ubuntu-archive folks: sync request bug 537708 has been pending in queue for 10 days -- is there anything in particular holding it up? Thanks! [20:48] Launchpad bug 537708 in hamlib "Please sync hamlib 1.2.10-3 (universe) from Debian unstable (main)" [Low,Confirmed] https://launchpad.net/bugs/537708 [20:50] micahg: build testing is enough? [20:50] ari-tczew: no, I was hoping for usage testing...what program uses it? [20:52] micahg: Reverse Depends: paros libjdic-bin === kamalm is now known as kamalm-away === FlannelKing is now known as Flannel === anzenketh_ is now known as anzenketh