[00:12]  * ari-tczew is going to celebrate birthday
=== MTecknology is now known as NoNickAssigned
=== NoNickAssigned is now known as MTecknology
[07:16]  * nigelb moves to the more appropriate channel
[07:16] <nigelb> So, the project I'm talking about is open Komodo
[07:16] <nigelb> http://www.openkomodo.com
[07:20] <nigelb> They claim mozilla license, but I could use some help reviewing the license to confirm compatibility with universe.
[07:20] <nigelb> My interest: One of the rare IDE's that actually is good.
[07:21] <persia> Do you have a link to the license?
[07:22]  * nigelb looks
[07:22] <nigelb> http://www.openkomodo.com/openkomodo
[07:24] <persia> Oh, that just links to upstream licenses.  All of those ought be fine.  The issue that some folk have with firefox has to do with the trademark license, not the source license.
[07:24] <nigelb> Ah.
[07:24] <nigelb> So, it packageable.
[07:24] <micahg> nigelb: debian 503135
[07:24] <ubottu> Debian bug 503135 in wnpp "RFP: openkomodo -- IDE based on the Komodo IDE" [Wishlist,Open] http://bugs.debian.org/503135
[07:24] <nigelb> Now to figure out if the open source version works.
[07:24] <nigelb> micahg: sigh.  I should learn to search
[07:25] <micahg> nigelb: you're still good to package it as no one appears to be working on it
[07:25] <nigelb> I should try helping out in Debian then.
[07:25] <micahg> nigelb: you might want to convert to RFP to an ITP and take ownership (I think)
[07:25] <persia> It's an RFP: just convert to an ITP, and have at it :)
[07:26] <nigelb> ok, as of now I don't remember how.  Let me look at the new maintainer's guide :)
[07:26] <persia> If you have questions about getting stuff into Debian (process), #debian-mentors@OFTC is also a good resource
[07:26] <nigelb> oh, that's one channel I used to hang out in.  Now I remember.
[07:35]  * micahg adds Debian mentors to IRC favorites
[07:35] <nigelb> whenever I work with debian bug tracker I have to express my profound love for launchpad :)
[07:36] <tumbleweed> fabrice_sp: hmm, I didn't know about that function, looks useful
[07:40]  * nigelb decided to be evil.  Uses @ubuntu.com address :)
[07:41] <micahg> nigelb: I think that's accepted by most now
[07:41] <nigelb> micahg: I hope so.
[07:41] <nigelb> I'm very glad about #debian-ubuntu :)
[07:42] <micahg> nigelb: I'll use my ubuntu dot com addy until I have a debian dot org one :)
[07:42] <nigelb> micahg: which I presume you'll get shortly? ;)
[07:42] <micahg> nigelb: nah, it'll be a while
[07:42] <nigelb> micahg: heh
[07:42] <nigelb> ok, control@ is supposed to send me a reply?
[07:43] <micahg> nigelb: yes
[07:43] <nigelb> I'm yet to get one :(
[07:44] <nigelb> I hope I didn't screw it up
[07:45] <persia> Sometimes takes a while, depending on system load, batch timing, queue size, etc.
[07:45] <persia> Tends to take longer on weekends, for some reason :)
[07:45] <nigelb> Phew, that's a relief.
[07:46] <nigelb> yay!
[07:46] <nigelb> debian bug 503135
[07:46] <ubottu> Debian bug 503135 in wnpp "ITP: openkomodo -- IDE based on the Komodo IDE" [Wishlist,Open] http://bugs.debian.org/503135
[08:03] <fabrice_sp> tumbleweed, very usefull, yes :-) So it looks good? The package builds fine in sid and maverick, so I think I'll upload it
[08:03] <persia> Um, does it also *work*  Just building isn't enough.
[08:03]  * persia uploaded something a few hours ago where the person uploading it had obviously not even installed it locally to check if it was correct
[08:05] <persia> (although, admittedly, it depends on the goal: if a package both fails to run and fails to build, and you can make it build, but not run, it's worth uploading that anyway, but it's not worth doing so if the package previously ran)
[08:08] <tumbleweed> fabrice_sp: yeah, I think it looks good
[08:08] <tumbleweed> persia: the issue was only in testing
[08:08] <tumbleweed> persia: unit tests I mean
[08:08] <persia> Sure, but let's look at a recent example of things.
[08:09]  * persia digs up the relevant bug
[08:09] <fabrice_sp> persia, I just desactivated unit test  in previous upload, and now, I found a way to run them again. The package without unit test was working fine
[08:09] <fabrice_sp> and the content is identical
[08:10] <persia> bug #625798 was discovered about two cycles late, because prior uploaders had decided to just change the tests.
[08:10] <ubottu> Launchpad bug 625798 in Tickcount "Don't use int constants with a long data type." [Undecided,New] https://launchpad.net/bugs/625798
[08:10] <persia> If the tests are failing, it's typically not the tests you want to change, unless you are *really* sure that you're still testing the behaviour you want to be testing.
[08:11] <fabrice_sp> interesting
[08:11] <fabrice_sp> in my case, the test was failling ot find the python script to run because of wrong path used
[08:12] <fabrice_sp> so it's easier :-) (I will fix the path in this second upload)
[08:13] <fabrice_sp> for some background: Debin Bug 592714
[08:13] <ubottu> Launchpad bug 592714 in flashplugin-nonfree (Ubuntu) "package flashplugin-nonfree 10.0.1.218 really9.0.262.0ubuntu1 failed to install/upgrade: Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. (dup-of: 429841)" [Undecided,New] https://launchpad.net/bugs/592714
[08:13] <ubottu> Launchpad bug 429841 in flashplugin-nonfree (Ubuntu Karmic) "broken packaging: package flashplugin-nonfree failed to install/upgrade: (breaks upgrade)" [High,Triaged] https://launchpad.net/bugs/429841
[08:13] <persia> In that case, it sounds like someone changed the expected behaviour, and didn't update the test, so patching the test would be correct, which means "it works" as well as building, meaning the answer to my original question is "of course"
[08:13] <fabrice_sp> Debian bug 592714
[08:13] <ubottu> Debian bug 592714 in creoleparser "creoleparser: FTBFS without Python 2.5: lib directory in python and in debian/rules does not match" [Important,Open] http://bugs.debian.org/592714
[08:14] <persia> And sorry for jumping on this: I'm just a bit sensitive because of the issue I hit earlier today, so took advantage of you to make a point, in part.
[08:14] <tumbleweed> persia: in this case the bug was that debian has python 2.5 and 2.6
[08:14] <micahg> wow, this is the smallest list of FTBFS that I've ever seen
[08:14] <persia> porters need more help.
[08:14] <tumbleweed> the tests were wrong in debian, but worked
[08:15] <persia> There's something sadly wrong with libvirt/powerpc (and upstream doesn't even try to make powerpc work anymore), and huge chunks of interpreters aren't ported to arm, and ...
[08:16] <persia> tumbleweed, Finding tests wrong but working is a great way to find real bugs and fix them (as demonstrated by the solution to the bug I mentioned)
=== hanska is now known as dapal
=== yofel_ is now known as yofel
=== freeflyi1g is now known as freeflying
[12:54] <c_korn> hm, karmic is released on 10.10.10 (bin) = 42 (dec) :)
[12:54] <c_korn> eh, maverick I mean of course
[12:55] <persia> c_korn, that was, of course, the entire reason the 29th wasn't selected.
[12:55] <c_korn> I was sure it couldn't be by accident :)
[12:56] <directhex> it should be delayed to the 30th, in celebration of the rally to restore sanity in washington dc
[12:56] <persia> It's unlikely to change again, regardless of the benefits of other dates.
[12:58] <directhex> i ought to look at the appindicator-sharp bug
[12:59] <Laney> libindicate could do with using automagic to figure out the sonames while you're at it...
[12:59] <directhex> setting up a maverick pbuilder first
[14:06] <nigelb> Rhonda: around?
=== rgreening_ is now known as ghost
=== ghost is now known as rgreening
[15:46] <ari-tczew> who use MSN?
[15:46]  * Bachstelze does
[16:16] <ari-tczew> tumbleweed: ping
[16:18] <tumbleweed> ari-tczew: hi
[16:18] <ari-tczew> tumbleweed: do you know any script to move patch to dpatch file?
[16:21] <ScottK> ari-tczew: Are you thinking of dpatch-edit-patch perhaps?
[16:32] <ari-tczew> ScottK: hmmm, not sure. I wrote this: http://paste.ubuntu.com/496526/
[16:34] <ScottK> ari-tczew: That's slightly different than dpatch-edit-patch.  With dpatch-edit-patch you would run it, be in a new subshell, apply your patch (or edit files as needed), and then exit and it would take all the changes and make a dpatch out of it.
[16:38] <ari-tczew> ScottK: aha, but what do you think about my script? It converts done patch file to dpatch.
[16:39] <ScottK> I think it might be useful.
[16:40] <ari-tczew> ScottK: it needs some tweaks and then I would get it into ubuntu-dev-tools.
[16:41] <ScottK> OK.
[16:42] <Laney> ari-tczew: edit-patch already does this
[16:44] <ari-tczew> BlackZ: in last merge aMSN you forgot about add patch to file debian/patches/00list
[16:44] <BlackZ> ari-tczew: which patch?
[16:45] <ari-tczew> BlackZ: 08_use_aplay_for_sound
[16:46] <BlackZ> ari-tczew: I can see "08_use_aplay_for_sound" there
[16:46] <ari-tczew> BlackZ: ah, right, above 06 patch. sorry
[17:12] <ari-tczew> when we can upload a package in natty? after toolchain?
[17:18] <geser> usually 1-2 weeks after release the archive for the next release opens
[17:20] <bdrung_> cjwatson: should lp-list-bugs be installed? then you have to add it to setup.py.
[17:22] <geser> it would be nice to see a u-d-t upload before maverick release, at least with the change of the defaults for natty if the other changes are too big to get included into maverick
[17:22]  * geser probably won't have time for it
[17:50] <bdrung_> geser: i already talked to DktrKranz. he will hopefully upload it to experimental (after i finished my changes)
[17:51] <geser> bdrung_: and then sync back to Ubuntu?
[17:51] <bdrung_> geser: yes
[17:53] <geser> hmm, it looks a bit strange to upload an Ubuntu-specific package to Debian first to get it into the Ubuntu archive
[17:54] <bdrung_> geser: there are tools that are useful for Debian, too. e.g. suspicious-source, wrap-and-sort, ...
[17:57] <geser> bdrung_: I'm not saying that u-d-t shouldn't be in Debian. But the order of the uploads looks strange: instead of uploading u-d-t to Ubuntu first and then "sync" it to Debian, we are doing it the other way round. That's all.
[17:59] <bdrung_> geser: there is no way for Ubuntu -> Debian regarding version number.
[18:07] <Laney> there are many ways
=== yofel_ is now known as yofel
[18:27] <bdrung_> Laney: which?
[18:28] <bilalakhtar> Hello there bdrung_ ! Thanks for that endorsement!
[18:28] <Laney> The same as the other way, but in reverse
[18:28] <bdrung_> hi bilalakhtar.
[18:28] <Laney> and s/ubuntu/debian/
=== _faizul is now known as faizul
[19:11] <bdrung_> DktrKranz: around?
[19:26] <tumbleweed> bdrung_: you back from vacation now? btw, I tweaked update-maintainer to use the ubuntu-deve-discuss maintainer for non-debian-derived packages (instead of $user), but that maintainer doesn't seem to be claimed on launchpad: https://edge.launchpad.net/~ubuntu-devel-discuss-lists
[19:28] <Rhonda> nigelb: Yes?
=== hanska is now known as dapal
[19:44] <bdrung_> tumbleweed: yes. i am back from vacation.
[19:49] <bdrung_> tumbleweed: pushed u-d-t
[19:54] <bdrung_> tumbleweed: why does update-maintainer uses $user? shouldn't it work based on the changelog?
[19:59] <tumbleweed> bdrung_: actually, $DEBEMAIL + DEBFULLNAME
[20:00] <tumbleweed> I don't actually know what the usecase for either changelog or DEB* is
[20:02] <bdrung_> tumbleweed: then we are two :)
[20:02] <tumbleweed> yay spaces :)
[20:20] <bdrung_> tumbleweed: pushed again. the conversion introduces some bugs.
[20:22] <tumbleweed> bdrung_: \ shouldn't be necessary inside brackets
[20:23] <bdrung_> tumbleweed: feel free to remove the unnecessary backslashes
[20:31] <ScottK> bdrung_: I think the last audacious sync is yours and it FTBFS.  Any chance you could have a look at fixing it up?
[20:31] <bdrung_> ScottK: audacious?
[20:31] <bdrung_> FTBFS?
[20:31] <bdrung_> ScottK: link please
[20:32] <ScottK> bdrung_: Sorry.  Audacity.  https://launchpad.net/ubuntu/+source/audacity/1.3.12-5
[20:32] <bdrung_> ScottK: ok. -> bug #629955
[20:32] <ubottu> Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Confirmed] https://launchpad.net/bugs/629955
[20:33] <bdrung_> ScottK: i have no clue. upstream is informed.
[20:33] <bdrung_> ScottK: the same version builds on on lucid.
[20:33] <ScottK> bdrung_: In the mean time could you just force it to build with gcc4.4 so it will be buildable?
[20:34] <bdrung_> ScottK: how do i do that?
[20:34] <bdrung_> ScottK: B-D on gcc4.4?
[20:34] <ScottK> Yes and then adjust configure.
[20:35] <bdrung_> ScottK: how?
[20:35] <ScottK> I'm looking for an example.
[20:36] <lucidfox> Hmmm
[20:37] <lucidfox> Is it possible to install a package from experimental in a Debian pbuilder-dist?
[20:37] <ScottK> bdrung_: Add CC=gcc-4.4 CXX=g++-4.4 to configure (depending on if it's C or C++)
[20:38] <bdrung_> C
[20:38] <bdrung_> ups, no. C++
[20:38] <ScottK> Then CC=gcc-4.4
[20:39] <bdrung_> k
[21:03] <bdrung_> ScottK: it fails with gcc-4.4: http://pastebin.com/iWRPithc
[21:03] <ari-tczew> could any mastermind take a look @ bug 642374 ?
[21:03] <ubottu> Launchpad bug 642374 in ntfs-config (Ubuntu) "Please remove this package from the archive" [Undecided,New] https://launchpad.net/bugs/642374
[21:06] <ScottK> bdrung_: I don't see what the error was that caused configure to fail.
=== neeraj_ is now known as _neeraj_
[21:07] <ScottK> Sure.
[21:07] <ScottK> ari-tczew: I'll have a lookt.
[21:10] <bdrung_> ScottK: AC_EGREP_HEADERS fails
[21:11] <ScottK> OK.  That I don't know how to fix, but it sounds like it may need some additional build-deps.
[21:12] <bdrung_> ScottK: feel free to develop a fix or workaround (and let me know)
[21:13] <ScottK> bdrung_: I think it's very unfortunate for ubuntu developers to not feel any responsibility for failed packages uploads they do.
[21:13] <ScottK> I didn't upload the broken package, you did.
[21:16] <bdrung_> ScottK: i feel responsible for this package. every day i get two message that the daily build fails on maverick. the problem is that it's not audacity's direct fault that it fails. it could be gcc or autotools.
[21:17] <ScottK> OK.  I gave you a suggestion on how to work around it and it sounds to me like you think it's now my job to fix it.  I have to go.
[21:18] <bdrung_> ScottK: the FTBFS wasn't caused by my change (from -4 to -5)
[21:18] <tumbleweed> oh, this is the missing #include issue. Our gcc-4.4 has that patch too (as well as 4.5)
[21:18] <ScottK> That's not particularly relevant.
[21:18] <ScottK> Bye.
[21:20] <bdrung_> ScottK: that's is a misunderstanding. it's not your job to fix it, but I thought that you might have the time and skills to fix it.
[21:21] <ScottK> bdrung_: OK.  Fair enough.  No.  Sorry, I don't have time and it would not be trivial for me to figure out.  "Use gcc4.4" is about as much help as I'm likely to be.
[21:32] <ari-tczew> can I call package *0ubuntu1 packaged from scratch?
[21:32] <ari-tczew> or there are other names for *0ubuntu1 packages?
[21:34] <tumbleweed> ari-tczew: that'd be correct (-0ubuntu1)
[22:25] <ari-tczew> could anyone take a look @ bug 637443 ? I think it's good sync request.
[22:25] <ubottu> Launchpad bug 637443 in ndiswrapper (Ubuntu) "Sync ndiswrapper 1.56-3 (main) from Debian incoming/unstable (main)" [Undecided,New] https://launchpad.net/bugs/637443
[22:26] <Laney> yes
[22:26] <Laney> that sync request comes from the Debian maintainer, so it should be good
[22:26] <micahg> needs a core dev ack
[22:26] <Laney> doesn't mean you shouldn't test it as usual though
[22:27] <Laney> oh
[22:27] <Laney> → -devel then
[22:30] <ari-tczew> I can't test it, because I don't use ndiswrapper.
[22:31] <Laney> it's immaterial, as we can't sponsor it anyway
[22:46] <ari-tczew> lifeless: ping
[22:46] <lifeless> hi?
[22:47] <ari-tczew> lifeless: could you take a look on bug 339169 ? You did a patch for karmic. If the bug still present, could you prepare a patch for maverick?
[22:47] <ubottu> Launchpad bug 339169 in Evolution "evolution crashed with SIGSEGV in strtoul() due to NULL flags column in folders.db" [Critical,In progress] https://launchpad.net/bugs/339169
[22:48] <lifeless> mavericks frozen isn't it ?
[22:48] <lifeless> ari-tczew: the patch is upstream too
[22:49] <ari-tczew> lifeless: for bugfixes always open
[22:49] <Laney> not so for main
[22:49] <ari-tczew> Laney: even with testing?
[22:50] <Laney> check the freeze announcement
[22:50] <Laney> I'd imagine a crasher would be fine, but that's not my call
[22:51] <micahg> well high priority and above are usually accepted after freeze from what I've been told
[22:51] <Laney> Regardless of what usually happens, the point is that they still need release team approval.
[22:51] <micahg> of course :)
[22:52] <lifeless> anyhow, no, I won't look at it - sorry. a) flat out still with LP; b) its easy to apply, take you 10 minutes if you're interested, and c) theres a lot of process at this point regardless, and I simply not have the tuits to drive this through it.
[22:53] <ari-tczew> lifeless: I can _try_ adjust the patch, but I need a testcase.
[22:54] <lifeless> power the machine off between index and summary retrieval for a single message.
[22:54]  * ari-tczew is killed
[22:54] <lifeless> [asking for an acceptance test case for a bug like this is crazy]. unit test sure - but upstream isn't really unit-test setup, and this is a result of their rather nuts db-message store implementation.
[23:12] <cjwatson> bdrung_: whoops, thanks
[23:15] <cjwatson> bdrung_: done
[23:22] <bdrung_> cjwatson: jw