[12:37] <persia> superm1: Sorry.  The bit about debian/README.Debian-source apparently was recently changed (I was looking at 3.3.7).  The sentence changed from "must contain detailed information how the repackaged source was obtained, and how this can be reproduced, in README.Debian-source or a similar file" to "must contain detailed information how the repackaged source was obtained, and how this can be reproduced in the debian/copyright.".  My apologies, and y
[12:42] <superm1_> ah not a big deal persia.  thanks for double checking on that
[12:42] <superm1_> was there a second half to that statement though, you left it at "My apologies, and"
[12:43] <superm1_> Ah.  debian/copyright does not describe that it was gathered from revu atm, but there is a X-Vcs-Bzr
[12:43] <superm1_> in debian/control
[12:44] <superm1_> i wasn't positive if that would be considered adequate
[12:45] <superm1_> an identical method was used in my previous upload, mythbuntu-default-settings
[12:45] <superm1_> actually the same debian/copyright
[12:47] <persia> superm1: Not according to the Developers Reference 3.3.9, but there's heaps of things in the archive that don't follow that yet (and I've been recommending debian/README.Debian-source until now).  For the older stuff, consider cleanup when you have time.  For new stuff, put it in debian/copyright.
[12:47] <superm1_> will do.
[12:47] <superm1_> persia, this is very good that you're helping to make more apps compliant :)
[12:49] <tristanbob> why is there no #ubuntu-security channel?
[12:49] <tristanbob> I want to ask a question about remote desktop "vino"
[12:49] <superm1_> i'll re-uplaod with a small bit in debian/copyright before i grab another revu from someone
[12:49] <keescook> tristanbob: generally we just talk about it in here.
[12:49] <keescook> what're you wondering?
[12:50] <tristanbob> I believe that vino encrypts the password with DES, but doesn't encrypt the session - is this still true?
[12:52] <tristanbob> keescook: also, vnc authentication is a single 8 character pasword, no username - correct?
[12:55] <keescook> tristanbob: right, I'm pretty sure the session is still not encrypted.
[12:56] <tristanbob> ok - thanks - I am going to blog about it
[12:57] <superm1_> tristanbob, if you would like the session encrypted, look into the -via switch of vncviewer
[12:57] <superm1_> you can tunnel the session through ssh easily with it
[12:58] <tristanbob> superm1: how easy?
[12:58] <tristanbob> I am aware of the technique
[12:58] <tristanbob> but why is it not in the gui?
[12:58] <superm1_> i'm not sure why it's not in the gui
[12:58] <tristanbob> ubuntu is supposed to "just work"
[12:58] <superm1_> i use it daily though
[12:59] <superm1_> like this: vncviewer localhost:0 -via uesr@HOST
[12:59] <superm1_> that will connect to an ssh server on port 22 of the machine host, and forward its :0 session of VNC
[01:07] <superm1_> persia, is this the sort of thing you are referring to for a better idea of debian/copyright: http://revu.tauware.de/revu1-incoming/mythbuntu-live-autostart-0707131850/mythbuntu-live-autostart-0.1/debian/copyright
[01:07] <persia> superm1: That looks good to me.
[01:08] <mohammad> ScottK: hello, thank you for reviewing Zekr. I cannot see why in your opinion the issue of MOZILA_FIVE_HOME is important. could you please give me some clue?
[01:08] <superm1_> alright good.  well if any other MOTUs are up for a revu, i've got one up here now http://revu.tauware.de/details.py?upid=6008
[01:11] <geser> superm1_: wouldn't build-depending on python (instead of python-dev) be enough?
[01:11] <geser> or does it need the python-headers?
[01:12] <superm1_> Well I guess it doesn't need the headers
[01:12] <superm1_> This was my first python app that i hand wrote and packaged, so i wasn't too sure
[01:13] <geser> you could also add a XS-Vcs-Browser field point to codebrowse on LP
[01:14] <TheMuso> Hey folks.
[01:14] <superm1_> geser, okay i'll double check on the python-dev / python debacle and then add that field
[01:16] <geser> another small note: please line-wrap this long line in the manpage
[01:16] <geser> persia: doesn't looking to the vcs location help?
[01:17] <minghua> persia: Good point.  Maybe XS-Ubuntu-Vcs-*?
[01:17] <persia> geser: For alioth or launchpad, yes.  For other sites, not so much.
[01:18] <persia> minghua: Maybe, but my dream would also involve patching apt to only verify I really want to download when it is an Ubuntu VCS, and the transition would take a while...
[01:18] <minghua> So if an Ubuntu users follow those VCS links, he/she will be surprised.
[01:18] <persia> minghua: In some cases (and it's not currently clear which).
[01:19] <minghua> persia: Are you talking about tools like Daniel's "bzr unpack"?  I am not familiar with those.
[01:20] <persia> minghua: Even just apt (try apt-get source for something with VCS links)
[01:21] <minghua> persia: Is that an Ubuntu-only feature?
[01:23] <persia> minghua: Maybe, but I don't see anything in the changelog (then again, there are some irregularities in the changelog)
[01:23] <minghua> persia: Thanks, I'll test.
[01:25] <superm1_> alright i've updated things per geser's recommendations if anyone else would like to take a look: http://revu.tauware.de/details.py?upid=6009
[01:28] <Toadstool> heya everybody
[01:29] <Fujitsu> Yay, beryl and its close relatives are gone!
[01:30] <Fujitsu> Hi Toadstool.
[01:30] <Nafallo> Fujitsu: 
[01:30] <Nafallo> ?
[01:30] <Toadstool> hey Fujitsu!
[01:30] <Toadstool> how is it going?
[01:30] <Fujitsu> beryl* has been removed.
[01:30] <Fujitsu> Not bad, just woke up.
[01:31] <Nafallo> Fujitsu: but the new thing is still there? :-P
[01:31] <Toadstool> Nafallo: replaced by compiz-fusion yeah
[01:31] <Fujitsu> Nafallo: Indeed, but it isn't /quite/ as crashy.
[01:31] <Nafallo> ehrm. not compcomm or something like that?
[01:31] <Fujitsu> ... wow. beryl-core has 132 open bugs.
[01:31] <Fujitsu> Compiz Fusion is the proper name.
[01:32] <Fujitsu> compcomm was only temporary, and lasted in Ubuntu for a whole couple of days, I believe.
[01:32] <Nafallo> I'll just throw that info to /dev/null again. will never understand those projects. worse than soap operas.
[01:32] <Fujitsu> Haha.
[01:33] <Fujitsu> TheMuso: Finally taking the plunge?
[01:34] <TheMuso> Fujitsu: Not exactly. I always keep up with daily CD images.
[01:34] <TheMuso> Just in cas.
[01:34] <TheMuso> case
[01:34] <Nafallo> anyone ever ordered stuff from Dell? :-)
[01:34] <Fujitsu> I bought a laptop from them 18 months ago.
[01:35] <Nafallo> Fujitsu: good. when you checked the status page for your order. was the date it originally said the order should be delivered when it was actually delivered? :-)
[01:35] <Fujitsu> No, it was delivered a couple of days later.
[01:36] <Nafallo> GAAH!
[01:36] <Fujitsu> I think they updated the ETA a couple of days before it was meant to come, though.
[01:36] <Nafallo> I should call them and point out it's important that it will actually land on the 20th :-)
[01:37] <minghua> Nafallo: In my case it was one day earlier, I think.
[01:37] <Nafallo> minghua: that would be much better indeed :-)
[01:38] <Nafallo> minghua: Tribe-3 on the 19th ;-)
[01:38] <minghua> I am in US though, so my case is not comparable with Fujitsu's, I suppose.
[01:39] <Nafallo> minghua: US, AU, SE ;-)
[01:40] <minghua> (unless Dell ships to moon)
[01:40] <Nafallo> minghua: tssss. "choose" ;-)
[01:41] <Fujitsu> Oh, right, meeting.
[01:41] <Nafallo> minghua: I will be moving to London in a month or so... ;-)
[01:42] <Nafallo> Fujitsu: DOIT! :-D
[01:43] <Toadstool> er is the meeting worth staying at work a little longer? the agenda is quite empty
[01:43] <sistpoty> hi folks
[01:43] <Fujitsu> Hi sistpoty.
[01:44] <sistpoty> hi Fujitsu
[01:44] <ajmitch> crap, motu meeting soon, no time for me to go out & get breakfast
[01:44] <ajmitch> there's nothing to discuss, so it should be fast
[01:45] <Toadstool> hopefully
[01:45] <Toadstool> hi ajmitch 
[01:45] <sistpoty> hi ajmitch and Toadstool
[01:45] <Toadstool> hey sistpoty 
[01:48] <zul> hey ajmitch 
[01:49] <ajmitch> hi
[01:53] <minghua> persia: That "apt-get source" using Vcs-* field is Ubuntu specific, bug 115959.
[01:53] <ubotu> Launchpad bug 115959 in apt "apt-get source should check the Vcs-Bzr field" [Medium,Fix released]  https://launchpad.net/bugs/115959
[02:00] <persia> MOTU Meeting in #ubuntu-meeting now.  All are welcome
[02:02] <zul> oh joy he just firgured out how to scream
[02:03] <Fujitsu> zul: Hahaha.
[02:48] <TheMuso> Morning RAOF.
[02:49] <RAOF> Morning TheMuso 
[02:51] <TheMuso> RAOF: Meeting in -meeting if interested.
[02:52] <RAOF> TheMuso: Thanks.  I won't be around for too long, though
[03:17] <minghua> persia: Is it okay for me to wait 4 hours to start drafting minutes?
[03:17] <persia> minghua: I don't have an issue with that.
[03:18] <ScottK> minghua: 10% pay cut if you don't start now.
[03:18] <TheMuso> heh
[03:18] <sistpoty> haha
[03:18] <minghua> persia: Thanks for the instructions.  I'll start later tonight (-0500).
[03:18] <minghua> ScottK: No problem, I'll take the pay cut. :-P
[03:19] <persia> minghua: Great.  Thanks again.
[03:19] <ScottK> See and I save us money too.
[03:21] <Fujitsu> It gets annoying after a while.
[03:21] <TheMuso> Yup.
[03:21] <persia> TheMuso: The trick is to complain before he leaves (but I always forget)
[03:21] <Fujitsu> And it has been quite a while.
[03:21] <RAOF> A while ~= 2 times
[03:21] <Fujitsu> persia: Right, that's the worst part.
[03:23] <ScottK> persia: Am I being to hard on zekr about the setup script thing?
[03:24] <persia> ScottK: I really don't know.  I suspect that it wouldn't work in Debian due to xulrunner-dev vs. firefox-dev, but that's just a guess.  I also think it's ugly, but that's just a personal preference.  It needs review by someone more familiar with Java packaging, in my opinion.
[03:25] <Fujitsu> Do we have anyone familiar with Java packaging?
[03:26] <leonel> we need  sun-java6 u2 ... :)
[03:26] <persia> Fujitsu: Depends on the definition of have.  A very active member of the Debian Java team is often here, and the MOTU Java Growers might contain such people.
[03:27] <ScottK> man-di is familiar with Java packaging.
[03:28] <ScottK> Hi leonel. Did you see clamassassin got backported today.
[03:28] <leonel> yes !
[03:28] <leonel> was great 
[03:29] <ScottK> Now that I'm authorized to approve backports, it should go a lot smoother.
[03:29] <persia> ScottK: Congratulations!
[03:29] <leonel> that's great  ScottK 
[03:29] <Fujitsu> ScottK: That's nice and convenient :)
[03:29] <ScottK> Yes.  
[03:29] <ScottK> Thanks.
[03:29] <Kioshen> ScottK: grats
[03:29] <sistpoty> ScottK: btw.: there seems to be s.th. wrong with current clamav (couldn't dist-upgrade to it successfully)... known issue?
[03:30] <ScottK> Archive Admins still have to buy it, but it's easier.
[03:30] <sistpoty> congrats btw. ;)
[03:30] <ScottK> sistpoty: Using the 22-7?
[03:30] <ScottK> kernel
[03:31] <ScottK> sistpoty: Bug 124141 is fixed in 22-8. That's the only thing I know about.
[03:31] <ubotu> Launchpad bug 124141 in linux-source-2.6.22 "kernel bug when installing clamav-freshclam" [High,Fix released]  https://launchpad.net/bugs/124141
[03:31] <sistpoty> ScottK: not quite sure, but I think so
[03:31] <sistpoty> (during dist-upgrade=
[03:32] <sistpoty> ScottK: nope. kernel didn't throw anything, but dpkg did
[03:32] <Fujitsu> That's not it, then.
[03:32] <sistpoty> (damn, I should keep logs)
[03:32] <ScottK> Hmmm
[03:33] <persia> sistpoty: Doesn't dpkg keep a log by default?
[03:33] <sistpoty> no idea?
[03:34] <minghua> /var/log/dpkg.log
[03:34] <sistpoty> nope, just looked, doesn't show errors of interest
[03:34] <minghua> not very useful for this kind of error, though.
[03:35] <minghua> sistpoty: What is the status of the problematic package (dpkg -l <name>) now?
[03:35] <sistpoty> iirc it was the postinst? of clamav-freshclam bailing out on dist-upgrade
[03:35] <sistpoty> minghua: I purged it, and now I could easily reinstall it
[03:35] <minghua> I see.  Tough to reproduce, then.
[03:35] <persia> sistpoty: Try installing the old version, and then upgrading
[03:36] <minghua> persia: May depend on versions of other packages.
[03:36] <persia> minghua: These things can be forced, and usually don't matter for postinst error tracing
[03:39] <sistpoty> imo this failed: upgrade clamav-freshclam 0.90.3-1ubuntu1 0.90.3-1ubuntu2
[03:39] <minghua> persia: Oh, I meant "the triggering of the bug may depend on the versions of other packages".
[03:39] <persia> minghua: Ah.  Good point.
[03:39] <ScottK> IIRC there was a change in the postinst in there.
[03:40] <minghua> I agree it's worth trying reinstalling the old version and try upgrading again though, if someone wants to hunt it down.
[03:40] <minghua> But I'm not going to bother.
[03:40] <minghua> Unless it's my package, of course.
[03:40] <sistpoty> imo it doesn't matter that much if the upgrade path from feisty -> gutsy is fine
[03:40] <minghua> These problems are just too common in development branch.
[03:40] <ScottK> Yes.
[03:41] <minghua> sistpoty: Agreed.
[03:41] <persia> minghua: Package ownership is an interesting concept, given the nature of MOTU :)
[03:42] <ScottK> paste.ubuntu-nl.org/29879 is the diff
[03:42] <ScottK> http://paste.ubuntu-nl.org/29879
[03:43] <ScottK> Debian did it newal=`which newaliases || true` - Dunno what difference that makes.
[03:45] <sistpoty> ScottK: shouldn't make a real difference imo, given the [ -x $newal ] 
[03:45] <ScottK> When I merged 0.90.3-2ubuntu1 I used the Debian version.  Not sure why you didn't get that.
[03:46] <persia> Doesn't postinst run under -e?  If this gets passed to the subshell, you'll break in the subshell, rather than coming back to postinst and finding the || true
[03:46] <minghua> persia: Sorry, I should have said "my Debian package".
[03:46] <persia> minghua: No worries :)
[03:47] <ScottK> persia: Dunno.  That's why I ask.  shwarma came up with the Ubuntu version of the change.
[03:48] <minghua> ScottK: I think without '|| true', when newaliases is not in $PATH, postinst will fail.
[03:50] <minghua> Yep. for example:
[03:50] <minghua> $ which non-existent; echo $?
[03:50] <minghua> 1
[03:51] <minghua> And all maintainer scripts have "set -e".
[03:51] <sistpoty> minghua: doesn't fail in my dash at least
[03:52] <sistpoty> (i.e.  x=`which non-existent` || true)
[03:52] <persia> sistpoty: Is that under -e?
[03:52] <sistpoty> persia: yes
[03:52] <minghua> sistpoty: I am sorry.  I don't have much context.  What is the debdiff ScottK posted for?
[03:53] <sistpoty> http://paste.ubuntu-nl.org/29879/
[03:53] <sistpoty> clamav-freshclam... only looked at this as well
[03:53] <minghua> sistpoty: With || true, it won't fail.  I am assuming the debdiff is from current Ubuntu package to another one.
[03:55] <sistpoty> I thought it would have been from my previous version to newer one... but it shouldn't fail anyway when retrying the new debdiff (in case the old failed=
[03:55] <ScottK> minghua: That was clamav 0.90.3-1ubuntu1 0.90.3-1ubuntu2
[03:55] <sistpoty> s/new debdiff/new package/
[03:56] <sistpoty> but as I said, I'm not even entirely sure if it was clamav-freshclam which failed or another clamav package
[03:56] <minghua> ScottK: I see.  Then that diff shouldn't cause any problem.  But is there a similar change in postrm?
[03:56] <ScottK> The postinst does 'set -e'
[03:57] <ScottK> postrm does not attempt to remove the alias, so it doesn't come up.
[03:57] <ScottK> minghua: ^^
[03:58] <persia> ScottK: How about prerm?  Shouldn't the alias be cleaned up at some point?
[03:58] <ScottK> Nope.  It just stops the freshclam daemon.
[03:59] <ScottK> persia: Go read the policy on purging.  It just talks about files.
[03:59] <minghua> ScottK: Before I go grabbing the package -- why -1ubuntu1 and -1ubuntu2?  I see -2ubuntu1 already in archive.
[04:00] <persia> ScottK: I know.  The reason for this is that it's really hard to implement dropping users and groups in a safe manner, as they may own files that are not purge targets (tmpfiles, logfiles, etc.)
[04:00] <sistpoty> please, don't put too much energy in this particularly bad report ;)
[04:00] <ScottK> minghua: That's another question I had for sistpoty.
[04:01] <minghua> Okay, then it's a bad report against old packages. :-P
[04:01] <ScottK> sistpoty: Not all the upgrade bugs I saw had kernel errors in them.  I may have duped a real issue to the kernel bug thinking it was all the same.
[04:01] <sistpoty> ScottK: when was it uploaded? I use a german mirror and lag one day
[04:01] <ScottK> sistpoty: July 10.
[04:02] <sistpoty> then I misinterpreted dpkg.log... sorry
[04:02] <minghua> sistpoty: Should use aptitude, then you at least have a readable package version history. :-P
[04:03] <sistpoty> bah... apt is all I need... if only I didn't forget to tee the log :P
[04:04] <sistpoty> ScottK: btw.: current version on my mirror is "clamav-freshclam                  0.90.3-2ubuntu1"... I won't look at dpkg.log again, promised ;)
[04:04] <ScottK> So you were upgrading to 0.90.3-2ubuntu1 when you got the error?
[04:05] <sistpoty> yep
[04:05] <ScottK> let me go check the diff for that one.
[04:05] <sistpoty> from $unknown_version probably a few (4-8) weeks old
[04:06] <sistpoty> or let's rather say I was on gutsy already *g*
[04:07] <ScottK> We may have a winner.  Give me a moment to pastebin the diff.
[04:07] <minghua> sistpoty: Should be from 3-1ubuntu2 according to your dpkg.log.
[04:08] <ScottK> http://paste.ubuntu-nl.org/29880
[04:08] <minghua> (as your last upgrade was from -1ubuntu1 to -1ubuntu2)
[04:08] <ScottK> Debian came up with that one all by themselves.  Any thoughts?
[04:09] <persia> Is it just me, or is $min not actually defined before use?
[04:09] <minghua> persia: It's just a diff, starting from line #107, no less.
[04:10] <persia> minghua: True.  Line 106 might be a definition for $min, but line 107 is a commented out definition for $min, which makes me suspicious.
[04:10] <minghua> Yeah, didn't see the commented-out line, sorry.
[04:11] <sistpoty> shouldn't matter... sh doesn't check for use before definition
[04:12] <minghua> Ahem.
[04:12] <minghua> * Fix newaliases test to not fail when newaliases isn't present (closes: #431990)
[04:12] <persia> ScottK: What's the difference between /usr/bin/freshclam and /usr/bin/freshclam --quiet?
[04:12] <minghua> That's in Debian changelog.  Anybody read the Debian bug?
[04:12] <persia> debian bug 431990
[04:12] <ubotu> Debian bug 431990 in clamav-base "clamav-base: installation fails: Not creating home directory `/var/lib/clamav'." [Serious,Fixed]  http://bugs.debian.org/431990
[04:12] <minghua> It's probably the fix in -1ubuntu2, though.
[04:13] <ScottK> That's correct.
[04:13] <ScottK> persia: Not sure.
[04:13] <ScottK> I looked into this when I did the merge and then did a brain dump.
[04:14] <persia> ScottK: heh.  Try running them locally (I don't have any clam* installed)
[04:14] <sistpoty> hm... any idea when newaliases was added to exim4?
[04:14] <minghua> persia: That --quiet change is not important.  Debian bug 427420.
[04:14] <ubotu> Debian bug 427420 in clamav-freshclam "clamav-freshclam: Recurring warning messages in cron-mode" [Normal,Fixed]  http://bugs.debian.org/427420
[04:15] <persia> minghua: Right.  It's just the only change I see in the diff for -2ubuntu1 (431990 having been fixed differently in -1ubuntu2)
[04:15] <sistpoty> hm... newaliases was added back in '02, so 431990 doesn't look like a candidate
[04:16] <sistpoty> minghua: +1 ;)
[04:16] <persia> sistpoty: You're only the bug reporter: you don't get to set the Importance :)
[04:16] <sistpoty> I guess it might prove more useful to test if a dist-upgrade from feisty to gutsy works, than to look for sistpoty's weird bugs
[04:17] <jorgerosa> hello
[04:17] <sistpoty> hehe persia
[04:17] <persia> Hi jorgerosa
[04:17] <jorgerosa> ----------
[04:17] <jorgerosa> Can anyone compile this for us, please, to .DEB file?
[04:17] <jorgerosa> https://i-team.svn.sourceforge.net/svnroot/i-team/branches/doddiiteam/
[04:17] <jorgerosa> and send back to me, please? We need it for some tests here. Thankyou!
[04:17] <jorgerosa> ----------
[04:17] <persia>    !paste | jorgerosa
[04:17] <ubotu> jorgerosa: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[04:17] <ScottK> Should have clamav 0.91-1 from Debian very soon, so I'll find out.
[04:17] <ScottK> If there's still an upgrade problem.
[04:18] <persia> jorgerosa: You'll probably do best to create a needs-packaging bug in LP.  There's a fair bit of work that needs doing to make that into a debian-format package.
[04:19] <jorgerosa> ok
[04:20] <persia> jorgerosa: Also, to reduce packaging hassle later, it would be ideal if you could include the relevant license for the software in your repository.  ./COPYING is common, as is ./LICENSE
[04:24] <jorgerosa> persia: Im sorry guys, im not a coder (coders r away right now), im only windows pro, sorry there :(
[04:26] <persia> jorgerosa: No problems.  It would be great to get your software into Ubuntu, and it's really nice when software is written to work for both Windows and Linux (even more points for Mac OS X, other BSDs, etc.).  Would you might letting the developers know that a license for the code would be preferred (as otherwise we can't distribute).
[04:27] <sistpoty> ok, /me is off to bed now... dawn is already breaking here
[04:27] <sistpoty> gn8 everyone
[04:27] <jorgerosa> Bye guys
[04:27] <Fujitsu> Night sistpoty.
[04:27] <Fujitsu> Bye jorgerosa.
[04:56] <Fujitsu> Hi Hobbsee.
[04:57] <ScottK> But Fujitsu, why would you possibly want to do that.  I don't understand.
[04:57] <Fujitsu> A 3.5KB CC line is just wrong.
[04:58] <Hobbsee> hey Fujitsu 
[04:58] <Hobbsee> Fujitsu: er...i think you can...
[04:58] <ajmitch> hello Hobbsee 
[04:58] <persia> Fujitsu: How about the mail interface?
[04:58] <Fujitsu> Hobbsee: Well, I mean without compiling a lot of email addresses.
[04:58] <ajmitch> persia: hence the CC line
[04:59] <Fujitsu> persia: Right, that's what I've done. Just confirmed with ubotu that they're all right.
[04:59] <Hobbsee> Fujitsu: ah, right
[05:00] <minghua> Fujitsu: From beryl to compiz-fusion?
[05:01] <Fujitsu> minghua: The beryl-core bugs..
[05:05] <Amaranth> Fujitsu: Don't
[05:06] <Amaranth> Unless there is a way to mass-reject bugs too
[05:07] <Fujitsu> Amaranth: What? I am mass-rejecting them...
[05:07] <Amaranth> oh, i thought you were moving them to compiz
[05:07] <Amaranth> i was going to get all stabby
[05:08] <Fujitsu> Ewww, no.
[05:08] <Fujitsu> I'm not /that/ stupid.
[05:08] <Amaranth> You wouldn't have been the first person to think of it
[05:08] <Fujitsu> Really? Wow.
[05:09] <minghua> I think it's my question that caused confusion, sorry.
[05:09] <Fujitsu> I find Compiz a tad more stable than Beryl.
[05:09] <Amaranth> We're trying :)
[05:09] <Fujitsu> I've been using it with little trouble for three weeks now.
[05:09] <Amaranth> btw, if you don't like gnome-session stalling for 2 minutes edit /usr/bin/compiz and remove --sm-disable
[05:11] <ScottK> Hah.  persia - beat you by 5 seconds.
[05:11] <Fujitsu> ScottK: In what?
[05:12] <ScottK> Replying to the MOTU merge process email.
[05:12] <Fujitsu> Ah.
[05:12] <Amaranth> Fujitsu: are you getting beryl removed from the archive then?
[05:12] <Fujitsu> Amaranth: It vanished about 14 hours ago.
[05:12] <Amaranth> ah
[05:12] <Fujitsu> There are 3 bits remaining, which I filed a removal request for a couple of hours back.
[05:12] <Amaranth> this is probably really mean but...
[05:13] <persia> ScottK: No contest: we're discussing entirely parallel things :)  Anyway, the meeting discussion was only a determination that having a documented merge policy would be a good thing, and that ideas should be discussed for the next meeting.
[05:13] <ScottK> persia: Was joking.  Good to hear.
[05:14] <Fujitsu> Amaranth: Ah, good. I was hoping it wasn't going to be some great rational for keeping it around.
[05:14] <Fujitsu> I was like `Oh, crap... this doesn't look good'
[05:14] <Amaranth> haha
[05:14] <persia> ScottK: Separately, do you think "last merger", "last uploader", and "last person to patch" are three different concepts, or just different facets of the same thing?
[05:15] <ScottK> Facets of the same thing.  Whoever touched it last.  Otherwise it gets too complex.
[05:15] <ScottK> There are exceptions.  I wouldn't count rebuilds.
[05:15] <Fujitsu> Gaaaaah, mail server doesn't like me sending that many.
[05:15] <Amaranth> haha
[05:15] <persia> ScottK: Hmm..  I wonder.  I've sent a few rebuilds in, for which I would have no idea how to process a merge, but which helped with library transitions, etc.  I'm also not sure about spelling corrections, .desktop files, dependency adjustments, etc.
[05:15] <Amaranth> looks like spam
[05:16] <ScottK> persia: Yes, but then there have been cases where I fixed bugs that I wanted to make sure didn't get lost in the next merge.
[05:16] <ScottK> The problem is how do you decide.
[05:16] <minghua> To copy a wiki page, no better way than just create an empty new page, press "edit" of old page, then copy and paste.  Right?
[05:17] <persia> ScottK: Yes.  I've had those (even in one case, where a .desktop file installation (but not the file itself) was dropped in a merge)
[05:17] <ScottK> I also think take backs after someone steals your package are fair.
[05:17] <Fujitsu> ScottK: In that case two wrongs do make a right.
[05:17] <ScottK> Not ownership, but the one that knows it best.
[05:18] <ScottK> The first time you have to merge a package it takes a while to reall grok the merge.  After that it gets easier and the error rate gets lower.
[05:18] <TheMuso> Personally, the only packages I'd rather people not touch unless tey have asked me, are accessibility/speech packages.
[05:18] <TheMuso> they even
[05:19] <ScottK> People doing the same package consistently will give better quality.
[05:19] <persia> Perhaps I need to be more clear.  When a good patch (or very intrusive patch, etc.) is made, the person making that patch is a good person with whom to discuss the implications.  For many fixes, it seems better to just apply the fix.  Merges are a little special, in my book, as there are usually undocumented justifications for the Debian diff.
[05:20] <ScottK> Team maintenance has advantages and disadvantages.  Consistency in doing the merges helps with the disadvantages.
[05:20] <persia> TheMuso: Really?  How about someone correcting some spelling in a translation, etc.
[05:20] <TheMuso> persia: Well thats different, but most of the packages I work with don't carry a lot of that stuff, in Universe at least.
[05:20] <persia> ScottK: Yes!  That's why we need some documentation: it improves consistency.
[05:21] <ScottK> Documenation is great.  I'm not opposed to it.
Documentation is great as long as I am not required to write them.</sarcastic>
[05:22] <ScottK> The person doing the merge being familiar with the package also improves consistency.
[05:22] <ScottK> I even write it sometimes.
[05:22] <ScottK> documentation that is.
[05:22] <persia> TheMuso: Ah.  Depends on the package, I guess.  I've just had a couple contributors ask me because they didn't expect a merge for their two-line patch for something small (the case where it's too hard), but I also don't see any reason that a developer who usually follows a package shouldn't adopt without too much coordination with the author of the two line patch.
[05:23] <persia> ScottK: Yes, although familiarity != last to touch necessarily.
[05:23] <ScottK> That's true.
[05:23] <ScottK> The problem is give me an algorithm that useable for most familiar?
[05:23] <ScottK> Last to touch is excessively simplistic, but executable.
[05:24] <persia> ScottK: Exactly :)  I think that's the discussion AndyP is starting, which would be a good thing (but I need to think more before I have any suggestions).
[05:24] <ScottK> Last to touch plus some comments about take backs when appropriate would get us pretty well there.
[05:24] <ScottK> The real problem is people who don't even bother to ask when there's no reason they can't.
[05:25] <TheMuso> But the biggest problem is the fact that people just go and do the merge.
[05:25] <persia> ScottK: Also, should we follow last-to-touch for only merges, or for any uploads?  If I'm just rebuilding, how should I indicate that I don't want last-to-touch (except perhaps for the 10 days or so after the rebuild)?
[05:25] <TheMuso> ScottK: yep
[05:25] <persia> TheMuso: Yes.  Exactly.  And then we need to fix them :(
[05:25] <TheMuso> Yep.
[05:25] <ScottK> persia: If the changelog has the word build in the Debian revision, it doesn't count.
[05:26] <persia> On the other hand, I've had a few merges done this cycle that were helpful, did the right thing, and happened entirely while I slept, which I found convenient.
[05:26] <TheMuso> ScottK: Aye. I have recently been syncing a lot of doko's rebuilds that were on MoM.
[05:26] <persia> ScottK: How about -38-ubuntu6, where the last 5 were rebuilds?
[05:26] <persia> Fujitsu: I thought I saw a sync request today.  That should clear the last-touched bit :)
[05:26] <Fujitsu> persia: Really?
[05:26] <ScottK> No automated algorithm will be both executable and cover all cases.
[05:27] <TheMuso> persia: I thought rebuilds only were buildx versioning.
[05:27] <persia> ScottK: Yep.  We need to find a best practice.
[05:27] <Fujitsu> That'll never get accepted... There are Ubuntu changes.
[05:27] <Fujitsu> Though it might be best to just start afresh.
[05:27] <persia> TheMuso: Yes, but we don't use -1ubuntu1build1, preferring instead -1ubuntu2.
[05:27] <TheMuso> persia: Oh for ubuntu modified packages, sure.
[05:28] <persia> TheMuso: Which flips the last-touched bit for the rebuilder :)
[05:28] <TheMuso> yup
[05:29] <ScottK> gpocentek: In response to your last e-mail, his work continues to be error prone and he's defensive about it -1.
[05:30] <TheMuso> ScottK: Do you mean andrea?
[05:30] <ScottK> Yes
[05:30] <gpocentek> ScottK: could you reply on the list?
[05:30] <TheMuso> Yeah I've had to prompt about a few things when I've worked with him as well.
[05:30] <ScottK> I will if TheMuso does too.
[05:30] <gpocentek> :)
[05:31] <gpocentek> if you're not confortable with it forget it
[05:31] <TheMuso> ScottK: I've already said enough I think. Other people have raised questions about his work quality.
[05:31] <ScottK> gpocentek: Was kidding.
[05:31] <gpocentek> hehe ok :)
[05:34] <teer2> Hello all - thanks for your continued hard work keeping the packages maintained.  I used Synaptic to install Democracy Player - as always, smooth install, but the version is (in some ways) not compatible with their servers since it is a few revs behind.  I was wondering where the responsibility falls to get updates into Synaptic?  Should I go poke the Democracy Player developers to get something to the Ubuntu MOTU folk, or how does th
[05:34] <ScottK> Sent.  He's also the one that got pissy about stealing merges.
[05:36] <ScottK> gpocentek: How was that?
[05:36] <TheMuso> ScottK: Out of the contributers we are working with, there are one or two who I feel aren't working with the rest of the MOTU team, andrea being one of those.
[05:36] <persia> teer2: You'll do best to open a bug report in LP.  If the gutsy DP isn't compatible with the servers, it'll likely get fixed really soon.  If a released version isn't compatible, we'll need to work out a plan to keep up to date, which might take a while, but a bug is still the best way to start.
[05:37] <teer2> persia: I am running Feisty - if that makes a difference.  Eagerly awaiting the Gusty release!
[05:37] <ScottK> !backports | teer2
[05:37] <ubotu> teer2: If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[05:37] <persia> Personally, I'd like to see those applying to become MOTU demonstrate more work with those still learning, to demonstrate the ability to provide strong solutions.
[05:37] <TheMuso> persia: Thats not a bad idea at all. I like it.
[05:37] <ScottK> Personally, I'm still stunned I got in.
[05:38] <TheMuso> ScottK: You shouldn't be.
[05:38] <teer2> ScottK: Ooooh, I see!  Thanks.
[05:38] <persia> ScottK: Isn't "the released version isn't compatible with the servers" a sufficient bug for -updates?  Perhaps we need a special ubuntu-DP server, or closer coordination with upstream.
[05:38] <ScottK> Shouldn't be stunned or shouldn't have gotten in.
[05:38] <TheMuso> ScottK: Shouldn't be stunned, sorry.
[05:39] <ScottK> persia: Then make a patch with just the changed that makes it compatible with the servers.  That would qualify for updates.
[05:39] <TheMuso> I haven't worked with andrea this period.
[05:39] <persia> ScottK: You spent months helping everyone get python packages in line, did a whole bunch of packages (mostly correctly, and all correctly after a bit), and were very active in the community.  I don't think it was a real question (which is how it should be).
[05:39] <TheMuso> Probably because he got annoyed at my comments.
[05:39] <ScottK> persia and TheMuso thanks.
[05:39] <persia> ScottK: Right.  I don't know enough about it and don't use it, but I'm guessing a bug is the way to get started (at least it would be for a package I know something about)
[05:40] <ScottK> Yes.
[05:40] <ScottK> But this reminds me, I was going to test build the new gnash for backports tonight.  I better get on that.
[05:40] <teer2> fyi, I get this error message when trying to add a DP channel: "To subscribe to this channel, you need Democracy Player.
[05:40] <teer2>  Don't have Democracy Player installed? Download it now..."  That doesn't happen on all the channels, btw.  DP otherwise functions normally.
[05:41] <teer2> Thanks again!
[05:46] <teer2> Hi again, I just checked the dependencies, and the new version of DP requires a new version of libc6, so it probably is not worth the trouble to push the new version on Feisty users!  Thanks again.
[05:48] <ScottK> Fujitsu: I think that's coming.
[05:49] <ScottK> https://launchpad.net/bugs/125788
[05:49] <Fujitsu> ScottK: They're not working to improve the use case where there is no upstream product defined, AFAIK.
[05:49] <ScottK> Ah.  Well that's pretty useless then.
[05:49] <persia> Fujitsu: Does the upstream link code not work for you?  I agree it's a little frustrating to set up for a new package, but I think it works nicely once it's set up (e.g. most of GNOME or KDE).
[05:50] <ScottK> Of course that use case wouldn't help the world domination plan.
[05:50] <Fujitsu> If I'm plowing through hundreds of bugs, I really can't be bothered registering a couple of hundred new products.
[05:51] <persia> Now I'm confused.  Personally, I don't understand it, but I've seen RainCT register upstream bugtrackers for at least 10 packages, so it clearly doesn't either require special permissions, or require secret knowledge
[05:51] <Fujitsu> In Debian, you just tag it forwarded.
[05:51] <Fujitsu> persia: It takes a lot more time than just tagging it.
[05:51] <persia> Fujitsu: Ah.  I see.  Yes, for 1000 bugs, it's annoying.
[05:51] <Fujitsu> We have 6500 bugs over several thousand packages, with maybe a hundred or less of those having projects registered.
[05:52] <persia> Does anyone know if BugSquad has policy meetings, or where, or when?
[05:52] <Fujitsu> I don't think so, persia.
[05:52] <Fujitsu> ScottK: Hah, that'd be nice.
[05:52] <persia> ScottK: It's not worth registering a team.  I'll just ping Mr. QA during the week, and update the wiki.
[05:52] <ScottK> persia: Just ping bdmurray on #ubuntu-bugs.
[05:53] <ScottK> Heh
[05:53] <persia> ScottK: This time I beat you (although only by 1 second) :)
[05:53] <Fujitsu> It'd be nice to have a one-click create-a-basic-project button, and it goes into a queue somewhere to have more useful details added later.
[05:53] <ScottK> Yep, so it's still +4 for me.
[05:53] <persia> Fujitsu: Agreed.  is there a bug open about that?
[05:53] <ubotu> Launchpad bug 125788 in malone "Add link to bugs needing forwarding upstream for a product" [High,Confirmed]  
[05:53] <Fujitsu> persia: I don't think so
[05:54] <Fujitsu> I've brought it up in #launchpad a couple of times, and they just say it won't be a problem once everything is registered.
[05:54] <persia> Fujitsu: There you go then.  Now, as this is a previously addressed problem: please file a bug :)
[05:54] <Hobbsee> persia: bugsquad doesnt have meetings
[05:54] <Fujitsu> Ah, the beryl-core bug page looks lovely :)
[05:55] <Hobbsee> persia: but remember - most of the bugsquad moves to doing packaging anyway
[05:55] <persia> Hobbsee: I thought they used to have them, but I hadn't seen any since bughelper was started, so I wondered....
[05:55] <Hobbsee> persia: not sure...i havent seen any in a *long* time
[05:55] <persia> Hobbsee: Eventually.  For particulaly slow people, that can take years.
[05:56] <Hobbsee> bah.  or just underconfident.
[05:56] <persia> Hobbsee: Depends.  It's often easier to file a good bug, perhaps with a patch or replication code than to actually fix the problem.
[05:57] <persia> minghua: But you still use sid, don't you?
[05:58] <minghua> I've filed a bug against dapper after testing installation a few days after release, got no responses, and was asked if it's reproducible on feisty one year later.
[05:59] <Hobbsee> minghua: that's a general problem with universe bugs, remember?
[05:59] <minghua> persia: Yes, I stopped using Ubuntu as daily system a bit after edgy release.
[05:59] <Hobbsee> minghua: you're not really going to get away from that, unless you get more people involved in triaging
[05:59] <gpocentek> ScottK: thanks for your reply
[05:59] <persia> minghua: That's just bad luck.  Most of my bugs got responses, and were solved within the release cycle.
[05:59] <ScottK> You're welcome.
[06:00] <Hobbsee> ScottK: do you have, and use, an account on alioth?
[06:00] <minghua> Hobbsee: I remember.  I'm not exactly blaming the developers, I know they are busy.  I am just saying such experiences makes me wary of filing bugs against unfamiliar packages.
[06:00] <minghua> I just don't know if there is a developer that looks at the bugs regularly.
[06:00] <Hobbsee> minghua: i hope you're filing those bugs to debian instead, then
[06:00] <ajmitch> minghua: unlikely
[06:01] <ScottK> Hobbsee: I do.
[06:01] <Hobbsee> ScottK: good.
[06:01] <Hobbsee> ScottK: with debian kde extras, i presume, shoving all applicable kde stuff back up there?
[06:02] <minghua> Actually, the same applies to Debian.  If I report bugs to one package and the maintainer doesn't reply, after one or two bugs I stop filing them (if not stop using the package).
[06:02] <ScottK> No, Debian Python Modules Team.
[06:02] <minghua> ajmitch: For some packages there are.  I look at the bugs of my Debian packages regularly.
[06:02] <persia> minghua: One way to check is to look for bug subscribers for the package.  Most of us who care about specific packages have subscribed to the package bugs, which increases the chance we'll see it.
[06:02] <Hobbsee> ScottK: ah.  please do it for kde packages that you see and touch, too.
[06:02] <ScottK> Hobbsee: Up until I started doing the S/MIME stuff, I'd never really done much for KDE.
[06:02] <Hobbsee> fair enough
[06:03] <minghua> Hobbsee: I don't file bugs to Debian before I reproduce them on Debian.  But I agree on your point.
[06:03] <Hobbsee> minghua: right, yeah
[06:03] <ScottK> Do I need to go back and send the S/MIME dependency changes to alioth?
[06:04] <Hobbsee> ScottK: well, if you think taht debian should also ahve the same functionality, that would be useful, yes....
[06:04] <persia> ScottK: Have you been granted write-access to the debian-kde-extras repository?
[06:04] <ScottK> persia: No.  I haven't asked.
[06:04] <Hobbsee> ScottK: you should
[06:04] <ScottK> OK.  Ask > TODO.
[06:04] <persia> ScottK: I'm pretty sure it's easy to get in for kubuntu members
[06:05] <minghua> persia: That's a good point.  But I am subscribed to some packages' bugmail without understanding it really, and don't reply bugmails.  I only monitor them in case I can reproduce the bug on Debian.  So bugmail subscriber is not a sure thing.
[06:05] <ScottK> I should also look into filing patches in BTS for the gnupg stuff too if it's relevant.
[06:06] <persia> minghua: True, but it's at least a hint.
[06:06] <ScottK> I actually had a very pleasant experience as an upstream today with Debian.  The libspf2 maintainer e-mailed and asked for comments on two patches he'd gotten.
[06:11] <ScottK> Good night everyone.  I'm going to bed.
[06:11] <TheMuso> Night ScottK.
[06:11] <Hobbsee> night ScottK 
[06:12] <persia> OK.  I think I'd like to process a sync, but I'm getting an md5sum mismatch on the Debian package.  Any suggestions on this?  Would it be appropriate to repack, or should it be ignored as likely compromised?
[06:14] <Hobbsee> persia: as in, are you asking about the packaging in debina, or it for ubuntu?
[06:14] <Hobbsee> persia: you'll have to fakesync it
[06:15] <Fujitsu> persia: You mean the Debian package won't unpack?
[06:15] <Fujitsu> You sure you're not using the Ubuntu .orig.tar.gz?
[06:15] <minghua> Sounds like different .orig.tar.gz.
[06:15] <persia> Hobbsee: Last update was a sync.  New update would be a sync, but the Debian package fails the md5sum check.  I'm just not sure if Ubuntu particularly cares.  If it's not important, I'll fakesync.  If it's important, I'll bug Debian about fixing it.
[06:16] <persia> Fujitsu: Yes.  New upstream in Debian, orig.tar.gz downloaded with dget from unstable.
[06:16] <minghua> persia: Which package?
[06:16] <persia> minghua: bochs
[06:16] <Hobbsee> persia: is the upstream version distributed as a .tar.bz2?
[06:16] <persia> Hobbsee: Looks like a snapshot
[06:16] <persia> (bochs_2.3+20070705.orig.tar.gz)
[06:17] <Hobbsee> okay, so where does the md5sum mismatch occur?
[06:18] <persia> Hobbsee: md5sum for .orig.tar.gz in dsc doesn't match the output of md5sum locally.
[06:18] <minghua> persia: 2.3+20070705-2 unpacks fine here.
[06:18] <minghua> 9b532803fcab3626a007f2f83a6fc921  bochs_2.3+20070705.orig.tar.gz
[06:18] <StevenK> persia: We knew that.
[06:18] <persia> minghua: Do you get 5f527e3e7ae6cbbb534e9454f1deb705 as the md5sum for the orig.tar.gz?
[06:19] <minghua> That's my download as well as what the .dsc says.
[06:19] <TheMuso> StevenK: lol
[06:19] <minghua> persia: sounds like corrupted download on your side.
[06:20] <persia> minghua: Really?  My dsc says 9b532803fcab3626a007f2f83a6fc921, but the signature is valid, making me think the download isn't corrupt.
[06:20] <Hobbsee> ***anyone who is bored, please fix stuff on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html - StevenK, myself, and any other main people, can sponsor changes ***
[06:20] <minghua> persia: Alas.  I meant "9b532803fcab3626a007f2f83a6fc921" is my download as well as the .dsc says.
[06:21] <persia> minghua: Hrm.  I'll try again.  Perhaps it's just an error on one mirror (I've gotten the same error with multiple downloads).
[06:21] <minghua> persia: so, corrupt .orig.tar.gz download for you.
[06:21] <StevenK> Hobbsee: Can I? :-P
[06:21] <Hobbsee> StevenK: yes.
[06:22] <persia> Hobbsee: I'll fix all those iff you can get someone to regularly regenerate gutsy_universe_probs.html
[06:22] <Hobbsee> persia: hmm...possible, i expect.
[06:22] <StevenK> persia: They tried that. It took like 6 hours
[06:22] <Hobbsee> persia: but debcheck provides a nicer output
[06:22] <persia> StevenK: Once a day (or even twice a week) would be better than never.
[06:22] <Fujitsu> http://alt.qeuni.net/~william/debcheck
[06:23] <Fujitsu> 6 hourly.
[06:24] <minghua> Fujitsu: Is that your page?  Nice.
[06:24] <persia> Hobbsee: OK.  I guess I have some work pending then :)  festival first.
[06:24] <Hobbsee> persia: yeah, well.  we'll see.
[06:25] <TheMuso> Fujitsu: You have festival installed?
[06:25] <persia> Fujitsu: Would you mind advertising that in the ubuntu-motu@ thread about tools?
[06:26] <Fujitsu> TheMuso: I do.
[06:26] <Fujitsu> Not sure why.
[06:26] <Fujitsu> persia: I'll reply to that thread now.
[06:26] <persia> Fujitsu: Thanks.
[06:26] <Fujitsu> It seems to actually be working now.
[06:31] <TheMuso> StevenK: ??
[06:32] <StevenK> sysv-rc is Priority: required, and yet he Depends on the highest version he can.
[06:32] <TheMuso> Ah.
[06:33] <minghua> Hmm, what is the verb for "officialize"?
[06:33] <Hobbsee> to make official?
[06:33] <Fujitsu> I think Hobbsee is correct.
[06:33] <Hobbsee> i cant think of anything else
[06:33] <minghua> I'll use that then,  thanks Hobbsee.
[06:34] <Hobbsee> :)
[06:36] <persia> StevenK: Hey!  I was fixing the festival dependencies.  I'll leave it to you then :(
[06:36] <minghua> I think we stole that from Japanese.
[06:39] <TheMuso> haha
[06:39] <TheMuso> FOund a python package that is arch all, but requires a package only on amd64/i386.
[06:40] <TheMuso> So is uninstallable on powerpc.
[06:41] <Nafallo> is someone packaging powertop?
[06:41] <Nafallo> http://www.linuxpowertop.org/results.php
[06:41] <Nafallo> oh. it's in Debian.
[06:41] <StevenK> persia: libvirt requires some Xen muscles
[06:42] <persia> Erm.  That's fixed too, and most of these use germinate, which bothers me.
[06:42] <persia> StevenK: Right - those are in 2.6.22-8, and -0ubuntu1 is depwait on them now :)
[06:46] <Hobbsee> persia: not sure if riddell's already touching that, or if it's installable as of the upload last night
[06:46] <Hobbsee> not positive on when that was regenerated last
[06:47] <persia> Hobbsee: At first glance, it looks like last night's upload works :(
[06:48] <persia> Hobbsee: My apologies, but I'm not sure there's much left for non core-dev to do.  RCS & LVM is sacred, -meta requires write-access to the seeds (or perhaps just run update), and GNOME gets lots of updates from upstream on a regular basis.
[06:50] <Fujitsu> Nafallo: We've had powertop in Ubuntu for a couple of months.
[06:51] <StevenK> persia: -meta might mean that one of the dependancies isn't installable
[06:51] <Hobbsee> persia: not sure that they were respun
[06:52] <Hobbsee> with the seed changes
[06:52] <Hobbsee> persia: no problem
[06:52] <persia> Hobbsee: That's my thought.  There were lots of changes committed recently, and a new germinate, but -meta hasn't been refreshed.
[06:52] <Hobbsee> persia: because we expected more changes, before the respin :)
[06:53] <persia> Hobbsee: Sure.  I'm not surprised, it's just that I don't think it's worth a debdiff - it's easier for a core-dev to run update and expect it to work (unless anastacia has lost her mind)
[06:53] <ajmitch> persia: what are you doing with libvirt?
[06:53] <Hobbsee> persia: oh yes, of course
[06:54] <persia> ajmitch: Nothing.  Chuck uploaded a fix for the installation failure, and it's just waiting on the Xen fixes, which Ben has been chasing.
[06:54] <ajmitch> ok
[06:54] <ajmitch> it's a package that I initially did
[06:56] <Fujitsu> Has anybody here got mod rights over the MOTU ML? I posted from the wrong address, it seems.
[06:56] <minghua> persia: https://wiki.ubuntu.com/MOTU/Meetings/2007-07-14 is my first draft
[06:56] <ajmitch> though I'd have to hunt down a list password
[06:57] <minghua> persia: It still needs work (finish the other topic section, adding links, spellchecking), but I hope I covered all discussions.
[06:57] <minghua> persia: And I'll be leaving for home soon.  Will work on it when I get home.
[06:57] <ajmitch> Fujitsu: done
[06:58] <Fujitsu> ajmitch: Danke.
[06:58] <minghua> Any other MOTU meeting attendee is also welcomed to check the minute draft.
[06:59] <StevenK> persia: What I was saying about -meta seems to hold true for ubuntu-meta on gutsy_probs. ubuntu-desktop can't be installed on Sparc, since gnome-session can't be.
[06:59] <persia> minghua: 1) AndyP's mail was post-meeting, 2) Next Q&A belongs in Upcoming Events.  3) I think the effort to cover Outstanding merges before UVF got merged into the larger merge discussion (and kicked it off, as I recall), 4) "More efficient HUG Days" needs attribution, and might belong with the HUG day schedule annoucement.  Otherwise, looks great.
[06:59] <StevenK> As well as gnome-power-manager
[07:00] <persia> StevenK: Right.  I just don't have a handy sparc :)
[07:00] <StevenK> I do, but it's a gutless wonder. :-)
[07:00] <TheMuso> Is sparky still up?
[07:00] <persia> StevenK: Can it install things?  It might take a couple days, but Fabio would likely bless you for fixing it :)
[07:01] <Nafallo> Fujitsu: why didn't you say when I showed the link to you? :-9
[07:01] <Nafallo> :-)
[07:01] <persia> TheMuso: Yep, but the keyring hasn't been refreshed in at least 6 weeks.
[07:01] <StevenK> sparky isn't much quicker than my sparc.
[07:01] <Fujitsu> Nafallo: I presumed you would know.
[07:02] <Nafallo> Fujitsu: hehe.
[07:02] <StevenK> Fujitsu: Oh?
[07:02] <Nafallo> Fujitsu: haven't even got a laptop myself. running it on my desktop now :-)
[07:02] <persia> Fujitsu: Why so many?
[07:02] <Nafallo> Wakeups-from-idle per second : 1614,2   interval: 10,0s
[07:02] <Fujitsu> Nafallo: Ouch.
[07:02] <Nafallo> Fujitsu: update-manager ;-)
[07:02] <Fujitsu> I wonder how I'm doing... Compiz is unlikely to be helping.
[07:03] <minghua> persia: 2 is just stupid typo and fixed.  Will fix 1 on next edit.  3 and 4 are in "other topic" section because there were no conclusions.  I deliberately kept discussion and event dates separate.
[07:03] <Amaranth> Fujitsu: compiz doesn't hurt
[07:03] <StevenK> Ugh.
[07:03] <TheMuso> StevenK: You will miss it.
[07:04] <Amaranth> it adds 60 or so if you use intel since it does an interrupt on vblank (your refresh rate)
[07:04] <Fujitsu> Amaranth: Something is causing my i915 interrupt to cause wakeups 200 times a second.
[07:04] <Amaranth> and compiz itself has a timer that adds 4
[07:04] <Fujitsu> I think Compiz might just be it, y'know?
[07:04] <Amaranth> Fujitsu: did you tell compiz your refresh rate was 200?
[07:04] <StevenK> TheMuso: Yeah, but not right now.
[07:04] <Fujitsu> It's down to about 100 now...
[07:04] <Fujitsu> Still rather high.
[07:06] <StevenK> Ah ha.
[07:06] <TheMuso> StevenK: Let me know when you've finished with sparky. I will need some of his CPU cycles soon.
[07:07] <minghua> I am heading home.  See you guys later.
[07:07] <Nafallo> http://www.linuxpowertop.org/known.php
[07:07] <Nafallo> Fujitsu: ^ :-)
[07:07] <Amaranth> something on my system flips out and causes like 80000 wakeups and locks me in C0 unless i disable my second core
[07:07] <Amaranth> happens after a certain amount of time and killing everything (literally, everything) doesn't fix it
[07:08] <Amaranth> and nothing shows up in the list to explain it
[07:08] <Hobbsee> okay, kdelibs hates me
[07:09] <Amaranth> weird, i'm up to 400
[07:09] <StevenK> TheMuso: All done.
[07:09] <TheMuso> StevenK: Thanks.
[07:09] <ScottK> Does Ubuntu care about Optional stuff depending on stuff in Extra?
[07:09] <StevenK> I suspect so.
[07:09] <Fujitsu> ScottK: It doesn't look like it.
[07:09] <StevenK> Hold on, weren't you going to bed?
[07:10] <Fujitsu> There is an enormous amount of stuff broken like that.
[07:10] <Fujitsu> StevenK: I thought so.
[07:10] <Nafallo> "The Pidgin (GAIM) instant messaging client checks every 5 seconds if you have been idle more than 10 minutes"...
[07:10] <StevenK> Nafallo: Kwality
[07:10] <Fujitsu> 617 sources with binaries with broken priorities.
[07:10] <Nafallo> indeed :-)
[07:11] <ScottK> Where would the policy be written?  Packaging guide?
[07:11] <persia> ScottK: I think we inherit from Debian policy on this.
[07:12] <Nafallo> "In addition to this, it will also ask the X server every 5 seconds if the X server supports the X screensaver extension"
[07:12] <Nafallo> LOL
[07:12] <Nafallo> I will NEVER use pidgin :-)
[07:12] <Fujitsu> Nice, nice.
[07:12] <ScottK> Well we're serous broken then I guess.
[07:12] <persia> (http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities)
[07:13] <ScottK> Right.  The question is does Ubuntu care?
[07:13] <Fujitsu> It's even a `must not'.
[07:14] <Nafallo> aha. pidgin is already fixed for those :-)
[07:14] <ScottK> Is there a process for changing priority or is it just file a bug with a debdiff and convince Hobbsee to upload it?
[07:14] <Hobbsee> ScottK: for what, sorry?
[07:15] <Fujitsu> ScottK: It's overrides...
[07:15] <ScottK> Hobbsee: Stuff that is optional depending on stuff that's extra
[07:15] <Hobbsee> i'm not sure...
[07:15] <ScottK> Hmmm
[07:15] <persia> Fujitsu: Is it overrides for all 617, or might some have an incorrect Priority setting?
[07:15] <lifeless> allo allo
[07:15] <Hobbsee> hi lifeless!
[07:16] <TheMuso> Heya lifeless.
[07:16] <Fujitsu> Hi lifeless.
[07:16] <lifeless> hi, hi, hi :)
[07:16] <TheMuso> StevenK: You didn't update the gutsy pbuilder on sparky?
[07:17] <ScottK> I guess I also wonder about debcheck whining about stuff in Main recommending Universe stuff.  Is that a problem?
[07:17] <Fujitsu> ScottK: I don't know of a policy on that.
[07:17] <persia> I thought "Recommends" we acceptable (but neither Depends: nor Build-Depends:).
[07:17] <Hobbsee> ScottK: er...good question
[07:17] <persia> s/we/was/
[07:17] <Fujitsu> It is a good question, though.
[07:17] <Fujitsu> Especially with the automatic installation these days.
[07:17] <Hobbsee> recommends are currently acceptable, as long as it's not a metapackage - but who knows if that will change
[07:17] <ScottK> persia: Me too, but debcheck complains.
[07:18] <Hobbsee> oh bleh
[07:19] <persia> Without Recommends, we'll either have a lot more in main, or Universe will be less obviously useful to users.
[07:19] <lifeless> Hobbsee: water it:)
[07:19] <Fujitsu> It's just there because it was there in Debian.
[07:20] <Hobbsee> lifeless: it's dying, because it's thinking my lp id is sarah, not hobbsee, which is what my ssh key is under.
[07:20] <persia> Fujitsu: Would you?  Ideally, everything there should be a request for an upload, no?
[07:20] <lifeless> erk
[07:20] <lifeless> time to check the code for environment variables :)
[07:20] <ScottK> Fujitsu: Can you somehow remove it for non-meta packages and keep it for metapackages?
[07:20] <Hobbsee> lifeless: yes.  it's tryign a standard bzr checkout, without using teh hobbsee@...
[07:20] <persia> Hobbsee: Always use the same username for everything :)
[07:20] <Hobbsee> lifeless: true.  this worked before, i thought
[07:20] <Fujitsu> ScottK: Possibly. I'll see if I have that info.
[07:20] <lifeless> Hobbsee: oh, easy answer -ssh alias
[07:21] <lifeless> .ssh/config
[07:21] <ScottK> Fujitsu: That would be the thing to do if you can (I think).
[07:21] <Hobbsee> lifeless: Oh?
[07:21] <lifeless> Host bazaar.launchpad.net:
[07:21] <lifeless>     user hobsee
[07:21] <lifeless> oh, no colon, but otherwise right
[07:21] <Hobbsee> ahhh..
[07:21] <lifeless> and spell your nick right too ;)
[07:21] <Hobbsee> yeah
[07:22] <Hobbsee> lifeless: i do vaguely consider just taking ~sarah :P
[07:24] <Hobbsee> lifeless: assuming that works...presumably that wont effect the checkotus that have hobbsee@bazaar...etc?
[07:24] <Fujitsu> Hobbsee: You'll need to rebind those.
[07:25] <Hobbsee> Fujitsu: rebind how?
[07:25] <Fujitsu> bzr bind sftp://sarah@baz...
[07:26] <Hobbsee> lifeless: that's working, thanks.
[07:26] <Hobbsee> Fujitsu: oh, i meant "assuming that the .ssh/config change works, that means i wont need to change the checkouts that have hobbsee@bazaar...."
[07:26] <Fujitsu> Ah, right.
[07:26] <Hobbsee> not the changing to ~sarah
[07:27] <lifeless> sound't need to rebind anytrhing
[07:27] <lifeless> best to not have usernames in the urls anyhow ;)
[07:30] <Amaranth> Fujitsu: 'more'?
[07:30] <Amaranth> you've already gotten angry beryl users?
[07:30] <Fujitsu> I had a couple of emails complaining.
[07:31] <Fujitsu> And one who said their bug was still present in compiz-fusion and moved it over there.
[07:31] <Amaranth> wow
[07:31] <Burgundavia> beryl users angry?
[07:31] <Burgundavia> why so?
[07:31] <Amaranth> why mass-reject anyway? the package is gone
[07:31] <Amaranth> don't the bugs go away?
[07:31] <Burgundavia> why mass reject?
[07:31] <Fujitsu> Amaranth: To kill off about 200 universe bugs?
[07:31] <Fujitsu> No, they stay there.
[07:31] <Amaranth> Burgundavia: because beryl is gone
[07:32] <Burgundavia> but they might be compiz-fusion bugs
[07:32] <Burgundavia> tag them as needinof and close them in two weeks
[07:32] <ScottK> Burgundavia: Where's the convenient LP interface for that?
[07:32] <Burgundavia> ScottK: I wish
[07:33] <Burgundavia> you coudl do it via the email interface
[07:33] <Amaranth> i even gave up on email
[07:33] <ScottK> That's what Fujitsu did and even then it was painful.
[07:33] <Fujitsu> The mail server didn't like 150 recipients :(
[07:33] <Hobbsee> ScottK: laserjock does have a point though
[07:33] <ScottK> Hobbsee: I agree.  There's a balance to be had.  
[07:34] <Fujitsu> Burgundavia: It's most likely that we're going to get those crashes reported again if they're still present in compiz fusion.
[07:34] <Hobbsee> true
[07:34] <ScottK> For me it seems like it's just a polite thing to do.  "Hey, you merged this last time.  Do you mind if I do it?"
[07:34] <Burgundavia> Fujitsu: but what about the feature requests? what about the usability bugs?
[07:34] <Fujitsu> It seems polite because that's how the policy works at the moment.
[07:34] <TheMuso> ScottK: Yeah. Usually the person in questions says go for it.
[07:35] <Burgundavia> I would be seriously pissed if my bugs were closed without anything
[07:35] <ScottK> Hobbsee: You may recall I merged several of your packages for Feisty and you never said no, yet I always asked.
[07:35] <Burgundavia> ScottK: there was a blog post about this, when gaim did it
[07:35] <Burgundavia> it is ok to tag them needsinfo and then close them
[07:35] <Hobbsee> ScottK: true :)
[07:35] <ScottK> That's different though, that was just a name change.  This is a removal.
[07:35] <Fujitsu> You can be fairly sure that all gaim bugs will be in pidging.
[07:36] <Fujitsu> *pidgin
[07:36] <Hobbsee> ScottK: i will only say no if i have some other reason
[07:36] <Burgundavia> ScottK: no, it is not
[07:36] <ScottK> Exactly.
[07:36] <Burgundavia> ScottK: it is pretty much the same source
[07:36] <ScottK> Not beryl.
[07:36] <Burgundavia> beryl was still mostly compiz
[07:37] <Fujitsu> Why did Beryl crash so much more, then
[07:37] <Fujitsu> *?
[07:37] <Hobbsee> it seething with crack
[07:37] <ScottK> Sure, but still bringing a fork back together is very different than a name change.
[07:37] <Hobbsee> er, it was seething wiht crack
[07:38] <Burgundavia> the point of the matter is that it is extremely rude and is likely to turn off some people from further contributions
[07:38] <ScottK> Not saying there aren't bugs in there that are valid still, but mass reject and rereport as needed seems like a good use of scarce time and talent.
[07:38] <ScottK> It all depends on what Fujitsu said in the rejection mail.
[07:38] <Burgundavia> if you are doing a mass reject, is it not as easy to mass reassign and tag as needs info?
[07:39] <Burgundavia> especially given Fujitsu did it via the email interface
[07:39] <Fujitsu> I said that it was replaced by Compiz Fusion, so had been removed from Gutsy. A couple of them have already been responded to by the reported and moved to compiz-fusion.
[07:39] <Amaranth> Burgundavia: speaking of which, you should see if your bugs filed against compiz are still relevant :)
[07:39] <Burgundavia> Amaranth: that I should
[07:39] <ScottK> And then do it again two weeks later after having to go through them all AGAIN to see which can be rejected.  It's the going through them again that eats the time.
[07:39] <Amaranth> i'm pretty sure i set them all the Incomplete and asked for a gutsy update
[07:39] <Burgundavia> ScottK: it is really not that hard, given we are trying to get the best compiz for gutsy
[07:40] <Burgundavia> I can say this, having done it once
[07:40] <ScottK> OK.  Keep in mind I've already been accused of being bitter tonight.
[07:41] <TheMuso> heh
[07:41] <Burgundavia> the key point is that you don't want to piss people off, because you never know when you might be pissing off a potential contributor
[07:43] <ScottK> Sure.  But (as with other things) there is a balance.  There is only so much manpower to do that work and using to much of it to avoid pissing off potential contributors is also counter productive.
[07:43] <Burgundavia> yes, but in this case it is almost the same amount of work
[07:43] <ScottK> Err X 2 is what it looks like from here.
[07:44] <Fujitsu> There's the initial move, then the waiting, then the looking through for replies, then the mass rejection (which would likely collect most of the bugs anyway, due to lack of response).
[07:45] <ajmitch> hello Burgundavia 
[07:46] <Burgundavia> hey ajmitch
[07:46] <Burgundavia> Fujitsu: but the replies are not much, given, as say, most are not going to reply
[07:48] <ScottK> But you still have to go through them.
[07:49] <Hobbsee> darn it.  i've forgottne how to update the metapackages, with the changelog entries
[07:51] <ScottK> Hah.  Beat persia by 15 seconds that time.
[07:52] <ScottK> Did I say that out loud?
[07:53] <Hobbsee> ScottK: just a thought - he may have had to step down for RL reasons, too.
[07:53] <ScottK> Sure.  That actually came out much more harsh than I was thinking.
[07:56] <persia> ScottK: I'd argue that any package that's hard to merge if the original uploader was hit by a bus would be a case of either a poor changelog, lack of comments in the patch, or the lack of README.Debian-source (but then, I'm a convert).
[07:56] <persia> s/either/one of/
[07:58] <ScottK> To an extent that's true, but if you know what to expect, you'll make fewer mistakes.
[07:58] <TheMuso> persia: Good call
[07:58] <persia> ScottK: That's true as well.  It's a matter of "targets of opportunity" vs. "personal responsibility".
[08:00] <ScottK> As a community cultural matter, I think it's polite to ask and polite to say OK, unless there's a good reason why not.  You might even say, "Sure, but watch out for po files in the diff.  Just edit them out."
[08:01] <ScottK> It's kind of like when you go out to eat and one person's food comes late.  It's polite to ask them if they mind if you go ahead and polite for them to say no.
[08:01] <persia> ScottK: True, but if there's an issue like that, doesn't it belong in the changelog or in README.Debian-source?  I'm certainly more knowledgeable about a merge at the time I do it than at the time the next Debian upload happens, and I'd like not to feel I have to check an extra web page daily to see if there are pending changes that have been assigned to me.
[08:02] <ScottK> Well in the case I mentioned (courier) it's only an issue if you're a non-MOTU doing a debdiff, so it doesn't really go in the changelog.
[08:02] <persia> Fujitsu: Which network?
[08:03] <Fujitsu> persia: The mailing list.
[08:04] <persia> ScottK: I must have missed that.  How does it matter?  What's special about courier?
[08:04] <ScottK> There's something with the po files in that package that they show up in the debdiff even though the aren't changed. 
[08:05] <ScottK> If you are merging and uploading it never comes up.
[08:05] <ScottK> I think it may have to do with line lengths, but I'm not sure.
[08:05] <persia> ScottK: They must be changing.  Perhaps they're updated and refeshed by clean: somehow?
[08:06] <ScottK> No, when you look at the text, they are the same, just line wrapped differently.
[08:06] <ScottK> Courier is a seriously unhappy package in many ways.
[08:06] <ScottK> Fujitsu: FYI, http://alt.qeuni.net/~william/debcheck/debcheck.php?list=ALL-light is 404.
[08:06] <minghua> Meeting minute draft: https://wiki.ubuntu.com/MOTU/Meetings/2007-07-14
[08:06] <persia> Anyway, I think that's just a sponsorship detail.  I regularly pull config.sub and config.guess changes from debdiffs when sponsoring, I'm not sure how auto-regerated po files are different.
[08:07] <Fujitsu> ScottK: Oops, I thought I'd migrated everything.
[08:07] <minghua> persia: "other topics" section are much more clear now.
[08:07] <minghua> Please review the minute draft, I'll be sending them in 30 minutes if no changes are required.
[08:07] <Fujitsu> ScottK: Fixed. It's in the template, so I didn't notice it.
[08:08] <ScottK> Fujitsu: Glad to be of service.
[08:08] <persia> minghua: Looks much better.  Thanks.  I still think that the remainder of the "other topics" section should have attribution to the person raising the topic, but that's not always been done in previous minutes.  Thanks a lot for drafting these.
[08:08] <ScottK> Fujitsu: Yep.  Works here now.
[08:10] <minghua> persia: Sometimes it's kind of hard to attribute to a particular person.
[08:10] <persia> minghua: Understood.
[08:11] <Fujitsu> Night, ScottK.
[08:11] <Hobbsee> sleep is overrated
[08:11] <ScottK> Good night.
[08:11] <ScottK> Hobbsee: Sleep is for the weak.
[08:12] <Hobbsee> exactly
[08:17] <minghua> Hmm, so its "meeting minutes" even for only one document.
[08:18] <persia> minghua: Yes.  Each item is considered a "minute", although there's usually poor correlation with typical time measurements.
[08:19] <minghua> persia: I see that you send minutes to -motu and -devel-discuss.  Do you think -devel is better?
[08:19] <minghua> There is probably not much to discuss about the minutes.
[08:19] <persia> minghua: I was just following the example of the two Daniels who had sent minutes for meetings before I started.  There's no intelligence involved in the distribution list.
[08:19] <minghua> And I suspect few people subscribe/regularly read -devel-discuss.
[08:20] <minghua> I'll send to -motu and -devel this time then, unless there is objection.
[08:21] <Hobbsee> persia: ifnot, they can filter
[08:21] <minghua> Speaking of reading list, is there a key-binding in mutt for "mark current mail as read"?
[08:21] <persia> Hobbsee: filter on what?  It otherwise looks like a normal mail from a developer.
[08:21] <Hobbsee> persia: er, delete, sorry
[08:22] <persia> Hobbsee: Perhaps, but isn't it better to notify the right audience than encourage people to delete things?  I thought that was why we all moved from usenet to email 15 years ago.
[08:23] <Hobbsee> persia: i'm unconvinced that there arent people wanting to watch motu stuff
[08:24] <minghua> s/to data/no data/
[08:24] <Hobbsee> particularly with the current pressure on doing some reviewing, from teh disto team, etc
[08:25] <Hobbsee> that being said - i havent seen the minutes yet
[08:25] <minghua> Hobbsee: https://wiki.ubuntu.com/MOTU/Meetings/2007-07-14  # Please do!
[08:25] <persia> Hobbsee: Not really anything about reviewing - it's mostly Fixed Topics, and calls for discussion for the next meeting.
[08:25] <Hobbsee> fair enough
[08:26] <persia> Hobbsee: I would argue that if there was something that was reviewing related, or otherwise of particular interest to a wider audience, someone should volunteer to draft a targeted message on the subject to ubuntu-devel@
[08:26] <Hobbsee> fair enough
[08:27] <minghua> persia: I am convinced, -devel-discuss then.
[08:28] <persia> I feel like a REVU.  Could anyone recommend a package that either 1) is nearly ready for upload, or 2) needs heaps of work (which allows me to autogenerate lots of comments)
[08:29] <Hobbsee> persia: start at the top...
[08:29] <persia> Hobbsee: Yeah, well.  Sometimes there are uploaders here who want reviews.  I like to reward attendance in #ubuntu-motu.
[08:29] <Hobbsee> true :)
[08:30] <Hobbsee> grep the logs
[08:32] <Fujitsu> What was the decision on the need of REVU for MOTU?
[08:33] <minghua> I don't really know.  I assumed since new package in REVU need two advocates, new package by MOTU needs another nod?
[08:34] <persia> Fujitsu: last I heard, the process for new packages by MOTUs was 1) upload to review, 2) wait for ACK, 3) upload to archive.
[08:34] <Fujitsu> I remember a decision was made a while ago.
[08:34] <persia> minghua: Right.  1 advocate should be enough, but the last couple I did had "second" ACK from the original uploader, so the NEW annoucement and actual upload were done by the original packager.
[08:36] <minghua> persia: What's your opinion of putting the text contents of meeting minutes in the mail?
[08:37] <persia> minghua: It hasn't been done since I was MOTU, but it was done in the past.  I don't have a strong opinion either way.
[08:40] <man-di> no leonel anymore
[08:40] <persia> Anyone have an opinion about the libgpod refresh?  It's currently cross-subscribed to U-M-S and U-U-S: I'd be happy to help sponsor (but main should go first).
[08:40] <man-di> anyway, if someone needs sun-java6 6u2, doko should be doing this
[08:41] <man-di> when he gets the DLJ builds from SUN
[08:41] <man-di> which needd several months for 6u1
[08:46] <Fujitsu> Hi TheMuso
[08:46] <persia> Has anyone seen Bixente in the last while?
[08:47] <TheMuso> No.
[08:48] <persia> TheMuso: Thanks.
[08:49] <TheMuso> WHois doesn't help either.
[08:49] <minghua> Meeting minutes sent.
[08:49] <Fujitsu> Thanks minghua
[08:49] <TheMuso> minghua: Thanks.
[08:49] <minghua> I do what I can. :-)
[08:50] <minghua> Thanks to you guys for fixing universe.
[08:51] <Fujitsu> We just watch it break and wait for Debian to fix it.
[08:51] <man-di> Fujitsu: do you had time to look into the multidistrotools issue with packages only pesent in debian?
[08:53] <Fujitsu> man-di: Sure, I'll hunt out the link to pastebin.
[08:55] <Bixente> hi persia :)
[08:56] <persia> Bixente: Hi!  I just archived your grandr-applet upload from REVU, but wanted to make sure that nixternal was correct regarding the code: if your package enhances other things, etc. I'd be happy to unarchive.
[09:00] <minghua> I think I'll join in.
[09:01] <persia> minghua: Great!  The more pre-meeting discussion, the easier it will be to get consensus at the meeting.
[09:01] <Fujitsu> man-di: It seems to be throwing exceptions now when it gets a 404. I have no idea about anything other than basic Ruby.
[09:01] <man-di> Fujitsu: at least you know basic Ruby ;-)
[09:02] <Fujitsu> I only know it from trial and error when hacking up version2html :P
[09:02] <Fujitsu> *versions2html
[09:02] <man-di> Fujitsu: I only know it from its name...
[09:02] <man-di> anyway
[09:02] <man-di> what is the best way to get that fixed?
[09:02] <Fujitsu> Probably catch the exception.
[09:03] <Fujitsu> Or rescue, as I think it might be in ruby.
[09:03] <man-di> is someone an ruby expert here?
[09:03] <Bixente> persia: np, I wanted to ask somebody to archive it.
[09:03] <persia> Bixente: Thanks for the confirmation.
[09:04] <Fujitsu> man-di: For now, it might be easiest to check if pl.b == 'NOTFOUND'
[09:04] <man-di> Fujitsu: can you test this?
[09:04] <Fujitsu> Possibly.
[09:06] <Fujitsu> I think I'll just wrap it in a begin..rescue, and hope that works.
[09:09] <Fujitsu> Bah, I have no idea how to do this.
[09:09] <Fujitsu> You'll have to ask a Ruby god.
[09:09] <Fujitsu> Or just disable the builds section for now.
[09:10] <Fujitsu> ScottK2: To bed with you!
[09:10] <Nightrose> persia: if you are still looking for something to revu: http://revu.tauware.de/details.py?upid=6003 would love to get some comments ;-)
[09:11] <persia> Nightrose: Sure.  Thanks.
[09:14] <man-di> Fujitsu: I disable the buildssection for now. I just would like to have it
[09:14] <man-di> Fujitsu: I will try to find a ruby god
[09:14] <man-di> Fujitsu: Thanks for your help
[09:15] <Fujitsu> man-di: If you get it fixed, please either create a branch and ask me to merge from it, or send a patch.
[09:15] <man-di> Fujitsu: will do
[09:15] <Fujitsu> Thanks.
[09:16] <Fujitsu> What do you use mdt for?
[09:17] <man-di> Fujitsu: making sure all Java packages are in sync or on a good way in Debian and Ubuntu
[09:17] <Fujitsu> Good to see somebody taking care of them.
[09:18] <Bixente> I'm looking for someone to review this package : http://revu.tauware.de/details.py?upid=5931, thanks
[09:20] <man-di> Fujitsu: thx
[09:24] <persia> Nightrose: commented.
[09:24] <gpocentek> Bixente: looking
[09:24] <gpocentek> (if persia is not already on it)
[09:25] <man-di> Fujitsu: the main reason I want this to work is: I requested a sync for eclipse, persia synced, some days later eclipse informed me that eclipse FTBFSed. I would really like to see this easily on my own
[09:25] <persia> gpocentek: Please feel free: I was just starting, but python policy compliance really isn't my forte :
[09:25] <persia> )
[09:25] <Fujitsu> Ah.
[09:25] <Bixente> gpocentek: thanks :)
[09:26] <gpocentek> persia: same for me :/ we'll ask ScottK-confused (ou ScottK2) for a second review ;)
[09:26] <persia> gpocentek: I believe that the reason there are no good nicks is because the owner is asleep :)
[09:26] <gpocentek> s/ou/or/
[09:26] <gpocentek> oh, he sleeps sometimes? incredible
[09:31] <Nightrose> persia: thx a lot - appreciate it
[09:32] <persia> Nightrose: Let me know if you get stuck with CDBS.  The package looks like a great target, with clean rules, but sometimes automation needs a hint :)
[09:32] <Nightrose> persia: will do thx
[09:36] <gpocentek> Bixente: done (commented by persia too)
[09:37] <persia> Bixente: I didn't give it a full review, just stopped after gpocentek started.
[09:38] <Bixente> persia: gpocentek thanks, I look
[10:07] <Fujitsu> Can anybody tell me what generates acinclude.m4?
[10:08] <StevenK> Dark, dark magic.
[10:08] <Fujitsu> Because the qt4 checking in qgis' instance is wrong.
[10:09] <Fujitsu> I'm patching it manually for the moment, but wondering if something else is broken or it needs to be regenerated or similar.
[10:09] <StevenK> What does the auto manual say about acinclude.m4?
[10:09] <Fujitsu> ?
[10:11] <StevenK> Neat. The autobook doesn't know anything about acinclude
[10:11] <Fujitsu> Neat!
[10:13] <Fujitsu> Yay, PHP4 is being EOLed in December!
[10:13] <Fujitsu> So they can't complaing at us for removing it for much longer.
[10:13] <Fujitsu> *complain
[10:14] <Flannel> Yay indeed.  Finally my hosting company will give me php5, and I'll have to stop hacking around OOP deficiencies
[10:14] <Fujitsu> Presumably.
[10:14] <Fujitsu> StevenK: Was it you who had evil PHP4-only code to maintain?
[10:14] <vorlon> generating acinclude.m4 is out of scope for autotools; it's input to autotools, the same way configure.ac is
[10:14] <Fujitsu> vorlon: Ah, so it's constructed by upstream?
[10:15] <vorlon> one assumes so
[10:15] <StevenK> persia: php4 was killed in Feisty
[10:15] <Hobbsee> what happens for php4 in dapper?
[10:15] <Flannel> persia: 2.8.2008 > 2.10.07
[10:15] <Fujitsu> Hobbsee: It's not supported.
[10:15] <Flannel> Hobbsee: We'll still maintain it, just like FF1.5
[10:16] <Hobbsee> Fujitsu: oh, right, good
[10:16] <Hobbsee> Fujitsu: thought it was in main for some reason
[10:16] <Fujitsu>       php4 | 4:4.4.2-1build1 | dapper/universe | source, all
[10:16] <StevenK> I thought Firefox was 2.0 in Dapper now
[10:16] <Flannel> In Dapper? Oh, I suppose it isnt.  Oh, right, apache1 is, php4 isnt
[10:16] <persia> Flannel: Yes, but if it's EOL 2 months in, 18 months of support is hard :(
[10:17] <Fujitsu> We're unfortunately meant to be supporting it in Dapper until 2011, but I can't really see that happening.
[10:17] <Flannel> persia: well, php4 was dropped entirely in feisty, so it's moot.
[10:18] <Flannel> StevenK: why would 2.0 be backported to dapper?
[10:18] <StevenK> Flannel: I thought it was. It seems I remembered wrongly.
[10:18] <Flannel> er, I mean, if it was, it would be in -backports, not in main
[10:18] <Fujitsu> StevenK: Urgh, no.
[10:18] <Fujitsu> You know how bad that would be?
[10:19] <StevenK> Shush, I'm sick.
[10:19] <Fujitsu> Flannel: -backports and main are not comparable.
[10:19] <Flannel> Fujitsu: right, I'm aware.  Which is why it being in -backports is quite different than main, but even if it were to be backported, it would only be in -backports
[10:19] <Fujitsu> It's backports vs. release/updates/security, not backports vs. main.
[10:21] <Flannel> Fujitsu: got references for that?  Since, I obviously misunderstand something
[10:21] <Flannel> Or, just anywhere I'd look for an explanation, instead of badgering you
[10:22] <Fujitsu> release/updates/security/backports are pockets. main/restricted/universe/multiverse are components. Pockets contain components.
[10:23] <Flannel> hmm.  right.  I suppose they do occupy different spots in repository config lines.  I suppose I've never made that connection before
[10:24] <Fujitsu> Pocket is Soyuz-speak. I'm not sure if it's ever used elsewhere.
[10:24] <minghua> I always understood them as two different dimensions before.
[10:26] <persia> Fujitsu: Well, it's used lots of places, but it only carries that meaning in Soyuz.
[10:26] <Fujitsu> persia: Right, that's what I meant.
[10:26] <Fujitsu> And there's also the proposed pocket, which I managed to leave out of that list somehow.
[10:28] <persia> Fujitsu: While you're giving a lesson in Soyuz-speak, what's the correct term for something that contains a set of pockets for a given name (e.g. Dapper)?
[10:28] <Fujitsu> distrorelease is the code name, and generally used by LP people.
[10:29] <persia> So distrorelease > pocket > component, right?
[10:29] <Fujitsu> Right.
[10:29] <Fujitsu> Then section > sourcepackage > sourcepackagerelease
[10:29] <StevenK> Which means a distrorelease is a coat, which contains many pockets?
[10:29] <Fujitsu> StevenK: Definitely.
[10:31] <persia> So, if each coat is given a number, what do we call a collection of coats?  Distribution?  Closet?
[10:31] <StevenK> When is Ubuntu coming out of the closet?
[10:32] <StevenK> persia: :-P
[10:33] <persia> No, but seriously, what is the term for "Ubuntu", "Kubuntu", etc?  Are these just flavors?  If flavors, of what are they a flavor?  What is the term for Dapper, Edgy, Feisty, and Gusty as a combined unit?
[10:34] <Fujitsu> Ah... THey're just flavours, they don't really fit in anywhere.
[10:34] <Fujitsu> persia: I think the combination of distroreleases is just.. Ubuntu.
[10:34] <persia> Fujitsu: OK.  Ignoring the flavours then, what is a collection of distroreleases as part of a common thread called?
[10:34] <Fujitsu> A distro.
[10:35] <persia> OK.  At that point, we get into "Also affects distribution", and so there's no longer enough commonality to need collections.  Thanks.
[10:35] <Fujitsu> It's a little confusing, as Ubuntu is both a flavour and distro.
[10:36] <persia> Fujitsu: That's just namespace collision.  "Ubuntu" the flavour is local, "Ubuntu" the distro is global.  Unless otherwise specified, the flavour applies whenever flavours are being discussed, and never applies in other cases.
[10:36] <Fujitsu> Flavors don't exist at all in LP at the moment, though I believe that's changing.
[10:36] <Fujitsu> Urrrgh, I just used an Americanism.
[10:37] <persia> That would actually be interesting.  I wonder if different flavours would be able to provide different seeds such that the component mix was different, but that's far from on-topic for here :)
[10:37] <Fujitsu> I don't like this evil autoconf stuff.
[10:38] <Fujitsu> I think the seeds will be able to be assigned to a flavour in LP, but I really don't remember.
[10:38] <Fujitsu> Yay, it passes configure.
[10:38] <Fujitsu> Oh, neat, it runs configure twice.
[10:38] <Fujitsu> Thanks Debian.
[10:39] <persia> Fujitsu: More problematic is that builds depend on components, so if different flavours want to change the seeds for components, it gets hopeless at the sourcepackagerelease level.
[10:39] <Fujitsu> persia: Components aren't for flavours to decide.
[10:39] <Fujitsu> That would never work.
[10:40] <persia> Fujitsu: Right.  On the other hand, it makes building CDs from a flavour without promising official support much easier.
[10:40] <Fujitsu> persia: In that case you just have a CD build system that allows universe too.
[10:41] <persia> Fujitsu: No, because of the flavour-specific seeds.  See, it gets hopeless.  Something might happen at some point in the future if another large sponsor wants to pay to share infrastructure and source, but likely not until then.
[10:42] <Fujitsu> Flavours can have differing ship seeds, but not feasibly different supported seeds.
[10:45] <Fujitsu> The Soyuz spec for it is distrorelease-flavours (and its (r)depends), though not much seems to be happening there.
[10:46] <persia> Fujitsu: Hmm...  That doesn't help flavours that need more variance, but then again, not all derivatives should be candidates for flavours.
[10:47] <Fujitsu> persia: How does Canonical-supported status affect unsupported flavours?
[10:49] <persia> Fujitsu: Well, if, as an example, someone wanted to distribute something that used jack as the default sound system (which cannot be in main now due to highly unstable rdepends upstream), and support that, this would need to be done as a derivative, rather than as a flavour (until something changes).  This is true to a lesser extent for anything wishing CDs, due to the CD builds from main restriction (which is less complicated).
[10:50] <Fujitsu> persia: Ah, I wasn't considering the possibility that someone might want to support that.
[10:50] <Fujitsu> I suppose it wouldn't be hard to provide overrides so packages could be dragged into a flavour-specific supported component.
[10:50] <persia> Fujitsu: Right.  It's the possibility of non-official support (or flavour-specific support) that makes it tricky.
[10:50] <Fujitsu> But then that requires a separate archive.
[10:50] <Fujitsu> I hadn't considered that possibility.
[10:50] <persia> Fujitsu: No, that's not hard, but tracking rebuilds becomes hard.
[10:51] <persia> Right.  At that point, derivative makes more sense than flavour.  As a result, flavour-specific seeds are probably limited to ShipSeed and DesktopSeed (or perhaps a couple other specialised seeds)
[10:52] <Fujitsu> supported is the only one that isn't restricted to distribution changes.
[10:52] <Fujitsu> So is the only one that must be shared.
[10:53] <Fujitsu> Yay, qgis builds properly and made this publisher run.
[10:55] <Fujitsu> Oh, nice, I just got a response to one of the beryl bugs asking why I was closing it when the bugs was still present in 6.10. Doubly invalid bugs, what fun.
[10:57] <ajmitch> ah yes, 6.10, which never had beryl in the repository
[10:57] <Fujitsu> ajmitch: Yep.
[11:09] <geser> btw: what's beryl's future in gutsy? will it get removed?
[11:10] <Fujitsu> geser: It was removed almost 24 hours ago.
[11:10] <Fujitsu> Though I missed three source packages in the first batch :(
[11:11] <StevenK> Beryl needs to die, so there.
[11:11] <geser> Fujitsu: I've seen the bug for it but as I didn't remember where it was, I couldn't find it anymore
[11:12] <Fujitsu> StevenK: Because whoever owns it found out Ubuntu was using it?
[11:12] <Fujitsu> Bah, dinner now.
[11:13] <StevenK> Sounds about right, knowing djpig.
[11:13] <Fujitsu> geser: Summary was something like `Please but beryl and co. out of their misery'
[11:13] <Fujitsu> I had to make it a little less boring than the normal, as it /was/ beryl.
[11:14] <geser> I got used to some nice looking emerald themes. Is there a proper replacement for it in gutsy?
[11:14] <Fujitsu> Compiz Fusion is getting something like Emerald soon, I believe.
[11:14] <Fujitsu> Now, I really have to go.
[11:14] <geser> Fujitsu: yes, that one
[11:32] <StevenK> I was curious about the bug number about Beryl
[11:33] <Fujitsu> StevenK: Which? Removal the 1st?
[11:33] <Fujitsu> Bug #124661
[11:33] <ubotu> Launchpad bug 124661 in emerald-themes "Please put beryl and co. out of their misery" [Wishlist,Fix released]  https://launchpad.net/bugs/124661
[11:34] <StevenK> Ahh. emerald-themes. Sneaky
[11:34] <Fujitsu> It has tasks for all of them.
[11:35] <Fujitsu> (except beryl-settings, beryl-settings-bindings, beryl-plugins-unsupported (which I missed), heliodor and emerald (which were already gone)
[11:37] <Fujitsu> I wonder if they could have split it into any more sources.
[11:37] <StevenK> Probably
[11:46] <Fujitsu> minghua: I'm sure you can guess.
[11:56] <Fujitsu> Oh, I do like this graph:
[11:56] <Fujitsu> http://outflux.net/ubuntu/stats/
[11:56] <TheMuso> pfft graphs.
[11:59] <persia> Fujitsu: Nifty.
[12:00] <geser> what happened?
[12:01] <persia> geser: beryl
[12:02] <Fujitsu> For once beryl did something good.
[12:07] <Hobbsee> Fujitsu: oh nice.... :)
[12:10] <ajmitch> Fujitsu: beryl, or the removal of it?
[12:12] <Fujitsu> ajmitch: Well, by being removed.
[12:12] <Fujitsu> I know, I feel terrible for destroying such quality code.
[12:15] <calc> ajmitch: good morning
[12:17] <ajmitch> hey calc 
[12:18] <ajmitch> you need a one with a hand-crank
[12:19] <calc> i need one of those new ubuntu mobile systems
[12:19] <calc> it hasn't been announced yet
[12:20] <calc> hell its really just started but from what i have seen it will be very nice
[12:22] <Fujitsu> I've got about the oldest Nokia phone in existence.
[12:22] <TheMuso> WHat toolkit does openmoko use?
[12:22] <ajmitch> gtl+
[12:22] <Fujitsu> GTK+, AFAIK
[12:22] <ajmitch> s/l/k/
[12:22] <TheMuso> Sweet.
[12:22] <ajmitch> fairly standard stuff
[12:22] <TheMuso> Just what I wanted to hear.
[12:22] <ajmitch> I managed to get the whole image built yesterday
[12:22] <ajmitch> you can test it in qemu
[12:23] <Fujitsu> It's not even ridiculously expensive.
[12:23] <ajmitch> no, I'm getting one as part of a group order
[12:23] <TheMuso> s/hish/his/
[12:25] <porthose> could you refer me to a package that uses cdbs so I can learn by example please
[12:26] <Fujitsu> ajmitch: Are you running it in a vanilla qemu?
[12:27] <ajmitch> Fujitsu: nope
[12:28] <ajmitch> you can download & build the whole set with 1 makefile
[12:28] <ajmitch> which builds a custom qemu as well
[12:28] <ajmitch> it emulates some more phone-specific hardware
[12:28] <persia> porthose: https://wiki.ubuntu.com/MOTU/School/PatchingSources suggests pmount as a good example.
[12:28] <Fujitsu> Right, I'm currently checking that out.
[12:29] <ajmitch> MokoMakefile?
[12:29] <persia> porthose: Also, look at the CDBS Documentation (from duckcorp): there are some example rules files there as well.
[12:30] <Fujitsu> ajmitch: That takes a while.
[12:30] <calc> Fujitsu: i have a nokia 2160 somewhere i think
[12:30] <calc> from ~ 1996
[12:30] <ajmitch> Fujitsu: I know, I built it
[12:30] <calc> it doens't work any more of course since it used tdma
[12:30] <porthose> persia: Looking at duckcorp now thanks for pmount example
[12:39] <Fujitsu> I see it even has stuff like gnome-vfs. Nice.
[12:53] <jekil> if i have this lintian errors, http://rafb.net/p/MaMZZH71.html after include that copyright in debian/copyright i must delete this files?
[12:57] <persia> jekil: Are all those different licenses?  Also, is this a source error or a binary error?
[12:58] <jekil> persia: yes, all different, bsd, gpl.. it's a source
[12:58] <jekil> i am packaging a source that's hell
[12:59] <persia> jekil: OK.  If upstream distributes all those license files, and they are all different, and you're not including them in your binary packages, you'll want to override the lintian error.
[01:00] <jekil> and if i am including it in my binary deb? (the app is in ruby, so there isn't difference)
[01:04] <persia> jekil: There is a difference.  A source package is a .dsc file, a .diff.gz file and an orig.tar.gz file.  A binary package is a .deb file.  You can check the contents of your binaries with dpkg --contents
[01:04] <persia> jekil: Also, is this http://framework.metasploit.com/msf/?
[01:05] <jekil> persia: yeah
[01:05] <jekil> persia: the source tar.gz is hell
[01:06] <persia> jekil: Did you read the license for downloading the source?  I'm not even sure that the software can be modified enough to make a package, and still comply with that license.  Further, it certainly would have to be in multiverse, as we cannot modify it, and it cannot be sold for profit.
[01:07] <man-di> jekil: the lintian error are about your binary package
[01:08] <man-di> jekil: this means you should not include them in the binary package, debian/copyright should have all the needed infos
[01:08] <jekil> persia: i read it, it can be distribuited for non-profit, you think that i must write on ubuntu-legal or whatever?
[01:09] <persia> jekil: There's no ubuntu-legal.  My concern is 1) there are companies that distribute Ubuntu for profit, and 2) that Ubuntu likes to be able to patch software without violating the license.
[01:11] <jekil> persia: ok, so this software cannot be packaged
[01:12] <persia> jekil: If you think it's a good candidate, by all means, send it to REVU.  I'd suggest checking against http://www.debian.org/social_contract to determine if it's OK to package.  As far as I know, the only licensing differences between Ubuntu and Debian are 1) GFDL is considered free, and 2) binary firmware without source is considered acceptable in some cases.
[01:12] <persia> jekil: That's my thought, but I'm not an authority regarding copyright law.
[01:13] <persia> (or tort law, which is more likely to apply in this case)
[01:13] <Q-FUNK> bryce: it seems I got upstream to accept my patch to auto-generate ChangeLog from the git commit log for -amd.
[01:13] <persia> Q-FUNK: Congratulations!  That is a great feature.
[01:14] <Kmos> persia: bug 121800
[01:14] <ubotu> Launchpad bug 121800 in lastfm "Please sync lastfm (1.3.0.62-2) from debian unstable" [Wishlist,Confirmed]  https://launchpad.net/bugs/121800
[01:14] <Kmos> can you do the sync ?
[01:15] <man-di> Kmos: subscribe u-u-s and wait, it will be done
[01:15] <Kmos> man-di: that's done
[01:15] <man-di> Kmos: then wait
[01:15] <persia> Kmos: No.  Only archive-admins can sync.  Did you put it in the U-U-S queue?
[01:15] <Kmos> yep
[01:15] <Kmos> :)
[01:15] <persia> OK.  If nobody else gets it before I look at the queue again, I'll review it.
[01:16] <Kmos> :) thx
[01:16] <persia> Kmos: No problem.  Thanks for following the process :)
[01:16] <Kmos> =)
[01:19] <Kmos> persia: http://revu.tauware.de/details.py?upid=5599
[01:19] <Kmos> bug 120816
[01:19] <ubotu> Launchpad bug 120816 in aegis-virus-scanner "Upgrade aegis-virus-scanner to version 2" [Undecided,Confirmed]  https://launchpad.net/bugs/120816
[01:19] <Kmos> v1.x isn't anymore supported by author
[01:20] <Fujitsu> What's the Debian equivalent of marking a bug as Invalid?
[01:21] <persia> Kmos: That's another one for which you want to subscribe the sponsors.  I've just looked, and it appears today was a slow day for sponsoring: I'll probably get to it soon.
[01:21] <Q-FUNK> persia: yup.  we at least now have a vague idea of what they changed upstream.  until now, upstream didn't provide any ChangeLog at all.
[01:21] <persia> Fujitsu: Won't Fix, or sending a nastygram to -closed.
[01:22] <Kmos> persia: I need you to check the package.. isn't complete. I can't create the gnome desktop file
[01:22] <persia> Q-FUNK: That's annoying.  Where there's a tarball, there should be a ChangeLog
[01:22] <persia> Kmos: Ah.  What problem are you haveing with the .desktop file?
[01:22] <Q-FUNK> persia: there's no tarball.  they only exist in X.org git.
[01:23] <persia> Q-FUNK: That explains it.  That's frustrating for entirely different reasons :)
[01:23] <Q-FUNK> persia: precisely. :)
[01:24] <Kmos> persia: i really don't know what to configure to make it create the desktop file
[01:24] <Kmos> and the rules dh_ command for that
[01:25] <persia> Kmos: I'd recommend enabling dh_install, and using debian/install to put share/aegis-virus-scanner.desktop in usr/share/applications.  You might want to install some of share/icons/* as well.
[01:26] <Q-FUNK> Fujitsu: the wontfix tag.
[01:26] <Q-FUNK> Fujitsu: either that or if the bug simply doesn't make sense, it gets closed.
[01:27] <Kmos> persia: what should i create on debian/install file ?
[01:28] <persia> Kmos: man dh_install
[01:28] <Kmos> ok
[01:28] <Kmos> thx
[01:49] <persia> bryce: Is the Ubuntu version of luit maintained at git://anongit.freedesktop.org/git/xorg/app/luit, or is that upstream debian/ ?
[01:54] <persia> OK.  Different question.  Am I correct that XS-Vcs-* should point to the packaging repository, rather than to the upstream source?
[01:54] <RAOF> That's the only way I've seen it used
[01:55] <Fujitsu> Pointing to the upstream source is wrong.
[01:55] <persia> Fujitsu: Thanks.  There's more to fix than I thought :)
[02:22] <persia> DktrKranz: I'm looking at bug 112313, and it FTBFS for me (see http://paste.ubuntu-nl.org/29898/).  Any ideas?
[02:22] <ubotu> Launchpad bug 112313 in xmms-liveice "xmms-liveice causes a segmentation fault if the playlist is emptied while playing" [Low,In progress]  https://launchpad.net/bugs/112313
[02:23] <persia> DktrKranz: Thanks.
[02:26] <DktrKranz> I understood why, it was a typo introduced by me
[02:26] <DktrKranz> look: if(if title
[02:26] <persia> DktrKranz: Could you stick a diff in a pastebin?  I'll wedge it in.
[02:27] <DktrKranz> no
[02:27] <persia> Ah.  Nevermind.  If it's just 3 character deletion, I don't need a diff :)
[02:27] <DktrKranz> *np
[02:28] <DktrKranz> anyway, I'll try to build it again to see if compiles, but it should
[02:28] <persia> DktrKranz: "if(title && strcmp(title,oldtitle) && lv_conf.title_streaming && lv_conf.header_format){" is what you want, right?
[02:29] <DktrKranz> that's it
[02:29] <persia> great.  Trying another build now.  Thanks for the quick fix.
[02:31] <DktrKranz> thanks to you for pointing that out
[02:32] <persia> DktrKranz: That worked.  Thanks again.
[02:32] <DktrKranz> again, thanks to you :)
[03:26] <DktrKranz> bug 122183 is affecting feisty. gutsy version does not build correctly and user reported it is an issue to be solved. anyone to mentor me on a possible SRU?
[03:26] <ubotu> Launchpad bug 122183 in plr "postgresql-8.1-plr for Feisty missing plr.so and plr.sql" [Undecided,Incomplete]  https://launchpad.net/bugs/122183
[03:29] <DktrKranz> after a brief look, this issue is due to the fact feisty version builds against libpq-dev 8.2
[03:31] <DktrKranz> while plr looks for files in /usr/lib/postgresql/8.1, while it should search in /usr/lib/postgresql/8.2 (or 8.?)
[03:36] <Fujitsu> Hm, what's this new lpia arch, and why are there no buildds for it?
[03:37] <AndyP> low power on intel?
[03:37] <persia> DktrKranz: That sounds like a conf file or rules file change.
[03:37] <TheMuso> Fujitsu: embedded?
[03:37] <Fujitsu> AndyP, TheMuso: Looks like it.
[03:37] <DktrKranz> persia, that's it
[03:37] <persia> Fujitsu: Think Samsung Q1 and similar equipment.
[03:37] <DktrKranz> s/8.1/8.\?/
[03:37] <Fujitsu> It has appeared on LP now.
[03:38] <DktrKranz> I have got a debdiff which fixes the inclusion problem. What's the procedure in these cases?
[03:39] <TheMuso> Night folks.
[03:39] <Fujitsu> Night TheMuso.
[03:39] <persia> DktrKranz: For gutsy, just subscribe U-U-S.  For an SRU, nominate it for a previous release, and attach a (tested) debdiff for the SRU to the bug, and subscribe U-U-S.  It's good to mention it's an SRU in a comment, to make sure that someone accepts the nomination.
[03:40] <DktrKranz> do I need to document it in changelog too?
[03:41] <DktrKranz> e.g: SRU bugfix or some?
[03:41] <persia> DktrKranz: You'll have two separate changelogs.  One for gutsy (just normal), and one for feisty updates (look at other changelogs there for examples).
[03:41] <DktrKranz> gutsy is not affected, only feisty is
[03:42] <persia> DktrKranz: What about "gutsy version does not build correctly"?
[03:42] <DktrKranz> backporting it for feisty does not build
[03:43] <DktrKranz> but gutsy build is successful
[03:44] <persia> DktrKranz: Ah.  My misunderstanding then.  In that case, just prepare an SRU debdiff, and subscribe U-U-S.
[03:44] <Fujitsu> Mark the Ubuntu task as Invalid, and propose it for Feisty.
[03:44] <DktrKranz> ok, I'll look at some changelogs to see if I need to add additional info
[03:45] <DktrKranz> I nominated it for feisty
[03:45] <persia> Fujitsu: Won't that hide it from the queue without approval of the nomination?
[03:45] <Fujitsu> persia: Hm, true. How annoying.
[03:46] <persia> DktrKranz: Follow Fujitsu's advice for now.  We'll have to think about this a bit more to get a good process in place :)
[03:48] <DktrKranz> ok, marking gutsy as invalid and attach a debdiff for feisty-proposed, right?
[03:48] <persia> Right.
[03:48] <DktrKranz> just one second
[03:49] <persia> Fujitsu: You seem well integrated with the LP crowd.  Any ideas on how to make it easier for contributors to recommend SRUs?
[03:53] <Fujitsu> persia: Um, possibly have people regularly check over the list of things to accept/reject, but that's probably not going to work.
[03:53] <persia> Fujitsu: Not unless we define a team, and I think we're short enough on staffing for sponsors already.
[03:54] <Fujitsu> Right. Not sure how best to do it.
[03:54] <Fujitsu> The only way I can see is to leave the task open, but that is hackish.
[03:55] <persia> Fujitsu: Yep.  Perhaps set a guideline that approving an SRU task should be done on request, unless it's obviously crack, and telling people to ask here?
[03:55] <Fujitsu> I think so.
[03:56] <AndyP> http://revu.tauware.de/details.py?upid=6005 should be easy to review now that upstream has removed their debian dir for me
[03:56] <DktrKranz> debdiff attached and U-U-S subscribed
[03:57] <ubotu> Launchpad bug 77442 in compiz "No screen updates when using desktop-effects with vnc" [High,New]  https://launchpad.net/bugs/77442
[03:58] <Fujitsu> Ah.
[03:58] <Fujitsu> vnc was demoted, so I get privileges over all the main tasks. How nice.
[03:59] <persia> Fujitsu: Interesting...  Sounds like a bug to me.
[04:00] <ScottK> AndyP: In addition to reviewing the e-mail responses to your message, you may also want to look at the IRC logs.
[04:00] <Fujitsu> persia: Yep, and it's related to another I filed months ago.
[04:00] <ScottK> Good morning everyone.  I think I got my network sorted now.
[04:00] <persia> Good day ScottK
[04:02] <AndyP> ScottK: i scanned through my irc backlog and picked up on some comments
[04:03] <ScottK> OK.  Just making sure.
[04:03] <AndyP> i didn't expect the level of debate it threw up but it seems like healthy debate to me
[04:03] <persia> AndyP: It is healthy.  Thanks for helping prod it.
[04:05] <persia> ScottK: I think it was new in edgy (maybe even late edgy).  I've never seen real controversy about it previously, aside from people grumbling when either it wasn't done, or the last uploader wasn't available.
[04:05] <AndyP> ScottK: i did too, really, but it's the method of asking i was looking into, and perhaps what to do if the previous uploader is not contactable
[04:05] <ScottK> Right, but it's clear now that we don't even have consensus on asking.
[04:06] <persia> ScottK: Strangely, yes.
[04:06] <Fujitsu> When I started in early Edgy, it was just common etiquette. It wasn't defined anywhere at all; you just knew.
[04:06] <Fujitsu> \/win 9
[04:07] <Fujitsu> Oops
[04:07] <ScottK> One other point is that since I merge the same package over and over, I'm more motivated to work with Debian to reduce that diff.  
[04:07] <persia> Fujitsu: Really?  I never heard anything about it for Dapper.  Perhaps new for Edgy?
[04:07] <ScottK> I guess that's the problem is that common etiquette isn't so common.
[04:07] <persia> ScottK: True, although I find that when someone else merges it badly, I'm even more motivated to work with Debian and upstream.
[04:08] <Fujitsu> My involvement prior to Edgy was in #ubuntu and the Australian Team. Nothing developerish, so I really don't know.
[04:08] <ScottK> As an example, I've gotten clamav down to where there is a one line diff in an init between Ubuntu and Debian.
[04:08] <Hobbsee> dapper was quite different
[04:09] <persia> Fujitsu: I was not involved for Edgy (left just before Dapper release (May-ish), and returned early Feisty (December-ish), so there's a bit of a gap in my memory.
[04:09] <persia> ScottK: for clamav, can't you do something nifty with postint and lsb?
[04:10] <ScottK> It's more a matter of doing the research to make sure the diff would be appropriate for Debian and then sending a patch.
[04:10] <persia> ScottK: Ah.
[04:10] <ScottK> If someone would send $TIME here, I'd get it done right away.
[04:11] <Hobbsee> dapper we had a small team of people, who were very involved, who were all very good, who could all upload, and who had more time.  and one wiki page of everything.   that's not still the case
[04:12] <Fujitsu> Now we have a small team of people who don't have much time, and a small group who don't have much time and can't upload. Lovely.
[04:13] <Hobbsee> it's probably a bit bigger group now
[04:13] <persia> Fujitsu: Both groups are growing.  We've eight or so new MOTUs so far in gutsy, and I keep seeing new names with <100 karma in the UUS queue, so I imagine the other group is growing as well.
[04:14] <Fujitsu> It seems smaller than Edgy/Feisty, but that might just be me.
[04:14] <persia> Fujitsu: It's certainly less noisy here, but it seems about the same in terms of archive churn.
[04:16] <Hobbsee> Fujitsu: a lot of hte really good people are inactive
[04:17] <ScottK> Hobbsee: Good point.
[04:17] <persia> I think rather that a lot of the people very active in edgy and feisty are inactive, as I don't think there is strong correlation between activity and skill (although experience tends to generate skill)
[04:17] <Hobbsee> a lot of the dapper people are now inactive
[04:18] <Hobbsee> i think they got a bit older, and had less time
[04:18] <persia> Hobbsee: It's not just age.  It's also time - it's a lot of work to keep up.
[04:18] <Hobbsee> true
[04:18] <ScottK> Which is one reason process churn is a bad idea unless really needed.
[04:19] <persia> ScottK: I'd actually argue against that.  I think a lot of our processes need work, as they previously relied on the herculean efforts of such legendary figures as The MOTU Trinity, etc.
[04:20] <persia> Dapper was fun, but there weren't 8 million users to worry about.
[04:20] <ScottK> Need work, fine, but churn no.
[04:20] <persia> ScottK: OK.  Agreed.
[04:20] <Hobbsee> persia: remember - core dev doesnt mean no work on MOTU
[04:21] <ScottK> For example this whole ask before you merge thing is process churn IMO.  There was a clear common understanding even if not well documented.
[04:21] <ScottK> No we're going to engage in several rounds of navel gazing to figure out what the right thing to do is.
[04:21] <ScottK> No/Now
[04:21] <persia> Hobbsee: Right, but core-dev usually means either a position with Canonical, a position that allows truly significant time to be spent on Ubuntu, or a Student (but those tend to lose time after a year or two)
[04:22] <Hobbsee> persia: core dev has nothing to do with canonical
[04:22] <persia> ScottK: Yep.  Gutsy is good for that, as we'll want to be in best shape for the next LTS, to make it really shine.
[04:22] <Hobbsee> persia: as in, if you're good enough for core dev, then you're probably on the canonical radar, but that's not a direct link
[04:23] <persia> Hobbsee: Officially, no, but it's tricky to get into core-dev if one can't commit at least 30 hours a week to Ubuntu, and probably more like 50.
[04:23] <Hobbsee> persia: oh, i dont know about that
[04:23] <Hobbsee> persia: that's a personal thing, on hwo much time you have
[04:24] <Hobbsee> ScottK: more to the point - i wouldnt say you needed to spend 30+ hours on ubuntu to be in core
[04:24] <persia> Hobbsee: Perhaps.
[04:24] <ScottK> Of course I'm kind of allergic to process, so who knows.
[04:24] <Hobbsee> heck - how much of the time is spent on irc?
[04:24] <Hobbsee> vs actually uploading things?
[04:25] <persia> Hobbsee: Sure, most of the time is IRC, when the person could be doing other things, but that also depends on the nature of  the other things the person does.
[04:26] <Hobbsee> true
[04:27] <persia> And, if someone can only commit ~20 hours a week to being on IRC, are they really connected enough to work in the Ubuntu culture?
[04:27] <Hobbsee> sure
[04:27] <persia> (ignoring legacy committers for the time being)
[04:27] <Hobbsee> or at least, if not, there's some problem with our procedures
[04:27] <Hobbsee> a person should nto have to read backscroll of irc to see all of the decisions
[04:27] <Hobbsee> we need to use our mailing list more
[04:28] <persia> Hobbsee: OK.  I'd agree with that, but I think it falls under "problem with practices", rather than "not an issue" at the current time.
[04:28] <Hobbsee> granted.
[04:29] <persia> On the other hand, one of the things that was exciting about Ubuntu when it was starting was that it was real-time: IRC and wiki, rather than mailing lists and waiting.  I'm not sure how much of that should be lost in the interest of encouraging people to spend ~10 hours a week and have full upload rights.
[04:31] <ScottK> Work it out on IRC and document it on the ML is not a bad way to work.
[04:31] <Hobbsee> ScottK: true that
[04:31] <persia> ScottK: Exactly.
[04:31] <Hobbsee> full upload rights is a bit of a red herring, i find.  there's just not that much use i have for main stuff
[04:31] <Hobbsee> excluding the seeds, and stuff i'm currently working on
[04:32] <Hobbsee> hehe
[04:33] <persia> Hobbsee: That's just you.  Think about the greater picture.  If I had upload rights to main, and took an engagement that limited me to ~10 hours a week on Ubuntu, I'm not sure that others would appreciate me uploading random things that took my fancy when I was around.
[04:33] <Hobbsee> persia: dunno - because, if you were the "maintainer" per se...then they may not touch it
[04:33] <persia> Right, but I'm against the very concept of "Maintainer".  It seems contrary to the discussion that brought Ubuntu into being.
[04:34] <ScottK> Then pick a more moderate word that means "Person that normally pays attention to this package".
[04:34] <Hobbsee> main's a bit different, as in, because someone has to be staying on top of each package's bugs.
[04:35] <persia> Hobbsee: Sure, someone has to track the bugs, but to date, nobody has complained about my (sponsored) uploads to main based on my random interests.  I believe this to be because whenever I've worked in main, I've been around, and responsive.
[04:36] <persia> ScottK: I think that's a good feature.  We should use it more.
[04:36] <ScottK> Sure, but for LP/malone it's not relevant.
[04:37] <eagles0513875> ScottK: so what ur saying is i can file a but to ask someone to help me debug an issue even though ill be the one doing the debugging
[04:37] <Hobbsee> persia: oh true
[04:37] <ScottK> See, I slept and so my bitterness quotient is revitalized.
[04:37] <ScottK> eagles0513875: You can file a bug and someone may offer to help you with it.  They may just fix it themselves.
[04:38] <Hobbsee> acutally, they might mark it as a support request
[04:38] <Hobbsee> better to just ask in here
[04:38] <persia> Hobbsee: Yep.  Shrugging is probably the right response for now.  Eventually, interested parties will come up with reasonable proposals, and those responsible for guiding the community will suggest how we should proceed.
[04:38] <Hobbsee> or #ubuntu+1
[04:38] <eagles0513875> ScottK: im having a problem which hasnt fixed itself and ive already tried a number of things
[04:38] <Hobbsee> persia: why do i get the distinct feeling that i'm regarded as one of them, as are the rest that have been doing MOTU stuff for a long while, or who are smart?
[04:39] <persia> Hobbsee: Because you have a sufficient sense of responsibility?
[04:39] <Hobbsee> persia: was more thinking of the people who were regarded to know what they were doing
[04:41] <eagles0513875> Hobbsee: u certainly give an impression u know what ur doing
[04:42] <Hobbsee> eagles0513875: which is exactly why i suspect i'm being watched for a response
[04:42] <eagles0513875> no i know ur in the ubuntu+1 room i dont expect u to respond 
[04:42] <persia> Hobbsee: Sorry.  Took me a while to determine how I had been unclear.  I'm saying that your sense of responsibility is the reason you are one of the people who is likely to develop a proposal for how we should do things.
[04:42] <Hobbsee> persia: ah right.
[04:43] <Hobbsee> persia: i wish we'd got something more productive out of our discussions in the smokers bar at UDS, but unfortunately not
[04:43] <Hobbsee> jono destroyed that, with his all new beer greeting, and all the others coming in
[04:43] <persia> Whereas, the people responsible for the community direction tend to be members of the CC
[04:43] <Hobbsee> CC is a very small group, tend nto to have direction for day to day stuff
[04:44] <persia> Hobbsee: That's not really the right venue anyway (although it tends to be my favorite)
[04:44] <Hobbsee> persia: well... :)
[04:44] <eagles0513875> lol
[04:44] <Hobbsee> persia: the rigth people were there, so...
[04:44] <Hobbsee> and hell, they werent moving, if htey could have a smoke, and i wasnt moving, being absolutely exhausted
[04:44] <persia> Hobbsee: Exactly - that's why it tends to be my favorite :)
[04:44] <eagles0513875> Hobbsee: whats a good program to use to play around with source files
[04:45] <Hobbsee> eagles0513875: $texteditorofchoice
[04:45] <persia> Regarding CC, I think that some of the issues (one team vs. maintainers, how do we recruit, etc.) are matters of interest to CC, but only after we've sufficiently thrashed the issues to prepare two or three well documented proposals.
[04:45] <eagles0513875> Hobbsee: ok lol
[04:45] <eagles0513875> ill use kate then
[04:45] <Hobbsee> persia: true.  may even be the tech board - but we *should* be able to fix this ourselves, as we know the problems.
[04:46] <Hobbsee> persia: i believe that jono plans to do a big MOTU drive, so we need our sponsorship processes well described, and we need our people to be up to scratch, and responsible.
[04:46] <Hobbsee> before that point
[04:46] <Hobbsee> and if htey're not responsible, then we either dont let them get upload rights in the first place, or look at removing them.
[04:47] <persia> Hobbsee: Not the tech board.  The problems aren't technical, they're social.  How should developers work together?  We should be able to fix it, but if we reach two or three models, rather than one, someone needs to decide.
[04:47] <Hobbsee> granted.
[04:47] <persia> Right.  The MOTU drive is in late October / early November, right?
[04:47] <AndyP> what's a MOTU drive?
[04:48] <Hobbsee> AndyP: give me more blood!
[04:48] <Hobbsee> AndyP: give me more motu blood!
[04:48] <persia> AndyP: It's like a cattle drive, only using developers and laserpointers :)
[04:48] <eagles0513875> lol
[04:48] <Hobbsee> haha
[04:48] <Hobbsee> ooh, shiny
[04:48] <AndyP> hehe
[04:49] <AndyP> ok now answer my question seriously ;)
[04:49] <Hobbsee> AndyP: but we did.
[04:49] <persia> Hobbsee: Good luck.  I think we sensibly have until next month before we need to really get it all proposed properly, but I may not be gauging things correctly.
[04:49] <Hobbsee> persia: thanks.
[04:49] <Hobbsee> persia: it'd probalby help if i got off irc for a while,b ut i need to stay on until the 19th, at least.
[04:49] <Hobbsee> night Fujitsu 
[04:50] <Fujitsu> Night Hobbsee.
[04:50] <persia> AndyP: More seriously, it's a international effort to recruit new developers to Ubuntu, including Contributors, MOTU, etc.
[04:51] <eagles0513875> thsi si to everyone here whether ur a programer or not i have to say kubuntu x86_64 is the best 64bit os i refuse to use anything else
[04:51] <persia> Hobbsee: Understood.  Note however, that not being on IRC might make the discussions based on any proposal more difficult :)
[04:51] <AndyP> ah i see *puts down the scalpel*
[04:51] <eagles0513875> where would i make a proposal
[04:51] <persia> eagles0513875: What sort of proposal?
[04:51] <Hobbsee> persia: oh, true that
[04:52] <eagles0513875> persia: another version of kubuntu that centers around clustering
[04:52] <eagles0513875> i honestly think canonical would make alot of money off it
[04:52] <Hobbsee> eagles0513875: provide someone to do the work.....
[04:52] <persia> eagles0513875: Most cluster arrangements are better run without X, except for the master station.  You may be interested in some variation of ubuntu-server for the nodes, and Kubuntu for the head.
[04:53] <eagles0513875> persia: what i was thinking was using pxe and do a network boot
[04:53] <eagles0513875> persia: y cant the basic ubuntu server be the ubuntu desktop version
[04:53] <eagles0513875> since u can download all the dev pkgs
[04:53] <persia> eagles0513875: In that case, you might also want to look at some of the work that has been done in Edubuntu to netboot the thin clients.
[04:53] <eagles0513875> ok
[04:54] <persia> eagles0513875: The big reason not to run desktop on a server is that X and friends take up too much RAM, interrupts, and processor time.
[04:54] <eagles0513875> but kubuntu is so light weight when it comes to ram thoguh
[04:54] <Hobbsee> pity
[04:54] <persia> Hobbsee: Just wait two more days :)
[04:55] <persia> eagles0513875: Yes, but not as light as ubuntu-server
[04:55] <Hobbsee> persia: it's time sensitive
[04:55] <persia> Hobbsee: In that case...
[04:55] <eagles0513875> how much lighter is the server version
[04:55] <Hobbsee> persia: as in, it really should have been discussed on friday, but i totally forgota bout it, until after pitti had left london
[04:55] <Hobbsee> eagles0513875: it doesnt run an x server.
[04:55] <AndyP> the server kernel is different to the desktop kernel also
[04:55] <persia> eagles0513875: I don't have a kubuntu installation, but probably about 60MB or so.
[04:55] <Hobbsee> persia: well, at least, irc, to go and drink beer
[04:56] <DarkMageZ> eagles0513875, i'm counting 100MB less ram usage from not using an xserver alone.
[04:56] <eagles0513875> wow
[04:56] <eagles0513875> hummm
[04:56] <persia> DarkMageZ: A lot of that is probably X resources stored by your clients as well.
[04:56] <DarkMageZ> probably. but still relevant to the point.
[04:57] <eagles0513875> how do i move a folder using shell
[04:57] <Hobbsee> eagles0513875: like they told you in #ubuntu+1
[04:57] <eagles0513875> sry
[04:57] <persia> eagles0513875: now you're getting into #ubuntu territory.  or maybe #ubuntu+1
[04:58] <eagles0513875> sry 
[04:58] <eagles0513875> persia: i think though in todays day and age the 60mb wont make a difference or would it
[04:59] <Hobbsee> on a server?  yes.
[04:59] <Hobbsee> old machiens are still used as servers...
[04:59] <DarkMageZ> persia, so i've waited a week for a responce from the debian maintainer. no responce. what should i do?
[04:59] <eagles0513875> older machines though in a cluster environment
[04:59] <persia> eagles0513875: Even for a new machine, it makes a huge difference.  For a cluster, even more so, as you might want to focus on compute power, and only purchase 64MB RAM for each node.
[05:00] <eagles0513875> true
[05:00] <persia> eagles0513875: More importantly, it's completely pointless - the cluster nodes will never need to run an X application, so loading the libraries into RAM just wastes space and CPU power.
[05:00] <eagles0513875> in the server version of the distro does pxe tftp dhcp and all that some come pre installed
[05:01] <Hobbsee> why dont you try it......
[05:01] <persia> Lastly, for clustering or a server, you want to focus on throughput, rather than responsiveness, which means a differently tuned kernel.
[05:01] <eagles0513875> ill download and run as a virtual machine
[05:01] <persia> eagles0513875: Take a look at the dependencies of ubuntu-server.
[05:01] <eagles0513875> ok
[05:02] <persia> DarkMageZ: Debian is slow.  You could ask for other opinions here.  I'm not tempted to introduce dpatch without some feedback, and the guidelines on the wiki say not to change the patch system, but there have been exceptions in the past.
[05:02] <persia> ScottK: heh.
[05:04] <Hobbsee> ScottK: er, have you heard of the predefined responses, and keescook's greasemonkey script?
[05:04] <eagles0513875> i see what u guys mean shaves of 300 or so mb off the download
[05:04] <Hobbsee> persia: ENOTIME, i expect.  which ones?
[05:05] <persia> Hobbsee: I forget.  Tollef uploaded a bunch of them to err.no during the session, but I completely failed to bookmark it.
[05:05] <ScottK> Hobbsee: I have heard of them.  I haven't had time to investigate them.
[05:06] <eagles0513875> i hate the way they limit download speeds during the day here
[05:06] <Hobbsee> persia: i wonder where tehy are, then
[05:07] <eagles0513875> persia: r the commands pretty much the same as in kubuntu 
[05:08] <persia> Hobbsee: My vague memory was that there were a couple different ones for LP, and a good clean one got hacked together, and one for the wiki was in progress when the room was taken over by the next session.  I never heard about anything else.
[05:08] <Hobbsee> persia: this was developer weather report stuff, by any chance?
[05:08] <persia> eagles0513875: 1) unless replying to someone, it's better to ask the channel, 2) that's a support request, and off-topic here, 3) yes.
[05:08] <persia> Hobbsee: No, special greasemonkey session.
[05:09] <Hobbsee> persia: oh right.  i'll poke mithrandir over it, then
[05:09] <Hobbsee> i cant see it is
[05:09] <Hobbsee> er, here
[05:09] <eagles0513875> persia: sry
[05:09] <Hobbsee> parts of norwegian are even starting to make sense, looking at this
[05:10] <eagles0513875> lol
[05:10] <persia> Hobbsee: http://people.ubuntu.com/~cjwatson/uds-sevilla/2007-05-10/ has a list of some of the other people you might also want to check with.
[05:10] <DarkMageZ> persia, how could the introduction of a patch system be a bad thing?
[05:12] <Hobbsee> persia: ah, thanks
[05:12] <Hobbsee> DarkMageZ: just more stuff to merge back
[05:12] <Hobbsee> persia: oh, i remember that day
[05:12] <persia> DarkMageZ: Well, it changes how the package is maintained, which may annoy the maintainer, it makes it more difficult to use grep to determine if a security issue was resolved, which may annoy the security team, it adds changes not required for the fix, which makes the patches on patches.ubuntu.com less useful, and Debian specifically asked us not to do it without checking.
[05:13] <Hobbsee> ohhhh....*now* i remember what we did that morning.
[05:15] <joejaxx> hi2all
[05:16] <persia> joejaxx: Good day.
[05:16] <Hobbsee> hi joejaxx 
[05:16] <joejaxx> :)
[05:18] <persia> Kmos: Have you tested Debian lastfm?  At first glance, it looks OK, but I'm a little worried about the device management changes
[05:22] <persia> OK.  Requeueing.
[05:28] <yamal> an improved sabnzbd upload is awaiting the keen eyes of the reviewers at http://revu.tauware.de/details.py?upid=6012
[05:29] <eagles0513875> Hobbsee: !@#)O*$& now im having that problem with something else too
[05:30] <Hobbsee> ....and this is my problem because?
[05:30] <eagles0513875> its not
[05:30] <eagles0513875> im just venting
[05:31] <persia> yamal: Great work, but it really needs licensing for the template files before it can be advocated
[05:31] <persia> eagles0513875: Again, unless specifically replying to someone, it's best to vent at the channel instead (and this may not be the ideal channel)
[05:32] <eagles0513875> persia: sry
[05:32] <yamal> persia: yup, I figured that... allready send mail to upstream author - no response yet but at least it didn bounce either
[05:33] <persia> yamal: Extra thanks for adding the comment on REVU that it wasn't ready yet - it makes our lives easier (although you shouldn't be surprised at a lack of response)
[05:34] <yamal> just hoping any other problems/mistakes/omissions be identified so i can iron these out in the meantime
[05:36] <persia> yamal: You've at least said you've fixed everything I found.  Maybe someone else can find something, but most people don't like to review when there's no chance of advocation, as they know that there will be another release soon enough anyway.
[05:36] <persia> s/release/revision/
[05:37] <ScottK> But let me second persia's thanks for commenting up front on the license issue.  It makes me very inclined to put you at the top of my list for REVUing once it's fixed.
[05:41] <yamal> ScottK: I'll remind you of that once the time has come :)
[05:42] <ScottK> yamal: No problem.
[05:42] <ScottK> Doing that was considerate of my time investment and I like to reward that.
[05:47] <persia> AndyP: I've added a short comment to 6005 based on a very brief review.  Looks like you'll have to chase upstream again :(  You probably want to make sure you've run all the automated tests you can think of as well.  Sorry for the brevity, but I wanted you to get a response to your request, and am out of time.
[05:56] <LucidFox> Is there a guide for using debhelper with scons?
[05:57] <broonie> Not that I'm aware of; I can't think of anything that I'd put in such a guide TBH.
[05:58] <ScottK> Certainly not right now unless the FTBFS has been fixed...
[05:59] <broonie> ScottK: Packages can avoid that if they want; it's orthogonal to debhelper anyway.
[05:59] <ScottK> Certainly.
[06:02] <broonie> LucidFox: What would you expect to find in such a guide?
[06:09] <LucidFox> broonie> well, how to create a debian/rules file to use with scons
[06:09] <LucidFox> but never mind, I think I figured it out now
[06:10] <broonie> Ah; as far as that goes the SCons interface is very similar to make.
[06:10] <crimsun> whoever backported 9.0.48.0.0ubuntu1~7.04.0 needs to stay on top of gutsy uploads.
[06:10] <crimsun> flashplugin-nonfree 9.0.48.0.0ubuntu1~7.04.0, that is.
[06:11] <crimsun> ubuntu1 is broken; debian/config was not updated.
[06:15] <gnomefreak> crimsun: i pinged him waiting for an answer
[06:16] <ScottK> crimsun: How did it get backported?  There's no feisty-backports bug for it.
[06:16] <crimsun> gnomefreak: I closed 125938; the cause is clear.
[06:17] <crimsun> ScottK: it went into -proposed.
[06:17] <ScottK> Ah.  Sorry.
[06:17] <gnomefreak> crimsun: ok looking at flash in feisty
[06:31] <ScottK> Hobbsee: There is a new clamav (0.91 - no API incompatibilities).  It's not in Debian yet.  I'm wondering if it might be worthwhile to jump Debian now to get it out before Tribe 3 and get more testing (and more upgrade testing as we have some recent postinst changes and got bit by a kernel bug on the last one).  Thoughts Ms. Release Manager?
[06:33] <gnomefreak> crimsun: i have it built im testing atm
[06:33] <ScottK> Any Ruby package fans here?
[06:35] <crimsun> Kmos: please do not assign ALSA bugs to me.  I no longer lead that Launchpad team.  As long as ubuntu-audio is subscribed, that is sufficient.
[06:42] <gnomefreak> crimsun: btw latest uploda of flash to gutsy can not be grabbed with apt-get
[06:43] <geser> ScottK: AFAIK does clamav 0.91 fix a security bug, so it would be good to have it in
[06:52] <gnomefreak> is it dput revu changes or dput changes revu?
[06:52] <geser> the first
[06:52] <gnomefreak> ty
[06:53] <Hobbsee> ScottK: answer a) it's in universe, so i dont care, from RM POV (as in, only main freezes), b)  that sounds sane, because people will dist-upgrade around the tribes
[06:53] <gnomefreak> crimsun: if you want flash its fixed and uploaded to revu i can give you link once i see it there
[06:53] <Hobbsee> oh, and c) i'm not the release manager...yet
[06:54] <Hobbsee> ScottK: erm, c) s/yet/possibly yet/
[06:59] <SourceContact> any motus interested in attending a development meeting for TimeVault at #ubuntutimevault?
[06:59] <Kmos> crimsun: ok, sorry..
[07:01] <gnomefreak> hmmmmm revu is either slow or broken
[07:02] <joejaxx> SourceContact: timevault?
[07:03] <SourceContact> yep: https://wiki.ubuntu.com/TimeVaultScreenShots
[07:03] <SourceContact> and https://launchpad.net/timevault/
[07:05] <leonel> ScottK: I've responded  thinking I was answering your email and  not  the  launchpad  mail :P
[07:11] <gnomefreak> any revu admins around? revu seems to not be working
[07:14] <Kmos> Categories=GNOME;Application;Utility;X-Red-Hat-Base;
[07:14] <Kmos> this on .desktop aren't wrong for ubuntu
[07:14] <Kmos> right?
[07:20] <ScottK> leonel: No problem.  Isn't Feisty squirrelmail patched to be the same as Gusty?
[07:21] <gnomefreak> feisty-proposed packages can be uploaded to revu right?
[07:25] <leonel> ScottK: they have the security patches applied but   Feisty has 1.4.9a  and  gutsy is  1.4.10a   and there are more than 20 bugfixes 
[07:26] <ScottK> Ah, so Gutsy == Feisty for security, but their are other bugfixes in Gutsy?
[07:26] <ScottK> leonel: Are there any new features in 1.4.10a?
[07:27] <leonel> ScottK: bugfixes only  let me check  right
[07:28] <ScottK> leonel: Backports is for new features, not bugfixes, so it'd helpful to your cause if you answered, yes, there is a new feature.
[07:38] <leonel> ScottK: I'm checking that
[07:38] <ScottK> OK.
[07:40] <leonel> ScottK:  no new features  bugfixes 
[07:40] <ScottK> OK.  Thanks.  Let me think about that one then.
[07:50] <softman> hi
[08:01] <ivoks> how about adding this to ubuntu:
[08:01] <ivoks> https://forge.vodafonebetavine.net/projects/vodafonemobilec/
[08:01] <ivoks> vodafone's tool for 3G cards - GPL
[08:05] <ScottK> Go for it.
[08:05] <ivoks> this would be easy bite for some newcomers
[08:05] <ivoks> it already has structured debian/ dir
[08:09] <Kmos> that will be nice =)
[08:09] <gnomefreak> since when cant you do a debdiff on the source dirs.? 
[08:11] <Kmos> wine 0.9.41-0ubuntu1 at gutsy now =)
[08:12] <aquo> hi
[08:13] <softman> hi aquo
[08:23] <gnomefreak> what do i do after uploading debdiff to get it into feisty-proposed?
[08:24] <ScottK> gnomefreak: Subscribe UUS and a MOTU will upload it.
[08:25] <gnomefreak> ScottK: ty revu seemed not to update after uploading it 
[08:26] <gnomefreak> UUS is ubuntu-universe-sponsers?
[08:26] <ScottK> Yes
[08:30] <gnomefreak> ScottK: done ty again 
[08:36] <ScottK> Unfortunately I don't have time to look at it right now.  I'm up to my ears in a libqt4-ruby SRU.
[08:49] <ScottK> leonel: Why don't you go ahead and add Feisty for squirrelmail.
[08:49] <gnomefreak> ScottK: thats fine i didnt mean for you personally to look at it ;)
[08:49] <ScottK> gnomefreak: No problem.  I was mostly trying to be clear I wasn't in case someone else could do it.
[08:50] <gnomefreak> ScottK: :)
[09:03] <joejaxx> anyone here use a amd64 to build i386 and x64?
[09:14] <ScottK> joejaxx: I think nixternal does something like that sometime.
[09:14] <joejaxx> oh ok
[09:48] <geser> joejaxx: you are running the stats about uploads, aren't you?
[09:50] <joejaxx> geser: sort of i broke the cron that was running for it
[09:50] <joejaxx> i need to fix that
[09:50] <joejaxx> hold on 
[09:51] <geser> could you add a number how many distinct people did uploading?
[09:51] <joejaxx> sure
[09:51] <geser> thanks
[09:51] <joejaxx> you are most welcome
[09:51] <joejaxx> i will have to do that in 1.5 hours though i have to drive home
[09:51] <Kmos> where are these stats?
[09:52] <joejaxx> Kmos: ubuntu.joejaxx.org
[09:52] <joejaxx> bbl
[09:52] <Kmos> geser: https://wiki.ubuntu.com/MarcoRodrigues
[10:04] <RickH> Hello... anyone interested in helping me beginning GTK+ development?
[10:10] <RickH> I have questions moving to GTK+ from a Windows developer background.
[10:11] <geser> doesn't have gtk+ own channels?
[10:13] <geser> RickH: http://live.gnome.org/GnomeIrcChannels
[10:13] <Flannel> On irc.gnome.org
[10:13] <RickH> GTK+ is GNome?
[10:13] <geser> for gtk+ that would be #gtk+ on irc.gnome.org
[10:14] <RickH> Okay, thanks.
[10:34] <leonel> ScottK: Done  squirrelmail 1.4.10a   builded and tested  in feisty 
[10:39] <ScottK> OK.  THanks.
[10:41] <leonel> no, thank you 
[10:46] <ScottK> leonel: Please add the debian/changelog entries since dapper to the squirrelmail bug.
[10:47] <ScottK> leonel: In the bug description.  Also which versions are current in Dapper, Edgy, and Feisty and the version # to be backported from Gutsy.
[10:48] <leonel> Ok   I'm  going  out right now   is it urgent ?
[10:49] <leonel> ScottK: I'll do  as soon I come back 
[10:50] <ScottK> OK.
[10:50] <ScottK> Do it when you get back.
[10:50] <leonel> ok thanks
[11:22] <Megaqwerty> Is there an easy way to get dependencies of source packages? I've tried using the script from debian's website, bit it misses a few that dpkg-depcheck finds. However, dpkg-depcheck doesn't print required version numbers...
[11:25] <Flannel> Megaqwerty: apt-get build-dep
[11:25] <Megaqwerty> Flannel: sorry, I meant .tar.gz files that don't have .debs yet
[11:26] <Megaqwerty> or .bz2, you get the idea.
[11:32] <man-di> Megaqwerty: build with pbuilder and look what fails
[11:33] <man-di> Megaqwerty: thats the only thing that is reliable
[11:33] <Megaqwerty> man-di: Alright, thanks.
[11:33] <man-di> Megaqwerty: note that sometimes stuff is optional, you need to read the build log to get aware of missing optional stuff