[00:00] have you tried a lucid live cd at all? [00:00] To clearify; it's NOT possible that it's a router problem since i can use the same statical IP and DNS from windoose [00:00] No, haven't tried lucid [00:00] i understand Ubuntu will not let you obtain an ip from the router [00:01] Ya :/ [00:01] ok well if you can download lucid and try it as a live cd, see if the problem is fixed there, and if not file a bug report using ubuntu-bug [00:01] but the really wierd thing is that it's still there after a reinstall on a formatted partition, because it worked out of the box when I first installed karmic. That was also a clean install [00:02] File reports with ubuntu-bug without internet is pretty meh :) [00:02] si thought you said you had ethernet? [00:02] Yeah [00:02] And a cable that's 0,5 meters :) [00:02] ..... [00:02] so it isnt possible? [00:02] I'll do that later, probably next week :/ [00:03] btw what wifi is it? [00:03] Yeah, but I'm kinda handicapped without a working computer [00:03] Intel 5100 AGN [00:03] Windoose doesn not satisfy [00:04] hang on 1 sec [00:07] m0ar: bug 437953, bug 398898, bug 356561 may be relevant after a search [00:07] Launchpad bug 437953 in linux "Problems with Intel Wireless WiFi Link 5100 agn, with wifi "n" connection" [Undecided,New] https://launchpad.net/bugs/437953 [00:07] Launchpad bug 398898 in network-manager "wlan switched off on boot up" [Undecided,New] https://launchpad.net/bugs/398898 [00:07] Launchpad bug 356561 in hal "After switching off and then on the wireless switch (iwlagn, Intel Wireless WiFi Link 5100AGN) " [Undecided,New] https://launchpad.net/bugs/356561 [00:08] Still; i freaking REINSTALLED the OS because I didn't wanna tinker anymore with it [00:08] With no effect :'D [00:09] m0ar: strange! have a look at those 3 bugs see if any are of any relevance may help :) [00:11] xteejx: Oh, thank you! [00:12] m0ar: no problem :) [00:20] xteejx: I'll be in later, catch you later [00:21] its 12:20am here ill be off very soon [00:21] 2 late [00:21] nah [00:39] hggdh: 12:39am not late? you're kidding right? lol [00:47] :-) [00:56] night all [01:38] I did some automated crash reports, and the reports were set to private. [01:39] WeatherGod: that's normal [01:39] ok, I am running off a LiveCD... [01:39] possibly the only sensitive thing I entered on my computer would be my network password [01:39] WeatherGod: if you're the submitter you should still see it [01:40] I guess I will double-check my traceback and see if there is anything about that before setting it to public [01:42] yeah, unless there is some special vodoo for the process maps, it is clean [01:46] ok, well, I marked them public [01:47] WeatherGod: before retrace? [01:47] ? [01:47] bug #? [01:47] bug 507277 [01:47] WeatherGod: Bug 507277 on http://launchpad.net/bugs/507277 is private [01:47] that is actually one of two [01:47] heh [01:49] ah, just refreshed it [01:49] I see that it got marked as a dupe [01:52] I am on a mission tonight to find as many different ways I can break Lucid... [01:52] gonna be fun [01:53] WeatherGod: have fun [01:53] hehe [02:36] so, essentially, Ubuntu Software Center can't seem to do anything right unless it has a package list [02:36] right, there's a bug for that [02:36] was it fixed for 1.1.8? [02:37] idr [02:37] because I can't test that as i have to have a package list to upgrade to 1.1.8 [02:37] heh [02:38] actually, wasn't it a major issue for Karmic? [02:38] yep [02:39] also, just a thought... [02:40] I understand the rational behind not having apport report for outdated software... [02:40] but maybe let it report for things like Software Updater and whatnot? [02:40] * micahg doesn't remember where it is [02:41] because, what if the reason the software is outdated is because the user can't update due to a bug [03:05] /var/log/jockey.log which ends with ERROR: update-alternatives: warning: skip creation of /usr/share/man/man1/nvidia-smi.1.gz because associated file /usr/share/man/man1/alt-nvidia-96-smi.1.gz (of link group gl_conf) doesn't exist. [03:05] should I bug jockey or nvidia-glx? [04:56] hey vish, thanks for the info.. i'll keep that in mind for next time [05:10] bcurtiswx: np :) [05:15] bcurtiswx: graphical resolution bugs convert to Q? [05:17] hmm.. is the last comment supposed to be a bribe o.0 > Bug 74042 [05:17] Launchpad bug 74042 in gdebi "gdebi-gtk - Include "uninstall" button" [Wishlist,Confirmed] https://launchpad.net/bugs/74042 [05:17] :s [05:22] vish: incentive [05:23] well , hope someone is enticed and fixes... ;) [05:23] fixes it* [06:41] Hello, I've similar problem to this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/451640 [06:41] Launchpad bug 451640 in linux "[Asus eeePc 1005HA] Suspend to RAM with wifi off deactivate the ethernet on next resume" [Undecided,New] [06:41] can some one tell me how to make useful report? [06:42] Usama: One might usually use apport-collect, but it appears someone else already uploaded all the relevant data to the bug. [06:43] May I help in something else? [06:44] Usama: Well, the bug report is currently against the kernel and talks about investigations done with network-manager. [06:44] You might investigate whether the kernel or network manager is having the issue, and potentially reassign the bug to network manager. [06:45] may I ask how to check that? [06:45] Alternately, if you can confirm it is the kernel, you could document the results of your investigation there, which may help the kernel folk debug it. [06:45] I'm not exactly sure :) [06:46] If I were investigating it, I'd probably start by disabling network manager and using lower-level tools to turn off WiFi (but not ethernet) and see if that survives a suspend-resume cycle. [06:46] If it has the same behaviour, it's probably the kernel. If it has a different behaviour, it's probably network manager. [06:47] (and be sure to document what you did and what results you got in the bug) [06:59] ok thank you [06:59] good morning all [07:07] low level tool like 'ifconfig' or 'ifup'? [07:07] * Usama a bit busy at wokr [07:07] * Usama *work [07:50] good morning === Yos_ is now known as Yos [09:05] hmm, the 5-a-day stats are just not updating... I'v changed my lp name nearly a month ago and it is still stuck with my old name and stats :( === kmdm_ is now known as kmdm [10:22] is this a bug in EOG or gcc? Bug #503061 [10:22] Launchpad bug 503061 in hundredpapercuts ""Change desktop background" dialog shows up when using "Set as desktop wallpaper" option in image viewer" [Low,Incomplete] https://launchpad.net/bugs/503061 [10:26] if a bug is not reproduceable and the reporter says he don't use the app any more to give further info what should i mark it. [10:28] om26er: I'd mark is "Invalid", stating in a response why and that the bug should be reopened when someone has the issue again. [10:32] It's worth including a request in the response for anyone else encountering it to provide specific steps to reproduce, as otherwise it may be difficult to fix later. [10:33] (alternately stated: when marking something invalid because triage cannot continue, be sure to ask the necessary triage questions in advance so the reopener can answer them without another round trip) [10:33] What package interprets the options set in /etc/fstab during boot? I might have find a bug (_netdev is not respected as an option) === SuBmUnDo_ is now known as SuBmUNDo`OuTzZ === SuBmUNDo`OuTzZ is now known as SuBmUnDo_ [10:35] is this a bug in EOG or gcc? Bug #503061 [10:35] Launchpad bug 503061 in hundredpapercuts ""Change desktop background" dialog shows up when using "Set as desktop wallpaper" option in image viewer" [Low,Incomplete] https://launchpad.net/bugs/503061 [10:35] anyone^ :) [10:36] vish: why do you think it would be a bug in gcc? [10:36] i.e.: what has the compiler to do with it? [10:37] Ampelbein: hmm , i thought the "appearance" dialogue was part of gcc... but i'm not sure it is an EOG bug [10:38] vish: gcc is a compiler. [10:40] "gcc" is a compiler. "g-c-c" is the typical shorthand for GNOME Control Centre, rather than "gcc", to distinguish. [10:40] persia: oops , i meant t g-c-c :) [10:40] oh. sorry, got that wrong [10:41] Ampelbein: sorry , i my bad :) [10:41] alvin: I believe it to be "mountall" [10:42] persia: I feared as much. Thanks. I already found an existing bug and will add my comments to that (Bug 384347) [10:42] Launchpad bug 384347 in util-linux "_netdev not working" [Undecided,New] https://launchpad.net/bugs/384347 [10:42] persia: so would that bug need to be dealt in both EOG[plugin perhaps?] and g-c-c ? [10:43] alvin: On my system, /sbin/mountall isn't provided by util-linux (but rather by mountall) [10:44] persia: Yes, the original reporter reported this against the wrong package I think. I'll add mountall [10:44] vish: i think eog is to "blame". It calls gdk_spawn_command_line_on_screen (screen,"gnome-appearance-properties" " --show-page=background",NULL); after setting the background [10:44] vish: I don't know enough about how the packages interact to have an opinion on where the bug belongs. [10:45] Ampelbein: ah.. ok. got it :) [10:45] persia: thanks :) [10:45] in eog-window.c, function eog_window_set_wallpaper() [10:47] Ampelbein: could you comment that on the bug? or shall i quote you from there? [10:47] s/there/here [10:47] vish: I can do that on lp and the gnome bugzilla. [10:47] Ampelbein: awesome , thanks.. :) === om26er_ is now known as om26er [10:52] vish: done ;-) [10:53] Ampelbein: cool... can i tempt you to submit a patch for that too? [i'm gonna set a papercut milestone for it] [10:53] :) [10:54] vish: I don't know... Don't want to start working on that without response from the eog developers. I made a suggestion on the gnome-bugzilla to make this a checkbox option. I'd think that would be better than removing the call. [10:55] Ampelbein: great , i see you are subscribed to the bgo bug , so its awesome :) [10:56] thanks [10:57] no problem [11:30] Bug 65230 was fixed a long time ago. (Hardy) In Karmic, I still see messages appear after the boot prompt appeared. Should it be reopened? [11:30] Launchpad bug 65230 in upstart "startup messages continue on screen after first login prompt appears" [Medium,Fix released] https://launchpad.net/bugs/65230 [11:53] alvin: Personally, I think that's just a natural result of non-sequential startup. In practice, it doesn't generally interfere with anything. [11:53] Easy workaround is to use vc2 for the initial login. [11:55] persia: It's very ugly. On some machines I can scroll up until the original boot prompt is visible. Especially when using NFS. Every share gives a lot of errors. Also, the messages keep coming. (Apparently sshd and smbd need to be restarted from time to time, and the console shows that) [11:55] persia: Well, you can just press enter [11:55] persia: It's no critical bug, but it's there. Should it be reopenend? [11:56] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/65230/comments/31 likely provides a guide as to why it's appearing again, but I'd suggest it warrants a new bug rather than reopening that one. [11:56] Launchpad bug 65230 in upstart "startup messages continue on screen after first login prompt appears" [Medium,Fix released] [11:57] But be aware that as long as one is logging into a console to which messages are sent, there's no way to make it completely pretty. [11:57] I can live with that. [11:57] Because it's quite possible to have more stuff write to console post-login, etc. [11:58] Showing nothing after the boot prompt and sending all post-boot messages to tty4 or something would be much nicer. [12:04] Good, bug 414017 already exists for the repeated messages on the root console (like smbd and sshd) [12:04] Launchpad bug 414017 in samba "dhclient hooks should not output messages on the root console" [Low,Invalid] https://launchpad.net/bugs/414017 [12:16] hey [12:19] alvin: After reading all the comments, I think that "fixing" it really requires deep work, rather than being just a simple change. See https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/65230/comments/34 and https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/65230/comments/35 [12:19] Launchpad bug 65230 in upstart "startup messages continue on screen after first login prompt appears" [Medium,Fix released] [12:20] Essentially, as long as console is copied to vc1, vc1 is going to end up with messages after getty presentation. [12:20] (although they may be inordinately delayed in some cases, depending on the activity on the machine) [12:25] Yes, it's probably a lot of work. My hope is that we will one day have a good feedback system. Proper boot logging (bug 328881, my favorite) and readable messages. I used Gentoo a long time ago, and I remember that logging used to be on a separate console. [12:25] Launchpad bug 328881 in upstart "init: support logging of job output" [Medium,Triaged] https://launchpad.net/bugs/328881 [12:36] alvin: well, depending on the implementation, 328881 could be perceived as making the symptoms in 65320 worse, but yeah, if that was in place, then it wouldn't matter as much (because there'd be a good argument for not sending stuff to console anyway) [12:38] could someone set Bug #503315 to triaged? [12:38] Launchpad bug 503315 in nautilus "File access field is not properly updated in folder properties (Nautilus)" [Low,Confirmed] https://launchpad.net/bugs/503315 [12:38] Exactly. It would make finding bugs easier too. I'm trying to pinpoint problems with the karmic boot process, and a log would make life eaier. Oh well... [12:38] s/eaier/easier [12:42] alvin: If you have two machines available, use a kernel argument to use a serial console, and log that. [12:42] (this also works if one has a serial printer or line terminal, but that's usually less likely for modern users) [12:43] persia: I hadn't thought of that. Thanks. About all Karmic machines I'm using have critical boot problems, so I'll try it. [12:43] vish: I won't set it triaged. I can't understand the bug from reading it. [12:44] Low/Triaged: bug 507192 [12:44] Launchpad bug 507192 in kile "Overlapping hotkey Alt+O when using "Find" or "Replace"" [Undecided,Confirmed] https://launchpad.net/bugs/507192 [12:45] yofel: Done. [12:46] persia: thx [12:48] persia: it has been sent upstream , the upstream report is clearer [12:49] persia: the lp user mentions that the permissions are changed but it is not immediately reflected in the peroperties window [12:49] properties* [12:52] vish: Explaining it to me won't help. I won't set it triaged because *I* don't immediately understand the nature of the issue from reading the bug report. Someone else might. Alternately, the description could be updated to better encapsul.ate the issue [12:54] When I try to replicate in my local environment, I can reproduce the described issue, but I can also change the permissions in other ways, and don't expect an update to happen then. [12:54] So, either this bug is asking for nautilus to monitor the permissions and keep the control updated in realtime, *or* it is asking for the control to show the results of the last action regardless of whether these are correct. [12:54] It is entirely unclear from the description and the bug comments which request is considered the bug. [12:55] So even if I was intimately familiar with the relevant code and prepared to make the change based solely on the bug report, I wouldn't know whether I had done so. [12:56] (sorry - momentary client issue) [13:00] vish: Looking at the upstream bug, it suffers from the same issue. [13:00] persia: hmm.. well I'll leave it alone too... ;) [13:02] vish: Alternately, debate with the submitter to determine the requested behavior, and once you believe that the nature of the requested change is clearly obvious, request again that it be considered "triaged". [13:08] so we have a wiki page on "Bug Ownership" and what it entitles (responsibilities associated)? [13:08] do* [13:09] https://wiki.ubuntu.com/Bugs/Assignment is kind of it i guess... [13:09] komputes: What are you trying to accomplish? [13:10] persia: trying to explain (in more detail) what it means for a bug to be assigned to a person [13:10] komputes: Well, it tends to mean different things to different people. [13:10] It might mean "I've put this on my todo list" [13:11] It might mean "Someone else put this on my todo list" [13:11] It might mean "I'm working on it" [13:12] persia: so it doesn't mean "I'm taking, or have been given responsability to fix this" [13:12] It could mean that :) [13:13] For a while, it was also used to mean "I'm the best contact for this bug now" [13:14] so someone would assign themselves when triaging and then unassign when done, but once we got the "Triaged" bug status, we stopped doing that. [13:15] whatever it means, If you feel like assigning a task to another user, get in contact with him/her first [13:15] Or have some prior arrangement that means you don't need to do so. [13:16] (e.g. if you hire someone, you can assign them all the bugs you want, usually) [13:16] ok, thanks. do you feel https://wiki.ubuntu.com/Bugs/Assignment be expanded to include what we have discussed [13:17] komputes: I guess the best way to describe common usage is: 1) Only assign yourself or someone who agrees to let you assign them, and 2) if someone is assigned, contact them before fixing it yourself [13:17] I guess I could add that to the wiki... [13:17] I think the current text of Bugs/Assignment is good. [13:18] Precisely how it gets used is very flexible and changes by individual. By being vague on the wiki, we don't have to argue about which is the "correct" interpretation. [13:19] hehe, good point [13:19] komputes: Do you feel there is a problem with the current definition? What sort of misunderstanding do you think may appear? [13:20] re.. [13:20] I do think it could benefit from the "Contact person (have them agree) before assigning" and "If someone is assigned, contact before starting a fix" guidelines you stated [13:20] persia: will ask for info [13:20] komputes: Well, most of us would rather not be contacted to be asked if we can be assigned. [13:21] persia: but you would rather be contacted than just blindly assigned a bug ;) [13:21] It tends to be more that when people are discussing a bug, and someone plans to fix it but doesn't have it open, that person might say "assign me". [13:22] Or arrangements external to Ubuntu that may cause one person to be able to speak on behalf of another. [13:22] like an upstream contact [13:22] But I think those cases are obvious when they come up, and don't need explicit instruction. [13:22] agreed, self assignment as well [13:23] komputes: I personally don't pay any attention to the list of bugs to which I'm assigned, although I assign and unassign myself to bugs for certain workflows. [13:23] I can't speak for others: depends on whether they use bug assignment to manage their tasks. [13:24] well I hope maintainers of a specific package, look at the bugs for their package [13:24] How do you mean "like an upstream contact"? Something like the Ubuntu Coordinator for the frobnicator team assigns one of the frobnicator developers to work on the bug? [13:24] We don't have maintainers in Ubuntu. [13:24] I don't go through all my bugs either, just check the one that get updated (notified by email) [13:24] Well, we have maintenance teams, but that's not people. [13:25] yeah, maintainer, someone from upstream, or a package adopter [13:25] Again, there are no maintainers. [13:25] in many cases it's not done (i.e. subscribe to bug mail) which is a shame :( [13:25] Upstream might assign themselves, but typically would be assigned the upstream task, rather than the Ubuntu task. [13:25] a package adopter typically wouldn't be assigned to a bug, but rather subscribed to bugs for the package. [13:26] <^arky^> Is there meta bug for CE: hpet increasing min_delt\ [13:26] <^arky^> a_ns to 15000 nsec [13:26] <^arky^> kernel errors [13:29] persia: not assigned, just look, and perhaps subscribe to bugmail for that package [13:29] komputes: Anyway, to get to your next point: I agree it might benefit from the latter addition. Perhaps something like "If the bug task has an assignee, it may be worth contacting them before starting work on the bug". [13:30] Oh, yeah. Lots of people subscribe to bugs :) [13:30] Both people and teams tend to have some set of packages for which they are bug contacts. [13:31] And for a number of the Ubntu workflows, we use subscription as the method of notifying people who might be interested in becoming assigned. [13:32] persia: ok, so i'll add that, but not "It is generally bad etiquette to assign a bug to someone else unless agreed upon together"? [13:33] Personally, I think "...for most packages you should not assign the bug to a person or team" covers that well. [13:33] There are a couple teams that actively request assignment for workflow, so it's risky to be too specific. [13:35] okidok [13:39] Bug #503330 updated and submitted upstream , could someone set to triaged/low [13:39] Launchpad bug 503330 in nautilus "File operation dialogue , the file count and the size count change in opposite direction." [Low,Incomplete] https://launchpad.net/bugs/503330 [13:41] vish, done, i've changed the severity to minor on the upstream report though [13:41] I can't even reproduce that one. [13:41] pedro_: ah , right.. i forgot that :) thanks for reminding [13:42] persia: this was a different but.. :) i havent updated the previous bug yet ;) [13:42] bug* [13:43] vish: the one I can't reproduce is 503330. [13:43] Not to say it isn't there, just that I can't reproduce it. [13:44] persia: you have to try with *several* files[ideally large video files ;) ] to notice it [13:44] I guess I don't have enough of those :) [13:49] <^arky^> Is the DebuggingRemovableDevices wiki page out of date? [13:49] <^arky^> it mentions ck-list-sessions which package provides it ? === gnomefreak is now known as thunderstrck === thunderstrck is now known as gnomefreak === gnomefreak is now known as gnomefreak76 === gnomefreak76 is now known as gnomefreak === gnomefreak is now known as gnomefreak76 === gnomefreak76 is now known as gnomefreak [14:04] oh! it's a hugday today: happy hugday everybody! [14:04] happy bug day thekorn! [14:04] kamusin, is doing an extraordinary work [14:04] * pedro_ hugs kamusin [14:05] * thekorn hugs kamusin too [14:05] yai! [14:07] obj = reduce( [14:07] lambda obj, attr: getattr(obj, attr), path[1:], shell.shell.user_ns[path[0]]) [14:07] type_url = obj._wadl_resource.type_url [14:07] argh [14:07] sorry, wrong window [14:11] Afternoon all [14:20] Who is sergio in LP???? [14:23] xteejx, who is sergio? ;) [14:23] try to search here: https://edge.launchpad.net/people/?name=sergio&searchfor=peopleonly [14:24] thekorn: I found them, just so DAMN annoying changing status he hasnt got a bloody clue what he's doing, have told him not to, so he changed bugs to Fix Committed WTF [14:24] sorry am peed off [14:24] bug 78470 [14:24] Launchpad bug 78470 in xorg-server "switching to current logged in user freezes gdm" [High,Incomplete] https://launchpad.net/bugs/78470 [14:25] oh :( [14:25] hmm [14:25] reported him to #launchpad, dunno what happens [14:29] pedro_: who can i whine to , about the 5-a-day stats not updating? ;) I'v changed my lp name nearly a month ago and it is still stuck with my old name and stats :( [14:30] vish, dholbach might know about that [14:31] pedro_: thanks :) [14:31] you're welcome [14:33] hi pedro_ ;) [14:35] hello there BlackZ [14:36] Guys, who do I speak to about a licensing issue with one of our packages??? [14:37] bdmurray: ping ^^ [14:37] i was told to ping bdmurray too :) [14:38] *by dholbach [14:38] gst-plugins-ugly is licensed by the author as GPLv2, but the copyright added by us or Debian states GPLv3 or later, which hasn't been OK'd by the author# [14:38] bug 181244 [14:38] Launchpad bug 181244 in gst-plugins-ugly0.10 "libcdio GPL/license violation" [High,Triaged] https://launchpad.net/bugs/181244 [14:39] Sun Microsystems stopped distributing libcdio for this reason, we still do for CD/DVD writing.....worrying [14:42] dholbach: ^ Any ideas? The copyright holder themselves reported this in LP [14:43] xteejx, he is not in here ;) [14:43] thekorn: oh yeah lol :) [14:43] Any Canonical guys? [14:43] well it's not a hard bug to fix [14:44] It's beyond my knowledge tbh, what about #motu? [14:44] i [14:44] i'm a motu [14:44] i'll do it right now [14:45] brilliant!! thank you maco!! Just thought I should make people aware as I spotted this... last thing we need is a lawsuit! lol [14:45] hrmm well i can fix the "it says gplv3 and should say gplv2" part easily [14:45] maco, what's your fix, kicking it out, or changing the licence? [14:45] the 2nd part where it says that the code is an incompatible license is more problematic [14:46] thekorn: yeah i just read the whole bug description :-/ [14:46] there *must* be another reason for this not being fixed [14:46] hmmm, none of the GPL licenses AFAIK are compatible [14:47] thekorn: It didn't even have a status/importance until I pinged the bug report [14:47] yeah someone probably didnt even see it [14:48] very likely [14:49] oh dear [14:50] well I'm the self appointed "clear out and check on the old rubbish" guy hehe [14:51] hrmph. i think we need to find someone who knows the licenses very well [14:51] and someone who wants to handle joerg schilling once he gets angry [14:51] hehe [14:52] he is surprisingly clam on that bug [14:52] * thekorn thinks siretart is a good person for this task ;) [14:52] yes [14:52] I wouldn't be that calm about it....thank god he isn't from M$ hahaha [14:52] *calm [14:53] thank god i'm not either ;) woohoo [14:53] hmmm the COPYING file *does* say GPLv2 or later [14:53] maco: I think it's the "or later" part he means [14:53] i.e. he released it under GPLv2 [14:54] xteejx: the bug report at first was complaining that debian/copyright had GPLv2 or later when the code was GPLv2, not "or later" .... but he code *is* "or later" [14:54] so having GPLv3 in debian/copyright should be ok-but-rather-daft [14:55] umm but debian/copyright says GPLv2 or later anyway, so moot point [14:55] I thought he was complaining *because* it was or later, and that he released it as GPL2, so GPL3 would be wrong? Or have I misread it? [14:55] right i understand it, [14:56] it was released as GPLv2 only, but it's also being used by libcdio which is LGPL licensed, which is incompatible with GPL [14:56] im checking the upstream tarball [14:56] ok [14:56] COPYING *should* match upstream tarball, while it's possible a maintainer would get debian/copyright wrong [14:57] however i see COPYING and debian/copyright as matching in lucid's package [14:57] could Debian have got it wrong upstream and we just synced it in like that? [14:59] ok correction, LGPLv2+ [14:59] and upstream tarball, the COPYING in the package, and debian/copyright *all* agree on that [15:00] still a conflict then if the author released source as GPLv2 right? [15:00] oooo jeez im so confused [15:01] gst-plugins-ugly0.10 is the currently marked affecting package [15:01] but they're arguing about libcdio in there [15:01] i think because one calls the other [15:02] we really need this directed to someone high up [15:03] whatever you do, coordinate it with siretart [15:03] libcdio is gnu software so i'd be really darned surprised if it *wasn't* gplv3 [15:03] and it is [15:04] the debian/copyright files are correct for both packages [15:05] maco: but libgstreamer is LGPL ..... thats one of the problems [15:06] yeah i dont know about their interaction too well, but im pretty sure the bug is correct that libgstreamer cannot call gpl shared objects :-/ [15:06] i just know that this person saying "now it says gplv3 when the code is actually gplv2" is wrong [15:06] I'm sooooo confused now [15:08] i think he's saying GNU/FSF changed the license without asking him (one of the contributors) and so he should be whining to GNU/FSF about it [15:09] shall i post this as a comment? [15:09] For gst-plugins-ugly0.10: [15:09] The COPYING file in http://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-0.10.13.tar.gz and in the package in Lucid and the debian/copyright in Lucid all agree that the license is LGPLv2.1+ [15:09] For libcdio: [15:09] The COPYING file in http://ftp.gnu.org/gnu/libcdio/libcdio-0.82.tar.gz and in the package in Lucid and the debian/copyright in Lucid all agree that the license is GPLv3+ [15:09] If you believe that GNU does not have the right to choose the GPLv3+ license for libcdio, please take this up with them. [15:09] that would make more sense, as I'm guessed all we do is grab it from them, or Debian does [15:09] hggdh: hey [15:10] I would try not to pee him off tbh [15:10] hi micahg, hggdh [15:10] hello, I'd like to link solang package with the upstream, how can I do it? [15:10] i dont want to get him upset, just i dont think complaining to individual distros will be nearly as productive as going directly to the people who are making the change to the license [15:10] as *we* aren't the ones who did it [15:10] hi xteejx [15:10] hi maco [15:10] maco: of course :) [15:11] hggdh, do you have any knowledge of GPL and LGPL licensing? [15:11] or micahg [15:11] I think that I have to fill this: https://launchpad.net/ubuntu/lucid/+source/solang/+edit-packaging [15:11] xteejx: depends on how deep you want to go [15:11] jjardon: it's not in lucid? [15:12] ermmm... bug 181244 [15:12] Launchpad bug 181244 in gst-plugins-ugly0.10 "libcdio GPL/license violation" [High,Triaged] https://launchpad.net/bugs/181244 [15:12] we're trying to work it out [15:12] micahg, no [15:13] micahg, http://packages.ubuntu.com/search?keywords=solang [15:13] jjardon: well, the way to do it is to set the upstream link [15:13] jjardon: this will link with solang trunk on Gnome (if I am correct) [15:13] you can link to a bzr branch for the project's upstream [15:13] xteejx: so if i add the line "Getting it changed there will trickle down to all distros instead of you having to ask many individual distros to make changes to the copyright files distributed with their packages." its less "not our bug" and more "this will help you"... right? [15:14] micahg, hggdh the project upstream is here: git://git.gnome.org/solang [15:14] jjardon: we can't do that [15:14] you can link to upstream in LP [15:14] maco: I would guess so, but honestly I'm very wary of licensing issues and believe it should be dealt with by Canonical since its their product [15:15] xteejx: reading the thing now [15:15] micahg, but then I'm going to have a ~jjardon/solang branch, isn't it? [15:15] maco: hang on, hggdh is looking, get a 3rd opinion can't hurt [15:15] jjardon: well, it should be tied to the project [15:15] but i grabbed source for lucid, libcdio is GPLv3 [15:16] so if you're the core dev for it, you can make lp:solang point to your branch [15:16] and then mark it as upstream === BUGabundo is now known as BUGabundo_remote [15:16] micahg, seems that is already done: https://code.launchpad.net/ubuntu/lucid/+source/solang [15:16] no, I'm not the core devel, I'm only want to link a downstream bug with th e upstream one [15:18] oh, you can do that without a branch [15:18] just select the project when you click affect another project [15:18] xteejx: if I am getting it right, the OP is one of the authors, and has not authorised the change from GPLv2 === jsalisbury_ is now known as jsalisbury [15:19] jjardon: it seems like it's not registered [15:19] micahg, I did that but I get an error: There is no project in Launchpad named "solang" [15:19] is the project called solang? [15:19] micahg, yeah ;) [15:19] also, seems libcdio has moved to GPLv3. This -- if I remember correctly -- makes it not kosher to link to LGPLv2 [15:19] micahg, http://projects.gnome.org/solang/ [15:20] jjardon: have hggdh help you register it with the proper owners [15:20] xteejx: this was called by some the TiVO effect [15:20] hggdh, yes exactly [15:20] hmmm? [15:20] i thought the TiVO effect was "sure you can have the code...but if you modify it and it doesnt match our checksum...you're hosed" [15:20]