=== mthaddon changed the topic of #ubuntu-devel to: archive: main frozen for alpha-6, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [00:15] wgrant: I don't remember, did you ever sponsor any of my uploads? [00:15] NCommander: I did not. [00:15] ok [00:17] StevenK: ping? [00:22] wgrant: Where is this ALLCAPS complaint about an ALLCAPS EULA? [00:23] ion_: Only the description of my bug that has been circulating everywhere... Have you not seen it? [00:23] ion_: bug 269656 [00:23] That one. [00:23] Launchpad bug 269656 in firefox-3.0 "AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP" [High,Confirmed] https://launchpad.net/bugs/269656 [00:24] Thanks [00:26] The bug report is missing ‘HEREAFTER REFERRED TO AS “THE BROWSER”’ etc. ;-) [00:27] Sorry. [01:33] cody-somerville: xubuntu images are up for alpha-6 and awaiting testing [01:35] \o/ [01:35] <_Zeus_> this isn't gmail :P [01:36] _Zeus_: ? [01:36] <_Zeus_> that's a gmail smiley [01:36] it's not a smiley [01:36] <_Zeus_> oh? [01:36] it's an army [01:36] nop, that's a clasic celebration ascii emoticon [01:36] <_Zeus_> slangasek: whoa, you're the guy who answers like all the launchpad bugs [01:37] <_Zeus_> hmm.. [01:37] I am? :) [01:37] <_Zeus_> OH wait. i was thinking of \m/ [01:37] <_Zeus_> slangasek: yeah. Steve Langasek. [01:37] it's a guy with the arms up [01:37] <_Zeus_> ah [01:37] <_Zeus_> now i see him [01:38] _Zeus_: yeah, slangasek can be a little grumpy sometimes, but really funny when not :D [01:38] _Zeus_: oh, yes, I suppose I am him [01:38] * nxvl HUGS slangasek [01:38] * slangasek hehs [01:39] \m/ is a hand with 2 fingers up, the clasic ROCK ascii emoticon [01:39] :D [01:39] <_Zeus_> ya [01:40] <_Zeus_> anyone know how to remedy this? https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/271459 [01:40] Launchpad bug 271459 in qt4-x11 "Skype fails loading object file" [Undecided,New] [01:42] If a package is moved in Debian from contrib to main, what's the procedure to get it reviewed/moved from multiverse to universe? bug 269074 [01:42] Launchpad bug 269074 in cglib2.1 "Please sync cglib2.1 2.1.3.dfsg.2-1 (multiverse) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/269074 [01:44] <_Zeus_> no one has any idea i take it... [01:49] pochu: file bug, subscribe ubuntu-archive [01:50] cjwatson: is partman-auto-raid working ? I'd like to get it included on the server cd [01:53] mathiaz: I don't know that it isn't, but then again since we haven't been using it it's untested in an Ubuntu context [01:53] <_Zeus_> is mark shuttleworth ever on irc? [01:54] Yes [01:54] mathiaz: given its structure, it's harmless if not explicitly activated, so I have no objection to somebody adding it to the platform.intrepid/installer seed after alpha 6 [01:54] <_Zeus_> ion_: what's his username? [01:54] cjwatson: ok - I'll also have to write a MIR for it [01:55] zeus: sabdfl. You could have found out it by grepping this channel’s WHO list. :-) [01:55] Mark's IRC username is easily found; but he's a busy man, please don't bug him :) [02:11] persia: It turns out that reading debian/copyright doesn't help at all when it comes to discovering the conditions under which one is allowed to freely modify Firefox. [02:12] debian/copyright doesn't cover the copyright license of the firefox logo? [02:13] Well it's actually a Trademark issue, not a copyright issue. [02:13] But no. [02:14] I think it's perhaps a policy hole that was opened when we diverged from Debian on allowing such restrictions, but didn't describe how they are to be documented. [02:15] ScottK: the whole reason Debian forked was over the inclusion of a restrictive copyright license on the logo to enforce their trademark [02:16] OK. Maybe I'm tangled up in terminology then. [02:16] so either something's changed in the licensing that I'm unaware of, or there's a bug in debian/copyright for it not being documented [02:16] No, it's in the upstream file called "LEGAL" [02:18] Also the argument that we have 'abrowser' so one's right to modify/distribute is unhampere started to seem a bit specious to me when I noticed it's a binary built out of the firefox-3.0 source package. [02:20] So I'd suggest it's more correct to characterize it as an unbranded version of Firefox, not as an unbranded alternative that is actually DFSG Free. [02:20] I don't see the distinction there [02:21] If I grab the Iceweasel source package, I can patch it and upload it and distribute it in any MPL/GPL/whatever the third license is manner I want. [02:22] ok, so you're asserting the restrictions on naming mean it's not DFSG Free. [02:22] Yes. I don't think that's in question. [02:22] I don't either; I think it's just false ;) [02:23] It's just that I think "Don't worry about Firefox not being quite free, it's OK we have abrowser" is meaningless. [02:23] "The license may require derived works to carry a different name or version number from the original software." DFSG#4 [02:23] OK. I'm a muppet then. [02:23] So why do we have Iceweasel? [02:24] ScottK: because the Debian maintainer chose to rename it to free himself from the requirement to get everything approved by MozCorp [02:24] it was entirely the maintainer's choice, not something that was considered a requirement (by Debian at large) under the DFSG [02:25] I see. [02:26] I think it was a reasonable choice to make, because Mozilla's intertwining of copyright and trademark in the license went beyond the pale for free software projects [02:27] but I don't think Ubuntu taking the other path means a choice for non-freeness, either [02:27] I agree, but I think there's a limit to how far down that path it's reasonable for us to tread. [02:29] fwiw, if you want precedent in Debian for software with renaming requirements on modification, try apache and metafont :) [02:29] Obviously people will disagree, but it's my opinion (based on the incomplete information I have) that we went a bridge to far. [02:29] (but neither of those includes an EULA, of course) [02:29] Right. I'd have preferred we renamed, but understand the choice and accept it. [02:30] I don't understand how we could have accepted this (and I hope that at some point it'll be explained why this was OK). [02:34] those of us who were involved weren't exactly comfortable with it either, although we saw different trade-offs; but, reading Mitchell Baker's blog, it looks like it should turn out OK in the ned [02:34] end [02:36] I'm deeply curious about Mark's comment in the bug that staying with an older version without the EULA requirement like Fedora did was not an option for us. [02:36] To me that would have seemed like the easy right thing to do. [02:37] we can't do that with Firefox; they have a history of bundling security updates with other updates in such a way that they're infeasible to disentangle [02:37] same reason as Firefox has a standing exception for new upstream versions in stable releases [02:37] cjwatson: i have an update-motd, removing the initscript, all of the debconf configuration, etc. [02:37] I understand we couldn't have released that way, but release is a ways off yet. [02:37] kirkland: what did you put in place of the init script? [02:38] cjwatson: nothing [02:38] ScottK: that would have just landed us with the same problem after release, which would have been worse. This has been brewing for a while [02:38] cjwatson: pitti was pretty anti-init script for this utility [02:38] ScottK: it was better to get it out of the way [02:39] cjwatson: http://people.ubuntu.com/~kirkland/update-motd/ [02:39] cjwatson: i have not uploaded to universe [02:39] cjwatson: i understand it's middle of the night for you, probably [02:39] cjwatson: so no request to review [02:39] cjwatson: Thanks for taking the time to give me your perspective on it. [02:39] any reason not to upload it? [02:39] cjwatson: if you'd like to, though, i'm all ears [02:40] cjwatson: well, i do have one question [02:40] cjwatson: etc/cron.d/update-motd is being installed into place, rather than being generated via debconf/config/postinst [02:40] I'd just like to say that the objection to the init script was pitti's; I wasn't concerned by it [02:41] cjwatson: so users upgrading from 1.5 to 1.6 will get a question about what to do about a conflicting conf file [02:41] cjwatson: I understand ;-) we're all looking out for our best interest... no complaints from me. [02:41] there are sneaky ways around that, though they may not be worthwhile [02:41] cjwatson: i did put a lot of effort into the debconf code, and you recognized that, which I appreciated, but I think you're right in the end... just more room for bugs [02:42] cjwatson: so what i did in place of an init script was to add --disable and --enable options to /usr/sbin/update-motd itself [02:42] yeah, I think it was doing the right thing, but ... well, I'm debconf co-maintainer and even I can't just look at that kind of code and say whether it's correct or not [02:42] cjwatson: where --disable touches /var/run/update-motd.disabled, and --enable removes it [02:42] ah, ok [02:42] that sounds sane [02:43] cjwatson: that gives the flexibility i wanted ... to be able to turn it off without uninstalling the package or farting around with the cronjob [02:43] pitti and i came up with that in a private IRC conversation [02:43] kirkland: That doesn't mean it comes back on after every reboot does it? [02:43] much more intuitive than an init script, I expect [02:43] ScottK: nope. it's sticky [02:44] OK. Even though /var/run is tempfs? [02:44] it does throw an error message, if you try and run it when disabled [02:44] tmpfs> I was about to say the same thing :) [02:44] update-motd is currently disabled. [02:44] You might try: [02:44] * update-motd --enable [02:44] * update-motd --force [02:45] so where is the state stored between reboots? [02:45] i stand corrected, i didn't realize that /var/run was tmpfs [02:45] so it's not sticky [02:46] if you want to disable it over boots, remove the cronjob [02:46] the enable/disable is merely meant as a simple convenience for short term disabling [02:46] can I suggest /var/lib/ somewhere instead then? it seems like it ought to be sticky [02:46] cjwatson: sure, would /var/lib be the best place for it? [02:47] that would be my instinct, though the convention there seems to be to create a subdirectory [02:47] sorry for YA minor change [02:47] sure, that's easy [02:49] kirkland: I think you need to exit 0 after parsing --enable as well as after parsing --disable? [02:49] kirkland: /var/run is declared in the FHS to be not sticky, so it's a tmpfs ;) [02:50] kirkland: what's the point of echo 2>&1? [02:50] cjwatson: well, i mentioned in the manpage that it will enable AND run it immediately [02:50] if you want it to go to stderr, use 1>&2 (or >&2) [02:50] cjwatson: but i'm indifferent [02:50] ah, I didn't see that, OK [02:50] that seems reasonable enough [02:50] slangasek: thanks ;-) more knowledge > kirkland [02:51] >>, we hope ... ;-) [02:51] Haha [02:51] * slangasek laughs [02:51] :-D [02:51] "Want device .... used for digging food ..." "A spoon?" "Yes" [02:52] the diff looks good to me otherwise and should mean there's no contention about main inclusion [02:52] cjwatson: thanks for catching my broken stderr redirects [02:53] cjwatson: i'll exit 0 after --enable, and note in the manpage that it exits immediately (not updating the motd) [02:53] I don't care about that, if you prefer the other behaviour then it sounds completely sensible [02:54] I just noticed the asymmetry, that's all, but life is not necessarily symmetric [02:54] cjwatson: do one thing and do it well :-) [02:54] cjwatson: enable and exit [02:54] mkay [02:56] cjwatson: changes pushed to http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/ [02:56] cjwatson: i'll do some testing of the /var/lib changes, for sanity [03:01] cjwatson: what about purging the old /etc/init.d/update-motd script? [03:01] cjwatson: on upgrades, i mean [03:02] yes, might be reasonable with a version guard [03:04] cjwatson: can you point me to a package with a sample? [03:04] hmm [03:04] alsa-base.postinst [03:05] consolekit.preinst has a more paranoid version that removes it only if unmodified [03:07] dhcdbd.p* has an even more careful and (I think) correct version that removes it only if modified and deals with rollback in the event of failed unpack or configure [03:09] StevenK: you floating around? [03:09] NCommander: I might be [03:10] NCommander: only if you test some cds :P [03:11] Hobbsee: for what, and why? [03:11] NCommander: alpha 6! [03:11] * NCommander burns [03:11] Ew [03:11] *er [03:11] NCommander: https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-September/001134.html - get to it! [03:11] I can [03:11] good man :) [03:11] I didn't say I would ;-) [03:11] * NCommander runs [03:12] NCommander: you inferred it, and my Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ is nice and sharp, for if you don't... [03:13] Wow, haven't seen the pointy stick in quite a while [03:14] Hobbsee: your stick is in metric, and I'm in imperial. Its incompatable with me [03:14] * Hobbsee attacks bddebian with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ [03:14] NCommander: actually, i'ts both. [03:14] NCommander: Heh, nice one [03:14] NCommander: so, fail. [03:14] bddebian: which image are you going to test? :P [03:17] cjwatson: http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/debian/postinst [03:17] cjwatson: while I'm at it, should I go ahead and 'fix' the conf file overwrite prompt? [03:17] cjwatson: would that go in postinst, or elsewhere? [03:22] kirkland: TBH I'd just leave it, it's a one-time thing and only affects alpha users [03:22] cjwatson: fair enough! [03:22] postinst is fine [03:23] testing looked good, i'm going to upload, and email pitti [03:23] Hobbsee: None of the above? :) [03:23] he said he'd check email and review [03:23] bddebian: so you will face the Stick. Poor Man. [03:23] kirkland: ok, cool [03:24] cjwatson: as always, big thanks \o/ [04:42] cd === ScottK2 is now known as ScottK-laptop === ssweeny_ is now known as ssweeny === TheMuso_ is now known as TheMuso [06:23] Is there a tool that can track when packages are no longer built for a given architecture? I've hit this before, but have again run into some outdated arch-specific binaries for packages that will no longer supply them, and was interested in hunting for some tool to track everything out-of-date towards requesting they be removed as old, buggy, and unlikely to be fixed. [06:27] you're looking to track packages that have been dropped on /an/ architecture, but not on /all/ architectures? [06:30] if so, I'm afraid the only tool I know of for doing this is dak; unless pitti's NBS script happens to cover that case [06:32] Nope, the NBS script doesn't happen to cover that case. [06:33] And I'll admit to a little trepidation in trying to import Ubuntu into dak just to hunt for these. [06:33] * wgrant wonders where bug #271502 should go. [06:33] Launchpad bug 271502 in ubuntu "No ddebs for -backports" [Undecided,New] https://launchpad.net/bugs/271502 [06:36] persia: yes, I don't think importing the database into dak is the right way to go about it :) [06:38] No, probably not. And e.g. http://people.ubuntu.com/~ubuntu-archive/testing-ports/intrepid_outdate.html only covers main, which is only part of the list. [06:39] What's the best way to request removal of these? A bug listing all the individual binaries to be removed on a per-arch basis, or a pointer to the changed source? [06:41] (today's annoyance being the linux-meta binaries for *all* ports) [06:41] list of binaries [06:41] OK. I'll file a bug. Thanks. [06:42] Also, do you know of any way of generating the _outdated.* output for universe as well? [06:43] britney [06:43] it just needs to be fed the full Packages lists; this isn't done because the version of britney being used is resource-intensive [06:44] switching to a newer one is on my TODO [06:44] So if full packages lists are available somewhere, running britney ought do the right thing? [06:44] yes, if britney is invoked correctly [06:44] wgrant: Is that something that would be trivial to set up, or does it need someone to construct the code? [06:45] * wgrant can look into that. [06:45] wgrant: Thank you. === torkel_ is now known as torkel [07:39] slangasek, cjwatson: I've been picking through the changes between our acpi-support and debian's. [07:42] slangasek, cjwatson: I found there's a huge amount of changes Debian made, that didn't get rolled into ours. The package has basically forked in a major way. [07:43] slangasek, cjwatson: to try and bring things back closer together, I've cherrypicked a bunch of the changes that look understandable and safe to me. Here's what I've got so far: http://bryceharrington.org/ubuntu/ACPI/ [07:46] slangasek, cjwatson: Anyway, I'd like to hear your comments/encouragement before continuing with the next set of changes. The next set of changes get into some structural issues that significantly change how this package works, so would like to get your thoughts first. [07:50] hi cjwatson [08:02] bryce: I'm afraid I'm not going to be able to provide much guidance there as far as the correctness of such changes; I've been aware for some time of the Debian forking of acpi-support, but haven't had the bandwidth to chase it up [08:04] slangasek: hmm, do you think I should continue with pulling in selected debian changes? [08:04] for intrepid? probably only ones you confirm fix bugs :) [08:04] are Debian bug fixes ok? [08:05] so far I've just been pulling in ones that look logically correct to me just by eyesight [08:05] well, and a few that seem appropriate for thinkpads... [08:07] I think acpi-support upstream should be debian and not us.. [08:08] since we don't have anyone maintaining it ;) [08:08] bryce: if they're valid bugfixes that are relevant to us, sure; there's no requirement that you file bugs in LP before fixing them [08:09] tjaalton: I've been wondering about that [08:10] slangasek: okie doke. I plan to look through LP and see if we have bugs that these changes fix. [08:18] asac: ping [09:13] persia, TheMuso: any expectations of testing UbuntuStudio alpha-6 soon? [09:14] There was some testing going on 12-3 hours back. I'll see if I can get the results somewhere. Where do you need them? [09:16] sbeattie: ? [09:17] asac: was just wondering if bug 271654 was known already [09:17] Launchpad bug 271654 in ubufox "intrepid: on first run, firefox opens homepage in 2 tabs" [Undecided,Confirmed] https://launchpad.net/bugs/271654 [09:18] persia: on http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all [09:18] and whether ubufox was the right place to file it. [09:18] StevenK: no its not [09:19] sbeattie: can you reproduce this outside of liveCD? [09:19] asac: this was post install [09:19] asac: should have made it clearer in the bug report, but i'm a bit tired. [09:19] asac: Hm? [09:19] sbeattie: oh ok [09:19] slangasek: Aha! It's the amd64 variant that didn't get *any* testing. I'll see if I can do anything about that. [09:19] StevenK: sorry .. not you ;) [09:20] persia: ok, cheers :) [09:21] sbeattie: does this also happen when you move .mozilla away and start firefox? [09:21] asac: i can reproduce each time I start firefox after doing rm -rf ~/.mozilla/ [09:22] Hi [09:24] sbeattie: ok thanks. please add that info to the summary. (e.g. reproduce by removign .mozilla) [09:24] asac: sure thing. [09:40] hey, kann jemand über die konsole eine tv-karte initialiesieren? [09:40] <\sh> asac: with ia32-libs 2.2ubuntu13 flashplugin10 works now as expected...(well, I need to test the rtmp connections still) [09:42] hallo? [09:43] <\sh> stefan__: this is an english speaking channel [09:43] !de [09:43] to do that? [09:43] Deutschsprachige Hilfe fuer Probleme mit Ubuntu, Kubuntu und Edubuntu finden Sie in den Kanaelen #ubuntu-de, #kubuntu-de, #xubuntu-de und #edubuntu-de [09:43] why is nobody there? [09:43] I am not here. [09:44] lucky Answer [09:44] <\sh> stefan__: your question is better suited in #ubuntu (this is a development channel only) [09:44] oh, take sure, sorry [09:44] uhhhh [09:44] stefan__: The answer to your question is "Ja", but the procedure you need is best collected in one of the channels ubottu mentioned. [09:47] \sh: rock [09:51] <\sh> asac: uploaded [09:51] <\sh> asac: and air works too...(at least the installation ;)) [09:57] can i build a package for ubuntu on debian? using debootstrap? [09:57] sure [09:58] which release should i use? intrepid? [09:58] that depends which release you want to build it for [09:59] i'd like to submit the package for inclusion in ubuntu [09:59] that has nothing todo with building, Ubuntu does source-only uploads [09:59] pythonic: you should contact #ubuntu-motu for that [10:00] yes, but i should check that it builds on some given release [10:00] k, thanks [10:01] <\sh> asac: http://paste.ubuntu.com/47990/ <- I just installed the "Color Browser" app from the air showcase...and I ran it from its installation dir...this is the only cruft I have left. [10:01] \sh: sigh [10:01] <\sh> but it works :) [10:02] maybe ia32-libs should be ia32-all-libs-in-main ;) [10:02] \sh: yeah ... most likely just broken theme engine for KDE users [10:02] <\sh> asac: the libqt4engine.so for sure... [10:02] <\sh> what bugs me is gio modules ;) [10:03] oh .. i only looked at the bottom [10:03] <\sh> asac: air app installer... Failed to load module: /usr/lib/gio/modules/libgiogconf.so [10:03] <\sh> and so on [10:03] shouldnt gio be in ia32-libs too? [10:04] <\sh> that's libgio0 right? [10:04] <\sh> dpkg _l [10:04] <\sh> grmpf [10:06] <\sh> gvfs [10:06] <\sh> ah...I think that's not important [10:07] <\sh> air installer uses gtk file dialogs...and I think it tries to use now the gvfs stuff..the modules are in the gvfs server package...and I wonder if that is sane to include into ia32-libs === TheJosh is now known as therealjosh [10:13] hey [10:14] i am wondering, i have made a program with is a budget program written in gtk. How would I go about getting it into ubuntu? I know intrepid is already frozen, but is j??? a likely target? where do I go to find out about the process? [10:15] therealjosh, https://wiki.ubuntu.com/UbuntuDevelopment is a good place to start [10:17] so do i need to get involved in the MOTU team just for one package? [10:17] no [10:18] the easiest way to get your package into Ubuntu would be to find someone to do the actual packaging for you, or with you; a MOTU could help you with that [10:19] on the other hand, it would also be possible to go via Debian -- find a Debian developer to help with the packaging, and then the package will get into Ubuntu as well [10:19] So I should ask on #ubuntu-motu if anyone would like to package my application? [10:19] that would be better because it gets more coverage, correct? [10:19] thanks [10:20] i have to go [10:23] https://bugs.launchpad.net/ubuntu/+source/ffmpeg-debian/+bug/254201 [10:23] Ubuntu bug 254201 in ffmpeg-debian "feature regression: ffmpeg lacks some video encoders (like h263+, MPEG4, maybe more...)" [Undecided,Triaged] [10:23] does anyone know the rationale behind requesting the removal of these? [10:24] it's totally cripped several video-capable sip/jingle clients including empathy and ekiga :( [10:24] *crippled [10:24] Robot101: well, the archive admins don't accept mpeg based encoders in the 'main' archive [10:25] Robot101: the package has a script that disables some mpeg 1 decoders from ffmpeg, see debian/strip.sh in the source package [10:25] Robot101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433287 [10:25] Debian bug 433287 in ffmpeg "ffmpeg" [Unknown,Open] [10:25] so it was just an accident that they were there for 4 or 5 years before being removed? [10:25] more or less [10:26] there was me thinking ubuntu were being cool and more functional than debian [10:26] so can they go in multiverse? [10:26] Robot101: I'm not sure it has been discussed for ubuntu [10:26] siretart: is the discussion you had a debian or an ubuntu one? [10:26] seb128: they were in everything up until intrepid [10:26] seb128: both [10:26] now intrepid's ffmpeg is crippled similarly [10:26] debian's not had the encoders for a long time [10:27] seb128: the end of the discussion with ubuntu was "well, if debian doesn't accept them, we won't as well" (shortened) [10:27] siretart: who did you discuss this with? [10:27] I don't know if medibuntu is kind of "official" but at least non-free codecs should be added there [10:27] seb128: that was in sevilla with at least pitti and elmo in the room [10:27] Zdra: no it's not [10:27] siretart: sevilla, that was ages ago [10:27] I've not found a very good justification for them being removed in Debian either, tbh [10:28] siretart: we had no issue with those until now, I'm not sure why that's an issue now [10:28] bryce: pretty much what Steve said - I'm not going to be able to provide specific review unfortunately, so his general guidance sounds about right [10:28] seb128: so we do accept mpeg encoders in the 'main' component? [10:28] I can understand MPEG4 having people enforcing it, but H263 is very, very old... [10:28] siretart: I don't know and I'm not the one to decide, I think that deserve some thinking and discussion [10:29] Robot101: There's rather a lot of money to be made enforcing it. [10:29] seb128: sure. each time I started that discussion it was.. difficult [10:29] broonie: patents on H263? [10:29] because nobody wants to decide on that subject [10:29] siretart: is h263 that problematic? [10:29] IIRC, yes. [10:29] bryce: looks like you're doing the right kind of thing at least from looking at the changelog, though [10:29] seb128: I have no idea, TBH. there are patents on that, but I have no idea if its being enforced [10:29] does anyone have any /actual/ source of knowledge on this, rather than heresay? :) [10:30] s/ere/ear/ [10:30] oh, so this is what server everyone's on. I wish freenode wouldn't curl up and die like that. [10:30] siretart: I think that should be taken to the technical board [10:30] * broonie is seeing if he can dig up some notes from when he worked on this. === Hobbsee` is now known as Hobbsee [10:30] Robot101: use google patent search for h263 [10:30] like does Canonical have lawyers they can ask and get an answer [10:31] seb128: again? - well, I welcome you to mail the TB, CC'ing me. [10:31] siretart: patents merely existing isn't a problem, it's if they're actively enforced [10:31] yes, we do; technical-board would be the place to start for that [10:31] seb128: I'd love to see an unrestricted ffmpeg in ubuntu [10:31] Robot101: Even a laywer can't necessarily answer the question "Is it safe to distribute foo". There are many jurisdictions, and each is different. [10:31] (if it hasn't been through the TB already of course) [10:32] cjwatson: the problem is determining if a codec 'is actively enforced' or not [10:32] persia: given what patents are like, our question is usually a bit more like "can we afford to distribute foo, I think" [10:32] persia: right, but presumably Canonical's lawyers are used to opining on such vague questions :) [10:32] siretart: yes, I'm familiar with the problem [10:32] cjwatson: Well, perhaps, but I think it's a matter for the TB, rather than a lawyer hired by a sponsor. [10:32] cjwatson: from what I've heared from the ffmpeg people is that they are not enforced against non-commercial projects but for companies that make a profit from them [10:33] some ffmpeg developers are hired by companies that pay patent fee to develop and sell their products [10:33] persia: the body who would be sued, in practice, is Canonical; therefore Canonical deserves the opportunity to decide [10:33] siretart: on what exactly? MPEG4 I can very much understand, the MPEG people are very active in enforcing. H263 I'm not so certain. [10:33] it is very unclear if ubuntu would be considered as 'non-profit' in that context [10:33] I'm off for lunch, brb in 45min - cu later [10:34] persia: for example, there is a history (and I'm afraid I forget the specifics) of Mark saying that he was OK with distributing certain enforced-patent audio codecs but not others [10:34] cjwatson: Er. Well. Perhaps. I don't think it *should* be that way, but I can see that point [10:34] as in "I think this is worth it" [10:35] (actually I think it may have been more like "bring it on" but as I say I forget the specifics :-) ) [10:35] :P [10:35] cjwatson: I understand. The distinction is Mark as "representative of Canonical" and Mark as "leader of Ubuntu". Anyway, as I said, given the current environment, it may not matter, especially for the ffmpeg question. [10:36] there are certainly things that might be considered too much of a risk, though; Canonical in principle has quite deep pockets and it could get ugly [10:37] Sure. Canonical being sued is significantly less than ideal. That Canonical is the default body getting sued is likely also so. That said, this isn't the forum to address that. [10:38] http://www.kroah.com/log/linux/lpc_2008_keynote.html I'll just leave this here. [10:38] ;) [10:38] sykopomp: ok, now leave then [10:38] sykopomp: I'm not sure how that's relevant. [10:38] persia: Blame stdin, he told me this is where it belonged :) [10:38] sykopomp, did he? [10:38] no, I didn't [10:39] persia: and I'm not sure how something directly related to ubuntu development is irrelevant. [10:39] sykopomp, i'm not sure how berating the developers is a help in any way, shape or form. [10:39] sykopomp: It's claims by someone that some company doesn't contribute to some selected subset of projects based on unavailable data. [10:39] elky: berating? [10:40] cjwatson: hi [10:40] persia: mmhmm [10:40] sykopomp: there is a replay at http://mdzlog.wordpress.com/2008/09/17/greg-kh-linux-ecosystem/ that is worth reading imo [10:40] persia: because the kernel is a meaningless subset that canonical accepts as perfect, and thus unworthy of man-hours of patching. [10:40] sykopomp: Considering that the majority of developers do not have a formal relationship with that company, it's at least confused, and not likely contributory to further development of Ubuntu. [10:40] cjwatson: thanks for the comments about the new GTK, it made me uneasy too since that's somewhat a compatibility change, I mailed the GNOME list about reverting it for this cycle [10:41] sykopomp: please stop talking about things which you have no clue about, ie: everything [10:41] seb128: great, thanks [10:41] stdin: clever retort. Did you learn that in Internet School? [10:41] cjwatson: I think we should revert the change for ubuntu in any case, will do that in the next upload, is that something which is required to get a working installed in alpha6? [10:41] sykopomp: nope, came up with it all by myself [10:41] stdin: your mum must be proud. [10:43] mvo: and thank you, that looks interesting :) [10:43] mvo: was sort of hoping for an actual reply that didn't involve made-up logic (re: stdin) [10:44] sykopomp, carry along now, and come back when you have something constructive to contribute. [10:44] elky: 'bawww' [10:44] sykopomp: do you have something useful to add? [10:44] sykopomp: and personal attacks are unwelcome in this channel. [10:44] (and yes, attacking an entire company and an entire project is a personal attack) [10:45] Hobbsee: it's good to know personal attacks are unwelcome. That's the kind of rule that builds strong, mature communities. :) [10:45] sykopomp, feel free to read the code of conduct some time too. [10:46] elky: link? [10:46] !coc [10:46] The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/ [10:46] thanks [10:47] You're all a lovely bunch, but I need my beauty sleep. Don't get your panties in a bunch, I'm not taking a dump on your work. Don't take inquiry as trolling, this wasn't ;) [10:47] stdin: code of conduct applies to you too. You're out of order [10:47] nite, all, and happy hacking. [10:47] cjwatson: yes, I was getting annoyed. so I stopped responding [10:48] Robot101: My grovelling appears to indicate a possibility of crossover between MPEG and H.263 IP; I've got a feeling that may be a mistake for H.264, though. [10:52] broonie: right, H.264 ~= MPEG4 [10:53] I thought H.263 and MPEG4 were developed quite separately, and MPEG4 was later adopted as H.264 [10:53] Yeah, that's why I've got a feeling it may be a mistake. [10:54] but it's possible that some of the lower level stuff got shared while the overall structures are very different. === tkamppeter_ is now known as tkamppeter [11:08] Robot101: well, I think I kind of agree with you that we can/should reenable h263 again. [11:08] Robot101: what I want to avoid at any price is that after reenabling I get approached by the archive admins rejecting the package [11:09] Robot101: this has happend to be already in debian, where we enabled _all_ encoders and had to implement this debian/strip.sh solution [11:09] Robot101: so what I actually ask for is for some guidelines what encoders are okay to leave in and what are to be disabled [11:09] siretart: really you should take that to the technical board so we have a clear decision taken on the topic [11:10] seb128: yes, perhaps you're right. [11:11] seb128: on my todo list is also to investigate the mplayer package, which also seems to contain all encoders in source and approach debian's ftpmasters with that. I didn't get to that yet, however [11:11] that's likely to just have the functionality asked to be removed from mplayer too [11:11]