[00:00] <directhex> mostly real figures for precisely what it means are in the section marked "Sample Mono20Transition Shrink" on http://wiki.debian.org/Teams/DebianMonoGroup/InstallSizeFormatted
[00:02] <nxvl> i'm gone
[00:04] <jdong> slangasek: the source-change backports only uploadable by core-dev rule was established by the tech board at the first backports meeting; Personally I'd like to see that changed s/core-dev/motu backporter/ but I won't cry too much if that can't be the case.
[00:05] <slangasek> sure
[00:05] <persia> NCommander: While it may not have much value in one's personal dealings, it's always safest to be sane when providing something to millions of people.
[00:06] <directhex> (/me wonders if anyone will notice 17 meg of livecd space saved from tomboy, and savings in f-spot too)
[00:06] <slangasek> directhex: <blink>
[00:07] <NCommander> persia, point take. Sanity is a useful item, but like all good things, it must be used in moderation
[00:07] <jdong> I agree with persia on this one. When we put things into a one-click trusted Backports repository we have a higher responsibility to only push sane reasonably low risk backports.
[00:08] <jdong> with that said, I'd really like to take some time to revamp prevu a bit more (maybe into a GUI) for users to be able to make their own more aggressive backporting decisions more easily.
[00:08] <NCommander> jdong, maybe you can simply turn prevu into a pbuilder wrapper with simple sanity checks
[00:08] <jdong> NCommander: that is what it is at the moment
[00:09] <NCommander> oh
[00:09] <NCommander> As you might surmise, I don't use prevu ;-)
[00:09] <jdong> NCommander: it's a pbuilder with $dist-{updates,backports} main+universe+multiverse+restricted that inserts into an apt repo in sources.list
[00:09] <jdong> NCommander: basically a lazy one-command prevu environment for backporters
[00:09] <jdong> pbuilder*
[00:09] <NCommander> heh
[00:09] <pochu> night everyone
[00:09] <persia> jdong: If you could make a quick GUI, it would make things simpler.  In the few cases I recommend backports, it's always a bit tricky to help people to do the backport compilation.
[00:09] <NCommander> I just use DIST=hardy-backports pbuilder build *dsc*
[00:10] <jdong> persia: agreed
[00:10] <jdong> NCommander: prevu would be "(DIST=target_dist) prevu lp:packagename(/distro_if_not_intrepid)"
[00:11] <persia> NCommander: Yes, but you're a developer.
[00:11] <NCommander> Maybe it would be possible to have a one-click script that can generate an upload to the PPA< which also makes it available to other testers easily
[00:11] <jdong> for those who are well versed in pbuilder the difference is trivial/nonvaluable
[00:11] <NCommander> persia, oh, I know, I'd never recommend a developer use pbuilder
[00:11] <NCommander> er
[00:11] <NCommander> non-developer
[00:11] <jdong> but for the beginners and non-developers we need to make prevu even friendlier
[00:11] <jdong> and also be able for users to monitor their backported packages and track their status in intrepid
[00:11] <NCommander> I dunno, the bar for prevu pretty low it seems
[00:12] <jdong> probably even give the ability to share debdiffs for debian/control
[00:12] <NCommander> Granted, my mom won't be able to use it, but my mom won't know what backports are either
[00:12] <jdong> NCommander: telling someone to install prevu, run sudo prevu-init, then prevu packagname, then apt-get update, etc is still not trivial
[00:12] <jdong> NCommander: that's not an ideal answer to "how do I get the latest pidgin?"
[00:13] <directhex> slangasek, assuming ubuntu-desktop has similar figures to debian's gnome-desktop-environment --without-recommends, i think 20 meg sounds like a reasonable figure for total shrinkage in tomboy/f-spot's dependencies in jaunty. i haven't tested against an ubuntu install for a while, since it makes more sense for me to focus on "upstream" (i.e. debian), but my gut says 20 meg is a conservative safe number saved
[00:14] <slangasek> directhex: I would be very happy to see that kind of savings. :)
[00:14] <directhex> slangasek, it's all explained in those two wiki pages
[00:14] <directhex> slangasek, it's mostlt applicable to debian
[00:15] <persia> directhex: Ubuntu is also recommends-by-default now: while this may not impact the total size comparison, it will be a factor in the interdependencies of the split packages.
[00:15] <directhex> persia, i know, but the confusion comes from debian NOT using recommends-by-default when installing from d-i (for one thing it excludes mono from debian desktops)
[00:16] <directhex> persia, those numbers are WITH recommends (hence the silly install size quoted for banshee)
[00:16] <directhex> persia, but a "clean" debian lenny system has gnome-desktop-environment WITHOUT recommends
[00:16] <directhex> slangasek, sorry, mostly applicable to ubuntu
[00:17] <persia> I'm confused.  I thought Debian was recommends-by-default before Ubuntu.  That d-i is special is odd.
[00:17] <directhex> persia, very odd, but sadly true
[00:17] <directhex> persia, the difference in gnome-desktop-environment's case is about a gig (!)
[00:17] <slangasek> d-i is special because the package manager behavior changed in Debian while the Recommends were mostly crap
[00:18] <slangasek> and joeyh/fjp didn't want to fight these one-by-one
[00:18] <persia> Oh.  That's probably it then.  In Ubuntu, a couple people could go change all the Recommends, and would get stomped on when they broke the CD sizes.  For Debian, it's a more complex social process.
[00:19] <pythonic> hi.. i've built a package for debian (build-depends: perl). what changes do i need to make to upload it to ubuntu?
[00:19] <persia> pythonic: None.  Upload it to Debian, and it will be automatically included when the archive is again unfrozen.
[00:20] <pythonic> persia: i have no sponsor there.. was looking to take this route instead :-)
[00:21] <pythonic> (as recommended by http://newpeople.debian.org/~mpalmer/debian-mentors_FAQ.html)
[00:21] <persia> pythonic: Honestly, I suspect your chances are better to have something on mentors.d.n and an ITP than to try to get something into Ubuntu today.
[00:21] <pythonic> i'm doing that too
[00:21] <directhex> silly recommends example: banshee adds 100 meg on disk to a "clean" lenny system. "zomg!" you cry. but... banshee Depends: gstreamer0.10-plugins-bad, which Depends: libwildmidi0 which Recommends: freepats which is 33 meg on disk - 1/3 of banshee's apparently bloated file size pulled in by a recommends required for gstreamer's mini playback plugin to have some synth voices
[00:22] <directhex> s/mini/midi/
[00:22] <directhex> persia, wouldn't you recommend improving debian as the best route anyway? share the love!
[00:22] <persia> For Ubuntu 9.04, REVU will open in November.  For putting a package through REVU rather than through Debian, the three main changes are the revision (-0ubuntu1 instead of -1), the bug closure (LP: #nnnnnn for a launchpad bug, instead of closes: #nnnnnn for a BTS bug), and the maintainer entry (packages in Ubuntu must have an @ubuntu.com maintainer, and teams are vastly preferred)
[00:23] <pythonic> the package is http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=bucardo
[00:23] <pythonic> (an asynchronous replication system for PostgreSQL)
[00:23] <pythonic> persia: ok, thanks :-)
[00:23] <slangasek> directhex: so, who's working on fixing libwildmidi0's recommends: ?
[00:23] <persia> directhex: It depends on the package.  In many cases, I think going through Debian is the best route.  In some cases, I'm less certain.
[00:24] <persia> slangasek: What's wrong with libwildmidi0's recommends?
[00:24]  * persia is supposed to fix that if they are broken, but hadn't heard.
[00:24] <directhex> slangasek, no idea. i mean, it makes sense really - libwildmidi0 is pretty useless without synth voices. the bigger question is, should gstreamer0.10-plugins-bad be split so you don't *need* midi playback support just to get at other plugins in bad?
[00:25] <slangasek> persia: well, if libwildmidi0 recommends: freepats and pulls in 33MB that's not needed by most of the reverse-deps of libwildpats0, something ought to be fixed there.  Maybe banshee should be fixed not to depend on -bad, instead?
[00:25] <slangasek> directhex: I guess we could move it from -bad to -worse ;P
[00:25] <directhex> i suspect banshee wants libgstfaad, since it supports aac as a cd ripping format
[00:25] <pythonic> persia: how do i get an @ubuntu.com address?
[00:26] <directhex> maybe libgstreplaygain too. i'd need to check the source
[00:26] <persia> slangasek: I'd go for either banshee not depending on -bad or -bad not including the wildmidi plugin (that could be a separate binary package).  Wildmidi is fairly useless without patches.
[00:26] <nhandler> pythonic: You get an @ubuntu.com address when you become an Ubuntu member.
[00:26] <slangasek> persia: that's fair
[00:26] <persia> pythonic: Most people just work with a team to maintain the package, rather than being an individual maintainer.
[00:27] <NCommander> jdong, speaking of backports, have you done anything about the spam to fiesty/gutsy backports trackers?
[00:28] <directhex> slangasek, working on mono, i'm used to the idea of one-package-per-lib to help produce ultra-minimal dependency chains where possible. the dependencies needed to run tomboy on mono versus opensuse today (i.e. before 2.0 transition changes) are already more than 50% smaller in ubuntu.
[00:28] <persia> slangasek: Note that wildmidi does *not* depend on fluid-soundfont-gm in the hopes of not being impossible to download.
[00:28] <pythonic> is there a list of maintainers/teams?
[00:28] <directhex> slangasek, it's not THAT much work if a good dh_ script exists to track those deps for you in debian/control
[00:29] <directhex> persia, 145 meg on disk just for synth voices would take the piss just a bit
[00:29] <slangasek> directhex: wow, Suse's mono deps for tomboy are /twice/ the size of Ubuntu's?
[00:29] <persia> pythonic: There are lots of lists, but none that are both comprehensive and correct.  Most people just work with the MOTU team for packages in universe (and you're in the right channel for that team).
[00:29] <persia> directhex: That's what I thought :)
[00:29] <directhex> slangasek, more. suse has a monolithic package, mono-core. every lib (2 versions thereof, for .net {1,2}.0, and all deps of those libs
[00:29] <directhex> as well as runtime etc
[00:30] <directhex> ubuntu's 80 binary packages from 1 source package might seem excessive, but it means tiny disk use by comparison
[00:31] <persia> 80 binary packages!  Now I understand why you thought there could be an improvement in the way the JRE was distributed in terms of required size on install.
[00:32] <NCommander> o_o;
[00:33] <directhex> well, 79
[00:33] <directhex> more after the 2.0 transition
[00:33] <persia> Oh.  That's not so bad then
[00:33] <Fagballs> Oh crap, i'm still in here.
[00:33] <Fagballs> ...
[00:33] <Fagballs> ...eh.
[00:34] <persia> The trick when having thoughts is to hold the fingers motionless :)
[00:34] <directhex> persia, but give http://www.meebey.net/jaws/?gadget=Blog&action=SingleView&id=Hello_World_how_small_can_you_get a read: "hello world" in mono in debbuntu is <4.5M on disk, how much for java? the splitting means only the very basics are needed for that - the jitter and enough of the class library to print hello world.
[00:34] <pythonic> persia: ok. i'd need to find a maintainer before i can upload the package to revu?
[00:35] <persia> directhex: Right, but you can use MOTU, which makes finding a maintainer fairly easy.  The hard part is that only exceptional new packages will even be reviewed before November.
[00:36] <directhex> pythonic, ^^
[00:36] <persia> That's why I encourage you to keep chasing Debian sponsorship (maybe once squeeze opens).
[00:36] <persia> directhex: Sorry: was distracted whilst planning a reply :)
[00:36] <directhex> persia, but it actually scales. gtk# app "graphmonkey", even before the 2.0 transition, pulls in 14.4 meg on disk including the app and the entire framework needed to run it. how much space does a typical gui java app need, including the runtime?
[00:37] <NCommander> jdong, out of curosity, when was the backporters must be MOTU rule was established?
[00:38] <jdong> NCommander: also at the same time (TB officialization of backports)
[00:38] <NCommander> ah I see
[00:38] <jdong> NCommander: the non-MOTU exception was myself, as kicking the founder of the backports team off wasn't logical, nor was magically making me MOTU at the time
[00:38] <NCommander> persia, oh, they annouced the new name for lenny+1?
[00:39] <jdong> NCommander: at the time I wanted to solely dedicate myself to backports work so I held off on MOTU apprenticeship
[00:39] <persia> directhex: I see the point.  Getting down from ~100MB to even ~20 would be nice.  Of course, it needs someone to do it :)
[00:39] <NCommander> yeah, I understand that :-)
[00:39] <directhex> persia, no, i'm not volunteering ;)
[00:39] <NCommander> I just fear, especially in light of kirkland's MOTU application that any attempt to get MOTU will get rejected due to lack of Universe uploads :-/
[00:40] <persia> NCommander: There are plenty of universe FTBFS if you just want universe uploads.
[00:41] <NCommander> persia, true, but I think its silly to require high numbers of universe uploads if there are uploads to main
[00:41] <NCommander> Because people who apply straight to core-dev run into the opposite problem, that they aren't an MOTU
[00:41] <directhex> persia, i'm just providing full disclosure which will hopefully benefit debbuntu - meanwhile though, i think it's safe to say mono in the clear in any mono-vs-java arguments wherever the topic of bloat is mentioned ;)
[00:41] <NCommander> debbuntu? Thats a new one
[00:42] <ceekay> persia: thanks for the explanation. filed bug 271956 :)
[00:42] <directhex> NCommander, as opposed to rpm dists like susehat
[00:43] <persia> directhex: I'm not someone who generally promotes x vs. y unless yada is concerned.
[00:43] <persia> NCommander: I don't see why those going straight to core dev need be MOTU, personally.
[00:43] <NCommander> persia, and those who grant core-dev don't understand why they don't have MOTU
[00:44] <persia> NCommander: Do you have an example of this?
[00:45] <NCommander> persia, yes, I can find it on -devel's archives
[00:46] <directhex> persia, well, no. our focus on the debian mono team is a stable platform for apps, first & foremost. but it would be nice if a best-of-breed app being java didn't mean 3-figure increases in livecd space requirements, for all concerned - it would be a terrible shame if a best-of-breed app were passed over for something inferior for something as mundane as space requirements
[00:47] <persia> directhex: For the most part I agree, although if something is truly best-of-breed, and nobody can be bothered to figure out how to get it to also fit on a CD, I have to question the importance of the breed.  See above about my decision to not push for proper soundfont support before adding wildmidi.
[00:48] <jdong> well.. the java runtime doesn't exactly use its extra space storing family photo backups of java devs... their "base" API is larger.
[00:48] <slangasek> I think that underestimates the impact of space requirements on the total user experience; writing each of your desktop apps in a different language, with a different runtime, affects things like virtual memory usage and integration, too.
[00:50] <slangasek> "40MB of libraries on disk that nothing else uses" =~ "40MB of libraries in memory that aren't shared between process", e.g.
[00:50] <slangasek> +es
[00:51] <directhex> and it doesn't help that java's a memory hog. (sorry, but that one's just true, check shootout.alioth.debian.org)
[00:52] <directhex> actually... slangasek, reckon thats WHY java seems to do badly in the memory dept in the shootout? or at least part of it?
[00:52] <slangasek> it's a part of it, yes
[00:52] <directhex> so splitting java would help. hm
[00:52] <jdong> don't they also only test the server mode of the JVM?
[00:52] <jdong> where the garbage collector is more lazy?
[00:53] <directhex> like persia says though, the lines are less clear in java as to what can be split where
[00:53] <slangasek> directhex: splitting the java libraries wouldn't help for that, if the JVM is only loading those jars actually referenced by the program in question
[00:53] <directhex> jdong, -server or -Xint
[00:53] <slangasek> although, the fact that Java libs are generally not mmap()able can't help performance
[00:53] <jdong> directhex: err... that doesn't sound fair
[00:54] <jdong> so either the one that takes a decade to JIT or the one that's interpreted bytecode?
[00:55] <jdong> but anyway, this is completely off topic from your discussion
[00:55] <persia> jdong: We're using HotSpot now which does a bit of both, so that's an outdated comparison (at least for some architectures)
[00:56] <jdong> persia: who's "we"? as in Ubuntu with OpenJDK?
[00:56] <persia> jdong: Also Debian with OpenJDK.  "we" being the Java Team (I can speak for Ubuntu Java Team, and a number of members of Ubuntu Java Team are also members of the Debian Java team)
[00:57] <jdong> persia: gotcha, understood; I was merely pointing out that they seemed to start the JVM with an unusual dichotomy of flags that they didn't subject mono or any other framework to.
[00:57] <jdong> i.e. I didn't see them turn off the JIT to mono or force it to --aot fully.
[00:59] <directhex> we don't ship mint, but it looks like the shootout is using mono from some upstream tarball
[00:59] <jdong> "is we don't ship the crippling option" really a valid excuse for enabling it on another language?
[01:00] <directhex> don't look at me, i don't run the shootout
[01:00] <persia> jdong: Oh.  I hadn't really considered the shootout.  I'm more in favour of supporting upstreams language choices, and letting users decide what to run than comparing languages.  That said, I'd ideally like to see everything in C, just to reduce the number of loaded libraries.
[01:00] <directhex> i'm just saying, we don't ship mint
[01:00] <persia> (but that day is *long* past)
[01:00] <directhex> persia, i'd rather write an app in an afternoon than fight c for a week
[01:01] <jdong> uh oh full-out language wars now
[01:01] <ceekay> serious
[01:01] <jdong> I really hate getting into this whole performance-of-languages shootout topic... it always gets touchy and blurry really fast...
[01:01] <directhex> performance IS a silly metric when you're talking about clicky gui apps though
[01:01] <persia> directhex: From the libary loading perspective for optimised performance on minimal hardware, I can't support that position.  From the developer perspective, I understand: hence my comment that I'm in favour of supporting upstream language choices.
[01:02] <directhex> who'd notice  a 20% speed drop in gedit?
[01:02] <persia> Probably mousepad users.
[01:02] <jdong> yeah
[01:02] <jdong> anyone who doesn't have a fast computer
[01:02] <jdong> and it's probably not a 20% speed drop either.
[01:02] <directhex> how do you speed up apps which spend 99% of their time waiting for user input?
[01:02] <jdong> it's probably a 20% average drop with big spikes here and there.
[01:03] <jdong> directhex: by making that 1% of the time they process really fast.
[01:03] <jdong> i.e. by the garbage collector not running when the user clicks save, by not spending 3000 cycles unwinding an exception stack, etc...
[01:03] <persia> Anyway, it's not worth having this discussion here.  We would do best to make sure that all the applications we have work as well as they can, and to help the flavour developers in their selection of an appropriate set of applications to meet their users' needs.
[01:04] <directhex> jdong, how much developer effort is that 1% worth, though? i suppose that's the question. and i think that depends on the scenario. i'd rather write my apps in c#, but i appreciate libavcodec having crunchy hand-optimized assembler sections to make my transcoding not suck
[01:04] <directhex> persia, you're right, of course
[01:04] <jdong> directhex: don't get me wrong, I agree with you personally on reasons to choose higher-level languages at the cost of performance but benefit of development time
[01:05] <jdong> but still it doesn't provide the basis to brush off people who are performance-conscious
[01:05] <persia> directhex: But I wasn't before: I inadvertantly put on a flavour developer hat here, and got the language wars all started up again :)
[01:05] <directhex> persia, emacs!
[01:05] <jdong> I feel I'm the only vim supporter over here.
[01:05] <jdong> I am a vim user in a pool of emac zombies.
[01:05] <slangasek> directhex: it's not a silly metric, it's just not the only metric
[01:05]  * ScottK likes vim.
[01:06] <directhex> i'm a bare-faced liar. i'm too dumb to use vim OR emacs, and just use nano
[01:06] <persia> directhex: Precisely. That's not a good choice for either of the flavours with which I am involved, but many people like it, and it's probably a good choice for them.
[01:06] <jdong> of course, going to the school where emacs was written doesn't help.
[01:07] <persia> jdong: I find the amount I use emacs is directly proportional to my distance from Kenmore Square.
[01:07] <slangasek> the emacsachusetts institute of technology?
[01:11] <directhex> bedtime.
[01:11] <jdong> slangasek: yeah, that place.
[01:12] <coppro> slangasek: no, the eMASSACHUSETTS Institute of TEcHNolOGY
[01:12] <jdong> they use the silly s/U/V/ font....
[01:14] <slangasek> coppro: what's wrong with your shift key?
[01:14] <slangasek> jdong: I'm still amazed at the idea that an OS I helped produce is now the basis for Project Athena
[01:14] <coppro> slangasek: My shift key? It's the Caps Lock key that's the problem :P
[01:14] <coppro> Project Athena?
[01:14] <jdong> slangasek: yeah I'm psyched for the Hardy release :)
[01:15] <jdong> coppro: the MIT AFS/Kerberos/Linux based operating system that runs on over 90% of the public computer stations on campus
[01:15] <coppro> ah, cool
[01:15] <coppro> jdong: really? I'm waiting for Intrepid, myself
[01:15] <jdong> coppro: the next release of Athena due in 2 months is based off a modified Ubuntu Hardy
[01:16] <coppro> ah, I see
[01:16] <coppro> I thought you meant you were waiting for Intrepid and thought it was Hardy
[01:16] <jdong> coppro: nah, I'm waiting to figure out how to swap alt and meta with this fancy new input device system
[01:17] <coppro> xmodmap?
[01:17] <jdong> coppro: that doesn't work for me anymore
[01:17] <coppro> :(
[01:21] <NCommander> jdong, the guy smashing up the backport bug trackers has been banned
[01:21] <jdong> good to hear
[01:21] <NCommander> I'm now asking the LP status to undo the damage
[01:57] <pythonic> hi.. i have created a package.. do i subscribe ubuntu-universe-sponsors to the "needs packaging" bug before uploading the package somewhere?
[01:59] <nhandler> pythonic: You should upload the package to REVU. That way, Ubuntu Developers can review the package, and post comments about it.
[01:59] <nhandler> !revu | pythonic
[01:59] <pythonic> the package needs to have an @ubuntu.org maintainer?
[02:00] <nhandler> pythonic: The maintainer should be 'Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>". I would suggest reading https://wiki.ubuntu.com/DebianMaintainerField
[02:00] <pythonic> i see. thanks :-)
[02:03] <pythonic> i also created this package for debian. should i have the debian-maintainer field?
[02:04] <slangasek> it's probably a good idea, in that case
[02:05] <pythonic> is it Debian-Maintainer or XSBC-Original-Maintainer?
[02:06] <persia> pythonic: XSBC-Original-Maintainer is the field conventionally used.  There's no reason you couldn't use XBCS-Debian-Maintainer, but the tools won't expect it.
[02:07] <persia> pythonic: Also, please don't be disappointed when nobody reviews your package until November, and then suggests changes that were due to things that happened between now and then.
[02:08] <pythonic> november's ok.. (in #debian-mentors i'd be asking november in which year?)
[02:13] <slangasek> who all does PPC porting nowadays?
[02:13] <slangasek> (https://launchpad.net/ubuntu/+source/mplayer/2:1.0~rc2-0ubuntu15/+build/707482)
[02:15] <NCommander> slangasek, I do some
[02:15] <slangasek> NCommander: your compiler segfaults ^^
[02:15] <NCommander> Yum
[02:15] <NCommander> ICE
[02:16] <NCommander> Impressive
[02:16] <NCommander> Its been awhile since I've seen a good ice
[02:17] <ScottK> I believe TheMuso is still interested.
[02:18] <NCommander> wow, queued 9 days?
[02:18] <NCommander> That bad of a backlog?
[02:18] <NCommander> er, 6
[02:20] <NCommander> slangasek, can you please retry the build
[02:20] <NCommander> GCC has been updated since this build was attempted
[02:20] <slangasek> ok, done.
[02:21] <slangasek> (does the gcc changelog point to anything ppc-related?)
[02:21] <NCommander> thank you my lord and master
[02:21] <NCommander> (haven't checked, but since my PPC machine is dist-upgrading to intrepid from hardy, it will be awhile before I can confirm or deny the build failure as buildd specific)
[02:23] <NCommander> slangasek, BTW, I have access to a HPPA Ubuntu box now (don't ask how I managed to magic that), so if there is a HPPA Build failure thats bugging you, point me at it
[02:23]  * NCommander also has an ia64 one too now
[02:23] <slangasek> instead of blaming lamont? :)
[02:24] <NCommander> er
[02:24] <NCommander> No hppa boxs here
[02:27] <NCommander> slangasek, although I don't have a vested interest in hppa or ia64, I do feel that our ports shouldn't be in such miserably shape that people avoid them like Vista
[02:30] <NCommander> WOOO
[02:30] <NCommander> FTBFS
[02:30] <NCommander> It's still using the old GCC
[02:30] <NCommander> WHile it seems to have built past that on my PPC
[02:30] <NCommander> ^- sladen
[02:30] <NCommander> er ^- slangasek
[02:33] <NCommander> slangasek, ok, FTBFS confirmed :-P
[02:35] <NCommander> persia, ping?
[02:36] <sladen> mmm
[02:50] <jdong> alright, now that this silly homework is done, let's make VLC happen :)
[02:56] <NCommander> lol
[03:18] <NCommander> Wow
[03:18] <NCommander> Windows CE's kernel source is available under a permissive license
[03:18] <NCommander> when did THAT happen
[03:20] <coppro> quick, put it in Ubuntu
[03:21] <NCommander> already checking the license for a catch
[03:21] <NCommander> :-)
[03:21] <wgrant> intrepid/wince-i386
[03:21]  * wgrant winces.
[03:21]  * NCommander also winces
[03:21] <NCommander> That is a rather unfortnate acronym
[03:22] <wgrant> It is.
[03:22] <NCommander> especially if you've ever done Windwos CE coding
[03:22] <NCommander> *Windows
[03:22] <NCommander> I'll just leave you the first lession
[03:22] <NCommander> There are no processes, just threads
[03:22] <wgrant> I am fortunately blissfully ignorant of such horrors.
[03:22] <NCommander> Now your mind can ooze
[03:23] <ajmitch> sounds safe & secure
[03:23] <NCommander> The design actually quite interesting
[03:23] <NCommander> the implementation
[03:23] <NCommander> Not so much
[03:24] <NCommander> I'm going to lie down
[03:24]  * NCommander travels beyond the reach of time itself
[03:24]  * wgrant vetoes NCommander's MOTU application for that knowledge.
[03:24] <NCommander> wgrant,well, if your going to play like that
[03:25] <NCommander> x86 real mode ASM has only four general purpose registers, and a segmented namespace vs a flat one by default. What this means is you have to do more stack manipulation for simple things then should be allowed
[03:26] <ajmitch> it's been a few years since I've done any of that, but I do recall that
[03:26] <NCommander> ajmitch, protected mode has more fun things :-)
[03:27] <NCommander> long mode is just bigger protected mode, although going from PM to LM is rather stupid
[03:27] <RAOF> No processes?  Owch.
[03:28] <NCommander> RAOF, well, there are, but generally speaking, its all threads vs. processes
[03:28] <NCommander> (i.e., no fork, no vfork, and a hell of a lot of threading)
[03:28] <coppro> erlang has no threads, just processes!
[03:29] <NCommander> processes on Linux aren't heavy
[03:29] <wgrant> Normal Windows has no fork either, odes it?
[03:29] <NCommander> They are on Linux
[03:29] <NCommander> wgrant, in POSIX mode it does
[03:29] <NCommander> wgrant, but you can't (easily) call the Win32 subsystem from POSIX subsystems
[03:29] <wgrant> Ahh.
[03:29]  * RAOF thinks that's probably a sanity-saver.
[03:30] <NCommander> RAOF, no, you haven't seen the win32 replacement for fork()
[03:30] <NCommander> CreateProcess
[03:30] <NCommander> And its 10 inputs
[03:30] <NCommander> four of those are structs
[03:30] <NCommander> Which control the resulting process
[03:30] <StevenK> Yup. Sounds like OpenFile() and it's 8 arguments.
[03:30] <RAOF> Each of which will require you to fill in the size of the structure as a part of setup, yes.
[03:30] <wgrant> What about the dozen variants of it?
[03:31]  * StevenK shivers, having done one semester of Win32 programming
[03:31] <RAOF> No, I meant that was likely a way to save the sanity of people used to POSIX by keeping the evil win32 away.
[03:31] <jdong> aahhhh
[03:31] <jdong> 3319 line interdiff
[03:31] <wgrant> jdong: VLC?
[03:31] <jdong> wgrant: yup
[03:31]  * ajmitch wonders why people think that win32 programming is bad
[03:31] <NCommander> StevenK, OpenFile() is depreiated
[03:31] <jdong> wgrant: just sifted through upstream's nightly packaging line by line
[03:32] <wgrant> jdong: Ew.
[03:32] <NCommander> ajmitch, actually, its not that bad once you get used to it
[03:32] <jdong> wgrant: merged what wasn't crack and fixed what was.
[03:32] <StevenK> Oh, CreateFile()
[03:32] <NCommander> StevenK, its now CreateFile
[03:32] <wgrant> NCommander: OpenFileI?
[03:32] <NCommander> Yeah
[03:32] <wgrant> Ah.
[03:32] <NCommander> No
[03:32] <NCommander> Every function has an A and a U version
[03:32] <NCommander> for Unicode
[03:32] <wgrant> Ahh.
[03:32] <NCommander> s/U/W/g
[03:32] <NCommander> (wide)
[03:32]  * ajmitch was about to say...
[03:32] <NCommander> Normally you can forget about that unless your doing COM objects
[03:32] <RAOF> ajmitch: For me, it was fiddling around with it and finding that all the structures seemed to have at least one undocumented member that had to be set a certain way or the program would mysteriously fail.
[03:32] <StevenK> Since just getting it to deal with Unicode is too hard
[03:32] <NCommander> COM objects have to use Unicode APIs
[03:33] <ajmitch> RAOF: at least the API is comparatively stable across versions
[03:33] <NCommander> Which can cause all sorts of fun interactions since you can't directly access the ASCII methods without doing a hell of a lot of magic
[03:33] <RAOF> ajmitch: Indeed.  That could be said to be it's major defining feature.
[03:33] <RAOF> "We're ABI compatible until the end of time"
[03:33] <ajmitch> and the major drawback, in a sense
[03:33] <StevenK> NCommander: And yet, you said "actually, its not that bad once you get used to it"
[03:34] <NCommander> StevenK, your talking to someone who codes in Ada
[03:34]  * StevenK twitches
[03:34] <NCommander> My tolerances for pain outstrip most peoples
[03:34] <NCommander> Hell, my hack o meter is desenstized to the point that I don't even flinch on some bad hacks
[03:34] <RAOF> While we're on API suckage, could someone kindly make GTK theadsafe?  Kthxbye.
[03:35] <NCommander> Generally speaking, COM is wonderful in some ways
[03:35] <NCommander> Total fail in others
[03:35] <NCommander> COM is what COBRA SHOULD have been
[03:35] <wgrant> No. CORBA shouldn't *be*.
[03:35] <ajmitch> yay for design-by-committee
[03:35]  * NCommander has used cobra
[03:35] <NCommander> :-)
[03:36] <NCommander> Its like a poorly implemented COM
[03:36] <NCommander> About the only good thing is its standardized so if you have a COBRA client, it (usually) works with any cobra server
[03:38] <jdong> RAOF: how many threadsafe GUI toolkits are there?
[03:38] <RAOF> jdong: I don't know, nor do I care.
[03:38] <jdong> :)
[03:38] <RAOF> jdong: I'd like GTK to be among their number!
[03:38] <jdong> good answer. I think the answer is zero though :D
[03:38] <NCommander> jdong, Qt
[03:38] <RAOF> QT isn't theadsafe?
[03:39] <jdong> NCommander: is it thread safe?
[03:39] <RAOF> Hah, NCommander beats me to it :)
[03:39] <NCommander> With some limitations, yes
[03:39] <NCommander> WIn32 is actually as well
[03:39] <jdong> *with some limitations*?
[03:39] <NCommander> jdong, some of the database APIs aren't
[03:39] <NCommander> Remember, QT isn't just GUI
[03:39] <NCommander> But last I checked, almost all of the GUI functions are thread safe with the exception of qt_init() or equivelent ;-)
[03:40] <NCommander> (you can only init the library once)
[03:40] <RAOF> It's _everything_ :).
[03:40] <NCommander> My grip with Qt is it intergrates poorly with everything
[03:40] <NCommander> I never mind running a GTK app in KDE
[03:40] <NCommander> But I wince when I have to run a Qt/KDE app in GNOME/Xfce
[03:40] <RAOF>  Because it is its own network, I/O, html, sound, video, GUI, IPC stack?
[03:41] <NCommander> GTK has quite a bit of that
[03:41] <NCommander> But when I use a GTK app, I don't usaully realize it
[03:41] <NCommander> Since GTK blends in with most enviornments (i.e., Motif)
[03:41] <jdong> ok, hopefully nobody reads the bzr logs of my internal VLC branch
[03:41] <jdong> I don't think they're code-of-conduct friendly at this point :D
[03:41]  * wgrant subscribes
[03:41]  * NCommander does too
[03:42] <NCommander> stransborn(sp) effect
[03:42] <jdong> CoC-friendliness = k/((pbuilder_build_failures)^100*(debuild_failures))
[03:42] <NCommander> The moment you try and censor something is the moment everyone learns about it
[03:42] <jdong> NCommander: I think you're thinking of Streisand.
[03:42] <NCommander> jdong, heh, you should have seen some of my "choice" comments with the KDE build failures
[03:42] <NCommander> jdong, right
[03:43] <NCommander> Oh well, at least we avoided Godwin's law
[03:44] <jdong> well let's try to put this shiny new iMac with faster hard drive and 4GB RAM into good use.
[03:44] <jdong> build race :)
[03:44] <NCommander> jdong, I'm working on making the PPC toolchain stop segfaulting
[03:44] <jdong> you poor thing :)
[03:44] <jdong> and I'm working while 100000000 VLC users seem to be breathing down my neck.
[03:45] <NCommander> jdong, I have a HPPA box
[03:45] <NCommander> :-)
[03:45] <jdong> :)
[03:45] <NCommander> (well access to one running Ubuntu HPPA)
[03:45] <NCommander> lamount will be happy. He found a second user
[03:45] <jdong> I bet ten bucks the moment I finish this someone will file a backports request for it.
[03:46] <NCommander> I'll take that bet
[03:46] <NCommander> what version of VLC are you backporting?
[03:46] <jdong> NCommander: hopefully 0.9.2 will be in intrepid this/next week
[03:46] <jdong> provided these lovely upstream debdiffs don't explode the LHC.
[03:47]  * NCommander files a backport request, winning ten dollars
[03:47] <jdong> for the most part, they were quite reasonable
[03:49] <jdong> ZOMGZ IT GOT TO THE CONFIGURE STAGE!
[03:49] <NCommander> Libtool failure in
[03:49] <NCommander> 3
[03:49] <NCommander> 2
[03:49] <NCommander> 1
[03:50] <coppro> FTBFS?
[03:50] <jdong> you people are jerks!
[03:50] <NCommander> :-)
[03:51] <NCommander> Its fun to watch someone else solve FTBFS instead
[03:51] <NCommander> Now I know why people ask me to do it
[03:51] <jdong> ok, looks all good
[03:51] <jdong> now it'll probably fail in the dh_install phase.
[03:51] <NCommander> segfault. come on segfault dh
[03:51]  * jdong wonders if it's evil to add -j2 during testing
[03:51] <jdong> NCommander: haha amd64's too popular to segfault
[03:52] <NCommander> jdong, try using the GCL lisp compiler
[03:52] <NCommander> Segfaults on amd64 all the time
[03:53] <jdong> should Standards-Version be bumped to 3.8.0 or whatever lintian wants it at?
[03:55] <NCommander> jdong, its somewhat pointless on Ubuntu if its going to get clobbered on a sync
[03:55] <NCommander> But I usually do it if I'm fixing lintian warnings
[03:56] <jdong> NCommander: well VLC isn't gonna be synced; though I have much more important things to worry about than quashing little lintian beefs here and there.
[03:56] <ScottK-vacation> jdong: Ubuntu policy specifically discourages bumping standards version.
[03:56] <jdong> ScottK-vacation: thanks, didn't know that
[03:57] <ScottK-vacation> See the ubuntu-policy package in Intrepid.
[03:57] <ScottK-vacation> We have one of those now.
[03:57] <NCommander> we do?
[03:57] <ScottK-vacation> Yep.
[03:57] <jdong> cool
[03:57] <ScottK-vacation> Decision to make one came at the last UDS.
[03:57]  * ScottK-vacation really goes on vacation now ...
[03:58] <NCommander> bah
[03:58] <NCommander> So much for backporting uploads
[03:58] <NCommander> jdong, we need a new core-dev :-P
[03:58] <jdong> lol hold your horses :)
[03:59] <NCommander> so your applying for core-dev ;-)
[03:59]  * superm1 breathes in jdong's general vicinity
[03:59] <jdong> haha no I'm not
[03:59] <superm1> how's VLC coming?
[03:59] <jdong> superm1: compiling
[03:59] <superm1> awesome
[04:00] <jdong> superm1: finally managed to push it past ./configure using bits of upstream packaging
[04:00] <NCommander> ok
[04:00] <NCommander> lying down for real
[04:00] <NCommander> night
[04:00] <jdong> superm1: parsing through the 3000-line change to debian/ was the most time consuming part
[04:00] <jdong> superm1: and worst part is I need to do it again tomorrow morning when less sleep deprived.
[04:00] <superm1> i knew it felt like there was some crack missing at this point in intrepid, so i'm glad you're taking this up
[04:00] <jdong> there were a few "shrug, why not" moments.
[04:01] <jdong> I don't think I got that libass thing that the one guy said twice or so in the bug report
[04:01] <jdong> I will have to go back and do that after this first test-build succeeds
[04:01] <jdong> (note the optimistic assumption I just stuck in there :D)
[04:01] <superm1> haha
[04:01] <superm1> none of these ffmpeg based players ever compile right on the first try
[04:02] <superm1> but it's good to be optimistic
[04:02] <jdong> you know, at this point I bet if it's gonna fail it's in the dh_install phase
[04:02] <jdong> 5 seconds before the build is done BOOM and everything gets rm'ed and we start from square one.
[04:02] <superm1> that's why i've learned to do things in schroot when i think it's a chance of failing
[04:02] <superm1> rather than sbuild
[04:02] <superm1> you spend another few minutes doing get-build-deps and waiting by hand
[04:02] <superm1> but it's worth it for these big builds
[04:03] <jdong> well I'm gonna just sip on coffee and wait for that
[04:03] <jdong> and catch up on course notes reading
[04:05] <jdong> haha my roommate just called me a nerd for using 3 computers :D
[04:05] <StevenK> jdong: At once?
[04:05] <jdong> StevenK: yeah
[04:06] <jdong> one for starcraft, one for course notes and IRC, one for compiling VLC
[04:06] <StevenK> Depending on how you define use, I'm using 4, now
[04:06] <jdong> the bluetooth keyboard, USB keyboard, and laptop keyboard help.
[04:51] <pythonic> hi.. su foo as root in a chroot environment requires a password.. why?
[05:17] <jdong> WHOOO FTBFS #4!
[05:29] <jdong> FTBFS #5
[05:30] <RAOF> Score!
[05:30] <RAOF> Let's see if you can break the big 1-0!
[05:31] <jdong> haha I broke down and chrooted into a pbuilder.
[05:31] <jdong> and hacked -j3 on make.
[05:31] <jdong> patience has been lost
[05:35] <RAOF> What happens when -j3 is the thing breaking the build? :)
[05:36] <jdong> RAOF: run -j3 twice then -j1 once to clean up the rest
[05:36] <jdong> RAOF: silly RAOF, I'm an ex Gentoo user :)
[05:36] <jdong> I'm a master at these hackish games of patience :)
[05:38] <RAOF> Wah?!
[05:39] <jdong> lol you've never heard that one for working around make -j* race conditions? :)
[05:40] <RAOF> Nope :)
[05:45] <jdong> obvious not a gentoo pro with strlen($CFLAGS) > 800
[05:54] <persia> Just as a general note, the buildds run with DEB_BUILD_OPTIONS="parallel=n+1", so expecting make -j1 behaviour is perhaps unsafe...
[05:54] <jdong> good to note.
[05:54] <jdong> I recall vaguely dealing with a race condition FTBFS from a year or so ago
[06:10] <Hobbsee> @schedule
[06:10] <Hobbsee> @schedule sydney
[06:10] <Hobbsee> oh, now.
[06:11] <persia> Err.  Oops.  An hour back, rather.
[06:12] <StevenK> As in, it's already been?
[06:12] <persia> Well, it wasn't, but it was scheduled.
[06:12]  * persia looks at the agenda to see if there is something that could be discussed during the second hour of the meeting
[06:12]  * TheMuso forgot that on the occasional friday, there is a MOTU meeting.
[06:13] <Hobbsee> yeah, i was fairly sure that 0400 UTC today had passed...
[06:13]  * RAOF forgot that on the occasional friday, there is a MOTU meeting that isn't at some godawful hour :)
[06:13] <StevenK> Hah
[06:14] <TheMuso> RAOF: thats actually what I meant, yes.
[06:14] <persia> Right.  No agenda.  Didn't we do this failure to have any meetings things last summer too, and all get annoyed, and decide to do something about it, getting back to regular meetings?
[06:40] <dholbach> good morning
[06:43] <iulian> Good morning Daniel.
[06:43] <dholbach> hey iulian
[07:09] <Laibsch> azeem: thanks, that indeed fixed it, it seems
[07:55] <TheMuso> 9/c
[08:27] <Adri2000> any bored motu-sru for bug #85266 ?
[08:37] <huats> morning everyone
[08:37] <Lamba> morning
[09:47] <verwilst> ping emgent
[11:44] <verwilst> hm, nspluginwrapper seems to be available for amd64 only in hardy?
[11:44] <verwilst> is that correct?
[11:44] <verwilst> on my system it's available for i386 as well, but on packages.ubuntu.com and on other systems no trace of i386 nsplugiwrapper is found
[11:44] <verwilst> only amd64
[11:48] <geser> verwilst: packages.u.c lists i386 for the version in intrepid (before it was amd64 only)
[11:48] <verwilst> geser: yeah
[11:48] <verwilst> but i have it for i386 too
[11:49] <geser> verwilst: which version?
[11:49] <verwilst> Architecture: i386 Version: 0.9.91.5-2ubuntu2.8.04.1~mt1
[11:49] <verwilst> don't know what that ~mt means though
[11:49] <verwilst> 3rd party repo? :)
[11:50] <geser> this doesn't look like a version from the offical archive
[11:50] <verwilst> then were did i get it from hehe
[11:50] <geser> what does "apt-cache policy nspluginwrapper" tell about it?
[11:50] <verwilst> mt! mozilla-team!
[11:50] <verwilst> ppa
[11:51] <verwilst> hehe :) solved
[12:35] <soren> NCommander: Do you intend to update all of xfce in the xubuntu-dev ppa to 4.5.90?
[12:49] <gnomefreak> what am i overlooking? http://pastebin.mozilla.org/539806
[12:51] <james_w> gnomefreak: the _source.changes and .dsc are from different builds at a guess
[12:53] <gnomefreak> james_w: thanks lintian on ~jjv doesnt error but on intrepid build it does ;)
[13:06] <DktrKranz> has anybody ever seen something similar to http://launchpadlibrarian.net/17761479/buildlog_ubuntu-intrepid-i386.libdebian-package-make-perl_0.04_FAILEDTOBUILD.txt.gz ? It builds fine in a pbuilder
[13:08] <gnomefreak> thanks james_w i think it has more to do with bzr bd now that i am getting into it more
[13:10] <siretart> jdong: wgrant: I think I have vlc ready for intrepid. it is currently in my ppa
[13:26] <iulian> Hi
[13:33] <jdong> siretart: lol beat me to it :) I was working on that last night
[13:34] <jdong> siretart: would you like to announce that on bug 270404?
[13:40] <siretart> jdong: I committed my tree to bzr on lp:~siretart/vlc/ubuntu, perhaps you might want to review/compare with your version?
[13:40] <siretart> jdong: anyways, I've found yet another mistake, the x264 plugin needs to go into vlc, not vlc-nox. this is fixed in the latest bzr revision
[13:41] <siretart> jdong: if you don't mind, please review that branch, and if you are confident, please upload it to ppa-motumedia and announce it on the bug calling for testers
[13:41] <siretart> jdong: as for a short test, the package works fine for me so far
[13:42] <jdong> siretart: I'll take a look at it this morning
[13:42] <siretart> jdong: what time is it for you?
[13:42] <jdong> siretart: morning :)
[13:42] <siretart> excellent :) - its afternoon (3pm) for me
[13:46] <jdong> siretart: why should x264 go into vlc instead of vlc-nox?
[13:46] <wgrant> That's my doing.
[13:47] <wgrant> It depends on libx11
[13:47] <wgrant> So it FTBFS otherwise.
[13:47] <jdong> wgrant: grumble is that because we built x264 with X11?
[13:47] <wgrant> Looks like it.
[13:47] <jdong> ok gotcha; we need that on $listofthingstotweakinsparetime
[13:47] <jdong> as x264 is useful for VLC transcoding
[13:48] <jdong> siretart: yeah yours looks pretty similar to mine plus minus some reordered build deps :)
[13:59] <_ruben> ugh .. i guess i went way over my head trying to package (for personal use initially) scst (combination of userland and kernel modules) .. time to read some more wikis and stuff
[14:07] <LucidFox> I'm seriously considering relinquishing my MOTUship in protest against the codec thing, but this will accomplish nothing anyway.
[14:07] <siretart> jdong: because our current package has that plugin in vlc already. we could move it to vlc-nox, but then we would need to add Replaces to debian/control
[14:07] <jdong> siretart: understood
[14:08] <jdong> LucidFox: "the codec thing"?
[14:08] <siretart> jdong: okay, great. will you upload to motumedia PPA or shall I do that?
[14:08] <jdong> siretart: I can do that if you wish
[14:08] <LucidFox> Ah, wait, it's not Canonical themselves going to sell codecs. False alarm.
[14:09] <jdong> LucidFox: wait a sec, what would be the issue if Canonical were to sell codecs?
[14:09] <siretart> jdong: okay, go ahead! thanks!
[14:09] <jdong> LucidFox: a lot of us, namely  the entire north american market, would love to have the option for paid-for access to legal codecs
[14:10] <LucidFox> Well, being a rabid Stallmanite, I wouldn't consider that acceptable even if I had the mistfortune to live there.
[14:10]  * siretart has noticed earlier today that our copy of ffmpeg already has support for dlopen'ing libfaad and liba52. it should work if one would include the relevant headers to the package and switch it on the confflags
[14:11] <jdong> LucidFox: not acceptable to... coexist in a world where codecs are sold? I mean, nobody's shoving this stuff down your throat, right?
[14:12] <LucidFox> Not acceptable for me to support Canonical, were it to consider such behavior acceptable - as opposed to the FSF's all-or-nothing policy.
[14:12] <siretart> LucidFox: is this a discussion about freeness of software or a discussion about obeying and/or enforcing patents?
[14:13] <jdong> seems to be like the entire "morality" of obeying patents
[14:13] <LucidFox> I consider software patents as an unacceptable phenomenon, period.
[14:14] <jdong> while I personally don't support the idea of patenting codecs the way they are now, I don't think just using their technology with blind disregard to the patents is the moral high road.
[14:14] <jdong> finding fully Free alternatives, however, would be such an alternative.
[14:14] <jdong> siretart: alright, in motumedia-ppa :)
[14:14] <LucidFox> Luckily, I have the fortune to live in a country where software patents are void.
[14:14] <jdong> at least that's where I think I uploaded it.
[14:14] <jdong> ;-)
[14:16] <siretart> jdong: yes, it seems to have landed there. now we can go calling for testers and bribe the release team to accept that package
[14:16] <jdong> haha the former sounds a lot easier :)
[14:16] <Hobbsee> mmm....beer.
[14:16] <Hobbsee> ;)
[14:16] <jdong> Hobbsee: sorry, underage :(
[14:16] <jdong> a few more months to go
[14:16] <Hobbsee> heh
[14:17] <Hobbsee> crazy country.
[14:17] <wgrant> Silly US.
[14:17] <wgrant> (although I'm underage even here...)
[14:17] <Hobbsee> besides, i'm not partial to beer, or any other kind of alcohol, anyway
[14:17] <LucidFox> I'm touchy enough that I'm going to throw away a legally bought DVD just because it contains an anvilicious intro movie about how "downloading movies is stealing". After ripping it first.
[14:17] <jdong> wgrant: no way?
[14:18] <soren> wgrant: what does that make you? 9 years old?
[14:18] <Lamba> lucid send it to me
[14:18] <Lamba> ill hate the dvd for ever for you
[14:18] <LucidFox> Lamba> What, the intro?
[14:18] <wgrant> soren: Hah. Not quite.
[14:18] <LucidFox> Or the entire video?
[14:18] <Lamba> the dvd :)
[14:18] <soren> wgrant: Perhaps the view of Australia I have in my head is ever so slightly skewed. :)
[14:19] <wgrant> soren: Heh.
[14:19] <LucidFox> No problem. Tell me your address and I'll mail you the DVD and pay the postage cost.
[14:20] <Lamba> j/k ;p i been caught by the internet dvd sending axe killer nutter too many times. :)
[14:20] <LucidFox> It's Stargate Continuum, by the way. English and Russian sound.
[14:21] <LucidFox> Lamba> Oh, what?
[14:21] <LucidFox> * Uh, what?
[14:21] <LucidFox> "the internet dvd sending axe killer nutter"? What the heck is that?
[14:21]  * wgrant kills some axes and sends DVDs of the Internets to LucidFox.
[14:22] <LucidFox> ...
[14:22] <wgrant> That's correct.
[14:23]  * LucidFox 's head explodes from trying to comprehend all this.
[14:25]  * NCommander takes the LucidFox bits and puts him back together
[14:50] <soren> NCommander: Did you see my XFCe ping earlier today?
[14:51] <NCommander> soren, no
[14:51] <NCommander> I just woke up
[14:51] <NCommander> What did I break?
[14:51] <soren> 11:35:13 < soren> NCommander: Do you intend to update all of xfce in the xubuntu-dev ppa to 4.5.90?
[14:51] <NCommander> soren, oh yes, I do
[14:51] <soren> NCommander: Fantastic.
[14:51] <NCommander> soren, I've just been a little short on time
[14:52] <soren> No worries. I know what that is like.
[14:52] <soren> brb
[14:52] <NCommander> Its first thing on the todo list tommorow
[14:57] <bddebian> Heya gang
[14:57]  * iulian is not staring at bddebian.
[14:57] <iulian> Hi bddebian :)
[14:57] <bddebian> Heh, hi iulian
[15:00] <jpds> Afternoon.
[15:03] <iulian> jpds: Hey!
[15:03] <jpds> Hey there iulian.
[15:21] <NCommander> soren, you an Xubuntu user?
[15:24] <norsetto> james_w: re. bug 272120, what do you mean by "via Debian"?
[15:25] <james_w> norsetto: upload to Debian and sync it
[15:26] <norsetto> james_w: errr, are you requesting us permission to upload to Debian!?
[15:26] <james_w> norsetto: no, to sync a package from Debian that isn't uploaded there yet
[15:27] <james_w> I need to seek a sponsor for Debian as well
[15:28] <norsetto> james_w: hmmm, did I miss any email or aren't you a motu yet?
[15:29] <james_w> norsetto: I'm not
[15:29] <norsetto> james_w: ok, I thought you got your blessing already
[15:32] <norsetto> james_w: ok, I'll give my ack as long as this doesn't drag for too long, hopefully you should get upload rights to our archive soon
[15:34] <james_w> norsetto: well, that wouldn't change the fact that this would need an FFe would it?
[15:34] <norsetto> james_w: it does, we can't assume archive admins have time to process things like sync, etc. after beta
[15:35] <soren> NCommander: Yup.
[15:36] <NCommander> soren, you should be in #xubuntu-devel :-P
[15:36] <NCommander> Were you using my 4.5.80 packages?
[15:37] <soren> NCommander: Is that where all the cool kids are?
[15:38] <NCommander> soren, its where all three of the Xubuntu developers live ;-)
[15:38] <soren> Heh
[15:38] <NCommander> we're a "little" understaffed
[15:58] <NCommander> soren, were you using my 4.5.80 packages?
[15:59] <soren> I am, yes.
[15:59] <NCommander> WOW
[15:59] <NCommander> I had a user
[15:59] <NCommander> yay
[15:59] <soren> ...only since yesterday, though :)
[15:59]  * NCommander falls over
[16:01] <jdong> AAAH NOOOOO don't rsync that!
[16:01]  * jdong remembers -x a bit better next time
[16:02] <liw> I use rsync --delete-after -axHS
[16:03] <jdong> liw: yeah but when it recurses into sysfs weird things happen :)
[16:05] <_ruben> hmm .. apparently DEB_DESTDIR=/some/path module-assistant build some-app doesnt honour the DEB_DESTDIR 'override' :/
[16:09] <liw> jdong, that is indeed why -x is good; -H and -S are also good, for other reasons
[16:11] <jdong> liw: indeed; I personally don't use -H due to the huge performance hit unless I have something that really relies on hardlinks
[16:12] <liw> I haven't found it to be a huge hit, unless there's a lot of hard links -- but if there are, then I want to keep them
[16:21]  * Adri2000 looks for a motu-sru person
[16:27] <jdong> Adri2000: mmm?
[16:28] <Adri2000> jdong: bug #85266
[16:30] <jdong> Adri2000: what motu-sru intervention is needed?
[16:30] <Adri2000> jdong: ack my .2 upload
[16:31] <Adri2000> jdong: .1 got approved etc. but norsetta found some problems with it. .2 should fix them
[16:31] <Adri2000> er, norsetto
[16:31] <jdong> Adri2000: ah, ok
[16:39] <Nutzebahn> Hello.
[16:39] <Nutzebahn> I really think that a Megatunix binary would be VERY helpful to many people, because Megatunix is the only ECU tuning program available for Linux.
[16:40] <Nutzebahn> Could someone help me with this?
[16:40] <Nutzebahn> Or make one.
[16:40] <Nutzebahn> This is quite important.
[16:42] <directhex> looks like a pretty simple package job
[16:42] <rexbron> Nutzebahn:  Start by reading this: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[16:42] <directhex> follow the ubuntu packaging guide
[16:42] <directhex> as linked by my beautiful assistant rexbron
[16:42] <csilk> Nutzebahn, yes it could be done easily
[16:42] <rexbron> directhex: rofl
[16:43] <Nutzebahn> I tried to compile it and couldn't...
[16:43] <Nutzebahn> :(
[16:43] <Nutzebahn> I don't know if anything is wrong with it...
[16:43] <Nutzebahn> But I definitely need help
[16:43] <Nutzebahn> .
[16:44] <pochu> hey hey rexbron!
[16:45] <rexbron> hey pochu
[16:45] <pochu> rexbron: are you going to California?
[16:45] <rexbron> It's in the air, UDS is in the middle of exams for me
[16:45] <rexbron> so if i get lucky, yes
[16:45] <csilk> Nutzebahn,  am i right in saying you need to run megatunix in a free partition?
[16:45] <csilk> *in its own partition
[16:46] <Nutzebahn> in it's own partition? :'(
[16:46] <Nutzebahn> Why does it need that?
[16:46] <csilk> Give me two minutes to read the manual and I'll elaborate
[16:47] <csilk> no wait, scratch that, I'm wrong
[16:47] <pochu> kirkland: hi, I've just reported 272172, I was surprised you aren't subscribed to update-motd bugs, so in case you want to know about it...
[16:47] <kirkland> pochu: doh!
[16:47] <csilk> I can package megatunix up and submit it for consideration into the repository
[16:47] <kirkland> pochu: sorry, i'll subscribe now
[16:47] <csilk> making it availabale from apt-get or install/remove programs
[16:48] <pochu> kirkland: no problem :)
[16:48] <directhex> Nutzebahn, built. like i said, an easy jobn
[16:48] <Nutzebahn> Ok, thank goodness.
[16:48] <Nutzebahn> Thank you. :)
[16:48] <csilk> I'll do it tonight
[16:48] <csilk> no worries
[16:48] <Nutzebahn> Could you send it to me after packaging it?
[16:48] <csilk> Sure thing
[16:49] <Nutzebahn> and to Ubuntu
[16:49] <directhex> Nutzebahn, i'm not making a package for you. i have less than zero desire to maintain it, and absolutely no ability to test it
[16:50] <Nutzebahn> Thank you.
[16:50] <Nutzebahn> If I could learn how to do it, I would maintain it.
[16:50] <directhex> Nutzebahn, but this is an easy package if YOU want to do it. no complex packaging at all
[16:50] <directhex> probably 3 lines with dh7
[16:50] <csilk> directhex,  I'll do it for him later
[16:51] <csilk> i dont mind testing and maintaining it
[16:51] <Nutzebahn> I couldn't even compile it, it said that it needed gtk+-2.0 and it wouldn't install that.
[16:51] <Nutzebahn> I would ike to do it and maintain it.
[16:51] <Nutzebahn> Thank you csilk.
[16:51] <directhex> Nutzebahn, aptitude install apt-file; apt-file update; apt-file search gtk+-2.0.pc
[16:51] <Nutzebahn> like*
[16:52] <Nutzebahn> directhex: The following NEW packages will be installed:
[16:52] <Nutzebahn>   apt-file libapt-pkg-perl{a} libconfig-file-perl{a}
[16:52] <Nutzebahn>   liblist-moreutils-perl{a}
[16:53] <directhex> yes, i know. that's the point. i think it's reasonable for me to assume that if you run some package installation commands, then packages will be installed
[16:54] <Nutzebahn> Ok, so it should compile now?
[16:56] <Nutzebahn> directhex: E: Can't create /var/cache/apt/apt-file: Permission denied
[17:07] <Nutzebahn> Help?
[17:08] <kirkland> pochu: hey, okay, i'm subscribed to update-motd bugs...  the packaging of this tool has changed due to some requests from cjwatson and pitti, for inclusion into main
[17:09] <kirkland> pochu: you will get that prompt again when you upgrade to 1.7, unfortunately.  after that, we should be good.
[17:09] <kirkland> pochu: cjwatson and pitti suggested that this is just something that alpha-users are going to have to cope with ;-)
[17:12] <kirkland> pochu: bug updated with a note to that effect ;-)
[17:17] <handschuh> nutzebahn: tried sudo?
[17:21] <pochu> kirkland: ah, right, it's not in hardy
[17:21] <pochu> kirkland: ok then
[17:21] <kirkland> pochu: yeah, sorry about the inconvenience
[17:22] <kirkland> pochu: i was advised against a preinst script that would maneuver around it, as being more complicated than worthy for an alpha release
[17:22] <kirkland> pochu: fwiw, it did make me squirm when I published the updates :-S
[17:23] <Nutzebahn> oops
[17:23] <Nutzebahn> :'(
[17:23] <Nutzebahn> Emnbarassing.
[17:25] <pochu> kirkland: don't worry, it's no problem to me
[17:25] <pochu> kirkland: I was just worried for hardy->intrepid upgrades, but since it's not there... :)
[17:26] <kirkland> pochu: right, not there
[17:26] <kirkland> pochu: brand new package ;-)
[17:27] <pochu> kirkland: feel free to close as won't fix if you haven't done it yet
[17:27] <pochu> when launchpad comes back ;-)
[17:27] <kirkland> pochu: k
[17:37] <crimsun> \sh: RE: ia32-libs: okay.
[17:39] <crimsun> slytherin: RE: bcm2033: see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid-lrm.git;a=tree;f=ubuntu-firmware/broadcom;h=c72df9cb589472b15528d3240a6170d9b4eeb73a;hb=HEAD
[18:47] <Nutzebahn> https://bugs.launchpad.net/ubuntu/+bug/272210
[18:55] <jdong> "I was wondering if this is still an issue or can you reproduce with a newer release?"
[18:55] <jdong> *stifles some grins*
[18:56] <jdong> must... resist....
[18:56] <jdong> lim(maturity(jdong), sleep -> 0)=0
[20:21] <fabrice_sp> Hi. I wanted to fix broken dependencies for icedove-dispmua and icedove-nostalgy, changing icedove by thunderbird. Is it acceptable to have the source package called icedove-dispmua and the binary called thunderbird-dispmua or should I left the binary called icedove-dispmua?
[20:29] <geser> fabrice_sp: should be no problem to keep the source name (easier for merging) and rename the binary. But you might want to talk to someone from the mozillateam as I don't know if there is a special policy or guidelines
[20:38] <fabrice_sp> geser: ok. I'll look for someone from the mozilla team. Thanks
[20:50] <fabrice_sp> Someone from mozillateam? asac? crimsun? fta? jazzva?
[20:52] <fta> fabrice_sp, we have no special policy about that, general rules apply
[20:52] <fta> indeed, if it's a merge from debian, it's easier to preserve the src pkg name
[20:53] <fabrice_sp> fta: that's what I think, but rename the binary package so that it's easier to find, or not?
[20:54] <fabrice_sp> (the same for icedove-nostalgy)
[20:54] <fta> would be nice, but you'll have to wait for approval from the release manager
[20:54] <fta> (it will be a NEW)
[20:55] <fta> not that it's a problem, just a little delay
[20:55] <fabrice_sp> so it's not a FFe, right?
[20:59] <fta> fabrice_sp, hold on
[21:01] <LaserJock> is there really no way to override the Ubuntu Maintainer field stuff?
[21:01] <fabrice_sp> fta: yes?
[21:01] <LaserJock> I'd like to keep an 0ubuntuX versioning *and* a non-Ubuntu Mainainer address
[21:03] <iulian> If I have a lot of files that are copyrighted by the Free Software Foundation, Inc but the years differs from file to file, can I just write the first and the last year? For example: 'Copyright (C) 1995-2003 FSF, Inc' instead of 'Copyright (C) 1995-1997, 2000-2003 FSF, Inc' ?
[21:04] <iulian> That will be written in the debian/copyright file obviously.
[21:08] <geser> LaserJock: unset $DEBEMAIL before calling dpkg-buildpackage or dpkg-source
[21:09] <geser> LaserJock: if DEBEMAIL contains @ubuntu.com it will produce an error else just a warning
[21:10] <LaserJock> geser: ah, right
[21:10] <LaserJock> forgot about that trick
[21:26] <NCommander> hola world
[21:32] <geser> Hi NCommander
[21:32] <NCommander> how goes it geser ?
[21:33] <geser> good, just got more busy the last week than expected
[21:33] <LaserJock> hmm
[21:33] <NCommander> geser, I know that feeling. What's your job?
[21:34] <LaserJock> does anybody know of a RSS feed for -changes?
[21:34] <geser> LaserJock: doesn't ubuntu-nl have some?
[21:34] <LaserJock> it seems Seveas' old feeds are no longer available
[21:34] <norsetto> hi folks
[21:34] <LaserJock> geser: I don't think so, I just checked and they're gone
[21:36] <geser> NCommander: usually I'm a student but between semesters I have a small office job
[21:37] <NCommander> Ah
[21:37] <NCommander> Same, expect office job == firefighter ;-)
[21:38] <LaserJock> ah, gmane.org has -changes
[21:39] <NCommander> hey LaserJock
[21:39] <geser> LaserJock: http://feeds.ubuntu-nl.org/IntrepidChanges
[21:41] <LaserJock> geser: well, that works except it doesn't have the entries that use the new format
[21:41] <LaserJock> I guess it's broken
[21:42] <LaserJock> I'm pretty sure ubuntu-nl.org is not a good place for those to be
[21:42] <geser> LaserJock: didn't the new format just started today?
[21:42] <LaserJock> yeah
[21:42] <LaserJock> but I believe the change has been known for several weeks
[21:43] <geser> yes, certainly. There was a mail to ubuntu-devel IIRC.
[21:44] <highvoltage> hey LaserJock and geser
[21:44] <LaserJock> in any case I'll update UbuntuDevelopment/PackageArchive
[21:44] <LaserJock> hi highvoltage
[21:46] <geser> Hi highvoltage
[21:50] <slytherin> [OT]: Can anyone having access to a windows machine help testing an application?
[21:53] <nellery> slytherin, what's the application?
[21:55] <slytherin> nellery: it is a 8085 simulator. I am cross compiling it. And a bug in wine keeps me from testing on ubuntu itself.
[23:10] <csilk> are there any rules about what cant be packaged and added to the repository?
[23:10] <jdong> csilk: Well the only thing that absolutely can't be packaged are packages with EULAs preventing redistribution by the archive mirroring system
[23:11] <csilk> Yeah sorry I didnt have my thinking hat on when asking that question.. Everything comes down to the license
[23:11] <wgrant> jdong: Licenses, not EULAs.
[23:12] <jdong> wgrant: sorry, did I use a sensitive word?
[23:12] <Laney> EULAs are distinct from licenses
[23:13] <jdong> understood.
[23:13] <Laney> EU = End User :)
[23:15] <wgrant> A mirror wouldn't be affected by a EULA.
[23:15] <wgrant> As they're not an end-user.
[23:16] <Laney> siretart, jdong: VLC seems good, btw
[23:16] <Laney> Stupid QT though ;)
[23:16] <jdong> can *.install exclude a director?
[23:16] <jdong> directory*
[23:16] <jdong> i.e. I want to install usr/share/vlc *EXCEPT* usr/share/vlc/mozilla
[23:17] <csilk> jdong, Laney by this > http://www.bluej.org/about/license.html  would you say that it is ok to distribute via the ubuntu repository or not?
[23:17] <csilk> or should I seek permission from the copyright holders first just to make absolutely sure
[23:18] <jdong> csilk: IANAL but that sounds okay for multiverse
[23:18] <Laney> "#
[23:18] <Laney> While Ubuntu will not charge license fees for this distribution, you might well want to charge to print Ubuntu CD's, or create your own customized versions of Ubuntu which you sell, and should have the freedom to do so.
[23:18] <Laney> I don't know if "non-commercial" falls foul of that
[23:18] <csilk> i think an email to the developers is in order
[23:19] <csilk> As this is a good candidate for the multiverse repository
[23:19] <Laney> csilk: Any agreement you get from them must not be Ubuntu-specific
[23:19] <blueyed> superm1: Thanks for taking care of virtualbox-ose recently. Please subscribe to bugmail though: https://launchpad.net/ubuntu/+source/virtualbox-ose/+subscribe
[23:19] <csilk> Laney,  can you elaborate?
[23:19] <superm1> blueyed, i'm watching it but i dont want all the bug mail in my box
[23:19] <superm1> i've been responding to recent bugs
[23:19] <Laney> csilk: Look at http://www.ubuntu.com/community/ubuntustory/licensing
[23:20] <Laney> It's pretty easy to understand
[23:20] <blueyed> superm1: ok. I think virtualbox-ose should depend on virtualbox-ose-source, so that the dkms part kicks in/gets used.
[23:20] <csilk> thanks
[23:21] <blueyed> superm1: JFI: I've just uploaded ubuntu3
[23:22] <superm1> blueyed, it recommends it and w/ recommends by default it should be installed
[23:22] <csilk> Laney,  From what I've read, it looks like it would have to under mulstiverse
[23:22] <csilk> *multiverse
[23:23] <Laney> csilk: Right. The non-commercial bit troubles me though, and I don't know whether it would be acceptable
[23:23] <blueyed> superm1: Do we have recommends by default now? (I've installed it using "dpkg -i")
[23:24] <blueyed> superm1: additionally, it might make sense to use the upstream's init.d script, which provides e.g. "setup" to manually recompile the module..
[23:25] <superm1> blueyed, yeah recommends are by default starting with intrepid
[23:25] <csilk> yeah i see your point but as its not installed by default I can't see a problem, I'll email the authors and see what they think, it's a commonly used piece of software among university computer science students, alot of which use ubuntu (at my university)
[23:25] <superm1> blueyed, well i would think only if that setup were re-scripted to do it with dkms. i forsee complications if both were available
[23:25] <superm1> as to which one should take precendence
[23:25] <csilk> It is a free learning tool (as in beer) but yeah, I'll seek permission first
[23:29] <superm1> blueyed, did you have any ideas on what's up with the 64 bit guestness?
[23:29] <superm1> blueyed, i tried to activate the support in every way i saw
[23:31] <blueyed> superm1: no, sorry..
[23:32] <blueyed> Does bug 271507 need any confirmation? (IIRC ubuntu-archive only processed confirmed bugs)
[23:33] <superm1> well given i wasn't part of the virtualization team, i didn't want to trump your guys' decisions on this
[23:33] <superm1> in case you didn't like the way dkms was doing things
[23:33] <nhandler> blueyed: A MOTU needs to Ack the request. Once they do, they set the status to Confirmed, and subscribe the Archive Admins
[23:34] <blueyed> nhandler: ubuntu-archive is subscribed and superm1 is MOTU. Maybe motu-sru needs to ACK?
[23:34] <blueyed> superm1: what decisions? about the vboxdrv init script? I've done this, and I'm not part of the virt team either
[23:34] <superm1> blueyed, oh i thought you were
[23:35] <superm1> blueyed, just about removing  the modules and doing things solely with DKMS
[23:35] <superm1> blueyed, since it was a signficant change
[23:35] <blueyed> Looks fine for me.. v-o-m was a big PITA
[23:35] <superm1> i'll mark it confirmed then.  an archive admin will probably touch it next week
[23:39] <blueyed> superm1: Thanks.