=== sysman is now known as MTecknology === tuantub_ is now known as tuantub === MTecknology is now known as \MT === \MT is now known as MT- [03:29] Hey everybody, could some motu review/advocate the harpia package ( http://revu.ubuntuwire.com/p/harpia ). It is a python app to generate computer-vision/image processing c code from block diagrams. It has alreade been uploaded to archive but got rejected due to some dependencies issues that were already fixed. Thanks a bunch! === Amaranth_ is now known as Amaranth === MobileMyles6o7 is now known as TwoToneSpirit [06:30] good morning [06:30] hi [06:31] hi ajmitch [06:32] * ajmitch waves farewell to the laptop [06:34] * hyperair has just written a one-liner, crude pull-revu-source script =\ [06:37] hyperair, Um, why not just use dget? [06:38] persia: maybe it does something like pull-revu-source indiana-jones-and-the-last-crusade [06:39] I generally like to read the comments anyway, but perhaps my URL dragging methods don't work for everyone. [06:46] persia: the script uses dget. the whole point is to pass it a package and dget the dsc without needing to launch a browser [06:50] * kb9vqf says a few nasty things to his laptop [09:49] geser: https://bugs.launchpad.net/bugs/372704 \o/ [09:49] Ubuntu bug 372704 in soyuz "expose Signed-by and Changed-by via API" [High,Fix committed] [09:54] that was fast, perhaps it's on egde tomorrow so I can adapt your other change to use it [09:54] :) [09:57] any docbook experts here? [09:58] slytherin, You might try #ubuntu-doc, unless it's not Ubuntu-related. [09:59] No. It is not ubuntu related. [09:59] Not sure if they would help then, although they do tend to use docbook a lot. They might trade for some good writeups of some of our tech :) [10:01] I have very specific question about list item. [10:01] slytherin: you make me remember that I completely forgot that w3m-xxx issue... [10:03] :-) === asac_ is now known as asac [10:47] What is the correct way to drop a binary package from a source package if the binary has an (= ${binary:Version}) depend on another -- libgnomescanui0: Depends: libgnomescan0 (= 0.4.1-0ubuntu4) but 0.6.2-0ubuntu1 is to be installed. [10:48] gnomescanui0 has been dropped [10:54] what happens if you simply don't build it anymore? [10:54] I don't see the problem currently [10:55] it breaks the dependency on the previously installed version (which no longer exists) [10:55] conflicts on the new libgnome0 could work [10:57] don't both binary packages come from the same source package? [10:57] if they do, won't it suffice to upload another version without the dependency? [10:58] they do, and that is what happened [10:58] but aptitude doesn't like it [10:58] you need to transition the rdepends of libgnomescanui0 anyway, after that it should be safe to let apt remove libgnomescanui0 during dist-upgrade [10:59] there are no rdepends [10:59] what does aptitude full-upgrade say? [10:59] that's what I was doing [10:59] doesn't aptitude do a safe-upgrade by default? [10:59] yeah it does [10:59] dunno, but I explicitly did full-upgrade [10:59] i.e. it won't remove packages? [10:59] hmm [11:00] if you explicitly did, then it shouldn't be an issue [11:00] :( [11:00] what does apt-cache policy libgnomescanui0 say? [11:00] apt-get does the right thing here btw [11:00] eh? hmm [11:00] aptitude fail =( [11:01] doesn't have aptitude an option to explain why it choose a specific solution? (I don't use aptitude myself) [11:01] 17:47:59 What is the correct way to drop a binary package from a source package if the binary has an (= ${binary:Version}) depend on another -- libgnomescanui0: Depends: libgnomescan0 (= 0.4.1-0ubuntu4) but 0.6.2-0ubuntu1 is to be installed. [11:02] and the first solution it proposes is to hold back gnomescan0 [11:04] Laney: how about libgnomescanui0 provides libgnomescan0? [11:04] haha [11:04] horrible :( [11:04] =p [11:04] why was libgnomescan0 removed anyway/ [11:04] How can there be a source package in the repository without any binary packages? [11:04] That seems to be the case here http://packages.ubuntu.com/search?keywords=gnome-shell&searchon=sourcenames [11:04] ui was removed, upstream doesn't do it any more [11:04] cyberixae: hasn't passed binary NEW is my guess [11:05] hyperair: if I run aptitude full-upgrade a second time after the rest of the upgrades are done it wants to remove it this time [11:05] * Laney shrugs [11:05] Laney: ah. i've seen something like that before. [11:05] cyberixae: failed to build yet (depwait for gnome-shell) [11:06] different proposal based on when you do it, weird [11:06] more like based on what's remaining =\ [11:06] I tought you'd normally fix that kind of stuff before uploading the source [11:06] but those two packages don't affect anything else [11:06] do we support EeePC or better yet Eeebuntu? [11:06] no [11:07] that's a third party project afaik [11:07] thank you so much :) [11:07] we are responsible for the packages that get installed though [11:07] cyberixae: we usually try to minimize build errors but it doesn't work out in all cases [11:07] Laney: thanks [11:07] it's perfectly fine for stuff to depwait [11:08] let computers do the boring scheduling work once you know it all fits together fine [11:09] you waste buildd time =p [11:09] hardly [11:09] hardly, but the time still exists =p [11:10] which time is more valuable? [11:10] uh what? [11:10] computer time or developer time [11:10] heh it depends =p [11:10] but in this case i'd say developer time [11:11] you could have cron or at dput it for you, though =p [11:11] heh [11:12] ! [11:15] oho [12:42] Could do with some help removing LVM snapshots created by sbuild: http://dpaste.com/64974/ [12:43] wait [12:43] no, can't lvchange -an the snapshot either === ogra_ is now known as ogra [13:28] Heya gang [13:50] greetings db [13:50] greetings bddebian [13:50] Hi highvoltage === txwikinger2 is now known as txwikinger_work [14:14] Transferring an unanswered question from the #ubuntu-classroom dh7 session: How do you run conditional logic that must be run only when building the arch-indep packages - i.e. not on the non-i386 buildds? [14:14] I suspect the answer may involve shell conditionals testing the output of dh_listpackages, but would welcome comments on whether this is the "right way"/ [14:17] maxb: would this be having build-arch and build-indep, or just the usual binary-arch and binary-indep split for install/creating the deb? [14:17] maxb, You add a binary-indep rule, and do some stuff before/after calling dh binary-indep [14:18] What about stuff you need to do in the middle of the dh sequence? Example: python module package installs usr/lib/ into foo and foo-common. Then deletes *.so from the indep package and everything except *.so from the arch-dep package [14:18] That sort of separation belongs in your dh_install hint files, I think. [14:19] so it builds into debian/tmp, and foo.install vs. foo-common.install do the split. [14:19] (and foo-common install is tossed for non-arch-all builds) [14:22] You can't say debian/tmp/usr/lib/!(*.so) in an .install file, though, can you? [14:22] dholbach_: a word in private? [14:22] alourie: sure === dholbach_ is now known as dholbach [14:23] maxb, Sure you can, but generally you just say "usr/lib/*.so" or some such, without the debian/tmp and let dh_install figure it out. [14:24] Just need to use valid globs as parsed by dh_install (I forget if these are POSIX or perl) [14:25] Hmm... note I used a bash extended glob above - I don't think you can actually translate that into anything dh_install will process [14:27] Well, if dh_install uses shell globs, you can force make to use bash, but that's considered a (mild) packaging bug. [14:27] Check the dh_install code. [14:29] dh7 doesn't seem to be suited to doing actual arch-only builds though [14:29] No, it's perl globs, and they can't do what I want, which returns us to the initial question [14:29] james_w, How do you mean "arch-only"? [14:29] "dpkg-buildpackage -B" [14:29] maxb, Um, there's nothing a perl glob can't match, the syntax just gets ugly. [14:30] write me a perl glob which says "all files in usr/lib/ except ones matching *.so" and I'll believe that [14:30] They just aren't expressive enough for this [14:30] all files with an even number of matched and nested brackets? [14:31] maxb: that's possible in perl [14:31] maxb, I'm not actually going to do that, but I'm convinced it's possible because perl was invented because awk globs were insufficient for a certain class of accounting file review activities. [14:31] Unless I'm totally missing something, it's not possible in a single glob expression [14:32] language-pack-en depends on language-pack-en-base, and the opposite, language-pack-en-base depends on language-pack-en. How can the a user install them? I've tried dpkg -i and it fails...(I'm trying to do something similar) [14:32] alkisg: give both at the same time to "dpkg -i" [14:32] alkisg, Have you looked at the contents, control, and maintainer scripts for those packages? [14:33] alkisg, Also, last time we talked about this, you were looking at Replaces. What happened there? [14:33] james_w: I've tried that, (for 2 similar packages of mine at least) and it failed, leaving the first of them in an unconfigured state. [14:33] persia: that's what I'm looking into, and I'm stuck with this [14:34] alkisg, Which bit is sticking? [14:34] The fact that I cannot install 2 packages that depend on each-other [14:34] (and the second one replaces the first) [14:34] Do I need a third package (like language-support-en) that depends on both of them or something? [14:35] maxb, persia: you can't do that with dh_install [14:35] alkisg, No, that doesn't matter. [14:35] james_w, Um, why not? That's how I do libraries when I package those. [14:36] alkisg, But you don't want circular dependencies anyway. That just leads to headaches. [14:36] persia: you have a glob to list all files in /usr/lib except for .so? [14:36] Well, no, I list the files I want installed. But I don't see any reason why one couldn't construct a nifty glob. [14:36] * persia is pedestrian about these things [14:36] persia: It's not possible. Perhaps you're confusing globs and regular expressions [14:36] persia: I'm saying you can't construct a nifty glob [14:37] persia: circular dependencies seem a headache to me too, but I just thought I'd use the same (=similar) dependencies that language-pack* uses... OK, I'll just dump one dependency :) Thanks! [14:37] dh_install uses a non-nifty glob [14:37] Ah. That's unfortunate. [14:37] maxb: so you can either be a bit more explicit in the install files, or use an override and rm and just list usr/lib/* in each [14:38] alkisg, If you want to use the same dependencies, you can, but you get to figure how the relation (and looking that those packages is probably your best guide). The constrant recommendation is to not introduce circular dependencies. [14:38] (in bash there's a GLOBIGNORE=*.so for this - ignore me if that's irrelevant) [14:38] alkisg, We try to avoid using bash as a backing shell for make in debian/rules [14:38] james_w: Yup, that's what I said 20 minutes ago, and then persia tried to convince me otherwise :-) [14:39] I'm moving my scripts away from bashisms too :) [14:39] maxb: well, you caused me to read the source of dh_install, so it wasn't useless :-) [14:40] So, i'm thinking that shell is the way to go here - if dh_listpackages | egrep -q '^foo-common$'; then indeponlystuff; fi [14:43] * persia reads more about globs, and gets annoyed at the lack of negation [14:44] maxb, Um, no. What precisely are you trying to do? [14:44] And when do you need it done? [14:45] I need dh_install to install usr/lib/ into a foo and a foo-common package, putting *.so into foo and not *.so into foo-common [14:45] And you can't determine !*.so in advance? [14:46] It could be done, but it would be somewhat more fragile to upstream changes [14:46] Well, yes, but that's often a good idea when dealing with libraries. [14:47] But the other option is to have your build rule depend on build-arch and build-indep [14:47] No, that won't help. You just have a single build run. [14:48] Right. Got it. [14:48] Or maybe not. [14:48] In a dh6 world, I'd just use binary-arch vs. binary-indep - simple [14:48] Just be careful with upstreams. [14:49] maxb, binary-arch and binary-indep still exist in dh7. [14:49] But dh_install runs in build. [14:49] (or rather, in install, but build depends on install) [14:50] build depends on install? [14:50] persia: could you give me your advice on one last thing? I built the "base" package with all the files in it. Now I'm trying to build the "differences" package that only contains a few of those files that needed to be modified. [14:50] Am I understanding this correctly in that I need to copy the modified files to a different directory before I make the "differences" package? I mean that the usual "orig.tar.gz" method does not apply here, because there's no "original source" in the "differences" package, right? [14:50] No. I'm wrong. install depends on build. [14:51] (I'm probably not making any sense :() [14:51] alkisg, I don't know how to advise you. I don't think following that model is the right way to handle updates, although I understand that you do, and your arguments. [14:51] But if you must do it that way, the differences package as native is likely least bad. [14:51] maxb: do you really mean foo-common from /usr/lib? [14:52] maxb: the package puts arch-indep things in /usr/lib? [14:52] Ah, good point! [14:52] I do. Python (a bit perversely, I accept) puts *.py in /usr/lib [14:52] maxb, Does it put it directly in /usr/lib, or in /usr/lib/something? [14:52] persia: but is there a way to handle it as not-native, while preventing it from being 100Mb? [14:53] /usr/lib/pythonX.Y/dist-packages/... [14:53] alkisg, Yes, but that's probably even worse. [14:53] maxb, Then just have foo-common.install contain usr/lib/python?.?/ [14:54] The *.so files are *also* there [14:54] (or specify more closely if you know the values of X and Y) [14:54] persia: OK, I don't want to take any more of your time. I appreciate all of your help, thanks a lot. :) [14:54] maxb, In the same directory as the .py files? [14:54] yes [14:54] I don't think they belong there. [14:55] Ugh, or maybe they do. [14:55] That's just broken. [14:55] nope [14:56] well, not for python [14:56] Well, yeah. I claim python is broken, not the specific package. [14:56] maxb: can you just have *.py in foo-common.install and *.so in foo.install? [14:57] most packages don't bother with a common for this though [14:57] For added fun, there's multiple levels of directory structure [14:57] nice [14:57] maxb, Don't bother with -common. That's going to be easier. [14:57] Unless the volume of arch-indep data is so large to make it very useful. [14:58] 1.1MB indep vs 55K archdep [14:58] :-) [14:58] The package is mercurial, fwiw, which currently has a question in the changelog from the Debian maintainer wondering what the proper way to do this is. [14:59] arch:all python packages should not have files in /usr/lib (hint: /usr/share/pyshared) [14:59] And that's the key. It was broken. [14:59] Fix the build system :) [14:59] No. The files *are* in /usr/share/pyshared by the time the build finishes [14:59] Or live with arch-dep [15:00] maxb, So, what's the confusion then? foo.install has usr/lib and foo-common.install has usr/share [15:01] dh_install has to separate the upstream-style installation into two packages - dh_pysupport only runs later, and rearranges the structure [15:02] dh7 doesn't seem to call dh_pysupport, unless it's a hook. [15:03] it's an addon [15:03] /usr/share/perl5/Debian/Debhelper/Sequence/python_support.pm [15:04] Hrm. And I suppose it works the way it does for legacy reasons. [15:08] .py files should be installed to the standard location (/usr/lib or /usr/local/*/dist-packages), dh_pysupport will move them to /usr/share/pyshared [15:09] /usr/share/pyshared should *not* be used in setupy.py's install [15:09] POX, So, how should one construct dh_install hint files to split a package? [15:10] make sure you use one dir only (force python2.6 to install to site-packages, without local) and then use something like /usr/lib/*/site-packages/foo/bar.py [15:11] (in package.install file) [15:11] maxb, ^^ [15:20] persia: maxb: maybe '*-packages/foo/bar.py' will work as well (you'll not have to touch python2.6 stuff then) === vorian_ is now known as vorian [15:29] geser: maven-plugin-tools needs a class which is not available in any of the packages libraries. So untill the library is located and packages, the maven work can not continue. I have asked Ludovic Claude for help as he is working on the maven stack in Debian. [15:42] what's the best way to add a png icon to a package? base64 encoded? [15:46] Hello, should I subscribe u-u-s to such a bug: LP 397456 [15:46] Launchpad bug 397456 in parti-all "xpra should depend on x11-xserver-utils not x11-server-utils" [Undecided,New] https://launchpad.net/bugs/397456 === AnAnt_ is now known as AnAnt [16:02] slytherin: I'm intrigued... people can't even find the class? [16:06] does anyone else find "(Accepted)" being at the end of the subject suboptimal? [16:06] mails from soyuz that is [16:07] james_w: Woould you rather have it read something else or would you rather have "(Accepted)" somewhere else on the line? [16:08] maxb: I didn't find it in already packaged libraries. It is available somewhere in maven repositories in one of the jar files. [16:08] james_w: I do find this. [16:08] soren: in thunderbird's collapsed mode you only get the first half of the subject [16:08] so I have to expand it to see whether my upload was accepted or not [16:08] debfx: do you really need to add png icon? Won't SVG work? [16:09] james_w: I agree, Accepted should be in start [16:14] hm I could use another icon that available as svg [16:36] can i create multile pbuilder enviroments [16:44] Yes [16:45] SolarWar: yes [16:48] SolarWar: https://wiki.ubuntu.com/PbuilderHowto [16:49] :) thanks I found it already === vorian is now known as JSwormbot === JSwormbot is now known as vorian [17:19] Adri2000: HAPPY BIRTHDAY! [17:25] dholbach: ahaha, thanks, but it was 2 months ago, I was slow at updating the wiki page :p [17:28] Any motu there killing time? Could you check the harpia package ( http://revu.ubuntuwire.com/p/harpia ). It was uploaded to the archive but had some little issues (all corrected now, I think) and got rejected. I already fixed them and re-uploaded it. It is a python app to generate c source code for image processing/computer vision from block diagrams. [17:33] al-maisan: Hi, do you plan to finish the magicor merge (as I've seen that you have a potential merge in your PPA) or is this merge free to take? [17:33] geser: that was the idea, yes. [17:35] no hurry, I just wanted a confirmation as fabrice_sp asked me if this merge is free or not [17:35] geser: actually, I just checked my email again, "The source magicor - 1.1-1ubuntu1 is already accepted in ubuntu/karmic" [17:35] is this the version in question? [17:36] https://edge.launchpad.net/ubuntu/+source/magicor still shows 1.0-2ubuntu1 [17:36] but 1.1-1 is on the to-be-merged list [17:36] geser: I'll be busy with some other work in the next few days .. so if you feel like taking care of the package please do so. [17:36] don't mind me :) [17:37] * al-maisan understood that somebody else merged 1.1-1 in the meantime [17:38] hmm .. no .. just checked it. === dpm_ is now known as dpm === micahg1 is now known as micahg [19:19] * marienjoanny marienjoanny [19:23] Can someone please work on open-vm-tools? https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/277556 contains the addition of DKMS and fixes other bugs in open-vm-tools. The package currently in karmic is unusable. [19:24] Ubuntu bug 277556 in open-vm-tools "should build kernel modules with dkms" [Undecided,Confirmed] === zul_ is now known as zul [19:34] reto`: there is a link in the topic for what you are looking for [19:40] can anyone suggest how to modify the rules file,while creating a debian package [19:43] rohitkg: Do not. Ever. Neither debian or ubuntu would accept such a package [19:44] maxb:u mean to say,i shouldn't modify anything inside it [19:45] what about postinst and preinst? [19:45] I mean that it would be bad to have a rules file which modifies itself during the build [19:46] actually i'm facing problems in understanding the rules file [19:47] was libgdl-1-0 replaced with something in Karmic? [19:48] rohitkg: Ah. Well then, ask specific questions about what you'd like help with. [19:49] gnomefreak: libgdl-1-2 [19:49] geser: thanks [19:51] maxb:i want to know about the diff. macros used [19:52] rohitkg: the dh_ stuff? [19:52] rohitkg: That is too vague an inquiry to answer. Please clarify. [19:52] yeah those dh_stuffs === hggdh_ is now known as hggdh [19:57] gnomefreak: ok, thanks [19:58] reto`: np [20:01] YokoZar: I can tell you that clamd will cost you 5-6 seconds on boot if you start it at boot on a modernish laptop. [20:02] ScottK: ok then that's unworkable I guess [20:02] Should load it on first open of an app that needs to be scanned then [20:02] YokoZar: Makes sense. You'd still want freshclam to start on boot, but that's a lot lighter. [20:05] ScottK: Gives a good place to use the "have the wine swishing around the glass while loading" graphic I thought of [20:11] ;-) === ogra_ is now known as ogra [20:34] rohitkg: the dh_ commands are a set of related utilities known as debhelper, and provided by the package of the same name. They have manpages, which are a good place to start discovering what an unfamiliar one does. [20:34] ok,i'll be going through that [20:35] maxb:which tool do you prefer for building debian packages? [20:35] debhelper. cdbs is scary [20:36] ok,i'll start with it [20:37] You might want to review the logs of the packaging training session that was held today in #ubuntu-classroot [20:37] oops [20:37] #ubuntu-classroom [20:37] ok === thekorn_ is now known as thekorn [20:45] Makefile.in, which seems to have been generated automatically, can be manually modified? === dpm__ is now known as dpm [20:49] as long as you don't regenerate them yes, I usually patch both the .am and .in so the changes don't get lost if someone regenerates it [20:50] of course only if the change is small enough to be make by hand [20:54] geser, ok awesome, thanks. :) === _simono_ is now known as so === bastiao__ is now known as k0p [22:31] geser: persia: Can either of you please review http://revu.ubuntuwire.com/p/excalibur-logkit whenever you get time? [22:52] i am trying to pack a script which is not distribuited as a tarball, what should i do in order to not create a debian native package? [22:54] Legendario: create a tarball first. [22:54] Legendario: or create a package-version.orig directory [23:01] hyperair, the software is a bash script. Should i pack it as a tar.gz file and append .orig to it? [23:02] either way's fine =\ [23:03] the result should be the same anyways [23:03] hyperair, what about the package-version.orig directory? how does it work? [23:03] debuild will automatically generate the .orig.tar.gz from that directory [23:03] that's all there is to it =\ [23:09] hyperair, another thing... I am having a bad time on trying to create a watch file. Can u help me with that? [23:10] Legendario: watch files can only be created with tarballs [23:10] afaik [23:10] man uscan [23:11] hyperair, so should i ignore the error shown? [23:11] you'd probably be better off with a blank watch file and a get-orig-source rule. [23:11] create a blank watch file [23:11] with a comment saying why a watch file isn't applicable [23:12] and then add a get-orig-source rule to your debian/rules which automatically grabs the script and then dumps it into a tarball automatically [23:14] hyperair, any orientation on how to create a get-orig-source rule? [23:15] http://www.debian.org/doc/debian-policy/ch-source.html <-- scroll down to the part about get-orig-source [23:15] anyway i'm off to bed [23:15] good night [23:16] hyperair, thanks a lot [23:16] good night [23:16] you're welcome [23:17] Legendario: maybe http://www.eyrie.org/~eagle/notes/debian/scripts.html helps with creating get-orig-source. [23:17] Ampelbein, gonna readit. thanks [23:21] Hey everybody, could someone advocate the harpia package ( http://revu.ubuntuwire.com/p/harpia ). It is a python app to generate computer-vision/image processing c source code from block diagrams. It has already been uploaded to archive but got rejected due to some dependencies issues that were already fixed. Thanks a bunch! [23:52] can dh7 do cmake? [23:53] automagically like regular make I mean