| nethus | out of interest: what is the decision process behind upgrading the included packages? | 00:03 |
|---|---|---|
| === zz_bigbash is now known as bigbash | ||
| === bigbash is now known as zz_bigbash | ||
| JackyAlcine | How do I find bugs specific to a certain programming language or toolkit (i.e: Qt, GTK, VTK)? | 05:23 |
| hggdh | if you are talking about bugs in the compiler/code generator itself, look for them; otherwise... you have to know the packages... | 07:28 |
| === Hurtz_ is now known as Hurtz | ||
| === bulldog98_ is now known as bulldog98 | ||
| === yofel_ is now known as yofel | ||
| jtokarchuk | Morning. I would like to contribute, but am mainly a Windows programmer. I have made the full jump to Ubuntu now, and would like to know where to start with bugfixes. Should I just grab a small bug and take a run at it? | 14:54 |
| penguin42 | jtokarchuk: what type of languages do you program? | 14:58 |
| jtokarchuk | C, asm, python, java | 14:58 |
| penguin42 | ok, so pretty much everything | 14:58 |
| jtokarchuk | essentially =] | 14:58 |
| penguin42 | jtokarchuk: So pick a bug, but then what you really need to do is look 'upstream' at where Ubuntu gets it from to see if they already fixed it | 14:59 |
| penguin42 | jtokarchuk: Most (but not all) Ubuntu packages come from debian packages, and they in turn come from whoever originally did the program; some of the work with deubgging in ubuntu is searching upstream to see if it's already fixed | 15:00 |
| jtokarchuk | Alright, I have read over the materials online quite a bit as well, but there was one unclear position: Do I need to be running the bleeding edge alpha? or are there plenty to fix in 11.10 | 15:01 |
| penguin42 | jtokarchuk: Well the thing is if you fix stuff in 11.10, unless it's a really important bug it won't get an update out there; however depending what you're fixing, if it's in an application say then you could just build the upstream application and work directly on that and contribute that straight back upstream | 15:02 |
| penguin42 | jtokarchuk: If it's something ubuntu specific, say the installer, unity or the like it's probably best to work on bleeding edge - maybe in a VM | 15:03 |
| jtokarchuk | Alright, so would testdrive be a usable solution for that? I had read about that. | 15:03 |
| penguin42 | jtokarchuk: Yeh that works, although what I do is I have a VM set up with quite a lot of RAM and disk and cpus configured so I can do builds and big stuff in the VM | 15:04 |
| penguin42 | jtokarchuk: But I'd say the 1st thing is choose the type of thing you're interested in debugging, because depending on the app it can take quite a while to learn the innards of the way it goes together and to find the bug | 15:05 |
| jtokarchuk | that works too, so just download a developer build and away I go | 15:05 |
| penguin42 | nod | 15:05 |
| penguin42 | jtokarchuk: The time scales of what bugs are important when varies as well; so with Precise at the moment going into alpha then it's all about getting fixes in for stuff broken in Alpha | 15:06 |
| jtokarchuk | Makes sense. | 15:07 |
| penguin42 | jtokarchuk: Some projects work mostly upstream though; like KDE stuff for example they seem to like to work on the main KDE sources and they have their own way of doing things | 15:07 |
| jtaylor | jtokarchuk: that is a good way to get started, you can find small bugs on harvest.ubuntu.com | 15:10 |
| jtokarchuk | Excellent. I am quite excited to get started. Have to run though, thank you for the ood info | 15:10 |
| jtaylor | wow that message took 10 min to get through :O | 15:10 |
| jtokarchuk | good | 15:11 |
| jtaylor | stupid flaky connection | 15:11 |
| penguin42 | jtaylor: Your censor wet for a rest break | 15:13 |
| penguin42 | n | 15:13 |
| jtaylor | ^^ | 15:13 |
| yofel | does someone know how to intentionally freeze the kernel during boot? I'm getting so many errors from 3.2.0 in precise that I can't read them | 15:25 |
| yofel | and "doesn't boot" isn't much of a bug report | 15:25 |
| penguin42 | you can put a delay between each message | 15:32 |
| penguin42 | yofel: Try boot_delay=100 - that will put 0.1s between each line of output from the kernel itself | 15:33 |
| yofel | thanks, I'll try that | 15:34 |
| === bladernr_ is now known as bladernr_afk | ||
| === Elbrus_reconnect is now known as Elbrus | ||
| penguin42 | is the fact I can't install liborc-0.4-0:i386 without uninstalling a load of 64bit stuff a bug in liborc itself or in something else? | 16:34 |
| Ampelbein | penguin42: maybe something to do with it not being multiarched yet? | 17:18 |
| penguin42 | Ampelbein: That's the conclusion that Yofel suggested in +1, so I filed bug 899650 on it | 17:21 |
| ubot4 | Launchpad bug 899650 in ubuntu "liborc-0.4-0 not allowing multiarch install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/899650 | 17:22 |
| Ampelbein | penguin42: oh, sorry, didn't see the discussion in +1. | 17:22 |
| penguin42 | np | 17:22 |
| Ampelbein | penguin42: I changed the affected package to "orc" (the source for liborc-0.4-0) | 17:24 |
| penguin42 | oh ok, I thought lp did that automagicall | 17:24 |
| penguin42 | y | 17:24 |
| Ampelbein | I think it only works with apport filed bugs. And there is a QA-bot script running that tries to guess packages. | 17:25 |
| penguin42 | bah, lp is sulking for me anyway at the moment | 17:26 |
| penguin42 | Ampelbein: Oh gah - now I understand your comment; I thought I'd clicked the Report Bug from within the right package | 17:56 |
| needhelp1 | yellow | 21:29 |
| penguin42 | green | 21:29 |
| ashams | who said blue? | 21:31 |
| hggdh | no, it was cyan | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!