[01:27] <teward> are quilt patches allowed to modify items inside the debian/ folder or is that a nono
[01:29] <Noskcaj> teward, Why would you?
[01:30] <teward> Noskcaj: the fix for LP Bug #1264674 is to modify a third-party module inside the debian/ folder (nginx)
[01:30] <ubottu> Launchpad bug 1264674 in nginx (Ubuntu Saucy) "nginx segfault when adding add_header in configuration" [Undecided,Confirmed] https://launchpad.net/bugs/1264674
[01:30] <teward> i have an upstream diff (from Debian) that fixes this for the nginx-extras module, but the question is do I manually modify it or have it as a quilt patch
[01:30] <teward> s/modify it/apply the patch/
[01:31] <teward> (it's rare I have to touch the third-party modules :/)
[01:31] <Noskcaj> I'm guessing it's allowed to patch, debian-mentors is usually best for these questions though
[01:31] <teward> well, i'll see if debuild whines.
[01:31] <teward> it occasionally does that
[01:31]  * teward shrugs
[01:33] <cjwatson> I think you can probably modify files under debian/ in quilt patches in theory, at least with some source formats, but it's really really confusing and you shouldn't.
[01:34] <cjwatson> I would expect any sponsor who's paying attention to kick that back to you.
[01:35] <teward> cjwatson: that's what i thought, but it's been a while since i messed with the third-party modules in nginx, I can prep a debdiff for either, then if the sponsor wants to kick back the "This modifies debian/..." thing at me there's an alternate debdiff
[01:35] <teward> I have a feeling rbasak is keeping an eye on the bug, but I might be wrong.
[01:36] <cjwatson> I would recommend just preparing the one with the files under debian/ changed directly and not in quilt, rather than wasting a sponsor's time
[01:36] <teward> meh, that's equally easy
[01:36] <cjwatson> It's the right thing to do.  Conceptually the quilt patch series should apply to the upstream tarball without debian/ even there.
[01:37] <cjwatson> Tools such as git-dpm would probably fail if that weren't the case.
[01:39] <teward> yeah, makes sense.
[01:39] <teward> in other news, thank god I can have amd64 AND i386 builds within sbuild, it prevents me having to use the PPA builders to build-test things. ^.^
[08:14] <dholbach> good morning
[09:10] <rbasak> teward: the debdiff in bug 1264674 looks fine. But before I test/sponsor, could you complete the SRU justification please?
[09:10] <ubottu> bug 1264674 in nginx (Ubuntu Saucy) "nginx segfault when adding add_header in configuration" [Undecided,Triaged] https://launchpad.net/bugs/1264674
=== ikonia_ is now known as ikonia
[15:51] <fully_human> Stupid question time. When should I write a test case for a bug? What if I don't see a "test" folder for a package?
[15:53] <rbasak> fully_human: when it would be useful. On a bug-by-bug basis, I'd say. Do you want to describe the bug to get a more helpful response?
[15:54] <fully_human> An inkscape bug where a color swatch contains an incorrect color. Inkscape does not have a "test" folder already.
[15:55] <fully_human> But I suppose test folders can be per-branch and the package maintainer will just apply the patch without the test. :-|
[15:55] <rbasak> Ah. I'm not sure about desktop bugs, sorry. Perhaps a test case that a human can follow will do.
[15:55] <fully_human> So a little note with the patch saying "See what you expect? This is what the patch returns!"
[15:56] <rbasak> Are you talking about a test case for an SRU?
[15:57] <fully_human> SRU?
=== barry` is now known as barry_
=== barry_ is now known as barry
[20:41] <fully_human> Sorry, I'm really confused here. I've seen three or four different tutorials on fixing a bug on Ubuntu/Launchpad and they all seem to say different things. For example http://packaging.ubuntu.com/html/fixing-a-bug-example.html has me create a new branch while http://packaging.ubuntu.com/html/fixing-a-bug.html just tells me to create a patch, edit it (should I do it before or after `patch`?) and export to a patch.
[20:43] <Noskcaj> fully_human, The simplest way is just make a patch however you think and submit it to a launchpad bug
[20:44] <fully_human> So it's all about diffing...how I go about it is up to me.
[20:44] <fully_human> Maybe I should write something about that in the docs so no one else is confused. :-\
[20:53] <rbasak> fully_human: personally I find a debdiff the easiest. Prepare the new source package you're proposing, and then attach the output of "debdiff <old_dsc> <new_dsc>".
[20:53] <fully_human> Thanks. :)
[20:54] <fully_human> So, basically I can do: 'cp -R foo foo-bug-1', edit some file in foo-bug-1, then do a 'debdiff foo foo-bug1' ?
[20:55] <fully_human> And I assume debuild -S and pbuilder just make a debian I can test?
[20:56] <jtaylor> the non vcs apparoch is: quilt add <files you want to edit>
[20:56] <jtaylor> edit them
[20:56] <jtaylor> quilt refresh
[20:56] <jtaylor> dch -i, write changelog
[20:56] <jtaylor> debuild -S; debdiff old-dsc new-dsc
[20:56] <jtaylor> oh quilt new <patch-name> first
[21:04] <fully_human> When I do debdiff, should I be one level up from the package directory?
[21:04] <jtaylor> doesn't matter it just needs two dsc
[21:04] <jtaylor> after debuild they are usually in ../
[21:05] <fully_human> And so debdiff will automatically try to find them?
[21:05] <jtaylor> no you need to tell it the path of the dsc
[21:05] <jtaylor> it will find the rest by itself
[21:05] <fully_human> Oh, yeah, I suppose since you said "old-dsc." :P
[21:06] <jtaylor> debuild will create a new dsc if you updated the version with dch -i
[21:06] <jtaylor> see ls ../*dsc
[21:09] <fully_human> Okay, I think I'll just see what happens here...I'm still a bit confused but I think I understand what's going on up until dch -i.
[21:15] <fully_human> Ah, should I test the package before or after I run dch -i?
[21:15] <fully_human> (well, too late because I'm already writing the changelog. :P)
[21:16] <jtaylor> you should do it before you debuild, else you overwrite the old dsc
[21:16] <jtaylor> but its not a big deal just download it again
[21:17] <fully_human> And pbuilder will create the new deb file to install, right?
[21:17] <jtaylor> yes
[21:17] <fully_human> Aha! I think I'm getting it!
[21:17] <jtaylor> debuild can also do it
[21:17] <jtaylor> without -S
[21:17] <jtaylor> you do that to get it right, then test with pbuilder because its slower
[21:18] <fully_human> Yes, I discovered this. o.O
[21:19] <jtaylor> there are many tricks to speed up pbuilder
[21:20] <jtaylor> using eatmydata, special buildplace mountoptions, using apt-cachers etc
[21:20] <jtaylor> worth looking into when you do more packaging work
[21:20] <fully_human> Hm...yelling at my computer (expletives included) didn't help...
[21:20] <fully_human> Your suggestion will probably work better. :)
[22:43] <fully_human> Which makes sense, because installing modified binaries. Any way to reset the build?
[22:44] <fully_human> So I tested my patch. It tried doing `debuild -S` to generate dsc files, but I got a bunch of errors like this one: dpkg-source: error: cannot represent change to share/extensions/Barcode/__init__.pyc: binary file contents changed
[22:44] <fully_human> dpkg-source: error: add share/extensions/Barcode/__init__.pyc in debian/source/include-binaries if you want to store the modified binary in the debian tarball
[22:44] <fully_human> Which makes sense, because installing modified binaries. Any way to reset the build?
[22:44] <jtaylor> hm that means the clean target of rules does not do what it should
[22:44] <jtaylor> that is an unfortunate annoyance
[22:45] <jtaylor> the easiest way around this is to use version control to reset the build
[22:47] <jtaylor> without that you could extract a new copy and apply your debdiff on it
[22:47] <jtaylor> or fix the clean rule for testing (and file a bug in debian)
[22:53] <fully_human> Even when I do a bzr revert I get the same debuild errors (or does bzr revert revert back to *my* patch?). I must be doing something wrong.
[22:53] <jtaylor> bzr clean-tree
[22:53] <jtaylor> make sure your patch is commited first
[23:14] <fully_human> With 'bzr commit'?
[23:14] <jtaylor> bzr add <file>
[23:14] <jtaylor> bzr status will show you what willb e commited
[23:14] <jtaylor> it should only be stuff in debian