[00:02] <geser> shadeslayer: don't forget to close your bug in your changelog entry the next time
[00:02] <shadeslayer> geser: i have to close my own bug in the changelog? 0_o
[00:02] <shadeslayer> i didnt know that
[00:02] <geser> yes please, else they stay open
[00:03] <shadeslayer> yeah, but i would have closed it manually :D
[00:03] <shadeslayer> but either way, ill remember this
[00:03] <shadeslayer> geser: thanks :D
[00:03] <geser> of course you can close them after your debdiff got sponsored through the web ui but it's easier to do through the changelog and one doesn't forget it
[00:06] <Laney> and better, because then the bug tells you in which version it was fixed
[00:06] <shadeslayer> right
[00:08] <geser> and one also has a reference to a previous merge bug (if a need arises in the future to understand some changes and why they kept merged)
[00:08] <Laney> haha
[00:08] <Laney> see, many reasons!
[00:08] <geser> as the merge bug might have some additional info
[00:10] <shadeslayer> any idea where cowbuilder stores generated debs? :P
[00:11] <geser> and from a DMB point-of-view: when looking at the sponsored packages from an applicant, the linking to the sponsoring bug makes it easy to check how it got handled
[00:16] <geser> shadeslayer: try /var/cache/pbuilder/result/ (if you don't use a script that sets a different directory)
[00:16] <shadeslayer> geser: its not there, thats why im asking
[00:16] <shadeslayer> which i find very odd
[00:19] <geser> does your ~/.pbuilderrc specify BUILDRESULT?
[00:19] <shadeslayer> nope
[00:19] <geser> I've never used cowbuilder, so I'm mere guessing
[00:19] <geser> :(
[00:19] <Laney> are you using pbuilder-dist?
[00:20] <shadeslayer> nope, just simple cowbuilder
[00:21] <geser> almost last idea: check the value of BUILDRESULT in /etc/pbuilderrc
[00:21] <geser> and if that doesn't help: check the source
[00:22] <shadeslayer> BUILDRESULT=/var/cache/pbuilder/result/
[00:22] <shadeslayer> well.. thats ok, it built fine
[00:23] <geser> and the build succeeded?
[00:23] <Laney> is there a cowbuilderrc?
[00:23] <shadeslayer> geser: yes
[00:23] <shadeslayer> Laney: no
[00:24] <Laney> i suggest you check the manpage
[00:24] <Laney> and if that fails then the source
[00:24] <shadeslayer> i did... nothing there :p
[00:24] <geser> Laney: http://manpages.ubuntu.com/manpages/maverick/en/man8/cowbuilder.8.html
[00:25] <shadeslayer> i wonder if its because i run sudo -E pdebuild
[00:25] <geser> mentions only the pbuilder configuration files, nothing cowbuilder specific
[00:25] <geser> shadeslayer: yep, pdebuild != pbuilder
[00:25] <geser> slight difference
[00:25] <geser> check .. for the debs
[00:25] <shadeslayer> geser: not there as well
[00:26] <geser> damn
[00:27] <geser> ok, the pdebuild manpages mentions /var/cache/pbuilder/result
[00:27] <geser> then you have to dig through the source where your debs got put
[05:52] <micahg> SpamapS: what Ubuntu version are you on?
[05:55] <micahg> anyone here that understands scons?
[07:32] <AnAnt> Hello
[07:38] <shadeslayer> ho
[07:39] <shadeslayer> err... hi
=== yofel_ is now known as yofel
[11:25] <ari-tczew> please open task on maverick and lucid in bug 617614
[11:25] <ubottu> Launchpad bug 617614 in gwget2 (Ubuntu) "epiphany-extension-gwget cannot be installed: requires 2.29 <= epiphany-browser < 2.30" [Undecided,In progress] https://launchpad.net/bugs/617614
[11:29] <Laney> ok
[11:29] <Laney> there yo ugo
[11:35] <ari-tczew> thanks Laney
=== IVBela1 is now known as IVBela
[13:44] <nthykier> Hi, I got a package (libsysactivity) that FTBFS on Ubuntu due the Autobuilders using a 2.6.24 kernel and one of the tests needs a 2.6.25 (or newer) - is there a way to get it built on a machine with a newer kernel or should I patch the package to skip the particular test?
[13:54] <tumbleweed> nthykier: I think the best solution is to patch out the test
[13:58] <bilalakhtar> hi tumbleweed
[13:59] <bilalakhtar> tumbleweed: looking at the nginx issue, Why is the lintian error being discussed now? Why wasn't it discussed when it was added?
[13:59] <bilalakhtar> tumbleweed: BTW, adding the HTML files is not important
[13:59] <bilalakhtar> tumbleweed: Its just an added convenience
[14:00] <bilalakhtar> tumbleweed: and, there's no need to run checks, because nginx has /var/www as its root by default
[14:00] <bilalakhtar> unlike apache ^^
[14:00] <tumbleweed> bilalakhtar: people make mistakes
[14:00] <tumbleweed> (and are lazy)
[14:00] <tumbleweed> but it's easier to get sponsorees to do the right thing :)
[14:01] <bilalakhtar> tumbleweed: yup, it appears the previous uploader has taken up the issue
[14:01] <bilalakhtar> tumbleweed: and he is ready to get it fixed
[14:01] <tumbleweed> bilalakhtar: I disagree re the checks. /var/www is an area that belongs to the sysadmin, we shouldn't be messing with their things in there
[14:02] <bilalakhtar> tumbleweed: but see, nginx is a server of its own and not an add-on
[14:02] <bilalakhtar> tumbleweed: it conflicts with apache and lighttpd
[14:02] <tumbleweed> bilalakhtar: so, as a sysadmin, you installed nginx when you deployed your machine
[14:02] <tumbleweed> now you upgrade to a new version of ubuntu
[14:02] <tumbleweed> and suddenly files appear in your /var/www
[14:03] <tumbleweed> (new files, that you didn't expect)
[14:03] <bilalakhtar> tumbleweed: should we do what debian is doing?
[14:03] <tumbleweed> you mean not installing them?
[14:03] <bilalakhtar> yes ^^
[14:03] <bilalakhtar> they are an added convenience
[14:03] <bilalakhtar> and
[14:03] <tumbleweed> yes, that's the easy solution
[14:03] <bilalakhtar> it appears that no bug was filed to have them in there
[14:03] <bilalakhtar> in lp ^^
[14:04] <tumbleweed> yeah, fair enough to remove them then
[14:04] <bilalakhtar> then the only change from debian would be the ufw profile
[14:04] <bilalakhtar> its always better to clean up packages when merging
[14:05] <tumbleweed> agreed, we often end up with cruft
[14:05] <tumbleweed> bonus points if you look at any bugs in lp with patches :)
[14:06] <bilalakhtar> BTW, the html file addition was done way back in karmic
[14:06] <bilalakhtar> it skipped lucid
[14:06] <bilalakhtar> and
[14:06] <bilalakhtar> was detected in maverick
[14:06] <bilalakhtar> RoAkSoAx was the one who uploaded
[14:06] <bilalakhtar> RoAkSoAx: ping
[14:07] <tumbleweed> the curse/advantage of group maintainance - every time we touch a package, a different person works on it.
[14:07] <bilalakhtar> Its somewhat better
[14:07] <bilalakhtar> In debian, NMUs take a long time to get sponsored
[14:07] <bilalakhtar> here, almost every upload is an NMU
[14:07] <tumbleweed> helps if you are a DD :)
[14:08] <bilalakhtar> tumbleweed: are you a DD ?
[14:08] <tumbleweed> bilalakhtar: no, I need someone to want to advocate me
[14:08] <bilalakhtar> tumbleweed: I have 6 uploads in debian pending sponsorship, of which 5 are new packages and 1 NMU
[14:09] <bilalakhtar> I am hunting down debian IRC channels and asking people to sponsor that NMU which is 2 months old now. But, most of them tell me to contact maintainer, who has been unresponsive
[14:10] <tumbleweed> yup, unresponsive maintainers are a pain
[14:14] <bilalakhtar> tumbleweed: dammit, a confusing, two-way bug #547267
[14:14] <ubottu> Launchpad bug 547267 in nginx (Ubuntu) "nginx should not install into /var/www/nginx-default (Debian policy)" [High,In progress] https://launchpad.net/bugs/547267
[14:16] <tumbleweed> there you go, you weren't th efirst to run into this
[14:16] <bilalakhtar> yup
[14:16] <bilalakhtar> and, RoAkSoAx has said that he forgot to add the reference to the bug
[14:16] <bilalakhtar> earlier, I mentioned that there was no bug
[14:16] <bilalakhtar> there is this one
[14:18] <vish> ScottK: tumbleweed: hey, [i think]found out why the lp janitor switches the name and email fields..  it seems to do that when the name has a . [dot], for some reason it doesnt like dots ;)
[14:19] <vish> tumbleweed: similar happened in Bug #532056
[14:19] <ubottu> Launchpad bug 532056 in bzflag (Debian) "Inappropriately appears in Ubuntu Software Center's "Graphics" > "3D" section" [Unknown,New] https://launchpad.net/bugs/532056
[14:19] <tumbleweed> vish: aha, file a bug :)
[14:20]  * tumbleweed has acutally just uploaded a (papercut) sponsorship with a .
[14:20] <vish> tumbleweed: yeah, should do that , bug in which...?  :)
[14:20] <bilalakhtar> vish: file a bug in malone
[14:20] <vish> bilalakhtar: malone!
[14:20] <vish> hrm..
[14:21] <bilalakhtar> vish: yes, the janitor is a part of malone
[14:21] <bilalakhtar> vish: https://edge.launchpad.net/malone
[14:21] <tumbleweed> vish: indeed: https://edge.launchpad.net/ubuntu/+source/acm/5.0-27ubuntu2
[14:21] <tumbleweed> bilalakhtar: I don't think this is malone, the problem is in th echanges file processing. soyuz?
[14:22] <bilalakhtar> tumbleweed: vish: Is the problem here as well? Aha
[14:22] <bilalakhtar> Go file in soyuz, vish
[14:23] <vish> tumbleweed: yeah, always wondered why it kept doing that.. finally found someone who suffers the same fate! ;p
[14:24] <bilalakhtar> vish: Yes, While looking at your uploads I thought why don't you follow the debian changelog policy!
[14:24] <vish> bilalakhtar: pff, policies ;p
[14:24] <bilalakhtar> vish: for adding changelog entries, I suppose you use dch
[14:25] <tumbleweed> bilalakhtar: the changelogs are correct, it's lp which has th ewrong data
[14:26] <bilalakhtar> tumbleweed: I know that
[14:27] <bilalakhtar> so soyuz grabs the latest changelog entry and tries to validate its e-mail address. Due to a dot in the name, it thinks the opposite and interprets the changelog in the wrong manner. malone just copies the data provided by soyuz
[15:02] <nthykier> tumbleweed: okay - TY
[15:49] <vish> DktrKranz: hi , does zipper work on Ubuntu or is it meant for use only after installing GNUstep?
[15:49]  * vish noticed DktrKranz made the last upload and might have some info.. :)
[15:59] <vish> DktrKranz: Bug #613301 was filed as its description seemed confusing for the user...  could you comment on it? thanks.
[16:00] <ubottu> Launchpad bug 613301 in zipper.app (Ubuntu) "Zipper description is confusing" [Undecided,New] https://launchpad.net/bugs/613301
[16:05] <DktrKranz> vish: well, it's an app designed for GNUstep, so it requires at least base packages (e.g. gnustep-base). Perhaps description can be improved, but it should be done Debian side first (and there's currently an ongoing transition there)
[16:09] <vish> DktrKranz: ah yeah, maybe for that info could be included .  could you comment on the bug?
[16:10] <vish> DktrKranz: maybe we can ask the reporter to forward the bug to debian :)
[16:34] <DktrKranz> vish: done
[16:48] <ScottK> Rhonda: I did, but to provide an endorsement.  it seems odd to me people doing random edits on people's wiki pages, but maybe that's just me.
[17:21] <xelister> I fixed a 1 year old damn bug in krusader
[17:22] <xelister> how to build it now? I got sources via apt-get source + apt-get build-dep
[17:23] <geser> debuild
[17:53] <xelister> geser: ok.. now what?
[17:53] <xelister> Successfully signed dsc and changes files
[17:54] <xelister> but I dont see any .deb file
[17:56] <xelister> the modified by me sources seem to build, debuild seem to execute,  now how to install the builded package to test if program works correctly?
[18:01] <shadeslayer> xelister: cd ..
[18:02] <shadeslayer> and then : sudo dpkg -i foo.deb
[18:11] <xelister> shadeslayer: how to make a diff to be attached as .patch to LP bug report for the bug I fixed?
[18:11] <shadeslayer> !debdiff | xelister
[18:11] <ubottu> xelister: A simple way to patch Debian/Ubuntu packages is to attach a debdiff to a bug report, or send it to the team which handles the package. Learn more about it from https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff
[19:21] <vish> tumbleweed: hmm , i think there is a white space in the changelog. :s the second entry, probably why it was failing?
[20:29] <micahg> jdong_: ping?
[20:32] <Rhonda> ScottK: Yes, it's strange to some degree. Though, I don't see the big deal when turning channel names into links. :)
[20:37] <micahg> Rhonda: are you familiar with scons?
[20:38] <Rhonda> Not really. I gave it once a try wether switching from autotools to it for wesnoth would make a sense, but I sticked with autotools. Why do you ask?
[20:38] <micahg> Rhonda: having trouble getting mongodb to make a source upload
=== JanC_ is now known as JanC
[22:08] <yofel> does anyone know if there's a reason why there are no -dbgsym packages for -backports?
[22:09] <micahg> yofel: maybe because they're not officially supported
[22:09] <yofel> was looking through old bugs and found bug 316227
[22:09] <ubottu> Launchpad bug 316227 in Ubuntu "devscripts-dbgsym unistallable in intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/316227
[22:10] <micahg> yofel: also intrepid is EOL
[22:11] <yofel> yep, but NO release has dbgsyms for -backports so..
[22:12] <yofel> you can reproduce that failure with any package from lucid-backports
[22:12] <ebroder> yofel: My understanding is that extracting the dbgsym packages is a giant hack, and it's probably "just" that nobody has implemented that hack for anything but the main archive
[22:12] <ebroder> (I have no idea how much resistance there would be on the archive admin/buildd admin/etc admin side to adding functionality for extracting backports dbgsym packages)
[22:13] <yofel> erm, debug symbol extraction is on for lucid lucid-updates lucid-proposed and lucid-security, only -backports doesn't have them
[22:13] <ebroder> yofel: Exactly. Someone with the right powers cared enough to set it up for -updates, -proposed, and -security. Nobody with the right powers has cared enough to set it up for -backports
[22:19] <yofel> any idea where I should send that bug to then? soyuz?
[22:21]  * micahg thought -backports weren't officially supported
[22:21] <Rhonda> yofel: There is wesnoth-1.8-dbg in karmic-backports. Or is that something completely different?
[22:22] <micahg> Rhonda: different -dbgsym
[22:22] <yofel> Rhonda: that is a packaged -dbg package, we are talking about -dbgsym on ddebs.ubuntu.com
[22:22] <yofel> those are automatically generated for every package
[22:22] <yofel> (by the buildds)
[22:23] <Rhonda> ah
[22:25] <yofel> micahg: well, I think too that -backports is unsupported so I'll close the bug
[22:26] <ebroder> yofel: backports is supported, just not through the same mechanisms as the normal archive. It's on a volunteer basis, like universe
[22:29] <yofel> well, I'll just leave the bug as it is until tomorrow, if anyone knows who I should talk to about or where I should move that bug ping me
[22:30] <ebroder> yofel: Sorry - I wasn't clear. Backports are supported, but anything related to intrepid is unsupported. So that bug can be closed. It's a separate bug that backports aren't generating dbgsym packages
[22:31] <yofel> ok, that makes sense, closing
=== easter_egg|off is now known as easter_egg