[00:03]  * jdong has successfully cleared his LP bugmail folder.
[00:04] <ajmitch> delete all?
[00:04] <dtchen_> I'm envious
[00:04] <dtchen_> 1 - 100 of 12626
[00:04] <ajmitch> quick, file more bugs for jdong!
[00:04] <jdong> hahaha
[00:04] <jdong> don't do that!
[00:05] <jdong> and I SWEAR clearing involved reading and taking action ;-)
[00:05] <ajmitch> sure
[00:06] <cody-somerville> 11037 bugmails here : (
[00:07] <ajmitch> so the aim is for lucid to have less bugs open than karmic did at release :)
[00:08] <dtchen_> I'm not even going that route
[00:08] <ajmitch> not even for audio bugs?
[00:08] <dtchen_> If we can get 10.04 out the door with fewer known issues, I'll be happy
[00:09] <dtchen_> yeah, I've long since stopped caring about open bugs. It seems like a get about six hundred a day.
[00:09] <dtchen_> like I get*
[00:09] <ajmitch> even the bug stats page that I remember hasn't been updated since april
[00:10] <ajmitch> at the rate it's taking me to fix a bug in a single package, I expect to fix 5 bugs by lucid release
[00:11] <dtchen_> I'm actually blocked on upstream for 2 significant annoyances :/
[00:11] <ajmitch> more HDA stuff?
[00:11] <dtchen_> nope, PA
[00:11] <dtchen_> it's getting close to F12 release, though, so I suppose that's understandable
[00:12] <ajmitch> the only hardware issues I have to complain about are only suspend/hibernate/resume related now, and they mostly just work
[00:13] <ajmitch> sound is working nicely thanks to you & alsa upstream
[00:13] <dtchen_> for lucid, we'll probably have crack-of-the-day builds for alsa-driver stable
[00:14] <ajmitch> in a snapshot package in main?
[00:15] <dtchen_> nope, universe for src:linux-backports-modules-2.6.3x -> bin:linux-backports-modules-alsa-2.6.3x-yy-generic
[00:15] <ajmitch> makes sense
[00:15] <ajmitch> more visible than a PPA
[00:15] <dtchen_> well, I suppose it would still be src:main -> universe:bin
[00:15] <ajmitch> do you think you'll update them post-release in lucid-updates?
[00:16] <dtchen_> yes, I hope so
[00:16] <dtchen_> smb just applied the wifi updates from 2.6.32-rc6 for karmic-proposed
[00:16] <ajmitch> 3 years of driver backports for desktops
[00:17] <dtchen_> I utterly fail at analogy ordering, apparently. src:main -> bin:universe
[00:17]  * ajmitch understood it still :)
[00:20] <ajmitch> I know that there'll be a large number of new packages that people want to get in through REVU again, if we can afford to carry them
[00:21] <ajmitch> but that's something for those who go to UDS to care about
[00:23] <dtchen_> I need more hours in a day
[00:24] <ajmitch> don't we all?
[00:24] <dtchen_> quilt pop -a
[00:24] <dtchen_> bah
[00:24] <ajmitch> quilt refresh
[00:39] <TheMuso> I only care about revu these days if there is a package I want to get into main, or for studio, where there is a group of us who maintain it.
[00:45] <ScottK> ajmitch: How's boost going?
[00:46] <ajmitch> 1.40 built for lucid in my PPA, after I stripped the python 2.5 stuff
[00:47] <ajmitch> 1.38 should get merged for lucid if we're keeping it, I haven't done it yet
[00:47] <ajmitch> but it works for karmic once I put some more detail in the changelog
[00:48] <ajmitch> of course there's now a possibility it could be fixed in python rather than just in boost
[00:57] <segler> hi, i need an advocate. please have a look at my small python rhythmbox plugin at http://revu.ubuntuwire.com/p/rhythmbox-radio-browser, thanks
[01:03] <c_korn> is there a game packages somewhere which needs to write into its game directory ?
[01:03] <c_korn> s/packages/packaged/
[01:04] <serialorder> i am looking at the diff between a denian and ubuntu package and one of the few differences I see is ubuntu has DH_VERBOSE := 1 DH_OPTIONS += --with=quilt while debian does not in debian/rules
[01:04] <serialorder> I am wondering if that is something I should keep or not?
[01:04] <ScottK> Are there patches applied in the Ubuntu version?
[01:09] <serialorder> scottk, yes there is one patch applied in the ubuntu version that is not applied in the debian version and there are two that are applied in both
[01:10] <ScottK> I'd keep it then
[01:11] <serialorder> whould you mind explaining whay its there/what its doing?
[01:17] <serialorder> oh I think i see the difference the ubuntu version has %:  dh $@   while the debian version has %:  dh  --with=quilt $@  so it looks like they just specify it in different places
[01:18] <ajmitch> minimise the difference from debian then
[01:18] <ScottK> Agreed
[01:21] <serialorder> that leaves only one difference in debian/rules which are the lines DH_VERBOSE := 1  and export DH_VERBOSE how important is it to keep that?
[01:22] <ScottK> Drop it.
[01:23] <serialorder> dropped! =)
[01:27] <serialorder> anyone have a link to what the different versions for a watchfile mean? I asked google but it has failed me
[01:28] <nhandler> kirkland: Is there an argument you can pass to testdrive to have it not use virtualbox?
[01:28] <RAOF> serialorder: There's version 3, which is the one that's current, and works.  There are apparently two other versions, 1 & 2, but I've never encountered one of them in the wild, and I'm not sure they actually work.
[01:28] <serialorder> RAOF, ok maybe thats why google 'failed' =) use version 3 got it
[01:31] <mmmiiikkkeee> Hi, what is the point of this guide: https://wiki.ubuntu.com/DebootstrapChroot  if pbuilder already sets up a chroot enviroment for when it builds a package? does pbuilder use that chroot env or makes a different one? should i be running pbuilder in the original chroot enveriment(no?)? how do all these pieces work together?
[01:33] <serialorder> i take it that if debian/control has a launchpad bzr and the debian version has a debian git I should keep the launchapd bzr ?
[01:35] <RAOF> If that's where it's being maintained, yes.
[01:35] <kirkland> nhandler: you would rather it use kvm, or what?
[01:36] <nhandler> kirkland: Yeah, is there a way to specify if it should use kvm or virtualbox?
[01:38] <kirkland> nhandler: it should use kvm by default, if you can use it
[01:38] <kirkland> nhandler: if kvm-ok; then
[01:38] <kirkland>         VIRT="kvm"
[01:38] <kirkland> nhandler: does kvm-ok return non-zero?
[01:39] <serialorder> RAOF,  it looks like it is being maintained in both places
[01:39] <serialorder> also should I do the merge with bzr or like i usually do with filing a bug and attaching a debdiff?
[01:40] <RAOF> Is it being maintained _in Ubuntu_ at the launchpad address?  It sounds like the answer is 'yes, so yeah, that's what should be in VCS-Bzr.
[01:41] <serialorder> RAOF, yes it is ok
[01:41] <serialorder> thanks
[01:41] <RAOF> Doing the merge in bzr may be good; that depends in part on how familiar you are with bzr and how familiar your sponsor is with bzr.
[01:43] <serialorder> I guess the reason I ask is that from what I understand/have heard soon all packages are going to have a bzr trunk in launchpad so i figured figuring out how to do a merge that way might be important
[01:44] <serialorder> but it sounds like i can/should just do it the 'normal' way
[01:51] <hedkandi> hello I'd like to put a page onto the ubuntu wiki. How would I do this?
[01:52] <hedkandi> the page I'm interested in is marked "immutable" which means it's not a wiki
[01:52] <hedkandi> the principle of wiki is that anyone can come along and edit it
[01:52] <hedkandi> so I really don't see that it should be called a wiki at all.
[01:53] <StevenK> hedkandi: That's because you're not logged in
[01:53] <StevenK> hedkandi: You need to be logged in to edit pages.
[01:53] <hedkandi> oh really? can I use my launchpad id to login?
[01:53] <StevenK> Sure
[01:53] <hedkandi> horay. I'll go and investigate that then.
[01:53] <hedkandi> thanks for the tip.
[01:53] <ajmitch> heh
[01:54] <nhandler> kirkland: I just did a quick reboot (it didn't register my last one), and that got it using kvm. It would be nice to add a flag/config option to allow users to specify whether kvm/virtualbox should be used for a certain ISO
[01:55] <kirkland> nhandler: sure thing
[01:55] <kirkland> nhandler: i'll add that now
[01:56] <nhandler> You rock kirkland. I might need to start doing some ISO testing now that I have an easy way to run the ISOs
[01:56] <kirkland> nhandler: ;-)  thanks man
[01:56] <kirkland> nhandler: glad to be of help
[01:57] <kirkland> nhandler: did this remove a barrier of some kind for you?  or just made it easier?
[02:01] <nhandler> kirkland: It made it easy and fast enough for me to be able to get and run an ISO that I would be up for doing some real ISO testing.
[02:01] <kirkland> nhandler: great; that's my goal :-)
[02:01] <kirkland> nhandler: Committed revision 55.
[02:04]  * nhandler hugs kirkland 
[02:25] <serialorder> is there a way to easily add ubuntu changelog entries into one from debian?
[03:31] <FFEMTcJ> Could someone please help me.. I'm trying to fix my second bug and I am running into a problem. I'm running debuild -S and its giving me errors..
[03:31] <nhandler> What error are you getting FFEMTcJ ?
[03:32] <FFEMTcJ> nhandler: http://pastebin.com/m7604205a
[03:34] <nhandler> FFEMTcJ: Do you have cdbs installed?
[03:35] <FFEMTcJ> i do now..
[03:35] <FFEMTcJ> lemme give another try
[03:36] <FFEMTcJ> worked.. thanks nhandler
[03:36] <nhandler> You are welcome FFEMTcJ
[05:22]  * ScottK is suspicious the package built on the first try. ...investigates further.
[05:23] <dtchen_> I keep thinking my build harnesses are good, but upstreams keep getting better at breaking things. This last time it was 32-bit asm to detect VMs. (?!)
[05:34] <ScottK> Suspicion was justified.
[05:37] <fabrice_sp> jdong, about bug #475891. what is the actual status? I'm a bit lost
[05:38] <fabrice_sp> (the fix released stuff is for Debian)
[05:38] <jdong> fabrice_sp: it's clear for upload.
[05:38] <jdong> and upon accepting, the archive admin is to copy the package over to lucid.
[05:38] <jdong> which is why it uses a standard version
[05:38] <jdong> (like how zsync was handled)
[05:39] <fabrice_sp> ok: in comment 11. you say that you'd like an archive admin opinion. That's why I was asking
[05:39] <fabrice_sp> Will have a look then :-)
[05:39] <fabrice_sp> thanks
[05:39] <jdong> fabrice_sp: lol the reason is that the proposed fix, as you can see, sounded "strange"
[05:40] <fabrice_sp> yeah: I saw that :-) (I was processing the merge, and saw also that 'strange' fix in the debian changelog :-) )
[05:41] <jdong> ack there's already a merge in the pipeline?
[05:41] <jdong> curse this latency!
[05:41] <jdong> eeeh
[05:41] <jdong> *shrug*
[05:41] <fabrice_sp> yeah... but as it's from Unstable, I was a bit reluctant to process it for the moment
[05:42] <jdong> ok
[05:45] <bbigras> hi, I attached debdiffs for bug 476360 and bug 428017 , if anyone's interested
[05:46] <ScottK> apachelogger: Please have a look when you have a moment ^^^
[05:47] <bbigras> thanks
[05:48] <AnAnt> Hello
[05:51] <fabrice_sp> Hi AnAnt
[06:21] <cody-somerville> jdong, that eagle package makes me want to hurl
[06:22] <jdong> cody-somerville: agree with you
[06:24] <cody-somerville> The change makes it impossible to fully apt-get remove the damn thing which makes me double hurl
[06:26] <fabrice_sp> cody-somerville, you're right. anyway, I've been able to reproduce the problem, so I'm waiting for more info to see, so no uplaod for the moment
[06:26] <fabrice_sp> s/I've/I've not/
[06:34] <AnAnt> can someone comment on this: LP 475338
[06:34] <AnAnt> I need opinion regarding that last comment I put there
[06:34] <fabrice_sp> AnAnt, you just opened it?
[06:35] <AnAnt> fabrice_sp: nah, it was opened few days ago, and got ack'ed by Daneil
[06:35] <AnAnt> Daniel
[06:36] <AnAnt> but I added a comment yesterday that there is a remaining difference (that I overlooked when I filed the sync request), but I see that this difference can also be dropped
[06:36] <fabrice_sp> I think it's safe to sync, even more if armel works fine with gcc 4.4
[06:37] <AnAnt> ok, thanks
[06:37] <fabrice_sp> yw :-)
[06:37]  * fabrice_sp goes back to the sponsorship queue
[06:37] <AnAnt> fabrice_sp: you following the TL2009 development ?
[06:38] <AnAnt> fabrice_sp: they just uploaded tl2009 to NEW !
[06:38] <fabrice_sp> tl2009?
[06:38] <AnAnt> texlive
[06:39] <AnAnt> it will still remain in experimental for a while though
[06:39] <fabrice_sp> ohh: I was speaking about the Ubuntu sponsorship queue :-)
[06:39] <fabrice_sp> so it won't make it for Lucid?
[06:40] <AnAnt> dunno
[06:41] <AnAnt> I hope it would
[06:54] <dholbach> buon giorno!
[06:55]  * geser yawns a good morning
[07:11] <fabrice_sp> good morning dholbach !
[07:11] <dholbach> hi fabrice_sp
[07:12] <ajmitch> hi
[07:14] <dholbach> maco: mvo and I were talking of writing an edit-patch command which wraps around whatever crazy crack the package uses and just works - there's some initial code and I guess we're going to finish it on the plane tomorrow :)
[07:14] <dholbach> maco: so hopefully for UDS and lucid we can put it somewhere :)
[07:15] <ScottK> dholbach: I think that's an excellent plan.
[07:15] <maco> cool!
[07:15] <ScottK> One of my concerns about the trend towards quilt is it increases the already steep learning curve for newcomers.
[07:15] <dholbach> definitely
[07:15] <dholbach> in any case after UDS we'll put up whatever we have, so we can finish off the rest
[07:19] <sbeattie> heh, I think it depends on what you know; I'd used and understood quilt for quite a while before I ever touched a debian package; but dpatch just seems utterly unhelpful.
[07:22] <AnAnt> so after UDS , quilt source packages will be accepted ?
[07:22] <dholbach> geser, persia, nixternal: we could stage a round of -1s today - it's Friday 13th ;-)
[07:22] <dholbach> AnAnt: I don't think - it'll take a bit longer to get support into LP for that
[07:22] <dholbach> AnAnt: but wgrant will know the exact-exact-exact answer
[07:22] <AnAnt> ok
[07:23] <nixternal> dholbach: ooh, good one
[07:23] <wgrant> 2009-12-05 at the latest. It may be before that if Debian increases adoption rapidly.
[07:23]  * wgrant checks today's count.
[07:24] <wgrant> Currently sitting at 0.39% of unstable, and the adoption rate has slowed lately.
[07:25] <AnAnt> wgrant: can you tell me about a small package that uses quilt format ?
[07:25] <dholbach> quilt?
[07:25] <wgrant> quilt itself, yes.
[07:25] <AnAnt> ok
[07:25] <AnAnt> thanks
[07:29] <randomaction> is it on by default in Debian already?
[07:30] <ScottK> It's supported, but not by default in Debian.
[07:34] <wgrant> I think some of the #ubuntu-devel discussion might have influenced that.
[08:15] <dholbach> persia: you've been over-eager with the wiki cleanup
[08:16] <dholbach> persia: Rodney and Scott are still on our list for next time
[08:16] <dholbach> or whenever
[08:16] <maco> hahahaha
[08:18] <persia> dholbach: I just commented them out.  I figured they'd uncomment themselves if they could make the next meeting.
[08:18] <dholbach> got it
[08:27] <highvoltage> yay! maco is a MOTU!
[08:34] <huats> congrats porthose_
[08:35] <huats> and of course congrats maco
[08:35] <porthose_> huats, ty :)
[08:35]  * dholbach hugs maco, porthose_ and diwic
[08:35] <dholbach> well done :)
[08:36]  * porthose_ hugs dholbach :)
[08:37] <hyperair> congrats maco =)
[08:40] <maco> hyperair: thanks
[08:41] <maco> thanks huats
[08:41] <maco> now really...nearly 4am. sleep time!
[11:06] <\sh> moins
[11:19] <highvoltage> mouns \sh!
[11:19] <siretart`> hi \sh, hi highvoltage!
[11:21] <highvoltage> hey siretart`
[11:21]  * highvoltage wonders about motu people and funny characters in their names
[11:22] <\sh> highvoltage\n, this nick is older then ubuntu ;)
[11:22] <highvoltage\n> \sh: so is mine!
[11:22] <highvoltage\n> (well not with the newline)
[11:23] <siretart`> highvoltage\n: that's because at work I use another irc client (rcirc), whereas my irssi runs on my private host in a datacenter
[11:23] <highvoltage\n> siretart`: aah
[11:23] <siretart`> btw, rcirc rocks, hard.
[11:24] <highvoltage> never used it before, what does it do?
[11:24] <siretart`> \sh: may I assume that the karmic kernel (finally) has a fixed aufs module that works over nfs?
[11:24] <siretart`> highvoltage: http://www.emacswiki.org/emacs/rcirc
[11:25] <\sh> siretart, hmm...regardnig waldemar and thomas: no
[11:25] <\sh> "See
[11:25] <\sh> fai-ubuntu-NFSROOT.patch as example. Here we have used unionfs-fuse
[11:25] <\sh> instead of aufs2. Ubuntu removed the aufs2 binary packages in
[11:25] <\sh> Karmic."
[11:26] <siretart`> err, unionfs-fuse? wtf?
[11:27] <siretart`> hm. as long as it works (better) than the in-kernel alternative.. sounds promising...
[11:28] <\sh> siretart, thomas is working on incorporating the changes into his fai main tree...he proposed as well, to work on two branches in fai svn..
[11:28] <\sh> so doing some changes for ubuntu, and moving it slowly into the main branch when debian changes to NWO, too
[11:30] <siretart`> NWO?
[11:30] <\sh> New World Order
[11:30] <siretart`> ah
[11:30] <\sh> siretart, you are  not a fan of Hulk Hogan, aren't you?
[11:31] <siretart`> that's about 2 decades ago..
[11:31] <\sh> siretart`, I'll take it as compliment ;)
[11:31] <siretart`> *g*
[11:31] <siretart`> I'm skimming over the patch.. hmm. just having the unionfs-fuse package in the nfsroot is sufficient to activate it? uh?
[11:33] <siretart`> hm, anyway. won't become urgent for me before next week
[11:33] <\sh> siretart, setting export UNIONTYPE="aufs" unionfs
[11:33] <\sh> but it's not in the patches somehow
[11:34] <\sh> I'll just mailed the fai ml to ask him
[11:35] <slytherin> ttx: Do you mind if I port libjug-java from Ubuntu to Debian. It is one of the essential build-dep for cruisecontrol.
[11:58] <ttx> slytherin: not at all, feel free to port any missing library :)
[11:58] <slytherin> ttx: thanks
[13:05] <ttx> question: I'm merging a -0ubuntuN with a -1 and the orig.tar.gz from debian is slightly different, what's the recommended solution to that case ? Keep ours and make a note in changelog ?
[13:06] <bddebian> Heya gang
[13:13] <StevenK> ttx: Yes, keep our .orig, after making sure they really do contain mostly the same contents
[13:13] <ttx> StevenK: I'm confirming that right now. Thanks !
[13:20] <slytherin> ttx: StevenK: What would be the version in Ubuntu in this case?
[13:21] <ttx> slytherin: -1ubuntu1
[13:22] <ttx> (for the record, unpacked  contents are strictly the same in my case)
[13:24] <ScottK> ttx: You have to keep the Ubuntu orig.tar.gz because if the md5sum doesn't match, Soyuz will reject the upload.
[13:24] <ttx> ScottK: I saw that :)
[13:24] <ScottK> OK
[13:26] <slytherin> ttx: I guess I will have to do fake sync for jmeter too
[13:26] <\sh> siretart, you don't need to change the aufs in unionfs...somehow it worked, told waldemar
[13:26] <ttx> slytherin: you uploaded a different orig.tar.gz between ubuntu and debian ?
[13:29] <slytherin> ttx: No. But for some reason the size for repackaged upstream tar ball is different on both distributions.
[13:30] <ttx> ...?
[13:30] <directhex> slytherin, compression will differ from the tiniest of things
[13:31] <directhex> i.e. mtime/atime
[13:31] <slytherin> I don't know what is the reason. May be my get-orig-source taregt is broken.
[13:31] <directhex> slytherin, is upstream a bzip2? zip?
[13:31] <ttx> directhex: right, but if he uploaded the same orig.tar.gz to both ubuntu and debian, that would be the same
[13:31] <slytherin> ttx: In that sense, yes the to tar balls are different.
[13:31] <directhex> ttx, every call to get-orig-source will produce a new md5sum, unless you account for it in your rule
[13:32] <slytherin> directhex: tar.gz, but I have to repack it to remove included jar files.
[13:32] <ttx> directhex: that's why he should only call it once :)
[13:32] <directhex> slytherin, want a recipe?
[13:33] <slytherin> directhex: Nope. Next time I am putting packages in Debian first. :-)
[13:33] <directhex> slytherin, i meant just in case. your enemy is mtime.
[13:34] <slytherin> directhex: Ok. Tell me.
[13:34] <siretart`> \sh: interesting...
[13:34] <directhex> slytherin, http://svn.debian.org/wsvn/pkg-cli-libs/packages/mysql-connector-net/trunk/debian/rules
[13:35] <directhex> slytherin, the key is the --mtime= flag to tar, and the -n flag on gzip
[13:38] <slytherin> ok
[13:39] <slytherin> directhex: what should be the value of mtime?
[13:40] <directhex> slytherin, any hard-coded number. but lintian will bitch if it's not recent enough.
[13:40] <directhex> try the value from "date -d 2009-11-13 +%s"
[13:40] <slytherin> ok
[14:25] <serialorder> highvoltage, I am testing a package I built in a schroot and I get the following error: Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory
[14:26] <serialorder> the application runs fine otherwise
[14:26] <serialorder> should I add a depends on canberra-gtk-module ?
[14:31] <ripps> serialorder: is the canberra part essential, or is it optional?
[14:33] <serialorder> ripps, i don't know the answer to that question I will try to figure that out, not exactly sure how
[14:34] <ripps> If it's essential it should be a depends, if not it should be a Recommend or Suggest
[15:22] <segler> hi, i need an advocate. please have a look at my small python rhythmbox plugin at http://revu.ubuntuwire.com/p/rhythmbox-radio-browser, thanks
[15:23] <ari-tczew> we have new patch tagging standards?
[15:28] <highvoltage> nixternal: hey, are you around?
[15:30] <nixternal> highvoltage: what's up?
[15:30] <highvoltage> I'll send you a pm
[15:31] <nixternal> k
[15:51] <EzraR> what would make a package to startbuilding with clean
[15:54] <EzraR> fakeroot debian/rules clean is the first and only thing this package does
[15:55] <EzraR> no build no install etc
[15:55] <EzraR> they are in the rules file
[15:55] <EzraR> its like it just skips them
[16:05] <EzraR> nobody?
[16:06] <ripps> EzraR: the default action is to run clean first, to make sure the build environment is clean. What's your package and what do have in you rules file?
[16:07] <EzraR> ripps: im trying to fix a bug in gw6c
[16:09] <ripps> EzraR: apparently the package attempt to patch the source with dpatch, do you have dpatch installed?
[16:10] <EzraR> ripps: yes
[16:15] <EzraR> i guess ill try building without any patches
[16:15] <EzraR> see if they are the cause...
[16:16] <ripps> EzraR: sorry my computer froze, did I miss anything?
[16:20] <EzraR> ripps: i said i had dpatch installed, and that i guess ill try building without the patches to see if they were the problem
[16:20] <ripps> EzraR: huh... It looks the dpatch.make file is empty... this must be a bug
[16:25] <EzraR> ripps: /usr/share/dpatch/dpatch.make ?
[16:25] <EzraR> ripps: mines not
[16:27] <ripps> EzraR: ah, my dpatch just installed incorrectly, probably due to my pc freezing
[16:30] <EzraR> so iff i take out all the patch names in 00list that should efectivly not include the patches in a build right?
[16:30] <ripps> EzraR: well, my gw6c just built completly in pbuilder, so I don't know what's wrong
[16:30] <ripps> It applied the patches properly too
[16:32] <ripps> EzraR: how exactly are you building the packages? Are you using pbuilder?
[16:35] <EzraR> yeah...
[16:36] <ripps> EzraR: do you get all OK's when you `dpatch apply-all`?
[16:36] <EzraR> i was looking at debuild output..
[16:36] <ripps> (remove patches with `dpatch deapply-all`)
[16:37] <ripps> EzraR: can you pastebin your debuild output?
[16:37] <EzraR> but if i remove them with that wont they still be applyed during build?
[16:38] <ripps> EzraR: 00list determines what's to be patched at build time, I'm just trying to determine if there is indeed something wrong with the patches.
[16:39] <EzraR> http://pastebin.com/d4d0e40b7
[16:40] <EzraR> os debuild suposed to go through the build targets after clean?
[16:40] <EzraR> is
[16:44] <ripps> EzraR: I don't know... it should be working. This wasn't built with pbuilder, It's hard to make sure you have an isolated environment unless your running from pristine environment like pbuilder...
[16:45] <EzraR> i am building with pbuilder
[16:45] <EzraR> you asked for my debuild output
[16:46] <hyperair> it's the same.
[16:46] <ripps> EzraR: sorry, pbuilder runs debuild too.
[16:46] <hyperair> debuild calls dpkg-buildpackage. pbuilder calls dpkg-source which calls dpkg-buildpackage
[16:46] <hyperair> no, i don't think pbuilder runs debuild
[16:47] <ripps> hyperair: your right, it runs dpkg-buildpackage within an isolated environment
[16:47] <EzraR> i was under the impression you used debuild and then built in pbuilder using the .dsc from debuild
[16:48] <hyperair> debuild calls dpkg-buildpackage under almost all circumstances
[16:49] <hyperair> exceptions being errors
[16:49] <hyperair> e.g. unsatisfied build deps
[16:49] <ripps> EzraR: no, you shouldn't need to ever install any -dev packages, just setup a package, and just run `pdebuild` and it will automatically import the source and the debian/ packaging into pbuilder to build it for you.
[16:49] <EzraR> does it make a diff if i use dbuild -S
[16:49] <hyperair> debuild -S creates dscs, debuild -b builds binaries (i think dscs are also created, but not sure)
[16:51] <ripps> EzraR: you should only create dsc's when your sure that the package will actually build correctly. pbuilder is meant for testing before you upload to a ppa or repository. Also, pbuilder will output in successfully built packages into /var/cache/pbuilder/result/
[16:52] <EzraR> well i took out all the patches from 00list and built it and still get the bug, so I can safely say it has nothing to do with the patches right?
[16:54] <ripps> EzraR: you need the include the patches, otherwise the package doesn't build
[16:55] <EzraR> i left the include dpatch.make, i just took out all patches from 00list
[16:56] <ripps> EzraR: I'm saying that was unnecessary
[16:57] <EzraR> ripps: unnecessary?
[16:57] <ripps> Every time I run pdebuild, full 00list and empty 00list, I still had pbuilder build successfully...
[16:57] <EzraR> ripps: the bug im trying to fix is not if it builds or not :)
[16:58] <ripps> EzraR: what exactly is the bug?
[16:58] <EzraR> ripps: i was confused earlier and was thinking debuild -S should go through the build targets of the rules file...
[16:59] <EzraR> ripps: the bug is it doesnt install a gw6c.conf into /etc/gw6c or anywhere for that matter
[16:59] <EzraR> ripps: sounds like a real easy fix right :)
[17:00] <ripps> EzraR: okay... let me look around the rules files a bit...
[17:01] <EzraR> look in tspc-advanced/Makefile
[17:07] <ripps> EzraR: I understand the problem, it's suppose install a conf in /etc, but isn't. The easist solution would be copy the sample conf in the correct directory at build time...
[17:11] <EzraR> ripp: i tried that but failed
[17:12] <EzraR> ripps: tspc-advanced/conf/Makefile is where the sample conf is generated
[17:13] <ripps> EzraR: yeah, it might be as simple as copying that conf.sample into debian/tmp/etc/gw6c/gw6c.conf
[17:17] <EzraR> at line 38 in
[17:17] <EzraR>  tspc-advanced/conf/Makefile i added a cp line but it came out wrong
[17:18] <EzraR> it didnt get the output from the sed cmd
[17:18] <EzraR> that was the first thing I tried when fixing this
[17:24] <ripps> EzraR: I'm testing some ideas, I'll let you know if any pan out
[17:25] <ripps> EzraR: Okay, I think I figured it out, just add `
[17:25] <ripps> `cp tspc-advanced/conf/gw6c.conf.sample debian/gw6c/etc/gw6c/gw6c.conf` to the end of install: section
[17:26] <ripps> in your debian/rules
[17:29] <EzraR> ripps: ok ill test it out
[17:31] <EzraR> ripps: did you notice the spelling error in that section
[17:31] <EzraR> :)
[17:31] <EzraR> [#ubuntu-motu]
[17:31] <EzraR> platofmr
[17:31] <ripps> EzraR: yeah, but it seems to work with it anyway, so why bother it
[17:35] <fabrice_sp> ari-tczew, about bug 477798. Did you checked why the package was not yet in testing, after 27 days?
[17:38]  * ripps is going to take a shower
[17:38] <EzraR> ripps: what does debian/rules:63: *** missing separator.  Stop. mean
[17:38] <EzraR> ripps: what seeparator
[17:39] <StevenK> EzraR: That usually means you have a command in it that doesn't start with tab
[17:39] <EzraR> ScottK: thnx
[17:39] <ripps> what ScottK sayid
[17:41]  * StevenK notes he isn't ScottK 
[17:41] <EzraR> ripps: go take a shower you stink :)
[17:42] <EzraR> StevenK: lol im sorry
[17:42] <EzraR> StevenK: the brain reads words at a time
[17:43] <maco> S<abunchaletters>K ?
[17:45] <StevenK> maco: And you get it to too with mako's similarity
[17:46] <maco> StevenK: actually, never on irc
[17:46] <highvoltage> maco! congrats on becomming a motu!
[17:46] <maco> highvoltage: thanks
[17:47] <maco> wait i lied
[17:47] <fabrice_sp> Hey maco: congrats!
[17:47] <maco> paul flint thought i was mako. "no no the dc one"
[17:47] <maco> fabrice_sp: thanks
[17:54] <ari-tczew> fabrice_sp: no
[17:55] <fabrice_sp> it seems to be an ugly priviledge escalation that was not there before, so I would prefer to wait until it get fixed, to avoid merging 2 times
[17:56] <fabrice_sp> we are still early in the cycle
[17:56] <ari-tczew> fabrice_sp: http://packages.qa.debian.org/s/slim/news/20090817T163923Z.html
[17:56] <fabrice_sp> except if someone else say the contrary
[17:56] <ari-tczew> removed because no exist in unstable?
[17:56] <fabrice_sp> no: have a look there: http://release.debian.org/migration/testing.pl?package=slim
[17:57] <fabrice_sp> (you can go there from bts package page)
[17:57] <fabrice_sp> new bugs introduced by this version
[17:59] <randomaction> fabrice_sp: 1.3.0-2 is also affected
[17:59] <ari-tczew> slim has been removed from karmic because it was buggy, unmaintained, but now is new maintainer
[18:00] <fabrice_sp> randomaction, strange. a comment seems to say the contrary: The bug was cloned from the package applying to the Sid version, but in the end doesn't apply to the package version in Lenny.
[18:01] <fabrice_sp> right: it's not in karmic
[18:02] <ari-tczew> an other comment seems to say that it is like as a new feature
[18:02] <fabrice_sp> so if it's not even present in Karmic, and new maintainer, I would say: wait until it enters testing
[18:02] <randomaction> ah, it makes sense
[18:02] <fabrice_sp> yeah: it's not very clear :-/
[18:03] <ari-tczew> when it will enter testing?
[18:03]  * fabrice_sp forgot to upload  the .orig tarball of tesseract :-/
[18:03] <fabrice_sp> ari-tczew, when this bug report will be closes, as the other one is already closed
[18:05] <ari-tczew> ehh
[18:05] <ari-tczew> fabrice_sp: are you bored? I have next bug for you :P
[18:06] <fabrice_sp> still sponsoring and building at the same time
[18:06] <fabrice_sp> not bored at all!
[18:06] <fabrice_sp> :-)
[18:07] <fabrice_sp> just give the bug number ;-)
[18:08] <ari-tczew> that's beautiful co-operation with sponsors! :)
[18:08] <ari-tczew> give me a moment
[18:08] <ari-tczew> I need to just report ;d
[18:08] <fabrice_sp> lol
[18:08] <fabrice_sp> no comment :-P
[18:11] <ari-tczew> bug #482278
[18:13]  * fabrice_sp checking
[18:13] <ari-tczew> ;-)
[18:14] <fabrice_sp> Now that I'm MOTU, I upload a lot less packages by myself than before! :-D
[18:16] <ari-tczew> Fabrice: please, don't fall in narcissism :P
[18:16] <fabrice_sp> Ack'd
[18:17] <fabrice_sp> (ffproxy, I mean)
[18:17] <ari-tczew> thanks brother :D
[18:17] <fabrice_sp> ;-)
[18:18] <ari-tczew> fabrice_sp: do you no need waiting for ubuntu archives admins?
[18:18] <ari-tczew> for synces
[18:18] <fabrice_sp> Just trying to keep the sponsoring queue as small as possible (and it's not easy because of you, guys! :-) )
[18:18] <fabrice_sp> ari-tczew, yes: motu can't do the sync, just ack it
[18:19] <ari-tczew> yhym
[18:19] <fabrice_sp> diner time: bbl
[18:19] <ari-tczew> bye
[18:20] <jdong> fabrice_sp: heh wrt bug 475891 I don't really have an opinion anymore :)
[18:22] <EzraR> fabrice_sp: did you speak to the deb maintainer about using the patch on solfege, or are you asuming from the dialog on the deb bug report?
[18:22] <EzraR> fabrice_sp: that he would be willing to use it
[18:32] <EzraR> anyone good with perl?
[18:32] <EzraR> or at least some idea
[18:33] <EzraR> heh
[18:38] <ari-tczew> ~ubuntu-archive has got a lot of work :P
[18:38] <StevenK> Well else is new ...
[18:49] <ari-tczew> good luck :P
[18:50] <AnAnt> Hello
[18:51] <AnAnt> why do most (if not all) upstream not use -Wl,--needed in LDFLAGS ?
[18:54] <bmhm> hi all
[18:54] <bmhm> I'm almost positive that there is a missing dependency or at least recommendation
[18:55] <bmhm> the tagger "picard" by musicbrainz does not support PUIDs on ubuntu (i.e. audio-fingerprints)
[18:55] <bmhm> can someone verify that for me please?
[18:55] <ari-tczew> fabrice_sp: let's go! bug #482295
[19:05] <fabrice_sp> jdong, do you think that if it's only on upgrade, it's worth a SRU?
[19:06] <fabrice_sp> EzraR, IIRC, that's what I saw in the debian bug report
[19:06] <jdong> fabrice_sp: what is the SRU? Same fix as above? Why does it work? Why does it only happen on upgrades?
[19:07] <fabrice_sp> jdong, yes: the ugly 'copy the binary to $HOME/.eagle' fix
[19:07] <fabrice_sp> no idea why it fails for upgrade only (new install don't have that file in home)
[19:08] <jdong> and by "fresh install" in the bug comment, you mean wipe the entire system and then install, right?
[19:08] <fabrice_sp> no :-D
[19:08] <jdong> not apt-get remove {{--purge}} and reinstall, right?
[19:08] <jdong> what?
[19:08] <jdong> now this is making less sense
[19:09] <fabrice_sp> I think it's apt-get purge / install
[19:09] <jdong> ok
[19:09] <fabrice_sp> I wasn't able to reproduce the problem
[19:09] <jdong> based on this information... what I lack right now is a coherent explanation of why this bug occurs
[19:09] <jdong> and I'm much more reluctant about the SRU's proposed fix
[19:09] <fabrice_sp> jdong, exactly. And Debian didn't really gave an explanation about that
[19:09] <jdong> right
[19:09] <jdong> other than "the debian dev that did it is really awesome"
[19:10] <jdong> which I would accept if the package didn't just go to the orphanage
[19:10] <fabrice_sp> lol
[19:10] <fabrice_sp> ohh
[19:10] <fabrice_sp> really?
[19:10] <jdong> apparently it's up for adoption, according to the bug comments
[19:10] <jdong> and given those circumstances I am not 100% sure the bugfix was really all that well tested / thought through on the Debian side
[19:11] <jdong> but given that eagle is not exactly telepathy or Xorg in urgency
[19:11] <jdong> I'd say let's  try to come up with a more satisfactory explanation of why it's broken
[19:11] <jdong> before attempting to shove through silly one-liner hacks when we still don't agree what the symptoms are yet :)
[19:11] <jdong> eventually once we understand the problem enough to make a fix,  I would be interestd in a SRU for it
[19:12] <fabrice_sp> makes sens
[19:12] <fabrice_sp> e
[19:12] <jdong> yeah feel free to paraphrase this onto the bug report
[19:12] <fabrice_sp> sure :-)
[19:12] <jdong> Scott Howard seems to be quite interested in the bug and making good progress on it
[19:12] <jdong> I'm sure the resolution won't be far from today
[19:12] <fabrice_sp> yes
[19:19] <AnAnt> hmmm, how can I run autogen without making it run configure
[19:21] <bmhm> has anyone read my request?
[19:24] <ripps> bmhm: scan in my picard works fine
[19:24] <bmhm> ripps: not talking about scanning
[19:24] <bmhm> I meant generating and sending PUIDs
[20:35] <leonel> hello :
[20:36] <leonel> Somedays ago I've submited a diff for squirrelmail, was something wrong with it ?   bug 446838
[20:45] <fabrice_sp> leonel, it seems ok. Waiting for a security team ack
[20:49] <Matthias_M> How do I port http://packages.debian.org/squeeze/gchempaint 0.10 to karmic/ppa or lucid (it is still 0.8); where do I start. I can't find the correct manual. I am a total newbie.
[20:51] <Matthias_M> still wondering why the auto-sync failed
[20:55] <randomaction> Matthias_M: see bug 233963
[20:57] <randomaction> I tried to merge it but there was a problem I couldn't fix
[20:58] <Matthias_M> can I help somehow?
[21:00] <randomaction> sure, you could prepare a merge of 0.10.8
[21:00] <randomaction> !merge
[21:01] <Matthias_M> thanks
[21:10] <leonel> fabrice_sp_: thanks
[21:11] <fabrice_sp_> leonel, just be patient :-) The security team has a lot of bugs (as you can imagine :-D)
[21:11] <leonel> fabrice_sp_: that's what I was thinking since this diff i've submited just before karmic release
[21:16] <mdeslaur> leonel: let me take a look
[21:16] <jdstrand> leonel, fabrice_sp_: the bug doesn't follow https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Submission
[21:16] <jdstrand> that is why it wasn't picked up
[21:17] <fabrice_sp_> oh, missed that. you're right
[21:17] <jdstrand> we have scripts to help us identify sponsored security updates
[21:17] <fabrice_sp_> I'm not used to this 'In progress' state
[21:17] <fabrice_sp_> sorry about that
[21:17] <jdstrand> not a problem
[21:17] <jdstrand> sorry we didn't notice it sooner
[21:18] <mdeslaur> leonel: I'll take a look at the patches, thanks!
[21:19] <leonel> mdeslaur: thanks  ,
[21:20] <leonel> that  process was new to me ..
[21:27] <mdeslaur> leonel: np...it'll take me a couple of days to review it...it's a _big_ patch :)
[21:28] <leonel> mdeslaur: it is
[21:28] <mdeslaur> thanks leonel!
[21:28] <leonel> mdeslaur: and squirrelmail does not uses  a patch system
[21:33] <Matthias_M> do I have to change /usr/lib/iceape/ to /usr/lib/firefox for the Ubuntu package?
[21:34] <Matthias_M> I mean iceweasel
[21:36] <DBO> are there any Makefile autoconf experts that could help our project get building with make distcheck
[21:36] <DBO> I really want to roll a release tarball, but I just cant make it work
[21:43] <maco> i'm logged into lp. i want to join ~ubuntu-universe-sponsors. the "join" button appears to be invisible, however. any idea how to join it?
[21:44] <StevenK> maco: It's a Restricted Team, you need to be invite
[21:44] <StevenK> *invited
[21:44] <maco> oh
[21:44] <maco> so thats what that means
[21:44] <maco> the little "?" icon next to "restricted team" doesnt seem to do anything
[21:45] <StevenK> Yeah, I just noticed that too. :-)
[21:45] <StevenK> maco: Prod one of the admins to invite you
[21:46] <ajmitch> which looks to be one of persia or TheMuso
[21:46] <ajmitch> hopefully one of them is in the right timezone & online :)
[21:46] <maco> well im pretty sure its like 3am in japan
[21:47] <StevenK> ah
[21:47] <StevenK> *Nah
[21:47] <StevenK> 5:47am or so
[21:47] <maco> ok so still an unreasonable time for persia to be awak
[21:47] <maco> e
[21:47] <ajmitch> and they may be near UDS
[21:47] <StevenK> TheMuso is probably not going to join IRC before he flies out
[21:48] <ajmitch> I thought he probably would have left by now
[21:48]  * maco crosses fingers that he found chocolate
[21:49] <ajmitch> heh
[21:49] <maco> (there's an aussie company that makes non-dairy white chocolate, not available in the US)
[21:50] <ajmitch> and so you're coercing people to bring it in for you?
[21:50] <maco> yes
[21:51] <maco> im told by a non-dairy friend whose sister is in oz that it can be carried by visitors, but customs gets upset if you try to have it shipped in
[21:51] <maco> (said friend is how i learned of its existence)
[21:52] <ajmitch> you'll find out soon enough if TheMuso is detained at customs :)
[21:52] <StevenK> Haha
[21:53] <ScottK> Depending on how closely he's 'inspected', you may owe him big time.
[21:53] <maco> no no its fine to carry in the chocolate!
[21:53] <maco> her sister does when she visits
[21:53] <maco> its just some sort of "zomg importing goods! tariffs! eek!" thing when you try to buy a bunch of chocolate from au
[21:54] <serialorder> not sure if this is the right place but the package i am merging is built and installed in my schroot and when i start it to test it I get a warning saying that I am missing a library. It runs fine otherwise. I was told I should track down where that library is being called from
[21:54] <serialorder> any tips on how i might approach that?
[21:55] <maco> ldd?
[21:56] <ScottK> I'm reminded of a story that was current in Ireland when I lived there in the mid-80s.  At the time 'family planning devices' were only available with a perscription.  You were allowed to bring such items in from outside the country for personal use only.  The story was a man was caught with a suitecased full, which he pleaded were for personal use, so they arrested him for attempted suicide.
[21:56] <ScottK> No idea if it's actually true.