[00:00] Can not upgrade [00:00] An upgrade from 'jaunty' to 'intrepid' is not supported with this tool. [00:00] Thats a new error [00:01] NCommander: Maybe "an upgrade from jaunty to intrepid is a downgrade" would be a better error message? :-) [00:02] update-manager obviously isn't fully aware of Jaunty at this time [00:02] * NCommander uses aptitude === asac_ is now known as asac [00:13] good night === txwikinger2 is now known as txwikinger === txwikinger2 is now known as txwikinger === txwikinger2 is now known as txwikinger [01:00] * ScottK smites a user and doesn't feel a bit guilty. [01:00] (-devel-discuss) [01:00] mono_2.0-1_i386.changes uploaded successfully to localhost [01:02] now people can stop complaining so much [01:02] to experimental? [01:03] ajmitch, aye [01:03] ajmitch, of course, 2.0.1 is out do they still get to complain [01:03] heh [01:03] * ajmitch saw that someone is wanting to package portable.net again [01:03] I really don't think it's that useful [01:04] apps need to make use of the new deps following the latest package split though [01:04] ajmitch, hanska? I told him not to bother [01:04] there's so much that just won't run [01:07] *glares at nspluginwrapper* [01:07] stupid untraceable segfaults [01:07] nspluginwrapper sucks *so bad* [01:07] any pointers on how to figure out more than "??? () in /lib32/libc.so.6"? [01:07] if only we had a rich media plugin with actual source, with actual amd64 versions [01:08] on a completely unrelated note, anyone for moonlight packages? [01:08] those sort of things generally indicate missing debug symbols, but I'd assume you have those installed [01:08] directhex: sigh you and your mono rhetoric [01:08] *ducks* [01:08] ajmitch: are there debug symbols for ia32-libs? [01:08] (swfdec isn't so bad) [01:08] directhex: you want people to package moonlight, or test packages? [01:08] jdong: no idea [01:08] ajmitch, well, i have packages ready already for 0.8.1, but it's not so useful right now [01:08] why not? [01:09] doesn't work on many sites. 1.0 should have "full" silverlight 1.0 compatibility... unfortunately SL2 was released recently & many sites have updated to target it [01:09] chasing a moving target is fun [01:09] especially for a young project [01:10] 1.0 is branched though [01:10] yes, it's not so bad for flash [01:10] it does do *something* though - http://www2.apebox.org/wordpress/wp-content/gallery/00-single/moonlight.png [01:11] initial support for SL2 should arrive relatively quickly - the first major chunk of code, the silverlight classlib, is already provided by mono; the second major chunk of code, the silverlight widget toolkit, was released by MS under a free software license to help accelerate SL development [01:13] so the moon devs "just" need to pull it all together & bugfix it to death [01:14] Right, but many of us will consider 'doesn't support $DRMSCHEME' a feature (doesn't matter much that's it's MS'). [01:16] i suspect building against ffmpeg rather than letting it download the binary codecs from microsoft.com is a pretty good way to guarantee it won't support drm [01:17] OK. Then maybe I don't understand what silverlight is about. [01:17] isn't that also a pretty good way to guarantee it isn't legal in NA? [01:17] ScottK: it's basically the .NET equivalent of Macromedia Flash. [01:17] Ah. [01:17] rich multimedia/UI applet system [01:17] what did you think it was? [01:17] OK. [01:17] ajmitch: probably a media format [01:17] * ScottK thought it was MS DRM thing. [01:18] it's primarily used these days for streaming video, i can see the misconception [01:18] Shows how much attention I pay. [01:19] jdong, libavcodec's in main. [01:21] directhex: which isn't legal in the US. [01:21] directhex: if you notice, no North American Linux vendor dares ship with MP3, MPEG4, etc decoders deriving from libavcodec. [01:21] * jdong points at the $50 fluendo codec pack [01:23] jdong, talk to siretart. someone decided ffmpeg was worth putting in main, albeit with some elements removed [01:23] directhex: hey I was in favor of that too [01:24] directhex: I'm just pointing out, that, technically you cannot use it in the US due to GPL incompatibility with the patent/royalty terms for the codecs being decoded [01:24] is Bob at home going to care? Probably not. But any Linux product or business deployment of Linux should probably care. [01:25] which is why upstream don't distribute binaries built against ffmpeg [01:26] but ubuntu *does* build things against ffmpeg, hence the rather large rdepends list [01:28] I guess fundamentally, it's whether or not Ubuntu *cares* about software patent laws in one particular jurisdiction. [01:28] my gut feeling to that is, no. the archive should care about redistributability according to software licenses, not silly particular laws in each jurisdiction. [01:29] you'd be lucky to escape with anything beyond /bin/true in the archive if you started trying to follow the rules for 300+ countries on every package [01:29] and even that would be touch and go [01:29] directhex: exactly [01:30] I think where we draw the line between main and multiverse's -unstripped variant is the presence of patent-covered encoders. I think legal history shows that when you use an encumbered encoder without paying the royalty, that's when "they" start caring. [01:30] but, if you look at Novell or Redhat "stripped" ffmpeg, it's literally down to PCM/WAV, ogg vorbis, and theora. [01:30] so i got confused. was that a "yay!" or a "boo!" to linking moonlight against ubuntu's ffmpeg? [01:31] directhex: I don't know, to be honest. I'd like that to be a personal "yay" but maybe a boo to commercial Ubuntu users. [01:31] directhex: is it not possible to make it a choice which to use? [01:32] jdong, the alternative, which i suspect would receive a more negative response (ironically), would be to disable media support, and rely on the plugin offering you to agree to a microsoft eula and download some .so files from microsoft.com [01:32] jdong, could i package both? i dunno, might need to run configure/make twice, or have a second source package [01:32] and the ms media pack is i386/amd64 only [01:32] directhex: eep the archive admins typically don't like the 2-source-package approach. Does ffmpeg offer the same spectrum of codec support as the binaries? (I bet not) [01:33] directhex: if this is going to affect watching populare Silverlight streaming media sites, then I'd say it's important to at least offer the choice of MS binary codecs [01:33] jdong, in my tests, ffmpeg-from-main has complete support for the 9 codecs required by silverlight except for one rarely-used audio codec [01:34] jdong, but it's possible the ms media pack would also enable drm-protected media playback (urgh), which obviously ffmpeg won't do [01:34] i'd need to ask upstream [01:35] directhex: as much as I hate DRM-protected media, it's probably going to create more unrest in the userbase if we don't support it :( [01:35] I don't think we personally gain much from a "DRM sucks so we don't support it on purpose" outlook [01:35] jdong, i suspect people will burn effigies of me either way [01:36] * jdong agrees :) [01:36] on a related note, who feels like syncing mono from experimental? ^_^ [01:36] hang on, it'll still be in NEW [01:36] * wgrant incinerates directhex. [01:37] wgrant, i prefer the term "immolates" [01:38] i've asked upstream. silverlight 1.0 has no DRM capability, so moonlight doesn't either. so we only lose one audio codec by linking ffmpeg instead of using the ms media pack [01:38] silverlight 2.0 reopens the question [01:40] can you not drop in place a codec pack and have that used though, or does it really have to be linked? [01:40] jdong, http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight#head-269adabf77c0d3971046e1d0b1413878912bf0cb [01:41] superm1, the codec pack is designed to drop in-place, but my understanding is it requires the plugin to have been explicitly built without ffmpeg support - you can't have ffmpeg AND mscodecs in the same plugin [01:41] oh that's going to be annoying [01:41] fallback support would be nice... [01:42] i know. it's an open question really [01:42] for now... i dunno. once 1.0 is tagged & i have a tarball to work with, i'll muck about with the possibilities [01:43] i'm trying to make this a first-class package. all the special debian/control values for Ubufox and everything [01:47] superm1: agreed, it'd be REALLY nice if it can fallback to one or the other [01:47] perhaps two packages then, even if it means messy mangling of the source package. one could get listed by the plugin finder as "Novell Moonlight (evil binary codec support)" and one as "Novell Moonlight (freedom-loving joy edition)" or somesuch [01:47] i.e. like the gstreamer pluggable infrastructure [01:47] directhex: yeah I think in this case it's not a bad idea to offer two alternatives [01:47] directhex, at least until fallback support is in the plugin itself, i think that would be a good solution [01:47] one built with MS codec support, one with ffmpeg linking [01:48] is running ./configure and make twice in one package acceptable? [01:48] at least a couple packages in the archive do this. [01:48] i've seen it before in some package [01:48] names would help [01:49] one of the media apps does this for static and non-static versions of its library... [01:49] trying to think of which [01:53] i thought some app did it for a gui and non gui version of itself too [01:53] again not much help though since i dont remember :) [01:53] vlc used to. [01:54] it was a royal PITA, and I'm very glad that's no longer the practise. [01:54] crimsun: hey while I have you here, have you looked into that pulseaudio suspend/resume issue/workaround? [01:55] 202089? [01:55] if so, yes, hyperair and I chatted about it last night [01:55] crimsun: yeah that's the one [01:56] my concern is that it's not sufficient, and it needs more testing to verify that it doesn't reintroduce 8.04's suspend-on-idle race [01:56] * jdong nods [01:57] (the race concerns multiple audio devices, one of which is external, usually usb-audio, so when loading/enabling module-suspend-on-idle, module-alsa-s{ink,ource} bomb) [01:57] I was bitten by that bug after hibernate yesterday, pidgin immediately found it amusing to swap the system to death [01:57] hmm shame I don't have multiple audio devices or external ones so I can't really test that personally [02:02] When submitting an ITP, is there something that needs to be done on Ubuntu side? Add the link to the bug on LP or REVU, or something like that? [02:03] moon allows both [02:03] it defaults to using mscodecs if available [02:03] but it wont prompt you to install the mscodecs unless you reach a site with a missing codec [02:05] superm1, seems it already does what we need :) [02:19] james_w: around? [02:22] What files should I attach to a bug report requesting that a package be upgraded to a new upstream release? This isn't a merge/sync request from Debian. [02:22] any body have problems updating their packages after upgrading to 9.04? I try to do a partial upgrade, but then it says "Can not upgrade. An upgrade from 'jaunty' to 'intrepid' is not supported with this tool" [02:22] nhandler, ideally, a new diff.gz ;) [02:23] directhex: Do they still want the interdiff? [02:23] nhandler, god knows. i lost track of which diffs to use when. i found the easy option was just to work on debian [02:24] directhex: That is why I am asking here. I can't even find the wiki page that talks about this anymore [02:26] nhandler: it's just the .diff.gz [02:27] hey persia [02:27] Thanks nellery. By any chance do you have a link to the wiki page that mentions this? I know it exists, I just don't know where it is (I lost my bookmarks after the upgrade) [02:27] nhandler: sadly no, I figured this out from irc [02:30] * persia goes off to find the documentation of interdiff, and update it. Please attach debdiff for the same upstream version, or a merge, and diff.gz for a new diff.gz [02:32] s/new diff.gz/new upstream version/ ? [02:32] Yes. [02:33] bedtime. [02:34] Night directhex [02:36] Anyway, hints for submission to the sponsoring queue are at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (and now actually say the right thing) === woody86_ is now known as woody86 [03:22] I just put together a quick script that lists how many packages each Developer still needs to sync/merge from Debian. It gets its list from DaD's last Ubuntu uploader field. Enjoy: http://nhandler.servehttp.com/merges.pl [03:24] * persia points out that merges aren't strictly assigned, and that just because one isn't listed doesn't mean one's work is done : UEHS lists *lots* of packages. [03:28] persia: I am aware of that. However, the person listed as the last Ubuntu Uploader is the one who usually gets first dibs at performing the merge/sync. If they do not wish to carry out this task, they are able to comment on it on DaD, and someone else will take care of it for them. [03:30] nhandler: of course, this then means that folk that are overloaded have to comment on huge numbers of packages to say they can't do stuff?! [03:31] lifeless: It isn't a requirement. However, it makes it clear to other people that that person is not planning on performing the merge. [03:35] nhandler: but that clarity is only needed because you're asserting that the last toucher has some sort of lock [03:35] Ubuntu doesn't have maintainer locks though, so -> I am confused [03:36] lifeless: I never said they had a lock. However, in most documents regarding merges, it does say that you should contact the last ubuntu uploader prior to performing the merge. This implies that they do have first dibs on the merge (like I stated) [03:37] I've had reservations about that guideline; it tended to introduce latency in previous merge cycles [03:38] I think that convention is being ignored more and more, fortunately. [03:38] wgrant: Last cycle, they sent out an email telling people to ignore that convention (I think after DIF). [03:40] It was right about DIF. [03:41] OTOH I've seen people who don't understand packages dive in and do bad merges. If someon who is familiar with a package is going to do it, they should be able to. [03:48] Unpacking OO.o build tree - [ go and have some coffee ] ... [03:48] That's not a good sign for the time this build will take ... [03:50] NCommander: Work on my library problem while you wait ... [03:50] NCommander: You have reached a new level of insanity. [03:50] wgrant, I'm building it on a 733Mhz processor :-) [03:50] And another. [03:51] I wonder if LTS+1 will be out by time it finishes [03:51] wgrant, with only 256MB of RAM [03:51] Oh, then it'll be quick. [03:51] ... to be OOM-killed. [03:51] * NCommander has 4GB of swap [03:52] how does the build go again? malloc(4000000000); [03:52] lifeless: No; that's too quick. [03:52] Anyone want to take estimates to when it finishes building? [03:52] lifeless: It malloc(1)s lots of times. [03:53] NCommander: I predict it won't finish. [03:53] Probably [03:53] * ScottK once tried to build Eclipse on a similar machine. [03:53] It died. [03:53] * NCommander did build Eclipse on this [03:53] * NCommander build OOo on an m68k [03:53] *built [03:54] The build time was something like 3-4 weeks [03:54] But it compiled from source! [03:54] Why would one want to build OOo on m68k? [03:54] To be a release architecture on Debian, you need 98% of the archive built, and 95% up-to-date [03:55] and we have a few free buildds [03:55] :-) [03:55] * NCommander notes we scare the Gentoo m68k users [03:56] wgrant, w.r.t. to sanity, I'm hoping I hit the insane counter upper limit, and it rolls into sanity [03:57] O_o; [03:58] the diff is over 100MB :-/ [03:58] compressed [03:59] WOO, ./configure is running === cprov is now known as cprov-zzz [04:24] ScottK, O___o, I didn't know we allowed non-MOTU to be mentors [04:24] NCommander: UCD's are allowed to be mentors in the Junior Mentoring Program [04:25] I believe you need to be a MOTU to be a mentor in the senior mentoring program [04:25] That seems like a *really* bad idea since we have no bar to measure what UCDs actually know [04:25] nhandler, see Scott's message to the list, and my follow up [04:26] NCommander: What's so chaotic about pulseaudio being removed? [04:26] it took ALSA with it [04:27] * nhandler is reading the messages now [04:28] NCommander: I found the deadly symbol in libspf2. [04:28] 1. what, and 2. how? [04:28] __libc_subinit [04:28] NCommander: Personally, I don't think there should be rank restrictions on who can be a mentor. If someone is willing to teach and has the knowledge, that should be enough. Maybe we should create a quiz to verify that the mentors know what they are talking about (for non-MOTUs) [04:28] ScottK, O_o; [04:28] Found a reference to private libc symbols starting with __libc (thanks to Google) and then grepp'ed the source. [04:29] nhandler: If the mentors know what they're talking about, why aren't they MOTU? [04:29] Ah [04:29] wgrant: You need more than knowledge to become a MOTU [04:29] NCommander: Any chance you could look at it and see if you can come up with an appropriate patch to avoid that? [04:29] nhandler, the only exception I could see are people who are DDs, and haven't been here that long, but those are few and far between, and even then, I'd perfer that they be MOTU so we know that they're aren't going to teach invalid packaging techniques [04:30] ScottK, you know, this library the freaking bastard child from hell :-P! [04:30] nhandler: Yes, but right now apparently the rule is there is no actual requirement for any technical knowledge at all. [04:30] Oooooh [04:30] NCommander: It's a "Learning experience". [04:30] Ew [04:30] ScottK: That is true. They are assuming that UCDs know what they are talking about [04:30] That is why I suggested a quiz [04:30] The reason this uses an internal glibc symbol is because it uses an internal glibc library [04:31] nhandler: And that's the flaw. UCD is not somehting you get for technical expertise. "They know because they are UCD" is a logical falacy. [04:31] it's a good idea to have some sort of DM/DD/MOTU guideline for mentoring. that said, there have been mentors who are no longer MOTU or DM/DD. [04:33] ScottK, yeah, I think I can fix this [04:33] * NCommander pukes [04:33] There is no way to keep people from teaching. We have a large forum community of people trying to "teach" each other. We do not restrict who is able to teach there. [04:33] The only nice thing about the Mentoring Program is that it takes care of the hassle of hunting down a person who knows about MOTU-related activities [04:33] nhandler: Agreed, but it's different if we say, "Here is your official mentor. Listen to him." [04:33] But what makes it "official" [04:33] Hi. I was looking at Bug #284910, and it appears to be because of libtool. Why Debian version is 1.5.26 and ubuntu one, 2.2.4? Is there a way to use the Debian version in Ubuntu? [04:33] Launchpad bug 284910 in gdal "libgdal1-1.5.0 can not recompiled" [Undecided,Confirmed] https://launchpad.net/bugs/284910 [04:34] (It's a FTBFS in Intrepid) [04:34] nhandler: It's the MOTU mentoring program. [04:34] For instance, persia helped teach me the basics of patching when I first got into development. I never went through the mentoring reception. I still consider him my mentor (even though it wasn't official) [04:35] nhandler, You were registered in that program, and when we lost touch, I sent a note saying that it had ended, although I've been glad to see you back, and with your work since then. [04:35] persia: I was? I never remember sending them an email [04:36] nhandler: That's great. That's the kind of mentoring I'm in favor of. [04:36] nhandler, You didn't : you asked me, and I fed your name to them because we were already in touch, and I didn't have time for more people. [04:37] ScottK, ok, I think I got it [04:37] NCommander: Cool. [04:38] persia: Ok, but the difference is, you started mentoring me, and then you informed the reception about that (so that they knew you couldn't mentor anyone else). I didn't actually go through the reception to get you [04:40] NCommander: You're MOTU now and it's in Universe, so go for it. [04:41] * NCommander hates mucking around with auto**** [04:42] B.S. You love it and you know it. [04:43] nhandler, Sure, but you also showed up in this channel a couple times, and were clearly looking for someone, and that happened to be the same week the Mentoring Program started, so it's a bit of a special case. Had there been a program then, you probably would have signed up. [04:43] Had there continued to be no program he probably would have gotten help just fine too. [04:44] persia: I did not realize the mentoring program was just starting up then. And ScottK, you are correct, I probably would have continued without the program. But it was nice having a mentor. [04:48] nhandler, Whether there is a MOTU Mentoring Program or not doesn't necessarily affect that. If I remember correctly, you had looked at one of the bugs I'd offered to mentor as a starting point. Whether self-selected LP declaration of mentoring is any better than a matching spreadsheet is unknown. [04:50] Given the number of people who seem to want to find a mentor before they do any work, I'm not tempted to throw away the Mentoring Program, but so far it's not shown itself to be significantly better than what proceeded it. [04:50] persia: One way I think it's almost certainly different is that when a perceived authority says to a new person, "Here is your official mentor", said new person is much more likely to assume they know what they are talking about. [04:51] persia: That is true. I started with one of the bugs you had offered to mentor. This method has 1 advantage. Usually, if a person is offering to mentor someone on a bug, it means that that person knows how to fix the bug and is willing to teach someone else how to do that. [04:51] persia: How many people want to wait because there exists a program to provide mentors and so that's thought to be the appropriate path? [04:51] Well, I'm too tired to think straight any more. I'm off to bed. [04:51] Good night. [04:52] ScottK, unquantifiable, although both before and after there was such a program, some people would ask for a mentor and weren't satisfied with "here's some bugs, ask here if you get stuck". [04:53] True, but I've always considered if you aren't a bit of a self-starter you won't be around here for long anyway. [04:53] I'd say that there are several groups of folk: those that just do, those that want a mentor,and those that are trying to figure out the best way to get started. No idea about percentages though. [04:55] Well, you don't have to be a self-starter, but you do need to have some reason to be doing. [04:56] Fair enough. [04:56] * persia would actually prefer a wider variety of motives to be working on Ubuntu :) [04:59] For me it's hard to be at all consistent without an external "reason to be doing", so far... I'm active for a week or two and then Real Life comes along and I stay away for weeks... which is why I'm still not even a contributor, never mind a MOTU :-) [05:02] jmarsden: Yes, but stick with it and you'll get there. [05:02] We all come and go to some degree. [05:03] Yes, I intend to ... if I had a month's vacation to do nothing but this stuff, I'd be there now :-) [05:03] ;-) [05:05] Do we have a spot on the wiki for little tips and tricks? [05:05] * ScottK just ran into a situation with a package that now builds in Jaunty and believes it should depend on a non-existant package called glibc_private. [05:06] sweet [05:06] It turns out this means that the package is building against private glibc symbols and this is no longer allowed, so the package is built uninstallable on purpose. [05:06] So the trick is to find said symbol and make it go away. [05:06] yay binary uploads to debian [05:07] It was never allowed. [05:07] OK. It no longer works. [05:07] Right. [05:07] This package has been in Ubuntu since a very long time and the offending bits are there from the beginning. [05:07] Eww. [05:08] You might put it under recipes. All the other tips&tricks seem to have gone. [05:08] So the trick that I eventually discovered is that private glibc symbols all start with __glibc and so if you know that, you can grep the source. [05:08] persia: I looked at that page and the description didn't seem to fit. [05:08] It talked about ways to use tools MOTU use regularly. [05:09] ScottK: Well, I suppose MOTU's use grep pretty regularly :-) [05:10] True. [05:10] But it's certainly not a common situation. [05:10] Agreed. [05:10] Would adding it under "Other packaging tasks" on https://wiki.ubuntu.com/MOTU/TODO work?? [05:11] Well, grepping for various constrctions is common. You could just use __glibc as an example. [05:11] OK. [05:11] I can do it that way. [05:11] Well, grepping for various constrctions is common. You could just use __glibc as an example./ That might be a good candidate location. [05:12] * persia curses the up arrow [05:12] That was supposed to say "where did stefanlsd7s excellent guide go..." [05:34] Since it's now policy not to mention maintainer change in debian/changelog, someone might want to make a better example for this https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff [05:51] why not mention the update-maintainer script? [05:57] I think that'd be a little confusing for an example of how to apply a debdiff. [05:57] * ScottK goes to bed. === RoAkSoAx_ is now known as RoAkSoAx === fabrice_sp_ is now known as fabrice_sp [06:42] good morning [06:44] dholbach: Good morning. :-) [06:45] hi slytherin === santiago-ve is now known as Guest69496 === Guest69496 is now known as santiago-ve [07:01] wgrant: May I take the maxima merge too? [07:01] Morning dholbach, slytherin. [07:01] hiya iulian [07:01] iulian: Go ahead. It should build now. [07:02] OK, thanks. [07:02] anyone else handing out merges :) [07:03] stefanlsd: will you do jigdo merge? I did last merge but I will not get time for next 24 hours. [07:03] slytherin: will have a look at it :) [07:08] good morning everyone. [07:09] gouki: Good evening (it is 11:10pm in California) [07:10] good morning dholbach, slytherin [07:10] hi geser [07:11] jmarsden, hehe. I just woke up. It's 7:10AM. It's raining like hell, and I bet it's pretty sunny there :) [07:11] geser: good morning [07:11] gouki: UK? [07:11] gouki: Well, it's pretty dark here, at 11pm :-) It was sunny earlier [07:12] iulian, close. Two to the left .. Portugal. [07:12] Ahh [07:12] jmarsden, d'ohh! Indeed. [07:13] Submitted an ITP but still didn't receive the bug number ... :S [07:15] [OT] - Has anyone purchased AVM FritzBox router? If yes, how good is it? [07:21] wgrant: Should I close bug #242243 in the changelog? It has been fixed in Debian. [07:21] Launchpad bug 242243 in maxima "New maxima FTBFS with "/bin/sh: ./maxima: No such file or directory"" [Unknown,Fix released] https://launchpad.net/bugs/242243 [07:21] iulian: Please do, if it does actually build. [07:22] wgrant: I'm building it now. [07:35] slytherin: re bug 295539: what's the advantage of building it for jvm 1.4? [07:35] Launchpad bug 295539 in libjogl-java "Please merge libjogl-java 1.1.1+dak1-1 (multiverse) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/295539 [07:41] NCommander: Around? [07:42] slytherin: merged if you would like to review it. It also built ok. - Bug #296648 [07:42] Launchpad bug 296648 in jigdo "Please merge jigdo 0.7.3-2 (universe) from Debian (unstable)" [Undecided,New] https://launchpad.net/bugs/296648 [07:42] soren, for some defintions of around [07:42] -> /msg [07:47] wgrant: I'm waiting for a response from bug #285420. Looks like it's the same as Debian bug #480308. [07:47] Launchpad bug 285420 in maxima "maxima "Couldn't protect"" [Medium,Incomplete] https://launchpad.net/bugs/285420 [07:47] Debian bug 480308 in maxima "maxima: segfaults in quad_qagi()" [Normal,Closed] http://bugs.debian.org/480308 [07:47] wgrant: In the mean time I'm looking for a fix. [07:49] wgrant: If he confirms that is the same bug I will do the merge because it's fixed in Debian. [07:49] And maybe we can backport it to Intrepid. [07:52] Bug #261056 needs investigation as well. [07:52] Launchpad bug 261056 in maxima "maxima crashes: Couldn't protect - out of memory allocating 7 bytes" [Medium,Confirmed] https://launchpad.net/bugs/261056 [07:56] wgrant: Or we can upload the new version to Jaunty and ask the reporters to test it to see if they still have the problems? [07:56] Hey DktrKranz. [07:57] morning iulian [07:57] morning * [07:58] iulian: Upload to Jaunty, backport to Intrepid, get people to test, then work out where the problem lies, SRU it. [07:59] I forgot the "work out where in the 53KLOC gcl diff the bug is". [08:02] wgrant: OK [08:08] stefanlsd: Looks fine to me. But I am not a MOTU so can't sponsor it. 2 comments. 1. There is another bug for move to libdb4,6. Make sure you also add that bug in changelog. 2. I was thinking if we should update ubuntu mirror list. Need comment on that from someone. Probably ask in #ubuntu-devel. [08:09] geser: re: libjogl-java, no specific advantage. But I think we should target 1.4 unless the app/lib specifically needs JRE 1.5 or higher. === RAOF_ is now known as RAOF [08:39] wgrant: Hmm, when I try to build maxima it fails with unmet dep (pbuilder-satisfydepends-dummy: Depends: gcl (>= 2.6.7-44) but it is not installable), even though I updated my Jaunty pbuilder. [08:40] I see that Jaunty has gcl version 2.6.7-45, it should have worked. [08:40] Am I missing something? [08:41] iulian: It failed on !(hppa|ia64) [08:42] Which probably means it needs a giveback. [08:42] * wgrant does so. [08:53] wgrant: Where did you see that? [08:54] iulian: https://edge.launchpad.net/ubuntu/+source/gcl/2.6.7-45 [08:54] But it all just failed again. [08:54] WTF [08:54] Since when do things succeed only on the most obscure archs!? [08:54] It's the new plan for ia64 domination [08:55] gcl? /me hides [08:55] Huh [08:55] DktrKranz: I'm hiding further away. [08:55] Bug #43150 was enough to keep me away for life. [08:55] Launchpad bug 43150 in wxmaxima "[SRU] maxima frontends fail to connect" [Medium,Fix released] https://launchpad.net/bugs/43150 [08:55] wgrant: I found a way to fix it [08:55] DktrKranz: How? [08:56] Oh. [08:56] It's in the dep installation. [08:56] I see. [08:56] a combination of black magic, voodoo and some inner-african rituals [08:56] I can't connect to launchpadlibrarian.net from here for some reason. [08:56] Ah, no, just lag fooling me into thinking it was deps. [08:56] but main point is some applications are still failing [08:56] Arfgergerhgear;ogi ewfgewrouf ewf [08:56] It has its own binutils, doesn't it? [08:56] don't remember which ones, but they seem racy [08:57] yes [08:57] NCommander! [08:57] he already trie [08:57] d [08:57] wgrant, ? [08:57] Oh, this is still that same issue? [08:57] NCommander: gcl \o/ [08:57] NCommander: gcl needs to die. [08:57] Oh good [08:57] We have concurrence [08:57] NCommander: or your beloved 14Mb .diff.gz [08:57] I just say we delete it, and all its rdepends [08:57] They haven't worked since Gutsy AFAIK [08:58] But maxima rocks :( [08:58] maxima works fine. [08:58] Indeed. [08:58] Can we compile it reliably :-)? [08:58] We could previously. [08:59] NCommander: we have something to do for jaunty, hooray! [08:59] Does this mean getting rid of gcl? [08:59] cruft-busters hat on? ;) [08:59] WOOOOOOOOOO [09:00] We can't get rid of gcl... but maybe it could be made a bit less crap. [09:00] yes. [09:00] Please. [09:00] How do other distros do it? [09:00] gcl has been unmaintained for awhile [09:00] I'd like to see gentoo [09:00] DktrKranz, not packaged AFAIK [09:00] Aren't there other CL implementations we could use? [09:00] cmucl [09:00] The Debian guy seem to decided that updating binutils was worth dumping in the diff [09:00] gah! [09:00] gentoo is good [09:01] and most of their fixes applies here [09:01] They don't ship ada last time I checked either :-) [09:01] The workaround for 43150 was to use cmucl to build it instead of gcl. It apparently worked fine. [09:01] So if we can use cmucl vs gcl [09:01] heh, ada :) [09:01] I say we transition out gcl [09:01] Then let's keep using cmucl until either it works, or it doesn't. [09:01] Let's first see what Fedora does. [09:02]