[00:15] Where's the source for ubuntu-dev-tools? It says "XS-Vcs-Bzr: https://launchpad.net/ubuntu-dev-tools/", but that's not a branch. [00:16] there are several branches. [00:16] blueyed: https://code.edge.launchpad.net/ubuntu-dev-tools/ [00:16] https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk [00:16] look under the Code tag [00:16] tab* [00:17] blueyed: That is a branch. [00:17] blueyed: and as Fujitsu said, if you branch that URL you will get the trunk. [00:17] Fujitsu: "bzr: ERROR: Not a branch: https://launchpad.net/ubuntu-dev-tools/" [00:18] blueyed: That's very off. [00:18] And I've only looked for the Code tab at https://edge.launchpad.net/ubuntu/+source/ubuntu-dev-tools. Thanks everybody.. :) [00:18] *odd [00:19] No revision control details recorded for trunk. [00:19] hmm is trunk set as the trunk? :D [00:19] LaserJock: you could also use prism, to handle gmail just like an app. One for you and one for your wife. [00:20] LaserJock: http://labs.mozilla.com/2007/11/prism-prototype-now-available-on-mac-and-linux/ [00:21] jdong: Now it is. [00:21] But the point is still valid, that the Vcs-Bzr field is wrong, isn't it? [00:21] Fujitsu: nicely done [00:21] blueyed: Try again. [00:21] blueyed: it works now [00:21] I think it should be OK now. [00:21] blueyed: it was an oversight on the product's configuration in LP [00:21] jdong: They're projects now. [00:21] yes, it works. Thanks. [00:22] Fujitsu: lol stupid nomenclature [00:23] projects, products.... blah. [00:41] blueyed: yeah I did think about that [00:53] Fujitsu: you did the upstream watch script right? [00:53] LaserJock: Yes. [00:54] Fujitsu: I was just thinking that Daniel Liedert wrote a perl script for Debichem to do a weekly watch file check [00:54] LaserJock: pong [00:54] not sure if you'd find that interesting or not [00:54] persia: hi, how did the session go? [00:54] LaserJock: Well, I stole the majority of the code from Debian. [00:54] crimsun: I like pulseaudio by default, but please make it easy for jack to not use pulse. [00:54] Fujitsu: alright, I just thought about it when I saw the weekly report for Debichem [00:55] LaserJock: quiet in the beginning, and very exciting at the end. Unfortunately, we didn't fix any bugs, but we did get good triage for two of the three we examined. [00:56] great [00:56] how long did it go/ [00:56] ? [00:56] LaserJock: About two hours [00:57] that's what I was guessing [00:57] I know I can never get anywhere in 1 hr [00:58] Actually, we finished triage on one bug in an hour (which I think it about normal). And the other two were only ~30 minutes each (but in neither case did we find the actual problem: one was against the wrong package, and the other was very confusing code). [01:06] persia: pasuspend work is higher priority for me than repromoting jack-audio-connection-kit into Ubuntu main. [01:08] \sh_away: haha. [01:08] crimsun: I'm not sure jack belongs in main until ffado (freebob replacement) is more stable. On the other hand, I use jack (as do others), so I want to make sure that calling `jackd -dalsa -dhw:0` (or similar) won't get trapped by pulseaudio. (whereas, I'd expect "default" to go into pulse). [01:10] So, pcm.default -> pcm.pulse but pcm.hw wouldn't be trapped. [01:12] persia: I don't intend to push "pulse alsa-lib plugin enabled via soundrc" onto users. [01:12] asoundrc* [01:12] crimsun: Ah. Nevermind then. I misunderstood. [01:13] I outlined in #ubuntu+1 the more conservative approach of polling users to see if a significant userbase on the forums, mailing lists, and irc end up using pcm.pulse, and if so, some hackery will be done to enable that. [01:14] * persia reads logs [01:14] if that, in fact, is the case, we can begin to whitelist apps to pasuspend, like jackd and/or qjackctl [01:14] (skype being another) [01:15] crimsun: A whitelist sounds like the solution I sought: you're way ahead of me. === pschulz01_away is now known as pschulz01 === apachelogger is now known as hsitter [01:24] * pkern is getting sick of LP. My other clearsigned email without attachments was ignored, too. === hsitter is now known as apachelogger [01:29] pkern: Are you sending it from a registered email address? [01:30] (attachments will just get dropped - the message will be unaffected) [01:32] pkern@ubuntu.com... [01:32] Which is of course not added... Gah. [01:33] Maybe another one will work... [01:35] pkern: You might try just adding it. Mine didn't work for a very long time until I told LP about it. [01:35] Is `sending it from a registered email address' talking about envelope-from or the from header? [01:36] If it forces me to fake my envelope from that would suck. [01:36] Well now it worked, thank you Fujitsu. [01:36] Yay for the build log in the description. [01:39] I think it's "From:" header. [01:43] It's the From header. [01:44] Now I also get request failures, fine. [01:46] pkern: You need to sign messages if they're changing things. [01:47] Fujitsu: I do now clearsign them, albeit I would normally use PGP/MIME. [01:47] Filing seems to work now. [01:49] * pkern passed some rebuilding to his desktop machine this afternoon (http://ka.philkern.de:9998/dist/hardy/arch/i386) [02:04] OOo seems to crash for me and I've been searching bugs and I don't see it [02:04] how can I tell which repo a package was installed from? [02:04] "seems to crash"? how does it look? [02:05] it dumps core [02:06] danielb@frodo:~$ ooffice [02:06] Bus error (core dumped) [02:06] ** (process:9746): WARNING **: Unknown error forking main binary / abnormal early exit ... [02:06] 2.3 is the version in gutsy, right? [02:06] !info openoffice.org [02:06] openoffice.org: OpenOffice.org Office suite. In component main, is optional. Version 1:2.3.0-1ubuntu5 (gutsy), package size 4 kB, installed size 44 kB [02:10] pkern: Oh dear. You're putting the entire build log in the description? [02:10] Can't you link to it or something? [02:11] Fujitsu: I would have made an attachment, and no I can't, yet. [02:12] But you see... LP would discard attachments. [02:12] pkern: You might want to look at python-launchpad-bugs. Also, attachments are never allowed in the first entry: only in comments. [02:13] LP is useless, right. But what is often done is sticking a link in the description. [02:13] persia: Apport does this sort of thing well, but it is black proprietary specific LP magic. [02:13] Fujitsu: ACK. [02:14] Fujitsu: So just copying the apport code isn't sufficient? [02:14] persia: I think the LP implementation is currently apport-specific, but I'll check. [02:15] Er, why is there a Fedora backend implementation in Apport!? [02:16] Fujitsu: Why not? Should apport be distro-specific? [02:16] I hadn't heard anything about it being used elsewhere, and would have thought there would have been a lot of NIH associated with it. [02:18] Hm, looks like the blob storage capability might actually be usable by everyone, just not documented anywhere. [02:18] Fujitsu: regarding NIH, you're forgetting the master plan :) [02:19] persia: Which master plan? [02:19] For blob storage, I thought I remember it being general: it's just undocumented. [02:19] Fujitsu: Good point. The LP takes over the world master plan. [02:19] Ah. [02:20] Right, using python-launchpad-bugs you upload a MIME blob (with an inline component being appended to the description, and attachments being attached), and get the URL back. Why isn't this documented anywhere? [03:06] persia: thanks [03:18] I have just made an Ubuntu package for multiget (to fix bug #163276) and I would like to find a sponsor to check it and help me uploading to ubuntu repository [03:18] Launchpad bug 163276 in ubuntu "[needs-packaging]multiget " [Wishlist,Triaged] https://launchpad.net/bugs/163276 [03:20] multiget is a GUI-based multi-thread downloader with publish support. a good replacement for the broken d4x [03:20] and I would really like to see multiget to be the default mass downloader in ubuntu desktop [03:21] codemaste1: Thanks for your package. The next REVU day starts in just short of 7 hours, so this tends to be a quiet time for REVU. I'd suggest you get the package in for hardy, and write a spec to make it default for hardy+1: fast transitions are hard to manage smoothly. [03:22] persia, are you willing to sponser multiget? If so, may I email the package to you? [03:23] codemaste1: I have no idea if I'm willing to sponsor yet. If it's on REVU, there's a good chance I'll review it during REVU day. If it already has an advocate when I review it, and I don't encounter any issues, I may well sponsor (but it's a very rare package for which I don't encounter issues). [03:23] pfft REVU ;-P [03:23] persia: You're supposed to be fixing scorched3d ;-P [03:24] how can I put my package onto REVU? [03:24] I already have an account on launchpad.net although I am not yet a member of any teams. [03:25] bddebian: That's currently 4th on my list (which is why I'm not REVUing now). [03:25] heh [03:26] codemaste1: You'll need to join the contributors team. See https://wiki.ubuntu.com/MOTU/Packages/REVU for details, and more generally, look at https://wiki.ubuntu.com/MOTU/Contributing for some guidelines on making sure your package gets through REVU smoothly. [03:27] * persia quivers in fear [03:27] Mez: are you actually here? [03:28] persia: now fix the soundfonts bug :) [03:29] * Fujitsu cowers in the corner. [03:29] Hobbsee: Is that still bug #45852, or did you make a new one? I can't find it. [03:29] Launchpad bug 45852 in baltix "Default Ubuntu desktop can't play midi files (not Kubuntu)" [Medium,Confirmed] https://launchpad.net/bugs/45852 [03:29] persia: havent made a new one [03:29] * jdong tries to figure out what he did now [03:30] aww poor guy [03:31] Haha. [03:31] ban didnt work, i see. [03:31] Mez is special [03:31] HAHAHA [03:32] Hobbsee: probably work better if you do him by ircname [03:32] jdong: there's a thought. [03:32] odd. [03:33] weird, it worked on -devel [03:33] Hm, might he have the ban-evasion level here? [03:33] Hobbsee: seems like he is identifying after a few channels are joined [03:34] i.e. his client's flaking/flooding :) [03:47] anyone alive i have a question of lintian error [03:47] W: iceape source: binary-nmu-debian-revision-in-source 1.1.6-1ubuntu0.7.10 [03:48] the source package seems to be correct, maybe i should drop debian's -1 since i didnt get anything from debian [03:48] The version number of your source package ends in +b and a number or [03:48] N: has a Debian revision containing three parts. [03:48] is the really confusing part or warning [03:49] gnomefreak: Are you based on Debian 1.1.6-1 ? [03:49] persia: not really i stopped geting stuff from debian a long time ago since mine is normall done first [03:50] but i did it for 1.1.5-1 still not using debian at all [03:50] where is the developers refference guide? it gives me a section on it [03:51] jdong: indeed. [03:53] gnomefreak: Well, the revision number looks sane, although I think I'd prefer 1.1.6-0ubuntu0.1 for gutsy-proposed, and 1.1.6-2ubuntu1 for an upload to hardy if you are using Debian input, or 1.1.6-0ubuntu1 if you are not using Debian input. I suggest the former: even if you don't use the patches, processing as a merge keeps it from showing on the merge list. [03:54] persia: will that get rid of the warning above about binaries? [03:54] * persia looks at lintian === _czessi is now known as Czessi [03:56] persia: http://revu.tauware.de/revu1-incoming/iceape-0711172100/lintian [03:57] gnomefreak: coincidentally, yes. The check is to see if there are two '.' characters in the revision number. My suggestion would still trigger it for something like 1.1.6-2.1ubuntu3.2 (2nd SRU of 3rd Ubuntu revision from 1st NMU of 2nd Debian revision). [03:57] last time i got that was with sunbird but was due to wrong orig.tar.gz name i used - instead of _ [03:58] gnomefreak: The critical part is whether the revision matches the regex /^-[^.-]+\.[^.-]+\./ [03:58] persia: not sure what you mean name it iceape_1.1.6-1ubuntu1.7.10 [03:59] gnomefreak: Don't use foo.7.10 and you don't get so many '.' characters, so it doesn't complain. [04:00] than how would i name it for gutsy? atm 1.1.5-1ubuntu1.7.10 is in gutsy atm i dont remember getting errors on it [04:00] persia: the .7.10 versioning seems to be used quite a bit by asac [04:00] Also, I'd recommend 1.1.6-0ubuntu0.1 meaning initial Ubuntu packaging (not from Debian) with initial upload for SRU (not previously released). That way, 1.1.6-0ubuntu1 is larger, so upgrades to hardy go smoothly. [04:00] LaserJock: True, but it triggers lintian. Doesn't really matter. [04:00] iceape wont upgrade to hardy we are using seamonkey in hardy [04:01] gnomefreak: OK. What happens for users that have iceape installed? Will there not be a transition package? [04:02] persia: we might try to get an upgrade for them but this was against my opinion i wanted to keep iceape until sm2 was released but my thought didnt matter i guess [04:03] gnomefreak: I don't know the history, but my opinion is that if there is an iceape package released in 7.10 or 6.06, hardy needs an "iceape" package. This "iceape" is permitted to be a meta-package depending on something else, but not having anything named "iceape" means users lose support silently. [04:05] persia: again i was against the change but i already spoke up but since the paid maintainer gets final say [04:06] gnomefreak: I'm not sure it matters if people get paid or not. There's no reason there can't be a universe transition package to support a broken upgrade path. You might also want to touch someone in QA. [04:06] persia: we might make it like that but that is not my concern atm [04:07] gnomefreak: OK. If you just want to shut lintian up, use less '.' characters in your version. [04:07] or ignore lintian [04:07] Right. [04:07] less ther eis only one - [04:07] Or complain about MOTU. [04:07] Oh, wait. [04:07] haha [04:08] so taht isnt something that will stop it from being pushed? [04:08] s/taht/that [04:08] gnomefreak: Not likely, if it's a good SRU. There's lots of packages that use that versioning scheme. The larger issue is that new upstream versions require special exceptions for SRU. [04:10] * Fujitsu wonders why this isn't having patches backportee. [04:10] *backported [04:11] Oh, Mozilla. Right. [04:11] Run away! [04:11] heh [04:12] anybody know if you can just dump a git branch on a web host like you can with bzr? [04:12] Rule 4 for keeping jdong happy: Things should build within an hour on a core 2 duo :) [04:12] LaserJock: I'm pretty sure git can't be served over http? [04:13] LaserJock: I believe you can: it's just files. [04:13] well i gave him links so maybe ill get lucky and get them pushed (none of my packages in last month or 2 have been uploaded since noone ever has time to do it and alot of motus are scared of mozilla and dont test it IMHO [04:13] LaserJock: never mind, it works [04:14] it's just really mean to do because it's slower than bzr 0.11 *ducks* [04:14] right [04:14] LaserJock: http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt might be interesting... [04:14] Dear. [04:15] jdong: Is that possible? [04:15] Fujitsu: it's an extremely talented achievement, but can be done if Linus puts his mind to it! [04:16] slower than bzr? [04:17] hah [04:20] LaserJock: yes, it is possible to just dump a git branch on a web host. i've done it [04:21] just remember to chmod +x .git/hooks/post-update, and when cloning, use path to .git directory rather than the working directory [04:24] dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address [04:24] dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address [04:24] *SNIFF* [04:24] do the buildd's perform the above check? [04:25] jdong: No. [04:25] backporting mplayer from Hardy -> Feisty, and pdebuild pukes on that [04:25] unset DEBMAIL [04:25] Hmm.. schroot seems to have lost my hardy chroot. It appears in lvs output, but doesn't show in /dev/data00/ Anyone have a pointer to something to check? [04:25] persia: Are there any broken snapshots of it? [04:25] Fujitsu: Yes, one. [04:26] persia: Try removing it, and if it doesn't come back `lvchange -a y' it. [04:27] Fujitsu: Thanks. Now, why would a broken snapshot cause the source to be hidden? [04:28] persia: It may decide that it's better not render the snapshot useless. [04:28] Was the snapshot full? [04:29] Fujitsu: likely. It was my working area for testing hardy, and I kept not syncing, while installing lots of packages. I should probably have created another real chroot for that. [04:29] Fujitsu: they don't? [04:30] Hobbsee: They don't what? [04:31] [15:24] do the buildd's perform the above check? [04:31] [15:25] jdong: No. [04:31] * Hobbsee thought htey did. [04:31] or maybe they turned that off. [04:31] Hobbsee: They don't die if you don't comply. [04:31] ahhh [04:31] Hobbsee: They do mangle the maintainer for the binary packages though. [04:31] ah right. [04:31] persia: That would be it, though I thought the kernel would mark the snapshot as broken and useless by default. [04:31] * Hobbsee notes that that's really...non-sense making? [04:31] it's a warning though? [04:32] LaserJock: on Feisty it's a hard abort [04:32] yeah, it's a warning [04:32] LaserJock: No, it kills the debuild locally. [04:32] it's a warning on the buildds, but kills locally? [04:32] Hobbsee: Every binary has an Ubuntu maintainer, as it's Ubuntu built, and Ubuntu originated. We don't mangle source inputs, as that's too much work, but we are supposed to change them for compile. There's still some packages that haven't been touched in ages that don't comply with the Debian Maintainer Field check. [04:33] persia: which then got rebuilt in gutsy, i thought [04:33] Fujitsu: It probably should have done so: I wonder why it let me get away with it for so long. [04:33] Hobbsee: No, in gutsy I identified a few hundred packages that failed the test, and didn't see enough changelog entries to indicate they were all fixed. I haven't run tests for hardy yet. [04:33] ahh [04:34] persia: pitti ran through the remaining modified sources in late Gutsy, updating the maintainer field. [04:34] maybe it was all the packages that we touched somewhere along the point [04:34] yeah, modified would be it [04:34] Fujitsu: All of them? [04:34] persia: As far as I know. [04:36] Maybe everything in main. I still see 312 binary packages that don't comply in hardy today. Looking for source packages now... [04:37] I saw some universe ones. [04:37] 285 source packages in main don't meet the test. [04:37] and how many of those are changed by ubuntu at all? [04:37] Err.. Nevermind. I'm testing the wrong thing. Let me rerun... [04:38] OK. for hardy/i386 102 source packages in main and 258 source packages in universe don't have *ubuntu* in the maintainer field and do have *ubuntu* in the version field. [04:39] (right now) [04:39] weird [04:39] Hobbsee: Work in progress. [04:39] must be [04:40] persia: can you tell if those are just old packages that havent' been uploaded recently? [04:41] LaserJock: Not with my current script: I'd need to extract more. [04:41] Further, I don't consider it a big issue at this point in the cycle: after DIF, I'd consider them all targets for update, regardless of whether they are new or old. [04:44] * Fujitsu convinces LaserJock to do some security stuff. [04:44] Fujitsu: Do you think http://people.ubuntu.com/~kees/ubuntu-cve/unfixed.html should be listed as a QA target? [04:44] * Hobbsee convinces Fujitsu to fix the world. [04:47] persia: persia You mean ~pitti? [04:47] Oops. [04:47] I can't see that under ~kees... [04:47] Fujitsu: This is part of why I ask: I don't know which is correct, and don't want to push the wrong place. [04:47] persia: ~pitti is the authoritative branch. [04:48] Fujitsu: OK. I'll add a link to http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html then. Thanks. [04:48] (I've gone through almost 100 CVEs from that tracker over the past couple of days working out what is actually needed where) [04:48] Fujitsu: which tracker? [04:48] persia: ubuntu-cve. [04:48] (see ~pitti/bzr/ubuntu-cve) [04:49] persia: the "unfixed.html" stuff is out of date (since Sep) [04:49] Aha. [04:49] I'll be providing some new stuff to replace it next week (I'm hoping) [04:49] Hi keescook. [04:50] hiya! (just passing through before dinner...) [04:50] keescook: Isn't it a bit late for dinner? [04:50] keescook: Ah. Great. I'll wait then. Please ping me when there's a nice external interface to a list of things that need doing, and I'll add it to the QA list. [04:50] Fujitsu: what are you wanting me to do? :-) [04:50] persia: okay, sounds good. I really should have something by Tue or so [04:50] LaserJock: Erm, work through the 998 or so open universe CVEs. [04:51] ah [04:51] keescook: No big rush: I'd rather good than fast. It's still a couple weeks before mass-publicity for the QA stuff. [04:51] Fujitsu: I'll put it on my list ;-) [04:51] keescook: Is there a timeframe for moving that branch to LP? [04:52] I have a dissertation to do, colloquia presentation on Tuesday to start, gcompris merge to do, then maybe we'll see [04:52] LaserJock: Ouch. [04:52] plus it's my birthday tomorrow :-) [04:52] LaserJock: define tomorrow? [04:52] * persia takes advantage of timezone skew to wish LaserJock happy birthday today. [04:52] * Fujitsu wraps up a block of CVEs for LaserJock. [04:52] okay, happy birthday then! [04:52] 18th, today for you [04:52] persia: me too :) [04:53] Slightly preemptive happy birthday! [04:58] do we have any automagical tool for detecting when the API/ABI of a library changes? [05:00] that'd be interesting [05:00] how would you tell? [05:00] jdong: Not really. It's supposed to be linked to SONAME, but not every upstream complies. [05:00] LaserJock: You could export the symbol map from the library, and check for significant changes. [05:00] LaserJock: so far it's been an exaustive try every reverse-depped package thrrouhg all usecases [05:01] LaserJock: I was wondering at least for C library API's if we can scan through their header files for prototype differences [05:01] persia: can API/ABI be easily be unintentially broken? [05:01] I was wondering how developers know [05:01] jdong: At a simple level (read backports), the binary package name is supposed to be updated when the API/ABI changes to support transitions. [05:01] LaserJock: Yes: just add a new function, or change a function prototype. [05:02] persia: in practice how often is that done though? [05:02] persia: I recall a libgpod update not bumping solib but causing its rdepends to segfault 2 release cycles ago [05:02] persia: I used to assume that same package name = still compatible... [05:02] persia: a new function would count? or changing an existing function? [05:02] jdong: I've only seen about 5 cases where it wasn't for normal shared libraries. Private libraries using wrappers are different. [05:03] LaserJock: Both are changes, but only the change is incompatible. ABI can also change due to changes in the build tools. [05:04] Err. That doesn't parse. Adding a new function makes a different API/ABI, but it can be a compatible API/ABI. [05:04] Changing a function definition usually results in an incompatible API. [05:04] persia: what results in incompatible ABI for C/C++ libraries? [05:04] apart from build tools [05:05] persia: ahh, so when you have an incompatible API/ABI you should change the SONAME [05:05] jdong: Ignoring build tools, it has to do with how the symbols are exported. If a symbol name changes, or the same name does a different thing, that's incompatible. If there are just more symbols, that's compatible. [05:05] LaserJock: exactly. [05:05] (symbols disappearing is also incompatible) [05:05] persia: ok, cool, that's good to know. Wow today was an educational day :) [05:06] persia: so what are symbols again? [05:07] jdong: Just to make it more fun, when the ABI changes, but the API is stable, a backport should just work. If the API changes, the backport should FTBFS. [05:07] the list of function? [05:07] LaserJock: functions, constants, etc. Things that the library exports. [05:07] ah, so lots of stuff [05:07] k [05:08] persia: so if I were bold enough to attempt/evaluate a library backport, what would be a good procedure to assessing compatibility? [05:08] I'm guessing at least a before/after symbol dump [05:08] possibly recompiling all the reverse deps if it seems like symbols got removed? [05:08] LaserJock: Right. Everything that the client application might want to use. Internal implementations are different. That's part of why it's a bad idea to write code that works but doesn't match the published public headers: there's no guarantee that it will keep working, even for a "stable" ABI. [05:09] jdong: before/after dump with analysis should be enough. If there is a change, all rdepends need a recompile. [05:10] jdong: Remember, you don't just want to make sure the symbols have the same name, but that they mean the same thing. If the semantics change, the clients may need recompile or porting. [05:10] Err. "...want to just make sure..." [05:11] persia: sounds logical [05:11] jdong: On another note, why would you want a library backport? [05:11] I've been thinking about doing one [05:12] but it's got a lot more deps than I want to take care of [05:12] LaserJock: Why? What new fancy feature does a library provide that would be user-visible? [05:12] umm, because the app I want to backport needs newer libs [05:12] persia: usually it would only be for pulling in a backport that requires a newer library [05:13] persia: for pairs like libtorrent/rtorrent where the latter is the only rdep of the former, I usually just let it slide if it's backported in a pair [05:13] I want gchemutils and it requires at least the goffice/openbabel versions in gutsy [05:13] OK. If an app being backported requires newer libraries, that's almost certainly a case of ABI incompatibility. Hardly even need to check. [05:14] persia: would a newer library release that only adds new symbols cause ABI incompatibility? [05:14] jdong: Where there's only one client, that makes sense. [05:15] jdong: If it's only adding symbols it can be compatible: I guess I'm thinking of the case where the client wants a new package name, and not the case where it just needs a newer version with the same package name. Nevermind. [05:15] persia: yeah, I know, the have different SONAMEs and now in Debian new package names so we can have multiple versions of goffice [05:16] that's why I'm not eager to backport it [05:26] anybody know if there is a way to do like an apt-get autoclean for pbuilder apt caches? [05:26] other than rm? [05:27] yeah, I want like autoclean [05:27] so look at what pbuilder would actually use [05:27] not pbuilder clean though? [05:28] LaserJock: how do you know what pbuilder would actually use? [05:28] from the current pbuilders apt caches [05:28] LaserJock: probably your best bet is to use python or something to look for duplicate package names, then delete the older one [05:28] LaserJock: autoclean simply removes files not referenced in any of your package lists, which would be essentially the same thing [05:29] yeah, although if I have a dapper, gutsy, and hardy pbuilders [05:29] oh [05:29] right [05:29] that's a lot more complex then [05:29] maybe I shouldn't worry about that case [05:29] Does anyone have a good suggestion for how to submit a sponsorable diff for a bug when it requires modification of a binary file? (native package) [05:29] I think some creative use of madison ;-) [05:29] hmm [05:30] persia: :-/ I've always just submitted the entire source package [05:30] jdong: As a sponsor, I don't like to receive that, but I can see the point. [05:30] if it's a single file I'd take just the file [05:30] persia: well a debdiff cannot represent the change... I guess there's otherways you can coordinate [05:31] this seems like a good one-case exception to receive an entire soruce package with explanation of what changed [05:32] LaserJock: There's actually a bunch of other changes as well. Essentially, this package has tar.gz files for test cases for the test rule, and the test cases need to be altered to match the source changes. [05:32] I would probably just do the whole source package [05:32] persia: "uencode it" is coming to mind. but, i dont know. [05:32] persia: wow, that'd be a pain to review :( [05:32] jdong: Perhaps you're right. I'll try it that way, although I'll also add the patches to make my sponsor's life easy. [05:32] kinda hard to review a binary blob [05:33] Hobbsee: Were it not native, I'd agree with uuencode. In this case, it's a tar.gz in a native package, and uudecoding in debian/rules just seems needless cruft. Since the package gets tar.gz'd anyway, I'm not sure why the author tar.gz'd the test cases. [05:34] persia: it does seem like a foolish decision of upstream to package this way [05:34] jdong: Native - no upstream :) [05:34] persia: can't you slap the guy to repackage his source then? [05:35] jdong: No. He's busy doing lots of other things I want to see done. [05:35] ah [05:39] persia: what package? [05:40] LaserJock: I won't mention it, as I don't want to shame the maintainer. [05:44] please tell me it's not enigmail [05:44] or something mozilla-related. [05:44] they like doing crack like that. [05:44] Mozilla does all sorts of crack. [05:45] Mozilla is crack. I want more. [05:55] dang it, I hate it when printing just stops working [05:59] LaserJock: you have no right to complain about printing to me! [05:59] sorry [05:59] LaserJock: you don't have to deal with kerberos authenticated lpr printers! [05:59] I just always find it weird with things *did* work and just mysteriously stop [05:59] :) [06:05] LaserJock: It's what printers do. Their primary function isn't to put ink/toner on dead trees, it's to fail mysteriously and make you spend half a day fixing them [06:17] hum. blender be broken. [06:18] Hobbsee: Generally :) [06:18] * Hobbsee does not like blender broken [06:19] oh, it's hte desktop effects stuff [06:21] persia: i take it your a blender hater? [06:22] Hobbsee: I'd like to like it, but I find that my AutoCAD knowledge translates poorly, the interface is annoying, and the documentation is weak. Further, it just hasn't run ~ 40% of the times I've tried it (not that my system is known for stability or anything) [06:22] I'd try blender, but I have nothing to draw [06:23] persia: yeah....the documentation is crap [06:23] it's not so bad once you actually learn it though - it's the learning part that's the problem! [06:23] works fine on kubuntu. falls over on ubuntu [06:24] Hobbsee: If it weren't for the crashing part, I suspect I'd agree with you :) [06:24] My brother got a bit annoyed that he can't run Blender and Compiz at the same and edit the massive models he often does. [06:24] appears to b ea dri problem [06:26] Hobbsee: More specifically, it's a problem with the GUI architecture, we've four different layers, and each application targets differently. As a result, it's really hard for the rendering drivers to do the right thing. [06:27] tasty. [06:28] Same problem as for sound, but at least sound is getting sane: we should be down to three layers soon, and lots of people are looking for a good solution. With visuals, it's still a matter of each app on their own, although compiz may help with this over time. [06:38] persia: why would a package have 2 soname versions? [06:38]