[00:09] jcastro: are you guys blogging about -proposed availability? [00:10] crimsun: I am not blogging about anything at the moment [00:10] jcastro: e.g., "foo is available in gutsy-proposed; please test"? [00:10] if you think I should, let me know [00:10] I have no problems doing so [00:10] general question: if I have a new project, is there any chance of it making it into hardy at this point? (I'm looking at the topic) [00:10] phomes (the gnome guy) suggested something like "Get the latest X two weeks before everybody else!" kind of thing [00:11] the entire discussion in -devel, for me, boils down to: 1) not enough people are testing, 2) the distro is worried about accountability [00:12] (1) is not easily resolved, but we can do a better job of getting word out there. [00:12] (2) allow the release manager of each stable release, ~ubuntu-sru, and ~ubuntu-security to override SRU/security policy [00:12] (heck, do we even have an active release manager for each stable release?) [00:14] what the hell do I do with a package after having it? I've created the package of libmtp-0.2.5, upgrading the existing 0.2.4-?ubuntu? [00:14] release managers,as far as i know, are only really responsible for the dev release [00:14] How do I get it into hardy? [00:14] tiagoboldt: have you filed a bug using LP against the libmtp source package? [00:15] nop, so is it a bug not having the latest version packaged? :l [00:15] tiagoboldt: attaching a debdiff against the Debian source package would be helpful. [00:16] 0.2.5-1 is in Debian unstable. [00:16] documentation sucks :\ There could be a lot more of people helping if it was easier to know were to put what :\ [00:17] hum, so I should port it, something like that, right? [00:17] Can anyone do that? Or should we respect the package maintainer? [00:17] tiagoboldt: do you need someone to assist you in merging 0.2.5-1 from Debian unstable? [00:17] anyone can do the work. [00:18] Heya gang [00:18] Hi bddebian [00:18] than I shall do it! Do I have to 'reserve' that job for me? so that no one else starts doing the same? [00:18] tiagoboldt: just begin working on it [00:19] Heya geser [00:19] Reading the motu pages on it, going to gather the script to use with MoM and start following the documentation :D [00:20] tiagoboldt: ok. [00:22] If you have got a spare moment, please take a look at openFX: http://revu.ubuntuwire.com/details.py?package=openfx [00:26] should I leave -- Ubuntu Merge-o-Matic as the maintainer after a merge? [00:26] no [00:26] tiagoboldt: No [00:27] you want to change that :D [00:27] that the script should go and get my debname and debmail (guess that's it) from bashrc, shouldn't it? [00:27] *than [00:29] that only happens with the initialization of a source directory to a debian package layout [00:32] so, I get all the stuff from mom, correct the conflicts, fill in the changelog and run merge-genchanges, thats it for the start? [00:32] Not really. [00:33] You really want to go over the previous Ubuntu changes and work out whether they're still necessary. [00:34] and if I'm unsure? :\ example: this one depends in ubuntu of udev, and in debian of something like {$udev} [00:35] Then you might want to check out when that Ubuntu change was made, preferably finding the LP bug, and see whether the rationale still applies. [00:36] If there *was* an LP bug you can see if the unchanged Debian package still exhibits that bug, and whether the Ubuntu change still fixes it. [00:37] got it, and, always, for every merge, create first a bug for the source I'm merging, right? So that I can close the bug with my merge, is that it? [00:37] Yup. That also tells other people not to merge the same package. [00:38] Also you should add a comment on DaD that you're merging. [00:38] mom/dad what's what? [00:39] MoM is the Merge-o-Matic. DaD is an open-source alternative, with per-package comments. It's annoying that there are 2 different Ubuntu mergers, but that annoyance is going away. [00:40] real soon now © [00:40] still, for now, I should be careful with both, I'll try that :D [00:40] is there any motu-school scheduled? [00:41] tiagoboldt: If, at the end of it all, you don't understand an Ubuntu change, or whether or not you can drop it you should ask in here. [00:41] Lutin: MoM code is available now, isn't it? Will you add comments support to it? [00:44] pochu: yeah. me or Adri2000 :) [00:44] Wow, they released it? [00:45] Fujitsu: Yes. [01:35] if there is a bug for the ubuntu kernel, is this one of the cases where a patch format other than a debdiff is better? [01:35] :) [01:35] not necessarily. [01:36] for the kernel, a git changeset or a URI to its upstream is sometimes more efficient [01:36] oh ok [01:36] evening [01:37] 'lo zul [01:37] hello zul :D [01:37] how is it going crimsun and joejaxx [01:37] * joejaxx goes to install git [01:37] it is going well [01:38] the reason i ask is because of Bug #162090 [01:38] Launchpad bug 162090 in linux-source-2.6.22 "appletouch does not recognize trackpad in macbook3,1" [Undecided,Confirmed] https://launchpad.net/bugs/162090 [01:38] the patch on there is only for the gutsy kernel [01:39] have you checked to see if this patch has been added upstream? [01:40] going to do that now :) [01:40] because it probably wont get applied to the gutsy kernel now [01:41] yeah :) i am talking about the hardy kernel :D [01:47] nope it looks like it is not in upstream yet [01:48] * joejaxx is waiting for git clone to finish [01:49] Heh. That'll take *some time* :) [01:49] yeah [01:49] 57% down indexing [01:49] s/down/done/g [01:49] i should have ran that process on here [01:51] joejaxx: easier to use the web interface [01:51] web interface? [01:52] you mean kernel.ubuntu.com? [01:52] if so i do not have access to that :P [01:52] Darn. virt-manager doesn't seem to have an interface to "qemu -snapshot". [01:52] /git/ [01:52] http://kernel.ubuntu.com/git [01:52] it'll redirect you to the proper gitweb [01:53] yeah i do not have access to that [01:53] :P [01:53] RAOF: interesting [01:53] zul: unless i misunderstood your suggestion :) [01:54] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary [01:54] (i.e., it's just a Web frontend ala git.kernel.org) [01:55] yeah :P how would that help me create a commit diff? [01:55] :P [01:55] all done [01:57] zul: how goes fatx? [01:57] heh [01:57] :) [02:22] is there any HowTo on updating packages? [02:22] not merging, but updating [02:23] never mind, found it [02:27] https://people.fluxbuntu.org/~joejaxx/ubuntu/patches/bug162090.patch :D git diff HEAD ftw [02:29] night * [02:30] emgent: Goodnight [03:02] zul: you still around? :D [03:15] Anyone from the python team here? [03:16] vorian: ktorrent 3.0~rc1 uploaded, I mangled your interdiff a bit, added the epoch and made rules do 3.0~rc1 or ~beta1 instead of stringing them together [03:16] vorian: otherwise 3.0rc1 > 3.0, which will suck when they finally release :D [03:18] tritium: What do you need? [03:19] vorian: dget it when it shows up, I am submitting that for most absurd watchfile regex award :D [03:19] ScottK: was curious about using python-scipy. It wants to install python2.4. [03:20] ScottK: Was it not updated for 2.5? [03:20] I thought it was. [03:20] tritium: Which release are you on? [03:20] ScottK: gutsy [03:21] * ScottK looks [03:23] If I start python and import scipy, it works (that's with 2.5). [03:23] tritium: ^^^ [03:24] ScottK: okay, so at least it works. Any idea why it pulls in 2.4? [03:24] Thanks for looking into it, ScottK. [03:25] What do you mean pulls in 2.4? Do you mean requires 2.4 to be installed? [03:25] ScottK2: yes, installing python-scipy results in python2.4 also being installed. [03:26] tritium: It installs bit that are python2.4/2.5 specific, so it does properly depend on both of them. [03:26] tritium: This is a needed part of support for multiple python version. python-scipy isn't at all unusual in this regard. [03:26] ScottK2: okay, fair enough. Thank you. [03:26] tritium: Also, the "python" team on LP doesn't appear to actually do anything. [03:27] Is that so? Well, I appreciate your reply. Thanks again. [03:27] No problem. === bmk789 is now known as bmk789_sleep [03:36] to have a package on gnome-default-applications it must be done on the package or on the source? === _czessi is now known as Czessi [03:52] Don't know if this is a bug or not, but just upgraded using 'sudo update-manager -d', yes I had problems, but they're sorted, but the desktop background is the elephant theme, keeping the brown/orange Ubuntu look, so why are the titlebars blue? [03:54] Does anyone else have this? === bigon is now known as bigon` [04:15] must package.orig.tar.gz have 1 "toplevel" directory? [04:28] eddyMul: that is the convention yes. it should be - [04:28] LaserJock: so, dpkg-source will unpack 1 extra level? [04:28] ? [04:29] what do you mean by "1 extra level" [04:29] LaserJock: I'm looking at phpmyadmin's source [04:30] LaserJock: phpmyadmin_$${version}.orig.tar.gz has a phpmyadmin-${extra-string}-$${version}/ folder in it [04:31] LaserJock: but `apt-get source phpmyadmin` unpacks stuff into phpmyadmin-$${version}/ folder [04:31] LaserJock: so, somehow dpkg-source unpacks the orig.tar.gz, and does some renaming? [04:31] ah [04:31] I see [04:32] LaserJock: do I understand dpkg-source's behavior correctly? [04:33] I believe so, the convention is -/ so dpkg-source handles that [04:34] LaserJock: I see. [04:35] LaserJock: my orig.tar.gz so far doesn't have a "toplevel" directory, but `pbuilder` didn't seem to complain so far. Of course, I've never tested it by installing it..... :p [04:35] LaserJock: thanx for the clarification [04:35] dpkg-source treats tarball with single directory and tarball with multiple directories/files differently. [04:36] minghua: I see [04:41] persia: Hello [06:19] When reviewing, how much do we care about missing watchfiles? [06:19] s/do/should/ [06:19] hmm, depends on who you ask I'd think [06:20] Fair enough. [06:20] I think persia's on a watch file crusade so I think he'd tell you to care :-) [06:20] I personally think they should be included, but wouldn't necessarily not advocate soley on that [06:21] I don't think I'll care too much, since upstream appears to be gnome-look, and it looks extremely difficult to scrape the right info off it. [06:21] I'd probably go ahead and advocate but tell the packager to either add a watchfile or get-orig-source rule as soon as they can [06:22] at this point we we need to get stuff in the archive, we can fix bugs (like watch files) later [06:23] Well, this package has a bunch of other stuff broken with it anyway. [06:23] ah [06:23] well then I'd add a watch file/get-orig-source to the list then [06:23] Especially since it's a (kinda) repack. [06:24] oh yeah, then a get-orig-source sounds like a good thing to add [06:24] watch files are good. I'd reject on the absence of one without good reason. [06:24] It looks like upstream needs a good kicking though. [06:25] I personally wouldn't reject if that was it but I'd want the packager to say they will add one as soon as they can [06:25] (They distribute a tar.bz2 containing a tar.gz containing the source and another tar.bz2 containing the gtkrc themes) [06:25] but as long as there's other stuff then yeah [06:25] nifty :/ [06:25] Gah! Copyright headers are the bane of my existance. [06:25] hehe ;-) [06:26] Let's see if I can break revu with an over-long comment again! [06:26] I'm currently trying to figure out how the licensing works on a package that seems to have both gpl and Apple something licensed parts [06:27] I guess it can work in the same way as say Java and a GPL Java app [06:27] I need to work out whether I need to kill openssl-linkage for the shiny new "let's include yet another libtorrent in our source tarball" miro. [06:27] * LaserJock scratches his head a little [06:27] Fujitsu: Does "upstream uses sourceforge" count as a good reason for you? [06:27] I wouldn't think so [06:27] minghua: Isn't there the special sauce for sourceforge in newer debhelper? [06:28] * minghua wonders if it makes sense to use Debian's QA sourceforge redirect URL in a Ubuntu-only package. [06:28] watch files work with sourceforge [06:28] minghua: why not? :-) [06:28] RAOF: Yes there is, probably not in debhelper though. [06:28] LaserJock: External reliance? [06:29] * RAOF isn't sure where he got that meme from. I thought it was man uscan, but it aint. [06:29] minghua: we kinda shoot that ever release ;-) [06:30] given that the vast majority of our packages rely on Debian [06:30] but I get your point [06:32] LaserJock: Yeah, I was half-kidding. Not objection of using Debian services, just some strange feeling. [06:32] s/objection of/objection against/, I suppose... [06:38] persia: Hello [06:58] Now that I've reviewed the aurora gtk2 engine package, any kindly DD care to help me close the gtk2-engines-nodoka ITP? :) === Aloha_ is now known as aloha === aloha is now known as Aloha [07:17] good morning [07:20] hey geser! [07:23] Joy. Miro embeds deluge-torrent which embeds a libtorrent. [07:26] Here's one for those with more copyright patience than me: Miro is GPLv2. The libtorrent it includes links to openssl. The only mention of openssl in any copyright statement is "the copyright holders give permission to link the code of portions of this program with the OpenSSL library", in the build script. === bigon` is now known as bigon [07:27] The question is: "is it time to patch out the linking to openssl?" [07:30] * Fujitsu thinks it probably is. [07:30] Sounds like so. [07:31] Let's get a patching! [07:31] * minghua reads the situation as "it is fine to link libtorrent against openssl, it is not to link Miro against openssl". [07:32] And linking is transitive. [07:32] I'm talking about distributing compiled binary, of course. [07:32] Yes. [07:32] minghua: ah good point, I was kinda wondering why the statement wouldn't suffice, but that makes sense [07:33] LaserJock: Yeah. Basically, you need a more permissive license than GPL to link to OpenSSL. [07:33] Special exception is one case of the "more permissive". [07:34] * minghua also thinks Miro upstream needs to be hit by some licensing cluebat. [07:34] So, to make it clearer upstream would want to add the exception to *all* their licensing headers, right? [07:34] I'll bet they distribute binary Miro themselves, too. [07:34] Oh, hell yes. [07:35] And I get nice bug reports for it on launchpad :( [07:35] Such is life of package maintainers. :-) [07:35] Indeed. [07:36] * wallyweek is not away [07:41] I hope deluge has decided to link against a system libtorrent. [07:41] RAOF: Knowing them, I doubt it. [07:41] Well, browsing the _Miro_ source, there's a note from deluge saying "We really should link against a system libtorrent" [07:42] I hate it when A includes the source for B (which includes the source for C). [07:43] * Fujitsu looks at a lot of Java apps. [07:44] Yeah, and Java apps include .jars, which is essentially compiled binary stuff, AFAIK? [07:44] Yup. [08:11] Whoops. Accidentally adding "ll" to the top of a python script kills the build, would you believe? [08:11] Nice one. [08:12] I am nothing if not awesome. [08:20] Heya all [08:20] Hi there. [08:23] if anyone has time for a little revu i have two packages hanging in the site: lashwrap & phasex [08:23] both are linux audio production apps or the like [08:26] How many libboost packages will I need to add before miro builds >:( === civija_ is now known as civija [08:40] RAOF, check the build error which tells you the missing header file and search for the package which contains the header file in packages.ubuntu.com [08:40] maybe you knew that already, but that's my two cents [08:40] vemon: Oh, I know how to do that. I've just done that 3 times now. [08:41] ok :) i just built a package which also required a few libboost deps [08:43] Oh, arse. Miro, your build system is rotten. [08:45] Also, read the frikkin licenses of the source you blindly copy from other projects. "All rights reserved" is unlikely to be GPL compatible! [08:47] Alright! More licensing fun! [08:47] http://cooperteam.net/logger.cpp <- How GPL compatible is this? [08:48] good morning [08:48] hey dholbach! [08:48] Howdy dholbach. === doko_ is now known as doko [08:49] hey wallyweek, hey RAOF [08:49] morning dholbach! [08:50] dholbach: Know any good "my package is doing crazy things with licences. How can I tell if it's actually redistributable?" resources? [08:50] RAOF: https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright [08:53] Hi dholbach [08:53] hey geser [08:55] dholbach: Ta, should've tried gnu.org :) [08:56] RAOF: if you find good stuff feel free to add it to the guide [08:59] dholbach: could you please have a look at sdlmame? it should only need advocation after nearly 1 year of work :( http://revu.ubuntuwire.com/details.py?package=sdlmame [09:00] wallyweek: I'll put it on my list, but I'm seriously busy catching up with stuff and not feeling well today - so your chances are better if you ask everybody in the channel [09:02] dholbach: ok, thanks. I'll advertise it again later [09:10] * wallyweek bumps [09:23] Man, it's possible to write really *impenetrable* C++ if you try. [09:23] RAOF: Miro devs have managed it? [09:24] No, they write un-unittested python. [09:24] But they've outsourced it to deluge, who've outsourced it to libtorrent. [09:24] One of the libtorrents, that is. [09:25] Ah, lovely. [09:25] Hints for writing impenetrable C++: there's no shame in making your 3 page functions a single statement. Just have your .def() function return *this, and chain them for 50 lines! [09:26] Also: templates are your friends. You should include at least one library that contains no .cpp files, just turing-complete templates. [09:36] keen eyed, well caffeinated reviewers wanted for http://revu.tauware.de/details.py?package=sabnzbdplus [09:39] Hm. Rather than not build the ssl stuff, it might be easier to make Miro link against gnutls instead. Hm. === Allan_ is now known as Hit3k [09:51] yamal: You might want to loosen your conditions a little :) [09:51] persia: I'll stick with keen eyed and drop the narcotics, then :p [09:55] How about grumpy, miro hating curmudgeons who'll make up spurious licensing problems because they're sick of trying to make Miro redistributable? [09:58] * yamal grabs english language dictionary to look up 'curmudgeons' [10:03] Got a moment? Please take a look at openFX and get some karma (the general kind :P) http://revu.ubuntuwire.com/details.py?package=openfx [10:38] persia: Please give me an advice. Should I fix the w3c-dtd-xhtml problem in Ubuntu? The debian bug sems to be getting nowhere. [10:39] * slytherin is impatient about this. [10:39] slytherin: I'm inclined to say "just fix it", but I'm not certain about the side-effects of doing so. Do you have a patch ready? Can you show me a link? [10:40] persia: I don't have a patch ready. I was planning to just add symlinks as to avoid any other problems. [10:40] slytherin: I'm currently working on an NMU with some XML maintainer [10:40] * persia defers to man-di [10:40] man-di: Fine. Thanks for update. I will wait. [10:41] persia: pm? [10:46] could anyone please review sdlmame? come on, it should only need advocation! http://revu.ubuntuwire.com/details.py?package=sdlmame [11:10] blueyed: Congratulations! [11:24] hi is it possible to have a wiki page which lists of MOTUs with special interest. So that when I have to solve a problem with a specific package (say a GTK+ program) I can consult the corresponding MOTU accordingly. [11:36] heya * [11:40] slytherin> Well, the wiki lists MOTU teams [11:42] slytherin: MOTUs are encouraged to list their interests on their LP pages, but I don't know if everyone does this, nor if anyone scrapes this information for anything. Generally it's better to ask this channel or the ML, rather than a specific person. [11:44] hi persia [12:10] * persia leaves REVU comments on vamp-plugin-sdk, gnubversion, phasex, lv2core, lashwrap, and openfx. Packagers: please fix. Other reviews expected soon... [12:19] * persia notes there are still four packages waiting for review that were skipped last week: http://revu.ubuntuwire.com/details.py?package=mumble http://revu.ubuntuwire.com/details.py?package=qdevelop http://revu.ubuntuwire.com/details.py?package=ssm http://revu.ubuntuwire.com/details.py?package=cvc3 === asac is now known as asac_resurrected === ember_ is now known as ember [12:34] Hobbsee: Since you are the last person who commented on bug 146198 can you please take a look at it before feature freeze? (I hope you do) [12:34] Launchpad bug 146198 in kopete "Add libjasper-runtime to 'Recommends'" [Undecided,Confirmed] https://launchpad.net/bugs/146198 === asac_resurrected is now known as asac [12:34] slytherin: You're more likely to see the fix if you submit a patch :) [12:35] (and, yes, it's pointlessly trivial) [12:35] persia: What I am not sure of is if it should be 'Recommends' or 'Depends' [12:35] libjasper is the JPEG2000 library, isn't it? [12:36] minghua: yes [12:36] slytherin: "Recommends" is when any normal person would want it installed. "Depends" is when it breaks without it. In this case, "Recommends" is likely more appropriate. [12:36] persia: Ok. [12:36] On the other hand, check the main/universe boundary: this may be more complicated than it appears. [12:36] * minghua thinks in this case libjasperX should recommend libjasper-runtime instead... [12:37] But what do I know about KDE land. [12:37] * persia hasn't really looked, and suspects minghua is correct [12:38] Does kopete depend on libjasper in Ubuntu? It doesn't in Debian. [12:38] persia: libjasper-runtime is in universe. :-( [12:38] minghua: It does in gutsy. Not sure about hardy [12:39] slytherin: That's why the MainInclusionReport was invented :) [12:39] libjasper1 only Suggests libjasper-runtime in Debian, BTW. [12:41] minghua: last time I checked in gutsy, kopete showed me an error dialog that it needs libjasper-runtime for webcam functionality. Not sure if this would count as bad user experience. [12:43] * minghua considers such case perfect example for Recommends. [12:43] persia: responded to comments on openFX, if you could clarify the points I raised? [12:43] However, it really depends on if Ubuntu installs recommends or not these days. [12:43] * persia advocates sdlmame, more from an inability to find any issues, rather than from an interest in expanding multiverse [12:43] minghua: It will for hardy (even if it doesn't today). [12:44] Hobbsee: thx for sear [12:44] man-di: you're welcome [12:44] persia: Good to hear. Definitely a step on the right direction. [12:47] rexbron: 1) I forget which package had the empty directory. Run lintian or dpkg --contents foo.deb. 2) At least one binary package didn't contain /usr/share/doc/foo/copyright.gz (nor did /usr/share/doc/foo/ appear to be a symlink). 4) such is life. Please request one (and it's not a blocking issue). 8) Assuming you dropped an 'e', because "debian/rules is not a shell script". [12:50] hey all ... I have been trying to fix a bug and I get an error when I try to build the packaged. aparently some dependency has unmet dependencies... how can I go around it? [12:51] effie_jayx: Fix the bug that keeps you from fixing the bug you want to fix, and then fix your bug :) [12:51] persia, right. [12:51] * effie_jayx has never fixed unmet deps :S. [12:52] here goes nothing [12:52] effie_jayx: What did you do the fix the bug? Any changes to configure/makefiles ? [12:52] effie_jayx: It usually just needs a rebuild or small adjustment to build-depends or depends. Should be fairly easy. Good luck. [12:52] effie_jayx: which unmet dep stops you? [12:53] let me check [12:53] * slytherin is tired of lucene2 unit tests. They take too long even on a 2.6 GHz machine with 1 GB RAM. [12:53] effie_jayx: At least, make sure the unmet dep problem is reported to LP. [12:54] kdelibs4c2a depends on libarts1-dev (>= 1.5.0) and it does not install [12:54] I thought we were tossing arts for hardy. Is that not the case? [12:55] effie_jayx: When did you do - sudo pbuilder update'? [12:55] That's probably going to be a hard one. [12:55] effie_jayx: I mean when was the last time you did it [12:55] slytherin, a two days ago maybe [12:56] slytherin, I am trying again now and see === \sh_away is now known as \sh [12:57] persia, another aolsver4 breakage in bug 184923, hooray! :) [12:57] Launchpad bug 184923 in aolserver4 "package aolserver4 4.5.0-14 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/184923 [12:58] DktrKranz: There's also the libldap transition. Why do we keep aolserver around again? [12:59] persia, dunno, I'll have a look at it later, I think we should call ldconfig.real again. [13:01] DktrKranz: I thought the package was split into aolserver-core and aolserver. Perhaps the relationship needs to be a Pre-Depends? [13:01] (where aolserver-core was really libaolserver) [13:02] persia, it won't fail if installed from nothing, probably it will during some upgrades [13:03] I'll try on Debian too, let's see if frankie has a final solution about it [13:04] AnAnt: usplash-theme-ubuntume commented. Borderline, and a strong argument would convince me to advocate. [13:04] DktrKranz: Thanks. Good luck with that. [13:08] Good morning all. [13:08] morning ScottK [13:08] morning :) [13:08] hi all [13:08] Morning ScottK. [13:09] Hello Hobbsee, vorian, mruiz, minghua, and whoever else decides to say hi. [13:09] effie_jayx: ScottK may be the person you want to talk to about the kdelibs4c2a unmet deps. [13:09] <\sh> aeh moins ;) [13:10] Hello \sh. [13:10] <\sh> bah I hate wine ;) [13:10] minghua, great.. I am updating pbuilder atm so I shall tell you in a couple of minutes [13:10] \sh, don't blame it on them... ;) [13:10] <\sh> effie_jayx, hehe.. [13:12] \sh: Don't hate WINE. Hate the reasons it needs to exist. [13:13] <\sh> ScottK2, hehe...I added some fixes yesterday..and now I'm trying to fix this dh_strip thingy...a nightmare [13:13] persia: I remember that aolserver needed to call somewhere the real ldconfig to find the libs [13:14] slytherin, the update did it [13:14] oy [13:14] geser: Thanks for taking care of debhelper 6. [13:14] geser: That was back when the library and the daemon were in the same package (which caused a bit of pain for packages build-depending on it). There was a package split that was supposed to fix that. [13:14] unmet dep gone... :D [13:15] (Actually, the package split happened about a week before gutsy release, but I applied the ldconfig.real hack because it was less invasive at that late date). [13:16] persia: does a pre-depends guarantee that ldconfig will be run before aolserver is tried to start? [13:16] * persia comments on extremetuxracer, and heads off for the evening, encouraging others to clear REVU [13:17] geser: I believe Pre-Depends means the package should be installed and configured before the depending package is installed. I could misremember though (and I'm at the very tail of my day, so not thinking very clearly). [13:17] geser: It should, but use of pre-depends is discourages. [13:17] discourages/discouraged. === santiago-php is now known as santiago-ve [13:18] persia: No, "installed" is very vague in this context. You want "unpacked" for Pre-Depends. [13:18] Anyway, nobody should install aolserver4 on general principles, and the packages that build-depend upon aolserver4-core should work fine. [13:18] minghua: Ah. That's not enough (unless we do ldconfig.real). [13:19] Someone mind reviewing http://revu.tauware.de/details.py?package=alliance === Hobbsee is now known as LongPointyStick [13:21] thnx persia [13:24] Hello LongPointyStick [13:24] Hi all [13:24] hi tuxmaniac [13:25] DarkSun88, heya [13:25] Hi emgent [13:44] Greetings everyone... [13:44] persia: thanks for your review on sdlmame! :) [13:46] Our project memaker.org has a package now. It has been accepted into Ubuntu Universe but we don't have a consistant packager is there someone that can help us out? None of us know how to package, and we don't want a buggy memaker in Ubuntu. :( [13:47] <\sh> encompass, what's the name of your package? [13:48] <_MMA_> encompass: If you learn and manage the package in BZR it can be easy to get someone to push you changes to the archive. [13:49] <\sh> hmmm... [13:49] \sh: memaker [13:50] <\sh> memaker source package is in the archive, packaged by pete ...but no binary package ... [13:50] memaker needs to be compiled? [13:50] <\sh> ah it's still in the newqueue [13:52] <\sh> encompass, ask pete savage if he's willing to main your package in general (cbx33 is his nick on irc.freenode) [13:53] <\sh> s/main/maintain/ [13:59] \sh: you mean, like in the main repo? [14:00] <\sh> encompass, nope...maintaining ;) taking care of the package :) [14:00] oh wait.. hehe [14:00] yeah... I don't think he can [14:00] we are good friends [14:00] we would have said if he can maintain it... [14:01] but with his new job and kid on the way, he already has WAY to much to be bothered with me. [14:01] he did it as a favor for me. [14:08] <_MMA_> _MMA_: Like I said, you setup the source package in BZR and make the changes yourself its trivial to get someone to push it to the archive. [14:08] hi, having problems packaging my shared library. I've been going at it for the last two days. Anybody out there willing to help, thanks! [14:10] is there something to help me do that? [14:11] it's in bzr now [14:12] but I don't know how you want it setup [14:12] I think I'm almost there, but when I check the resulting deb the lib is not there. I'm using cmake for building and it creates the debs using pbuilder. I guess I'm messing things up with shlibs or so [14:12] <_MMA_> encompass: Its not how "I" want it setup. :) [14:12] <_MMA_> Gimmie the project link in LP. [14:13] http://sourceforge.net/projects/tuxcap [14:13] <_MMA_> _MMA_: #bzr will also help. [14:13] anybody mind reviewing http://revu.tauware.de/details.py?package=alliance [14:14] I've also the correct changelog, copyright etc. I could send you what i've got up to now cause I'm curious what I'm doing wrong [14:18] _MMA_: are you talking to me? [14:19] <\sh> bah I'm rich now ;) [14:19] <_MMA_> encompass: Yeah. Bad paste. [14:19] alrighty [14:19] I am asking there [14:22] * ScottK is about to start reviewing sdlmame. [14:25] \sh: did you win in the lottery? :) [14:26] <\sh> geser, hehe..na got my last salery from my former company and the compensation :) [14:28] persia: FYI ... I am able to reproduce the TestSort unit test failure in lucene2 when trying to build with GCJ. Found a reference to the same on Debian pkg-java list - http://lists.alioth.debian.org/pipermail/pkg-java-commits/2007-August/003771.html [14:33] hid [14:33] hi [14:37] I have a question... I have been fixing a typo in a man page... checking through debian/control I see that the maintainer is not MOTU... it's jriddell. can I still send in my patch? if so ... who do I assign for package sponsorship [14:38] anybody mind reviewing http://revu.tauware.de/details.py?package=alliance [14:38] effie_jayx: What package? [14:39] kmail [14:39] its in kdepim [14:39] it was in the bitesize bugs [14:40] effie_jayx: It's in Main, so file attach a debdiff to the bug and subscribe ubuntu-main-sponsors. [14:40] That's a big package, so the Kubuntu devs will probably wait to bundle that fix with others to upload. [14:41] ScottK, good then thanks [14:42] effie_jayx: Also, if you're interested in KDE thinks, you can join us on #kubuntu-devel ... [14:42] effie_jayx: I see you're there already. [14:43] ScottK, yes :D, I am trying kde and I things might get interesting in the KDE front [14:44] effie_jayx: Great. We can always use more help. [14:50]