[12:41] <Kopfgeldjaeger> n8
[01:10] <pkern> So should we actually suggest users with ATI graphics to upgrade to Gutsy?
[01:15] <persia> pkern: Not yet :)
[01:16] <imbrandon> ok i'm off to dinner, if pochu comes back arround the upload is done
[01:16] <pkern> persia: Not even after the release I am afraid, at least not on laptops.
[01:22] <Joe_CoT> persia: got the updated changelog deb diff for LP #149050. Would you be able to sponsor it? Should i subscribe to sponsors instead?
[01:22] <ubotu> Launchpad bug 149050 in deluge-torrent "Deluge torrent client: Cannot set file priority, as it continually claims that Full Allocation is not set" [Undecided,In progress]  https://launchpad.net/bugs/149050
[01:24] <persia> Joe_CoT: You'll always want to subscribe to sponsors when you have something ready, rather than looking for individuals.  I'm not sure I'll be sponsoring anything else for gutsy, but if I do, and nobody else has already uploaded it, I may.
[01:24] <Joe_CoT> persia: ok, thanks, i'll subscribe it
[01:33] <superm1> pkern, why not?
[01:34] <pkern> superm1: Decide: Which one do you like most: suspend or 3d acceleration?
[01:35] <superm1> pkern, ah :)  wasn't sure if suspending was the thing to accuse this time around :)
[01:35] <superm1> i'm on the beta team and suspending has been broken for some time for me, so i've just learned to not suspend, wasn't sure if it was still broke :)
[01:36] <pkern> I'm used to suspend ever since I used an iBook.
[01:50] <bluefoxicy> is vmware-server not coming for gutsy?
[01:51] <bluefoxicy> vmware-player and virtualbox lack kernel modules ...
[01:51] <pkern> There was a recent article on planet.u.c about the vbox modules.
[01:52] <bluefoxicy> u.c?
[01:52] <pkern> ubuntu.com
[01:53] <bluefoxicy> oh
[02:00] <pkern> ScottK: python-debian supports Version objects (and changelog objects) so that would be a no-brainer. ;)
[02:01] <pkern> ScottK: But maybe we should talk with pitti *first* to confirm if the format still holds.
[03:33] <LaserJock> so did I miss something? why have I got ~350 updates today?
[03:34] <imbrandon> slow mail server ?
[03:34] <LaserJock> imbrandon?
[03:34] <imbrandon> no idea, was a wild guess
[03:35] <LaserJock> it just seemed odd for an RC freeze
[03:35] <imbrandon> i only made one upload and it was a approved , sponsored upload
[03:35] <imbrandon> heh
[03:36] <LaserJock> I've gotta upload edubuntu-docs tonight
[03:36] <imbrandon> ;)
[03:38] <crimsun> pfft.  It's no fun if there aren't hourly multi-hundred MiB updates!
[03:39] <imbrandon> crimsun: hehe yea
[03:39] <LaserJock> crimsun: hello
[03:40] <crimsun> hi
[03:44] <LaserJock> crimsun: how's Washington?
[03:45] <crimsun> it's capitol-y.
[03:50] <imbrandon> nice word :)
[03:53] <LaserJock> I spent a week staying out by Arlington for an American Chemical Society meeting
[03:53] <LaserJock> it was fairly nice
[04:53] <bddebian> whoa, crimsun!
[04:53] <crimsun> (where?!)
[04:54] <bddebian> ^--- there :-)
[04:55] <bddebian> OK I'm working with the Debian games team now and I'm still not convinced that svn doesn't SUCK for package management :-)
[04:56] <imbrandon> s/svr/RCS/g
[04:57] <imbrandon> svn* damn
[04:57] <bddebian> I knew what you meant :-)
[04:57] <imbrandon> hehe
[04:57] <tonyyarusso> rcs?
[04:58] <imbrandon> revision control systems, svn,cvs,bzr
[04:58] <tonyyarusso> ah
[04:59] <imbrandon> great for code, sucks for package management, imho, package mnagement seems to be much more a "one man job"
[04:59] <bddebian> Heh, go for it
[04:59] <bddebian> Fujitsu: Just mark them all won't fix after Gutsy releases ;-P
[05:00] <bddebian> We'll just start fresh after every release from now on..
[05:03] <Hobbsee> imbrandon: get to it : )
[05:03] <Hobbsee> Fujitsu: sounds good.
[05:03] <imbrandon> heya Hobbsee
[05:03] <Hobbsee> hiya!
[05:04] <bddebian> Hi Hobbsee
[05:04] <Hobbsee> hi bddebian
[05:07] <white> anyone wants (or is) subscribed to
[05:07] <white> secure-testing-commits@lists.alioth.debian.org
[05:07] <white> or at least checking
[05:07] <white> secure-testing-announce@lists.alioth.debian.org
[05:07] <Fujitsu> white: Aha, I'll subscribe.
[05:07] <bddebian> More spam.. :)
[05:08] <white> Fujitsu: is the universe security team active?
[05:08] <white> it would be nice to get cooperation done :)
[05:08] <bddebian> Is there a universe security team?
[05:09] <white> i could do some randon checking now :)
[05:09] <white> !info util-linux gutsy
[05:09] <ubotu> util-linux: Miscellaneous system utilities. In component main, is required. Version 2.13-8ubuntu1 (gutsy), package size 426 kB, installed size 1364 kB
[05:09] <tonyyarusso> bddebian: motu-swat, iirc
[05:11] <white> or easier, someone could check, if the security fixes from http://security-tracker.debian.net/tracker/status/dtsa-candidates are included in gutsy
[05:12] <Amaranth> white: You probably want to talk to pitti or keescook
[05:13] <white> Amaranth: apparently they are doing main
[05:13] <white> Amaranth: i was offering something for univers
[05:13] <white> e
[05:13] <Amaranth> white: util-linux is in main
[05:15] <white> the version 2.13-8ubuntu1 looks fixed to me
[05:15] <LaserJock> security-tracker.debian.net is so awesome
[05:16] <white> Amaranth: and i am bringing it up, because i forget to theck here and it would be nice to get an ubuntu person to do it
[05:16] <white> LaserJock: indeed :)
[05:16] <LaserJock> saved me loads of time doing the moodle MIR
[05:16] <Amaranth> moodle? isn't that an edubuntu thing?
[05:16] <Amaranth> oh right, you're an edubuntu guy :P
[05:19] <LaserJock> Amaranth: pfft
[05:19] <LaserJock> hmm, still need to get that interview up :/
[05:28] <tonyyarusso> Hobbsee: Do you have a shortcut for that phrase?
[05:33] <ScottK> tonyyarusso: Did you see my comments on the kompozer backport request?
[05:33] <tonyyarusso> ScottK: I saw one, to the effect of "sounds like a good idea - test?"
[05:34] <ScottK> That one.
[05:34] <ScottK> Please test.
[05:34] <tonyyarusso> well, um, it's installed on my feisty system right now, does that count?
[05:34] <ScottK> Yes. it does.
[05:35] <ScottK> Just say in the bug that you've built and installed it on Feisty and it works.
[05:35] <tonyyarusso> Okay.  It builds both in a local pbuilder and on LP PPA.
[05:36] <ScottK> I need it in the bug.
[05:37] <tonyyarusso> done
[05:38] <ScottK> tonyyarusso: Acked to the archive.  They usually do backports about once a week.
[05:39] <tonyyarusso> ScottK: neat.  Any thoughts on whether we should try for Edgy/Dapper as well?
[05:40] <ScottK> Hobbsee: Would you please ack Bug #148548.  We updated gnucash, we really ought to do the docs too.
[05:40] <ubotu> Launchpad bug 148548 in gnucash-docs "Gnucash-docs is 2.0.1 while it should be 2.2.0" [Undecided,New]  https://launchpad.net/bugs/148548
[05:40] <ScottK> tonyyarusso: Can you test on Edgy/Dapper?
[05:49] <tonyyarusso> ScottK: If I take the time to read some pbuilder docs, yeah.  There's already a PPA build for Edgy as well.
[05:50] <ScottK> tonyyarusso: It's not just building.  I need you to say it installs and runs.
[05:51] <tonyyarusso> ScottK: I can test that for Dapper for sure; not sure where I'll find an Edgy installation.
[05:51] <tonyyarusso> I'm sure if I ping enough people I could.
[05:52] <LaserJock> vmware/virtualbox?
[05:52] <tonyyarusso> no experience in that department..
[05:52] <tonyyarusso> Live CD could work I suppose
[05:54] <imbrandon> or "pbuilder-edgy login' then install and test it
[05:54] <imbrandon> ;)
[05:54] <tonyyarusso> what now?
[05:55] <imbrandon> as in ?
[05:56] <tonyyarusso> pbuilder-edgy login would just let you log into the command line system of the base.tgz, I take it?
[05:56] <tonyyarusso> How would I test a graphical app in that environment?
[05:57] <ScottK> LiveCD would do it.  Dunno about the rest.
[05:58] <LaserJock> tonyyarusso: install it and launch it?
[05:59] <tonyyarusso> LaserJock: would it use my feisty's X?
[05:59] <nenolod> probably
[05:59] <LaserJock> I suppose
[05:59] <nenolod> X is X. it doesn't really change ABI very often
[05:59] <nenolod> (Xlib, that is)
[06:00] <imbrandon> you might need to allow X connections from localhost, like 'xhost +` prior to pbuilder login
[06:01] <imbrandon> tonyyarusso: ^ but other than that should work fine
[06:01] <tonyyarusso> interesting
[06:01] <jdong> imbrandon: xhost + is a big more than localhost if the system is not properly configured though ;-)
[06:02] <nenolod> oh, use X inside a pbuilder?
[06:02] <imbrandon> yea if you dont setup your router correctly it can be a security bug, man xhost for more indepth info
[06:02] <nenolod> he just needs to do xhost +localhost
[06:02] <nenolod> it'll work provided that your debian/rules sets DISPLAY=:0
[06:02] <jdong> nenolod: right, I was gonna say xhost +localhost is more cautious
[06:02] <nenolod> (probably in configuration phase, right?)
[06:03] <imbrandon> shouldent matter, should default to 0
[06:03] <imbrandon> err :0
[06:04] <imbrandon> e.g. the following should work fine , `xhost +localhost` `pbuilder-edgy login` `apt-get install amarok` `amarok`
[06:04] <nenolod> no
[06:04] <nenolod> DISPLAY must be set, otherwise Xlib will not connect to the X server
[06:04] <nenolod> there is no defaults in Xlib
[06:05] <nenolod> (and thus any toolkits ontop of Xlib, e.g. Qt)
[06:05] <imbrandon> e.g. the following should work fine , `xhost +localhost` `pbuilder-edgy login` `apt-get install amarok` `export DISPLAY=:0` `amarok`
[06:05] <imbrandon> :)
[06:05] <nenolod> :)
[06:05] <imbrandon> no source changes
[06:05] <LaserJock> well, I used to use a chroot and bindmount ~/ and it's work fine for that kind of thing
[06:05] <LaserJock> *it'd
[06:05] <imbrandon> LaserJock: esentialy the same thing
[06:06] <imbrandon> pbuilder is just a self cleaning [sic]  chroot
[06:06] <LaserJock> right, but I believe that getting ~/ and hence .Xauthority into the chroot was the key thig
[06:07] <imbrandon> ahh
[06:08] <jdong> imbrandon: for X /tmp needs bindmounting too; that's where the sockets usually are
[06:14] <imbrandon> nah there should be a tmp in the chroot, you dont want to nessesarly give it access
[06:19] <nenolod> just do xhost +localhost and export DISPLAY=:0
[06:19] <nenolod> ;p
[06:30] <Hobbsee> tonyyarusso: perhaps.
[06:30] <Hobbsee> ScottK: please do it.
[06:31] <ScottK> Hobbsee: OK.
[06:31] <Hobbsee> tonyyarusso: there are ways to test grapical bits in a chroot.
[06:31] <ScottK> Hobbsee: I already test built it, so I'll turn it into a sync request.
[06:31] <Hobbsee> ah, you found it
[06:31] <Hobbsee> ScottK: great
[06:32] <Hobbsee> ScottK: will leave you to handle it then
[06:38] <LaserJock> crap
[06:42] <bddebian> not here please :-)
[06:44] <ScottK> Hobbsee: Done.
[06:44] <ScottK> jdong: You still around.
[06:44] <jdong> ScottK: half-awake, but yeah
[06:45] <ScottK> jdong: What happened to all the backports testing people?
[06:45] <ScottK> jdong: I think you need to rustle up some more ...
[06:45] <jdong> ScottK: I'm not sure myself, seems like a lot of them are mysteriously idle
[06:45] <ScottK> Hobbsee: Yummy?
[06:45] <Hobbsee> indeed!
[06:45] <jdong> ScottK: I'll send out an e-mail to the backports testing folk and see if I can whip em back
[06:45] <ScottK> jdong: Then Hobbsee's explaination fits...
[06:46] <jdong> ScottK: lol they're nutritious :)
[06:46] <ScottK> Or however you spell that word.
[06:46] <Hobbsee> explanation
[06:46] <ScottK> jdong: Remember: Sleep is for the weak.
[06:46] <ScottK> Yeah, that.
[06:46] <jdong> lol, but I am weak :)
[06:48] <ScottK> LaserJock: I'm not sure, but that may be a CoC violation, so don't do it on IRC.
[06:48] <LaserJock> hehe
[06:53] <LaserJock> wahoo, it works
[06:53] <LaserJock> now all those non-English speaking people can read the docs
[06:55] <Hobbsee> heh
[06:55] <LaserJock> I've spent the last 3 hrs working on the translations for edubuntu-docs
[06:56] <LaserJock> had to build several scripts
[06:56] <LaserJock> and rewrite debian/rules
[07:07] <bddebian> Gnight gang
[07:20] <LaserJock> \o/, uploaded
[07:20] <LaserJock> hopefully that's my last upload for gutsy
[07:20] <Hobbsee> aww
[07:21] <LaserJock> now hopefully slangasek or pitti lets it threw
[07:21] <LaserJock> hmm, *through
[07:21] <Hobbsee> LaserJock: we have more than 2 people in the release team, fortunately :P
[07:22] <LaserJock> I thought one of those two had to approve an RC freeze exception
[08:11] <LaserJock> shesh, the gutsy branch of doc team svn repo is ~550MB
[08:12] <ScottK> LaserJock: That's nothing.  I remember some guy talking about doing a checking of the Debian LaTex tree and it being huge.
[08:13] <LaserJock> umm, that was me
[08:13] <LaserJock> and it was 20GB
[08:13] <tonyyarusso> oof
[08:13] <ScottK> I know.  I just thought it was kind of funny that way.
[08:13] <LaserJock> heh, right
[08:14] <LaserJock> but we're supposed to move the doc team repo to bzr
[08:14] <LaserJock> which makes 500MB a bit more troublesome to me
[08:15] <ScottK> But bzr is wonderful.  Everyone here says so.
[08:15] <LaserJock> heh, I haven't really gotten that impression exactly
[08:15] <LaserJock> it's great for local stuff
[08:15] <LaserJock> but the remote stuff is still so slow
[08:17] <LaserJock> but the doc team repo is the last Canonical svn repo
[08:17] <LaserJock> so the sysadmins don't want to maintain it anymore
[08:22] <ScottK> Well good luck.  I'm off to bed.
[08:22] <LaserJock> cya ScottK
[09:39] <slangasek> imbrandon: packages don't have to be acked by the release team before being uploaded, if they're uploads to main and they don't fit the freeze rules they can just be rejected :)
[09:41] <AnAnt> Hello, if I am making a package for a work that is under LPPL license, the complete text for this license is not in /usr/share/common-licenses/, should I then include the complete text in the debian/copyright file  ? or is it enough to have something like this statement: http://pastebin.com/m16fc5080  ?
[09:44] <persia> AnAnt: The complete text of the license should be in debian/copyright.  The URL may not be available to a user (perhaps they are offline) when they check.
[09:44] <AnAnt> ok
[09:46] <AnAnt> persia: how about installing it in /usr/share/common-licenses/ ?!
[09:46] <Fujitsu> AnAnt: Is it a particularly common license?
[09:47] <AnAnt> Fujitsu: for those using LaTeX, I think so
[09:47] <persia> AnAnt: That directory is reserved for common licenses, for which large numbers of programs are using.  As an example of the threshold, the ISC license is not included, and we've heaps of ISC code.  Similarly, none of the CC licenses, although that is fairly prevalent.
[09:48] <AnAnt> k
[09:49] <persia> AnAnt: If you think it's common enough, feel free to post a bug against base-files to include it: be sure to list all the packages that use it in the bug, to demonstrate that it would save significant space on a user's system.
[09:50] <AnAnt> ok, how can I indent several lines with 4 spaces in vim ?!
[09:56] <AnAnt> nevermind about the last question
[09:56] <AnAnt> thanks
[10:04] <Fujitsu> Hobbsee: Are you still around?
[10:04] <Hobbsee> Fujitsu: fsvo around, what's up?
[10:05] <Fujitsu> Hobbsee: Just wondering if I'm going to be killed for uploading a new upstream version, the UVFe for which was filed by somebody else, and approved a month ago.
[10:06] <Hobbsee> Fujitsu: unlikely
[10:06] <Hobbsee> although why wasnt it uploaded then?
[10:06] <Hobbsee> that's a good question, actually
[10:06] <Fujitsu> Hobbsee: REVU was down, and the reporter isn't a MOTU.
[10:07] <Fujitsu> So it got lost.
[10:07] <Hobbsee> ah yes
[10:07] <Hobbsee> no idea if archive admins will get time to review it
[10:07] <Fujitsu> Are they meant to be reviewing things at this point?
[10:07] <Fujitsu> I thought they were just giving them a glance and letting them through.
[10:11] <Hobbsee> Fujitsu: for new packages?  dream on.
[10:12] <Fujitsu> Hobbsee: `a new upstream version'
[10:25] <nenolod> slangasek, yay for auto-rejections :P
[10:27] <nenolod> Fujitsu, a new upstream version won't be approved until gutsy ISOs are built. if you're shooting for gutsy +1 and your package is OK, then it will probably pass through reviewers at that time
[10:27] <nenolod> but... uploads targeted at gutsy itself will likely be auto-rejected :P
[10:28] <persia> auto-rejected?  I don't think that's the case for packages not destined for ISO inclusion (or, really, anything in universe).
[10:29] <nenolod> well ISO building also includes gutsy archive finalization too
[10:29] <nenolod> and even the topic says universe is frozen for upstream versions and new packages
[10:29] <nenolod> ;p
[10:30] <Fujitsu> nenolod: Erm, what? ISOs have very little to do with anything, it has already been approved, and I'm a MOTU so it doesn't need review.
[10:31] <nenolod> Fujitsu, well ok :P
[10:32] <persia> nenolod:  That seems to contradict https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002411.html.  Are you sure?  Why?
[10:32] <nenolod> persia, i'm going by what is implied by the text in the topic
[10:32] <Fujitsu> nenolod: Right, UVF and NPF in effect. I have an exception, although it is old.
[10:33] <persia> nenolod: Ah.  Yes.  New upstreams are frozen.  There is a freeze exception process, and so some (very few) things can be approved.
[10:33] <nenolod> persia, yes i understand that.
[10:33] <nenolod> Fujitsu, yes. i understood that point. hince the "well, ok"
[10:35] <sladen> two week folks, then we can upload whatever we want!
[10:35] <Fujitsu> sladen: Two weeks + UDS + toolchain settling.
[10:36] <nenolod> i do hope that gutsy will ship with audacious-plugins that are not built with SSE2
[10:36] <Fujitsu> nenolod: Why?
[10:36] <DarkMageZ> cause some of us don't have sse2
[10:36] <nenolod> Fujitsu, because not everyone has SSE2 ;)
[10:36] <persia> nenolod: If it doesn't detect at runtime, that's a bug (and should be reported).
[10:37] <nenolod> it has been reported
[10:37] <nenolod> upstream anyway
[10:37] <Fujitsu> I don't see the bug in Ubuntu..
[10:37] <nenolod> yeah, i'll check
[10:38] <nenolod> ah. it's debbugs
[10:38] <persia> nenolod: It's a good idea to get the bug in both places, if it's verified an issue in Ubuntu: upstream may have a different threshhold ("I cannot imagine why anyone would want to not use optimisation" is something I recently saw on a different upstream mailing list).
[10:39] <nenolod> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423833
[10:39] <ubotu> Debian bug 423833 in audacious "audacious: Crash (illegal instruction) when playing MP3 file" [Normal,Fixed] 
[10:39] <nenolod> of ypi want, o
[10:39] <nenolod> lets try that again
[10:39] <nenolod> if you want, i'll clone it in LP
[10:40] <Fujitsu> nenolod: If you could file a bug in LP, and add a Debian task linked to that bug, it'd be nice.
[10:41] <nenolod> (it's fixed in debian)
[10:41] <nenolod> ah.
[10:41] <nenolod> gutsy has it already
[10:42] <Fujitsu> nenolod: Yeah, we have that version.
[10:44] <nenolod> great :P
[10:44] <nenolod> because some people have flamed over that already
[10:44] <Fujitsu> Heh.
[10:46] <nenolod> i need to report a bug in NetworkManager, but I think I will wait until morning for that
[10:46] <nenolod> i'm not awake enough to think right now ;)
[10:47] <nenolod> i'm also not yet convinced that it is not a bug in madwifi too ;)
[11:51] <pkern> LongPointyStick: Thanks. ;)
[01:11] <pkern> Haha@everybody loves the Debian cabal.
[01:17] <DEVIUS> hi all
[01:18] <AlinuxOS> Hello All ;)
[01:21] <DEVIUS> I'm about to take www.ubuntu-ge.org domain and make it Ubuntu official support for georgian users
[01:21] <AlinuxOS> + setup Ubuntu LOCO team.
[01:23] <AlinuxOS> DEVIUS, let's try on #ubuntu-locoteams
[01:24] <AlinuxOS> maybe someone is alive :)
[01:33] <persia> Would anyone with a i386 and working GL be willing to test something for me?
[01:33] <Fujitsu> persia: Sure.
[01:34] <persia> Fujitsu: Thanks.  launch torcs, make sure your audio backend is set to openal, get around the first curve of the default course, and hit something (another car, the wall, etc.).
[01:35] <persia> It crashes on AMD64 due to differences in MMX compilation from gcc3.x to gcc4.x, and upstream's fix is really intrusive: I'm just not sure whether to disable the offending file for only AMD64 or for everything.
[01:35] <StevenK> Yay, torcs!
[01:35] <Fujitsu> Wow, torcs is fairly big.
[01:35] <StevenK> ... but MMX is just register fildding, how would amd64 kill it?
[01:36] <Fujitsu> StevenK: What would that be?
[01:36] <persia> StevenK: From what I can tell, there's a difference in the way that SIMD detection works with gcc 4.0 and optimisation, such that you need to have different #ifdef statements for newer compilers.
[01:36] <StevenK> % head -n 1 debian/control
[01:36] <StevenK> Source: virtualbox-ose-modules
[01:36] <StevenK> Fujitsu: ^
[01:37] <Fujitsu> StevenK: Aha.
[01:37] <StevenK> persia: But SIMD isn't MMX.
[01:37] <persia> StevenK: Huh?  MMX is one of many SIMD APIs.  Lead me...
[01:38] <StevenK> persia: MMX came first - SSE came after.
[01:38] <persia> StevenK: Yes.
[01:38] <StevenK> persia: I don't know much more than that, though. :-)
[01:40] <persia> StevenK: Ah.  From what I can tell looking at upstream CVS and the intel docs on MMX, MMX can be SISD or SIMD, but is usually SIMD, using packed registers (4 16-bits in a 64-bit).  It seems that newer gccs use a different set of controls to decide how to optimise.  If the code is written to the old MMX target, and doesn't have good runtime detection, it may get incorrectly optimised.
[01:40] <Fujitsu> persia: I've gone a fair way around the track, and managed to run into a lot of walls (I'm *so* great at such games), no crashing.
[01:41] <persia> Fujitsu: And this is with the openal audio backend, and with working sound?
[01:41] <Fujitsu> Yep.
[01:42] <persia> Fujitsu: Excellent.  Thanks for testing that.  I'll only disable MMX for x86_64 targets then,
[01:42] <Fujitsu> More `vroom, crash, skid, spin, oh look at that car that has lapped me for the second time'
[01:43] <persia> Fujitsu: You can choose everyone's cars if you want.  It's a little easier if you have a F1 and they have dune buggies.
[01:44] <Fujitsu> persia: I'm sure I'd still lose.
[01:44] <persia> Fujitsu: Then you have special skills :)
[01:44] <Fujitsu> Haha.
[01:45] <persia> StevenK: As the master of all library transitions: could you suggest any means to make sure that a modified libopenal0 works with all the rdepends without finding a way to expose the MMX issue in each game?
[01:46] <rexbron> persia: how goes it?
[01:46] <persia> rexbron: It appears that I've found an issue upstream fixed last march, but somehow never got merged.  If only it were earlier in the dev cycle...
[01:48] <rexbron> :(
[01:48] <rexbron> but it will be fixed upstream for hardy correct?
[01:49] <persia> rexbron: Depends.  Upstream hasn't actually had a release in a while, and is sponsored by Creative and Apple, so most of the development has been targeted towards Windows and Mac OS X.
[01:51] <rexbron> persia: best of luck (and lots of good work) then
[01:52] <persia> rexbron: Thanks.
[02:23] <persia> Anyone feel like packaging a 1-line SRU for Dapper?  #86212.
[02:25] <DktrKranz> hi persia, welcome back :)
[02:26] <persia> DktrKranz: Thanks.
[02:26] <DktrKranz> I looked at that bug, a user already provided a patch
[02:26] <DktrKranz> maybe he could do the job
[02:26] <DktrKranz> if not, I will be happy to manage myself
[02:26] <persia> DktrKranz: Right.  Someone just needs to make a Dapper debdiff, and go through the SRU process.  It's easy, but needs someone to watch it.
[02:27] <persia> (and verify the problem & solution in Dapper).
[02:27] <DktrKranz> no proble to verify it
[02:28] <persia> DktrKranz: Great.  Thanks.
[02:29] <DktrKranz> give me ten minutes, I have to finish a couple of things before...
[02:29] <persia> DktrKranz: No big rush.  The bug has been around for a while :)
[02:30] <DktrKranz> I see :)
[02:30] <DktrKranz> is it relevant for edgy too?
[02:31] <persia> DktrKranz: I'm not sure.
[02:31] <DktrKranz> ok, I'll check for edgy too
[02:51] <persia> rexbron: I've just taken a quick look at the genpo package.  You'll want to run the lintian and linda commands recommended in w.u.c/MOTU/Contributing on .dsc, and then on the .changes when you build it.  Remember to use `bzr export` :)
[02:53] <DktrKranz> persia, confirmed on Dapper, Edgy is affected too, could you please add a task?
[02:54] <persia> DktrKranz: added.
[02:54] <DktrKranz> that patch needs additional love
[02:54] <persia> DktrKranz: Yes it does :)
[02:55] <DktrKranz> at least, it requires an if clause to check if /var/run/smokeping is already present
[02:55] <DktrKranz> otherwise, it will raise an error
[02:56] <DktrKranz> I will report this to the user, asking if he want to manage those SRUs
[02:56] <persia> DktrKranz: I thought the -p took care of that.  Does it not work for the final directory?
[02:57] <DktrKranz> persia, IIRC it creates parent directories, not sure if it checks if the final one exists
[02:57] <persia> DktrKranz: I can't replicate any issues with breaking on existing directories with -p (even in dash)
[02:58] <DktrKranz> yes, it works
[03:40] <DarkMageZ> is there a way to get pbuilder to automatically generate -dbgsym packages of anything it builds?
[03:42] <DktrKranz> DarkMageZ, IIRC you can install pkg-create-dbgsym
[03:43] <DktrKranz> if you insert it into the default set, you should get them automatically
[03:43] <persia> DarkMageZ: Install pkg-create-dbgsym in the pbuilder chroot
[03:43] <DarkMageZ> ah, great :) ty
[04:21] <persia> Anyone with i386 and working GL willing to test the patch from bug #149806?  The test case is to compile and install a new libopenal0, start torcs, turn around the first bend, and crash into something.
[04:21] <ubotu> Launchpad bug 149806 in openal "OpenAL has unsafe MMX support on AMD64" [Undecided,New]  https://launchpad.net/bugs/149806
[04:23] <DarkMageZ> persia, i'll give it a shot
[04:23] <persia> DarkMageZ: Thanks.
[04:26] <DarkMageZ> persia, i've pulled the orig.tar.gz & diff.gz & .dsc, but how do i apply a debdiff? patch -p0 file didn't seem to be happy
[04:27] <persia> DarkMageZ: No?  Hmm.  Let me check that again...
[04:29] <DarkMageZ> persia, nvm. noob error on my part
[04:29] <persia> DarkMageZ: OK.  I was worried there :)
[04:31] <DarkMageZ> what was create the diff & dsc without signing again? it was something like debuild -us -uc
[04:31] <persia> DarkMageZ: exactly
[04:32] <persia> DarkMageZ: Alternately, you can use a pbuilder or sbuild (or deb-o-matic :) )
[04:32] <DarkMageZ> trippy. it says my system doesn't have the dependencies. i thought that command wasn't going to try and build it.
[04:32] <pkern> DarkMageZ: -S
[04:33] <persia> DarkMageZ: That command doesn't sign it.  -S doesn't build it.
[04:33] <pkern> DarkMageZ: Well it's called de*build*
[04:33] <DarkMageZ> ah, there it goes :) building.
[04:50] <DktrKranz> persia, deb-o-matic? did you use it in the past?
[04:51] <persia> DktrKranz: I remember looking at it a couple months ago, but I'm fairly fixed on sbuild for now.
[04:52] <jdong> bug 150130
[04:52] <ubotu> Launchpad bug 150130 in xserver-xgl "Xgl causes noise when scrolling" [Undecided,New]  https://launchpad.net/bugs/150130
[04:52] <DktrKranz> well, I started to write it just because I don't like wanna-build
[04:54] <persia> DktrKranz: Makes sense.  I don't have enough local package needs to get much beyond just building things, although I'll probably become more interested if I ever get more than one supported architecture working at once.
[04:55] <DktrKranz> it's a wanted feature, waiting for qemubuilder to became more stable
[04:55] <persia> DktrKranz: Now that's an interesting way to do it :)
[04:56] <DktrKranz> (I should have said waiting for qemubuilder AND qemu to become more stable, especially on sparc)
[04:57] <DktrKranz> I have kernel panics each time :(
[04:57] <persia> heh
[04:58] <pkern> What does deb-o-matic do?
[05:00] <DktrKranz> pkern, it's an automatic package builder. it uses pbuilder as engine. users upload source packages on a given directory with dput (or similar) and it gets them built
[05:01] <DktrKranz> it has some good features, others will come
[05:02] <pkern> Well I use reprepro for repository management. How does it determine what needs to be built?
[05:02] <DktrKranz> it has an "incoming queue"
[05:03] <DktrKranz> it scans it on a regular basis (by default every 60 seconds), determines which package should be built (based on priority)
[05:04] <DktrKranz> and, after updating pbuilder (if there is need to do so), it starts build process as pbuilder does
[05:04] <pkern> And update the chroot beforehand to grok updated builddeps?
[05:04] <pkern> Hm.
[05:04] <DktrKranz> it does only if archives has changed since last build
[05:05] <pkern> How does it "interface" with "archives"?
[05:06] <DktrKranz> when fetching packages or when checking if update is required?
[05:08] <pkern> I guess I'll look at the source next week. I want to get an amd64 autobuilder for our archive.
[05:09] <DktrKranz> well, it's not a professional tool now, just a toy for someone who has not time to wait for pbuilder to finish long builds :)
[05:11] <pkern> Well I need something asynchronous. I would be able to register new builds in reprepro hooks but here I would need to copy the package somewhere and get the result imported into reprepro again. (The latter could be solved if the built packages are placed into a seperate queue directory and the possiblity to call a script after each build to import it.)
[05:12] <pkern> And although we use PostgreSQL I still don't want to install dak and/or wanna-build ;)
[05:13] <pkern> Currently at 110 binary packages, more to come as Etch gets older.
[05:14] <DarkMageZ> persia, done. no odd results. cept for sound stuttering
[05:14] <DktrKranz> pkern, you can set a "incoming" directory as you wish, you will need source packages and related sources.changes file
[05:15] <DktrKranz> so, it won't bother reprepro
[05:15] <pkern> I don't have _source.changes currently.
[05:16] <pkern> That's another point. ;)
[05:16] <persia> pkern: No _source.changes?  How does that happen?
[05:16] <pkern> persia: It's Debian. We build it for i386.
[05:17] <pkern> Point is that we don't want the second step of shelling on another box and doing a -B build.
[05:17] <persia> DarkMageZ: Sound stuttering?  Does it do that with the libopenal0a from the repositories?
[05:17] <DarkMageZ> persia, yup. so that's not a regression :)
[05:17] <DktrKranz> pkern, you may want use a older release, when it used .dsc files to start build process
[05:18] <persia> DarkMageZ: OK.  Thanks.
[05:18] <pkern> DktrKranz: _<somerandomarch>.changes aren't that different ;) But I would have to dig into the code if that would be a solution for me.
[05:19] <pkern> It's a pity that Julien wrote rebuildd specific for the task of rebuilding packages.
[05:19] <DktrKranz> right, I would have used that
[05:19] <DktrKranz> instead of writing a buggy, unuseful, redundant piece of code :)
[05:20] <pkern> I mean probably that would be solved with a wrapper around apt-get source to apt-get update first.
[05:20] <pkern> And then enqueue the jobs after they got imported into the archive (and after an export of the lists obviously).
[05:21] <minghua> WTF is bug 150205
[05:21] <ubotu> Launchpad bug 150205 in baltix "Make menu items labels more consistent and clear" [Undecided,Invalid]  https://launchpad.net/bugs/150205
[05:22] <persia> minghua: Someone didn7t read the HIG, but noticed that it's not implemented 100%
[05:22] <pkern> minghua: Just a bit late?
[05:22] <pkern> persia: s/didn7t/did/?
[05:23] <persia> pkern: Ah.  ' is shift-7 on my keyboard layout, and I broke my finger this morning, so my typing's a bit funny.
[05:23] <pkern> I could still kill the Gnome devs for having merged Font into Appearance. /me grumbles.
[05:23] <minghua> persia: I wouldn't mind if he submit bugs to each package, but just one bug and subscribe everyone?
[05:23] <pkern> persia: There was also a change in the meaning in my question.
[05:23] <persia> minghua: I'd agree with that.  It's a per-package issue.
[05:24] <persia> pkern: Right.  The bug submitter's suggestions are closer to HIG, but not HIG compliant.
[05:24] <minghua> pkern: I personally like the new appearance dialog.
[05:24] <pkern> persia: k ;)
[05:24] <pkern> minghua: I use different Gnome versions.
[05:24] <pkern> (Yeah with that argument no change would be possible.)
[05:25] <minghua> heh.
[05:25] <pkern> Currently I'm on 2.14 ;)
[05:25] <minghua> persia: The bug reporter apparently doesn't realize those strings appear in other places as well, such as KDE and Xfce.
[05:26] <persia> minghua: I thought Xfce preferred HIG-compliant naming.  I don't know about KDE.
[05:27] <minghua> There is no FreeDesktop HIG as far as I know.
[05:29] <persia> Hrm.  There ought to be an abstraction of shared data.  http://developer.kde.org/documentation/standards/kde/style/basics/ and http://developer.gnome.org/projects/gup/hig/2.0/ really don't seem to match that closely.
[05:30] <minghua> That's exactly my point.
[05:31] <persia> From what I can tell, there'll be something new from KDE as part of KDE4 development (but I would think at least a draft would be somewhere by now...)
[05:31] <minghua> IMHO this is just lazy bug reporting, pointing out problems and hope others will do the hard work to fix it.
[05:32] <persia> minghua: Well, yes, but sometimes that's useful too.  There's quite a few things I've fixed only because someone complained.  On the other hand "won't fix" or "upstream" seem appropriate responses for the busy maintainer.
[05:33] <persia> (especially for such a badly filed bug)
[05:33] <minghua> I'm just attempted.  I'm not going to change it to "won't fix".
[05:34] <minghua> persia: Generally I don't mind lazy bug reporting, but this one makes me quite angry.
[05:34] <persia> minghua: You mean because the reporter didn't even bother to really firmly suggest alternatives, just whined about it?
[05:34] <minghua> If I change the scim part to "wishlist", and add comment about what should be done, I'll be spamming other maintainer.
[05:35] <persia> Ah, yes, making it useless for discussion.
[05:36] <minghua> persia: No, mainly the "throw everything in one report because it's easy for me" attitude.
[05:36] <proppy> hi
[05:37] <persia> Interestingly enough, there's a lot of traffic on the mailing lists, etc. that would imply that we prefer fewer bugs (we have too many to process), and there are several people who would start leaving "don't mass-file" comments if someone were to open a series of similar bugs, but for actual bug management, a targeted bug is much more useful.
[05:39] <pkern> Probably LP should support such meta bugs to easily track issues belonging together. \:
[05:40] <minghua> pkern: There isn't really much point about a meta bug.  Many other .desktop files don't have HIG-compliant name either, he reported those just because those are installed by default.
[05:40] <persia> pkern: Right, but how does one handle subscriptions?  I like to be subscribed to bugs I might fix, bugs I know how to fix that I might pass to someone, bugs in the packages I watch, and bugs I have on my system.  I have little interest in other bugs, and don't want to get discussion traffic in my mailbox for those.
[05:40] <minghua> persia: I skipped the whole thread about bug management. :-)
[05:41] <persia> minghua: That's probably for the best :)  Anyway, it was more about LP bug statuses than about few/many or meta/targeted.
[05:42] <minghua> Same with persia, especially since I put scim bugmails at a very high priority among my mailboxes, getting irrelevant discussions there really pisses me off.
[05:43] <minghua> persia: Yes, I know it starts from ScottK's "LP people shouldn't tell MOTUs what is the correct way to use LP". :-P
[05:43] <minghua> s/starts/started/
[05:44] <persia> minghua: I'd say it's more complicated than that, but it's not an important distinction.
[05:45] <minghua> I know I was over-simplifying.  Thus the smiley.
[05:46] <minghua> Hey, isn't Japan _the_ country of smileys?
[05:47] <minghua> ...on a second thought, that's probably why it's possible to enroll in a "graduate emoticon course". :-)
[05:48] <persia> minghua: Yep.  There's a heap of interesting examples in http://www.2chan.net/
[05:49] <persia> Or, better, http://2ch.net/
[05:52] <pkern> That looks so Japanese-ish.
[05:52] <persia> pkern: The best bit is that 90% of users are on 320x240 or less.
[05:57] <pkern> bigon: Is there anything particular in the aiccu updates that you want to see in Gutsy?
[06:05] <pkern> People continue to run into the fglrx+suspend issue. /me ponders to write a planet.u.c post.
[06:08] <persia> pkern: I believe an updated package has been prepared, and is waiting for merge (unless I completely fail to understand the issue: a distinct possibility)
[06:09] <pkern> persia: Uh, where what how?
[06:09] <pkern> persia: The only heared won't fix from various sides.
[06:09] <pkern> i.e. that gutsy will ship like that.
[06:09] <superm1> updated package, with what driver?  8.41 breaks any workstation cards
[06:09] <superm1> eg firegl
[06:10] <superm1> and it says in the release note for maintainers not to ship it
[06:11] <pkern> So it will be downgraded? I don't think that solves *that* issue I am talking about.
[06:12] <bigon> pkern: not really
[06:13] <pkern> 8.37.6 is in Gutsy
[06:13] <pkern> bigon: Aye, because I tend to NACK it. Simply because there isn't really a benefit and the risk of breakage at this point.
[06:13] <persia> pkern: Ah.  Nevermind.  I'm completely mistaken (xorg ati vs. ati frglx)
[06:15] <pkern> That issue I talk about is obviously not even considered release notes-worthy.
[06:15] <pkern> Bah.
[06:15] <pkern> But a post would probably be phrased too harsh.
[06:40] <pkern> How would I betatest Gutsy if I weren't at university... fetched one day full of updates (30M) in 5s. o_O
[07:36] <jdong> is the APSL or whatever license Apple Darwin's userspace is under considered kosher for Universe?
[07:37] <jdong> I'm considering packaging a bit of the HFS+ utils (namely fsck_hfs and newfs_hfs)...
[07:37] <jdong> as our current ones are nearly useless with Macpods and modern HFS volumes
[07:44] <pkern> bigon: The configuration/init script problem is not a regression.
[07:45] <pkern> Fun, I guess I need to revamp the debconf scripts next week. ;)
[08:12] <ScottK> jdong: Do you have a link to the license?
[08:13] <jdong> ScottK: http://www.opensource.apple.com/apsl/2.0.txt
[08:13] <jdong> APSL 2.0 AFAIK
[08:18] <ScottK> jdong: I think the patent provisions may be problematic.  The rest seems fine.  Not sure.
[08:19] <jdong> ScottK: interesting...
[08:19] <jdong> ScottK: I'll play around with the code a bit more; it's all BSD makefiles too.... gonna be "fun" to get it to build under Ubuntu :)
[09:07] <mssever> I'm developing a program that depends on libdaemonize-ruby. Someone recently complained that there is no such package in Gutsy. Since I'm not yet running Gutsy, can someone verify this and/or find the proper name for the gutsy package?
[09:08] <pkern> There's libdaemons-ruby...
[09:09] <pkern> Daemons provides an easy way to wrap existing ruby scripts (for example a self-written server) to be run as a daemon and to be controlled by simpl start/stop/restart commands. daemons can also run and control blocks of Ruby code in a daemon process.
[09:09] <mssever> Is that the same lib as libdaemonize?
[09:09] <pkern> That's what I ask you :-P
[09:09] <pkern> Don't know, at least there's no libdaemonize
[09:10] <mssever> pkern: hmm I'll look onto that
[09:12] <pkern> I don't find s.th. like daemonize on rubygems.
[09:12] <pkern> Just `daemons'.
[09:14] <mssever> Well, it appears that libdaemons-ruby isn't the same as libdaemonize-ruby--which is in feisty
[09:14] <mssever> Any chance of getting libdaemonize-ruby back in Gutsy?
[09:15] <pkern> mssever: See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428979
[09:15] <ubotu> Debian bug 428979 in ftp.debian.org "RM: libdaemonize-ruby -- RoM; superseded by libdaemons-ruby" [Normal,Open] 
[09:17] <mssever> Thanks for that link. I guess I'll update the depends field of my package and see if I get bug reports...
[09:17] <pkern> Uh oh.
[10:51] <Kmos> bug 144258
[10:51] <ubotu> Launchpad bug 144258 in scribes "[UVFe]  Please sync scribes (universe) 0.3.2.9-1 from Debian Unstable (main)" [Medium,New]  https://launchpad.net/bugs/144258
[10:51] <Kmos> need another ack and subscribe to ubuntu archive