[00:00] bug 340816 for python transition :) [00:00] Launchpad bug 340816 in fonttools "Depends: python (< 2.6) but 2.6.1-0ubuntu3 is to be installed" [Undecided,New] https://launchpad.net/bugs/340816 [00:05] <_cooper_> Hi. [00:05] <_cooper_> I'm about to generate an ubuntu package and found in the PackagingGuide how to name the package. [00:05] <_cooper_> "If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.1.1-1 package was changed by Ubuntu, the version string would be 2.1.1-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1)." [00:06] <_cooper_> The package I'm about to generate exists neither in Ubuntu nor in Debian. [00:06] <_cooper_> Should I better generate a debian package first and then the one for Ubuntu? [00:07] nhandler, I see your subscribed to gnome-scan (which should be gnomescan) on revu [00:07] <_cooper_> Of course this would cause some delay. [00:07] _cooper_: it's probably better to include it in debian as well :) [00:08] cody-somerville: I subscribe to all packages I comment on ;) [00:08] _cooper_: nothing stops you from trying in both "fronts" :) [00:08] <_cooper_> savvas: That's what I'm planning to do. [00:08] <_cooper_> Provide packages for both distros. [00:08] _cooper_: and when it is included in debian, you can bump the version from 2.1.1-0ubuntu1 to 2.1.1-1ubuntu1 :) [00:09] nhandler, How was the package the last time you looked at it? I' [00:09] <_cooper_> The quoted paragraph just made me think if I'm doing it in the wrong order. [00:09] nhandler, I'd like to get gnomescan into jaunty [00:09] cody-somerville: I honestly can't remember. I can take another look at it if you want [00:09] nhandler, that would be great [00:10] _cooper_: just follow my suggestion, I think there won't be any problems! :) you can send your ubuntu version to be reviewed at http://revu.ubuntuwire.org [00:10] <_cooper_> Ah. If this won't cause confusion, then I'll do both. [00:10] cody-somerville: Isn't gnomescan already in the repositories? [00:11] nhandler, it is, yup [00:11] cody-somerville: So why are you going through REVU? [00:11] nhandler, I'm not [00:11] nhandler, someone else is [00:11] Why? [00:12] nhandler, " [00:12] onkarshinde, this packaging is completely rewritten, just like the software itself, this is why i pass the process from the beginning. " [00:12] <_cooper_> savvas: Thanks. [00:12] directhex: hey, were you Cced on the reject of monodevelop-debugger-gdb [00:12] ? [00:12] cody-somerville: I guess that is what I get for not actually opening up the REVU page ;) [00:12] <_cooper_> savvas: Any other hints saving me to be flamed all over when submitting my first package? #-) [00:12] no, i wasn't [00:13] unless it happened since i last ran my mail client [00:13] mmm, no, nothing here [00:16] _cooper_, I'd recommend mostly focusing on the Debian route until after the Jaunty release. Before then, few people are likely to review new packages targeting Ubuntu. [00:16] * ScottK seconds to _cooper_ what persia suggested. [00:18] * pochu seconds ScottK's second :) [00:18] _cooper_: yes, when using debuild to build the package or the source, read the lintian errors and try to google them :) [00:20] <_cooper_> Good pont. [00:20] <_cooper_> +i [00:20] nhandler, do you want to take on getting gnomescan into jaunty? :) [00:20] nhandler, it would be much appreciated. [00:21] <_cooper_> due I'm using ubuntu on my laptop, I'm interested in an Ubuntu package myself to do some more longrun tests. [00:22] <_cooper_> I think I'll do two packages and send them off when they're done. [00:23] directhex: I got a REJECT, but no accompanying explanation [00:23] cody-somerville: I'm looking at it now. Is bersace still working on it? [00:24] nhandler, He commented on a bug recently hoping it isn't too late for jaunty [00:24] james_w, and monodevelop-debugger-mdb? [00:24] directhex: -gdb [00:25] james_w, you're right - mdb passed NEW [00:25] cody-somerville: Glad to hear that. I'll add a comment to the bug sometime tonight. If he keeps making the changes, I'll keep reviewing [00:26] nhandler, awesome. [00:28] er.. [00:28] gapti - do we need it? [00:28] its trunk wasn't updated since 2006: https://code.edge.launchpad.net/~gapti-dev/gapti/trunk [00:28] savvas: Is it broken? [00:29] ScottK: it needs python transition, I think it's easy, but I also think that it's not maintained upstream [00:29] If it's easy and not otherwise broken, then I'd transition it. [00:29] ah cool :) [00:30] Might be worth checking with asac or mvo to see if it's part of the current ThirdPartyApt plan. [00:31] If it's just duplicate to gdebi and friends, then dropping it might be useful, as it's Ubuntu-local. [00:32] never tried it, I'll give it a go :) [00:34] Hi, I'm seeing multiple additional LOAD_CYCLES on my laptop after about 2 minutes, should I be concerned? [00:37] wrong channel :p [00:53] opinion question: what would be faster, running my debian package through revu to update a package already in Jaunty or waiting for Debian's ftp-masters to move it out of the new queue? === asac_ is now known as asac [00:54] <_cooper_> Thanks for help, I think I'll return with some questions later... [00:54] binarymutant: We're past Feature Freeze for Jaunty, so is this a bug fix only change? [00:55] ScottK, there aren't any bugs in the package but the one in Debian is much more "cleaner" [00:55] should I just leave it alone? [00:56] So you got it into Ubuntu, then got an improved version into Debian that's still in New? [00:56] binarymutant: ^^ [00:56] ya [00:56] it conforms better to Debian's python-policy [00:57] I'd file a bugg with a debdiff to a fixed version in it. We generally only use REVU for new packages. [00:57] Then subscribe ubuntu-universe-sponsors. [00:57] Also make sure it works with Python 2.6 .... [00:58] I should send a post to ubuntu-universe-sponsors with a debdiff ? [01:00] cool thanks for the help, I found the wiki page for it === orly_owl_ is now known as orlyowl === orlyowl is now known as orly_owl_ === orly_owl_ is now known as orlyowl === orlyowl is now known as orly_owl_ === orly_owl_ is now known as orly_owl === rgreening_ is now known as rgreening [05:09] Is there an official "metapackage" that includes all of the tools listed here: https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20Tools [05:09] ? [05:11] I think it would be cool to have such a metapackage linked to from that wiki [05:21] kostmo: file a wishlist bug (of it doesn't exist yet) and maybe create it ;-) [05:21] sure, I'll look [05:28] bug 340901 for python transition :) [05:28] Launchpad bug 340901 in gapti "needs python 2.6 transition and porting" [Undecided,New] https://launchpad.net/bugs/340901 [05:29] savvas: your debdiff is a bit ugly (seems like your editor changed a lot of "empty" lines) [05:30] JanC: + Replaced lines with spaces (\s+) with empty lines [05:30] :) [05:31] I said that since I'm fixing the source, I might as well fix most of it :P [05:33] JanC: here's the build in case you need it: http://launchpadlibrarian.net/23743844/buildlog_ubuntu-jaunty-i386.gapti_0.0.2ubuntu4_FULLYBUILT.txt.gz [05:33] I don't need it, I just think it's wrong to make such changes... [05:35] JanC: the upstream hasn't updated the trunk/main series since 2006 [05:37] savvas: I think a patch to "fix" whitespace/empty-lines should be applied upstream (or in case upstream is dead, you could maybe fork it) and then pulled in in karmic koala [05:37] but that's just my "humble opinion" ;) [05:40] savvas, your changes makes a lot more complicated to review the changes. And I would say that to change the source, you should use a patch system, as it makes easier to identify where a change comes from [05:40] but I'm not a MOTU, so I could be wrong [05:41] well.. if anyone wants to make them as patches, be my guest :) [05:42] not the changes of spaces, for sure [05:42] I already patched a lot of sources, and I always used a patch system [05:43] anyway: you subscribed U-U-S, so let's wait for a MOTU to comment it [05:44] I've notified the original author about that bug as well [05:44] about the spaces, you mean? [05:44] savvas: You seem to have rewritten debian/rules, and made a whole lot excessive changes. [05:44] It's unlikely that anybody will sponsor that. [05:45] but dh_python is deprecated as far as I could read [05:46] Then you just remove it, without rewriting the build system and half of the upstream code. [05:46] oh well, the author might want to patch it upstream :) [05:46] We prefer to keep the tiniest possible diff against Debian. [05:46] the upstream code had to be rewritten, it wasn't working otherwise [05:47] it's not a debian package: https://edge.launchpad.net/ubuntu/+source/gapti [05:47] There are lots of spacing changes and importing things under different names, and using the print statement (which doesn't exist yet) and that sort of thing. [05:47] The same applies to the diff between as and upstream. [05:48] As much as it can be nice to play upstream sometimes, we are not upstream for gapti. [05:49] And doing this will ensure that merging the next upstream release is very, very difficult. [05:50] I suppose you're all right [05:51] wgrant: can you unsubscribe u-u-s until I sort this out? [05:51] savvas: I'm not in u-u-s, I'm afraid. [05:52] darn :\ well, I'll just put a comment to disregard that patch [05:54] savvas: Given the sad state of the old debian/rules, and the lack of the package in Debian, you can (and probably should) replace it. [05:55] I'm surprised it has gone so long without python-(support|central)... we were meant to get rid of them all years ago. [05:56] well I asked if it should be dropped from ubuntu, the general reply was "if you want to patch it, do it" - I guess they meant without so many changes :) [05:57] wgrant: but either way, I could do a patch without the empty spaces changes, but it still needs to be tampered with upstream code change, some modules have changed unfortunately [05:58] wgrant: I think you mean the print function instead of th print statement? [05:59] wgrant: I think that's not really an issue (although not needed yet) as it will work even in older python versions (normally) [05:59] JanC: That is of course what I meant. [06:00] But it's an unnecessary change, as it's not required yet, so we shouldn' [06:00] ... shouldn't do it. [06:00] OTOH, no need for it in jaunty yet, and an upstream change would be more useful indeed [06:00] savvas: Most of the files don't require any changes. [06:00] * wgrant -> gone. [06:04] eh, it was good for practise at least [06:05] ツ === teKnofreak is now known as techno_freak [06:10] Does anybody knows if we should repack upstream tarball if it's a bz2 instead of a gz? [06:11] I think that you can use bunzip2 for that fabrice_sp_ - and gzip to make a tar.gz :) [06:14] savvas, I was already repacking the tarball, as upstream was including debian directory, but with the new version, it's not the case anymore, so I wanted to get rid of that 'repacking'. Will play with watch options... thanks anyway! === fabrice_sp__ is now known as fabrice_sp [06:21] fabrice_sp: you're using watch to update it? you could try debian uupdate with watch, I think it automatically transforms tar.bz2 to tar.gz if I'm not wrong :P [06:22] savvas, yes: a watch file, with uscan in a get-orig-source in debian/rules [06:22] there is an option to uscan --repack that does the job ;-) [06:22] ah yeah :) [06:34] fabrice_sp, When using uscan --repack, please create a get-orig-source to do that anyway, and document it as a repack in debian/README.source. The md5sum won't match, so without the documentation, someone may feel impelled to investigate. [06:35] persia, ok. I'll update the README.debian to explain that. Thanks for the info! [06:35] Please don't. [06:36] README.Debian is intended to be packaging-specific end-user documentation. It should be used when the behaviour of the packaged software differs from the upstream behaviour. [06:36] debain/README.source is the appropriate place to put packaging-specific developer documentation, when it is useful to document what one has done for fellow developers. [06:38] * persia hopes the timing isn't such that that was missed [06:38] persia, I meant README.source. Sorry for the mistake [06:38] README.source is the file I was editing [06:39] Excellent :) [06:39] :-) [06:41] hm, I'm currently looking at a package coming from Debian without changes which doesn't have README.source like that despite being repackaged (AFAICS) ;) [06:41] Have to go now. Bye! [06:42] JanC, If it claims Standards-Version: 3.8.0, that's a bug. If it claims a lower standards version, it just needs to be updated. [06:43] it does say 3.8.0 [06:43] I'll contact the people involved as I know them [06:43] Double-check by reading debian-policy 3.8.0, but I believe that's a bug. [06:44] On the other hand, debian/README.source might still be optional with 3.8.0.0 (I forget precisely). [06:44] BTW: why should a bz2 source be repacked? [06:44] * JanC is a new at this [06:45] I think the debian packaging system needs an orig.tar.gz file [06:45] I wish all upstreams & distros would use lzma to minimize bandwidth ;) [06:47] I heard about a different system with patches for updates [06:47] delta packages ? or something like that [06:48] savvas: that's for binary packages [06:49] and fedora & opensuse are already using something like that AFAIK [06:50] There's ongoing work on the various archive software and build tools to use alternate compression mechanisms, but nothing widely adopted yet. [06:51] ah :) [07:05] hm.. I think I have a minimalistic patch now :P [07:05] http://paste.ubuntu.com/129654/ [07:06] good morning [07:06] good morning dholbach :) [07:06] hiya savvas [07:32] dholbach: you think the patch is good? :P [07:32] savvas: I think you put quite some work into it - as others said already: it's a good idea to get upstream to accept it and then make use of it, so we don't have to maintain a huge delta [07:33] savvas: I think you're doing great work [07:33] my motu-release friends: what do you think about bug 340008? [07:33] Launchpad bug 340008 in ubuntu "Please sync python-django-lint (0.7-1) from Sid" [Undecided,New] https://launchpad.net/bugs/340008 [07:33] ah ok :) [07:33] thanks! [07:34] ROCK ON! :) [07:34] I've send an email to wasabi, Jerome Haltom - https://edge.launchpad.net/gapti [07:34] ahhh ok, didn't know he's maintaining it [07:34] maybe I should send that patch as a bzr merge [07:35] he's not, the trunk wasn't touched since 2006 :P [07:35] but with a great message: "* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload.* Cleaned up and made first upload." [07:35] hehehe [07:36] anyway, I'll wait for wasabi to respond, then see what to do :) === pmjdebru1jn is now known as pmjdebruijn [08:48] james_w, any luck seeing why -gdb was rejected? [08:49] good morning! [08:50] does anyone know what does "-include" do in a makefile? is it like a comment "#include" ? [08:53] savvas, it changes how make reacts if the included file does not exist [08:54] savvas, install make-doc, and run "info doc" and type control-s and then "-include" (without the quotes) for the full story [08:54] ah cool [08:54] thanks liw :) [09:03] nhandler: hi [09:23] I think gdesklets needs just a rebuild, bug 336200 - someone should double check though, I always tend to make mistakes :) [09:24] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/336200/+text) [09:25] * savvas bbl === ScottK2 is now known as ScottK === jussio1 is now known as jussi01 [11:18] lo all. I've a bit of a nasty issue with ipod-convenience in jaunty alpha 5: [11:18] ipod-convenience: Depends: python-gpod but it is not going to be installed [11:19] python-gpod: Depends: python (< 2.6) but 2.6.1-0ubuntu1 is to be installed [11:19] blizzkid: python-gpod has to be rebuilt against python 2.6 [11:20] DktrKranz: so, basically I download the source of python-gpod and build it myself? [11:20] blizzkid: basically that's what needs to be done [11:21] we do exactly that in the buildds [11:21] dholbach: DktrKranz wants to invite you at our meeting... :P do you want to have a trip in italy, this month? [11:21] blizzkid, you can. apt-get source python-gpod, and go from there. Of course, this will solve your immediate issue, but not the general one -- unless you open a bug on it. [11:21] DktrKranz: right? :) [11:21] yup! [11:22] ok DktrKranz, is there a _good_ howto on how to start with src and build a .deb out of what I created? If I build it, I can as well build a .deb from it... [11:22] hggdh: I could maybe build a deb, and attach that to the bug report? ;) [11:23] blizzkid, a debdiff would be better, or even just a diff [11:23] hggdh: if you can point me to a howto on creating a (deb)diff, I'll gladly try to provide one :) [11:23] gaspa: when? I'm going to be quite busy [11:24] blizzkid, see (for starters) https://wiki.ubuntu.com/PackagingGuide/Maintenance [11:24] blizzkid: you can look at pbuilderhowto in the wiki, or better wait for a proper fix (it won't take too long) [11:24] but trip to Italy sounds great... in general :) [11:24] dholbach: :) 28th of march, the end of this month [11:25] dholbach: we're going to make it a cross-meeting, we plan to invite some DDs to work together with them, so both distros can receive attention :) [11:25] sounds great, not sure if I'll be able to attend though [11:25] k, I'll have a look hggdh and DktrKranz thx [11:26] blizzkid: I can't promise anything right now, but I will be able to look at it in the next few days for an official fix [11:26] DktrKranz, gaspa: Ma io non parlano italiano! [11:26] dholbach: well, we'll be pleased, but of course do as you can. :) [11:26] LOL [11:26] "parlo" [11:27] dholbach: it's not a problem, we have google translate in place :) [11:27] DktrKranz: guess what I used ;-) [11:27] that would be cool DktrKranz [11:28] btw, let me take this opportunity to thank all motu's for the great work. Been using Ubuntu since it appeared, and still loving it [11:28] gaspa: we need to setup a simultaneous translation for dholbach, what about totopalma? :) [11:28] DktrKranz: totopalma would be great! [11:28] :D [11:28] totowhat? [11:28] * DktrKranz moves to lunch now [11:30] dholbach: our trustworthy translator [11:30] ahh ok [11:31] DktrKranz: Bon appetit! [11:41] dholbach: How soon are you planning on starting those packaging lessons? [11:44] nhandler: I was thinking of waiting a bit to get more input and leave a bit of time until everybody read the proposal, then mail all the people who are interested to start planning [11:44] nhandler: what do you think? [11:45] dholbach: Sounds fine by me. Just be sure to give the people interested in leading a session enough time to prepare [11:45] nhandler: sure... thanks a lot for volunteering already! [11:45] :) [11:46] nhandler: as long as we don't have too high expectations on what people should deliver there and we're very inviting, we should be fine :) [11:49] dholbach: I think these will be a big success. Some will have more audience participation than others, but I think many people are interested in learning about packaging [11:50] yeah, I hope so :) [11:56] hmmz, I installed libgdk-pixbuf2 and libgdk-pixbuf-dev, but when running configure I get "checking for GDKPIXBUF... no". Am I missing something here? [12:16] What's the chance I could get this in jaunty+1? http://www.vergenet.net/~conrad/scripts/pants.html [12:17] lfaraone: Almost none. [12:17] lfaraone: Package it for Karmic and then have a backport. [12:20] hello. could you tell me, please, after i've done with building packages, is it safely to remove /var/cache/pbuilder/build/* dirs? [12:20] ScottK: that's *exactly* what I said, I was talking about getting it into karmic. jaunty + 1 == karmic :) [12:20] ia: I'd assume so. [12:20] lfaraone: Ah. I missed the +1. Sorry. [12:22] ScottK: I was refering to whether the package would be rejected for serving no useful purpose. (akin to "sl") [12:30] lfaraone: It's a game. I think games are fine. [13:03] Hi, I'm all new to packaging and whatever term you can mention, but I would like to learn how I can pack an app and send it off to a repo and whatever is between that. Can you guide me in the right directions with some references or something? [13:06] ChrisBuchholz: I believe https://wiki.ubuntu.com/UbuntuDevelopment is the canonical starting point. [13:07] ChrisBuchholz: there's also #ubuntu-nordic-dev if you'd rather discuss in Danish/Swedish/Norwegian. [13:08] ...or Finnish/Icelandic, I suppose, but I don't think you'll get a lot of response that way :) [13:14] Many thanks, Soren, I'll give it a shot, bye;) [13:30] persia, geser: I won't be able to attend the MC call today. Due to premature DST in the US, I have a conflict. [13:33] Does anybody know where I can get some documentation on the Gnome dbus multimedia keys framework? === ssweeny_ is now known as ssweeny [13:51] ripps: tried asking in #ubuntu-desktop? [14:24] persia: any idea what all changes are needed to visualvm packaging to compile it against latest netbeans packages? [14:28] slytherin, None at all, I'm afraid. [14:29] It is not a simple rebuild that is for sure. I tried some packaging changes the other day but was stuck and I have limited knowledge about visualvm [14:30] From the limited information I received, I think visualvm was one of the reasons that libnb-platform was versioned at a source level. [15:03] Heya gang [15:04] Hi bddebian [15:04] Heya geser [15:07] geser: hi, could you check bug 336200 when you find some spare time? I'm almost certain that it just needs a rebuild :) [15:07] Launchpad bug 336200 in gdesklets "Dependencies for gdesklets are no longer fulfilled" [High,New] https://launchpad.net/bugs/336200 [15:08] this is the pbuilder log of gdesklets_0.36-5 (the already existing version): http://launchpadlibrarian.net/23747311/last_operation.log [15:10] savvas: What are you expecting geser to do that you can't/haven't already done yourself? [15:10] ah so it's done? [15:11] Well I thought I need a second opinion just to be sure I am correct :) [15:11] OK. Fair enough [15:11] sorry to poke around :) [15:16] hm... [15:16] it seems to depend on python 2.4 still [15:18] ScottK: is there an environment variable I can set to use a specific python version? [15:18] or anyone? [15:19] savvas: specify it at the shebang of the script [15:21] I'll try that [15:21] thanks [15:23] hmm Could not import tiling module! [15:24] /usr/lib/gdesklets/utils/tiling.la [15:24] * savvas looks at the source code [16:11] er.. [16:11] after reading http://bugs.archlinux.org/task/12217 and a bunch of other sites, the error I get seems to be fixed in gdesklets 0.36.1 [16:14] I'll file a bug === zul_ is now known as zul === dholbach_ is now known as dholbach [16:51] nope, the debian version isn't working either heh [16:56] Hello, I'm trying to package a daemon. It provides an initscript which should go in /etc/init.d/. The problem is that dpkg thinks this script is a configfile, so it doesn't get removed unless --purged. Is this normal behaviour and how to get passed it? Is there a good (easy) example of a packaged daemon? [16:57] rulus: THats what happens normally, any package tat has an initscript doesn't have the script remove unless the package is purged. [16:58] ah ok, so nothing to worry about then :) [16:58] true, it's in /etc/ :) [16:58] rulus: no [16:58] thanks! [16:59] rulus: WHich is why you will see many initscripts depending on the binaries they need to function before they actually do anything. [16:59] rulus: s/depending on/checking for/ [17:00] TheMuso: ok, seems a good thing to do indeed [17:06] i am not so familiar with python, so how do i know what changes should be done for the python transition again? [17:06] the 2.6 transition [17:46] i only modified something in the control of a package, and run dch -i. however debdiff says debdiff: fatal error at line 266: Can't read file: ../espeak_1.32-0ubuntu1.dsc . What is the problem? i am just a beginner [18:01] come on? can't anyone give me a hand? [18:02] cristi: What did you feed debdiff? [18:02] ScottKi run it in the file with /debian [18:02] the problem is that it asks for espeak 1.32 and i have 1.36 as a .dsc [18:05] Generally it works best if you debdiff libmail-dkim-perl_0.32-1.dsc libmail-dkim-perl_0.33-1.dsc (for example) when both files are in the current dir. [18:06] ScottK: what are the 2 debdiff parameters? the i didn't see that in the wiki [18:06] It's the .dsc for the two package revisions your are trying to diff. [18:07] If you look at man debdiff you'll see there's lots of ways to do it, but that's what I always use. [18:07] ScottK: the second .diff is done by debuild ? [18:08] Yes. Debuild -S -us -uc your knew revision first. [18:08] Then you'll have a .dsc in the parent dir for the new revision. [18:16] ScottK: yes, thank you, it worked, but i don't know how the first debuild didn't create the right .dsc [18:17] cristi: Then look at the top entry in debian/changelog and make sure it refers to the correct version. [18:17] ScottK however, is there any point in submitting a debdiff to this bug ? https://bugs.launchpad.net/debian/+source/espeak/+bug/250860 [18:17] Ubuntu bug 250860 in espeak ""konqueror" is mispelled in package description" [Undecided,Fix released] [18:18] i guess not, but at least i am starting to get used with the tools [18:19] cristi: That one is already fixed in Ubuntu anyway. === azeem_ is now known as azeem [18:22] ScottK: how do i know what changes should be done to the python packages for the python transition again? sorry for bugging you with this :-s [18:22] cristi: At this point just playing with the tools is good. It's a strong learning curve at the beginning. [18:22] Didn't we go over this yesterday? [18:22] If your IRC client doesn't log there is irclogs.ubuntu.com. [18:23] I'll be glad to answer specific questions, but don't have time today to redo the tutorial. [18:23] ScottK ok [18:30] cristi: hi :) [18:32] savvas: hey there [18:36] Would you prefer to make a patch for a Makefile that uses python setup.py or just include the commands in debian/rules ? [18:37] savvas: if i see setup.py in the package, but however it is not mentioned in rules, i don't have to change anything? [18:38] cristi: if it's mentioned in the install rule, I think you have to add a parameter --install-layout=deb [18:39] savvas: yes, but i don't see it in install rule [18:39] cristi: paste the debian/rules [18:40] savvas: http://pastebin.com/maf3a3de [18:42] cristi: I don't know about that one :\ I've never seen one like it so far! [18:42] it seems it uses configure.py [18:42] savvas: i'll just leave rules untouched [18:42] ? [18:43] cristi: well, try, but if you see your files installed in /usr/local/... then something is wrong ;) [18:43] when the binary package is built, check it: dpkg-deb -c yourfile.deb [18:43] it shows the contents of the package [18:44] ok [18:46] when preparing an FFe would PPA build logs be sufficient? === JanC_ is now known as JanC [18:59] ScottK: I forgot got to thank you about pbuilder-dist recommendation, it's great, thanks! :) [18:59] savvas: YW. Thank RainCT as he wrote it. [19:00] RainCT: thanks for the pbuilder-dist script, very useful hehe, saves me a lot of keystrokes :) [19:01] savvas: i don't see it anywhere it /usr/local/ [19:01] cristi: it's built in: cd $HOME/pbuilder/jaunty_result [19:01] and you do: dpkg-deb -c *.deb [19:02] savvas: i used pbuilder-dist jaunty login [19:02] savvas: that's no good? [19:02] savvas: great, I'm happy that you like it :) [19:02] ls [19:02] cristi: type: cd $HOME/pbuilder/jaunty_result [19:03] cristi: and then: dir [19:03] do you see any .deb files? [19:03] savvas: bash: cd: /home/cristi/pbuilder/jaunty_result: No such file or directory [19:03] lol [19:06] cristi: ls ~/pbuilder [19:07] cristi: I think you can figure it out, find a *result* folder inside ~/pbuilder :) [19:07] cristi: nautilus ~/pbuilder [19:07] :P [19:08] use cd to get into that folder [19:08] and then when you see .deb files: dpkg-deb -c *.deb [19:08] savvas: ok, thanks [19:09] savvas: Do you know about debc? [19:09] savvas: i see only for pystatgrab [19:09] savvas: i was working on pyqwt [19:11] debc? [19:11] ScottK: what's that? :) [19:11] cristi: paste the output of the dpkg-deb -c *.deb command at pastebin :) [19:11] cristi: ah wait [19:12] cristi: you mean you don't see your package? [19:12] savvas: yes.. [19:12] savvas: It's a decent utility for doing what you're after here. [19:12] then it's probably not built correctly [19:12] debc the binary.changes file. [19:12] were there any errors in the log of pbuilder? [19:13] dh_install: python-qwt5-qt3 missing files (usr/lib/python*/Qwt5/*), aborting [19:13] make: *** [binary-arch] Error 1 [19:13] savvas:it's because of one of the .install files i edited i guess [19:13] cristi: paste the whole output so we can see where the problem is :) [19:13] ScottK: thanks! I'll check/try it out once we get it built hehe :) [19:14] savvas: it was larger than my scroll. should i rebuild with a bigger scroll, or the one i have will do? [19:16] savvas: http://pastebin.com/m7d5d0c61 this is what i have [19:16] cristi: the latest log file is saved somewhere in the ~/pbuilder folder :) [19:16] mine is last_operation.log [19:17] cristi: paste debian/control too [19:17] savvas: the error comes from a .install file. you sure you want debian/control? [19:18] cristi: which package you said it was? [19:18] pyqwt [19:21] i modified usr/lib/python*/site-packages/Qwt5/* to usr/lib/python*/Qwt5/* [19:21] use this: usr/lib/python*/*-packages/Qwt5/* [19:22] site-packages is used for python versions 2.5 (or less up to some point :P) [19:22] dist-packages is used by 2.6 [19:22] so *-packages grabs both :) [19:23] savvas: i see, i wish i had more general knowledge about this matter [19:23] modifief usr/lib/python*/site-packages/PyQt4/Qwt5/* to usr/lib/python*/PyQt4/Qwt5/* is ok? [19:24] or like this usr/lib/python*/-packages/PyQt4/Qwt5/* [19:25] You're still missing a * [19:25] usr/lib/python*/*-packages/PyQt4/Qwt5/* [19:26] maxb: is this ok? [19:26] Assuming you've just changed "site" to "*", yes [19:26] maxb: thank you [19:29] cristi: all in time, I didn't know about this either a week ago :) [19:31] * quadrispro working at Python 2.6 transition [19:34] apt-cache rdepends python2.5|grep -c " " [19:35] = 119 [19:35] Plenty more to do [19:36] that's kind of good news for me, i have to get used with editing packages [19:37] ScottK: and those are just the packages that explicitly list their < 2.6 dependency :) [19:47] And then there's the packages which install, but spew DeprecationWarnings :-) [19:56] man, when dpatch is in build-depends it should fail to allow direct patches :P [19:57] lintian will whine already :-) [19:58] it does, but I just found a package with 3 files edited directly with dpatch installed :) [20:45] savvas: Were the direct edits done in Debian or Ubuntu? === nhandler_ is now known as nhandler [21:12] does this lintian error pose any problems ? bad-ubuntu-distribution-in-changes-file jaunty [21:13] cristi: No, you can ignore that. It just has to do with the version of lintian you have [21:13] cristi: No. It just means you might want a newer lintian. There is one that know about Jaunty in hardy-backports. [21:13]