[00:01] <loic-m> salty-horse: Last time I checked, Jaunty uses the native amd64 beta
[00:02] <salty-horse> loic-m, http://packages.ubuntu.com/jaunty/flashplugin-nonfree says it depends on nspluginwrapper  (>= 0.9.91.4-2ubuntu1) [amd64]
[00:03] <loic-m> salty-horse: I dunnon, i just now it dl and install the amd64 beta
[00:05] <salty-horse> do you have nspluginwrapper installed?
[00:08] <loic-m> no
[00:09] <loic-m> on my system, it doesn't depends on ndiswrapper
[00:11] <salty-horse> how odd
[00:11] <loic-m> however I've got 3ubuntu2, not 3ubuntu3, there's been a change, see the changelog and you'll get your answer
[00:11] <loic-m> http://changelogs.ubuntu.com/changelogs/pool/multiverse/f/flashplugin-nonfree/flashplugin-nonfree_10.0.15.3ubuntu3/changelog
[00:13] <salty-horse> I don't see the answer.. :) it still claims to require nspluginwrapper ...
[00:13] <salty-horse> oh oh
[00:13] <salty-horse> ok
[00:13] <salty-horse> haven't looked at 3ubuntu2 :)
[00:14] <salty-horse> I wonder why the change was reverted. asac?
[00:15] <asac> salty-horse: thats ok. when it is final we will pull the native binary from archive.canonical
[00:16] <asac> the native thing comes from adobe.com which is error prone
[00:16] <asac> as there is no stable link for versions
[00:16] <salty-horse> I'm using it, and getting a better experience than with nspluginwrapper
[00:16] <salty-horse> somtimes the sound stops and I have to restart it, but still a better experience
[00:16] <directhex> salty-horse, you don't like grey rectangles?
[00:16] <loic-m> salty-horse: the change wasn't reverted. If you look at the changelog, it's still using native amd64 flash, the problem was AFAIU that it still need ia32 libs
[00:16] <asac> you didnt listen what i said ;)
[00:16] <asac> native has no stable link ;)
[00:17] <asac> like in URI
[00:17] <asac> salty-horse: which version of nspluginwrapper are you using?
[00:17] <salty-horse> asac, well, I'm reading you, and I didn't understand :)
[00:17] <asac> works nice here in its latest form ;)
[00:17] <asac> salty-horse: good. understood?
[00:17] <salty-horse> I'm not using it ever since the native client came out :)
[00:17] <asac> salty-horse: right. try it and you will see ;)
[00:18] <asac> better than native ;) ... you can kill npviewer if it consumes too much mem
[00:19] <salty-horse> asac, that's right, but then I don't have flash in *any* website.. not just the offending one :) besides, now I have a new computer and I don't mind restarting firefox with all of it's tabs.
[00:19] <loic-m> salty-horse: are you on Jaunty amd64 now?
[00:19] <salty-horse> yes
[00:19] <asac> salty-horse: reloading pages should start it again. doesnt it?
[00:19] <loic-m> salty-horse: do you see grey rectangles instead of video?
[00:20] <salty-horse> didn't use to, AFAIR
[00:20] <asac> loic-m: you see that with native or our package?
[00:20] <salty-horse> loic-m, I put the native one in ~/.mozilla/plugin and it works just fine
[00:20] <salty-horse> that's ~/.mozilla/plugins
[00:20] <loic-m> salty-horse: do you see grey rectangles with -3ubuntu3?
[00:21] <salty-horse> loic-m, never used it. want me to test?
[00:21] <asac> for me youtube works ;)
[00:21] <loic-m> asac: grey rectangles are there when using 32bits flash on amd64
[00:21] <salty-horse> asac, I always test with homestarrunner.com :)
[00:21] <loic-m> salty-horse: if you can, yes please
[00:21] <salty-horse> downloading the specific package..
[00:22] <asac> loic-m: you mean you dont see anything or just artifacts?
[00:22] <loic-m> asac: 32bits flash on amd64 works once out of ten, which means you need to reload the page at least 10 times before you see anything
[00:22] <loic-m> asac: 64bits flash on amd64 works all the time
[00:22] <asac> k
[00:22] <directhex> ctrl-f5 is your friend!
[00:22] <asac> didnt experience something like that for ages
[00:23] <loic-m> directhex: that, and unlimited patience
[00:23] <salty-horse> loic-m, why aren't you using the latest version?
[00:23] <loic-m> asac: me neither since i've been on native flash ;)
[00:23] <asac> loic-m: maybe your install is wrong?
[00:24] <asac> could be that the wrapper took your native plugin and tried to wrap that miserably ;)
[00:24] <loic-m> salty-horse: I'm on intrepid. i use backported packages, and didn't even know there was a new version in Jaunty
[00:24] <directhex> flash in general has exploded much less for me since i worked around bug 286119
[00:24] <ubottu> Launchpad bug 286119 in samba "firefox 3.0.3 crashes (no SIG) on most pages w/ images when using nss_wins: 8.10beta AMD64" [High,Fix committed] https://launchpad.net/bugs/286119
[00:24] <asac> loic-m: if you are on intrepid you should try the jaunty nspluginwrapper
[00:24] <asac> that should work mostly flawless ;)
[00:24] <salty-horse> loic-m, so do you still want to test it? :)
[00:24] <directhex> if you're on jaunty you should try the jaunty moonlight-plugin-mozilla!
[00:24] <loic-m> asac: nope, that's flash 32 bits expected behavior on amd64, since ages. Don't know if it's better in Jaunty though
[00:25] <salty-horse> directhex, is that  moonlight 2.0?
[00:25] <directhex> salty-horse, nay, only 1.0 for now
[00:25] <salty-horse> :(
[00:25] <asac> loic-m: its for sure. as i said i havent seen something like that for ages here
[00:25] <loic-m> asac: why would I when -3ubuntu2 is native and works flawlessly?
[00:25] <directhex> salty-horse, i'm in daily contact with upstream - trust me, 1.0 is best for now
[00:25] <salty-horse> directhex, well, it's already packaged nicely as an extension :)
[00:26] <asac> loic-m: until adobe changes the binary ;) ... then things blow up. thats why we cant use it yet
[00:26] <loic-m> salty-horse: nope, if it's confirmed -3ubuntu3 uses 32 bits flash, I'd rather stay far from the pain.
[00:26] <salty-horse> explosions are pretty
[00:26] <salty-horse> thank you, loic-m :)
[00:26] <asac> loic-m: take nspluginwrapper too ;) and you will like it
[00:26] <asac> backports i mean
[00:27] <loic-m> asac: I've got the binary on my install, and adobe ain't gonna change it
[00:27] <asac> yes, but not for new installs or upgraders
[00:27] <loic-m> asac: I don't support running 32bits app under amd64
[00:27] <directhex> salty-horse, also an option. depends on whether you want to use the MS binary codecs, really
[00:28] <loic-m> asac: that's ok. For me, if there's no reason to share the pain, I'd rather enjoy web browsing instead
[00:28] <salty-horse> directhex, I'm not that much of a purist to mind
[00:29] <loic-m> I'm not a purist either, but we've been asking for 64 bits flash enough not to  want to go back to square one
[00:29] <loic-m> 32bits flash is so 2008
=== nhandler_ is now known as nhandler
[01:05] <fruchtix> slangasek: and because you asked for a statement like that in such a nice way: Catspaw (insanecats.com) is a modern woman who stands up for women rights. and she qualifies for that role. because she does not play with men like your darling helix
[01:05] <slangasek> fruchtix: that would be off-topic here
[01:06] <fruchtix> slangasek: as i said, you asked for it in such a nice way
[01:07] <fruchtix> slangasek: maybe you should swing from girl (helix) to a real woman who teaches you about the power of feelings, emotions and social behaviour
[01:07] <slangasek> !ops
[01:07] <ubottu> Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpatrick!
[01:08] <ajmitch> thanks Hobbsee
[01:08] <Hobbsee> slangasek: nice timing!  I just managed to poke holes thru the uni firewall, too
[01:08] <slangasek> heh
[01:09] <ajmitch> slangasek: fwiw chanserv says you can boot trolls from here as well
[01:09]  * Hobbsee dumps the guy on ignore
[01:09] <slangasek> oh
[01:09] <slangasek> right, someone did stick me with ops here, didn't they
[01:09] <Hobbsee> yeah
[01:09] <Hobbsee> that was probably me
[01:09]  * slangasek files that away in a different part of his brain for reference
[01:09] <slangasek> I believe so :)
[01:10] <Hobbsee> man, this guy is a complete nutter
[01:11] <directhex> and seems to hate erinn for some reason
[01:11] <Hobbsee> hates me too
[01:11] <mrooney> Should I be using requestsync for packages not in Debian and if so, how?
[01:11] <directhex> mrooney, how "not in debian" is "not in debian"? some major third party repo?
[01:12] <mrooney> directhex: I mean, it is in Jaunty universe as an -0ubuntu1 package
[01:12] <mrooney> and I need an upstream sync
[01:12] <directhex> mrooney, oh, well no, you need to prepare that yourself
[01:12] <mrooney> directhex: okay, any instructions for that?
[01:13] <directhex> probably on the wiki. my helpfulness tails off past 1am. sorry
[01:25] <mrooney> Okay, I am looking at https://wiki.ubuntu.com/SyncRequestProcess, I don't see anything for non-Debian packages
[01:25] <mrooney> I can file a sync request and see what happens!
[01:26] <RAOF> Where is it that you're syncing from?
[01:26] <directhex> what happens: bug marked invalid?
[01:26] <directhex> RAOF, nowhere. he wants an uupdate
[01:26] <directhex> RAOF, on a 0ubuntu1
[01:26] <RAOF> Oh.
[01:27] <directhex> mrooney, did you notice feature freeze? is this a bugfix release?
[01:27] <slangasek> mrooney: "sync" refers to "there is an existing package that we can pull into the archive".  If you're updating a package to a new upstream version, how is that a sync?
[01:32] <mneptok> slangasek: ooo! OOOOOO! i'll teach you! PICK ME!
[01:32] <slangasek> mneptok: about the power of feelings, emotions and social behaviour?
[01:32]  * Hobbsee snorts
[01:33]  * mneptok preens Hobbsee 
[01:33] <mneptok> slangasek: mrf mmmff hrrmmm yeah *preen*preen*
[01:33]  * Hobbsee pets the crazy mneptok
[01:34] <directhex> i'm confused :|
[01:34] <mneptok> or we could click like dolphins. or the ant-thing (but i hate the exertion).
[01:34] <directhex> i think i'll just go to bed
[01:36] <josephpiche> I have a question: there is a package (gnugo) that I would like build a deb for and put in a PPA. I know how to build the software normally (using make), but I don't know how to actually package it
[01:37] <josephpiche> is there a wiki page or or something that would help me?
[01:37] <RAOF> !packagingguide
[01:37] <ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[01:37] <RAOF> josephpiche: Yes. ^^^
[01:37] <josephpiche> sweet, thanks
[01:46] <mrooney> slangasek: well it is a sync with upstream
[01:46]  * Yagisan catches up on the scrollback and wonders how anyone could hate Hobbsee 
[01:46] <mrooney> I assumed the term "sync" derives from synchronizing the ubuntu version with its source
[01:46] <StevenK> But it isn't a sync in Ubuntu nomenclature
[01:47] <mrooney> okay
[01:47] <Hobbsee> Yagisan: because he's paddy frank, and i'm female.  There is no other reason
[01:47] <StevenK> mrooney: No, the term sync is synchronizing from Debian
[01:47] <mrooney> okay, that makes sense, now that I know
[01:47] <mrooney> so what should the bug report look like before subscribing universe sponsors?
[01:47] <mrooney> here is what I came with: bug 333639
[01:47] <ubottu> Launchpad bug 333639 in wxbanker "Please sync wxbanker 0.4.1.0" [Undecided,New] https://launchpad.net/bugs/333639
[01:47] <mrooney> I see now I should change the title
[01:48] <slangasek> Hobbsee: s/female/an op/, I think :)
[01:48] <Yagisan> Hobbsee, oh - I know your female - I vaguely recall meeting you when I was still young and optimistic ;)
[01:48] <StevenK> Haha
[01:49] <Hobbsee> slangasek: oh, was that it.  I got targetted in a very "you are female" way in PM, so i just assumed it was that
[01:49] <Hobbsee> Yagisan: heh :)
[01:50] <mrooney> StevenK: should I use "update" instead of "sync"?
[01:50] <slangasek> Hobbsee: I believe that's tactical rather than indicative of his agenda
[01:50] <ajmitch> Yagisan: back many years ago?
[01:50] <Hobbsee> slangasek: you might be right there
[01:50] <StevenK> mrooney: Yup
[01:50] <slangasek> mrooney: that would be clearer, yes; and that would go through the generic sponsorship process
[01:50] <Yagisan> ajmitch, yep - way back then. I must say, my beloved Ubuntu shirt is starting to wear out. Time for a new one I think.
[01:51] <StevenK> I'm still trying to work out his agenda, but I don't think even he knows
[01:51] <mrooney> slangasek: okay so, sync -> update, and subscribe u-u-s?
[01:51] <slangasek> mrooney: yes
[01:51] <mrooney> excellent, thanks!
[01:52] <slangasek> mrooney: as mentioned earlier, please check that if your request needs a feature freeze exception, that the bug report includes all of that relevant information
[01:52]  * Yagisan 's eyes glaze over as all these messages about update-manager pour into his inbox.
[01:52] <slangasek> StevenK: I know but I'm not telling
[01:52] <mrooney> slangasek: okay, it is only a bugfix and translation update, I assume it doesn't require one?
[01:53] <slangasek> mrooney: "bugfix" is fuzzy - but I assume a sponsor will take it up with you if more detail is needed :)
[01:53] <mrooney> okay thanks again :)
[01:54] <mrooney> slangasek: okay one last question, I see people add comments when they subscribe sponsors like "subscribing u-u-s...", should I add one afterwards as well, or is that not important
[01:55] <Yagisan> ajmitch, it's been so long since I last saw you - my little girl started school (and my $%#$%#%$#%$ uni degree still isn't over :( )
[01:55] <slangasek> mrooney: not important - the subscription itself triggers mail to the appropriate parties
[01:55] <slangasek> mrooney: if *I* subscribe u-u-s to a bug, I comment to let the submitter know why it's happening
[01:56] <ajmitch> Yagisan: yeah, it has been awhile
[01:59] <Yagisan> ajmitch, /me had, then come x-mas, didn't have a nice job as a sys-admin for Ubuntu boxes. People are still running Fiesty boxen on their networks.
[02:00]  * ajmitch thinks the oldest install here is probably gutsy by now
[02:00] <ajmitch> though last I looked, that computer didn't even boot :)
[02:01] <Yagisan> ajmitch, well, suggesting they go to hardy instead of making a franken-fiesty box didn't go down well. OTOH was nice to have an Ubuntu related job
[02:02] <ajmitch> apart from that, you've just been studying?
[02:02] <ajmitch> plenty of time to work on ubuntu then...
[02:02] <Yagisan> ha - I wish
[02:03] <Yagisan> enough time to realise jumping on jaunty right now would probably annoy me
[02:03] <StevenK> Does Jaunty want you jumping on it?
[02:04] <Yagisan> StevenK, it sure does. Isn't that how you fit it onto a CD ?
[02:04] <ajmitch> yeah, my laptop is still running hardy
[02:04] <StevenK> Yagisan: I'd have to ask slangasek
[02:04]  * Yagisan is mixed hardy/intrepid here.
[02:05] <slangasek> StevenK: jackalopes love nothing more than jumping
[02:06] <StevenK> That's *them* jumping, not them being jumped on
[02:06] <ajmitch> does it blend?
[02:06] <StevenK> My laptop was running Gardy at UDS Prague
[02:08]  * Yagisan can imagine a rabbit in a blender actually. buzzzzzzzzzzzz chunk chunk buzzzzzzzz ....
[02:10]  * Yagisan now needs to make an important decision - save some money and get a Phenom x3 for my virtual machine server, or bite the bullet and get a Phenom II x3
[02:14] <tomhinkle> Hi all -- I'm an upstream developer who recently has (inadvertently) gotten into a conflict with the upstream packager of my software (i.e. a MOTU) and I was looking for some advice. Is this an okay forum to ask questions of this kind?
[02:17] <RAOF> Absolutely.
[02:18] <RAOF> tomhinkle: What is the problem?
[02:18] <tomhinkle> The packager of my package is upset that I provide .deb files of my bleeding-edge releases for users on SF.  Is this generally discouraged? I find I have a large number of users who want to try the newest packages (more than once every 6 months) and it's handy.
[02:19] <RAOF> That should be fine; we should be able to easily filter out those bug reports.
[02:19] <RAOF> Perhaps the packager was annoyed that you have a debian/ directory in the releases you ship?
[02:20] <tomhinkle> He asked me to get rid of that when he first packaged and I did.
[02:20] <tomhinkle> Then after I realized my users were struggling to build from source, I used his debian/ directory as a basis for my own releases (he'd made a number of fixes to the packaging that I took on)
[02:20] <tomhinkle> So now I'm releasing tarballs + .debs upstream, but the tarball has no debian/ directory.
[02:20] <RAOF> Hm.  That seems strange.  I don't know why a MOTU would be complaining about that.
[02:21] <tomhinkle> Yeah, that's what I thought. He's been upset about it for a while and we exchanged e-mails -- now he's said he's going to stop packaging the software. I wanted to check if I was breaking some established norms or something.
[02:22] <RAOF> No.  Not from what you've said here.
[02:22] <Hobbsee> er, that seems reasonable
[02:22] <tomhinkle> Hrmph. Well, that's good and bad for me I guess. Good because it seems reasonable, bad because it doesn't give me any information about why he's so mad.
[02:23]  * Hobbsee agrees with RAOF about it being strange that a MOTU is complaining about it
[02:23] <ajmitch> the main reason I could see him complaining would be if the packages broke upgrades
[02:24] <ajmitch> but the packager should be able to sort through that with you
[02:24] <tomhinkle> That may be what's happened -- he mentioned the package being broken, but didn't get into specifics. He seemed to think I would just stop releasing them.
[02:25] <Hobbsee> if that's gourmet, are you aware of https://bugs.edge.launchpad.net/grecipe-manager/+bugs?
[02:25] <tomhinkle> It is and I am -- is there something in that list that sticks out as a particular problem.
[02:26] <Hobbsee> (as a somewhat unrelated statement)
[02:26] <Hobbsee> no, i just noticed it existed
[02:27] <tomhinkle> ah, I see.
[02:29] <tomhinkle> Alright -- well thanks for your input. It doesn't look like there's too much I can do at this point. I'll offer to fix any packaging errors he points out in my .deb if the problem is that they're breaking updates.
[02:32] <tonyyarusso> what's the page for figuring out what's causing a segfault again?
[06:17] <anakron> ping Laney : hey, can you see https://bugs.launchpad.net/ubuntu/+source/qcad/+bug/311476
[06:18] <ubottu> Ubuntu bug 311476 in qcad "qcad menu entry lacks a category" [Low,Triaged]
[06:18] <anakron> persia, can you look it please? https://bugs.launchpad.net/ubuntu/+source/qcad/+bug/311476
[06:18] <anakron> hi all, hi persia and Laney
[06:20] <anakron> or this one
[06:20] <anakron> https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/301603
[06:20] <ubottu> Ubuntu bug 301603 in firestarter "Impossible to launch firestarter" [Undecided,Confirmed]
[06:21] <anakron> if someone can see them and review my patches
[06:26] <anakron> and the last one
[06:26] <anakron> https://bugs.launchpad.net/ubuntu/+source/qtpfsgui/+bug/309740
[06:26] <ubottu> Ubuntu bug 309740 in qtpfsgui "no menu icon" [Undecided,Confirmed]
[06:45]  * RAOF should, perhaps, not have picked beagle as my first evolution-sharp transition upload.
[06:53] <tonyyarusso> How can I figure out the value of a variable (in C) while my program is running?
[06:53] <tonyyarusso> It's not crashing, but I suspect something isn't being set right.
[06:54] <StevenK> Use gdb?
[06:55] <dtchen_> and your friendly print
[06:56] <tonyyarusso> dtchen_: I don't really have a good place to print it, so while I could, it would likely be more work.
[06:56] <tonyyarusso> StevenK: I figured that would be involved, but I'm not familiar with gdb beyond the instructions on https://wiki.ubuntu.com/Backtrace.  Looking through output from that now to see if it's already there.
[06:56] <dtchen_> huh? meaning not even setting breakpoints is feasible?
[06:56] <StevenK> tonyyarusso: gdb supports 'print <var>'
[06:57] <tonyyarusso> oooooh, sweet
[06:57] <StevenK> tonyyarusso: Set a breakpoint and poke around
[06:57] <tonyyarusso> erm, breakpoint?  like, just 'break' in the code and kill it?
[07:00] <fabrice_sp> tonyyarusso, when needed to set a breakpoint, I use DDD
[07:00] <fabrice_sp> it's a gdb frontend
[07:01] <tonyyarusso> fabrice_sp: that's another package?
[07:01] <fabrice_sp> yes
[07:01] <fabrice_sp> called DDD :-)
[07:06] <dholbach> good morning
[07:06] <fabrice_sp> good morning dholbach ;-)
[07:06] <dholbach> hiya fabrice_sp! :-)
[07:15] <tonyyarusso> fabrice_sp: man, that interface looked more confusing, not less...
[07:17] <fabrice_sp> tonyyarusso, I myself find it more useful to go through the source, but it's as you want
[07:18] <tonyyarusso> fabrice_sp: maybe once you know how to use it?  dunno.
[07:18] <tonyyarusso> although in gdb proper I can't manage to define a break either.
[07:18] <tonyyarusso> (gdb) break save_pounce_cb
[07:18] <tonyyarusso> Function "save_pounce_cb" not defined.
[07:18] <tonyyarusso> Make breakpoint pending on future shared library load? (y or [n])
[07:21] <StevenK> tonyyarusso: No, specify the file and line number
[07:24] <tonyyarusso> StevenK: that gives me "No source file named gntpounce.c"
[07:28] <tonyyarusso> oh, I suppose it needs a path to it.
[07:28] <tonyyarusso> nope, not that either
[07:31] <ara> morning!
[07:36] <tonyyarusso> StevenK: do you know what that would mean?
[07:41] <hyperair> hey what happened to revu? it seems to have disappeared
[07:41] <hyperair> $ host revu.ubuntuwire.com
[07:41] <hyperair> Host revu.ubuntuwire.com not found: 2(SERVFAIL)
[07:58] <savvas> ScottK: any other packages in order to remove boost 1.34 completely?:)
[08:07] <mok0> hyperair: try revu.tauware.de
[09:36] <Tonio_> what happens with revu ? is it down ?
[09:37] <dholbach> Tonio_: http://revu.tauware.de/
[09:37]  * Yagisan suggests someone update the topic to pint everyone looking for revu to the .org address
[09:37] <dholbach> http://www.ubuntuwire.com/
[09:37] <ajmitch> Yagisan: you've just volunteered yourself
[09:37] <slytherin> Tonio_: use .org instead of .com
[09:38] <Tonio_> slytherin: oki
[09:38] <dholbach> slytherin: aha!
[09:38] <Tonio_> dholbach: yeah that was my problem...
[09:39] <Yagisan> ajmitch, you really want to give me op's etc ??? I may even have time to google up how to keep it
[09:39] <Tonio_> slytherin: is that permanent change ?
[09:39] <ajmitch> Yagisan: topic isn't locked
[09:40] <geser> Tonio_: AFAIR someone is working on getting .com back (it didn't got renewed)
[09:40] <dholbach> Tonio_: the .com address expired - I think sistpoty and siretart talked to imbrandon about it
[09:43] <Yagisan> ajmitch, O-o
=== Yagisan changed the topic of #ubuntu-motu to: Jaunty Feature Freeze in effect - Go fix bugs! | https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Fix RC bugs: http://qa.ubuntuwire.org/bugs/rcbugs | Help to clear NBS list: http://people.ubuntu.com/~ubuntu-archive/NBS/ | Revu is at http://revu.ubuntuwire.org/
[09:44] <Yagisan> ajmitch, better ?
[09:44] <Tonio_> dholbach, geser: oki
[09:45] <ajmitch> Yagisan: I guess :)
[09:54] <savvas> is there a team for lpia builds?
[09:58] <hyperair> mok0: okay i will thanks
[10:00] <mok0> hyperair: .org works too
[10:05] <slytherin> savvas: AFAIK, no.
[10:05] <slytherin> savvas: What builds you are talking about, by the way?
[10:17] <savvas> slytherin: http://launchpad.net/~medigeek/+archive/ppa/+build/880883 - libatlas-base-dev dependency is missing
[10:22] <slytherin> savvas: the build has failed on lpia - https://edge.launchpad.net/ubuntu/jaunty/+source/atlas/+builds See if you can debug the build failure.
[10:22] <savvas> slytherin: ah, thanks, I'll take a peek :)
[10:45]  * slytherin loves solving recursive FTBFS. :-D
=== korn_ is now known as c_korn
[11:15] <ScottK> savvas: cgal and btk-core I think are the only two.
[11:17] <hggdh> dholbach, ping
[11:17] <dholbach> hggdh: pong
[11:18] <hggdh> good morning -- question: a get-orig-source is expected to be a manual target, correct?
[11:19] <hggdh> dholbach, ^^
[11:21] <dholbach> hggdh: yep
[11:24] <hggdh> dholbach, k. another: although a build usually is not expected to run automake/conf/etc, should I adjust configure.in also?
[11:24] <dholbach> hggdh: in which way to you want to adjust it?
[11:25] <hggdh> dholbach, bloody thing recreates ./debian/changelog, among others
[11:25] <hggdh> so I wanted tp make sure it does not
[11:26] <hggdh> and I was getting  tired of seeing my ./debian/changelog vanishing on each make
[11:27] <dholbach> ahhhhhhhhh, that's that thing where upstream does their own debian/ stuff
[11:28] <dholbach> sounds like a good idea to add a patch that modifies configure.in to not do that - indeed
[11:29] <hggdh> dholbach, thank you. Should have a new source package in a few
[11:29] <savvas> anyone else having problems with gmail?
[11:29] <dholbach> hggdh: excellent
[11:33] <hggdh> savvas, gmail is working here (3 accounts)
[11:33] <hggdh> savvas, correction: *was* working :-(
[11:34] <savvas> heh
[11:34] <savvas> :)
[11:34] <savvas> hggdh: 502 error?
[11:38] <savvas> ScottK: ok, sent patch for cgal: bug 331911 - I don't know how much luck mok0 had with upstream about btk-core, but I'm trying out a patch for boost1.35 anyway: http://launchpad.net/~medigeek/+archive/ppa/+builds?build_text=&build_state=building
[11:38] <ubottu> Launchpad bug 331911 in cgal "FTBFS on Jaunty" [High,New] https://launchpad.net/bugs/331911
[11:38] <hggdh> savvas, I do not know (did not try via HTTP) -- I am getting  SSL negotiation failure on POP3
[11:42] <hggdh> hum. Now I am getting generic DNS resolution errors across the board
[11:42] <stefanlsd> savvas: my gmail doesnt work either
[11:43] <savvas> cc1plus: warning: unrecognized command line option "-Wno-long-double"
[11:43] <savvas> oops
=== JanC_ is now known as JanC
=== thunderstruck is now known as gnomefreak
=== thunderstruck is now known as gnomefreak
[12:45] <AnAnt> Hello, can someone help me with generating symbols control file, I understand that I should use dpkg-gensymbols, but dunno how
[12:49] <james_w> directhex/Laney: are you familiar with the evolution-sharp 5.0 transition? stefanlsd has posted debdiffs, and I just wanted to check if there was anything special to be aware of before I sponsored.
[12:49] <Laney> james_w: I think RAOF is the man for that
[12:50] <directhex> james_w, i've not been dealing with it... i think RAOF is your man
[12:50] <Laney> HIGH FIVE!
[12:50] <stefanlsd> hehe
[12:50] <james_w> heh :-)
[12:50] <directhex> in his oh-so-useful timezone
[12:50] <stefanlsd> i think thats an unanimous agreement.
[12:51] <stefanlsd> also kinda weird actually
[12:52] <james_w> stefanlsd: would you do me a favour and install the tasque that you built and have a look at https://bugs.edge.launchpad.net/ubuntu/+source/tasque/+bug/313683 and https://bugs.edge.launchpad.net/ubuntu/+source/tasque/+bug/319385 to confirm they are fixed?
[12:52] <ubottu> Ubuntu bug 313683 in tasque "Tasque 0.1.8-1 does not provide any backends" [Undecided,Confirmed]
[12:52] <stefanlsd> james_w: will do
[12:52] <directhex> sniff sniff, smells like mono-addins 0.4-2
[12:53] <directhex> no, actual evo# bugs. wheee!
[12:53] <directhex> i assume errors about things missing are caused by that ;)
[12:54] <james_w> yeah tasque could use some triage love, I suspect several of the newer bugs are this problem
[12:55] <directhex> bam! @ monodevelop
[12:55] <directhex> the last 2 addins are there now, only an ickle bit past FF
[12:56] <Laney> worketh it?
[12:56] <directhex> just in need of a loving sponsor (yes, i test-built in pbuilder)
[12:56] <Laney> did you remember to update-maintainer?!
[12:56] <directhex> for once! :o
[12:56] <Laney> !!!
[12:56] <james_w> heh
[12:56] <james_w> Laney: are you going to sponsor those?
[12:57] <Laney> not now, at work
[12:57] <Laney> feel free
[12:57] <stefanlsd> i wonder if i work more on work or more on ubuntu at work
[12:57] <Laney> actually maybe not even today if I can't fix xorg
[12:57] <directhex> stefanlsd, shhhhhhhhh!
[12:57] <Laney> heh
[12:58] <Laney> there's some kind of pancake cooking going on right outside my office door
[12:58] <Laney> but I haven't been invited :(
[12:58] <directhex> ooh, pancakes!
[12:58] <Laney> I'll just walk through reeeeeeeally slowly
[12:58] <Laney> looking hungry
[12:59] <stefanlsd> mm. tasque is actually pretty cool
[12:59] <Laney> yep
[12:59] <Laney> is evo# in debian?
[12:59] <Laney> yep
[13:00] <Laney> stefanlsd: please forward patches
[13:07] <stefanlsd> Laney: the rebuild patches for lib-evolution3.0-cil to debian?
[13:08] <Laney> stefanlsd: are there changes? I didn't check it out
[13:08] <Laney> no-change rebuilds will be ok
[13:08] <stefanlsd> Laney: yeah, no change. Just build-deps
[13:08] <Laney> ok
[13:09] <Laney> check whether RAOF will just do it himself then
[13:10] <stefanlsd> james_w: both those bugs appear to be fixed.  I do get backends.  ie.   EDS, local file and something called remember the milk
[13:11] <james_w> stefanlsd: thanks for testing
[13:11] <james_w> stefanlsd: I'll add the bug numbers to the changelog
[13:13] <directhex> stefanlsd, RTM is a website
[13:13] <directhex> http://www.rememberthemilk.com/
[13:13] <stefanlsd> directhex: yeah. figured it was some backend that would keep a task list for you
[13:14] <stefanlsd> asac: were you doing something with google gears 64?
[13:15] <asac> stefanlsd: not sure. do we have a package?
[13:15] <asac> ;)
[13:19] <stefanlsd> asac: heh. someone was saying something about it. thought it was you. (i also wanna get it in actually)
[13:20] <asac> stefanlsd: i think i commented on a packaging request?
[13:20] <asac> cant remember
[13:28] <slytherin> gmail is back. :-)
[13:32] <RainCT> Hey
[13:33] <RainCT> jpds: I've just asked - "shouldn't be a problem" if I skip classes for UDS \o/
[13:33] <Laney> :O!
[13:33] <directhex> RainCT, the last day of UDS is my wife's birthday, which doesn't bode well for attendance :|
[13:33] <Laney> RainCT: did you apply for sponsorship?
[13:33] <Laney> directhex: bring her!
[13:34] <RainCT> Laney: Nope. I wouldn't feel well doing so being only 30 minutes away from BCN :)
[13:34] <Laney> hah
[13:34]  * Laney will apply
[13:36] <stefanlsd> fta: do you know of any work on packaging  google gears for 64?
[13:36] <RainCT> stefanlsd: I have it on my TODO :)
[13:37] <RainCT> feel free to take it if you want, though
[13:37] <slicer> I could use a bit of advice on bug #333573 . It fails to build since we've added Qt 4.5.0-rc1, which changes the way qmake works. I have a workaround ready, which I'll submit to debian, which should eventually result in a new package version available for syncing. At that point, I'll request a new sync. What do I do with the sync request I already have? Just mark it Invalid?
[13:37] <ubottu> Launchpad bug 333573 in mumble "Please sync mumble 1.1.7-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/333573
[13:37] <RainCT> nhandler: about your merge request, that's not a bug but a feature :P
[13:37] <stefanlsd> RainCT: oh cool. yeah. I think i'll start it out and get it into revu at least.  Did you say you possibly had a ffe for it?
[13:37] <directhex> Laney, if you get to UDS and i don't, then you're gonna have to be the pkg-mono spokesman!
[13:38] <Laney> directhex: I will be your mouthpiece!
[13:38] <Laney> we should both go and crush the free desktop dream for good
[13:38] <RainCT> stefanlsd: not yet, but 64 bit support is (according to asac) a good rationale :)
[13:38] <stefanlsd> RainCT: kk. thanks
[13:38] <directhex> Laney, why are we asking canonical for sponsorship? getthefacts@microsoft.com!
[13:39] <directhex> Laney, they'll help!
[13:39] <Laney> haha
[13:43] <slytherin> directhex: Laney both of you should now take the microsoft certification for .net developers. :-P
[13:43] <directhex> slytherin, i don't believe in vendor certs. they lack "heart"
[13:44] <directhex> slytherin, i'd gladly make a macaroni picture depicting my work with c# for any prospective employer, though
=== __iron is now known as iron
[13:49] <hyperair> when there's stuff in debian/tmp or wherever, just run dpkg-gensymbols | patch bla.symbols
[13:52] <james_w> slicer: you can just edit the old sponsorship request to request the new version
[13:57] <RainCT> «Ggfgf says: Oh look a Growl ripoff       Mark Shuttleworth says: Oh look, an anonymous coward.» lol
[14:01] <slicer> james_w: Ok, thanks :)
[14:10] <ScottK> RainCT: Where is this?
[14:11] <savvas> ScottK: http://www.markshuttleworth.com/archives/265
[14:12] <ScottK> savvas: Thanks.
[14:12] <savvas> np :)
=== Koon is now known as ttx
=== ttx is now known as ttx_
=== ttx_ is now known as ttx
[15:08] <AdamDH> hi all, what's the best way to find out what dependancies my package requires in order to be built from source?
[15:09] <bmm> The wiki states revu.ubuntuwire.com and my default /etc/dput.cf also states .com but it seems to be revu.ubuntuwire.org is that correct?
[15:10] <directhex> bmm, yup
[15:11] <directhex> AdamDH, a new package? try building it in a pbuilder, and keep fixing control until it works
[15:11] <bmm> K, then somebody needs to have the default dput changed and the wiki should be changed. Somebody with rights should get on it ;)
[15:12] <bddebian> Heya gang
[15:13] <directhex> afternoon bazza
[15:16] <AdamDH> directhex: its a new package, will do that and keep modifying as required
[15:24] <bmm> New packages should be set to karmic instead of jaunty, right?
[15:25] <rexbron> bmm: we are in a feature freeze, so unless you file for an exception, that is correct
[15:25] <bmm> rexbron: thought so, thanks!
[15:34] <AdamDH> the .PHONY tag do I need to list each example: I use in my rules? say if I use one called extract: does that need to be listed?
[15:37] <directhex> .PHONY is your friend
[15:39] <hyperair> AdamDH: i don't think it's required, but it's good to add all rules that don't refer to a file to .PHONY
[15:40] <hyperair> AdamDH: as in, if i have a rule foo, that generates a file called foo, then don't add it to .PHONY, otherwise do so
[15:40] <directhex> e.g. clean
[15:41] <directhex> you really want clean in .PHONY ;)
[15:42] <AdamDH> clean is the rule I am having problems with now hence my question as what ever I do it does not seem to run
[15:46] <savvas> AdamDH: try clean:: instead of clean: :)
[15:46] <AdamDH> what does the extra : do?
[15:47] <savvas> I have no idea, I'm still learning, but it makes it run :)
[15:47] <savvas> good question though, what does it do?
[15:49] <AdamDH> im still learning as well, I am good with shell scripts just learning the way debian handles creating packages
[15:50] <savvas> well, debian/rules is a makefile
[15:51] <savvas> it's better to wait for someone else to reply, I'm really not that good :)
[15:51] <hyperair> adding rules to .PHONY basically means run the rule even if there is a file by that name
[15:53] <AdamDH> what about if its not ran when added to .PHONY?
[15:53] <savvas> there should an error message then about it
[15:54] <AdamDH> i will take a look at the logs once once in case I missed something
[16:01] <AdamDH> this is my rules: http://paste.ubuntu.com/122435/ I get no error on clean
[16:02] <ScottK> savvas: I fixed the depends problem on lpia for cgal.  Now there's a header path issue: https://launchpad.net/~kitterman/+archive/ppa/+build/881158
[16:03] <hyperair> hmm is it possible to create a karmic pbuilder yet?
[16:03] <hyperair> AdamDH, savvas: rule:: means that you can declare it multiple times, and they're appended
[16:03] <hyperair> basically i can have somerule:: something at the top, and then somerule:: somethingelse at the bottom, and then it'll just append everything
[16:03] <hyperair> it's used a lot in CDBS
[16:03] <hyperair> basically CDBS declares the rules with ::, so you can hook onto the end of them and run some stuff
[16:04] <ScottK> I notice now that there's a rules change needed too.
[16:06] <AdamDH> this is my rules files, http://paste.ubuntu.com/122435/ not sure why clean is not been ran
[16:06] <AdamDH> will append a :
[16:06] <AdamDH> just not seen a clean: in the examples so was looking to see if anything else was wrong
[16:07] <AdamDH> clean:: sorry
[16:08] <stefanlsd> yay. built a x86_64 xpi of google gears. seems to work ok.
[16:13] <AdamDH> ah got it to work
[16:14] <Laney> stefanlsd: can you hax it to work with ff 3.1 at all?
[16:14] <AdamDH> if I paste my working rules files in a mo can some one just take a look to see if I missed anything? I will then add it to my ppa so I can get a few people to try it
[16:15] <stefanlsd> Laney: can have a look at it. i was just gonna start packaging a .deb now so we can maaaybe get it into jaunty
[16:16] <stefanlsd> Laney: do you want to try this xpi in 3.1?
[16:16] <RainCT> ls
[16:16] <stefanlsd> hehe
[16:16] <RainCT> :$
[16:18] <AdamDH> my clean rule is ran at the start of the build but not after the build so it leaves temp files lying about any ideas why?
[16:19] <RainCT> AdamDH: that's the expected behaviour
[16:19] <AdamDH> ah did not know that
[16:19] <RainCT> AdamDH: you can run   fakeroot debian/rules clean   to clean up the source directory
[16:21] <Laney> stefanlsd: I will later. I tried it from google's site and it wasn't compatible. I just wondered if you haxed the xpi whether it would work
[16:22] <RainCT> if someone from motu-sru is around please have a look at bug #333902
[16:22] <ubottu> Launchpad bug 333902 in webboard "Please upgrade webboard to version 0.2.2" [Undecided,New] https://launchpad.net/bugs/333902
[16:26] <AdamDH> thanks RainCT I was not expecting that behaviour
[16:26] <RainCT> AdamDH: No problem. It's useful in case you have to debug something, etc.
[16:28] <AdamDH> this is my final rules file and it creates a working deb http://paste.ubuntu.com/122444/ can any one tell me if there is anything I could improve?
[16:29] <RainCT> uhh nice :)
=== dholbach_ is now known as dholbach
[16:38]  * RainCT falls asleep waiting for Launchpad to load a page :'(
[16:39] <RainCT> oh, it opened
[16:51] <AdamDH> RainCT launchpad seems slow today, trying to upload a package to my ppa seems to be taking its time
[16:53] <RainCT> not only today, it feel it like this since a few weeks already
[16:54] <AdamDH> well we are on alpha4 so probally the reason why!
[16:55] <RainCT> nobody uses alpha 4 (compared with the amount of people who will use the final version..)
[16:58] <maxb> AdamDH: for the sanity of everyone else who ever needs to look at that rules file, *please* use standard 1-tab indentation
=== murdok_ is now known as murdok
[16:59] <maxb> also, as I've said before, the entire concept of remove-patch-stamp is fundamentally invalid
[16:59] <maxb> furthermore, use CURDIR
[17:01] <AdamDH> maxb, forgot I still have the clean patches in there I will remove that, I will clean up the rules a little
[17:02] <maxb> Also, cd-ing just to exec rm is overcomplicating things, rm -f $(CURDIR)/whatever
[17:04] <AdamDH> I always considered cding more robust
[17:04] <AdamDH> I will alter all these small things and get it put into my ppa
[17:09] <AdamDH> maxb I am using msp430-binutils-2.18-msp430-cvs.0.0.20090224 as my version as I am applying a patch to the upstream binutils. If my next package is msp430-gcc-3.2.3-msp430-cvs.0.0.20090224 in control for the next package how do I tell it to depend on msp430-binutils? just put msp430-binutils-2.18?
[17:10] <maxb> msp430-binutils-2.18-msp430-cvs.0.0.20090224 is not a version, nor a package_version fragment of a dpkg filename, please clarify what you actually mean
[17:11] <AdamDH> I used msp430-binutils-2.18-msp430-cvs.0.0.20090224 as the version for my package, where msp430-binutils-2.18 was the upstream version and the rest showing the patch came from cvs
[17:11] <AdamDH> I came up with that after asking for advice here
[17:11] <maxb> No, 2.18 is the upstream version
[17:12] <AdamDH> yup thats what I said?
[17:12] <maxb> You said msp430-binutils-2.18
[17:12] <AdamDH> sorry yes see what you mean
[17:12] <AdamDH> 2.18 is the upstream version and msp430-binutils is the package
[17:13] <maxb> 2.18-msp430-cvs.0.0.20090224 is a bad version because versions should not contain multiple - characters unless the upstream version does
[17:13] <maxb> s/does/contains any/
[17:13] <AdamDH> my version should be 2.18-msp430-cvs.0.0.2009022
[17:14] <maxb> Is the patch contained within your .diff.gz? Or is part of the patch applied in the .orig.tar.gz ?
[17:15] <maxb> Where is the cvs repository in question?
[17:16] <AdamDH> mspgcc.sf.net is where the CVS repository is
[17:17] <AdamDH> I am applying it to the upstream source and the patch is contained within the tar.gz I do not have have a .orig.tar.gz I just called it binutils-2.18.tar.gz and applied the patch to that
[17:17] <AdamDH> I created the patch from CVS sources
[17:18] <maxb> binutils-2.18.tar.gz is horribly misleading because that is a name that is used by a real upstream binutils release
[17:19] <AdamDH> yup maxb I agree but my patch is applied to that upsream release to create a cross compiler
[17:19] <AdamDH> the whole project is a mess and missleading
[17:19] <AdamDH> so it seemed better to show what upstream version I was working on
[17:21] <maxb> The cvs repo you pointed me to contains "binutils/NO_LONGER_MAINTAINED" that requests people now use official binutils releases, so where's the patch coming from?
[17:21] <maxb> "The standard binutils package, available at http://sources.redhat.com/binutils, now contains this MSP430 support. " says the website
[17:22] <AdamDH> that is not true, the patches are inside packaging/patches
[17:22] <AdamDH> the mailing list discusses what patches need to be applied to create a working version, nothing has been taken upstream
[17:22] <AdamDH> so there is 3 patches to be applied to 2.18 before it will work with all msp430 devices
[17:23] <maxb> You might consider asking upstream to fix their website, then :-)
[17:24] <AdamDH> maxb its all a mess so my packages were supposed to take the headache out and leave programmers to programme instead of spending hours getting a working toolchain
[17:24] <AdamDH> my binutils package works and so does gcc just need to work on libc
[17:25] <maxb> Right. The nicest way to package this is to use the *original* *upstream* binutils-2.18 tarball, and to include the three patchfiles from mspgcc cvs within the debian/patches/ directory of your package, and to apply them in debian/rules
[17:27] <maxb> Your version number then can simply be 2.18-0ubuntu1
[17:27] <AdamDH> my package uses the orginal upstream tar ball and inclues the patches in a folder called patches, the patch as they just give the modified files on the cvs and expect you to copy over to the upstream source, I instead created a patch that could be applied to the upstream source. But how do I show what revision the patch is as that comes from CVS?
[17:27] <AdamDH> *tarball
[17:28] <AdamDH> if I keep with the 2.18-msp430-cvs.0.0.20090224 in the control for gcc that depends on binutils what do I put? just msp430-binutils and it uses what ever version is in the ppa?
[17:30] <maxb> <AdamDH> my package uses the orginal upstream tar ball and inclues the patches in a folder called patches, the patch as they just give the modified files on the cvs and expect you to copy over to the upstream source, I instead created a patch that could be applied to the upstream source. But how do I show what revision the patch is as that comes from CVS?
[17:30] <maxb> huh?
[17:30] <maxb> I see three patch files for 2.18 in the cvs directory you pointed me to
[17:33] <AdamDH> ah there are now, gcc has no patches tho that is the same case as before
[17:35] <maxb> OK, but since binutils does have patches, I stand by what I said.
[17:39] <AdamDH> so you would just call it by its upstream name in the case of binutils?
[17:49] <maxb> AdamDH: I suggest you've reached the point where you should put your binutils package at least to REVU
[17:55] <AdamDH> I have a PPA on launchpad will that do?
[18:02] <maxb> AdamDH: PPAs build binaries, REVU doesn't, but it allows users to add comments.
[18:02] <AdamDH> i will take a look at revu
[18:02] <maxb> wiki.ubuntu.com/REVU
[18:04] <hyperair> does anyone knoew if karmic packages will be reviewed? =\
[18:04] <hyperair> can you even get a chroot for testing on karmic?
[18:04] <RainCT> hyperair: that depends on how generous you are :P
[18:04] <ScottK> Not until after Jaunty release most likely.
[18:05] <hyperair> RainCT: how generous *I* am?
[18:06] <hyperair> RainCT: if i'm very generous, then the revu queue will grow bigger ;)
[18:09] <RainCT> heh
=== RainCT_ is now known as RainCT
[19:00] <fabrice_sp_> Hi, pigment-python is marked as FTBFS in qa.ubutnuwire.org/ftbfs, but I've built it successfully with an updated sbuild. I think that the dependency was compiling when  the build was running (http://launchpadlibrarian.net/23007901/buildlog_ubuntu-jaunty-i386.pigment-python_0.3.10-1_MANUALDEPWAIT.txt.gz). Is it possible for some admin to relaunch the build? Or do I have to force a new version with a debdiff?
=== fabrice_sp_ is now known as fabrice_sp
[19:02] <pochu> fabrice_sp: if it's in universe, I can retry it
[19:02] <fabrice_sp> Hi pochu! yes, it's in universe
[19:03] <fabrice_sp> :-D
[19:03] <pochu> err
[19:03] <pochu> fabrice_sp: it didn't FTBFS, it's DEPWAIT
[19:03] <pochu> fabrice_sp: it will be built once the dependency it needs is available
[19:03] <savvas> ScottK: I forgot who, but someone in the channel suggested that we could also debug the atlas problem: https://launchpad.net/ubuntu/jaunty/+source/atlas/+builds
[19:03] <pochu> so nothing to retry ;)
[19:04] <ScottK> savvas: atlas is a hairy mess.  I'd prefer to avoid it if we can.  If you can fix that, it'd be wonderful.
[19:04] <savvas> pochu: in PPA? they're automatically retried once the dependency is satisfied?
[19:04] <pochu> savvas: no, in the archive
[19:05] <savvas> ah, I was prepared for a hug :P
[19:05] <pochu> savvas: I guess it's the same in the PPA, but I'm not sure
[19:05] <fabrice_sp> hmm: pigment 0.3.14 has been build :-/
[19:05] <emgent> hello
[19:05] <savvas> ScottK: I'll try both sides, see what can be done :)
[19:06] <fabrice_sp> pochu, http://launchpadlibrarian.net/23033637/buildlog_ubuntu-jaunty-amd64.pigment_0.3.14-1_FULLYBUILT.txt.gz. (14 hours ago). What is the frequency of the retry?
[19:07] <a|wen> fabrice_sp: did the binaries get out of binary new?
[19:07] <fabrice_sp> a|wen, good point. How can I check that?
[19:08] <a|wen> fabrice_sp: https://launchpad.net/ubuntu/+source/pigment/0.3.14-1/+build/879857 ... look to the right
[19:08] <a|wen> fabrice_sp: "Binaries awaiting acceptance:" so not yet
[19:09] <fabrice_sp> got it!
[19:09] <a|wen> :)
[19:09] <fabrice_sp> thanks and sorry for the noise :-)
[19:21] <savvas> architecture armel in ubuntu is arm in debian?
[19:22] <ScottK> savvas: No.  armel in bother
[19:22] <ScottK> bother/both
[19:22] <ScottK> Debian released Lenny with arm and armel, but arm is to be dropped soonish.
[19:22] <savvas> oh, ok :)
[19:25] <savvas> ScottK: is it similar to arm, something like i386 with lpia?
[19:25] <savvas> with = and
[19:25] <ScottK> Not exactly, but not so far off.
[19:25] <ScottK> I don't recall exactly.
[19:31]  * savvas crosses fingers
[19:32] <savvas> I've noticed that in atlas there's not a folder for lpia nor for armel in debian/, but there is one for the rest of the architectures
[19:33] <savvas> I'll have to make a pbuilder for lpia for this one, seems quite big to upload to a ppa :)
[19:35] <salty-horse> hi. vlc on jaunty has the video detached from the controls, and it seems to not respect the "integrate video in interface" option. compiled from git it works fine... known bug?
[19:36] <savvas> salty-horse: known :)
[19:37] <salty-horse> I'm not worrying then :D
[19:38] <savvas> salty-horse: you should be - it's a killer bug, if they allow integration, vlc will crash: bug 314038
[19:38] <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/314038/+text)
[19:38] <savvas> woops
[19:38] <savvas> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/314038
[19:38] <ubottu> Ubuntu bug 314038 in vlc "Integrated video interface is broken in Jaunty" [Undecided,Confirmed]
[19:39] <savvas> salty-horse: I have a package for it integrated, but vlc crashes when I press stop :P
=== RainCT_ is now known as RainCT
[20:02] <ianto> With the Debian Policy Manual, does anyone know what section a code analyser for C++ would come under? “utils” perhaps?
[20:05] <RainCT> ianto: devel?
[20:05] <RainCT> ianto: Btw, if you look at http://packages.debian.org/unstable/, you have the sections there but with a description :)
[20:05] <RainCT> (they have fancy names there, but if you look where the URLs point to you'll get the real name)
[20:06] <ianto> RainCT: Ah right OK thanks, I thought that devel was more for the compilers & coding tools themselves rather than analysers; although I guess that it is too a development tool :-/
[20:06] <_ruben> when using module-assistant, is it possible for a -source package to have a dependency on package-x.y.z-dev, where x.y.z is the kernel version for which you want to build a kernel using module-assistant?
[20:07] <directhex> m-a? how retro
[20:07] <_ruben> never got the hang of dkms
[20:08] <_ruben> and dkms doesnt produce "distributable" packages, or does it? like i said, never really got the hang of that one
=== bastiao_ is now known as k0p
[20:08] <RainCT> _ruben: afaik it compiles the modules at boot, so that if the kernel version changes they are just recompiled on the user's systems and the users don't have to wait for a new version
[20:09] <superm1> it also has support for mkdeb or mkdsc if you want to build distributable packages
[20:09] <_ruben> RainCT: which is not what i want really, as i dont want a build environment on all machines
[20:09] <_ruben> superm1: interesting
[20:10] <_ruben> but the question kinda remains the same .. is just a dependency possible?
[20:10] <superm1> _ruben, it's almost inevitable to have a build environment on all machines unless you can control them to never run different kernels
[20:11] <_ruben> superm1: i upgrade my "m-a packages" when i upgrade kernel .. no build env needed
[20:11] <_ruben> got a buildhost to build new packages when needed
[20:12] <superm1> _ruben, well you can do the same thing with dkms, it's the same tools you need for building
[20:12] <stefanlsd> RainCT: i have a gg 64 ff3.0+ xpi built
[20:12] <superm1> _ruben, DKMS can just handle that portion for you
[20:13] <RainCT> stefanlsd: as a .deb?
[20:14] <_ruben> superm1: i'll definately look into dkms once again, hopefully 3rd time's a charm ;-)
[20:14] <stefanlsd> RainCT: xpi mainly. i just built a test .deb of the xpi following the mozilla-team extensions guidlines. so i do have a .deb and it installed. its just not really clean yet.. (changelog, copyright etc)
[20:15] <RainCT> stefanlsd: OK. Got the source from Google Code?
[20:15] <stefanlsd> RainCT: yeah
[20:15] <RainCT> stefanlsd: Great. Poke me once it's ready and I'll review it :)
[20:15]  * RainCT hugs stefanlsd 
[20:15] <_ruben> as for the initial query .. i currently have 2 -source packages, but the 2nd has a dependency on a Symbols.symvers file that's created by the first .. which unless im missing something is a nasty dependency to properly fix ;)
[20:15] <stefanlsd> RainCT: do you know if it will be acceptable to use the compiled xpi?
[20:16] <RainCT> stefanlsd: the .xpi should be created at build time
[20:17] <stefanlsd> RainCT: the mozilla team currently uses .xpis they get. maybe those xpi's dont contain .so's tho
[20:18] <stefanlsd> RainCT: source is bout 300mb :|
[20:18] <RainCT> stefanlsd: Oh (yeah, it took some time to checkout the source here but I haven't looked at it yet). Where does the xpi come from then?
[20:18] <RainCT> and, how are you patching it for 64bit?
[20:19] <stefanlsd> RainCT: the make of the source generates the xpi.  the source is patched to get it to compile
[20:20] <RainCT> stefanlsd: So what's the problem?
[20:20] <RainCT> stefanlsd: that you want to generate the xpi locally and only put the xpi into the source package to avoid the 300mb, or what?
[20:21] <stefanlsd> RainCT: yeah. essentially
[20:21] <ScottK> savvas: https://launchpad.net/~kitterman/+archive/ppa/+build/881570
[20:21] <tonyyarusso> All right, I'm back at this and need a bit about gdb usage explained to be, specifically breakpoints and printing variables.  So far whenever I've tried to set a break I get Function not defined, make depend on future shared library?
[20:22] <RainCT> stefanlsd: 19M  gears/
[20:22] <RainCT> stefanlsd: did you get ride of the .svn directories?
[20:23] <stefanlsd> RainCT: i did. i also builds against some of the 3rd party stuff. need to check exactly what. i know gecko_1.8 and gecko_1.9.
[20:24] <stefanlsd> and theres a hack there also. You need to copy the xulrunner-dev  xpcom 64 .so's over those...
[20:24] <RainCT> stefanlsd: that third_party directory looks really evil :P
[20:24] <savvas> ScottK: that's great! one more to go then :)
[20:24] <RainCT> stefanlsd: well, best ask asac if you have any problem, he's the real Fx master :)
[20:25] <ScottK> savvas: mok0 filed a removal bug for btk-core, so I think we're done.
[20:25] <stefanlsd> RainCT: kk. will do. I essentially wanna find out if we need to go from source. if so, i'll start cleaning it up, hopefully get the size down
[20:25] <savvas> ScottK: does that mean that atlas wasn't necessary?
[20:25] <stefanlsd> RainCT: at least then we can also link against the ubuntu build time libaries.
[20:26] <ScottK> It will build without it.  If you look in debian/control you'll see it's excluded on quite a number of architectures.
[20:31] <savvas> true, I missed that
[20:34] <ScottK> savvas: You've been a big help on this.
[20:40] <savvas> ScottK: I wish I could provide more help, but my knowledge in programming and packaging is limited - it was good for learning and practice! Do you have anything else similar on transitions? :)
[20:41] <Teddy___> Ubuntu has an old version of my package.  How can I make sure the newer (actually working) version is included in Jaunty?
[20:41] <ScottK> Teddy___: What package?
[20:42] <ScottK> savvas: Nothing comes immediately to mind.
[20:42] <ScottK> Getting rid of old GCC versionsis always 'fun'.
[20:42] <Teddy___> ScottK: "mandos"
[20:44] <savvas> mandos seems to be taken from debian
[20:44] <savvas> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mandos
[20:44] <Teddy___> savvas: Yes, it is.
[20:45] <ScottK> Teddy___: Is it just bug fixing between what we have and what's in Debian?
[20:45] <Teddy___> savvas: But Debian now has version 1.0.5-1, and will soon have 1.0.7-1, but Ubuntu is still on 1.0.2...
[20:45] <Teddy___> ScottK: Yes, more or less.
[20:46] <ScottK> Teddy___: Ubuntu works on 6 month release cycles.  In the first part of the cycle we automatically sync packages from Debian that we get unmodified from them.  At this point a sync would have to be requested.
[20:47] <Teddy___> ScottK: ...  So what do I do?  The 1.0.2 version has some rather bad bugs, and 1.0.7 is completely compatible with only minor feature additions.
[20:47] <ScottK> Teddy___: Or since the latest version isn't in Debian yet, you could file a bug in Launchpad and attach the .diff.gz to the bug.  If you 1.0.7-1/-0ubuntu1 and unstable/jaunty your package should be equally good for Ubuntu
[20:48] <ScottK> Teddy___: Since we are post feature freeze for this release you'll need to give the information for a feature freeze exception.
[20:48] <savvas> I think it fits the freeze exception :) https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20Exceptions
[20:49] <Teddy___> ScottK: ...And what information is that?  And to whom do I give it?
[20:49] <ScottK> You put it in the bug and subscribe motu-release to the bug.  It's described in the link savvas just gave you.
[20:50] <Teddy___> ScottK: Thanks, I'll check it out.
[20:58] <Teddy___> ScottK: To report a bug on launchpad, I'll have to register Yet Another Damn Account...
[20:58] <ScottK> Yes.  Yes you will.
[20:59] <ScottK> Sorry.
[20:59] <Teddy___> ScottK: And it doesn't even support OpenID
[21:00] <ScottK> It does, but only as a provider.  It'd actually be better if supported it less from a security perspective.
[21:00] <ScottK> For developers Launchpad passwords have actual security implications which makes OpenID completely inappropriate.
[21:06] <aeg37> hello everyone
[21:12] <Teddy___> ScottK: I'll drop this for now; I don't like registering new accounts all the time.  Maybe someone else has an existing Launchpad account.
[21:13] <ScottK> Teddy___: Ping me after it's in Debian
[21:14] <Teddy___> ScottK: Ping?  Sure, will do.
[21:15] <jdstrand> \sh: hi-- on bug #331410, were you able to reproduce it?
[21:15] <ubottu> Launchpad bug 331410 in net-snmp "CVE-2008-6123: not fixed in latest security releases" [Undecided,In progress] https://launchpad.net/bugs/331410
=== asac_ is now known as asac
[21:28] <ScottK> savvas: If you want another puzzle, there is https://launchpad.net/ubuntu/+source/bmpx/0.40.14-1ubuntu1/+build/876596
[21:28] <ScottK> That will also block the boost removal.
=== santiago-pgsql is now known as santiago-ve
[21:38] <savvas> hm.. checking for C64_clockSpeed in -lsidplay... no
[21:38] <savvas> configure: error: libsidplay 1.x not found!
[21:38] <savvas> dependency error?
[21:39] <savvas> I'll check it out
[21:55] <RainCT> jpds: What do you think about backporting espeak?  (The version in Jaunty has support for Catalan :)).
[21:55] <ScottK> I suspect it'll end up being a kernel bug, but I don't know for sure.  I didn't have time to research it.
[21:55] <RainCT> bah he's away
[22:42] <savvas> can I use pbuilder to create powerpc packages?
[22:43] <mdke> hi there. I've been looking through the various guides on the wiki and it is all very good. But I can't see how to actually upload a package to ubuntu, short of "use dput". Is there a more detailed document?
[22:44] <ScottK> savvas: No, you need powerpc hardware for that.  TheMuso might be able to help you out.
[22:44] <mdke> Launchpad has some quite good instructions on dput for PPAs but I wondered if there is an equivalent guide for Ubuntu
[22:44] <TheMuso> savvas: Is there a specific reason you need to make powerpc packages?
[22:46] <savvas> TheMuso: I'm looking at a failed build on bmpx powerpc: https://launchpad.net/ubuntu/+source/bmpx/0.40.14-1ubuntu1/+build/876596 - but no, not yet, I'll let you know if I come up with something :)
[22:48] <TheMuso> savvas: hrm ok. Unfortunately I can't currently help, since I don't have a working powerpc jaunty install, due to various testing, and discovering some bits of breakage, however I should have that sorted by later today.
[22:49] <mdke> ah, I've found this now, looks to be what I'm after - https://wiki.ubuntu.com/DeveloperGuide/Uploading
[22:50] <savvas> TheMuso: ok, thanks!
[22:53] <savvas> ScottK: could we possibly disable sid in debian/rules? --disable-sid instead of --enable-sid ?
[22:53] <RainCT> mdke: see also https://wiki.ubuntu.com/MOTU/New
[22:53] <ScottK> savvas: Dunno.  I haven't taken a look at it.
[22:53] <mdke> james_w: thanks for that page (DeveloperGuide/Uploading), very useful - I think it would be useful to put a link on UbuntuDevelopment
[22:53] <mdke> RainCT: ok, thanks
[22:54] <james_w> mdke: too much of a WIP for that yet in my opinion
[22:55] <mdke> james_w: ok, your call, but I found it very clear
[22:56] <mdke> james_w: so thanks :)
[22:56] <james_w> mdke: glad to help
[22:56]  * RainCT agrees, nice page :)
[22:56] <RainCT> james_w: ppa:<name> is only available on Jaunty, or?
[22:56] <james_w> erm
[22:57] <james_w> yeah, I think that's right
[22:57] <james_w> Cody's clever idea
[22:57] <RainCT> Yeah, it's *much* better than having to edit dput.cf
[23:10] <savvas> When using -lsomelibname does it retrieve libsomelibname.so (as in, "lib" in filename) ?
[23:15] <savvas> ah, yes
[23:35] <slicer> quadrispro: Hi. About bug #333573. I was told earlier today by james_w to edit the original sync request once the bug was fixed in debian (it now is, 1.1.7-3 was released a few hours ago -- just waiting for PPA build on i386 to finish to be absolutely sure). Should I still do that, or should I create a new sync request?
[23:35] <ubottu> Launchpad bug 333573 in mumble "Please sync mumble 1.1.7-2 (universe) from Debian unstable (main)." [Wishlist,Invalid] https://launchpad.net/bugs/333573
[23:37] <quadrispro> hi slicer, no, updating #333573 is good
[23:37] <anakron> hi all
[23:38] <anakron> ping Laney: Hi !! how are you? im interested to show you some things that i worked
[23:38] <Laney> anakron: Hi! Sorry I've been away
[23:38] <slicer> quadrispro: Ok. So I just set it back to it's original state (new, undecided) and post a comment with the changelog? (Assuming the PPA build finishes successfully)
[23:38] <anakron> ok
[23:39] <Laney> let's have a look
[23:39] <quadrispro> slicer: setting "new" again and change the description (instead of adding another comment)
[23:39] <quadrispro> is good :)
[23:39] <slicer> quadrispro: Ok, will do. Thanks.
[23:41] <quadrispro> slicer: I'm already subscribed, feel free to assign that but to me
[23:41] <quadrispro> s/but/bug
[23:42] <anakron>  https://bugs.launchpad.net/ubuntu/+source/qtpfsgui/+bug/309740
[23:42] <ubottu> Ubuntu bug 309740 in qtpfsgui "no menu icon" [Undecided,Confirmed]
[23:44] <anakron> I'll review one now and then I'll tell iy to you Laney
[23:57] <anakron> HI again
[23:57] <anakron> damned mplayer
=== murdok is now known as pablog
[23:58] <Laney> hi anakron
[23:58] <Laney> anakron: Are you familiar with patch systems?
[23:58] <anakron> yes
[23:59] <anakron> why?
[23:59] <Laney> I notice you changed project.pro without using it, when the package uses quilt