[00:05] <JonyBlaze> anyone want to critique my first package ever (minus the walk-throughs)?
[00:05] <JonyBlaze> i would like to get it into ubuntu in the future
[00:06] <JonyBlaze> https://launchpad.net/~ezrareeves/+archive/pep8
[00:06] <tsimpson> how about uploading it to revu
[00:06] <JonyBlaze> i would have to build it for lucid for that wouldnt i?
[00:08] <tsimpson> JonyBlaze: well, if you want it in ubuntu
[00:09] <tsimpson> besides, it's just a source upload. so just update the changelog
[00:09] <JonyBlaze> right
[00:10] <tsimpson> revu lets motu post comments and you can re-upload without bumping the version
[00:13] <JonyBlaze> ok i will do that then
[00:15] <Laney> jdong: poor motu-sru!
[00:15] <jdong> Laney: it's mostly okay; I think karmic response time hasn't been too awful for SRUs
[00:15] <jdong> I'm making best effort at 24h turnaround
[00:15] <Laney> did you get put back into the process yet? ;)
[00:16] <jdong> Laney: nope!
[00:16] <jdong> and nobody said anything on the list either!
[00:16] <Laney> pitti made the change iirc - maybe you could ask him directly
[00:18] <Amaranth> MTecknology: gah, I changed the description for the flash bug too
[00:18] <MTecknology> Amaranth: same time?
[00:18] <Amaranth> Apparently
[00:18] <Amaranth> Or right before you
[00:18] <MTecknology> lol
[00:18] <Amaranth> Mine dropped workaround two and added a new workaround three from comment 163
[00:19] <Amaranth> Seemed like the easiest one of the nspluginwrapper hacks
[00:19] <Amaranth> and mentioned Chrome users were out of luck entirely
[00:19] <MTecknology> Amaranth: right after me; yours is the one that took
[00:19] <MTecknology> https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/410407/+activity
[00:19] <Amaranth> oh, goody
[00:27] <MTecknology> Amaranth: dangit... compiz is breaking my website -_-
[00:28]  * Amaranth uses the bat again
[00:29] <MTecknology> Amaranth: my site is kinda broken though..... I'm doing this thing where I try to knock out hundereds of lines of css to make things less bloated and easier to work with (and hopefully not fight nail and teeth to make show up decent in IE6)
[00:38] <fcuk112> in python there is a section that checks os.environ.has_key("XXX_PATH").  how does XXX_PATH get set here?
[00:38] <mzz> fcuk112: I don't understand the question
[00:39] <fcuk112> i mean, how do i find out where this environment variable got set?
[00:39] <mzz> fcuk112: os.environ is the environment, so on a unixy system you'd do something like "XXX_PATH=foo python ..."
[00:40] <mzz> fcuk112: or it may already be set in the environment you run python from (try running "echo $XXX_PATH"), or some other bit of python may be adding it to os.environ, or some extension module may be setting it from c
[00:40]  * dtchen prepares more pulseaudio crack for the lucid crackheads
[00:40] <mzz> there's not really a callback on setting an env var, you'd have to resort to basic grpping
[00:40] <mzz> oh wait, this isn't #python
[00:40] <fcuk112> yea i tried, couldn't see it.
[00:40] <fcuk112> hehe
[00:40] <mzz> sorry, bit of a mischan, but I guess what I said still applies
[00:41] <mzz> fcuk112: is this really literally "XXX_PATH", and what's the context to this?
[00:46] <jdong> dtchen: you can upload into main, right?
[01:03] <fcuk112> fixing a tomboy notes screenlets bug, it was pointing to the wrong path.  before that it was trying to source from the env.  but it's all good, i was testing the wrong version of the py script.
[01:15] <dtchen> jdong: no, I don't have upload privileges.
[01:16] <dtchen> I think there are a couple people who do lurking about
[01:19] <serialorder_> why would a debian directory have both a changelog and a changelog.in ?
[01:22] <serialorder_> if you have package_ver-0ubuntu2 and a recently updated package_ver-1 and no new changes need to be made because of debian's update what should be done?
[01:30] <dtchen> assuming the orig.tar.foo matches, request a sync from Debian $release
[01:30] <ajmitch> jdong: I have upload rights but no bandwidth here
[01:37] <jdong> dtchen: can I get your opinion/blessing on the debdiff proposed in https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/330766
[01:37] <serialorder_> dtchen, its not a sync because ubuntu makes some changes it just happens that ubuntu packaged the new version before debian so the ubuntu specific deltas need to be preserved its just that debian didnt introduce anything new
[01:37] <serialorder_> i dont know if that is clear enough
[01:39] <ajmitch> serialorder_: then make package_ver-1ubuntu with the debian revision as a base, with the ubuntu changes you need to keep
[01:40]  * ScottK hands ajmitch another '1'.
[01:40] <ajmitch> just say "Merge from Debian Squeeze, remaining changes:" or something similar
[01:40] <ajmitch> ScottK: yeah, typing via ssh from a conference :)
[01:41] <ScottK> I figured you knew, but just in case someone else thought that was correct.
[01:41] <ajmitch> yes sorry, i was typing too fast to check :)
[01:53] <serialorder_> ajmitch, when I list the remaining changes in the changelog should I retype them from before or just put a refernece  the original versions that introduced the changes?
[01:54] <ajmitch> list all changes that still affect the version you're working on
[01:54] <ajmitch> and list changes that you've dropped since the last version, too
[01:54] <ScottK> serialorder_: The next person that comes along to look at the package should be able to understand both the what and the why of the difference from Debian with just that changelog entry.
[01:55] <serialorder_> ok so then it is not sufficient to just list the entries lower in the changelog that specify why, that is good to know
[01:57] <ScottK> Since we do team maintenance here, it should be easy for anyone picking up the package to understand what's up with it.
[01:59] <serialorder_> should i list which versions the deltas are preserved from as well?
[02:02] <ScottK> No.
[02:02] <ScottK> Current state is what's important.
[02:03] <ScottK> When I do a merge, I have a habit of just dropping any undocumented changes I find unless it's obvious why they are needed (and then I document them).
[02:08] <ScottK> 3 out of 3 hunks FAILED -- saving rejects to file debian/rules.rej
[02:09] <ScottK> 5 out of 5 hunks FAILED -- saving rejects to file debian/control.rej
[02:09] <ScottK> \o/
[02:09] <ScottK> So much for the easy way.
[02:15] <JontheEchidna> Was there ever a source format 2.0?
[02:17] <ScottK> JontheEchidna: Google wig and pen.  Never deployed.  Heavily bike shedded over the years.
[02:21] <JontheEchidna> Interesting.
[02:31] <ScottK> So now which goes faster?  The laptop battery (11% and declining) or the tarball upload?
[02:32] <ajmitch> my laptop is working remarkably well in karmic now... except for important things like the cooling fans
[02:33] <ajmitch> even suspend/hibernate is working, so it's strange that the fan part of the ACPI info is just missing
[02:33] <ScottK> Easily worked around with a bag of ice.
[02:33] <ajmitch> except that I have it on my lap at pycon
[02:34] <ajmitch> I think I'll upgrade the BIOS before filing a bug about it
[02:56] <fcuk112> is launchpad.net running ok for you guys?  i am getting timeout errors.
[02:57] <ScottK> That's not rare.
[03:15] <p3rror> please can you explain the memory process when you do a SQL select on a table
[03:15] <lifeless> not really, thats more #mysql or #drizzle or #postgresql or ....
[04:06]  * ScottK gives up on trying to figure out if there is a way to get the laptop on the other side of the room to unsuspend so he can ssh into it and avoid getting up off the couch.
[04:56] <pmcenery> Does anybody have any recommendations on a pbuilder environment. What I mean by this is... for me, I dont really want my primary workstation to be bloated with packages. Instead, I'm thinking of either schroot for a couple of different pbuilder environments, or possibly lxc. Is there anyone who uses this sort of config for their build environment who has some valuable advice on the subject?
[05:13] <dtchen> pmcenery: well, I tend to have multiple pbuilders, sbuilds, schroots all hooked to an apt-cacher-ng instance on the host. That way it doesn't really matter about "bloating".
[05:16] <dtchen> jdong: looks sane, of course
[05:16] <dtchen> christoph's comment is nicely irrelevant, and the workaround is pretty kludgy
[05:17] <jdong> dtchen: *nods* thanks for the input
[05:17] <jdong> ScottK: ^^ based on that, and ebroder uploaded a new debdiff with correct versioning, could you do the honor of uploading to main?
[05:18] <ScottK> jdong: What bug again?  I'll probably put it off until tomorrow since I'm very tired and making silly mistakes at the moment.
[05:19] <jdong> ScottK: bug 330766
[05:19] <jdong> thanks, Scott :)
[05:21] <pmcenery> dtchen: thanks for the info.
[05:23] <dtchen> yw
[05:26] <ScottK> OK.  Got it.  Off to crash now.
[05:26] <jdong> good night!
[05:57] <astechgeek> Is the ubuntu-motu-mentors mailing list for Mentors or people looking for mentors?
[05:58] <jmarsden> astechgeek: The latter, I think, but some mentors are subscribed to it too.
[05:58] <astechgeek> okay just wanted to make sure I didn't want to subscribe being that Im looking to get involved and have no clue where to start
[05:58] <jmarsden> astechgeek: You can read the archives at https://lists.ubuntu.com/archives/ubuntu-motu-mentors/ before you subscribe...
[05:59] <astechgeek> I was reading through the articles on the ubuntu wiki about getting involved...
[05:59] <jmarsden> Good :)
[06:00] <astechgeek> as a noob where would be the best place to go to get started in contributing?
[06:01] <jmarsden> Well, it depends how fast you learn... if you want to contribute in MOTU-like work, you can use the six steps in https://wiki.ubuntu.com/MOTU/GettingStarted as a guide, and ask questions here in #ubuntu-motu
[06:01] <jmarsden> If after reading some of the material you decide packaging is too technical for you, consider joining the bugsquad and doing bug triage, etc to start with, maybe?
[06:01] <astechgeek> i have programming exp but don't feel confident enough to try the development side
[06:02] <jmarsden> MOTU stuff is more about basic scripting and use of tools than deep programming knowledge.
[06:02] <astechgeek> okay what about the bugsquad?
[06:03] <jmarsden> https://wiki.ubuntu.com/BugSquad
[06:03] <astechgeek> do they have a channel?
[06:03] <dtchen> #ubuntu-bugs
[06:04] <jmarsden> It's often more about asking bug reporters for more more info and duplicating bugs reports than deep debugging..., and yes, #ubuntu-bugs
[06:04] <astechgeek> simple enough :-D
[06:06] <astechgeek> thanks for the help, the descriptions will help ensure that I get involved with something that I'm comfortable with.
[06:11] <jmarsden> No problem, and welcome :)
[09:00] <MTecknology> Amaranth: compiz is breaking java too..... I don't use compiz but... ya know... it's not working :P
[09:00] <MTecknology> g'night all
[09:23] <ripps> I'm want to apply to become a MOTU, I want to know if anybody can look over my wiki and tell me what else I can do. https://wiki.ubuntu.com/ripps818
[09:25] <slytherin> ripps: have you done any contribution in terms of packaging in Ubuntu?
[09:27] <ripps> slytherin: I maintain 100+ packages in the gmpc-trunk team ppa's. I've also created several new packages that have gotten into Debian and then synced into Ubuntu
[09:28] <slytherin> ripps: PPAs are not official repository. And Debian is not Ubuntu. :-)
[09:28] <ripps> slytherin: well, I've tried time and time again to get packages through REVU, but it never pans out and I'm always ignored.
[09:28] <slytherin> ripps: thing is that if you want to apply for MOTU membership you need to demonstrate that you have helped packaging in Ubuntu directly and you blend in the community.
[09:29] <hyperair> slytherin: but packaging stuff for debian which get synced into ubuntu is recognized
[09:29] <slytherin> ripps: new packages is not the only way to help. You can fix existing packages.
[09:30] <ripps> I've made a few patched packages that I've offered up in my Testing PPA, like a focus glitch in compiz-plugins-main. It was fixed in Karmic, but I still have the Jaunty package in there.
[09:30] <slytherin> hyperair: not necessarily always. You can not get motu membership simply on the basis of youe debian work.
[09:32] <ripps> I'd gladly participate more with package fixing and new software in Ubuntu, but It always seems that nobody notices when I try to help. Maybe I'm just not vocal enough
[09:32] <slytherin> ripps: no. we are always short on manpower
[09:33] <hyperair> slytherin: true, but almost all my work in ubuntu is pushed in through debian. more people benefit that way.
[09:33] <slytherin> hyperair: I know.
[09:35] <ripps> Well, I have a few packages sitting in Debian Mentors, but I haven't been able to get anybody to sponsor it yet. If I upload it to REVU, can I get some help getting it accepted?
[09:35] <hyperair> ripps: you have to poke people here
[09:35] <ripps> I have, many times, but I'm usually ignored....
[09:35] <hyperair> ripps: try again >_>
[09:36] <hyperair> not everybody's free all the time
[09:36] <hyperair> if you just try a few times and give up, it's never going in
[09:36] <hyperair> i find it's easier to find a sponsor here than in debian mentors
[09:36] <hyperair> i've got a few packages sitting in mentors for months on end
[09:36] <fabrice_sp> in general, you will get more attention fixing existing packages than bringing new packages to Ubuntu
[09:37] <slytherin> ripps: That is the reason I said fixing up existing packages is better way to contribute. Once you are known in community it is easier to find sponsors for new packages.
[09:38] <ripps> Well, I have an updated liburiparser package, anybody interested in looking at it?
[09:38] <fabrice_sp> bug?
[09:38] <ripps> fabrice_sp: well, it's a requirement in order to get libxspf in, which is being called on increasingly in upstream for xspf playlist support
[09:39] <fabrice_sp> is there any bug number in launchpad?
[09:39] <fabrice_sp> for the new version upgrading
[09:40] <ripps> fabrice_sp: I don't see any launchpad bugs...
[09:41] <hyperair> ripps: imo the best way to handle getting packages into ubuntu is to get the update into debian, and then handle the sync/merge in ubuntu yourself instead of waiting for someone else to do it.
[09:41] <ripps> hyperair: I know, I did that with the libcue package I made
[09:44] <hyperair> well yeah, handle a few more and then apply for motuship or contributing-developer status
[09:45] <hyperair> contribution first, status/upload rights later
[09:50] <fabrice_sp> when beginning to contribute, I discover that you should be more proactive in opening bug reports to fix things, and open new ones to get your  stuff sponsored.
[09:52] <ari-tczew> hello
[09:52] <ari-tczew> devs, I have a question
[09:54] <fabrice_sp> !ask
[09:55] <fabrice_sp> :-D
[09:55] <ari-tczew> package in karmic have a patch, but unstable & testing have a new upstream version in repositories which these new versions have patch applied upstream. can is it a sync into lucid?
[09:55] <fabrice_sp> sounds like yes
[09:56] <fabrice_sp> if the patch has been integrated upstream, and the new package works (builds/installs/runs) fine, yes
[09:56] <ari-tczew> I guess that isn't can done by Ubuntu Archive Autosync, so do I need to open a sync request, right?
[09:57] <ari-tczew> of course including buildlog and information that patch has been applied upstream
[09:57] <fabrice_sp> yes
[09:57] <ari-tczew> ok, thanks ;-)
[09:57] <fabrice_sp> ;-)
[09:59] <ari-tczew> fabrice_sp: In this cycle's moment sync's requests needs MOTU ack?
[09:59] <ari-tczew> or only sponsor?
[10:00] <fabrice_sp> sponsors
[10:00] <ari-tczew> ok
[10:02] <fabrice_sp> motu-release subscription is when feature freeze is on
[10:03] <fabrice_sp> got to go. Bye
[10:05] <ari-tczew> ok bye
[10:12] <Nafallo> bdrung: no
[10:14] <bdrung> Nafallo: ?
[10:14] <Nafallo> 18:03:23 #ubuntu-motu: < bdrung> bigon: did you upload gajim to karmic-proposed?
[10:14] <Nafallo> doh
[10:14] <bdrung> k
[10:14]  * Nafallo should stop hilighting on gajim / wake up :-P
[11:15] <randomaction> Packages uploaded to REVU should target lucid, right? REVU complains: "Package is for "lucid" but only packages for "karmic" are currently accepted."
[11:19] <mok0> randomaction: that's abug
[11:20] <randomaction> I guess someone should update current development target
[11:20] <mok0> yeah
[11:20] <randomaction> is it worth filing a bug at LP?
[11:20] <mok0> You could
[11:21] <mok0> REVU has a project there
[11:21] <mok0> Then the devs wont forget :)
[11:22] <randomaction> ok, will do
[11:23] <mok0> Great, thx
[11:51] <geser> when merging an Ubuntu changelog into the Debian one, do we sort the Ubuntu changes by version or by date?
[11:53] <ari-tczew> I guess that by version
[11:57] <hyperair> by date would make things very confusing imo
[12:01] <ari-tczew> what is it a thing called an 'Ubuntu delta'?
[12:02] <geser> Ubuntu delta = differences between the Debian package and the Ubuntu one
[12:02] <ari-tczew> ok thnx
[12:44] <diwic> While trying to create a pbuilder environment for lucid, I ran into the following error: diff: PreDepends: diffutils but it is not installed
[12:44] <diwic> Any ideas?
[14:12] <ari-tczew> bugs looking for sponsors - merge to lucid:
[14:13] <ari-tczew> bug #477387
[14:13] <ari-tczew> bug #477389
[14:14] <c_korn> what is the correct why of a -dev package to depend on the library package ? I get lintian warnings with both binary:Version and source:Version
[14:38] <geser> what exactly did you put into debian/control?
[15:27] <ScottK> Possible new packaging opportunity coming our way; http://share.skype.com/sites/linux/2009/11/skype_open_source.html
[15:29] <hyperair> ScottK: i was thinking about that as well, but it seems that the protocol remains close sourced.
[15:31] <ScottK> hyperair: It will no doubt, have to go in Multiverse, but having it in the repos would be an improvement
[15:31] <hyperair> ScottK: do binary blobs go in multiverse?
[15:32] <ScottK> hyperair: If they are redistributable.
[15:32] <hyperair> chances are that the protocol library will remain a binary blob if it isn't opened as well
[15:32] <hyperair> ah
[15:32] <hyperair> so they can eh..
[15:32] <ScottK> Absolutely.
[15:33] <ScottK> Pretty much the only requirement for Multiverse is that it be legal for Canonical and it's mirrors to distribute.
[15:33] <hyperair> ah i see
[15:34] <ScottK> We have at least one package that even says something like "and if there's a conflict between what's in the license and what's needed for normal Ubuntu distribution, then the distribution's needs are OK".
[15:35] <Amaranth> Hey we can add skype support to telepathy
[15:38] <hyperair> that would be interesting
[15:38] <hyperair> but i'd really really prefer to see metacontact support on empathy first >_>
[15:39] <ripps> c_korn: foobar (= ${binary:Version})
[15:39] <hyperair> for some of my contacts, i've got 3-4 duplicates
[15:39] <geser> jdong: could you please ACK the SRU for bug #472824
[15:39] <hyperair> it's the main reason i'm sticking by pidgin for the time being
[15:40] <c_korn> ripps: this gives me an error that the dependency is too strict. (the -dev package is arch-indep)
[15:41] <geser> c_korn: no .a file in the -dev package?
[15:42] <c_korn> geser: no, no static libs. just headers and .so symlinks.
[15:45] <ripps> c_korn: pastebin the error that lintian is giving you
[15:45] <geser> c_korn: then try >= , like libpurple-dev does it too
[15:52] <c_korn> this is the error with = ${binary:Version}
[15:52] <ScottK> jdong: 330766 needs a TEST CASE:
[15:53] <c_korn> with >= ${source:Version} I get this error: http://pastebin.com/d5dd6ec96
[15:55] <c_korn> and a similar one with >=${binary:Version} http://pastebin.com/d52b323a1
[15:55] <c_korn> oh, I have forgotten the link in the = ${binary:Version} case. this is it: http://pastebin.com/d2a3e26aa
[15:57] <c_korn> and just for completeness the = ${source:Version} dependency: http://pastebin.com/d5a73530c
[16:05] <geser> c_korn: seems you get a warning either way, so pick one you "like" and overwrite it
[16:06] <geser> I guess lintian doesn't know yet about arch:all -dev packages
[16:07] <geser> if you want to get the package into Debian, I suggest using >= ${source:Version} as it's binNMU-safe
[16:07] <c_korn> geser: ok, thanks.
[16:22] <jdong> geser: acked
[16:43] <ScottK> chrisccoulson: runit needs to be fixed in Lucid before I accept the SRU (439049)
[16:51] <chrisccoulson> ScottK - no problem. I can do an upload to Lucid too
[17:01] <chrisccoulson> ScottK - it's fixed in Lucid now
[17:06] <ScottK> chrisccoulson: Accepted for karmic-proposed too.
[17:06] <chrisccoulson> ScottK - thank you
[17:06] <ScottK> No problem.  My part of the job is easy
[17:13] <ScottK> chrisccoulson: Would you please look at bug 400839.  I've been working with the uploader, but would like to see him get sponsored by more than just me.  I'd like to get it into Lucid quickly so we can do an SRU.
[17:13] <ScottK> jdong: It'd be nice to get a motu-sru ack for ^^^ too (patch will be the same modulo revision number).
[17:20] <JonyBlaze> anyone familiar with googlecodes URL syntax as far as making a watchfile
[17:55] <jdong> ScottK: ok, done :)
[18:02] <JonyBlaze> err nm
[18:02] <JonyBlaze> in uscan man page it says you can specify what the current version is on the 2nd line but doesnt show how, anyone know?
[18:03] <ScottK> JonyBlaze: I don't.  I'd suggest finding an existing package in the archive hosted there and copy.
[18:05] <Guest34157> I need som help
[18:05] <ScottK> jdong: Looking at it but getting distracted by filing bugs against our tools
[18:05] <JonyBlaze> ScottK: my issue is that upstream doesnt use very good versions in the filenames
[18:06] <JonyBlaze> ScottK: so I changed it for packaging, uscan would check theirs against mine and it wouldnt come up with the right answer
[18:06] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:07] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:09] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:09] <joaopinto> Guest34157, first you should get  a proper nick :)
[18:17] <Laney> and stop repeating
[18:18] <hyperair> Laney: too late
[18:19] <Laney> what is
[18:21] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:22] <hyperair> Laney: "and stop repeating"
[18:23] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:26] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:26] <Laney> hahaha
[18:26] <Laney> hyperair: If you mean that he parted, I have that ignored
[18:26] <Laney> christian_: stop repeating please
[18:27] <hyperair> Laney: ah.
[18:28] <ScottK> christian_: My advice is read http://www.catb.org/~esr/faqs/smart-questions.html and then ask again after considering it.
[18:30]  * mok0 doesn't understand why that setup.py vs bash thing should be a problem
[18:31] <Laney> "All access to Launchpad must be authenticated as an application acting on behalf of a user. It's possible for the user to grant the application only readonly access, but it's not possible to access the APIs anonymously"
[18:32] <ScottK> Sounds like more user friendly design.
[18:33] <Laney> I'll just turn that into a warning
[18:34] <christian_> I followed this guide, https://wiki.ubuntu.com/PackagingGuide/Python, and it doesn´t explain how to proceed if the package doesn´t have a setup.py file. Please help me.
[18:36] <mok0> christian_: are you packaging a python program or module?
[18:37] <christian_> a python program, djl http://en.djl-linux.org/
[18:38] <ScottK> jdong and dtchen: Uploaded.
[18:39] <mok0> christian_: you don't need setup.py. From within rules, do whatever you need to in order to do the build
[18:40] <christian_> could you explain some more? This is my first package.
[18:40] <jdong> ScottK: Thanks!
[18:41] <mok0> christian_: can you write your own setup.py file?
[18:41] <mok0> christian_: if so, it will make things much easier
[18:42] <christian_> ok, should I just put the setup.py in the directory then?
[18:43] <mok0> christian_: yes, that will be ok for starters
[18:43] <christian_> mok0: Thanks!
[18:43] <mok0> christian_: then you can use the CDBS system and the rules file will be just a few lines
[18:45] <sebner> mok0: arghrshsarhgsharhgahgahs.. DH7!!!
[18:45] <mok0> sebner: bah
[18:45] <mok0> :)
[18:45] <mok0> I much prefer makefile macros
[18:45] <sebner> we have dh7 and quilt now. NO need for something else!
[18:46] <mok0> sebner, we have GNU make. No need for anything else
[18:46] <mok0> :)
[18:47] <sebner> mok0: I forgot to add "which is the best in the world so why using something worse .." ;)
[18:47] <mok0> sebner: But if you like, you can take over mentoring christian_ in dh7 *shudder*
[18:47] <ScottK> sebner: quilt is good for complex packages, but has a bit of learning curve.  It's the git of patching systems.
[18:48] <sebner> ScottK: I've found it always easier than e.g dpatch
[18:48] <sebner> mok0: I'd recommend DktrKranz who is *the* python with dh7 expert ;)
[18:48] <mok0> I use quilt
[18:48] <sebner> \o/
[18:49] <mok0> I use cdbs
[18:49] <ScottK> sebner: It doesn't get much easier than dpatch-edit-patch.
[18:49] <ScottK> Or cdbs-edit-patch
[18:50] <sebner> ScottK: right but my experience is that it's the easiest and most powerful among all patch systems
[18:50] <mok0> ScottK: cdbs-edit-patch is quite useful as an introduction anyways, since it's harder to screw up than quilt
[18:50] <ScottK> Well any system that requires people to set environment variables as the first step fails the easy test.
[18:51] <ScottK> mok0: Agreed.
[18:51] <ScottK> I've used quilt enough now that I'm comfortable with it, but it took some time.
[18:52] <mok0> I've forgotten a few time to "add" a file to quilt, and then it's a real pain to get the patch created
[18:54] <JonyBlaze> why cant debian/watch just use normal wildcards /sigh
[18:54]  * DktrKranz is a n00b, sebner probably confused him with someone else
[18:56] <mok0> JonyBlaze: The perl weirdness is upon us
[19:01] <JonyBlaze> :(
[19:17] <goshawk> hi, is there a way to retrieve a package with dget from the debian ftpmaster new section? http://ftp-master.debian.org/new.html ?
[19:20] <ScottK> goshawk: No.  They are not publically available
[19:21] <goshawk> oh
[19:36] <christian_> I get this when I am trying to build: dpkg-gencontrol: warning: can't parse dependency python-qt4  python-central (>= 0.6.11) dpkg-gencontrol: error: error occurred while parsing Depends field: python-qt4  python-central (>= 0.6.11) dh_gencontrol: dpkg-gencontrol returned exit code 255
[19:37] <jmarsden> christian_: python-qt4  python-central (>= 0.6.11)   needs a comma in there to separate the two clauses: make it Depends: python-qt4, python-central (>= 0.6.11)
[19:38] <jmarsden> In general "can't parse" means you made a syntax mistake of some sort.
[19:39] <christian_> Thanks! Let´s see how things work this time.
[19:41] <jmarsden> No problem.
[19:41] <christian_> Worked :-) Should I write something in the changelog about the setup.py file I added?
[19:47] <mok0> christian_: absolutely
[20:02] <ScottK> jdong: Unless you tell me otherwise pretty quickly, I'm going to assume your ack on gurlchecker means i can accept it.
[20:04] <jdong> ScottK: yes sir
[20:04] <ScottK> Excellent.
[20:04] <ScottK> Battery is at 5%, so it may not be until after I find power.
[20:06] <ajmitch> morning
[20:08] <ScottK> Just made it.
[20:26] <christian_> Package is here: http://revu.ubuntuwire.com/p/djl Please comment.
[21:25] <rlameiro> Good evening/morning/afternoon everyone
[21:25] <rlameiro> Well I want to start to make packages, what do I need to know before starting?
[21:26] <rlameiro> Do i need to understand makefiles etc?
[22:14] <bmm> I want to create a package for a very simple tool which does not have any Makefile and is just a single Python script. ( http://git.logfish.net/?p=shareftp.git;a=commit;h=9bff07bf7b18d19d8d16db0d67d2b31b575c379b ). Should I path a Makefile for the package or is there a nicer way?
[22:25] <lifeless> bmm: you're going to need a copyright statement at minimum
[22:25] <lifeless> we don't care about a makefile or not
[22:26] <bmm> lifeless: I just found out I can remove the /usr/share/cdbs/1/class/makefile.mk include (I'm using CDBS) and then add the files I need into shareftp.install and shareftp.manpages
[22:26] <bmm> I'm currently going to look up where to install the binary (/bin or /usr/bin) because I'm not sure what the policy is on that yet.
[22:26] <bmm> :)
[22:27] <bmm> lifeless: Thank you for you response!
[22:28] <bmm> OK, that's /usr/bin. Should be ok from here. Thank you for your response.
[22:39] <rlameiro> https://wiki.ubuntu.com/PackagingGuide/HandsOn
[22:39] <rlameiro> i am following this tutorial
[22:39] <rlameiro> but i am stuck in the dh_make
[22:39] <rlameiro> it gives an error
[22:40] <rlameiro> lameiro@studio:~/hello/hello-2.4$ dh_make -e lameiro@macinhata.net
[22:40] <rlameiro> Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs?
[22:40] <rlameiro>  [s/i/m/l/k/n/b] s
[22:40] <rlameiro> Maintainer name : Ricardo da Rocha Lameiro
[22:40] <rlameiro> Email-Address   : lameiro@macinhata.net
[22:40] <rlameiro> Date            : Sat, 07 Nov 2009 22:38:26 +0000
[22:40] <rlameiro> Package Name    : hello
[22:40] <rlameiro> Version         : 2.4
[22:40] <rlameiro> License         : blank
[22:40] <rlameiro> Using dpatch    : no
[22:40] <rlameiro> Using quilt     : no
[22:40] <rlameiro> Type of Package : Single
[22:40] <rlameiro> Hit <enter> to confirm:
[22:40] <rlameiro> Could not find hello-2.4.orig.tar.gz
[22:40] <rlameiro> Either specify an alternate file to use with -f,
[22:40] <rlameiro> or add --createorig to create one.
[22:40] <rlameiro> lameiro@studio:~/hello/hello-2.4$
[22:40] <rlameiro> that tar doesnt exists
[22:40] <rlameiro> what exist is the underscore one
[22:40] <rlameiro> hello_2.4.orig.tar.gz
[22:41] <ScottK> !pastebin | rlameiro
[22:41] <mok0> !pastebin | rlameiro
[22:41] <rlameiro> sorry
[22:41] <mok0> Ha, ScottK you beat me to it
[22:42] <rlameiro> http://paste.ubuntu.com/312812/
[22:42] <rlameiro> better now?
[22:43] <mok0> rlameiro: You need to specify the tarball
[22:43] <rlameiro>  -r ?
[22:43] <rlameiro> at the tutorial they dont say that :/
[22:43] <mok0> rlameiro: you need at tarball called "hello-2.4.orig.tar.gz"
[22:44] <rlameiro> but shouldnt it be with _
[22:44] <rlameiro> ?
[22:44] <mok0> rlameiro: which must be in ../ relative to where you execute the commnad
[22:44] <mok0> yes
[22:45] <mok0> rlameiro: actually, it doesn't matter what it's called, as long as you specify it with the -f argument
[22:45] <rlameiro> ah
[22:45] <rlameiro> ok
[23:40] <bmm> Is it possible to have "quilt" generate a new file (not in the original source tree)?
[23:45] <dtchen> sure, via quilt new ... quilt add ... edit ... quilt refresh
[23:46] <Laney> or quilt shell!
[23:46] <dtchen> yep, several approaches
[23:48] <bmm> dtchen: that won't work for new files. If I create the file, then quilt new, quilt add file.txt, quilt refresh it will not see any changes as the file was added after it was created without any changes.
[23:49] <dtchen> err
[23:49] <jmarsden> bmm: Don't "create the file" first, create the file using quilt edit
[23:50] <dtchen> right
[23:50] <dtchen> I haven't ever created the file first :-)
[23:51] <bmm> jmarsden: but the files are created with a download script :( I'm trying to do a quick package of cgit and cgit requires me to download the full source of a git release in the source tree.
[23:52] <bmm> (I know, ugly, but still). So my plan now: make a list of all the files that I need, remove them, quilt add them before they exist, copy them back. Just making sure, that is the best way to do this with quilt?
[23:52] <Laney> use quilt shell
[23:53] <bmm> Laney: ah, that may help :D
[23:53] <bmm> Laney: of to try that...
[23:55] <bmm> Ah, works like a charm! Great, thanks!
[23:56] <Laney> good chap!
[23:57]  * bmm chuckles at the sight of a 9.8M patch