[00:07] <directhex> hm. this isn't technically correct, but does the job ( i hope)
[00:32] <fta> kiko, I'm done with songbird 1.0.0 but apparently, there's an issue with the ppa builders so cprov killed my builds. I have no way to investigate as locally, it's all fine.
[00:49] <ScottK> If a package has a substantially larger popcon than the sum of the popcon of all it's rdepends, would that be a reason to think people are using it with something unpackaged?
[00:50] <ScottK> I came up dry using Google.
[00:53] <Hobbsee> ScottK: or popcon is on crack.  But yes, i'd sya that's probably a reasonable assumption
[00:54] <Hobbsee> popcon doesn't do partial reporting, afaik, so i presume that's the only solution
[00:54] <ajmitch> ScottK: that's not such a problem though, is it?
[00:55] <ajmitch> if you need to change something about the package (say the ABI), it it breaks 3rd party stuff, how were you to know?
[00:55] <ScottK> ajmitch: It's not a problem, but something accounting for ~200 popcon in Debian that's not packaged might be worth packaging.
[00:55] <ajmitch> trying to identify what that thing is will be fun
[00:55] <ScottK> I'd like to know what it is.
[00:55] <ScottK> Yeah.
[00:57] <ScottK> If someone is bored, the package in question is python-dns.
[00:57] <ScottK> Not something you're likely to install directly.
[00:58] <ajmitch> so it's either something unpackaged, or people are installing it directly to actually use the module in something they've written
[00:58] <kiko> fta, hmm, I'll ping cprov to figure out what's up
[01:00] <ajmitch> ScottK: funnily enough, I'm one of the latter
[01:01] <Hobbsee> ScottK: blog about it, and ask?
[01:02] <ScottK> ajmitch: You installed it directly?
[01:02] <ajmitch> it appears so
[01:02] <ScottK> Hobbsee: That might work.
[01:02] <ScottK> Odd.
[01:02] <Hobbsee> ScottK: planet's always good for those sorts of things
[01:02] <ScottK> Yeah.
[01:02]  * ajmitch does have python-formencode installed, by the look of things
[01:03] <ajmitch> but I think I did actually look at using python-dns directly
[01:04] <ScottK> python-formencode is it's largest (by popcon) rdepend.
[01:04] <ajmitch> not surprising
[01:04] <ajmitch> since python-turbogears & python-pylons use it
[01:04] <ScottK> Ah.  Makes sense.
[01:10] <st33med> Has anybody made the closed source version of Virtual Box available on multiverse?
[01:14] <stdin> can the binary be distributed freely?
[01:14] <st33med> Yep
[01:15] <st33med> http://www.virtualbox.org/wiki/Linux_Downloads
[01:15] <st33med> Wait
[01:15] <DarkKnight> hey i m a newbie...and wanted to be on the MOTU team....i read the wiki page...but there are certain things that i didnt understand
[01:15] <st33med> Does accepting a license count as free?
[01:16] <st33med> Say em DarkKnight, might be a while for someone to reply
[01:17] <DarkKnight> ya i just wished to be one of the developers in ubuntu...
[01:17] <DarkKnight> so wen i referred the wiki page....
[01:17] <ajmitch> st33med: http://www.virtualbox.org/wiki/Licensing_FAQ has a fairly clear no on redistribution of binaries
[01:17] <DarkKnight> it said that i had to file a bug or something
[01:17] <stdin> yep FAQ 7 says no
[01:17] <st33med> Ah
[01:17] <DarkKnight> to which i did
[01:18] <Hobbsee> st33med: note all of virtualbox-ose, virtualbox-ose-dbg, virtualbox-ose-source, virtualbox-ose-guest-source, virtualbox-ose-guest-utils
[01:18] <st33med> Yah
[01:18] <Hobbsee> and perhaps a couple of others
[01:18] <Hobbsee> (which are in universe)
[01:18] <st33med> OSE doesn't have USB support, which kinda sucks
[01:19] <stdin> one could, theoretically, do what is done with flash
[01:19] <stdin> ie, create a package which downloads it from their website
[01:19] <DarkKnight> so can anyone tell me where i can getgood info about compiling  packages
[01:19] <stdin> but that'd require running dpkg inside a dpkg run, so it's bad
[01:20] <stdin> !packaging
[01:20] <stdin> and..
[01:20] <stdin> !compiling
[01:20] <Hobbsee> stdin: or one could just use the repositories from virtualbox.org, which also work reasonably well ;)
[01:21] <stdin> yeah, much easier. which is probably why no one has ever tried to create such a package
[01:23] <Hobbsee> stdin: well, the OSE versions are already there, so...
[01:26] <st33med> And anyone who has heard of it most likely visited the website too
[01:26] <st33med> So yah.
[01:35] <nellery> is there any way to run debuild without getting the DebianMaintainerField error?
[04:13]  * ScottK-laptop starts to wonder if this thing is actually on?
[04:30] <leonel> scottK ping
[04:36] <ScottK> leonel: pong
[04:36] <leonel> scottK for the  jpeg  the code has changed
[04:37] <leonel> scottK in  special.c  the patch applies fine
[04:37] <leonel> but there are   structs  changes  for example  maxreclevel  in   0.92.1  is in cl_limits  and  in 0.94  has been moved to  cl_engine
[04:38] <ScottK> leonel: Right.  So does that mean the patch needs to be adapted?
[04:38] <leonel> I think so
[04:38] <leonel> and  in the svn from clamav
[04:39] <leonel> the  changelog for the 1266 clamav bug
[04:39] <leonel> does not shows the changes  in  others.h or  in clamav.h  for that change
[04:40] <leonel> so I guess I'll first find an exploit for the code  test it  and if  is vulnerable  try to adapt the code
[04:40] <leonel> as you asked previously that if 0.92.1 is vulnerable
[04:42] <ScottK-laptop> leonel: My guess is that unless you find some kind of recursion limit in special.c it's vulnerable, but that sounds good.
[04:43] <leonel> ScottK-laptop: if(ctx->recursion > ctx->engine->maxreclevel)
[04:43] <leonel>   	            return CL_EMAXREC;
[04:44] <leonel>  those and another reference is there
[04:44] <leonel> but the maxreclevel is on another  struct
[04:44] <leonel> in 0.92.1
[04:46] <leonel> got to go  I'll continue  tomorrow  morning
[04:47] <ScottK> OK.
[04:47] <ScottK> leonel: Thanks for working on this.  I know it's not simple.
[04:48] <leonel> scottK   this must get fixed .. see you tomorrow
[04:48] <aib> i'm interested in packaging our software and having it included in ubuntu. is this possible? our software is called Emergent and we have been running our own ubuntu repository for years. http://grey.colorado.edu/emergent
[04:49] <ScottK-laptop> aib: If it's got an appropriate license the answer is generally yes.
[04:49] <aib> GPL
[04:49] <aib> where do I start?
[04:52] <ScottK-laptop> aib: You have experience with Debian packaging then?
[04:52] <aib> extensive
[04:53] <ScottK-laptop> OK.  Ubuntu essentially follows Debian policy with some minor variations.
[04:53] <ScottK-laptop> Initial revision for a package not in Debian would be -0ubuntu1.
[04:54] <ScottK-laptop> Upload target would be jaunty instead of unstable
[04:54] <jdong> "copyright" 599L, 19060C written
[04:54] <jdong> whee :)
[04:54] <aib> ok, supposing i follow the debian new maintainers guide with the ubuntu modifications, what do i then do with my package?
[04:54] <aib> is there a doc describing this? i haven't found one yet
[04:55] <ScottK-laptop> !revu | aib
[04:55] <ScottK-laptop> aib: We also have some special rules about Maintainer.  See https://wiki.ubuntu.com/DebianMaintainerField
[04:56] <ScottK-laptop> And finally:
[04:56] <kees> ah, crap, leonel went offline
[04:56] <ScottK-laptop> !packagingguide
[04:56] <kees> I have the PoC for the JPEG crash -- added it to the clamav test
[04:56] <ScottK-laptop> kees: He'll be back in the morning.
[04:56] <ScottK-laptop> Cool.
[04:57] <ScottK-laptop> kees: Debian needs to patch Etch, can I offer it to them?
[04:57] <aib> ScottK-laptop, thank you very much
[04:58] <ScottK-laptop> kees: Or you could just join #debian-clamav on OFTC and offer it yourself ...
[04:58] <kees> ScottK-laptop: yeah, totally, it's in the upstream bug report: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1266
[04:58] <ScottK-laptop> kees:
[04:58] <ScottK-laptop> OK.
[04:58] <ScottK-laptop> Recursion is fun.
[04:58] <ScottK-laptop> aib: You're welcome.  Thank you for showing up and wanting to contribute to Ubuntu.
[04:59] <ScottK-laptop> kees: sgran is almost certainly asleep right now, but he does read the scrollback.
[05:00] <kees> ScottK-laptop: looks like hardy isn't vulnerable to it
[05:00] <kees> (intrepid was, prior to the patch)
[05:00] <ScottK-laptop> kees: That's what leonel was trying to figure out when he ran out of steam.
[05:01] <ScottK-laptop> kees: Is it not vulnerable or not vulnerable if MaxRecursionLimit (or something similar) is set to a sane value.
[05:02] <kees> ScottK-laptop: oh, good point.
[05:02] <kees> ScottK-laptop: well, I guess I should say "stock install of" ...
[05:02] <aib> i recently ported our software from autotools to cmake as KDE did - has anyone packaged cmake-based software? does their debian generator create standard compliant packages?
[05:02] <ScottK-laptop> aib: All the KDE4 packages in Intrepid and Jaunty are cmake.
[05:03] <aib> as in, `make deb' packages? that would be wonderful but i really doubt it:)
[05:03] <ScottK-laptop> No, not that simple.
[05:04] <ScottK-laptop> Most of the Kubuntu devs are in Europe, so this is not the best time of day, but you can discuss cmake stuff here or in #kubuntu-devel.
[05:30] <ScottK-laptop> Good night all.
[05:31] <ScottK-laptop> aib: You can ask questions here as you have them.  Generally someone here can/will answer.
[05:32] <Hobbsee> night ScottK-laptop
[05:52] <Hobbsee> james_w: wow, that went quickly!
[06:26] <dholbach> good morning
[06:26] <fabrice_sp> morning dholbach
[06:27] <dholbach> hi fabrice_sp
[06:28] <fabrice_sp> dholbach: how are you doing this morning ! :-)
[06:28] <fabrice_sp> ?
[06:29] <dholbach> fabrice_sp: I'm slowly waking up, but I'm good - also very excited about meeting people at UDS
[06:29] <dholbach> fabrice_sp: how are you?
[06:30] <fabrice_sp> fine also, thanks! Preparing for going to work :-)
[06:30] <fabrice_sp> UDS will be huge! :-)
[06:30] <dholbach> yeah
[06:30] <dholbach> fabrice_sp: have a great day!
[06:31] <fabrice_sp> also for you :-)
[06:54] <slytherin> is there any set timeline for a package to get cleared from NEW queue?
[06:55] <Hobbsee> slytherin: not as such
[06:55] <Hobbsee> slytherin: people do have archive days
[06:55] <Hobbsee> but UDS will throw that out, and there are a lot in the queue (and it's not necessarily FIFO)
[06:56] <Hobbsee> which package, and do you need it for something else?
[06:56] <geser> good morning
[06:56] <slytherin> Hobbsee: libhibernate3-java, and I need it to clear at least 3 more DEPWAIT.
[06:57] <slytherin> geser: good morning.
[06:57] <geser> Hi slytherin
[06:57] <iulian> G'morning.
[06:58] <Hobbsee> slytherin: k
[06:59] <slytherin> geser: Just FYI ... if we need to move the jboss related packages to universe, they will all need to be moved together.
[07:01] <Hobbsee> slytherin: what do you need given back?
[07:04] <slytherin> Hobbsee: I will do it myself thanks. :-)
[07:04] <Hobbsee> slytherin: you can?  OK.
[07:06] <Hobbsee> 20 left.  obviously it's getting helped along reasonably quickly
[07:26] <didrocks> morning & Danke Schöne dholbach :)
[07:26] <dholbach> didrocks: :)
[08:51] <slytherin> Hobbsee: I didn't need to give back any packages. they were automatically rebuilt.
[10:03] <eMerzh> someone has time to review http://revu.ubuntuwire.com/details.py?package=sqliteman ? thaaaaanks a lot :)
[10:49] <monomanta> hello... can we haz ScummVM version bump in repositories PLZ?
[10:57] <monomanta> https://bugs.launchpad.net/ubuntu/+source/scummvm/+bug/291591
[10:58] <directhex> coo, scummvm
[11:03] <monomanta> coo?
[11:24] <bmm> I'm online for comments on http://revu.ubuntuwire.com/details.py?package=metalink thanks in advance!
[12:50] <slytherin> Hobbsee: ping
[13:14] <slytherin> geser: Do you mind if I go ahead today with libjogl-java merge? We will sync with Debian once the package in experimental is moved to unstable.
[13:15] <ScottK> slytherin: Why not sync from Experimental?
[13:15] <slytherin> ScottK: Because it is in experimental. :-) And I don't know the reasons.
[13:16] <ScottK> slytherin: OK.  Sounds reasonable.
[13:17] <directhex> moonlight 1.0~beta1 packages ready ^_^
[13:24] <slytherin> ScottK: Current merge will help us move package to universe (license change). Where as if we do a sync from experimental it may solve FTBFS on Sparc. But considering that Sparc is not officially supported architecture I don't think sync is urgent.
[13:29]  * apachelogger waits for JontheEchidna to say "hi" :P
[13:30] <JontheEchidna> aib: Hello there, I heard you needed some assistance with a package using cmake?
[13:30] <ScottK> JontheEchidna: He's also two hours west of us, so I'm guessing still sleeping.
[13:30] <JontheEchidna> makes sense
[14:21] <geser> slytherin: no, I don't mind, go ahead (I'm currently too busy to do it myself)
[14:22] <slytherin> geser: Ok.
[14:23] <slytherin> geser: By the way, now there are only 3 packages (2 in NEW, 1 in DEPWAIT) that need to be available to check if jboss from Debian builds or not.
[14:28] <geser> does the one in DEPWAIT wait on one of those in NEW?
[14:31] <slytherin> geser: yes it does.
[14:32] <slytherin> geser: the package in DEPWAIT is - libhibernate-entitymanager-java, depends on libhibernate-annotations-java which is in NEW
[14:39] <handschuh> isnt libhibernate-annotations-java supposed to be libhibernate-commons-annotations-java ?
[14:48] <slytherin> handschuh: those are two different packages. rmadison is your friend. :-)
[14:51] <handschuh> slytherin: ok .. thanks quite confusing .. the package is somehow bad, I think
[15:04] <slytherin> handschuh: I am not concerned about shape of package at this point. Only getting them built. :-)
[15:31] <lod__> hello, I have a Q.; I'm maintaining custom kernel with IMQ patch for QoS, and using the guide at wiki.ubuntu.com for building custom kernel, but can't find where to change revision numbers for builded kernel, I've looked at debian/rules but can't find it..
[15:32] <dholbach> lod__: try #ubuntu-kernel
[15:34] <lod__> 10x
[15:52] <invaleed> Hallo
[15:55] <allquixotic> Hello MOTUs: I am looking to do an SRU for Intrepid, and have followed the process up to the point where I am requesting the release team to evaluate the report: https://bugs.launchpad.net/ubuntu/+source/libshout/+bug/304843
[16:00] <jdong> allquixotic: that's a main package; you want to subscribe the 'ubuntu-sru' team
[16:00] <jdong> and #ubuntu-devel would be the correct channel to poke if poking were deemed to be necessary
[16:01] <allquixotic> How would I go about subscribing the ubuntu-sru team?
[16:01] <allquixotic> "subscribe someone else"?
[16:01] <allquixotic> nevermind, I've done it.
[16:05] <jdong> cool.
[16:13] <jdong> would someone like to speculate why Phoronix benchmarked ext4 using 4 synthetic FS tools and 12 CPU-bound tasks, such as 3D game FPSes?
[16:13] <jdong> I'm not sure Michael understands that ext4 doesn't run on video cards...
[16:16] <directhex> jdong, michael, bless his little cotton socks, doesn't really get benchmarking
[16:16] <directhex> and i say this despite his test suite being a very clever framework (written in php (!))
[16:16] <jdong> directhex: I think one thing that it DOES show is the variance in his tests
[16:16] <directhex> yes
[16:17] <jdong> directhex: for some reason his gnupg test showed more than 5% difference in performance between the 4 filesystems.
[16:17] <jdong> judging from that I'd consider anything less than a 20% difference in his tests to be statistically insignificant
[16:17] <directhex> jdong, but even when doing a 3d card, he benchmarks ancient games which are ~100% cpu bound on a modern card
[16:18] <jdong> directhex: he also failed to identify even the most basic behavioral characteristics of the 4 filesystems he teste
[16:18] <jdong> d
[16:18] <jdong> i.e. he failed to notice XFS takes 20-200x longer than ext3 and reiserfs respectively to rm -rf a kernel source tree.
[16:18] <directhex> let's not make this a bitching session - but i feel phoronix's benchmarking criteria have always been a little strange
[16:18] <jdong> or that XFS deletes a single 1TB file 20x faster than ext3...
[16:19] <directhex> jdong, running mythtv means you just knows these things instinctively ;)
[16:19] <jdong> directhex: maybe phoronix should run a mythbuntu vs ubuntu 7-zip benchmark.
[16:19] <directhex> jdong, you mock, but.....
[16:20]  * jdong wonders how on earth LZMA compression differed by 4-8 seconds doing a single-file using the 4 different FSes...
[16:21] <jdong> bless his soul for taking all this time to benchmark stuff; I'm not trying to rag on him or discredit his work....
[16:21] <jdong> just this clearly demonstrates more than ever that his results need to be taken with scrutiny.
[16:22] <jorgenpt> jdong: 4-8 seconds to a total of .. what?
[16:22] <jdong> 320 seconds or so
[16:22] <jorgenpt> jdong: Representing that as a percentage is much more telling. :-)
[16:22] <jdong> about 1-2% variation
[16:23] <jdong> http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=7
[16:23] <jdong> more frightening is the last benchmark there
[16:23] <jdong> GNUPG of a 2GB file
[16:24] <jdong> ext3 and ext4 difered by 11 seconds (more than 10%)
[16:24] <jdong> I don't know what settings he used, but on my system GPG for a 2GB file is somewhat CPU-bound...
[16:24] <directhex> jdong, thing is, benchmarking is BORING. it's not as if a little game of quake4 whilst the bench runs matters, right? that's what multi-core is FOR!
[16:25] <rjune> LOL
[16:25] <jdong> ffmpeg also showed a 7% variation for MPEG2 encoding between ext3 and ext4
[16:25] <jdong> I also find that extremely hard to believe
[16:25] <directhex> right, that's my coffee finished. to the motorway!
[16:25] <jdong> ffmpeg's mpeg2 encoder at times is slower than its MPEG4-ASP encoder
[16:41] <RainCT> Is there a PPA or something to try ext4 on Intrepid?
[16:43] <jdong> RainCT: I've got a HOWTO.
[16:44] <RainCT> jdong: cool, URL?
[16:44] <jdong> digging :)
[16:44] <jdong> RainCT: http://ubuntuforums.org/showthread.php?t=973701
[16:45] <jdong> RainCT: FWIW I've been intensively running two systems with ext4dev on stock Intrepid kernels and have not experienced any disk issues YET
[16:45] <jdong> I think it's a *better* idea to grab the ext4 2.6.27 patchset from tytso's kernel.org directory
[16:46] <jdong> but even without it, I'm noticing dramatically better concurrent IO performance, fragmentation behavior, and REALLY IMPROVED small-file-deletion performance using ext4 compared to ext3
[16:46] <hyperair> i wonder how much difference it'd make if you're using ext3 vs ext4 on top of dm-crypt
[16:46] <psusi> jdong: you know I found out recently while working on the defrag package that fsck considers just about any file over 44k to be non-contiguous in it's little report, since any file over that size will have an indirect block which normally would follow the 11th data block
[16:47] <jdong> psusi: not surprised; I measure fragmentation by cold-read throughput
[16:47] <RainCT> jdong: "a better idea" as in it will be faster or as in your computer may not explode? :P
[16:47] <jdong> RainCT: it will be faster and one or two unmount-time potential oopses are fixed.
[16:47] <jdong> RainCT: there is a notable patch that reduces fragmentation in extent allocation behavior
[16:48] <RainCT> alright
[16:48] <jdong> IIRC, for a 4GB fedora torrent limited to 200KB/s download speed, the readback on ext3 went at 8MB/s while on ext4 it went at 25MB/s
[16:48] <jdong> disk is capable of 40MB/s sequential sustained
[16:48] <jdong> on XFS it was shockingly close to that 40MB/s number, upper 30's IIRC
[16:48] <jdong> no preallocation of any type was used
[16:49] <psusi> wow, I was going to say neither ext3 nor 4 look good there then
[16:50] <jdong> psusi: well ext4 is looking *BETTER* and this is without the aforementioned ext4 extent patch
[16:50] <psusi> yea, but even 25 sounds not good
[16:51] <RainCT> jdong: I guess the "turn on not backwards-compatible stuff" point is optional?
[16:52] <psusi> well, not turning on the new features would kind of defeat the point wouldn't it?
[16:52] <RainCT> Well, I think I'll wait. I have / and /boot together, and don't want to mess with the /home partition :P
[16:53] <RainCT> jdong: btw, nice forum sig :P
[16:57]  * invaleed is away (Please give me hug)
[17:28] <eMerzh> Any volonteers to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ?  it was previously advocated by DktrKranz ...
[17:58] <hefe_bia> jdong: On the ext4 topic: Is the info on volid vs. blkid from http://ext4.wiki.kernel.org/index.php/Ext4_Howto still valid or valid at all? Is this a problem in real usage?
[17:59] <bddebian> Heya gang
[18:02] <slytherin> somebody please help. What host do I need to use with dput to upload to Ubuntu archives?
[18:04] <Laney> slytherin: upload.ubuntu.com
[18:04] <Laney> afaik
[18:05] <jmarsden|work> dput -H lists the hosts...
[18:05] <Laney> slytherin: https://wiki.ubuntu.com/MOTU/New
[18:07] <ScottK> slytherin: In the default Ubuntu config for dput you shouldn't need to list a host.
[18:07] <slytherin> Laney: Thanks for link.
[18:08] <slytherin> ScottK: got that after reading that wiki page. :-)
[18:09] <ScottK> slytherin: Personally I change that to make sure I have to do dput ubuntu to get to the official archive (I once accidentally uploaded a package intended for a PPA to the archive - and it was in Main and it was during a freeze).
[18:10] <slytherin> ScottK: thanks for advice. I will be careful.
[18:11] <Laney> well at least it was during a freeze
[18:15] <iulian> Hiya bddebian.
[18:15] <bddebian> Hello iulian
[18:22] <ScottK> Laney: No,  It was a 'soft freeze'.  One of the 'please don't upload' ones.
[18:26] <Laney> Oh, that's bad then
[18:27] <ScottK> Yes.  So I'm very careful now.
[18:27] <jdong> ScottK: I do the same
[18:27] <ScottK> By default my dput uploads to a non-existent repo called 'bob'
[18:27] <jdong> my default dput target is invalid
[18:28] <ScottK> If you just unset the target it defaults to Debian ftp-master.
[18:28]  * ScottK uploaded there by mistake too.
[18:28]  * ScottK had to hunt down a DD to do dcut for him.
[18:28] <ScottK> Thus I upload to bob.
[19:01] <bmm> Request for comments: http://revu.ubuntuwire.com/details.py?package=metalink
[19:21] <Aquina> hy
[19:21] <Aquina> Can you please update the Cherokee webserver to its latest version 0.11.x in synaptic?
[19:22] <Aquina> I'm running Xubuntu 8.04. HH and the software availale is of version 0.5.x
[19:41] <handschuh> slytherin: ping
[19:46] <ScottK> !backports | Aquina
[20:16] <Milyardo> <3 ubottu
[20:50] <directhex> hm
[20:50]  * directhex summons a vote
[20:51] <laga> ka-ching
[20:52] <directhex> moon apparently requires cairo 1.8. not a debian problem, but i was hoping for syncability
[20:52] <directhex> do i target experimental (which has it) or make the package build its own static cairo?
[20:52] <directhex> or something else?
[20:53] <pochu> directhex: are you sure you are on the right channel? :)
[20:53] <directhex> pochu, sure. the syncability question matters!
[20:53] <directhex> pochu, or if not, what solution? OOo-style synamic control building?
[20:55] <pochu> directhex: ok, if you can upload to experimental and keep it syncable, I'd go for that
[20:55] <pochu> it won't hit testing anyway ;)
[21:00]  * directhex gives his sponsor the word
[21:05] <RAOF> directhex: Yeah.  Sync from experimental!
[21:38] <Laney> Can anyone spot a problem with this: pbuilder-sid create --othermirror "deb ftp://ftp.uk.debian.org/debian experimental main contrib non-free" - I get "E: Malformed line 1 in source list /etc/apt/sources.list (URI)"
[21:42] <mok0> Laney: looks sane to me. Perhaps it's another line
[21:42] <Laney> Maybe I'll use pbuilder directly
[21:42]  * Laney smites it
[21:42] <RAOF> You've aware that you can just do a pbuilder-experimental create, right?
[21:43] <mok0> Laney: use cowbuilder!
[21:43] <Laney> RAOF: I was not.
[21:43] <RAOF> Experimental is a supported dist for pbuilder-dist; it pulls in sid + experimental.
[21:44] <mok0> cowbuilder is much faster than pbuilder
[21:44] <Laney> RAOF: I'm using pbuilder-dist.new. Let's see if it likes that
[21:45]  * mok0 feels ignored
[21:45] <Laney> mok0: Sorry, I'm not ignoring you. It's just that RAOF is giving me answers that don't require me to learn a new tool :P
[21:45] <mok0> :-) It's more-or-less the same
[21:46] <Laney> is there a cowbuilder-dist?
[21:46] <Laney> "Warning: Unknown distribution «experimental»."
[21:46] <Laney> but it still seems to be doing ok
[21:46] <mok0> Laney: except cowbuilder doesn't need to unpack the tar archive first
[21:46] <Laney> Oh, yeah that takes a couple of seconds
[21:46] <mok0> Laney: it uses a create-on-write filesystem
[21:47] <RAOF> Can you make cowdancer build on a tmpfs?
[21:47] <Laney> mok0: Does it implement pbuilder's interface, roughly?
[21:47] <mok0> RAOF: I haven't tried
[21:47] <Laney> Oh, that's the point of cowbuilder. I see.
[21:47] <mok0> Laney: yes, it's almost the same, except for one option
[21:48] <mok0> Laney: you need to specify --base-dir instead of --base-tgz
[21:48] <RAOF> Because that's the biggest pbuilder optimisation I've seen.  As long as I don't try to build something that saps too much memory ;).
[21:48] <Laney> I should get around to fixing my schroots to use a local apt cache.
[21:49]  * RAOF used squid for that.
[21:50] <RAOF> Cool.  So, xserver-xorg-video-nouveau builds (and works) with unmodified Jaunty libdrm.
[21:50] <mok0> http://wiki.debian.org/cowbuilder
[21:50] <mok0> https://wiki.ubuntu.com/CowdancerHowto
[21:51] <RAOF> Time to update experimental's nouveau snapshot, polish the dkms nouveau-kernel package, and get some review.
[21:51] <ajmitch> RAOF: great, is it useful?
[21:52] <Laney> mok0: Maybe you could port pbuilder-dist{.new} in ubuntu-dev-tools to cowbuilder? ;)
[21:52] <Laney> {,.new}*
[21:52] <RAOF> ajmitch: Depends on what you want.  If you want 3d, no.  If you want fast, featureful 2d, yes.
[21:52] <ajmitch> RAOF: of course I need 3D :)
[21:52] <mok0> Laney: It wouldn't be a huge project... I've just made my own little script
[21:53] <Laney> I imagine it would mostly be s/pbuilder/cowbuilder/
[21:53] <mok0> Laney: yeah
[21:53] <RAOF> ajmitch: Nouveau's 3d got merged into the main mesa repository, so it's getting a little more love; you could try that :)
[21:54] <Laney> RAOF: pbuilder-experimental works. Win!
[21:54] <mok0> \O//
[21:56] <mok0> Have any of you tried adopting an orphaned Debian package?
[21:56] <ajmitch> RAOF: so in 12 months I can play WoW? :)
[21:58] <RAOF> Concievably ;)
[21:59] <ajmitch> I expect there'll still be a lot of work to do
[21:59] <RAOF> In 12 months time?  Probably.
[21:59] <RAOF> Gah.  New mesa won't build because we don't enable dri2 in X.
[22:00] <RAOF> Or maybe because we have an obsolete dri2-proto.  Who knows.
[22:01] <quadrispro> hi RainCT
[22:25] <mok0> heh, I did it...
[22:28]  * ScottK-laptop wonders if he should ask ...
[22:32]  * handschuh nods
[22:33] <Laney> Gah
[22:33] <Laney> http://pastebin.ubuntu.com/80042/ <- when doing pbuilder-experimental create
[22:33]  * Laney headdesks
[22:34] <Laney> directhex: How do you testbuild mono stuff? :(
[22:43] <RAOF> Laney: Hm.  Mine Just Worked(tm).  I don't suppose sid+experimental is broken atm?
[22:43] <Laney> I guess so
[22:57] <directhex> Laney, test things in experimental? i had to tweak my pbuilder to pin experimental to the same as sid
[23:13] <Hobbsee> slytherin: contentless pong?
[23:13] <Hobbsee> slytherin: and cool