[00:00] or modify the .iso and remove the 'gfxboot' line from isolinux.cfg [00:00] cjwatson: shift didn't get it, will try to sed 'gfxboot' out === rickspencer3-afk is now known as rickspencer3 [00:07] kirkland: qemu-kvm is no help; kvm still exhibits the same symptoms. qemu does work though. [00:08] cjwatson: okay, thanks, i'll dig into it; could you open a bug? [00:08] cjwatson: 3min left for iso download [00:08] ok, will do once I downgrade so I can use ubuntu-bug [00:08] no rush, bed soon [00:08] cjwatson: sure thing, thanks. [00:08] cjwatson: thanks for trying the daily [00:09] cjwatson: i'm hoping those become useful [00:14] cjwatson: installing both [jaunty & karmic]-server-i386 now [00:15] did Gnometris disappear off the default games? === YokoZar1 is now known as YokoZar [00:16] YokoZar, patents!!! [00:16] what [00:20] Results of Search in US Patent Collection db for: [00:20] tetris: 63 patents. [00:20] or, being less useless, it seems there's no binary for it in gnome-games in karmic [00:20] the manpage is there [00:21] * debian/rules: [00:21] - Disabled gnometris as it requires clutter to build [00:21] there you go. [00:22] That might be enabled again later; IIUC clutter is aiming for promotion to main for Empathy + geoloc? [00:34] dtchen: I think you said the otehr day you have been working on rtkit. Do you have anything up anywhere that I could use as a starting point to get pulse 0.9.16 into my PPA for karmic? [00:37] cjwatson: okay, i have successfully installed and booted karmic-server-i386 and jaunty-server-i386, both of which I expect are PAE kernels [00:38] cjwatson: my host is an x86_64 jaunty system (running karmic's virt packages) [00:39] slangasek: so it sounds like in both cases it's a manual process to notice changes? [00:39] Caesar: prior to DebianImportFreeze, changes to the /package/ are automatically imported. [00:39] changes to /bugs/ aren't going to be noticed automatically [00:39] slangasek: I mean for the lifetime of the release that contains that package, particularly LTS releases [00:40] that's certainly true, yes [00:40] So it seems to me that there's some free work to be capitalised on if it could be automatically noticed [00:40] and free improvements [00:41] Again, using this libxcb thing as an example [00:41] SRUs are entirely driven by user demand (where "user" may be "uploader"); I don't think we should automatically take bugs that are marked as RC in Debian and nominate them as SRU candidates [00:42] the libxcb one seems to be an example of us not even keeping up with the demand for SRUs for bugs that users *have* said they care about, let alone auto-importing from debian [00:43] Perhaps not automatically nominate them, but auto-import them as applicable? [00:43] auto-import the bugs or the package? [00:43] I think that's broadly inconsistent with how we do bug management for released versions of Ubuntu today [00:43] The bugs against the package [00:43] slangasek: of course it is [00:43] I wouldn't be having this conversation with you if it wasn't [00:44] there have been tools to track RC bugs filed against debian that could be fixed in ubuntu, which ought to be fixed to work better for multiple ubuntu releases [00:44] kirkland: I guess it must be i386-host-specific [00:44] but it's not an easy thing, there are many false positives [00:44] Caesar: I mean that there are lots of other bugs that are in LP that we do know about already, and know they're applicable to released versions, but we don't mark them as applying to those releases unless we intend to SRU them [00:44] so I don't think Debian bugs should be treated differently [00:45] Not even fixed bugs? [00:45] but perhaps this is a discussion better had on ubuntu-devel to get wider perspectives, yeah [00:45] I will write something up and email ubuntu-devel [00:46] Caesar: opening tasks for bugs that are already fixed in the old release, just to close them? sounds like busywork to me [00:47] Huh? [00:47] It's still applicable to that release [00:47] So you're not going to close it [00:48] Caesar: fwiw, I /personally/ strongly prefer the debbugs 'version tracking' workflow, but that's not the workflow Ubuntu uses in LP [00:48] I realise that [00:48] So your best option is to target to a specific release [00:48] and not for lack of considering the debbugs model [00:48] Caesar: ok, you meant bugs that are fixed in the latest release but still apply to previous releases - yep, tasks only get opened against the other releases if there's an expectation that they're SRU candidates [00:48] So I guess I'm proposing that if Debian fixes a bug in a version of a package that ended up in an Ubuntu release, that bug gets imported into LP (possibly along with the fix) for consideration [00:49] otherwise, it's implicitly "wontfix", so why open it [00:49] slangasek: yes, I'm not talking about the current development release [00:49] right, I just misunderstood what you meant by "fixed bugs" [00:49] slangasek: you should know by now that I'm usually talking about released LTSes :-) [00:50] Caesar: as a rough start on something we've used for this for universe, see http://qa.ubuntuwire.com/bugs/rcbugs/ [00:51] though it only shows info for the development release rather than fixes post-release [00:51] ajmitch: that looks cool [00:51] Looks like a good starting point === sconklin is now known as sconklin-away === WelshDragon is now known as YDdraigGoch [01:48] Yay. Either there is policykit or consolekit breakage that stops audio from working, permissions wise. [01:49] slangasek: we are in DebianImportFreeze aren't we? [01:50] Don't forget devicekit breakage too :-) [01:51] james_w: ahhh, the things that sprint travel does to one's hold on reality [01:51] james_w: yes, we're meant to be, but apparently I gave everybody an extension by running another round of autosyncs today ;) [01:52] score! [01:52] "They're more of just guidelines anyway" [01:53] siretart: why have you subscribed ubuntu-archive to bug #223212? I don't see anything there that's a request for action [01:53] Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212 [01:53] siretart: (unsubscribing [01:53] ) === slangasek changed the topic of #ubuntu-devel to: Archive: open | DebianImportFreeze in effect | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [01:56] superm1: you seem to have subscribed ubuntu-archive instead of ubuntu-mir for bug #390973; adjusted [01:56] Launchpad bug 390973 in libftdi "MIR for libftdi" [Undecided,New] https://launchpad.net/bugs/390973 [02:36] slangasek, thanks, sorry my mistake [02:36] pitti, sure [02:36] why does apt-cache policy nvidia-glx-180 show....nvidia-glx-180: [02:36] Installed: 185.18.14-0ubuntu1 [02:36] while nvidia-x-server settings shows 180.60 [02:38] billybigrigger, because they're different? [02:38] billybigrigger, see #ubuntu for support please [02:39] nvidia-glx-180 has a -185 series driver though? [02:39] that doesn't seem right. [02:39] superm1: that's somewhat intended though [02:39] ajmitch, how so? [02:40] at least bryce had a reason for doing so when I asked about the package in his PPA [02:40] well im just confused, as hardware drivers show's the 180 series installed [02:40] so which driver am i using? 180 or 185? [02:41] billybigrigger, that's the 185 series driver, just the package is named 180 series [02:42] seems a bit confusing to me [02:42] wouldn't it make sense to label a 185 driver as 185, not 180? [02:43] billybigrigger, that's what i was saying too. [02:43] bryce, what's the reasoning for that? [02:44] The Gtk 2.17.2 package is called libgtk2.0-0 for the same reason. It’s ABI-compatible, so other packages don’t need to constantly keep changing their dependencies for no reason. [03:10] ScottK: Sorry for the delay, I'll be uploading livecd-rootfs presently [03:47] StevenK: Thanks. [04:00] superm1, if the package gets renamed every time there is just a version number change, it makes bug management a PITA [04:01] honestly, I'd sort of rather the source package be named either xserver-xorg-video-nvidia, or nvidia-installer, for consistency with other drivers === SEJeff_ is now known as SEJeff_away === SEJeff_away is now known as SEJeff_home [04:23] bryce, ah [04:24] superm1, probably we should discuss the naming more [04:25] If ubiquity is core dumping (bug filed) is there still an easy way to install with the desktop CD? [04:25] * tedg doesn't want to download another CD. [04:25] it'd be nice to have a "stable" name. the -177 to -180 transition was awkward as far as bugs go [04:26] bryce, ah so maybe the stable name is always the same and if there needs to be a legacy drivers then add more source packages [04:26] that seems like a better scheme [04:26] bryce, Any suggestions? We dropped -legacy and -new because it confused people. Having 4 nvidia-foo packages is somehow useful, and I suspect we'll only get more. [04:27] Heh. nvidia-glx, nvidia-glx-legacy, nvidia-glx-legacy-legacy, nvidia-glx-really-get-another-gfx-card-damnit-legacy? :) [04:27] actually there's just 3 packages. -177 went away once -180 was moved to [04:27] I see -71, -96, -173, and -180 on i386. What shouldn't be there? [04:28] oh yeah -71 [04:28] http://pastebin.ca/1479097 [04:28] but I think that may not be updated to the jaunty kernel [04:28] so im not the only one complaining about the naming of 180 or 185 [04:28] :P [04:28] I was looking at karmic, but hrm. [04:28] is this a normal error? [04:28] persia: I'd guess it's in the archive but actually unusable. [04:29] Can I talk to someone about package development, my project is having a issue [04:30] -71 was last uploaded to jaunty 29 January. If it's not useful, I think it ought be removed from the archive. [04:30] Kage_Jittai, What specific question do you have? [04:30] it took me a while to find out that bcmwl-kernel-sources was the right package to install for broadcom sta wireless driver [04:31] It'd be useful if it works; there are some gpus only supported by -71. I'm just checking whether or not it actually builds. [04:31] finally got it though [04:31] persia: I work on a project called The Mana World [04:31] persia: its a MMORPG [04:31] someone told me but I was in kind of a jumpy mood so I was confused [04:31] persia: Our issue is with LTS distros [04:31] finally figured it out after a good search on installing ubuntu on the dell mini 9 [04:31] persia: as a MMO, we are always coming out with new features [04:31] (in karmic) [04:32] persia: many of these features are unsupported [04:32] persia: since people connect to a server, and to play with others [04:32] DoYouKnow, jockey now supports offering that as of today or so [04:32] persia: unsupported versions being used cause issues [04:32] ok [04:32] that must be the taskbar on the lower right [04:33] persia: http://pastebin.com/d608d5889 [04:33] err [04:33] or not [04:33] I'll look it up [04:33] persia: that is a pastebin of yesterday's version information [04:33] persia: as you see .24.1 is being used quite a bit [04:34] Kage_Jittai, Hrm. I think you have an issue with the philosophy of how we support releases. [04:34] persia: how ever, we dropped support for .24.1 almost a year ago [04:34] My recommendation would be to do one of the following: [04:34] persia: well, as being the only real GPL MMORPG with a central server, our needs are special [04:35] Hrm, [04:35] With a central server, one of my options is out :( [04:35] How about a backport to foo-backports? [04:36] persia, bryce: Yeah, in what shouldn't be a terrible surprise, nvidia-71 fails to build against 2.6.30-10-generic. I guess someone should ask nvidia if they plan to support it, and remove the packages if not. [04:36] Yeah, backports is probably the least bad option. [04:36] we do offer backports, even package them our self [04:36] but they never seems to get accepted into LTS distros [04:36] Kage_Jittai: If you need everybody to be running the latest software, it seems like you really want to be running your own repository so you can control that [04:36] And have the server tell people to enable -backports if they seem to be connecting with the old Ubuntu client [04:36] ebroder: we don't need the latest software [04:36] Kage_Jittai, We don't change packages on backporting, just recompile against backports. Are you familar with the Ubuntu Backporting team? [04:37] ebroder: we support .26 .27 .28 .28.1 .29 .29.1 [04:37] persia: no, that is most likely part of the issue [04:37] oh, jockey == restricted driver manager [04:37] !backports [04:37] If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [04:37] Kage_Jittai, basically, you file a bug, get a few people to test following a specific procedure, and wait a week or two (usually). [04:38] Then you can just tell your users to use backports (which gets distro authenticated and everything), to use a newer version. [04:39] persia: can we somehow tell the backport team about our special needs? [04:39] wouldn't a PPA be better suited for this? [04:39] we have .28.1 on ppa [04:39] we even link to it [04:40] but most people seem to still use the repo [04:40] Kage_Jittai, I'm not sure I understand how your needs are special in the context of backports. backports is often just the newest software, recompiled against the older stack. [04:40] bryce, Also PPAs have architecture limitations, etc. [04:41] I think part of the problem with our backports is we use guichan [04:41] guichan seems poorly supported in older distros [04:41] persia, "architecture limitations"? You mean, like no PPC? [04:41] bryce, Yes. [04:57] persia: well thanks for trying [04:58] Kage_Jittai, Hrm? Did something not work, or is there some special concern? [04:58] persia: we have requested backports [04:58] which go unanswered [04:58] have you organised some testers? [04:58] ^_- [04:58] no, not really [04:58] My memory is that there need to be several positive test reports for a backport to be approved.\ [05:00] And I seem to remember the backports team several times claiming that the lack of testers was the primary obstacle to getting backports done. [05:00] So, I'd advise organising some testers, and having them report on the backports bugs. [05:01] persia: we need more ubuntu geeks [05:01] on our team [05:01] any voluteers? [05:01] :P [05:02] Most people here are busy developing the next release. You might try asking in #ubuntu, and sometimes in #ubuntu+1 (people testing the new release) [05:02] #ubuntu-backports is theoretically the right place, but I almost never see anyone there when I join. [05:02] You could always get some of your users to test it, no? [05:03] Put a note on your PPA page saying "please test our backport so you don't have to use the PPA any more" [05:03] we use a public ppa [05:06] !backports [05:06] If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [05:07] Hardy really needs to be updated [05:40] persia: ok I registered for launchpad [05:40] how would I request the backport [05:41] Kage_Jittai, I've only done it once, and years ago, so I'm probably not the best person to ask. Does that wiki page not explain the process? I think it's just filing a bug. [05:41] it says to file the report, but doesn't say what type of details to give [05:43] Oh, the package name, the version (in karmic) to backport, and the rationale for the backport should do it. [05:44] That's where you'd explain that TMW is a MMORPG, and that you don't support .24 anymore, so need the backport so users can upgrade. [05:44] What testing has been done is also important. The testing standard for a backport is that it builds, installs, and runs. [05:45] ScottK, Does that go in the initial request, or in tester comments (or both)? [05:45] persia: It can all be done at once if the initial requestor is also the tester. [05:46] ScottK, That makes sense, and probably makes for a better report. [05:49] persia: this will work https://bugs.launchpad.net/ubuntu/+source/tmw/+bug/393724 ? [05:49] Ubuntu bug 393724 in tmw "Please Sync tmw 0.0.24.1-1 in Hardy with tmw 0.0.29.1-1 in karmic" [Undecided,New] [05:51] You want "Please Backport" [05:52] updated [05:53] Kage_Jittai, Other than that, you just need the test reports, I think. [05:54] *sigh* [05:55] now the hardpart [05:55] heh. [05:56] persia: wanna volunteer? [05:56] Kage_Jittai, Um, no. I have a big stack of stuff I've already promised to do. [05:58] I am infact on hardy, even though I use git version, how could I post test data? [06:00] You need to backport the actual version and packaging that's in Karmic, and build and test that. [06:00] Kage_Jittai, Well, take the karmic version, follow the instructions for backporting to produce a hady backport, and test that version. [06:05] persia: these instructions are where? [06:05] Kage_Jittai, On the backports wiki page, I thought. [06:07] Kage_Jittai, Under "Backport Process", most of the way down the page. [06:09] * Kage_Jittai gives puppy dog eyes to persia [06:10] Kage_Jittai: They don't work on him, which is a pity. [06:10] About what? [06:11] persia: doing the backport ^l^ [06:12] I can't do it: I'm not a member of the backports team. And for testing, I honestly believe that if I put it in my queue, it would get done by others before I got to it. [06:12] anyone that is part of the backport team? [06:14] Kage_Jittai, You don't want a backport team person to look at the bug until it's tested. [06:15] You need to get the testers first. Once the testing is complete, then you want the backpoters. [06:15] Because such a person would just mark it incomplete and then tell you to get it tested. [06:15] * ScottK really goes to bed this time. [06:15] Good night. [06:16] Grrr! === Kage_Jittai is now known as Fire_ant_command === Fire_ant_command is now known as FireAntCommander [07:02] Good morning [07:02] morning pitti [07:14] slangasek: it seems to me that the package is in clear violation with http://www.ubuntu.com/community/ubuntustory/licensing and I thought the archive administrators might want to have a look and comment on that issue. [07:16] slangasek: in other words: this is clearly non-free software in 'main'. Doesn't really anyone care? [07:20] good morning [07:20] siretart, is it clearly non-free? I read it as completely undocumented, leaving significant uncertainty as to the freeness. [07:22] persia: it comes without source, without any copyright notice and is in main. According to my reading of http://www.ubuntu.com/community/ubuntustory/licensing this is in violation of what we require for packages in 'main' [07:23] or at least I don't know how to understand the first point here in any other way: "Must include source code. The main component has a strict and non-negotiable requirement that application software included in it must come with full source code." [07:24] OK. That makes sense. I seem to remember there being some debate about linux-firmware in the past (leading it to be a separate package). [07:25] While I don't remember anything about missing licenses for specific items, I do believe that it was granted a special exception to be in main because otherwise the entire stack broke. [07:25] So this firmware thing keeps coming up in Debian? Can we just not repeat here? Please? [07:25] That said, if there exists some part of it that's not only without source, but actually non-free, it doesn't belong there. [07:26] persia: well, without any copyright statement, we have no basis to believe that we are allowed to redistribute it [07:26] and moreover, "special exception to be in main because otherwise the entire stack broke" is in clear contrast to "non-negotiable requirement that application software included in it must come with full source code." [07:26] siretart, I'd argue we also have no basis to believe we cannot ship it, but yes. Still, the solution is to investigate, rather than remove. The cost is high. [07:27] Hrm. That's also true. Either my memory or that wiki page is in error. [07:27] I'm sorry, how can we possibly believe to retain any credibility here if we simply look away here? [07:27] Um, I think you perceive my input as something other than it is. [07:28] possibly [07:28] If you want to file a removal bug, go ahead. I don't read that as a removal bug. [07:28] there is already a bug, and I subscribed the archive admins to comment on it [07:28] slangasek just unsubscribed from there [07:28] You're talking about bug #223212? [07:28] Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212 [07:28] I really hope there is some misunderstanding here [07:29] yes [07:29] Right. I don't see a request to remove the package in the log of that bug. [07:29] because that's pointless, we do have a place for that in ubuntu. it's called 'restricted' [07:30] siretart: Right, so you subscribe ubuntu-archive without even commenting in the bug that you'd like ubuntu-archive to comment on the package in question, and you're suprised when slangasek just unsubscribes ubuntu-archive? [07:30] I think you need to make clear what action should be taken. [07:30] Just because we're memebers of ubuntu-archive doesn't mean we can read minds. [07:30] Putting it in restricted breaks ogre-model, but it quite likely possible with some wrangling. [07:31] StevenK: well, yes, I'm indeed a bit surprised here. when I did that, a fellow DD pointed me to the issue, but I was at work and a bit in a hurry [07:31] StevenK: in the end, you suggest me to comment on the bug and then re-subscribe ubuntu-archive? [07:31] No, just saying. [07:32] I hate how this issue keeps coming up over and over and over and over in Debian, and I don't want the same thing to happen here. [07:32] siretart, I'd recommend you make a clear statement of what action should be taken prior to subscribing ubuntu-archive. Moving it to restricted probably first requires some fiddling with the kernel dependencies, which would involve working with the kernel team. [07:33] StevenK: so do I. and I thought that we had settled that in ubuntu by other means than putting heads in the sand [07:33] * persia has had little success with soliciting ubuntu-archive comment when it comes to policy in the past [07:33] what would be bad with moving it to restricted? [07:33] pitti, Dependencies, mostly. Probably just needs some sorting. [07:33] persia: indeed, tech board is more authoritative in that regard [07:34] ubuntu-archive executes policy, we don't actually define it in that scope [07:34] pitti: linux-image-generic Depends on linux-firmware [07:34] pitti, Well, perhaps, although I find that generall a developer statement is sufficient for most things, if they don't break anything. [07:34] pitti: linux-generic is in restricted, and linux-image-generic is in main [07:34] this should be solved by TB and checked for feasibility with kernel team IMHO [07:35] I'm surprised that we have a different understanding of policy here. up to now I thought http://www.ubuntu.com/community/ubuntustory/licensing was pretty clear [07:35] siretart, I don't think anyone is arguing about policy. It's just the mechanics involved. [07:35] indeed, so then we could theoretically shuffle the metapackages [07:35] siretart: So, we should just purge it from the archive and break the world? [07:35] but half of the archive team thinks this should go via TB, well, then so be it [07:35] e. g. linux-generic could pull in the firmware, and linux-image* stop depending on it [07:35] Um, no it's that the TB makes policy. [07:35] siretart: TB -> change of policy [07:36] This doesn't need a policy statement: there is clear policy. [07:36] I think policy is just fine here. the implementation isn't. [07:36] if we just have a bug (wrong component), and you don't want to change the policy, TB isn't actually needed [07:36] pitti: I recall rtg had a reason why he didn't do that, but I don't recall what it is. [07:36] It's just that the mess of linux and linux-meta and linux-firmware needs to be sorted to not break the world. [07:36] StevenK: well, at some point this has been accepted into main. I think this was an error. [07:36] StevenK: you can install Ubuntu with "free software only", but well, then you have to keep both pieces if it breaks for you [07:36] siretart: *nod* [07:37] the "linux" metapackage is in restricted for a similar reason [07:37] siretart, I remember when it was accepted into main. It was done because it introduced no new components. The questionable bits came from upstream at some point nobody can identify in prehistory. [07:38] so, AFAICS, if we move linux-firmware dependency from linux-image-generic to linux-image, and move linux-image and l-firmware to restricted, it should be all good [07:38] persia: you are aware that your last statement can be read in a pretty malicious way, are you? [07:38] Can we not just clean up the confusing set of metapackages? [07:38] siretart, Erm, no. Sorry. It wasn't intended that way. [07:38] persia: you have another proposal? [07:39] pitti, Well, we have linux, linux-generic, linux-image-generic, linux-image, etc. [07:39] Do we really need that many? [07:39] persia: I know that you didn't mean it. I'm just saying that this argument will be perceived outside ubuntu completely different than you mean it here [07:39] persia: not on i386/amd64 right now, I think [07:40] siretart, Ah. I understand. Right. [07:40] pitti, Do you know why not? I remember this being discussed for the past 3-4 cycles, and it's always too late in the cycle to fix it, or there's some other reason. [07:41] But just moving the dependency should be sensible, and allow migration to restricted. [07:41] siretart: I unsubscribed the archive admins because all you did was subscribe us, without saying what you wanted. And if you want it /removed/, then that would appear to be an inter-developer dispute, which I don't intend to mediate with my archive admin hat, to be sure [07:41] that sounds quite right to me [07:41] persia: well, re-thinking about it, we still have several flavours (-i386, -generic, -server, -rt, etc.), so we probably still need them all [07:41] for my part, I'm not convinced moving it to restricted is the correct course of action [07:42] slangasek: okay, sorry for that, I was under the wrong impression that the bug was already clear. now I see that it is not [07:42] pitti, I guess the one I don't understand the most is the distinction between "linux" and "linux-image". They seem to differ by a single transposed word. [07:42] slangasek: can you please elaborate? How can we keep it in main without violating http://www.ubuntu.com/community/ubuntustory/licensing? [07:43] slangasek, Or were you saying that removal may be the more appropriate action? [07:43] persia, before karmic, having linux and linux-image made sense because linux pulled in LRM as well as linux-image [07:43] now for karmic since there is no more LRM, the linux meta package itself makes less sense [07:43] siretart: note that this page says "application software", which firmware are not [07:44] superm1, No, l-r-m was always pulled by linux-image-flavour, because l-r-m can be flavour-specific. [07:44] (or maybe it was linux-flavour) [07:44] persia: AFAIUI, "linux-image" -> the actual kernel, like bzimage and modules; "linux" -> everything around it, such as restricted-modules, firmware, etc. [07:44] we do allow non-applications in main that don't permit free modification; e.g., RFCs [07:44] persia, i'm looking at apt-cache depends linux on jaunty right now. the only two depends are linux-image and linux-restricted-modules [07:45] where linux-restricted-modules is another metapackage [07:45] superm1, Hrm. Maybe I'm confused. I filed a bug about this a long time ago, was told it couldn't be fixed easily, and forgot some of the detals. [07:46] persia, well now it really should be much more easily fixable with LRM gone, so i would recommend reviving said bug [07:46] pitti: the split between linux-image and linux is "depends on restricted" and "doesn't depend on restricted" [07:46] linux-image at various points in its history depends on linux-ubuntu-modules, too [07:47] maybe I'm too much from the embedded world, but for me "application software" does not necessarily imply to be software on the same processor the linux kernel runs on. anyway. the next point is that we require permission to redistribute and modify it. are you positive that we have that permission? the bug is about these missing copyright statements [07:47] superm1, Perhaps. Someone needs to sit down and untangle the mess. It might be me, and it might be someone else. [07:47] hey guys, apt-get install branding-ubuntu and then open solitaire, tell me what you think [07:47] siretart: no, I'm not positive; I agree that it's a bug, I just don't see that it's a bug that the archive admins can resolve, since our only available option is "pull it and make it uninstallable" [07:48] siretart, There are two issues being conflated. 1) Should linux-firmware be in main and 2) does the current licensing of linux-firmware meet the requirements (even for firmware as documented at http://www.ubuntu.com/community/ubuntustory/licensing) [07:48] persia: perhaps you're right and these two issues should be discussed seperately [07:49] siretart, There's a separate section for firmware further down on the page. I'm not sure that the bug raised doesn't even break that guideline, although it needs investigation. [07:49] right, so 1) is the easy part here; (2), figuring out their licenses, is the real work here [07:50] Well, 1) is really making a call as to whether we consider the contents of the package "firmware" or "application software". In the first case, main is fine (as I read the page). In the second case, it belongs in restricted. Probably easier to put it in restricted to avoid the argument, but needs confirmation from the kernel team. [07:51] In terms of undocumented licenses, I think we ought follow the practices we've followed in the past: when we encounter something where licensing is unclear (take a look at the copyright files for a bunch of stuff in Priority:required sometime), we try to fix them or work around any discovered issues. [07:53] moving linux-firmware to restricted also breaks the ogre model in that it builds two udebs that are embedded in the d-i initramfs [07:53] (nic-firmware, scsi-firmware) [07:53] Aha. That's the part that breaks. Thanks for the clarification. [07:54] superm1: I answered to the jockey-text merge request, BTW [07:55] ah, okay, this makes things more clear. but I need to leave now, will be back later. cu === tkamppeter_ is now known as tkamppeter === Quintasan_ is now known as Quintasan === krusaf|bnc is now known as krusaf [09:26] siretart: that page is absolutely explicit about whether firmware is application software; it says that it is not. [09:27] "Ubuntu contains licensed and copyrighted works that are not application software. For example, the default Ubuntu installation includes documentation, images, sounds, video clips and firmware." [09:27] (I've followed up to the bug separately) [09:28] pgraner: bug 223212 needs attention from your team, I think [09:28] Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212 === lifeless_ is now known as lifeless [10:02] seb128: can you please change the Maintainer from pidgin to ubuntu-devel-discuss instead of ubuntu-devel with one of the next uploads? [10:03] tkamppeter: ^ same goes for some of the printer related packages [10:03] update-maintainer of the ubuntu-dev-tools package will take care of it for you [10:03] (mails get into the ubuntu-devel@ moderation queue because of it) [10:05] dholbach, why? [10:05] which mails? [10:05] archive@ubuntu.com mails [10:05] an upload should not spam any mailing list [10:06] if my software-0.0.2 is open source till date, can i now make it closed source at software-0.0.3 version? [10:06] it has lgpl currently... [10:08] seb128: they do get into the moderation queue though [10:08] dholbach, I'm a bit concerned that an upload spam a mailing list, would that mean that emails would land on ubuntu-devel-discuss when I upload pidgin? [10:08] they manifestly don't ... [10:09] seb128: I'm not moderator of that list, so I don't know - maybe archive@ubuntu.com is explicitly blocked there [10:09] well, if they go in the moderation queue that's because they try to go there, if I change the email for an open list one what would block the email? [10:09] vise: I don't think you should really be expecting free software developers to give you advice on taking your program away from us [10:09] to be perfectly honest :) [10:09] dholbach, what do those emails say? [10:10] seb128: it's the usual archive@ubuntu.com emails you get on every upload, plus the "rejected"ones [10:10] seb128: I just noticed pidgin and a few printing related packages [10:10] cjwatson: I dont want to either.. But please.. :) [10:10] also I'd like to get the merge proposal mails for ~ubuntu-core-dev from that list [10:10] but I don't know what to do there === pochu_ is now known as pochu [10:11] dholbach: er, what? [10:11] vise: it's my understanding that you can't withdraw the licence already given for software-0.0.2, so people can continue to modify and distribute that; furthermore, if you've incorporated code from anyone else under the LGPL then you don't have the right to make that closed-source. For anything else, I suggest asking your lawwyer [10:11] lawyer [10:12] Hobbsee: what what? :) [10:12] dholbach, I'm not sure to understand what is going on but I will change the email address anyway, still seems weird that the lists are mailed on upload [10:12] seb128: they really aren't. [10:12] Hobbsee: aren't what? [10:12] cjwatson: tyvm [10:12] dholbach: I suspect we probably ought to add an ubuntu-reviews mailing list [10:13] dholbach: the lists (u-d, u-d-d) aren't mailed on upload [10:13] cjwatson: that sounds sensible, we could route the sponsoring there too [10:13] dholbach: did you want the merge proposals on u-d, or not? I'm unclear with what you're saying thee [10:13] Hobbsee: let me do a pidgin upload that is going to be rejected - just a sec [10:13] Hobbsee: I'd prefer not having them [10:13] on ubuntu-devel@ [10:14] right [10:14] they were only ever temporarily on ubuntu-devel@, until they got past the point when they were manageable there [10:15] ok pidgin right now has Maintainer: Ubuntu Core Developers - what the ubuntu-devel@ moderation queue in a few minutes [10:15] now [10:15] cjwatson: so we'e dopping the erge requests? so far, iv'e just been skippign them [10:16] ah, that did dop in the moderation queue [10:16]