[00:04] <TheMuso> .c
[00:06] <directhex> .cs
[02:10] <xoox> Can anyone tell me why the ppa repo https://launchpad.net/~rvm4000/+archive/ppa is empty? All the links are broken.
[02:35] <Milyardo> xoox: https://launchpad.net/~rvm4000/+archive/ppa/+build/917148
[02:35] <Milyardo> There were build failures at launchpads last attempt to build packages
[03:03] <xoox> Milyardo: So *no* packages are available?
[03:03] <xoox> Milyardo: Seems only lpia failed.
[05:51] <LordKow> so whats going on with nautilus-actions?
[05:51] <LordKow> bug 341035
[05:52] <LordKow> upstream cvs has had little activity over the last couple of years, mostly translation updates. all of the bug reports on gnome's bugtracker are being left alone. i don't think ubuntu should try and maintain an otherwise unmaintained package... if that is the case.
[05:52] <LordKow> it appears that nautilus scripts can pretty much do the same. and as it stands right now nautilus-actions is pretty much useless if %params are broken.
[05:55] <LordKow> i guess not all the %params are broken, but still my other points stick... i guess if there is a motu person who wants to continue to maintain it then sure.
[06:26] <dholbach> good morning
[06:28] <stefanlsd> morning
[06:28] <dholbach> hiya stefanlsd
[06:34] <fabrice_sp> 'morning stefanlsd
[06:37] <pwnguin> ScottK-desktop: out of curiousity, how'd you notice #312957
[07:07] <dholbach> can I persuade somebody to do a demo of some packaging topic on 23rd April, 0:00 UTC?
[07:07] <dholbach> I know I might be up at the wrong time to persuade people who are awake around that time ;-)
[07:13] <dtchen> i could. any suggested topics/boundaries?
[07:14] <dholbach> hey dtchen
[07:14]  * dholbach hugs dtchen
[07:14] <dholbach> anything you like - https://wiki.ubuntu.com/Packaging/Training is what we're going to try out
[07:14] <dholbach> a 15 minute demo + some time for Q&A is compeltely fine
[07:15] <dholbach> I hope that people will step up and give short demos like "dh_install --list-missing" or "quilt" or "pbuilder hooks" or whatever
[07:15] <maco> yes plz!
[07:17] <maco> doh...i'll have to miss that one. there'll be logs, right?
[07:17] <dtchen> maybe piuparts, though i certainly don't mind covering dh 7/quilt/git
[07:17] <dholbach> sure
[07:17] <dtchen> let me get back to you via e-mail
[07:18] <dholbach> dtchen: thanks a lot - I'll be announcing the sessions in a bit anyway, we'll just keep the slot open until then
[07:18] <dholbach> dtchen: as I said, whatever you like - I'm sure there's going to be a lot of people who appreciate it
[08:21] <geser> good morning
[08:22] <dholbach> hi geser
[08:22] <geser> Hi dholbach
[08:25] <stefanlsd> Anyone willing to take a look at https://bugs.edge.launchpad.net/ubuntu/+source/tripod/+bug/337862 - its NBS and there is a FTBFS for lastfm. Its qt4.5 related and gentoo has a patch, i just cant work the qmake stuff out
[08:30] <Toadstool> good morning
[11:53] <abli> Hi! if I want to publish a package in my ppa for hardy, intrepid and jaunty, does that mean that I have to uploaded it three times with only the distrib being different in the changelog?
[11:55] <geser> abli: yes, changing the distro and the version (e.g. adding ~intrepid1 to the end)
[11:56] <abli> Even if nothing else is different? Shouldn't I be able to upload a single source package and say "compile this for each distrib"?
[11:56] <pmjdebruijn> not yet
[11:57] <abli> ok. thanks.
[11:58] <geser> abli: as the build debs are strored in one directory you can't have three different debs (each one for a different release) in that one dir (as the filename will be the same)
[11:59] <abli> ok. Uploading the source three times is no problem. I was just trying to avoid generating extra work for the ppa system, but I guess its not much of an issue.
[12:00] <pmjdebruijn> just always suffix ~intrepid or ~jaunty
[12:01] <gordonsyme> Hello
[12:01] <gordonsyme> Any python packagers about?
[13:27] <ScottK> pwnguin: One of the Python teams (pythonistas) is subscribed to cwiid bugs.
[13:29] <directhex> wii!
[13:29] <directhex> i still wish someone more competent than me had done something with the ps3 bluetooth remote
[14:11] <goshawk> hi
[14:17] <gordonsyme> Hi, any python packagers around?
[14:17] <hyperair> gordonsyme: as in python apps or python itself
[14:18] <gordonsyme> hyperair: python apps
[14:18] <cody-somerville> !ask
[14:18] <hyperair> well i've been messing around with a python app but nobody's reviewed it/sponsored it in debian
[14:18] <gordonsyme> hyperair: I've been trying to work out how to package something for a few days and I've just hit a wall. I don't know enough about the packaging process to continue
[14:18] <hyperair> yea just ask
[14:19] <POX> hyperair: not possible, did you ask on #debian-python or debian-python@l.d.o ?
[14:19] <hyperair> POX: what?
[14:20] <POX> "but nobody's reviewed it/sponsored it in debian"
[14:20] <hyperair> POX: i'm not satisfied yet
[14:20] <hyperair> POX: when i'm satisfied with my own packaging i'll ask for sponsoring
[14:20] <hyperair> POX: there's a java part which may or may not need building
[14:20] <gordonsyme> I have a bunch of modules and three scripts. I have distutils building a tarball for me. Previously I was using CDBS to package the distutils tarball into a single deb. Now I would like to package the modules in one 'common' deb and put each script into its own deb. Is this even possible without writing a massive rules file?
[14:21] <POX> oh ok, I thought nodoby in Debian replied to your RFS
[14:21] <hyperair> POX: hahah
[14:21] <hyperair> POX: actually i think i posted an RFS on debian-mentors
[14:22] <hyperair> POX: then i retracted it because upstream changed something
[14:22] <POX> Cc debian-python@ next time
[14:22] <hyperair> gordonsyme: look into dh_install
[14:22] <hyperair> POX: does debian-python have some sort of Vcs?
[14:23] <gordonsyme> hyperair: thanks
[14:23] <POX> debian-python@l.d.o is a mailing list, but we have 2 teams as well
[14:23] <hyperair> gordonsyme: you might be interested in looking at remuco-server which is sitting in mentors.debian.net
[14:23] <POX> one for modules/extensions and one for applications
[14:23] <gordonsyme> hyperair: cool, will have a look
[14:23] <POX> can someone teach the ubottu about DPMT and PAPT?
[14:23] <hyperair> POX: i see. what are their names?
[14:24] <hyperair> POX: what's DPMT and PAPT?
[14:24] <POX> there's a wiki page on ubuntu.com, IIRC
[14:24] <POX> let me search
[14:26] <POX> https://wiki.ubuntu.com/Debian/PythonModulesTeam
[14:28] <hyperair> POX: i see. cool
[14:29] <hyperair> POX: only svn? =(
[14:29] <POX> but your package will have to be perfect to be sponsored, ask savvas ;)
[14:29] <hyperair> ?
[14:30] <POX> https://bugs.launchpad.net/ubuntu/+source/imgseek/+bug/342450
[14:30] <POX> "It was a long journey" ;)
[14:30] <hyperair> ._.?
[14:32]  * hyperair doesn't like svn =\
[14:32] <POX> it's just a tool that keeps the debian dir
[14:33] <hyperair> yes iknow
[14:33] <hyperair> i prefer git
[14:33] <POX> tell that to >100 other maintainers
[14:33] <hyperair> =(
[14:34] <POX> I like git too, but I doubt we'll use it
[14:34] <hyperair> we could use both =D
[14:34] <POX> even if I would be the only one to decide
[14:34] <hyperair> oh =(
[14:34] <hyperair> well pkg-cli-* has both git and svn
[14:34] <POX> no we cannot use both
[14:34] <hyperair> why not
[14:35] <POX> one of the requirement is to have a command that will update all packages (including the new ones)
[14:35] <hyperair> oh
[14:36] <POX> try to check/sponsor few packages a day when you cannnot automate as much a possible
[14:36] <hyperair> since when is sponsoring an automated task
[14:37] <POX> updating all packages in one comman and grepping for common mistake is
[14:37] <POX> or updating it while starting to read RFS mails
[14:37] <POX> command*
[14:38] <hyperair> i see
[14:38] <POX> actually right now I'm without computer at home (it died few days ago), but usually I do it this way
[14:40] <ahasenack> hey guys, got this error when trying to build a package for smart-1.2 (based on the previous jaunty one):
[14:40] <ahasenack> pycentral: pycentral debhelper: both directories site-packages and dist-packages exist.
[14:40] <ahasenack> pycentral debhelper: both directories site-packages and dist-packages exist.
[14:40] <ahasenack> it's the same rules file (1.1.1 vs 1.2), and same environment (jaunty), but for some reason it fails when using 1.2
[14:40] <ahasenack> what's this about?
[14:42]  * hyperair has only used python-support
[14:42] <hyperair> but if rules fails with 1.2, then obviously upstream has changed something
[14:42] <hyperair> and rules needs to be updated
[14:42] <hyperair> or something else
[14:43] <POX> hyperair: it will be hard to be sponsored with python-central in our teams
[14:43] <POX> ahasenack: check if you have new pytohn-central
[14:43] <hyperair> POX: ?
[14:43] <POX> python2.6 installs to dist-utils by default (or at least if the layout=deb is used)
[14:43] <ahasenack> POX: 0.6.11ubuntu5
[14:43] <hyperair> POX: you mean python-support or python-central is preferred?
[14:43] <POX> so it's ok
[14:44] <POX> not prefered, pysupport is the only one accepted since few week
[14:44] <POX> s
[14:44] <ahasenack> hmm, found a difference in setup.py
[14:44] <hyperair> POX: then you shouldn't be telling me, i've only ever used python-support ;)
[14:44] <hyperair> POX: but you should get the debian python policy page updated
[14:44] <POX> I only wanted to let you know that you're using the right one ;)
[14:44] <hyperair> POX: ah okay =p
[14:45] <POX> hyperair: the policy for 95% of packages is 1) install to standard location 2) call dh_pysupport
[14:46] <hyperair> POX: install to standard location meaning?
[14:46] <POX> we'll deal with policy once all packages will not use pycentral or "currect"
[14:46] <hyperair> my package uses python setup.py install --install-lib=/usr/share/python-support/modulename --root=debian/tmp
[14:46] <POX> hyperair: python ./setup.py --root=debian/package/
[14:46] <hyperair> POX: is that all that's needed?
[14:46] <POX> hyperair: that's wrong
[14:47] <POX> you should not use pysupport internal paths
[14:47] <hyperair> hm
[14:47] <POX> remove --install-lib and it will be ok
[14:48] <hyperair> POX: the policy said to use --isntall-lib. don't you think this is even more reason to correct it?
[14:48] <hyperair> and perhaps state that "pysupport is preferred"
[14:48] <POX> hyperair: there are lots of special cases, but again for ~90%  of packages that's all what you need to know about python policy
[14:49] <POX> at least for python modules
[14:49] <hyperair> POX: http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html#s-pysupport
[14:49] <POX> (not applications or extensions)
[14:49] <hyperair> POX: i'm talking about this. it says use --install-lib
[14:49] <POX> check README file from python-support package
[14:50] <POX> (the one from experimental has a mini howto)
[14:50] <hyperair> hmm
[14:50] <POX> /usr/share/doc/python-support/README.gz
[14:50] <POX> (experimental's one is updated)
[14:51] <hyperair> i see
[14:51] <POX> (will be uploaded to unstable soon)
[14:51] <hyperair> but seriously, what's wrong with updating the policy?
[14:52] <POX> you have to convince doko to update it
[14:52] <POX> and since he's python-central author, it will be hard
[14:52] <hyperair> ugh
[14:54] <goshawk> i'm packaging a compiler which needs a library which is not packaged in ubuntu yet (both library and compiler). The compiler needs the library (which is a .a) to link binaries cuz it's a standard library. Should i package the library into the compiler package or should i create 2 packages, oner for library-dev and one for compiler?
[14:54] <hyperair> POX: without --install-lib, it installs into /usr/share/python2.6
[14:54] <hyperair> sorry
[14:54] <hyperair> debian/tmp/usr/lib/python2.5/site-packages
[14:54] <POX> that's ok, dh_pysupport will move the files to the right location
[14:55] <sistpoty|work> goshawk: I'd just put it the static lib into the compiler package
[14:55] <hyperair> POX: but it didn't
[14:55] <POX> change "tmp" to package name and it will
[14:55] <hyperair> meh.
[14:55] <hyperair> i see
[14:55] <goshawk> sistpoty|work: uhm... well.
[14:55] <hyperair> so pysupport is after dh_install eh
[14:56] <POX> yes
[14:56] <goshawk> sistpoty|work: do you know if there is a paragraph in the debian policy about it?
[14:56] <hyperair> i see
[14:57] <sistpoty|work> goshawk: to my knowledge there isn't
[14:57] <sistpoty|work> goshawk: does upstream release the library as separate tarball?
[14:57] <goshawk> sistpoty|work: yes
[14:57] <goshawk> compiler is a project
[14:57] <sistpoty|work> goshawk: then I guess the -dev is better... just thought this was in the same tarball
[14:58] <goshawk> and library another one
[14:58] <gordonsyme> hyperair: many thanks for your help, your remuco-server rules file showed me exactly what to do
[14:58] <hyperair> gordonsyme: np.
[14:58] <hyperair> gordonsyme: one thing. debian/rules should not have --install-lib in the setup.py call
[14:58] <goshawk> sistpoty|work: but the compiler should depend on the library then
[14:58] <goshawk> as Depends:
[14:58] <sistpoty|work> goshawk: if it otherwise can't build binaries then yes
[14:59] <goshawk> isn't it?
[14:59] <goshawk> ok
[14:59] <goshawk> thx
[14:59] <hyperair> gordonsyme: also, if you don't have a Makefile as well as a setup.py at the top-level, you shouldn't need to override dh_auto_install
[14:59] <goshawk> one more think
[14:59] <goshawk> thing
[14:59] <goshawk> the library name is tango
[14:59] <goshawk> should i package it as libtango?
[15:00] <gordonsyme> hyperair: ok, I'll give that a go. Thanks again
[15:00] <hyperair> goshawk: see the debian library packaging guide
[15:00] <hyperair> gordonsyme: if you're using git, you can use git clone git://git.debian.org/git/collab-maint/remuco-server.git
[15:01] <hyperair> gordonsyme: i've updated the stuff there
[15:01] <gordonsyme> hyperair: great, ta
[15:01] <hyperair> =)
[15:08] <vladimir_e> hi all, does anyone know why claws-mail-tools depends on claws-mail? it's a recommended package for Sylpheed and that forces Sylpheed users to install claws-mail
[15:12] <bddebian> Heya gang
[15:15] <sistpoty|work> hi bddebian
[15:15] <bddebian> Heya sistpoty|work
[15:16] <cody-somerville> vladimir_e, Probably a bug.
[15:16] <cody-somerville> vladimir_e, please file one :)
[15:16] <vladimir_e> cody-somerville, yes, wanted some insight before doing so
[15:29] <\sh> et voila...google-perftools fixed
[15:33] <ziroday> could anyone help me out with https://wiki.ubuntu.com/MOTU/GettingStarted?
[15:33] <ziroday> I'm getting a 500 error
[15:33] <vladimir_e> ziroday, working for me
[15:34] <ziroday> vladimir_e: heh, appending the ? made it work, https://wiki.ubuntu.com/MOTU/GettingStarted doesn't though
[15:45] <maxb> ziroday: It works for me, try refresh (or Shift+Refresh)
[15:45] <ziroday> maxb: must just be my day :)
[17:50] <LucidFox> If I see a bug with only a patch attached rather than a debdiff, should I ask the patch's author to post a debdiff, or make my own upload and include the patch there?
[17:50] <maco> make your own
[17:51] <maco> not everyone that knows how to code knows how to make a debdiff. ive started going through and converting patches i find
[17:52]  * LucidFox nods
[18:46] <YokoZar> Quick sponsorship question: if I'm sponsoring someone else's debdiff without further changes, I'm supposed to leave their name in the changelog and manually sign it before uploading yes?
[18:47] <directhex> afaik yes
[18:47] <YokoZar> (this isn't listed in the sponsorship workflow page): https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[18:47] <directhex> i.e. acknowledgement of who did the work
[18:48] <directhex> i've been in a few changelog.Debian.gz files anyway
[18:48] <YokoZar> How does launchpad know whose signature is on it?
[18:48] <YokoZar> (eg that I uploaded it)
[18:48] <YokoZar> because it tracks that too I think
[18:49] <YokoZar> Also I'm not entirely sure of the command to make this manual signature (I'll put it in the wiki on the sponsorship page)
[18:50] <fabrice_sp> Hi. A small question: can a package in universe depends on packages in multiverse?
[18:50] <directhex> debuild takes a -k flag
[18:50] <directhex> fabrice_sp, no, that package is a multiverse package by definition
[18:50] <YokoZar> fabrice_sp: no, that package should then be moved to multiverse
[18:50] <YokoZar> Although that has to be done manually I think
[18:51] <YokoZar> fabrice_sp: It can recommend them though
[18:52] <directhex> YokoZar, recommends is okay? i thought only suggests
[18:52] <fabrice_sp> directhex, so what kind of bug report should I open to demote it? (it's for mythtv-status, that depends on libmyth-perl)
[18:53] <fabrice_sp> or YokoZar
[18:53] <YokoZar> directhex: I thought recommends was okay...that way when someone has multiverse unchecked in sources it won't freak out like it will with depends
[18:54] <YokoZar> Only difference between recommends and suggests is install by default -- otherwise we'd need a third category (install by default unless repo is disabled) or something, which is what recommends does currently
[18:54] <Turl> hi
[18:55] <Turl> how can I call dh_desktop on cdbs?
[18:55] <YokoZar> fabrice_sp: file a bug against the package on launchpad and just put that in the description "should be in multiverse" or "depends on a multiverse package but is in universe"
[18:55] <fabrice_sp> YokoZar, ok. Thanks!
[19:04] <fabrice_sp> For that request (move from universe to multiverse), should I subscribe u-u-s or archive admin directly?
[19:23] <AnAnt> Hello, I am trying to create a pbuilder environment from the Jaunty beta ISO image as follows:
[19:23] <AnAnt> sudo pbuilder --create  --distribution jaunty --mirror  "deb cdrom:[Ubuntu 9.04 _Jaunty Jackalope_ - Beta i386 (20090324)]/"
[19:23] <AnAnt> and I've mounted the ISO on /cdrom/
[19:24] <AnAnt> yet pbuilder gives this error:
[19:24] <AnAnt> E: unknown location deb/dists/jaunty/Release
[19:24] <lfaraone> AnAnt: run the command without "deb" and see what happens.
[19:25] <AnAnt> E: unknown location cdrom:[Ubuntu/dists/jaunty/Release
[19:25] <AnAnt> so ?
[19:27] <lfaraone> AnAnt: did you use apt-cdrom to add the CD?
[19:27] <AnAnt> lfaraone: apt-cdrom in what ?
[19:27] <lfaraone> AnAnt: apt-cdrom is a utility.
[19:28] <lfaraone> AnAnt: you use it to add CDs to your apt sources.
[19:28] <AnAnt> lfaraone: I'm talking about pbuilder, apt-cdrom adds CD in /etc/apt/sources.list
[19:28] <lfaraone> AnAnt: once you do that, apt should know to use it automagically.
[19:28] <AnAnt> lfaraone: what has apt to do with pbuilder ?
[19:28] <lfaraone> AnAnt: (pbuilder uses apt)
[19:28] <lfaraone> AnAnt: *everything*
[19:29] <AnAnt> lfaraone: anyways, the CD got added when I ran /cdrom/cdromupgrade
[19:29] <AnAnt> lfaraone: pbuilder uses apt, but it doesn't get the mirrors from /etc/apt/sources.list
[19:29] <AnAnt> lfaraone: it gets them either from command line or /etc/pbuilderrc
[19:31] <maco> lfaraone: pbuilders have their own /etc/apt/sources.list though
[19:31] <maco> you can login to pbuilders
[19:32] <AnAnt> ah, done it
[19:32] <AnAnt> --mirror file:/cdrom
[19:33] <AnAnt> got it from debian  bug 1666651
[19:33] <AnAnt> got it from debian  bug 166651
[19:35] <superm1> AnAnt, add that to the wiki page if you can
[19:36] <AnAnt> well, this seems to have a problem on subsequent pbuilder update though
[19:36] <AnAnt> oh, I got other errors
[19:38] <AnAnt> W: Failed to fetch file:/cdrom/dists/jaunty/main/binary-i386/Packages  File not found
[19:39] <AnAnt> that causes pbuilder to abort with error
[19:39] <AnAnt> I see that there is /cdrom/dists/jaunty/main/binary-i386/Packages.gz
[19:39] <AnAnt> ie. gzip'ed
[19:41] <ahasenack> are there people from Ubuntu QA here in this channel? I was wondering if we could get https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/309042 fixed for jaunty at least
[19:48] <nxvl> nixternal: ping
[19:50] <AnAnt> why is it trying to fetch cdrom/dists/jaunty/main/binary-i386/Packages instead of cdrom/dists/jaunty/main/binary-i386/Packages.gz ?!
[19:50] <nixternal> nxvl: pongalong
[19:51] <nxvl> nixternal: whouldn't you want to run the session of 23rd April, 00:00 UTC??
[19:51] <nixternal> what session?
[19:51] <nxvl> nixternal: http://ubuntupackaging.wordpress.com/2009/03/31/packaging-training-kicking-off-this-week/
[19:54] <nixternal> nxvl: unsure if I can commit to that just yet, but I would be interested in some Kubuntu packaging stuff on that list
[19:55] <nxvl> nixternal: that's fine, we are going to do it every thursday
[19:55] <nxvl> nixternal: rotatin hours like it said there
[19:55] <nxvl> nixternal: i'm just trying to file the white space of the 23th
[19:56] <nixternal> let me find someone for you
[19:56] <nxvl> nixternal: \o/
[19:56] <nxvl> nixternal: even a 15 minutes session + Q&A is welcomed
[20:28] <AnAnt> heimdal-dev is a virtual package ?!
[20:30] <AnAnt> what's wrong with pbuilder ?!
[20:30] <cody-somerville> nothing
[20:30] <cody-somerville> pbuilder uses apt
[20:30] <DktrKranz> AnAnt, it's not
[20:31] <AnAnt> pbuilder is failing to build a package because it thinks that heimdal-dev, libfsplib-dev, libmozjs-dev and libtre-dev are virtual packages !
[20:33] <jpds> AnAnt: Do you ave universe enabled in your pbuilder setup?
[20:33] <AnAnt> yup
[20:34] <AnAnt> and done pbuilder update
[20:35] <fabrice_sp> Hi DktrKranz. It seems Bug #345263 is stuck. What should be the next step?
[20:35] <AnAnt> how does it get the notion that those packages are virtual ?
[20:37] <fabrice_sp> AnAnt, try to login to pbuilder, and check what is the content of source.list
[20:39] <AnAnt> fabrice_sp: I just done that, found that universe & multiverse are enabled there, so I logged using --save-after-login, and enabled them, and now running apt-get update
[20:39] <fabrice_sp> ok
[20:39] <AnAnt> thanks
[20:39] <fabrice_sp> good luck with pbuilder :-)
[20:40] <AnAnt> thanks
[21:11] <cjwatson> ahasenack: 309042> surely getting bugs fixed is a function of development, not QA
[21:12] <ahasenack> cjwatson: I was under the impression QA was the first step: they would triage it and assign it the right milestone
[21:12] <cjwatson> ahasenack: yay paperwork
[21:12] <ahasenack> cjwatson: :)
[21:12] <cjwatson> I'll deal with it, I might actually get it right
[21:13] <cjwatson> the keyboard subsystem is difficult and I'm not aware that QA is deeply familiar with the ins and outs of it (I wouldn't blame them)
[21:13] <ahasenack> cjwatson: \o/ thanks!
[21:14] <cjwatson> ahasenack: but just as a basic comment, the set of layouts and variants that exists is actually under the control of xkeyboard-config, not console-setup
[21:15] <cjwatson> ahasenack: the reason it wasn't changelogged in console-setup is that console-setup just gets updated from xkeyboard-config on each rebuild
[21:15] <ahasenack> aha
[21:15] <cjwatson> I'll make sure that it isn't getting left out for some other reason before reassigning the bug
[22:10] <maco> is there a way to specify to dh_make whether its gplv2 or v3?
[22:11] <maco> or does it not have to be that specific?
[22:12] <marnold> maco, iirc no
[22:12] <maco> is that to both?
[22:19] <cjwatson> maco: why not just edit it after dh_make has finished? it's only meant to be a first pass
[22:21] <maco> cjwatson: well the second question was to ask if the control file has to say which gpl version or just "gpl"
[22:22] <cjwatson> maco: licensing goes in debian/copyright rather than debian/control; but yes, it should say which GPL version is involved, although that might be "v2 or later" or similar
[22:24] <maco> oops. ok thank you