[01:49] hey guys, I have a little issue with locales. upstream has moved locales to a new folder and now running the package sets it to the base langauge always. however if I do LANG=EN fr example I get the app in the correct language [01:55] http://pastebin.ubuntu.com/452710/ [03:52] hi. where can I find the documentation of what variables I can expect to be set for debian/rules when dpkg-buildpackage is called? [04:00] ramiro: You can't really expect any environment variables to be set; debian/rules is not guaranteed to be called by dpkg-buildpackage (although it will be almost all the time). [04:06] RAOF: ok, that's what I thought. I found some documentation at http://man.cx/dpkg-buildpackage%281%29 that lists a few env vars. [04:06] and is there a non-hackish way (through the dpkg- tools) to determine what host system I'm building with and for (hackish being calling uname and gcc -dumpmachine). [04:07] dpkg-architecture [04:08] It doesn't export the variables itself, but it provides all the host information you'll need. [04:09] thank you === echidnaman is now known as JontheEchidna [06:34] hi [06:37] is there a mailing lits for this channel ? [06:37] list* [06:37] kaushal: there is a mailing list for MOTU [06:37] I have a particular issue [06:38] shall i post the thread ? [06:38] kaushal: what type of issue? [06:40] https://lists.ubuntu.com/archives/ubuntu-server/2010-June/004345.html [06:40] kaushal: #ubuntu-server is probably the best place [06:41] micahg: i did that already [06:42] kaushal: this channel is for packaging related issues, not support, also you posted on the weekend, you might want to see if you get some results Monday morning [06:43] kaushal: I'd suggest trying the #ubuntu-server channel in about 9 hours [06:43] micahg: ok [06:44] kaushal: maybe 8 hours [06:46] micahg: can i findout the package maintainer [06:46] kaushal: In Ubuntu, we generally don't have maintainers [06:47] kaushal: it's in universe, so MOTU is responsible for packaging [06:47] good morning [06:50] kaushal: but aside from one upload for hardy, it's been sync'd from Debian [06:51] kaushal: BTW, there's an update in hardy-updates for your package [06:54] micahg: are you talking about ocsinventory-agent ? [06:54] kaushal: yes [06:55] can i know the details ? [06:55] kaushal: https://launchpad.net/ubuntu/+source/ocsinventory-agent/1:0.0.8-1ubuntu0.1 [06:57] micahg: how do i install it [06:58] i did apt-get update and then apt-get install ocs..... [06:58] kaushal: you have to enable hardy-updates [06:58] someone in #ubuntu can help with that [07:07] micahg: Thanks it worked now [07:07] kaushal: good luck === dholbach_ is now known as dholbach [09:27] http://www.sinfest.net/archive_page.php?comicID=3574 - wtf? [09:27] Can someone explain that one to me? :) [09:28] http://www.urbandictionary.com/define.php?term=bro [09:30] I know the slang term bro for brother, but I still don't get it. [09:31] The ubuntu reference is what I'm puzzled about. [09:45] hyperair: hey, jcastro told me you have a branch for hal-free banshee, do you think it's in a state that can be integrated to maverick? [09:45] didrocks: i haven't actually tried it yet. it's still rather experimental, or so i have heard. [09:46] hyperair: the hal support is only for ipod or for all hw? [09:46] didrocks: all hw. [09:46] didrocks: if i'm not mistaken, that hal-free banshee branch will deprecate ipod-sharp and podsleuth, in favour of libgpod [09:47] hyperair: that would rock :) do you know who I should contact about it to see if we can integrated and leverage some tests? (unfortunately, I don't have enough upstream knowledge to hack on it there) [09:47] didrocks: lemme dig through my mail [09:48] (also, I don't see the branch there: http://git.gnome.org/browse/banshee/refs/heads) [09:48] thanks hyperair :) [09:48] =) [09:48] hyperair: Really? I didn't think the hal-free banshee was particularly related to the libgpod transition? [09:48] RAOF: it wasn't? [09:48] RAOF: podsleuth isn't going to transition to hal-freedom anytime soon. [09:49] But there still aren't any C# bindings for libgpod, are there? [09:49] didrocks: lamalex was working on it, its probably on gitorious [09:49] And the udev-backed Banshee branch is available _now_ (and may even work) [09:50] RAOF: do you have an url please? I want to put the crack on maverick now :) [09:52] Laney: hum, don't find it in gitorious (should be there, I guess: http://gitorious.org/banshee/mainline) [09:52] I suggest you have a word with lamalex first [09:52] It's probably this http://gitorious.org/~lamalex/banshee/lamalex-udev or one of the clones/branches [09:53] Laney: yeah, google was just my friend :) not sure if that's what RAOF was talking about [09:54] I'll email him now [09:55] RAOF: the libgpod C# bindings are being worked on afaik [09:55] he hangs around in #banshee as well [09:55] (just not atm) [09:56] Laney: ok, I'll try to ping him when he's there, I wasn't sure he was hanging on IRC [09:56] hyperair: Laney: thanks! [09:56] no worries [09:57] he's on yank time, so try again when yanks aren't sleeping [09:58] didrocks: http://old.nabble.com/iPhone-Support-in-Banshee-tt23116289.html#a28873202 [10:02] didrocks: ping alan on #banshee as well [10:02] (he's also not around currently) [10:02] he's on ireland time, so should be about [10:03] hyperair: oh sweet, will do, thanks [10:04] http://gitorious.org/~alanmcgovern/banshee/banshee-iphone <-- this looks like a clone of lamalex's branch though [10:04] Yeah, it is. [10:04] he had it working [10:04] Sorry about that, X freeze. [10:04] he was showing demos [10:14] directhex: really? Hum, can be interesting to include it for alpha2 then [10:26] the e-mail mentioned it should be upstreamed in a week or two (from that date, that should be around now, or next week) [10:32] alan just materialized FYI [10:42] If he is, tell him to keep an eye on: http://gitorious.org/~alanmcgovern/banshee/banshee-iphone [10:42] i cloned yesterday and will start pushing my work to there this week [10:42] once everything is good to go, i'll push my changes to lamalexs branch [10:42] and once his changes are all good to go, they'll be pushed to banshee [11:42] hey all, I just addd a patch system to a package, after setting up the patch, is there something I should add to debian/rules for it to be applied during the build of the deb file? [11:56] I fund what I was looking for reading more carefully the docs === jtechidna is now known as JontheEchidna === mathiaz_ is now known as mathiaz [15:51] What's the simplest/cleanest way to get cdbs to run autoreconf -fi (yes, I know it should be done upstream ;P) === jtechidna is now known as JontheEchidna === dholbach_ is now known as dholbach [17:34] scottk: i will take a look at revu and delete anything i have left in there (and possibly move it to DPMT instead) [17:35] statik: Thanks. DPMT would be good. === Quintasan_ is now known as Quintasan [18:27] hi fabrice_sp :) [18:28] fabrice_sp: good news. mocker 1.0 was relased yesterday :P [18:31] dobey, you was waiting for me :-D [18:31] so the watch file should work, right? [18:34] fabrice_sp: hehe. i just switched channels and saw you come in. the watch file does work now. i ran uscan and it downloaded the new tarball :P [18:35] fabrice_sp: but the license changed, and lots of bugs were fixed. there's only 1 open on mocker now. so i'm making the deb for 1.0 [18:35] dobey, cool [18:35] ping me when you get the package in a good shape, and I'll ave a look [18:36] what is the new license? [18:36] and i'm going to fix it to run tests during the build too [18:36] BSD [18:36] ok [18:36] good [18:36] by the way, it's python, riht? [18:38] yes [18:41] fabrice_sp: alright, just did the dput to revu for it :) [18:44] did you try to ocntact debian-python team? [18:45] * fabrice_sp don't remember if he already tried to send you there .-) [18:48] tumbleweed: poke :) [18:50] fabrice_sp: i haven't, because as i said, just trying to have it packaged in ubuntu, so we can rely on the package rather than copying mocker.py across all the ubuntu one projects where we use it (and the landscape/launchpad guys also want it), and in order to have it packaged, and to run tests in our package builds, it would need to be in ubuntu, rather than just a PPA [18:50] Hi all [18:50] and upstream would prefer not to have it packaged at all, but i bugged him enough to reach a compromise in that regard :) [18:51] shadeslayer_: yes? [18:51] tumbleweed: ah yes,in this : http://revu.ubuntuwire.com/details.py?upid=8319 [18:51] tumbleweed: do i add a debian/watch or modify debian/rules? [18:52] we might as well move this to PM [18:52] tumbleweed: sure [18:52] hi NorthernLights [18:52] Hola [18:53] tumbleweed: It's better to keep technical discussions in the channel so bystanders can learn. [18:53] Any answer about the Original-Maintainer thingy? [18:53] NorthernLights: i didn't ask, but my comment on revu was based on what the FAQ says on the wiki about it :) [18:53] oh [18:53] ScottK: ok, sure. but they can get long and noisy :) [18:53] i guess you're right [18:53] * NorthernLights is still tickled... [18:53] tumbleweed: I think it's fine. [18:53] Hola MOTU! [18:54] in that case, shadeslayer_: both. example: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/rules?revision=12242&view=markup [18:54] Must new Ubuntu packages debian/control file have a XSBC-Original-Maintainer field? [18:54] tumbleweed: Not that I particularly worry with you, but there have been problems in the past with bad advice given in PM. If it's in public, QA can happen real time. [18:55] NorthernLights: No, it's not absolutely required, but there will be warnings as a result, so generally it's better. [18:55] ScottK: yeah, agreed. [18:55] Tx ScottK [18:55] tumbleweed: if you can walk me through those lines please :) [18:56] tumbleweed: ive understood the 3rd line of get-orig-source :P [18:57] shadeslayer_: so, it's all executed as one sh command (that's why we set -e, to exit or errors) [18:57] bah.. ive understood all of it except line 1 and 2 [18:57] VER uses dpkg-parsechangelog to find what the current version of the source package is and store it in VER [18:57] tumbleweed: is that a standard line used everywhere? [18:58] like suppose can i use it for my package? [18:58] shadeslayer_: no I don't think there are any standards to this kind of thing, but it's a nice way to do it [18:58] this example actually gets us a zip file which then gets repacked as .tar.gz - let me see if I can find a simpler examlpe [18:59] tumbleweed: ok one more thing,where does it store the URL part? the actual URL it has to download? [18:59] that comes from debian/watch [18:59] ahh.. [18:59] which also has a little magic: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/watch?revision=12242&view=markup [19:02] shadeslayer_: ok, here's a simpler one: http://svn.debian.org/viewsvn/python-modules/packages/pyfiglet/trunk/debian/rules [19:04] tumbleweed: ah ok,i understand... [19:04] i need spend a little more time reading about sed tho :P [19:04] tumbleweed: and the watch file.. [19:04] whats : opts=dversionmangle=s/\+ds// \ [19:05] so, our version has +ds at the end, but upstream doesn't [19:05] that says remove +ds from the version [19:05] ah... [19:06] the sed was also doing that, and stripping the "Version: " a the beginning [19:06] [^+]+ means "everything until you reach a +" [19:07] ^.*\+ [19:08] tumbleweed: so "Version: " is like the string or a number,like 1.0.0 ? [19:08] NorthernLights: * is greedy, so it'll catch everything util the last + [19:08] shadeslayer_: run dpkg-parsechangelog and you'll see [19:09] tumbleweed: on the dsc file? [19:09] just in your source [19:09] Ohhhh [19:10] right tumbleweed [19:10] but are you sure ^+ means anything? [19:11] NorthernLights: when a [] starts with a ^ it means anything except what's listed [19:12] oh i didn't know that, thanks [19:27] * NorthernLights is taking advantage of a pause in the discussion [19:27] *inhales... exhales... [19:28] Hey MOTUs! Wanna review a great package? Easy and quick! Nice upstream software! http://revu.ubuntuwire.com/p/synergy-plus ! Yeah! [19:29] hehe :D [19:43] ok so i have this lintian warning : W: qipmsg source: dh-clean-k-is-deprecated [19:44] but when i replace dh_clean -k with [ ! -f Makefile ] || $(MAKE) distclean,the package fails to build [19:45] shadeslayer: you're meant to use dh_prep instead [19:45] ok wait... wth its building now :P [19:45] sbasuita: ok.. .so use dh_prep now? [19:46] dobey, in case you're still here: you should run update-maintainer [19:46] sbasuita: ok thanks [19:46] shadeslayer: i just googled and found http://lintian.debian.org/tags/dh-clean-k-is-deprecated.html ;) [19:46] (It seems I missed it before) [19:46] btw to update my revu upload,what should i do? post debdiff? [19:46] fabrice_sp: what does that do? [19:46] sbasuita: yes i found that too,but lintian says otherwise ;) [19:47] shadeslayer: what does it say? [19:48] sbasuita: http://shadeslayer.pastebin.com/HRWJWrAz [19:48] dobey, update the maintainer field to the latest value, and put your name in XSBC-original-maintainer [19:48] fabrice_sp: haha [19:48] [dobey@lunatari:mocker]: update-maintainer --help [19:48] Maintainer email is set to an @ubuntu.com address - doing nothing. [19:48] argh [19:49] fabrice_sp: should it be something else for some reason? i will be maintaining it [19:49] dobey, the correct value is "Ubuntu Developers " [19:50] dobey, :p [19:50] put yourself as original-maintainer [19:50] shadeslayer: dh_clean and make distclean do two separate jobs [19:50] fabrice_sp: fix the FAQ :) [19:50] and after uploaded, subscribe to the bug reports [19:50] which FAQ? [19:50] https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#What%20does%20XSBC-Original-Maintainer%20mean? [19:50] shadeslayer: you'll need both [19:51] dobey, what should be fixed? [19:52] Sorry, but it seems correct with a quick read :-) [19:53] fabrice_sp: that entry implies that Original-Maintainer should match the previous value of Maintainer, when a package is changed in Ubuntu. It doesn't say new packages directly in Ubuntu should have the maintainer set to Ubuntu Developers and Original-Maintainer set. it implies that is only for pre-existing package being changed in Ubuntu [19:53] and there is no preexisting package being changed in ubuntu here [19:55] dobey, well, I'm sure that there is some wiki page that says that the maintainer field sohuld be set to Ubuntu Developers for ubuntu's package [19:55] :-) [19:56] dobey, https://wiki.ubuntu.com/DebianMaintainerField [19:56] How about https://wiki.ubuntu.com/PackagingGuide/Complete#control ? [19:57] "In Ubuntu we set the Maintainer field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team). [19:57] Edit control using the information above (making sure to provide your information for the XSBC-Original-Maintainer field)." [19:58] rfabok, so it should be set to Ubuntu Developers, and Original-Maintainer not set at all [19:58] err [19:58] wtf [19:59] i typed fab and got rfabok? [19:59] * dobey pokes irssi with a stick [19:59] fabrice_sp: ok, so it should be set to Ubuntu Developers, and Original-Maintainer not set at all [19:59] no? [19:59] dobey, you can put yourself as xsbc-original-maitainer [20:03] all these pages seem to say something just slightly different :-/ [20:09] fabrice_sp: ok, just dput another upload with that change [20:10] dobey, ok. I'll download it in a bit [20:15] dobey, my point is that if you had uploaded it to Debian, your name would be there, so it follow the same. If you check dvdstyler, you'll se my name there :-) [20:15] (and it's a pure ubuntu package) [20:16] fabrice_sp: if i had uploaded it to debian, and Maintainer includes @ubuntu.com, the wiki page states it shouldn't change, anyway :) [20:16] well, I would had updated it :-) [20:17] as maintenance in Ubuntu is Team based [20:19] Hi, I'm a member of the FrostWire team, we've finished packing a frostwire source package as requested here for inclusion to Ubuntu repo https://bugs.launchpad.net/debian/+bug/94011 - They told me to come here for help to see what's needed to include FrostWire as part of the repo. [20:19] Launchpad bug 94011 in Ubuntu "[needs-packaging] Frostwire" [Wishlist,Confirmed] [20:19] fabrice_sp: well, if i'd uploaded to debian, there would be no need to maintain it in ubuntu really. would just need it synced, and then approved for MIR later i guess [20:20] dobey, right: in a sync, the maintainer won't be hcanged [20:21] fabrice_sp: um, I thought it was, during build [20:22] tumbleweed, let me check, but source isn't [20:22] yeah, source isn't, binary is [20:24] tumbleweed, right [20:24] I've just with one package and source is still Debian maintainer, but binary is updated to Ubuntu Developers [20:33] I didn't know that. Thanks tumbleweed ! [20:43] fabrice_sp: do you need to re-advoacate for the new upload? [20:44] dobey, yep [20:44] That's what I was doing :-) [20:45] do you know if the BSD license file is copied in some place in the system? (like the GPL one) [20:45] the BSD license is almost always modified by the user [20:45] don't think it is [20:45] ok [20:46] /usr/share/common-licenses/BSD [20:46] oh it is [20:46] but watch out, people change "the name of the University" [20:46] but that's broken [20:47] because everyone doesn't assign copyright to the Regents of the University of Berkeley [20:47] so linking to that would imply the uni owns the copyright [20:47] something like that [20:59] tumbleweed: my new rules file : http://shadeslayer.pastebin.com/R5ZmbPzZ [20:59] still playing with it tho... [21:00] line 26 should be dh_prep... but its not working with that [21:01] shadeslayer_: I doubt your package is called configobj :) [21:01] >< [21:01] corrected :) [21:02] tumbleweed: ok what do you think of line 26? lintian complains of using dh_prep [21:02] but when i use it package FTBFS [21:02] why would you clean inbetween build and install? [21:03] fabrice_sp: hrmm. was that comment supposed to end immediately after "another" ? or did it get chopped off? (there's no period) [21:03] oh -k [21:03] :) === aganice_ is now known as aganice [21:12] shadeslayer_: so, what's the problem with dh_prep? [21:13] tumbleweed: http://shadeslayer.pastebin.com/4zEsfjBP [21:13] causes FTBFS cuz im not using it properly :P [21:13] dobey, it was supposed to end with "sponsor." [21:13] tumbleweed: http://pastebin.com/Nwcrg0tu [21:13] :-) [21:14] tumbleweed: i moved dh_prep to the clean part [21:14] fabrice_sp: ok [21:14] who wants to sponsor my package and upload it to universe? :) [21:14] shadeslayer_: why? why not replace dh_clean -k with dh_prep [21:14] tumbleweed: same issue [21:15] causes FTBFS [21:15] what fails? [21:15] tumbleweed: make[1]: *** No rule to make target `packages/qipmsg-1.0.0.orig/debian/qipmsg'. Stop. [21:18] shadeslayer_: works fine for me, as long as you "[ ! -f src/Makefile ] || $(MAKE) clean" [21:18] aha! [21:19] lets see what happens now.. [21:20] tumbleweed: how do i update my revu request with new changes? [21:20] you upload it again [21:20] tumbleweed: nuke earlier package? [21:20] it'll replace it [21:20] ah ok [21:20] even if its the same version? [21:21] yup [21:21] nice nice... [21:22] tumbleweed: what can i do about I: qipmsg: spelling-error-in-binary ./usr/bin/qipmsg Unkown Unknown [21:23] tumbleweed: still ftbfs :P [21:23] make[1]: *** No rule to make target `packages/qipmsg-1.0.0.orig/debian/qipmsg'. Stop. [21:23] tumbleweed: can you pastebin your rules file? or is it the same? [21:23] shadeslayer_: a single line like that doesn't help. Paste your rules file, the command you are excuting, and output [21:24] hold on ill pastebin the whole log :) [21:24] tumbleweed: http://pastebin.com/wGfPiZDU [21:24] thats the rules file [21:25] I see it's still called configobj [21:25] tumbleweed: yeah i know :P [21:25] and you try to unzip a .tar.bz2 [21:25] oh.. i need tar there [21:28] tumbleweed: how do i update my revu request with new changes? <- However you need to use the option '-f' or delete the related *.upload file otherwise you can't upload it newly [21:28] BlackZ: yes know about that :) [21:28] dput -f :) [21:30] tumbleweed: http://pastebin.com/LtP8E9wZ [21:31] thats even worse than debuild :P [21:31] BlackZ: new upstream xchat is available to merge [21:32] tumbleweed: http://pastebin.com/NSLtUiUG [21:32] ari-tczew: oh really? I will merge it then [21:32] I didn't know, sorry [21:32] BlackZ: ;) [21:32] tumbleweed: also after line 58,which dir is the script in? the untarred dir or the dir in which the packed sources are present? [21:33] this is an example, when MoM should send e-mail to last uploader with information about merge available [21:33] ( probably later according to me ) [21:33] shadeslayer_: current directory - it never cds [21:35] brb [21:39] tumbleweed: ok [21:39] that means ill have to add some more to the get-orig-source part [21:39] shadeslayer_: so, I see your problem. It only worked before because I'd been playing around [21:40] shadeslayer_: I think just allow the make clean to fail [21:40] shadeslayer_: unless someone who knows qmake better has a suggestion [21:40] shadeslayer_: yeah, it looks like your get-orig-source needs testing :) [21:40] yep... [21:42] ok,so finally now,let clean fail,but wont that cause package to ftbfs? [21:42] no, I mean say "- $(MAKE) clean" [21:42] ah .. [21:42] i was typing that :P [21:42] tumbleweed: also about dh_prep.. do i let it stay? or use dh_clean -k ? [21:43] don't use clean -k, it's deprecated [21:43] hmm [21:46] tumbleweed: http://shadeslayer.pastebin.com/AseHBtgr === keffie_jayx is now known as effie_jayx [21:56] shadeslayer_: I simply don't get that. what am I doing wrong? http://shadeslayer.pastebin.com/rfA5EfS4 [22:00] tumbleweed: you don't have an space in the directory where you try to build the package like shadeslayer_ [22:00] from shadeslayer_: DESTDIR=/home/shadeslayer/ninja/New packages/qipmsg-1.0.0.orig/debian/qipmsg [22:00] geser: :) [22:00] the " " in New packages isn't escaped or guarded [22:01] well spotted [22:03] oh I suppose that'd have been obvious if I'd read the log properly. must be getting tired [22:07] geser: in the new xchat package we use dpatch but the maintainer of the package dropped dpatch and adopted quilt, now we have two possibilities: 1. reintroduce dpatch for our patches; 2. rename all patches. What's the best way for you? [22:08] BlackZ: why do you have to rename the patches? [22:08] BlackZ: 3. convert the dpatches to quilt [22:09] how can I get buildlog from pbuilder-dist ? [22:09] ~/pbuilder/blah_result/last_operation.log [22:09] micahg: in the currently debian package the patches are in the *.patch ext, for an "university" reason [22:09] also, the package uses quilt as well, now [22:10] ari-tczew: pbuilder-dist maverick build --logfile build.log a_package.dsc [22:10] oh, pbuiler-dist logs by default? [22:10] yep [22:11] BlackZ: right, but you're merging from debian, right? so, just convert whatever patches we add like geser suggested [22:11] yes, I missed that, thanks geser [22:12] thanks Laney and geser