[00:10] yea, but what do you use for the orig tarball when the package you are releasing IS the upstream? [00:10] you make an upstream release [00:11] psusi: if you want to make debian packages of your upstream release; you need to think og it as doing two releases. [00:11] psusi: a) an upstream tarball release that all distributions can use and [00:12] psusi: b) a .deb package for e.g. Ubuntu [00:12] but they are the same thing [00:12] psusi: what is your package that you say that? [00:13] having an ubuntu release means having changes from upstream.... I don't [00:13] e2defrag [00:13] the Ubuntu package explains how to turn your upstream tarball into a deb file [00:15] there is no upstream tarball though... [00:15] psusi: so e2defrag is useful for redhat and gentoo as well, right ? [00:15] maybe [00:15] there will be if you follow our advice [00:16] psusi: so, the best thing to do here is to make an upstream tarball. If your code is in bzr you can jsut do 'bzr export ../e2defrag-1.2.3.tar.gz' [00:16] or use make dist [00:16] or whatever you like [00:16] so you're saying I should create a tarball to be an upstream release... ok... now the tarball is already set up as a debian package, so no changes are needed to debianize it [00:17] psusi: thats ok, it doesn't really matter either way. [00:17] your tarball shouldn't include debian/ [00:17] psusi: though some people will argue that it does matter, they are wrong ;) [00:17] ha [00:17] then there's no .diff to apply to the upstream to arrive at a -1 [00:17] 3.0 makes this matter less somewhat [00:17] psusi: once you have that tarball, you can upload that to debian for other people to download [00:17] psusi: and do a debian package build [00:17] A zero-byte diff is fine. [00:18] how does that differ from a native package? [00:18] Laney: http://rbtcollins.wordpress.com/2009/12/18/upstreams-should-package/ [00:18] We can make changes without changing the packaging style. [00:18] psusi: a native package is harder for everyone else to work with [00:18] Other distros can more reasonably make changes without feeling second-class. [00:18] you already can... just append a -1 to the version [00:18] psusi: its harder to derivative changes [00:18] psusi: and harder to feed the changes back [00:19] plus you don't have to make a new upstream release for ubuntu-specific changes [00:19] An update can be uploaded without replacing the orig.tar.gz. [00:19] right... and that will happen if you decide to make ubuntu specific changes and add a changelog entry taking it to -1 won't it? [00:19] lifeless: I would have encouraged it to be in a branch which is then merged in ;) [00:20] Laney: That's what I do. It works excellently. [00:20] but until there are any ubuntu specific changes made, it's a native upstream release isn't it? [00:20] Laney: I think that that can be better, but that we should primarily focus on the collaboration [00:20] psusi: It may be the same as the upstream release, but it's not socially native. [00:21] psusi: if its a 'native package' we have to make a new tarball [00:21] psusi: but we're not upstream, so its inappropriate for us to do that. [00:21] psusi: thus, your packages should not be 'native packages'. [00:21] the only things that make sense as native packages are ubuntu-dev-tools, dpkg, apt, aptitude; possibly a couple of others. [00:22] in the entire archive. [00:22] Also the germinate-based metapackagse. [00:23] ah right [00:23] and translation packs [00:23] I remember a thread duking this issue out on debian-devel a few months back [00:23] so maybe a couple hundred, automatically generated packages [00:23] and one could argue against apt and aptitude as these are available in other places (e.g. fedora) [00:23] indeed [00:23] * ajmitch remembers the mess of wxwidgets being a native package in debian [00:23] I don't think native packages make sense except for the auto-generated case. [00:23] psusi: so please please please please just trust us [00:24] psusi: even if you don't get the distinction, we do. [00:24] ajmitch: That was wxwindows: wxwidgets has always been non-native. [00:24] As persia says, the dpkg stack could usefully have upstream releases. [00:24] persia: right, I couldn't remember if it happened before/after the rename :) [00:24] http://lists.debian.org/debian-devel/2009/09/msg00107.html [00:24] psusi: its fine to release a tarball that contains a debian/ dir; its *not fine* to upload a 'native package' to Ubuntu except when it really should be - and this should not be. [00:24] that's the thread, if you like debian-devel style discussions :) [00:26] ohh, so if someone does make a -1 release, they have to manaully create the .orig.tar? it won't just use the native release that came before it as the orig? [00:26] psusi: native packages don't *have* a .orig.tar.gz [00:26] psusi: they only have a tar.gz, containing everything [00:27] psusi: One would hope that if the project was on launchpad, the project developers would have made a release tarball downloadable from launchpad. [00:27] right... it IS the .orig.tar.gz... but you're saying that the tools won't figure that out when you make a -1 release, they have to have a human manually feed them the .orig.tar.gz? [00:27] Could there ever be an upstream release without an Ubuntu release? [00:27] psusi: I think we've found the knowledge you are missing. [00:28] hrm.... I think I see now [00:28] psusi: debian packages have two *nearly-totally-different* ways of representing the source [and this simplified to skip the whole v3-mess] [00:28] psusi: *normal* packages, which are a orig.tar.gz + a diff.gz (which can be empty - thats ok). [00:28] psusi: *native* packages, which are **just** a tar.gz [00:29] psusi: native packages can't be patched, and every upload uses a new entire tarball. [00:29] psusi: normal packages can be patched, and only the first upload includes a tarball. [00:29] well, I wasn't really planning on having the ubuntu and upstream releases diverge at all [00:29] imagine the fun of openoffice as a native package :) [00:30] psusi: Except you can't control that, because there are no maintainers in Ubuntu, so anyone might upload your package (e.g. library rename, etc.), and they may not be members of the upstream development team. [00:31] I suppose... [00:31] it's quite common, even for things like a rebuild [00:33] psusi: divergence is normal - you can't upload to e.g. mint linux [00:33] psusi: but they might need to do a bugfix; why would you make it harder for them ? [00:33] psusi: unless it also makes it *much* easier for you. [00:33] psusi: and this doesn't - all you need to do is *1* bzr export or make dist. Easy-as. [00:45] yay... upstream tarball release uploaded [00:58] siretart: FYI, I've almost got all the vlc xul192 commits cherry picked [02:09] well by golley I think I got e2defrag working with uninit_bg [02:09] that was much easier than I thought it would be [02:37] spoke too soon === EzraR_ is now known as EzraR [07:26] good morning [07:51] Morning all. I'm been patching the predict package, which is amateur radio software. It's been suggested that I push the branch into the Ubuntu ham developer branches area rather than predict; possibly because I've applied 4 patches. Opinons? === dholbach_ is now known as dholbach [12:27] james_w: thanks a lot for processing syncs :) [12:28] np [12:28] just replied to the haskell/ia64 issue too [12:29] * sistpoty|work reads mail [12:31] james_w: ok, will do for haskell/ia64... I'll also check about P-A-S, maybe it's already done in debian === dyfet` is now known as dyfet [12:34] james_w: got a few more syncs, if you don't mind: bug #548812, bug #561316, bug #535386 [12:35] Launchpad bug 548812 in libelf "FFE for lucid - libelf" [Undecided,Confirmed] https://launchpad.net/bugs/548812 [12:35] Launchpad bug 561316 in codelite "Sync codelite 2.5.2.4031~dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/561316 [12:35] Launchpad bug 535386 in gnat-4.4 "FFEs for ada packages in lucid / arm builds" [Undecided,Confirmed] https://launchpad.net/bugs/535386 [12:48] A question on subscribing the Ubuntu Sponsors Team, I've just made a branch which covers 4 bugs in a package, how do I deal with subscribing the team? Do it on each bug? [12:50] Ciemon: I guess one bug should suffice... maybe you can create a new bug report referring to the 4 bugs containing the sponsoring request? [12:51] well.. the first one I asked for a sponsor for a week ago will pick it up I guess [12:52] and in doing so, see them all. [12:57] that should suffice then, I guess [12:57] thanks for the confirmation === ogra_ is now known as ogra === rgreening_ is now known as rgreening [13:49] Ciemon: have you sent them all to Debian? [13:50] Hi sistpoty|work, I was thinking about uploading a new highlighting-kate to get building on armel/sparc, what do you think? [13:52] Laney: what's the problem with the current version? [13:52] Laney: no [13:53] sistpoty|work: it's too monolithic or something, upstream reworked it somewhat [13:53] trying to talk with the patch author, but I suspect I'll end up send them [13:54] ok then [13:54] I'm looking at your branch [13:55] Laney: from a quick look, highlighting-kate is a leaf package? if so, go ahead [13:56] yep [13:56] thanks a lot [13:57] thanks for all your work wrt the haskell stack! :) [13:58] it's a *lot* better now that we have the DHG [13:58] *nod* [13:59] Laney: all comments welcome, it's my first proper go. [13:59] I'm not particularly qualified to review the quality of the patches themselves [14:03] heh, highlighting-kate is still quite a hefty build [14:08] Ciemon: I find it weird that it first applies and then unapplies the patches before applying them once more for the build [14:14] Laney: can you tell me where you're looking so that I can check it out? [14:14] I just built it with pbuilder and saw it happen [14:14] I don't think you introduced that problem though [14:15] http://launchpadlibrarian.net/42798458/buildlog_ubuntu-lucid-i386.predict_2.2.3-2ubuntu1_FULLYBUILT.txt.gz <- you can see it there [14:15] applies the patches, cleans, applies them again [14:15] weird stuff [14:15] excellent, thanks for the link [14:18] Ciemon: you can look at that later, I'm going to upload your stuff now [14:18] good work [14:19] oh, wait :( [14:20] Ciemon: Yeah I think your stuff is technically fine, but … really it needs a feature freeze exception at this point in the cycle [14:20] !ffe [14:20] Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process. [14:28] Laney: not worried about getting into Lucid tbh (personally) [14:32] alright, then you should unrequest sponsorship until after lucid ;) [14:50] Um, please so. If there is a known good patch that isn't lucid targeted please push it to Debian and/or upstream. [14:50] s/so/no/ [14:50] that's already in hand aiui [14:53] I figured as much given the identity of the requestor, but wanted to make sure that the procedure was clear to all :) [14:54] ok.. just so I'm clear, unrequest sponsorship, and push the patches to Debian? The assumption being that we'll get it all on the synch for M ? [14:55] right [14:55] and if you don't hear from Debian, then you can request sponsorship again then [14:56] Thanks Laney. [14:59] Ciemon: One of the patches has already been pushed to Debian (by me) [15:00] BTW, There is already a patch delta between Debian and Ubuntu, regarding a fix done a few weeks ago by someone else. [15:00] (that has been fixed to Debian aswell) [15:01] I'd be suprised if this package is updated in unstable before FF. [15:35] dholbach: looks like b-d's didn't get synced in bug #556593... (at least I can't see them in the new queue), can you take a look please? [15:35] Launchpad bug 556593 in openttd "sync openttd 1.0.0-1 from Debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/556593 [15:36] sistpoty|work: WEIRD - I'll pass it on to jordi - I'm a busy myself right now [15:36] dholbach: ok, thanks! [15:36] no worries [15:48] Would truecrypt go in the Utilities section? [15:48] err- no.. that's not right.. [15:50] utils* [15:51] Sounds reasonable. [15:52] persia: is the u-u-s team still used? [15:53] Only by accident. [15:53] * sistpoty|work has subscribed ubuntu-sponsors to a number of granted FFe's that need sponsoring [15:53] persia: OK, so I can let my membership expire? Or do I need to subscribe somewhere else? [15:54] Well, if you want to be a sponsor, you'll want to join ~ubuntu-sponsors. [15:54] Do you want to be a sponsor? [15:55] persia: Yeah, I think so, although I'm not really active lately. [15:55] That's why I'm asking :) [15:55] I'm happy to add you to the sponsors if you're going to sponsor stuff :) [15:57] * persia needs to run off for a bit, but will fiddle group memberships if requested upon return [15:57] ok, cya [15:58] showard314 is here, i'll be right back [15:59] showard: ;-) [16:01] ha i just got your email [16:03] ubuntu-meeting looks open until 17:00, looks like motu-mentors reception can use it [16:09] showard, let's go there? [16:10] I see huats is here too, sure let's hop over [16:10] If there's a really long license for a package, should I include the whole thing in copyright or just the header and reference the full version in the source code? [16:10] MTecknology: Which license? [16:11] persia: it's their own license [16:11] Then it needs to be in debian/copyright. [16:11] Fully copy in debian/copyright then. [16:11] ok [16:11] Essentially, the end-user needs to have the license on their system when they install the package. For licenses in /usr/share/common-licenses/ we only ship a header and a reference to save space. [16:12] oh [16:14] persia: I was just curious because it's 176 lines, I suppose there's others that are a lot worse thoguh [16:14] Indeed. There's one debian/copyright that is > 2Mb [16:15] wow [16:15] what's that for? [16:16] I forget. [16:16] One of those ancient projects that has *lots* of different compatible licenses accumulated over the years. [16:16] the one for chromium is over 1M [16:16] <\sh> hmm... [16:16] Well, for chromium-browser. chromium itself has a much saner one. [16:17] hmm, right :) [16:18] sistpoty|work: Hi, I just collated the list of haskell packages on ia64. Wanna take a look? http://pastebin.com/yd2TTeLq [16:18] For upstreams considering new software: "chromium-browser" is a classic example of how not to do it: 1) please collaborate with other projects so that your code works as part of the wider ecosystem, 2) strive for license sanity, 3) pick a name that isn't already in use. [16:19] Oh, and 4) actually publish supported releases. [16:19] persia: It's the future. See Firefox. [16:19] :-( [16:19] huh, some arch:all stuff is in there [16:19] Laney: excellent, thanks a lot! [16:19] ScottK: Doesn't make it less of an example of how not to do it. [16:19] Laney: hugs98 can stay as well? [16:20] Agreed. [16:20] sistpoty|work: Oh, someone did an upload to fix the ftbfs [16:20] Laney: yeah, looks like it [16:21] good stuff [16:22] <\sh> grmpf....bug #554106 is fixed now and works, but having two monitors + ati oss drivers == no compiz anymore...this was diff this morning [16:22] Laney: others than that (and apart from the arch:all packages), the list looks good to me, at least from a glimpse [16:22] Launchpad bug 554106 in gnome-control-center "Gnome Appearance Properties dialog hangs when changing desktop effects" [Medium,Fix released] https://launchpad.net/bugs/554106 [16:23] TheMuso: FYI, powerpc for Kubuntu is looking really good this cycle. We even have a working (not oversize) and tested live CD. [16:29] So what do := and ?= do? [16:31] sistpoty|work: I guess you need to ack this then — bug 561583 [16:31] Launchpad bug 561583 in ubuntu "Remove Haskell packages from Lucid/ia64" [Undecided,New] https://launchpad.net/bugs/561583 [16:33] Laney: just go straight to ubuntu-archive (actually I wanted to prepare the list anyways) [16:34] ok then [16:34] Laney: do you know if these packages are in p-a-s in debian? [16:34] MTecknology: := sets a variable at parse time, rather than at runtime. ?= sets a variable at runtime IFF it currently has no value. [16:34] sistpoty|work: no they aren't === mathiaz_ is now known as mathiaz [16:34] Laney: do you think we should add them to p-a-s? [16:34] no, there's no need [16:34] they can't be tried again until ghc6 builds on ia64 anyway after the binary is removed [16:35] ah, good :) [16:35] which will probably have to be bootstrapped as ghc6 b-d ghc6 === qwebirc70998 is now known as RoAkSoAx [16:36] *nod* [16:39] persia: oh, so if the make file does := then I can't override it in rules? [16:42] * sistpoty|work heads home now... cya [16:42] seeya [16:45] MTecknology: Not easily, no. It's possible, but you'd have to dig in the make manual (no, not man make) and experiment. [16:46] persia: thanks [17:08] Is there any way to get a lit of directories that a package uses? the Makefile seems to do just about everything and doesn't really let me change the install directory which seems fine because it installs to /usr/bin/ anyway. [17:09] I also need to figure out how to make the Makefile make two binaries and it doesn't look like it wants to do that either :P - yay I get to learn more about rules [17:15] MTecknology: what ar eyou trying to do? [17:16] hyperair: package up truecrypt [17:17] MTecknology: you do know that the license isn't permissive enough for us to put into the archives, right? [17:17] MTecknology: they claim it's free but it isn't. [17:17] hyperair, okay, nice to catch you this time. Can you sign up as a review lead for a few hours for patch day? [17:17] nigelb: when is patch day again? [17:17] hyperair, may 5th (in all tz) [17:17] hyperair: oh... I thought that as long as the original source isn't modified at all it was ok [17:18] MTecknology: that's considered non-free. [17:18] nigelb: no problem. [17:19] hyperair: I thought sun java was like that [17:19] MTecknology: no, sun java was GPL'd, iirc. [17:19] MTecknology: Well, I would expect that their Makefiles could be considered source, too. Please be very wary on such topics, especially when you plan to upload it to PPA and thus even redistribute it through that … [17:19] hyperair, feel free to fill up the hours https://wiki.ubuntu.com/PatchDay [17:20] nigelb: cool. [17:20] Rhonda: I wasn't going to modify the source Makefile either, only make the rules file work with it. [17:21] That sucks- I'd now like to go yell at them - I was excited because I thought I could do something a lot of people might like. [17:22] MTecknology: If you can't convince them any other way, try to convince them to allow folks to distribute patches along with their source, and ship binaries with the patches applied. That's enough for multiverse (but not wonderful). [17:22] MTecknology: A lot of people like weird stuff and don't care about licenses. Within the boundries of our distribution though we should guard them from licensing weirdnesses instead of just pleasing them with something that might get them into troubles. [17:24] Alrighty, I already made contact with them and they just referred me to their license section 3, I guess I'll mention the problems with their license and ass if there's anything they could do about it.. [17:25] Freud'schian typo, "and ass"? :) [17:31] nigelb: done [17:31] * nigelb hugs hyperair [17:31] * hyperair needs to reorganize his irssi windows [17:31] thank you :) [17:32] nigelb: no.. thank you for organizing this =) [17:32] hyperair, I was hoping you'd cover that vast empty space :D [17:32] nigelb: unfortunately, i've got a project which requires me to sit in the lab from 8AM-5PM on weekdays. [17:33] nigelb: i'm willing to dedicate my entire weekend to it though [17:33] hyperair, then shall I change my times so we cover more hours? [17:33] hyperair: How many do you have currently? :) [17:33] hyperair: You do use /layout save and /save, right? [17:34] Rhonda: i do use those. but i kinda memorized the numbers =( [17:34] Rhonda: now that there are more #ubuntu-* channels, i'd like to group them together, which means shifting all the windows around. [17:34] hhaha [17:34] Then don't shift. :) [17:34] nigelb: i say just add every hour you're free =) [17:34] Rhonda: but adding them to the back feels messy =\ [17:34] I don't shift at the front. [17:35] Rhonda: anyway i have 42 windows, including the status and the hilight window [17:35] Up to 60 windows are pretty much fixed. [17:35] hyperair, It was either the late hours of evening or early hours of morning. If you're covering evening, I'll take the morning [17:35] When I drop in those early numbers I move a later window to the spot to not move them around. :) [17:36] #ubuntu-motu has replaced #debconf in spot 23 a while ago, e.g. ;) [17:36] nigelb: i'll add more hours on the day itself, if i'm free =) [17:36] nigelb: but mornings are off-limits for me. [17:36] nigelb: what timezone are you in? your hours seem really similar to mine [17:36] hyperair, thanks again :) [17:36] IST [17:37] Rhonda: ahah nice one. [17:37] I love mornings. Stable power. and nice and quiet here [17:39] nigelb: my early mornings would be past-midnight hours before sleeping =p [17:40] hyperair, I'm very bad at staying up late considering I need to get in to work at 6 am [17:40] nigelb: ahah i see. [17:40] hyperair, you're in malaysia? [17:40] nigelb: no, i'm in singapore. [17:40] or somewhere around there? [17:40] nigelb: but the timezone is there, yes [17:41] the same timezone [17:41] aah, I'm in india... closeby [17:41] * hyperair nods [17:41] how did you guess? [17:41] I read somewhere.. wiki perhaps? [17:41] hmm i see. [17:41] =p [17:41] my wiki said that i'm studying in singapore, but come from malaysia =p [17:41] well during holidays i go back to malaysia \o/ [17:41] the land of great food. [17:41] hyperair, my memory works sometimes ;) [17:41] great, cheap food =p [17:43] kklimonda: any progress on bug 368855 ? [17:43] Launchpad bug 368855 in cherrypy3 "formatwarning() definition from cherrypy3 incompatible with Python 2.6" [Undecided,Confirmed] https://launchpad.net/bugs/368855 [17:49] ari-tczew: hmm, still waiting for sru ack I think [17:51] kklimonda: I subscribed ubuntu-sru, because motu-sru is out of business generally. I think that jdong will check this bug soon [17:52] heh [17:55] ari-tczew: done. [17:55] :) [17:56] Laney: You said to unsub Ubuntu Sponsors Team, I don't see how to https://bugs.launchpad.net/ubuntu/+source/predict/+bug/552568 I can unsub myself but no-one else I guess I don't have the required access. [17:56] Launchpad bug 552568 in predict "hamlib rotctld support" [Undecided,In progress] [17:56] jdong: cool, thanks! [17:56] sure thing :) [17:59] Ciemon: I'll unsubscribe for you. [18:00] please sponsor debdiff from bug 368855 [18:00] Launchpad bug 368855 in cherrypy3 "formatwarning() definition from cherrypy3 incompatible with Python 2.6" [Undecided,Confirmed] https://launchpad.net/bugs/368855 [18:01] persia: thank you [18:09] jdong: you played much with the e2freefrag utility? found it the other day and have been using it to quantify the job that e2defrag does... it's kinda neat [18:09] psusi: yeah I briefly looked at its out put and it was kinda cool [18:10] would be interesting to see what effect pydefrag has on the free space fragmentation [18:10] oh yes :) [18:10] lol I'd like to try that some day when I have time [18:10] just run it blindly on / and do a before-after [18:11] e2defrag makes it clean up A LOT... gets rid of all of the fragments under ~32-64mb entirely [18:11] yea, exactly [18:13] also I found that it normally only shows up to 1-2 gb maxium free extent size... this is because mkfs defaults to a flex_bg size of 16 groups, which means every 16 x 128 mb = 2gb you have a bg that actually contains an inode table and bitmaps, thus breaking up the free space... you can mkfs with a larger flex size and get bigger free extents [18:38] hi i need to package kipi plugins for digikam,but i dont fully understand the process of merging my package with debian changes [18:38] can someone explain this to me? [18:44] shadeslayer: Could you give a bit more context? [18:44] persia: see #kubuntu-devel ;) [18:46] Oh, so it's just a normal merge: a package with Ubuntu changes and a new version in Debian? [18:48] persia: apparently there are some huge issues... [18:48] persia: Debian introduced loads of changes [18:59] Ciemon: yeah sorry, I forgot that not everyone can do that [19:07] persia: could you give this a glance and tell me what you think? http://dpaste.com/182929/ [19:09] MTecknology: Sounds like the easy solution is to name it realcrypt :) [19:10] persia: I hate doing that - I think it sounds MUCH nicer to give them proper credit in the name and everywhere else - I guess that's not what they want :S [19:11] persia: you think that would be the best solution? [19:11] i think they ned to know the difference between "need to" and "able to" [19:11] I specifically don't have an opinion on whether this is the best solution, and won't develop one :) [19:11] hyperair: hm? [19:12] s/ned/need/ [19:12] But http://www.ubuntu.com/community/ubuntustory/licensing may be useful as comparison [19:12] persia: I guess that renaming it like that would at least be enough to get it into multiverse and maybe universe if you can modify the whole thing under that new name? [19:12] MTecknology: Indeed. [19:13] MTecknology: he stresses that there is no need to patch, blah blah, when what is needed is the *freedom* to patch, not necessarily meaning that there will be patches [19:14] hyperair: ya, I mentioned it like that actually. It's true that it does work wonderfully like that, but by their definition of modification, just adding debian/ is an alteration afaict [19:15] MTecknology: they were always a sucky upstream >_> [19:15] persia: I really like that page, thanks [19:16] "Modification" means (and "modify" refers to) any alteration of This Product, including, but not limited to, addition to or deletion from the substance or structure of This Product, translation into another language, repackaging, alteration or removal of any file included with This Product, and addition of any new files to This Product. [19:16] repackaging is part of this modification [19:17] I guess if they want it distributed as another name it'll just lose it's reach a little bit and there will be the rist of users diassociating it with TrueCrypt which is worse for them... Espcially because that means I'll need to make a patch that completely renames TrueCrypt to RealCrypt [19:18] MTecknology: i don't see iceweasel and what was that other thing called losing reach. [19:19] icedove? [19:19] good point [19:19] "what was that other thing called" is somewhat indicative of the opposite of your point though ;-) [19:19] that's pretty much the exact same thing? [19:19] jdong: that's because i don't use debian. ;-) [19:19] :) [19:20] jdong: isn't there a way we could negotiate this trademark issue in ubuntu though? [19:20] has anyone tried talkign with upstream about a Ubuntu / Canonical Partners effort? [19:20] i mean we did it for thunderbird and firefox [19:20] lol we said that at the same time. [19:20] before we take this rebranding solution, at least make sure that indeed upstream wants nothing to do with us [19:20] jdong: but i didn't mean partners ;-) [19:20] hyperair: you can argue that mozilla is right now partner-esque. [19:20] :) [19:20] jdong: is it? [19:20] hyperair: in that it's not a purely RMS-y definition of FOSS [19:21] hyperair: I'm quite sure I'm not allowed to just arbitrarily add a patch to Firefox [19:21] jdong: either way, unless i was reading that email wrong, it sounded hostile. [19:21] jdong: nothing to do with us, referring to what i'm talking about or firefox? [19:21] MTecknology: truecrypt [19:21] jdong: really? i thought firefox was freely patchable.. [19:21] hyperair: I thought that was delegated to just the Ubuntu Mozilla Team [19:21] No. [19:21] Not even them. [19:21] then who? [19:21] The patches have to be "approved" by upstream to keep using the branding. [19:22] * hyperair facepalms [19:22] hyperair: I think I offended him some, not intentionally, I tried to be friendly thoguh [19:22] MTecknology: maybe. [19:22] persia: in practice does asac have to consult with Mozilla each time? [19:22] persia: or is it somewhat understood that he is trusted to make these decisions for Ubuntu as long as he doesn't do anything crackful? [19:22] * sebner pets hyperair [19:22] * hyperair woofs [19:22] hyperair: but yeah bottom line point is there's definitely a "special" "relationship" going on between us and Mozilla [19:23] jdong: i see. that makes sense, i suppose. [19:23] I wonder to what degree TrueCrypt would be receptive towards that [19:23] jdong: I don't know the details, but I think the process is that the mozillateam pushes patches upstream and packages official releases. [19:23] jdong: it's touchy [19:23] of course if the question was framed from the perspective that we-want-full-control... TrueCrypt will get pissy [19:23] but maybe a more constructive attitude can work towards a common ground solution [19:24] * hyperair nods [19:24] I just personally feel that the loss of branding is a somewhat big deal :-/ [19:24] maybe not to techie users, but the general audience definitely recognizes buzzwords [19:24] i agree. me too. [19:24] oh, the logo on that app will need to change too, won't it... [19:24] Indeed. [19:24] i was pretty annoyed with the strange globe we had instead of our firefox icon at first. [19:25] MTecknology: as an example, just look at CentOS vs RHEL [19:25] MTecknology: that's the degree to which things will need to change [19:25] jdong: i don't think things are that serious. [19:25] (iceweasel is an easier example because there's a magical build flag that de-brands automatically anyway) [19:25] The question is whether the brand has enough value to be worth the extra effort to support the brand. For very valuable brands, that argument can be made. For not so valuable brands, there's no point supporting more folk trying to use branding to control software. [19:25] hyperair: if you take a literal read of their license, I think it does evaluate to that serious [19:25] jdong: CentOS and RHEL are distros. that means every bit of branding in whatever packages they have that do have branding will have to be changed. [19:26] jdong: it's an entirely different scale, i should think. [19:26] hyperair: CentOS goes to great trouble to be binary-compatible with RHEL: it's really just branding changes. [19:26] (but yes, the scale is different) [19:26]