[00:13] howdy!! Library packages are not supposed to have Depends on ${python:Depends}, or are they? === dendrobates is now known as dendro-afk [00:50] andreserl: Please don't ask the same questions in multiple channels just a few minutes apart. === dendro-afk is now known as dendrobates [01:43] anybody experienced problem using gnash on maverick? [01:43] mnajem got it using CPU usage almost 100% [01:44] * RAOF wonders how that's different to the regular flash player… [01:45] can someone remind me/point me to the documentation of what's special about the "metapackages" section? [01:45] mnajem: Likely you'll want to file a bug, particularly if you can find a reproducible way of making it misbehave. [01:45] ScottK, just noticed that question was more appropriate for -motu that's why I repeat the question there [01:45] mwhudson: I don't know about docs, but I think it's implemented by a file in /etc/apt/apt/conf.d [01:46] RAOF, thanks [01:46] andreserl: In that case, it'd be nice to mention it in the first channel so multiple people don't consider answering the same question. [01:47] ScottK, ok :) I'm answering in -motu now [01:47] OK [01:48] ebroder: thanks, so it seems my next question is "what does Never-MarkAuto-Sections mean" :-) [02:03] * sanchaz off to bed === sanchaz is now known as sanchaz-away === asac_ is now known as asac [03:02] kirkland, ping? [03:02] andreserl: hi [03:03] kirkland, howdy!! quick question :). Ok so I've got another action for powernap. [03:03] andreserl: k [03:03] kirkland, In lower power state, I change the CPU governor from ondemand to powersave, which sets the CPU freq to 800MHz. Do you know if it is possible to even set it lower by hardcoding the frequency? [03:04] andreserl: it's not possible [03:04] andreserl: i'm pretty sure that that should already be covered by pm-powersave [03:04] andreserl: ie, i don't think you need to do that one [03:05] kirkland, there doesn't seem to be any script that actually does that [03:05] so that's why I did it [03:05] I'll ask pitti tomorrow :) [03:06] andersk: ah, okay, then yeah, that's a good one [03:06] andreserl: ^ [03:07] kirkland, but for example, when it is ondeman it will allow the CPU to automatically change the frequencies. If I set it to powersave, it will stay in 800Mhz always [03:07] andreserl: cool [03:07] kirkland, ok then :). Anyways, other than that, now that this scripts will be in pm-powersave, Should I still keep the feature to be able to enable/disable scripts, and list which ones are enabled/disabled? [03:08] andreserl: nah [03:08] andreserl: i don't think it's necessary [03:08] andreserl: if it is, it probably belongs in pm-utils [03:12] kirkland, ok then :) thanks for the input. Btw.. I presented it yesterday in class and professor was very satisfied with it [03:17] andreserl: great! [03:19] kirkland, They were asking me so many questions about it, that I ended up explaining the whole project instead of just the part that was supposed to be done for the course project. [03:19] andreserl: heh [03:19] cool === dendrobates is now known as dendro-afk === emma_ is now known as emma === manusheel_afk is now known as manusheel [04:05] hi guys. i have a rather technical question: i am sshing into a Solaris system at work using gnome-terminal. keys like control+arrowkey don't work. how do i start to troubleshoot this problem? it's been causing me a lot of grief === manusheel is now known as manusheel_afk === almaisan-away is now known as al-maisan === _LibertyZero is now known as [DooF][HC]Libert [06:28] GOOD MORNING! === amitk is now known as amitk-afk === amitk-afk is now known as amitk === ivoks-afk is now known as ivoks === ivoks is now known as ivoks-afk === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === hrw|gone is now known as hrw === [DooF][HC]Libert is now known as LibertyZero [09:06] can someone please accept the nomination for maverick in bug 617885 so it doesn't vanish from the sponsoring queue [09:06] Launchpad bug 617885 in gparted (Ubuntu) "gparted crash at start: glibmm-ERROR **" [Undecided,Fix released] https://launchpad.net/bugs/617885 === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === davidbarth is now known as dbarth === dmart_ is now known as dmart [11:39] geser: done === ivoks-afk is now known as ivoks === dendro-afk is now known as dendrobates === amitk is now known as amitk-afk === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === xfaf is now known as zul === dbarth_ is now known as dbarth === al-maisan is now known as almaisan-away [14:07] ScottK: morning. i was off on another desktop for a bit. py3.2 is not building? [14:10] jelmer: did bzr-svn 1.0.3 affect compatibility with previous mappings? [14:11] jelmer: I have a (fairly important and complicated) branch which I believe I last pulled using 1.0.2; 1.0.3 now says "These branches have diverged" [14:11] cjwatson: no, the mappings haven't changed since 0.4.x IIRC [14:12] jelmer: if you have a moment, it would be great if you could have a look at lp:~cjwatson/debian-installer/main vs. svn://svn.debian.org/svn/d-i/trunk/installer - I'm not sure how to investigate further [14:12] cjwatson: what does "bzr missing" say about the differences? [14:12] cjwatson: I'll have a look [14:13] jelmer: it says there are no common revisions [14:14] missing back to r1 both sides [14:14] it also had to completely refetch the svn branch when I did 'bzr pull' earlier === drizztbsd_ is now known as drizztbsd [14:18] builds are broken right now, yes? [14:20] directhex: hmm? [14:21] oh, perhaps not. was misreading the log [14:23] well, happy to look if you spot something [14:30] a mere bashism === zyga is now known as zyga-coffee === zyga-coffee is now known as zyga [15:08] kirkland: overheard @ plumbers: PROC_EVENTS [15:09] kirkland: that can be used to get notifications about new procsses, forks, etc., for the server powernap thingy we discussed [15:09] kirkland: so, we wouldn't need to poll any more [15:09] http://lwn.net/Articles/157150/ [15:09] kirkland: I haven't researched details yet [15:09] is that the same as the netlink proc connector? [15:09] cjwatson, do you mind if I assign bug #662276 to you? it seems you usually do the vim merges in Ubuntu [15:09] Launchpad bug 662276 in vim (Ubuntu) "Merge vim 2:7.3.035+hg~8fdc12103333-1 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/662276 [15:09] yes, apparently so [15:09] cjwatson: presumably yes [15:09] cjwatson, geser did the work, it just needs review and sponsoring [15:10] cjwatson: I just wasn't aware of this before [15:10] seb128: it's already queued in my browser, at geser's request; go ahead [15:10] it's not race free, thus not suitable for upstart & friends [15:10] cjwatson, ok thanks, I'm just tried to clean the sponsoring queue a bit [15:10] I'm trying to get natty builds working as a priority, that's all [15:10] cyphermox: any luck with dhcp? [15:11] kirkland: /usr/src/linux-headers-2.6.36-1/include/linux/cn_proc.h is the API [15:11] cjwatson, I haven't had time to get back to it, but I will in a few minutes... afaik it's good now as soon as I upload NM with the added Breaks and give it a quick test [15:12] music to my ears [15:13] cjwatson, I already have a scratch system upgraded to natty so I can try the ppa [15:21] pitti: how is proc connector race-y? Because I think Keybuk was talking about using it to deal with some double-forking issues in upstart [15:22] it sounds like pitti has been listening to lenny [15:22] ebroder: I don't know the details; Lennart just said that it's not the right thing to use for pid 1; perhaps they don't get queued properly, so that you miss events when you don't get scheduled in for a while [15:23] but as I said, IANAKD, and only parrotting here [15:23] but either way, it seems more than appropriate for powernap [15:24] Lenny is wrong, fwiw [15:25] the last time I used the proc connector, my monitoring process was getting woken up frequently enough that it caused a performance hit - I had to add some code to only process events after they'd spent some amount of time queueing [15:26] that's because it's a bit of a firehose [15:26] and includes all clone() calls, not just fork() ect. [15:26] so you get notifications as threads come and go as well [15:26] right, right. and to be clear, when i talk about a performance hit, i'm talking about a hit on running ./configure on something :) [15:27] so you use the socket filter api over top of it, so you just get the events you're actually interested in === deryck_ is now known as deryck [15:36] ebroder: clearly, you should run ./configure on Cygwin instead, since it has none of these advanced APIs! === dholbach_ is now known as dholbach === deryck_ is now known as deryck [15:43] barry: https://launchpad.net/ubuntu/+source/python3.2/3.2~a3-2 [15:47] ebroder: the current powernap uses polling (like 20 times a second), which hardly sounds more efficient [15:48] sure. I had no idea there was a socket filtering api. it looks awesome [15:59] pitti: Do you have some free time to review a library split for cluster-glue? [15:59] RoAkSoAx: not this week, sorry (i'm on a conference) [15:59] pitti: ok no prob :) === Guest63625 is now known as jelmer [16:11] cjwatson: Still there? [16:11] cjwatson: I've pulled down those two repositories and am looking at them at the moment. [16:12] jelmer: here [16:12] Hi I am having trouble with 10.04 and a CQ50-110US laptop any help. [16:12] cjwatson: it appears as though the first branch was still using the old (pre-bzr-svn 0.4) style mappings. [16:12] ah, that's possible, I created it a long time ago [16:12] cjwatson: did you perhaps change machines, or did you move the branch? [16:13] the initial import was in November 2007 [16:13] cjwatson: newer versions of bzr-svn would still have used the older style mappings if they were configured to do so [16:14] I've switched disks since then, but I did a full-system restore [16:15] http://paste.ubuntu.com/525745/ - contents of ~/.bazaar/subversion.conf [16:15] still seems to be configured there [16:15] I don't think I moved it in the filesystem. What's the UUID of? [16:16] cjwatson: it's the UUID of the remote subversion repository [16:17] I would be surprised if that had changed, but I suppose it's possible - how would I check? [16:17] cjwatson: 'svn info svn://svn.debian.org/svn/d-i' should tell you [16:17] it doesn't seem to have changed though [16:18] so maybe this is a regression in bzr-svn's backward compatibility support === beuno is now known as beuno-lunch [16:18] I'm happy to try the version in natty if you think that would help, or try other debugging [16:27] cjwatson: I'm currently checking if I can reproduce it here (trunk) with your configuration [16:30] ta [16:34] Hi guys ;D [16:41] My Nvidia 8200M G does not do compositing....For what ever reason. [16:43] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [16:43] 1280 root 20 0 1293m 843m 274m S 4 22.0 495:25.71 Xorg [16:43] * nemo sighs [16:52] pitti: sweet! [16:53] RoAkSoAx: see PROC_EVENTS from pitti, http://lwn.net/Articles/157150/ [16:53] pitti: that's pretty awesome [16:55] 00b4e000-25362000 rw-p 00000000 00:00 0 [heap] [16:55] hm [16:56] I guess I could try a gdb dump of that... [17:01] damn. tried attaching to the process and Xorg went wild. now uses 100 megs more of memory and 100% of CPU [17:02] appears to be ignoring gdb's request to suspend [17:08] * nemo sighs and kills it [17:08] so today's attempt to figure out my massive Xorg leak in maverick, once more driven back [17:08] kirkland: ok will take a look at it :) [17:08] heh. gdm stop failing [17:09] hard kill time [17:09] -2 ignored, -4, on to -9 [17:11] kirkland: so we could change the process monitor to use that instead of examining the process table. and not do it through upstart? === dendrobates is now known as dendro-afk === manusheel_afk is now known as manusheel === dendro-afk is now known as dendrobates === almaisan-away is now known as al-maisan === zyga is now known as zyga-nc10 === beuno-lunch is now known as beuno [18:01] TheMuso: hi! say, if you have some time, ScottK recommended that i chat with you about maverick on my powermac g5 dual 2.7. i'm trying to get a ppc box up - it actually installed fine, but seems to be very unstable when running under maverick [18:02] barry: I should have mentioned that there is #ubuntu-powerpc too. [18:02] ScottK: ah, that's probably a better place to ask. /me joins and re-posts === yofel_ is now known as yofel === manusheel is now known as manusheel_afk [18:36] first d-i installation images for natty are up, but don't bother testing them, there's a fatal udpkg bug. fixed upstream and will trickle down tomorrow or so [18:36] (no CD images yet) [18:37] * SpamapS relaxes the trigger finger poised over his wget window... [18:37] * highvoltage is itching for cd images [18:37] highvoltage: maybe try baby powder for that? [18:37] SpamapS: well, I upgraded to Natty on my laptop and that helped a bit [18:38] So.. has anyone seen chromium's method of source distribution and dependency specification.. they're pretty much throwing tarball out the window in favor of svn repository@revision === brianchidester is now known as brianchid [18:39] a lot of that's just an artifact of how the internal repository management stuff works at google [18:40] http://src.chromium.org/viewvc/chrome/releases/9.0.572.0/DEPS?revision=65042&view=markup === al-maisan is now known as almaisan-away [18:42] It does not jive well with making packages. :-P [18:43] no reason you couldn't generate tarballs as an archive format from svn repository@revision [18:43] SpamapS, You might want to look at some of fta's scripts to handle that sort of thing. [18:47] Indeed, it seems the only traditional "release" that is provided is these DEPS files .. [18:48] So.. hmm.. create a tarball with the svn revno pointed to... [18:48] persia: http://people.ubuntu.com/~fta/chromium/ [18:48] persia: that stuff? [18:48] SpamapS, Well, the stuff that generates that stuff (and the daily builds and the license-analysis tools, etc.) [18:49] Catch fta and he can likely tell you lots more about them. [18:50] fta: when you have a moment, I'd love to discuss your tools for extracting/handling chromium sources for building packages (I will send an email too) [18:50] * SpamapS understands fta is probably past EOW for the day. [18:51] SpamapS, hi. no, i'm still here. what do you want to know? [18:52] fta: so I'm wanting to build mod_pagespeed .. which depends on the depot_tools from chromium... [18:52] fta: seems like there are a whole bunch of hoops to jump through to get all of this packaged in a traditional manner. [18:53] fta: persia suggested that you may have gone through some of this pain already. [18:53] SpamapS, not really, assuming you have the correct DEPS file in your project [18:54] it's kind of easy once you have depot_tools, you need to call gclient [18:54] fta: right, so shouldn't depot tools be a package? [18:55] SpamapS, well, so far, it was just used by chromium [18:55] I don't want to build it just to play with it.. I really want to package it the right way. But its hard to know what the version of depot_tools is. [18:56] I'm happy just working backward, and making the version the revno that is pointed to by my DEPS file ... [18:56] fta: is depot_tools included in a binary package already? [18:56] SpamapS, it's small enough to be carried. there's no release for this i'm afraid [18:57] Could we create a "release" sequence to prevent code duplication? [18:57] sure [18:58] i already did it for gyp [18:58] as i needed it for at least 2 packages [18:58] Version: 0.1~svn840-0ubuntu1 [18:58] yep [18:58] so just make a chromium-depot-tools 0.1~svnXXXX [18:58] but it doesn't include depot_tools [18:59] upstream will hate me if i do that [18:59] :) [19:02] wait.. so.. chromium's build process seems to do svn co's .. [19:02] how does that work on a buildd? [19:02] oh wait thats just in gos [19:03] aha, so the magic is in get-original-source .. ok its making sense to me now [19:03] SpamapS, We can always create a tarball from a known revision (and there are good scripts to automate this) [19:05] since src/depot_tools is already in the chromium source.. we can just create a chromium-depot-tools package and install it.. [19:05] Wait: what's the bit about upstream hating this? [19:06] I'm not sure they would hate this part [19:06] SpamapS: you should be careful with that as chromium has a micro-release exception, so the tools will change in a stable release === manusheel_afk is now known as manusheel [19:07] micahg: I think thats ok. Things that build-depend on the tools currently all suggest as a first step 'svn co tool_url/trunk' [19:07] micahg, That's fungible, to a certain degree. [19:07] SpamapS, i do something like this: http://paste.ubuntu.com/525875/ [19:07] fta: why do all of the packages in chromium pre-depend on lzma btw? [19:08] SpamapS, because my debs are compressed with lzma, and if you don't have it, bad things will happen [19:08] persia: right, but people might be shocked if they can non longer regenerate a source for a package in a stable release due to the depot_tools changing [19:08] fta: ahhh good to know [19:09] hi guys. i have a rather technical question: i am sshing into a Solaris system at work using gnome-terminal. keys like control+arrowkey don't work. how do i start to troubleshoot this problem? it's been causing me a lot of grief [19:09] i say "technical" but i guess what i mean is old-school. the new school users with their GUIs for everything would probably have no idea where to begin [19:10] hdon: #ubuntu-server may be a better place to ask. :) [19:11] persia, upstream hated me when i split gyp from chromium, it was not meant to be used outside of chromium, yet it's perfectly usable outside [19:11] SpamapS, thanks ! [19:11] fta: even though its being used all over the place now.. page-speed.. mod_pagespeed.. all using gyp and gclient [19:12] SpamapS, didn't know it. i'm glad to hear it. are those all google stuff? [19:13] fta: yes [19:13] ok, makes sense [19:13] I'd really like to get mod_pagespeed into natty and backport it to lucid so that people don't have to get a binary only .deb from google [19:15] Best place to start is probably a discussion with upstream to make sure there is shared agreement on how the pieces work together. [19:17] Their build instructions are pretty uniform.. svn co whatever the latest depot_tools are .. add them to your PATH .. type gclient.. [19:18] Sure, but if multiple projects are sharing the same dependencies, and they want to have feature changes or API shifts in the dependencies, they must have a way to track them, which system, if we used, would probably make our offerings less offensive. [19:19] the gclient script even runs svn up on the dir if it can. [19:20] persia: from what I'm seeing.. they're pretty much in the "the latest crack is the only crack" mode for these tools.. [19:20] yes, it's doing a lot of magic.. too much for my taste. that's why i added the --nohooks [19:21] They do lock it down with the other bits though.. just not this particular one. [19:22] otherwise, it runs gyp which needs all the -dev packages installed.. which i don't have/want in the box i use to create my tarballs [19:24] The wrapper for gclient seems to just be concerned with getting the latest crack.. [19:26] or .. maybe we should just get out of upstream's way and put this in multiverse. :-P [19:26] SpamapS, multiverse doesn't help with the security aspects, and it's only for non-free software anyway. [19:26] indeed. multiverse is not a dumping ground for stuff that's just bad. [19:28] Right, the question is.. when upstream wants their stuff updated every time it runs... can we accomodate that? [19:29] SpamapS: -backports? [19:29] SpamapS: every time it runs? [19:30] We don't do runtime updates: fails the case where there is no internet access (consider a small LAN on the moon: latency to upstream is too painful) [19:30] http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/gclient?revision=63234&view=markup [19:31] update_depot_tools updates everything from svn [19:31] and? [19:31] persia: agreed. Your point about talking with upstream is I think even more important. [19:32] SpamapS, i just use it in my get-orig-source rule, which happens on my side, before i send the source package to the builder [19:32] fta: right, but thats going to violate debian policy (maybe its ok in ubuntu?) if I do that for mod_pagespeed. [19:33] No embedding of convenience copies of source code IIRC. [19:33] http://www.debian.org/doc/debian-policy/ch-source.html section 4.13 [19:33] having a separate package for that is not needed. would even make my life even harder as it's one more dep to track and to update along with chromium for lucid up to natty for each release === dendrobates is now known as dendro-afk [19:34] hmmm actually.. the wording is different than I remembered it.. [19:34] "packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way" [19:35] was already though enough to get the SRU expection for chromium, its codecs and gyp. I don't want to return there ask for another tiny bit ;) === sanchaz-away is now known as sanchaz [19:35] tough [19:36] right, I'm thinking more than the chromium package can just spit out its version of depot_tools as a binary package.. and then we just rally around that. [19:36] s/than/that/ [19:37] btw, chromium also provides a real tarball, something like 2GB compared to my already huge 180MB stripped tarball [19:37] some distros requested it, so they don't have to fight with svn [19:38] but it's regularly broken [19:38] I like the get orig source method. [19:38] it makes perfect sense. [19:38] i like it too, but most people hate me for this [19:38] SpamapS, The no-convenience-copies bit is mostly a maintainability thing: when things aren't used elsewhere, nobody cares that much. See libgyp as an example: once there were two users, it needed to get split. [19:39] i might be wrong, but i think our LSB is broken [19:39] killproc doesn't work [19:39] ivoks, What gives you that impression? [19:40] persia: : [19:40] killproc KILL /usr/sbin/corosync [19:40] /sbin/start-stop-daemon: signal value must be numeric or name of signal (KILL, INT, ...) [19:40] without a signal, it returns 0, but the process is still running [19:40] it's documented as killproc pathname [signal] [19:40] /usr/share/doc/lsb-base/README.Debian.gz [19:41] fta: so if I sent you a patch to have chromium output gclient as a binary package, would you be alright with that? [19:41] cjwatson: same results [19:41] * fta should make some tests to see if xz is faster than lzma.. lzma takes ages to compress my tarballs :( [19:41] it doesn't kill it [19:42] I know no more. (It seems to be the other way round in this SuSE man page I found under a rock, though ...) [19:42] you could just use pkill [19:42] in suse/redhat it works in a way that it sends TERM, waits [19:42] then if it doesn't exit, sends KILL [19:43] if signal is specified, it sends signal and exits (without waiting for the results) [19:43] ivoks: is this hardy by any chance? [19:43] it's lucid [19:43] ah, ok === dendro-afk is now known as dendrobates [19:44] and we get this for free :) [19:44] /sbin/start-stop-daemon: warning: this system is not able to track process names [19:44] longer than 15 characters, please use --exec instead of --name. [19:45] fta: you might also want to check lzip [19:45] (by using killproc) [19:46] SpamapS, ..i don't particular the idea of a system gclient. it's already proven weak several times, creating incomplete and unusable tarballs, like when google changes the format of the DEPS files, that's why there's no upstream release, forced me to do XX+0 fake versions :( [19:48] micahg, tought about xz because it superseded lzma, and broke my backports in the process [19:48] fta: well crap! [19:48] fta: actually [19:49] fta: then that suggests its more like a generated configure/aclocal.sh script than stable system tool.. and probably doesn't need to be packaged.. yet. [19:49] micahg, (because tar -c --lzma -f creates a xz file on maverick which can't be opened on hardy with the same command which really expects lzma) [19:50] SpamapS, not exactly, configure/auto* is more equiv to gyp. gclient is a source fetcher, capable of running hooks, incl gyp [19:51] and it's a moving target [19:51] !ohmy > SpamapS [19:51] SpamapS, please see my private message [19:51] * SpamapS just mispelled the common fish.. he swears! [19:52] “crap” warrants !ohmy? :-) [19:52] Everybody craps. [19:52] fta: ok, I guess you have to wait another 6 months to upgrade to lzip [19:52] ion, Only once in a while. [19:52] ion: no, craps is a gambling game in Vegas [19:53] eheh [19:53] fta: given that chromium would spit it out, only to support a few of the other bits building.. I think the other bits can adapt to chromium's massiveness... [19:54] * fta attempting one more time to land the launchpad translations into chromium... [19:54] drum rolls.. [19:55] SpamapS, another reason i'm reluctant is that i do tons of builds: http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html [19:55] (and i have to fix the new beta too, damn) [19:56] (and the prepare the new stable too) [20:01] grrr, failed. a translator turned a "" into "" making a xml.sax parse error :( [20:03] There are comments in translatable strings? [20:05] ebroder, Consider rather that there may be translatable comments being exposed to users. [20:05] persia: That sounds like they're no longer comments [20:06] ebroder, use/mention. It's a comment *as part of the UI*, rather than a comment in the code. [20:09] i should reject those and alert the translator, not sure how to do that with launchpad though... [20:17] hi [20:19] hm [20:19] quitet in here [20:19] quiet :p [20:19] people don't usually respond unless there's an actual question ... [20:20] ok [20:20] sorry [20:21] i'm quite new in the linux world [20:21] but i'm a developer [20:21] and i'm interested in ubuntu development [20:22] what are the main languages that are used to create the ubuntu os? [20:22] C, Python, POSIX shell, C++, Perl, various others. my experience is that it helps greatly to be flexible [20:23] bear in mind that the bulk of the actual code is written in other projects, and integrated in Debian and/or Ubuntu [20:25] okay [20:26] i've read the ubuntu documentation on how to set up the dev environment [20:26] but are there many articles on the actual development [20:26] debugging [20:26] packaging [20:26] submitting code [20:26] ... [20:27] http://wiki.ubuntu.com/UbuntuDevelopment and http://wiki.ubuntu.com/ContributeToUbuntu are full of links that should help [20:31] deyaert: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html [20:32] which languages you'd recommend [20:32] deyaert: it's less about what language and more about what you want to do [20:32] depends what you want to do [20:32] jinx [20:33] personally I work on Hedgewars, but that's not ubuntu specific. I'm just hanging out here hoping to glean suggestions on a memory leak in Xorg [20:33] bugfixing is quite a general subject [20:33] Depends on your interests. You can be productive with even a bit of shell. [20:33] deyaert: it's true, but you're better off starting more focused than "fixing bugs in ubuntu". something like "fixing bugs in empathy" or whatever [20:33] I never recommend any particular language - it's definitely more important to find something that interests you and work from there [20:33] it's all new for me [20:33] i mainly developed in java and c# [20:33] and i come from the windows world :-) [20:33] deyaert: well are you using ubuntu now? what bugs you about it? [20:33] start with things that are comfortable for you then [20:34] Ubuntu has code in practically every language under the sun, somewhere [20:34] but you hear about a lot of languages [20:34] if you know c#, you could look at some of the mono apps like banshee and tomboy [20:34] perl python ... [20:34] mono I've worked with [20:34] if you want to pick up more languages, go for it, but there's no reason you should feel constrained by what the bulk of the base system is written in when you're starting out [20:34] but that's more for application development not? [20:34] Ubuntu contains applications written in Mono [20:35] yea? [20:35] out of the box? [20:35] which ones? [20:35] ebroder just gave examples [20:35] deyaert: http://ubuntuforums.org/showthread.php?t=51003 (more on packaging) [20:35] tomboy is out of the box, banshee is currently an add-on but is due to be out-of-the-box in natty [20:35] and i think gbrainy is the other mono app included by default [20:36] okay [20:37] if you want to develop for example [20:37] a cross platform installation [20:37] Ubuntu is full of stuff that is not distributed out of the box, though [20:37] is there a way that the ubuntu team whould pick up the application [20:37] and supply it by default? [20:37] maybe, although that's not really a good place to start [20:38] the space available for things to be installed by default is *very very restricted* [20:38] I would not advise starting with that as a goal, because chances are you would be disappointed [20:38] lots of things are distributed in our repositories for later addition, though [20:39] if you want to develop applications for use on Ubuntu, there's a way to get them into extras.ubuntu.com and make them available in software-center; that's one route [20:39] ok [20:39] but i'm also interested to fix bugs [20:39] as a hobby [20:40] that's great, we have several tens of thousands of them [20:40] :-) [20:40] i've taken a look at some bugs on the site [20:40] but on most of them it's not mentioned the language [20:40] it's not always that detailed? [20:41] almost never, that's not the way things are laid out [20:41] as folks said above - it's much better to find something that bothers you personally and that seems to be in an environment you're familiar with, fix that, and repeat [20:42] that's true [20:42] I think I should read some more about it then [20:42] that's certainly how I started, and I suspect that's how a lot of successful developers get started [20:44] find annoying thing that seems vaguely accessible, grab relevant source code, read until you understand where the problem is, hack until you've fixed it, clean up patch for submission, send off, polish as requested [20:45] you've fixed a lot of bugs? [20:45] yes [20:45] haha. cjwatson has probably fixed more bugs than everyone else in the channel put together :-P [20:45] hehe [20:46] yeah i'm just curious [20:46] for me it's all new :-D [20:46] (I wouldn't say that ...) [20:46] and what kind of bugs? [20:46] I mostly work on the installer and the boot loader [20:46] deyaert, Best to start with something that bothers you, grab the source, and dig in. If nothing makes sense, find something else that bothers you. If it only makes a little sense, ask for help. [20:46] various other things on the side [20:46] what persia said [20:47] ok [20:47] i'll start looking for something that bothers me :-) [20:47] * persia learned to read and patch C++ solely from help given attempting to fix bugs in Ubuntu [20:48] cjwatson, and what kind of languages are used over there [20:51] deyaert: boot loader: almost entirely C with a bit of assembly (and some scary stuff in the build system). installer core: C and shell. graphical installer frontend: Python. [20:53] damn [20:54] :-) [21:10] Hi everyone! I was wondering if someone could help me with something. I've been following a bug in KDE that prevents you from switching users when you have GDM enabled === Pilif12p is now known as Tannerbot_Log [21:10] the bug has been fixed in trunk and i've done a patch that "backports" the bugfix into the version that is in 10.04 LTS === Tannerbot_Log is now known as Pilif12p [21:11] ... my question is... what do I do now? what is the "correct" process for getting a patch into ubuntu LTS when you don't need to file a new bug (cos its fixed already) [21:12] !sru | real_ate [21:12] real_ate: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [21:16] ebroder: thank you for the information [21:18] Looking at it... it seems like the bug that I'm trying to fix doesn't fit into any of the catagories of a sru [21:18] it seems like it is more of a backport or something [21:18] I'm not sure [21:19] real_ate: so it's probably not a severe regression, but is the patch "obviously safe"? [21:19] can someone give me their opinon on the matter? the bug, I don't think that it has an ubuntu launchpad bug, can be seen here: https://bugs.kde.org/show_bug.cgi?id=186198 [21:19] real_ate, For backports, we generally like to use the latest upstream (which may include a fix), but we don't much like it for bugfixes, unless there are also new features. [21:19]