[00:02] persia: so, if the package has one advocate, it gets a bulb. If then someone rejects it, it gets a hammer. When it's uploaded again, it gets a bulb again... until it gets another advocate and gets a heart. Is that right? [00:02] persia: and what would you expect if the package has 2 advocates (and thus a heart) and someone rejects it? o.O [00:03] pochu: hammertime!! [00:03] :) [00:03] couldn't resist [00:04] pochu: if it has 2 advocates, it gets uploaded... [00:05] jdong, "can't upload this" dum-de-de-dum [00:05] mok0: usually, yes. [00:18] persia: new patch attached to bug 185133 [00:18] Launchpad bug 185133 in revu "Improve package images so that there is just one image per package" [Undecided,In progress] https://launchpad.net/bugs/185133 [00:20] jdong: do you know transmission 1.02 is in debian unstable? I guess we could ask a sync, WDYT? [00:20] jdong: as there are no changes other than a new upstream... [00:21] does anyone know what make error 1 is? [00:25] pochu: yes, it's in debian.. you should request a sync of it [00:26] it's installed now in hardy by default [00:26] jdong: I'll request it. Let me know if you disagree :) [00:32] make erro 1. Any guess? [00:37] Legendario: that is nowhere near enough info to say anything about [00:37] Legendario: you need to pastebin the stuff that happened before the make error [00:46] Dear PyPy. You sound cool, but please build on amd64. [00:50] LaserJock, here it is: http://paste.ubuntu-nl.org/53400/ [00:52] Legendario: well, look at what it's telling you :-) [00:52] checking for PIDGIN... configure: error [00:53] i think is a Build-Depends error [00:54] Legendario: does it make sense? === lakin_ is now known as lakin [01:02] pochu: wait a sec don't sync yet [01:03] pochu: I want to review it, there was a tarball packing error with the initial 1.02 release; I feel more comfortable with the one I rolled [01:06] the orig tarballs are not the same [01:07] LaserJock, yeah, it makes sence. it is building a pidgin plugin [01:08] Legendario: so do you have a build dependency on pidgin-dev ? [01:08] does the Developer Sprint is taking place or this development circle there was no one? [01:11] pochu: I closed the sync ticket you opened for transmission; reasoning can be found on the bug report. I'll also poke debian about the situation. [01:13] how would a person go about tackling these issues? http://paste.ubuntu-nl.org/53402/ [01:13] :) [01:15] For the first two, you're using CDBS, yes? [01:15] vorian: You have ${shlibs:Depends} not ${python:Depends} and you're calling dh_shlibdeps instead of dh_pycentral or dh_pysupport [01:15] RAOF: yes [01:15] ah! [01:16] thanks StevenK :) [01:16] is there anyone willing to review http://revu.ubuntuwire.com/details.py?package=sdlmame [01:17] please do it... it's been in revu since last february and I really like to see it in hardy :D [01:24] * wallyweek is sad to leave, but he *strongly* needs some sleep [01:31] * jdong fixes prevu's misuse of exceptions [01:37] does anyone here know how to get rid of an installed package whose uninstall-hook messes up? [01:37] jdong: hmm, if upstream rolled a new tarball, they should have done it with a version bump [01:38] jdong: alright, let's wait for 1.03 then [02:00] pochu: yeah, I agree that was bad judgement on their behalf [02:00] pochu: but meh what can you do; it's good enough already that they didn't say "deal with it" [02:06] jdong: yeah, but how would you know now whether someone has the good or the bad tarball offhand? [02:06] jdong: anyway nice to hear it's fixed. [02:16] pochu: well I compared md5sums first, then ./configure --help, look at mandir and infodir defaults. Correct ones say DATAROOTDIR/man and so on, incorrect ones say PREFIX/man. /usr/man is obviously not a good place for manpages ;-) [02:25] yea but it wont work with Core Audio i dont think , not sure, I'll try a new compile here tonight and see [02:25] err totaly wrong window === nixternal_ is now known as nixternal [03:42] So can anybody here help me get on my path toward Ubuntu development? [03:42] what's the best way to get a GPL app put in the repos? [03:43] browndruid: that kinda vague. What are you interested in? [03:43] MarcC: well, packaging it. :-) [03:43] MarcC: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [03:43] I't not really totally sure. I have very little programming experience, so if there's somewhere you can point me to so I can start learning, I think that would be the best first step. [03:44] browndruid: you might want to have a look at https://wiki.ubuntu.com/UbuntuDevelopment/ [03:44] well, you don't often need very much programming experience [03:44] I've been reading the Development site. [03:44] What kind of stuff would I do without programming experience? [03:44] well, anything you want [03:44] thanks LaserJock [03:45] Yeah, but if I don't know how to do it, then I can't. [03:45] browndruid: https://wiki.ubuntu.com/MOTU/TODO [03:45] browndruid: well, we don't really program [03:45] we package and take care of the archive [03:46] programming experience can be helpful when bug fixing, but even then there's a lot you can do [03:46] * jdong smiles... [03:46] I'm going to hell for this one :) [03:46] uh oh [03:46] LaserJock: don't worry, it's ony on my personal computer :) [03:46] you rick rolled someone ? [03:47] I kinda reinvented module-assistant [03:47] Well, I guess I'll be on my way! [03:47] devil!!! [03:47] browndruid: why? [03:47] browndruid: do you wanna help or ? [03:47] so i can start on the whole learning what i need to do thing. [03:47] a deb package that in postinstall unpacks and recompiles madwifi-ng if it isn't probed in the running kernel... [03:47] Yeah, I want to help. [03:47] browndruid: this is a great place to learn [03:47] I was tired of recompiling madwifi on every kernel update. [03:48] I'm sure I broke some holy rules of deb packaging :) [03:50] * imbrandon waits for someone to package the wow installer + custom wine [03:50] that would suck and rock , both [03:51] imbrandon: I see dist-upgrader does --force-{some,all,etc} during release and partial upgrades now, so.... what's the harm in that ;-) [03:51] heh, thus why i stick to apt-get [03:52] if you cant apt-get dist-upgrade , something is broke imho [03:52] imbrandon: personally, I wonder if a lot of dist-upgrader's jobs should be somehow worked into the metapackages [03:52] jdong: they should imho [03:53] bleh I just drank rubbing alcohol [03:53] the time it takes to "fix" it in dist upgrader could easily be added to the packages [03:53] don't keep open bottles of water and alcohol close by [03:53] but thats just me personaly [03:54] imbrandon: I agree, I don't see much of a technical reason why it couldn't be a part of a package's pre/post* scripts [03:55] imbrandon: Up for sponsoring a Kubuntu merge? It's Bug #185754. [03:55] Launchpad bug 185754 in sip4-qt3 "Please merge sip4-qt3 4.7.3-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/185754 [03:55] I'm working on python-qt4 merge right now and that one needs to go first. [03:55] ScottK: sure give me a few to dig out my usb key ( gpg ) and i'll have a look [03:56] can somebody tell me how this looks as a needs-packaging bug? [03:56] https://bugs.launchpad.net/ubuntu/+bug/185810 [03:56] Launchpad bug 185810 in ubuntu "Art of Illusion - Easy to use 3D modeling studio" [Undecided,New] [03:56] imbrandon: Great. [03:57] LaserJock, sorry. i had to go away for a couple hours. Do you mind if we go back a little. I have the build dependencies for it. I have the pidgin-dev installed and when i run the configure script for the program i am trying to build a debian package, it says to me that everything is ok. [03:58] k [03:59] MarcC: looks fine as far as a request [04:00] ok, thanks imbrandon [04:02] ScottK: is that a debdiff against the debian or ubuntu source, dosent look like the patch applies to the hardy ubuntu [04:06] imbrandon: debdiff against debian [04:06] ScottK: got it [04:14] debiandiff :) [04:14] diffbuntu [04:14] hi all [04:14] I coin those two terms! [04:14] can I bug someone to update the octave package on hardy? and subsequently gutsy? [04:14] debian's got source packages for those in sid [04:15] http://packages.debian.org/sid/octave3.0 [04:15] freakabcd: Hardy's easier to argue than gutsy currently [04:15] freakabcd: see bug #185653 [04:15] Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed] https://launchpad.net/bugs/185653 [04:15] it's already been put in the queue [04:15] freakabcd: once it's in hardy we can talk gutsy-backports [04:16] gotta go [04:16] ah, cool [04:16] will be back tomorow though [04:16] jdong: But those backports guys are crazy. [04:16] ScottK: yeah I know ;-) [04:16] well, it doesn't need to be a backport [04:16] it could be a proper gutsy release [04:16] ScottK: that's why people should make a website where anyone can upload and share the debs they create [04:17] freakabcd: that is not in line with the update policy for released distributions [04:17] because, the deb octave list have still not moved to gfortran based dependencies [04:17] I didn't think we were doing Octave 3.0 yet [04:17] LaserJock, deb has packages already. trivial to get them on hardy [04:17] freakabcd: not exactly [04:18] LaserJock: well \sh pulled the trigger ;-) [04:18] we were thinking of leaving 3.0 out of Hardy perhaps [04:18] no way [04:18] as we weren't sure of the upgrade path [04:18] you mean the octave modules issue? [04:19] please follow debian's footsteps in this matter. they already have 3.0 released. providing binary modules isn;t too much of a priority anyway. [04:19] the next step they are already working on is to move away from f77 and onto gfortran [04:19] well, we can't just follow Debian in all cases [04:19] we have to take care of our users as well [04:20] Debian dropped the octave binary [04:20] they dropped binary octave modules? [04:20] no [04:20] what did they drop then? [04:20] the metapackage [04:21] we were going to do some upgrade testing first [04:21] obviously. their reasoning was that this time when someone installs 'octave' they get exactly that 'octave' nothing more like the binary octave modules, etc. [04:22] jdong: I did have a pleasant IRC conversation with someone I'm working on a project with. He mentioned he was getting more spam. I asked him if he'd upgraded to spamassassin 3.2.4 yet. He said no, he guessed he'd have to build from source (he's got a feisty server). [04:22] I thoroughly enjoyed being able to say no, it's in feisty-backports. Just install it. [04:23] heh [04:23] ScottK: :) [04:24] well, perhaps we should have emailed -motu about Octave 3.0 [04:24] well, they need to include 3.0 atleast in hardy. [04:24] we'll see [04:24] how far away are we from freeze? [04:25] hopefully [04:25] Feb 14th [04:26] wow, not too much time. hope the 'octave guy' here updates to 3.0 [04:26] well of course I want to [04:26] i forgot his name; was kind enough to update the 2.9 package from the ancient .12 [04:27] well, nobody has filed a sync bug that I know of [04:27] https://bugs.launchpad.net/ubuntu/+source/octave3.0/+bug/185653 [04:27] that one? [04:27] Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Confirmed] [04:27] freakabcd: You can look it up in the package info on Launchpad [04:27] LaserJock: I just linked to one! [04:27] bah [04:27] lol [04:27] stupid LP [04:28] I did a search and nothing came up [04:28] what is MoM sync ? [04:28] LaserJock: it's filed under octave3.0 somehow [04:28] Merge-o-Matic [04:28] LaserJock: even though that package should be -ENOENT [04:28] freakabcd: MoM is merge-o-matic [04:28] I don't get Launchpad anymore [04:29] ah, interesting acronym [04:29] alright so maybe I should set it to Incomplete at the moment and leave a note [04:29] damn, i don't have hdd space to mess around with hardy :( [04:29] persia: ping [04:31] whats with the tags on LP on the left? [04:31] there is a tag '1680x1050' i clicked on it and there are no results [04:32] Maybe we can use them like slashdot tags ;-) [04:32] freakabcd: means what ever was using it is no longer [04:32] lol, it was searching for 1680x1050 with the octave-3.0 domain [04:32] LaserJock: UW search works much better than LP search in most cases :) [04:32] thats funny [04:34] hmm, well if minghua shows up we can discuss it [04:34] ( LaserJock and even has a FF plugin hehe ) [04:49] freakabcd: it may be we just need to patch octave3.0 to build the octave metapackage [04:50] cool. that would be great. [04:53] LaserJock, i'm not on my ubuntu box at the moment. what packages does the octave metapackage install? the headers, emacsen, etc. ? [04:54] well, octave3.0 itself too [04:55] great. i hope to see 3.0 packages in gutsy too :D [04:55] then i can start messing around with providing binary packages for the octave-forge modules [04:56] no, they won't be in gutsy [04:56] I don't think there would be a way to do that outside of maybe a PPA [04:56] you mean the backport guys will refuse to backport it? [04:56] I believe so, there's too much that depends on it [04:56] you'd have to backport probably like 20-30 packages I'm guessing [04:57] LaserJock: Kind like with clamav, right? [04:57] at least ;-) [04:57] and without the justification [04:58] wait a minute.. 2.9.19 from hardy hasn;t been backported to gutsy [04:58] !! why? [04:58] Sorry, I don't know anything about why? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [04:58] freakabcd: we don't just backport everything [04:59] ok, i'm going to get the source package for 2.9.19 from hardy and backport it to gutsy. [04:59] i will assume it is trivial. and let you guys laugh at me tomorrow at my failure :D [05:00] LaserJock, what makes me believe it is trivial is that none(that i know) of the deps have updated releases [05:01] well [05:01] freakabcd: If it build/installs/runs on Gutsy, you can ask for a backport. File the bug in the gutsy-backports project. [05:01] "what can be done by rebuild from source" is different than "building with the archive and making everything happy" [05:01] ok, cool. i will mess with it tonight. [05:02] i should setup a build environment, right? [05:02] pbuilder [05:02] slomo!!!! Just the developer I needed to speak to :) [05:02] i finally managed to free some space. about 2G should be enough, right? [05:02] (not really, just trying to scare you) [05:03] freakabcd: octave's big, isn't it? [05:03] when you add in the build-deps [05:03] lol, no. i meant for the pbuilder environment thingy [05:03] i hate building atlas. that thing compiles for years [05:04] freakabcd: pbuilder's base.tgz for hardy takes like 50MB [05:04] freakabcd: the problem is that the unpacked build environment is the size of apt-get build-dep octave plus a bit more [05:04] and unless you have magical space (i.e. tmpfs) it won't be happy with 2GB most likely [05:05] jdong, what if i have the _binary_ deps installed and the deps_dev packages installed too? [05:05] i won;t need to rebuild the deps from src, right? [05:05] no [05:05] but you want a pbuilder for that [05:05] freakabcd: pbuilder is a self-isolated environment [05:05] freakabcd: what you have installed in your main system is irrelevant [05:06] freakabcd: pbuilder will make a temporary chroot and bootstrap it, and install all build-deps via apt-get in that environment, then destory it once it's done building [05:06] jdong: unless it's maybe Windows, I've not seen anybody run pbuilder off of Windows ;-) [05:06] lol LaserJock [05:06] I gotta run for a bit [05:06] bbl [05:06] LaserJock: haha cygwinbuntu? :D [05:07] lol [05:07] jdong, damn. so i need a lot more than 2G for a base-system + installing octave deps, then compiling octave-3.0 [05:07] thats what you are saying, right [05:07] ? [05:07] freakabcd: it would seem that way in my humble opinion [05:08] freakabcd: do you have a large RAM+swap you're not using? [05:08] ok, i'll try to free up more space tonight. [05:08] * jdong puts on his hack hat [05:09] i've got a 2G swap and 1.25G RAM. and 2G free space at the moment. if my simple calculations are correct i will be around 6G free hdd space [05:09] :) [05:09] it looks like unionfs hacking time ;-) [05:09] stitch all your random free space together! [05:09] frankenstein mountpoint [05:10] jdong: So unionfs doesn't work because it needs hundred year old bolts? [05:10] lol, frankenspace [05:11] StevenK: is that why frankenstein failed? [05:11] Hah [05:11] :) === Ibalon is now known as zakame [05:30] can I confirm my own needs-packaging bug (185804) or does it need something else? [05:30] https://bugs.launchpad.net/ubuntu/+bug/185804 [05:30] Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New] [05:30] gQuigs> triaged [05:31] imbrandon: How did the merge look? [05:31] thanks LucidFox [05:34] ScottK: looks fine, should have it uploaded here very shortly [05:34] imbrandon: Thanks. [06:38] Heya all [06:52] warp10, hi [06:52] Hi Aloha [07:06] guys, can someone check libsuitesparse in hardy? I'm still on gutsy and had libsuitesparse installed before. now, i tried to install libumfpack and it conflicted with some files from libsuitesparse (amd) [07:07] i don;t much care about this problem, but i thought it must be checked in hardy. why doesn;t just libsuitesparse install libumfpack? [07:07] since it is supposed to be providing umfpack [07:15] freakabcd: Why do you think it's a problem? AFAIR libsuitesparse _should_ conflict with libumfpack. [07:16] really? why would that be? also why would it tell me during the installation phase that it conflicts? [07:16] it should have known that once i selected the package in synaptic [07:17] How do I stop CDBS from turning debian/changelog files into symlinks in dependent packages? [07:17] minghua, would you be able to tell me how much b/w will be consumed for me to setup a pbuilder env? [07:18] freakabcd: I only have hardy here. And it seems there is simply no libumfpack4 in hardy. I'm checking the situation in gutsy. [07:19] freakabcd: As for the bandwidth question, I don't really know. For a minimal pbuilder it shouldn't be much, but you can't do much about the pbuilder either. [07:24] freakabcd: Yes, there is a bug in gutsy's libsuitesparse package, it should Conflict and Replace libumfpack4 but doesn't. [07:25] LucidFox: You don't [07:25] freakabcd: Actually, there is bug 144171. [07:25] Launchpad bug 144171 in suitesparse "package libsuitesparse 3.0.0-3 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/144171 [07:25] LucidFox: This is a feature of Ubuntu's cdbs that Linitian isn't aware of. [07:26] so I should add a Lintian override? [07:26] or just leave it alone? [07:26] What am I suppose to do with the bug? It's fixed in hardy. Just label it "Fix released"? [07:26] minghua> yes [07:26] LucidFox: I'd file a bug against lintian. [07:30] if i rename postinst.ex to postinst does it automatically use it in the package or do i need to add a line somewhere? [07:33] * minghua reads the bug again and decides to mark it incomplete because the report didn't say why it failed to install... [07:33] Aloha: It's automatic. [07:33] minghua, thnx [07:34] Or perhaps, it's automatic if you use debhelper/CDBS/etc. [07:38] is there a way to interactively edit the changelog? [07:41] dch/debchangelog [07:41] debchange* [07:42] minghua: It's automatic for cdbs. For debhelper you need to call (I think it's) dh_installinit in debian/rules. [07:43] ScottK2: Are you sure? It's postinst, not init script. I think either dh_control or dh_installdeb deals with postinst. Both of which should be mandatory. [07:44] minghua: Sorry. [07:44] It's almost 3AM here. [07:44] ScottK: :-) It's dh_installdeb BTW. [07:44] I think it's automatic then. [07:44] Ah. [07:44] Also, there is no dh_control, only dh_gencontrol. [07:47] minghua, so on gutsy. i just installed pbuilder. [07:47] to create the environment, i just go: pbuilder --create ? [07:48] freakabcd: Pretty much. There are some configurations you may want to set, though. I am not really an expert on pbuilder creation. [07:52] minghua, where will this env be stored on my computer? [07:53] well, it will be persistent, right? i don;t want to do this every time i try to test out building new src packages [07:53] freakabcd: ~/.pbuilderrc. You should read pbuilder(8) man page first. [08:30] Hi all. Can anyone point me to nautilus extension library api docs? [08:31] slytherin, i tested that package and it messed up things, i had to reinstall nautilus [08:31] techno_freak: There was no need to reinstall. You just had to remove the package. :-) [08:31] i made a stupid mistake of saving the error message there itself, i deleted the image without noting it [08:32] techno_freak: I mean the open-terminal package [08:32] slytherin, oh, i just did apt-get install --reinstall nautilus === civija_ is now known as civija [08:53] does MOTU add packages to universe that are created by LoCo teams? [09:13] persia, how verbose are you setting your lintian? I set it to what you had mentioned to me some time back in my bashrc, but still seem to not be catching things you are catching === \sh_away is now known as \sh [09:19] hi folks! :) [09:19] <\sh> moins [09:20] superm1: are you using lintian -ivI ? [09:20] is there and example for packaging .desktop files? [09:20] vemon: yes.. [09:20] !packaging | vemon [09:20] vemon: 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 [09:20] I've added a watch file to sdlmame, I think it could receive advocation now, could anyone please have a look at it? http://revu.ubuntuwire.com/details.py?package=sdlmame [09:21] <\sh> minghua, ping [09:21] Kmos, the packaging guide has a chapter of packaging desktop files for KDE apps but does that also apply for Gnome applications? [09:22] <\sh> minghua, bug #185653 what do you think about the idea in my comment? [09:22] Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653 [09:22] and is there a "cdbs way" to do it? [09:22] <\sh> moins raphink :) [09:22] like just adding the file to say... debian/desktop.files [09:23] * wallyweek feels downhearted as sdlmame is in revu since last february and still can't find his way to multiverse :( [09:23] vemon: cdbs do it automatically, catches for .desktop files [09:23] hi \sh [09:23] vemon: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles [09:23] what's up \sh? [09:24] Kmos, so if the .desktop files are in the root of the package they are installed? do i need a specific cdbs import/include for this? [09:24] vemon: no, you don't.. but try to learn cdbs manual.. [09:24] !cdbs | vemon [09:24] Sorry, I don't know anything about cdbs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [09:24] is it ok to full fix fro a bug from upstream svn? [09:25] Kmos, thanksfor the SuppFiles -link! haven't seen that page before [09:25] slytherin: how do you mean? [09:26] raphink: I mean I check the SVN diff and create a patch for those fixes in Ubuntu package. [09:26] yes it's ok slytherin, as long as you include the patch properly [09:26] <\sh> raphink, waiting to start my new job :) what about you still happy at your place? [09:26] using dpath, quilt or cdbs's simple-patchsys [09:26] \sh sure :) [09:26] I'm fine, still having fun [09:27] there's tons of things to do here :) [09:27] Kmos, the functionality i'm looking for seems to be in gnome.mk. thanks again! [09:27] and I'm taking a week of vacation in the moutains in family next week :) [09:27] raphink: The fixes are just few lines. So it will be fine. There is a bug fixed in SVN, but the fix for that touches many files so I am not pulling that. [09:27] slytherin: although it might sometimes be worth considering a full upgrade of the package if a good amount of fixes were added [09:28] slytherin: ok [09:28] slytherin: if you know exactly the few lines to patch, then create a patch just for that [09:28] slytherin: just keep in mind that each patch that is added has to be maintained/merged in the future [09:28] and that adding a patch system to a pacakge if it doesn't exist yet makes it harder to maintain [09:30] raphink: It is already using cdbs patch system. So that is not a problem. The bug for which I am pulling in the fix from SVN makes the package unusable in hardy. That's why this urgency. I will send email to maintainer asking when he plan to do new release. [09:30] hi, did openscenegraph compile with libxine-dev? [09:30] slytherin: in this case, go for it :) [09:30] i dont see an updated package yet... [09:31] \sh what is your new job? [09:33] <\sh> raphink, building a new datacenter infrastructure :) [09:33] ah nice :) [09:33] what tools are you using this time? [09:34] \sh: Commented on bug #185653. [09:34] Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Undecided,Incomplete] https://launchpad.net/bugs/185653 [09:34] * wallyweek is not away, it's only unable to tell this stupid online irc client not to disconnect him [09:34] wallyweek: make a cron to wake up your irc client every 5 minutes? ;) [09:35] raphink: that would be good but I'm on mibbit web client as proxy doesn't allow irc protocol at work :( [09:38] hmm, debian maintainers really skip always needed builddep for media players... [09:38] even when i mail em [09:38] wallyweek: how about using a transport agent with a jabber client or so? [09:41] <\sh> minghua, there is a mistake in your comment ... Package: octave3.0 \n Provides: Provides: octave,octave2.9 \n Replaces: octave (<= 2.0.16-2),octave2.9 \n Conflicts: octave (<= 2.0.16-2),octave2.9 [09:41] raphink: I've no practice with such a thing, I'll have some googling about it, thanks! :) [09:41] <\sh> minghua, and I would like to recheck that octave3.0 will not break any other octave using sources... [09:41] wallyweek: get a jabber client (Kopete, Pidgin, etc.) [09:42] wallyweek: get a jabber account on a server with IRC agents (jabber.fr does that for example) [09:42] Kano: How come the packages compile then? [09:42] \sh: Which part of my comment is mistaken? [09:43] slytherin: they work but you dont have full features [09:43] like missing output plugins for mplayer [09:44] Kano: Then upstream authors make the dependencies essential instead of optional [09:44] you miss dxr3 DXR3/H+ video out when you forget em8300-headers [09:44] <\sh> minghua, that they are parallel installable..but I should read all comments...sry [09:44] slytherin: but even in the description of the package is DXR3 support mentioned... [09:44] \sh: Good that we agree, then. :-) [09:46] <\sh> minghua, well, as I said, I'm doing some tests now: 1. upgrade tests 2. rebuilding all sources which are directly build-depending on octave2.9/octave , against octave3.0 and 3. prepare a list of packages which are depending indirectly on octave2.9 [09:47] \sh: Sounds a good plan. Also, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457675 all but one package have migrated to octave3.0 in Debian. [09:47] Debian bug 457675 in octave2.9 "RM: octave2.9 -- RoM; superseded by octave3.0" [Normal,Open] [09:48] \sh: Altough there is probably a chicken an egg problem in hardy. We can't start migration without octave3.0 in archive, but once we starts octave metapackage will be broken. [09:49] <\sh> minghua, this is not a problem... [09:49] \sh: So it seems we need to get it done altogether. [09:49] <\sh> minghua, as I'm preparing the build-dep list and rdepends list I can prepare all packages to use octave3.0/octave and push a rebuild on our buildds [09:50] <\sh> minghua, just like libgif transition ;) [09:50] \sh: Good, good, go ahead and good luck. :-) [09:50] <\sh> minghua, but now: just a bunch of packages at one time :) [09:58] I am getting this error when trying to build a package. - aclocal: configure.in: 18: macro `AM_PROG_LIBTOOL' not found in library. Can anyone help? [10:00] slytherin: You need to install libtool [10:00] persia: Thanks for reviewing the package, couple of questions. What am I patching in the bare diff.gz that should be moved to debian/patches? [10:02] TheMuso: Why was it not needed before? [10:03] slytherin: What do you mean why was it not needed before? [10:03] TheMuso: I am modifying existing package [10:03] slytherin: And? Sorry I wasn't reading prior IRC conversations, I just saw your error. [10:04] TheMuso: Yes that is the only information I have to give. I am getting this error when I am trying to fix a bug in nautilus-open-terminal [10:05] slytherin: What did you run? Autogen? [10:05] slytherin: What did you change? Did you change configure.in or Makefile.ams? [10:05] autogen.sh even [10:06] minghua: TheMuso: I changed configure.in [10:07] slytherin: Right, in that case, you need to regenerate the configure script .Usually packages have a build.sh, or autogen.sh to do this. [10:08] Thats when you need libtool and other bits like autoconf/automake. [10:10] Hello [10:11] TheMuso: So should I simply add libtool to build dependency? or should I generate configure script locally (outside pbuilder) [10:12]