[00:02] (yes I am in the process of installing it, but my connection is slow, you have plenty of time to answer this for me before its finished ;) ) [00:09] we its finished, its black [07:37] good morning [09:37] kinda going around in circles, I've fixed a bug in xine-lib, branching from lp:xine-lib, do I need to change the changelog file for such a small change or will it be somehow aggregated with other small changes by the actual "uploader" or merger [09:55] sagaci: It depends on your goal, really. [09:56] If you branched lp:xine-lib and want to push it upstream, then changelog likely doesn't matter much. [09:56] That would be added by the person integrating the change. [09:57] (note that lp:xine-lib is automatically imported from the CVS repo on sourceforge) [09:57] i'll try to describe, fixing a small bitesize typo, with the aim of it going upstream or at least into sid/oneiric [09:57] If you want to change the package in Ubuntu, you'd want to start with lp:ubuntu/xine-lib [09:58] If you want to be the uploader (even being sponsored), then you'd be expected to prepare the changelog, etc. Everything necessary for upload. [09:58] thanks, i'll try doing it that way [09:58] If you aren't concerned, then you don't have to do anything other than ask for a merge, and someone else will integrate. [09:58] If it's just a typo, then it's better to send upstream. [09:59] but how do you bzr push a change without a proper changelog entry [09:59] I'd recommend using `bzr diff` to generate a patch, and sending it to the upstream list (xine-devel at lists.sourceforge.net) [10:00] `bzr commit` then `bzr push` [10:00] Note that if you do this, you need to specify a revision for `bzr diff -r ${REVISION}` when preparing the upstream patch. [10:01] righteo, i'll try that bzr diff === dholbach_ is now known as dholbach [11:22] http://pastebin.ubuntu.com/644718/ => somebody an idea on this ? [11:22] cmake broke or ? [11:55] dupondje: which package? [11:55] Hello. I was working on packaging open teacher(LP:#682582) for Ubuntu 11.04. I was told from here to get it included in Debian and it would be synced into Ubuntu. But, Debian didn't seem interested in including open teacher in their repos(http://lists.debian.org/debian-edu/2011/03/msg00002.html) and upstream don't plan to change the name either(private email). Isn't it possible to upload the package into Ubuntu repositories witho [11:56] acoustid-fingerprinter [11:56] https://bugs.launchpad.net/ubuntu/+bug/682852 ? [11:56] Ubuntu bug 682852 in Ubuntu "[needs-packaging] OpenTeacher" [Wishlist,In progress] [11:59] dnivra: I don't see that this package was denied int hat thread? [11:59] just some discussion over the name [11:59] I think its not to generic, so first come first serve [12:00] are there other projects named openteacher? [12:00] no there's no other project with the same name AFAIK. Checked via google too. [12:01] Well they had a discussion over the name and I gathered they weren't interested unless the name's changed. I didn't pursue the issue after that :). [12:02] (The discussion sounded like it was going to be a no to me) [12:03] just post again arguing for the current name [12:03] the fact that they have a domain and lots of google hits speaks in favour [12:03] dnivra: I only see some concern from wo peopl and I do not see their point [12:03] maybe speak to some people in #debian-edu [12:04] jtaylor: I don't see their point either. I asked for a clarification on what exactly they had a problem with and they never got back to me on the issue. heading to #debian-edu now. [12:04] Laney: sure. will do :). [12:09] jtaylor: acoustid-fingerprinter [12:11] I'll have a look soon [12:12] ok :D [12:20] dupondje: workaround here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632870 [12:20] Debian bug 632870 in acoustid-fingerprinter "acoustid-fingerprinter: Does not build" [Normal,Open] [12:20] but that it does not find it in the first place may indeed be a cmake bug [12:21] hm no wait that workaround may be wrong [12:22] I saw that workaround, but doesn't look very clean. And Cmake should work imo [12:23] got cmake open in a pbuilder now, so if you need some trace output ^^ [12:23] maybe a missing b-d [12:27] Removed QtConcurrent from find_packages in CMakeList.txt [12:27] that fixed it [12:27] yes but it may be wrnong [12:27] yea true [12:28] but QtConcurrent should be in libqt4-dev ? :s [12:28] its in qtcreator, I wonder why [12:30] even with qtcreator installed cmake fails tho [12:35] the debian bug should probably be increased to RC [12:35] or debian should get 0.2-1 :) [12:35] fixed both bugs :p [12:36] well none in the Debian Edu channel are responding. I've emailed the list-hope they respond. I would like to know if it's still possible to upload the package to Ubuntu in case Debian doesn't respond in time for feature freeze. The developer would really like it to be included :) [12:48] jtaylor: Developper of the package is on freenode also, going to poke him :) [12:52] btw, how to name a package version between 0.2 and 0.3. Source is just the current HEAD [12:52] no 0.3 out yet [12:53] package-0.3~gitc53005affbd184f6b598 ? [12:53] no [12:53] package-0.3~YYYYMMDD and mention the commitin the changelog [12:53] and no -0ubuntu1 ? [12:54] that too [12:54] maybe you can add a shortened git hash too, but it should stay below 80 characters [12:55] acoustid-fingerprinter-0.3~20110715-0ubuntu1 [12:55] this would be fine for example ? [12:55] does it make sense to use a git snapshot? [12:56] can't you just backport the one commit that fixes the issue? [12:59] In the very last commit QtConcurrent got dropped [12:59] and alot of things fixed [12:59] but anyway i'll ask the developper first [12:59] when QtConcurrent can be dropped [13:00] But the git versions builds fine ^^ === ximion2 is now known as ximion [14:01] Some package is missing a build dep, which causes ftbfs [14:01] upload fix yet to ubuntu ? or wait for debian ? [14:11] depends, is it a package that needs exposure to testing now? was it just a rebuild that failed and the same version is already downloadable? [14:11] in general I'd wait for debian a few weeks first if its not urgent [14:12] https://launchpad.net/ubuntu/+source/bochs/2.4.6-2 [14:13] dupondje, So, if you find something like that, it's best to test-build in a Debian chroot. [14:13] I did, failed there also :) [14:13] If the test build works, and you can replicate the failure in Ubuntu (with the same source package), check the dependencies. [14:13] If the test build fails in Debian, fix it, and send the fix to the Debian BTS. [14:14] Before DIF, it's often worth just waiting, but after DIF, unless you have a relationship with the Debian maintainer, it's often easier to just upload in Ubuntu. [14:14] Mind you, if Debian adopts it, merging to get back in sync later is handy. [14:14] I bugreported on debian already [14:14] (and if you are a little slow about fixing it in Ubuntu because you're hoping the maintainer applies it, that's understandable as well). [14:15] Ah, cool. [14:15] its just adding 'jade' as build depend [14:15] so that should be easy for them :D [14:15] I just saw advice to "wait for debian a few weeks", and without the context, that sounded a bit uncooperative. [14:15] Is jade needed for all architectures, or just the "all" architecture? [14:17] I guess the 'all' one [14:17] as building docs fail because of it [14:17] So, on the buildds, it works on armel, amd64, powerpc, but fails for i386? [14:17] y [14:18] Then you want to upload to Ubuntu. [14:18] That's a bug in Debian, but not one that lots of maintainers care much about. [14:18] Many maintainers build the "all" packages on their local system, and don't remember to add stuff to Build-Depends-Indep. [14:19] Also, double-check the patch to the BTS: that belongs in the Build-Depends-Indep: header, rather than the Build-Depends: header (as it's only required for architecture independent building). === kentb-out is now known as kentb [14:23] btw, pbuilder does the build indep also ? [14:23] no matter the arch [14:24] I think there's a switch to turn that on or off. [14:25] But not being a pbuilder user, I'm really not sure. [14:26] https://bugs.launchpad.net/ubuntu/+source/bochs/+bug/766024 => patch added [14:26] :) [14:26] Ubuntu bug 766024 in bochs (Ubuntu Oneiric) "bochs version 2.4.5-1 failed to build on i386" [High,Confirmed] [14:34] dupondje: without an option pbuilder acts like a "i386" buildd (builds both the arch dep and arch indep packages) but there is an option (--binary-arch) to just build the arch dep packages [14:37] geser: thx ! === ximion1 is now known as ximion [14:59] Hi guys ! [15:00] I am trying to package a small game written in C++ with Code::Blocks [15:00] Is there any way to make the packaging tool work with the codeblock projects ? [15:00] maybe by adding something to the rules files === shadeslayer_ is now known as shadeslayer === ximion is now known as ximion1 === jpds_ is now known as jpds [15:46] Last day of UDW (https://wiki.ubuntu.com/UbuntuDeveloperWeek) starting in 15 minutes in #ubuntu-classroom [15:54] Ah! Thanks for the reminder. Almost forgot about DMB! [15:54] Hope network is really fine in Banja Luka on monday :) [15:57] oh yeah, that reminds me [15:58] No, *that* reminds me: [15:58] REM Jul 18 2011 AT 21:00 DURATION 1:00 +5 MSG PPU Application #ubuntu-meeting %c [15:59] just incase I don't make it :-) [16:02] * Rhonda likes wyrd :) [16:34] yey libgmpada updatew fixed the wishlist --as-needed bug but ignored the two ftbs RC bugs ._. [16:41] who says binary uploads require the uploader to ensure it builds :) === marnux_ is now known as Marnux === jtaylor_ is now known as jtaylor [18:54] tumbleweed: around? [18:54] bdrung: yeah [18:54] tumbleweed: we need to fix backportpackage. the bug is going on my nerve [18:54] heh [18:55] bug #801945 [18:55] Launchpad bug 801945 in ubuntu-dev-tools (Ubuntu) "[backportpackage] Fails to backport local .dsc file" [Medium,New] https://launchpad.net/bugs/801945 [18:55] that's a regression [18:55] we need test cases for that [18:55] tumbleweed: is bug #810974 a bug in debootstrap? [18:55] Launchpad bug 810974 in ubuntu-dev-tools (Ubuntu) "pbuilder-dist fails for sid" [Undecided,New] https://launchpad.net/bugs/810974 [18:56] the local .dsc thing sounds like something I can do easily [18:56] I was going to ask for more info on the debootstrap one [18:56] tumbleweed: including a testcase? [18:56] it could also be that sid is just broken [18:59] the test case is tricker, because then we have to be sure not to hit launchpadlib on those code paths [19:03] tumbleweed: a online test would be sufficient [19:04] or just stub them out [19:04] * tumbleweed has a look [19:04] tumbleweed: stub them out? [19:04] use mox to intercept them [19:04] aha [19:18] bdrung: I just successfully pbuilder-dist created sid on oneiric [19:19] tumbleweed: and on natty? [19:20] that requires a vm, coming up... [19:21] oh, actually it wasn't successful, ran into dupondje's /proc issue [19:22] tumbleweed: the issue is in util-linux (the binary package is 'mount'), downgrading just mount to the previous version fixes the proc issue. [19:23] tumbleweed: (for some reason umount ignores $PWD and tries to umount /proc, instead of the $CHROOT/proc) [19:24] ah [19:25] I should probably add my findings to the bug report. [19:25] that'd be helpful, esp as I recall util-linux uploads recently, due to /run [19:27] oh, https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/805886/comments/3, colin already added basically the same. [19:27] Ubuntu bug 805886 in debootstrap (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New] [19:32] Ampelbein: it's still assigned to debootstrap [19:33] (the debian bug too) [19:34] tumbleweed: changed the ubuntu package to util-linux with a comment. [19:35] thanks === yofel_ is now known as yofel [22:59] hey ajmitch === medberry is now known as med_out