[00:00] 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] i'm gone [00:04] 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] sure [00:05] 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] (/me wonders if anyone will notice 17 meg of livecd space saved from tomboy, and savings in f-spot too) [00:06] directhex: [00:07] persia, point take. Sanity is a useful item, but like all good things, it must be used in moderation [00:07] 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] 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] jdong, maybe you can simply turn prevu into a pbuilder wrapper with simple sanity checks [00:08] NCommander: that is what it is at the moment [00:09] oh [00:09] As you might surmise, I don't use prevu ;-) [00:09] NCommander: it's a pbuilder with $dist-{updates,backports} main+universe+multiverse+restricted that inserts into an apt repo in sources.list [00:09] NCommander: basically a lazy one-command prevu environment for backporters [00:09] pbuilder* [00:09] heh [00:09] night everyone [00:09] 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] I just use DIST=hardy-backports pbuilder build *dsc* === Pici` is now known as Pici [00:10] persia: agreed [00:10] NCommander: prevu would be "(DIST=target_dist) prevu lp:packagename(/distro_if_not_intrepid)" [00:11] NCommander: Yes, but you're a developer. [00:11] 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] for those who are well versed in pbuilder the difference is trivial/nonvaluable [00:11] persia, oh, I know, I'd never recommend a developer use pbuilder [00:11] er [00:11] non-developer [00:11] but for the beginners and non-developers we need to make prevu even friendlier [00:11] and also be able for users to monitor their backported packages and track their status in intrepid [00:11] I dunno, the bar for prevu pretty low it seems [00:12] probably even give the ability to share debdiffs for debian/control [00:12] Granted, my mom won't be able to use it, but my mom won't know what backports are either [00:12] NCommander: telling someone to install prevu, run sudo prevu-init, then prevu packagname, then apt-get update, etc is still not trivial [00:12] NCommander: that's not an ideal answer to "how do I get the latest pidgin?" [00:13] 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] directhex: I would be very happy to see that kind of savings. :) [00:14] slangasek, it's all explained in those two wiki pages [00:14] slangasek, it's mostlt applicable to debian [00:15] 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] 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] persia, those numbers are WITH recommends (hence the silly install size quoted for banshee) [00:16] persia, but a "clean" debian lenny system has gnome-desktop-environment WITHOUT recommends [00:16] slangasek, sorry, mostly applicable to ubuntu [00:17] I'm confused. I thought Debian was recommends-by-default before Ubuntu. That d-i is special is odd. [00:17] persia, very odd, but sadly true [00:17] persia, the difference in gnome-desktop-environment's case is about a gig (!) [00:17] d-i is special because the package manager behavior changed in Debian while the Recommends were mostly crap [00:18] and joeyh/fjp didn't want to fight these one-by-one [00:18] 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] 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] pythonic: None. Upload it to Debian, and it will be automatically included when the archive is again unfrozen. [00:20] persia: i have no sponsor there.. was looking to take this route instead :-) [00:21] (as recommended by http://newpeople.debian.org/~mpalmer/debian-mentors_FAQ.html) [00:21] 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] i'm doing that too [00:21] 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] s/mini/midi/ [00:22] persia, wouldn't you recommend improving debian as the best route anyway? share the love! [00:22] 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] the package is http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=bucardo [00:23] (an asynchronous replication system for PostgreSQL) [00:23] persia: ok, thanks :-) [00:23] directhex: so, who's working on fixing libwildmidi0's recommends: ? [00:23] 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] 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] 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] 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] directhex: I guess we could move it from -bad to -worse ;P [00:25] i suspect banshee wants libgstfaad, since it supports aac as a cd ripping format [00:25] persia: how do i get an @ubuntu.com address? [00:26] maybe libgstreplaygain too. i'd need to check the source [00:26] 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] pythonic: You get an @ubuntu.com address when you become an Ubuntu member. [00:26] persia: that's fair [00:26] pythonic: Most people just work with a team to maintain the package, rather than being an individual maintainer. [00:27] jdong, speaking of backports, have you done anything about the spam to fiesty/gutsy backports trackers? [00:28] 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] slangasek: Note that wildmidi does *not* depend on fluid-soundfont-gm in the hopes of not being impossible to download. [00:28] is there a list of maintainers/teams? [00:28] slangasek, it's not THAT much work if a good dh_ script exists to track those deps for you in debian/control [00:29] persia, 145 meg on disk just for synth voices would take the piss just a bit [00:29] directhex: wow, Suse's mono deps for tomboy are /twice/ the size of Ubuntu's? [00:29] 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] directhex: That's what I thought :) [00:29] 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] as well as runtime etc [00:30] ubuntu's 80 binary packages from 1 source package might seem excessive, but it means tiny disk use by comparison [00:31] 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] o_o; === Sneaky is now known as Fagballs [00:33] well, 79 [00:33] more after the 2.0 transition [00:33] Oh. That's not so bad then [00:33] Oh crap, i'm still in here. [00:33] ... [00:33] ...eh. [00:34] The trick when having thoughts is to hold the fingers motionless :) [00:34] 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] persia: ok. i'd need to find a maintainer before i can upload the package to revu? [00:35] 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] pythonic, ^^ [00:36] That's why I encourage you to keep chasing Debian sponsorship (maybe once squeeze opens). [00:36] directhex: Sorry: was distracted whilst planning a reply :) [00:36] 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] jdong, out of curosity, when was the backporters must be MOTU rule was established? [00:38] NCommander: also at the same time (TB officialization of backports) [00:38] ah I see [00:38] 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] persia, oh, they annouced the new name for lenny+1? [00:39] NCommander: at the time I wanted to solely dedicate myself to backports work so I held off on MOTU apprenticeship [00:39] 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] yeah, I understand that :-) [00:39] persia, no, i'm not volunteering ;) [00:39] 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] NCommander: There are plenty of universe FTBFS if you just want universe uploads. [00:41] persia, true, but I think its silly to require high numbers of universe uploads if there are uploads to main [00:41] Because people who apply straight to core-dev run into the opposite problem, that they aren't an MOTU [00:41] 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] debbuntu? Thats a new one [00:42] persia: thanks for the explanation. filed bug 271956 :) [00:42] Launchpad bug 271956 in makedumpfile "Upgrade to new upstream version 1.2.9" [Undecided,New] https://launchpad.net/bugs/271956 [00:42] NCommander, as opposed to rpm dists like susehat [00:43] directhex: I'm not someone who generally promotes x vs. y unless yada is concerned. [00:43] NCommander: I don't see why those going straight to core dev need be MOTU, personally. [00:43] persia, and those who grant core-dev don't understand why they don't have MOTU [00:44] NCommander: Do you have an example of this? [00:45] persia, yes, I can find it on -devel's archives [00:46] 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] 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] 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] 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] "40MB of libraries on disk that nothing else uses" =~ "40MB of libraries in memory that aren't shared between process", e.g. [00:50] +es [00:51] 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] 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] it's a part of it, yes [00:52] so splitting java would help. hm [00:52] don't they also only test the server mode of the JVM? [00:52] where the garbage collector is more lazy? [00:53] like persia says though, the lines are less clear in java as to what can be split where [00:53] 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] jdong, -server or -Xint [00:53] although, the fact that Java libs are generally not mmap()able can't help performance [00:53] directhex: err... that doesn't sound fair [00:54] so either the one that takes a decade to JIT or the one that's interpreted bytecode? [00:55] but anyway, this is completely off topic from your discussion [00:55] 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] persia: who's "we"? as in Ubuntu with OpenJDK? [00:56] 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] 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] i.e. I didn't see them turn off the JIT to mono or force it to --aot fully. [00:59] we don't ship mint, but it looks like the shootout is using mono from some upstream tarball [00:59] "is we don't ship the crippling option" really a valid excuse for enabling it on another language? === funkyHat is now known as funkyHat|off [01:00] don't look at me, i don't run the shootout [01:00] 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] i'm just saying, we don't ship mint [01:00] (but that day is *long* past) [01:00] persia, i'd rather write an app in an afternoon than fight c for a week [01:01] uh oh full-out language wars now [01:01] serious [01:01] I really hate getting into this whole performance-of-languages shootout topic... it always gets touchy and blurry really fast... [01:01] performance IS a silly metric when you're talking about clicky gui apps though [01:01] 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] who'd notice a 20% speed drop in gedit? [01:02] Probably mousepad users. [01:02] yeah [01:02] anyone who doesn't have a fast computer [01:02] and it's probably not a 20% speed drop either. [01:02] how do you speed up apps which spend 99% of their time waiting for user input? [01:02] it's probably a 20% average drop with big spikes here and there. [01:03] directhex: by making that 1% of the time they process really fast. [01:03] 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] 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] 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] persia, you're right, of course [01:04] 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] but still it doesn't provide the basis to brush off people who are performance-conscious [01:05] 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] persia, emacs! [01:05] I feel I'm the only vim supporter over here. [01:05] I am a vim user in a pool of emac zombies. [01:05] directhex: it's not a silly metric, it's just not the only metric [01:05] * ScottK likes vim. [01:06] i'm a bare-faced liar. i'm too dumb to use vim OR emacs, and just use nano [01:06] 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] of course, going to the school where emacs was written doesn't help. [01:07] jdong: I find the amount I use emacs is directly proportional to my distance from Kenmore Square. [01:07] the emacsachusetts institute of technology? [01:11] bedtime. [01:11] slangasek: yeah, that place. [01:12] slangasek: no, the eMASSACHUSETTS Institute of TEcHNolOGY [01:12] they use the silly s/U/V/ font.... [01:14] coppro: what's wrong with your shift key? [01:14] jdong: I'm still amazed at the idea that an OS I helped produce is now the basis for Project Athena [01:14] slangasek: My shift key? It's the Caps Lock key that's the problem :P [01:14] Project Athena? [01:14] slangasek: yeah I'm psyched for the Hardy release :) [01:15] coppro: the MIT AFS/Kerberos/Linux based operating system that runs on over 90% of the public computer stations on campus [01:15] ah, cool [01:15] jdong: really? I'm waiting for Intrepid, myself [01:15] coppro: the next release of Athena due in 2 months is based off a modified Ubuntu Hardy [01:16] ah, I see [01:16] I thought you meant you were waiting for Intrepid and thought it was Hardy [01:16] coppro: nah, I'm waiting to figure out how to swap alt and meta with this fancy new input device system [01:17] xmodmap? [01:17] coppro: that doesn't work for me anymore [01:17] :( [01:21] jdong, the guy smashing up the backport bug trackers has been banned [01:21] good to hear [01:21] I'm now asking the LP status to undo the damage === NCommander is now known as MAC === MAC is now known as NCommander [01:57] hi.. i have created a package.. do i subscribe ubuntu-universe-sponsors to the "needs packaging" bug before uploading the package somewhere? [01:59] pythonic: You should upload the package to REVU. That way, Ubuntu Developers can review the package, and post comments about it. [01:59] !revu | pythonic [01:59] pythonic: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [01:59] the package needs to have an @ubuntu.org maintainer? [02:00] pythonic: The maintainer should be 'Ubuntu MOTU Developers ". I would suggest reading https://wiki.ubuntu.com/DebianMaintainerField [02:00] i see. thanks :-) [02:03] i also created this package for debian. should i have the debian-maintainer field? [02:04] it's probably a good idea, in that case [02:05] is it Debian-Maintainer or XSBC-Original-Maintainer? [02:06] 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] 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] november's ok.. (in #debian-mentors i'd be asking november in which year?) [02:13] who all does PPC porting nowadays? [02:13] (https://launchpad.net/ubuntu/+source/mplayer/2:1.0~rc2-0ubuntu15/+build/707482) [02:15] slangasek, I do some [02:15] NCommander: your compiler segfaults ^^ [02:15] Yum [02:15] ICE [02:16] Impressive [02:16] Its been awhile since I've seen a good ice [02:17] I believe TheMuso is still interested. [02:18] wow, queued 9 days? [02:18] That bad of a backlog? [02:18] er, 6 [02:20] slangasek, can you please retry the build [02:20] GCC has been updated since this build was attempted [02:20] ok, done. [02:21] (does the gcc changelog point to anything ppc-related?) [02:21] thank you my lord and master [02:21] (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] 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] instead of blaming lamont? :) [02:24] er [02:24] No hppa boxs here [02:27] 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] WOOO [02:30] FTBFS [02:30] It's still using the old GCC [02:30] WHile it seems to have built past that on my PPC [02:30] ^- sladen [02:30] er ^- slangasek [02:33] slangasek, ok, FTBFS confirmed :-P [02:35] persia, ping? [02:36] mmm [02:50] alright, now that this silly homework is done, let's make VLC happen :) [02:56] lol [03:18] Wow [03:18] Windows CE's kernel source is available under a permissive license [03:18] when did THAT happen [03:20] quick, put it in Ubuntu [03:21] already checking the license for a catch [03:21] :-) [03:21] intrepid/wince-i386 [03:21] * wgrant winces. [03:21] * NCommander also winces [03:21] That is a rather unfortnate acronym [03:22] It is. [03:22] especially if you've ever done Windwos CE coding [03:22] *Windows [03:22] I'll just leave you the first lession [03:22] There are no processes, just threads [03:22] I am fortunately blissfully ignorant of such horrors. [03:22] Now your mind can ooze [03:23] sounds safe & secure [03:23] The design actually quite interesting [03:23] the implementation [03:23] Not so much [03:24] 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] wgrant,well, if your going to play like that [03:25] 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] it's been a few years since I've done any of that, but I do recall that [03:26] ajmitch, protected mode has more fun things :-) [03:27] long mode is just bigger protected mode, although going from PM to LM is rather stupid [03:27] No processes? Owch. [03:28] RAOF, well, there are, but generally speaking, its all threads vs. processes [03:28] (i.e., no fork, no vfork, and a hell of a lot of threading) [03:28] erlang has no threads, just processes! [03:29] processes on Linux aren't heavy [03:29] Normal Windows has no fork either, odes it? [03:29] They are on Linux [03:29] wgrant, in POSIX mode it does [03:29] wgrant, but you can't (easily) call the Win32 subsystem from POSIX subsystems [03:29] Ahh. [03:29] * RAOF thinks that's probably a sanity-saver. [03:30] RAOF, no, you haven't seen the win32 replacement for fork() [03:30] CreateProcess [03:30] And its 10 inputs [03:30] four of those are structs [03:30] Which control the resulting process [03:30] Yup. Sounds like OpenFile() and it's 8 arguments. [03:30] Each of which will require you to fill in the size of the structure as a part of setup, yes. [03:30] What about the dozen variants of it? [03:31] * StevenK shivers, having done one semester of Win32 programming [03:31] 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] aahhhh [03:31] 3319 line interdiff [03:31] jdong: VLC? [03:31] wgrant: yup [03:31] * ajmitch wonders why people think that win32 programming is bad [03:31] StevenK, OpenFile() is depreiated [03:31] wgrant: just sifted through upstream's nightly packaging line by line [03:32] jdong: Ew. [03:32] ajmitch, actually, its not that bad once you get used to it [03:32] wgrant: merged what wasn't crack and fixed what was. [03:32] Oh, CreateFile() [03:32] StevenK, its now CreateFile [03:32] NCommander: OpenFileI? [03:32] Yeah [03:32] Ah. [03:32] No [03:32] Every function has an A and a U version [03:32] for Unicode [03:32] Ahh. [03:32] s/U/W/g [03:32] (wide) [03:32] * ajmitch was about to say... [03:32] Normally you can forget about that unless your doing COM objects [03:32] 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] Since just getting it to deal with Unicode is too hard [03:32] COM objects have to use Unicode APIs [03:33] RAOF: at least the API is comparatively stable across versions [03:33] 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] ajmitch: Indeed. That could be said to be it's major defining feature. [03:33] "We're ABI compatible until the end of time" [03:33] and the major drawback, in a sense [03:33] NCommander: And yet, you said "actually, its not that bad once you get used to it" [03:34] StevenK, your talking to someone who codes in Ada [03:34] * StevenK twitches [03:34] My tolerances for pain outstrip most peoples [03:34] Hell, my hack o meter is desenstized to the point that I don't even flinch on some bad hacks [03:34] While we're on API suckage, could someone kindly make GTK theadsafe? Kthxbye. [03:35] Generally speaking, COM is wonderful in some ways [03:35] Total fail in others [03:35] COM is what COBRA SHOULD have been [03:35] No. CORBA shouldn't *be*. [03:35] yay for design-by-committee [03:35] * NCommander has used cobra [03:35] :-) [03:36] Its like a poorly implemented COM [03:36] About the only good thing is its standardized so if you have a COBRA client, it (usually) works with any cobra server [03:38] RAOF: how many threadsafe GUI toolkits are there? [03:38] jdong: I don't know, nor do I care. [03:38] :) [03:38] jdong: I'd like GTK to be among their number! [03:38] good answer. I think the answer is zero though :D [03:38] jdong, Qt [03:38] QT isn't theadsafe? [03:39] NCommander: is it thread safe? [03:39] Hah, NCommander beats me to it :) [03:39] With some limitations, yes [03:39] WIn32 is actually as well [03:39] *with some limitations*? [03:39] jdong, some of the database APIs aren't [03:39] Remember, QT isn't just GUI [03:39] But last I checked, almost all of the GUI functions are thread safe with the exception of qt_init() or equivelent ;-) [03:40] (you can only init the library once) [03:40] It's _everything_ :). [03:40] My grip with Qt is it intergrates poorly with everything [03:40] I never mind running a GTK app in KDE [03:40] But I wince when I have to run a Qt/KDE app in GNOME/Xfce [03:40] Because it is its own network, I/O, html, sound, video, GUI, IPC stack? [03:41] GTK has quite a bit of that [03:41] But when I use a GTK app, I don't usaully realize it [03:41] Since GTK blends in with most enviornments (i.e., Motif) [03:41] ok, hopefully nobody reads the bzr logs of my internal VLC branch [03:41] 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] stransborn(sp) effect [03:42] CoC-friendliness = k/((pbuilder_build_failures)^100*(debuild_failures)) [03:42] The moment you try and censor something is the moment everyone learns about it [03:42] NCommander: I think you're thinking of Streisand. [03:42] jdong, heh, you should have seen some of my "choice" comments with the KDE build failures [03:42] jdong, right [03:43] Oh well, at least we avoided Godwin's law [03:44] well let's try to put this shiny new iMac with faster hard drive and 4GB RAM into good use. [03:44] build race :) [03:44] jdong, I'm working on making the PPC toolchain stop segfaulting [03:44] you poor thing :) [03:44] and I'm working while 100000000 VLC users seem to be breathing down my neck. [03:45] jdong, I have a HPPA box [03:45] :-) [03:45] :) [03:45] (well access to one running Ubuntu HPPA) [03:45] lamount will be happy. He found a second user [03:45] I bet ten bucks the moment I finish this someone will file a backports request for it. [03:46] I'll take that bet [03:46] what version of VLC are you backporting? [03:46] NCommander: hopefully 0.9.2 will be in intrepid this/next week [03:46] provided these lovely upstream debdiffs don't explode the LHC. [03:47] * NCommander files a backport request, winning ten dollars [03:47] for the most part, they were quite reasonable [03:49] ZOMGZ IT GOT TO THE CONFIGURE STAGE! [03:49] Libtool failure in [03:49] 3 [03:49] 2 [03:49] 1 [03:50] FTBFS? [03:50]