[00:40] <MTecknology> I need some help with some packaging... (http://bazaar.launchpad.net/~nginx/nginx/debian/files) An old version of nginx installed files for nginx-{full,light,extras} to /etc/logrotate.d/nginx-{full,light,extras}. The file was removed and put into nginx-common which installs /etc/logrotate.d/nginx. That part works perfect. The issue is upgrade from a broken version.
[00:41] <MTecknology> No matter what I try, I can't make the old file get properly removed.
[00:43] <MTecknology> nginx-common.{preinst,postinst,prerm} are using dpkg-maintscript-helper to deal with that but they don't seem to be doing anything. I don't see any errors, warnings, or anything during the upgrade either. Just looks like it worked great and then doesn't end up removing the old conf
[00:43] <MTecknology> I've been fighting this for over a month now and I'm just utterly lost.
[00:49] <Ampelbein> MTecknology: can you pastebin your debian/rules?
[00:49] <Ampelbein> MTecknology: and pre/post-inst/rm
[00:49] <MTecknology> Ampelbein: ya, you could just checkout that link too; it has those files
[00:50] <MTecknology> http://bazaar.launchpad.net/~nginx/nginx/debian/files
[00:50] <Ampelbein> true, I could do that. was feeling lazy ;-)
[00:50] <Ampelbein> but will do ;-)
[00:51] <MTecknology> :P
[00:56] <Ampelbein> MTecknology: maybe I need more coffee, but you don't have a preinst?
[00:57] <MTecknology> Ampelbein: no; do I need to add that file for this to work?
[00:58] <Ampelbein> MTecknology: yes, you do. in the pre-inst, dpkg-maintscript-helper determines what to do with the file and renames it to either *.dpkg-remove or *.dpkg-backup and in the postinst deletes or keeps this renamed file
[00:58] <MTecknology> oh......
[00:59] <MTecknology> that'd make a crap done of sense then..
[01:00] <MTecknology> Ampelbein: I'll try that and see how things work :D
[01:00] <Ampelbein> MTecknology: it does ;-) you need the snippet in the preinst, the postinst and postrm
[01:01] <MTecknology> hm.. might need to wait a little bit to redo this package
[01:05] <MTecknology> Ampelbein: so this is all I need in there? http://dpaste.com/456611/
[01:06] <Ampelbein> MTecknology: that looks about right
[01:14] <MTecknology> and now build time
[01:15] <Ampelbein> for me it's now oscar's time ;-)
[01:16] <MTecknology> hm?
[01:18] <Ampelbein> MTecknology: the academy awards 2011
[01:19] <Ampelbein> MTecknology: you know, that movie stuff, like youtube, only on big screen.
[01:43] <MTecknology> amoh
[01:43] <MTecknology> oh*
[01:57] <MTecknology> hm.... if anyone could help me figure out the rest of the conversation above..
[01:58] <MTecknology> This is what I end up with now - http://dpaste.com/456739/
[02:02] <MTecknology> I guess that's progress from where I was; things are at least trying to happen
[02:08] <lesliev> hi people! another question: when trying to follow daniel holbach's deb building tutorial, "debuild -S -sa" is not making a .diff file
[02:08] <lesliev> it is making a new .debian.tar.gz source file
[02:08] <lesliev> why doesn't it make a .diff.gz?
[02:09] <lesliev> this is the file it seems to be creating instead: ed_1.5-0ubuntu1.debian.tar.gz
[02:10] <micahg> lesliev: because it's using source format 3.0
[02:10] <lesliev> ok, so this is an improvement in debuild?
[02:11] <micahg> lesliev: here's where you can read more about it and its benefits: http://wiki.debian.org/Projects/DebSrc3.0
[02:12] <lesliev> ok, will look at that
[02:12] <lesliev> debuild also seems to be angry about the line I put in changelog
[02:12] <lesliev>   * Initial release.
[02:12] <lesliev>   * Repacked .tar.lz to .tar.gz, no other changes
[02:12] <lesliev> That second line it complains about
[02:12] <lesliev> parsechangelog/debian: warning: ed-1.5/debian/changelog(l4): unrecognised line
[02:12] <lesliev> LINE: 	* Repacked .tar.lz to .tar.gz, no other changes
[02:13] <lesliev> is there a problem with it?
[02:13] <micahg> lesliev: maybe it's your spacing
[02:13] <paultag> lesliev: looks like you did a tab?
[02:13] <micahg> MTecknology: seems like the postinst failed on nginx-common
[02:13] <paultag> that or irssi is barfing again
[02:14] <paultag> I have a package I'll be requesting a sync for soonish. Since we're in FFe, what must I do for the sync? If it helps, it closes a RC bug (in Debian, but same issue is in Ubuntu)
[02:14] <lesliev> oooooh, tab
[02:14] <paultag> lesliev: two spaces, jabroni
[02:14] <paultag> :)
[02:14] <micahg> paultag: is it bug fix only?
[02:15] <paultag> micahg: no, new upstream version with bugfixes, plus a dfsg repack, one theme is non DFSG
[02:15] <paultag> I missed that for the last few releases. Upstream is willing to relicense that, but in the meantime :)
[02:15] <MTecknology> micahg: does the postinst i pasted (http://dpaste.com/456611/) look obviously wrong?
[02:15] <micahg> paultag: if the new upstream isn't bug fix only, pass -e to requestsync to request an FFe
[02:16] <lesliev> :)
[02:16] <paultag> micahg: it's a fluxbox release -- it's been less then two days since the major number release last -- it's both upstream and debian bugfixes, I don't think there are new features. What would you do?
[02:16] <micahg> MTecknology: I'm not familiar with that type of scripts so I can't help you there
[02:16] <paultag> Oh jeez, two weeks
[02:17] <paultag> sorry, my fault
[02:17] <MTecknology> micahg: alrighty; thanks :) I couldn't even figure out which file it was yelling at me for
[02:17] <micahg> paultag: bug fix only, wherever they are, doesn't need an exception, only new features
[02:17] <paultag> micahg: cheers, thanks
[02:18] <MTecknology> micahg: the package I'm doing now is bug fixes to packaging only; no exception needed, just bug report?   and a new app I write would need to pass through an exception (and probably wouldn't make it) ? <-- that how it works right now?
[02:18] <micahg> MTecknology: lines 57 and 58 of your original paste
[02:19] <MTecknology> oh..
[02:19] <micahg> MTecknology: right
[02:19] <MTecknology> thanks again :)
[02:19] <micahg> MTecknology: actually 35 and 36 of the original paste
[02:59] <MTecknology> micahg: heh.. now I'm confused.. the only change was adding a .preinst file; not .postinst
[03:00] <MTecknology> and that exact same chunk is in each of package.{pre,post}{inst,rm}
[03:12] <c2tarun> good morning :)
[03:28] <Rcart> I'll apply this patch on bug 725217
[03:28] <Rcart> Bug the bug is present in the translation files (dir po), that the patch does not cover
[03:29] <Rcart> I would like to know if I *must* fix the typos in the .po files too.
[03:30] <Rcart> *But
[03:40] <RoAkSoAx> SpamapS i upgraded to nvidia drivers today and they are working well not perfect but good enough
[03:41] <SpamapS> RoAkSoAx: yeah when I get back home I'll upgrade. Good to hear though!
[03:41] <SpamapS> RoAkSoAx: did you solve your multi monitor issues?
[03:41]  * SpamapS really should be trying to get a bit more sleep
[03:44] <RoAkSoAx> SpamapS yeah kinda getting a dualhead2go to try it out and see what happens otherwise ill get a x200 ultrabase
[03:45] <Rcart> T_T
[03:45]  * Rcart is going to bed.
[03:49] <c2tarun> Can anyone give me a patch with DEP-3 tags. I want to look at one of those as an example.
[03:51] <paultag> c2tarun: http://dep.debian.net/deps/dep3/
[03:51] <paultag> c2tarun: there's a sample patch down a ways
[03:55] <c2tarun> this question may be silly, but why we refer FTBFS fixes as binutils-gold?
[03:56] <paultag> c2tarun: well binutils-gold issues are FTBFS issues, but not all FTBFS issues are binutils-gold issues
[03:56] <paultag> c2tarun: aptitude show binutils-gold, it's a change in the linker
[03:56] <paultag> c2tarun: and as a result, the linker behaves in a different way -- so some libraries which used to be linked are no longer linked
[03:56] <paultag> and as a result, it fails to build (from source)
[03:57] <c2tarun> paultag: got it :) thanks
[03:57] <paultag> c2tarun: cheers :)
[03:59] <c2tarun> can we use LIBS variable in rules file?
[04:01] <RAOF> c2tarun: No; you're not running in the same make context.
[04:09] <c2tarun> how to fix errors like [LD_ERROR] libkio.so.4: could not read symbols: Invalid operation
[04:21] <RAOF> c2tarun: http://wiki.debian.org/ToolChain/DSOLinking
[04:22] <RAOF> c2tarun: Essentially - fix the build order.
[04:28] <c2tarun> there is a package named kbarcode, when I am trying to install build-dependencies I am getting this error http://paste.ubuntu.com/573311/
[04:29] <c2tarun> when I am pinging to IP 91.189.88.45 I am getting response.
[04:30] <RAOF> I'd just try again; that's a network problem.
[04:34] <c2tarun> RAOF: I think that package is removed from that page.
[04:34] <c2tarun> RAOF: What should I do?
[04:34] <RAOF> Refresh your package lists if that error persists.
[04:34] <RAOF> Aaah.
[04:34] <RAOF> Sorry, I misread the error the first time.
[04:35] <RAOF> That error is frequently caused by your apt cache being out of date - so apt tries to download 4:4.6.0-0ubuntu2 when 4:4.6.0-0ubuntu3 (or whatever) has been released and hence 4:4.6.0-0ubuntu2 has been removed from the mirror.
[04:35] <RAOF> So, a simple “sudo apt-get update” should resolve things.
[04:35] <c2tarun> RAOF: so updating the chroot will do it?
[04:36] <RAOF> Right.
[04:36] <c2tarun> RAOF: thanks :)
[04:51] <lesliev> is there any list of packages that need packaging? searching for needs-packaging in launchpad doesn't seem to help much
[04:52] <lesliev> for example, it lists "symon", which looks like it last had activity in 2006
[04:52] <arand> lesliev: You might want to have a peek at harvest?
[04:52] <lesliev> which makes me think its not really even needed by anyone
[04:52] <lesliev> aha
[04:55] <arand> lesliev: It doesn't seems to be very exhaustive... hmm, http://harvest.ubuntu.com, looking at it, it doesn't have a good needs-packaging fileter it seems
[04:56] <arand> lesliev: I guess you could always check out debians lists, which should be somewhat representative I guess...
[04:56] <arand> lesliev: http://www.debian.org/devel/wnpp/requested
[04:57] <lesliev> so is most packaging done for debian and just pulled into ubuntu?
[04:59] <arand> Well that's the ideal case I guess, if possible.
[05:00] <lesliev> symon's changelog shows activity last year, so it may be worth trying to package. I am putting together a packaging presentation, so I want some test cases
[05:00] <lesliev> oh, checking that url...
[05:03] <arand> In particular now, when feature freeze is in action, it would likely be a good idea to get a new app into debian in order for it to get in natty+1.
[05:04] <lesliev> wow, a lot of requests are >1 year old
[05:07] <lesliev> does harvest rank requests based on how many people ask for the same thing?
[05:09] <arand> It may rank by bug heat or so, and uses plent of lp tags, I think..
[05:42] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
[07:54] <c2tarun> can anyone please help me with this error http://paste.ubuntu.com/573321/ I know how to fix this error, but I dont know where to link the libraries to fix the error.
[08:01] <Bachstelze> c2tarun: looking at it
[08:08] <dholbach> good morning
[08:13] <Rhonda> Hmm, I guess I need a FFE for gitolite. Or actually not, it's just a oneline security-related fix?
[08:13] <Rhonda> I guess I should also prepare updates for maverick
[08:14] <Rhonda> Ouch! natty still has 1.5.4, for the update to 1.5.7 I _definitely_ would need a FFE, I'm taking the question back. :)
[08:14] <Rhonda> Now I wonder: Should I rather go for FFE for 1.5.7-2, or rather try to prepare an 1.5.4-2ubuntu1 with the security fix only, for natty?
[08:22] <Bachstelze> c2tarun: have you tried ld's suggestion of adding /usr/lib/libkio.so.4 to the command line?
[08:39] <siretart> Rhonda: at this point, your chances for a FFe seem high :-)
[08:51] <Rhonda> siretart: So you'd suggest 1.5.7-2 to natty with FFe and 1.5.4-1ubuntu1 to maverick-updates for a SRU?
[08:56] <siretart> Rhonda: I didn't look into that case at all. I just pointed out that FFe used to be approved more lightly right after FF than right before release
[09:04] <Rhonda> Rught
[11:52] <Rhonda> Shall I pass the maverick update for gitolite through the security team? Anyone I could query about that?
[11:53] <Rhonda> micahg, sbeattie?
[11:54] <Rhonda> Or is even kees around for a quick question?
[14:07] <ari-tczew> bdrung_: https://lists.ubuntu.com/archives/technical-board/2011-February/000707.html
[14:08] <ari-tczew> if you have another solutions, please reply on list
[14:24] <c2tarun> I was working on bug 726405. The problem can be fixed by making a change in Makefile.am by a patch, but the problem is when I am building the source package the debdiff is getting extremenly large because a file Makefile.in is being generated automatically which is causing this problem. After building first time when I am trying to build the package again I am getting the error patch failed. What can I do?
[14:25] <ari-tczew> c2tarun: attach this large debdiff to bug for example
[14:31] <Laney> that package seems to have it's reautotoolisation split up into patches in d/patches
[14:56] <c2tarun> ari-tczew: I am trying but not able to upload that file on LP, may be my connectio problem. Can I upload it to someother place?
[14:56] <c2tarun> ari-tczew: phew... its done :) please take a look at bug 726405
[15:06] <ari-tczew> c2tarun: quilt delete debian-changes-2.0.7-3ubuntu1
[15:06] <ari-tczew> and rerun build source
[15:07] <c2tarun> ari-tczew: but why is it there ? I didn't create it.
[15:10] <ari-tczew> c2tarun: sometimes it just works like that. domain of 3.0 source format.
[15:10] <micahg> ari-tczew: you should be able to push to any branch you can upload to
[15:11] <ari-tczew> micahg: the case is changing status of merges
[15:11] <micahg> ari-tczew: you can do that for branches you can control, as should be appropriate
[15:12] <ari-tczew> micahg: bdrung can't do this as well and he is core-dev
[15:12] <ari-tczew> so it's NOT appropriate ;]
[15:13] <micahg> which branch specifically
[15:13] <ari-tczew> c2tarun: * Modified patch according to dep3 format. <- remove it, not necessary info for d/changelog
[15:13] <ari-tczew> micahg: https://code.launchpad.net/~legolas/ubuntu/natty/php5/5.3.5/+merge/48128
[15:14] <micahg> Rhonda: re gitolite, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[15:16] <c2tarun> ari-tczew: I uploaded a new debdiff, can you please take a look, and tell me if still there is some problem
[15:17] <Rhonda> micahg: Thanks. No CVE id though. But I'll follow through that checklist, expect a bugreport later tonight (european time)
[15:20] <micahg> Rhonda: well, you might want to ask in #ubuntu-hardened to be sure if it should go through security, I remember the mentions in the Debian channel about it
[15:21] <Rhonda> micahg: Does http://git.deb.at/w/pkg/gitolite.git/commitdiff/d471220 look proper to you? ae402da is the cherry-picked one-line change.
[15:23] <Rhonda> I'm fine with dropping the Maintainer email address change if it really must, but I'd like to adjust these things when I'm in there already.
[15:23] <micahg> Rhonda: version and target are correct, maintainer address changes probably shouldn't happen in a security update, but I don't see the actual one line change in tehre
[15:24] <Rhonda> It's ae402da, replace the end of the URL (or click the [parent] link)
[15:24] <ari-tczew> c2tarun: * Modified patch according to dep3 format. <- remove it, no point to keep this change
[15:25] <micahg> Rhonda: yeah, you should probably run that by sbeattie in #ubuntu-hardened in a few hours
[15:25] <ari-tczew> c2tarun: Bug: https://bugs.launchpad.net/ubuntu/+source/kbarcode/+bug/726405 <- it's wrong, please use another tag and short URL
[15:25] <micahg> Rhonda: he's on community this week
[15:25] <Rhonda> micahg: Alright, will drop by there later then.
[15:25] <ari-tczew> c2tarun: Bug-Ubuntu: https://launchpad.net/bugs/bug-number
[15:25] <c2tarun> ari-tczew: sure i'll do it
[15:26] <ari-tczew> c2tarun: generally d/changelog entry should be rewrited
[15:28] <ari-tczew> c2tarun: use something like this http://pastebin.ubuntu.com/573493/
[15:29] <ari-tczew> c2tarun: I guess your fix in Makefile is wrong
[15:29] <ari-tczew> c2tarun: try just add -lbkio
[15:29] <ari-tczew> sorry, -lkio
[15:30] <c2tarun> ari-tczew: I tried, after adding -lkio and after that it will ask for another and another, that's how I got all of them
[15:33] <ari-tczew> c2tarun: let me try to build
[15:33] <c2tarun> ari-tczew: sure
[15:34] <mike__b> Hi, I have a package that does not have any patches yet. I've added a patch to it, to debian/patches, and added that patch to debian/rules. If I build a package from that, the patch is not applied. How can I check what is missing?
[15:35] <mike__b> I meant debian/patches/series
[15:36] <Ampelbein> mike__b: what sourceformat is the package using?
[15:36] <ari-tczew> c2tarun: in future please use tag Description instead Subject if you add one sentence.
[15:36] <mike__b> Ampelbein: I'm sorry, I'm a real newbie wrt Deb packages. How would I check?
[15:36] <ari-tczew> mike__b: what-patch
[15:37] <mike__b> unknown patch system :D
[15:37] <ari-tczew> mike__b: do you creating new package?
[15:37] <c2tarun> ari-tczew: sure, I'll fix that too and upload a final debdiff
[15:37] <mike__b> No, I'm trying to patch an already existing package.
[15:37] <mike__b> But the package did not have patches before.
[15:38] <ari-tczew> c2tarun: in bug 725933 DEP3 tags should be below /bin/sh (initial script)
[15:38] <ari-tczew> mike__b: does this package exist in Debian?
[15:39] <mike__b> Yes it does.
[15:40] <ari-tczew> mike__b: check https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[15:40] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom in 20 minutes!
[15:40] <c2tarun> ari-tczew: please take a look on my new upload on bug 726405 meanwhile I'll fix bug 725933
[15:44] <mike__b> ari-tczew: I read that article already, but to me it's confusing because it discusses so many different use cases. What am I missing? Should I add the stuff to debian/rules about the patches?
[15:50] <ari-tczew> mike__b: which package?
[15:50] <c2tarun> can anyone please help me with this error, http://paste.ubuntu.com/573510/ I got this error when I changed the sequence of few comments in .dpatch file
[15:50] <mike__b> ari-tczew: libsoap-lite-perl
[15:52] <ari-tczew> mike__b: switch to 3.0 source format will be easiest way
[16:00] <MTecknology> I have nginx-common.preinst 'http://dpaste.com/456611/' That exact same chunk is sitting in {pre,post}{inst,rm}. The package would install just fine prior to adding .preinst. Now it blows up when I try to install it.. http://dpaste.com/456739/      Any thoughts to what I might be doing wrong? Packaging is at http://bazaar.launchpad.net/~nginx/nginx/debian/files
[16:11] <tap-out> what is ubuntu motu
[16:12] <Rhonda> Ubuntu is a Linux Distribution, and MOTU stands for Master Of The Universe, a petname for developers responsible for the packages in the "universe" part of the distribution.
[16:16] <jpds> Rhonda: Shame he left. :<
[16:18] <Rhonda> uhm
[16:18]  * Rhonda is a fair bit annoyed about quick-leavers
[16:25] <MTecknology> Rhonda: indeed.. at least he past the 2min barrier for most
[16:25] <ari-tczew> Rhonda: if you don't want write to wall, please use TAB for check whether nick is still online
[16:26] <ari-tczew> it will be also helpful for person who asked because he will be notified (highlight)
[16:29] <joaopinto> hum, doesn't the MOTU definition overlaps with "Ubuntu Contributing Developers" ?
[16:32] <Laney> !motu
[16:32] <Laney> !ucd
[16:32] <Laney> I don't know why it says 'collectively responsible' — that's not my understanding (https://launchpad.net/~universe-contributors)
[16:33] <joaopinto> from https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev, UCDs are collectively responsible for the maintenance of most of the packages in Ubuntu  = universe ?
[16:34] <joaopinto> unless we read as MOTUs being a subset of UCDs, meaning you can be an UCD maintaining packages without being a MOTU
[16:35] <Laney> UCD means you have met the requirements for membership, and you contributions are from development
[16:39] <Rhonda> ari-tczew, very much thanks for your input, actually I did that, but thanks anyway.
[16:41] <Rhonda> joaopinto: UCDs need sponsorship for uploads, MOTUs don't.
[16:41] <joaopinto> ah ok, tks
[16:43] <ari-tczew> UCD = Ubuntu Member + Bug control
[16:45] <Laney> I don't think it gives bug control.
[16:46] <udienz> UCD = Ubuntu Member + Revu uploader + Planet Ubuntu
[16:47] <ari-tczew> Laney: Right, MOTU gives bug control.
[16:47] <Laney> yes
[16:54] <fta> siretart, ping
[16:56]  * siretart throws a contentless pong back
[16:56] <fta> siretart, i was wondering about debian bug 595452, it's been a while and the bug is still there in natty. could we land that at least as a distro patch, if not directly upstream
[16:56] <siretart> fta: what would be the patch?
[16:57] <siretart> AFAIR. the lavf demuxer is already enabled by default in rc4
[16:57] <fta> siretart, referring to the "there is a patch pending for it in the MPlayer dev list" comment in the bts
[16:58] <siretart> that referred to the native mkv demuxer
[16:58] <siretart> from a distro POV, you want to improve libavformat, not the mplayer internal mkv demuxer
[16:58] <fta> i still have mkv files that are unplayable in mplayer but fine in totem (yet too slow)
[16:58] <siretart> do they play with ffplay?
[17:00] <fta> super slowly but yes. mplayer is able to play the video smoothly (vdpau) but doesn't recognize the sound track
[17:01] <siretart> that indicates a deficiency in libavformat. get that fixed :-)
[17:03] <fta> well, no, as -demuxer lavf is fine
[17:03] <siretart> no, you just told me that ffplay was broken
[17:04] <fta> no, it's slow (no vdpau)
[17:04] <siretart> aaah, so whats the problem then?
[17:04] <fta> no audio with mplayer default demuxer
[17:06] <fta> siretart, http://paste.ubuntu.com/573540/
[17:07] <siretart> that paste indicates the (broken) internal mkv demuxer. so?
[17:07] <fta> isn't what the debian bug is about?
[17:08] <fta> well, n-m, -demuxer lavf will do.
[17:08] <siretart> rc4 (which we have in natty) uses the libavformat demuxer by default, or not?
[17:08] <siretart> oh, it says that rc4 used the internal mkv muxer? that would be a bug then, indeed
[18:59] <geser> tumbleweed: I've commented on your u-d-t merge proposal.
[18:59] <geser> Have you tried to use your branch over ssh? as this would be a general launchpadlib problem which will affect other non-u-d-t scripts too
[19:02] <tumbleweed> geser: yeah working on it with leonardr in #launchpad
[19:02] <tumbleweed> well, working on notes for NEWS
[19:03] <tumbleweed> it seems like it'll work on headless boxes over ssh, but once you have python-gnomekeyring installed, things get messy
[19:28] <ari-tczew> geser, tumbleweed: is requestsync broken at this moment?
[19:29] <geser> sort of, python-launchpadlib 1.9 requires some changes, tumbleweed is working on it
[19:29] <tumbleweed> ari-tczew: use e-mail for now
[19:29] <ari-tczew> tumbleweed: or LP :)
[19:30] <tumbleweed> or request the sync from a non-natty machine :)
[19:30] <ari-tczew> tumbleweed: no infrastructure :>
[19:31] <kklimonda> use VM
[19:32] <micahg> tumbleweed: newest requestsync is broke on any version
[19:32] <kklimonda> I keep older releases in VM so I can test on them, or fallback if my current development install is getting too unstable ;)
[19:33] <tumbleweed> micahg: you mean the not-quite-newest requestsync?
[19:34] <micahg> I guess, the one from 0.117 ubuntu-dev-tools
[19:36] <manish> what is the possible problem with this changelog file?
[19:36] <manish> http://paste.ubuntu.com/573624/
[19:36] <manish> I get
[19:36] <manish> parsechangelog/debian: warning: zeitgeist-datahub-0.7.0/debian/changelog(l7): badly formatted trailer line
[19:36] <manish> LINE:  -- Manish Sinha <manishsinha@ubuntu.com> Tue, 01 Mar 2011 01:00:00 +0530
[19:37] <tumbleweed> micahg: yeah, sorry about that, python scoping is a bit weird sometimes. 0.118 fixed it
[19:38] <ari-tczew> manish: please use dch -e
[19:39] <manish> ari-tczew: same
[19:39] <manish> parsechangelog/debian: warning:     debian/changelog(l7): badly formatted trailer line
[19:39] <manish> LINE:  -- Manish Sinha <manishsinha@ubuntu.com> Tue, 01 Mar 2011 01:00:00 +0530
[19:39] <manish> both the lines starting from * should end with a . ?
[19:39] <manish> right?
[19:40] <seidos> period = unity
[19:40] <seidos> i'm working on a flag
[19:41] <ajmitch> manish: two spaces between the email address & the date, not one
[19:42] <manish> ajmitch: yes. that was the issue. Thanks
[19:42] <MTecknology> http://dpaste.com/459264/ <-- Any chance you guys could help me figure out this? /etc/logrotate.d/nginx-full should get removed. Packaging.. http://bazaar.launchpad.net/~nginx/nginx/debian/files
[19:46] <MTecknology> err. that's not the 'exact' packaging, this has two fixes to keep it from breaking, but those are obvious in the paste
[20:22] <pulb> hi guys, I created this package -> http://revu.ubuntuwire.com/p/basenji.  ari-tczew mentioned it is possibly too late to get it into natty and suggested to get it into debian. any opinions?
[20:22] <Quintasan> pulb: Yup, too late for Natty as Feature Freez is in effect
[20:23] <Quintasan> I think you can get it in Debian and then request a sync in natty+1
[20:23] <pulb> hmmpf, I spend a lot time to get comfortable with this revu stuff. is debian uploading any different?
[20:24] <Quintasan> pulb: dput mentors <changes>
[20:24] <pulb> I don't have the time to install debian for testing, is it just a matter of dependency renaming?
[20:24] <Quintasan> pulb: be sure to change the package to meet Debian requirements (like version in changelog etc)
[20:25] <Quintasan> pulb: I do not think there should be any dependency renames
[20:25] <Quintasan> pulb: Be sure to check you package using sid pbuilder
[20:26] <pulb> if i dput it to mentos, where do i get feetback?
[20:26] <pulb> err mentors
[20:26] <Quintasan> pulb: http://mentors.debian.net/cgi-bin/welcome
[20:27] <Quintasan> pulb: You will need to find a sponsor for your package, your best shot is #debian-mentors @ irc.oftc.net
[20:27] <pulb> ok, thanks!
[20:28] <micahg> ari-tczew: your advise on kklimonda's application is wrong, UNRELEASED should be used when proposing merges in a VCS unless you are the uploader
[20:28] <micahg> err, scratch that last part, proposed merges should target UNRELEASED in case changes need to be made
[20:29] <ari-tczew> micahg: yea, in VCS, not in lp:ubuntu/foo
[20:30] <micahg> ari-tczew: UDD is a VCS
[20:30] <ari-tczew> o_O
[20:30] <micahg> if something in a UDD branch is not in the archive, the target should be UNRELEASED
[20:34] <ari-tczew> micahg: I like sponsoring bzr merges by sponsor-patch but if branch is UNRELEASED there is a problem because it won't upload it into archive
[20:35] <micahg> ari-tczew: then the tool should be fixed
[20:35] <ari-tczew> bdrung: ^^
[20:36] <bdrung> ari-tczew, micahg: that's how sponsor-patch works. it will ask if you want to set the series. then you can set it to whatever you want (natty, maverick-proposed, ...)
[20:36] <ari-tczew> bdrung: by script? don't I need to open directory in /tmp and do it manually?
[20:37] <bdrung> ari-tczew: if you say "yes", it will give you a shell in the correct directory
[20:37] <bdrung> ari-tczew: do you have an example bug?
[20:38] <ari-tczew> bdrung: no at this moment
[20:38] <ari-tczew> bdrung: ehh, can't script do it automatically?
[20:38] <ari-tczew> e.g. "there is UNRELEASED target, would you like to update it?"
[20:38] <ari-tczew> and options to choice
[20:38] <bdrung> ari-tczew: do we always know where it should be uploaded?
[20:38] <ari-tczew> 1. natty
[20:38] <ari-tczew> 2. maverick-rpoposed
[20:39] <ari-tczew> bdrung: if you take it as sponsor, you should know where do you want upload it
[20:39] <bdrung> yes, but does the script can know it?
[20:39] <ari-tczew> bdrung: as I wrote 2 minutes ago, choice
[20:41] <micahg> ari-tczew: that's a maintenance burden for the script to always keep those updated
[20:42] <bdrung> micahg: no, we have distro-info!
[20:42] <micahg> bdrung: ah, you actually did it?
[20:42] <bdrung> yes
[20:42] <cody-somerville> couldn't it just ask and let the user input the suite name? That would be better than dropping to a shell and having to do it manually + would make the tool work in non-ubuntu context.
[20:43] <bdrung> cody-somerville: it is very ubuntu specific currently
[20:43] <bdrung> cody-somerville: it work on LP bugs
[20:43] <bdrung> s/work/works/
[20:47] <micahg> kklimonda: congrats on MOTU
[20:47] <highvoltage> kklimonda: welcomee to MOTU!
[20:48] <kklimonda> thanks highvoltage, micahg :)
[20:49] <chrisccoulson> kklimonda, oh, congrats!
[20:49] <Quintasan> kklimonda: \o/ cookies
[20:50]  * ari-tczew gives beer for kklimonda
[20:50] <porthose> kklimonda, congrats welcome to MOTU :)
[20:51] <kklimonda> chrisccoulson: thanks, it did take me some time, but I've done it at last :)
[20:51] <kklimonda> porthose: thanks :)
[21:06] <kklimonda> Ampelbein: you should branch ubuntu:transmission (or lp:ubuntu/transmission)
[21:08] <Ampelbein> kklimonda: I did that. And then made a local branch for my bugfix. But then I'm getting a bit stuck. Do I have to use quilt to make my patch? Do I just edit the source? But how does the patch come in then? This is all a bit confusing
[21:08] <kklimonda> Ampelbein: it is, isn't it? :)
[21:09] <kklimonda> Ampelbein: you use quilt, add patch and changelog entry and then push your branch.
[21:10] <Ampelbein> kklimonda: but then I end up with the changes 2 times in the bzr-diff - once in the original file and once in the patch. I know that it doesn't matter much but that doesn't sound right, if you know what I mean.
[21:10] <kklimonda> .pc folder doesn't exist in transmission branch so I assume you don't have to commit it. But this part is a bit fuzzy
[21:11] <kklimonda> Ampelbein: I just do quilt pop -a before commiting when .pc is not in vcs
[21:11] <Ampelbein> kklimonda:  I branched with 'bzr branch ubuntu:transmission natty'
[21:12] <Ampelbein> kklimonda: which has the patches applied (and thus the .pc directory)
[21:12] <kklimonda> ah, then you should commit along with .pc
[21:13] <kklimonda> sorry, I've cloned the wrong branch - I don't use bzr for transmission myself
[21:13] <kklimonda> (but it's time to start doing it)
[21:14] <Ampelbein> kklimonda: it is easier with just apt-get source, quilt new, quilt add, quilt refresh, debuild -S, debdiff, attach. at least till I understand this bzr thing fully.
[21:14] <Ampelbein> kklimonda: but thanks, I will have another go.
[21:15] <kklimonda> Ampelbein: I think you should add both debian/patches/patch and .pc/patch
[21:15] <kklimonda> lets see if it works
[21:20] <kklimonda> nope.. hmm..
[21:22] <kklimonda> Ampelbein: it looks like you should clone the branch, create patch with quilt, add changelog entry, unapply the newly created patch, commit changelog, d/patches/series and d/patches/patch and that's it..
[21:23] <Ampelbein> kklimonda: is there a website somewhere documenting that?
[21:23] <kklimonda> but other patches are applied and .pc directory is commited.. ugh..
[21:24] <kklimonda> Ampelbein: there is an entire wiki page about it: https://wiki.ubuntu.com/DistributedDevelopment but I don't know how up to date it is. I just tinker with it until it works :)
[21:25] <MTecknology> http://dpaste.com/459264/ <-- Any chance you guys could help me figure out this? /etc/logrotate.d/nginx-full should get removed. Packaging.. http://bazaar.launchpad.net/~nginx/nginx/debian/files (only difference is the chmod that was breaking it and the use of set -x)
[21:25] <kklimonda> Ampelbein: there is also https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[21:25] <MTecknology> Ampelbein: maybe you could take a look?.. :D
[21:26] <Ampelbein> kklimonda: some pages there seem like "we need to document this", but https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem looks good
[21:27] <kklimonda> Ampelbein: hmm, interesting - I've heard of looms before but it was months ago and they were being mentioned in context "it would be nice to have looms to do it" ;)
[21:28] <Ampelbein> MTecknology: maybe later, I'm currently trying to figure out using bzr ;-)
[21:29] <MTecknology> Ampelbein: alrighty; if you help me get this actually working I might need to go find you and hug you
[21:31] <Ampelbein> kklimonda: http://bazaar.launchpad.net/~amoog/transmission/bug-726756/revision/63 this is the result of my current try without the looms stuff
[21:32] <kklimonda> Ampelbein: it will create a debian-changes file when you try building a source package out of it
[21:34] <Ampelbein> kklimonda: yes, that's fine I guess? transmission is source format 3.0 already.
[21:36] <Ampelbein> kklimonda: and the debdiff looks fine, too http://paste.ubuntu.com/573667/
[21:36] <kklimonda> Ampelbein: indeed, looks fine
[21:38] <Ampelbein> kklimonda: I will propose a merge request and see what seb has to say ;-)
[21:39] <kklimonda> Ampelbein: I can upload transmission, so I'll see if it works and upload ;)
[21:39] <Ampelbein> kklimonda: oh, even better. thanks ;-)
[21:40] <kklimonda> no problem
[22:07] <kklimonda> Ampelbein: it doesn't work for me, any idea how to debug it?
[22:09] <Ampelbein> kklimonda: you could try 'strace -o magnet.txt xdg-open "magnet-url"' to see what gets called?
[22:18] <Ampelbein> MTecknology: where is your package failing now? the packaging looks good (apart from the 2 things you mentioned)
[22:18] <kklimonda> Ampelbein: hmm
[22:18] <kklimonda> Ampelbein: does it work for you with Exec=transmission-gtk %F ?
[22:19] <kklimonda> I've had to change it to Exec=transmission-gtk %U
[22:19] <kklimonda> and, by reading fd.o specification, I've come to conclusion that %F is wrong code for Exec in transmission's case..
[22:19] <kklimonda> but it's been there for as long as I can remember, and it worked just fine.
[22:22] <Ampelbein> kklimonda: actually it doesn't work for me with %F. I manually edited the .desktop in /usr/share/applications and must have forgot about that change. silly me.
[22:22] <Ampelbein> kklimonda: I edited back to original state now and transmuussion just starts, but no add-file dialog
[22:22] <Ampelbein> kklimonda: with %U it works
[22:23] <kklimonda> it looks like fd.o tools got more strict in natty
[22:24] <Ampelbein> kklimonda: I will update the upstream bug once it gets through moderation queue.
[22:24] <kklimonda> upstream bug? you have a number?
[22:26] <Ampelbein> kklimonda: not yet, it is still in moderation queue
[22:26] <kklimonda> moderation queue on transmission trac? huh.. I'll poke developer to get it through :)
[22:27] <Ampelbein> kklimonda: yes, I needed to register myself there and when i made new ticket, it said it was in queue for moderation.
[22:27] <Ampelbein> kklimonda: I pushed an updated branch with the fix
[22:27] <kklimonda> thanks
[22:28] <acarpine> I need help
[22:29] <acarpine> I worked on the bug 719379
[22:29] <RAOF> acarpine: Ah!  That was you?
[22:29] <acarpine> wow raof you are here!
[22:29] <acarpine> tks 4 your reply
[22:30] <acarpine> but this is my first bug fix
[22:30] <acarpine> just a couple of questions...
[22:30] <RAOF> Shoot!
[22:32] <acarpine> I believe my error is that I used bzr push lp:~acarpine/ubuntu/natty/python-fstab/fix-719379
[22:32] <acarpine> instead of bzr push lp:~juliank/python-fstab/debian
[22:32] <acarpine> correct?
[22:33] <acarpine> I'm talking about your first email advice
[22:33] <RAOF> acarpine: No.  You pushed to the right place, but when you made the merge request you asked for it to be merged into the wrong tree.
[22:34] <RAOF> You wouldn't have been able to push to lp:~juliank/python-fstab/debian, but you should be able to request a merge of your existing branch into it.
[22:34] <acarpine> ok, clear now (I hope :-)
[22:35] <RAOF> Feel free to ask more questions if I've been unclear anywhere else - I'll be here for the next 8 hours or so :)
[22:35] <acarpine> the last advice said smthing about
[22:35] <acarpine> You could drop the debian/changelog hunk and propose a merge into lp:python-fstab, which is where the upstream code lives.
[22:35] <RAOF> (and then tomorrow, and the next day, and … ☺)
[22:35] <acarpine> :) tks
[22:36] <kklimonda> Ampelbein: I'll upload it after the soft freeze is over
[22:36] <acarpine> I believe my problem is caused by my bad English...
[22:36] <acarpine> raof: what do you mean with drop the debian/changelog hunk ?
[22:37] <kklimonda> Ampelbein: It'll give me some time to get a response from T dev about this issue, as I'd like to get his input on it - the %F did come from somewhere :)
[22:37] <Ampelbein> kklimonda: sure, no problem. thanks again for the help with bzr, I think I understood that a bit better now.
[22:37] <RAOF> acarpine: No, it's probably the specialised language that I'm using. :)
[22:38] <RAOF> acarpine: So, a “hunk” is the name for one piece of the patch; your patch has 3 hunks - one for the changelog, and one each for the 2 message typos.
[22:39] <Ampelbein> kklimonda: probably from the time when transmission didn't know magnet? as for torrent files I think %f is ok.
[22:40] <kklimonda> Ampelbein: no, %F has broken opening torrents directly from Firefox
[22:40] <kklimonda> both worked fine in maverick, and broke in natty
[22:41] <Ampelbein> kklimonda: oh, I used to save torrent files and open from download folder so I didn't run into that problem.
[22:42] <RAOF> acarpine: And as for what I was saying there: In Ubuntu, we generally take the code that various different projects write - banshee, gnome-do, firefox, python-fstab, …, ensure that it integrates with the rest of Ubuntu, and add the bits of metadata that become a Debian package.
[22:42] <RAOF> acarpine: Other distros do the same thing.  So to make your fix as useful as possible, it would be good to submit it to the python-fstab project - that way it'll be fixed in Ubuntu, and Debian, and Fedora, and…
[22:43] <RAOF> acarpine: And to do that, you'd want to make the same changes, but submit a merge to lp:python-fstab :)
[22:45] <acarpine> raof: but why I should "drop my changelog hunk" I mean...when I submit a merge directly to lp:python-stab I don't need to edit the changelog?
[22:46] <acarpine> ...I'm feeling like a babe at his first lesson...
[22:46] <RAOF> acarpine: Ah!  Because lp:python-fstab won't *have* debian/changelog.  Because debian/changelog is a part of the metadata that goes into a Debian package, not a part of the upstream project.
[22:48] <acarpine> raof: wow incredible...my question have some logic so :D
[22:49] <RAOF> acarpine: Yeah, there's a whole specialised language to distro development.  It can be difficult to understand if you're unfamiliar wih it :)
[22:50] <acarpine> raof: Ok, perfect so I can change my previous branch or I have to delete it to fix....
[22:52] <RAOF> acarpine: To merge into lp:python-fstab you'll need to redo your branch, this time starting by “bzr branch lp:python-fstab” and then making your changes.
[22:52] <RAOF> acarpine: To re-target your existing branch at lp:~juliank/python-fstab/debian you won't need to do anything to your branch.
[22:56] <acarpine> raof: ok I try, really tks raof
[22:56] <RAOF> No problem!  Thanks for your work!
[23:10] <kklimonda> Ampelbein: ticket got accepted, can you add a comment about %U?
[23:15] <Ampelbein> kklimonda: done
[23:51] <acarpine> raof: done
[23:53] <acarpine> raof: I hope I did well...but i'm still not very self-confident (I have good reasons :)
[23:58] <RAOF> acarpine: I'll take a look.
[23:59] <acarpine> raof: using bzr branch lp:python-fstab instead my previous bzr branch lp:ubuntu/python-fstab downloaded a different sources.
[23:59] <acarpine> Sources without the debian directory (I believe this explain your comment about the changelog...)