[10:33] <tumbleweed> Laney: Think I've got a coherent complete upload history set. Ready to take it?
[14:30] <tumbleweed> meh, summer is here. It's still and hot :/
[14:30] <tumbleweed> highvoltage: getting well baked?
[14:46] <highvoltage> tumbleweed: staying mostly inside for the moment :)
[14:47] <tumbleweed> the curse of being bound to a computer...
[14:54] <highvoltage> I have to be careful, I get subnurnt really easy. (even in london in the winter once)
[15:03] <tumbleweed> heh
[20:31] <broder> ScottK, tumbleweed, micahg, Laney: i'm working on revamping the backports docs to try and do a better job of delineating "end-user" and "developer" targeted docs. what i have so far is at http://bit.ly/rNEOWc
[20:32] <broder> i'd like to split the docs between help.u.c (end-user) and wiki.u.c (dev)
[20:32] <broder> interested in your thoughts. also interested in how to avoid wall-of-text syndrome for the stuff i have drafted
[20:34] <ScottK> Avoiding wall of text isn't something I'm very good at.
[20:35] <ScottK> broder: Scanned it and I think it's good.  My only comment is to make clear that "developer" is anyone that wants to build/test a backport.
[20:35] <broder> i guess i'm hoping it will balance well as a reference against requestbackport's less verbose output
[20:36] <broder> ah, good catch
[20:36] <ScottK> It might even be better to call it tester instead of developer.  not sure.
[20:36] <broder> i don't think i actually use the word developer in the docs, just my title, which was more placeholder
[20:36] <ScottK> OK.
[20:37] <broder> but i should probably make it clear in the text
[20:37] <ScottK> There are really five states: Requester, Builder, Tester, Approver, User
[20:37] <ScottK> Approver is the only one that requires an ubuntu-dev type person.
[20:38] <ScottK> Builder is the only one that may need some technical/packaging knowledge.
[20:38]  * broder nods
[20:39] <ScottK> I think having information for requesting/building/testing as distinct things would be good as people can sometimes do one of those things and not the others.
[20:39] <ScottK> Going from Requesting -> Building/Testing would be a good bridge from h.u.c to w.u.c.
[20:40] <broder> i'm not sure we should encourage that, because you risk setting the expectation that requested backports will eventually get handled without any additional input from the requester, and that just doesn't happen in practice
[20:41] <ScottK> I think we should say that.
[20:41] <ScottK> You can file a request, but ...
[20:41] <broder> fiar
[20:41] <ScottK> There was a time when there were people who would test backports they didn't request.
[20:41] <ScottK> It might happen again if we get things ramped up a bit.
[20:42] <broder> yeah, and i still want to try to automate some of the testing, which will probably also help
[20:42] <broder> ok. i'll play with it some and see if i can tease those roles apart more
[20:42] <ScottK> Great
[21:22] <virusuy> hi everyone
[21:22] <virusuy> i'm trying to package a simple bash script
[21:23] <virusuy> and i need to modify $PATH
[21:23] <virusuy> where should i declare that in the package ?
[21:26] <tumbleweed> virusuy: that sounds wrong. Why do you need to modify $PATH?
[21:27] <CarlFK> once a .deb is on a stable repo (or maybe beta too) it won't be updated: a newer version may come out, but it will have a new file name.  right ?
[21:27] <tumbleweed> CarlFK: yes, but why are you asking?
[21:27] <virusuy> tumbleweed: but if i don't modify $PATH, how can i call the script without using the full path ?
[21:27] <CarlFK> trying to figure out if I should bother telling squid to expire debs
[21:29] <tumbleweed> virusuy: what are you trying to do?
[21:29] <CarlFK> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/squid-deb-proxy/oneiric/view/head:/squid-deb-proxy.conf#L52  refresh_pattern deb$   129600 100% 129600
[21:29] <CarlFK> 129600 min is 90 days.
[21:29] <CarlFK> made me wonder where 90 days came from
[21:30] <virusuy> tumbleweed: i have a bash script
[21:31] <tumbleweed> virusuy: so, put it in /usr/bin, so it'll be on people's paths
[21:31] <virusuy> tumbleweed: ok then
[21:51] <l3on> tumbleweed, around ? :)
[21:51] <l3on> I've solved this ftbfs:
[21:51] <l3on> https://launchpad.net/ubuntu/+source/clearsilver/0.10.5-1.2/+build/2930410
[21:51] <l3on> What's next step?... file a bug?
[21:53] <tumbleweed> l3on: yup, https://wiki.ubuntu.com/SponsorshipProcess
[21:53] <l3on> tumbleweed, well.. which info I have to report?
[21:53] <l3on> I mean.. I patched a source file
[21:53] <jtaylor> l3on: idealy file a bug vs upstream and debian
[21:54] <jtaylor> format-security issues are probably no reason to diverge from debian at this point
[21:54] <l3on> patch is:
[21:54] <l3on> -  cgi_error (cgi, s);
[21:54] <l3on> +  cgi_error (cgi, "%s", s);
[21:54] <l3on> directly to upstream ?
[21:55] <jtaylor> if upstream is affected yes
[21:55] <jtaylor> here an example bug I filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646350
[21:56] <jtaylor> In your case you would add the aptch too
[21:56] <l3on> ok jtaylor I'll do it :)
[21:57] <l3on> and in Ubuntu jtaylor I have to file a "merge bug" ?
[21:57] <jtaylor> ubuntu will get the fix automatically when debian fixes it
[21:58] <jtaylor> is there any info if this flag will stay enabled for precise?
[21:58] <l3on> I don't know how I can check it
[21:59] <l3on> I read this: http://en.wikipedia.org/wiki/Format_string_vulnerabilities
[21:59] <l3on> and applied patch
[21:59] <tumbleweed> jtaylor: I would assume it won't. Last I heard, we were waiting for the first rebuild to see how bad the fallout was
[21:59] <tumbleweed> but the rebuild won't happen until feature freeze
[21:59] <jtaylor> ok thx
[22:00] <jtaylor> l3on: in this case we will want to wait a bit before fixing the package in ubuntu
[22:00] <l3on> Ok, I'm going to file only bug debian.
[22:00] <jtaylor> carrying difference to debian is a maintenance overhead which might not be necessary in this case yet
[22:00] <l3on> Ok, I got it :)
[22:00] <jtaylor> debian does not enable that flag for the whole archive
[22:02] <jtaylor> but thanks for looking at it, your help will be much appreciated when ubuntu decides to keep the flag
[22:25] <l3on> ok bug filed in debian e upstream
[22:25] <l3on> debian 649322
[22:26] <tumbleweed> l3on: whoops, that doesn't have a subject
[22:26] <l3on> damn ...
[22:26] <jtaylor> no problam you can fix that easily
[22:26] <jtaylor> also you should add tags
[22:27] <jtaylor> it has a patch so the patch tag should be added, also these issues are tracked in so called usertags, "hardening-format-security hardening" for user debian-qa@lists.debian.org
[22:28] <l3on> I'm reading how to do it
[22:30] <jtaylor> l3on: mail this to http://paste.ubuntu.com/743693/ control@bugs.debian.org
[22:32] <tumbleweed> if you have working mail on your machine, there's a handy tool called bts in devscripts, for things like that
[22:32] <l3on> thank you jtaylor .. I was still reading retitle command :P
[22:33] <l3on> ah wow .. nice, I'm looking at manpage
[22:35] <jtaylor> you should also keep how to reproduce it in debian in the bug
[22:35] <jtaylor> in this case it is by enable the hardened build
[22:36] <l3on> The export+include ? :)
[22:36] <l3on> Ah ok, I'm making note about this ...
[22:36] <jtaylor> yes just helps to quickly test it
[22:37] <jtaylor> you quited the d-d-a mail it is in there, but adding cliffnotes is always nice
[22:38] <l3on> ok :)
[22:38] <jtaylor> don't forget to subscribe to the bug
[22:39] <jtaylor> the bts will not do that for you even when you file it
[22:40] <l3on> and in Ubuntu how people will know that there is a pending patch in Debian ?
[22:41] <jtaylor> during rebuilds bugs are filed in ubuntu
[22:41] <jtaylor> which you link and tag with the debian bugs
[22:41] <jtaylor> also when fixing issues you always look in debian if there is a fix already
[22:42] <l3on> Ok,thanks for this :)
[22:50] <l3on> Mmm.. I sent mail at control .. but nothing changes...
[22:50] <jtaylor> it takes a while
[22:51] <l3on> oki :)
[22:51] <jtaylor> the bts is not very fast, some parts are only updated every 15 minutes
[22:51] <l3on> this problem will be reported in the same way?
[22:51] <l3on> https://launchpadlibrarian.net/83733832/buildlog_ubuntu-precise-i386.libccscript3_1.1.7-1.1_FAILEDTOBUILD.txt.gz
[22:52] <jtaylor> yes looks like the same issue
[22:53] <jtaylor> before you file issues, check if it was already filed
[22:53] <jtaylor> I did a few of these a while back
[22:53] <jtaylor> also you should always check if debian is really affected
[22:54] <l3on> ok, I checked and it filed under debian 643417
[23:00] <l3on> another question :)
[23:00] <l3on> Why some builds seem to fail whet apply patch ?
[23:01] <l3on> and patch comes from debian
[23:01] <l3on> this for example:
[23:01] <l3on> https://launchpadlibrarian.net/85415333/buildlog_ubuntu-precise-i386.magics%2B%2B_2.12.9-5_FAILEDTOBUILD.txt.gz
[23:01] <jtaylor> that is a special case
[23:02] <jtaylor> the buildtool needs patching so it correctly handles the as-needed flag
[23:02] <jtaylor> because libtool sucks ;)
[23:02] <l3on> lol
[23:02] <jtaylor> so this package had a patch included in the it
[23:02] <jtaylor> but the underlying libtool was updated so the patch does not apply anymore
[23:02] <jtaylor> dh-autoreconf has gained the ability to do the patching now
[23:03] <jtaylor> which is more robust as it only needs one package to be up to date isntead of many
[23:03] <jtaylor> dh-autoreconf --as-needed
[23:09] <l3on> well.. I have to go.. thanks for all :)
[23:10] <l3on> bye