| teward | are quilt patches allowed to modify items inside the debian/ folder or is that a nono | 01:27 |
|---|---|---|
| Noskcaj | teward, Why would you? | 01:29 |
| 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:30 |
| 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:31 | |
| 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:33 |
| cjwatson | I would expect any sponsor who's paying attention to kick that back to you. | 01:34 |
| 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:35 |
| 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:36 |
| cjwatson | Tools such as git-dpm would probably fail if that weren't the case. | 01:37 |
| 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. ^.^ | 01:39 |
| dholbach | good morning | 08:14 |
| 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 | 09:10 |
| === ikonia_ is now known as ikonia | ||
| 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:51 |
| 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:53 |
| fully_human | An inkscape bug where a color swatch contains an incorrect color. Inkscape does not have a "test" folder already. | 15:54 |
| 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:55 |
| rbasak | Are you talking about a test case for an SRU? | 15:56 |
| fully_human | SRU? | 15:57 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| 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:41 |
| Noskcaj | fully_human, The simplest way is just make a patch however you think and submit it to a launchpad bug | 20:43 |
| 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:44 |
| 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:53 |
| 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:54 |
| fully_human | And I assume debuild -S and pbuilder just make a debian I can test? | 20:55 |
| 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 | 20:56 |
| 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:04 |
| 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:05 |
| jtaylor | debuild will create a new dsc if you updated the version with dch -i | 21:06 |
| jtaylor | see ls ../*dsc | 21:06 |
| 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:09 |
| 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:15 |
| 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:16 |
| 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:17 |
| fully_human | Yes, I discovered this. o.O | 21:18 |
| jtaylor | there are many tricks to speed up pbuilder | 21:19 |
| 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. :) | 21:20 |
| fully_human | Which makes sense, because installing modified binaries. Any way to reset the build? | 22:43 |
| 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:44 |
| jtaylor | the easiest way around this is to use version control to reset the build | 22:45 |
| 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:47 |
| 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 | 22:53 |
| 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 | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!