[00:00] <RainCT> ryanakca: it has some little differences... like the h and the r being excanged
[00:00] <azeem> lfaraone: both are orthogonal
[01:50] <binarymutant> I was wondering if it was okay to contact upstream about including gpl info into the source code, and if getting the okay, including a patch with the package?
[02:03] <nhandler> binarymutant: If upstream agrees about having the GPL info in the source (like it should be), I would try and get them to make the changes themself. That way, we don't even need to patch it.
[02:04] <binarymutant> nhandler, I just didn't want to wait for another release to have those gpl paragraphs included in the source code :/
[02:04] <NCommander> directhex, ping
[02:05] <nhandler> binarymutant: It all depends on upstream. Some upstream developers have no issue relasing new versions of the application that only fix minor issues (like the GPL one)
[02:05] <directhex> NCommander, sleepy pong
[02:05] <NCommander> directhex, I have a patch for mono on armel, where do you want it?
[02:05] <binarymutant> thanks nhandler for the info
[02:05] <directhex> NCommander, bugs.debian.org. or if you prefer, pkg-mono@lists.debian.org
[02:06] <directhex> NCommander, actually, maybe upstream wants it? i could bridge it into novell bugzilla tomorrow
[02:06] <NCommander> directhex, ok, ping me tommorow
[03:13] <persia> nhandler, Note that we're note supposed to patch the license while packaging, which it probably a stronger argument for doing/not doing than most others.
[03:15] <nhandler> persia: Thanks for clarifying. I knew it wasn't commonly done. I also knew it wasn't recommended. However, I wasn't sure if it wasn't allowed.
[03:16] <persia> nhandler, Essentially, the licensing is the license extended to the packager.  Such a license (WTFPL) generally doesn't permit the user to modify the license while not altering the attribution when distributing.
[03:17] <persia> s/WTFPL/WTFPL excepted)
[03:17] <persia> nhandler, So, if you take licensed code, and modify it a bit, and create something different, you can do license cleanup.
[03:17] <persia> (to a limited degree, depending on the license).
[03:18] <persia> If you're just packaging, and claiming that this is upstream source, with upstream licensing, you generally can't.
[03:18] <persia> (again, WTFPL excepted)
[03:19] <persia> (note: for those seeking a definition of "free" that goes well beyond anarchy, the WTFPL is a good choice)
[03:26] <jsmidt> If anyone has time, could you look at the buildlogs for herwigpp in my ppa: https://launchpad.net/~jsmidt/+archive
[03:26] <jsmidt> The build isn't working
[03:27] <jsmidt> It has this error: dh_shlibdeps: command returned error code 512
[03:28] <jsmidt> I'm new at packaging and I am trying to figure out what exactly is going wrong.
[05:41] <edajai> hi
[05:42] <dholbach> good morning
[05:42] <edajai> morning
[05:43] <edajai> i'am confused... i want to contribute to ubuntu project ..but i dunno where to start
[05:43] <edajai> i thought of packaging
[05:43] <dholbach> edajai: what are you interested in?
[05:43] <dholbach> ah great
[05:43] <edajai> programming
[05:43] <dholbach> check out https://wiki.ubuntu.com/MOTU/GettingStarted
[05:44] <edajai> i know c++
[05:44] <dholbach> it links to a lot or resources like the packaging guide, tutorials, videos, etc
[05:44] <edajai> i thought MOTU was for packaging only
[05:44] <dholbach> we fix a lot of bugs too :)
[05:44] <dholbach> so knowing a programming language or two definitely helps
[05:44] <edajai> oh..nice
[05:45] <fabrice_sp> Hi dholbach :-)
[05:45] <edajai> can u please provide me links to relatively less complex bugs that can be easily fixed
[05:45] <dholbach> once you feel like you've played with the toys^Wtools a bit, there's also lists of bugs that might be easy to start with on the wiki page I gave you
[05:45] <nellery> hi dholbach :)
[05:45] <dholbach> hi fabrice_sp
[05:45] <dholbach> hi nellery
[05:45] <edajai> toys^Wtools???
[05:45] <dholbach> tools
[05:46] <edajai> k
[05:46] <edajai> which IDE would u recommend?
[05:47] <dholbach> regarding "^w": http://en.wikipedia.org/wiki/%5EW
[05:47] <fabrice_sp> I need some help with a watch file. I have this line inside: http://sf.net/dvdstyler/DVDStyler-(.*)\.tar\.bz2
[05:47] <dholbach> edajai: just go with any editor you're familiar with for now
[05:47] <fabrice_sp> but I'm getting DVDStyler-1.7.1b1.tar.bz2 as newer than DVDStyler-1.7.1.tar.bz2, when b1 is neta
[05:47] <fabrice_sp> s/neta/beta/
[05:48] <edajai> k
[05:48] <fabrice_sp> How can I get that 1.7.1 is newer than 1.7.1b1 ?
[05:48] <dholbach> fabrice_sp:
[05:48] <dholbach> daniel@lovegood:~$ dpkg --compare-versions 1.7.1b1 gt 1.7.1 && echo TRUE
[05:48] <dholbach> TRUE
[05:48] <dholbach> daniel@lovegood:~$
[05:48] <dholbach> seems that upstream's to blame
[05:49] <dholbach> wow... we're at bug 299776 now
[05:49] <fabrice_sp> dholbach: that's what I thought :-)
[05:49] <fabrice_sp> thanks
[05:49] <dholbach> I guess today we'll get to bug 300000
[05:49] <dholbach> ubottu: not yet
[05:50] <fabrice_sp> do we have stats on bugs/versions? Just curious :-)
[05:50] <dholbach> we should have, if you ask me :)
[05:50] <fabrice_sp> lol
[05:51] <edajai> just curious.. is there any work being done on delta deb upgrades??
[05:52] <persia> fabrice_sp, You might want to look at uversionmangle in the uscan manpage.  changing the 'b' to "~b" might do it.
[05:53] <persia> fabrice_sp, If you do that, you probably also want to adjust 'a' in case upstream releases an alpha, rather than a beta.
[05:54] <fabrice_sp> persia: there have been alpha, so I'll have a look at that! Thanks!
[06:19] <fabrice_sp> It worked! Thanks persia for the solution! This is the line I put: opts=uversionmangle=s/b/~b/;s/a/~a/
[06:20] <persia> fabrice_sp, Would you mind adding some documentation on that hint, and the specific regex to the wiki page on creating watch files?
[06:20] <persia> This is the second or third time I've seen the question, and I think maybe the uscan manpage language isn't accessible to some people.
[06:21] <persia> fabrice_sp, Also, you might consider something like /([a-z])/~$1/ (if I remember perl correctly) to generalize rather than calling two match expressions.
[06:28] <fabrice_sp> persia: I'll have a look at the wiki, but that's true that as it's perl regex, it's not so easy :-)
[06:29] <persia> fabrice_sp, If you can't get the perl syntax right, that's fine.  Just the hint for 'a' and 'b' will probably save a lot of people pain.
[06:31] <fabrice_sp> I'm used to vi, so I know this kind of regex, but as it's perl, it's a bit different. For sure it's not simple :-)
[06:31] <fabrice_sp> Anyway, I'll update the wiki :-)
[06:40] <Hobbsee> rainct: oh, thanks.
[08:38] <slytherin> geser: FYI ... about 20 jboss related packages have entered 'NEW' queue in Debian main. Let's hop our build failures will get solved this time.
[08:43] <eMerzh> if someone can review  my package http://revu.ubuntuwire.com/details.py?package=sqliteman ....
[09:05] <bain> can somebody help me and review http://revu.ubuntuwire.com/details.py?package=teamgit
[09:10] <geser> slytherin: that would be awesome
[09:16] <iulian> bain: It seems that is something like git-cola. http://cola.tuxfamily.org/screenshots.php.
[09:16] <iulian> bain: I will have a look at it when I get back home from school.
[09:16] <bain> iulian, yes its something like git-cola but with different ultimate goals
[09:16] <iulian> Looks interesting, I wonder what it can do.
[09:16] <iulian> OK.
[09:17] <bain> iulian, thanks, is it a bad thing to have two packages doing similar thigns?
[09:18] <iulian> bain: I believe not. But IMHO we should keep the one which is the best.
[09:18] <bain> iulian, teamgit will be the best ;-) (hint i am the author :p )
[09:19] <iulian> Yes, I saw :)
[10:43] <joaopinto> Hello
[10:44] <joaopinto> any MOTUs around ?
[10:46] <persia> Probably about half of the active ones.  Better to ask a specific question, as it collects more interest.
[10:47] <joaopinto> the usual approach I had to ask that specific question every 10 joins or so, without much results, I am trying a new approach
[10:47] <joaopinto> can someone advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[10:48] <persia> Oh.  Yeah.  That question doesn't tend to collect much interest except on REVU days, unless someone is particularly bored.
[10:48] <persia> Also, it's probably better to ask for a review than an advocation.
[10:48] <joaopinto> I already got enough reviews, I believe its the proper time for advocation
[10:49] <joaopinto> 4 months reviewing should be sufficient
[10:49] <persia> Well, a review will result in an advocation if it's ready.
[10:49] <RAOF> Unless you've already got one advocate; once you've got one, advertising the fact is a good idea.
[10:49] <persia> Also, there were only one or two REVU days during intrepid, so it's really only been about 3 weeks that the queue has been being processed much.
[10:50] <persia> RAOF, Good point.
[10:50]  * persia usually looks for one-advocate packages with problems.
[10:50] <joaopinto> persia, the package was already reviewed before intrepid, that counts because the package was not started from scratch
[10:52] <joaopinto> I am confident on the package status, that is why I am asking for someone with the ability to advocate
[10:53] <persia> joaopinto, Where can I get the originals for the art?  Or where is this stated?  I don't see it from my quick look so far, but it appears to be a requirement of the license.
[10:54] <joaopinto> which originals ? The art is contained on the source
[10:54] <persia> joaopinto, The license for the art requires that the recipient be provided with information to collect the originals.
[10:54] <persia> I don't know where the originals live, or anything about them.  If you also don't, I think you've a bit of investigation to do.
[10:55] <joaopinto> "the originals" are contained on the source
[10:56] <persia> Surely that's the distributed copy.
[10:56]  * persia reads the license again
[10:56] <persia> Also, in the ,desktop file, why drop the category "LogicGame", and why add "StartupNotify=true"?
[10:58] <persia> No, it clearly states "You can freely distribute the copies of these works, modified or not, whatever their medium, wherever you wish, for a fee or for free, if you observe all the following conditions: ... specify to the recipient where he will be able to access the originals  (original and subsequent)."
[10:59] <persia> From my reading, it just needs a URL somewhere.  Maybe it's in the README (haven't gotten to that file yet).
[10:59] <joaopinto> persia, that statement applies to derivated/modificated work, the artwork distributed is the "originals"
[10:59] <persia> "modified or not"
[11:00] <joaopinto> persia, the download link is on the top of the copyright, that covers the "originals" availability requirement
[11:00] <joaopinto> regarding startupnotify, what is wrong on using it ?
[11:00]  * persia refuses to argue, but will need to find a link somewhere to advocate with that license
[11:01] <persia> If the application doesn't support it, it hangs a process for 120 seconds.
[11:02] <joaopinto> how is that checked, exit code ?
[11:03] <persia> I'm not 100% sure, but my understanding is that it's a window manager hint callback that the application can use to say "I've started cleanly".  There's a hardcoded 120 second timeout to stop the "Starting application" pointer if it's not supported, but it's best to only use it when it is supported.
[11:03] <joaopinto> persia, be more specific, what link do you need related to the license, there is a link which points to the page from where you can get the original art..
[11:03] <joaopinto> ok, I will update the desktop patch
[11:03] <persia> joaopinto, Yes.  I'll be looking at that.  I've not gotten to it yet.
[11:07] <persia> joaopinto, Your watchfile doesn't work for me.
[11:09] <joaopinto> persia, please post the comments on revu, I will only be able to fix the package later today :\
[11:09] <persia> joaopinto, Oh, sure.  No problem.
[11:16] <eMerzh> persia, if you are in a reviewing mood , please consider watching my pkg (http://revu.ubuntuwire.com/details.py?package=sqliteman) .. thanks a lot!
[11:28] <persia> eMerzh, I'll take a quick look, but am still running the processing for the amoebax review.
[11:28] <persia> eMerzh, No point mentioning debian/patches/00list in the changelog.
[11:29] <persia> Be good to have a README.source
[11:29] <eMerzh> oki thanks persia
[11:29] <eMerzh> ok
[11:30] <persia> Better to use /usr/share/cdbs/1/rules/dpatch.mk than the mess you have in debian/rules
[11:31] <persia> ALso, make triple-sure README isn't ending up in the binary package, as it's useless for end-users, but CDBS might try to include it by default.
[11:31] <persia> Nothing else obvious from glancing through debian/
[11:49] <eMerzh> persia, what should be in the README.source?
[11:52] <persia> eMerzh, http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource but ideally you want to point at common shared instructions for dpatch.
[12:08] <slytherin> eMerzh: https://wiki.ubuntu.com/README.sourceHowTo
[12:09] <persia> (note especially the note on the top of the page that it is becoming obsolete)
[12:10] <eMerzh> ah ok, thanks slytherin ...how should i point to /usr/share/doc/dpatch/README.source.gz ?
[12:16] <slytherin> eMerzh: no idea. persia, can you please help with that question ^^?
[12:16] <eMerzh> :)
[12:20] <persia> Just some informal text.  Something like "This package uses dpatch for patch management.  Please see usr/share/doc/dpatch/README.source.gz for usage details" or something.
[15:19] <directhex> hm. how much pain and/or stabbing is involved in bundling a non-final RC or pre-RC of something into a release, then SRUing the hell out of it ASAP?
[15:20] <persia> directhex, Heaps.  SRUs should be cherrypicks, except when there is a *very* convincing reason.
[15:20] <jdong> the latter part will be a pain, the former part will not.
[15:27] <directhex> monodevelop has been ancient and crap for ages - but upstream have been warning us not to try and use a pre-release alpha tarball as something to support for months on end. the next major release is due in 3-4 months
[15:29] <persia> Right.  Push to Jaunty,  Track upstream, and get final in the release.
[15:29] <persia> backport final to intrepid/hardy.  Let the cruft remain otherwise.
[15:29]  * persia isn't on the SRU team, but is opinionated
[15:30] <slytherin> directhex: is the situation similar to how it was for FF 3.0 beta in hardy?
[15:30] <directhex> persia, i wasn't actually talking about intrepid/hardy (it needs a new mono stack, so won't happen officially). i really meant for jaunty, since it's likely to miss assorted freezes
[15:30] <directhex> slytherin, AFAIK yes
[15:31] <persia> directhex, If you want to pre-check with MOTU release, send mail to ubuntu-motu@lists.ubuntu.com describing the plan,and asking for MOTU release acceptance in advance.
[15:32] <directhex> persia, as someone who isn't on the SRU team, but is opinionated, would you back a hardy-ff3-style plan?
[15:32] <slytherin> directhex: You might also consider freeze exception depending on when the final release comes out.
[15:33] <persia> directhex, If you're not SRUing, it's not an SRU decision: it's a Release decision.  Personally, I don't like to see snapshots in releases, but if you're sure you can get a real release for e.g. beta, I'd think it was good (but it's really a MOTU Release decision).
[16:16] <kirkland> nixternal: geser: hey guys ...  would you mind voting on my core-dev application sometime soon?  thanks, cheers.
[16:19] <nixternal> kirkland: I voted a while back
[16:23] <directhex> persia, there we go, ML mailed. i hope i've described the situation adequately
[16:24] <persia> directhex, Cool.
[16:24] <kirkland> nixternal: hey, hmm, i don't see it, in my inbox, or in the threaded archive
[16:24] <kirkland> nixternal: i have your vote for my MOTU, back in September
[16:25] <kirkland> nixternal: this is for core-dev, https://lists.ubuntu.com/archives/motu-council/2008-October/001725.html
[16:29] <nixternal> kirkland: you are right, I sent it to persia only...I just resent it to the list...I apologize for that
[16:30] <persia> So this is why I was sure you'd voted :)
[16:30] <kirkland> nixternal: awesome, thanks ;-)
[16:31] <nixternal> persia: hehe, ya :)
[16:41] <geser> kirkland: I try to get it done today, actually I just wanted to start on it
[16:41] <frafu> Hello, I am trying to add a gconf schemas file to a debian source python debian package, but there remains an entry in the gconf database after uninstalling the package. I described the problem in the following thread: http://ubuntuforums.org/showthread.php?t=984014 Could anybody please tell me where the problem?
[16:57] <kirkland> geser: great, thanks!
[17:08] <frafu> What I don't understand is why "gconf-schemas --unregister onboard.schemas" does not delete everything in the gconf database!? What could be the reason? If somebody has an idea that would be great.
[17:20] <JonReagan> is there any order to the REVU process?
[17:20] <JonReagan> like, the first packages in are the ones that get reviewed first?
[17:22] <mok0> JonReagan: not really
[17:22] <JonReagan> ah, thx
[17:22] <mok0> JonReagan: although we are trying to work through the backlog
[17:23] <JonReagan> ah, lol... yeah I noticed there were quite a few
[17:24] <JonReagan> good problem to have i guess
[17:24] <mok0> It overwhelming
[17:24] <JonReagan> yeah... sorry.  I uploaded mine this morning ;)
[17:24] <mok0> JonReagan: except not everyone who uploads has the stamina to keep going
[17:25] <JonReagan> ah
[17:25] <mok0> So there's a lot of wasted time and effort
[17:25] <JonReagan> ah, that's not good
[17:25] <mok0> And many MOTUs don't really want new software in Universe
[17:26] <JonReagan> ah
[17:26] <JonReagan> well, I'm dedicated on working on my package, so at least that's one not to be worried about.
[17:26] <JonReagan> :)
[17:26] <mok0> JonReagan: There's > 1000 packages to maintain
[17:26] <JonReagan> !
[17:27] <mok0> JonReagan: what package?
[17:27] <JonReagan> openproj
[17:27] <JonReagan> version 1.4, to be exact
[17:27] <JonReagan> it's my first package upload to revu
[17:27] <mok0> JonReagan: I'll take a quick look
[17:27]  * JonReagan does happy dance
[17:28] <JonReagan> oh, thank you so much!
[17:28] <JonReagan> http://revu.ubuntuwire.com/details.py?package=openproj - here's the link
[17:28] <mok0> JonReagan: you've been maintaining this for your own use?
[17:29] <JonReagan> for my own use?
[17:30] <JonReagan> I was hoping that it would find it's way into some repo for Ubuntu, either universe or multiverse
[17:30] <mok0> JonReagan: it's not been in a distro
[17:30] <JonReagan> not included in one yet
[17:31] <JonReagan> Ubuntu will be the first one
[17:31] <mok0> ok
[17:32] <mok0> JonReagan: you need to take the debian/ dir out of the tarball
[17:32] <mok0> JonReagan: since this is not a native package.
[17:32] <JonReagan> ah, ok
[17:33] <JonReagan> to upload the tarball after I have removed the debian folders, is there anything different from uploading the package with dput?
[17:33] <mok0> JonReagan: (I also make a comment on revu)
[17:33] <JonReagan> ah, thanks
[17:34] <mok0> JonReagan: lets get to that later
[17:34] <JonReagan> k
[17:36] <mok0> JonReagan: in debian/changelog, you have to trim it down to the latest version. We are only interested in what happens after Ubuntu submission
[17:36] <JonReagan> ok
[17:37] <mok0> distribution is jaunty not GA
[17:37] <JonReagan> k
[17:38] <JonReagan> just so I'll know... these changes need to be made in the original tarball and then recompiled for upload to revu?
[17:38] <mok0> JonReagan: and version will be (1.4-0ubuntu1)
[17:38]  * JonReagan writes it down
[17:39] <mok0> JonReagan: I am pasting my comments to REVU  as well
[17:39] <JonReagan> thanks!
[17:39] <mok0> JonReagan: did you create a needs-packaging bug on LP?
[17:40] <JonReagan> yes I did... it got marked as a duplicate, however
[17:40] <JonReagan> the other bug was a request for openproj that I had made a year ealier
[17:40] <JonReagan> *earlier
[17:40] <JonReagan> and the request was for an old version
[17:40] <mok0> JonReagan: you need to close the LP bug in the changelog
[17:40] <JonReagan> ok
[17:42] <mok0> JonReagan: debian/control now
[17:43] <eMerzh> after compiling and installing, my package at "dpkg-genchanges: failure: cannot read files list file: No such file or directory" .... anyone has an idea how to fix it? google don't help me much on this....
[17:43] <eMerzh> i change arch from any to all , but always the same pbm
[17:44] <JonReagan> do I need to place a link to the new lp bug in the changelog and debian/control?
[17:44] <mok0> JonReagan: Maintainer is:  Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[17:44] <mok0> JonReagan: you will be XSBC-Original-Maintainer:
[17:44] <JonReagan> ah, wondered about that... thanks
[17:45] <mok0> JonReagan: Standards-Version is 3.8.0 now
[17:45] <JonReagan> ah... k
[17:45] <mok0> Is there a homepage for this app?
[17:46] <JonReagan> openproj.org
[17:47] <mok0> JonReagan: You need to work more on the long description. Look at the hints in the Debian Maintainers Guide
[17:47] <JonReagan> ok
[17:48] <mok0> JonReagan: Lemme just see if I can find a link for that
[17:49] <JonReagan> oh, thanks... I was hittin up google now
[17:50] <NCommander> AHAHAH
[17:50] <NCommander> I got bug #3000000
[17:50] <NCommander> I got bug #300000
[17:50] <NCommander> :-P
[17:51] <jdong> IT'S OVER 3000000!!!!!
[17:51] <jdong> (sorry :D)
[17:53] <JonReagan> mok0:  I found it
[17:53] <mok0> http://www.debian.org/doc/maint-guide/
[17:53] <JonReagan> thx
[17:54] <mok0> I think this is where I've seen the instructions on how to write a proper long description
[17:55] <iulian> jdong: That should be a bad things, isn't it?
[17:55] <iulian> s/things/thing/
[17:55] <bain> iulian, I fixed the teamgit package according to your comments
[17:56] <mok0> JonReagan: OK I have submitted a comment for your package, which will now appear in the "needs work" section... :-)
[17:56] <JonReagan> ah, thank you so much! :D
[17:56] <JonReagan> you have been a ton of help!
[17:56] <mok0> JonReagan: when you "dput" your changes file next time, it should include a diff.gz file that contains the debian/ dir (and nothing else)
[17:57] <mok0> JonReagan: glad to be of help :-)
[17:57] <iulian> bain: OK, will have a look at it again in a moment.
[17:57] <JonReagan> ah, k thx
[17:57] <mok0> JonReagan: I am not good at Java packages, so I have skipped some things for now
[17:58] <JonReagan> ok, I know some java folks who might be able to help me out on those
[17:58] <mok0> OK, dinnertime :-P
[17:58] <JonReagan> lunchtime for me ;)
[17:58] <mok0> JonReagan: it's more about Ubuntu policy
[17:58] <iulian> JonReagan: You might want to talk to slytherin or geser. They are good at Java packaging.
[17:59] <mok0> JonReagan: where to place things etc.
[17:59] <mok0> Bon appetit! hehe
[17:59] <bain> iulian, judging from mok0's comments my diff.gz contains few files that are not correct
[17:59] <JonReagan> ah, ok.  Thanks!  I will get to work on the stuff you recommended
[17:59] <bain> iulian, will fix and report back here
[17:59] <mok0> iulian: just saw your PM... I'll be back later
[18:00] <JonReagan> ooh, after I finish the fixes, do I need to recompile the original source file?
[18:01] <eMerzh> someone could help me to remove the README from the installed file?
[18:02] <iulian> JonReagan: Build the package and upload it again.
[18:03] <JonReagan> ah, thanks!
[18:03] <iulian> eMerzh: Upstream's README?
[18:03] <JonReagan> thank you so much everyone!
[18:06] <bain> iulian, did the fix please review it whenever possible thanks
[18:06] <eMerzh> iulian, yep the readme about how to compile ,...
[18:08] <iulian> eMerzh: You can remove it from the debian/docs file. Sometimes README files are very useful but sometimes aren't, please double check when you remove it.
[18:08] <iulian> bain: OK, I'm looking at it now.
[18:14] <iulian> bain: I see that it's a native package. Do you want to ship the debian/ dir in the original tarball?
[18:14] <iulian> Or it's just a mistake?
[18:14] <slytherin> geser: do you mind if I work on libjdic-java merge/sync?
[18:14] <bain> iulian,  no i do want to ship it
[18:14] <iulian> bain: Then please remove it.
[18:15] <iulian> Ahh, you do want.
[18:15] <iulian> Sorry, misread.
[18:15] <eMerzh> iulian, i don't have it in a debian/docs ....i haven't a docs file :)
[18:17] <iulian> bain: Remove -0 from the version since it's a native package.
[18:17] <bain> iulian, ok should i do it now or wait for more of your comments
[18:18] <iulian> bain: What's with that debian/clean file? Please add that in the clean target in debian/rules.
[18:19] <bain> iulian, actually i did that acting on your comment "Please merge rm -rf into dh_clean."
[18:20] <bain> i obviously misunderstood
[18:20] <iulian> bain: I didn't tell anything about creating a debian/clean file :)
[18:21] <bain> so i should just add the listing in the rules file in front of dh_clean?
[18:23] <geser> slytherin: no, please go ahead
[18:24] <iulian> bain: $(MAKE) clean should do it for you.
[18:24] <geser> kirkland: done
[18:24] <iulian> bain: Please rename that to [ ! -f Makefile ] || $(MAKE) clean
[18:26] <bain> iulian, make clean does not get rid of these files
[18:26] <bain> i use qmake for generating makefiles and can't figure out how to do that
[18:27] <iulian> bain: Well, I've never worked with qmake so I can't give you any advice about it.
[18:28] <iulian> Perhaps someone from this channel knows?
[18:29] <bain> iulian, ok make distclean will do it, can i change to that?
[18:30] <iulian> bain: If it does, yes.
[18:30] <iulian> In the end we're trying to get rid of unwanted files.
[18:40]  * iulian is going to school to take his notebook.
[18:40] <iulian> I obviously forgot about it.
[18:40] <bain> iulian, ok i have almost fixed all the things you told so far, thanks for your help
[18:41] <bain> iulian, review whenever you get time next chao
[18:42] <iulian> bain: OK, good. Will review it again when I get back home. School is not so far.
[18:43] <bain> iulian, i won't be on irc as this is past midnight here in india please leave a comment ... thanks again for your help
[19:33] <serialorder> anyone around?
[19:34] <geser> depends on what you need
[19:36] <serialorder> well then you are probably not around =)
[19:37] <serialorder> I am interested in contributing, I have read quite a bit of the documentation on the MOTU wiki but the process still seems rather opaque to me
[19:37] <geser> where are you stuck?
[19:39] <serialorder> a lot of the technical parts are pretty clear, retrieving a source, applying a change, rebuilding etc...
[19:40] <serialorder> the hard part is actually finding something that needs to be done, I have looked in launchpad and that is just a bit overwhelming
[19:42] <geser> have you a software/package where are you interested in? if yes, you could check their bugs for example
[19:43]  * geser checks if there are some bitesize tagged bugs
[19:45] <geser> you could also check the pending merges (if you're interested) and work on them (after coordinating with the previous uploader)
[19:46] <serialorder> im going to look around for that
[19:49] <geser> there are many tasks so I often have problems to point people to one specific task as it depends on what someone is interested in
[19:52] <serialorder> I guess I am also not sure of exactly what my interests are, as funny as that sounds
[19:53] <serialorder> sadly, there is not one package that I am absolutely enamored with or anything
[19:53] <serialorder> just sort of want to help fix things
[19:58] <NCommander> hey geser
[19:59] <geser> Hi NCommander
[19:59] <NCommander> geser, how goes it?
[20:00] <geser> good, just to much work has accumulated in the past and this doesn't actually increase my motivation to work on it :(
[20:01] <nixternal> anyone have a good link for docs that would help me setup my own local buildd here at work?
[20:02] <nixternal> would love to have a setup similar to what we have now, where people will upload (dput), and then I have to approve or deny the packages
[20:03] <geser> nixternal: iirc NCommander has already set one buildd up
[20:04] <nixternal> NCommander: you better help me then :)
[20:04] <NCommander> nixternal, aka, you want something with a NEW queue, right?
[20:04] <nixternal> don't want to spend a lot of time doing it, but would like to get it up soon so I can start working on a migration path for our appliances here
[20:04] <nixternal> NCommander: yes
[20:04] <NCommander> nixternal, then you want dak
[20:04] <NCommander> Which kills the "don't want to spend a lot of time doing it" requirement
[20:05] <nixternal> hehe
[20:05] <nixternal> figures
[20:05] <NCommander> It's not that bad
[20:05] <NCommander> WHen do you want it by?
[20:05] <nixternal> next few weeks
[20:05] <NCommander> actually
[20:05] <NCommander> WHere are you in the world nixternal ?
[20:05] <nixternal> I have time to spend on it, just didn't :)
[20:05] <nixternal> Chicago silly
[20:05] <NCommander> right
[20:05] <NCommander> Well
[20:05] <NCommander> Two choices
[20:05] <NCommander> We do it at UDS
[20:05] <NCommander> You give me the couch and I drive to Chicago
[20:06] <nixternal> that could be a viable option actually
[20:09] <NCommander> whihc nixternal which one?
[20:14] <NCommander> nixternal, I can come to Chicago a week and a half from now
[20:14] <ScottK> nixternal: Careful.  He'll do it.
[20:15] <NCommander> ScottK, you know me too well :-P
[20:16] <NCommander> ports.u.c just went down ...
[20:16] <NCommander> bah
[20:18] <NCommander> nixternal, ?
[20:22] <shay> hello
[20:22] <shay> anyone here involved with Xen support on Ubuntu?
[20:26] <nixternal> NCommander: get together at UDS possibly
[20:26] <geser> shay: try #ubuntu-kernel or contacting zul
[20:27] <NCommander> nixternal, you need a build machine the same architecture(s) you want, a machine to run wanna-build and wanna-persue on, and all buildds must be able to send email
[20:27] <shay> thanks geser
[20:27] <nixternal> ya, looking at that now
[20:45] <leonel> ScottK: not all the patches you sent   can be applied
[20:45] <leonel> ScottK: still working
[21:06] <ScottK> leonel: It doesn't suprise me not all of them are relevant to 0.92.1.  Thanks for working on this.  I know it's a lot.
[21:11] <directhex> NCommander, did you file that armel bug yet, or am i not getting mail from bugs.debian.org?
[21:11] <NCommander> I hadn't filed the bug yet
[21:11] <kirkland> geser: cheers!  thanks.
[21:22] <ryanakca> RainCT: ah... he means to stick some # comments in the patchfile ... ## patch_name.diff by Me <me@foo.bar>\n ## <Description of patch>
[21:40] <jdong> asac: drive-by: How serious is xulrunner about breaking yelp < 2.22.1-0ubuntu2.8.04.1? I'm guessing backports should rebuild a yelp.
[21:46] <serialorder> anyone available to answer a quick question?
[21:46] <directhex> no
[21:46] <directhex> nobody
[21:46] <serialorder> its an easy one
[21:46] <serialorder> i think
[21:46] <serialorder> I have performed my first merge
[21:47] <serialorder> I created a new dsc, verified it works with pbuilder and hav created two debdiffs one between the new dsc and the debian dsc and another between the new dsc and the previous ubuntu dsc
[21:47] <serialorder> Basically I followed this guide: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[21:47] <serialorder> problem is I dont know what to do to get it accepted now
[21:54] <directhex> serialorder, well, file a merge bug on launchpad. that's a good step
[22:06] <geser> serialorder: now the usual sponsorship process applies, see https://wiki.ubuntu.com/SponsorshipProcess
[22:08] <serialorder> apparently launchpad is offline for maintenance right now
[22:10] <savvas> "Launchpad is down from until 23:59 UTC for a code update"
[22:10] <serialorder> im trying to figure out which files i need to attach in launchpad
[22:11] <serialorder> when it comes back online fo course
[22:14] <NCommander> -_-;
[22:20] <NCommander> emgent, poke
[22:20] <directhex> bugs.debian.org isn't down though
[22:23] <NCommander> Now that LP is down ...
[22:24] <binarymutant> does bugs.debian.org publish their uprecords somewhere?
[22:36] <ethana2> I wish bugs were things we could just brutally murder with our own bare hands
[22:37] <ethana2> if my machine sometimes fails to suspend, how do I find out why it did?
[22:38] <ethana2> Meh, back to figuring out what a watch file is..
[22:42] <NCommander> etank, a watch file is a file that check against upstream, and notifies Ubuntu Developers when a new updated release is made available
[22:54] <Yasumoto> so if I've attached a debdiff to a bug
[22:55] <Yasumoto> is there typically anything else I should do to get it in jaunty/backported to intrepid?
[22:55] <Yasumoto> (it includes a testcase in the description)
[22:56] <savvas> I think you have to subscribe the ubuntu sponsors to the bug
[22:56] <savvas> not sure though
[22:56] <savvas> and you'll have to wait, since launchpad is down for maintenance :)
[22:57] <Yasumoto> yeah, haha
[22:57] <Yasumoto> Otherwise I would have added the link
[22:57] <Yasumoto> It's a fix for a program called "xournal" which tablet pc users apparently use a lot
[22:58] <savvas> it will probably make it in jaunty, but as I've seen from other bug reports, it has to stay a bit in jaunty before it gets backported
[22:59] <Yasumoto> yeah, for sure
[23:00] <Yasumoto> thanks savvas :)
[23:01] <savvas> n/p Yasumoto - of course, you can always build a "test" package for intrepid through Launchpad's PPA ;)
[23:01] <Yasumoto> ah
[23:01] <Yasumoto> I totally forgot about PPA
[23:01] <Yasumoto> good idea, that should help a lot :)
[23:02] <Yasumoto> there's a lot of noise on the bug, some people have added .deb's they've made as attachments
[23:06] <etank> NCommander: ok??
[23:07] <etank> oh i see. that was for ethana2 not me
[23:09] <directhex> NCommander, minor tweak needed to apply against 2.0.1
 debian-pkg-mono: directhex-guest * r3774 /mono/trunk/debian/ (changelog patches/00list patches/armel-glibc-2.8.dpatch): Fix armel FTBFS on glibc 2.8
[23:21] <NCommander> directhex, ah, I didn't check to see if it cleanly applied ;-)
[23:21] <directhex> NCommander, there's a platform test in there for iphone
[23:21] <directhex>  #if !defined(PLATFORM_MACOSX)
[23:22] <NCommander> Ah
[23:22] <NCommander> No problem
[23:36] <asac> jdong: gutsy?
[23:40] <jdong> asac: correct
[23:43] <asac> jdong: does it cause issues?
[23:44] <asac> jdong: imo it doesn't interfere with gutsy yelp
[23:49] <jdong> asac: ok, I think you might be right, the check is probably extraneous
[23:49] <jdong> I will do some virtual machine testing and see
[23:49] <jdong> if that's the case then I'll remove that conflicts.
[23:49] <asac> jdong: what conflict?
[23:49] <asac> oh ... the conflict came from the hardy package?
[23:49] <kirkland> kees: ping
[23:50] <jdong> asac: correct
[23:50] <asac> yeah. should be dropped in backport then
[23:50] <asac> all conflicts
[23:50] <kirkland> kees: i'm working with mikeowens on that bogosec package
[23:50] <jdong> asac: ok, thanks
[23:50] <asac> well ... alls app conflicts
[23:50] <kirkland> kees: i wanted to explain one thing here, regarding your questions about rpm and dpkg-dev ....
[23:50] <kees> kirkland: ponng
[23:50] <kees> kirkland: I'm all ears :)
[23:50] <kirkland> kees: those two utilities are required *only* if you want to use bogosec to scan source packages (.src.rpm's or .dsc files)
[23:51] <kirkland> kees: that's why i set them as suggests
[23:51] <kirkland> kees: it'll continue to operate just fine on exploded source trees, and tarballs
[23:51] <kirkland> kees: perhaps Recommends might be better?
[23:51] <kirkland> kees: but i don't think Depends is right
[23:52] <kees> kirkland: fair enough.  it seems like it fails pretty unexpectedly if they're not installed.
[23:52] <kees> I would agree not Depends.  Recommends might be a better idea.
[23:52] <kirkland> kees: yeah, i think i might handle that in the source code itself, do a 'which', and explain the situation
[23:52] <kirkland> kees: coolio, thanks.
[23:52] <kirkland> kees: also, meet mikeowens ;-)
[23:53] <mikeowens> kees: hey kees
[23:53] <kirkland> kees: he's been doing some good work on this one, and conmux;  has a unique interest in packaging things from scratch :-D
[23:54] <kees> heya mikeowens!  :)
[23:54] <mikeowens> kees: thanks for the input
[23:54] <mikeowens> kees: dustin's been great (patient)
[23:55] <kees> I'm looking forward to getting bogosec in -- I like the idea of keeping a time-line of its output for the other packages.  :)
[23:55] <kees> mikeowens: cool!  :)