| === korn_ is now known as c_korn | ||
| MTecknology | so basically quilt will handle weaving together patches that alter the same piece of code; so each patch is stitched into a quilt and the quilt is laid on top of the source? | 00:42 |
|---|---|---|
| lifeless | MTecknology: same as any other patch system | 00:44 |
| MTecknology | lifeless: the only 'patch system' I understand right now is patch < file.patch | 00:45 |
| MTecknology | I'm trying to understand it though | 00:45 |
| MTecknology | I just didn't know if that's how it works or if it just adds one patch to the source, then the next, and so on so each patch needs to be aware of the one before it - 'ignoring that the wiki says they shouldn't mess with the same code more than once' | 00:46 |
| lifeless | https://wiki.ubuntu.com/PackagingGuide/PatchSystems | 00:46 |
| MTecknology | I just finished reading that page | 00:46 |
| lifeless | ok, well the wiki is offering a heuristic | 00:47 |
| lifeless | if you have to edit the same line twice, you have to. | 00:47 |
| MTecknology | I just noticed a link to this page - http://pkg-perl.alioth.debian.org/howto/quilt.html - I'll read that and see if it begins to make more sense | 00:48 |
| MTecknology | now I get it. | 00:49 |
| MTecknology | 3 paragraphs in and things just made much more sense :P | 00:49 |
| MTecknology | Is it possible to test the patches without building anything? | 00:50 |
| lifeless | nhandler: around? | 01:19 |
| MTecknology | the more i read about quilt the more it feels kind of like revision control | 02:24 |
| nigelb | feels like it, but not per se | 02:25 |
| nigelb | 2 of the patches I did were on quilt, it was pain staking to learn, its kind of like having revision control + packaging | 02:26 |
| MTecknology | nigelb: check this out - http://pkg-perl.alioth.debian.org/howto/quilt.html | 02:27 |
| MTecknology | nigelb: idk if you did but it cleared up my head a lot | 02:27 |
| nigelb | MTecknology: thats what I first read :) | 02:27 |
| MTecknology | that's the second thing I read - I just patched 70 files in a package :P - I'm new - things will break | 02:28 |
| MTecknology | alias qe='quilt edit' is nice | 02:28 |
| nigelb | 70 files? | 02:29 |
| nigelb | whoa | 02:29 |
| MTecknology | mostly all adding | 02:31 |
| _Andrew | heya | 03:52 |
| stefanlsd | Anyone else have an issue with pbuilder-dist not looking at ~/.pbuilderrc ? | 03:53 |
| _Andrew | Anyone know why there is no libicu-dev for lpia builds? http://packages.ubuntu.com/hardy/libicu-dev It's making my own package in my ppa fail to build on lpia because it's unavailable for libboost | 03:54 |
| _Andrew | I'm assuming it used to be available because my package used to build on lpia previously | 03:54 |
| persia | _Andrew: Just ignore lpia: it's better all around. | 03:58 |
| persia | If some bit of hardware claims to be lpia, just run i386 on it with the i686 libraries installed. | 03:59 |
| persia | lpia was slightly more optimised for jaunty, but contained all sorts of investigatory and debugging wrappers in karmic and wasn't maintained. | 04:00 |
| _Andrew | ok | 04:01 |
| nigelb | pbuilder seems to removing the build folder every tiem I logout | 04:53 |
| nigelb | any way I could change this behavior | 04:53 |
| persia | --save-after-login I think | 04:53 |
| persia | But this breaks the point of having a clean environment. | 04:53 |
| nigelb | it still removes that folder | 04:54 |
| persia | You probably want two *different* pbuilders, one for development (saved) and one for build-testing (created afresh each time) | 04:54 |
| persia | Well, yeah, but it saves all the changes. | 04:54 |
| nigelb | I have to read the pbuilder how to again | 04:54 |
| nigelb | I'm still not clear how to have 2 pbuilders | 04:54 |
| persia | Neither am I. | 04:54 |
| nigelb | its just screwing up | 04:55 |
| RAOF | I just bind-mount for my testing. | 04:57 |
| RAOF | pbuilder-lucid --bindmounts /home/raof login | 04:57 |
| RAOF | Or possibly the other way around :) | 04:57 |
| nigelb | oooh, that works huh | 04:58 |
| nigelb | lemme try. I'm creating a new dev environment for pbuilder first | 04:58 |
| nigelb | is it possible to use my X using bind mount? | 04:59 |
| RAOF | You could also bind-mount /tmp, I guess. | 04:59 |
| nigelb | let this thing get created | 05:00 |
| nigelb | persia: I finally contributed *my own piece of code* ;) | 05:00 |
| nigelb | bug 525888 | 05:00 |
| ubottu | Launchpad bug 525888 in rhythmbox "Apport hook for rhythmbox" [Wishlist,In progress] https://launchpad.net/bugs/525888 | 05:00 |
| persia | RAOF: The goal we were looking at before was being able to run a karmic system, have a development environment for building sources in lucid + test stuff in lucid, and having a separate clean chroot for building. Easy with schroot, but I don't know how to do it with pbuilder. | 05:02 |
| persia | nigelb: Nice. Keep at it. | 05:03 |
| RAOF | With pbuilder you could specify --basetgz to keep different chroots. | 05:06 |
| RAOF | I don't think that works with pbuilder-dist, because pbuilder-dist sets --basetgz for your different build environments itself. | 05:06 |
| nigelb | thats what I'm doing now, specifying different basetz's | 05:07 |
| nigelb | the build folder is getting deleted every time ugh! | 05:32 |
| nigelb | is there any way to make sure the thing gets retained ? | 05:33 |
| persia | Why do you want to retain it? | 05:35 |
| persia | Generally people want to dispose of it. | 05:35 |
| nigelb | even for a development environment? | 05:35 |
| persia | If you want to debug a build in-progress, log into the chroot, apt-get build-dep the package, and debuild-b | 05:35 |
| persia | Yes. | 05:35 |
| nigelb | then I have to bind with how RAOF_ said earlier? | 05:36 |
| persia | At least I find that in 95% of cases I can identify the issue from the build log or the state of the buggy result package. | 05:36 |
| persia | I always bind /home, but there's no requirement this be done. | 05:36 |
| nigelb | lemme try | 05:37 |
| nigelb | I'd like to finish off the boa constructor soon (at least when you're around) | 05:37 |
| persia | Anyone else should be able to help with it also. It's a little complex because it requires code changes, but it's not huge. | 05:38 |
| persia | On the other hand, it's in Python, with which I'm weak, so there's a good chance someone else can help even more than I. | 05:38 |
| nigelb | when I'm looking at the source of the python project, is there a way to see how the output of the interface looks? | 05:59 |
| nigelb | Do I have to compile it? | 05:59 |
| MTecknology | !patch | 06:20 |
| ubottu | Patches are files describing the changes in code to achieve some results. There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines. | 06:20 |
| MTecknology | This was used as an example - dget -x -u https://edge.launchpad.net/ubuntu/intrepid/+source/udev/124-8/+files/udev_124-8.dsc - how can I find that link for somebody elses ppa? | 06:21 |
| persia | The bot takes /query too :) | 06:21 |
| slytherin | MTecknology: by browsing the PPA. | 06:22 |
| persia | If you look at a PPA, you'll find it has references to deb and deb-src lines. | 06:22 |
| persia | slytherin: Was that fixed? I thought one still needed to go grab from ppa.launchpad.net. | 06:22 |
| MTecknology | missed it... | 06:22 |
| MTecknology | thanks | 06:22 |
| persia | slytherin: By the way, did the changes to UEHS work for you? | 06:23 |
| slytherin | UEHS - I don't think so. For example UEHS does not show cortado package which in 3.0 format and one release behind upstream. | 06:23 |
| slytherin | Even specifically searching for package shows zero results. | 06:24 |
| persia | OK. wgrant did the merge you requested just as you left, and this is the first time I've been around when I've seen traffic from you since. | 06:24 |
| slytherin | wgrant: ^^ | 06:24 |
| persia | slytherin: Remember the UEHS filter (ubuntu-local or Debian QA). Could this be the issue? | 06:24 |
| persia | slytherin: It looks to me like that doesn't appear in UEHS because it has a maintainer in Debian. | 06:25 |
| slytherin | persia: I know he did the merge. He told me and he said it will take a while for the results to get updated. | 06:25 |
| slytherin | persia: I don't understand what those filters are. | 06:25 |
| persia | slytherin: They updated later that evening. | 06:25 |
| slytherin | Specifically 'what is Debian QA filter'? | 06:26 |
| persia | UEHS doesn't show any packages that are both present in Debian and have a maintainer other than Debian QA. | 06:26 |
| persia | That's intentional. | 06:26 |
| slytherin | persia: How come it is showing tuxguitar here - http://qa.ubuntuwire.com/uehs/no_updated.html | 06:27 |
| persia | That's a better question :) | 06:28 |
| wgrant | Interesting. | 06:28 |
| wgrant | Let me see. | 06:28 |
| slytherin | I never knew such filters existed. I just assumed that it showed status of all non-native packages. | 06:28 |
| wgrant | Odd, mdt is putting tuxguitar in the list. | 06:29 |
| wgrant | Let's see why. | 06:29 |
| persia | No. We intentionally limited UEHS to reduce the volume, and we cut everything with a Debian Maintainer because Debian Maintainers do great work. | 06:30 |
| persia | There's still way more than we manage to keep up with. | 06:30 |
| slytherin | I agree. | 06:30 |
| persia | So, for cortado, check DEHS, and since you're on that team in Debian, keep it in sync :) | 06:31 |
| slytherin | persia: The package is updated in Debian. It is just not synced in Ubuntu. So I expected it to show on UEHS (not knowing about filters). | 06:32 |
| slytherin | :-) | 06:32 |
| persia | Aha. That makes sense. No, that would show up at http://qa.ubuntuwire.com/multidistrotools/java.html | 06:34 |
| nigelb | hm, I'm looking at the source code of boa-constructor to remove the pychecker dependency and I'm kinda lost :( | 06:37 |
| persia | nigelb: OK. So you ran the grep, right? | 06:38 |
| nigelb | yep | 06:38 |
| persia | And that told you which files and which lines used pychecker, right? | 06:39 |
| persia | So, your next task is to go investigate those files and see if you can make them not use pychecker | 06:40 |
| nigelb | well, in file the pychecker code is already commented out | 06:41 |
| nigelb | the other file, well, I can't make out much of the code | 06:46 |
| persia | nigelb: OK. Now ask if someone can help with the specific code snippet (I probably can't), but it sounds like half your work is done. | 06:49 |
| wgrant | slytherin: tuxguitar is on the list because tuxguitar isn't in testing! | 06:49 |
| nigelb | persia: I get an idea. Once a program is written, it lets you test with pychecker | 06:51 |
| persia | Right, but we don't have pychecker, so that needs to be disabled. | 06:51 |
| slytherin | wgrant: hmm. Which in current context means that it is not present in Debian, right? | 06:51 |
| nigelb | looks like I need to replace that code with a msg telling Pychecker is not enabled | 06:51 |
| persia | Or you can port pychecker to python2.6 :) | 06:51 |
| persia | nigelb: Precisely. | 06:51 |
| * nigelb cant make sense of python code, and you want me to port an entire program? | 06:51 | |
| nigelb | persia: i have this feeling | 06:54 |
| nigelb | that they have already made sure that pychecker can be "suggests" | 06:54 |
| wgrant | slytherin: Correct. | 06:55 |
| wgrant | This is perhaps suboptimal, but it's not clear either way. | 06:55 |
| persia | nigelb: That's often the case: lots of times it's just a control file change, but it's important to investigate in each case to be sure. | 06:55 |
| nigelb | do you have the code, can refer you to the exact lines | 06:55 |
| ddecator | btw nigelb , this is completely unrelated, but congrats on all the progress you seem to be making with motu. hopefully i can figure out this packaging and programming stuff someday =p | 06:57 |
| persia | I don't have the code, and my python is lousy to nonexistent. The key is that you understand it, not that you can explain it to me. | 06:57 |
| nigelb | ddecator: thanks :) | 06:57 |
| nigelb | I could use some confirmation ;) | 06:57 |
| nigelb | there is a 'try: imp.find_module('pychecker')' | 06:57 |
| persia | nigelb: The usual thing to do is to pastebin the code snippet and ask a targeted question about it. | 06:58 |
| nigelb | I'm lazy ;) | 06:58 |
| nigelb | http://paste.ubuntu.com/383499/ | 06:59 |
| nigelb | see lines 165 and the following few lines | 06:59 |
| nigelb | I feel it was meant to work around not having pychecker | 06:59 |
| nigelb | persia: did you see ^ ? comments? | 07:04 |
| persia | I did. Did you see my comments about how well I understand python and suggesting asking a targeted question about the code? | 07:05 |
| nigelb | okay, I'll narrow it down | 07:05 |
| nigelb | there is a try catch before importing pychecker | 07:05 |
| nigelb | or adding any of the functions that depend on it | 07:05 |
| nigelb | it seems to suggest that the edits were made to make sure it was meant to work without pychecker | 07:06 |
| nigelb | there are 3 calls in the code, one was commented, the second call is referenced in the third file, and the third file seems to expect not having pychecker around | 07:07 |
| nigelb | persia: I guess that's the best narrowing down I can do. | 07:08 |
| persia | nigelb: If you're not sure, ask for help. That's why we have IRC channels. Just don't ask me because I have no idea how python imports or exception clauses work. | 07:10 |
| nigelb | okay :) | 07:10 |
| nigelb | I'm pretty sure the source can handle it, so I'll change, build and test it | 07:29 |
| persia | That's often a good plan. | 07:30 |
| nigelb | I cant get a confirmation, but I'm sure my instincts wont be wrong | 07:32 |
| nigelb | to get X, i just bind the relevant mount points? | 07:32 |
| nigelb | I'm going to patch and do debuild outside pbuilder and then build and later work inside pbuilder | 07:33 |
| nigelb | since the package is still in debian format, I assume I have to change that stuff before uploading (for when I get there) | 07:37 |
| persia | Hrm? | 07:38 |
| persia | I don't understand "still in debian format" | 07:38 |
| nigelb | the maintainer fields are not yet corrected | 07:39 |
| persia | Oh, that's trivial. Just run update-maintainer in the package directory. | 07:41 |
| persia | And there's no reason you can't try to build the source package with karmic, it's just that it's not guaranteed to work for every package. | 07:42 |
| nigelb | just the debuld -S | 07:42 |
| nigelb | after that I'll login to pbuilder (once I figure out how to get X working inside) | 07:42 |
| persia | If you're working in karmic, be extra careful about your changelog entries. | 07:44 |
| nigelb | I made that mistake twice (I dont think I'll ever forget) | 07:46 |
| nigelb | pbuilder kept throwing errors. I repeated building for like 4 times before i realized what I did wrong | 07:46 |
| dan4dm | hi, seeking reviews/advocates for supercollider http://revu.ubuntuwire.com/p/supercollider - think it's in good shape now | 08:04 |
| dan4dm | artfwo: http://revu.ubuntuwire.com/p/supercollider | 08:09 |
| artfwo | dan4dm, yes, I've checked the packaging this morning | 08:09 |
| dan4dm | artfwo: (actually you get cc'ed on the emails do you? so you already know) | 08:09 |
| artfwo | I have already cleaned up a little cruft from our previous work and will update the svn tonight | 08:10 |
| rainct_ | Any package needing review (with an approved FFe)? | 08:10 |
| === rainct_ is now known as RainCT | ||
| dan4dm | RainCT: http://revu.ubuntuwire.com/p/supercollider needs review (i don't know what FFe means) | 08:11 |
| * RainCT has some time while he listens to basic modular programming stuff at class... | 08:12 | |
| RainCT | dan4dm: Feature Freeze exception. Ubuntu Lucid is at a stage where no new features (be it new packages or changes to existing packages introducing new features) aren't allowed anymore without getting an exception from the release team | 08:13 |
| RainCT | (see https://wiki.ubuntu.com/FeatureFreeze) | 08:13 |
| dan4dm | RainCT: i see, thanks. so supercollider has missed the boat for lucid then, darn | 08:14 |
| RainCT | dan4dm: Unless there's some very convincing reason to get it in :) | 08:14 |
| nigelb | well, success, boa constrictor now builds :) | 08:15 |
| dan4dm | RainCT: hmmm no, apart from its general amazingness there's nothing i can say really ;) - does FF/FFe also apply to multiverse and suchlike? | 08:15 |
| dan4dm | oh no wait I mis-remembered what multiverse means | 08:17 |
| dan4dm | i meant "universe" - is FF/FFe just about the main distro or also for universe stuff? | 08:18 |
| RainCT | dan4dm: Yeah, all of Ubuntu. (Until now there were different release teams for main/restricted and universe/multiverse, but they are in the process of being merged. Doesn't make a big difference in any case) | 08:18 |
| dan4dm | RainCT: ok thanks | 08:18 |
| RainCT | dan4dm: If supercollider would already be in Ubuntu and we were talking about a new upstream version it probably wouldn't be difficult to get it updated if it has important new features (arguing low number of users and no impact on other applications if there are no reverse dependencies)., but I'm not sure how new packages are being handled | 08:21 |
| dan4dm | np, thanks for the info | 08:24 |
| RainCT | dan4dm: You're welcome, thanks for your interest in contributing to Ubuntu :) | 08:25 |
| dan4dm | :) | 08:25 |
| nigelb | I have a package, which I want to test inside a pbuilder chroot, any suggestions? | 08:27 |
| nigelb | basically I want the chroot to use my X | 08:27 |
| dholbach | good morning | 08:28 |
| RainCT | nigelb: I think it'd be easier to use a virtual machine. | 08:28 |
| RainCT | Morning dholbach :) | 08:28 |
| dholbach | hey RainCT | 08:29 |
| RainCT | Uhm.. Any idea what's going on here? "W: cowdancer: unsupported operation flock, read-only open and fchown/fchmod/flock are not supported: tried openning dev:inode of 2053:433992" | 08:41 |
| RainCT | nvm, "chown rainct.rainct /opt" (using /opt/builder as PBUILDFOLDER) fixed it | 08:44 |
| RainCT | (erm no it didn't) | 08:44 |
| === hannesw_ is now known as hannesw | ||
| === ApOgEE__ is now known as ApOgEE | ||
| pather87 | heyho | 09:05 |
| pather87 | somebody here? i would have some questions. I'm new to packaging | 09:08 |
| Rhonda | Just ask your questions and in case someone knows the answer they will respond. No need to ask wether you can ask. :) | 09:09 |
| pather87 | kk :) | 09:09 |
| tseliot | nigelb: maybe run export DISPLAY=localhost:0.0 in the chroot? | 09:09 |
| pather87 | I've read the maintainer-guide on http://www.debian.org/doc/manuals/maint-guide/ and on chapter 5 he uses a little skript to get the build-depends for a program. In short it is a skript which strace the ./configure and then searches the log through files which are opened and then get the corresponding package. I've tried it with the the source of the bc package and the build-depends don't match with the log-output the way i expected | 09:18 |
| pather87 | Now i would know how you find out the Build-depends in the control-file for the packages | 09:21 |
| siretart` | pather87: the best way to find that out is to understand the software you package. reading the documentation might be a good start. | 09:26 |
| lifeless | nhandler: ping | 09:39 |
| TeTeT | hi, I try to start packaging dhclient4 for Ubuntu and run into a problem at the very first step as described in James Westby doc for bzr builddeb, http://pastebin.ubuntu.com/383602/ | 10:42 |
| TeTeT | it seems it is expecting a debian directory already - so do I need to start with dh_make? | 10:43 |
| persia | Which doc are you using? | 10:43 |
| c_korn | hello, I try to make a debian/watch file for flock. the upstream tarball is here: http://ftp.osuosl.org/pub/flock/releases/2.5.6/flock-2.5.6.en-US.linux-i686.tar.bz2 I use this watch file: http://paste.ubuntuusers.de/397778/ but uscan reports this: http://paste.ubuntuusers.de/397779/ | 10:51 |
| persia | ([\d\.]+) | 10:52 |
| Rhonda | c_korn: You have two () parts. One should be (?:) | 10:52 |
| persia | (the second one) | 10:52 |
| persia | TeTeT: So, which doc are you using? | 10:52 |
| Rhonda | Yeah, the second, otherwise it would be 0.5.15.0 instead of 0.5.15 :) | 10:53 |
| TeTeT | persia: http://jameswestby.net/bzr/builddeb/user_manual/normal.html | 10:53 |
| TeTeT | persia: I'm a bit baffled by the error message, but it seems to have initialized a branch | 10:54 |
| Rhonda | Hmmm, somehow the linux-i686 part in the filename sounds like it is binary, not sources? | 10:54 |
| persia | Some upstreams are annoying, but yeah. | 10:54 |
| persia | TeTeT: Which command gives the error? merge-upstream? | 10:54 |
| Rhonda | c_korn: What does uscan -verbose give you? | 10:55 |
| Rhonda | c_korn: That should show you all the matches it finds. | 10:55 |
| TeTeT | persia: yes | 10:55 |
| TeTeT | persia: I just continue with dh_make and see where it goes | 10:55 |
| persia | Don't bother with dh_make. That just feeds you a set of outdated defaults that are useful if you want to learn about packaging but annoying if you want to package something. | 10:56 |
| ari-tczew | how long is dapper server support? june 2011? | 10:56 |
| persia | ari-tczew: Theoretically, yes. | 10:56 |
| persia | TeTeT: Run licensecheck -r --copyright to get some info to create debian/copyright, run dch --create to create debian/changelog, cp /usr/share/doc/debhelper/examples/rules.tiny to debian/rules, echo 7 > debian/compat, man uscan and create debian/watch. | 10:57 |
| persia | TeTeT: debian/control is a bit trickier, but just glancing at an existing one and basing off http://www.debian.org/doc/debian-policy/ch-controlfields.html usually works. The important fields (I think) are Source: Maintainer: Section: Priority: (use "optional"), Build-Depends: , Standards-Version (check the version of debian-policy you have installed), and Homepage in the source paragraph. In the binary paragraph you want at least Package: Arch | 11:00 |
| persia | itecture: (please use one of "all" or "any"), Depends/Recommends/Suggests (remember ${misc:Depends} in Depends:), and Description. | 11:00 |
| TeTeT | man uscan? | 11:00 |
| * Rhonda hates rules.tiny | 11:00 | |
| persia | Rhonda: Why? | 11:00 |
| * persia has become a big fan | 11:01 | |
| Rhonda | persia: It makes easy things easy and complicated things utterly difficult. | 11:01 |
| TeTeT | persia: I want to use cdbs | 11:01 |
| Rhonda | It's totally the wrong approach for the wrong problem. | 11:01 |
| Rhonda | TeTeT: Please not.l | 11:01 |
| persia | TeTeT: No you don't. You'll never figure out what broke when you get an error. | 11:01 |
| Rhonda | persia: same with dh tiny. :) | 11:01 |
| persia | Rhonda: how are complicated things utterly difficult? Most things can be dealt with through overide_dh_auto_foo and the remainder by just injecting old-style rules snippets. | 11:02 |
| Rhonda | persia: Yes, but one has to dig up what override_dh_auto_foo are possible and what the old-style rules snippets are. | 11:02 |
| Rhonda | That's the same argumentation that would work for cdbs, FWIW. | 11:03 |
| persia | I used to think that, except that I spend a lot of time explaining how to package stuff, and I find that people just don't understand when it's CDBS, and they do understand when it's dh(1). | 11:03 |
| persia | For CDBS, people seem to try random variables hoping they work or override internals because they don't read the manual. | 11:04 |
| persia | For dh(1) it's harder to get it quite so wrong, and easier to track down a problem when it appears. | 11:04 |
| Rhonda | That still doesn't make the tiny approach any better. | 11:04 |
| Rhonda | "because it works for 80% of software" is no reason to make it harder for the remaining 20% to understand | 11:05 |
| * sebner totally agrees with persia and throws dh7 at Rhonda | 11:05 | |
| * Rhonda throws sebner into /dev/void | 11:05 | |
| * sebner hides | 11:06 | |
| persia | Rhonda: How is it harder for the remaining 20%? | 11:06 |
| sebner | Rhonda: /dev/zero ftw! | 11:07 |
| Rhonda | I don't deny that dh is a much saner approach than cdbs. Far from it. But dh tiny isn't an improvement, it's rather a step into the cdbs hell direction. | 11:07 |
| persia | Rhonda: Either you override the parts that don't work, or if you don't want to learn about overrides, just write a normal rules file in make. | 11:07 |
| Rhonda | sebner: That would be too much place for you to hide in. | 11:07 |
| sebner | heh | 11:07 |
| persia | Rhonda: The big reason I like dh(1) is that I can tell someone how to package in 3-4 lines in IRC. Then they get a buggy package. Debugging it isn't that hard. When we tell people to write rules files from scratch, we get all sorts of monstrosities because packaging is not something most folk understand. | 11:08 |
| Rhonda | Yes, I am writing normal rules file in make. Actually there is no magic involved in all the thing anyway: You install into debian/$package and call dpkg --build debian/$package .. | 11:08 |
| persia | And it works for enough stuff that lots of people are happy with the results. | 11:08 |
| persia | Well, yeah, but lots of people don't even understand that :) | 11:09 |
| Rhonda | Unfortunately the drawback for that "it works for enough stuff" makes it a pain for the rest and make worshipers (that work just on such stuff) a vocal majority that deny the issues for the rest. | 11:09 |
| Rhonda | Same with all this source format 3.0 troubles that mostly root in totally misnaming it as "quilt" - which it wasn't, still isn't and probably never will be. :/ | 11:11 |
| persia | Rhonda: Please show me an example of how it's any more painful than using debhelper 7 without dh. Any example. | 11:11 |
| persia | Rhonda: I'd agree with you except I haven't found one yet. | 11:11 |
| Rhonda | It hides what's going on behind from people who don't know it from before and leave them with the additional requirement to dig things up (also for oldstanders, mind you) in case something needs to be tweaked. | 11:13 |
| Rhonda | Before one would just remove the dh_python line if the package doesn't do any python stuff, or add the -X switch to any of the dh_* calls when needed instead of having to dig up what the hell the acccording override function would be called. | 11:13 |
| Rhonda | And actually, I have a hard time to find any documentation on the override parts in man dh | 11:15 |
| TeTeT | persia: I recycled the control files from dhcp3, hoping that it will just work by replacing a lot of 3s with 4s ... | 11:16 |
| Rhonda | It goes into examples of --before and --after, but actually it doesn't list which arguments that could take or in what oder they would be processed. | 11:16 |
| c_korn | Rhonda, persia: thank you. I got it working with this line. but I don't know what you wanted me to do with (:?): http://ftp.osuosl.org/pub/flock/releases/([\d.]+)/flock-([\d.]+)\.en-US\.linux-i686\.tar\.bz2 | 11:17 |
| Rhonda | c_korn: Actually, you should leave off the second () | 11:18 |
| Rhonda | c_korn: (?:pattern) means that it won't be put into a variable and is only used for grouping (like, that you could add a quantifier after it) | 11:18 |
| persia | Rhonda: --before and --after are just asking for pain, in my opinion. And overrides are only if you *want* to use the automation. But the sequences are available in a sane format (dh source), which I can't say for CDBS. | 11:18 |
| persia | Rhonda: So, while it's less clear for complex stuff and oldstanders need to learn it, I say it's much better than CDBS, which was previously considered the "easy" way by new folk. | 11:19 |
| Rhonda | persia: Ah, the old UTSL approach. That's always the best documentation. :) | 11:19 |
| Rhonda | … unfortuantely I highly disagree with that. | 11:19 |
| persia | UTSL? | 11:19 |
| Rhonda | Use The Source, Luke | 11:19 |
| Rhonda | That would require one to know that dh is directly viewable, and find ones way through it. | 11:20 |
| Rhonda | Given that it is perl I expect quite a lot of people to rather retreat from dh before they would use such sort of "documentation". | 11:21 |
| * Rhonda . o O ( not me, mind you. :) ) | 11:21 | |
| Rhonda | … and I hope that I'm not shying away people with this semi-rant discussion. | 11:21 |
| c_korn | persia: this line does not work "http://ftp.osuosl.org/pub/flock/releases/([\d.]+)/flock-(?:[\d.]+)\.en-US\.linux-i686\.tar\.bz2" uscan says: Newest version on remote site is 1, local version is 2.5.6 oO | 11:22 |
| Rhonda | c_korn: http://ftp.osuosl.org/pub/flock/releases/([\d.]+)/flock-[\d.]+\.en-US\.linux-i686\.tar\.bz2 | 11:23 |
| persia | Rhonda: Well, at least UTSL is easier with dh(1) than with CDBS, but yeah, it needs docs. | 11:23 |
| Rhonda | The second () doesn't make any sense somehow. :) | 11:23 |
| * persia keeps planning to write up an exception-based guide to using dh(1) but never gets around to it | 11:24 | |
| Rhonda | I've been kicked from writing for my former workplace's magazine - but I don't want to stop writing all together. Maybe I could come up with something useful that will keep helpful for others, too. :) | 11:25 |
| c_korn | Rhonda: it is tricky :) http://paste.ubuntuusers.de/397781/ | 11:29 |
| Rhonda | c_korn: Then I think you should move the () from in the directory to the filename | 11:30 |
| Rhonda | Like http://ftp.osuosl.org/pub/flock/releases/[\d.]+/flock-([\d.]+)\.en-US\.linux-i686\.tar\.bz2 | 11:30 |
| Rhonda | Hmmm, interestingly, I also have two () in pgadmin3 … | 11:32 |
| * Rhonda hides. | 11:32 | |
| persia | heh. 2 ()s are extra good, but I believe the second one is silently ignored by uscan. | 11:32 |
| Rhonda | … even though it insists on it being there. | 11:33 |
| persia | What! That's just odd. | 11:33 |
| Rhonda | persia: See c_korn's last paste. | 11:35 |
| persia | Hrm. | 11:36 |
| persia | I'd need to go look at uscan source again to understand. I *thought* it just used $1 blindly. | 11:38 |
| Rhonda | No, it's way more complex than that. :) | 11:41 |
| persia | It's almost always more complex :) | 11:42 |
| c_korn | Rhonda: your approach gives this: http://ftp.osuosl.org/pub/flock/releases/[\d.]+/ failed: 404 Not Found | 11:44 |
| Rhonda | I guess you should stick with the one version that was working for you and nevermind. :) | 11:45 |
| c_korn | yeah, I take this: http://ftp.osuosl.org/pub/flock/releases/([\d.]+)/flock-([\d.]+)\.en-US\.linux-i686\.tar\.bz2 | 11:46 |
| persia | It working is always better than it looking right. | 11:46 |
| c_korn | I thank you persia and Rhonda | 11:46 |
| * persia gives Rhonda all the credit | 11:46 | |
| * Rhonda buys a house with the credit | 11:47 | |
| * persia wishes the instruction manual on how to buy houses on credit obtained from helping folk on IRC was more widely available | 11:49 | |
| TeTeT | I put the dhcp4 package in my PPA, https://edge.launchpad.net/~tspindler/+archive/ppa/+packages | 12:02 |
| persia | TeTeT: And everything worked for you? | 12:04 |
| TeTeT | persia: bzr bd resulted in a working dh_client, yes. I'm a bit perplexed as my debian directory is nearly empty and the one of dhcp3 is full with files. So I guess there's still a lot of work to be done for the server | 12:04 |
| TeTeT | persia: but on my Lucid laptop I now got dhclient4 up and running from a package | 12:05 |
| persia | TeTeT: I suspect you'll end up needing to copy some or all of the files (perhaps in modified form), but that really requires investigating what each one does and why it's there. | 12:05 |
| Laney | james_w: Hi, got the next round — http://dpaste.com/164648/ | 12:09 |
| Laney | 3 more to go after this | 12:09 |
| james_w | Laney: I'll wait a little to make sure we don't interfere with the alpha preparations | 12:38 |
| Laney | no rush | 12:40 |
| jussi01 | persia: did you find an op for here? | 13:13 |
| persia | jussi01: For which? To set +t? | 13:13 |
| jussi01 | you wanted -t no? | 13:14 |
| persia | Err, right. | 13:14 |
| * persia is fuzzy about some things :) | 13:14 | |
| jussi01 | :)e | 13:14 |
| Rhonda | dholbach and Hobbsee have access. see /msg chanserv access #ubuntu-motu list | 13:16 |
| Pici | jussi01: er, the ircc has access | 13:16 |
| shadeslayer | dholbach: hi | 13:17 |
| jussi01 | Pici: yes, but we are for emergencies only. its not that urgent. | 13:17 |
| persia | See, that's why not including me before and me having to wait until the current mess is sorted is frustrating :) | 13:19 |
| persia | But it's not critical. Life can go on. | 13:19 |
| shriekout | Can someone can review my package (happytimer) please ? : http://revu.ubuntuwire.com/p/happytimer | 13:49 |
| sebner | persia: openarena ~~o~~ *hehehe* | 14:09 |
| persia | Lovely. | 14:09 |
| sebner | persia: unfortunately too late for lucid | 14:10 |
| persia | Why? | 14:11 |
| shadeslayer | persia: i guess feature freeze | 14:13 |
| sebner | persia: release folks will shout at us in March :P | 14:14 |
| persia | March? Yeah, that7s too late. | 14:16 |
| sebner | persia: then bug your colleagues to upload it to unstable the next days :P | 14:16 |
| persia | It will be uploaded when it's ready. | 14:17 |
| sebner | persia: I hate that sentence :P | 14:18 |
| persia | WHy? if you're in a hurry, go make it ready ;p | 14:18 |
| sebner | persia: Personally I don't care for sooo many things but I'm thinking about poor users :P | 14:19 |
| persia | That's why we have backports :) | 14:20 |
| sebner | persia: pfffffffffffffffffffffffffff | 14:21 |
| sebner | ;) | 14:21 |
| === lukjad007 is now known as lukjad86 | ||
| c_korn | it is spooky here. lintian complains "W: wxhexeditor source: dh-make-template-in-source debian/menu.ex" but there is no such file in the debian directory | 14:25 |
| Rhonda | c_korn: Did you repack the source after you removed/renamed the file? | 14:29 |
| c_korn | Rhonda: ooops. I included the debian directoy in the upstream tarball by accident :/ | 14:31 |
| c_korn | at least there is a logical/non-mystical explanation for it :) | 14:33 |
| shadeslayer | hi can anyone help me package a library? | 14:35 |
| shadeslayer | its here : http://gitorious.org/joschy/joschy | 14:35 |
| shadeslayer | so anyone? | 14:56 |
| c_korn | shadeslayer: what is your problem regarding the lib ? do you want it packaged ? | 15:06 |
| Rhonda | shadeslayer: Ask your concrete troubles with packaging it and you might receive answers. :) | 15:07 |
| shadeslayer | c_korn: i want to package it | 15:16 |
| shadeslayer | c_korn: the lib is : http://gitorious.org/joschy/joschy | 15:16 |
| shadeslayer | c_korn: ive so far managed to package stuff already in the repos with apt-get source... | 15:17 |
| shadeslayer | and ive learnt how to use pbuilder ( sudo pbuilder build foo.dsc ) | 15:17 |
| shadeslayer | but this is my first non native package and i cant seem to get my teeth around it :) | 15:17 |
| c_korn | ok, shadeslayer. is the lib only available in git or is there a tarball of a stable version around. | 15:18 |
| c_korn | ? | 15:18 |
| shadeslayer | c_korn: only in the git | 15:18 |
| shadeslayer | c_korn: i can tarball the lib with git archive | 15:18 |
| c_korn | yes, this looks like a good starting point | 15:19 |
| shadeslayer | yeah i know a bit of git and svn :) | 15:19 |
| abogani | Hi All, Are there any REVU admin here? | 15:25 |
| c_korn | shadeslayer: ok, do you have the tarball extracted ? | 15:25 |
| shadeslayer | c_korn: yes | 15:26 |
| c_korn | shadeslayer: ok, what is the name of the library ? joschy ? | 15:27 |
| shadeslayer | yes | 15:27 |
| c_korn | shadeslayer: does the library have a version currently ? | 15:29 |
| c_korn | else we have to use the date as version | 15:29 |
| shadeslayer | c_korn: nope | 15:29 |
| shadeslayer | c_korn: i was discussing the version no. in #kubuntu-devel and they said 0.0.0.1+git20100225 was the best | 15:30 |
| c_korn | shadeslayer: ok, the rename the joschy-joschy directoy to 0.0.0.1+git20100216 | 15:31 |
| c_korn | the master branch was changed on feb 16 the last time | 15:31 |
| shadeslayer | c_korn: so the dir is : joschy-0.0.0.1+git20100225 | 15:31 |
| c_korn | yes | 15:32 |
| shadeslayer | done | 15:32 |
| shadeslayer | c_korn: i guess we dont need the tarball since its a new package.. | 15:32 |
| c_korn | shadeslayer: we need the tarball for the diff later. just rename it: mv joschy-joschy-master.tar.gz joschy_0.0.0.1+git20100225.orig.tar.gz | 15:34 |
| shadeslayer | c_korn: already done ;) | 15:34 |
| abogani | Are there any REVU admin here? I would want nuke a package on REVU... | 15:34 |
| c_korn | well, I also don't package libraries too often. so let's use the dh_make template. run this inside the directory: dh_make -c gpl2 -l -f ../joschy_0.0.0.1+git20100225.orig.tar.gz | 15:36 |
| shadeslayer | c_korn: done :) | 15:36 |
| c_korn | ok, then: rm -f debian/*.ex debian/*.EX debian/dirs debian/docs debian/README.Debian | 15:37 |
| shadeslayer | done | 15:38 |
| shadeslayer | c_korn: ^^ | 15:41 |
| c_korn | ok, we need libqt4-dev and cmake as a build-dependency | 15:41 |
| shadeslayer | c_korn: cmake? | 15:43 |
| shadeslayer | c_korn: i thought build-essential was default | 15:43 |
| nigelb | I have a package, which I want to test inside a pbuilder chroot, any suggestions? basically I want the pbuilder chroot to use my current X | 15:43 |
| shadeslayer | ( and i think we need kdelibs5-dev as well) | 15:43 |
| c_korn | shadeslayer: cmake is not build-essential | 15:44 |
| iamfuzz | nigelb, should just be able to export DISPLAY=:0 | 15:44 |
| nigelb | iamfuzz: how do I do that? | 15:44 |
| shadeslayer | c_korn: ok | 15:44 |
| iamfuzz | nigelb, just "sudo export DISPLAY=:0" in your chroot | 15:45 |
| nigelb | ah, lemme try that. been at this for hours! | 15:45 |
| iamfuzz | nigelb, errr drop the sudo | 15:46 |
| iamfuzz | nigelb, and on the host, make sure you type "xhost +" | 15:46 |
| iamfuzz | should be gtg from there | 15:46 |
| nigelb | iamfuzz: lemme check out | 15:47 |
| shadeslayer | sharms: sorry for that | 15:47 |
| shadeslayer | sharms: bad tab complete :( | 15:47 |
| c_korn | shadeslayer: replace the BROKEN in debian/control with 1 | 15:47 |
| shadeslayer | ok | 15:47 |
| nigelb | iamfuzz: how does the final command look? "export xhost +DISPLAY=:0" ? | 15:48 |
| iamfuzz | xhost + outside chroot | 15:49 |
| iamfuzz | export DISPLAY=:0 inside chroot | 15:49 |
| shadeslayer | c_korn: done | 15:49 |
| nigelb | erm, what should I do outside? | 15:50 |
| c_korn | shadeslayer: ok, it compiles. delete the debian/*.dirs files and rename joschy.install to libjoschy.install and joschy-dev.install to libjoschy-dev.install | 15:51 |
| c_korn | libjoschy.install only should contain this line: usr/lib64 | 15:51 |
| c_korn | and libjoschy-dev.install should only contains this line: usr/include | 15:51 |
| nigelb | iamfuzz: erm, what should I do outside? I'm still confused | 15:51 |
| iamfuzz | nigelb, I just told you... | 15:52 |
| iamfuzz | xhost + outside | 15:52 |
| geser | type "xhost +" and hit [Enter] | 15:52 |
| nigelb | iamfuzz: err, I didnt think it would be that simple.. thanks geser | 15:52 |
| shadeslayer | c_korn: shouldnt that be joschy1.install to libjoschy1.install | 15:52 |
| abogani | Are there any REVU admin here? I would want nuke my package on REVU for trademark issue... | 15:52 |
| Rhonda | c_korn: Shouldn't the .a and plain .so file also be installed into the -dev package rather than the plain library? And doesn't the library package require the soname version in its name? | 15:53 |
| ScottK | abogani: Doesn't take a REVU admin. What package | 15:53 |
| Rhonda | Maybe I'm thinking too far along. :) | 15:53 |
| abogani | ScottK: arduinico | 15:53 |
| shadeslayer | c_korn: my bad | 15:53 |
| shadeslayer | c_korn: and theyre already named so ;) | 15:54 |
| c_korn | Rhonda: the library does not build static libs and there are only the normal .so files without soname | 15:54 |
| shadeslayer | but theyre not in debian/ theyre in joschy-0.0.0.1+git20100225 | 15:54 |
| Rhonda | c_korn: erm, depending on where it's used I fear it would needed to get fixed to do that. | 15:55 |
| shadeslayer | c_korn: should i remove the last part inlibjoschy.install | 15:55 |
| shadeslayer | c_korn: lib*.so.* | 15:55 |
| nigelb | I'm trying to build a package and run it inside a pbuilder schroot, only thing I cant figure out is, how to get the deb! | 15:55 |
| c_korn | puh, I am not that skilled with packaging libraries. | 15:56 |
| shadeslayer | c_korn: dont leave me like this :P | 15:57 |
| Rhonda | nigelb: You can work with --bindmounts of getting an outside directory inside the pbuilder chroot and do dpkg -i inside then | 15:57 |
| shadeslayer | c_korn: so... | 15:58 |
| nigelb | Rhonda: ah, the dpkg -i.. thats what I needed | 15:58 |
| nigelb | I figured almost everything else out | 15:58 |
| c_korn | shadeslayer: well, I would at first leave it like that. it is for your personal use and not something you want to upload to revu, am I right ? | 15:59 |
| shadeslayer | yes | 15:59 |
| shadeslayer | c_korn: actually ill be uploading to a PPA | 15:59 |
| shadeslayer | c_korn: so others *might* use it | 15:59 |
| c_korn | shadeslayer: hm, ok. but as I don't know how to make it build static libs and so on let's just make the best out of it. | 16:01 |
| shadeslayer | c_korn: what are static libs? | 16:01 |
| nigelb | now I'm wondering, how do I get the .deb file? I'm so used to debuild -S, i never figured that out | 16:02 |
| geser | shadeslayer: each binary has it's own copy (added at build time) instead of using a shared one (e.g. from /usr/lib) | 16:02 |
| c_korn | well, if you use a static lib for an application it gets integrated into the application directly. so you don't have to link _dynamically_ against it. | 16:03 |
| geser | nigelb: have you already build the deb successfully or do you need to build it first? | 16:03 |
| c_korn | thanks geser. this brings it to the point :) | 16:03 |
| nigelb | I ran a debuild -S, and built sucessfully in pbuilder | 16:03 |
| nigelb | but I'm not sure I see a .deb anywhere | 16:04 |
| shadeslayer | geser: ooh.. so like theres a different library for each app that uses the library | 16:04 |
| c_korn | shadeslayer: add this to the debian/rules file http://pastebin.com/hZrk78n4 (replace the spaces with a tab) | 16:04 |
| geser | nigelb: plain pbuilder or pbuilder-dist? | 16:04 |
| nigelb | pbuilder with a lucid schroot | 16:04 |
| geser | shadeslayer: yes | 16:04 |
| geser | nigelb: then check in /var/cache/pbuilder/results for your build debs | 16:05 |
| shadeslayer | geser: ah | 16:05 |
| nigelb | geser: ah, thanks :) | 16:06 |
| geser | once you found it, copy it into /var/cache/pbuilder/.../tmp (from outside) and "dpkg -i /tmp/...deb" from inside | 16:06 |
| shadeslayer | geser: did i have to add it or replace the whole thing | 16:07 |
| c_korn | shadeslayer: then the libjoschy1.install should contain this line: usr/lib | 16:07 |
| ScottK | abogani: Nuked | 16:07 |
| abogani | ScottK: Thanks! | 16:07 |
| shadeslayer | c_korn: ^^ | 16:07 |
| shadeslayer | c_korn: did i have to add it or replace the whole thing | 16:08 |
| c_korn | shadeslayer: replace it | 16:08 |
| shadeslayer | c_korn: ok done | 16:08 |
| shadeslayer | c_korn: dont the libjoschy.install thing too | 16:08 |
| shadeslayer | *done | 16:09 |
| c_korn | ok | 16:10 |
| shadeslayer | c_korn: anything else? | 16:10 |
| c_korn | I don't know how your debaian/control file looks like. but it should be like this: http://pastebin.com/acQ0CLHn | 16:11 |
| c_korn | shadeslayer: oh, and if you upload to PPAs you have to specify the release of course in debian/changelog: http://pastebin.com/ZeXfW5Zy | 16:12 |
| shadeslayer | c_korn: http://pastebin.ca/1810286 | 16:12 |
| shadeslayer | c_korn: yeah know about that ;) | 16:12 |
| c_korn | shadeslayer: add libqt4-dev to the build-depends | 16:13 |
| shadeslayer | c_korn: done | 16:13 |
| c_korn | shadeslayer: and add the lib prefix to joschy (only for the packages not the source) | 16:13 |
| shadeslayer | forgot that earlier :P | 16:13 |
| c_korn | oh, and you can change "Architecture: any" under libjoschy-dev to "Architecture: all" | 16:14 |
| shadeslayer | c_korn: http://pastebin.ca/1810291 | 16:14 |
| shadeslayer | done | 16:14 |
| c_korn | shadeslayer: http://pastebin.ca/1810293 | 16:15 |
| c_korn | shadeslayer: you can give it a try :) | 16:16 |
| shadeslayer | sure | 16:16 |
| shadeslayer | c_korn: http://pastebin.ca/1810295 | 16:16 |
| shadeslayer | one more thing | 16:16 |
| c_korn | shadeslayer: the line "Depends: joschy1 (= ${binary:Version})" should be "Depends: libjoschy1 (= ${binary:Version})" | 16:17 |
| shadeslayer | c_korn: yeah did that too ;) | 16:17 |
| shadeslayer | http://pastebin.ca/1810296 | 16:17 |
| c_korn | shadeslayer: yeah | 16:17 |
| shadeslayer | c_korn: can you tell me the purpouse of the .install files later on? | 16:18 |
| shadeslayer | and how does one make the rules file too :P | 16:18 |
| c_korn | shadeslayer: well it just "installs" the files in the target directory | 16:18 |
| shadeslayer | c_korn: and how do you find that out? | 16:19 |
| c_korn | if the file is not in the source directory it looks in debian/tmp (which is where the files get installed to if there is more than one package defined in debian/control) | 16:19 |
| shadeslayer | some kind of black magic :P | 16:19 |
| c_korn | shadeslayer: man dh | 16:19 |
| c_korn | shadeslayer: man debhelper | 16:19 |
| c_korn | shadeslayer: and for the purpose of the install files: man dh_install | 16:20 |
| shadeslayer | c_korn: oooh | 16:21 |
| shadeslayer | nice | 16:21 |
| lightnin | When releasing a binary package on a production site, should it be built for the earliest Ubuntu release with which it is compatible? | 16:21 |
| shadeslayer | ill remember that ;) | 16:21 |
| shadeslayer | lightnin: i think it should be latest release+1 and the latest release | 16:21 |
| shadeslayer | like lucid and karmic | 16:21 |
| micahg | lightnin: or just point to PPA | 16:21 |
| bcurtiswx | StevenK: would you be able to push docky out of NEW ? | 16:22 |
| shadeslayer | lightnin: yeah PPA's are great | 16:22 |
| * shadeslayer loves docky but is too great a KDE fan to even try it out | 16:22 | |
| lightnin | shadeslayer: Yep, we might link to our ppa as well. But we figure it would be good to post it on our download page with the rest: http://info.scratch.mit.edu/Scratch_1.4_Download | 16:23 |
| shadeslayer | lightnin: MIT :o | 16:23 |
| shadeslayer | lightnin: well i would point a link to the PPA | 16:24 |
| shadeslayer | lightnin: PPA's have a very good description page on how to add them | 16:24 |
| shadeslayer | all thanks to lp devs ;) | 16:24 |
| lightnin | shadeslayer: hmm.. well, I think some end users will get lost trying to add a ppa. | 16:24 |
| micahg | lightnin: instructions are provided on the PPA home page | 16:25 |
| micahg | s/the/your/ | 16:25 |
| shadeslayer | lightnin: yeah,look at https://launchpad.net/~rohangarg/+archive/kde-extra | 16:25 |
| shadeslayer | thats my PPA ;) | 16:25 |
| lightnin | micahg: Yep, and they make perfect sense to me! But you'd be surprised by what many non-tech end users can get stuck on.... | 16:26 |
| micahg | lightnin: well, you can give more detailed instructions on your site if you wish | 16:26 |
| shadeslayer | lightnin: if you know about hook scripts you can provide binaries and then run a script which adds the PPA | 16:26 |
| shadeslayer | c_korn: so whats next? | 16:27 |
| shadeslayer | c_korn: debuild -S -sa ? | 16:27 |
| c_korn | shadeslayer: yep | 16:27 |
| lightnin | If we do release a binary, should I put jaunty in the changelog, since it will work with the versions that follow it? | 16:27 |
| lightnin | shadeslayer: oooh, that would be cool. Like a one click to install type of thing? | 16:28 |
| Laney | if it's for a PPA you should upload to the oldest release you support | 16:28 |
| Laney | and then you can copy it forward to all of the others | 16:28 |
| shadeslayer | c_korn: http://pastebin.ca/1810318 | 16:28 |
| lightnin | Laney: Wow, that's great to know :) I haven't figured out how to do that yet. | 16:28 |
| shadeslayer | lightnin: its accomplished by hook scripts afaik... like the google chrome dev | 16:28 |
| shadeslayer | s/dev/deb | 16:29 |
| c_korn | shadeslayer: http://pastebin.ca/1810320 replace the spaces with a tab | 16:29 |
| shadeslayer | lightnin: so you just link your PPA binaries to the site,users download them install via gDebi | 16:29 |
| shadeslayer | and the hookscript adds the ppa | 16:30 |
| shadeslayer | !hook | 16:30 |
| shadeslayer | meh | 16:30 |
| shadeslayer | c_korn: http://pastebin.ca/1810324 | 16:31 |
| shadeslayer | lightnin: https://wiki.ubuntu.com/PbuilderHowto | 16:31 |
| shadeslayer | lightnin: at the end of that page are hookscripts | 16:32 |
| c_korn | shadeslayer: bad-ubuntu-distribution-in-changes-file unstable <-- you said you knew what to do :) | 16:32 |
| c_korn | change the unstable release in debian/changelog to karmic or whatever release you upload to | 16:32 |
| shadeslayer | c_korn: yeah im building for lucid first | 16:33 |
| shadeslayer | so just leave that... the other 2 warnings | 16:33 |
| lightnin | shadeslayer: That's pretty cool! Thanks. Have to wishlist it for now, no time. But really good to know. | 16:33 |
| shadeslayer | lightnin: no problem ;) | 16:33 |
| shadeslayer | c_korn: http://pastebin.ca/1810327 | 16:34 |
| shadeslayer | c_korn: sooo | 16:37 |
| c_korn | shadeslayer: you can easily fix the warnings. just change the build-dependecy in debian/control to debhelper (>= 7.0.50) | 16:37 |
| lightnin | For now, is it possible to get a link to the *latest* version of our binary package for jaunty on our ppa? (i.e. so when we update the ppa, we don't have to change the link on our download page?) | 16:37 |
| lightnin | https://launchpad.net/~scratch | 16:37 |
| shadeslayer | c_korn: i know what about the other? | 16:37 |
| c_korn | and add ${misc:Depends} to the depends of libjoschy-dev | 16:37 |
| shadeslayer | done and no errors... uploading | 16:38 |
| === jono_ is now known as jono | ||
| shadeslayer | lightnin: check out : https://launchpad.net/~scratch/+archive/ppa/+packages | 16:39 |
| shadeslayer | lightnin: then click on any package | 16:39 |
| shadeslayer | c_korn: its building for just 32 bit | 16:48 |
| shadeslayer | c_korn: build fails : http://launchpadlibrarian.net/39783274/buildlog_ubuntu-lucid-i386.joschy_0.0.0.1%2Bgit20100225-0ubuntu0~ppa7_FAILEDTOBUILD.txt.gz | 16:50 |
| nigelb | boa constructor comes under universe does it not? | 16:51 |
| c_korn | shadeslayer: oh, my fault. I was compiling for amd64. one sec | 16:53 |
| shadeslayer | ;) | 16:53 |
| c_korn | shadeslayer: replace the line mv ... in debian/rules with this: [ ! -d debian/tmp/usr/lib64 ] || mv debian/tmp/usr/lib64 debian/tmp/usr/lib | 16:54 |
| nigelb | I ran update-mainainer on boa constructor and it added the ubuntu-devel-discuss mail ID, is that correct? | 16:54 |
| c_korn | you also have to increment the debian revision in debian/changelog now | 16:54 |
| shadeslayer | c_korn: http://pastebin.ca/1810362 | 16:56 |
| shadeslayer | c_korn: yeah i know ;) | 16:56 |
| c_korn | shadeslayer: http://pastebin.ca/1810363 | 16:57 |
| sshaw | I'm completely new to the ubuntu/debian packages worlds. I have a team ppa setup and need some packages from lucid for karmic | 16:58 |
| sshaw | for example I need at-spi 2.29.X for karmic | 16:58 |
| ScottK | This channel is not for PPA support. | 16:59 |
| ScottK | It's for development of Ubuntu. | 16:59 |
| sshaw | ScottK: sorry, someone pointed me to here :( | 17:03 |
| sshaw | ScottK: what is the better channel? I'm completely new to ubuntu and all things ubuntu :( | 17:04 |
| geser | nigelb: yes, it's correct. All packages use it. | 17:05 |
| nigelb | ah, so one build failure fixed :) | 17:05 |
| bcurtiswx | whats the best way for me to start learning c/glib ? | 17:05 |
| * bcurtiswx appears to be a chat killer | 17:07 | |
| nigelb | can someone sponsor bug 527084 when they get time, build dep fixed :) | 17:08 |
| ubottu | Launchpad bug 527084 in boa-constructor "Cannot be installed in Lucid" [Undecided,In progress] https://launchpad.net/bugs/527084 | 17:08 |
| nigelb | geser: thanks :) | 17:08 |
| geser | nigelb: if you want it sponsored to lucid, then you should mention lucid in the changelog (and not karmic) | 17:10 |
| * nigelb has been forgetting this for long | 17:10 | |
| nigelb | geser: fixing | 17:11 |
| geser | and it would be nice if you would close your bug in your changelog (add "(lp: #527084)" to your changelog entry) | 17:11 |
| nigelb | geser: fixed :) | 17:12 |
| nigelb | geser: I did the whole thing right the first time, but forgot to update maintainers | 17:12 |
| nigelb | this time I did update maintainers but forgot everything else | 17:12 |
| geser | and the next time you either do everything right or forget everything? :) | 17:14 |
| nigelb | geser: I'm late for work, that could contribute to my amnesia | 17:14 |
| ScottK | sshaw: There probably isn't a great one. It's at least not off topic in #launchpad. | 17:27 |
| sshaw | ScottK: thanks | 17:28 |
| toabctl | what about source package wacom-tools? is this no more available in lucid? | 17:28 |
| randomaction | toabctl: https://launchpad.net/ubuntu/+source/wacom-tools/+changelog | 18:06 |
| randomaction | ( renamed to xf86-input-wacom) | 18:07 |
| === toabctl_ is now known as toabctl | ||
| hyperair | superm1: it seems lirc is orphaned in debian, and you've been handling the ubuntu version pretty well. could i ask you to bring your changes to debian? it seems that it's been orphaned, and the lirc packaging team (https://alioth.debian.org/projects/pkg-lirc/) has gone inactive. | 18:09 |
| superm1 | hyperair, it isn't orphaned as far as i'm aware | 18:09 |
| hyperair | it isn't? | 18:09 |
| superm1 | hyperair, i started to push some stuff up to them and they took some of it | 18:09 |
| hyperair | hmm i see. | 18:09 |
| hyperair | but they're 3 releases behind | 18:10 |
| hyperair | =\ | 18:10 |
| Quintasan | hyperair: a bit late but grats :) | 18:10 |
| hyperair | Quintasan: heh thanks =) | 18:10 |
| superm1 | hyperair, wow though, they are a bit behind, i guess it's been a while since i had any communication with them | 18:10 |
| superm1 | do you know how to find their git, we can see what the last update was | 18:11 |
| hyperair | superm1: yeah, it'd be awesome if you could give them a nudge or something. maybe even join the team and prepare their uploads ;-) | 18:11 |
| hyperair | superm1: they use svn. | 18:12 |
| shadeslayer | c_korn: yeah sorry about that | 18:12 |
| superm1 | hyperair, ah yeah. so they've got commits within the last two months | 18:12 |
| shadeslayer | c_korn: i dont think the package built properly :) | 18:12 |
| superm1 | but not nearly as active as is ideal | 18:13 |
| hyperair | superm1: right. so why don't you join the team and make a difference? ;-) | 18:13 |
| shadeslayer | c_korn: https://launchpad.net/~rohangarg/+archive/playground/+packages | 18:13 |
| shadeslayer | the packages are just 2 KB's in size | 18:13 |
| superm1 | hyperair, it's a lot of work splitting up our patches to send up, and i got rather discouraged when they didn't respond for several months | 18:13 |
| c_korn | shadeslayer: sorry about what ? as I saw the install files were not executed. probably they have a wrong name | 18:13 |
| superm1 | and then only took a few of them | 18:13 |
| c_korn | shadeslayer: what is your debian/control and what is `ls debian/*.install` ? | 18:14 |
| hyperair | superm1: try talking about taking over the package. | 18:14 |
| hyperair | superm1: if you poke them and they don't respond for over a week, you're allowed to NMU or even hijack the package. | 18:14 |
| superm1 | hyperair, honestly; i've got a lot on my plate already here, i dont want to commit to that atm | 18:14 |
| hyperair | superm1: okay then =\ | 18:14 |
| hyperair | superm1: are there many ubuntu specific patches? | 18:15 |
| superm1 | especially since that would mean i'd have to work through a sponsor in debian to help push | 18:15 |
| superm1 | hyperair, yes, there are a lot of extensions we've added | 18:15 |
| * hyperair sighs | 18:15 | |
| hyperair | looks like i won't be able to make banshee-community-extensions syncable =\ | 18:15 |
| superm1 | I *tried* to push a lot up :( | 18:15 |
| superm1 | someone came and helped with the ubuntu packages last cycle and helped us to get a lot of our patches to upstream upstream lirc | 18:16 |
| hyperair | cool | 18:16 |
| superm1 | but still until the debian packaging is more in sync; particularly the postinst, it's not a good operating model right now | 18:16 |
| * hyperair nods | 18:17 | |
| hyperair | i'd love to help, but i don't have an lirc device and can't test | 18:17 |
| superm1 | well testing isn't the big problem, it's really a matter of comparing why we have deltas in debian/ and convincing debian they need our deltas in a lot of cases | 18:17 |
| superm1 | and splitting those into smaller more eddible snippets again | 18:18 |
| hyperair | heheh sounds like loads of work. | 18:18 |
| hyperair | @_@ | 18:18 |
| shadeslayer | c_korn: sorry about the fact that i had to go :P | 18:19 |
| shadeslayer | c_korn: http://pastebin.ca/1810473 << contro | 18:21 |
| Quintasan | Why libjpeg7-dev is not present in lucid? | 18:22 |
| shadeslayer | c_korn: ls: cannot access debian/*.install: No such file or directory | 18:23 |
| c_korn | shadeslayer: you did not put the .install files into the debian directory | 18:24 |
| c_korn | everything which is packaging related has to be in the debian directory | 18:25 |
| JontheEchidna | Quintasan: it's libjpeg8 now | 18:25 |
| shadeslayer | oh | 18:25 |
| JontheEchidna | though, there doesn't seem to be a -8 in the archive :/ | 18:25 |
| JontheEchidna | should be according to the changelog though: https://edge.launchpad.net/ubuntu/+source/libjpeg7 | 18:26 |
| Quintasan | JontheEchidna: kffmpegthumbnailer conflicts with new ffmpegthumbnailer (bump in lib version) here | 18:26 |
| Quintasan | JontheEchidna: hmm, seems I'm doing it wrong, let me check something first | 18:27 |
| shadeslayer | c_korn: http://launchpadlibrarian.net/39786079/buildlog_ubuntu-lucid-i386.joschy_0.0.0.1%2Bgit20100225-0ubuntu0~ppa9_FAILEDTOBUILD.txt.gz | 18:36 |
| shadeslayer | c_korn: i guess we need usr/lib/lib*.a | 18:36 |
| c_korn | shadeslayer: your libjoschy-dev.install file _only_ has to contain this line: usr/include | 18:37 |
| c_korn | shadeslayer: also you can set the -dev package arch-all in debian/control | 18:37 |
| shadeslayer | c_korn: oh | 18:38 |
| shadeslayer | c_korn: i dont think it built even now :P | 18:48 |
| Quintasan | mr_pouit: ping | 18:49 |
| shadeslayer | c_korn: http://launchpadlibrarian.net/39786462/buildlog_ubuntu-lucid-i386.joschy_0.0.0.1%2Bgit20100225-0ubuntu0~ppa10_FULLYBUILT.txt.gz | 18:49 |
| c_korn | shadeslayer: the -dev package is fine. but the lib package not. probably the install file has a wrong name | 18:51 |
| shadeslayer | c_korn: so.. what is the correct name | 18:52 |
| shadeslayer | c_korn: btw thanks for your patience :) | 18:52 |
| shadeslayer | this is my last try.. then im sleeping :P | 18:52 |
| Quintasan | Can anyone help me with debuild error? http://pastebin.ca/1810516 if I switch the package to source format 3.0 it works | 18:52 |
| c_korn | shadeslayer: libjoschy1.install . the contect has to be: usr/lib | 18:52 |
| shadeslayer | c_korn: i guess 11 is a lucky no. | 19:00 |
| shadeslayer | c_korn: it built! | 19:00 |
| shadeslayer | libjoschy1_0.0.0.1+git20100225-0ubuntu0~ppa11_i386.deb (321.4 KiB) | 19:00 |
| shadeslayer | c_korn: are you available on 27th Feb 1700 UTC? | 19:01 |
| c_korn | shadeslayer: probably | 19:02 |
| shadeslayer | c_korn: ok can you join me in #ubuntu-classroom | 19:03 |
| c_korn | is there another session coming this weekend ? | 19:03 |
| shadeslayer | ill be giving a presentation about PPA's and how to use them,your expertise will be appreciated :) | 19:03 |
| shadeslayer | :P | 19:03 |
| shadeslayer | i didnt know how to package libraries... | 19:03 |
| shadeslayer | still dont,but ive begun to understand | 19:04 |
| c_korn | shadeslayer: ok, I hope I could help you a bit | 19:04 |
| shadeslayer | c_korn: yes you can :D | 19:04 |
| shadeslayer | oh and btw ill meet you same time tommorow for the details of this lib | 19:04 |
| shadeslayer | fine with you? | 19:04 |
| shadeslayer | c_korn: ^^ | 19:06 |
| c_korn | shadeslayer: ok, just ping me :) | 19:06 |
| shadeslayer | sure | 19:08 |
| paki | hi all | 19:51 |
| paki | i'am a mantainer, can i include my changelog for update-manager? | 19:51 |
| paki | how to do? | 19:51 |
| paki | anyone can help me? | 19:55 |
| Rhonda | I am not really sure what you mean with your question. | 19:56 |
| jdong | Rhonda: I think he means can his changelog show up for a PPA/3rd-party-repo package in update-manager's GUI | 19:56 |
| jdong | and AFAIK the answer to that is no | 19:56 |
| paki | no no | 20:01 |
| paki | how can i compile my project with ChangeLog file in source? | 20:01 |
| paki | it is read from update-manager for show the changelog | 20:02 |
| paki | excuse my crappy english | 20:02 |
| Rhonda | I think rather update-manager displayes the debian/NEWS file. | 20:03 |
| paki | news file? | 20:03 |
| jdong | update-manager AFAIK displays neither. it fetches from changelog.ubuntu.com | 20:03 |
| paki | not changelog? | 20:03 |
| jdong | which is only for the Ubuntu official repositories. | 20:03 |
| jdong | http://changelogs.ubuntu.com/ rather | 20:04 |
| jdong | plural | 20:04 |
| * Rhonda . o O ( There is more than one on that site ;) ) | 20:04 | |
| paki | uff i don't understand | 20:05 |
| paki | in many source i see files:Changelog AUTHORS etc.. | 20:06 |
| paki | how can i compile my project for create these file? | 20:06 |
| c_korn | where can I ask for help about sourceforge redirector for debian/watch files ? there seems to be a bug. it does not find the project zaz http://qa.debian.org/watch/sf.php/zaz although it clearly exists: http://sourceforge.net/projects/zaz/files/ | 20:08 |
| Rhonda | paki: They are part of the upstream sources, you don't "compile" them, upstream does write them. | 20:12 |
| Rhonda | c_korn: Try #debian-qa on irc.debian.org (OFTC) | 20:12 |
| paki | ok, write | 20:12 |
| paki | but what? | 20:13 |
| paki | file's name etc.. | 20:13 |
| Rhonda | Upstream does that. If they aren't there, you as package maintainer shouldn't care. | 20:13 |
| toabctl | is there a guide howto update a package with a new version from upstream? (without a watch file) | 20:14 |
| Rhonda | toabctl: uupdate ../new-upstream.tar.gz | 20:14 |
| Rhonda | … optional it might require the new upstream-version as additional argument, but it will tell you so. | 20:14 |
| paki | no, i'm a mantainer and developer | 20:14 |
| toabctl | Rhonda, thanks! | 20:15 |
| === yofel_ is now known as yofel | ||
| GaryvdM | Hi | 20:41 |
| GaryvdM | I'm trying to upload a package to a ppa | 20:42 |
| GaryvdM | When I uploaded it, it's name ended up as 'dulwich', not 'python-dulwich' | 20:43 |
| GaryvdM | But in the debian/control file, Its got 'Package: python-dulwich' | 20:45 |
| randomaction | source package and binary package may have different names | 20:45 |
| GaryvdM | Ah, that may be it | 20:46 |
| ScottK | And this channel isn't for PPA support | 20:57 |
| GaryvdM | ScottK: Sorry. Where should I go? | 20:58 |
| ScottK | Dangrous question that one. | 20:59 |
| ScottK | There really isn't a great channel. It's at least not off topic in #launchpad. | 20:59 |
| GaryvdM | Ok | 20:59 |
| === fta_ is now known as fta | ||
| arand | GaryvdM: Yea, python-dulwich seems to be built as one part of the "dulwich" source package, you should get the p-d package when it's been built.. | 21:04 |
| toabctl | how can i update a package to a new upstream version with bzr? | 21:07 |
| toabctl | i got the package with bzr branch lp:/ubuntu/xf86-input-wacom and want to apply the new upstream version to the package. | 21:07 |
| GaryvdM | toabctl: I *think*, if you have a new version of bzr-builddeb, you can do bzr merge-upstream | 21:35 |
| GaryvdM | IANAE | 21:35 |
| MTecknology | If you have a version of one package (0.9) that depends on a specific version for another package (1.5); how should that look in the changelog and as a version? They call the version 0.9~1.5 and in the tarball they call it 0.9-1.5. In my head it seems more fitting to call it 0.9 and just depend on that exact package version | 22:04 |
| MTecknology | !depends | 22:16 |
| micahg | c_korn: are you planning on backporting vlc anymore? | 22:31 |
| c_korn | micahg: it is done on getdeb.net now. | 22:36 |
| c_korn | http://www.getdeb.net/software/VLC | 22:37 |
| micahg | c_korn: k, thanks | 22:37 |
| === nhandler_ is now known as nhandler | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!