[00:07] NCommander, ng, nxvl: I just noticed that while pushing bzr --fixes doesn't change the bug, it does provide a little button on the trunk page to update the bug. I see it, and hope others do also: https://code.edge.launchpad.net/~nealmcb/electionaudits/trunk [00:07] oh [00:07] nealmcb: The link will also appear on the bug page. [00:08] --fixes shouldn't close the bug, because the branch might not be merged into trunk yet. [00:08] wgrant: ah - yes indeed - interesting [00:08] Although there's discussion about making that happen when it _is_ merged to trunk. [00:09] RAOF: Indeed, that would be good. [00:09] I wish the doc was clearer about all that. and I did see the conversation https://bugs.edge.launchpad.net/bzr/+bug/120050 [00:09] I disagree. [00:09] Merging stuff is changing, so it's not unthinkable. [00:09] Launchpad bug 120050 in bzr "'bzr commit --fixes' should have better documentation" [Medium,Fix committed] [00:09] ScottK-laptop: On which point? [00:09] It shouldn't get marked fixed until it's in the archive. [00:09] ScottK-laptop: I think we're talking about upstream tasks. [00:09] ScottK-laptop: I think we're talking about different things. [00:09] Ah. [00:09] Distros don't have branches (yet). [00:09] Ah. [00:09] Nevermind then. [00:10] And when distros _have_ branches, then I'd suggest that "fix committed" is a worthwhile status for "fix in trunk, but not yet in archive" :) [00:10] But actually, you have a point - when something is merged to trunk, it should be marked Fix Committed, not Fix Released. [00:11] I obviously missed the start of this conversation. I thought that was the expected status! [00:11] I guess I was thinking like changelog-closes-bugs. [00:11] Which is fine for after it's actually released somewhere. [00:11] it offers fix-available for trunk now [00:12] for non-ubuntu projects (which is where I started this conversation) [00:13] hi all. I'm doing my first backport since I've upgraded to hardy, when when I do a dpkg --compare-versions of 1.2ubuntu3~hardy1 against 1.2ubuntu3, first isn't anymore greater-or-equal than latter. Has something changed on the version policy? [00:13] s/when/but/ [00:14] cosmodad: ~ is explicitly less than nothing. [00:14] cosmodad: That's the expected behaviour; ~ always sorts after everything else [00:14] cosmodad, that's be design [00:15] wow. :) [00:15] hmm I could swear this has worked before. [00:15] Not a chance. [00:15] Backports, and SRUs require the ~ to make sure upgrades work sanely [00:15] NCommander: Not SRUs. [00:16] Oh right [00:16] SRU's use X.1 [00:16] ANd so forth [00:16] No, that's -security. [00:16] ok so I get this error: "ifupdown depends on netbase (>= 4.30ubuntu2); however: Version of netbase on system is 4.30ubuntu2~hardy1." How'd I resolve it properly? [00:16] SRUs use whatever the uploader wants, which is bad. [00:16] cosmodad: Find the ifupdown dep. [00:16] hmm - but just clicking on "fix available" on one of those pages and hitting "update" doesn't do anything. and putting a comment in the box adds a comment but doesn't change the status [00:16] Er, Fix. [00:16] wgrant, wait .... seriously? I thought SRU was standardized on the version it used [00:17] wgrant, and security isn't always standardized. There are some oddball exceptions [00:17] NCommander: No - that would make sense. [00:17] yay, NCommander is here [00:17] wgrant: well I backported netbase myself, so what do I need to fix? how to version the package? [00:17] * NCommander notes that backporting a base package like netbase is a bad idea [00:17] NCommander: Security is always X.1, unless the same version is in different distroseries, in which case it's X.Y.MM.Z [00:17] (Y.MM being the distroseries version number) [00:17] wgrant, clamav using backport versioning [00:18] wgrant, mostly because that's what clamav uses for security [00:18] or something to that effect [00:18] * NCommander notes clamav sucks but yeah [00:18] NCommander: I know, but it's just one debian revision number which I require. [00:18] cosmodad, your asking to break your system [00:19] anyway, to resolve your issue [00:19] You must backport every rdepend that has binary:Version depends [00:20] (beside the obvious chance of regressions, this is why we try to avoid backporting packages with rdepends out the wazoo) [00:23] NCommander: True, ClamAV is a very special case. [00:23] Like Firefox. [00:24] NCommander: I backported both ifupdown and netbase. They depend on each other, and no other rdepend is affected as the other's rdepends are ok with respect to version numbers. [00:24] NCommander: so I don't see what I'm missing. [00:25] cosmodad, you need to edit the control files to also make sure all the version numbers match [00:25] I emphasize again that this is a horribly stupid idea if you care about your computer [00:26] NCommander: on numerous backports I've done before, I never touched the version fields of debian/control. How come it is required now? [00:26] is it because of the circular dependency? [00:27] Because there are likely hardcoded version numbers for a reason [00:27] hard-coded in control you mean? [00:27] yeah [00:27] I'm going to be blunt. Unless you explain why you need netbase on hardy and can't upgrade to intrepid, I don't think I can help you anymore; what your trying to do is absolutely crazy. [00:28] NCommander: intrepid is still beta, and the versions of ifupdown and netbase I require fix a bug that makes my wifi work when starting up my machine and possibly also when I recover from STR/D. [00:29] NCommander: I'll reconsider doing what I do if you'd be so kind and re-explain to me why this is so crazy. [00:29] I still don't see the point as this is just a minor change. [00:29] * NCommander bashes his head into a wall a few times [00:31] just for the sake of knowledge, please explain. [00:31] netbase controls ipup/ipdown/etc. Looking at the changelog, those commands had some internal changes to the way they handle networking, and in addition, should there be a incompability, you are promised to break your machine [00:32] If you break your machine [00:32] No one will be able to help you, and you will be SOL [00:34] I see. And why couldn't a simple reinstall of the old versions fix such a problem? [00:36] wgrant: I'm also surprised that although launchpad updates the bug page about the fix in the branch, it doesn't send mail about that. Anyway, this discussion should go on in #launchpad, but I just had wanted to track down those situations in ubuntu where this stuff does work, based on queries raised in #launchpad. thanks, all! [00:37] nealmcb: Hmmm, that lack of mail sounds like a bug. [00:39] geser: yes I can do it tomorrow [00:41] what am i doing wrong if i get "dh_installchangelogs: I have no package to build" [00:43] directhex: Trying to build arch-all packages on !i386? [00:44] RAOF, isn't that an ubuntu issue, not one you meet when using dpkg-buildpackage ? [00:45] Possibly. Although you could get it by running a build with the smart arch-all flag (-a ?) locally, I think. [00:52] it's arch:any [00:52] but now you mention it, the -dev package ought to be all [00:59] RAOF, somehow you're right - the arch:all package builds fine, the arch-any packages are ignored [00:59] wgrant: I added comment about lack of --fixes mail to that bug I noted before. thanks again [01:03] NCommander: Clamav had backports revision numbers in -updates and -security because it lived in backports for a while and then got copied over once it was well tested. [01:04] ScottK, sounds like loads of fun ;-) [01:04] It was. [01:05] OTOH, getting the same clamav version in 4 releases with all the rdepends working was kind of my thesis project for my core-dev application. [01:06] Just to pick one particularly 'fun' example, if you look at avscan in Dapper you'll find the -updates version is the Dapper Debian packaging, the Feisty base package, and one file grabbed from the Hardy version. [01:07] o_o; [01:08] ScottK, you need to look at the subversion backport [01:08] It got tested [01:09] NCommander: OK. I like sticking with openssl. [01:09] Since that's what Hardy already does. [01:09] How do you feel about that? [01:10] Works for me since its the path of least resistance so to speak [01:10] ScottK, it also lets me backport 1.5.2 once I find some piece of mind. [01:10] OK. Is there a debdiff for that in the bug? [01:10] ScottK, should be [01:11] K. What's the bug number again? [01:11] ScottK, also look at this one https://bugs.edge.launchpad.net/hardy-backports/+bug/276016 [01:11] Launchpad bug 276016 in hardy-backports "Please backport clamav 0.9.4 from intrepid" [Undecided,Confirmed] [01:12] Hrm [01:12] We aren't ready on that one yet. We need work on the rdepends. [01:12] Need to figure out what to do about avscan. [01:12] https://bugs.edge.launchpad.net/hardy-backports/+bug/265065 [01:12] Launchpad bug 265065 in subversion "Subversion 1.5.1 does not work with SSL certificates" [Undecided,New] [01:14] ScottK, also https://bugs.edge.launchpad.net/hardy-backports/+bug/243583 [01:14] Launchpad bug 243583 in hardy-backports "Can not install libqtwebkit-dev after libqt4-dev backport install" [Medium,Incomplete] [01:15] ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/241560 [01:15] Launchpad bug 241560 in hardy-backports "Please backport bugzilla 3.0 from Intrepid to Hardy" [Wishlist,Triaged] [01:15] :-) [01:16] NCommander: I've stared at that one a bit, but not with enough alcohol in my bloodstream to actually come op with a solution (243583) [01:16] I posted a solution [01:16] A backport of webkit fixes it [01:17] or at least it did [01:17] THat being said, libqtwebkit was removed from intrepid -_-; [01:18] It's qt4-webkit now [01:18] Right. You don't want libqtwebkit [01:18] * ScottK-laptop goes to help the 5 year old clean the kitchen [01:20] ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/257211 also [01:20] Launchpad bug 257211 in rsync "please backport rsync 3 from Intrepid to Hardy" [Undecided,Invalid] [01:25] ScottK, also https://bugs.edge.launchpad.net/hardy-backports/+bug/260998 [01:26] Launchpad bug 260998 in hardy-backports "Please backport Xen 3.3 from Intrepid" [Wishlist,Triaged] [01:41] What exactly is a lintian out fo date standards warning? [01:42] csilk: A warning from lintian that the package asserts compliance to an old Standards-Version. [01:42] How can I rectify this? [01:42] Generally you don't. [01:43] csilk: Ensure that the package complies with the newest version of Debian policy, and update the version number in debian/control. [01:43] wgrant: Unless we're getting the package from Debian, then you don't [01:44] ScottK-laptop: Good point. But I would have thought it should be well known that you only make minimal changes in Debian-derived packages. [01:44] wgrant, as far as I'm aware the package meets the latest debian policy. I'll just ammend the Standards-version: fiel din control, i assume that iwll remove the warning [01:44] csilk: As ScottK says, you would only do that if it was not in Debian. [01:44] wgrant: Right, well Ubuntu Policy specifically says not to change it now. [01:45] And you can't say "as far as I'm aware"; you need to check. [01:45] ScottK-laptop: Oh, good. [01:47] what is the difference between Depends and PreDepends in a ubuntu package? [01:48] Same as in Debian. [01:48] csilk: As ScottK says, you would only do that if it was not in Debian. [01:48] wgrant, it's not in debian [01:49] csilk: Ah, OK. Probably best to only make minimal changes at this point in the cycle, however. [01:49] fyi, this is the first package I've ever done in preperation for revu [01:50] How did you get the old standards-version in the first place if it's a new package? [01:50] I have no idea, That's what dhmake did for me [01:55] wgrant, any idea why dh_make would do that? [01:56] csilk: Because it's old, probably. [01:57] wgrant, the version of dh_make I'm using is the latest availabel via apt-get install [01:57] *available [01:57] unless of course that is a minor version out of date [01:57] either way, i changed it to the latest version considering this is a new package [01:58] Well if you're using the Hardy version you're getting what was current when Hardy was released. [02:00] I'll be testing this in a chroot intrepid [02:03] Brilliant, lintain returns no errors and no warnings after I fixed the distclean option :D [02:03] *lintian [02:04] csilk: Look in hardy-backports for a newer version. [02:06] will do [02:18] monopd suggests a package not included in Intrepid (atlantik)... who would I forward a debdiff to to have it uploaded? [02:20] ryanakca: atlantik was part of kdegames in KDE3, but not ported to KDE4. [02:20] So it's gone. [02:20] ScottK-laptop: no, to have the suggests removed? [02:20] Ah. [02:21] ryanakca: I'll take care of it. [02:21] ScottK-laptop: http://ryanak.ca/~ryan/monopd_0.9.3-4ubuntu1.debdiff [02:23] ryanakca: You forgot the maintainer change. I got it. [02:24] ScottK-laptop: splendid, thanks :) [02:25] hey ScottK [02:27] Heya NCommander. [02:27] Subversion is still building. [02:27] \o\ [02:27] There were a bunch of other backports I asked you to look at ;-) [02:28] Yeah. Subversion was the one I agreed to look at. [02:29] -_-;;;;;;;;;;;;;; [02:29] I'll do the qt webkit one too. What's the bug number? [02:29] ScottK, sudo look at backports [02:29] :-) [02:29] * ScottK-laptop is on break. jdong is Mr. Backports this fall. [02:29] ScottK-laptop, jdong hasn't been active it seems [02:30] ScottK, there a lot that have no need for uploads, just need an ACK [02:30] https://bugs.edge.launchpad.net/hardy-backports/+bug/243583 [02:30] Launchpad bug 243583 in hardy-backports "Can not install libqtwebkit-dev after libqt4-dev backport install" [Medium,Incomplete] [02:30] * ScottK-laptop smacks jdong in the head to get his attention. [02:31] Right. I'd really rather he did those. [02:31] Some of them are almost a month old [02:31] And since I'm not a backporter, I can't actually approve them -_-; [02:32] NCommander: What exactly am I approving on that one? [02:32] nellery: hi! [02:33] the webkit backport, but I'm still not 100% its the right fix, I wanted someone else to perform a sanity check on it to make sure I didn't misanything [02:33] I don't have the spare cycles to really consider it, nor do I have a hardy machine to test it on. [02:34] I'll reconfirmed that backporting webkit makes things installable, but webkit has a rather nasty set of rdepends [02:34] It might break things worse [02:34] ryanakca: Uploaded. Thank you for your contribution to Ubuntu. [02:35] *reconfirm [02:35] Which would have to be tested [02:35] right [02:36] But the broken dev package also breaks loads of things [02:36] (Qt's development headers are uninstallable ATM) [02:37] Right and in Kubuntu webkit wasn't really used for anything in Hardy, so it's safe. I'm worried about Gnome though. [02:37] some of would consider a broken GNOME a feature ;-) [02:37] * NCommander runs [02:38] We could probably hack the **** out of libqtwebkit to work, but thats also asking for a nice headache when upgrade time comes [02:39] Yep. [02:40] NCommander: Wouldn't adding a conflicts/replaces in libqt4-dev on libqtwebkit-dev solve it? [02:40] Hrm ... maybe [02:40] We probably want that for upgrades anyway in Intrepid [02:40] As far as installability goes [02:41] I think the issue is that the QT webkit stuff got folded into the main QT4 packages and not split out. [02:41] Maybe we should simply backport the current Qt package, and then leave a virtual libqtwebkit one in its place [02:41] Probably less likely to hose things then mucking around new Qt + old webkit [02:43] I don't think we want to take the hardy-backports QT4 from 4.4.0 to 4.4.3 [02:43] Well, wasn't upgrading Qt in the first place what broke everything so miserably? [02:45] To 4.4.0. Let's not build on the problem. [02:45] Point taken [02:45] I think the problem is the new Qt has the development headers of libqtwebkit [02:45] 4.4.3 has the conflicts already, so I'll just add it to the hardy-backports one. [02:45] Yes. [02:45] We still have the problem that anything that depends on lib-qtwebkit will go boom [02:46] So it has to conflict/replace it. [02:46] We need a virtual package so we don't break anything that depends on libqtwebkit-dev [02:46] Does anything? [02:46] IIRC it was pretty much a late afterthought that was almost immediately regretted. [02:46] Checking [02:47] what was [02:47] libqtwebkit-dev? [02:47] Yes. [02:47] And libqtwebkit [02:47] (I know we have two backports stalled because its uninstallable) [02:47] Well, libqtwebkit is file [02:47] *fine [02:48] If we scratch the source package via a removal, the dev package would disappear, but NBS would prevent the library from going poof [02:48] * NCommander feels his hack meter go off [02:49] apt-cache rdepends says that only libqt has a depends on libqtwebkit [02:49] Which isn't a problem if you have the new QT4. [02:50] so its just a matter of turning libqtwebkit into a transitional package so anything that build-deps on it still works sanely if you have backports enabled [02:50] No NBS because we aren't touching the release pocket. Only backports. [02:50] The we just add provides to the mix then. [02:50] The/Then [02:51] We have a versioned depends [02:51] a provides won't do the trick [02:51] Where? [02:52] Back in 5 [02:53] sigh, jdong is being raped by Ron Rivest's homework assignment this weekend; please give me another 5 hours or so to be alive. [02:53] (yes that's the R in RSA) [02:55] Would i tbe benefical to update my version of pbuilder if building a package fro intrepid? [02:55] *for [02:57] Yes. That's also in hardy-backports [02:58] i'd of thought so, although i cant find it in hardy backports [02:58] Ah. Actually it's the new debchroot that you want. [02:58] Not pbuilder [02:59] NCommander: Where's this versioned depends? [02:59] I thought libqt-dev has a versioned depends on libqtwebkit-dev [02:59] So I guess the problem is mute now that I thought about it [02:59] mute/moot, but yes. [03:00] NCommander: Why don't you whip me up a debdiff for that then? [03:00] debchroot? [03:01] That (or something very close to that) is what pbuilder uses to make the chroot it builds inside of. [03:02] rite, so I'd need to update my version of that package [03:03] i cant find anything even similar to it in hardy-backports [03:07] NCommander: Didn't we want to add something openssl'ish to the build-dep for subversion? [03:09] ScottK-laptop, thats pulled in via the libneon build dep [03:09] So it's OK I don't see openssl pulled in as a dep to any binary? [03:10] Yeah, openssl -> libneon -> subversion [03:10] SOmeone already confirmed the debdiff works [03:10] (since I uploaded it to the PPA [03:11] OK [03:12] NCommander: Subversion uploaded. Thank you for your contribution to Ubuntu. [03:13] NCommander, don't be late [03:14] On what? [03:14] ^- cody-somerville [03:18] cody-somerville, ? [03:36] NCommander: Now he's got you worried. That's a success for a manager. [03:38] ScottK, not when his coworkers loose their mind and are committed [03:38] ;-) [03:38] * NCommander bzr ci's himself [03:42] Ok, I'm officially in the market for a sound card that will work on my Pentium 4 ubuntu machine...taking any and all recommendations! Thanks for your help. [03:42] RickZilla, I recommend anything off the shelve. [03:44] cody-somerville: I spent about 6 hours trying to troubleshoot why I didn't have sound on my Creative Soundblaster card on my Dell machine...I'm just looking to see what other lInux users are having success with [03:45] The 90's called, they want their soundcard back. [03:47] :-) [03:47] The machine itself is about 6 years old, so you're not too far off the mark. [04:53] If theres a package for an app already made but isn't available in the repo what policy dictates how it could make it's way to the repo, could i just check it's conformity then upload to revu or what? [04:55] Yes, but with the understanding that we aren't taking new packages for Intrepid any more. [04:56] Yeah I know, I'd be waiting till after the release of intrepid of course [05:05] how can i manual select the gateway? === nellery_ is now known as nellery [08:06] Someone should package up the hardy wallpapers, and put them into intrepid. [09:33] Hello. [09:34] How do I get the version of the package inside rules? === m-y-t-h-o-s is now known as mythos === nm-rocker is now known as asac [10:58] asac aka nm-rocker \o/ ^^ [12:27] directhex: hi, I'd like your opinion on a bug please [12:27] bug 211347 [12:27] Launchpad bug 211347 in sysinfo "sysinfo Fails to Find Hardware" [Undecided,Confirmed] https://launchpad.net/bugs/211347 [12:27] directhex: how hard would it be to make the list dynamic? [12:33] dynamic IWW? [12:35] oh, you mean stop forcing a size on the array, so it doesn't die when it finds too many foo or bar controllers? [12:38] oh lord, what dumb code. [12:39] james_w, busy with other tasks right now, but System.Collections.ArrayList is a dynamic-length array you can just add items to. hard-coded array sizes = moronic in extremis [12:42] OR, if you're looking for the "better" solution, look towards compiling the app against .net 2.0 using gmcs instead of 1.0 (we're dropping support for 1.0 apps in jaunty) - which adds generics, and you can use a string list generic [12:44] directhex: C has hard coded array sizes? [12:45] StevenK: C#? yes [12:45] No, C [12:45] StevenK, it's C# though. and it has a hard-coded size if you explicitly create a new array with 5 null objects in it [12:46] StevenK, using a smart language then chopping off a leg is dumb [12:47] directhex: You may want a hard limit, though. It depends on the situation. [12:49] not in this one. this is a fairly old pc and exceeds some of this app's hard-coded limits by more than 2x [12:49] generally speaking, when is lspci output gonna need hard-coded limits? === DrKranz is now known as DktrKranz [12:51] I dunno. The last program I wrote that touched lspci was written in Perl :-) [12:54] StevenK, it's pretty obvious the guy doesn't underdtand what he's doing anyway - to make a fixed size array, use String[n] not String[]={null,null,null,...,null} [13:10] thanks directhex [13:16] geser: can you please ack bug #277088 [13:16] Launchpad bug 277088 in libjrosetta-java "Please move package to universe" [Undecided,New] https://launchpad.net/bugs/277088 === azeem_ is now known as azeem [14:08] * marnanel has a cdbs question. I am packaging a GNOME application. I added "include /usr/share/cdbs/1/class/gnome.mk" to debian/rules. When it runs it attempts to run "configure" (which doesn't exist) rather than "autogen.sh". I should package it in the post-autogen.sh'd state? [14:08] s/runs/installs/ (and fails, obviously) [14:12] marnanel: yeah, or override the configure target [14:13] marnanel: but the former is probably better, unless this is a badly made upstream tarball you don't want to modify further [14:13] azeem: okay, thanks. just wanted to check before I did anything crazy. [14:14] marnanel: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml has some nice examples, but there is also a lot of crack in there [14:14] thanks! [14:14] * marnanel is amused that cdbs is supposed to make everything easier and people immediately start talking about the crack in it :) [14:15] well, some intermediate maintainers of it added a lot of stuff which did crazy automatic stuff most people frowned upon [14:15] it got a pretty bad reputation in the Debian community by that time [14:17] also, the most important variable, DEB_CONFIGURE_EXTRA_FLAGS is only explained halfway through that document, after "automatic handling of debian/control" etc. [14:23] does "Please subscribe ubuntu-universe-sponsors to any bugs for which you wish to request sponsorship." mean I shall assign the bug via launchpad to ubuntu-universe-sponsors? [14:23] tobi: which bug? [14:25] it's more a general question about the sponsoring process, the sentence above is from the ubuntu sponsor team page [14:25] tobi: by the way, subscribe means subscribe, not assign [15:20] Is it out of place to ask about packaging problems for PPA things? [15:21] marnanel: hey, if it's about the workings of PPAs the #launchpad is better, but for packaging things you can ask here [15:22] Okay... I packaged something and it appears to have built, and I added my PPA to sources.list and did an update, and yet apt-cache search can't find it. Is that anything obvious from the description? [15:22] s/built/built properly/ [15:23] marnanel: once it's built it will take a few minutes to be published, so if you were too quick you may have missed it [15:24] Okay, thanks [15:25] marnanel: it's published now, so another update might work [15:26] cheers [15:26] YAY [15:26] it's there [15:26] thank you [15:27] no problem [15:28] directhex@mortos:/tmp/moon$ dpkg -l \*moon\* | grep ^ii [15:28] ii libmoon-dev 0.8.1+dfsg-1 open source implementation of Microsoft Silverlight [15:28] ii libmoon0 0.8.1+dfsg-1 open source implementation of Microsoft Silverlight [15:28] ii moonlight-plugin-core 0.8.1+dfsg-1 open source implementation of Microsoft Silverlight [15:28] ii moonlight-plugin-mozilla 0.8.1+dfsg-1 open source implementation of Microsoft Silverlight [15:40] !pastebin | directhex [15:40] directhex: pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [15:42] directhex: ahahaha [15:42] sebner, sat in SVN, awaiting tagging & uploading ;) [15:43] directhex: that's great but don't ignore the warning ^^ [15:46] directhex: but why is it called moon? [15:46] sebner, dunno. blame upstream. the tarballs's called moon, and there's no moon source package, so... [15:46] * directhex moons sebner [15:46] rofl [15:46] crazy [15:48] sebner, i'm sure there'll be petitions to remove it from the archive once it goes in, but still [15:48] directhex: really? I always thought people trust debian guys with license things and so on [15:49] sebner, TEH PATENTZ! [15:49] sebner, (ignoring the usual details) [15:49] sebner, funny thing is, moonlight DOES contain code (c) microsoft. [15:49] sebner, that code is licensed under Ms-PL [15:50] sebner, Ms-PL is a GPL3-compatible license containing a full patent grant [15:52] directhex: I know. funny :) ... Please remove moon from Debian Unstable. Rationale: PATENTZ :P [15:52] sebner, did you read http://www2.apebox.org/wordpress/linux/51/ ? ^_^ [15:53] directhex: of course. I told you that that's a great post :P [15:54] sebner, apologies, i have memory issues so i don't remember who has & hasn't seen something [15:55] directhex: np. :) [15:55] directhex: btw, I'm wondering if you also hack a little bit on smuxi!? [16:02] sebner, i have little time for app development [16:03] directhex: what a pitty, seems you have a good knowledge of C# :) [16:03] sebner, only what i've picked up, and applied from my java-based undergrad degree [16:04] directhex: oh my god. the j word xD [16:04] directhex: can you explain to me what the purpose of silverlight is. and 2ndly my degree is also java based lol [16:04] eagles051387: to kill flash :P [16:05] silverlight = flash equivalent [16:05] eagles051387, silverlight is largely a flash competititor. there are other distinctions, but the easiest description is "microsoft's version of flash" [16:06] iirc all the streaming access to the olympics in the US was done via silverlight [16:06] wow [16:06] someone needs to dev a linux based flash player to compete with adobe flash and silverlight [16:07] well, gnash is a cross-platform reverse-engineered flash player [16:08] the problem with that is it doesnt work in firefox [16:08] moonlight is a cross-platform implementation of silverlight [16:08] i had it and with ff3 it never used to work for me [16:08] ahhh gotcha that would be sweet to have in repos [16:08] eagles051387: it will, with jaunty ;) [16:08] ? [16:08] jaunty is next aprils release [16:09] right. [16:09] already have the name for it [16:09] sebner, depending on how meebey feels, i might publish a moon package into my mono repo today [16:09] sebner, i want approval on the package as-is first [16:09] well when i get settled down with my lecture schedule im going to start helping pkg stuff and bug fix if i can [16:10] directhex: nice, I think I have moonlight through a firefox xpi installed but never used it so far [16:10] eagles051387, http://www2.apebox.org/wordpress/wp-content/gallery/00-single/moonlight.png is a couple of embedded silverlight objects in a web page, running via moonlight [16:11] nice [16:12] !info moonlight [16:12] Package moonlight does not exist in hardy [17:11] I was asked to put up a trunk build of metacity in my PPA. But of course that replaces metacity, metacity-common, etc. I put "Replaces:" those in the debian/control file, but it doesn't replace them, and the line doesn't show in apt-cache show. [17:12] * marnanel asked in #launchpad and they sent me right back here :) [17:12] marnanel: "Replaces" simply indicates that this package overwrites files from the package it replaces [17:12] you need more magic to have APT actually install that package in favour of the other [17:13] marnanel: why did you rename the package, instead of just bumping the version? [17:13] it seems both are not parallel-installable anyway [17:15] hm. a) I knew they weren't parallel-installable: I wouldn't have expected to replace one with the other if they were, unless I'm confused. b) all the other nightly trunk packages I've seen used different names. I worried I'd tread on the real maintainer's toes [17:15] hrm, ok [17:15] marnanel: what's an example for another nightly trunk, or are those local packages? [17:16]