[00:02] <jtaylor> how do I proceed now. propose the branch for merge and let the sponsor subscribe sru or subscribe them myself?
[00:32] <nhandler> Thanks RainCT. Somehow, I don't think I'll have much trouble with this package based on the ML feedback, but I'll definitely keep you in mind when I am ready
[00:46] <micahg> jtaylor: propose the branch for merge and subscribe ubuntu-sponsors
[00:46] <micahg> jtaylor: oops, no need to subscribe when proposing a merge
[00:47] <micahg> jtaylor: I'll be piloting in a bit, so I can run this through if it's ready
[00:52] <jtaylor> micahg: merge proposed
[00:52] <jtaylor> binary debdiff is just egg-file -> egg-folder with all the setuptools stuff in it
[00:56] <micahg> jtaylor: thanks
[07:04] <dholbach> good morning
[09:50] <jtaylor> micahg: I can't reproduce that foolscap problem in chroot, natty and oneiric, anything special you did?
[10:08] <Laney> hwo can I view patches to a package in fedora? anything like the PTS?
[10:10]  * Laney found pkgs.fedoraproject.org
[10:11] <RAOF> Oh, is that useful?  I always trawl the git.
[10:13] <Laney> it got me to the git in the end
[11:34] <Laney> Rhonda: is it known that packages.d.o's file search is broken for experimental? http://packages.debian.org/search?suite=experimental&mode=exactfilename&searchon=contents&keywords=csharp should return results, for example
[11:40] <Rhonda> hmmm
[11:40] <Rhonda> huhm, http://packages.debian.org/experimental/all/mono-csharp-shell/filelist
[11:41] <Rhonda> That's there since a month, right …
[11:41] <Rhonda> Laney: Can you file a bug about that, please? against www.debian.org
[11:42] <Laney> sure
[11:42] <Rhonda> Thanks. Not much time now to investigate further.
[11:58] <wejaeger> Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
[12:46] <stlsaint> im getting this error when trying to upload changes file with dput: No host ppa:stlsaint/packagesources found in config
[12:48] <arand> stlsaint: Is this from debians dput (does not support normal ppa syntax)?
[12:54] <stlsaint> arand: yes i am on debian
[12:55] <arand> stlsaint: You can specify PPAs individually http://paste.debian.net/117487/
[12:55] <arand> Alternatively, port over the PPA argument magic from the ubuntu version into debian ;)
[12:56] <stlsaint> arand: is that the dput conf?
[12:56] <arand> stlsaint: ~/.dput.cf  yes
[12:57] <stlsaint> arand: aye gotcha
[12:58] <stlsaint> arand: is it suppose to be blank at first?
[12:58] <arand> stlsaint: yes, /etc/dput.cf is read initially ~/.dput.cf overrides/adds, I assume..
[13:01] <stlsaint> arand: so where you have ubuntu should i have debian?
[13:01] <stlsaint> arand: i tried running and it still gave same error
[13:02] <arand> stlsaint: I'm also on debian, your's should be very similar, just replacing ppa names (redeclipse ppa unstable, in my case)
[13:04] <stlsaint> arand: i changed everything but still same error, same as yours except i change the name and ppa on all three stanzas
[13:05] <arand> The title in [] is the one to use when dputting, eg, "dput ppa-unstable *.dsc In my case to upload to my ppa:arand/unstable"
[13:07] <stlsaint> arand: hrm one sec
[13:08] <stlsaint> arand: this is command im using: dput ppa:stlsaint/packagesources lxdm_0.3.0-0ubuntu5.1_i386.changes
[13:09] <arand> stlsaint: You want to replace the "ppa:stlsaint/packagesources" with whatever to named the entry for that ppa (in my case, e.g. just "resvn")
[13:12] <stlsaint> arand: so i have a ppa on lp name packagesources, that should go in place of where you have resvn?
[13:14] <arand> stlsaint: the thing within [] can be anything, but that is the name you will have to use when nivoking dput.
[13:14] <arand> Gotta run, sorry
[13:14] <stlsaint> here is the commadn i use:  dput ppa:stlsaint/packagesources lxdm_0.3.0-0ubuntu5.1_i386.changes
[13:14] <stlsaint> shucks
[13:33] <stlsaint> dang im slow
[13:33] <stlsaint> arand: i see what you were saying now
[13:34] <stlsaint> i fixed that but now im getting something about no signature on that file but signed the package at build
[13:35] <stlsaint> crap never mind on that either
[15:32] <mnemoc> hi, I want to push to a ppa a fixed version of a package, tp_smapi. Is there any easy trick (debuild -something?) to help the infrastrcture to notice the diff?
[15:33] <mnemoc> any docu related to this case?
[15:34] <mnemoc> wrong channel? :)
[16:00] <micahg> jtaylor: I built the package locally, could be I broke something, I'll push up to my SRU PPA to see if I get the same failure
[16:02] <jtaylor> micahg: wait I think I want to add a small change to the patch
[16:02] <jtaylor> the dependency on python-twisted is too strong, it only needs -core and -web
[16:03] <jtaylor> it just slipped in in the dh_python2 transition
[16:07] <jtaylor> or would that change also first have to be uploaded to debian? in this case its probably not worth it
[16:08] <micahg> jtaylor: changes must be made in the dev release first
[16:10] <jtaylor> then one can probably ignore it, it just installes a few extra packages
[16:11] <micahg> jtaylor: yeah, that's not worth fixing in an SRU
[16:11] <micahg> jtaylor: but Debian should get the fix if appropriate
[16:12] <jtaylor> yes going to commit it to the vcs soon
[16:46] <arand> stlsaint: Sorry for rushing off, you got it working?
[16:48] <stlsaint> arand: well the command went thru but there is still nothing in my ppa
[16:48] <stlsaint> arand: though it said upload was successful
[16:49] <arand> stlsaint: And the build queue is empty as well, and yo've received no confirmation by email?
[16:50] <arand> Hmm, yea it appears to be completely empty...
[16:52] <arand> stlsaint: The source (debiuld -S) is signed with one of the gpg keys that are specified on LP as well?
[16:54] <stlsaint> arand: yes
[16:56] <arand> Then I'm not quite sure, I think then you'd have followed the same procedure as I normally do, and unless LP is in flux currently, I don't know what the issue would be .. :/
[16:57] <stlsaint> arand: cool thanks
[17:11] <micahg> jtaylor: confirmed, I get the error on upgrading python-foolscap
[17:12] <jtaylor> I don't, what could be the cause? it upgrades in debian and a clean chroot and a oneiric vm
[17:12] <micahg> jtaylor: this is for the natty SRU
[17:12] <jtaylor> yes thats what I tried
[17:13] <jtaylor> also they are practially the same
[17:13] <micahg> no idea, I haven't come across this before
[17:14] <jtaylor> the only difference is a dropped breaks which was empty anyway
[17:14] <jtaylor> does the version in oneiric install an your natty machine?
[17:15]  * micahg can check
[17:16] <micahg> jtaylor: yep, that worked
[17:16] <jtaylor> oO
[17:24] <jtaylor> I don't get why it doesn't happen on my machine, but I guess I need to add a Break: python-foolscap (<< 0.6.1-3)
[17:30] <micahg> jtaylor: that version won't work for the SRU, I wonder what the difference is
[17:33] <jtaylor> lets see if I can get piuparts to run
[18:00] <jtaylor> friggn piuparts, worked once with the debian version and now it fails on the same file with some weird unrelated error ...
[18:11] <jtaylor> micahg: as I can't reproduce the problem can you try adding that to the control: http://paste.ubuntu.com/610697/
[18:11] <jtaylor> althout it should not be necessary ...
[18:26] <micahg> jtaylor: yep, in a bit, about to head out for lunch
[18:43] <evaluate> Hello.
[18:44] <evaluate> I was wondering if Bug 702316 is under review and if maybe there is anything else that I need to do for the patch to get applied.
[18:49] <micahg> evaluate: yeah, I have the patches, I just need to test build and upload
[18:49] <evaluate> micahg, cool.
[18:49] <broder> evaluate: you did everything right, the process has just been a little laggier than usual because of the recent release, UDS, etc.
[18:49] <micahg> evaluate: sorry, my piloting ran a little late, so I figured to wait until today to upload
[18:49] <micahg> but since I already looked at it, wanted to claim it
[18:51] <evaluate> micahg, would enabling the indicator need a patch too?
[18:52] <micahg> evaluate: hmm, technically, probably should be since it's 2 different things
[18:54] <evaluate> Thing is, I disabled it by default in the source package, since it generated a lot of problems for maverick/lucid, but I think it should work fine in natty, so it would be nice if it was enabled by default.
[18:55] <micahg> evaluate: right, and it seems that it was supposed to be enabled in the last upload but I don't think the merger noticed your source change
[18:58] <evaluate> ok, so what would be the right thing to do to have it enabled in this case?
[18:58] <evaluate> Should I submit another patch? Or edit the current patch?
[18:59] <micahg> evaluate: have a named patch to enable the indicator and a named patch to fix the crash
[18:59] <micahg> evaluate: if you want to fix it up, I can grab it over the weekend
[19:00] <evaluate> Can I leave the current patch as it is and submit another one for enabling the indicator, or do you want me to also rename the current one?
[19:00] <micahg> evaluate: I thought the current one enables it
[19:00] <micahg> all in one patch that is
[19:01] <evaluate> Ohh, yes it does.
[19:01] <evaluate> Forgot that I also had that change in there.
[19:01] <micahg> oh, it's set to auto, not yes, but I think with the build flag we're good
[19:02] <evaluate> Well, auto means that if the appindicator-0.1 package is present (which is set as a build-dep in ubuntu) it will default to yes.
[19:03] <evaluate> ok then, so can I leave the patch as it is?
[19:03] <micahg> evaluate: yeah, are you going to push these changes into Debian as well?
[19:05] <evaluate> Yes. I have sent the 1.3.13 version which includes these changes to my mentor, but it couldn't be uploaded due to some transitions going on in Debian and now I didn't bug him anymore about it since I want to roll out 1.4.0 soon anyway.
[19:06] <micahg> evaluate: k, I'll upload this to oneiric later today or over the weekend so we can get the SRU in
[19:07] <evaluate> Good. Thank you very much!
[19:07] <micahg> evaluate: thank you for your work!
[19:09] <micahg> evaluate: actually, I might move the enable indicator piece out since it's not part of the upstream patch, but I can do that locally
[19:10] <evaluate> Yeah, I enabled the indicator only in the 1.4 branch.
[19:19] <micahg> jtaylor: works now...
[19:19] <jtaylor> strange, it should not need that and why does the oneiric version work
[19:20] <micahg> jtaylor: no idea
[19:21] <micahg> jtaylor: if you want to have someone else test, I have the original in ppa:micahg/sru-test
[19:30] <jtaylor> ok from there I could reproduce it
[19:31] <micahg> jtaylor: cool :)
[19:31] <Quintasan> bdrung_: ping
[19:32] <micahg> jtaylor: so, do you want to discuss with some python gurus if the breaks/replaces is correct or if there's a better fix for this?
[19:32] <jtaylor> #debian-python says no replace needed, but I'll just check whats the difference to the package I built
[19:33] <micahg> jtaylor: k, well, you can show them the package in the PPA and the error and see if they change their minds :)
[19:43] <bdrung_> Quintasan: pong
[19:43] <Quintasan> bdrung_: sponsor-patch is broken I think
[19:44] <Quintasan> sponsor-patch --builder=pbuilder-dist 712534 --workdir kamoso
[19:44] <Quintasan> AssertionError: kamoso/kamoso_2.0-0ubuntu2.dsc does not exist.
[19:44] <Quintasan> ls kamoso/kamoso_2.0-0ubuntu2.dsc -> kamoso/kamoso_2.0-0ubuntu2.dsc
[19:44] <Quintasan> the file is there
[19:44] <bdrung_> Quintasan: that is fixed in trunk. can you file a bug report and add the needed stuff for a SRU?
[19:45] <Quintasan> bdrung_: well, I can, but later, uploading 24mb bug stacktrace now @_@
[19:45] <bdrung_> Quintasan: thanks
[19:47] <bdrung_> tumbleweed: we need a online test infrastructure for these kind of bugs ^
[19:58] <Quintasan> bdrung_: the version for SRU should be 0.123?
[19:58]  * Quintasan notes you might as well upload that to oneiric
[19:59] <bdrung_> Quintasan: 0.122.1
[20:07] <bdrung_> Quintasan: http://paste.ubuntu.com/610750/
[20:08] <Quintasan> oh
[20:17] <Quintasan> bdrung_: bug 785923
[20:17] <Quintasan> I think I'm doing it right
[20:18] <Quintasan> bdrung_: Are you going to upload a newer version to oneiric soon?
[20:19] <bdrung_> Quintasan: yes
[20:19] <Quintasan> cool
[20:28] <bdrung_> Quintasan: uploaded to proposed
[20:29] <Quintasan> oh wait..what? so fast
[20:29] <Quintasan> :D
[20:29] <bdrung_> Quintasan: in rare cases :)
[20:30] <Quintasan> :)
[20:36] <bdrung_> broder: re bug #785854 - what's the reason for the broken pipe?
[20:37] <tumbleweed> bdrung_: what was the issue you say we need testing for?
[20:37] <tumbleweed> oh that one
[20:37]  * tumbleweed sees the paste
[20:38] <bdrung_> tumbleweed: btw i am releasing 0.123
[20:38] <bdrung_> tumbleweed: i give a few seconds to veto
[20:39] <tumbleweed> cool
[20:47] <broder> bdrung_: because diff got to the end of its input? there are a bunch of programs that expect SIGPIPE, not EPIPE
[20:47] <broder> cjwatson walks through the basics at http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009-07-02-python-sigpipe.html
[20:48] <broder> because python changes the SIGPIPE handler, and signal handlers don't get reset on fork/exec, the program that expects SIGPIPE starts getting EPIPE instead, and gets confused
[20:51] <tumbleweed> meh, we probably need to work around that in a bunch of places (or wrap subprocess, or use this subprocess32 backport)
[20:52] <broder> tumbleweed: i may have a subprocess wrapper that resets a bunch of generally undesirable behavior
[20:52] <broder> i need to dig it up
[20:52] <bdrung_> but why doesn't it always fail?
[20:52] <tumbleweed> bdrung_: it'd only be an issue if the pipeline shuts down before the processes are done
[20:52] <tumbleweed> i.e. if we stop being interested in output
[20:53] <broder> bdrung_: there's some raciness involved. i don't remember the details
[20:54] <tumbleweed> I guess it also breaks subprocess' childern
[20:55] <broder> right, that would be what's happening here, i think
[20:56] <tumbleweed> yeah
[21:23] <jtaylor> micahg: not even break works for me when installing from a ppa, but conflicts seems to work. I'll try to understand that and then probably go over debian
[21:26] <jtaylor> (although its not affected, I don't know why)
[22:13] <shadeslayer> hi! i can't seem to be able to build avogadro with oneiric in a pbuilder, is there a problem with the gcc package ?
[22:14] <shadeslayer> http://paste.ubuntu.com/610811/ << error in pbuilder
[22:14] <broder> shadeslayer: update your pbuilder
[22:14] <shadeslayer> afaik it's updated, but i'll check again
[22:14] <shadeslayer> bleh ... outdated mirrir
[22:14] <shadeslayer> *mirror
[22:18] <shadeslayer> broder: didn't work
[22:18] <shadeslayer> same issue
[22:18] <broder> shadeslayer: all that error means is that the gcc packages you have installed don't match the version of the gcc packages in the archive
[22:19] <broder> although it could be a publishing skew issue of some sort
[22:19] <shadeslayer> okay, but i switched to the main archives
[22:19] <broder> i know doko was in the middle of updating gcc for something, so maybe just wait a day
[22:19] <shadeslayer> yeah looks like it
[22:55] <micahg> jtaylor: you should use breaks w/replaces
[22:55] <jtaylor> micahg: does not work
[22:56] <jtaylor> micahg: only conflicts
[22:56] <jtaylor> micahg: debian work fine, Im slowly thinking this is a dpkg bug
[22:56] <jtaylor> tries to remove a file from the new package instead of the old
[22:56] <micahg> jtaylor: breaks/replaces works for me with the package I built locally upgrading from the one in the repo
[22:58] <jtaylor> micahg: not for me, its kind of a heisenbug, as earlier I could not reproduce it to begin with
[23:00] <jtaylor> http://paste.ubuntu.com/610839/
[23:02] <micahg> jtaylor: weird, upgrading from natty to oneiric version was fine, upgrading to version in my PPA + breaks/replaces was fine for me
[23:02] <jtaylor> yes my oneiric vm worked fine too
[23:03] <jtaylor> and according to debian policy it should work without the breaks too
[23:03] <jtaylor> (which it does in debian)
[23:28] <micahg> bdrung_: any reason for me not to upload the eclipse FTBFS fix over the weekend?
[23:38] <bdrung_> micahg: no
[23:39] <bdrung_> micahg: can you check if 3.6.2 is affected too? (master-3.6 git branch)
[23:39] <micahg> bdrung_: k, thanks
[23:39] <bdrung_> i have only amd64
[23:39] <bdrung_> (and there it builds)
[23:42] <micahg> bdrung_: idk if I'll be able to get to it, but I'll see