=== _neversfelde is now known as neversfelde [01:16] Hi, if anyone has the time to review my updated packages, http://revu.ubuntuwire.com/details.py?package=charm, I would be very grateful. Thanks === kc8tad is now known as rrittenhouse [01:36] binarymutant, I'll have a look === tonyyarusso is now known as Guest24518 === tonyyarusso is now known as Guest12575 [01:50] binarymutant, commented. === tonyyarusso is now known as Guest5946 [01:53] thanks DktrKranz === Guest5946 is now known as tonyyarusso [02:51] which version of dh_make and lintian should I use? whichever that is in their VCS ? === jmarsden_ is now known as jmarsden [03:22] help review my packages: http://revu.ubuntuwire.com/details.py?package=ibus-hangul, http://revu.ubuntuwire.com/details.py?package=ibus-table-cangjie, http://revu.ubuntuwire.com/details.py?package=fqterm, thanks === tritium_ is now known as tritium === ziroday` is now known as ziroday [04:36] hello [04:36] anybody here? [04:50] I've written a .net application and ported it to Mono to compile under Ubuntu, could any one point me in the direction of packaging the application such that it can be included in the repositories? My project is here https://sourceforge.net/projects/vscalenotes/ [04:52] HarassmentPanda, you may statr by looking at https://wiki.ubuntu.com/PackagingGuide/ [04:52] s/statr/start/ [04:53] Is there an easy way to find out what dependencies a program requires? [04:53] and may also want to look at http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ [04:53] As in I got my program to run but I don't know what the actual dependencies are [04:54] That looks like a lot to read :-) [04:54] indeed [04:54] I don't know if I will have time to continue developing the project if I have to read all that to package it [04:55] you do not need to, but it helps to understand what will happen [04:55] So even if I package it, it may not be included in a universe? [04:55] the packaging guide is a brief introduction to packaging [04:55] if it is not (for example) free software, indeed [04:56] its released under the GPL [04:56] way to go [04:56] and the only libraries it relies on are SDL and mono [04:56] not sure of exactly which ones as I just installed everything to get it to work [04:58] then for sure SDL and mono [04:59] you can use pbuilder to find out more -- the build will fail if you are missing depends [04:59] https://wiki.ubuntu.com/PbuilderHowto [05:00] is there any where I could suggest my software to be packaged by some one more experienced? [05:01] I guess here (not sure myself), or the ubuntu-devel-discuss mailing list, for example [05:02] * hggdh is not a motu, so your mileage may vary [05:02] hu? [05:03] HarassmentPanda: You can file a bug against Ubuntu and tag it 'needs-packaging'. There are people who look at those for stuff to package. [05:04] ok thanks [05:05] i'll try that first === HarassmentPanda is now known as HarassmentPanda| [05:41] thanks, ScottK [05:41] hggdh: No problem. [05:44] quick question: updating a package to a new release fixes/commits all of the quilt patches in debian/patches. should quilt and the patches/ directory be dropped entirely from the new version, or left for future use? [05:45] Generally dropped. Is it a KDE package? [05:46] ScottK: nope, twitux from 0.62 to 0.68. [05:46] Then you can drop it. [05:46] ScottK: ok, thanks. :) [08:24] is ports.ubuntu.com down? apt-get is giving timeout here. === svaksha is now known as svaksham [10:11] could someone explain to me why the acpi update replaced all the conf files? [10:11] ie. http://paste.ubuntu.com/105835/ [10:12] Because you hadn't modified them, and the maintainer had? [10:15] It should not be possible for an incoming SMS to lock up my phone. === asac_ is now known as asac [10:30] RAOF, yay for phones [10:58] jpds: consider catching that extension to hide the traceback [11:03] RainCT: if cred == None: print >> sys.stderr, "Failed." ? [11:07] jpds: nope, that won't work. try: [cred =....] except IOError, msg: print >> sys.stderr, msg; sys.exit(1); [11:09] RainCT: That works. :) [11:25] help review my packages: http://revu.ubuntuwire.com/details.py?package=ibus-hangul, http://revu.ubuntuwire.com/details.py?package=ibus-table-cangjie, http://revu.ubuntuwire.com/details.py?package=fqterm, thanks [12:28] StevenK: Hi, I have an issue you encountered already some days ago on gnome-games package: http://paste.ubuntu.com/105881/. Strange as the patch including launchpad-integration.h is there and applied successfully [13:05] what should i name a cleaned up tarball? i can't exactly call it package_version.orig.tar.gz can i? [13:32] hyperair: You append some string to the end of the upstream version [13:33] For example, in Debian, when the reason for repacking is to comply with the DFSG, they append .dfsg - for a general removal of junk, .cleaned or .repack might be reasonable tokens to append [13:34] maxb: i need to do autogen.sh && make dist [13:34] why do you need to do it? [13:34] maxb: because the upstream author decided that it was too dificult to use make dist for some reason or other [13:35] hmm, odd [13:35] maxb: build fails otherwise [13:35] a whole lot of missing files or other [13:35] An alternative option might be to use the original upstream tarball, and run those things at build time? [13:35] That might be considered preferable [13:36] config.status: error: cannot find input file: src/Makefile.in [13:36] lintian spits out a lot of stuff [13:36] config.log in orig tarball and whatnot [13:37] so i was thinking, since i'm going to have to repack it to make lintian be happy, i must as well do the autogen stuff in the repack process [13:37] and CDBS's autotools thing only runs ./configure,which fails because the author forgot to include src/Makefile.in [13:38] i've emailed him thrice [13:38] I'm not sure you should repack at all if it's just to get rid of cruft, unless the amount of cruft is huge [13:38] maxb: but if i want to get it through revu lintian has to be clean right? [13:40] maxb: also, i'll add stuff to build-dep if i need to run autogen [13:40] Hmm, I think it's worth finding a MOTU for a definitive opinion on that. Personally I'd consider a few lintian warnings (which can be overridden) preferable to a repack [13:41] I can't see why extra build-deps would be a problem? [13:41] oh right. overriding the errors. i forgot about that [13:41] yeah i think i'll do just that [13:41] thanks [13:41] directhex: ping [13:41] If you can avoid the repack, then upgrading to new upstream versions is considerably easier [13:46] hyperair, pong [13:48] directhex: banshee lyrics plugin has a tarball scattered with config.status, config.log and is missing a Makefile.in. do i autogen.sh before configure, or do i repack the tarball? [13:48] directhex: another thing.. the version 0.6 of banshee lyrics plugin is newer than 1.0. how do i convince uscan to not take 1.0 instead? [13:49] hyperair, which strikes you as easier to maintain, long term? [13:49] directhex: autogen.sh before configure, but then it'll have more build-deps [13:49] directhex: specifically automake1.9 or something, and that'll change when automake 1.9 gets deprecated [13:51] no actually i'll just depend on the latest automake and autoconf and see how it goe [13:51] sd [13:52] bear in mind issues with your "clean" rule not being correct [13:58] directhex: what? [13:59] hyperair, packages should be buildable twice in a row, which requires your "clean" rule to get the package back to *precisely* how it was when you unpacked. messing with autofoo inside the package increases risks of that not being the case [13:59] directhex: what about the whole uscan version thing? how do i prevent it from grabbing 1.0 instead of 0.6? upstream only distributes a bz2, so i suppose i'll have to use get-orig-source for a gz [14:00] directhex: i'll see what i can do about clean [14:00] hyperair, broken upstream versions? hm................. dunno. sorry. [14:01] hyperair, sounds like a pretty hard case for uscan to deal with properly... perhaps something involving dates, if it's in an ftp dir? [14:01] =\ [14:01] it's a google code site [14:01] 0.6 comes after 1.0 [14:01] because the upstream author is a genius like that [14:01] then yell at upstream ;) [14:02] laga: if yelling worked, don't you think i'd have already gotten him to use make dist instead of manually tarring his stuff? [14:02] laga: i even went out of my way to fix his damn stupid build system and propose a patch to him [14:06] heh === ivoks__ is now known as ivoks [14:17] slytherin: ports.ubuntu.com should be back. [14:24] directhex: clean removes autom4te.cache which was included in the source tarball, but otherwise second build works fine [14:24] directhex: is that okay? [14:37] james_w: do you mind if I work on azureus? [14:37] I mean the merge [14:37] slytherin: not at all [14:37] james_w: by the way, what is the reason vuze is demoted to suggests? [14:38] not sure, let me look [14:39] "Recommend vuze until we find a way to start azureus without the vuze [14:39] + interface." [14:40] so I guess that is possible now? [14:40] james_w: yes, I am seeing some changes in Debian which introduces new wrapper script with appropriate variables to start with/without vuze interface. [14:42] anybody running jaunty here? can someone help me find out which package /usr/bin/csc is in? [14:43] nevermind, i foudn it [14:43] hyperair: I am running jaunty. IIRC it is the part of mono toolchain. You can search on packages.ubuntu.com [14:43] http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition [14:43] slytherin: mono-devel [14:43] i needed it as a build-dep [14:46] james_w: IIRC, azureus does not work with gij, right? [14:47] slytherin: not sure, sorry [14:47] slytherin: check the RC bug that was fixed in the NMU [14:48] hmm [14:59] could someone review my package? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin [15:05] hyperair, I'll take a look, if you will help me with another package in return ;-) [15:05] mok0: no problem [15:05] mok0: what's the package? [15:05] hyperair: lemme find it [15:07] hyperair: it's http://revu.ubuntuwire.com/details.py?package=gnome-art-ng [15:08] Look at my comment, strangely gmcs is missing eventhough the package does pull in mono-gmcs [15:09] mok0: heh. i had that problem too. you need to pull in mono-devel, and then add MCS=/usr/bin/csc to configure flags [15:11] hyperair, thanks! Will you write that in a comment to the uploader? [15:12] alright [15:12] but i'll take a look at the package and make sure that works first [15:12] hyperair: oh, that's perfect [15:13] hyperair: you rock as dholbach would say :-) [15:13] hahah thanks [15:14] i actually just learnt abotu this whole csc thting, because bansheelyricsplugin wouldn't build but there was a banshee binary in jaunty, so i dug that one out and took a look [15:23] hmm this gnome-art-ng thing is a pretty nice app [15:24] hyperair: oh, that's good to know [15:24] so yeah it built [15:24] hehe [15:24] after i made the changes i posted in the comments [15:25] mok0: anyway how about that review? [15:25] hyperair: thank you. I had a few troubles with your new package, see the comments [15:25] hmm [15:26] ah damnit. .svn folders eh? i didn't see that one. [15:26] hyperair: yeah [15:26] mok0: should i cleanup the tarball in get-orig-source or something then? [15:27] mok0: regarding the errors to do with apt-get, could you update your sbuilder or something? [15:27] hyperair: some MOTUs think it should be done; I don't care. [15:27] mok0: it doesn't seem to be a problem with my pacakge, but a problem with banshee [15:27] hyperair: however, it is sloppy packaging of the tarball [15:27] mok0: i know. it is. i tried to get the author to use "make dist" [15:27] but he wouldn't listen [15:27] hyperair: it's not a spelling mistake in build-depends versions? [15:27] mok0: no it's not. pbuilder works fine [15:27] and my pbuilder's pretty up to date [15:27] 2.24.0 -> 2.24? [15:28] banshee: Depends: libgconf2.24-cil (>= 2.24.0) but it is not going to be installed [15:28] Depends: libgnome2.24-cil (>= 2.24.0) but it is not going to be installed [15:28] that seems to indicate it's a problem with banshee's dependencies [15:28] but banshee installs just fine on my pbuilder [15:28] It could have something to do with the archs [15:28] Maybe even 2.24~ [15:28] mok0: what arch are you building on? [15:29] I had to specify arch-indep [15:29] arch-indep? [15:29] where? [15:30] hyperair: my machine is amd64, and with sbuild, it does not build arch "all" by default [15:30] i see [15:30] hyperair: your package only contains arch "all", so I had to pass an "-A" flag [15:30] ah [15:31] hyperair: pbuilder builds "all" arch by default [15:31] well mine's an x86 machine [15:31] So sometimes, I have discovered packaging bugs that way [15:31] no make that an x86 installation [15:31] Would you not always want to use sbuild -A for evaluating whether a prospective package builds? [15:32] maxb: if it's purely arch packages, I don't need to [15:32] true [15:32] mok0: regarding the build-deps.. i didn't have any versioned build-deps [15:32] libgconf2.0-cil, [15:32] libgtkhtml3.16-cil [15:32] those are the only -cil packages [15:33] hyperair: ah, so it could be a problem with banshee's depends? [15:33] it could be [15:33] hyperair: I just now updated my builder from the archive [15:33] if you're running jaunty, could you try installing banshee? [15:33] or perhaps install it in your sbuilder temporarily? [15:33] hyperair: I'm not [15:33] in your sbuilder? [15:33] hyperair: I only have a jaunty schroot [15:34] yes [15:34] if it doesn't work it would be a banshee problem. otherwise i don't know what the error's about [15:34] hyperair: I can log on to my schroot at try it [15:35] ah. please do. [15:38] hyperair: it's takes a while, it has to install a ton of stuff [15:39] okay [15:40] oh and by the way, what lintian arguments did you use? [15:40] hyperair: -I [15:40] hyperair: that's capital i [15:40] i also used lintian -i on the .dsc [15:40] oh [15:40] -I [15:40] revu doesn't use it i guses [15:40] revu's lintian log is clean [15:40] no [15:41] ok no problems installing banshee [15:41] okay [15:41] could you try building it again then? [15:41] In the chroot I'm in? [15:42] also what should i do about the build-depends-without-arch-dep lintian error? [15:42] hyperair: use -iI it will tell you [15:42] not necessarily, could be a fresh chroot [15:43] I'll try manually in the schroot I'm in right now [15:46] hyperair: just running debian/rules build, I get this error: [15:46] configure: error: Cannot find "mcs" compiler in your PATH [15:47] you need to run autogen.sh? [15:48] yep [15:48] how about debuild -b [15:48] configure needs to be run with MCS=/usr/bin/csc [15:48] that's specified in debian/rules [15:49] hyperair: it's not happening in the autogen.sh call [15:49] eh whoos [15:49] whoops* [15:49] If I am using cdbs to build a package and cdbs already has dependency on debhelper, do I need to add debhelper as build-dep? [15:49] mok0: configure still gets called after autogen.sh gets called [15:49] mok0: because cdbs adds some flags i think [15:50] hyperair: http://paste.ubuntu.com/105935/ [15:51] aah. right. i forgot [15:52] should i patch configure out of autogen.sh? [15:52] otherwise configure gets called around three times i think [15:52] hyperair: how about using autoreconf instead [15:52] yeah it's PITA [15:53] hyperair: the right thing is to patch configure.ac and regenerate configure using the tools [15:54] patch configure.ac? [15:54] what do i change it to? [15:56] hyperair: I need to see what you've done first [15:56] hyperair: in the meantime, look at the output of my sbuild http://paste.ubuntu.com/105937/ [15:58] mok0: did you install mono-devel on your sbuild? [15:58] mok0: i just tested without the whole DEB_CONFIGURE_EXTRA_FLAGS line, and it works [15:58] hyperair: no [15:58] as long as mono-devel is installed [15:58] mono-devel is a build-dep [15:59] also, that's intrepid [15:59] in intrepid i suppose it's mono-gmcs [15:59] in jaunty it's mono-devel [15:59] hyperair: it won't compile under intrepid [16:00] hyperair: but what does it require from banshee? [16:00] mok0: the pkg-config file [16:00] /usr/lib/pkg-config/bansheesomething.pc [16:00] hyperair: oh, that's probably in banshee-dev or something [16:01] banshee-1-thickclient [16:01] there isn't a banshee-dev [16:01] hyperair: right, so you builddepend on that? [16:01] yep [16:01] but the problem here is that if it builds in jaunty (build-dep mono-devel) it won't build in intrepid (build-dep mono-gmcs) and vice versa [16:02] so how would i fix that? [16:02] hyperair: your package should be for jaunty [16:02] alright, so i just don't care? [16:02] right [16:02] or should i put mono-devel | mono-gmcs? [16:02] hyperair: it can be changed if there's ever a backport [16:02] perhaps mono-gmcs ( oh [16:03] okay [16:03] i'll make my next upload then [16:04] * mok0 goes to get some coffee... [16:16] mok0: new upload. could you review that please? [16:22] ok [16:26] hyperair: is it correct that banshee-extension-lyrics [16:26] has arch "all" and not "any" ? [16:26] well [16:26] -cil generally has arch all [16:26] i tink [16:26] think* [16:26] mok0: there's actually a deb for amd64 that works on intrepid.. [16:26] arch all [16:27] http://launchpad.net/~banshee-team/+archive [16:27] hyperair: ... because mono creates bytecode for all archs? [16:27] yeah [16:27] ok, so it's like java [16:27] yep [16:27] in fact, you can take bytecode compiled on windows and run it on linux [16:28] also gnome-sharp2 has arch=all [16:28] yes I know it's pretty cool [16:28] not that i like mono =p [16:28] or C# [16:28] I'm a sceptic too [16:28] hahah [16:29] i just keep my mouth shut about it. let both sides argue it out. but you won't see me programming in C# anytime soon [16:30] hyperair: I still get those missing dependencies of banshee [16:31] meh damnit [16:31] pbuilder doesn't have any trouble [16:32] http://paste.ubuntu.com/105958/ [16:33] there has to be some conflict or other [16:33] otherwise it would be installed [16:34] hyperair: could be that jaunty is broken somehow at the moment [16:34] aah [16:34] wait [16:34] wait [16:34] i think i might have a clue.. [16:34] i made it depend on libgconf2.0-cil [16:35] aha [16:35] yep [16:35] but why did it work on my pbuilder? [16:35] strange [16:35] hyperair: I'll get rid of it [16:35] and try again [16:36] hyperair: probably the package set evolved since you last updated it [16:37] hyperair, here goes, it's doing something more [16:38] okay [16:38] actually, should i include libgconf2.24-cil or not? since banshee includes the dependency [16:39] hyperair: leave that dep to banshee [16:39] ah, crashed [16:39] with a stacktrace [16:40] hm [16:40] meh [16:40] that's weird, it's trying to open a file in my home directory [16:41] hyperair: I'll pastebin it [16:41] okay [16:42] no actually are you sure it's trying to open a file in your home directory and not the upstream author's home directory? [16:42] http://paste.ubuntu.com/105959/ [16:42] no mine, look here [16:42] lines 4 and 6 [16:43] and it's spooky, my cwd is /tmp [16:44] your /home is /u? [16:44] hyperair: yes [16:44] ah [16:44] to save typing or what [16:44] /u/mok [16:44] i think you might have some stray env variable [16:45] to do with .wapi [16:45] hyperair: I don't even know what that is [16:45] wait, i've dealt with .wapi stuff before.. when packaging for archlinux [16:46] you have a MONO_SHARED_DIR env variable set? [16:46] archlinux packages generally have export MONO_SHARED_DIR=$(srcdir)/.wapi somewhere, and then rm -rf it after the build [16:46] no [16:47] meh strange [16:47] can you grep your env for .wapi then? [16:47] The only thing is HOME [16:47] that refers to /u/mok you mean? [16:48] yes [16:48] there's nothing with .wapi in my env [16:48] strange [16:48] wait, i thought it didn't build in intrepid [16:48] or do you have a home directory in sbuild [16:49] Well, the sbuild enviroment doesn't know about /u [16:49] http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html [16:50] hmm [16:50] something about .wapi [16:50] which is nice because I don't want it to fool around with my personal stuff [16:50] okay then [16:50] it seems that i need to export MONO_SHARED_DIR [16:50] and then remove it [16:51] I have a dir ~/.wapi but it's empty [16:51] Created 2008-08-19 [16:52] In fact I'll get rid of it [16:52] hmm i think i'll create one just to test [16:53] hey wait there are files in mine [16:53] i think i'll just clear it and leave it empty then try building in a non-chroot env [16:53] ok [16:54] uh damn that doesn't work. [16:54] i'm on intrpied [16:54] intrepid* [16:55] how very strange. i don't get errors [16:55] * mok0 is even more convinced that mono is evil [16:57] still no errors [16:57] I'm getting a stacktrace from the _compiler_ because it can't open a semaphore file in a hidden directory in my root??? WTF? [16:57] lol! [16:57] heh [16:58] i'm uploading another one with the whole .wapi thing fixed [16:58] hyperair: what did you do? [16:58] export MONO_SHARED_DIR=$(CURDIR) [16:58] near the top of debian/rules [16:58] * mok0 , your friendly neighborhood buildd [16:59] hahah [16:59] hyperair: you have a ppa? [17:00] mok0: yes i do [17:00] several [17:00] under different teams of course [17:00] you might try to upload it there to test build... just add ~ppa1 to the version [17:02] yeah i could [17:02] it'd have reached ppa20 by now =p [17:02] hyperair: ah. remember to remove that libgconf-cil dep next upload [17:02] wow [17:02] done [17:10] The build succeeded now! [17:10] although, you may need to add "libtool" to the build deps [17:12] mok0, don't we have pbuilder for test building? ;] [17:13] cody-somerville: heh, well pbuilder is more tolerant that buildd [17:13] cody-somerville: and in this instance, the build succeeds in pbuilder but fails in sbuild [17:16] hyperair, are you in contact with upstream of this plugin? [17:17] if an application has been packaged upstream, is it possible to have it copied over with the authors permission, rather than packaging it again? [17:18] nellery: no [17:19] mok0: so it should be completely repackaged from scratch [17:19] nellery: of course you can take over the files in debian/ [17:19] nellery: ... and upstream should be persuaded not to ship the debian/ dir [17:20] mok0: okay [17:20] thanks [17:20]