[00:03] <nethus> out of interest: what is the decision process behind upgrading the included packages?
=== zz_bigbash is now known as bigbash
=== bigbash is now known as zz_bigbash
[05:23] <JackyAlcine> How do I find bugs specific to a certain programming language or toolkit (i.e: Qt, GTK, VTK)?
[07:28] <hggdh> if you are talking about bugs in the compiler/code generator itself, look for them; otherwise... you have to know the packages...
=== Hurtz_ is now known as Hurtz
=== bulldog98_ is now known as bulldog98
=== yofel_ is now known as yofel
[14:54] <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:58] <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:59] <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
[15:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:10] <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:11] <jtokarchuk> good
[15:11] <jtaylor> stupid flaky connection
[15:13] <penguin42> jtaylor: Your censor wet for a rest break
[15:13] <penguin42> n
[15:13] <jtaylor> ^^
[15:25] <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:32] <penguin42> you can put a delay between each message
[15:33] <penguin42> yofel: Try boot_delay=100     - that will put 0.1s between each line of output from the kernel itself
[15:34] <yofel> thanks, I'll try that
=== bladernr_ is now known as bladernr_afk
=== Elbrus_reconnect is now known as Elbrus
[16:34] <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?
[17:18] <Ampelbein> penguin42: maybe something to do with it not being multiarched yet?
[17:21] <penguin42> Ampelbein: That's the conclusion that Yofel suggested in +1, so I filed bug 899650 on it
[17:22] <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:24] <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:25] <Ampelbein> I think it only works with apport filed bugs. And there is a QA-bot script running that tries to guess packages.
[17:26] <penguin42> bah, lp is sulking for me anyway at the moment
[17:56] <penguin42> Ampelbein: Oh gah - now I understand your comment; I thought I'd clicked the Report Bug from within the right package
[21:29] <needhelp1> yellow
[21:29] <penguin42> green
[21:31] <ashams> who said blue?
[21:37] <hggdh> no, it was cyan