[00:09] <crimsun> jcastro: are you guys blogging about -proposed availability?
[00:10] <jcastro> crimsun: I am not blogging about anything at the moment
[00:10] <crimsun> jcastro: e.g., "foo is available in gutsy-proposed; please test"?
[00:10] <jcastro> if you think I should, let me know
[00:10] <jcastro> I have no problems doing so
[00:10] <danbhfive> general question: if I have a new project, is there any chance of it making it into hardy at this point?  (I'm looking at the topic)
[00:10] <LaserJock> phomes (the gnome guy) suggested something like "Get the latest X two weeks before everybody else!" kind of thing
[00:11] <crimsun> the entire discussion in -devel, for me, boils down to:  1) not enough people are testing,  2) the distro is worried about accountability
[00:12] <crimsun> (1) is not easily resolved, but we can do a better job of getting word out there.
[00:12] <crimsun> (2) allow the release manager of each stable release, ~ubuntu-sru, and ~ubuntu-security to override SRU/security policy
[00:12] <crimsun> (heck, do we even have an active release manager for each stable release?)
[00:14] <tiagoboldt> what the hell do I do with a package after having it? I've created the package of libmtp-0.2.5, upgrading the existing 0.2.4-?ubuntu?
[00:14] <LaserJock> release managers,as far as i know, are only really responsible for the dev release
[00:14] <tiagoboldt> How do I get it into hardy?
[00:14] <crimsun> tiagoboldt: have you filed a bug using LP against the libmtp source package?
[00:15] <tiagoboldt> nop, so is it a bug not having the latest version packaged? :l
[00:15] <crimsun> tiagoboldt: attaching a debdiff against the Debian source package would be helpful.
[00:16] <crimsun> 0.2.5-1 is in Debian unstable.
[00:16] <tiagoboldt> documentation sucks :\ There could be a lot more of people helping if it was easier to know were to put what :\
[00:17] <tiagoboldt> hum, so I should port it, something like that, right?
[00:17] <tiagoboldt> Can anyone do that? Or should we respect the package maintainer?
[00:17] <crimsun> tiagoboldt: do you need someone to assist you in merging 0.2.5-1 from Debian unstable?
[00:17] <crimsun> anyone can do the work.
[00:18] <bddebian> Heya gang
[00:18] <geser> Hi bddebian
[00:18] <tiagoboldt> than I shall do it! Do I have to 'reserve' that job for me? so that no one else starts doing the same?
[00:18] <crimsun> tiagoboldt: just begin working on it
[00:19] <bddebian> Heya geser
[00:19] <tiagoboldt> Reading the motu pages on it, going to gather the script to use with MoM and start following the documentation :D
[00:20] <crimsun> tiagoboldt: ok.
[00:22] <rexbron> If you have got a spare moment, please take a look at openFX: http://revu.ubuntuwire.com/details.py?package=openfx
[00:26] <tiagoboldt> should I leave  -- Ubuntu Merge-o-Matic <mom@ubuntu.com> as the maintainer after a merge?
[00:26] <joejaxx> no
[00:26] <RAOF> tiagoboldt: No
[00:27] <joejaxx> you want to change that :D
[00:27] <tiagoboldt> that the script should go and get my debname and debmail (guess that's it) from bashrc, shouldn't it?
[00:27] <tiagoboldt> *than
[00:29] <joejaxx> that only happens with the initialization of a source directory to a debian package layout
[00:32] <tiagoboldt> so, I get all the stuff from mom, correct the conflicts, fill in the changelog and run merge-genchanges, thats it for the start?
[00:32] <RAOF> Not really.
[00:33] <RAOF> You really want to go over the previous Ubuntu changes and work out whether they're still necessary.
[00:34] <tiagoboldt> and if I'm unsure? :\ example: this one depends in ubuntu of udev, and in debian of something like {$udev}
[00:35] <RAOF> Then you might want to check out when that Ubuntu change was made, preferably finding the LP bug, and see whether the rationale still applies.
[00:36] <RAOF> If there *was* an LP bug you can see if the unchanged Debian package still exhibits that bug, and whether the Ubuntu change still fixes it.
[00:37] <tiagoboldt> got it, and, always, for every merge, create first a bug for the source I'm merging, right? So that I can close the bug with my merge, is that it?
[00:37] <RAOF> Yup.  That also tells other people not to merge the same package.
[00:38] <RAOF> Also you should add a comment on DaD that you're merging.
[00:38] <tiagoboldt> mom/dad what's what?
[00:39] <RAOF> MoM is the Merge-o-Matic.  DaD is an open-source alternative, with per-package comments.  It's annoying that there are 2 different Ubuntu mergers, but that annoyance is going away.
[00:40] <Lutin> real soon now ©
[00:40] <tiagoboldt> still, for now, I should be careful with both, I'll try that :D
[00:40] <tiagoboldt> is there any motu-school scheduled?
[00:41] <RAOF> tiagoboldt: If, at the end of it all, you don't understand an Ubuntu change, or whether or not you can drop it you should ask in here.
[00:41] <pochu> Lutin: MoM code is available now, isn't it? Will you add comments support to it?
[00:44] <Lutin> pochu: yeah. me or Adri2000 :)
[00:44] <Fujitsu> Wow, they released it?
[00:45] <ScottK> Fujitsu: Yes.
[01:35] <joejaxx> if there is a bug for the ubuntu kernel, is this one of the cases where a patch format other than a debdiff is better?
[01:35] <joejaxx> :)
[01:35] <crimsun> not necessarily.
[01:36] <crimsun> for the kernel, a git changeset or a URI to its upstream is sometimes more efficient
[01:36] <joejaxx> oh ok
[01:36] <zul> evening
[01:37] <crimsun> 'lo zul
[01:37] <joejaxx> hello zul :D
[01:37] <zul> how is it going crimsun and joejaxx
[01:37]  * joejaxx goes to install git
[01:37] <joejaxx> it is going well
[01:38] <joejaxx> the reason i ask is because of Bug #162090
[01:38] <ubotu> Launchpad bug 162090 in linux-source-2.6.22 "appletouch does not recognize trackpad in macbook3,1" [Undecided,Confirmed] https://launchpad.net/bugs/162090
[01:38] <joejaxx> the patch on there is only for the gutsy kernel
[01:39] <zul> have you checked to see if this patch has been added upstream?
[01:40] <joejaxx> going to do that now :)
[01:40] <zul> because it probably wont get applied to the gutsy kernel now
[01:41] <joejaxx> yeah :) i am talking about the hardy kernel :D
[01:47] <joejaxx> nope it looks like it is not in upstream yet
[01:48]  * joejaxx is waiting for git clone to finish
[01:49] <RAOF> Heh.  That'll take *some time* :)
[01:49] <joejaxx> yeah
[01:49] <joejaxx> 57% down indexing
[01:49] <joejaxx> s/down/done/g
[01:49] <joejaxx> i should have ran that process on here
[01:51] <zul> joejaxx: easier to use the web interface
[01:51] <joejaxx> web interface?
[01:52] <joejaxx> you mean kernel.ubuntu.com?
[01:52] <joejaxx> if so i do not have access to that :P
[01:52] <RAOF> Darn.  virt-manager doesn't seem to have an interface to "qemu -snapshot".
[01:52] <crimsun>  /git/
[01:52] <zul> http://kernel.ubuntu.com/git
[01:52] <crimsun> it'll redirect you to the proper gitweb
[01:53] <joejaxx> yeah i do not have access to that
[01:53] <joejaxx> :P
[01:53] <joejaxx> RAOF: interesting
[01:53] <joejaxx> zul: unless i misunderstood your suggestion :)
[01:54] <zul> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
[01:54] <crimsun> (i.e., it's just a Web frontend ala git.kernel.org)
[01:55] <joejaxx> yeah :P  how would that help me create a commit diff?
[01:55] <joejaxx> :P
[01:55] <joejaxx> all done
[01:57] <imbrandon> zul: how goes fatx?
[01:57] <imbrandon> heh
[01:57] <joejaxx> :)
[02:22] <nxvl_work> is there any HowTo on updating packages?
[02:22] <nxvl_work> not merging, but updating
[02:23] <nxvl_work> never mind, found it
[02:27] <joejaxx> https://people.fluxbuntu.org/~joejaxx/ubuntu/patches/bug162090.patch :D git diff HEAD ftw
[02:29] <emgent> night *
[02:30] <joejaxx> emgent: Goodnight
[03:02] <joejaxx> zul: you still around? :D
[03:15] <tritium> Anyone from the python team here?
[03:16] <jdong> vorian: ktorrent 3.0~rc1 uploaded, I mangled your interdiff a bit, added the epoch and made rules do 3.0~rc1 or ~beta1 instead of stringing them together
[03:16] <jdong> vorian: otherwise 3.0rc1 > 3.0, which will suck when they finally release :D
[03:18] <ScottK> tritium: What do you need?
[03:19] <jdong> vorian: dget it when it shows up, I am submitting that for most absurd watchfile regex award :D
[03:19] <tritium> ScottK: was curious about using python-scipy.  It wants to install python2.4.
[03:20] <tritium> ScottK: Was it not updated for 2.5?
[03:20] <ScottK> I thought it was.
[03:20] <ScottK> tritium: Which release are you on?
[03:20] <tritium> ScottK: gutsy
[03:21]  * ScottK looks
[03:23] <ScottK2> If I start python and import scipy, it works (that's with 2.5).
[03:23] <ScottK2> tritium: ^^^
[03:24] <tritium> ScottK: okay, so at least it works.  Any idea why it pulls in 2.4?
[03:24] <tritium> Thanks for looking into it, ScottK.
[03:25] <ScottK2> What do you mean pulls in 2.4?  Do you mean requires 2.4 to be installed?
[03:25] <tritium> ScottK2: yes, installing python-scipy results in python2.4 also being installed.
[03:26] <ScottK2> tritium: It installs bit that are python2.4/2.5 specific, so it does properly depend on both of them.
[03:26] <ScottK2> tritium: This is a needed part of support for multiple python version.  python-scipy isn't at all unusual in this regard.
[03:26] <tritium> ScottK2: okay, fair enough.  Thank you.
[03:26] <ScottK2> tritium: Also, the "python" team on LP doesn't appear to actually do anything.
[03:27] <tritium> Is that so?  Well, I appreciate your reply.  Thanks again.
[03:27] <ScottK2> No problem.
[03:36] <nxvl_work> to have a package on gnome-default-applications it must be done on the package or on the source?
[03:52] <mcisbackuk> Don't know if this is a bug or not, but just upgraded using 'sudo update-manager -d', yes I had problems, but they're sorted, but the desktop background is the elephant theme, keeping the brown/orange Ubuntu look, so why are the titlebars blue?
[03:54] <mcisbackuk> Does anyone else have this?
[04:15] <eddyMul> must package.orig.tar.gz have 1 "toplevel" directory?
[04:28] <LaserJock> eddyMul: that is the convention yes. it should be <packagename>-<version>
[04:28] <eddyMul> LaserJock: so, dpkg-source will unpack 1 extra level?
[04:28] <LaserJock> ?
[04:29] <LaserJock> what do you mean by "1 extra level"
[04:29] <eddyMul> LaserJock: I'm looking at phpmyadmin's source
[04:30] <eddyMul> LaserJock: phpmyadmin_$${version}.orig.tar.gz has a phpmyadmin-${extra-string}-$${version}/ folder in it
[04:31] <eddyMul> LaserJock: but `apt-get source phpmyadmin` unpacks stuff into phpmyadmin-$${version}/ folder
[04:31] <eddyMul> LaserJock: so, somehow dpkg-source unpacks the orig.tar.gz, and does some renaming?
[04:31] <LaserJock> ah
[04:31] <LaserJock> I see
[04:32] <eddyMul> LaserJock: do I understand dpkg-source's behavior correctly?
[04:33] <LaserJock> I believe so, the convention is <packagename>-<version>/ so dpkg-source handles that
[04:34] <eddyMul> LaserJock: I see.
[04:35] <eddyMul> LaserJock: my orig.tar.gz so far doesn't have a "toplevel" directory, but `pbuilder` didn't seem to complain so far. Of course, I've never tested it by installing it.....   :p
[04:35] <eddyMul> LaserJock: thanx for the clarification
[04:35] <minghua> dpkg-source treats tarball with single directory and tarball with multiple directories/files differently.
[04:36] <eddyMul> minghua: I see
[04:41] <AnAnt> persia: Hello
[06:19] <RAOF> When reviewing, how much do we care about missing watchfiles?
[06:19] <RAOF> s/do/should/
[06:19] <LaserJock> hmm, depends on who you ask I'd think
[06:20] <RAOF> Fair enough.
[06:20] <LaserJock> I think persia's on a watch file crusade so I think he'd tell you to care :-)
[06:20] <LaserJock> I personally think they should be included, but wouldn't necessarily not advocate soley on that
[06:21] <RAOF> I don't think I'll care too much, since upstream appears to be gnome-look, and it looks extremely difficult to scrape the right info off it.
[06:21] <LaserJock> I'd probably go ahead and advocate but tell the packager to either add a watchfile or get-orig-source rule as soon as they can
[06:22] <LaserJock> at this point we we need to get stuff in the archive, we can fix bugs (like watch files) later
[06:23] <RAOF> Well, this package has a bunch of other stuff broken with it anyway.
[06:23] <LaserJock> ah
[06:23] <LaserJock> well then I'd add a watch file/get-orig-source  to the list then
[06:23] <RAOF> Especially since it's a (kinda) repack.
[06:24] <LaserJock> oh yeah, then a get-orig-source sounds like a good thing to add
[06:24] <Fujitsu> watch files are good. I'd reject on the absence of one without good reason.
[06:24] <RAOF> It looks like upstream needs a good kicking though.
[06:25] <LaserJock> I personally wouldn't reject if that was it but I'd want the packager to say they will add one as soon as they can
[06:25] <RAOF> (They distribute a tar.bz2 containing a tar.gz containing the source and another tar.bz2 containing the gtkrc themes)
[06:25] <LaserJock> but as long as there's other stuff then yeah
[06:25] <LaserJock> nifty :/
[06:25] <RAOF> Gah!  Copyright headers are the bane of my existance.
[06:25] <LaserJock> hehe ;-)
[06:26] <RAOF> Let's see if I can break revu with an over-long comment again!
[06:26] <LaserJock> I'm currently trying to figure out how the licensing works on a package that seems to have both gpl and Apple something licensed parts
[06:27] <LaserJock> I guess it can work in the same way as say Java and a GPL Java app
[06:27] <RAOF> I need to work out whether I need to kill openssl-linkage for the shiny new "let's include yet another libtorrent in our source tarball" miro.
[06:27]  * LaserJock scratches his head a little
[06:27] <minghua> Fujitsu: Does "upstream uses sourceforge" count as a good reason for you?
[06:27] <LaserJock> I wouldn't think so
[06:27] <RAOF> minghua: Isn't there the special sauce for sourceforge in newer debhelper?
[06:28]  * minghua wonders if it makes sense to use Debian's QA sourceforge redirect URL in a Ubuntu-only package.
[06:28] <LaserJock> watch files work with sourceforge
[06:28] <LaserJock> minghua: why not? :-)
[06:28] <minghua> RAOF: Yes there is, probably not in debhelper though.
[06:28] <minghua> LaserJock: External reliance?
[06:29]  * RAOF isn't sure where he got that meme from.  I thought it was man uscan, but it aint.
[06:29] <LaserJock> minghua: we kinda shoot that ever release ;-)
[06:30] <LaserJock> given that the vast majority of our packages rely on Debian
[06:30] <LaserJock> but I get your point
[06:32] <minghua> LaserJock: Yeah, I was half-kidding.  Not objection of using Debian services, just some strange feeling.
[06:32] <minghua> s/objection of/objection against/, I suppose...
[06:38] <AnAnt> persia: Hello
[06:58] <RAOF> Now that I've reviewed the aurora gtk2 engine package, any kindly DD care to help me close the gtk2-engines-nodoka ITP? :)
[07:17] <geser> good morning
[07:20] <wallyweek> hey geser!
[07:23] <RAOF> Joy.  Miro embeds deluge-torrent which embeds a libtorrent.
[07:26] <RAOF> Here's one for those with more copyright patience than me: Miro is GPLv2.  The libtorrent it includes links to openssl.  The only mention of openssl in any copyright statement is "the copyright holders give permission to link the code of portions of this program with the OpenSSL library", in the build script.
[07:27] <RAOF> The question is: "is it time to patch out the linking to openssl?"
[07:30]  * Fujitsu thinks it probably is.
[07:30] <minghua> Sounds like so.
[07:31] <RAOF> Let's get a patching!
[07:31]  * minghua reads the situation as "it is fine to link libtorrent against openssl, it is not to link Miro against openssl".
[07:32] <RAOF> And linking is transitive.
[07:32] <minghua> I'm talking about distributing compiled binary, of course.
[07:32] <RAOF> Yes.
[07:32] <LaserJock> minghua: ah good point, I was kinda wondering why the statement wouldn't suffice, but that makes sense
[07:33] <minghua> LaserJock: Yeah.  Basically, you need a more permissive license than GPL to link to OpenSSL.
[07:33] <minghua> Special exception is one case of the "more permissive".
[07:34]  * minghua also thinks Miro upstream needs to be hit by some licensing cluebat.
[07:34] <RAOF> So, to make it clearer upstream would want to add the exception to *all* their licensing headers, right?
[07:34] <minghua> I'll bet they distribute binary Miro themselves, too.
[07:34] <RAOF> Oh, hell yes.
[07:35] <RAOF> And I get nice bug reports for it on launchpad :(
[07:35] <minghua> Such is life of package maintainers. :-)
[07:35] <RAOF> Indeed.
[07:36]  * wallyweek is not away
[07:41] <RAOF> I hope deluge has decided to link against a system libtorrent.
[07:41] <Fujitsu> RAOF: Knowing them, I doubt it.
[07:41] <RAOF> Well, browsing the _Miro_ source, there's a note from deluge saying "We really should link against a system libtorrent"
[07:42] <RAOF> I hate it when A includes the source for B (which includes the source for C).
[07:43]  * Fujitsu looks at a lot of Java apps.
[07:44] <minghua> Yeah, and Java apps include .jars, which is essentially compiled binary stuff, AFAIK?
[07:44] <RAOF> Yup.
[08:11] <RAOF> Whoops.  Accidentally adding "ll" to the top of a python script kills the build, would you believe?
[08:11] <Fujitsu> Nice one.
[08:12] <RAOF> I am nothing if not awesome.
[08:20] <warp10> Heya all
[08:20] <RAOF> Hi there.
[08:23] <vemon> if anyone has time for a little revu i have two packages hanging in the site: lashwrap & phasex
[08:23] <vemon> both are linux audio production apps or the like
[08:26] <RAOF> How many libboost packages will I need to add before miro builds >:(
[08:40] <vemon> RAOF, check the build error which tells you the missing header file and search for the package which contains the header file in packages.ubuntu.com
[08:40] <vemon> maybe you knew that already, but that's my two cents
[08:40] <RAOF> vemon: Oh, I know how to do that.  I've just done that 3 times now.
[08:41] <vemon> ok :) i just built a package which also required a few libboost deps
[08:43] <RAOF> Oh, arse.  Miro, your build system is rotten.
[08:45] <RAOF> Also, read the frikkin licenses of the source you blindly copy from other projects.  "All rights reserved" is unlikely to be GPL compatible!
[08:47] <RAOF> Alright!  More licensing fun!
[08:47] <RAOF> http://cooperteam.net/logger.cpp <- How GPL compatible is this?
[08:48] <dholbach> good morning
[08:48] <wallyweek> hey dholbach!
[08:48] <RAOF> Howdy dholbach.
[08:49] <dholbach> hey wallyweek, hey RAOF
[08:49] <warp10> morning dholbach!
[08:50] <RAOF> dholbach: Know any good "my package is doing crazy things with licences.  How can I tell if it's actually redistributable?" resources?
[08:50] <dholbach> RAOF: https://wiki.ubuntu.com/PackagingGuide/Basic#Copyright
[08:53] <geser> Hi dholbach
[08:53] <dholbach> hey geser
[08:55] <RAOF> dholbach: Ta, should've tried gnu.org :)
[08:56] <dholbach> RAOF: if you find good stuff feel free to add it to the guide
[08:59] <wallyweek> dholbach: could you please have a look at sdlmame? it should only need advocation after nearly 1 year of work :( http://revu.ubuntuwire.com/details.py?package=sdlmame
[09:00] <dholbach> wallyweek: I'll put it on my list, but I'm seriously busy catching up with stuff and not feeling well today - so your chances are better if you ask everybody in the channel
[09:02] <wallyweek> dholbach: ok, thanks. I'll advertise it again later
[09:10]  * wallyweek bumps
[09:23] <RAOF> Man, it's possible to write really *impenetrable* C++ if you try.
[09:23] <Fujitsu> RAOF: Miro devs have managed it?
[09:24] <RAOF> No, they write un-unittested python.
[09:24] <RAOF> But they've outsourced it to deluge, who've outsourced it to libtorrent.
[09:24] <RAOF> One of the libtorrents, that is.
[09:25] <Fujitsu> Ah, lovely.
[09:25] <RAOF> Hints for writing impenetrable C++: there's no shame in making your 3 page functions a single statement.  Just have your .def() function return *this, and chain them for 50 lines!
[09:26] <RAOF> Also: templates are your friends.  You should include at least one library that contains no .cpp files, just turing-complete templates.
[09:36] <yamal> keen eyed, well caffeinated reviewers wanted for http://revu.tauware.de/details.py?package=sabnzbdplus
[09:39] <RAOF> Hm.  Rather than not build the ssl stuff, it might be easier to make Miro link against gnutls instead.  Hm.
[09:51] <persia> yamal: You might want to loosen your conditions a little :)
[09:51] <yamal> persia: I'll stick with keen eyed and drop the narcotics, then :p
[09:55] <RAOF> How about grumpy, miro hating curmudgeons who'll make up spurious licensing problems because they're sick of trying to make Miro redistributable?
[09:58]  * yamal grabs english language dictionary to look up 'curmudgeons'
[10:03] <rexbron> Got a moment? Please take a look at openFX and get some karma (the general kind :P) http://revu.ubuntuwire.com/details.py?package=openfx
[10:38] <slytherin> persia: Please give me an advice. Should I fix the w3c-dtd-xhtml problem in Ubuntu? The debian bug sems to be getting nowhere.
[10:39]  * slytherin is impatient about this.
[10:39] <persia> slytherin: I'm inclined to say "just fix it", but I'm not certain about the side-effects of doing so.  Do you have a patch ready?  Can you show me a link?
[10:40] <slytherin> persia: I don't have a patch ready. I was planning to just add symlinks as to avoid any other problems.
[10:40] <man-di> slytherin: I'm currently working on an NMU with some XML maintainer
[10:40]  * persia defers to man-di
[10:40] <slytherin> man-di: Fine. Thanks for update. I will wait.
[10:41] <slytherin> persia: pm?
[10:46] <wallyweek> could anyone please review sdlmame? come on, it should only need advocation! http://revu.ubuntuwire.com/details.py?package=sdlmame
[11:10] <persia> blueyed: Congratulations!
[11:24] <slytherin> hi is it possible to have a wiki page which lists of MOTUs with special interest. So that when I have to solve a problem with a specific package (say a GTK+ program) I can consult the corresponding MOTU accordingly.
[11:36] <emgent> heya *
[11:40] <LucidFox> slytherin> Well, the wiki lists MOTU teams
[11:42] <persia> slytherin: MOTUs are encouraged to list their interests on their LP pages, but I don't know if everyone does this, nor if anyone scrapes this information for anything.  Generally it's better to ask this channel or the ML, rather than a specific person.
[11:44] <emgent> hi persia
[12:10]  * persia leaves REVU comments on vamp-plugin-sdk, gnubversion, phasex, lv2core, lashwrap, and openfx.  Packagers: please fix.  Other reviews expected soon...
[12:19]  * persia notes there are still four packages waiting for review that were skipped last week: http://revu.ubuntuwire.com/details.py?package=mumble http://revu.ubuntuwire.com/details.py?package=qdevelop http://revu.ubuntuwire.com/details.py?package=ssm http://revu.ubuntuwire.com/details.py?package=cvc3
[12:34] <slytherin> Hobbsee: Since you are the last person who commented on bug 146198 can you please take a look at it before feature freeze? (I hope you do)
[12:34] <ubotu> Launchpad bug 146198 in kopete "Add libjasper-runtime to 'Recommends'" [Undecided,Confirmed] https://launchpad.net/bugs/146198
[12:34] <persia> slytherin: You're more likely to see the fix if you submit a patch :)
[12:35] <persia> (and, yes, it's pointlessly trivial)
[12:35] <slytherin> persia: What I am not sure of is if it should be 'Recommends' or 'Depends'
[12:35] <minghua> libjasper is the JPEG2000 library, isn't it?
[12:36] <slytherin> minghua: yes
[12:36] <persia> slytherin: "Recommends" is when any normal person would want it installed.  "Depends" is when it breaks without it.  In this case, "Recommends" is likely more appropriate.
[12:36] <slytherin> persia: Ok.
[12:36] <persia> On the other hand, check the main/universe boundary: this may be more complicated than it appears.
[12:36]  * minghua thinks in this case libjasperX should recommend libjasper-runtime instead...
[12:37] <minghua> But what do I know about KDE land.
[12:37]  * persia hasn't really looked, and suspects minghua is correct
[12:38] <minghua> Does kopete depend on libjasper in Ubuntu?  It doesn't in Debian.
[12:38] <slytherin> persia: libjasper-runtime is in universe. :-(
[12:38] <slytherin> minghua: It does in gutsy. Not sure about hardy
[12:39] <persia> slytherin: That's why the MainInclusionReport was invented :)
[12:39] <minghua> libjasper1 only Suggests libjasper-runtime in Debian, BTW.
[12:41] <slytherin> minghua: last time I checked in gutsy, kopete showed me an error dialog that it needs libjasper-runtime for webcam functionality. Not sure if this would count as bad user experience.
[12:43]  * minghua considers such case perfect example for Recommends.
[12:43] <rexbron> persia: responded to comments on openFX, if you could clarify the points I raised?
[12:43] <minghua> However, it really depends on if Ubuntu installs recommends or not these days.
[12:43]  * persia advocates sdlmame, more from an inability to find any issues, rather than from an interest in expanding multiverse
[12:43] <persia> minghua: It will for hardy (even if it doesn't today).
[12:44] <man-di> Hobbsee: thx for sear
[12:44] <Hobbsee> man-di: you're welcome
[12:44] <minghua> persia: Good to hear.  Definitely a step on the right direction.
[12:47] <persia> rexbron: 1) I forget which package had the empty directory.  Run lintian or dpkg --contents foo.deb.  2) At least one binary package didn't contain /usr/share/doc/foo/copyright.gz (nor did /usr/share/doc/foo/ appear to be a symlink). 4) such is life.  Please request one (and it's not a blocking issue).  8) Assuming you dropped an 'e', because "debian/rules is not a shell script".
[12:50] <effie_jayx> hey all ... I have been trying to fix a bug and I get an error when I try to build the packaged. aparently some dependency has unmet dependencies... how can I go around it?
[12:51] <persia> effie_jayx: Fix the bug that keeps you from fixing the bug you want to fix, and then fix your bug :)
[12:51] <effie_jayx> persia,  right.
[12:51]  * effie_jayx has never fixed unmet deps :S.
[12:52] <effie_jayx> here goes nothing
[12:52] <slytherin> effie_jayx: What did you do the fix the bug? Any changes to configure/makefiles ?
[12:52] <persia> effie_jayx: It usually just needs a rebuild or small adjustment to build-depends or depends.  Should be fairly easy.  Good luck.
[12:52] <geser> effie_jayx: which unmet dep stops you?
[12:53] <effie_jayx> let me check
[12:53]  * slytherin is tired of lucene2 unit tests. They take too long even on a 2.6 GHz machine with 1 GB RAM.
[12:53] <minghua> effie_jayx: At least, make sure the unmet dep problem is reported to LP.
[12:54] <effie_jayx>  kdelibs4c2a depends on libarts1-dev (>= 1.5.0) and it does not install
[12:54] <persia> I thought we were tossing arts for hardy.  Is that not the case?
[12:55] <slytherin> effie_jayx: When did you do - sudo pbuilder update'?
[12:55] <minghua> That's probably going to be a hard one.
[12:55] <slytherin> effie_jayx: I mean when was the last time you did it
[12:55] <effie_jayx> slytherin,  a two days ago maybe
[12:56] <effie_jayx> slytherin,  I am trying again now and see
[12:57] <DktrKranz> persia, another aolsver4 breakage in bug 184923, hooray! :)
[12:57] <ubotu> Launchpad bug 184923 in aolserver4 "package aolserver4 4.5.0-14 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/184923
[12:58] <persia> DktrKranz: There's also the libldap transition.  Why do we keep aolserver around again?
[12:59] <DktrKranz> persia, dunno, I'll have a look at it later, I think we should call ldconfig.real again.
[13:01] <persia> DktrKranz: I thought the package was split into aolserver-core and aolserver.  Perhaps the relationship needs to be a Pre-Depends?
[13:01] <persia> (where aolserver-core was really libaolserver)
[13:02] <DktrKranz> persia, it won't fail if installed from nothing, probably it will during some upgrades
[13:03] <DktrKranz> I'll try on Debian too, let's see if frankie has a final solution about it
[13:04] <persia> AnAnt: usplash-theme-ubuntume commented.  Borderline, and a strong argument would convince me to advocate.
[13:04] <persia> DktrKranz: Thanks.  Good luck with that.
[13:08] <ScottK> Good morning all.
[13:08] <Hobbsee> morning ScottK
[13:08] <vorian> morning :)
[13:08] <mruiz> hi all
[13:08] <minghua> Morning ScottK.
[13:09] <ScottK2> Hello Hobbsee, vorian, mruiz, minghua, and whoever else decides to say hi.
[13:09] <minghua> effie_jayx: ScottK may be the person you want to talk to about the kdelibs4c2a unmet deps.
[13:09] <\sh> aeh moins ;)
[13:10] <ScottK2> Hello \sh.
[13:10] <\sh> bah I hate wine ;)
[13:10] <effie_jayx> minghua,  great..  I am updating pbuilder atm so I shall tell you in a couple of minutes
[13:10] <effie_jayx> \sh,  don't blame it on them... ;)
[13:10] <\sh> effie_jayx, hehe..
[13:12] <ScottK2> \sh: Don't hate WINE.  Hate the reasons it needs to exist.
[13:13] <\sh> ScottK2, hehe...I added some fixes yesterday..and now I'm trying to fix this dh_strip thingy...a nightmare
[13:13] <geser> persia: I remember that aolserver needed to call somewhere the real ldconfig to find the libs
[13:14] <effie_jayx> slytherin,  the update did it
[13:14] <proppy> oy
[13:14] <ScottK2> geser: Thanks for taking care of debhelper 6.
[13:14] <persia> geser: That was back when the library and the daemon were in the same package (which caused a bit of pain for packages build-depending on it).  There was a package split that was supposed to fix that.
[13:14] <effie_jayx> unmet dep gone... :D
[13:15] <persia> (Actually, the package split happened about a week before gutsy release, but I applied the ldconfig.real hack because it was less invasive at that late date).
[13:16] <geser> persia: does a pre-depends guarantee that ldconfig will be run before aolserver is tried to start?
[13:16]  * persia comments on extremetuxracer, and heads off for the evening, encouraging others to clear REVU
[13:17] <persia> geser: I believe Pre-Depends means the package should be installed and configured before the depending package is installed.  I could misremember though (and I'm at the very tail of my day, so not thinking very clearly).
[13:17] <ScottK2> geser: It should, but use of pre-depends is discourages.
[13:17] <ScottK2> discourages/discouraged.
[13:18] <minghua> persia: No, "installed" is very vague in this context.  You want "unpacked" for Pre-Depends.
[13:18] <persia> Anyway, nobody should install aolserver4 on general principles, and the packages that build-depend upon aolserver4-core should work fine.
[13:18] <persia> minghua: Ah.  That's not enough (unless we do ldconfig.real).
[13:19] <tuxmaniac> Someone mind reviewing http://revu.tauware.de/details.py?package=alliance
[13:21] <effie_jayx> thnx persia
[13:24] <tuxmaniac> Hello LongPointyStick
[13:24] <DarkSun88> Hi all
[13:24] <LongPointyStick> hi tuxmaniac
[13:25] <emgent> DarkSun88, heya
[13:25] <DarkSun88> Hi emgent
[13:44] <encompass> Greetings everyone...
[13:44] <wallyweek> persia: thanks for your review on sdlmame! :)
[13:46] <encompass> Our project memaker.org has a package now.  It has been accepted into Ubuntu Universe but we don't have a consistant packager is there someone that can help us out?  None of us know how to package, and we don't want a buggy memaker in Ubuntu. :(
[13:47] <\sh> encompass, what's the name of your package?
[13:48] <_MMA_> encompass: If you learn and manage the package in BZR it can be easy to get someone to push you changes to the archive.
[13:49] <\sh> hmmm...
[13:49] <encompass> \sh: memaker
[13:50] <\sh> memaker source package is in the archive, packaged by pete ...but no binary package ...
[13:50] <encompass> memaker needs to be compiled?
[13:50] <\sh> ah it's still in the newqueue
[13:52] <\sh> encompass, ask pete savage if he's willing to main your package in general (cbx33 is his nick on irc.freenode)
[13:53] <\sh> s/main/maintain/
[13:59] <encompass> \sh: you mean, like in the main repo?
[14:00] <\sh> encompass, nope...maintaining ;) taking care of the package :)
[14:00] <encompass> oh wait.. hehe
[14:00] <encompass> yeah... I don't think he can
[14:00] <encompass> we are good friends
[14:00] <encompass> we would have said if he can maintain it...
[14:01] <encompass> but with his new job and kid on the way, he already has WAY to much to be bothered with me.
[14:01] <encompass> he did it as a favor for me.
[14:08] <_MMA_> _MMA_: Like I said, you setup the source package in BZR and make the changes yourself its trivial to get someone to push it to the archive.
[14:08] <paas> hi, having problems packaging my shared library. I've been going at it for the last two days. Anybody out there willing to help, thanks!
[14:10] <encompass> is there something to help me do that?
[14:11] <encompass> it's in bzr now
[14:12] <encompass> but I don't know how you want it setup
[14:12] <paas> I think I'm almost there, but when I check the resulting deb the lib is not there. I'm using cmake for building and it creates the debs using pbuilder. I guess I'm messing things up with shlibs or so
[14:12] <_MMA_> encompass: Its not how "I" want it setup. :)
[14:12] <_MMA_> Gimmie the project link in LP.
[14:13] <paas> http://sourceforge.net/projects/tuxcap
[14:13] <_MMA_> _MMA_: #bzr will also help.
[14:13] <tuxmaniac> anybody mind reviewing http://revu.tauware.de/details.py?package=alliance
[14:14] <paas> I've also the correct changelog, copyright etc. I could send you what i've got up to now cause I'm curious what I'm doing wrong
[14:18] <encompass> _MMA_: are you talking to me?
[14:19] <\sh> bah I'm rich now ;)
[14:19] <_MMA_> encompass: Yeah. Bad paste.
[14:19] <encompass> alrighty
[14:19] <encompass> I am asking there
[14:22]  * ScottK is about to start reviewing sdlmame.
[14:25] <geser> \sh: did you win in the lottery? :)
[14:26] <\sh> geser, hehe..na got my last salery from my former company and the compensation :)
[14:28] <slytherin> persia: FYI ... I am able to reproduce the TestSort unit test failure in lucene2 when trying to build with GCJ. Found a reference to the same on Debian pkg-java list - http://lists.alioth.debian.org/pipermail/pkg-java-commits/2007-August/003771.html
[14:33] <dcordero> hid
[14:33] <dcordero> hi
[14:37] <effie_jayx> I have a question... I have been fixing a typo in a man page... checking through debian/control I see that the maintainer is not MOTU... it's jriddell. can I still send in my patch? if so ... who do I assign for package sponsorship
[14:38] <tuxmaniac> anybody mind reviewing http://revu.tauware.de/details.py?package=alliance
[14:38] <ScottK> effie_jayx: What package?
[14:39] <effie_jayx> kmail
[14:39] <effie_jayx> its in kdepim
[14:39] <effie_jayx> it was in the bitesize bugs
[14:40] <ScottK> effie_jayx: It's in Main, so file attach a debdiff to the bug and subscribe ubuntu-main-sponsors.
[14:40] <ScottK> That's a big package, so the Kubuntu devs will probably wait to bundle that fix with others to upload.
[14:41] <effie_jayx> ScottK, good then thanks
[14:42] <ScottK> effie_jayx: Also, if you're interested in KDE thinks, you can join us on #kubuntu-devel ...
[14:42] <ScottK> effie_jayx: I see you're there already.
[14:43] <effie_jayx> ScottK,  yes :D, I am trying kde and I things might get interesting in the KDE front
[14:44] <ScottK2> effie_jayx: Great.  We can always use more help.
[14:50] <dcordero> effie_jayx, that is lp: 180141?
[14:51] <effie_jayx> dcordero,  yes
[14:51] <dcordero> effie_jayx, you could send anywhere a comment  to the bug, someone could work in the same bug
[14:52] <dcordero> if you dont tell them
[14:52] <effie_jayx> dcordero,  well I edited the wiki page. I will comment on launchpad.
[14:53] <dcordero> i say that because i was reading the bug, for fix it :) But i have read you also here
[14:54] <ScottK2> effie_jayx: When you are working on a bug, assign it to yourself in LP.
[14:54] <effie_jayx> ScottK,  well I did that one time.. and I was told to asign it to nobody
[14:55] <ScottK> effie_jayx: Assign it to yourself while you are working on it.  Once you attach the debdiff, assign it back to nobody.
[14:55] <effie_jayx> ScottK,  right, got it
[14:55] <effie_jayx> sorry about that dcordero
[14:56] <dcordero> ;)
[15:07] <ScottK> sdlmame uploaded.
[15:07] <dcordero> what means a bug asigned to MOTU and with Confirmed status?
[15:08] <ScottK> dcordero: What bug?
[15:08] <ScottK> Bugs should never be assigned to MOTU.
[15:08] <dcordero> #105416 for example
[15:08] <ScottK> What it probably means is someone didn't know better.
[15:08] <ScottK> Bug #105416
[15:08] <ubotu> Launchpad bug 105416 in ubuntu "[need-packaging] dvdsub" [Wishlist,Confirmed] https://launchpad.net/bugs/105416
[15:09] <ScottK> dcordero: Means nothing.  It shouldn't have been that way.
[15:09]  * ScottK fixed
[15:09] <dcordero> ok i never seen it before, that was i asked about it :)
[15:09] <dcordero> thanks
[15:19] <\sh> ScottK, octave3.0 transition bug is resolved...
[15:20] <ScottK> \sh: Great.
[15:20] <ScottK> That didn't take long...
[15:21] <\sh> ScottK, it took some time for at least two packages to make them running with octave3.0 because of changed ways of catching some infos
[15:25] <ScottK> Cool.  Congratulation.
[15:25] <ScottK> s
[15:28] <\sh> well..starting now ;)
[15:31] <bddebian> Heya gang
[15:32] <geser> Hi bddebian
[15:32] <bddebian> Hi geser
[15:32]  * \sh needs some nicotine
[15:32] <hellboy195> \sh: nicotine kills you ;)
[15:32] <slytherin> Does anyone know why openoffice.orf FTBFS on powerpc? I am not able to access build logs at present.
[15:33] <\sh> hellboy195, the question is, what doesn't kill me nowadays ;)
[15:33] <hellboy195> \sh: ^^ true
[15:34] <Hobbsee> \sh: nicotine kills you faster, and in nastier ways.
[15:34] <dcordero> can someone help me packaging a application. The application is a simple .jar file that need java-sun >= 5.0
[15:35] <LucidFox> dcordero> Do you have the source code for it?
[15:35] <dcordero> yep
[15:37] <slytherin> dcordero: what help do you need?
[15:40] <dcordero> the sourceforge of the proyect say that the project is writer in a interpreted language
[15:40] <dcordero> but then the source has java
[15:41] <dcordero> and with no intruction for compile it
[15:43] <slytherin> dcordero: url please
[15:44] <dcordero> http://sourceforge.net/projects/robocode
[15:45] <\sh> Hobbsee, na..eating steaks or schnitzel kills me at least as fast as nicotine ,)
[15:45] <Hobbsee> heh
[15:50] <slytherin> dcordero: I see build.xml files in all the sub directories. So it must be using ant as build tool.
[15:54] <dcordero> ok compiled, thanks
[16:00] <\sh> oh well...I wonder what gives me the -X<item> funktionality back to dh_strip
[16:13] <frafu> TheMuso, RAOF: thanks for your review of mousetweaks. I have fixed the issues indicated by RAOF (the ^M were probably due to copy/paste) and uploaded  it to revu. Could you please also review the new version if you have time and interest? Thanks in advance.
[16:17] <nxvl_work> how is that a meeting is scheduled on fridge? where can i ask about it?
[16:18] <frafu> By the way, can anybody please indicate an editor with gui capable of showing what linebreaks the file uses? For example, not knowing how to really use vi,  I used vi to locate the ^M and gedit to correct the file.
[16:18] <norsetto> nxvl_work: try asking bluekuja
[16:19] <emgent> bluekuja is in very long away time.
[16:19] <nxvl_work> norsetto: thnx
[16:19] <emgent> ~2 Week
[16:20] <emgent> hi norsetto :)
[16:23] <slytherin> frafu: What do you mean by correct the file?
[16:25] <frafu> slytherin: replace the ^M (which are dos-linebreaks) with unix linbreaks
[16:26] <slytherin> frafu: why not simply use 'fromdos' command?
[16:27] <frafu> because I did not know about it   :-/   Never used that command
[16:31] <frafu> slytherib: But I would be interested to have an editor with gui that shows what type of linebreaks are used in the file; in order to see whether it uses the correct ones. Do you have any suggestion? Or anybody else?
[16:36] <saivann> Hi, I think that this is the Review day for REVU, can someone take a look at my simdock package here? : http://revu.tauware.de/details.py?package=simdock
[16:38] <slytherin> frafu: Nope. I have no idea.
[16:39] <frafu> slytherin: thanks anyway.
[16:41] <frafu> By the way: here is the fixed version of mousetweaks in revu: http://revu.tauware.de/details.py?upid=1568
[16:43] <slytherin> frafu: If you are fixing some bug in existing version then better file a bug and add a debdiff as attachment.
[16:44] <tuxmaniac> anybody mind reviewing http://revu.tauware.de/details.py?package=alliance sorry for spamming every hour
[16:46] <slytherin> tuxmaniac: be patient. all the packages will be reviewed eventually
[16:46] <frafu> slytherin: the problem was in debian control in a package that I uploaded to revu
[16:52] <paas> Hi all. Can someone help me packaging my shared library. I think I'm almost there, cause it builds in pbuilder, but the resulting .deb is not right. I'm using cdbs, debhelper and cmake? thanks!
[16:52] <pochu> paas: upload what you have to REVU, someone will take a look at it
[16:53] <paas> ok, will do ,thanx
[16:58] <nxvl_work> dholbach: did you know how is that a meeting is scheduled on fridge? where can i ask about it?
[16:59] <ScottK2> dholbach: cjwatson deleted on the MOTU SRU info from the SRU page.  Do you know if that was intentional?
[17:01] <dholbach> nxvl_work: do you want to submit something to the fridge events page (fridge-devel@lists.u.c) or check the events page (http://fridge.ubuntu.com/event)?
[17:01] <nxvl_work> dholbach: submit, so it need to be sent to the fridge-devel list, ok thanks
[17:02] <dholbach> ScottK2: let me see what the change in question was - up to this moment I only know pitti and seb128 discussing simplifying the SRU process and I think the outcome was to simplify the wiki page (to make it less daunting)
[17:02] <dholbach> ScottK2: I don't think removing the MOTU SRU section would be the right fix :)
[17:02] <tuxmaniac> How much time do we have before things freeze in the [new] package area?
[17:02]  * ScottK2 neither, but that's what's currently implemented.
[17:03] <nxvl_work> dholbach: how was the sprint? lots of fun and work?
[17:03] <dholbach> nxvl_work: yeah, it was great to have a lot of people in the same building - lots of good sessions, unfortunately I (and some others) picked up the plague there, that's why I'm a bit slow today
[17:04] <nxvl_work> heh, been there
[17:04] <geser> nxvl_work: see also http://stompbox.typepad.com/blog/2008/01/ahhh-dogfood.html :)
[17:05] <dholbach> ScottK2: https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=80&rev1=79 is the change that cjwatson did - it's just an addition of bits about LTS
[17:06] <nxvl_work> for the hardy+ i will try to be there
[17:06] <nxvl_work> :P
[17:06] <effie_jayx> can anyone help me read this problem... dpkg-shlibdeps: warning: debian/kdepim-kresources/usr/lib/libknotes_xmlrpc.so.1.0.0 shouldn't be linked with libdl.so.2 (it uses none of its symbols).
[17:06] <dholbach> ScottK2: I think the changes you're after happened here: https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=79&rev1=77 (imbrandon and dktrkranz merged and simplified the motu-sru procedure)
[17:06] <effie_jayx> it seems like a missing dependency somewhere
[17:06] <tuxmaniac> effie_jayx, that is ok. most packages have that issue
[17:07] <effie_jayx> tuxmaniac,  but pbuilder fails to build :S
[17:07] <tuxmaniac> effie_jayx, atleast AFAIK
[17:07] <tuxmaniac> effie_jayx, its just a warning. pbuilder must fail due to something else
[17:07] <effie_jayx> tuxmaniac,  ok
[17:07]  * effie_jayx goes back to check
[17:09] <DktrKranz> dholbach, ScottK2: when revisiting SRU wiki page, it was decided to drop motu-SRU section basically because it was almost the same procedure, IIRC only three deltas still remains, so there's no need to duplicate an already long text.
[17:10] <effie_jayx> tuxmaniac,  dpkg-shlibdeps: failure: couldn't find library libkabcscalix.so.0 needed by debian/kdepim-kresources/usr/lib/kde3/kabc_scalix.so (its RPATH is '').
[17:10] <dholbach> DktrKranz: I completely agree
[17:10] <dholbach> the process document is long enough already ;-)
[17:10] <tuxmaniac> effie_jayx, aah ok
[17:10] <effie_jayx> it's the same lib as the warning...
[17:11] <tuxmaniac> effie_jayx, I think both are differnt. I am not an expert though.
[17:11] <dholbach> re sru being to daunting etc: http://www.murrayc.com/blog/permalink/2008/01/26/bug-fixed-glom-16-in-ubuntu-710-gutsy/
[17:12] <\sh> effie_jayx, nope..the warning is about libknotes_xmlrpc ... the bug is not finding libkabcscalix.so.0
[17:19] <\sh> effie_jayx, which package are you working on?
[17:20] <dcordero> are u a motu?
[17:22] <\sh> dcordero, who?
[17:23] <dcordero> my mistake, i wrote in the wrong window
[17:27] <\sh> effie_jayx, bah it's cdbs black magic...I would say in debhelper syntax: dh_shlibdeps -- -xkdepim-kresources
[17:28] <effie_jayx> \sh, so much for bitesize...
[17:28] <effie_jayx> hehe
[17:28] <\sh> effie_jayx, try riddell for help ;) I'm not this cdbs expert
[17:29] <\sh> effie_jayx, bug no?
[17:35] <tuxmaniac> \sh, hows octave3.0 coming along?
[17:36] <smarter> Hi
[17:36] <\sh> tuxmaniac, it should build now in our archives...:)
[17:36] <tuxmaniac> \sh, oh coolness. which means I can expect it in hardy after all the 2.3, 2.9 octave libs chaos?
[17:37] <smarter> Could someone please review my package? http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin thanks in advance ;)
[17:37] <paas> Hi all, I've just joined the contributers group and would like to upload to REVU, could somepne please re-sync the REVU uploaders keyring? thanks
[17:37] <\sh> tuxmaniac, you mean 2.1 and 2.9 .. yes...once it build cleanly I'll have to tell pitti to get rid of 2.1 and 2.9 and do some syncs and uploads for the other packages
[17:38] <tuxmaniac> \sh, yeah 2.1, my bad. this shall close I guess atleast 4-5 bugs
[17:39] <\sh> tuxmaniac, I think we need to clean up after the transition is done ...
[17:40] <tuxmaniac> \sh, yep. am all game for it. just ping me on what help is needed after the transition.
[17:40] <\sh> tuxmaniac, cool :) will do :)
[17:45] <effie_jayx> \sh,  it's a bitesize bug ... yes... But I have a nack for picking the ones with eater eggs
[17:47] <\sh> effie_jayx, as I said, you need to instruct dh_shlibdeps (which is a wrapper around dpkg-shlibdeps) to ignore the package itself. both libs are inside the same package, so something is going wrong there...-x<packagename> pushed towards dpkg-shlibdeps ignores this package...in debhelper mode it's just a dh_shlibdeps -- -x<packagenmae> and this problem should be resolved
[17:50] <proppy> REVU day ends at ?
[17:51] <ScottK2> proppy: It's based on AET.
[17:51] <proppy> AET /
[17:51] <proppy> ?
[17:51] <ScottK2> AET = Earth Anywhere Time
[17:51] <smarter> persia: ping
[17:51] <ScottK2> As long as it's Monday somewhere, it's still REVU day.
[17:52] <proppy> :)
[17:52] <proppy> nice to hear
[17:52] <proppy> maybe I'll have the time to get my upload to revu then
[17:55] <smarter> persia: you reviewed my package(http://revu.ubuntuwire.com/details.py?package=extremetuxracer) and I don't understand some things
[17:55] <dcordero> i have packaged a new application but an upgrade of another package is neccesary, How can i fix it before send my package to revu?
[17:58] <effie_jayx> \sh,  thanks
[18:03] <tuxmaniac> smarter, can you please tell what you dont understnad? I will try to help.
[18:04] <smarter> tuxmaniac: 1) extremetuxracer-data should be arch:any  << it's already arch:any, should it be arch:all?
[18:04] <LucidFox> smarter> Given that it's a -data package, I'd assume arch:all
[18:05] <smarter> ok
[18:06] <smarter> "2) upstream changelogs are nice, expecially when included in binary packages " << My packages all contains a /usr/share/doc/<name>/changelog.gz with the upstream changelog, I don't see the problem?
[18:06] <tuxmaniac> LucidFox, if you have time can you re- check my package? http://revu.tauware.de/details.py?package=alliance
[18:07] <LucidFox> tuxmaniac> I can't advocate it anyway ;)
[18:07] <tuxmaniac> LucidFox, aah ok.
[18:07] <tuxmaniac> LucidFox, you arent a motu? I thought you were.
[18:08] <smarter> should I put the list of translators and "additional contributors" in debian/copyright?
[18:09] <tuxmaniac> smarter, have you mentoned the author there/
[18:09] <tuxmaniac> ?
[18:09] <tuxmaniac> smarter, i mean the upstream author.
[18:10] <smarter> There's a *lot* of upstream authors
[18:10] <smarter> and in the AUTHORS file there's a list of translators and "additional contributors"
[18:11] <tuxmaniac> smarter, atleast mention the packager's name saying.. this software was debianised by foobar.. blah blah. then provide the Upstream website and add a gpl snippet
[18:12] <smarter> I did that
[18:12] <tuxmaniac> smarter, take a look at other packages and see whats missing
[18:12] <LucidFox> tuxmaniac> I'm not a MOTU, I just review packages on REVU when I feel like it :)
[18:12] <smarter> I didn't put the whole list of author
[18:12] <smarter> *s
[18:12] <tuxmaniac> smarter, and from the comment, I guess thats what persia pointed out
[18:13] <smarter> and the AUTHOR file is not even complete
[18:13] <smarter> some guys only have their nickname
[18:14] <smarter> some don't have an email
[18:17] <tuxmaniac> smarter, hamish already has packaged 0.4 if what I see from the website is correct. I shtere something I am missing?
[18:17] <tuxmaniac> LaserJock,
[18:18] <LaserJock> hi tuxmaniac
[18:19] <tuxmaniac> LaserJock, have succesfully managed to kill those scripts-have-language-extension crap. have uploaded a fresh package yesterday.
[18:21] <smarter> tuxmaniac: are you speaking of this package? http://www.extremetuxracer.com/?download
[18:21] <tuxmaniac> smarter, yep
[18:21] <smarter> bbl
[18:23] <ScottK> Any interested in learning more about policykit?
[18:23] <tuxmaniac> ScottK, what is it? wiki link?
[18:23] <ScottK> It's a new thingy for Hardy.  Dunno much about it.
[18:24] <ScottK> Bug 186710 asks for some integration work with it.
[18:24] <ubotu> Launchpad bug 186710 in clamtk "should use policykit to escalate privileges" [Undecided,New] https://launchpad.net/bugs/186710
[18:24] <tuxmaniac> https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration ?
[18:27] <warp10> Heya!
[18:27] <ScottK> tuxmaniac: Yes.
[18:29] <LaserJock> warp10: hiya
[18:29] <warp10> LaserJock: :)
[18:30] <tuxmaniac> I have this warning. W: alliance: script-not-executable ./etc/alliance/alc_env.csh I think it is not a needed file for bash. but needed for csh. can I just make a check in my debian/rules for the shell used and appropriately copy the correct file. this will eliminate the warning I guess
[18:30] <tuxmaniac> hello warp10
[18:30] <warp10> hi tuxmaniac :)
[18:31] <tbutter> tuxmaniac: you need it only at build time?
[18:31] <LaserJock> tuxmaniac: is it supposed to be executed or is it a config file?
[18:34] <tuxmaniac> LaserJock, there are two files. one with the .sh extension and another with .csh extension
[18:35] <smarter> tuxmaniac: the deb package of etracer was a checkinstall until recently and now it's just my package.
[18:35] <tuxmaniac> LaserJock, responsible for setting up the environment variables
[18:36] <tuxmaniac> tbutter, yes.
[18:36] <tbutter> why do you install it then?
[18:37] <tuxmaniac> it i present only in the config section.
[18:39] <tuxmaniac> no. hold. something is wrong.
[18:42] <tbutter> anyone would like to review http://revu.tauware.de/details.py?package=jodviewer ? all known issues are fixed
[18:44] <tuxmaniac> no. I got that all wrong. It is needed to run the tools
[18:44] <tuxmaniac> those are scripts in which the setting of the environment variables take place
[18:45] <tuxmaniac> for bash shells it is the file with .sh and for cshells it is the file with .csh that needs to be run
[18:46] <dcordero> can someone help, i have a problem creating a new package for fix a bug
[18:46] <tuxmaniac> so the warning actually will be reverse in a machine that has cshell
[18:46] <tuxmaniac> and I feel it can be ignored. please comment
[18:47] <dcordero> i am packagin qbittorrent
[18:47] <dcordero> http://www.qbittorrent.org/
[18:47] <dcordero> i have get compile and install it on my machine
[18:47] <ScottK2> tuxmaniac: Why are you installing scripts in /etc?
[18:48] <sistpoty> hi folks.
[18:48] <dcordero> but like you can read on the website is needed libtorrent  > 0.13 for compile qbittorrent. And give you a link to the correct libtorrent that i used
[18:48] <sistpoty> sorry, I just broke commenting in revu, will be fixed ASAP
[18:48] <dcordero> but when i am doing a package i have found that the last libtorrent in the oficial webpage of libtorrent is 0.12 :/
[18:49] <ScottK2> Hello sistpoty.
[18:49] <sistpoty> hi ScottK2
[18:50] <tbutter> tuxmaniac: you are always calling the .sh scripts in your /usr/bin scripts
[18:51] <tuxmaniac> tbutter, is there a better way to do that?
[18:52]  * LucidFox pings jdong
[18:52] <LucidFox> tovid is ready for review: http://revu.ubuntuwire.com/details.py?package=tovid
[18:52] <tuxmaniac> ScottK, actually it is in alliance/etc and not /etc
[18:53] <ScottK> Ah.  OK.
[18:53] <tuxmaniac> and the /usr/bin scripts have to call the alc_env.sh or .csh to set the environment variables for the user to run the cad tools
[18:54] <tbutter> tuxmaniac: but you alway call alc_env.sh
[18:54] <ScottK2> So I geuss the question you need to answer is why do you get that warning?  Are you installing the scripts in the right place (per FHS)?
[18:54] <tuxmaniac> oh. you mean there is no necessity for .csh ?!
[18:54] <tuxmaniac> tbutter, ^
[18:55] <tuxmaniac> ScottK, i removed the "cp" that is done in debian/rules for .csh and then the warning disappears (ofcourse ;-)) and tools work too
[18:56] <ScottK> tuxmaniac: What if someone is using csh as their shell?
[18:57] <tuxmaniac> ScottK, so I guess its better to introduce the check for shell in debian/rules ?
[18:58] <tbutter> tuxmaniac: in debian/rules you check the shell on the build machine, not that of the user
[18:59] <tuxmaniac> ah ok
[19:01]  * DaveMorris plugs his package - http://revu.tauware.de/details.py?package=opensg
[19:03] <tuxmaniac> ScottK, just checked. all the files that call alc_env.sh are bash scripts. so they are correct. and this file .csh isnt needed at all then.
[19:03] <ScottK> tuxmaniac: I'll ask again, what if someone is running csh as their shell?
[19:05] <tuxmaniac> ScottK, then one solution which comes to my mind is change the scripts in /usr/bin to make the decision and source the "correct" shell script for setting up the environment variables
[19:06] <tuxmaniac> ScottK, I hope I am speaking some sense. Please correct me if wrong.
[19:06]  * ScottK doesn't have a strong opinion, but we ought to support as many options as we reasonably can.
[19:13] <pochu> persia: latest patch for REVU images applied, let me know if you still find something wrong
[19:13] <rulus> I'm packaging something that depends on sun-java6-jdk, which is only available on i386 and amd64. Should my package also only support these architectures, or should I leave it 'all'?
[19:14]  * tuxmaniac decides to take it up tomorrow. off to bed.
[19:14] <tuxmaniac> bye guys.
[19:15] <sistpoty> emgent: uploaded
[19:15] <tbutter> rulus: did you try icedtea?
[19:16] <sistpoty> thanks again pochu!
[19:16] <rulus> tbutter: nope, I didn't, I'll check that out first :)
[19:17] <pochu> sistpoty: you're welcome. And thanks for reviewing it :)
[19:17] <emgent> sistpoty, big thanks.
[19:17] <sistpoty> pochu: obviously I didn't review it hard enough :P
[19:23] <calc> rulus: icedtea is cool :)
[19:24] <calc> too bad it probably won't make it into main for 8.04 :\
[19:24] <calc> maybe 8.10 or 9.04 though
[19:28] <nixternal> icedtea is actually working much better than I had expected
[19:28] <nixternal> thus far, all of my java projects have compiled with it just fine, which totally suprised me
[19:35] <proppy> re
[19:36] <proppy> http://revu.tauware.de/details.py?package=juce updated on REVU
[19:39] <vemon> how can i add a blank line to the description in debian/control?
[19:39] <vemon> if i try that i just get this: dpkg-source: error: syntax error in control file ./phasex-0.11.1/debian/control at line 20: continued value line not in field
[19:40] <ion_> Use a dot.
[19:40] <vemon> seems to work. thanks
[19:41] <vemon> is the dot "visible"?
[19:41] <ion_> Yep, e.g. apt-cache show gcc
[19:43] <DRebellion> what is  $(INSTALL_ROOT)
[19:43] <DRebellion> used for, sorry in a makefile
[19:49] <calc> nixternal: yea it worked for openoffice also, but doko didn't want to put it in main until it is no longer beta (iirc)
[19:49] <calc> nixternal: due to support issues
[19:49] <nixternal> ya
[19:50]  * calc bbiab have to beat on my voip router
[19:50] <nixternal> hehe
[19:51] <mcisbackuk> Evening all....Question: How do I go about creating a Makefile for a source package that hasn't got one? Also, if the only commands to build the source are ./configure make make install and make clean, then what do I need to put in?
[19:51] <smarter> mcisbackuk: make use a Makefile
[19:52] <smarter> mcisbackuk: your package probably generate a Makefile from ./configure
[19:52] <mcisbackuk> smarter: I worded it wrong, it's 2 separate questions, sorry
[19:52] <smarter> oh okay
[19:52] <LaserJock> mcisbackuk: do you mean a debian/rules Makefile?
[19:52] <persia> pochu: Looks nice.  Thanks.
[19:53] <smarter> mcisbackuk: if  your package only use ./configure && make && make install, just use dh_make and select cdbs
[19:53] <smarter> it will use the autotools and do everything automatically
[19:53] <persia> smarter: When I compiled your package, CDBS stripped all the upstream changelogs.  How are you building it to test?
[19:53] <mcisbackuk> LaserJock: Think so, if its the one that debuild or is it pbuilder uses? But there's so many frigging lines in any other makefile / rules i've come across and I've found no documentation on either
[19:54] <smarter> persia: I used pbuilder I think, I'll retry later
[19:54] <persia> smarter: hardy pbuilder, up-to-date?
[19:54] <smarter> gutsy, I don't have an hardy box atm
[19:54] <smarter> but I'll try with a chroot later
[19:54] <mcisbackuk> LaserJock: Basically I'm proper confused
[19:54] <LaserJock> mcisbackuk: well, it helps to specify that it is debian/rules as that is different than a general Makefile that you find in a source
[19:54] <persia> smarter: Also, you don't need all the email addresses for the authors and copyright holders (although it's nice).
[19:55] <smarter> persia: what's the correct way to include the Changelog file?
[19:55] <LaserJock> mcisbackuk: do you know what a Makefile is? perhaps that's a good start?
[19:55] <persia> smarter: You can run a hardy pbuilder on a gutsy box.  Some developers run Dapper.  Just update your pbuilder.
[19:55] <smarter> That's what I'll do
[19:55] <persia> smarter: It should be installed with what you did.  For now, you need to add DEB_INSTALL_CHANGELOGS_ALL to your debian/rules.
[19:55] <smarter> be back later, thanks for the review
[19:56] <mcisbackuk> LaserJock: Yes, well a good diea at least, it passes build instructions to the kernel to compile itself right?
[19:56] <persia> (this is a workaround for something that won't be fixed in hardy)
[19:56] <smarter> there's a bug in hardy's cdbs?
[19:56] <LaserJock> mcisbackuk: well, not necessarily the kernel, but yes, it's the instructions for building the software
[19:56] <mcisbackuk> LaserJock: I meant that :) lol
[19:57] <LaserJock> mcisbackuk:  debian/rules is a special makefile used to build a binary package (.deb) from a source package
[19:57] <mcisbackuk> LaserJock: And I need to create both? (This source in particular has a ./configure)
[19:57] <LaserJock> mcisbackuk: no
[19:58] <LaserJock> mcisbackuk: ./configure is part of autotools and when it's run it creates a Makefile for building the software
[19:58] <mcisbackuk> LaserJock: OK this is where I'm confused, one wiki page says one, the other says another
[19:58] <LaserJock> mcisbackuk: what page are you looking at
[19:58] <mcisbackuk> LaserJock: So I invoke ./configure in the debian/rules?
[19:58] <pochu> sistpoty: can we remove "[Motu-reviewers][REVU]" from review mails please? :)
[19:59] <LaserJock> mcisbackuk: that is one of the things you'll do yes
[19:59] <mcisbackuk> LaserJock: I closed it now, think it was packaging guide/basics
[19:59] <sistpoty> pochu: not too sure... does it come from revu or from the mailing list setup?
[19:59] <LaserJock> mcisbackuk: ok, so what happens is ./configure creates a Makefile, then you "run" that Makefile with "make" and then you install the software by telling "make" to use the install rule
[20:00] <LaserJock> that's the ./configure && make && sudo make install
[20:00] <pochu> sistpoty: from the ML
[20:00] <mcisbackuk> LaserJock: Yup, I got that and understand it fine, I've built source before
[20:00] <pochu> sistpoty: well I'm not sure. but I receive them from the ML
[20:00]  * sistpoty takes a look
[20:00] <LaserJock> mcisbackuk: what you want to do in debian/rules is run that, but also "guide" it to install to the right place and make sure it conforms to Debian/Ubuntu policy
[20:00] <pochu> sistpoty: http://lists.tauware.de/pipermail/motu-reviewers/2008-January/date.html
[20:01] <pochu> sistpoty: the first 2 prefixes are always the same and thus useless IMHO
[20:01] <LaserJock> mcisbackuk: does that make sense?
[20:01] <mcisbackuk> LaserJock: OK, to /usr/bin/<PROG> for example? And what is the policy?
[20:02] <sistpoty> pochu: seems to be a mix of revu and the ML mangling: Comments.py:    subject = "[REVU][COMMENT] for %s" % packagetext
[20:02] <LaserJock> mcisbackuk: right, the policy is http://www.debian.org/doc/debian-policy/
[20:02] <pochu> sistpoty: so we would need to remove [REVU] from the code and [Motu-reviewers] from the ML setup, right?
[20:03] <mcisbackuk> LaserJock: OK got it :) Thanks :)
[20:03] <sistpoty> pochu: from a first glance: yes
[20:03] <pochu> sistpoty: could you take care of the ML setup? I can look into the code if you are busy :)
[20:04] <sistpoty> pochu: I guess siretart needs to do the ML stuff (at least I don't have access to the ml)
[20:04]  * ScottK suggests writing the regular MOTU ML first as some people filter based on tags like that.
[20:04] <LaserJock> mcisbackuk: if you look at the bottom of https://wiki.ubuntu.com/PackagingGuide/PackagingOverview you'll see and example rules file
[20:04] <sistpoty> ScottK, pochu: I just wanted to write this... at least I guess I have my filter setup like this *g*
[20:05] <mcisbackuk> LaserJock: Brilliant....I'm bookmarking this :)
[20:05] <pochu> ScottK, sistpoty: X-BeenThere: motu-reviewers@tauware.de
[20:05] <ScottK> sistpoty: Presumably you provide proper list-id headers and people should filter on that.
[20:05] <LaserJock> mcisbackuk: it's not a perfect example because it doesn't have a configure: rule but it's an example anyway
[20:05] <ScottK> pochu: I agree there are better ways to do it, but don't remove something people rely on without warning/discussion.
[20:06] <mcisbackuk> LaserJock: I'm sure I'll get the hang of it, I just wanted a silly example to look at anyway :)
[20:06] <pochu> ScottK: alright. I'll mail ubuntu-motu@. sistpoty, is that fine with you? siretart?
[20:07] <sistpoty> pochu: sure... and when looking again, I already seem to use the x-been-there thingy (confused by my different filter rules *g*)
[20:08] <persia> \sh: re: octave: Congrats on the hard part.  Are you planning to file removal bugs for the obsolete stuff?  Also, once that is gone, could you re-add the "octave" virtual package to smooth upgrades?
[20:11] <\sh> persia, yepp...it's all going the correct ways :)
[20:11] <persia> \o/
[20:11] <\sh> persia, removals of 2.1 and 2.9 are being scheduled for tomorrow
[20:12] <persia> \sh: Thanks a lot for actually digging through all that.  The new octave is a major feature win.
[20:14] <\sh> persia, is an provide:octave  not enough?
[20:15] <LaserJock> well
[20:15] <LaserJock> you can't just reinsert the virtual package
[20:15] <LaserJock> that's why Debian removed it
[20:15] <persia> \sh: There used to be an octave virtual package, which was dropped due to droppoing the epoch for octave3.0.  Provide: makes the upgrade work if the user happens to have another package that depends on "octave", but it doesn't help the user who has the "octave" package installed.
[20:16] <persia> LaserJock: You can reinsert as soon as the previous octave package is gone.  The only issue is the epoch (or am I missing something?)
[20:16] <LaserJock> well, exactly the epoch
[20:16] <LaserJock> that means it won't upgrade
[20:16] <ScottK2> Exactly
[20:16] <\sh> ah yes...right...sure I'll push it to the archive
[20:16] <LaserJock> so you'll have a useless octave virtual package
[20:16] <persia> Ah.  Right.  That's annoying.
[20:17]  * persia had forgotten that archive state and installed state both needed tracking
[20:17] <LaserJock> you'd either have to use an epoch in octave 3.0 which throws us off from upstream
[20:17] <LaserJock> or have a new source package that just does octave
[20:17] <LaserJock> that *is* epoched
[20:17] <persia> So hardy releases without "octave", and it can be put back for hardy+1?
[20:18] <LaserJock> but what happens to Hardy users?
[20:18] <LaserJock> hmm, I guess they would be left with octave/octave2.9 as "local" packages
[20:18] <persia> LaserJock: They get to be unhappy, unless we can figure out a workaround.
[20:18] <LaserJock> but it shouldn't remove them
[20:19] <\sh> LaserJock, then I would like to have a dummy package with an epoch inside...
[20:19] <frafu> TheMuso, RAOF: I just uploaded a new version of mousetweaks that corrects an error in debian/watch: http://revu.tauware.de/details.py?package=mousetweaks Thanks for reviewing it again if you have time and interest.
[20:19] <persia> \sh: If you have a dummy package with an epoch, we can't sync when Debian brings back the virtual package, because we'd hit the same issue.
[20:20] <persia> frafu: You'll get a better package if you get more different reviewers.  Best to advertise generally.
[20:20] <LaserJock> persia: Debian didn't say they *would* bring it back, just that they could if need be
[20:21] <persia> LaserJock: They have the same issue.  They can't release it for lenny.  Maybe it will be present for lenny+1.
[20:21] <LaserJock> I personally think it's just fine to not have it as long as we have provides
[20:21] <paas> Hi, I've uploaded my package to REVU a couple of hours ago but it doesn't show up. Is this because my key is currently not in the keyring? If so could someone resync the key-ring. thanks
[20:22] <sistpoty> paas: what package? I'll take a look at the queue
[20:22] <paas> libtuxcap, thanks
[20:22] <sistpoty> paas: ah, k (there is only libtuxcap in rejected *g*)
[20:23] <DRebellion> Hi, can someone point me at a guide for the syntax/format of debian/menu ?
[20:23] <persia> sistpoty: Are you resyncing, or shall I?
[20:23] <\sh> persia, LaserJock, we could let mvo hack some magic into dist-upgrader
[20:23] <persia> DRebellion: install the menu package, and look in /usr/share/doc/menu
[20:23] <sistpoty> persia: I'll just do a quick import and put back the package :)
[20:23] <frafu> persia: I talked to them, because they already reviewed previous versions. Of course, I will also be thankful to anybody else that will review it.
[20:24]  * persia is awed by sistpoty's leet REVU s|>17Z
[20:24] <sistpoty> persia: heh, that's no skills, revu-key has import as a command :)
[20:24] <DRebellion> persia: thank you
[20:25] <persia> frafu: Understood.  It's precisely because they reviewed it before that I recommend you find someone else.  If you get the same reviewer several times, 6you are more likely to get a rejection after your first advocation, which can be frustrating.
[20:26] <sistpoty> paas: libtuxcap should get picked up with the next cron run (<= 10 minutes)
[20:26] <persia> Essentially, each of the reviewers tends to have a slightly different set of checks.  Just because you pass one doesn't mean you will pass another, and even if you get two, if they didn't check everything, the archive admins may well reject it.
[20:26] <paas> sistpoty: thanks
[20:29] <LaserJock> bddebian: ping
[20:29] <bddebian> Yo
[20:30] <frafu> persia: what do you mean by a rejection after the first advocation: I thought that after two advocation, it would be accepted. It already happened to me to get an advocation and a second person found another error. Consequently, I suppose that 2 advocation for the same upload are required!?
[20:30] <LaserJock> anybody familiar with sauerbraten here?
[20:31] <persia> frafu: Yes.  Two advocations for the same upload are required.  Further, many advocates will wait for a while before readvocating if it was rejected, as rejection after advocation tends to make reviewers shy.
[20:31] <bddebian> LaserJock: I said yo.. :-)
[20:31] <persia> LaserJock: Why?  Possible licensing issues?
[20:31] <LaserJock> bddebian: you did? oh, you did
[20:31] <bddebian> Needs a new upstream release
[20:31] <LaserJock> ok, why is it in Multiverse?
[20:32] <LaserJock> I've got somebody who's built a game from it and they'd like to get it into Edubuntu/repos
[20:32] <bddebian> The engine is free, some of the content is not, iirc
[20:32]  * persia defers to the expert, but believes REVU is the appropriate path
[20:33] <LaserJock> well, there's not even a package
[20:33] <persia> LaserJock: That would be the first step then, no?
[20:33] <LaserJock> I'm trying to assess feasibility
[20:34] <LaserJock> I don't want to say "sure" when it's gonna get dumped in Multiverse after 6 months of battling with it ;-)
[20:34] <persia> Could anyone suggest where I should ask about bluetooth initialisation issues?
[20:34] <persia> LaserJock: Given feature-freeze timing, that seems the most likely scenario.  Maybe a PPA for now?
[20:35] <LaserJock> would this be the sort of thing the Games team would be interested in?
[20:35]  * calc back
[20:35] <LaserJock> I don't think Edubuntu has the packaging power to do it, especially if it's just gonna end up in Multiverse
[20:36] <frafu> persia:  you told above that the archive admin can still reject it after two advocation. Will the uploader be informed about the rejection by the archive admins?
[20:37] <persia> frafu: Usually the packager and the archive ML, but not the uploader.
[20:37] <frafu> persia: ML?
[20:38] <pochu> Mailing List
[20:38] <frafu> ok
[20:40] <RainCT> «W: freevial: changelog-file-not-compressed ChangeLog»  if I have ChangeLog listed in debian/docs, shouldn't it be compressed automatically of needed?
[20:40] <\sh> does anyone has cjwatsons key on his keyring and has gnupg2 running?
[20:41] <persia> RainCT: You should never have a changelog in debian/docs.  Use dh_installchangelogs
[20:44] <RainCT> persia: ah.. thanks :)
[20:44] <persia> keescook: About dirty autoconf hints in debdiffs.  For SRUs, they tend to be preferred, as patching the package to not get dirtier on clean is considered "more invasive".  Of course, this indicates a bug in the package, as debian/rules clean shouldn't make it dirty.
[20:45] <frafu> Is anybody interested in reviewing the mousetweaks package; Could anybody please review the mousetweaks package; http://revu.tauware.de/details.py?package=mousetweaks  In fact, mousetweaks provides the new accessibility functions of the accessibility tab of the mouse control panel of GNOME 2.22 (the version that will be in hardy).It would be odd to have the settings in the control panel, but not the module providing the functionalitie
[20:46] <keescook> persia: yeah, true.  perhaps inkscape is one of the special cases.
[20:46] <persia> frafu: "providing the functionalie"
[20:47] <persia> keescook: There are an unfortunate number of them.  To me it makes sense to hold the SRU until the dev release is patched to not do that any more, but not to ask for filterdiff for SRUs: that way lies danger.
[20:49] <keescook> persia: yeah.  Mostly, bryce confirmed that I should "Won't Fix" those bugs since he didn't want to run them with SRU (they're minor bugs).
[20:50] <persia> keescook: Makes sense to me: they didn't really look SRU-worthy.  On the other hand, that wasn't clear from the bugtrail, and I don't think that someone running filterdiff would be well rewarded for their efforts.
[20:50] <\sh> ok...looks good with octave3.0
[20:52] <\sh> keescook, you are our security officer ;) I do have some problems with gnupg2 and cjwatsons key, because he has some sigs on his subkey...and reading rfc4880 it seems like this is wrong...I get errors reading the key with gnupg 2.0.x
[20:53] <keescook> \sh: hurm.  Can you open a bug report for it?  (And include a "this is how it breaks" example for me?  I'm not heavily using gnupg 2 yet)  :)
[20:53] <frafu> persia: in other words, the mousetweaks module does the job of what is indicated in the accessibility tab of the mouse control panel. For example: you can activate automatic mouse button click in the mouse control panel (useful for some disabled people). However it is mousetweaks that does the clicks.
[20:54] <\sh> keescook, well, I felt about it during testing of another linux distro :) and we tracked it down to this....I'm doing some tests with ubuntu and gnupg2 tomorrow....
[20:54] <keescook> \sh: cool
[20:54] <\sh> and hopefully colin is back on stage then ;)
[20:55] <emgent> heya people
[20:56] <keescook> heya emgent
[20:56] <geser> \sh: gnupg 1.4 is happy with that key?
[20:56] <\sh> geser, yepp
[20:56] <\sh> 2.0.8 not
[20:56] <\sh> geser, and as I read http://tools.ietf.org/html/rfc4880#section-12.1 even rfc is not happy :)
[20:57] <\sh> geser, or I misread something
[20:57] <\sh> s/I/we/
[20:59] <\sh> geser, will followup on this tomorrow...need to prepare dinner for my wife..she's coming home in a few
[20:59] <\sh> persia, LaserJock : octave3.0 build on mostly all our archs...but not lpia because of missing deps it seems....
[21:00] <\sh> so ... and off
[21:00] <persia> \sh: While it was part of the original intention of the pocket computer, I suspect those of us who use mathematical packages beyond a calculator on our pocket computers are members of a very small minority.
[21:04] <persia> rexbron: openlibraries commented
[21:07] <bddebian> LaserJock: Sorry, at work.  Shoot an e-mail to debian-devel-games@lists.debian.org. :)
[21:19] <LaserJock> hmm, everytime I see a "anybody figured out how to install <pkg> from source?" I keep wanting to do a PPA
[21:19] <LaserJock> people are really wanting Octave3.0 on gutsy
[21:22] <geser> keescook: are there any plans to upload the pcre3 version from gutsy-security also to hardy? currently gutsy-security has a newer version than hardy
[21:23] <keescook> geser: yeah, it's on my list.  I'd like to get Debian's 7.4-1 merged.
[21:32] <LaserJock> darn, it appears that actually running fetchmail after a reboot produces more email in my inbox :-)
[21:33] <LaserJock> I wondered why it was such a slow email day
[21:35] <geser> LaserJock: if you don't the usual spam anymore then it's time to check your mail server :)
[21:36] <LaserJock> yes, very true
[21:54] <leonel> Hey someone stole my  restricted drivers manager on my hardy ..
[21:55] <_MMA_> leonel: There's but some change with that. Im looking into it myself.
[21:56] <leonel> I've upgraded a gutsy desktop yesterday  and  today tried my wireless and need the frimware for the card   on  gutsy  with restricted drivers manager  got solved
[22:43] <sistpoty> gn8 everyone
[22:45] <crimsun> stgraber: since you provided only an interdiff for #186827, and the URL given in debian/control does not contain an orig.tar.gz for 0.9, do you plan to add a get-orig-source target to debian/rules?
[22:47] <stgraber> crimsun: hmm, I haven't checked the get-orig-source, I just saw we had a watch file in our bzr and uploaded :)
[22:47] <crimsun> stgraber: I have no problem renaming http://www.stgraber.org/download/projects/pastebin/pastebinit-0.9.tar.gz to conform to source package policy, but that direction would be useful in the bug report  :-)
[22:49] <stgraber> Oh, what's wrong with it ? I just tried doing a uscan --force-download and it went without any problem ?
[22:50] <crimsun> stgraber: according to the version used in the topmost debian/changelog entry, this is a non-native source package, which means there needs to be an orig.tar.gz
[22:51] <crimsun> stgraber: I presume that the tarball given in my post above is actually the orig.tar.gz, in which case it would simply need to be downloaded and renamed to conform to source packaging policy.
[22:51] <stgraber> yes, it's the .orig.tar.gz
[22:51] <crimsun> stgraber: I was asking you to affirm that http://www.stgraber.org/download/projects/pastebin/pastebinit-0.9.tar.gz is in fact the upstream tarball for 0.9.
[22:52] <crimsun> stgraber: ok.  For clarity, please state as much in the bug report in the future if you're only providing an interdiff.
[22:53] <stgraber> ok, will think of adding a bit more information next time :) (first time I play with interdiff)
[22:53] <crimsun> thanks  :-)
[22:59] <emgent> heya crimsun :)
[22:59] <crimsun> hi emgent  :-)
[23:22] <stgraber> crimsun: thanks for the upload
[23:23] <crimsun> yw
[23:26] <Legendario> got the following ppa message: MD5 sum of uploaded file does not match existing file in archive. Files specified in DSC are broken or missing, skipping package unpack verification.
[23:26] <Legendario> what is it?
[23:27] <mok0> Legendario: you need to build the source package and upload the _source.changes
[23:27] <Legendario> mok0 that's what i did...
[23:28] <mok0> Legendario: you probably have some files left from a binary build
[23:28] <mok0> Legendario: use flags -S -sa
[23:28] <Legendario> mok0, on what?
[23:28] <pochu> stgraber: wow, pastebinit is really useful :)
[23:29] <pochu> stgraber: btw paste.stgraber.org is down
[23:29] <mok0> dpkg-buildsource (or debuild...)
[23:29] <Legendario> the packaging worked well on pbuilder
[23:29] <mok0> Legendario: sure, but this is uploading, right?
[23:30] <Legendario> mok0, yes. I uploaded it to ppa but the package was rejected. that was the message i got
[23:31] <mok0> Rebuild the source package with debuild -S -sa
[23:31] <stgraber> pochu: I know, it's one of the things I changed with this upload :)
[23:31] <stgraber> pochu: default is now pastebin.com
[23:31] <mok0> that gives you a _source.changes file, which you dput
[23:31] <jdong> mok0: dput checks md5sums before uploading
[23:31] <jdong> mok0: I am more tending to think it's something wrong with the infrastructure that caused it
[23:31] <stgraber> pochu: I would need to reinstall the pastebin on my own server as the external pastebin I was using seems to be dead now :(
[23:32] <pochu> heh
[23:32] <mok0> jdong: could be
[23:32] <LaserJock> Legendario: is the package already in Ubuntu?
[23:37] <Legendario> LaserJock, no, it is not
[23:43] <Legendario> well, should i rebuild it and try to upload it again?
[23:44] <mok0> Legendario: try it
[23:45] <Legendario> mok0, gonna try
[23:45] <mok0> Legendario: go for it
[23:45] <Legendario> mok0, gonna tell you the results if it fails
[23:46] <mok0> Legendario: you can pastebin it
[23:55] <jscinoz> hey guys, sisposty submitted a patch for urbanterror to make it work with ubuntu's libjpeg, but how exactly would i apply this patch: http://launchpadlibrarian.net/11602996/upid_1386_use_system_libjpeg6.patch