[01:02] hi i need help. :) [01:03] hi. we need descriptions. [01:03] https://bugs.launchpad.net/bugs/515153 [01:03] Ubuntu bug 515153 in ubuntuone-client "Ubuntu One gave error attempting startup (dup-of: 455544)" [Undecided,Confirmed] [01:03] Ubuntu bug 455544 in ubuntuone-client ""Protocol version error" - when bandwidth throttling is enabled with the default values" [High,In progress] [01:05] and here https://bugs.launchpad.net/bugs/516596 [01:05] Ubuntu bug 516596 in ubuntuone-client "can't connect this morning" [Undecided,Fix released] [01:05] i just wanna make sure that im doing the right thing here [01:08] i don't know enough about which bug it is, but i don't think fix released is right (proposed is not released), and it's probably a dup [01:09] dobey: yes i think so too [01:11] i checked the changelog of proposed packages and it seems nothing fits the description [01:13] user descriptions usually are either not descriptive enough, or way too chatty :) [01:13] lol [01:14] okay new update emmet hickory just marked it as New => Triaged [01:14] oh it's probably a dup of the NoAccessToken bug [01:14] based on syncdaemon-exceptions.log anyway [01:14] for karmic, yes [01:16] normally uisync --authorize fixes client to server sync issues [01:17] *u1 [02:09] can anyone tell me how to synconise a complete folder? [03:05] hey jamesh, how is it going? [03:06] i was wondering whether it's ok to do a 0.2 release of django-openid-auth now, and whether you want to do it or if I should [03:12] statik: bugger. I got tied up with other stuff earlier. I'll do the release now: the trunk seems to be fairly stable given the testing on edge [03:13] jamesh: ah cool, thanks [03:14] that will give a good week or two for me to get it into lucid before feature freeze [03:14] i want to try and convert to the new 3.0 sourcepackage [03:14] the new format, that is [03:15] as opposed to the Python version :) [03:22] :) indeed [03:24] statik: here it is: https://launchpad.net/django-openid-auth/trunk/0.2 [03:26] jamesh: awesome, thanks! [03:51] +555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555 [03:52] uh, oh [03:53] looks like my cats got on my keyboard while i was away. Sorry for any channel flood. [07:40] ping duanedesign [11:50] [12:45:12] Hello, have a question [11:50] [12:45:39] If I have a couchdb database installed [11:50] [12:45:52] and I put data into that couchdb [11:50] [12:46:15] will it be replicated via ubuntuone service ? [11:50] [12:47:36] I know that there is sth like desktopcouch to synchronize application data [11:50] [12:48:15] but If I put data into couchdb on standard couchdb port [11:50] [12:48:50] will it be somehow collected by desktopcouch client, and then synchronized by ubuntuone [11:51] Chipaca, would you know? ^ [11:51] vtech: no, it wouldn't [11:51] hmm [11:52] chipaca,Ihave to use desktopcouch [11:52] right [11:52] chipaca, Is there c++ client for desktopcouch? [11:55] chipaca, I know that it was developed in python, but I do not know if there is a c++ port for that client ? [11:55] vtech: desktopcouch? [11:56] chipaca, yhy [11:56] Chipaca, yhy -means yes :P [11:56] nope, no python [11:58] Chipaca, desktopcouch is not written in Python ? [11:59] Chipaca, but I saw sourcecodes of desktopcouch in Python [11:59] vtech: sorry, I meant, just python [12:00] Chipaca, So I have to make my own wrapper :( === jamalta-afk is now known as jamalta [14:04] hello hello [14:04] <__lucio__> hello [14:04] hi statik [14:04] hi statik [14:06] yo [14:06] so i'm supposed to talk about packaging [14:06] i'm sorry i didn't get lernid working [14:06] i had trouble with the iCal part [14:06] Hola statik [14:06] so we have 5 people! thats great [14:07] did anyone make it through that incredibly agressive list I sent out? [14:07] * statik was being optimistic [14:07] i'm here! [14:07] ah great, 6 :) [14:07] well I did, apart frm putting deesktop couchdb on my PPA, but I've uploaded it several times already, so ;) [14:07] rmcbride, thats fine :) [14:08] statik: putting the finishing touches to pbuilder [14:08] facundobatista, you mentioned that my list of assumptions you were missing a couple things, maybe I can help explain those? how far did you get on the list? [14:08] thisfred: great [14:08] statik: I have a question! what's "run through setup-packaging-environtment"? [14:09] for me at least, putting stuff in ~/bin doesn't put it in my path? [14:09] thisfred: you have to export $HOME/bin in your path [14:09] nessita, there is a command named setup-packaging-environment, it will help with configuring some things [14:09] nessita: run that command, and it'll ask you a series of questions [14:09] thisfred: it doesn't happen automatically [14:09] <__lucio__> pbuilder is taking its time [14:09] thisfred, you can also use /usr/local/bin instead, i just like keeping stuff in my ~ [14:09] statik: I don't have that command, at leas not in my PATH [14:10] nessita: which is good (I think it used to, and I got bitten by that once) [14:10] * jblount just saw the list and is making his way through it [14:10] statik, I did a setup.py like 8 years ago, really don't have a clue what's needed nowadays [14:10] nessita: then you missed the previous step: install ubuntu-dev-tools [14:10] statik, and pbuilder is still doing its stuff (and messing with my home dir) [14:10] thats totally ok [14:10] that stuff can run in parallel while we talk [14:11] thisfred: I did [14:11] so, I thought it would be best to start with a practical example of a packaging task, one that I was working on last night [14:11] nessita, i wonder if the command is only added in the lucid version of ubuntu-dev-tools [14:11] nessita: weird, then I'm out of clues [14:12] nessita, apt-get install ubuntu-dev-tools [14:12] so, a very common task that you would do during the dev part of the ubuntu cycle (before feature freeze) is to update an existing package to a new upstream version [14:12] alecu: I did -.- [14:12] statik: I think that's the case. it's there on my laptop (lucid) but not on the new machine (still karmic) [14:12] last night jamesh cut the 0.2 release of python-django-openid-auth [14:12] nessita, oh, wrong scrollback :P [14:12] alecu: ubuntu-dev-tools is already the newest version. :) [14:12] so, we will go through updating that package, using the brand new ubuntu distributed development systems based on bzr [14:13] I don't remember if I asked everyone to install bzr-builddeb, but you will need that package also [14:13] I think everyone is familiar with how launchpad organizes branches by lp:~// [14:14] for using bzr with ubuntu packaging, a new parallel namespace has been set up [14:14] every single package in ubuntu and debian has been imported into bzr [14:14] and every time someone uploads a new version of a package, it's imported into bzr automatically, creating some nice history [14:14] this means that we can also work on new versions of packages directly in bzr, and post merge proposals rather than attaching a debdiff to a bug [14:15] I'll start with how a release is usually created for a python project. so, everyone go to a temp directory and do 'bzr get lp:django-openid-auth' [14:16] * nessita is bzr-getting [14:16] let me know once that has completed, and i'll explain how upstream would create a release tarball from this using setup.py [14:16] <__lucio__> done [14:16] done [14:16] done [14:16] done [14:17] done [14:17] done [14:17] <__lucio__> pbuild is still on "d", so it will take tome time :) [14:17] done [14:18] <__lucio__> hey, theres no "debian" directory here [14:18] __lucio__: "here"? [14:18] yeah, I've noticed the archives have been super slow lately [14:18] done [14:18] <__lucio__> nessita, inside django-openid-auth [14:18] __lucio__: oh, right [14:18] exactly! current standard practice is that in the upstream project, you don't include the debian directory, and that debian directory is not included in the tarball that the upstream project releases [14:19] btw: I'm having the same problem nessita does. I'm on karmic, and setup-packaging-environment does not show up. [14:19] the work of the packager is to take the original upstream tarball, and add the debian directory [14:19] * facundobatista doesn't have setup-packaging-environment either, but pbuilder didn't finish yet... is it supposed to bring it? [14:19] alecu, nessita: you can probably bzr get lp:ubuntu-dev-tools to get the upstream source and get setup-packaging-environment script right out of the bzr branch [14:20] statik, ok. [14:20] so, back to django-openid-auth - take a look at setup.py, line 50 [14:20] statik: ack [14:20] this is actually more complicated than most setup.py files are [14:20] but you can see some simple things like author, license info, and version number [14:21] a few lines down, packages= explains what python modules this will install [14:21] and package_data= explains that there are some extra data files that need to be included as well [14:21] if you were working on a brand new project, you might need to create a similar (or simpler) setup.py and propose it to upstream [14:22] now, close out that file and run 'python setup.py sdist' [14:22] <__lucio__> statik, is installing just "install dependencies, put files in correct places, run custon shell commands", or is there more magic to it? [14:22] and then look at the contents of the dist/ directory [14:22] __lucio__, thats it. the only magic is a set of rules or policy about how packages are supposed to work [14:23] setup.py is nothing to do with ubuntu/debian, thats all pure python, but the ubuntu packaging system knows how to get all the info out of setup.py so you don't have to repeat it [14:23] nice [14:23] you should be seeing a tarball in the dist/ directory [14:24] yes [14:24] django-openid-auth-0.2.tar.gz [14:24] congrats, this is a tarball release! now, if you were the upstream release manager, you would upload that tarball to pypi and launchpad [14:24] now, we switch hats and look from the perspective of an ubuntu developer rather than a django-openid-auth developer [14:25] statik, question [14:25] earlier, I talked about the namespace for bzr branches on launchpad [14:25] facundobatista, sure [14:25] statik, the upload to LP is to the project home page (or something about releases under it), or to the PPA? [14:25] facundobatista: for the tarball, that would be to the releases area of the project home page, and to the pypi package index on python.org [14:26] statik, ok [14:26] once we turn this into an ubuntu sourcepackage, then we will upload to the PPA [14:26] great! [14:26] <__lucio__> statik, where do i upload tarballs to lp? [14:26] <__lucio__> ah [14:27] __lucio__, check out the lp-project-upload command in ubuntu-dev-tools as well [14:27] ubuntu developers are lazy, so if you are doing manual work for this kind of stuff you are making a mistake :) [14:28] I am going to practice this all on my pet project :) [14:28] I also brought an apple for statik [14:28] the namespace for ubuntu distributed development bzr branches (UDD) is lp:~///// [14:29] thisfred, me too, I want to have a PPA for lalita [14:29] <__lucio__> ppa for cocos2d! [14:29] this is a crazy set of namespace things to remember, but it gets easier [14:29] there are some good shortcuts available though [14:29] statik, one example of that namespace? [14:29] one thing to remember is that the ubuntu package name may be different from the upstream package name [14:29] upstream project name I mean [14:30] right, the python- prefix for one [14:30] * rtgz just caught up :) [14:30] hi rtgz! [14:30] one example is lp:~ubuntu-branches/ubuntu/lucid/python-django-openid-auth/lucid [14:30] you can subst karmic for lucid [14:30] you can also swap ubuntu for debian, and lucid for sid [14:31] the shortcut is 'bzr get lp:ubuntu/python-django-openid-auth', but wait one moment before running that [14:31] when you use that bzr shortcut, the 'ubuntu' prefix says "this is package, ok? look it up in the current dev version of ubuntu" [14:32] I keep my branches organized a certain way so I don't get confused when comparing between ubuntu hardy, karmic, lucid, debian sid, etc. [14:32] so, i recommend this layout (you can change it of course): mkdir -p ~/udd/ubuntu/lucid [14:32] cd ~/udd/ubuntu/lucid [14:32] bzr get lp:ubuntu/python-django-openid-auth [14:32] this will give you the current version of python-django-openid-auth that is in lucid [14:33] you'll notice that branch is different, it has a debian/ directory in it :) this branch is the result of some special bzr import stuff that unpacks a sourcepackage and saves the whole thing in bzr [14:33] let me know when everyone has that branch, and is inside the python-django-openid-auth directory [14:33] done [14:33] done [14:33] <__lucio__> done [14:34] statik, why ~/udd/ubuntu/lucid, because you're in lucid, or the bzr get will bring lucid stuff [14:34] ? [14:34] once there, take a peek at debian/changelog, to confirm that the last changelog is what you expect [14:34] facundobatista, because bzr get will bring lucid stuff [14:34] Branched 2 revision(s). [14:34] you don't have to be on lucid to do this, you could be running sid [14:34] done [14:34] statik, ok [14:34] changelogs are kind of special and important in packages [14:35] facundobatista, I understand that because of the shortcut, that gets the most recent version. [14:35] alecu, and how did you know the most recent version was a lucid one? [14:35] the version number and series (lucid) that you see at the top of this changelog file controls the version number of the package that will be built [14:35] python-django-openid-auth (0.1-0ubuntu1) karmic; urgency=low ? [14:36] facundobatista, I mean, the most recent series of a distribution [14:36] rtgz, exactly. thanks for pasting! i want to explain the different parts of this version string [14:36] the first part is the sourcepackage name, that has to be perfect [14:36] then, inside the () [14:36] 0.1 is the upstream release number [14:36] this is from the tarball that we would have downloaded from pypi [14:36] <__lucio__> where did all of this come from? [14:36] <__lucio__> was it manually written? [14:37] <__lucio__> its just lp magic? [14:37] <__lucio__> what can i change? [14:37] __lucio__, most of this was manually written because i didn't know the lazy shortcuts yet [14:37] we will change it in just a moment [14:37] <__lucio__> but it is just a branch, right? [14:37] yes [14:38] after the 0.1, the -0 means that this package was never in debian [14:38] after that, the ubuntu1 means this is the first version of this package in ubuntu [14:38] if I patched something in this package, I would change the version number to 0.1-0ubuntu2 [14:39] if I was working in my PPA, preparing something that would eventually get uploaded to ubuntu, I would add a magic suffix [14:39] so, 0.1-0ubuntu2~karmic1 would be what i would use for making a version for karmic in my ppa [14:39] the next version I upload to my ppa would be 0.1-0ubuntu2-karmic2 [14:39] statik: check that string [14:39] statik: hi, question about versions [14:39] ~ rather than -, right? [14:39] if I wanted to backport that set of changes to hardy, I would change the version number to 0.1-0ubuntu2-hardy1 [14:40] oh right [14:40] if I wanted to backport that set of changes to hardy, I would change the version number to 0.1-0ubuntu2~hardy1 [14:40] and 0.1-0ubuntu2~karmic2 [14:40] the ~ is special [14:40] Dashes where tilde's should go cause heartache and woe [14:41] what it means is that if dpkg is going to compare packages to see which one is newer (and should be installed as an upgrade), the ~ allows you to say one package is older [14:41] so, 0.1-0ubuntu2 is ALWAYS newer than 0.1-0ubuntu2~anything [14:41] <__lucio__> what demons would i be invoking if i put a % in that string? [14:42] aren't &s demons? [14:42] there are a bunch of crazy complicated rules around version numbers [14:42] thisfred: good point [14:42] it's the easiest thing to screw up, and will make your life miserable [14:42] <__lucio__> statik, arent they just strings that get sorted to figure out whats the latests and the rest just conventions? or there non humans parsing them? [14:42] so i'll stop talking about version numbers now, you can read in the man page for dpkg to get lots more info [14:42] __lucio__, these get parsed by all kinds of tools [14:42] <__lucio__> yuck [14:43] they must be *perfect* [14:43] they are also critical for upgrades working correctly between versions of ubuntu [14:43] so now we have heard there is a new upstream release of django-openid-auth [14:43] so, lets get the new tarball! [14:43] there is a tool to help with this [14:43] look at debian/watch [14:44] yes [14:44] this is a simple pattern that the uscan tool will use to go look at a website and see if there is a new version [14:44] lets try it out. run 'uscan --verbose --rename' [14:45] uscan: you must have the libcrypt-ssleay-perl package installed [14:45] needs libcrypt-ssleay-perl [14:45] -- Scanning for watchfiles in . [14:45] uscan: No debian directories found [14:45] <__lucio__> nessita, go inside the branch [14:45] Successfully downloaded updated package django-openid-auth-0.2.tar.gz [14:45] and renamed it as python-django-openid-auth_0.2.orig.tar.gz [14:45] __lucio__: yes, I noticed :-) [14:46] statik: shouldn't the libcrypt-ssleay-perl be dependency on ubuntu-dev-tools? [14:46] done, got the same output as rmcbride [14:46] nessita, maybe it is an optional dependency for uscan [14:46] many places publish their tarballs on http or ftp [14:46] launchpad uses https, so thats why the ssl dependency [14:47] we can look at the uscan package later, maybe thats a great bug for you to fix :) [14:47] statik: yey! [14:47] you will notice that the tarball was renamed, this has to happen in exactly this pattern so that the packaging tools can find the tarball [14:47] <__lucio__> statik, so, libssleay should be shown in apt-cache show ubuntu-dev-tools somewhere? [14:48] perhaps [14:49] i'm not sure which package holds uscan [14:49] devscripts [14:49] statik, where the tarball is renamed? [14:49] facundobatista, it got renamed by uscan when it was downloaded [14:49] so you see it is now .orig.tar.gz [14:49] <__lucio__> facundobatista, ls .. [14:49] and the - was changed to a _ before the version number [14:49] __lucio__, oh [14:50] more tools parsing version strings :/ [14:50] but, the tools make it easy to get it right most of the time [14:50] <__lucio__> facundobatista, yes, having tools that touch ".." is like having frame hacks in python. ugly :) [14:50] now we use a brand new bzr command [14:50] __lucio__, indeed [14:51] this is going to import the upstream tarball into our packaging branch, including saving some pristine-tar info so that the exact tarball can be recreated from the branch later [14:51] it will also do some smart things with merging [14:51] * alecu feels hunting version-of-by-one-character must be a huge timesink [14:51] bzr merge-upstream --version=0.2 ../python-django-openid-auth_0.2.orig.tar.gz [14:52] bzr: ERROR: unknown command "merge-upstream" [14:52] facundobatista: I think you need bzr-builddeb installed [14:52] Committed revision 2.\nAll changes applied successfully. [14:52] facundobatista: you have bzr-builddeb? [14:52] facundobatista: it worked for me [14:52] facundobatista: so may be a missing package, nior karmic's fault :-) [14:52] worked here [14:52] now if you do bzr status, you will see a bunch of changes [14:53] don't commit yet [14:53] ok, done [14:53] lets go back and look at debian/changelog [14:53] wow [14:53] there should be a new entry, automatically set up [14:53] neat [14:53] <__lucio__> statik, all this magic parsing and i still have to tell him what version it is? [14:53] __lucio__, i know, it kills me :) [14:54] write a patch for bzr-builddeb :) [14:54] <__lucio__> ok, i see where this is going :) [14:54] now i like to write extra stuff in the changelog entry [14:54] usually if upstream is nice they have written a NEWS file [14:55] statik: NEWS where? [14:55] if upstream is lazy like me and jamesh, there is no NEWS file for django-openid-auth [14:55] so, I went and looked at the upstream changes [14:55] statik, shame of you [14:55] :D [14:56] the other thing that is very interesting about changelogs is you can put bug numbers in them [14:56] statik: where that file would be? next to changelog or next to debian? [14:56] and, bugs are used to track sponsoring uploads of packages [14:56] nessita, if upstream provided a NEWS file it would probably be in root [14:57] whats cool about putting a bug number (or several) in the changelog is that when the package is uploaded to ubuntu, the bug is automatically marked as fix released [14:57] so, I wrote a bug number about this upgrade [14:57] oh, more magic [14:57] and my changelog entry looks like this: * New upstream release. (LP: #517400) [14:57] <__lucio__> statik, why does it say karmic everywhere? [14:58] nessita, NEWS is a file required by autotools (as well as README, AUTHORS and Changelog) [14:58] __lucio__, if you are running on karmic the tool that helps write changelogs (dch) will default to that. you can change it to lucid [14:58] <__lucio__> statik, im not [14:58] __lucio__, i'm not sure then [14:58] statik, question [14:58] facundobatista, go ahead [14:59] statik, did you simly wrote the bug number to the file? [14:59] statik, I fix 20 bugs, then release, all those bug numbers are in the NEWS file [14:59] statik, should I put the 20 bug numbers in the changelog in one line? [14:59] facundobatista: no, write it to be as nice as you can [14:59] the changelog entry is shown by the package manager GUI tools on the desktop [15:00] facundobatista, I do sometimes that, listing the NEWS for the release in debian/changelog, with each entry with its bug # [15:00] statik, but I want to them being marked automatically by LP as released! [15:00] facundobatista, you can have many lines [15:00] facundobatista, of course, for too many bugs, it might be too much :-) [15:00] ok [15:00] facundobatista: mine is such a short line but it describes perfectly what the bug is about - new upstream release [15:00] if you were fixing a bug you would decide how much to write based on the bug [15:00] you do not have to list every bug [15:00] or every change [15:01] this is going to be very subjective, but it's a good spot to not be lazy and spend 10 minutes to try and come up with a good brief description of whats going on with the package [15:01] other questions so far? [15:02] statik: me! qustion, you mentioned a GUI [15:02] nessita: yes, like synaptic or software-center [15:02] statik: which one will be that GUI? [15:02] ah... I understand now [15:03] oh, maybe we need to take a quick break to let the desktop+ team do their standup meeting. coffee! I'll be back in 5 minutes [15:03] statik, the file needs to be edited manually right? I thought that it might be useful to fetch the description field of all the updates and have it updated automatically with the description line of bzr commit [15:03] not that it is actually being written by devs, but it is recommended :) [15:03] rtgz, yes you almost always need to write things manually in the changelog [15:03] statik, ok, thanks [15:04] rtgz: all the commits can be way too much information, or not very informative at all, depending on the quality/quantity of commit messages [15:04] statik, uploading a package for one ubuntu release that marks a bug as fixed, would mark it as fixed for all releases? [15:04] it is possible to retrieve that info from LP, put it in a file and paste from there (that's how I do the changelog notes for the test ubuntuone-client packages) [15:05] provided the upstream is in LP of course :) [15:05] statik, is there a way I can mark it on launchpad as not yet backported to an older release? [15:07] i'm back [15:07] i don't see a desktop+ meeting going, so i'll keep on hogging the channel :) [15:07] alecu, yes. the top line of the changelog says which ubuntu release the package is for [15:07] a bug in launchpad can have many also-affects lines [15:07] these are sometimes called 'bug tasks' [15:08] so you can have 1 bug, with a bugtask in python-configglue, a bugtask in ubuntuone-client, and a bugtask on the ubuntu karmic package of ubuntuone-client [15:08] and each of those may have a different status [15:08] oh, right! great! [15:09] so everyone should have a changelog entry that looks something like this: [15:09] python-django-openid-auth (0.2-0ubuntu1) lucid; urgency=low [15:09] * New upstream release. [15:09] -- Elliot Murphy Fri, 05 Feb 2010 09:51:41 -0500 [15:09] now we want to turn this into a sourcepackage that can be built by pbuilder or a PPA [15:10] so run 'bzr builddeb -S' [15:10] the s means build a sourcepackage [15:10] this is wrapping up a lot of smaller commands that have an infinity of options [15:10] so if you need to do something special, it's absolutely possible, this is just handling the common case [15:10] <__lucio__> statik, python-django-openid-auth (0.2-0ubuntu1) UNRELEASED; urgency=low ??? unreleased? [15:11] ah, the UNRELEASED series is a special token so that you can work on this in version control and do testing, and not get mixed up about whether it has been uploaded already [15:11] statik: hum, something is not right in my env. [15:11] statik, should we leave it in UNRELEASED? [15:11] when you are touching 25 different packages across debian and several versions of ubuntu and private PPAs, it is easy to get mixed up [15:11] facundobatista, you can run dch -r to flip it from UNRELEASED to lucid [15:11] statik: https://pastebin.canonical.com/27500/ [15:12] when I ran bzr bd -S, I was prompted to gpg sign two files [15:12] statik: it seems the options (name + email address) from the setup aren't respected [15:12] ok [15:12] nessita, same problem here. [15:12] this is a fragile part of the process it seems [15:12] you can specify the key ID to use for signing [15:12] nessita, I have always to add -k'rodrigo.moya@canonical.com' so that it gets the correct gpgp signature [15:12] so, gpg --list-secret-keys [15:13] or yes, what rodrigo said [15:13] bzr bd -S -k'rodrigo.moya@canonical.com' [15:13] statik, gpg tells me that there's no secret key and I have exactly one gpg key which was picked up at setup-dev-thing stage [15:13] statik, hold on, please [15:13] <__lucio__> bzr: ERROR: no such option: -k [15:13] bzr bd -S -- -k'blah' [15:13] yeah, -- -k... [15:14] statik, I did "dch -r", it opened a file that looked like the changelog, but modified, I closed it without saving [15:14] the changelog is untouched [15:14] <__lucio__> yay! now i have a really dirty parent directoty! [15:14] great [15:14] statik, now dch -r opens an empty file [15:14] facundobatista, dch -r will make changes then open debian/changelog in your $EDITOR to review and save I think [15:14] rodrigo__, it worked now, thanks. [15:14] oh, now dch -r opens a file with content again! [15:14] statik: isn't easier to export DEBFULLNAME and DEBMAIL? [15:15] * rtgz has signed the deb file for the first time... [15:15] verterok, yes I have those in my environment, I also have some custom settings in ~/.devscripts [15:15] statik, I saved the file, but the changelog is still untouched [15:15] huh [15:15] facundobatista, you can just edit debian/changelog manually and change from UNRELEASED to lucid [15:15] oh, I have a debian/changelog.dch now [15:16] so the files that were created in your parent dir [15:16] there is a .changes, a .dsc, and a .diff.gz [15:16] yes [15:16] there should also be the .orig.tar.gz [15:16] * rtgz notices that there is no deb file [15:16] the .changes and .dsc are used by the system somehow [15:17] the .diff.gz should contain a diff that is only the contents of the debian/ directory [15:17] and the orig.tar.gz, is, of course, the orig tarball from upstream [15:17] these are the components of a sourcepackage [15:17] it has to get built into a binary package before it can be installed [15:17]