[03:10] <savvas> hmm
[04:50] <fmarier> I've got a question about LP#350732: I subscribed universe-sponsors to it in the hope that it will be picked up for Jaunty, however someone else marked it as "confirmed".  Does this mean that it will not be seen by the motu?
[04:59] <fmarier> bug 350732
[04:59] <fmarier> is this supposed to trigger a bot response?
[05:01] <savvas> fmarier: yes, either that or bug #350732 (I also think LP: #350732 triggers it)
[05:01] <savvas> anyway, you've followed the correct process :)
[05:02] <fmarier> so "confirmed" is fine? I remember someone telling me that it was better for some reason to leave it as New until it was acked by a sponsor...
[05:03] <savvas> I'm really not sure, but if I remember correctly the status shouldn't be changed after the sponsors are subscribed to it
[05:04] <fmarier> ok, well as long as the bug is considered for Jaunty then I'm happy... the version of asterisk that's currently in there is pretty useless for anybody wanting to use encryption :(
[05:12] <LucidFox> If a Debian package has the same upstream version but adds a new binary package, I suppose it's better not to merge it after FF?
[05:15] <dtchen> there's no explicit reason not to if there are bugfixes
[06:07] <dholbach> good morning
[06:09] <Adila01> Depending where you are
[06:13]  * nixternal hugs dholbach 
[06:13]  * dholbach hugs nixternal back
[06:14] <nixternal> hey, check the planet...could someone take a look at python-coherence bugs and see if you can help with that during the personal emergency please? if you can, please ping me and let me know...if I don't hear anything by morning, I will ask again
[06:14]  * nixternal has an interview bright and early
[06:14] <Hobbsee> nixternal: if you're going to play april fools day jokes, i wish you'd do it while it's actually april fools day in forward-countries.
[06:15] <nixternal> porthost is going through a personal emergency and has 2 bugs #352653 and #338963 that he would like someone to look after while he is gone, looks like he will be gone for more than a week
[06:16] <nixternal> Hobbsee: why? it is more fun that way, plus I am tired of this whole international thing, everyone just needs to get over it and set their clocks to CST (Chicago Standard Time) :p
[06:16] <maco> or to UTC
[06:16] <nixternal> GMT
[06:16] <nixternal> do it right
[06:16] <maco> nah, UTC
[06:16] <maco> cuz the UK has summer time, like DST
[06:16] <Hobbsee> heh
[06:17] <nixternal> GMT!
[06:17] <Adila01> EST
[06:17] <nixternal> there is no such thing as 00:00 or Zero Hours...silly UTC
[06:18] <maco> yeah there should be 00:01 through 24:00
[06:18] <nixternal> that is what the Astronauts use, so we should use it too
[06:18] <maco> though apparently at 00:00 UTC it's tomorrow, not still today
[06:18] <maco> which cnfuses me
[06:18] <nixternal> there should be 24:00 to 24:00
[06:19] <maco> nixternal: wait! you were in the military! you should be used to Zulu
[06:19] <nixternal> GMT is the civilian version and Zulu is the military version
[06:20] <nixternal> the funny thing is, they all mean the same damn thing :p
[06:23]  * nixternal goes to bed
[06:23] <nixternal> g'nite
[06:23] <dholbach> nightie nixternal
[06:23] <maco> i thought GMT still observed summer time?
[06:24] <dholbach> no
[06:24] <dholbach> BST
[06:24] <dholbach> British Summer Time
[06:25] <maco> ooo
[06:25] <dtchen> there's often confusion between the original measurement and the more colloquial timezone usage
[06:25] <dtchen> in the former, utc is an approximation within 0.9 secs of gmt
[06:26] <dtchen> in the latter, you have the infamous "but utc isn't gmt" junk
[06:26] <dtchen> regardless, i trust `date -R'
[06:27] <maco> not date -u?
[06:27]  * nixternal trusts his clock in his vista task bar
[06:27] <nixternal> ok, didn't go to bed yet, pkg updates :p
[06:27]  * maco steals nixternal's clock
[06:27] <maco> neener neener!
[06:27] <nixternal> zsh + dpkg -l are not friends
[06:27] <dtchen> packaging convention uses `date -R'
[06:27] <maco> oh that
[06:27]  * Hobbsee hands nixternal a \
[06:35] <maco> dtchen: also, *why* do you know that 0.9 seconds of gmt thing?
[08:10] <Toadstool> good morning
[11:16] <mcnicholls> hi
[11:16] <mcnicholls> what group do i subscribe if i want to get sponsorship on a package in multiverse?
[11:20] <dholbach> mcnicholls: ubuntu-universe-sponsors
[11:21] <mcnicholls> thanks Daniel ;-)
[11:21] <dholbach> no worries
[15:21] <mcnicholls> have got a package that needs rebuilding because of an NBS dep, but the package FTBFS. Would a merge be considered at this point in the cycle or would taking a specific patch from upstream and making a new ubuntu version be better?
[15:31] <bddebian> Heya gang
[15:31] <cody-somerville> hi
[15:32] <bddebian> Hi cody-somerville
[15:32] <cody-somerville> :)
[17:09] <Pollywog> when I look for kmail bugs in launchpad, it replies "There is no project named 'kmail' registered in Launchpad"  Does that mean I cannot use Launchpad to find bugs in kmail or am I possibly using the wrong name for the project that includes kmail?
[17:11] <Pollywog> that's it, I found kmail within kdepim
[17:38] <fidji> hi
[17:38] <fidji> how I can make a package for all distrib ?
[17:38] <fidji> in changelog
[17:39] <savvas> I don't think you can :) different distributions use different package versions
[17:40] <savvas> you could build one for hardy and then use it for the rest, but I'm not sure
[17:40] <savvas> rest = intrepid, jaunty
[17:40] <fidji> for all ubuntu
[17:41] <fidji> actually I use intrepid
[18:09] <fidji> I see in some ppa, package for all ubuntu (intrepid, jaunty, ...)
[18:09] <fidji> I wish do the same in mine
[18:09] <fidji> https://launchpad.net/~ubuntu-fr-scripts/+archive/ppa
[18:10] <dyfet> fidji: In my case, I simply named each source set with ~distroname appended
[18:11] <dyfet> fidji: hence, xxx~ppa1~hardy1, xxx~ppa1~intrepid1
[18:12] <fidji> I must do one ppa for each ditroname ?
[18:12] <fidji> distroname*
[18:13] <dyfet> That seems to be the case, or at least it is what I did.
[18:14] <fidji> ok thank's
[18:14] <dyfet> Unless someone else has an alternate solution to offer :)
[18:30] <fidji> there is a delay to see the latest build  package in synaptic ?
[18:31] <dyfet> You mean from ppa dput and build, to finally being able to see and access newly built packages?
[18:32] <fidji> I have 2 packages in the ppa
[18:32] <fidji> but in synaptic I see only one
[18:34] <dyfet> https://launchpad.net/~fidji+archive/ppa ?
[18:34] <fidji> yep
[18:34] <fidji> I see only ufrs-toolbox
[18:35] <fidji> https://launchpad.net/~ubuntu-fr-scripts/+archive/ppa
[18:35] <dyfet> Ah...that one has packages...
[18:36] <dyfet> I notice that even though it shows build status complete, there is a delay before it adds it into the repo...
[18:36] <fidji> ah ok, I mean that too
[18:37] <fidji> so I waiting for ;)
[18:37] <dyfet> If you go to http://ppa.launchpad.net/ubuntu-fr-scripts/ppa/ubuntu/ you can see if it made it all the way through...
[18:38] <dyfet> And then you need to do a new apt-get update to refresh your machine after the repository is updated...
[18:38] <fidji> I see Status Published
[18:39] <dyfet> and http://ppa.launchpad.net/ubuntu-fr-scripts/ppa/ubuntu/pool/main/u/ seems to have both packages now
[18:40] <fidji> yes
[18:40] <dyfet> I think if you do reload package info in synaptic (under edit) you should see both now
[18:41] <fidji> I do the reload but always onlys one packqge
[18:42] <dyfet> hmm...
[18:43] <fidji> I make a mistake with the name of the first release
[18:43] <dyfet> Which one do you see?
[18:43] <fidji> urfs-toolbox
[18:44] <fidji> I whish see ufrs-math
[18:44] <fidji> http://ppa.launchpad.net/ubuntu-fr-scripts/ppa/ubuntu/pool/main/u/ufrs-math/
[18:44] <fidji> but I make a mistake with the first relase
[18:44] <fidji> bad name
[18:45] <fidji> ufrs-jeux_0.9.4-1_all.deb
[18:45] <fidji> perhaps it's better if I delete an redo ?
[18:46] <dyfet> I did not see your jeux one...
[18:47] <dyfet> Oh yes, I do...
[18:48] <fidji> ufrs-jeux_0.9.4-1_all.deb ufrs-math_0.9.4-2_all.deb
[18:49] <fidji> I mean that's the problem
[18:49] <dyfet> It could be...
[18:50] <fidji> ok I delete and redo
[18:50] <fidji> thank's for the help
[18:51] <dyfet> Hmm...
[18:51] <dyfet> ufrs-math - Pack ubuntu-fr-scripts Math
[18:51] <dyfet> ufrs-jeux - Pack ubuntu-fr-scripts Math
[18:51] <dyfet> ufrs-toolbox - Boîte à outils bash, perl, python
[18:51] <dyfet> I get that from apt-cache search when I add your repo...
[18:54] <fidji> yes I see that too
[18:55] <fidji> I delete the 0.9.4-1
[18:55] <dyfet> Both (maybe all 3) are installable from apt-get...
[19:01] <fidji> work with apt-get
[19:01] <fidji> so I wait for the deletion
[19:01] <dyfet> okay
[19:09] <maco> Can anyone force a rebuild on seahorse-plugins 2.26.0-0ubuntu2 for hppa?  There were broken dependencies at the time
[19:11] <dtchen> hobbsee: / Riddell:  ^giveback, please
[19:11] <dtchen> d'oh
[19:12] <ScottK> Did it build or FTBFS?
[19:12] <ScottK> Got it
[19:13] <ScottK> dtchen and maco: done.
[19:13] <ScottK> dtchen: Anyone with upload rights for the package can do that now.
[19:13] <maco> ScottK: thanks
[19:13] <maco> ScottK: it failed to build only on that arch because epiphany was broken at the time
[19:14] <ScottK> maco: That's not a rare thing.
[19:14] <maco> ScottK: dtchen said hppa gets behind because it's a port
[19:15] <ScottK> hppa gets behind particularly because the hppa buildd's are VERY slow and that particular port is the least well maintained.
[19:15] <ScottK> You'll see generally that powerpc (for example) keeps up reasonably well.
[19:16] <maco> dtchen: are built-in mics still busted all over the place?
[19:17] <dtchen> yes
[19:17] <dtchen> well, if one is extremely unlucky
[19:18] <maco> so if someone reports that everything but built-in mic works with a certain quirk on Jaunty, does that still mean "wrong quirk" or is it "right quirk, just busted"?
[19:19] <maco> (mine works right now, but I can't figure out how to make Wengo or Ekiga use PulseAudio's capture device)
[19:20] <dtchen> err
[19:20] <dtchen> "just busted" implies wrong qurik
[19:20] <dtchen> quirk*
[19:21] <dtchen> those two things are non-orthogonal
[19:21] <dtchen> meaning jack sensing and quirks are tied
[19:21] <maco> i thought there were many cases happening in jaunty only where internal mics regressed
[19:21] <dtchen> there are, and they're due to quirk regressions
[19:22] <dtchen> not *just* jack sensing regressions
[19:22] <maco> so do they mean it's the wrong quirk to use or that its the right quirk to use bt that the quirk is slightly broken and will be fixed?
[19:22] <blueyed> Can you debug apport hooks of a package, without actually sending a bug? (e.g. by using staging.launchpad.net) I could fake an entry for launchpad.net to the staging IP in /etc/hosts maybe.. - anything better?
[19:23] <dtchen> maco: they're the same in this case
[19:25] <maco> dtchen: so assuming those quirk regressions were caused by trying to fix something else, would the correct solution be to have 2 similar quirks (1 old behaviour, 1 new behaviour) and divide up the quirks table entries between them?
[19:26] <maco> (based on what worked only in intrepid v. only in jaunty)
[19:26] <dtchen> maco: err, meaning the foo_cfg_tbl[] or a wiki table?
[19:26] <maco> foo_cfg_tbl[]
[19:27] <dtchen> division would be bad
[19:27] <dtchen> step one is to fix the jack sense regression
[19:27] <dtchen> step two is to filter the quirk regressions
[19:28] <maco> what does jack sensing have to do with the internal mic? shouldnt that only break the plugin type?
[19:29] <jdong> directhex: what are your feelings on MD 2.0 final?
[19:29] <dtchen> maco: jack sensing is everywhere now
[19:29] <jdong> dtchen: do you have any magical insight on jaunty + skype's insane CPU usage?
[19:30] <jdong> skype almost certainly shares the blame but it's regressed from Intrepid
[19:30] <dtchen> geez, when it rains it pours
[19:30] <jdong> dtchen: haha I'm sorry :)
[19:30] <directhex> jdong, i have a standing feature freeze. it's a dead cert for jaunty.
[19:30] <dtchen> no, i'm just being bombarded on all sides by alsa questions from eric sandeen, you guys, etc., etc.
[19:31] <jdong> dtchen: I figured ;-) but that's what happens when you spring to life.
[19:31] <dtchen> yeah, well, i'm going back to work
[19:31] <jdong> directhex: awesomeness; yeah I've been screwing around with the new release and it's quite nice.
[19:31] <dtchen> lunch spent doing bug stuff isn't really lunch
[19:31] <jdong> no, it isn't :)
[19:31] <jdong> I'll ambush you at a later time
[19:32]  * jdong retriggers the script
[19:33] <directhex> jdong, it's waiting on 3 things: meebey getting home from work, some gentle bumping of changelogs, and a dinstall run in debian which i can sync from
[19:34] <jdong> directhex: ok, awesome; didn't mean to prod you, was just curious
[19:37] <directhex> [18:51] <directhex> meebey, can i schedule some of your time for MD2.0 before the 9th? by all means, focus on smuxi for now, but that's FinalFreeze, and after that the paperwork gets messy
[19:37] <directhex> was already on my TODO ;)
[19:58] <asac> ScottK: could you check whether http://paste.ubuntu.com/143010/ is Kubuntu compatible please? .... hmm libbonobo..?
[19:59] <ScottK> asac: Looking (and thanks for asking).
[20:00] <asac> ok assume libbonobo* is not in there. anything else?
[20:01] <ScottK> OK.  What package is this for?
[20:01] <asac> ScottK: thunderbird
[20:01] <asac> (without -gnome-support)
[20:01] <ScottK> OK.  Looking.
[20:04] <asac> liborbit2?
[20:04] <asac> seems its gnome specific
[20:07] <leonel> ScottK python-clamav for jaunty is done right ?
[20:08] <ScottK> leonel: I haven't reviewed it yet.  It builds is all I can say for it.  If you'd review and provide any needed improvement, that'd be great.
[20:08] <leonel> yesterday got time to work on it and found it was already fixed ..
[20:08] <leonel> I'll test it
[20:08] <ScottK> Great.
[20:09] <ScottK> asac: It does.  I had it installed only for gtk-qt-engine
[20:09] <asac> ScottK: ok. good so without libbonobo and liborbit the list looks kubuntu compatible, right?
[20:10] <ScottK> asac: I think so. libart-2.0-2 I have installed due to klamav, but nothing in Main, so I think it's OK.
[20:11] <asac> ScottK: right libart isnt a dependency of current tbird, so its likely gnome specific too
[20:12] <ScottK> I can't promise there's nothing else, but it seems OK to me.
[22:46] <MTecknology> There's a bug in vim, when you update, it wants to update a file in /etc that a user never changed, but the update process thinks that the user made a change. What makes this happen?
[22:46] <MTecknology> if this is the right place to figure it out
[22:46] <jpds> MTecknology: Do you know which file it wants?
[22:47] <MTecknology> jpds: I want to create a patch for this - but I have no clue where to start
[22:48] <sbeattie> jpds: it's /etc/vim/vimrc.tiny
[22:49] <MTecknology> sbeattie: should I not bother touching the issue?
[22:50] <jpds> MTecknology: You'd have to download the source package, make changes to it, and upload a debdiff to a bug report on Launchpad; https://wiki.ubuntu.com/Bugs/HowToFix - outlines the process.
[22:50] <sbeattie> MTecknology: not at all, I don't know what causes it, either.
[22:50] <jpds> sbeattie: Is there a bug report already?
[22:50] <MTecknology> 354111
[22:51] <MTecknology> bug 354111
[22:52] <jpds> How odd.
[22:52] <MTecknology> jpds: I've been looking at the source of vim-tiny, but I don't know how to package or what would cause that :p
[22:52] <MTecknology> it did happen to me too
[22:53] <jpds> MTecknology: I guessing a changed checksum in the configuration files.
[22:53] <jpds> sbeattie: Does debconf let you view the difference between the file and the proposed one?
[22:54] <sbeattie> jpds: yes, the difference in that is what's in the description.
[22:55] <GuyFromHell> So the wiki says I am to seek a developer after uploading a patch, i assume that would be here? this is in reference to #337394
[22:56] <sbeattie> jpds: I have both files in the vm available (I had it install the maintainer's version), if you'd like me to attach them to the bug report.
[22:57] <james_w> GuyFromHell: I think Mirco is the best person to review that, and he is already assigned to the bug, so he may well review it tomorrow
[22:57] <GuyFromHell> james_w, alright, i'll leave it as is then for now. thanks
[22:58] <MTecknology> jpds: are you working on that issue then?
[22:58] <james_w> GuyFromHell: thanks for working on it
[22:58] <jpds> MTecknology: No, just thinking what could be the problem. :)
[22:59] <MTecknology> jpds: care to think out loud in a query?
[22:59] <jpds> sbeattie: No the diff is enough, thanks.
[23:52] <MTecknology> anyone wanna help me fix a tiny insignificant bug?
[23:55] <MTecknology> I'm mostly trying to fix it for experience, but it has been reported
[23:55] <james_w> which bug?
[23:56] <MTecknology> bug 354111
[23:57] <james_w> ah, it may be small, but I don't think it's trivial to fix
[23:57] <james_w> if you can get an intrepid chroot that causes the problem when upgraded then that will help a lot
[23:58] <MTecknology> james_w: I'm looking at the 7.1.314 and 7.2.079 versions of README_os2.txt file - I know that's the file it's referring to
[23:58] <MTecknology> james_w: wanna help me learn how to do that?
[23:58] <james_w> what's README_os2.txt?
[23:59] <MTecknology> set path=%path%;C:\vim\vim71 ; set path=%path%;D:\editors\vim\vim71
[23:59] <MTecknology> the two lines changed to vim72 in the latest build
[23:59] <MTecknology> there's a few other lines that changed, but that's the jist of it