=== blueyed_ is now known as blueyed [01:20] hmm, linux-tools from lenny-backports is built against binutils from lenny (non-backports)? [01:20] *scratches head* [01:21] it's anomalies like this which make me hesitant about the whole cherrypick-from-backports idea [01:23] not that there's a "correct" answer to whether or not linux-tools should build with the toolchain from backports, though.... === hannesw_ is now known as hannesw === hanska is now known as dapal === yofel_ is now known as yofel [12:41] What is needed to block wesnoth-1.9 from natty? [12:49] Rhonda: one of these guys: http://1.bp.blogspot.com/_owN7osPiFRo/S_PSmG6HyxI/AAAAAAAAAMw/9wsxd6Da5h4/s1600/IMG_0109.jpg [12:51] bdrung: Congrats and welcome to the DMB! [12:57] thanks bilalakhtar [13:18] Rhonda: It's already in Natty. If you want it removed, file a bug asking for removal and sync blacklist and subscribe ubuntu-archive. === emma_ is now known as emma [16:58] http://launchpadlibrarian.net/58738628/buildlog_ubuntu-maverick-i386.nodejs_0.2.4~maverick1~ppa201011061723_FAILEDTOBUILD.txt.gz <- somebody cares to look at this ? the build was working fine on 10.04, and now it is failing on a litian stuff in dh_buildeb [17:02] jetienne: for some reason files are installed in /usr/local and not in /usr [17:03] kklimonda_: yep but how come it worked without trouble in lucid and is failing now in maverick ? [17:04] jetienne, I hate to be nit-picky -- but what's this line -- echo this is failling but i dunno why, so i disable \n this is failling but i dunno why, so i disable [17:05] paultag: this is where i admit that i just pacakging to help friends. im not a pro [17:05] jetienne: there is nothing obvious in the log so you'll have to build it locally and investigate [17:06] kklimonda_: this is the key problem :) it build as src and as bin .deb on my vm [17:06] jetienne, what's your rules file look like? -- looks like you override | override_dh_usrlocal [17:06] override_dh_usrlocal: [17:06] echo this is failling but i dunno why, so i disable [17:07] paultag: this is the line currently existing in the Rules [17:07] http://pastebin.com/X7mgpC1a <- the whole Rules [17:09] jetienne, do you have a log that ended successfully from Lucid you could post? [17:09] paultag: let me look [17:10] https://launchpad.net/~jerome-etienne/+archive/neoip/+packages <- the nodejs package for lucid is still there i cant find the build log [17:10] maybe you can [17:11] OK [17:11] http://launchpadlibrarian.net/58168485/buildlog_ubuntu-lucid-i386.nodejs_0.2.4~lucid1~ppa201010250818_BUILDING.txt.gz <-- that's one [17:11] ok [17:12] dpkg-deb --build debian/nodejs .. <- this is going ok on lucid [17:12] you should use pbuilder with dpkg-buildpackage -S jetienne [17:13] paultag: ? i dont understand, can you give more details ? [17:14] jetienne, just in general -- you should use dpkg-buildpackage -S to create the dsc file, and then use pbuilder to build in a chroot. Say... I wonder. [17:14] jetienne, it could be that you have a dependency issue, are you ensuring all the build-depends are being installed? [17:14] jetienne: lucid build is also wrong [17:14] no package should install files in /usr/local/ [17:15] +1 kklimonda_, but that does not explain the FTBFS [17:15] the reason the build doesn't fail on lucid is most likely because maverick "buildchain" has been made more strict [17:15] paultag: i dunno but the binary is built without issue [17:15] Oh yes, I see kklimonda_ [17:15] INFO: Disabling pkgbinarymangler for PPA build [17:15] for Lucid [17:15] kklimonda_: how come it build on maverick locally then ? [17:16] what is this pkgbinarymangler ? [17:17] jetienne, https://launchpad.net/ubuntu/+source/pkgbinarymangler [17:17] pkgbinarymangler consists of a dpkg-deb wrapper that calls helper applications while building a debian binary package <- ok [17:18] jetienne, fix up the install issues and you should be OK. Try testing in pbuilder [17:18] which install issues ? [17:18] jetienne, installing to /usr/local/ [17:18] override* is no more honnored ? [17:19] jetienne: pkgbinarymangler works on a different level [17:19] kklimonda_: i dont understand [17:20] jetienne: override_dh_usrlocal doesn't stop pkgbinarymangler from doing its magic [17:21] kklimonda_: can i prevent it from doing that ? or to have it honnor the usual rules override ? [17:21] jetienne: you should fix the build system to install files in /usr and not in /usr/local [17:21] but, to answer your question, I have no idea [17:21] kklimonda_: unfortunatly i cant [17:21] ok thanks anyways [17:21] why? [17:21] because if i do other stuff break [17:22] there is something wrong with either your build rules or with upstream build script - either should be fixed. [17:22] how can i make my local build to use pkgbinarymangler ? [17:22] kklimonda_: well just trying to help friends, not to fix the whole world :) [17:23] jetienne: well, nodejs has ben packaged for maverick and natty so you can just reuse their rules [17:24] kklimonda_: ok i got your point. unfortunatly i cant [17:25] currently all i want is to be able the pacakge locally the same way ppa is doing it [17:25] thus i could try to fix this problem without waiting 30min at each iteration :) [17:26] jetienne: then make sure you have pkgbinarymangler installed and it should be used [17:26] ah ok pkgbinarymangler provides another dpkg-deb binary [17:26] (because you already use dpkg-deb) [17:27] kklimonda_: thanks trying [17:28] dh_builddeb: dpkg-deb --build debian/nodejs .. returned exit code 1 <- excelent :) [17:58] Hi, is it true that only packages for natty are currently accepted (as REVU says) ? [18:02] yes [18:02] And where can I download a beta version of natty to test my app on it? [18:02] there is a separate process for backports to maverick [18:02] and also another one for 'extras' for averick. [18:04] you can upgrade from maverivk to natty [18:04] no cds yet [18:09] I don't get you. Can you explain me a bit better, because on REVU I've seen a lot of recent packages being rejected because of 'Package is for "lucid" but only packages for "natty" are currently accepted.' and i don't want to have the same problem with my own app. [18:11] So where should I try my app to ? [18:17] hakermania: well, that depends on what you are aiming for. If you'd like to get your (open) application into Ubuntu you should use REVUand aim for natty, and after that request backport to every stable release you care about. This process in, unfortunately, pretty long one. [18:18] you could also try to get your application into current stable release and skip development one by using the new process which involves application review board. But it's a new process and I'm not sure if they are actually accepting applications at this time. [18:19] They are accepting applications, but nothing has been approved yet. [18:19] So, let's say I 've tested my app in maverick and works just fine, is there any other thing I have to do to avoid the pre-mentioned error about natty or I should upload my package to REVU instantly? [18:20] ScottK: Thanks, will do so. [18:21] hakermania: you should test if your application builds on natty (there are few ways of doing that without actually running natty on your computer) and then, in the changelog target natty release instead of maverick. [18:21] ScottK: ah, right. [18:21] You're welcome. [18:21] ScottK: is there an actual list of applications that are being proceeded at this time by the ARB? [18:22] kklimonda_: I've no idea. I only know what I do because it was mentioned at UDS. [18:23] kklimonda_: I searched for downloading a beta version on natty to test in on a virtual machine or something but I found nothing. Can you send me a link or something? [18:24] hakermania: there are no natty images currently available, you have to install 10.10 and use apt-get dist-upgrade to upgrade. [18:25] hakermania: but you can create a simple scroot (by using pbuilder or similar tool) just to check whether your package builds fine. [18:26] Omg, i think my prog will work fine in natty, I'll simply change the changelog to natty --_--' I hope one day packaging process and policy will become easier and simpler! [18:27] ScottK: hmm, wenn I click subscribe and enter ubuntu-archive, it gives me two. The one I expected, but also "Ubuntu Archive Auto-Sync". Should I (also) subscribe the later because of the sync blacklist? It somehow sounds fitting and made me uncertain. [18:27] s/scroot/chroot/ [18:27] Rhonda: You want exactly ubuntu-archive [18:27] That's the actual team of people that maintain the blacklist. [18:28] Right, that's the one I always used before anyway. But the other got me confused, that's why I ask. [18:36] Hi guys [18:36] bug 671222 - is python-gconf due to be rebuilt against python2.7 soon? [18:36] Launchpad bug 671222 in update-manager (Ubuntu) "update-manager fails to start" [High,Confirmed] https://launchpad.net/bugs/671222 [18:37] xteejx: Hi [18:38] hakermania: Hi :) [18:38] xteejx: Commented in the bug. [18:39] ScottK: Thank you :) [18:41] paultag: kklimonda_: succeed !! thanks for your help [18:41] kklimonda_Is there something else I have to do except from changing the changelog to natty? [18:41] ScottK: Could it be that update-manger is trying to use python2.7 and that control needs 2.6 explicitly set? [18:42] xteejx: Something like that. I'm sure mvo will sort it out. He's pretty good about these things. [18:42] ScottK: Oh ok coolio :) [18:42] Its extremely unlikely that this will be one of those less-obvious bugs :) [18:43] kklimonda_: Is there something else I have to do except from changing the changelog to natty? [18:43] hakermania: no [18:46] This is mad :P Are whole projects rejected and asked to be re-uploaded because the changelog says maverick and not natty ? :P ? [18:47] They should be natty, we're in the natty dev cycle [18:51] Stupid question time....: [18:51] Why on the mom page are the packages coloured differently? [18:57] ??? [20:18] http://dehs.alioth.debian.org/no_updated.html show a lot of updated upstream pkgs, is there anything we can do with that? [20:19] i.e. should we help debian if we can to update them, since it benefits us if we sync from it [20:20] xteejx: debian is in freeze so they don't really care that much about new versions [20:20] (at least until freeze is over) [20:20] kklimonda_: Does that mean we can update from upstream directly to Ubuntu? [20:20] or should we wait? [20:21] I haven't been in a cycle properly before, only bug triaging so not familiar with the way things work, i.e. debian freezes, our DIF, etc [20:24] Anyone at all?? [20:25] depends if the package has a maintainer or QA maintained in Debian [20:25] geser: don't they all have maintainers? [20:25] orphaned ones don't have one (if you don't count the QA team as maintainer) [20:26] I see, so they are just left as they are for whatever reason someone leaves it [20:27] the Debian QA team is similar to MOTU [20:27] both touch packages only when needed [20:27] i.e. updated? [20:28] if someone has an interest to update the package [20:29] geser: Only reason I ask is that Debians freeze could last a while while they iron our RC bugs, what happens to our 11.04? :S [20:29] *iron out [20:29] for universe it will be mostly the same like maverick then [20:30] This why I wish I knew what everyone here does, my packages would be updated within a week of the debian/watch telling me there was a new upstream version :( [20:30] if you are interested in updating one package go for it (and talk to the Debian maintainer first) [20:31] Well I'll be honest I think my efforts would be better concentrated there, looks like they damn well need it lol [20:31] updating package is not usual as there are enough other tasks too (FTBFS, NBS, UNMETDEPS) [20:32] Hmm I suppose [20:33] and there are also those packages which aren't in Debian (yet) which could use an update too [20:33] xteejx: This week I've been knocking two to four a day off of http://qa.ubuntuwire.com/ftbfs/ - That's work that needs doing. [20:34] ScottK: Same here, well nowehre near as many I'm too stupid (lol) but I've helped peck at the FTBFS bugs [20:34] xteejx: So that's good work to be doing. [20:34] xteejx: I've been doing this for years, so some stuff I can solve pretty quickly. It will come in time. [20:35] ScottK: Well I do learn quick when things are explained relatively simply, geser does that quite well [20:35] Who needs a mentor ;) [20:36] It was just the 2700+ number that really shocked me [20:36] I think it's much better for people to be active in this channel and ask questions as you've been doing than to wait for a dedicated mentor. [20:37] I completely agree, you don't ever learn anything if you don't ask quetions [20:37] s/quetions/questions [20:38] As a sidenote, it was http://packages.qa.debian.org/a/alexandria.html I was looking at in particular [20:38] No pkg update for 4.5+ years :O [20:38] xteejx: I'm intersted in sponsoring your patches. [20:39] ari-tczew: What patches? [20:39] xteejx: e.g. ftbfs [20:39] Ohh, I haven't done any for 2-3 days so I don't have anything at the minute :) === Zhenech_ is now known as Zhenech === Zhenech_ is now known as Zhenech [22:20] BlackZ: Ping on bug 671941. It's in universe. You can upload it. [22:20] Launchpad bug 671941 in ctdb (Ubuntu) "Please merge ctdb 1.0.112-12-1 (main) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/671941 [22:23] ari-tczew: thanks, I realized it was in main [22:23] :) [22:57] Ubuntu Developers does not use Launchpad [22:57] ;o [22:58] https://launchpad.net/~ubuntu-devel-discuss-lists [22:58] * ari-tczew thought that we really work on Launchpad! (ironic) [23:43] ari-tczew: ubuntu-devel-discuss is on lists.ubuntu.com, not launchpad.net. [23:43] ScottK: so, do you think that this is not an issue? [23:44] I think it is not an issue. [23:45] ScottK: I disagree with you. I think that ubuntu-devel-discuss-lists ~ubuntu-dev [23:45] ^^ should be merged into ~ubuntu-dev [23:45] (LP accounts) [23:45] I think it's meaningless. Feel free to work on it if you think it's important. [23:45] then LP shows that packages touched in Ubuntu are maintained by non-existing account [23:46] it not looks good.