[11:34] <SimonK> hi there :), anyone here who can tell me, how to check out a (mainline-) kernel?
[11:36] <SimonK> It seems like kernel 3.9.* has only candidates up to "v3.9.7", but in the kernel-ppa is a "v3.9.11-saucy" version ("git checkout v3.9.11" says that git dosn't know this version)
[11:39] <smartboyhw> SimonK, quite certain that 3.9.11 is a vaild version
[11:40] <SimonK> hm, just to be on the safe side: if i am able to check out 3.10-rc1, that means 3.9.11 should be in my git-tree?
[11:41] <SimonK> the highest number i can find is "2ea699d98cd6f9e9b813c24542d581dedacdc659 refs/tags/v3.11-rc6"
[11:41] <smartboyhw> SimonK, you checked out http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=summary right?
[11:42] <smartboyhw> Well, "master" only bases on Linus' tree
[11:42] <smartboyhw> i.e. does not include any stable releases from upstream Linux
[11:45] <smartboyhw> SimonK, mainline actually means https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ (for stable kernels)
[11:45] <SimonK> I cloned "git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git"
[11:46] <SimonK> kernel.org didn't let me clone (it stopped at 13% every time, probably because of my dsl-speed)
[11:47] <SimonK> well, then i do a bisect between 3.9.7 and 3.10-rc1.
[11:48] <smartboyhw> SimonK, ubuntu-saucy != mainline.............
[11:49] <SimonK> so I have to clone from kernel.org? Well, thats unfortunate.
[12:40] <hggdh> SimonK, smartboyhw: the Ubuntu kernel versions are slightly different from upstream git (given that we usually start with the devel kernels)
[12:40] <hggdh> an easy way to find that out is by looking at /proc/version_signature -- there you will see the Ubuntu version and the upstream version
[12:41] <SimonK> I see... I'm trying to download from kernel.org at the moment *fingers crossed*
[12:41] <SimonK> I'll never understand why you have to restart a cloning if you abrot it bevore :/
[12:47] <hggdh> we do have mainline kernels build for Ubuntu
[12:47] <hggdh> SimonK: see https://wiki.ubuntu.com/Kernel/MainlineBuilds
[12:49] <SimonK> Yes, I know which version is the last good (3.9.11) and the first bad (3.10-rc1) my problem now just comes down to bad internet-connection, git cloning from *.kernel.org is aborting every time i tried so far
[18:02] <TheLordOfTime> anyone able to tell me what happens if an SRU goes to verification-failed ?
[18:06] <hggdh> TheLordOfTime: the package should be removed from the -proposed pocket, and the bug should be put back into triaged
[18:06] <TheLordOfTime> hggdh: should i let sponsors do those changes, or can I bump it back to Triaged myself?
[18:06] <TheLordOfTime> because E: Bug 1206878 VERIFICATIONFAILED because E: New Bug
[18:06] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Fix committed] https://launchpad.net/bugs/1206878
[18:07] <hggdh> TheLordOfTime: you can bump it back to triaged yourself; removal from the -proposed will have to be done by someone with archive authority
[18:08] <TheLordOfTime> hggdh: done, now, if I were to try and fix this, and actually fix the newly-introduced-bug from what's in 1.1.19-1ubuntu0.3, do I bump the version to -1ubuntu0.4, or...?
[18:08] <TheLordOfTime> (this is the first patch I've actually had fail o.O)
[18:10] <hggdh> good question... I think it would remain 0.3, but this might conflict with an already-uploaded source.
[18:11] <TheLordOfTime> so... i should wait until I can go poke someone, like bdmurray who actually sponsored the upload, to explain what to do in this case?
[18:11] <hggdh> yeah. Or -motu, or -devel, or -packaging
[18:11] <TheLordOfTime> -MOTU's been nonresponsive
[18:11] <TheLordOfTime> hence me asking here about the verification-failed thing
[18:11] <TheLordOfTime> -devel will be my next target probably.
[18:11] <TheLordOfTime> unless someone wakes up on the MOTUs
[18:11] <hggdh> yeah, I saw your comment in -servers
[18:12]  * hggdh goes afk for a bit
[18:21] <bdmurray> -1ubuntu0.4 because the previous version of the package already existed in the archive
[18:21] <bdmurray> TheLordOfTime:, hggdh ^^
[18:22] <TheLordOfTime> bdmurray: so, I have the -1ubuntu0.3 package I pulled from proposed with dget, do i just add code modifications to that, add a new changelog entry for -1ubuntu0.4, and attach another debdiff, or do i start from -1ubuntu0.2, do changes, and then new changelog -1ubuntu0.4 ?
[18:23] <TheLordOfTime> basically, which package do I base the updated debdiff from.
[18:24] <bdmurray> -1ubuntu0.3
[18:25] <TheLordOfTime> okay, so work off what's already in proposed, fix the newly-introduced-bug, test, and then attach the debdiff...
[18:25] <TheLordOfTime> cool.
[18:25] <TheLordOfTime> (this was the first patch that has been for nginx that verification-failed o.O)
[18:25] <TheLordOfTime> (at least, that i've worked on)
[18:27] <hggdh> bdmurray: yeah, I wondered about an already-uploaded debdiff. So the process is base on the failed fix, and add the fix's fix
[18:31] <TheLordOfTime> bdmurray: for -1ubuntu0.4, though, do I also need to put in (closes LP: #bugnumber) that was referenced in -1ubuntu0.3 ?
[18:32] <bdmurray> TheLordOfTime: yes
[18:32] <TheLordOfTime> ok
[19:58] <TheLordOfTime> bdmurray: if you're not busy, can you perhaps guide me to a resolution of a bug issue?  I'm stuck between Invalid/Wishlist and actually poking someone in a position to make a decisive answer on the bug, and that plus the emails I"m getting about it are driving me to the point of telling everyone to die in a fire... o.o
[20:00] <bdmurray> TheLordOfTime: I'm not terribly involved in anything at the moment
[20:00] <TheLordOfTime> hggdh: you know the bug, i briefly discussed it here
[20:00] <TheLordOfTime> bdmurray: okay, one moment
[20:00] <TheLordOfTime> (btw, i'll need you to also sponsor a new debdiff for 1206878, that fixes the issues)
[20:00] <TheLordOfTime> bdmurray: this is the one driving me insane: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1170586
[20:00] <ubot2> Launchpad bug 1170586 in nginx (Ubuntu) "Naxsi package lacking Stub Status" [Undecided,Incomplete]
[20:01] <TheLordOfTime> bdmurray: it's stuck between Invalid/Wishlist (because although the code for that module exists, its rules file never included it)...
[20:01] <TheLordOfTime> and trying to figure out whether there's any way to get an approved change to the package to build the module's code, as it exists in the 1.1.19 source
[20:02] <TheLordOfTime> quantal and later all have the module's code compiled in the rules
[20:02] <TheLordOfTime> as it stands i'm leaving it Incomplete/Undecided until someone more... senior... can make a decision on how to proceed
[20:03] <TheLordOfTime> the whole initial issue was based on research the OP found that pointed at 1.2.1 (on Debian's wiki page)
[20:03] <TheLordOfTime> comment 4, i narrowed the criterion for the issue to be specific to the package, and not what debian's saying, but nginx's debian maintainers can't give me a clear answer
[20:03] <TheLordOfTime> so... this is now in the point where someone wants the thing, but activating it isn't SRU worthy
[20:04] <TheLordOfTime> and I don't see a backport being relevant in this case either because they want something that wasn't activated in the rules, but is actually in the source code.
[20:04] <TheLordOfTime> so... i'm stuck :/
[20:06] <TheLordOfTime> bdmurray: hggdh: anyone else: i welcome any guidance on how to tackle this to get everyone off my case about this... o.o
[20:10] <bdmurray> TheLordOfTime: everyone?  I see only one person affected by it.
[20:11] <TheLordOfTime> bdmurray: direct emails to me are causing the stress
[20:11] <TheLordOfTime> not on the bug
[20:11] <TheLordOfTime> either way, the bug is stuck in triager limbo until someone can figure it out
[20:11] <TheLordOfTime> on the one hand, activating the module is as simple as one line of code, on the other, doing that wouldn't fit into SRU or backport
[20:12] <TheLordOfTime> so... kinda stuck
[20:12] <TheLordOfTime> (part of me wants to Invalid that bug but... i'm in too high a stress level to do so sanely)
[20:17] <TheLordOfTime> bdmurray: on a more sane, not-as-stressful note, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1206878 has a new debdiff ready for sponsoring
[20:17] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Triaged]
[20:17] <TheLordOfTime> that apparently fixes the issue introduced in 1.1.19-1ubuntu0.3 (that was in -proposed)
[20:18] <TheLordOfTime> at least, from my testing with the testcases specified, it works as expected, and doesn't trigger installation or purge errors
[20:18] <bdmurray> I'd prefer no to sponsor that since I'll may be the SRU team member reviewing it.
[20:18] <bdmurray> Do you know what the patch for the other bug would look like?
[20:18] <TheLordOfTime> okay, i'll have to go find a sponsor then...
[20:19] <TheLordOfTime> bdmurray: you mean the one that's driving me to wanting to tell people to burn?
[20:19] <TheLordOfTime> bdmurray: i can probably slap up an example patch in a few minutes
[20:19] <TheLordOfTime> but for all intents and purposes... Bug 1206878 is a much higher priority than 1170586
[20:19] <ubot2> Launchpad bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Triaged] https://launchpad.net/bugs/1206878
[20:19] <TheLordOfTime> because config removal on a non-common-files purge is just bad.
[20:25] <TheLordOfTime> bdmurray: a diff for LP Bug 1170586 would look something along the lines of this: http://paste.ubuntu.com/6189724/
[20:25] <ubot2> Launchpad bug 1170586 in nginx (Ubuntu) "Naxsi package lacking Stub Status" [Undecided,Incomplete] https://launchpad.net/bugs/1170586
[20:25] <TheLordOfTime> (note because of convenience, I built that off of the -1ubuntu0.4 package I uploaded a debdiff for which fixes 1206878)
[20:26] <TheLordOfTime> note i tend to testbuild before I submit a debdiff...
[20:26] <TheLordOfTime> so unless someone's actually going to approve adding in that line to build the module, i'm not even going to test-build
[20:26] <TheLordOfTime> (although in theory it should build)
[20:27] <bdmurray> and I think that fits in this part of the "When" for SRUs
[20:27] <bdmurray> Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
[20:28] <TheLordOfTime> bdmurray: then, if i were to upload a debdiff for that and propose it for SRU under that criterion...
[20:28] <bdmurray> but I'm pretty sure I'm still the new guy on that team
[20:28] <TheLordOfTime> then perhaps someone would look at it?
[20:28] <TheLordOfTime> ehh, where are the SRU team anyways
[20:29] <TheLordOfTime> or, rather, would you mind poking them and seeing what they say :P
[20:29]  * TheLordOfTime yawns
[20:29] <TheLordOfTime> i need to go beat my head against the wall for a bit
[20:29] <TheLordOfTime> but the good news is that annoying bug that removes a user's configs when nginx-light or nginx-full or nginx-naxsi or nginx-extras is purged is (hopefully) in the queue to fix it
[20:30] <TheLordOfTime> bdmurray: last question, do i leave the verification-failed tag on 1206878 since i uploaded a new debdiff, and wait for someone from sponsors and SRU team to take a look?
[20:32] <bdmurray> TheLordOfTime: yes, because we don't want it showing up as verified on the pending sru report
[20:35] <TheLordOfTime> okay, done.  if sponsors need to be resubscribed, can you do that for me, bdmurray?  i'm going to go take a warm shower to try and calm down... for some reason that's relaxing... *shrugs*