[00:04] crimsun: http://www.pastebin.ca/1007528 for esdctl attempting to cache the startup sound. [00:05] TheMuso: nice, thanks! [00:08] crimsun: np. [00:08] esdctl should return a slot number, and a name to use to play the cached sample. [00:08] Which doesn't occur. [00:08] right [00:10] * ajmitch is glad that he's only had one audio app causing no end of problems, rather than several [00:16] \sh, xdebug now in debian - do you wanna have a looksie see if it [00:16] s ok to just overwrite on Intrepid>? === pgquiles__ is now known as pgquiles [00:26] Is this http://scratch.mit.edu/pages/source DFSG compliant? [00:41] ffm: I'm not #debian-legal, but it looks DFSG non-free to me. [00:42] I made it!! I made my first package!.. it works and finally finished the project!! thank you guys for the wikis.. but now I'll sleep!... (it's getting late!) [00:42] ffm: The 'non-commercial' certainly smacks of DFSG #6 non-freeness. [00:42] ffm: http://www.debian.org/social_contract#guidelines [00:45] wow.. and it seems I've found an error/bug/whatever while printing!! where do I report this problem? [00:46] is there any specific site/channel/blog for printing problems?? [00:47] i4x: There's always launchpad.net :) [00:47] hm, fine!! [00:48] well, c yall!! [01:06] hi [01:06] im trying to build audacity after a merge but it gives me this http://paste.ubuntu.com/10117/ any ideas? [01:07] do you have cdbs installed [01:08] no [01:08] try installing cdbs then [01:08] ok [01:08] thanks [01:14] RoAkSoAx: ping [01:18] Ah, x86-64. An extra 32bits you need to try _really hard_ to make work. [01:28] hi all, when i work on update a package to a new upstream version, i need to provide a get-orig-source rule, right? [01:28] That would be nice, but not 100% necessary. (yet) [01:28] ok :) [01:29] At this point in time, you should also be very much working with the Debian maintainer to get whatever it is in Debian, too. [01:53] crimsun: i go to sleep, night and big thanks :) [02:21] Things I didn't know before today: fedora's base install includes latex. [02:23] RAOF: gotta stay protected man [02:25] Heya gang [02:25] jdong: >.< [02:25] Yo! bddebian! [02:25] Hi RAOF [02:46] nxvl, pong [03:18] RAOF: I think Ubuntu's base install includes some elements of tex at least [03:18] not sure about latex specifically [03:21] anybody know if the intrepid debootsrap just does a simlink like Hardy? [03:24] LaserJock: the changelog hints so [03:24] I might just do it locally [03:24] * Add (Ubuntu) intrepid as a symlink to gutsy. [03:25] I'm trying to figure out how to do an intrepid chroot for sbuild/LVM [03:26] I might be able to name it intrepid but have it build a hardy chroot [03:26] then I can dist-upgrade it [03:28] seems to be working [03:29] * TheMuso duplicated his hardy chroot and dist-upgraded, although I do intend to create fresh chroots in the coming days. [03:29] hello. I've a question, when packaging a new upstream release, i have to attach the diff.gz, or a debdiff? [03:29] I'm not very good with the LVM foo so I let kees do it for me ;-) [03:30] bitbuzter: diff.gz [03:30] I believe [03:33] jdong: what do you think of an SRU fixing a .menu file? [03:34] LaserJock: what was wrong with the file before? [03:34] jdong: since we don't use the Debian menu by default I can't imagine why it'd be very important [03:34] * persia notes that the default install set doesn't even change the interface based on a menu file [03:34] jdong: it was missing a [03:34] "\" [03:34] sounds like a serious bug [03:35] it is broken, but I really don't think we need an SRU for a .menu file [03:35] LaserJock: does it make the menu file unusable for people who do use the Debian menu? [03:35] Actually, it might be, if it blocked the menufile parser on installation. Can the package be installed? [03:35] LaserJock: thanks, the diff.gz that is created when i build the package, right? [03:35] jdong: it does [03:35] LaserJock: I can't see the regression potential of fixing it.... [03:35] persia: yes, it can be installed, it just won't run [03:35] LaserJock: There's no .desktop file they can use as an alternative? [03:35] And it will run, just not from the menu. [03:35] it's a fairly non-invasive change to upload [03:36] oh wait [03:36] persia: I don't think that's the point [03:36] this is important though: [03:36] "The bug manifests itself by making sure no applications installed after [03:36] this package appear in the Applications menu." [03:36] so apparently it screws up the Debian menu [03:36] LaserJock: that's pretty rough [03:36] yeah, let's fix that [03:37] rightio [03:37] Ah, yes, that's a parser issue, in which case it deserves an SRU. Be better to make the menu parser more robust, but... [03:37] rexbron: ping? [03:37] * ajmitch thinks that the bar should be fairly low for hardy fixes anyway [03:37] though my opinion is worth little [03:37] * jdong agrees with ajmitch at least until 8.04.1 [03:37] well [03:37] ajmitch: Why low for hardy as opposed to something else? [03:38] I agree it should be low [03:38] but I also don't want a -proposed full of fixes nobody is going to test or care about [03:38] I'm not arguing for hardy being high, just for consistency in the application of policy [03:38] persia: mainly because of the LTS thing, and that people have a higher expectation for hardy [03:38] persia: up until 8.04.1 I think we should treat it as a RC-freeze w/ no upstream version clause.... [03:38] either way, it's not up to me [03:39] persia: I think it's important for our LTS that we make a continual effort to "get it right" and more polished [03:39] jdong: That'd be very different: in that case, why shouldn't anything RC-freeze acceptable go to any release? [03:39] persia: though if the effort pays off in a positive way,we can consider using it as a precedent for future releases [03:39] jdong: I disagree. I would be happy with a policy that said for all releases we made a continual effort to "get it right", but don't think LTS is sufficiently special. [03:40] in policy I don't think it should really be any different [03:40] in practice everybody is more focused on hardy [03:40] no no in policy it should be the exact same [03:40] but I honestly don't think we "made a continual effort to get it right" in previous releases [03:40] so they are more likely to file/look at/fix bugs [03:40] ajmitch: While it may not be up to you, 40% of the people to whom it is up are present, so it's a good place to make your arguments :) [03:40] to be honest [03:41] LaserJock: That's fine. Any SRU policy is tempered by the interest of those preparing patches. [03:41] we can do better and here's a good chance for us to prove that [03:41] persia: I have no arguments to make, only uninformed opinions [03:41] s/uninformed/informed/ [03:43] * jdong just noticed his GNOME weather applet said "Sky: Broken clouds" [03:43] that doesn't sound like the right way of wording it [03:44] somebody gonna patch it? [03:44] * LaserJock files an SRU on jdong's weather [03:44] LaserJock: I think there's too many patches already ;-) [03:44] [03:44] hmm [03:44] * LaserJock ponders "Broken clouds" and "Patchy weather" [03:45] even patchy clouds sounds better than broken clouds [03:52] Isn't that string pulled from the updating service, rather than encoded in the applet? It might be hard to change. [03:53] * ajmitch doesn't understand why it's considered wrong [03:55] broken clouds simply sounds awkward [03:55] it's not wrong it just maybe sounds funny [03:55] it's a common description [03:55] I'm not sure. The phrase "A break in the clouds" has a long history. "Broken clouds" typically means patches of blue whilst mostly overcast. "Patchy clouds" would be the inverse. Either works for 50% coverage. [04:04] jdong: Persia's right. Broken (and partly broken) clouds are standard weather terms. [06:37] good morning [06:38] good night :) [06:38] sleep tight RoAkSoAx [06:39] thanks dholbach, you have a nice day =) [06:39] thanks a lot :) [06:43] hrmm, anyone else having problems building their intrepid pbuilder due to libc6? [06:43] mornin' dholbach [06:44] nixternal: Yup. [06:44] hiya nixternal [06:44] OK, so it isn't just me then [06:44] * nixternal does a dput and pray for Intrepid then :p [06:44] I gotta catch up on my 5-a-days [06:44] should be 2 to 4 or more 'really fix its' fixed [06:45] * nixternal does one more Hardy backport before calling it a night [06:49] dholbach: guten nacht! [06:49] dholbach: is monday already in there? [06:49] hehe... sleep tight nxvl [06:49] nxvl: yes, it's 7:49 [06:49] nxvl: Its 15:49 here on Monday. [06:49] * dholbach hugs nixternal [06:50] TheMuso: where do you live? [06:50] here is still sunday [06:50] well [06:50] monday already [06:50] 00:50 [06:50] nxvl: Sydney, Australia. [06:50] oh! [06:50] nice! [06:51] * nxvl want's to visit Australian Waves some day [06:52] Wow, this makes me feel good about myself. some one commented on my progress on a simple bug I was working on and said they learned from it [06:52] :) [06:52] And this is only my first week contributing :D [06:53] tbielawa: excellent! keep it up! :) [06:56] Morning [06:56] thanks [06:56] Morning [06:57] well [06:57] time to sleep [06:57] good night [06:57] see you all later (tomorrow for me ) [06:57] * nxvl HUGS everyone [06:57] * tbielawa waves [06:57] im not tired.. cant sleep :P [06:57] * Syntux hugs back [06:58] c/c [07:01] dholbach, can i ask you a favor? i did my first merge... could you check it? https://bugs.launchpad.net/ubuntu/+source/blam/+bug/226670 [07:01] Launchpad bug 226670 in blam "[wishlist]Please merge blam 1.8.5-1 from Debian unstable (main)" [Undecided,Confirmed] [07:01] good morning [07:02] hi geser [07:03] RoAkSoAx: it's in the sponsoring queue - once I've caught up with my mail backlog I'll dive into sponsoring head-first [07:05] Good morning [07:06] hi warp10 [07:06] dholbach, yep i uploaded it to u-u-s as stated by nxvl, thanks for checking it :) [07:06] hey dholbach! [07:07] I need a pbuilder for intrepid!!! hopefully I don't wake up to any FTBFS in the morning [07:08] nixternal: Eh. Make the archive your build experiment! [07:08] been there, done that...thus far I have been lucky [07:08] at least I built and tested all of my backports for Hardy :) [07:12] g'nite all! [07:14] byeeee [07:14] So has anyone gotten a working intrepid pbuilder set up? [07:15] I've seen that topic come up a few times in here over the past few days [07:18] actually, i have a more pressing concern. my lintian check on revu is upset about a missing .orig.tar.gz [07:18] http://revu.ubuntuwire.com/details.py?package=bibus [07:19] even when I rename the source gz to the correct name and rebuild the source package it only wants to reference and create the tar.gz with the original name scheme: bibus_1.4.2-1.tar.gz [07:19] tbielawa: I have copied my hardy base.tgz and upgraded it to intrepid (a few days ago) [07:20] geser: I attempted the upgrade method. My attempt failed due to unmet build dependencies. It seemed wrong because apt-cache search had results for each failed dep with the >= the min version required [07:21] last night debootstrap worked for intrepid [07:21] idn if that's still the case now [07:21] murphy's law says no [07:21] I was chroot'd into the hardy environment when I ran the search with an updated source.list [07:21] jdong: ya, no joke there :( [07:22] tbielawa: I did the upgrade a few days ago and I got some unmet deps today when I tried to update it [07:22] tbielawa: how did you name your .orig.tar.gz? [07:23] apt-get source from the upstream repo (hack through sf.net) privides bibus_1.4.2-1.tar.gz. it came debianized but needed updating [07:24] I renamed the tarball with a proper .orig.tar.gz and went into the decompresed source dir and did a source build of the original source so I had a dsc [07:24] it insisted on recreating the tarball with the bibus_1.4.2-1.tar.gz format, even in the dsc "Files: " log [07:25] have you tried to rename the the tar.gz to bibus_1.4.2.orig.tar.gz? [07:25] geser: Yes I did [07:25] hmm [07:26] I thought that if I took the source and rebuild the original source (unmodified) to produce a dsc and had a properly named *orig.tar.gz in the ../ from the source dir it would reference that in the new dsc. [07:26] hello [07:27] will somebody fix the plone mess in the repository? [07:27] then my thoughts were, make changes and dch for the ubuntu1 release so I'd get a fancy diff.gz, but it failed at recognizing I even had a orig.tar.gz! [07:27] i think there are 2 instances of the old plone... and zope-plone3 is like missing or something [07:28] i'm talking about www.plone.org .. the cms [07:29] no luck with intrepid pbuilder today :( [07:35] tbielawa: I fetched your package from revu, renamed bibus_1.4.2-1ubuntu1.tar.gz to bibus_1.4.2.orig.tar.gz and run debuild -S (inside bibus-1.4.2) to build a new source package and got a diff.gz [07:36] and empty one because the debian dir is already in your .orig.tar.gz [07:37] the gz you got is after I made changes (update fsf address in all files, etc). Should there be a diff generated from upstream to the ubuntu1 versions then? [07:39] let me know if it's not clear what I'm trying to express [07:44] tbielawa: yes, if you can take a .orig.tar.gz without the debian/ dir as .orig.tar.gz so the contents from debian/ will end in the .diff.gz [07:48] ok [07:48] what can I do to fix the lintian error? [07:49] you mean the native-package-with-dash-version [07:49] error ? [07:50] it should vanished if you have a proper .orig.tar.gz [07:52] Would that mean taking the debian/ dir out of the upstream tar.gz and recompressing it at .orig.tar.gz then applying all my changes (put back in debian/) into the now un-debianized folder? [07:54] yes [07:55] tbielawa: I've to run now but I hope someone else will pick up and help you further [07:55] geser: thanks for being helpful. This process is pretty new to me still, thanks for your patience too [07:55] alright, bye, thanks again [08:03] <\sh> grmpf [08:04] <\sh> did anyone succeed in creating a chroot for intrepid? [08:05] Sure. [08:11] <\sh> soren, hmm...W: Failure trying to run: chroot /home/shermann/intrepid_chroot dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_amd64.deb <-- bad [08:11] <\sh> soren, using a.u.c. and local mirror... [08:12] What's the error? [08:12] <\sh> soren, what I pasted...it can#t install libc6 [08:13] *shrug* It worked for me. [08:13] <\sh> soren, could you try again? :) [08:13] sure [08:13] \sh: Doesn't work for me, either. [08:14] <\sh> after I resolved my "dear wife, why did you label my cds, and if so, why did you label them totally wrong?" [08:14] <\sh> I thought I'm done with the errors ;) [08:22] Ah, I know what's going on. [08:23] Gimme a minute. [08:25] <\sh> soren, go for it :) [08:45] \sh: For now, adding "--add perl-modules" to debootstrap's command line should fix it. [08:47] <\sh> soren, hmm..if it works, ok...but why? :) [08:47] as i recall, motu's "package" *buntu deb's for *buntu distrobutions [08:47] correct? [08:48] \sh: libc6's postinst uses debconf, which ends up requiring a file from perl-modules, but perl-modules is priority: standard, so debootstrap doesn't pull it in. [08:48] BunnyRevolution: Er... Something like that. [08:49] the packaging guide would tell me the information i need to know for packaging, correct? [08:49] That's the intent, yes. [08:50] <\sh> soren, is it new? and if so, the fix is only a matter of time, right? [08:50] \sh: Yes. [08:50] \sh: and yes. [08:51] thank you soren [08:51] <\sh> soren, --add or --include? [08:52] <\sh> i guess it's --include [08:52] Oh, right. [08:53] <\sh> soren, but it doesn't work actually..perl-modules is getting included...but the same error occurs [08:53] <\sh> ah damn [08:53] <\sh> perl-modules included, but isn't extracted before libc6 [08:53] \sh: Try reexecuting the command line. [08:53] \sh: Oh. [08:54] * soren kicks debootstrap [08:54] <\sh> hehe [08:54] <\sh> well, perl-base is the only perl package which is extracted..but not perl-modules [08:54] WEll, you *could* add perl-modules to $base in /usr/share/debootstrap/scripts/intrepid [08:55] ..if you're in a hurry. [08:55] <\sh> soren, yes..that's what's next on my list [09:01] <\sh> soren, $base doesn't help... [09:01] <\sh> soren, imho $required is better [09:02] <\sh> soren, but doesn't solve it ;) [09:05] <\sh> now it's mawk [09:05] <\sh> which pre-depends on -> voila libc6 [09:11] bah, sebner isn't here. [09:12] LaserJock: give the bugsquad a list about bugs that they really should just leave alone? [09:12] LaserJock: i've suggested that in my current mail to them [09:13] ScottK: people who assign MOTU to a bug to get it fixed faster only do so once, though.... [09:13] and, if done well enough, tell their friends, so they don't make the same mistake [09:15] ScottK: ditto those who do the entire ~ubuntu-dev [09:15] <\sh> damnit...working on hardy sbuild...better then nothing [09:20] /usr/share/debootstrap/scripts/intrepid is empty on my debian system :/ [09:20] <\sh> white, ln -s gutsy intrepid ;) [09:21] :) [09:21] i'll see, if it works now [09:21] i am using cowbuilder, so --include does not really work [09:22] E: Couldn't find these debs: zlib1g, [09:22] bah, i only want a base.cow here :/ [09:29] hum, can we change the icon of revu-uploaders to be less similar to ubuntu-core-dev? :) [09:29] <\sh> white, forget it...it's a perl pkg bug...see #ubuntu-devel [09:30] <\sh> white, soren determined it, and hopefully is fixing it ;) [09:31] <\sh> ScottK, claws-mail* <--- should we drop the old sylpheed-* transitional packages now for intrepid? [09:35] \sh: Unless we had the old packages in Hardy, we don't need them any more. [09:35] <\sh> wgrant, ok...so we can hopefully sync it from debian now... [09:37] \sh: We'll be able to sync a lot of stuff again now that Dapper isn't relevant. [09:41] <\sh> wgrant, sure [09:52] hm, shouldn't audacious default to pulseaudio in hardy? now it uses alsa [09:52] tjaalton: I smell an SRU. [09:53] wgrant: yep, me too [09:53] and it doesn't seem to have a systemwide config to set it in the meantime === RAOF_ is now known as RAOF === Allan_ is now known as Hit3k [10:14] morning norsetto [10:14] jpatrick: hi there [10:26] I have question regarding getting a fix into both intrepid and an as an SRU. Will the same debdiff be used and just uploaded to different archives or do I need to prepare different debdiffs? [10:27] <\sh> hmmm [10:28] rexbron: The latter. [10:28] The versioning is different. [10:28] ok, one should be versioned -0ubuntu2.1 and the other (for intrepid) be -0ubuntu3, even though they are the same? [10:28] That's right. [10:29] ok [10:42] wgrant: audacious fixed :) [10:44] tjaalton: What did you have to do? [10:44] wgrant: patch bmp_default_config [10:44] Aha. [10:45] like patch 003 does [10:45] changes the theme [10:56] morning [11:16] emgent: good morning to you ;) [11:18] heya tseliot :P [11:20] dholbach, I'm not sure how I should handle debian/changelog for -proposed updates [11:21] LucidFox: stick it as hardy-proposed, iirc. [11:21] as the target [11:21] Yes, I know, but I'm modifying a version that is already in hardy-proposed [11:21] should I increment the version number? [11:21] i expect so - else it won't get accepted [11:22] then dholbach is right, my debian/changelog _is_ incorrect [11:32] On an unrelated note, I posted a Debian bug about old FSF address in debian/copyright, but the maintainer is reluctant to change it until upstream does [11:33] does it have merit? [11:34] LucidFox: Technically but it's not really worth worrying about. [11:34] lucidfox: personally, I think it makes sense [12:05] http://www.colectionarul.com/existenz1.html [12:06] ex1stenz: ? [12:11] http://www.colectionarul.com/existenz1.html [12:11] ex1stenz: That looks like spam to me. [12:12] has revu opened for intrepid? is anyone planning to package jmeter? [12:18] \sh: Yes (drop the transitional packages). === rraphink is now known as raphink [12:30] Hobbsee: random.. [12:34] persia: Unison backport is done (IIRC it was you that had some interest in this). [12:39] Hobbsee: Thanks for the support on bugsquad. [12:40] ScottK: NP - but us adding to their documentation of bugs not to touch might be a good idea. [12:40] ScottK: I felt some responsibility, and wanted to see it to avoid as much noise as fedora got, but I'm not a user. [12:40] What's the next step: does it need testing or something? [12:40] Hobbsee: Agreed. I discussed it with bdmurray and I'd thought he was going to do it. [12:41] persia: At this point it'll still be building and such. I'd suggest leave it for a bit and see if there's a user push for it. Personally I'm not in a rush since a lot of people are still using older Ubuntu versions. [12:42] ScottK: That mirrors my thoughts on the matter. I just didn't want to miss a process step if there was something pending which required action. [12:43] The way Unison tends to break on the wire between versions is a definite problem with Unison. One in release and one in backports isn't so bad. [12:43] persia: OK. Thanks for looking after it. [12:44] Sure. We ought have the new one for intrepid, and so with the backport for hardy be covered until the next thesis, unless someone really wants to push an SRU. [12:49] Whoever was looking after pulse by default issues ( TheMuso, was that you) might be interested in http://nenoblog.net/?p=4 [12:50] ScottK, i think the proposed solution is now to use nspluginwrapper even in i386 and let libflashsupport return [12:50] (the issues were mainly flash/firefox related) [12:51] nenolod: Is there a bug for that? [12:51] there is no bug (yet) [12:51] (and keep pulse as is) [12:51] the issue is that the patch is not guaranteed to work in the future [12:52] nenolod: Ah. It'd probably be accepted :) [12:52] and .. i mean it's an ugly hack! [12:52] heh. [12:52] then again, so is the "appease josselin mouette" hack [12:52] which is admittedly done the same way, and by me [12:52] nenolod: I'm failing to see why a blog post is better than filing a bug. [12:53] wgrant, i'm failing to see how the patch was accepted in the first place [12:53] wgrant: There's a process issue here as well as a technical issue with the patch. [12:53] wgrant, it is clearly wrong [12:54] broonie: Surely, but nenolod is about a lot, and active enough to know the right people to poke. [12:54] Nether of which are best addressed by an "Ubuntu sucks" blog post. [12:54] ScottK, it's not a ubuntu sucks blog post [12:54] Nether/Neither [12:54] "Yay! Ubuntu patches my code horribly wrong! And I don't even bother to tell them!" [12:54] it's a "this person made an ubuntu patch, it was horribly wrong and it ticked me off" post [12:54] nenolod: OK. If you say so. Maybe it was an "Ubuntu developers are idiots" blog post then. [12:55] wgrant, they could have easily done about 2 seconds of clicking around on launchpad, saw that i was on IRC, and then went "hey is this a good way to do it" [12:55] and then i would have gone, "fix PLUGIN_FILENAME() and use my previous patch, as that will always work" [12:55] nenolod: I dispute its possible to find anything useful in Launchpad in 2 seconds. [12:56] haha [12:57] ScottK, well, i was more annoyed that nobody actually poked me before uploading such a hideous patch [12:57] i would have been happy to ensure it is done correctly [12:57] which i will get around to doing [12:57] * norsetto wonders since when ubuntu-motu has become a support list [12:57] but i should have been to bed about 3 hours ago :p [13:00] norsetto: it's not, but people don't read list descriptions. [13:00] norsetto: and probably since some of the MOTU's stupidly started to answer them. [13:00] Hobbsee: Oh, you mean launchpad-users isn't for requesting CDs? Damn. [13:00] * Hobbsee beats wgrant [13:01] clearly those people don't work enough retail - in retail, you learn to not let the stupids get away with things, because it'll encourage them to keep trying. There are definite parallels with the MOTU ML. [13:01] (not saying that the MOTU ML people who ask support questions are stupid, but...) [13:02] Hobbsee: Exactly. Same with people who answer support queries in #ubuntu-devel - they're just encouraging. [13:02] *encouraging it. [13:02] wgrant: exactly. [13:02] wgrant: better to send them away, so they don't try it again, for their next question. [13:02] Mhm. [13:02] same with hardy stuff in #ubuntu+1, too. Topics are hard. [13:04] Previously I thought #ubuntu+1 redirected to #ubuntu until later in the release cycle. [13:04] I'd hate to have any end users thinking running Intrepid is a sane thing they can do and get help with. [13:04] ScottK: it usually does. [13:05] ScottK: Amaranth whined repeatedly, until they reopened it when intrepid's archives were open for proper development. [13:06] Hobbsee: OK. I don't see the sense in it, but whatever. It sounds like inducement to idiocy to me, but who knows. [13:06] ScottK: as for how that will make the quality of the end users better, i've no idea. [13:06] and their feedback [13:07] IMO if you know enough to provide useful feedback at this point, you don't need #ubuntu+1 [13:07] ScottK: well, that was my thought on it too, but if that's the way they want it, then that's how they can have it, as long as they're doing the moderating, and not me. [13:07] Right. [13:07] <\sh> ScottK, sync requested :) [13:07] \sh: Great. [13:07] heya \sh :) [13:07] ScottK: then again, if circumstances regarding the irc ops team were different, i probably wouldn't be saying that. [13:09] <\sh> hey ember [13:09] <\sh> aeh emgent [13:09] <\sh> ScottK, I compiled new claws as well for hardy...you could start to deal with backports for it :) [13:09] :) [13:10] \sh: File a hardy-backports bug, say it builds, installs, and runs and then ping me. [13:10] \sh: when you have time see query [13:11] that patch will make audacious segfault at exit too [13:11] * nenolod headdesks [13:12] what's the procedure for recalling that upload? [13:13] i've commented on the bug, hopefully someone will read and deny that upload for inclusion in 8.04.1 [13:14] nenolod: It needs an SRU to fix it. [13:14] !sru | nenolod [13:14] nenolod: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [13:14] nenolod: I don't think it can be recalled at this point: more likely updated with a new upload [13:14] which will of course be denied [13:14] thanks :P [13:14] persia, bummer. good thing nobody is using intrepid at this point [13:14] Why would it be denied? Segfault at exit is pretty critical, and the SRU team has been talking about making it easier to fix bugs in hardy anyway [13:14] mok0: around? [13:15] sebner: yeah [13:15] persia, the patch causes the segfault [13:15] persia, :) [13:15] nenolod: The people who decide stuff on SRUs are different than the one that uploaded it. [13:15] persia, it also causes potential doublefree [13:15] sebner: wassup [13:15] nenolod: Right, which means there needs to be a new patch that doesn't segfault uploaded to hardy [13:15] mok0: Maybe ScottK already told you. I took over the courier merge. I suppose it's ok for you? [13:15] sebner: oh, that's fine, np [13:15] mok0: I asked him to look into it. [13:16] strings in the cfg object are supposed to be strdup'd. the only exception is the skin path, which is leaked so that vendors can rebrand the player easily [13:16] ScottK: It's in good hands then :-) [13:16] I'm kinda busy with other stuff at the moment [13:16] mok0: Well at least I have 1 question. "- Removed trailing whitespace everywhere." Would you mind explaining that to me? [13:17] sebner: in the debian/ directory... [13:17] sebner: or rather, in FILES in debian/ :-) [13:18] mok0: an what whitespaces do they have? [13:18] sebner: white space at the end of the line _______ [13:18] really though ubuntu should push mudkip-player over audacious [13:18] audacious is this audiophile thing [13:19] mudkip-player uses gstreamer and looks exactly like XMMS [13:19] although i haven't released it yet :) [13:19] mok0: in every file? [13:19] nenolod: That's likely too late for hardy, but we'd welcome it in intrepid. [13:20] sebner: actually you shouldn't repeat that, if you're doing a merge [13:20] well, audacious has it's place too, but "XMMS replacement saviour" isn't it [13:20] audacious2 doesn't even load winamp skins :D [13:20] It seemed the best option at the time. [13:20] persia: I don't want to be too annoying, really, but any news on my application? [13:20] sebner: Best not to ask. Anyway, all application processing is public on the mailing list. [13:21] persia: I know, just wondering if that was an official vote the MC has 48 hours to vote IIRC. :) [13:21] sebner: it just makes the diff bigger and more unmaintainable. [13:21]