=== emma_ is now known as emma [00:22] ah quadrispro just left. [00:22] I was gonna hand out today's amusing SRU debdiff of the day award [00:22] http://launchpadlibrarian.net/36055807/xvidcap_1.1.7-0.2ubuntu5.1-SRU.patch [00:26] O_O [00:27] jdong: that is an interesting way to do it [00:28] yup. [00:29] jdong: what's the procedure where there's a version in proposed and I have another patch? === micahg1 is now known as micahg [00:33] jdong: sorry if I missed your response [00:36] <\sh> damn...for our rollout tonight, we needed the new puppet release from karmic...good that I have a buildserver [00:37] \sh: working late? [00:37] micahg: wait for the SRU to fully verify and go into -updates [00:37] and then start the new SRU against that. [00:38] jdong: ok, I guess I can't do my SRU then until the other one goes through [00:38] <\sh> ajmitch, software rollout tonight :) so nightshift :( [00:38] micahg: correct [00:38] can I prepare and test on top of it in a PPA? [00:39] \sh: luckily rollouts for me wouldn't take that long [00:40] <\sh> ajmitch, 32 BL465cG5 + 16 DL385G5P + 16 DL365G5 + some other crappy machines named fujitsu siemens [00:40] <\sh> ajmitch, god knows, that I'm an automation fetishist .. FAI + Puppet rocks [00:41] well you'd want at least some automation with that many machines [00:41] <\sh> ajmitch, but two drbd splitbrains on some database machines keeps my blood pressure up ;) [00:42] you can't get too bored or they'll replace you ;) [00:42] <\sh> ajmitch, teamlead of us didn't want automation...good that I'm not compatible with those PoV and I'm not following my boss...no clue this guy [00:43] he wants everything done & repeated ad nauseam on every machine? [00:43] <\sh> ajmitch, yes [00:44] I guess if he wants to spend a week doing it.. [00:44] <\sh> ajmitch, that was former world order here [00:45] now it's work for 1 evening & relax for a week, I hope :) [00:46] * ajmitch wonders if the new package sets are visible in the LP UI [00:47] <\sh> ajmitch, next update is already knocking at our door [00:48] ajmitch: You can view the package sets here if you want: http://people.canonical.com/~cjwatson/packagesets [00:48] * nhandler isn't sure how up-to-date that is though [00:49] nhandler: thanks, I was just waiting for bzr to give me a branch to dig into it :) [00:49] ajmitch: No, no UI. [00:50] Although one might spring up soonish, since the schema is finalised. [00:50] if someone has time & cares enough for it [00:50] I'm just trying to understand how this'll affect various upload rights [00:51] Component permissions override all, so this is a purely additive move. [00:53] right [00:53] looks like those package sets needs a bit of refining [00:54] I'd have expected ubuntu-server to include apache2, and not packages like gst0.10-python :) [00:56] hello [00:57] i'm interesting in creating and maintaining packages for ubuntu... I have one year experience with linux.. but not much for packaging [00:57] where do I start ? [00:57] I know how to compile programs and manage dependencies [00:58] I mainly interesting in creating packages that are requested by users but not yet included in the default repos [00:59] the packaging guide is a good start for that [01:00] it's linked from https://wiki.ubuntu.com/MOTU/Contributing#Preparing New Packages [01:00] ok [01:00] thanks [01:01] for a beginner .. what type of programs should i start packaging ? should I avoid big programs that have fancy installation methods [01:01] and just stick to the ones that work with make and make install ? [01:01] until i get more experience ? [01:02] most of them will be based around autotools, something more complex will probably lead to frustration [01:03] i guess i will need to keep contact with both ubuntu and debian packagers [01:03] because the packages need to be included first in debian and then ubuntu [01:03] right ? [01:04] it's generally suggested to do it that way [01:05] is there a specific category where package maintainers are lacking ? [01:05] where the is help needed ? [01:05] there is* [01:06] probably more with fixing bugs than bringing in new packages :) [01:06] :) ! [01:07] filling bugs are very important very true [01:07] most people don't realise that the developers are quick at fixing after reporting them [01:07] so they don't even file the report [01:08] and sometimes the bugs need to be reported at the proper website. it's not always launchpad [01:09] anyways.. i will start reading the documentation on my time [01:09] and see what packages i can start with [01:09] thank you very much [01:10] alright, there's often people around here if you have questions [01:10] ok.. any other irc channels that i should frequent for this type of stuff ? [01:11] #ubuntu-devel, but here is more appropriate for general questions [01:12] perfect [01:12] take care [01:12] bye [01:14] hi [01:14] if i make a Linux-Libre deb, what would i have to do to get it into the repos? [04:35] fabrice_sp, around? [04:35] meoblast001: What is it? [04:36] mannyv, 'morning :-) [04:36] ScottK: Linux-Libre? [04:36] should be 'night here :-) [04:36] meoblast001: Yes. [04:36] it's Linux with all the nonfree components (hex firmwares) stripped [04:36] :-) [04:36] the FSFLA (FSF Latin America) made it [04:37] and they maintain it as well [04:37] i was wondering, since you have been the one to sponsor almost all of my sync requests, is attaching the build log helpful for you [04:37] is it something i should keep doing? [04:38] meoblast001: I think the non-free firmware is already separated into a separate package in Ubuntu, so I'm not sure what the point would be. [04:38] mannyv, I always build again the debian package (I don't trust what sponsoree attach, except the debdiff :-D ) [04:38] meoblast001: There's even a free software only option in the installer if you want to avoid all non-free stuff. [04:38] I was think about a script that make that in a automatic way (even subscribe to the launchpad bug report :-D ) [04:38] mannyv, ^ [04:39] ScottK: from my understanding, this is not a fully free Linux [04:39] to make attaching the build log automatic? [04:39] ScottK: by "free software only" that means everything except for Linux from what i'm told [04:39] meoblast001: Then file bugs. It should be. I don't think carrying an entire duplicate kernel is a great idea. [04:40] ScottK: the bug is already known of [04:40] meoblast001: That was once the case, but there's a separate restricted linux-firmware package. [04:40] there has to be a seperate kernel package [04:40] meoblast001: Is it filed in Launchpad? [04:40] the firmware is in many cases compiled into the kernel [04:40] ScottK: yes [04:40] mannyv, no: to get the package from Debian (dget), and compile it. I also always install it, and try to play with it, but that part cannot be made automatically [04:41] fabrice_sp, oh because u was going to say i have actually modified my version of requestsync so that i can do that, works with launchpad api but not email yet [04:41] ScottK: https://bugs.launchpad.net/ubuntu/+bug/370675 [04:41] Launchpad bug 370675 in ubuntu "[needs-packaging] Linux Libre kernel" [Wishlist,In progress] [04:41] meoblast001: IIRC what this is about is removing the ability to use non-free firmware if a user chooses to and not actually removing firmware. [04:41] meoblast001: I mean bugs against the existing kernel. [04:41] ? [04:41] oh no [04:41] meoblast001: How is that different to the ongoing Debian project of shifting the firmware out of the kernel and into linux-firmware? [04:42] RAOF: Much of which we've already done. [04:42] ScottK: Indeed. [04:42] i know gNewSense shifted to LinuxLibre [04:42] RAOF: It's about removing the ability to use non-free firmware at all. [04:42] ScottK: In what way does that make the kernel more free? [04:42] RAOF: It doens't [04:42] i haven't looked through all of Linux's source, but i know that if there wasn't still a problem with it, LinuxLibre wouldn't still be under development [04:43] meoblast001: That's an interesting way to look at the problem. [04:43] i'm not going to lie, i haven't looked through all the code of Linux [04:43] mannyv, a "Sponsor this" script would make sense :-) It would unsubscribe u-u-s, subscribe you, mark as in Progress, and load the "wishlist" importance :-D I njeed to have a look at ubuntu-dev-tools, or whatever is his name [04:44] meoblast001: It takes a significant maintenance commitment to keep an alternate kernel tree in sync with the Ubuntu kernel. There is a group that does this already for the Ubuntu Studio real time kernel. I doubt we would be willing to accept yet another kernel without a team to keep it updated. [04:44] mannyv, and check what exists [04:44] ScottK: i did read though that the shift of firmware out of the kernel into seperate packages is the longterm goal, but until then (it isn't completed yet), a seperate kernel, LinuxLibre, exists [04:45] fabrice_sp, sounds like a good idea, i would like that... if i could sponsor [04:45] meoblast001: If there is still non-free firmware in our kernel, it's a bug. Just identify what needs to be moved (in bug reports) and it should get dealt with. [04:45] ok [04:46] Thinking of (potentially) non-free (kinda) firmware, I wonder how we're going to deal with nouveau. [04:49] mannyv, :-D All comes with time ;-) [04:50] fabrice_sp, yeah im not trying to rush it, i still have a lot to learn about how everything fits together [04:51] mannyv, after participating to a full release cycle, everything makes sense :-) And we all have a lot ot learn ;-) [04:57] RAOF: i know a Nouveau dev, he said it's coming along well [04:57] RAOF: they will have it deblobbed in a few weeks [04:58] ScottK: courier is complaining about 2 .mo files [04:58] ScottK: did you know anything about it? [04:58] ScottK: the error is a sanity check in the rules file AFAIK [04:58] nxvl: Nope. [04:58] ScottK: http://launchpadlibrarian.net/36034994/buildlog_ubuntu-lucid-armel.courier_0.63.0-1ubuntu1_FAILEDTOBUILD.txt.gz [04:59] nxvl: I'd suggest a bad merge and something got duplicated, perhaps. [04:59] ScottK: /build/buildd/courier-0.63.0/debian/tmp/usr/share/locale/{de,sv}/LC_MESSAGES/pcp.mo [04:59] ScottK: it seems to me that it's a translations something [04:59] It is. [05:07] nxvl: I'm not sure what to do about that. [05:20] bug 487876 has been rejected, because the orig tarball is different between Ubuntu and Debian, and I've been asked to do a 'fakesync'. Where can I find information on how doing a fakesync? [05:20] Launchpad bug 487876 in checkgmail "Sync checkgmail 1.13+svn43-1 (universe) from Debian testing (main)" [Wishlist,Invalid] https://launchpad.net/bugs/487876 [05:21] is it like a 'false' merge (ie. no changes in Ubuntu)? [05:22] fabrice_sp: I knew that was going to come up :-) [05:22] lol [05:22] sorry to bug you about htat StevenK :-) [05:22] fabrice_sp: The first step is find out why the orig tarballs are different [05:22] it's my firs fake sync ;-) [05:22] ok [05:27] it's becaue the date of the man directory (the day it has been exported, it seems) :-/ but the content is the same [05:28] so I think the Ubuntu orig tarball can be substituted with the Debian one [05:29] StevenK, ^ [05:31] the problem is that there's already a version with that tarball in the archive [05:32] that's where the fakesync comes, I suppose [05:32] so you can't just go from one ubuntu revision to a new debian revision, keeping the upstream version the same with a different tarball [05:32] yep [05:33] fabrice_sp, i have been looking at these two tarballs and i cannot find any differences [05:33] mannyv, neither do I :-) [05:33] ScottK, ^ [05:34] md5sum tarball.orig.tar.gz [05:34] so ajmitch, how do you perform this 'fakesync', knowing that there is no difference right now between the 2 packages (debian directory) [05:34] You'll get different results. [05:34] sorry ScottK ignore tha [05:35] is it worth it? The fakesync. Maybe, we should just wait for another new upstream version [05:36] fabrice_sp: Take the Ubuntu tarball, unpack it, add the debian/dir from the Debian version of the package, and then add an ubuntu1 entry in debian changelog that says * Fakesync due to different orig.tar.gz md5sums [05:36] So you end up with the Ubuntu tarball and the Debian packaging in one source package. [05:37] what ScottK said ^^ (I got distracted by shinies) [05:41] ok. thanks to all! [05:43] fabrice_sp, i still wonder why they have different md5sums. I untared both of them into separate directories and and checked the md5sums for each file individually and they are identical. I guess they must have tared or gzipped differently? [05:43] mannyv, the date of the man directory is different [05:43] everything else is identical :-) [05:44] fabrice_sp, nice spot! [05:49] so out of curiosity if we can see that the only difference between the two is the date of a directory, why can't we just sync with the debian version? [05:49] Because once an orig.tar.gz is in the archive, we don't allow it's md5sum to change. It's a security/archive consistency feature. [05:50] It's not a big deal, just fakesync until the next upstream and then sync for real when that's in Debian. [05:54] ScottK, i was just curious to know why. There are so many little things that are not really written anywhere (or at least the major first exposure documents) so it helps for my own note keeping/memory [05:57] Grr. This upstream promised me that he would ship a copy of the GPL in the next release. Out it comes, with no GPL file in sight again. [06:00] how long does something last in -proposed before it's pushed to updates? [06:01] mannyv, don't get scared about strange things happening to bug 488227: I'm experimenting with python and lp integration :-) [06:01] Launchpad bug 488227 in software-properties "IndexError: list index out of range" [Undecided,New] https://launchpad.net/bugs/488227 [06:01] mannyv: As I mentioned, security and archive consistency. While verified non-differences like this are harmless, the md5sum check gives us a good way to make sure the contents of a package release don't change once they are in the archive either accidentally or on purpose. [06:02] hmm, 488427 [06:03] ScottK: how long does something last in -proposed before it's pushed to updates? [06:03] micahg: Roughly 10 days or so [06:04] micahg: But it needs a few people to say it's good, and no one saying it isn't [06:04] hmmm, what if something's been there 3 weeks? [06:04] micahg: Is it marked verified? [06:04] hmm, let me see [06:04] It's minimum time and tested both [06:05] ah, no one verified [06:07] it's not my patch, but I want to push one through after it [06:08] micahg, just test then that it's fixing the bug, and it will make it quicker :-) [06:09] fabrice_sp: it's actually one of your SRUs :) [06:09] micahg, really? [06:09] yeah [06:09] for UIM [06:09] tell me which, and I'll check [06:10] bug 460280 [06:10] Launchpad bug 460280 in uim "package uim-qt3 (not installed) failed to install/upgrade: trying to overwrite '/usr/share/locale/ja/LC_MESSAGES/uim.mo', which is also in package libuim-data 1:1.5.6-0ubuntu1" [Undecided,Fix committed] https://launchpad.net/bugs/460280 [06:12] I'll be back in about an hour [06:12] ok: I'll check that it's really fixed in -proposed [06:12] ok [06:12] great, thanks, then I can work on getting my fix into -proposed [06:12] :-) [06:17] g'night all [06:21] g'night mannyv [06:34] jdong, one more SRU: bug 481732 :-) [06:34] Launchpad bug 481732 in luciole "Webcam acquisition does not work on luciole under karmic" [High,Fix released] https://launchpad.net/bugs/481732 [07:39] ajmitch: the package sets are generated from seeds. If there's weirdness, it just reflects weirdness in the seeds and the archive. apache2 is in core because stuff all over the place needs it [07:41] cjwatson: fair enough, I assume these will just get cleaned up over time as needed [07:43] sometimes it's intrinsic [07:43] If the upstream tarball includes Qt .qm translations, should I remove them and generate them from .ts files during build, or leave them as is? [07:44] the ubuntu-server package set isn't "everything that's useful on the server", it's "things that don't affect the whole world and that are used on the server" === mac_v is now known as mac_v`afk [07:44] it's mostly my misunderstanding of what the package sets are then :) [07:52] good morning === mac_v`afk is now known as `afk === mac_v is now known as mac_v`afk === mac_v`afk is now known as mac_v [08:24] hey folks! [08:27] hey siretart, siretart` [08:27] heh [08:28] I should probably just shut down my irssi client and convert fully to rcirc... [08:31] good morning [08:32] siretart`: people often lose a whole day when switching IRC clients :) [08:33] hi highvoltage [08:33] heya dholbach [08:38] highvoltage: and sometimes a whole server, (iptables + ENTER key pressed too quick) :) [08:40] DktrKranz: heh :) === micahg1 is now known as micahg === azeem_ is now known as azeem [09:36] fabrice_sp_: are you planning work on hk_classes? [09:41] Has anyone seen this weird problem of blank fstab file? I found a bug on LP but there is no info on how to fix it. [09:57] slytherin: this is not really the correct channel; try the main ubuntu channel [09:57] can I make a backport for a amd64 using launchpad? I have a 32 bit myself [09:57] flower: PPA questions should be in #launchpad [09:57] using this method: http://pastebin.com/m6fa3a5e1 [09:58] anyone have any information about progress on the main sponsor queue; submitted a patch almost 2 weeks ago with no further comment (appreciate that last week was hectic) [09:58] m4rtin: I don't expect anyone there to know about this. Anyway, this is usually the channel I lurk in so I asked the question. [09:59] flower: PPAs build binary for i386, amd64 and lpia. All you have to do is upload the source package. === mac_v is now known as mac_v_ [10:00] slytherin: that's what I said in #launchpad :) === lionel__ is now known as lionel [11:08] ttx: there? need to discuss porting of jug to Debian [11:09] slytherin: yes [11:10] ttx: the C files in the source do not have specific copyright notices. But the CREDITS file mentions who provided which code. Is that acceptible? [11:11] * ttx looks [11:13] slytherin: istr Tatu Saloranta holds copyright [11:13] slytherin: that's why I only mentioned the others in the "Authors" list [11:13] * ttx looks deeper [11:13] ttx: overall. But it looks like these files were contributed by other people. Check release-notes/CREDITS [11:14] In most cases that CREDITS is more about someone pointing out a defect rather than contributing a chuck of code [11:15] release-notes/README lists real authors [11:15] but in this case it actually lists who contributed the code [11:15] in any case, do you have any idea if files without copyright are acceptable? [11:16] slytherin: "Leonid Kunin: suggested adding 2 constructors (that were missing)" [11:16] looks like a bug report rather than written code [11:17] slytherin: well, they were accepted in Ubuntu, so they should certainly be acceptable [11:17] slytherin: though we would very much prefer clear copyright info [11:18] Do you think I should mail upstream? [11:19] slytherin: If you can link every C file to an author in CREDITS, I think it's acceptable [11:19] ttx: then that is already done. [11:19] slytherin: mailing upstream cannot hurt, but I wouldn't block on that :) [11:20] ttx: You wouldn't, but FTP masters in Debian might. :-) [11:20] might. :) [11:35] Hi, a packaging question: I'm looking to make 2 packages, one "server" and one "client" (to be installed in school servers and clients respectively). Those two packages will share some source code. What would be better, using a different debian directory for each package, or using a single debian directory and a single control file for both of them? [11:37] alkisg, if they are both build from a single source you should use a multi binary package, a single debian generating multiple .debs [11:38] joaopinto: Thanks. I'd like to build from the same code tree. But, if I change something that only affects the server package, wouldn't also the client package bump to a new version, with no changes at all? [11:38] unless you see foresee the need for different sources for each of the components [11:39] E.g. I change my-server.py, so I get a server 2.0 package, why should the client also get to 2.0 version since my-client.py wasn't changed? [11:39] (sorry my English is a little poor...) [11:40] alkisg, it would, I believe you can force a specific version for the target binary package, but never tried [11:40] bumping the version because a piece of the source was changed is common and not usually a matter of concern :) [11:40] Could I just upload only the server package to launchpad? [11:41] No it's not the version per se that concerns me, it's the unnecessary client updates [11:41] alkisg: only source packages are uploaded. binaries are build on build servers. [11:41] E.g. if the package is 1 Mb, all the clients will download and install 1 Mb without anything changed... [11:41] slytherin: ah, so both would be build, right ... :-/ [11:41] alkisg: don't people read changelog before applying updates? [11:42] Well, nope, teachers don't do that :) (PPAs also don't help, the changelogs don't show up to the update manager) [11:42] Thanks - I'm not looking to innovate here, I was just looking for the usual solution [11:43] alkisg, you have to choose, either you have extra work by keeping two different source packages, or you force both components to be upgraded [11:43] alkisg, 1MB is a big binary :P [11:43] It's just some Kb, it was a figure of speech :) [11:43] alkisg, and do those few KBs justify the extra work :) ? [11:43] Nope :) [11:44] Am I right in that both of the packages will share a common changelog? [11:44] I.e. "version 2.0: updated server.py" ==> will that show up in the client package? [11:44] alkisg, packaging changelog yes [11:45] OK, thanks guys for clearing all that up for me. Much appreciated! :) [11:46] alkisg, and if you have common code, you probably want to move that to a lib* :) [11:46] Ehm, and the lib would be build from the same control/changelog as well, right? [11:47] Ty! [11:48] alkisg, right === mt-lith is now known as miket === miket is now known as michaelt === michaelt is now known as mt [12:07] hello, what do need to change to make this build: [12:07] http://launchpadlibrarian.net/36108620/buildlog_ubuntu-karmic-i386.scikits.timeseries_0.91.3-2~ppa2_FAILEDTOBUILD.txt.gz? === mt is now known as mj-t [12:09] I'm trying to build a package from scratch which requires an environment variable to be set. The environment variable is to define a directory used during the build process. I am seeeing this near the top of debian/rules: SmartEifel=$(CURDIR)/serc.build [12:10] This variable seems to be getting lost before the make command is run. Is there another way I should be doing this? [12:14] pmcenery, try it as "export SmartEifel := $(CURDIR)/serc.build ? [12:15] timmi: try adding python-setuptools to your Build-Depends [12:15] cyphermox: thanks. I am using CDDBS. Should that be above or below the "include" lines? [12:16] pmcenery, I don't think it matters [12:21] cyphermox: thanks... that has worked! [12:21] pmcenery: np :) [12:22] Are there any guidelines about when/how packages should be split into lib* and any other packages like doc? === Zic_ is now known as Zic === mezgani is now known as p3rror [13:19] pmcenery, there are [13:20] pmcenery, you should look at the Debian Policy Manual... if you give me a sec I'll get you a link [13:21] pmcenery, http://www.debian.org/doc/debian-policy/ [13:27] pmcenery, it's chapters 8 and 12; globally you'll want to separate your libraries in libname1 (lib packages, with the development files (.h, .la, etc) in libname-dev, and your documentation in name-doc or libname-doc [13:34] cyphermox: thank you for that. I'll check it out [13:38] I just picked a package from the debian WNPP and have started packaging it. I think I have got quite far. I probably didnt choose the easiest one there. I'm now looking into resolving issues where it doesnt do a standard make install :( [13:49] is there any list of package sets in archives as per new reorg? I am wondering how java packagea are classified. === chuck_ is now known as zul === BlackZ_ is now known as BlackZ [15:46] Hi all - I'm completely new to IRC so be patient with me please :-) [15:53] I would like to start helping to contribute back to the Ubuntu Community, anyone have advice? [15:54] BTW, I am not a programmer :-( [16:03] i suppose the best first step is reporting bugs(?) [16:03] https://help.ubuntu.com/community/ReportingBugs [16:04] or if/when you feel more comfortable, triaging bugs [16:04] https://wiki.ubuntu.com/HelpingWithBugs [16:05] patrickcage, ^ i was going to say the same thing [16:05] patrickcage, also if you speak multiple languages you can contribute translations [16:37] :-[Hello everybody [16:40] hello [16:40] something the matter? [16:41] how can I speka to one or many here? [16:42] you're speaking to one here [16:42] when more people appear, you may speak to many here [16:42] thanks [16:42] can I expect some help here about edubuntu? [16:42] if it's to do with development, probably [16:43] for support, i'd point you to #ubuntu [16:43] or #edubuntu even [16:43] wanna a picture to stay at the bottom of the screen while a kid logs into edubuntu and studies [16:44] right, for those kinda questions, it's best to ask in #edubuntu. (i don't know the answer) [16:45] thanks [16:45] i will join edubuntu [17:24] mannyv, thanks for your input (sorry for delay was away from pc) [17:24] SevenMachines thanks for your input too [17:25] no worries, good luck! [17:50] hello! [17:50] i have TWO packages yes two on revu and I'm here to advertise them and get people to look at them [17:50] The first is a gui editor for rss feeds called rssedit [17:51] The second is a command-line app for querying the gnome-keyring daemon [17:51] both are written in C++ [17:51] aren't they great!! [17:51] the latter is called gkp [17:52] The world of linux SO needs this fine software! [17:52] okay well I'm going back to work. work work. === chuck_ is now known as zul [19:07] * popey wonders if someone can help him with a packaging issue. [19:07] I have a package which builds for karmic and jaunty for my ppa and using pbuilder-dist, just fine [19:07] but it barfs when building for hardy with a debhelper error.. [19:07] http://shellinabox.googlecode.com/issues/attachment?aid=1700113005853053268&name=hardybuildfail.txt [19:07] popey: What version of debhelper does it need? [19:08] popey, which compat level did you specify? [19:08] debhelper (>= 4.0.0), [19:08] popey, seems that dh doesnt support the level you used to build that package [19:08] its not my package [19:09] where is the level specified? [19:09] popey, debian/compat file [19:09] it says 7 [19:09] should it be a lower value for hardy? [19:09] hardy got an old dh release so yes [19:09] lower it and you're done [19:09] excellent [19:09] to something <= 6 [19:10] if it needs debhelper 7 features, then you need to have debhelper 7 available [19:10] If debian/compat is 7, then your Depends on debhelper that says debhelper (>= 4.0.0) needs adjusting. [19:10] ajmitch, I don't think this is the case [19:10] I guess he will be just fine with having it at level 6 [19:11] or even lower [19:11] av`: nor do I, but it took a couple of minutes for me to fetch the build failure :) [19:11] ah ok, np then :) [19:12] jmarsden, your approach is not the best one [19:12] jmarsden, if he's building for hardy is better to lower the compat level [19:12] not the dh level itself [19:12] win! [19:12] thanks for being super quick and helpful everyone! [19:12] np :) [19:12] and have fun packaging! [19:12] av`: The point is that the compat level and the Depends should be the same, right... compat says 6, Depends: should be on 6 also... [19:13] av`: I'm really enjoying it tbh :) [19:13] built a few bits and bobs for people, nothing major, but it's all good [19:13] jmarsden, yes, but he is not packaging anything that will go into the archive [19:13] it's for his own purpose === RainCT is now known as RainCT_ [19:13] av`: OK. [19:14] so I guess popey doesnt care about proper packaging :) [19:14] :) [19:14] one day === RainCT_ is now known as RainCT [19:14] popey, just train a lot [19:14] and you'll make it [19:15] popey, anyway just remember that the compat level should go along with the dh version [19:16] will do [19:16] popey, you specify into debian/control [19:16] popey, so if you lower the dh level on debian/control you need to lower the compat level [19:16] as well [19:16] :) [20:45] hello ... I have a package https://launchpad.net/~cherokee-webserver/+archive/ppa but this package generates a /var/lib/cherokee/graphs I need that this directory get chowned by www-data I've added a chown to debian/rules but no luck .. [20:48] what is the orig.tar.gz file? [20:49] leonel, have a look at dpkg-stateovveride [20:49] flower, is the tarball that contains upstream files [20:50] av`: and diff.gz? [20:51] http://pastebin.com/db610b57 [20:51] flower, the modifications you added [20:51] this is how the rules are .. [20:51] flower, the diff that gonna be applied to the orig [20:51] av`: right, and the *.dsc? [20:52] flower, usually contains some data, like the source format, the maintainers, the build-depends, the md5sums of other files etc [20:52] av`: do you mean to add dpkg-stateoverride [20:52] av`: to debian/rules ? [20:52] leonel, read the man page of dpkg-stateoverride :) [20:53] leonel, you'll know how to use it, which syntax it uses and much more [20:53] :) [20:53] av`: no man page and package installed looking for that man page somewhere else thanks [20:54] leonel, http://man-wiki.net/index.php/8:dpkg-statoverride [20:54] leonel, or read the docs on debian developers references [20:55]