[15:14] <soee> is it only me or you also have feeling that ingame performance with latest nvidia driver is better ?
[16:09] <mamarley> soee: 375.26?  I don't really play games that much, so I'm not sure.  I did check to see if Sauerbraten and Xonotic ran, but my GTX970 can already run those at 60fps, so…


[00:06] <ScottK> Laney: OK.  I'm game.  Accepted.  Please keep an eye on it and make sure it builds.
[01:18] <porthose> ScottK, ping bug #460779 #460720, if you need anything else leave a comment on the bug, going to bed :)
[01:28] <ScottK> porthose|afk: Nice.  Thanks.
[01:28] <ScottK> .away
[01:45] <hedkandi> hello anyone at home?
[01:45] <hedkandi> I'm just putting a package together for revu
[01:45] <hedkandi> and so do I need to write an installation bit in the makefile?
[01:45] <hedkandi> dh_make is saying something along those lines
[01:46] <hedkandi> $DESTDIR not ./
[01:46] <ScottK> hedkandi: Those of us who are here are pretty much focused on last minute bug fixing, so don't be suprised if you don't get an answer today.  Next week will be better.
[01:46] <hedkandi> indeed.
[01:46] <hedkandi> when is the big day then?
[01:46] <ScottK> Thursday is the release.  Last day for non-emergency uploads is tomorrow.
[01:46] <hedkandi> Are you guys in your offices in the usa?
[01:46] <hedkandi> working for canonical?
[01:48] <JontheEchidna> All of us here are mainly volunteers, scattered across both Europe and the USA
[01:49] <hedkandi> I see. Which magazine will publish intrepid ibex first then?
[01:53] <ScottK> Intrepid was released a year ago.
[01:53] <hedkandi> koala
[01:53] <hedkandi> kola koala
[01:54] <hedkandi> karmic kocaine
[01:54] <hedkandi> is what I mean
[02:06] <ScottK> porthose|afk: Nice job.  Two for two uploaded and accepted.  Thank you for your contribution to Ubuntu.
[02:28]  * ScottK notes he is fresh out of stuff to review for acceptance.
[04:01] <zooko> Folks: what are the commands to fetch the source, patch it, and build it in the same way that ubuntu builds it?
[04:01] <zooko> I'm narrowing down a segfault in a crypto lib on Karmic.
[04:02] <ScottK> zooko: apt-get source <packagename> to get the source
[04:02] <zooko> Right.  Adding sources to my sources.list now...
[04:02] <ScottK> Patching depends on what patch system, if any, the package uses.
[04:03] <ScottK> To build it, you'll want to build in a clean environment, such as pbuilder
[04:05] <zooko> So running apt-get source has a step where it says it applied a diff.  I think that's the "patching" that I meant.
[04:07] <ScottK> OK.
[04:14] <wrapster> all of a sudden im getting an error saying that libc.so.1 is not found.. even while compiling for 32bit ..anyone know why?
[04:14] <wrapster> it was working fine all the wile.
[04:16] <AnAnt> ScottK: do you read the NM Reports ?
[04:16] <ScottK> AnAnt: Yes.
[04:17] <ScottK> AnAnt: Did you see I uploaded your sabily artwork changes?
[04:17] <AnAnt> ScottK: yes and bitlbee too I think, thanks a lot
[04:17] <ScottK> Yes, that's right.
[04:17] <ScottK> You're welcome and thank you for contributing to Ubuntu.
[04:18] <AnAnt> ScottK: so, you stopped working on debian ?
[04:18] <ScottK> AnAnt: No, took a break.  Working on it again now, but it hasn't gotten to the front desk to change my status yet.
[04:18] <AnAnt> I see
[04:20] <ScottK> YokoZar: Where is this pk7zip-full that spring-engine needs?
[04:21] <zooko> p7zip-full package?
[04:22] <ScottK> There isn't one, but his package build-depends on it.  That's the problem.
[04:22] <zooko> Can I figure out exactly what version of g++ was used to build the libcrypto++-8 in karmic?
[04:23] <zooko> Not pk7zip-full
[04:23] <zooko> p7zip-full
[04:23] <ScottK> zooko: It'll be 4.4, probably 4.4.1.
[04:23] <ScottK> zooko: Thanks.
[04:23] <ScottK> Now lets see if it was his typo or mine.
[04:24] <zooko> So, I can't reproduce this segfault with the libcrypto++-8 from karmic, but I can reproduce it by building the upstream Crypto++ with the current karmic g++ 4.4.1-4ubuntu8.
[04:24] <zooko> So I'd like to know more exactly what g++ was used to build the one that is currently in karmic.
[04:24] <ScottK> Look at when it was built and what version of gcc-4.4 was current at the time.
[04:25] <zooko> Okay thanks.  It is named p7zip-full btw
[04:25] <ScottK> Thanks
[04:28] <wrapster> can anyone look into this weird issue pls
[04:29] <zooko> Hm, how do I learn when libcrypto++-8 was built and how do I learn what version of gcc 4.4 was in use at that time?
[04:30] <zooko> I know when it was changed from the changelog: http://changelogs.ubuntu.com/changelogs/pool/universe/libc/libcrypto++/libcrypto++_5.6.0-3/changelog
[04:30] <AnAnt> btw, good news, we can sync (instead of merge) texlive from now on, they have the same changes now
[04:30] <zooko> But I don't know when it was built.
[04:38] <ScottK> zooko: Launchpad's down for maintenance for 3 1/2 hours, but when it comes back you can find it there.
[04:39] <zooko> Aha!  The pbuild automatically runs the test suite!  Great!
[04:39] <zooko> *and* it fails in the same way that I've been seeing.
[04:40] <zooko> So there is a regression in the toolchain, maybe, since it was built.
[04:40] <zooko> I *think* this isn't really critical, as long as it doesn't get rebuilt before karmic goes gold.
[04:40] <zooko> But it would, of course, be good to know what's going on.
[04:40] <zooko> To reprodce: just rebuild libcrypto++-8.
[04:41] <micahg> I thought it was only supposed to be down for a half hour
[04:41] <zooko> (I did using pbuilder)
[04:41] <zooko> N.B. I've been saying "segfault" all this time, but Crypto++'s own self-tests don't seg fault, but instead they go into an infinite loop in the SHA or SHA-256 validation tets.
[04:42] <zooko> Well I need to get to sleep, but I guess I'll open a bug... launchpad's down?
[04:42] <zooko> Okay, I need to get some shuteye.  By for now.
[04:43] <YokoZar> ScottK: It's a build dep (the build system makes a few .7z archives of its content and renames them)
[04:43] <YokoZar> ScottK: oh god I misspelled it it's p7zip-full lol
[04:46] <YokoZar> I have no idea why dpkg-buildpackage didn't complain when I test built that
[04:46] <YokoZar> ScottK: reject it, I'll reupload
[04:52] <zooko> ScottK: any advice for me on pursuing this issue in libcrypto++8 and/or g++ tomorrow?
[04:52] <zooko> I would like to draw it to the attention of the relevant devs, perhaps after generating a minimal test case.
[04:53] <zooko> I'm concerned because Tahoe-LAFS depends on libcrypto++8
[04:53] <zooko> I think I might fall sleep soon...
[04:58] <ScottK> YokoZar: You need to do an ubuntu2 as it's already accepted when you uploaded it.
[04:58] <ScottK> zooko: Let's chat tomorrow.
[05:38] <micahg> ScottK: apparently, the new prism prevents usage of old files created with prism
[05:38] <micahg> I have an idea for a fix
[05:39] <micahg> when's the cutoff for non-emergency fixes?
[06:23] <wrapster> while building for 64bit im getting this error. http://pastie.org/669680
[06:23] <wrapster> im very sure im running on a 64bit machine...
[06:24] <wrapster> but the checking host-- and target systems are defined as i386 so its causing errros..
[06:24] <wrapster> would like to know how i can change it?
[06:24] <maco> the machine may be 64bit, but is the OS?
[06:25] <maco> solaris?
[06:26] <wrapster> maco: its nexenta
[06:26] <wrapster> and yes the OS is 64bit
[06:26] <maco> sol kernel + ubu userspace?
[06:26] <wrapster> yes
[06:26] <wrapster> since it was a pkging que im asking..
[06:26] <wrapster> a total newbie here .. pls help
[06:26] <maco> sounds like solaris kernel's reporting wrong...
[06:27] <wrapster> isainfo --> amd64 i386
[06:27] <wrapster> is there a way I can override it?
[06:27] <maco> dunno
[06:28] <wrapster> but the surprising thing is.. on this machine i've already compiled it for 64bit a lot of times
[06:28] <wrapster> its now that its cribbing!!
[06:50] <wrapster> maco: if i chaange anything in anyother file apart from the rules file.. I get this http://pastie.org/669690
[06:51] <wrapster> but i do not know how to refresh it ..
[06:51] <wrapster> could you please help me
[06:51] <wrapster> how to refresh that patch
[06:52] <maco> i dont see what change
[06:53] <wrapster> i went into the configure script and added --enable-64bit.
[06:53] <wrapster> then when i try building i get this.
[06:53] <slytherin> Are bug fix uploads still allowed in universe?
[06:59] <fabrice_sp> slytherin, according to last ScottK email, yes, with the ack of a motu-release "Bug fixes that are minimally risky or fix serious bugs (such as FTBFS) are still welcomed"
[07:00] <slytherin> Ok. Mine is minimally risky and probably also fixes serious bug in the package. :-)
[07:02] <wrapster> got it.. it was a bloody mistake of not including clean while configuring for 64
[07:10] <dholbach> good morning
[07:12] <fabrice_sp> good morning dholbach !
[07:12] <dholbach> hi fabrice_sp
[07:22] <wrapster> maco: i kinda got upto the stage where a copy is made of the genearted 32bit .so files and ran the configure for 64 bit  also successfully.. But now i got toatally confused in linking up the rules so that the same is created for 64bit as well..
[07:23] <wrapster> Could you please help.
[07:23] <wrapster> maco: http://pastie.org/669690
[07:30] <wrapster> anyone who can help me?
[07:54] <slytherin> wrapster: what are ou trying to do exactly?
[07:55] <wrapster> slytherin: im trying to generate 32/64 bit version of libnspr(and others).so from the same pkg...
[07:55] <wrapster> I have gotten this far.. One moment.. i'll do a latest pastie
[07:56] <slytherin> wrapster: why, don't existing packages work for you?
[07:57] <wrapster> slytherin: long story cut short, its actually a prerequisite for something else that we are doing.. I cannot discuss that unfortunately.
[07:57] <slytherin> Ok. So where are you stuck now?
[07:58] <wrapster> slytherin: http://pastie.org/669690
[07:58] <wrapster> thats the entire pastie...
[07:59] <slytherin> wrapster: I have seen that, what I am asking is at what stage are you stuck?
[08:00] <wrapster> slytherin: http://pastie.org/669680
[08:00] <wrapster> thats where Im stuck.
[08:01] <wrapster> the pkg build comes along cleanly but I dont see the staging dir being created or any of the *.so files within it ,in 64bit versions.
[08:01] <wrapster> I must be missing the logic that it directly goes to shlibdeps, after make, without running the cc -m64 <whatever>
[08:03] <wrapster> slytherin: this will give you a better picture http://pastie.org/669723
[08:03] <wrapster> its the complete log for 64bit build
[08:06] <slytherin> wrapster: I believe the prefix (in configure command) is wrong
[08:06] <slytherin> It should be debian/ IIRC.
[08:09] <wrapster> IIRC ?
[08:09] <wrapster> slytherin: for the 46 bit configure u mean?
[08:11] <wrapster> slytherin: could you please explain?
[08:13] <slytherin> IIRC is - If I remember correctly. I was referring to line 37 http://pastie.org/669690
[08:15] <wrapster> slytherin: no thats correct only. if your talking about indentation then it was messed up with the pastie... thats all
[08:17] <slytherin> I was talking about the value. Shouldn't it be debian/usr instead of /usr? I haven't packaged any C app/lib in a while so I may be wrong.
[08:18] <azeem> slytherin: no, the --prefix must be /usr
[08:19] <azeem> line 88 makes sure the package is properly installed in debian/tmp
[08:19] <wrapster> that didnt make a change... as i already said.. When i compiled it as an individual pkg(only as a 64bit pkg) it all worked fine.
[08:20] <wrapster> this i386+amd64 thing all in one is causing issues.. Im doubting my logic here.. but got really confused looking around .. so pls help
[08:20] <azeem> line 4 in the second paste might be wrong; AFAIK dh_shlibdeps takes -l arguments relative to $(CURDIR)
[08:20] <azeem> or at least expects them
[08:23] <wrapster> azeem: i dont think so, coz it worked fine for 32 bit when i had written it the same way, and also while compiling the 64bit individually.
[08:24] <wrapster> if you look at http://pastie.org/669723 as soon as the ./configure has done its job its jumping to dh_shlibdeps without running the cc -<options> thats why i said my logic could be worng but now im confused totally
[08:24] <azeem> I don't know what the issue is anyway, I arrived here mid-conversation
[08:26] <azeem> what is the thing after line 139 in http://pastie.org/669690 anyway?
[08:28] <azeem> wrapster: and why do you think it should run some "cc -<options>"?  I don't see a build_64 rule or anything like that
[08:31] <wrapster> azeem: thats a sad pastie.. something went wrong.. one moment...pls
[08:32] <wrapster> azeem: i dont know from wher its coming... before pastie it is nto there ...after i hit submit this pops up
[08:32] <azeem> 09:28 < azeem> wrapster: and why do you think it should run some "cc -<options>"?  I don't see a build_64 rule or anything like that
[08:36] <wrapster> azeem: buil_64 is not there coz im directly calilng build-stamp
[08:36] <wrapster> tahs the one right
[08:36] <azeem> the one right?
[08:37] <wrapster> yeah...
[08:37] <wrapster> install-stamp calls the buil-stamp twice
[08:37] <azeem> I didn't understand what you mean with "the one right"
[08:37] <azeem> no
[08:37] <azeem> it has the build-stamp rule as requirement
[08:38] <azeem> if the "build-stamp" file already exists at the second time, the requirement is fulfilled and the rule will not be run
[08:38] <wrapster> oh sorry
[08:38] <wrapster> didnt think of that.
[08:39] <azeem> the clean way to do this would be to have two build directories, and build/install in both, each as a requirement for build-stamp
[08:39] <azeem> like (mkdir build-32; cd build-32; $(CFLAGS32) ../configure; make)
[08:40] <azeem> (mkdir build-64; cd build-64; $(CFLAGS64) ../configure; make)
[09:19] <wrapster> azeem: all of these that you said can be written as a single rule right.. instead of making more and more dependencies?
[09:20] <azeem> if you prefer
[09:20] <azeem> that makes it harder to just build one or other other, though
[09:21] <wrapster> ok from what i've already written could you help me make it clean.pls
[09:21] <azeem> no, I don't have time right now
[09:22] <wrapster> ok
[10:23] <wrapster> slytherin: could i take your help pls?
[10:23] <slytherin> wrapster: regarding what?
[10:24] <wrapster> slytherin: the build comes through successfully, i can create a backup of the 32bit files ,i can also see that the staging dir has 64bit files but its not being put under /usr/lib
[10:24] <wrapster> under the same rules file.
[10:25] <slytherin> hmm, can't help much. I usually work on java packages. :-(
[10:25] <wrapster> hmm
[10:25] <wrapster> ok thanks anyway.
[10:25] <wrapster> geser: are you around :)
[10:34] <geser> yes
[10:39] <wrapster> geser: one moment pls..
[10:39] <wrapster> i'll finish the build
[10:43] <wrapster> geser: ok so here is the update .. individually i can build the 64bit versions but im not suppose to do so.. So i tried integrating both and this is what i could come up with http://pastie.org/669815
[10:44] <wrapster> geser: I have a backup that will be created of the 32bit ones but when the rules file builds for 64bit , the 64bit (*.so) files are created in the staging dir no doubt(debian/tmp) but they are not transferred to the debian/libnspr4-0d
[10:44] <wrapster> where they should actually reiside...
[10:46] <wrapster> essentially what i want to say is debian/libnspr4-0d is missing most of the contents of the staging dir (debian/tmp) when the 64bit version is built.. for the 32bit one tehre is no problem... Again im guessing my logic could be worng.. or the way im placing the dependecies could be worng.. Could you pls help...
[10:48] <geser> can you pastebin debian/libnspr4-0d.install (if it exists and I guess the filename right)?
[10:52] <wrapster> yeah
[10:52] <wrapster> geser: here is a pastie that will explain my problem very well..http://pastie.org/669823
[10:53] <wrapster> geser: the file exists and it only had 2 contents...
[10:53] <wrapster> usr/lib/*.so.0d
[10:53] <wrapster> usr/lib/*.so
[10:54] <azeem> wrapster: how do you make sure the 32bit and 64bit *.so are differently named?
[10:54] <azeem> do you put them in different directories?
[10:54] <wrapster> yes.
[10:54] <azeem> which are?
[10:54] <geser> wrapster: like I assumed. The .install files controll which files get moved over from debian/tmp to debian/$pkgname (from where the deb is build)
[10:54] <wrapster> pls look at this http://pastie.org/669815 line no 75
[10:55] <wrapster> the copy_32 rule, will actually copy out all the *.so files to a named dir for future replacement..
[10:55] <azeem> wrapster: and then those get copied back to debian/libnspr4-0d/usr/lib in line 103
[10:55] <azeem> probably overwriting the 64bit files
[10:56] <wrapster> azeem: no
[10:56] <wrapster> they are acutally not being copied for some reason.
[10:57] <geser> wrapster: so debian/tmp contains both the 32bit libs and 64bit ones correctly? the first ones in debian/tmp/usr/lib and the second ones in debian/tmp/usr/lib/amd64?
[10:57] <azeem> wrapster: did you check the content of bkup_32?
[10:57] <azeem> cp debian/tmp/usr/lib/*.0d bkup_32
[10:57] <azeem> this might just copy over a symlink
[10:57] <wrapster> azeem: yes the bkup_32 only has 32bit files
[10:58] <wrapster> and within the debian/tmp dir
[10:58] <azeem> ok
[10:58] <geser> azeem: I assume it's just the install file telling to move the 32bit libs into the package
[10:58] <wrapster> there is no lib/amd64 being created .. (coz ive not mentioned it...)
[10:58] <wrapster> however the files will be created in debian/tmp/usr/lib only but these will be 64bit
[10:58] <wrapster> im very sure and i ran a check on this to clarify...
[10:59] <wrapster> so the summary being... I have the 32bits in bkup_32 and 64bits in debain/tmp/usr/lib at the end of my build.
[10:59] <wrapster> but there is nothing in debian/libnspr4-0d dir :(
[11:02] <azeem> sorry, but I'm not interested in debugging your rules
[11:02] <wrapster> azeem: / geser : http://pastie.org/669829 this is the o/p at the end of my build.
[11:02] <wrapster> azeem: ok np.. thanks for you help
[11:02] <wrapster> geser: could you pls help me..
[11:03] <azeem> wrapster: also note that people will probably mock Nexenta if you push this into a release like this
[11:03] <azeem> it's really ugly
[11:06] <cbx33> hey motu peeps
[11:06] <cbx33> anyone using the bluetooth networking in karmic?
[11:08] <Laney> gah
[11:09] <geser> wrapster: I assume that "install-stamp-64" installs the libs also to debian/tmp/usr/lib and overwriting your backup from line 103. Try moving the 64bit libs to the correct location (after you installed them) and only then copy back the 32bit libs
[11:09] <Laney> dh_haskell_configure doesn't support passing arbitrary flags through
[11:12] <Laney> I fear I'll have to leave hsh for karmic
[11:18] <wrapster> geser: ok
[11:27] <wrapster> geser: i want it to overwrite the 64bit libs coz by the time the 64bit processing will start I already have taken the backup of 32bit files...(in bkup_32) so i will definitely have it in tmp/usr/lib/ but if i can somehow reflect it in libnspr4-0d then i can do further copy and so on... but thats not happening.. thats my worry
[11:30] <wrapster> geser: this is how the makefile logic i created works... build everything for 32bit until you reach dh_installdep -a (coz thats when the tmp dir having 32bit is created)--> then copy all these to bkup_32--->clean-->configure_64-->build64-->install
[11:36] <azeem> did you verify that the build is actually going like this?
[11:39] <wrapster> yes
[11:39] <wrapster> azeem: and i think i resolved the issue one moment let me see..
[11:47] <wrapster> azeem: no... :(
[11:47] <wrapster> not working
[11:48] <wrapster> azeem: / geser: yay yay
[11:48] <wrapster> working.
[12:25] <Laney> sigh
[12:26] <sebner> huhu Laney
[12:26] <Laney> hi there
[12:26] <sebner> Laney: anything wrong?
[12:26] <Laney> yeah
[12:26] <Laney> I need armel to test a fix
[12:26] <Laney> :(!
[12:27] <Laney> (or sparc)
[12:29] <hyperair> Laney: qemu?
[12:29] <sebner> Laney: NCommander not around?
[12:30] <Laney> hyperair: dunno how
[12:30] <hyperair> Laney: manpage =0
[12:31] <Laney> its unhelpful
[12:31] <Laney> looks like hassle too
[12:32] <Laney> I would very much like one of those PPAs that builds for everything
[12:34] <dinxter> me too, armel, sparc, powerpc needed here:*(
[12:35] <hyperair> well powerpc emulatable
[12:35] <hyperair> but you can't debootstrap a powerpc chroot >_>
[12:36] <hyperair> rather, even if you did, you'd end up having to figure out a way to install the powerpc kernel and bootloader
[12:39] <dinxter> I'm sure I needed this before and did something, if only I could remember what.. old age
[13:05] <slytherin> Laney: IIRC, revu is on sparc. So may be you can bribe revu admins for access to a chroot. :-P
[13:22] <dinxter> all i need is a build check in pbuilder rather than anything more
[13:25] <slytherin> Laney: Another solution is to bribe the MOTUs who are also DDs to test the fix bug for you. :-)
[13:27] <Laney> slytherin: I thought of that one ;)
[13:27]  * Laney looks at directhex
[13:36] <zooko> morning folks
[13:43] <ScottK> Would someone that knows C please review https://code.edge.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854
[13:53] <joaopinto> ScottK, gint count = (strlen(no_ansi) - written); it could use just "len" no need to call strlen() again
[13:54] <ScottK> joaopinto: Could you fix it and make a proper debbdiff?
[13:55] <joaopinto> well, it's a very small improvement, doesn't worth a debdiff at this time, the code looks sane
[13:56] <zooko> ScottK: something looks wrong to me.
[13:57] <zooko> Suppose strlen(no_ansi) is 20 at the start.  written gets initialized to 0.  First pass of the loop, count  = 20
[13:57] <zooko> suppose partial write, written = 5, then
[13:57] <zooko> second pass of the loop, count = 15
[13:57] <zooko> so far so good -- it invokes write(fd, no_ansi+5, 15)
[13:58] <zooko> but if there is a second partial write, let's say this time written = 6
[13:58] <zooko> so 3rd pass of the loop, count = 14
[13:58] <joaopinto> oh written is not cumulative :\
[14:02] <ScottK> OK.  Sounds like we should give it a pass for Karmic.  Maybe an SRU.
[14:02]  * Laney is going to upload another armel/sparc fix, this time for darcs
[14:02] <Laney> same caveats as before
[14:03] <ScottK> OK.
[14:12] <Teddy_> I need a sync from Debian to fix a security bug #457709.  Who should I poke?
[14:22] <ScottK> Teddy_: You've come to the right place.
[14:26] <zooko> ScottK: so, should we do anything about the fact that, on my machine at least, "pbuilder build libcrypto++_5.6.0-3.dsc" when it gets to the SHA validation suite and enters an infinite loop?
[14:27] <zooko> I'm glad to see that the tests get run automatically as part of pbuilder, since that means if it fails then it will *not* be uploaded to ubuntu, right?
[14:28] <ScottK> It should fail to build, yes.
[14:28] <sistpoty|work> the patch for gnoemoe should probably replace the first do-loop with http://paste.ubuntu.com/302087/
[14:28] <zooko> Oh yeah, I was going to figure out which version of gcc was used to build it.
[14:28] <ScottK> Althought pbuilder and the buildd's are not identical.
[14:28] <Teddy_> ScottK: Right then.
[14:28]  * Teddy_ pokes the channel about bug #457709
[14:28] <ScottK> sistpoty|work: simon-o is online, so maybe you could discuss it with him
[14:28] <ScottK> Teddy_: I'm looking at it.
[14:29] <Teddy_> ScottK: Cool, thanks!
[14:29] <sistpoty|work> simon-o: ^^?
[14:29] <simon-o> sistpoty|work: yes
[14:29] <sistpoty|work> simon-o: read the above discussion about your patch for gnomeoe?
[14:30] <sistpoty|work> gnoemoe even
[14:30] <simon-o> sistpoty|work: yes, ScottK attached it to the merge proposal
[14:30] <zooko> Where is there a history of when packages were built and/or uploaded?
[14:30] <ScottK> simon-o: sistpoty|work had an additional suggestion
[14:30] <zooko> I'd like to understand if the difference between my pbuilt libcrypto++8 and the one in karmic is due to a slightly different version of g++.
[14:30] <ScottK> zooko: In launchpad.  What's the source package name?
[14:31] <simon-o> ScottK, sistpoty|work: Ok I see, you mean http://paste.ubuntu.com/302087/
[14:31] <simon-o> ?
[14:31] <sistpoty|work> yes, boils down to the same as in the compileflags wiki
[14:31] <sistpoty|work> simon-o: of course it'd also be worthwhile to check if the file descriptor in question is opened non-blocking. if so EAGAIN is also a vaild error
[14:31] <zooko> Source: libcrypto++
[14:32] <zooko> and Source: gcc-4.4
[14:32] <ScottK> zooko: https://launchpad.net/ubuntu/+source/libcrypto++/+publishinghistory
[14:32] <ScottK> Similar for gcc-4.4
[14:33] <simon-o> sistpoty|work: Is your patch for the updated version of my patch?
[14:33] <zooko> hm.
[14:34] <sistpoty|work> simon-o: yes it should replace the first do-loop
[14:34] <sistpoty|work> simon-o: the recipe in the compilerflags wiki would also work though
[14:34] <zooko> ok, how can i fetch the version of gcc that was used to build and see if building with that version yields a working libcrypto++?
[14:35] <zooko> 4.4.1-3ubuntu3
[14:36] <ScottK> zooko: What architecture?
[14:36] <bddebian> Heya gang
[14:36] <simon-o> sistpoty|work: I don't really get what you mean with ret. Where is that defined?
[14:37] <zooko> ScottK: amd64
[14:37] <ScottK> zooko: https://launchpad.net/ubuntu/+source/gcc-4.4/4.4.1-3ubuntu3/+build/1195506
[14:38] <ScottK> Heya bddebian.
[14:38] <bddebian> Hi ScottK
[14:40] <ScottK> Teddy_: mandos sync'ed for Karmic.
[14:40] <Teddy_> ScottK: Wonderful!
[14:40] <Teddy_> ScottK: Thanks a lot.
[14:44] <sistpoty|work> simon-o: oh, should be same as written... forgot to add that variable
[14:44] <ScottK> Teddy_: The binaries are failing to upload due to a known launchpad bug.  I'll do a direct upload to work around it, so don't worry.
[14:45] <Teddy_> ScottK: I was just wondering about that, thanks!
[14:45] <sistpoty|work> (same type as written
[14:45] <simon-o> sistpoty|work: ok, this makes sense. I don't really see a benefit of using a for loop (I personally like for more, but I tried to keep this as close to the recipe as possible to make it easier for reviewing)
[14:45] <sistpoty|work> +)
[14:46] <sistpoty|work> simon-o: I only learnt that the recipe exists after I pastebin'd my solution ;)
[14:46] <gaspa> ScottK (or some m-r) : python-poppler-dbg is uninstallable, I'd like to upload a fixed revision.
[14:46] <sistpoty|work> simon-o: either one should be fine
[14:46] <ScottK> gaspa: Pastebin the diff please.
[14:46] <simon-o> sistpoty|work: Ok, so would it be ok with you if I fix the my patch and use that one?
[14:47] <gaspa> ScottK: yup, just a minute.
[14:47] <sistpoty|work> simon-o: sure
[14:47] <simon-o> sistpoty|work: ok, thanks for your help. I'll post a new diff soon.
[14:47] <sistpoty|work> yw
[14:49] <ScottK> sistpoty|work: Do we care about 302003?
[14:49]  * sistpoty|work looks
[14:50] <ScottK> Thanks
[14:53]  * sistpoty|work looks closer at mxml
[15:00] <gaspa> ScottK: http://paste.ubuntu.com/302105/
[15:00] <ScottK> gaspa: Go for it.
[15:01] <gaspa> thank you
[15:01] <simon-o> ScottK, joaopinto, zooko, sistpoty|work: I updated the merge proposal at https://code.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 based on your feedback. Here is the proposed patch http://paste.ubuntu.com/302107/ (LP seems to has some problems)
[15:02] <sistpoty|work> ScottK: no, we don't care for bug #302003, as the shared object is already linked against the pthread library, and hence will draw it in when getting loaded (the only thing to fix here would be to add @PTHREAD...@ to Libs.private)
[15:02] <ScottK> sistpoty|work: Thanks.
[15:02]  * sistpoty|work adds a comment to the bug
[15:03] <joaopinto> simon-o, it's still faulty, you can't use the cumulative value to exit the loop, that one needs to be based on the last write( return value
[15:03] <joaopinto> you want to use "total_written" for the pointer, and "written" to break the loop due to a negative write( return
[15:04] <simon-o> joaopinto: argh, sorry. I'll try it again. Thanks
[15:06] <joaopinto> simon-o, the fix for those unhandled writes( is not as simple as it looks ;)
[15:06] <simon-o> joaopinto: yeah, that's true.
[15:06] <simon-o> good to have someone who reviews it :)
[15:06]  * sistpoty|work wonders why it uses write there in the first place, and not just the much simpler stdio counterparts
[15:13] <ScottK> gaspa: Accepted.  Thanks.
[15:13] <gaspa> ScottK: cool, thank _you_ :P
[15:16] <simon-o> joaopinto: next try: https://code.edge.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 I now use the total written bytes to decrease the counter and move forward in the buffer
[15:18] <joaopinto> simon-o, 2 errors
[15:18] <joaopinto> ops, wait, let me look again :P
[15:19] <simon-o> :P
[15:19] <joaopinto> simon-o, well, there is a broken code path, but it get's discated on loop exit condition
[15:20] <joaopinto> total_written += written;
[15:20] <joaopinto> on error, written is negative, and you are decreasing total_* :P
[15:21] <joaopinto> I hope no one decides to re-use total_written out of the loop :P
[15:21] <simon-o> joaopinto: that's right, but then the loop discontinues
[15:22] <simon-o> joaopinto: ok, that's a good point I'll move total_written += written two lines up
[15:22] <simon-o> then it should be ok
[15:22] <sistpoty|work> no, if a signal is delivered during the write, written is negative and errno is EINTR
[15:22] <sistpoty|work> but the loop continues
[15:24] <simon-o> sistpoty|work: I thought errno is only EINTR before any bytes are written
[15:24] <simon-o> ok I see, forget about it
[15:25] <simon-o> sistpoty|work, joaopinto: I'll add a check if written > 0 and increase total_written only in that case
[15:25] <simon-o> that should be safe
[15:25] <joaopinto> that looks good
[15:26]  * sistpoty|work has the suspicion that the code slowly migrates to what I pasted :P
[15:26] <simon-o> :D
[15:33] <simon-o> joaopinto, sistpoty|work: https://code.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854 updated again
[15:37] <ScottK> didrocks: Any luck on a quickly fix?
[15:37] <quidnunc> How do I search for a package that might be a child of some metapackage?
[15:37] <didrocks> ScottK: I didn't have the time to work on it, but currently doing it. It seems to be almost good
[15:37] <ScottK> didrocks: Excellent.
[15:37] <joaopinto> quidnunc, a child ? you mean a dependency ?
[15:39] <quidnunc> joaopinto: I thought that sometimes that a dependency might be listed but that dependency was not actually a package but was provided by the "real" package
[15:39] <quidnunc> Specifically I want to know what provides "X11", if anything
[15:41] <joaopinto> ah ok :|
[15:42] <sistpoty|work> simon-o: almost good: for the second part, you don't clear errno, but have the write done in a loop that loops on errno==EINTR. iirc a write will not clear errno (only set it if things go wrong)
[15:42] <joaopinto> simon-o, I am not sure the second loop is safe
[15:42] <joaopinto> write() can return 0, that is not an error, and you are not retrying
[15:43] <joaopinto> merge it with sistpoty|work comments :P, you only care about errno if rc<0
[15:43] <sistpoty|work> exactly :)
[15:47] <simon-o> sistpoty|work, joaopinto: ok, so while (e]
[15:48] <simon-o> while (written <0 && errno == EINTR)
[15:48] <sistpoty|work> yes
[15:53]  * zooko has a fantasy of the Test Driven Operating System
[15:54] <zooko> So anyway, I've installed gcc-4.4.1-3ubuntu3 and now I'm creating a new pbuilder chroot with it.
[15:55] <simon-o> sistpoty|work, joaopinto: Here we go again: https://code.edge.launchpad.net/~simono/ubuntu/karmic/gnoemoe/fixes-bug-459164/+merge/13854
[15:55] <zooko> This should tell us whether there was a regression in gcc between 4.4.1-3ubuntu3 and the current 4.4.1-4ubuntu8, or whether there is something funny with my particular machine.
[15:57] <didrocks> ScottK: Quickly fix uploaded in 0.2.6
[15:58] <ScottK> didrocks: Would you please pastebin me the diff.
[15:58] <sistpoty|work> simon-o: looks good to me
[15:59] <ScottK> didrocks: Any chance you could sponsor simon-o's patch ^^^
[16:00] <joaopinto> simon-o, looks good
[16:00] <didrocks> ScottK: http://paste.ubuntu.com/302134/
[16:00] <ScottK> THanks.
[16:00] <didrocks> ScottK: joaopinto seems to be on it :)
[16:00] <ScottK> didrocks: OK.
[16:00] <ScottK> I lose track of who is MOTU and who isn't.
[16:00] <joaopinto> I am not a MOTU :)
[16:01] <didrocks> oh ok
[16:01] <didrocks> reviewing so :)
[16:01] <maco> you know im not ;)
[16:01] <ScottK> Thanks.
[16:01] <ScottK> maco: Yes.  You should fix something I can sponsor
[16:01] <maco> haz midterm tonight. then will do
[16:02] <ScottK> maco: OK.  8AM our time tomorrow is the deadline.
[16:02] <didrocks> ScottK: I don't have here a running VM with GUI (at work), but I can do it in let's say 4 hours, is it ok?
[16:02] <maco> oh dear. ok youre a night owl, yeah?
[16:02] <ScottK> maco: Also up at 5:45 to get kids off to school.
[16:03] <zooko> 8AM in what timezone?
[16:04] <simon-o> sistpoty|work, ScottK, didrocks, joaopinto: Thanks for your help
[16:04] <sistpoty|work> thanks for working on it, simon-o
[16:05] <ScottK> didrocks: quickly accepted.  thanks.
[16:05] <simon-o> sistpoty|work: This was a nasty one, but I learned a lot :)
[16:05] <sistpoty|work> :)
[16:05] <ScottK> zooko: -0400.  Noon UTC is the deadline
[16:05] <ogra> ScottK, she should fix something you can sponsor ? i'D say she should fix her status and finally become motu rather :)
[16:06] <ScottK> ogra: Right and if I sponsor something I can write a nice endorsement on her application.
[16:06]  * ogra would have betted money on maco being motu ... why arent you yet ?
[16:06] <maco> ogra: wanna cheer for me on nov 13?
[16:06] <maco> im applying at that mc meeting
[16:06] <ogra> aww, thats awfully close to UDS ... but i'll try to attend
[16:07] <maco> i think youre the second person to express surprise at my not-motu-ness
[16:07] <ogra> heh
[16:11] <didrocks> ScottK: thanks to you :)
[16:26] <zooko> Hm.  pbuilder of libcrypto++8 hangs on the SHA validation suite even though I dpkg -i'ed gcc-4.4.1-3ubuntu3 before creating this pbuilder.
[16:26] <ScottK> Anyone with amd64 that could do a test build of klamav and tell me if/why it fails.
[16:26]  * zooko tries to double-check to make sure that the g++ version in there is really 4.4.1-3ubuntu3.
[16:27] <ScottK> zooko: Did you install it on your system or in the pbuilder chroot?
[16:28] <zooko> I installed it into my system and then mv'ed aside /var/cache/pbuilder and created a new pbuilder.
[16:28] <zooko> following this howto https://wiki.ubuntu.com/PbuilderHowto
[16:29]  * zooko unpacks /var/cache/pbuilder/base.tgz
[16:29] <zooko> Whoops, it has g++-4.4.1-4ubuntu4 in it.
[16:29] <zooko> How do I create a pbuilder chroot with g++-4.4.1-3ubuntu3?
[16:31] <zooko> Also, could I interest someone else in..  Hey, maybe #ubuntu-motu isn't the best channel for finding someone who wants to help me worry about a regression in g++.
[16:32] <zooko> But what is the right channel?  #ubuntu-devel?
[16:32] <zooko> Anyway, I was going to say could I interest someone in rebuilding libcrypto++8 and telling me if it hangs, segfaults, or passes its self-tests (specifically the SHA ones).
[16:33] <zooko> http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1
[16:33] <zooko> ^-- very cool automated git bisect of performance regressions
[16:35] <ScottK> asac: accepted bindwood
[16:36] <ScottK> zooko: Use pbuilder --login and then install the .deb's in the chroot
[16:36] <ScottK> Then debuild -us -uc
[16:38] <zooko> ScottK: thanks
[16:39] <ScottK> zooko: You'll also need devscripts and fakeroot installed in the chroot
[16:40] <zooko> ScottK ok
[16:44] <zooko> Um, ScottK: this is a newbie question, but is there any easier way to get stuff into the chroot environment than uploading it to a web server and wget''ing it once I've chrooted?
[16:44] <zooko> I just finished adding it into the tarball when I realized that the resulting taball won't have the right mknod bits set...
[16:44] <zooko> If I repack it with "tar cf"
[16:45] <ScottK> zooko: Yes.  The chroot lives in /var/cache/pbuilder/build after you login.  You can sudo cp stuff into it.
[16:45] <joaopinto> you should be able to repackage a chroot with tar without problems
[16:48] <zooko> thanks
[16:50] <sistpoty|work> ScottK: I'll give klamav a shot
[16:52] <ScottK> sistpoty|work: Thanks.
[16:52] <zooko> Hrm, it says it needs libcloog-ppl0 libgmpxx4ldbl libppl-c2 libppl7 to install g++-4.4.1-3ubuntu3.
[16:53] <zooko> I don't suppose there is a comman d to tell apt-get to get all of those deps recursively but get the *older* ones that match this version of g++?
[16:53] <zooko> Also I wonder why it didn't say that when I installed g++-4.4.1-3ubuntu3 in my actualy system.
[16:56] <zooko> Hm, also libcloog-pp10 doesn't appear to be a real ubuntu package at all.
[16:57] <sistpoty|work> ScottK: fails: http://paste.ubuntu.com/302162/
[16:58] <ScottK> sistpoty|work: It used to build.  Any ideas what would cause that?
[16:58] <sistpoty|work> ScottK: not at the moment, let me dig a bit further
[16:59] <ScottK> We can't accept any more uploads for packages that are seeded by Mythbunto or Ubuntu Studio.
[17:06] <blackxored> ScottK, I'm here ;)
[17:06] <ScottK> blackxored: What's the issue that needs this update?
[17:07] <blackxored> ScottK, is some lockdown in multiannounce torrents and suddenly all torrent sites started using the feature 2 weeks ago or so, so it will an annonyance for users
[17:08] <blackxored> ScottK, that was the long answer, the short one: #551363
[17:08] <ScottK> OK.  Looking.
[17:08] <blackxored> the changes are trivial so I don't think we'll break anything by this update
[17:09] <blackxored> at debian bts
[17:09] <blackxored> btw
[17:09] <ScottK> There's an existing Ubuntu delta.  Did you check to see if that's in the Debian package now?
[17:09] <blackxored> ScottK, no is not because it's related to hotspot and we don't experience the bug in debian
[17:10] <ScottK> OK, so what I really need is a merge, not a sync.
[17:10] <blackxored> ScottK, I never asked for a sync ;)
[17:10] <blackxored> the ubuntu delta is just for the launcher
[17:10] <blackxored> but it may be required for you
[17:11] <ScottK> I'm reluctant to drop it so close to release.
[17:11] <blackxored> although is kind of weird since I'm running my build on karmic without problems, could even be dropped after some testing ;)
[17:11] <ScottK> We're ~16 hours from our final, final freeze for universe, so I'm reluctant.
[17:11] <blackxored> azureus:
[17:11] <blackxored>   Installed: <IP_ADDRESS>-3
[17:11] <blackxored>   Candidate: <IP_ADDRESS>-3
[17:11] <blackxored>   Version table:
[17:11] <blackxored>  *** <IP_ADDRESS>-3 0
[17:11] <blackxored>         100 /var/lib/dpkg/status
[17:11] <blackxored>      <IP_ADDRESS>-1ubuntu1 0
[17:11] <blackxored>         500 http://cu.archive.ubuntu.com karmic/universe Packages
[17:11] <blackxored> running without problems
[17:12] <blackxored> ok no problems for me but I'm just telling that probably it was a bug with the hotspot compiler that got eventually fixed, it was karmic alpha 5 if I recall
[17:12] <ScottK> I believe it works for you, I just don't know exactly what conditions caused it to be added in the first place.
[17:13] <blackxored> ScottK, a segmentation fault in the hotspot compiler for the class it's now excluded from compilation in the ubuntu delta
[17:13] <blackxored> No LSB modules are available.
[17:13] <blackxored> Distributor ID: Ubuntu
[17:13] <blackxored> Description:    Ubuntu 9.10
[17:13] <blackxored> Release:        9.10
[17:13] <blackxored> Codename:       karmic
[17:13] <ScottK> jdong: You around?
[17:14] <ScottK> I see.
[17:14] <blackxored> well but that's not exactly my point I want this bugfix to be used in ubuntu as well
[17:14] <ScottK> blackxored: RIght, I'm just about getting it in the safest way
[17:14] <blackxored> ScottK, that's both of us then ;)
[17:15] <ScottK> iulian: Can you look at this ^^^
[17:15]  * ScottK has ETOOMANYPROBLEMS going on right now
[17:15] <blackxored> also you're at ubuntu1 revision??? wow you're missing two important bug fixes then
[17:15] <blackxored> in <IP_ADDRESS>-2: Fix filename encoding UTF8 issues. Closes: #502879.
[17:16] <blackxored> and now in <IP_ADDRESS>-3: - Fix multi-announce torrent issues. Closes: #551363.
[17:17] <ScottK> Yeah.
[17:18] <ScottK> If iulian doesn't look at it, I can look at it a little later.
[17:18] <blackxored> ScottK, that's fine I wanted you guys to know before everything is frozen ;) heheh
[17:18] <blackxored> ScottK, thanks for your help
[17:20] <blackxored> BTW for you guys to check about the ubuntu delta, the bug that caused it it's LP#428514
[17:23] <ScottK> Thanks.
[17:28] <ScottK> mterry: mseide-msegui accepted.  Thanks.
[17:29] <mterry> ScottK: that's my big ftbfs contribution today.   :)  was busier elsewhere than I thought
[17:29] <ScottK> mterry: OK.  Thanks for that.  We're open for business for another 18 and a half hours, so keep them coming.
[17:30] <asac> ScottK: thx
[17:30] <ScottK> No problem.
[17:30] <sistpoty|work> ScottK: my best guess is that a libtool build-dependency is missing for klamav, giving that a shot
[17:31] <sistpoty|work> (since when is libtool no longer getting drawn in from autoconf (or was it automake?)...?)
[17:31] <ScottK> sistpoty|work: Thanks.
[17:31] <ScottK> I have this bug in Debian too and no amd64 to work on it.
[17:33] <sistpoty|work> oh, looks like autoconf didn't depend on libtool in the first place... strange, I always thought that was the case
[17:34] <ScottK> Is there a MOTU in the house that can look at Bug #461234
[17:35] <iulian> ScottK: Looking at azureus right now.
[17:35] <ScottK> iulian: Thanks.
[17:38] <sistpoty|work> ScottK: hm, adding libtool to b-d didn't fix klamav.
[17:51] <mpt> Hi everyone
[17:51] <mpt> This week I am designing the Ubuntu Software Center v2, which will be dealing with non-application packages (like Synaptic does)
[17:51] <mpt> so I shall be asking various strange questions about packaging
[17:52] <iulian> blackxored: As ScottK said, I don't want to drop that change from Ubuntu either, especially at this point.  How important are these two patches?
[17:52] <ScottK> What is a non-application package?
[17:52] <ScottK> iulian: I'd say just merge and update.
[17:52] <mpt> ScottK, one that doesn't contain an application with a .desktop file. Or more precisely but less enduringly, one that isn't represented inside app-install-data.
[17:53] <iulian> ScottK: OK.
[17:54] <ScottK> OK.  Well there are lots of applications that don't need gui or .desktop files.  It seems an odd choice of terminology
[17:55] <mpt> ScottK, yeah, it's the least clumsy term I've thought of so far. If you have ideas for a better term, that would be cool, because there needs to be a toggle for it in the interface somewhere :-)
[17:59] <mpt> My first strange question is: Are any Ubuntu packages marked as "Essential"? (I don't see it mentioned in "apt-cache show libc6" for example.) If so, how would I see a list of which packages they are?
[18:03] <ScottK> libc6 isn't essential.
[18:04] <mpt> It's "Priority: required"
[18:06] <sistpoty|work> mpt: bash is an example of a package marked as Essential: yes
[18:06] <sistpoty|work> mpt: you can see these in /var/lib/dpkg/available for example (^Essential: yes) might be a starting point
[18:07] <sistpoty|work> mpt: however essential: yes != required. it just means it's a package that provides functionality that can be used in maintainer scripts w.o. further thinking
[18:07] <mpt> ok
[18:07] <mpt> thanks sistpoty|work
[18:08] <sistpoty|work> yw
[18:08] <mpt> interesting that dash and bash are both Essential
[18:08] <joaopinto> hum, what's the criteria for that Essential ? part of the debootstrap process ?
[18:08] <sistpoty|work> mpt: because you'll want to call shell scripts and iirc there might be problems with /bin/sh being a symlink if not both packages are installed
[18:09] <sistpoty|work> joaopinto: provide essential functionality for maintainer scripts (and dpkg)
[18:09]  * mpt toddles off home
[18:12] <alkisg> Hi, `usermode` is translated in a lot of languages (there are lots of .po files in its source) but *none* of the .mo files get installed if one installs the package. What could be wrong?
[18:13] <alkisg> !info usermode
[18:14] <iulian> When running dpkg-buildpackage I get:
[18:14] <iulian> You must specify a valid JAVA_HOME or JAVACMD!
[18:14] <iulian> make: *** [ant-sanity-check] Error 1
[18:14] <iulian> How can I fix this?
[18:14] <iulian> blackxored, ScottK: ^
[18:14] <ScottK> iulian: You're building the source package?
[18:15] <iulian> Yes.
[18:15] <ScottK> Install the build-deps
[18:15] <ScottK> You need one of them (I don't recall which) to make the source package
[18:15] <ScottK> I usually just apt-get build-dep and then autoremove when I'm done
[18:17] <iulian> ls
[18:17] <iulian> Oups.
[18:18] <alkisg> Also, if I run `apt-get source usermode` and then `debuild -b`, the resulting package *does* have all the .mo files. How can that be?!!!
[18:19] <iulian> ScottK: Thanks.
[18:22] <alkisg> Does the Ubuntu building process strip all the .mo files by default?
[18:22] <ScottK> For packages in Main it does
[18:23] <ScottK> It then puts them in language packs
[18:23] <alkisg> But usermode is in universe...
[18:23] <ScottK> Yeah.
[18:23] <ScottK> This happens sometime.
[18:23] <alkisg> uh, should I file a bug then?
[18:23] <ScottK> JontheEchidna: Any suggestions ^^^?
[18:23] <ScottK> dpm: ^^^
[18:23] <ScottK> Let's see if we can get it figured out.
[18:23] <JontheEchidna> hmm
[18:23] <alkisg> Thanks
[18:24]  * ScottK has summoned people who know more about it than he
[18:24]  * dpm reads...
[18:25] <JontheEchidna> anything non-kde translation related is a bit out of scope for me
[18:25] <sistpoty|work> ScottK: I didn't get too far with klamav. my best guess is that rerunning autotools might help, but it seems that acinclude.m4 could be the troublemaker (probably an old version copied somewhere from kde)
[18:25] <dpm> alkisg, if you are building a package locally, translations are not stripped by default.
[18:25] <ScottK> urgh
[18:26] <ScottK> dpm: But they shouldn't be stripped for Universe packages either
[18:26] <alkisg> dpm: yes, but my problem is that I'd like it to be translated when I install it from the ubuntu repositories, so that I don't have to compile it myself...
[18:26] <dpm> ScottK, yes, that's correct, and that's the other point :-)
[18:26] <sistpoty|work> ScottK: but that's just guess, and probably not a very good one
[18:26] <ScottK> sistpoty|work: Thanks for looking.
[18:26] <sistpoty|work> yw
[18:28] <blackxored> iulian, i was off
[18:28] <blackxored> you need ant for clean target
[18:28] <iulian> ScottK: I've prepared a merge of azureus.  Are you OK if I upload it?
[18:29] <ScottK> iulian: Assuming you've built it, etc., sure.
[18:29] <iulian> blackxored: Yea, I've successfully built it.
[18:29] <blackxored> I'll be off for another ten minutes so please pv me
[18:29] <blackxored> iulian, great ;)
[18:29] <ScottK> blackxored: It's about to go in.  Thanks for letting us know about it.
[18:29] <blackxored> iulian, what did you do about the ubuntu delta, you kept it, as you said a merge didn't you
[18:30] <ScottK> Yes, we kept it.
[18:30] <iulian> blackxored: Yes.
[18:30] <iulian> ScottK: Uploaded.
[18:30] <ScottK> We can look at dropping it in Lucid
[18:30] <ScottK> Excellent.
[18:30] <blackxored> ScottK, no problem at all, I would have done it myself, but I was kind of busy with an ecommerce app, also not quite confident to ubuntu procedures, since I came from debian
[18:30] <blackxored> iulian, ScottK: thank you guys, I'll soon go ahead and install ;)
[18:31] <iulian> blackxored: Cool, thank you.
[18:31] <ScottK> blackxored: We could really use more help from people who know something about Java.  Not to many MOTU do
[18:31] <blackxored> ScottK, I'm part of the debian-java team so I'll be around for any questions ;) hehe
[18:31] <ScottK> OK
[18:31] <ScottK> Thaks
[18:31] <ScottK> Thanks even
[18:37]  * iulian -> supper.
[18:43] <wrapster> geser: I dont understand whats going on at all.. npsr i built successfully all the 64libs are installed yet when i try compiling nss i get this.. http://pastie.org/670439
[18:44] <wrapster> i just want to get this up and working..pls help
[18:46] <geser> wrapster: is this from a libnss 64bit build?
[18:47] <wrapster> geser: yes
[18:48] <geser> wrapster: looks like it's missing the flag to build a 64bit lib (the .o files got build for 64bit, yet it tries to link them to 32bit lib, that's what it's complaining about)
[18:49] <wrapster> geser: here is the rules file http://pastie.org/670458
[18:50] <geser> wrapster: it
[18:51] <wrapster> geser: it ?
[18:51] <geser> wrapster: hit the return key to early :(
[18:51] <wrapster> i got it.. looking at the makefile in mozilla/nss/security... but dont seem to quite get it.
[18:52] <wrapster> geser: thats ok..
[18:52] <geser> wrapster: while your build uses -m64 (from CFLAGS), it's missing in the linking stage (IIRC I saw it mentioned in your pastes where you got the linking a little bit further)
[18:53] <wrapster> geser: no..
[18:53] <wrapster> geser: no was for that -m64 flag
[18:53] <wrapster> i have indeed used it.
[18:55] <geser> if the upstream Makefile honours LDFLAGS during the linking stage, try setting it to the flags needed to link a 64bit lib
[18:56] <wrapster> ok
[18:58] <geser> I'm slowly losing an overview of what you have tried, what worked and what not
[19:00] <wrapster> geser: i looked at the make file nothing like that specified
[19:00] <wrapster> geser: oh.. well forget about that nspr thing for now.. its all working fine..
[19:01] <wrapster> and in nss there is nothing much i changed apart form -m64 being added to the rules file.
[19:01] <wrapster> thats all..
[19:01] <wrapster> with this im hoping that individually at least I can first build it then I will think about including both...
[19:03] <geser> what did you do that nspr linked a 64bit lib (instead of a 32bit one), or didn't you need to change anything for it?
[19:06] <asomething> If anyone from MOTU-Release is around and has time to look at Bug #460462, I'd appriecieate it.
[19:15] <ScottK> asomething: Yes.  Please.
[19:16] <asomething> ScottK: Thanks!
[19:31] <JontheEchidna> ScottK: does opengtl need updating?
[19:32] <JontheEchidna> in regard to bug 460345
[19:32] <ScottK> doko_: ^^^
[19:32] <ScottK> He'd know
[19:33] <JontheEchidna> looks like 0.9.11 is required for llvm 2.6
[19:33] <JontheEchidna> http://www.opengtl.org/Download.html <- as referenced here
[19:34] <JontheEchidna> I believe that koffice2 and darkroom will need rebuilt for the new .so version
[19:34] <ScottK> Argh.
[19:34] <ScottK> OK.
[19:34] <ScottK> doko_: ?
[19:35] <JontheEchidna> (I did a gtl transition earlier this cycle)
[19:35] <ScottK> OK.  Hopefully doko answers soon.
[19:36] <JontheEchidna> doko_: if need be, I can take care of opengtl and its rdepends
[19:38] <JontheEchidna> I would have updated opengtl earlier on, but it's very finicky about what it considers llvm 2.6, and I did not have time to make the detection consider our snapshot 2.6
[19:38] <ScottK> Right, well the 2.6 upload just got done today.
[19:39] <fabrice_sp> ScottK, what about bug #461286?
[19:39] <ScottK> Looking
[19:40] <ScottK> fabrice_sp: If you've tested it and think it's good, I'm good.
[19:40] <randomaction> Got a couple of FTBFS fixes: bug 461373 and bug 461375
[19:40] <fabrice_sp> ScottK, I'll test it. Test building now
[19:42] <ScottK> randomaction: Yes.  Please.
[19:43] <ScottK> Anyone around who can sponsor 461373 and 375?
[19:46] <Laney> bug 461373 bug 461375
[19:47] <asomething> ScottK: If you provide the motu-release acks, I'll test and sponsor the uploads
[19:47] <Laney> already looking at 373
[19:47] <Laney> you can take the other one, AndrewGee
[19:47] <ScottK> Ack for both of them.
[19:47] <Laney> asomething: *
[19:48] <asomething> Laney: ok, i'll take 461375
[19:51] <sistpoty|work> ScottK: I think I've got an extremely ugly you-don't-even-want-to-think-about-it workaround to make klamav build
[19:51] <ScottK> sistpoty|work: Cool.  What?
[19:51] <ScottK> extremely ugly don't want to think about it permeates the code
[19:51] <sistpoty|work> ScottK: fiddling a bit with admin/ltmain.sh and removing some of the strange rpath logic there... let me paste it somewhere
[19:51] <ScottK> Thanks.
[19:53] <Laney> kobodeluxe uploaded
[19:53] <ScottK> didrocks: Are you still doing gnoemeo?
[19:53] <ScottK> Thanks
[19:54] <didrocks> ScottK: I'm just back from work, so I can work on it now
[19:55] <ScottK> Excellent.  Thanks.
[19:55] <sistpoty|work> ScottK: http://paste.ubuntu.com/302267/
[19:55] <sistpoty|work> ScottK: I think you need only the 3rd hunk from it
[19:56] <sistpoty|work> (the other ones were tries that didn't work)
[19:56] <ScottK> sistpoty|work: Building without the rpath defined is 'better' anyway, isn't it?
[19:56] <sistpoty|work> ScottK: I hope it doesn't actually need rpath somewhere? then klamav would probably be broken by it
[19:56] <sistpoty|work> ScottK: not if it uses private shared objects (e.g. in /usr/lib/klamav)
[19:57] <sistpoty|work> at least I think I've read something on debian-devel that it's ok to do that nowadays
[20:02] <ScottK> We'll try it and see.
[20:04] <sistpoty|work> ScottK: the 3rd hunk is indeed enough, just did a cleaner test-build again
[20:04] <ScottK> Thanks.
[20:06] <asomething> knmap uploaded. Thanks randomaction!
[20:06] <randomaction> thanks for quick acks and uploads :)
[20:07] <ScottK> JontheEchidna: If doko doesn't answer, use your best judgement about uploading stuff and let me know.
[20:09] <ajmitch> ScottK: when's close-off for uploads?
[20:11] <ScottK> jwilk: https://launchpad.net/ubuntu/+archive/test-rebuild-20090909/+build/1228820/+files/buildlog_ubuntu-karmic-i386.python-goopy_0.1-3_FAILEDTOBUILD.txt.gz
[20:11] <ScottK> ajmitch: 1200 UTC on Tuesday for unseeded packages in Universe/Multiverse.  For seeded stuff unless it's urgent enough for an ISO respin, it's too late.
[20:11] <ScottK> Eventually got the right message on the right channel
[20:12] <ajmitch> ScottK: it's ok, I'm in there as well
[20:12] <ajmitch> so pretty much just the next few hours
[20:13] <ScottK> Over 15.
[20:13] <ScottK> That's not so bad.
[20:16] <ajmitch> yeah, stuff like that boost issue just came up in #nzpug after some people upgraded to karmic
[20:17] <fabrice_sp> htcheck uploaded
[20:18]  * sistpoty|work must go home now... cya
[20:19] <ScottK> ajmitch: Did anyone ever find a patch for that (it'll have to go to updates now)?
[20:19] <ScottK> fabrice_sp: Thanks.
[20:21] <ScottK> Any MOTU can look at 461300 and 461338?
[20:21] <didrocks> ScottK: gnoemoe sponsored
[20:22] <ScottK> didrocks: Thanks.  Can you look at ^^^
[20:22] <didrocks> yeah, taking first one :)
[20:22]  * sebner steps in for the second one
[20:22] <JontheEchidna> wow, too fast :D
[20:23] <sebner> Laney: ah do you do it?
[20:24] <ScottK> OK 461234
[20:24] <ScottK> Who's up for htat?
[20:24] <ScottK> that
[20:25] <ajmitch> ScottK: no I didn't find one yet
[20:25] <ScottK> urgh.  ok
[20:26] <JontheEchidna> I can take 461234
[20:26] <ajmitch> yeah sorry, I'll try & hunt over the next couple of days so we can get a SRU ready for it
[20:26] <sebner> If sebner just would know how to work with bzr and branches xD
[20:26] <Laney> I wonder how to sponsor from branches indeed
[20:27] <ScottK> sebner: There's a link to pull a diff
[20:27] <sebner> heh
[20:27] <Laney> isn't there a proper (bzr) way?
[20:27] <sebner> ScottK: Yeah, uploading the package is not the problem but merging the branch with the fix etc
[20:27] <didrocks> sebner: I generally use: bzr bd debuild -- -S -k…
[20:28] <didrocks> oh, merging the branch. I dunno too :/
[20:28] <asac> ScottK: is there a bfilter upload or something for a while in unapproaved?
[20:28] <asac> a while == 1 week
[20:29] <ScottK> asac: No
[20:29] <asac> hmm
[20:30] <asac> ok need to upload then i guess.
[20:30] <asac> you said something about locked archive? isnt it manual review now?
[20:30] <sebner> asac is *teehh* bzr hero
[20:30] <asac> haha
[20:30] <asac> i would think that its got rejected
[20:30] <asac> ;)
[20:30] <sebner> Laney: do you search for a proper solution or only care to get the fix into the archive?
[20:30] <ScottK> asac: For stuff on an ISO it needs to go to proposed.  For unseeded stuff there's 15 hours
[20:31] <Laney> sebner: what?
[20:31] <ScottK> sebner: Today get it in the archive.
[20:31] <sebner> aye aye
[20:31] <asac> ScottK: 15 hours?
[20:31] <asac> the archive gets locked down hard?
[20:31] <ScottK> asac: 1200UTC tomorrow is when we stop.
[20:31] <sebner> Laney: do you do 461338?
[20:31] <asac> stop everything?
[20:32] <asac> is that new?
[20:32] <Laney> if I set it as in progress
[20:32] <ScottK> asac: There's a 12 hour OMG window after that for Ubuntu Release, but MOTU Release won't approve anything else.
[20:32] <sebner> Laney: so yes I suppose
[20:32] <sebner> ScottK: might delegating another sponsorship task to me?
[20:32] <sebner> *mind
[20:32] <Laney> chillax then
[20:32] <Laney> sebner: just do the list
[20:32] <ScottK> sebner: That's all I got.  Go fix some FTBFS.
[20:33] <sebner> Ok :)
[20:33] <ScottK> asac: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-October/000634.html <- Is actually later than we've done ever before.
[20:33] <asac> ScottK: is that new? why do we prevent two days of universe fixes?
[20:33] <asac> hmm
[20:33] <asac> odd
[20:33] <asac> ok
[20:33] <ScottK> asac: Normally we freeze on Sunday.
[20:34] <ScottK> Thanks to security in soyuz though we don't need 3 days to copy the archive to dak.
[20:34] <asac> yeah. but freeze means for me: "manually approvable"
[20:34] <asac> yeah
[20:34] <asac> ok
[20:34] <ScottK> Then we're frozen now.
[20:34] <asac> i think we have two more uploads then
[20:34] <asac> or three
[20:34] <ScottK> OK.
[20:34] <asac> today
[20:34] <asac> all
[20:34] <ScottK> Good
[20:36] <didrocks> ScottK: klogic uploaded
[20:36] <ScottK> Excellent.
[20:39] <Laney> hmm
[20:40] <JontheEchidna> jargoninformatique uploaded
[20:40] <ScottK> Thanks
[20:49] <sebner> ScottK: do you get to the approval list anyways or should we ping you?
[20:50] <sebner> ScottK: ah nuke python-happydoc please
[20:51] <Laney> kdbg done
[20:51]  * Laney -> out
[20:51] <fabrice_sp> I've fixed a FTBFS in a package (libcsfml). Should I upload it, and request review here, or create a bug report?
[20:53] <sebner> fabrice_sp: just upload and ScottK will approve it
[20:54] <fabrice_sp> ok
[20:56] <ScottK> fabrice_sp: That's fine.  If you can pastebin me the diff, that'd be nice too.
[20:57] <fabrice_sp> ScottK, http://pastebin.ubuntu.com/302306/
[20:57] <fabrice_sp> (for libcsfml upload)
[20:58] <ScottK> fabrice_sp: Ack.  Go for it.
[20:58] <sebner> ScottK: please reject python-happydoc :)
[20:58] <ScottK> sebner: Will do
[20:58] <sebner> thx
[20:59] <fabrice_sp> thanks :-)
[20:59] <ScottK> sebner: Somewhat interestingly I looked at that and thought I better test build it myself before accepting ....
[21:00] <sebner> ScottK: Now you can accept
[21:00] <sebner> ScottK: hmm? I fixed the changelog. testbuilt myself of course
[21:00] <ScottK> sebner: OK.
[21:00] <sebner> ScottK: you are free to give it another test of course :)
[21:00] <ari-tczew> hello, I need ask someone from MOTU
[21:01] <sebner> ari-tczew: just ask ;)
[21:01] <ari-tczew> I'm looking at packages.ubuntu.com for drupal5
[21:01] <ari-tczew> there is 5.15-1ubuntu1.1 on jaunty
[21:01] <ari-tczew> but if I click on changelog
[21:02] <ari-tczew> The requested URL /changelogs/pool/universe/d/drupal5/drupal5_5.15-1ubuntu1.1/changelog was not found on this server.
[21:02] <ari-tczew> note: package built fine today
[21:02] <ScottK> I've seen at least one use of ${py_setup_install_args} not go well today, so I'm being careful
[21:02] <sebner> ScottK: ah, ok. np
[21:02] <ari-tczew> what is wrong?
[21:02] <ScottK> ari-tczew: It takes some time to get there
[21:02] <sebner> ScottK: I usually testbuild stuff myself before uploading *anything* though ;)
[21:02] <ajmitch> just look at the changelog on launchpad instead
[21:03] <ScottK> sebner: Certainly.  It's just I'm extra paranoid on the last day
[21:03] <ari-tczew> "software related to..." doesn't have this info too
[21:03] <sebner> heh
[21:04] <ajmitch> https://edge.launchpad.net/ubuntu/+source/drupal5 has it, I don't know how often the changelogs are extracted for the site you're looking at
[21:07] <ScottK> sebner: It's (as you expected) fine.  Thanks.
[21:07] <sebner> ScottK: heh, really np. Please stay that paranoid as it's really the last day. :)
[21:08] <JontheEchidna> erm
[21:08] <JontheEchidna> crap: http://paste.ubuntu.com/302311/
[21:09] <ajmitch> that don't look so hot
[21:09] <ari-tczew> I just wonder why these packages are not exist in my page on launchpad as "Software related to..."
[21:10] <ajmitch> maybe because it's a sponsored security upload, there could be special stuff around that
[21:11] <ajmitch> you'd have to find out from #launchpad
[21:12] <JontheEchidna> opengtl is an optional dependency in both cases. If worse comes to worse we can drop them as build-depends from both darkroom and koffice2
[21:13] <ScottK> JontheEchidna: Upstream have patches?
[21:15] <JontheEchidna> looks like a 0.9.12 release is due pretty soon
[21:17] <JontheEchidna> oh, no it's not
[21:17] <JontheEchidna> no patches upstream
[21:17]  * JontheEchidna -> dinner
[21:18] <sebner> ScottK: do we prefer syncs still over manual uploads
[21:18] <sebner> +?
[21:19] <ScottK> sebner: Generally.
[21:19] <fabrice_sp> ScottK, http://pastebin.ubuntu.com/302316/ ?
[21:20] <ScottK> fabrice_sp: Ack.  Go for it.
[21:20] <ScottK> sebner: If it needs a manual upload, let me do it.
[21:21] <sebner> ScottK: I just filed the sync request. Give me a sec to fetch the bug number
[21:21] <ScottK> 461451, right?
[21:21] <sebner> good catch ;)
[21:22] <sebner> ScottK: dpkg-deb: building package `pygopherd' in `../pygopherd_<IP_ADDRESS>+nmu2_all.deb'.
[21:22] <sebner> saves you the time of testbuilding
[21:25] <ScottK> sebner: I've asked to have it sync'ed.  I'll do it manually later if needed.
[21:25] <sebner> k
[21:27] <asac> ScottK: so sugar-hulahop and helix-player with xulrunner-1.9.1 switch uploaded
[21:27] <ScottK> asac: Thanks.
[21:33] <asac> ScottK: also one more one line fix for bindwood ... thanks and sorry. i think thats it.
[21:33] <asac> for me ;)
[21:35] <sebner> ScottK: another ${py_setup_install_args} for you to test :D
[21:35] <ScottK> sebner: Now that I saw one work, I'll believe you.
[21:35] <ScottK> asac: OK.
[21:36] <sebner> ScottK: Trust is good, control is better :) gnahh I testbuild so thx ^^
[21:36] <ScottK> Debian put out a DSA for nginx today.  Would someone check and see if we have the fix.
[21:37] <ScottK> sebner: Just pastebin me the diff
[21:38] <sebner> ScottK: hihi, http://paste.ubuntu.com/302330/  with  dpkg-deb: building package `pympd' in `../pympd_0.07-1.2ubuntu1_all.deb'.
[21:38] <ScottK> sebner: Ack.  Go for it.
[21:39] <sebner> ScottK: thx, We should have made a "Fix python FTBFS" too as most of them are not that hard to fix
[21:39] <ScottK> I'm off for a while.  Any motu-release can ack uploads and I'll accept them when I get back.
[22:08] <doko_> JontheEchidna, ScottK: go ahead, it's better than having a non-working version
[22:08] <ScottK> OK
[22:09] <JontheEchidna> Go ahead with which solution?
[22:09] <ScottK> doko_: ^^^
[22:14] <doko_> ScottK: the opengtl update?
[22:14] <ScottK> doko_: Except that didn't work.
[22:14] <ScottK> doko_:  http://paste.ubuntu.com/302311/
[22:16] <doko_> ahh, ok
[22:17] <doko_> hmm, but supported by llvm ...
[22:17] <JontheEchidna> come to think of it, things worked fine before the check, at least compiling-wise
[22:18] <JontheEchidna> nevermind, the check came 7 months ago
[22:26] <vadi2> Hi, I'm getting this error when trying to use debuild: "Enter passphrase: gpg: gpg-agent is not available in this session"
[22:26] <vadi2> Anyone know how to fix it?
[22:41] <ari-tczew> valdi2: have you got installed: gpgv libgpgme11 pinentry-gtk2 ?
[22:42] <sebner> ScottK: http://paste.ubuntu.com/302371/
[22:42] <sebner> ScottK: already uploaded of course ^^
[22:42] <ScottK> sebner: Ack
[22:42] <sebner> :)
[22:43] <micahg> ScottK: if helix-player fails to build with the latest python and is 2 years old, is it worth trying to build the latest version (also no longer in debian)
[22:44] <ScottK> micahg: Depends on how hard it is.  Generally Python FTBFS aren't hard.  At this point I'd rather fix it than remove it.
[22:44] <micahg> well, it was removed from debian 2 years ago, so I think Ubuntu chose to keep it
[22:44] <vadi2> ari-tczew: no, but I installed it now and the same thing
[22:45] <vadi2> ari-tczew: before, seahorse would pop-up a dialog for me... I reinstalled, and it's not anymore
[22:46] <ari-tczew> please restart system
[22:46] <ari-tczew> and test again
[22:49] <vadi2> ok, brb
[22:54] <vadi2> ari-tczew: thanks mate, that worked. would it be a bug that devscripts didn't install that stuff?
[22:55] <ari-tczew> hmmm
[22:55] <ari-tczew> have you got time now?
[22:55] <ari-tczew> we need check depends
[22:56] <vadi2> I'm taking a break, yeah
[22:56] <ari-tczew> but remember: packages in universe cannot depends on main
[22:56] <ari-tczew> valdi2: have you got installed gnupg-agent now ?
[22:56] <vadi2> yep
[22:58] <ari-tczew> which packages you not have installed from: gpgv libgpgme11 pinentry-gtk2
[22:58] <ari-tczew> ?
[22:59] <vadi2> I installed them all
[22:59] <ari-tczew> please check separately them
[23:00] <ari-tczew> e.g. uninstall gpgv and test - reproduce
[23:00] <vadi2> uninstalling gpgv would remove too much stuff. it must have been already installed
[23:00] <ari-tczew> this way we can learn which package is needed to work
[23:01] <ScottK> vadi2: It's by design that devscripts does not install everything needed for every script.  It would pull in a huge amount if it did.
[23:01] <vadi2> and removing libgpgme11 removes seahorse... but it was already installed.
[23:01] <vadi2> ScottK: but don't people have to sign packages normally?
[23:01] <ScottK> vadi2: Yes, but they don't need devscripts to do that.
[23:02] <ScottK> devscripts just provides some wrappers that make it easier.
[23:02] <vadi2> eh. Well, the problem was pretty cryptic for me, just wondering about a solution for others
[23:03] <sebner> ScottK: http://paste.ubuntu.com/302390/
[23:03] <ScottK> sebner: Ack.
[23:04] <ari-tczew> normal user doesn't have time and skill to searching where is the problem :(
[23:59]  * ScottK wonders where all the FTBFS fixers went?