[00:00] jscinoz: the .o file is the compiled files, they need to be linked to generate the program [00:00] it's an object file [00:00] and these are not included with libjpeg62-dev? [00:01] no [00:01] .o files get linked to create the program [00:01] jscinoz: well, they are assembled into a library [00:01] .so are what would be shipped in a library [00:02] alright, so when someone says " static copy of system library: please change the upstream Makefile to link against Ubuntu’s libjpeg62 instead of using the static copy inside the sources" what do i need to change the make file to reference? the headers? the actual source or what? [00:02] jscinoz: the makefile, in principle [00:03] >_< [00:03] ok. [00:03] so. [00:03] you want it to build against the headers I believe [00:03] jscinoz: it looks like the program gets linked to the set of .o's from the jpeg subdir [00:04] included with the upstream package is libjpeg source, ie .h and .c, it builds these into a bunch of .o it needs to compile, now the libjpeg62-dev package contains no .c, and only a few headers compared to those in the upstream [00:04] jscinoz: yes, and those headers are being included by other parts of the source [00:05] so... in the makefile, i've commented out where it compiles libjpeg from the source in the .c files. [00:05] jscinoz: you need to define to the compiler where to find those headers (if not in the subdir), and also where to find the library [00:05] /usr/lib/libjpeg.so.62 yes? [00:06] the first is usually with a -I switch, and the latter with a -ljpeg switch to the linker [00:06] jscinoz: yes, that's the one that replaces the .o files [00:06] oh [00:07] jscinoz: i.e. gcc -I/usr/include program.c -ljpeg -o program [00:07] so instead of the multitude of .o files on line 1000-1033, i just need the one .so? [00:07] jscinoz: yup [00:07] ugh [00:07] wish i found that out earlier. [00:08] the -ljpeg is all i need? [00:08] i dont need it to be -l/usr/lib/libjpeg.so.62? [00:08] jscinoz: no [00:08] jscinoz: -ljpeg [00:08] thank you [00:08] by default, the linker knows to look for libraries in /usr/lib [00:09] it knows their names always start with 'lib' and end in '.so' [00:09] so you only need to specify the "variable" bit = jpeg [00:10] hmm... what does this do "common-binary-predeb-arch" ? [00:10] and "common-binary-predeb-indep::" ? [00:14] mok0_, with -ljpeg can lines 1000-1033 be removed/commented out? or do they need to be changed somewhat [00:14] * mok0_ looks [00:15] and also line 153, and lines 1553-1554 [00:16] jscinoz: it's not that simple [00:17] >_< [00:18] jscinoz: you need to put it in the LDFLAGS variable, and in fact it looks as if you can do that when calling make [00:18] jscinoz: make "LDFLAGS=-ljpeg" [00:19] make[2]: *** No rule to make target `build/release-linux-i386/client/jcapimin.o', needed by `build/release-linux-i386/ioUrbanTerror.i386'. Stop [00:19] as i said, should line 1k-1033 be commented out? [00:19] jscinoz: yes that has to go [00:20] jscinoz: but this makefile is full of ifeq... endif sections so be sure to fix it the right place [00:20] new output: http://pastebin.ubuntu-nl.org/52947/ [00:21] jscinoz: looks like it's missing -lGL [00:22] hmm [00:22] because it didnt have that output before i removed its own jpeg stuff.. [00:22] same output with -lGL aswell >_< [00:22] Hmm [00:23] jscinoz: do you have someone where you live that knows about programming? [00:23] no. [00:23] hmm [00:23] jscinoz: Like I said earlier, what you are trying to accomplish is not easy [00:23] if i have it still compile its own libjpeg, but remove the lines referncing the *.o's, it gives this same output [00:24] so what i think is that -ljpeg isnt linking it properly or something [00:24] aye, same output with or without "LDFLAGS=-ljpeg" [00:24] jscinoz: it could be that it's a modified libjpeg [00:24] gah [00:25] jscinoz: I suggest you tell the motu that you looked into the problem with help on IRC and that it does not seem to be possible to use Ubuntu's libjpeg as a replacement [00:25] alright thanks [00:26] jscinoz: you can say you got indefined references and urbanterror [00:26] s version seems to be modified [00:27] alright [00:32] hi Hobbsee and minghua [00:33] heya LaserJock [00:33] Good evening LaserJock. [00:35] hmm whats a way to count the amount of lines output by grep/cat [00:35] grep -c [00:36] wc -l < file [00:36] Either works fine [00:36] should I write a patch to fix two dozen lines of this? "dpkg-source: warning: file qyoto/csharp/qyoto/core/QObjectExtras.cs has no final newline (either original or modified version)" ? [00:36] thanks [00:37] s/two/a/ [00:38] pochu: I haven't, it's a little complicated. [00:54] hmmm. Ok, so I've got qyoto merged into kdebindings, I'm just wondering how to generate the dsc since I'm getting these errors http://paste.ubuntu-nl.org/52952/ when I run debuild -S -sa -kE95EDDC9 [00:59] I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge [01:03] ryanakca: it looks like it's from source files and if it doesn't cause a bug I certainly wouldn't worry about it. [01:03] LaserJock: was that to the patch question or how to generate the dsc question? [01:04] patch question [01:04] okies, thanks :) [01:05] ryanakca: hmm, it kinda looks to me like there's a lot of stuff going on in the .diff.gz there [01:06] LaserJock: yes, well, I copied all of the qyoto sources into kdebindings-3.5.8 [01:06] ryanakca: The building error question -- the real problem are the two "cannot represent change" errors. [01:06] oh, that's going to be a bit difficult [01:06] right, what minghua said [01:07] you're trying to add source when packaging is not meant for that [01:07] yes... then what would be the appropriate way? [01:07] * ryanakca was asked to merge qyoto into kdebindings... generate a new .orig.tar.gz ? [01:09] ryanakca: I guess so [01:09] is qyoto distributed separately? [01:09] StevenK: Alright. Would be nice though if possible. [01:09] LaserJock: okies. take out the debian dir? [01:09] ryanakca: hmm? [01:09] LaserJock: yes, but kdebindings is just an assortment of libraries which are distributed seperately [01:10] take out the debian/ dir when making the .orig.tar.gz ? [01:10] how is it distributed? [01:10] ryanakca: first we need to figure out how you get the kdebindings .orig.tar.gz [01:11] how are they distributed? umm... part comes from http://www.kde.org/download , another comes from the xparts website, some from qyoto.org, kjsembed... umm.. unsure how it was all pieced together originially [01:11] * ryanakca reads the changelog [01:12] ryanakca: are you working on KDE3? [01:12] yes [01:12] k, I'm grabbing the source [01:13] I was originally supposed to merge the KDE3 package with the KDE4 package from debian, and then merge in qyoto into that merged thing, but then it was decided to just merge qyoto into kdebindings kde3 since the debian kde4 packaging wasn't advanced enough [01:16] LaserJock: step by step, what I did was copy the qyoto source dir to kdebindings-3.5.8/qyoto, merge kdebindings-3.5.8/qyoto/debian/* with kdebindings-3.5.8/debian/*, then remove kdebindings-3.5.8/qyoto/debian [01:16] right, and I think that's wrong [01:17] * ryanakca tars up kdebindings-3.5.8/debian and puts it on his webserver [01:17] hmmm. [01:17] the problem is that packaging isn't meant to add source to [01:17] so your .diff.gz can't represent binary files [01:18] and really, you don't want to do that [01:18] Heya gang [01:18] you want to add qyoto to kdebindings [01:18] * ryanakca nods [01:18] LaserJock: http://blog.ryanak.ca/kdebindings-3.5.8.debian.tar.gz [01:19] hey bddebian [01:19] so kdebindings is distributed upstream as a tarball [01:19] LaserJock: ok, to add qyoto, I'd have to generate a new orig.tar.gz? [01:19] Hello ryanakca [01:19] hmmm [01:20] and in that new .orig.tar.gz, I would have to remove debian/, then readd it, debuild, etc ? [01:20] well [01:20] hmm [01:20] this is a bit funky [01:21] * ryanakca nods [01:21] you want to take the kdebindings upstream tarball [01:21] unpack it, add your qyoto source, and retar it [01:21] ok. [01:21] but that means you're creating a new .orig.tar.gz for the same version of kdebindings [01:21] can I do that to the current .orig.tar.gz? [01:22] which is not great [01:22] hmm... Riddell is probably asleep atm... [01:22] ryanakca: I honestly don't know why you're not adding this as a separate package [01:23] LaserJock: it currently is a seperate package... [01:23] ah .... [01:23] LaserJock: *gets the logs from this afternoon describing what he has to do*, just a sec. [01:25] LaserJock: http://blog.ryanak.ca/kubuntu-devel.log [01:28] LaserJock: Do you have time to do some source backports for me (I need a core-dev to upload)? [01:29] ryanakca: well, honestly, you've got to talk to Riddell about that. That looks really odd/suspicious to me [01:29] ScottK: what do you need [01:29] ? [01:30] LaserJock: I need to you upload the 3 packages with debdiffs in But #183914. [01:30] Urgh [01:30] Bug #183914 [01:30] Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,In progress] https://launchpad.net/bugs/183914 [01:31] The won't get published until an archive admin accepts them, but I can't upload them... [01:31] The/They [01:31] LaserJock: ok, will do [01:32] superm1: Re bug #134197 - as far as I can tell, monodevelop doesn't need a build-dep on firefox at all (but it does need a dep on firefox, & I've filed a debian bug about that). [01:32] Launchpad bug 134197 in monodevelop "Please merge monodevelop 0.18.1+dfsg-1 from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/134197 [01:32] Hi all, I'd like to get involved in packaging, but a lot of the wiki's are confusing [01:33] RAOF, i didn't want to change things with the way it worked (it build-depends fine with it in there) [01:33] superm1: Quite true. It doesn't care whether or not you've got a firefox-dev build-dep or not :) [01:34] Can anyone help me get started please? [01:34] mcisbackuk: the Ubuntu Packaging Guide is a good starting place... [01:34] mcisbackuk: What would you actually like to do? [01:34] (Packaging is a broad field ;)) [01:34] RAOF, :) [01:34] mcisbackuk: http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html [01:35] i've had a look at the guide, but it's too broad, as you say, and I'll be honest I'm not that good on linux, but know pc's well (notdeveloper level) and would love to help out, maybe get rid of some on the wishlist to help you guys out :) [01:36] !packagingguide > ryanakca [01:36] superm1: Did you try to xul-1.9ify it at all? [01:36] LaserJock: oh? hmm... *checks the new link* [01:36] RAOF, i did not. [01:36] LaserJock: What do you think, are you up for it? [01:36] RAOF, i was more looking to get the merge done (given the time frame for the impending freeze) [01:37] LaserJock: heh, interesting. [01:37] mcisbackuk: ignore me :) [01:37] i havent used irc before how do i reply lol sorry i must sound really stupid now [01:37] superm1: Yeah, fair enough. I'll add that to my moderately large "before FF todo" list. [01:38] RAOF, yeah i'm looking for any other big ones that i know people are going to be annoyed by here if they aren't done at this point [01:38] ryanacka [01:38] oops [01:38] * RAOF would like to fix debian bug #461353 before FF, for example. [01:39] Debian bug 461353 in monodevelop "monodevelop: Fails to start without Gecko" [Normal,Open] http://bugs.debian.org/461353 [01:39] Argh, wrong one. [01:39] mcisbackuk: to reply, put the persons name : message. [01:44] Am I still connected? [01:44] mcisbackuk: Yes. [01:45] RAOF : Thanks [01:45] RAOF: Thanks [01:46] It's just that no one is saying anything much :) [01:47] That happens. [01:47] Ahh I see :) [01:48] I really wann get my hands dirty in linux lol [01:48] Are packages added to the repositories after the feature freeze do you know? [01:49] Only with a good reason. [01:49] So not anything silly like someone wants a game then [01:49] The only really hard freeze is at the end. All the other freezes mean that you need to make a good argument for why $PACKAGE should be an exception. [01:50] mcisbackuk: If you are just starting now, you probably want to start learning packaging through bugfixing and merges and then do new packages starting with Hardy +1 [01:50] What if it's built for 7.10 for example though? [01:50] Ahh I see... [01:50] 7.10 is done. Packages can be added/updates from Hardy in gutsy-backports, but that's it. [01:51] ok [01:52] I get it now :) [01:53] So I take it the only time software gets updated is with a new release, and its only bugfixes/security updates until then? [01:54] If you mean "after that" by "until then", basically yes. [01:54] Pretty much. And not just any bugfixes; they need to be important (for a certain definition of important). [01:54] From a user's point of view, at least. [01:55] Like data loss, corruption I take it? [01:55] That'd certainly qualify. Also regressions from previous versions (it works in Feisty, but not Gutsy) often qualify. [01:55] I see [01:55] mcisbackuk: you might want to read http://wiki.ubuntu.com/StableReleaseUpdates [01:56] Up until the beta, my usual definition of sufficiently importatant is someone thougth it was worth the trouble to come up with the fix. [01:56] Basically the risks of touching a package increase the closer to the release date we are. *After* the release date the risk is considered very nearly infinite, so you need a *very* good reason for touching anything. [01:57] Since everything is pretty much working at that point? [01:57] evening [01:57] That's the theory. [01:58] evening zul. [01:58] how is going ScottK [01:58] Theory's nice lol :) [01:58] zul: Pretty good. LaserJock's uploading the source backports for Dapper so we can get the current clamav into dapper-backports. [01:59] nifty [01:59] * RAOF needs to write a blog post on what "stable" means in the context of Ubuntu releases/archives. [01:59] I feel like I just did a masters thesis in packaging, testing, and release management. [02:00] So, sorry guys, what about bug #182693, it says needs-packaging, but its under mentoring available? Does that mean the maintainer is willing to help out someone new with doing it? Sorry you must all think I'm a pain in the backside. [02:00] Launchpad bug 182693 in ubuntu "[needs-packaging] monkeystudio" [Wishlist,In progress] https://launchpad.net/bugs/182693 [02:00] mcisbackuk: Part of what we do is help people get started. [02:01] mcisbackuk: You're fine. [02:01] mcisbackuk: The "in progress" status of that bug suggests that someone is actively working on it, so it might not be a good place to start. [02:01] ScottK: Thanks :) I just want to learn and help out [02:01] Then you're in the right place [02:03] Well I was looking at bug #184791, and it looked like a simple one to start off with, an alarm clock....but none of the guides tell you how to compile the binary/deb in python [02:03] Launchpad bug 184791 in ubuntu "[needs-packaging] Alarm Clock" [Undecided,New] https://launchpad.net/bugs/184791 [02:05] Or vice versa [02:08] mcisbackuk: We're pretty close to feature freeze. It's really unlikely that if you start a new package it would make it into Hardy, but you're certainly free to give it a shot if you want. [02:09] ScottK: Well I'd like to at least have a go, and try refining the skills needed to package. [02:10] mcisbackuk: It's much easier to start with bugfixing. Then you learn bits of packaging at a time. [02:10] RAOF: Don't you need to know more about the actual code then? [02:10] mcisbackuk: If you really want to take a shot at that one, find a similar package and see how they did it. [02:11] mcisbackuk: Do you code at all? [02:11] Nope - I think that may be the problem lol [02:11] It's not needed to package. [02:12] Thank god [02:12] look for bugs tagged packaging and bitesize [02:12] mcisbackuk: You don't have to understand the code in many cases. Some bugs are just in the packaging. Sometimes you can follow the bug to the upstream bug tracker, where there's a patch to fix it. [02:12] As in the original from the developers website? [02:12] Yes. [02:13] OK, maybe I'll start there :) [02:13] Can either of you point me to an idiots guide, if there is such a thing? [02:13] lol [02:20] mcisbackuk: and idiots guide to what? [02:21] LaserJock: Packaging, or as RAOF said re-packaging upstream versions [02:22] mcisbackuk: I think the best we've got really is the packaging guide http://wiki.ubuntu.com/PackagingGuide [02:22] LaserJock: OK I'll have to grit my teeth and buckle down and see if I can work it out, I won't let it get the better of me :) [02:24] mcisbackuk: packaging is not all that hard, but does require patience [02:24] there is a lot of stuff to remember [02:24] but it's definitely learnable [02:24] I have the patience and the time to do it definately, and I learn quick [02:28] well i managed to bork my system >_< [02:29] Doesn't sound good..... [02:30] jscinoz: This isn't a support channel. [02:30] i know :P just saying it casually lol [02:31] and zomg someone check the latest uploads of my urbanterror and urbanterror-data packages, i fixed some more stuff [02:34] one of my review comments mentions the "python packaging policy". but Google isn't helping me find that. Anybody have a link? [02:34] * bddebian would if it wasn't a 300+Mb data package :-) [02:35] wolfger: http://wiki.debian.org/DebianPython/NewPolicy [02:36] thx [03:16] man, busy day today. Got almost nothing done that I wanted to :) [04:21] ajmitch: You around at all? [05:42] good morning! [05:51] should i add "Uploaded to REVU: http://...." comment to a [needs-packaging] bug when i do a revu upload? [05:51] wouldn't hurt [05:53] if there is someone who knows that LASH is then here's one for review: N: The source package refers to a 'Standards-Version' that is starting to [05:53] N: get out of date, compared to current Policy. You can safely ignore [05:53] :D [05:53] N: this warning, but please consider updating the package to current [05:53] well not that [05:53] N: Policy. [05:53] http://revu.tauware.de/details.py?package=lashwrap [05:54] sorry for flooding :D middle clicking can be a little hazardous sometimes [06:32] vemon> commented [07:05] Heya [07:05] mornin [07:08] MOTUs, your comments please, for the latest and greatest sabnzbd package: http://revu.tauware.de/details.py?package=sabnzbdplus [08:56] cprov: how long does it take to revu to get your dput and email you? [08:56] Please be so kind to review one of my packages http://revu.tauware.de/details.py?package=alex4 and http://revu.tauware.de/details.py?package=speed-game. These packages are in a good state, all previous comments have been addressed [08:57] theseinfeld, you won't get an email... [08:57] but revu is updated once every 12 minutes [08:57] amarillion: yes, I can see that it was received, but I was waiting for the password so I could login... [08:57] amarillion: or did i get it all wrong? [08:57] :( [08:58] The password won't get emailed either. Just fill out your email address, and press login. It fails, then gives you the option to get a new password [08:59] Once you have uploaded a package to REVU, a password will be created for you. To get it, enter your e-mail address into the login box, leaving the password field blank, and click Login. Click Recover, and REVU will display an encrypted message with your password in it. [08:59] yes [08:59] amarillion: you are right... [09:00] yeah, do you get a password now? [09:00] amarillion: the problem is that i get this [09:00] No REVU account for theseinfeld@users.sf.net exists yet. [09:00] Did you sign up for the universe contributors team? [09:00] yes [09:00] also, do you have a GPG key uploaded to launchpad? [09:00] since yesterday [09:00] the key must be 2 years old [09:00] :D [09:00] yes yes yes [09:01] oh, it may take a day before the keys get copied to revu [09:01] so that may be the problem [09:01] ask persia to do a sync [09:01] whois persia [09:01] ok [09:01] I can wait also... [09:01] yeah, both will work :) [09:01] I was puzzled that the package is uploaded [09:02] did you upload a package? [09:02] http://revu.tauware.de/details.py?package=libdc1394-22 [09:02] which one? [09:02] hi [09:02] amarillion: libdc1394-22 [09:03] theseinfeld, would you like me to review it? [09:04] amarillion: on phone...just a sec [09:06] i created a bug to sync a package in hardy, do i need subscribe someone special so that it's taken care of? [09:08] philn: Yes, read https://wiki.ubuntu.com/SyncRequestProcess and follow instructions. === civija_ is now known as civija [09:08] ok; thx [09:09] Hey MOTUs. [09:09] and MOTu hopefuls. :p [09:10] hi deity [09:12] Hobbsee: lol [09:12] TheMuso: or is that info not public yet? [09:14] Hobbsee: Lets just say its not common knowledge. [09:14] fair enough [09:15] we'll just call you a deity without saying the reason tehn [09:17] is the backports repository the only place to get new upstream versions after an ubuntu release? [09:18] meaning: are bug fixes the only changes which are uploaded to the normal repos after release? [09:18] vemon: Yes, unless the new upstream version is a bugfix-only release, and fix important bugs. [09:21] !sru | vemon [09:21] vemon: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [09:22] hi all. Does anyone know if the java license related debconf preseeding on buildd works for both java5 and java6? [09:22] slytherin: yes, as both use the same debconf question [09:26] geser: One more question. Are 'arch: all' packages built on i386 only? [09:27] amarillion: back [09:33] slytherin: yes, the i386 buildd builds also the arch:all packages === jono_ is now known as jono [09:46] Hi dholbach [09:46] hey geser === dholbach changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com [09:48] * TheMuso can't see any major change in that topic. [09:49] * StevenK bites his tongue [09:49] StevenK: hardy hardy gar [09:49] s/gar/har/ [09:51] Please be so kind to review the following package: http://revu.ubuntuwire.com/details.py?package=libdc1394-22 . It should be in a good state as it has been discussed with some Debian people. Thank you [10:10] hi [10:19] slytherin: do you know if with sun-java[56] compiled code runs with kaffe? I'm looking at the statcvs package now. [10:21] geser: Not sure, never used kaffe. But if the code itself doesn't use any sun specific apis/extensions then it should run with any VM. And I guess kaffe supports Java 1.5 apis, but I will have to confirm. [10:21] geser: What is the problem by the way? [10:23] slytherin: no problem, just checking if depends line is still correct after changing build-depends [10:24] statcvs depwaits currently on sun-j2sdk* and I want to change it to the available compilers [10:25] geser: Why not try java-gcj-compat-dev? [10:25] I did, doesn't build with it [10:26] geser: can you paste the error somewhere? [10:26] btw: libjibx-java from yesterday doesn't build with gcj either [10:27] hmm. [10:29] geser: looks like kaffe is far behind other Free JVMs. http://www.kaffe.org/~stuart/japi/htmlout/h-kaffe-jdk14.html [10:32] slytherin: http://paste.ubuntu.com/3773/ [10:33] hi! [10:33] do you know if it exist any tool that allow to find out (and then install) all the build-dependencies of a package which is not debianized yet? I mean get all the libblabla-dev required at build time? [10:33] psicus78: no, try and error [10:34] geser: Check error number 8, It uses sun specific apis. [10:34] psicus78: you can read the README and/or INSTALL file and hope that it contains a list of requirements [10:34] psicus78: There are tools to help, but nothing like "apt-get build-dep" [10:34] minghua: yes, autotools should help [10:35] psicus78: you can also look which packages configure looks for [10:35] geser: correct, that's what I was thinking [10:35] \me plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines or single machines. Has support for sort 1st and sort last. I'm currently using it to power a cluster with a 46 million pixel display. It's cool so please revu it. [10:35] I was wondering if it would be possible to automate that [10:36] slytherin: so build-depend on sun-java[56]-jdk. is kaffe still a good candidate for depends? [10:36] I believe it is possible [10:37] psicus78: you could also check the included headers files [10:37] geser: No. Obviously in this case since the runtime should also contain those sun specific apis, only Sun JRE qualifies [10:38] slytherin: so I change "Depends: classpath, kaffe | java2-runtime" to "Depends: sun-java6-jre | java2-runtime"? [10:39] geser: only "sun-java5-jre | sun-java6-jre". [10:40] slytherin: thanks [10:42] geser: mmm...if the developer uses autotools he should check everything in configure.ac [10:42] geser: or configure.in [10:43] psicus78: yes, if the developer uses autotools [10:44] geser: I was wondering if there is something cannot be discovered automatically [10:44] now that you're talking about Depends... what does the {sh:Depends} (probably not typed correctly) actually do? [10:45] i've seen that in many packages and it seems it's not necessary to explicitly define deps for those packages [10:45] i'n debian/control i mean [10:45] geser: for instance in network-manager there is some code to check for wireless-tools but not using pkg-config, that could be a problem [10:46] vemon: dh_shlibdeps computes the runtime dependencies (by looking at the needed libs) and replaces the the placeholder with it [10:46] vemon: I'm not sure 100% but I think {sh:Depends} includes all the packages that contain the shared libraries required at runtime [10:46] vemon: what I want is build-time depends instead [10:48] geser: I must suppose that autotools is used, otherwise is impossible [10:49] Can someone explain to me process of merge? [10:50] slytherin: simplified: you take the latest debian revision and the Ubuntu changes, check which are still needed and apply them again [10:50] slytherin: you can use the output of MoM as a starting point for most merges [10:51] geser: Ok. And then which debdiff should I submit? Or should I submit interdiff? [10:52] slytherin: debdiff, between the debian revision and the new ubuntu revision [10:53] ok, thanks. [10:53] are there cases where sh:Depends is not enough? (i guess when some package is only suggested?) [10:55] vemon: it works only for libraries (lib*.so.*), so if your app is written in perl/ruby/python/etc. you need to figure the depends yourself out [10:56] vemon: another examples are -dev packages, where you want to install the correct version of the lib the headers belong to [11:00] can give me an example? [11:01] vemon: an example for what? [11:11] geser, for a dev package which requires a certain version of the lib it gives headers to [11:19] vemon: e.g. http://revu.tauware.de/revu1-incoming/libmirage-0801202040/libmirage-1.0.0/debian/control any other package on revu building a -dev package should have it too [11:26] geser: Are you able to search packages in debian unstable from http://packages.debian.org ? It times out for me for last few days. [11:31] slytherin: works fine here [11:32] slytherin: here too [11:35] geser, now i understand. i think i missed the part where you said the package to be built is a dev- package. :) [11:52] Hey everyone! Got one ack and looking for a second: http://revu.tauware.de/details.py?package=ubuntustudio-controls [11:55] * Hobbsee has a look === _czessi is now known as Czessi [11:58] morning [11:59] rexbron: surely setup.py should have some form of copyright notice too? [11:59] if the rest does? [12:00] Hobbsee: perhaps, but that is just calling a function. If by convention setup.py should have a copyright notice, I will include one [12:00] rexbron: will leave it, and see what the other archive admins say [12:00] ok [12:02] * Hobbsee acks, uploads === Sp4rKY is now known as Sp4rKy [12:02] :) [12:02]