=== fta` is now known as fta === luciano_ is now known as virusuy [04:38] hi! [04:38] i'm packaging from scrath.. some unity's launchers [04:39] i'm at control file [04:39] and i don't know in wich Section can i put this launchers [04:54] virusuy: Find another package that's similar. See what they used. [04:55] ScottK: ok! [07:03] guten morgen [07:04] hello highvoltage [07:33] Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn === nigelb is now known as Guest86583 === Guest86583 is now known as nigelb [12:22] lucidfox, thanks for your advocate! [12:23] No problem :) === hannesw_ is now known as hannesw === ximion1 is now known as ximion === ximion is now known as ximion1 === ximion1 is now known as ximion [15:01] Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn === ScottL is now known as scott-downstairs === yofel_ is now known as yofel === hrw is now known as hrw|away === Quintasan_ is now known as Quintasan [17:10] this is the changelog I got from the source I pulled from debian. http://paste.ubuntu.com/604138/ how can a debian's changelog have ubuntu specific entries? O_O === scott-downstairs is now known as ScottL [17:27] the same way an ubuntu changelog can have debian ones [17:27] if it reflects the history of the package, why not? [17:31] Laney: but most of the time we either sync or merge from debian. so package comes first in debian and then its ubuntu version comes. Look at the changelog, there is no entry for debian's 15-0 but there is entry for 15-0ubuntu1. [17:31] there's no reason that it can't happen either way round [17:31] the first line of the latest changelog even says this [17:32] hmm... [17:33] Laney: ok, so according to the first changelog entry debian is synching with ubuntu, so there is no need for us to call a syn request. Am I correct? [17:34] debian /did/ copy the ubuntu package once, but now as their version is higher than ours then it can be synced [17:35] hmm... don't you think that our repo will then contain a package with two different versions but same content? [17:35] or you can speak to the maintainer and find out what he's planning on doing [17:35] two different versions? no, the old one will go away just like it always does [17:36] old version goes away? I didn't knew that. o_O that's new info, thanks :) [17:37] old version goes away in the release it gets uploaded to [17:37] it will still be available in older releases [17:37] yofel: so for one release there can be only one version at a time. got it :) [18:00] all, hello. In a preinst file, a call to source debconf lib (. /usr/share/debconf/confmodule) leads to a failure whe pre installing the package (return error status 30). But this exactly same package still works find in Lucid. I check the changelog but nothing to light me. [18:01] all, does anybody has any idea on what may be happening? [18:01] all, I'm trying it now in Natty [18:02] all, Lucid ok but natty fails [18:03] * nigelb ^5 bcurtiswx. [18:04] bcurtiswx, Thursday's gonna rock :) === arand_ is now known as arand [19:40] ghc 7 transition [19:40] here goes [19:41] well, it'll need source newing ;-) [19:58] all, hello. In a preinst file, a call to source debconf lib (. /usr/share/debconf/confmodule) leads to a failure whe pre installing the package (return error status 30) on Natty. But this exactly same package still works fine in Lucid. [20:04] ziviani: you could set -x to see where it fails [20:36] cjwatson: ping [20:36] c2tarun: I recommend not giving contextless pings; it both saves the time of the person you are after and potentially allows someone else to answer [20:38] Laney: actually he did last merge of package elilo, and now there are two conflicts in that package. Here are the conflicts, http://paste.kde.org/53563/ I was wondering if he could help me in fixing these conflicts. [20:38] can you help me with these conflicts? [20:40] I don't know what it's for. [20:41] did you ask him if you could take over the merge? [20:41] Laney: I was going to ask that first and then this problem [20:42] do we have to ask each and every time we want to merge or sync a package. Even if the conflict is obvious and easy to resolve? [20:43] it is assumed that the previous uploader will take care of it [20:44] but that way no work will be left for new guys :( [20:44] I don't subscribe to the belief that merges are a good thing to start with, actually [20:44] I would prefer to keep that merge, if you don't mind [20:45] cjwatson: sure, I was not getting any hint on how to resolve the conflict. [20:46] I think it should be clear to people who know make [20:46] can anyone please tell me from where to start? I mean except merges, what else packaging related work is there? [20:46] the reason merges are not a good place to start is that merges are not a mechanical task - they often jump out and surprise you with requiring really quite deep knowledge of the package [20:47] I generally recommend starting by finding bugs that are bothering you and figuring out how to fix them, and repeating [20:47] there are no doubt plenty of other ways to do it [20:48] cjwatson: sorry :( but I tried, fixing bugs is not as easy as it seems (at least for me) most of the time we have to understand the programming of whole application, which requires complete scanning of the package source code [20:49] I don't mean to be unwelcoming, just that merging something with the kinds of complex changes elilo has offers lots of ways to make mistakes in ways that are hard to review [20:49] yes, and you have to understand how the programming of the application works in order to do merges, in general [20:49] sure, there are merges that don't require that; it varies [20:49] but for the harder merges, you have to understand lots about the programming of the package, *and* you have to keep state about a three-way merge in your head [20:50] it can be quite cognitively challenging even when you're used to it, at times [20:50] cjwatson: so I should start with fixing bugs first? [20:51] I don't actually in general find that you have to understand the whole package in order to fix a bug in part of it, though [20:51] the skill you have to develop is narrowing down the part of the package you need to understand [20:51] c2tarun: it's just my opinion [20:52] cjwatson: I am trying to learn Qt, I'll start with some kde bugs. Thanks :) [20:52] but can we do simple merges or sync in which conflict is pretty obvious? [21:21] c2tarun: Ones that seem obvious aren't always so. [21:25] ScottK: conflicts in debian/control file in which maintainer-name is changed, or Standards-version is bumped are bit easy. [21:26] c2tarun: That's true, but there are cases where even if the previous Ubuntu changes are fixed, new ones are needed. You've had advice from one of the most experienced people in the project on this. My advice is listen to it. [21:27] c2tarun: If you want a generic place to start, look for installation failure bugs in LP and see if you can fix them. [21:27] Those are often quite tractable with just a bit of shell and will help you learn how the packaging system works. [21:27] You can ask in #ubuntu-bugs for help finding candidates. [21:27] ScottK: offcourse I'll listen the advices. :) that will help me a lot. [21:28] ScottK: sure :) I'll look for such bugs. [21:28] Then stop asking if it's a good idea if you do merges.