[01:16] <binarymutant> 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
[01:36] <DktrKranz> binarymutant, I'll have a look
[01:50] <DktrKranz> binarymutant, commented.
[01:53] <binarymutant> thanks DktrKranz
[02:51] <binarymutant> which version of dh_make and lintian should I use? whichever that is in their VCS ?
[03:22] <lidaobing> 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
[04:36] <sukiminna> hello
[04:36] <sukiminna> anybody here?
[04:50] <HarassmentPanda> 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] <hggdh> HarassmentPanda, you may statr by looking at https://wiki.ubuntu.com/PackagingGuide/
[04:52] <hggdh> s/statr/start/
[04:53] <HarassmentPanda> Is there an easy way to find out what dependencies a program requires?
[04:53] <hggdh> and may also want to look at http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/
[04:53] <HarassmentPanda> As in I got my program to run but I don't know what the actual dependencies are
[04:54] <HarassmentPanda> That looks like a lot to read :-)
[04:54] <hggdh> indeed
[04:54] <HarassmentPanda> 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] <hggdh> you do not need to, but it helps to understand what will happen
[04:55] <HarassmentPanda> So even if I package it, it may not be included in a universe?
[04:55] <hggdh> the packaging guide is a brief introduction to packaging
[04:55] <hggdh> if it is not (for example) free software, indeed
[04:56] <HarassmentPanda> its released under the GPL
[04:56] <hggdh> way to go
[04:56] <HarassmentPanda> and the only libraries it relies on are SDL and mono
[04:56] <HarassmentPanda> not sure of exactly which ones as I just installed everything to get it to work
[04:58] <hggdh> then for sure SDL and mono<something>
[04:59] <hggdh> you can use pbuilder to find out more -- the build will fail if you are missing depends
[04:59] <hggdh> https://wiki.ubuntu.com/PbuilderHowto
[05:00] <HarassmentPanda> is there any where I could suggest my software to be packaged by some one more experienced?
[05:01] <hggdh> 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] <HarassmentPanda> hu?
[05:03] <ScottK> 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] <HarassmentPanda> ok thanks
[05:05] <HarassmentPanda> i'll try that first
[05:41] <hggdh> thanks, ScottK
[05:41] <ScottK> hggdh: No problem.
[05:44] <jacob> 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] <ScottK> Generally dropped.  Is it a KDE package?
[05:46] <jacob> ScottK: nope, twitux from 0.62 to 0.68.
[05:46] <ScottK> Then you can drop it.
[05:46] <jacob> ScottK: ok, thanks. :)
[08:24] <slytherin> is ports.ubuntu.com down? apt-get is giving timeout here.
[10:11] <jussi01> could someone explain to me why the acpi update replaced all the conf files?
[10:11] <jussi01> ie. http://paste.ubuntu.com/105835/
[10:12] <RAOF> Because you hadn't modified them, and the maintainer had?
[10:15] <RAOF> It should not be possible for an incoming SMS to lock up my phone.
[10:30] <directhex> RAOF, yay for phones
[10:58] <RainCT> jpds: consider catching that extension to hide the traceback
[11:03] <jpds> RainCT: if cred == None: print >> sys.stderr, "Failed." ?
[11:07] <RainCT> jpds: nope, that won't work.  try: [cred =....]  except IOError, msg: print >> sys.stderr, msg; sys.exit(1);
[11:09] <jpds> RainCT: That works. :)
[11:25] <lidaobing>  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] <didrocks> 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] <hyperair> what should i name a cleaned up tarball? i can't exactly call it package_version.orig.tar.gz can i?
[13:32] <maxb> hyperair: You append some string to the end of the upstream version
[13:33] <maxb> 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] <hyperair> maxb: i need to do autogen.sh && make dist
[13:34] <maxb> why do you need to do it?
[13:34] <hyperair> maxb: because the upstream author decided that it was too dificult to use make dist for some reason or other
[13:35] <maxb> hmm, odd
[13:35] <hyperair> maxb: build fails otherwise
[13:35] <hyperair> a whole lot of missing files or other
[13:35] <maxb> An alternative option might be to use the original upstream tarball, and run those things at build time?
[13:35] <maxb> That might be considered preferable
[13:36] <hyperair> config.status: error: cannot find input file: src/Makefile.in
[13:36] <hyperair> lintian spits out a lot of stuff
[13:36] <hyperair> config.log in orig tarball and whatnot
[13:37] <hyperair> 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] <hyperair> and CDBS's autotools thing only runs ./configure,which fails because the author forgot to include src/Makefile.in
[13:38] <hyperair> i've emailed him thrice
[13:38] <maxb> 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] <hyperair> maxb: but if i want to get it through revu lintian has to be clean right?
[13:40] <hyperair> maxb: also, i'll add stuff to build-dep if i need to run autogen
[13:40] <maxb> 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] <maxb> I can't see why extra build-deps would be a problem?
[13:41] <hyperair> oh right. overriding the errors. i forgot about that
[13:41] <hyperair> yeah i think i'll do just that
[13:41] <hyperair>  thanks
[13:41] <hyperair> directhex: ping
[13:41] <maxb> If you can avoid the repack, then upgrading to new upstream versions is considerably easier
[13:46] <directhex> hyperair, pong
[13:48] <hyperair> 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] <hyperair> 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] <directhex> hyperair, which strikes you as easier to maintain, long term?
[13:49] <hyperair> directhex: autogen.sh before configure, but then it'll have more build-deps
[13:49] <hyperair> directhex: specifically automake1.9 or something, and that'll change when automake 1.9 gets deprecated
[13:51] <hyperair> no actually i'll just depend on the latest automake and autoconf and see how it goe
[13:51] <hyperair> sd
[13:52] <directhex> bear in mind issues with your "clean" rule not being correct
[13:58] <hyperair> directhex: what?
[13:59] <directhex> 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] <hyperair> 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] <hyperair> directhex: i'll see what i can do about clean
[14:00] <directhex> hyperair, broken upstream versions? hm................. dunno. sorry.
[14:01] <directhex> 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] <hyperair> =\
[14:01] <hyperair> it's a google code site
[14:01] <hyperair> 0.6 comes after 1.0
[14:01] <hyperair> because the upstream author is a genius like that
[14:01] <laga> then yell at upstream ;)
[14:02] <hyperair> 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] <hyperair> laga: i even went out of my way to fix his damn stupid build system and propose a patch to him
[14:06] <laga> heh
[14:17] <persia> slytherin: ports.ubuntu.com should be back.
[14:24] <hyperair> directhex: clean removes autom4te.cache which was included in the source tarball, but otherwise second build works fine
[14:24] <hyperair> directhex: is that okay?
[14:37] <slytherin> james_w: do you mind if I work on azureus?
[14:37] <slytherin> I mean the merge
[14:37] <james_w> slytherin: not at all
[14:37] <slytherin> james_w: by the way, what is the reason vuze is demoted to suggests?
[14:38] <james_w> not sure, let me look
[14:39] <james_w> "Recommend vuze until we find a way to start azureus without the vuze
[14:39] <james_w> +    interface."
[14:40] <james_w> so I guess that is possible now?
[14:40] <slytherin> 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] <hyperair> anybody running jaunty here? can someone help me find out which package /usr/bin/csc is in?
[14:43] <hyperair> nevermind, i foudn it
[14:43] <slytherin> hyperair: I am running jaunty. IIRC it is the part of mono toolchain. You can search on packages.ubuntu.com
[14:43] <james_w> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
[14:43] <hyperair> slytherin: mono-devel
[14:43] <hyperair> i needed it as a build-dep
[14:46] <slytherin> james_w: IIRC, azureus does not work with gij, right?
[14:47] <james_w> slytherin: not sure, sorry
[14:47] <james_w> slytherin: check the RC bug that was fixed in the NMU
[14:48] <slytherin> hmm
[14:59] <hyperair> could someone review my package? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[15:05] <mok0> hyperair, I'll take a look, if you will help me with another package in return ;-)
[15:05] <hyperair> mok0: no problem
[15:05] <hyperair> mok0: what's the package?
[15:05] <mok0> hyperair: lemme find it
[15:07] <mok0> hyperair: it's http://revu.ubuntuwire.com/details.py?package=gnome-art-ng
[15:08] <mok0> Look at my comment, strangely gmcs is missing eventhough the package does pull in mono-gmcs
[15:09] <hyperair> 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] <mok0> hyperair, thanks! Will you write that in a comment to the uploader?
[15:12] <hyperair> alright
[15:12] <hyperair> but i'll take a look at the package and make sure that works first
[15:12] <mok0> hyperair: oh, that's perfect
[15:13] <mok0> hyperair: you rock as dholbach would say :-)
[15:13] <hyperair> hahah thanks
[15:14] <hyperair> 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] <hyperair> hmm this gnome-art-ng thing is a pretty nice app
[15:24] <mok0> hyperair: oh, that's good to know
[15:24] <hyperair> so yeah it built
[15:24] <hyperair> hehe
[15:24] <hyperair> after i made the changes i posted in the comments
[15:25] <hyperair> mok0: anyway how about that review?
[15:25] <mok0> hyperair: thank you. I had a few troubles with your new package, see the comments
[15:25] <hyperair> hmm
[15:26] <hyperair> ah damnit. .svn folders eh? i didn't see that one.
[15:26] <mok0> hyperair: yeah
[15:26] <hyperair> mok0: should i cleanup the tarball in get-orig-source or something then?
[15:27] <hyperair> mok0: regarding the errors to do with apt-get, could you update your sbuilder or something?
[15:27] <mok0> hyperair: some MOTUs think it should be done; I don't care.
[15:27] <hyperair> mok0: it doesn't seem to be a problem with my pacakge, but a problem with banshee
[15:27] <mok0> hyperair: however, it is sloppy packaging of the tarball
[15:27] <hyperair> mok0: i know. it is. i tried to get the author to use "make dist"
[15:27] <hyperair> but he wouldn't listen
[15:27] <mok0> hyperair: it's not a spelling mistake in build-depends versions?
[15:27] <hyperair> mok0: no it's not. pbuilder works fine
[15:27] <hyperair> and my pbuilder's pretty up to date
[15:27] <mok0> 2.24.0 -> 2.24?
[15:28] <hyperair> banshee: Depends: libgconf2.24-cil (>= 2.24.0) but it is not going to be installed
[15:28] <hyperair>            Depends: libgnome2.24-cil (>= 2.24.0) but it is not going to be installed
[15:28] <hyperair> that seems to indicate it's a problem with banshee's dependencies
[15:28] <hyperair> but banshee installs just fine on my pbuilder
[15:28] <mok0> It could have something to do with the archs
[15:28] <ScottK> Maybe even 2.24~
[15:28] <hyperair> mok0: what arch are you building on?
[15:29] <mok0> I had to specify arch-indep
[15:29] <hyperair> arch-indep?
[15:29] <hyperair> where?
[15:30] <mok0> hyperair: my machine is amd64, and with sbuild, it does not build arch "all" by default
[15:30] <hyperair> i see
[15:30] <mok0> hyperair: your package only contains arch "all", so I had to pass an "-A" flag
[15:30] <hyperair> ah
[15:31] <mok0> hyperair: pbuilder builds "all" arch by default
[15:31] <hyperair> well mine's an x86 machine
[15:31] <mok0> So sometimes, I have discovered packaging bugs that way
[15:31] <hyperair> no make that an x86 installation
[15:31] <maxb> Would you not always want to use sbuild -A for evaluating whether a prospective package builds?
[15:32] <mok0> maxb: if it's purely arch packages, I don't need to
[15:32] <maxb> true
[15:32] <hyperair> mok0: regarding the build-deps.. i didn't have any versioned build-deps
[15:32] <hyperair>                libgconf2.0-cil,
[15:32] <hyperair>                libgtkhtml3.16-cil
[15:32] <hyperair> those are the only -cil packages
[15:33] <mok0> hyperair: ah, so it could be a problem with banshee's depends?
[15:33] <hyperair> it could be
[15:33] <mok0> hyperair: I just now updated my builder from the archive
[15:33] <hyperair> if you're running jaunty, could you try installing banshee?
[15:33] <hyperair> or perhaps install it in your sbuilder temporarily?
[15:33] <mok0> hyperair: I'm not
[15:33] <hyperair> in your sbuilder?
[15:33] <mok0> hyperair: I only have a jaunty schroot
[15:34] <mok0> yes
[15:34] <hyperair> if it doesn't work it would be a banshee problem. otherwise i don't know what the error's about
[15:34] <mok0> hyperair: I can log on to my schroot at try it
[15:35] <hyperair> ah. please do.
[15:38] <mok0> hyperair: it's takes a while, it has to install a ton of stuff
[15:39] <hyperair> okay
[15:40] <hyperair> oh and by the way, what lintian arguments did you use?
[15:40] <mok0> hyperair: -I
[15:40] <mok0> hyperair: that's capital i
[15:40] <hyperair> i also used lintian -i on the .dsc
[15:40] <hyperair> oh
[15:40] <hyperair> -I
[15:40] <hyperair> revu doesn't use it i guses
[15:40] <hyperair> revu's lintian log is clean
[15:40] <mok0> no
[15:41] <mok0> ok no problems installing banshee
[15:41] <hyperair> okay
[15:41] <hyperair> could you try building it again then?
[15:41] <mok0> In the chroot I'm in?
[15:42] <hyperair> also what should i do about the build-depends-without-arch-dep lintian error?
[15:42] <mok0> hyperair: use -iI it will tell you
[15:42] <hyperair> not necessarily, could be a fresh chroot
[15:43] <mok0> I'll try manually in the schroot I'm in right now
[15:46] <mok0> hyperair: just running debian/rules build, I get this error:
[15:46] <mok0> configure: error: Cannot find "mcs" compiler in your PATH
[15:47] <mok0> you need to run autogen.sh?
[15:48] <hyperair> yep
[15:48] <hyperair> how about debuild -b
[15:48] <hyperair> configure needs to be run with MCS=/usr/bin/csc
[15:48] <hyperair> that's specified in debian/rules
[15:49] <mok0> hyperair: it's not happening in the autogen.sh call
[15:49] <hyperair> eh whoos
[15:49] <hyperair> whoops*
[15:49] <slytherin> 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] <hyperair> mok0: configure still gets called after autogen.sh gets called
[15:49] <hyperair> mok0: because cdbs adds some flags i think
[15:50] <mok0> hyperair: http://paste.ubuntu.com/105935/
[15:51] <hyperair> aah. right. i forgot
[15:52] <hyperair> should i patch configure out of autogen.sh?
[15:52] <hyperair> otherwise configure gets called around three times i think
[15:52] <mok0> hyperair: how about using autoreconf instead
[15:52] <mok0> yeah it's PITA
[15:53] <mok0> hyperair: the right thing is to patch configure.ac and regenerate configure using the tools
[15:54] <hyperair> patch configure.ac?
[15:54] <hyperair> what do i change it to?
[15:56] <mok0> hyperair: I need to see what you've done first
[15:56] <mok0> hyperair: in the meantime, look at the output of my sbuild http://paste.ubuntu.com/105937/
[15:58] <hyperair> mok0: did you install mono-devel on your sbuild?
[15:58] <hyperair> mok0: i just tested without the whole DEB_CONFIGURE_EXTRA_FLAGS line, and it works
[15:58] <mok0> hyperair: no
[15:58] <hyperair> as long as mono-devel is installed
[15:58] <hyperair> mono-devel is a build-dep
[15:59] <hyperair> also, that's intrepid
[15:59] <hyperair> in intrepid i suppose it's mono-gmcs
[15:59] <hyperair> in jaunty it's mono-devel
[15:59] <mok0> hyperair: it won't compile under intrepid
[16:00] <mok0> hyperair: but what does it require from banshee?
[16:00] <hyperair> mok0: the pkg-config file
[16:00] <hyperair> /usr/lib/pkg-config/bansheesomething.pc
[16:00] <mok0> hyperair: oh, that's probably in banshee-dev or something
[16:01] <hyperair> banshee-1-thickclient
[16:01] <hyperair> there isn't a banshee-dev
[16:01] <mok0> hyperair: right, so you builddepend on that?
[16:01] <hyperair> yep
[16:01] <hyperair> 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] <hyperair> so how would i fix that?
[16:02] <mok0> hyperair: your package should be for jaunty
[16:02] <hyperair> alright, so i just don't care?
[16:02] <mok0> right
[16:02] <hyperair> or should i put mono-devel | mono-gmcs?
[16:02] <mok0> hyperair: it can be changed if there's ever a backport
[16:02] <hyperair> perhaps mono-gmcs (<something)
[16:03] <hyperair> oh
[16:03] <hyperair> okay
[16:03] <hyperair> i'll make my next upload then
[16:04]  * mok0 goes to get some coffee...
[16:16] <hyperair> mok0: new upload. could you review that please?
[16:22] <mok0> ok
[16:26] <mok0> hyperair: is it correct that  banshee-extension-lyrics
[16:26] <mok0> has arch "all" and not "any" ?
[16:26] <hyperair> well
[16:26] <hyperair> -cil generally has arch all
[16:26] <hyperair> i tink
[16:26] <hyperair> think*
[16:26] <hyperair> mok0: there's actually a deb for amd64 that works on intrepid..
[16:26] <hyperair> arch all
[16:27] <hyperair> http://launchpad.net/~banshee-team/+archive
[16:27] <mok0> hyperair: ... because mono creates bytecode for all archs?
[16:27] <hyperair> yeah
[16:27] <mok0> ok, so it's like java
[16:27] <hyperair> yep
[16:27] <hyperair> in fact, you can take bytecode compiled on windows and run it on linux
[16:28] <hyperair> also gnome-sharp2 has arch=all
[16:28] <mok0> yes I know it's pretty cool
[16:28] <hyperair> not that i like mono =p
[16:28] <hyperair> or C#
[16:28] <mok0> I'm a sceptic too
[16:28] <hyperair> hahah
[16:29] <hyperair> 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] <mok0> hyperair: I still get those missing dependencies of banshee
[16:31] <hyperair> meh damnit
[16:31] <hyperair> pbuilder doesn't have any trouble
[16:32] <mok0> http://paste.ubuntu.com/105958/
[16:33] <hyperair> there has to be some conflict or other
[16:33] <hyperair> otherwise it would be installed
[16:34] <mok0> hyperair: could be that jaunty is broken somehow at the moment
[16:34] <hyperair> aah
[16:34] <hyperair> wait
[16:34] <hyperair> wait
[16:34] <hyperair> i think i might have a clue..
[16:34] <hyperair> i made it depend on libgconf2.0-cil
[16:35] <mok0> aha
[16:35] <hyperair> yep
[16:35] <hyperair> but why did it work on my pbuilder?
[16:35] <hyperair> strange
[16:35] <mok0> hyperair: I'll get rid of it
[16:35] <mok0> and try again
[16:36] <mok0> hyperair: probably the package set evolved since you last updated it
[16:37] <mok0> hyperair, here goes, it's doing something more
[16:38] <hyperair> okay
[16:38] <hyperair> actually, should i include libgconf2.24-cil or not? since banshee includes the dependency
[16:39] <mok0> hyperair: leave that dep to banshee
[16:39] <mok0> ah, crashed
[16:39] <mok0> with a stacktrace
[16:40] <mok0> hm
[16:40] <hyperair> meh
[16:40] <mok0> that's weird, it's trying to open a file in my home directory
[16:41] <mok0> hyperair: I'll pastebin it
[16:41] <hyperair> okay
[16:42] <hyperair> 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] <mok0> http://paste.ubuntu.com/105959/
[16:42] <mok0> no mine, look here
[16:42] <mok0> lines 4 and 6
[16:43] <mok0> and it's spooky, my cwd is /tmp
[16:44] <hyperair> your /home is /u?
[16:44] <mok0> hyperair: yes
[16:44] <hyperair> ah
[16:44] <hyperair> to save typing or what
[16:44] <mok0>  /u/mok
[16:44] <hyperair> i think you might have some stray env variable
[16:45] <hyperair> to do with .wapi
[16:45] <mok0> hyperair: I don't even know what that is
[16:45] <hyperair> wait, i've dealt with .wapi stuff before.. when packaging for archlinux
[16:46] <hyperair> you have a MONO_SHARED_DIR env variable set?
[16:46] <hyperair> archlinux packages generally have export MONO_SHARED_DIR=$(srcdir)/.wapi somewhere, and then rm -rf it after the build
[16:46] <mok0> no
[16:47] <hyperair> meh strange
[16:47] <hyperair> can you grep your env for .wapi then?
[16:47] <mok0> The only thing is HOME
[16:47] <hyperair> that refers to /u/mok you mean?
[16:48] <mok0> yes
[16:48] <mok0> there's nothing with .wapi in my env
[16:48] <hyperair> strange
[16:48] <hyperair> wait, i thought it didn't build in intrepid
[16:48] <hyperair> or do you have a home directory in sbuild
[16:49] <mok0> Well, the sbuild enviroment doesn't know about /u
[16:49] <hyperair> http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html
[16:50] <hyperair> hmm
[16:50] <hyperair> something about .wapi
[16:50] <mok0> which is nice because I don't want it to fool around with my personal stuff
[16:50] <hyperair> okay then
[16:50] <hyperair> it seems that i need to export MONO_SHARED_DIR
[16:50] <hyperair> and then remove it
[16:51] <mok0> I have a dir ~/.wapi but it's empty
[16:51] <mok0> Created 2008-08-19
[16:52] <mok0> In fact I'll get rid of it
[16:52] <hyperair> hmm i think i'll create one just to test
[16:53] <hyperair> hey wait there are files in mine
[16:53] <hyperair> i think i'll just clear it and leave it empty then try building in a non-chroot env
[16:53] <mok0> ok
[16:54] <hyperair> uh damn that doesn't work.
[16:54] <hyperair> i'm on intrpied
[16:54] <hyperair> intrepid*
[16:55] <hyperair> how very strange. i don't get errors
[16:55]  * mok0 is even more convinced that mono is evil
[16:57] <hyperair> still no errors
[16:57] <mok0> 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] <hyperair> lol!
[16:57] <mok0> heh
[16:58] <hyperair> i'm uploading another one with the whole .wapi thing fixed
[16:58] <mok0> hyperair: what did you do?
[16:58] <hyperair> export MONO_SHARED_DIR=$(CURDIR)
[16:58] <hyperair> near the top of debian/rules
[16:58]  * mok0 , your friendly neighborhood buildd
[16:59] <hyperair> hahah
[16:59] <mok0> hyperair: you have a ppa?
[17:00] <hyperair> mok0: yes i do
[17:00] <hyperair> several
[17:00] <hyperair> under different teams of course
[17:00] <mok0> you might try to upload it there to test build... just add ~ppa1 to the version
[17:02] <hyperair> yeah i could
[17:02] <hyperair> it'd have reached ppa20 by now =p
[17:02] <mok0> hyperair: ah. remember to remove that libgconf-cil dep next upload
[17:02] <mok0> wow
[17:02] <hyperair> done
[17:10] <mok0> The build succeeded now!
[17:10] <mok0> although, you may need to add "libtool" to the build deps
[17:12] <cody-somerville> mok0, don't we have pbuilder for test building? ;]
[17:13] <mok0> cody-somerville: heh, well pbuilder is more tolerant that buildd
[17:13] <mok0> cody-somerville: and in this instance, the build succeeds in pbuilder but fails in sbuild
[17:16] <mok0> hyperair, are you in contact with upstream of this plugin?
[17:17] <nellery> 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] <mok0> nellery: no
[17:19] <nellery> mok0: so it should be completely repackaged from scratch
[17:19] <mok0> nellery: of course you can take over the files in debian/
[17:19] <mok0> nellery: ... and upstream should be persuaded not to ship the debian/ dir
[17:20] <nellery> mok0: okay
[17:20] <nellery> thanks
[17:20] <cody-somerville> mok0, neat :)
[17:20] <cody-somerville> mok0, We should document those cases
[17:20] <mok0> cody-somerville: yes I guess
[17:20] <hyperair> mok0: if upstream actually listened, i wouldn't have put in autoreconf
[17:21] <hyperair> and we'd have a clean tarball
[17:21] <mok0> heh
[17:21] <mok0> upstream authors rarely know what is required to distribute software
[17:22] <savvas> that's easy, a maintainer!
[17:22] <savvas> :P
[17:22] <anakron> hi all!
[17:22] <hyperair> mok0: well... banshee did a pretty good job
[17:22] <mok0> savvas: heh, exactly, but they should listen to that maintainer
[17:23] <mok0> Of course some upstreams also maintain their software in Debian/Ubuntu
[17:24] <mok0> hyperair: Banshee package is maintained by upstream?
[17:24] <ScottK> \o
[17:24] <mok0> heya ScottK
[17:24] <ScottK> Heya
[17:24] <ScottK> That was me raising my hand about being an upstream who maintains stuff in Debian/Ubuntu
[17:25] <hyperair> mok0: what?
[17:25] <mok0> hyperair: you said banshee did a pretty good job
[17:25] <hyperair> ah
[17:25] <hyperair> sebastian droge packaged it
[17:25] <mok0> I see
[17:25] <ScottK> What Java thing do I need to install for Firefox to believe it has Java support?
[17:25] <hyperair> i think he's got commit rights to banshee heh
[17:26]  * ScottK never needed Java for anything before today.
[17:26] <hyperair> ScottK: sun-java6-plugin i think
[17:26] <ScottK> Thanks.
[17:26] <mok0> ScottK: isn't that handled by depends?
[17:26]  * ScottK tries
[17:26] <ScottK> mok0: No, Firefox works great with no Java.
[17:26] <ScottK> It's not a depends.
[17:26] <hyperair> yeah it does
[17:27] <hyperair> i use it because my bank requires java in order to log into their web interface
[17:27] <hyperair> pah
[17:27] <hyperair> mok0: uploaded another time, this time with libtool
[17:27] <Chris`> I use Java for FireGPG :-/, any reviewers free today btw? :)
[17:28] <hyperair> Chris`: firegpg needs java?
[17:28] <Chris`> hyperair: Yeah to clearsign messages
[17:28] <hyperair> strange i thought it didn't need anything
[17:28] <hyperair> other than gpg of course
[17:28] <ScottK> hyperair: That was it.  Thanks.
[17:29] <hyperair> well firegpg sucks anyway. it failed verification of about every clearsigned message on launchpad.net
[17:29] <Chris`> I've only just got into using it
[17:29] <hyperair> heh. have fun
[17:29] <hyperair> ScottK: you're welcome
[17:30] <mok0> hyperair: you think you could persuade upstream to put gpg clauses in the source files?
[17:30] <hyperair> mok0: i wouldn't bet on it.
[17:30] <mok0> hyperair: it's no blocker, but FSF recommends it
[17:30] <hyperair> mok0: i came up with a patch to fix the build system, but upstream didn't reply
[17:31] <mok0> hyperair: It's pretty fast to do with a script, perhaps you can send upstream a patch?
[17:32] <hyperair> mok0: got an example of a script? i've never managed to script something like that
[17:32] <mok0> hyperair: Hmm. I think somewhere, I'd have to browse around
[17:32] <hyperair> unless you mean ( echo "copyright header"; cat file; ) > file.tmp; mv file{.tmp,}?
[17:33] <mok0> hyperair: that's what I had in mind, yes, something like that
[17:33] <hyperair> it seems he's got his own headers
[17:33] <hyperair> =\
[17:33] <hyperair> i wonder if the copyright clause should go above or below
[17:33] <mok0> hyperair: that depends on how anal upstream is about his code :-)
[17:34] <hyperair> heh
[17:34] <hyperair> i wonder.
[17:34] <mok0> hyperair: I used to have an $Id: line at the very top, but I don't use it anymore because I've converted to git for VCS
[17:35] <mok0> hyperair: however, it is actually meaningful to have it in every file, given that people can grab just one source file and use it in their own project
[17:35] <hyperair> what's $Id for?
[17:36] <mok0> hyperair: oh, it's a macro that gets expanded by svn and CVS
[17:36] <mok0> hyperair: with version, file path and stuff like that
[17:36] <hyperair> into what?
[17:36] <hyperair> oh
[17:36] <hyperair> i see
[17:37] <hyperair> so why doesn't git need something like that?
[17:37] <mok0> hyperair: but it works poorly with merges
[17:37] <hyperair> heheh. svn sucks for merging
[17:37] <hyperair> i like bzr
[17:37] <Nafallo> \o/ BAZAAR \o/
[17:37] <mok0> hyperair: because git is designed to work with any type of file, and it does not touch them.
[17:38] <mok0> Nafallo: Hm, I prefer git, bzr is pretty clunky in comparison IMHO
[17:38] <hyperair> mok0: but if you don't put the macro then svn won't touch the files will it?
[17:38] <hyperair> mok0: what's wrong with bzr?
[17:38] <hyperair> i should go learn git heh
[17:38] <mok0> hyperair: yes, that's right. In fact, you have to specifically turn on the feature in svn, on a per-file basis
[17:39] <mok0> but CVS would just go ahead and replace every $Id: it finds
[17:39] <Nafallo> mok0: to be fair, I don't really care what others use. I love bazaar myself :-)
[17:39] <hyperair> ah
[17:39] <hyperair> Nafallo: hear hear
[17:39] <hyperair> Nafallo: it's a little hard to find a bazaar hosting server though
[17:39] <hyperair> apart from launchpad
[17:39] <hyperair> and launchpad sucks if you're in asia
[17:40] <hyperair> slow as hell, and connection keeps breaking
[17:40] <Nafallo> hyperair: I was about to say launchpad.net is quite easy to find... ;-)
[17:40] <hyperair> last time i pushed something, i had to keep running break-lock
[17:40] <hyperair> Nafallo: you see a few for svn and cvs and git, but none for bzr other than launchpad
[17:40] <Nafallo> hyperair: not that hard to set up your own bazaar box either.
[17:41] <Nafallo> trac works with bazaar... what's the issue? :-)
[17:41] <hyperair> Nafallo: but i'd like to have it hosted so that others can branch it
[17:41] <hyperair> and work on it
[17:41] <hyperair> and so on
[17:41] <Nafallo> hyperair: yes?
[17:41] <hyperair> trac? isn't that something you install on some server?
[17:41] <hyperair> as in not hosted elsewhere?
[17:41] <spod-> hi, is there a gdb package which is compiled with thread debugging enabled?
[17:42] <hyperair> spod-: i thought gdb has thread debugging enabled by default
[17:42] <Nafallo> hyperair: as I said. not hard to put up your own servers...
[17:43] <hyperair> Nafallo: i don't have any computer i can leave on 24/7
[17:43] <Nafallo> anyway. shower.
[17:44] <hyperair> no wait, actually i'm supposed to be setting up a project management server for a club i'm in, but besides port 80 i don't have anything else, and getting a subdomain seems to be hell
[17:44] <spod-> excuse the multiline - i get:
[17:44] <spod-> (gdb) info threads
[17:44] <spod-> (gdb) thread 1
[17:44] <spod-> Thread ID 1 not known.
[17:44] <spod-> (gdb)
[17:45] <mok0> hyperair: I think most stuff runs on port 80 just fine
[17:46] <mok0> hyperair: I know git works fine
[17:46] <hyperair> mok0: i haven't heard of pushing bzr through port 80
[17:46] <mok0> hm
[17:46] <hyperair> mok0: also, that particular port 80 doesn't really belong to me either.
[17:47] <hyperair> mok0: there's a server set up... and i just hooked up my two servers behind that one
[17:47] <mok0> hyperair: you don't control the server?
[17:47] <hyperair> one is an ubuntu mirror
[17:47] <hyperair> archives mirror
[17:47] <hyperair> i don't control the main one
[17:47] <hyperair> that one belongs to the lab
[17:48] <hyperair> one more is the project management server i'm supposed to be setting up
[17:48] <hyperair> basically if you connect to the main server using a certain hostname, the request is forwarded to one of the servers bhind it
[17:48] <hyperair> so you can't access it without modifying your /etc/hosts file
[17:49] <mok0> hyperair: isn't that good enough?
[17:49] <hyperair> mok0: do you want everybody who wants to access the website of your project to have to modify their /etc/hosts file?
[17:49] <mok0> hyperair: it means the client from the outside speaks directly to a web server you control, it sounds like
[17:50] <mok0> hyperair: so the hostname is not in DNS?
[17:50] <hyperair> client -> main server (i don't control this) port 80 -> one of the server's port 80 depending on hostname
[17:50] <hyperair> no the hostname isn't in dns
[17:51] <hyperair> meaning i can't register the archives mirror yet either
[17:51] <mok0> hyperair: looks like that sysadm's got you by the balls
[17:51] <hyperair> and it requires very specific configuration to get working
[17:51] <hyperair> mok0: it's a campus thing.
[17:51] <mok0> hyperair: if the project is official then you need to get that fixed
[17:51] <hyperair> mok0: the lab owns the server, and they have a domain name.
[17:52] <hyperair> mok0: i need to get a domain name from the centre for it services
[17:52] <hyperair> and they're idiots who love microsoft
[17:52] <hyperair> basically i just need an alias
[17:52] <hyperair> alias for the domain name that's already there
[17:52] <mok0> yes
[17:52] <hyperair> i could of course.. sign up for some dynamic dns service
[17:52] <mok0> hyperair: so they forward traffic for your domain
[17:53] <hyperair> yes
[17:53] <hyperair> i did the configuration for the main server regarding that
[17:53] <mok0> hyperair: your server is behind a firewall I guess
[17:54] <hyperair> my server accesses the internet from behind the main server
[17:54] <mok0> hyperair: but through a firewall or dmz that you don't control?
[17:55] <hyperair> the main server acts as that particular lab's server, as well as a NAT-enabled router (i added this), and i modified their apache configuration to forward requests made to certain hostnames
[17:55] <hyperair> the main server is behind a firewall i don't control
[17:55] <mok0> hyperair: It sounds like you know much more about this than I do
[17:56] <hyperair> basically i made the configuration in that manner (forward requests based on hostname) so that i don't have to attempt to convince the sysadmins to modify their firewall
[17:56] <mok0> hyperair: I only know that not being directly on the internet sucks :-)
[17:56] <hyperair> mok0: all that i know comes from google-fu
[17:57] <hyperair> ;)
[17:57] <mok0> hyperair: perhaps you could get server space somewhere else for your project
[17:57] <hyperair> nowhere else hosts bzr
[17:57] <hyperair> other than launchpad
[17:57] <hyperair> so i was actually looking into using bzr-svn
[17:57] <hyperair> and then using sourceforge or google code
[17:57] <broonie> Debian's alioth service hosts bzr too.
[17:58] <hyperair> alioth eh?
[17:58] <hyperair> i'll take a look into that one
[17:58] <hyperair> does it have a server anywhere remotely near asia?
[17:58] <Nafallo> bzr.gnome.org :-)
[17:59] <broonie> not particularly
[18:00] <mok0> couldn't you set up a bzr hosting locally?
[18:01] <hyperair> mok0: yes of course. but i don't have a computer that i can leave on 24/7
[18:02] <hyperair> mok0: and my home internet connection sucks.
[18:03] <hyperair> think 30kB/s maximum upstream rate (from the server's point of view), and that's in-country.
[18:04] <hyperair> Nafallo: then i'd have to register as a gnome project =p
[18:05] <Nafallo> hyperair: ...and the server is in London
[18:05] <hyperair> hahah
[18:06] <hyperair> yes i've got issues checking out files from svn.gnome.org
[18:06] <Nafallo> that one is hosted in north sweden iirc
[18:07] <hyperair> oh
[18:07] <Nafallo> lol! faik
[18:07] <Nafallo> it's in London as well ;-)
[18:07] <Nafallo> cvs.g.o was in Sweden I'm pretty sure :-)
[18:08] <Nafallo> meeh. I don't get anything right today :-)
[18:08] <Nafallo> cvs.g.o is not in Sweden :-)
[18:08] <Nafallo> ah! ftp.gnome.org is in Sweden :-)
[18:09] <hyperair> lol
[18:10] <hyperair> mok0: regarding bansheelyricsplugin, other than the license clause, is there anything else before it can get approved?
[18:20] <nhandler> Anyone feel like helping me debug a pbuilder problem in intrepid?
[18:22] <DktrKranz> nhandler, which kind of problem?
[18:23] <nhandler> DktrKranz: I can create a sid and intrepid pbuilder in intrepid (with backports enabled), but I can't create a jaunty pbuilder. It always says can't resolve archive.ubuntu.com (I have tried with other mirrors and gotten the same type of error)
[18:23] <DktrKranz> nhandler, is debootstrap up-to-date with latest jaunty?
[18:23] <mok0> hyperair: look at my comments. Almost ready
[18:24] <hyperair> mok0: thanks for the review. actually the tarball was repackaged using uscan --repackage
[18:24] <hyperair> mok0: also, the latest version matches 1.0
[18:24] <hyperair> not 0.6
[18:24] <hyperair> how do i fix that?
[18:24] <DktrKranz> I've seen some problems if just symlinked with i.e. intrepid
[18:24] <hyperair> 0.6 is after 1.0, as stupid as that sounds
[18:24] <mok0> hyperair: I get "Bin"
[18:24] <hyperair> ah right
[18:24] <hyperair> i forgot to make that change
[18:24] <hyperair> but assuming i make it match only numbers and dots
[18:24] <hyperair> then i'd get 1.0
[18:25] <nhandler> DktrKranz: 1.0.10ubuntu1~intrepid1
[18:25] <lfaraone> Hi, I'm trying to get into MOTU and I'm wondering if there is any low-hanging fruit to be fixed.
[18:25] <nhandler> DktrKranz: 1.0.10ubuntu2 is in jaunty
[18:25] <mok0> hyperair: perhaps you can use some of the mangling rules?
[18:25] <mok0> hyperair: what is the version system this upstream is using? Is he counting backwards from 1.0 :-P
[18:26] <nhandler> !harvest | lfaraone
[18:26] <hyperair> mok0: god knows. at first he was following banshee's version, then he suddenly came up with a release "0.6"
[18:26] <DktrKranz> nhandler, have you full pbuilder log available?
[18:26] <nhandler> lfaraone: I would check out harvest. It has a lot of low hanging fruit
[18:26] <lfaraone> nhandler: hm?
[18:26] <mok0> ubottu: beer > mok0
[18:26] <lfaraone> nhandler: ok, thanks.
[18:26] <nhandler> lfaraone: Maybe someone can get you a link, my internet is slow right now
[18:26] <lfaraone> nhandler: python-low-hanging-fruit? :)
[18:26] <nhandler> DktrKranz: Yeah, one second
[18:26] <lfaraone> nhandler: understood
[18:28] <DktrKranz> nhandler, moving to dinner, back in twenty minutes
[18:28] <james_w> http://daniel.holba.ch/harvest
[18:28] <nhandler> Thanks james_w
[18:29] <mok0> Hm. Anyone here knows howto scroll from with screen?
[18:29] <hyperair> mok0: what mangling rules can i use?
[18:30] <nhandler> mok0: Easiest way is to enter copy mode
[18:30] <nhandler> mok0: Ctrl+a [
[18:30] <mok0> hyperair: you can run some substitutions etc. on the string that's fetched from the url, so I thought you could mangle 1.0 into something < 0.6
[18:31] <hyperair> mok0: that won't be very maintainable in the long term would it
[18:31] <hyperair> and how should i mangle 1.0 into lesst han 0.6?
[18:31] <mok0> hyperair: s/1.0/0.01/ ?
[18:31] <hyperair> hmm
[18:32] <mok0> hyperair: I know, it's a hack, but what systematics is upstream using?
[18:32] <hyperair> doesn't look like he's using any systematics
[18:32] <hyperair> he just dishes out a version when he feels like it
[18:32] <hyperair> or something
[18:32] <mok0> hyperair: can we trust his code I wonder :-O
[18:33] <hyperair> i'm using it, and there doesn't seem to be many bugs
[18:33] <hyperair> it's just an extension for banshee
[18:33] <hyperair> downloads stuff from lyricswiki and whatnot
[18:33] <mok0> j/k
[18:33] <hyperair> hahah
[18:33] <nhandler> DktrKranz: http://paste.ubuntu.com/105996/
[18:34] <mok0> hyperair: Perhaps you persuade upstream to be systematic about versions, now that his software is going into Ubuntu. He must be kinda pleased with that
[18:35] <savvas> anyone good with copyrights? what are my limits if I want to make a package with the atheros madwifi-hal license? http://svn.madwifi.org/madwifi/trunk/hal/COPYRIGHT
[18:36] <hyperair> mok0: i daresay that with 0.6 signifies that he's going to be using his own versions (probably incrementing?) as opposed to hooking onto banshee's versions
[18:37] <mok0> savvas: it looks like clause 1 prevents us from distributing
[18:38] <nhandler> DktrKranz: ~/.pbuilderrc http://paste.ubuntu.com/105998/
[18:38] <mok0> hyperair: I suggest you assume that, and just mangle the one file that doesn't fit that scheme... hopefully he wont re-use version 1.0
[18:38] <hyperair> heh yeah
[18:39] <mok0> hyperair: document it carefull in the watch file, because anyone looking at it will wonder
[18:39] <savvas> mok0: so I'm not allowed to compile and package it as a binary?
[18:40] <Laney> mok0: Wouldn't it be ok for multiverse? http://www.ubuntu.com/community/ubuntustory/licensing
[18:40] <mok0> savvas: well, for your own use, but otherwise not IMHO
[18:40] <hyperair> mok0: okay
[18:40] <mok0> savvas: that license basically says, if you find a bug, you're not allowed to fix it
[18:41] <savvas> meh
[18:41] <savvas> ok thanks :)
[18:41] <mok0> savvas: sorry :-(
[18:41] <savvas> looks like it's going to be an .sh script then :P
[18:42] <hyperair> mok0: okay, now i need to use get-orig-source to repack the tarball?
[18:42] <hyperair> mok0: can i just make get-orig-source do uscan --force-download --repack?
[18:42] <mok0> hyperair: yes, the idea is that you fetch the tarball with uscan and then run debian/rules get-orig-source to repackage it
[18:43] <hyperair> mok0: wait, that means that get-orig-source doesn't automatically download the tarball?
[18:43] <mok0> hyperair: right, the rule expects the downloaded bz2 thing to be there
[18:44] <mok0> hyperair: you might even provide a check :-P
[18:44] <hyperair> is there any documentation about this rule? i found this: https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball and it seems to imply that get-orig-source downloads the tarball
[18:44]  * mok0 looks forward to source package format 3.0 where orig.tar.bz2 is allowed...
[18:46] <fabrice_sp_> Hi. I've been disconnected, so I don't know if my request for review of dvdstyler has been received or not. Can someone tell me if it has been received or not?
[18:46] <fabrice_sp_> (in the channel)
[18:50] <mok0> fabrice_sp: I didn't see anything
[18:51] <fabrice_sp_> ok. So I'll repost it :-) Thanks
[18:52] <fabrice_sp_> Is there some reviewer willing to review dvdstyler? (http://revu.ubuntuwire.com/details.py?package=dvdstyler). It has already been advocated by mok0. Thanks!
[18:52] <DktrKranz> nhandler, I think that has been fixed in 1.0.10ubuntu2
[18:53] <DktrKranz> or at least it's a very similar issue
[19:01] <Quintasan> Hello, can I ask some questions regarding debuild here or in #ubuntu?
[19:04] <mok0> !ask | Quintasan
[19:07] <mok0> Quintasan: go ahead
[19:15] <Quintasan> After reading https://wiki.ubuntu.com/PackagingGuide/Basic I've tried to do the same for my program which is pretty simple (1 source file + Makefile) and upload it to ppa, however when using dput I get: "Checksum doesn't match for /home/quintasan/src/converter_1.0-1.dsc"
[19:17] <nellery> if a package does not contain a license, but mentions in the README that the package is released into the public domain, does that mean that it can be packaged?
[19:32] <hyperair> after removing .svn files from a source tarball, do i mangle the version to contain .repack or do i just leave it as .orig.tar.gz  (original was .tar.bz2)
[20:02] <Chris`> If upstream has released a tarball named 0.9.9 but they intend on making a 0.9.10 tarball next, should I rename to 0.9.09 in the control file?
[20:03] <Chris`> *changelog
[20:04] <nhandler> DktrKranz: So should I prepare a backport for 1.0.10ubuntu?
[20:04] <pmjdebruijn> Chris`: no
[20:05] <Chris`> pmjdebruijn: How will the updates work properly then?
[20:05] <pmjdebruijn> Chris`: huh
[20:05] <pmjdebruijn> Chris`: last time I checked 10 is bigger than 9
[20:05] <pmjdebruijn> Chris`: 9 isn't 90
[20:05] <Chris`> pmjdebruijn: Kinda messed up numerics but that is what apt recognises?
[20:06] <pmjdebruijn> Chris`: huh?
[20:06] <pmjdebruijn> Chris`: why would that be messed up
[20:06] <Chris`> 0.9 is bigger than 0.1
[20:06] <pmjdebruijn> Chris`: version numbers aren't floats
[20:06] <pmjdebruijn> Chris`: major.minor
[20:06] <pmjdebruijn> Chris`: the dot a seperator... not a numeric dot
[20:07] <pmjdebruijn> is a*
[20:07] <pmjdebruijn> Chris`: you fundamentally misunderstand version numbers :p
[20:07] <Chris`> Ah OK then, basically the same as a comma then?
[20:07] <pmjdebruijn> sortof
[20:07] <pmjdebruijn> Chris`: first major is checked, then minor
[20:07] <Chris`> Cool well that makes sense
[20:08] <pmjdebruijn> i've almost never found the need to renumber tarballs
[21:23] <slytherin> ScottK: on i386/amd64, icedtea6-plugin should work just fine if you are already using openjdk. For sun jdk use the respective plugins.
[22:10] <hyperair> could someone review my package please? http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[23:15] <spitfire> How to upload .orig file to PPA using dput?
[23:15] <spitfire> Or anything else?
[23:16] <nellery> spitfire: see https://help.launchpad.net/Packaging/PPA
[23:19] <spitfire> nellery: There is no explanation how to do it.
[23:19] <spitfire> I've read it.
[23:19] <spitfire> And they only mentioned it is possible.
[23:22] <nellery> spitfire: you don't upload the .orig
[23:22] <nellery> you must package it first
[23:23] <nellery> https://wiki.ubuntu.com/PackagingGuide
[23:23] <spitfire> nellery: but it isn't available in ubuntu
[23:23] <spitfire> I'm backporting it from debian.
[23:23] <spitfire> file libmtp_0.3.5.orig.tar.gz isn't available in ubuntu, nor launchpad.
[23:24] <nellery> do you mean using -sa when you build the package?
[23:24] <spitfire> And it is pinted, that i *CAN* upload it.
[23:24] <spitfire> nellery: here's what i did:
[23:24] <spitfire> apt-get source libmtp
[23:24] <spitfire> (got it from debian)
[23:24] <spitfire> dch -i -l ~ppa
[23:25] <spitfire> (added suffix)
[23:25] <spitfire> and dpkg-buildpackage -S
[23:25] <nellery> ahh
[23:25] <spitfire> and that's all.
[23:25] <nellery> use dpkg-buildpackage -S -sa
[23:25] <savvas> spitfire: debuild -S -sa
[23:25] <savvas> or that :p
[23:25] <spitfire> what does -sa?
[23:25] <savvas> #
[23:25] <savvas> alternative version of an existing package: debuild -S -sd
[23:25] <savvas> #
[23:25] <savvas> brand new package with no existing version in Ubuntu's repositories: debuild -S -sa
[23:26] <savvas> quoted from https://help.launchpad.net/Packaging/PPA
[23:26] <spitfire> oh.
[23:26] <spitfire> savvas: sorry, didn't understood/noticed
[23:26] <nellery> from the manpage
[23:26] <nellery> -sa    Forces the inclusion of the original source.
[23:26] <savvas> that's much clearer heh
[23:27] <nellery> sorry, misunderstood your question at first ;)
[23:35] <savvas> spitfire: if it has important changes and fixes, you could ask for a sync to update the package from debian for jaunty :)
[23:35] <spitfire> savvas: it has soem improvements, and is lot faster.
[23:36] <spitfire> But I don't think there are security issues.
[23:36] <spitfire> So isn't it hard to do such a bump after debianimportfreeze?
[23:37] <savvas> If you can give good reasons to do it, then I believe no-one would object to include it :)
[23:37] <spitfire> savvas: will do.
[23:38] <spitfire> what do I have to write in the topic for a version bump?
[23:38] <savvas> https://bugs.edge.launchpad.net/ubuntu/+source/libmtp/+bug/315679
[23:38] <savvas> I see that you already have :)
[23:38] <spitfire> savvas: oh, I forgot:P
[23:38] <spitfire> lol
[23:39] <savvas> hold a sec
[23:40] <spitfire> savvas: I've just included link to debian.
[23:42] <savvas> spitfire: change the bug subject to this: Please sync libmtp 0.3.0-1ubuntu3 (main) to 0.3.5-1 from Debian (experimental)
[23:43] <savvas> nellery: do you know if we have to subscribe someone else for a package sync?
[23:43] <spitfire> ok
[23:44] <savvas> spitfire: also change the description or add in a comment why do you believe it should be updated
[23:44] <spitfire> savvas:ok
[23:44] <nellery> subscribe ubuntu-universe-sponsors
[23:44] <nellery> once they confirm it
[23:44] <nellery> they will subscribe ubuntu-archive
[23:44] <savvas> er.. it's in main
[23:44] <savvas> ubuntu-main-sponsors then?
[23:45] <nellery> ah, yes
[23:45] <nellery> https://wiki.ubuntu.com/SyncRequestProcess
[23:45] <savvas> thanks :)
[23:48] <spitfire> savvas: I corrected one more, it is associated to the previous one: https://bugs.edge.launchpad.net/ubuntu/+source/mtpfs/+bug/301645
[23:51] <spitfire> But I bet both will get into in the next release cycle:/
[23:53] <savvas> spitfire: the dependencies are satisfied, I'll confirm it
[23:53] <spitfire> savvas: ?
[23:53] <savvas> and it looks that they've gone a long way with fixes and device support
[23:53] <spitfire> really?
[23:53] <spitfire> thanks.
[23:53] <savvas> spitfire: confirming means "someone else is interested in this too" :)
[23:53] <spitfire> I don't think I'll use jaunty anyway.
[23:54] <savvas> I'll subscribe the sponsors team and let's hope it gets fixed :)
[23:54] <spitfire> Not until intel graphics drivers get fixed/use GEM properly.
[23:54] <spitfire> Now I'm backporting everything possible to jaunty.
[23:54] <spitfire> *hardy.
[23:55] <spitfire> from jaunty/intrepid/deb-experimental.
[23:56] <savvas> well actually, if this gets in jaunty, after a while usually gets backported to the LTS release (hardy)
[23:57] <savvas> ok, sponsors added, have a good night!
[23:58] <coppro> OO.o 3 isn't in jaunty yet? :(
[23:59] <spitfire> savvas: could you also look at the second bug/bump request?
[23:59] <spitfire> It's associated with libmtp;)
[23:59] <spitfire> And it's transiston from SVN snapshot to a stable version.