[12:20] <icf7> Is there any way to require "Any JDK which supports >= 1.5" ?
[12:21] <geser> icf7: you could add all working JDK to the Depends
[12:22] <icf7> geser: Thats my current solution, but it is certainly not as nice as the gentoo version >=virtual/jdk-1.5 . Thank you anyway
[12:23] <minghua> icf7: that requires all the JDK package maintainers to agree on the name of the virtual package, then change each JDK package to provide it
[12:24] <minghua> icf7: in other words, doable, but need quite some effort
[12:26] <icf7> minghua: Thank you, I'll think about launching such a proposal
[12:30] <minghua> icf7: actually, there are already a bunch of java-related virtual packages, but I don't know versioned virtual packages work or not (I suspect they don't).
[12:58] <StevenHarperUK> Hi I need help My source.changes file has an error : I get this when I try to upload to REVU : Unable to find distrorelease: unstable   
[12:58] <StevenHarperUK> what do I need to change please
[12:59] <StevenHarperUK> Do I need another line in my debian/control file?
[01:00] <icf7> StevenHarperUK: You should change that to an Ubuntu version, like "feisty" or "gutsy"
[01:01] <StevenHarperUK> Think I just found it : its in the chnagelog yeh?
[01:01] <icf7> StevenHarperUK: exactly
[01:01] <StevenHarperUK> Thanks
[01:01] <StevenHarperUK> Ill retry
[01:04] <StevenHarperUK> Ah : Ok im getting Already uploaded to upload.ubuntu.com Doing nothing for usbadslmodemmanager_0.5.2_source.changes : do I really have to go up a version number - or is there a way or re-submitting
[01:05] <jussi01> StevenHarperUK: are you uploading to revu?
[01:05] <StevenHarperUK> Yes
[01:05] <jussi01> dput -f revu 
[01:06] <StevenHarperUK> ta
[01:06] <jussi01> ;)
[01:06] <mok_> Any MOTUs around?
[01:07] <mok_> ... or just bots?
[01:07] <crimsun> please don't ask to ask.  Just ask, then we'll process things when we get around to them.
[01:07] <StevenHarperUK> OK the upload is working now ...Do I need to get a MOTU to clear my broken one, or will it just work?
[01:08] <crimsun> StevenHarperUK: your previous upload to the Ubuntu repository has been rejected automatically.
[01:08] <StevenHarperUK> And will my new one et processed?
[01:08] <mok_> I need someone to help me look at some packages I uploaded to REVU
[01:08] <crimsun> StevenHarperUK: if it's valid, yes
[01:09] <StevenHarperUK> Thanks : ill watch me Email
[01:12] <StevenHarperUK> ok im back : Signer has no upload rights at all to this distribution. : new error...
[01:13] <StevenHarperUK> I submitted my Key today : I guess a sync hasn't happened yet
[01:14] <mok_> I think it's synced once a day
[01:15] <StevenHarperUK> Ok ill re-try tommorow : unless we have a MOTU that can re-sync RevU?
[01:16] <mok_> StevenHarperUK: I just went through my first upload. Looking for advocates now...
[01:17] <imbrandon> StevenHarperUK, give it a few minutes, i just kicked off a manual sync
[01:17] <crimsun> that keyring sync takes about 2 hours
[01:17] <imbrandon> should be about ~15 minutes to finish ( maybe less )
[01:17] <imbrandon> crimsun, huh ?
[01:17] <crimsun> tiber is experiencing network difficulties
[01:17] <imbrandon> ahh shiznit
[01:17] <StevenHarperUK> Yeh im on first upload too
[01:17] <StevenHarperUK> Ta imbrandson
[01:18] <imbrandon> crimsun, seems to be working fairly quickly , might be a fluke
[01:18] <imbrandon> or stall in a minute
[01:18] <crimsun> imbrandon: ok.  Not logged in ATM.
[01:18] <mok_> StevenHarperUK: What's your package?
[01:18] <StevenHarperUK> Can you tell when its finished?
[01:18] <imbrandon> crimsun, its doing about one key per 5 seconds looks like
[01:18] <StevenHarperUK> usbadslmodemmanager http://www.squeezedonkey.com/wiki/linux
[01:19] <imbrandon> StevenHarperUK, sure
[01:19] <StevenHarperUK> mok_ : yours?
[01:19] <mok_> I packaged kssh, which strangely is missing 
[01:20] <imbrandon> crimsun, i got my daughter today /me is sooo happy, just took her home
[01:20] <mok_> ... and some bioinformatics tools
[01:20] <jmg> imbrandon: congratulations
[01:20] <StevenHarperUK> Well done : your first?
[01:20] <imbrandon> me and her mom might be getting back togather
[01:20] <mok_> Yes
[01:20] <imbrandon> StevenHarperUK, jmg , she's 10 :)
[01:20] <crimsun> imbrandon: excellent!  Best of luck there!
[01:20] <StevenHarperUK> ah right
[01:20] <StevenHarperUK> My oldest is 10
[01:20] <mok_> I've been packaging RPMs for years
[01:20] <imbrandon> RPM and DEB == whole diffrent world :)
[01:21] <jmg> yeah
[01:21] <StevenHarperUK> This is first ever Package of ANY kind
[01:21] <imbrandon> i did suse rpm's for years, took me ages to get used to debs
[01:21] <jmg> think of deb as rpm minus the suck
[01:21] <StevenHarperUK> But I have been developing APps for 14 years
[01:21] <imbrandon> jmg, exactly :) more like dpkg++
[01:21] <imbrandon> crimsun, thanks :)
[01:21] <mok_> Not really, but the organization surrounding the packaging is chaotic
[01:22] <crimsun> mok_: where "packaging"-> RPM or DEB?
[01:22] <StevenHarperUK> I Agree : if its a C package it well documented
[01:22] <StevenHarperUK> I resorted to downloading some one elses Source package and having a look about it
[01:22] <imbrandon> seems the key sync has slowed to a crawl, it might be a bit
[01:22] <mok_> crimsun: I recently switched to Ubuntu and I am now moving my packages to DEB format
[01:22] <StevenHarperUK> hehe
[01:23] <jrib> sorry to interrupt, would anyone like to review http://revu.tauware.de/details.py?upid=5444, a python module?
[01:23] <mok_> jrib: You have to be a MOTU to review, right?
[01:23] <crimsun> mok_: ah, so you're saying that the organisation surrounding DEBs is chaotic?
[01:23] <imbrandon> i'm not really in a good position to revu anything atm sorry, only have my windows boxen here at work
[01:23] <jmg> jrib: unusual naming scheme, shouldnt it be python-reverend?
[01:24] <mok_> crimsun: Noooo, the org. around RPMs is chaotic
[01:24] <crimsun> ah
[01:24] <crimsun> (I'm inclined to agree, but I'm biased.)
[01:24] <mok_> crimsun: Redhat only feels responsible for their 2500 packages
[01:24] <StevenHarperUK> I like DEB org, its just working out what to do in the RULES file if your doing a Python package
[01:24] <jrib> jmg: the binary package is.  I found that python-paramiko's source was just "paramiko" so I copied that
[01:25] <jmg> ah
[01:25] <StevenHarperUK> No-ones written a handy guide
[01:25] <crimsun> actually I think ScottK has
[01:25] <StevenHarperUK> A URL would be ace
[01:25] <ajmitch> morning
[01:25] <crimsun> he documented his experience working with the Debian Python policy IIRC
[01:25] <crimsun> morning ajmitch 
[01:26] <jrib> StevenHarperUK: the cdbs documentation had some examples
[01:26] <StevenHarperUK> Yeh Debian Python Policy tells you where they want stuff, How do do that with the Rules file is not so clear
[01:26] <StevenHarperUK> Thats what I use dinteh end
[01:26] <mok_> StevenHarperUK: check out cdbs
[01:26] <StevenHarperUK> ***in the End
[01:26] <StevenHarperUK> I did
[01:27] <StevenHarperUK> The disttools in Oython is a red herring
[01:27] <StevenHarperUK> in Python I mean
[01:27] <mok_> I haven't packaged any python modules yet, but I'm going to...
[01:27] <StevenHarperUK> I wasted about 14 hours on that
[01:27] <jmg> StevenHarperUK: ouch
[01:27] <mok_> But cdbs should work with disttools?
[01:27] <jrib> mok_: my rules file is like 3 lines with cdbs for that python module
[01:28] <StevenHarperUK> Yeh but I have spent 3 weeks on my App, so I'm keen to get it done
[01:28] <StevenHarperUK> Yeh mines about 3 lines :p
[01:28] <mok_> I guess the problem is if you need to do something extra?
[01:28] <jrib> I spent some time trying to figure out why .pyc files weren't being created only to find out I wasn't looking in the right place...
[01:29] <StevenHarperUK> The disttools is great for Pure python packages, mine has Graphics, start menu items etc....
[01:29] <mok_> Can't you write your rules file in python?
[01:29] <mok_> ... or is that not allowed?
[01:29] <StevenHarperUK> Plus i'm new to Python too : I only just started learning for this project
[01:29] <StevenHarperUK> im a Java & C++ coder really
[01:30] <StevenHarperUK> That's made it harder
[01:30] <mok_> Python is great
[01:30] <StevenHarperUK> Its good for teh Client stuff
[01:30] <StevenHarperUK> I prefer Java for Server Apps
[01:30] <crimsun> mok_: well, if you _really_ wanted to, yes.  debian/rules just needs to be executable.
[01:31] <StevenHarperUK> imbrandon: Hows that Sync coming along?
[01:32] <mok_> ... it would be possible to write a python environment for building debs that would kick b*tt..
[01:32] <imbrandon> StevenHarperUK, looks finished
[01:33] <jrib> mok_: never tried but http://docs.python.org/dist/built-dist.html
[01:33] <StevenHarperUK> Oh yes that's what Python and Debian really needs
[01:33] <StevenHarperUK> Maybe that's my next project :P
[01:33] <StevenHarperUK> ok : wish me luck
[01:34] <mok_> StevenHarperUK: I'd help out
[01:34] <StevenHarperUK> Yeh that's the one that ate 14hours of my life
[01:34] <mok_> Your first BABY!!!
[01:34] <mok_> :-)
[01:35] <StevenHarperUK> ok It's uploaded....
[01:35] <StevenHarperUK> so mok_ a nice GUI you pick a source folder, it makes teh deb and all the rest?
[01:35] <StevenHarperUK> the debian folder
[01:36] <StevenHarperUK> i mean
[01:36] <StevenHarperUK> Nice GUI to Pick menu items, auto start, init.d scripts : that's whats needed
[01:36] <mok_>  StevenHarperUK: I wasn't thinking about a GUI. More like a set of classes that you subclass and customize
[01:37] <StevenHarperUK> So a starting point?
[01:37] <StevenHarperUK> or helper tool?
[01:37] <mok_> .... and then object.compile(), obj.install() etc.
[01:37] <mok_> Yeah, a helper tool
[01:38] <StevenHarperUK> Still same Error : Signer has no upload rights at all to this distribution.
[01:38] <mok_> obj = PythonModuleBuilder(); etc
[01:38] <StevenHarperUK> can Anyone Help?
[01:38] <jrib> StevenHarperUK: what are you trying to do?
[01:38] <StevenHarperUK> Submit to REVU
[01:38] <icf7> Steven
[01:39] <icf7> StevenHarperUK: Did you forget to configure /etc/dput.conf ?
[01:39] <mok_> Dont forget to do: dput revu xxxx.source.change
[01:39] <geser> StevenHarperUK: dput revu your_pkg.changes
[01:39] <geser> else you are uploading to the Ubuntu archive
[01:39] <StevenHarperUK> ah
[01:39] <StevenHarperUK> whoops
[01:39] <StevenHarperUK> ok
[01:39] <StevenHarperUK> ta
[01:39] <mok_> It must be SOURCE.changes
[01:40] <mok_> otherwise your package gets stuck
[01:40] <StevenHarperUK> ok sending to revu now :p
[01:40] <StevenHarperUK> Yeh its source
[01:40] <mok_> So many things to learn ;-/
[01:41] <StevenHarperUK> Yeh I have been learning it for about 3-4 weeks now : I Started using Ubuntu at work 1.2 years ago, I decided I better make something
[01:41] <StevenHarperUK> OK Its finished uploading to REVU....
[01:41] <mok_> Let's go have a look...
[01:42] <crimsun> the cronjob is every 5 minutes
[01:42] <crimsun> if you just uploaded, it won't appear if accepted until after :45
[01:42] <StevenHarperUK> ah right Ill go n see how the mrs is doing then BRB
[01:42] <mok_> ... so what is the mean waiting time?
[01:43] <crimsun> define "waiting time"
[01:43] <mok_> The mean time people have to wait until the upload is visible. That number is less than 5 minutes
[01:44] <crimsun> it depends if the upload is accepted
[01:44] <mok_> duh
[01:44] <crimsun> Delivery-date: Sun, 10 Jun 2007 19:35:17 -0400
[01:44] <crimsun> validating usbadslmodemmanager_0.5.2.dsc
[01:44] <mok_> I see it! Just below my packages ;-)
[01:45] <mok_> Uhuh, StevenHarper, you have lintian errors
[01:45] <StevenHarperUK> Woohoo!
[01:45] <StevenHarperUK> What are them ?  lintian errors
[01:45] <StevenHarperUK> is there a Cream to sort it?
[01:46] <mok_> Errr Cream?
[01:46] <crimsun> yes, the cream is free
[01:47] <mok_> I got some of those source-contains-CVS---- etc, but they came in the original tarball
[01:47] <mok_> is that serious?
[01:47] <StevenHarperUK> Yeh I see them 
[01:47] <crimsun> morning emmet
[01:47] <StevenHarperUK> I have SVN ones
[01:47] <jrib> StevenHarperUK: but you got the source as a tarball?
[01:47] <persia> hello crimsun
[01:47] <StevenHarperUK> I thin you can add -I*.svn
[01:47] <StevenHarperUK> whne you build
[01:48] <StevenHarperUK> it will leave them out then
[01:48] <StevenHarperUK> -I*.csv for you
[01:48] <crimsun> doesn't `export` omit them, or am I confusing both CVS & SVN with bzr?
[01:48] <jrib> export works for svn
[01:48] <mok_> I dont think so because it looks at the orig.tar.gz so you have to remove them by hand if it matters
[01:49] <StevenHarperUK> Yeh but I make my own original
[01:49] <StevenHarperUK> so I will have to export
[01:49] <mok_> Ah
[01:49] <StevenHarperUK> Do you know what the command is?
[01:49] <StevenHarperUK> svn export?
[01:49] <jrib> yep
[01:49] <mok_> Who would have guessed :-)
[01:50] <StevenHarperUK> usbadslmodemmanager source: source-nmu-has-incorrect-version-number 0.5.2
[01:50] <StevenHarperUK> what should it be
[01:50] <StevenHarperUK> 0.5.2-1
[01:50] <StevenHarperUK> ?
[01:50] <mok_> Good question...
[01:51] <mok_> Perhaps 0.5
[01:51] <mok_> Perhaps 0.5-1
[01:51] <StevenHarperUK> I have a user base of about 100 users so I better keep tje 2
[01:51] <geser> 0.5.2-0ubuntu1
[01:51] <jrib> yeah, in the changelog
[01:52] <bluefoxicy> http://bluefox.kicks-ass.org/
[01:52] <mok_> I though the ubuntu* tag was only to be used for main etc
[01:52] <bluefoxicy> This machine is running Apache 1.3 booted from an Ubuntu LiveCD :)
[01:52] <bluefoxicy> Notice anything?
[01:52] <bluefoxicy> (scroll down to the bottom, look right)
[01:52] <jrib> bluefoxicy: it says debian?
[01:53] <bluefoxicy> :)
[01:53] <bluefoxicy> Not my doing.
[01:53] <geser> lintian will still complain about the number. it doesn't know the Ubuntu codenames and the Ubuntu versioning and report them as a bad NMU
[01:53] <crimsun> geser: no longer.  I sponsored Jordan's upload for that.
[01:53] <persia> bluefoxicy: If you have a better graphic, file a bug.
[01:53] <crimsun> in gutsy, that is.
[01:53] <geser> crimsun: but REVU doesn't use this version yet, does it?
[01:53] <bluefoxicy> persia:  it's not that.  The whole thing says things like "This computer has installed the Debian GNU/Linux operating system, but it has nothing to do with the Debian Project. Please do not contact the Debian Project about it." and so on.
[01:53] <crimsun> geser: correct
[01:54] <bluefoxicy> persia:  I will file a bug though
[01:54] <persia> bluefoxicy: Right, but changing the text and leaving the graphic would be confusing :)
[01:54] <StevenHarperUK>  usbadslmodemmanager source: changelog-should-mention-nmu : can anyone help with that one?
[01:54] <geser> mok_: no, all packages changed (or made) by Ubuntu has -XubuntuY in the version
[01:54] <jrib> persia:  well do you *need* a graphic really :P
[01:54] <geser> ignore this one
[01:55] <mok_> geser: OK, thanks
[01:55] <mok_> geser: I'll have to change that in mine
[01:56] <StevenHarperUK>   usbadslmodemmanager source: changelog-should-mention-nmu : anyone know the correct format for the change log?
[01:57] <StevenHarperUK> It also says that you've specified an unknown `target distribution' for your upload inN:   the debian/changelog file.
[01:57] <StevenHarperUK> so 2 problems with that file
[01:57] <StevenHarperUK> any Ideas?
[01:58] <mok_> target dist: universe?
[01:58] <geser> you can ignore both, lintian doesn't know the Ubuntu specifics
[01:58] <mok_> Perhaps there should be an "ubuntian"
[01:59] <geser> there is already one in gutsy, but not on REVU
[01:59] <mok_> Really? It was a joke :-)
[02:00] <StevenHarperUK> Great to I can Ignore them
[02:00] <geser> mok_: https://lists.ubuntu.com/archives/gutsy-changes/2007-June/002804.html
[02:01] <geser> StevenHarperUK: the one you should fix is about the svn dir
[02:01] <jrib> how come StevenHarperUK ended up with a file called "*.diff"?
[02:01] <StevenHarperUK> Dunno
[02:01] <mok_> I got some of those too...
[02:01] <StevenHarperUK> Yes I do
[02:01] <geser> it's normal
[02:02] <StevenHarperUK> ok ill do that now
[02:02] <jrib> weird mine ends up as reverend_0.3.svn20070609-0ubuntu1.diff    
[02:02] <jrib> maybe it's because of the version number complaint
[02:02] <geser> what StevenHarperUK has is called a native package, which should only by used for software which is only useful on Debian or Ubuntu
[02:02] <mok_> Btw, I am thinking of filing a bug report on dh-make: it should put ubuntu-motu etc in the Maintainer field, and then create a XSCB-Original-Maintainer for the packager
[02:03] <geser> the other packages (non-native) have a orig.tar.gz and a diff.gz
[02:03] <jrib> geser: oh I see
[02:03] <crimsun> mok_: careful, XSCB-Original-Maintainer is relevant for Debian.  We shouldn't assume the person is or isn't pulling source from Debian.
[02:04] <mok_> OK, so no packager name in the control file?
[02:04] <crimsun> Packager?  No.  Maintainer?  Sure, it can default to MOTU.
[02:05] <Amaranth> jrib: packing the reverend python bayesian classifier?
[02:05] <Amaranth> err, packaging
[02:05] <jrib> Amaranth: uh oh, you're going to tell me it's packaged aren't you (yes)
[02:05] <Amaranth> no
[02:06] <Amaranth> that was before the error got turned into a warning
[02:07] <crimsun> no, I see.
[02:07] <crimsun> The spec makes it applicable to all source packages.
[02:08] <crimsun> "we will do as follows for all Ubuntu binary packages, and Ubuntu source packages which are modified relative to Debian"
[02:08] <StevenHarperUK> OK I sent a clean one up :p
[02:08] <Amaranth> jrib: the bayesian classifier in willowng was based on code from reverend
[02:08] <jrib> Amaranth: ah
[02:08] <crimsun> however, it does state "Ubuntu source packages which are modified relative to Debian"
[02:08] <StevenHarperUK> Im so pleased that I have got this far
[02:08] <StevenHarperUK> I was close to giving up
[02:08] <crimsun> and not "all Ubuntu source packages"
[02:08] <mok_> congrats
[02:09] <persia> Hmmm.  I wonder if "modified relevant to Debian" covers the case where the modification is limited to "inclusion in the distribution".
[02:10] <mok_> StevenHarper: so now what? We'll just have to bug the MOTUs to advocate our packages :-)
[02:10] <mok_> persia: That's how I interpreted the spec
[02:11] <mok_> The point is that the Debian developers are fed up with getting bug reports from Ubuntu users
[02:12] <mok_> so anything that is modfied by Ubuntians should NOT have the Debian developers name in the Maintainer field
[02:13] <crimsun> mok_: there's no question WRT source packages originating in (synced from) Debian.
[02:13] <mok_> crimsun: Right
[02:13] <StevenHarperUK> OK im all done now!
[02:13] <StevenHarperUK> yeha
[02:13] <StevenHarperUK> Yeh bugging the MOTU's is my new hobby
[02:14] <crimsun> the ambiguity - rather, lack of coverage - is for source packages not in Debian.  It's clear that Maintainer should be set.  Should XSBC-Original-Maintainer be set, too?
[02:14] <mok_> What does SBC stand for?
[02:14] <crimsun> covered in Policy
[02:14] <StevenHarperUK> Thanks a Lot everyone who helped me
[02:15] <StevenHarperUK> Good night im off for R & R
[02:15] <mok_> persia: sounds reasonable!
[02:16] <mok_> As long as the maintainer is not a MOTU, it makes sense to have the MOTU list in the Maintainer: field.
[02:17] <crimsun> mok_: section 5.7 of Policy
[02:17] <mok_> ... and the the orig. packager should be in the XSBC--- field
[02:17] <crimsun> persia: raise it on -devel-discuss, methinks
[02:17] <persia> mok_: Rather, as long as the Maintainer does not have an @ubuntu.com email address, it makes sense to use one of the default development lists as the maintainer.
[02:17] <mok_> OK
[02:17] <jrib> hmm, guess I should my package then
[02:18] <persia> crimsun: I'll add that to my list :)  I think you're right, and I think the spec is ambigous.
[02:18] <mok_> ... and dh_make should be fixed...
[02:19] <crimsun> well, you can file that bug
[02:19] <mok_> Will do
[02:19] <mok_> Can you tell me what debdiffs are for?
[02:20] <mok_> I see people use them when fixing their packages
[02:21] <crimsun> unified diffs between source package revisions
[02:22] <mok_> So, when I fix my packages uploaded to REVU, I make a debdiff between the old and new versions and upload that?
[02:22] <crimsun> I don't recommend using debdiffs for old & new upstream versions
[02:23] <crimsun> e.g., 1.2.3 and 1.2.4 is better poised as a complete source package of 1.2.4
[02:23] <icf7> Is there any way to install executable files with dh_install or do I have to manually install them?
[02:23] <persia> mok_: Rather, when submitting new revisions to packages already in the archive.  See "Preparing New Revisions" in https://wiki.ubuntu.com/MOTU/Contributing
[02:23] <mok_> I am thinking of packages that have been modified according to the recommenations of the advocates
[02:27] <mok_> icf7: put the names of the executables in the _package.install file
[02:28] <icf7> mok_: I did, but they get installed with -x
[02:28] <mok_> icf7: are they scripts?
[02:29] <icf7> mok_: Yes
[02:30] <mok_> with a shebang character in the first line?
[02:31] <mok_> and: are the scripts executable in the orig. source?
[02:31] <icf7> mok_: Yes, and no, they are from debian/
[02:32] <mok_> It still should work...
[02:32] <icf7> mok_: Oops, sorry - I did something wrong. Upon retrying, everything works fine. Sorry.
[02:32] <mok_> Hehe
[02:33] <mok_> I struggled with the debhelper progs
[02:33] <mok_> the man pages are wrong
[02:33] <icf7> mok_: Well, I think it's confusing hello does not use them? Hello ;) ? hello is the example package!
[02:33] <mok_> debhelper stinks
[02:34] <mok_> You can take a look at cdbs but it's more of a black box
[02:34] <Amaranth> got another op around in case i screw up this test? :)
[02:34] <mok_> Works great for standard stuff
[02:35] <Amaranth> err, wrong channel
[02:36] <mok_> I'd like a python environment to do the building
[02:36] <mok_> We talked about that before you came
[02:36] <icf7> Found it, forget the correct directory and chmod does not raise a crash - wtf?
[02:39] <mok_> The last sentence is incomprehensible
[02:39] <AndyP> persia: just got back... seems that lionel already saw to my nufw merge upload but out of curiosity, what were your questions about the changelog?
[02:40] <persia> AndyP: Just personal preferences about the format of debian/changelog when adding new changes to a package at the same time a merge or fakesync is being processed.  No worries.
[02:41] <AndyP> persia: okie dokie, but if there's something i should learn, please teach :)
[02:44] <persia> AndyP: http://pastebin.ca/557525
[02:45] <icf7> mok_: Sorry, I'm tired, 2:44am here. I had written "chmod a+x file" instead of "chmod a+x debian/file", and there was no fatal error despit "file" not being in cwd
[02:45] <AndyP> persia: ahh yes, that makes sense, thanks
[02:45] <icf7> mok_: Thanks for your help
[02:46] <mok_> icf7: Glad to help, I'm a newbie too :-)
[02:59] <Fujitsu> persia: Which bug?
[03:00] <persia> Fujitsu: 57951, 88617, 82343
[03:00] <Fujitsu> bugs 57951, 88617, 82343
[03:00] <ubotu> Launchpad bug 57951 in xchat "[SRU]  xchat crashes frequently on quit" [Medium,Confirmed]  https://launchpad.net/bugs/57951
[03:00] <ubotu> Launchpad bug 88617 in duplicity "incremental backup does not work" [Medium,Confirmed]  https://launchpad.net/bugs/88617
[03:00] <ubotu> Launchpad bug 82343 in cryptsetup "init.d/cryptdisks doesnt create symlinks in /dev/disk/by-*" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82343
[03:02] <Fujitsu> persia: There's a method to work around that restriction. Stick /releasename after /ubuntu, and click 'Also needs fixing here'
[03:02] <Fujitsu> It seems to work.
[03:04] <persia> Fujitsu: Cool.  Thanks.
[03:04] <Fujitsu> No problem, happy SRUing :P
[03:04] <persia> Fujitsu: I'm just triaging for now :)
[03:05] <Fujitsu> Really!?
[03:06] <persia> Fujitsu: Well, not any more.  Nominations bloat it :)
[03:06] <Fujitsu> True. How unfortunate. Everyone should just use ultra-stable Gutsy.
[03:06] <persia> heh
[03:06] <AndyP> single digit eh?
[03:07] <persia> AndyP: If you can't find a good one, consider hunting patches and getting them applied.
[03:08] <AndyP> persia: where should i start?
[03:10] <AndyP> ah, the "show only bugs with patches available" tick box :)
[03:10] <persia> AndyP: Two good places are https://bugs.launchpad.net/ubuntu/+bugs?field.tag=patch and that tick box.  Once you find a package that needs work, look at "Preparing New Revisions" in MOTU/Contributing for more places to find patches.  It's best to fix as many bugs as possible with each upload.
[03:25] <persia> Is there a document somewhere that provides guidelines on including new software from contrib into multiverse?
[03:29] <Burgundavia> persia: it is just a sync request
[03:30] <persia> Burgundavia: Yes, but as this doesn't happen automatically, I'm guessing that Ubuntu doesn't want everything Debian has in contrib and non-free (I just don't understand when things are included).
[04:13] <crimsun> persia: you just need to request it & sub u-a as per usual.  Just remember to state clearly that its origin is in contrib/non-free, since it's a different sync rune according to Colin.
[04:13] <Amaranth> persia: someone files a request, someone checks it over
[04:14] <crimsun> Though the last time I asked was over eighteen months ago
[04:14] <persia> crimsun: Amaranth: Thanks.  As above, I was seeking policy.  In the absence thereof, I'll approve any requests for syncs from contrib/non-free that are passed to me.
[04:15] <persia> (assuming 1) it builds locally, 2) it works locally, 3) it doesn't replace something else in Ubuntu, and 4) it doesn't seem completely unreasonable).
[04:16] <Amaranth> who thought it would be a good idea for a usb plug to fit into an ethernet port?
[04:16] <Amaranth> i wonder if they ever thought of that when designing usb
[04:17] <persia> Amaranth: It's really a good thing for case designers, etc.
[04:17] <Amaranth> but bad for me
[04:18] <Amaranth> i almost always plug my mouse into my ethernet port, move it around, notice it doesn't work, and then plug it into the right place
[04:18] <Amaranth> i suppose the real answer is to not have them on the same side
[04:19] <Amaranth> persia: i think multiverse's only rule is 'legal to redistribute'
[04:19] <persia> Amaranth: Doesn't Debian enforce that for contrib and non-free?
[04:19] <Amaranth> yeah
[04:19] <Amaranth> so.... :)
[04:20] <Amaranth> arg
[04:21] <Amaranth> can someone give me the link to the queue in launchpad?
[04:21] <Amaranth> that has to be the hardest thing to find, i swear you just have to know the URL to know it exists
[04:21] <jmg> http://www.google.co.nz/url?sa=t&ct=res&cd=1&url=https%3A%2F%2Flaunchpad.net%2Fqprocd&ei=qrFsRsLKGJm-hAPj9MTeAg&usg=AFQjCNHH-38-OaxIhuBDJWAYRQYnQFSbtw&sig2=XY-1n5lFhrcRRicPD9GcYQ
[04:21] <jmg> https://launchpad.net/qprocd
[04:21] <jmg> ?
[04:21] <crimsun> https://launchpad.net/ubuntu/$release/+queue
[04:22] <crimsun> and yes, it's so difficult to locate that I just memorised it releases ago
[04:23] <jmg> the "Show uploads" button goes to the queue
[04:23] <crimsun> which is mildly more sane than one of the previous links, which simply was Build Queue
[04:23] <jmg> perhaps it should be renamed to "Show queue" or "Show uploads queue"
[04:24] <Amaranth> hrm, it seems mvo never uploaded compiz-compcomm-plugins-main
[04:24] <Amaranth> but bcop is in the new queue, maybe he is waiting for it to clear since it's a build dep
[04:25] <Amaranth> browsing in launchpad i did manage to find the actual build queue for each arch
[04:25] <Amaranth> but not the new/ftbfs/etc stuff
[05:32] <chillywilly> I installed ubuntu-xen-server and then udevd started hoggin the CPU and spitting out something like: device-mapper: ioctl: error adding target to 
[05:32] <chillywilly> table
[05:32] <chillywilly> over and over again
[05:32] <chillywilly> so I stopped it and now all seems well
[06:27] <crimsun> ok, morning queue: u-u-s, then alsa*.
[07:18] <persia> As part of the investigation for initiating wider discussion of the DebianMaintainerField guidelines, I've identified 312 binary packages and 889 source packages in Universe that do not currently comply with the spec.  Are these likely to be bugs?
[07:19] <crimsun> can you summarise how they're non-compliant?
[07:21] <superm1> jamyskis, ping
[07:21] <persia> crimsun: I've yet to investigate the special cases, but the numbers come from ` wget -O - http://archive.ubuntu.com/ubuntu/dists/feisty/universe/binary-i386/Packages.gz | gunzip | grep-dctrl -sSource:Package,Package,Maintainer -FVersion ubuntu  | grep-dctrl -sSource:Package -FMaintainer -v -n ubuntu | sort -u  | wc -l` and ` wget -O - http://archive.ubuntu.com/ubuntu/dists/feisty/universe/source/Sources.gz| gunzip | grep-dctrl -sPackage,Maintaine
[07:22] <crimsun> persia: hmm, not gutsy?
[07:22] <persia> crimsun: Right.  Thanks.
[07:23] <persia> Gusty is 624 binaries and 248 sources.
[07:24] <persia> Um.  Rather 624 sources and 248 binaries
[07:26] <StevenK> persia: Has no one taught you about $()? :-P
[07:27] <persia> StevenK: How would you use it in this case?  I've only used ` above to indicate that I'm quoting a shell fragment.
[07:29] <StevenK> persia: I thought you were pulling from a script that used a subshell, which is what `` and $() both do. The difference is $() can be nested, and `` can't.
[07:29] <persia> StevenK: Not in this case :)
[07:29] <_Enchained> Hi all
[07:29] <StevenK> persia: Then I sit corrected. :-)
[07:30] <_Enchained> http://revu.tauware.de/details.py?upid=5461 updated
[07:30] <_Enchained> If anyone have a little time
[07:30] <StevenK> Hrm. /me wonders who to talk to about a bunch of packages that haven't registered builds yet.
[07:30] <StevenK> persia: I've pretty much stopped using ` altogether for shell - Perl still keeps the habit alive, damn it's black heart.
[07:45] <persia> So, getting back to my original question: is it considered an upload-worthy bug if a package doesn't meet the tests listed in DebianMaintainerField spec, and is not an Ubuntu-only package?
[07:46] <StevenK> persia: And has an Ubuntu delta?
[07:47] <persia> StevenK: At least has an -XubuntuY version number.  I'm only going to investigate deltas if it needs to be fixed :)
[08:15] <coNP> Hi, lionel, I am a kind of a newbie, you seem to have uploaded the package I provided via a debdiff (ruby-gnome2). Shouldn't we mark this 'fix released' now?
[08:18] <crimsun> not yet.
[08:18] <crimsun> it hasn't appeared as built via LP
[08:18] <crimsun> I believe it's one of the uploads that hasn't registered a build
[08:18] <crimsun> (possible soyuz bug)
[08:19] <crimsun> ('lo Hobbsee)
[08:21] <coNP> What does this exactly mean? Packages get uploaded and never built (automagically)?
[08:22] <lionel> They should be build automagically
[08:22] <lionel> but during the week-end, lot of uploads does not have any build registered (that's what LP told)
[08:23] <crimsun> we're discussing it in -devel; will need to be patient until cprov appears and has had sustenance
[08:23] <crimsun> ;)
[08:23] <lionel> :)
[08:23] <coNP> thanks you both, I am just interested what happens to my little debdiffs :D
[08:31] <crimsun> coNP: thanks for your work on them :)
[08:32] <coNP> It was quite easy to fix the bugs except that I had to become familiar with both dpatch and quilt :)
[08:32] <crimsun> both excellent utilities.
[08:40] <ranf> hi
[08:45] <jussi01> hi
[09:03] <dholbach> good morning
[09:03] <jussi01> good morning dholbach
[09:03] <dholbach> hiya jussi01
[09:09] <jamyskis> superm1: good morning :)
[09:09] <jamyskis> good morning persia
[09:13] <dholbach> persia: :-))))
[09:25] <jamyskis> persia, superm1: i just wanted to say thanks for all your help, though i've decided to hand over the reins for packaging my stuff to anyone else who is willing and able, as i simply do not have the time to learn the extreme amount of stuff needed for packaging for the ubuntu repos
[09:30] <persia> As a last note about DebianMaintainerField, for those who might have been interested, of the 624 affected sources in universe, only 458 are clearly based on Debian (of which there are 609 in all of main, restricted, universe, and multiverse).  The others may be new.  I'll wait for response to my mail prior to fixing these.
[09:31] <StevenK> persia: To -motu?
[09:32] <persia> StevenK: to -devel-discuss, as advised earlier.
[09:33] <persia> (earlier, in this case, being about 7 hours ago)
[09:35] <persia> Fujitsu: That makes sense to me, but I tend to follow previous advice unless I have an agenda regarding the advice.  I don't think it's worth resending, do you?
[09:35] <Fujitsu> Probably not once it's sent, no.
[09:36] <Fujitsu> But the people who are likely to want to read it are on -devel.
[09:37] <Fujitsu> IMO, only Debian-derived packages should be mangled, and it should be easy to opt-out
[09:38] <persia> Fujitsu: Please reply with that.  That's exactly the sort of feeback I'm hoping for, and I'd ilke to see discussion on the list to build a consensus.
[09:38] <crimsun> I advised -devel-discuss because there's an off-chance that upstream maintainers may be subscribed to it
[09:39] <crimsun> their input as the original maintainers is valuable, too
[09:39] <Fujitsu> That it is.
[09:39] <Fujitsu> But some of the people who count are probably not on -devel-discuss. This is why the lists shouldn't have been split.
[09:41] <persia> That's an old discussion.  It's hard to fix now.  There's good arguments in both directions.  Perhaps items of interest to both should be cross-posted for now.
[09:42] <Fujitsu> I don't read it normally, but I'm subscribed.
[09:43] <StevenK> So I tend to think carefully before doing so.
[09:44] <persia> StevenK: Despite previous issues, the volume isn't very high right now.  Better documentation has helped a lot.
[09:46] <StevenK> How much mail per week or so?
[09:48] <persia> StevenK: I'd guess about 15 or so, but I don't count mail that way.  You may get a better idead from https://lists.ubuntu.com/archives/ubuntu-devel-discuss/
[09:48] <persia> s/d fr/ fr/
[09:59] <man-di> doko: are you in EDI already?
[09:59] <doko> man-di: no
[09:59] <doko> next Monday afternoon
[09:59] <man-di> doko: ah
[09:59] <man-di> doko: I'm currently building a package for icedtea
[10:01] <Fujitsu> persia: I've replied, but it has been moderated.
[10:01] <crimsun> coNP: are you working on 119796?  I'm working through the source ATM.
[10:01] <man-di> doko: $ bin/java -version
[10:01] <man-di> openjdk version "1.7.0-internal"
[10:01] <man-di> OpenJDK Runtime Environment (build 1.7.0-internal-mkoch_11_jun_2007_06_25-b00)
[10:01] <man-di> OpenJDK Client VM (build 1.7.0-internal-mkoch_11_jun_2007_06_25-b00, mixed mode)
[10:01] <coNP> bug 119796
[10:01] <ubotu> Launchpad bug 119796 in openbox "Please include Openbox 3.4.2 in Ubuntu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119796
[10:01] <doko> man-di: ohh, cool!
[10:01] <coNP> crimsun: actually mithrandir said it might get into Debian then we can sync
[10:02] <crimsun> coNP: ok.  I've already updated the Debian bug tracking on the bug, so we'll wait.
[10:02] <coNP> crimsun: but if it is not the way I am up to create a package upgrade (something I did not make yet but want to start soon :))
[10:03] <man-di> doko: but currently only with SUN JDK 6, with gcj I get compile time errors about too old jvmti headers or so
[10:04] <doko> man-di: and building it with itself?
[10:04] <crimsun> coNP: it's fairly straightforward; the patch to openbox/client.c can be dropped
[10:04] <man-di> doko: you need a bootstrap jvm
[10:05] <coNP> crimsun: actually there *is* already a package on their website
[10:05] <man-di> doko: but I have to say I dont tried make bootstrap yet
[10:05] <crimsun> coNP: yes, but they didn't post the source package
[10:05] <man-di> doko: I will try
[10:06] <coNP> crimsun: I am just not sure how long it is worth waiting for debian (not that I would be so impatient just to see how things are meant to go)
[10:07] <doko> man-di: well, yes, but at least for those architectures with an existing jdk6, we can do the initial bootstrap with the jdk6, and then build it with itself
[10:07] <crimsun> coNP: since 3.4.2 was just released yesterday, I'd give Mithrandir at least two weeks.  I'm sure he's quite busy with Canonical->Ubuntu things.
[10:08] <coNP> crimsun: okay, thanks
[10:11] <crimsun> coNP: in the meantime, feel free to prepare a source package on REVU.  I recommend also looking through Debian BTS/openbox and updating status as appropriate.
[10:15] <coNP> thanks, crimsun 
[10:15] <crimsun> np
[10:30] <siretart> StevenK: regarding REVU2 better done in rails. I haven't touched ruby at all yet, but I've been looking at python django, and have been considering writing revu2 with that framework
[10:31] <StevenK> siretart: Ah. Rails is fun. :-)
[10:31] <siretart> sure. I however prefer python
[10:33] <lionel> django is fun ;)
[01:43] <mok0> a
[01:44] <mok0> ls
[01:44] <Fujitsu> I agree.
[02:10] <geser> Fujitsu: Hi, are you working on bug #115935?
[02:10] <ubotu> Launchpad bug 115935 in qgis ".so links in non-dev package" [Undecided,In progress]  https://launchpad.net/bugs/115935
[02:11] <Fujitsu> geser: Not actively at the moment.
[02:12] <geser> I have a debdiff for it ready.
[02:12] <Fujitsu> geser: Oh, right, I remember now. I was trying to fix it but it FTBFSed due to some qt4 thing.
[02:12] <Fujitsu> Upload it if you wish.
[02:12] <geser> ok
[02:13] <geser> I had to patch configure to accept qt 4.3 to get it build
[02:13] <Fujitsu> That'd do it. I didn't have the time at that point to look into that at all.
[02:15] <xxxxx1> good morning people!
[02:24] <pygi> ajmitch, around?
[02:24] <pygi> meh, ignore
[02:24] <zul> he's gone to bed
[02:25] <pygi> zul, yup, doesn't matter anyway :)
[02:39] <DarkSun88> Hi all
[02:40] <Hobbsee> hi DarkSun88 
[02:40] <DarkSun88> Hi Sara
[02:41] <zul> violence will never get you anywhere
[02:41] <DarkSun88> Sarah*, sorry. :)
[02:41] <Hobbsee> hehe :)
[02:41] <Hobbsee> zul: violence solves any problem, if applied well enough
[02:41] <Hobbsee> DarkSun88: hiya :)
[02:44] <mok0> How can I disable join and leave info messages in irssi?
[02:44] <Hobbsee> mok0: ask in #ubuntu
[02:44] <mok0> ok
[02:44] <Hobbsee> mok0: bug /set ignore JOIN PART QUIT i believe
[02:44] <Hobbsee> or something like that
[02:44] <Hobbsee> s/bug/but/
[02:54] <mok0> Hobsee: I'll try it, thanks!
[02:58] <mok0> It's /set activity_hide_level = JOINS QUITS PARTS
[02:59] <mok0> Ah, nice!
[03:03] <mok0> Hmmm
[03:03] <mok0> doesn't work...
[03:04] <Hobbsee> mok0: you do actually want /ignore JOINS QUITS PARTS or /set ignore JOINS QUITS PARTS - the activity hide level refers to something else, iirc.
[03:07] <freeflying_> anyone has a amd64 box
[03:08] <persia> freeflying_: What do you need tested?
[03:08] <freeflying_> persia: a package only has rpath issue on amd64
[03:08] <freeflying_> persia: would you  like test it for me
[03:09] <persia> freeflying_: Which package?
[03:09] <freeflying_> persia: eva 
[03:10] <freeflying_> persia: if you have time, I may mail you a latest package, with relibtoolize patch
[03:11] <mok0> Hobsee: you are right
[03:11] <persia> freeflying_: I've a list of things to be doing, but I'll be around for a couple hours, and could test a patch.  If you have a handy testcase, that'd be nice too :)
[03:12] <freeflying_> persia:  :)
[03:18] <persia> freeflying_: Um..  What sort of issue are you seeing?  I'm not seeing and hardcoded paths in eva (with objdump), and don't see a bug.
[03:18] <persia> s/and/any/1
[03:19] <freeflying_> persia: lintian warning
[03:19] <persia> freeflying_: Ah.  That'll be easier then :
[03:19] <freeflying_> persia: because of rpath issue, and rejected by debian ftp-master
[03:19] <persia> )
[03:22] <mok0> I have a bunch of packages in REVU, does someone have time to take a look?
[03:22] <bluekuja> mok0, provide links
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5455
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5456
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5457
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5458
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5459
[03:23] <mok0> http://revu.tauware.de/details.py?upid=5460
[03:24] <mok0> :-)
[03:24] <bluekuja> :D
[03:24] <persia> mok0: I recommend submitting one package for review at a time.  Frequently, there are common issues to address, and you'll have an easier time concentrating on your feedback.
[03:25] <persia> (Not one upload to REVU, but one annoucement at a time :))
[03:25] <mok0> Sounds like a good idea
[03:25] <mok0> Some of them have no lintian errors 
[03:26] <mok0> so I can't get further on my own
[03:26] <persia> mok0: For which package do you most with review?
[03:27] <persia> s/with/wish/
[03:27] <mok0> Let's start with 5459, that's a multipackage one with xinit scripts etc
[03:27] <mok0> s/xinit/xinetd/
[03:28] <persia> mok0: Is this intended for Ubuntu or for Debian?
[03:29] <mok0> Well, both, ideally
[03:29] <persia> mok0: Rather, this specific upload.
[03:30] <mok0> Ubuntu
[03:31] <mok0> Isn't it easier to get it accepted into Debian if it is in Ubuntu? I read something about contacting the Utnubu group later.
[03:31] <persia> mok0: OK.  You'll at least want to change the version number (-0ubuntu1) and other Ubuntuisations (most of which cause lintian warnings :)
[03:31] <mok0> OK
[03:31] <mok0> I already know about the Maintainer: field
[03:32] <mok0> I filed a bug against dh_make this morning
[03:35] <mok0> So, when I fix the package, how do I upload it revu? Will revu let me overwrite the older debs, do I bump the release, or what??
[03:36] <Hobbsee> it'll automatically overwrite them
[03:36] <Hobbsee> dont bump the release
[03:36] <persia> mok0: Just out of curiosity, does this work with LVS as well?
[03:36] <mok0> The release is 1 now, can I change it to 0ubuntu1 ?
[03:36] <persia> mok0: Rather, unbump the release :)
[03:36] <mok0> Hehe ok
[03:37] <mok0> Shall I try it now?
[03:38] <mok0> What about changelog? What do I do there?
[03:39] <persia> mok0: Wait a bit, and I'll post a comment.  Ask me then :)
[03:48] <persia> freeflying_: I've just completed a local sbuild, and i cannot find anything obvious in the build log to explain it.  I'm looking forward to your patch.  Separately, I'd split the pacakge into eva + eva-data.  Lastly, am I correct that while libeva is built, it's statically linked into eva, and not distributed?
[03:49] <freeflying_> persia: ya, and without eva, those data is useless
[03:49] <freeflying_> persia: so I haven't split them 
[03:50] <persia> freeflying_: I'll look at the patch, but I'm thinking that the static linking of libeva might be part of why it's happening.
[03:50] <freeflying_> persia: maybe
[03:50] <persia> freeflying_: Yep.  Maybe :)
[03:51] <mok0> A static library is just an ar archive of .o files so I doubt that explains anything
[03:52] <freeflying_> persia: I'd mail you tomorrow
[03:53] <persia> freeflying_: OK.  I'll look for it.
[04:02] <persia> mok0: I've commented with a few items.  Was there anything specific with which you needed help?
[04:02] <mok0> I'll take a look at your comments
[04:04] <dholbach> what happened to REVU days?
[04:04] <mok0> What section would you propose for cluster monitoring?
[04:05] <mok0> Otherwise there are lots of things to get to work on... :-)
[04:05] <dholbach> mok0: 'admin'?
[04:06] <Hobbsee> dholbach: it exists.  it's dying a bit at the moment
[04:06] <mok0> There is nothing called "cluster"? 
[04:06] <mok0> That would in fact be useful
[04:07] <persia> mok0: I'd use "utils" for a monitoring utility, but it's a matter of taste.  "admin" is also good.
[04:07] <StevenK> I seriously doubt there are enough tools to justify a cluster section.
[04:07] <Hobbsee> :)
[04:07] <mok0> Yes but they are difficult to locate
[04:07] <xxxxx1> hello dholbach 
[04:07] <mok0> cluster utils I mean
[04:08] <dholbach> hiya xxxxx1
[04:08] <mok0> persia: tmp.sh and xxxxx are just crud files left from my poking around
[04:09] <mok0> xxxxx is a tmp file generated by rules
[04:09] <persia> mok0: It's a good practice to review your diff.gz to make sure you don't touch anything outside debian/ before uploading.  Also, remember to delete any tmp files in your clean: rule.
[04:09] <mok0> I'll remember that.
[04:10] <Gekitsuu> Is there a way to do a reinstall on a running system via apt?
[04:10] <mok0> Is it ok to use /tmp in rules
[04:11] <StevenK> Gekitsuu: apt-get --reinstall install <package> for a single package. For multiple packages, stronger magic is required. To simulate a complete re-install, no, I don't think so.
[04:11] <Gekitsuu> even if you did a --reinstall of ubuntu-desktop?
[04:11] <persia> mok0: It's best to avoid that.  Just put temporary files somewhere in the build tree, and delete them in clean:
[04:12] <Gekitsuu> really the filesystem is ok I just have some package problems
[04:12] <leonel> hello !
[04:13] <StevenK> Gekitsuu: If you did a --reinstall of ubuntu-desktop, it would only reinstall it, not everything it Depends on.
[04:14] <Gekitsuu> ahhh ok, thank you :)
[05:16] <Hobbsee> persia: ....the entire wiki?
[05:16] <persia> Hobbsee: Yep.
[05:16] <Hobbsee> but that's.....huge.
[05:17] <persia> Only wiki.ubuntu.com.  I didn't get to the community sections, nor help.  It's only about 15,00 pages, of which only about 10,000 have real content.
[05:17] <Hobbsee> ahh
[05:19] <zul> you have too much time on your hands
[05:20] <persia> zul: See https://wiki.ubuntu.com/MOTU/WikiCleanUp
[05:20] <zul> ah but still ;)
[05:21] <Hobbsee> persia: wants to make the entire wiki a lot better, so it'd be a help
[05:21] <persia> zul: In case you hadn't noticed, w.u.c is completely unmanageable.  As I noted before, about 25% is redirects, for which many the target no longer exists.  It really needs some help.
[05:21] <persia> s/which many/many of which/
[05:39] <tobiasschulz> hi
[05:39] <tobiasschulz> are some motu admins in this channel?
[05:40] <persia> tobiasschulz: You'll get a better response by asking your question directly, rather than seeking someone first.
[05:41] <geser> Hobbsee: as you can upload to main, could you please upload the debdiff from bug #119873 for me?
[05:41] <ubotu> Launchpad bug 119873 in gnupg2 "[gutsy]  Rebuild with libcurl4-gnutls" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119873
[05:42] <Hobbsee> geser: er, why does it need a rebuild?
[05:43] <Hobbsee> libcurl transition or something?
[05:44] <geser> yes
[05:44] <tobiasschulz> i want to upload a new package to universe for gutsy (with revu). in the ubuntu wiki ist says "Next, ask the REVU admins in #ubuntu-motu or at  keyring@tiber.tauware.de to re-sync the REVU uploaders keyring, which grants you upload rights to REVU"
[05:44] <Hobbsee> geser: cool, uploaded
[05:45] <geser> Hobbsee: thanks
[05:45] <Hobbsee> tobiasschulz: it'll be abotu ~10 mins.  will tell you when it's done
[05:45] <gnomefreak> tobiasschulz: you should just beablet o dput revu name.changes
[05:45] <_Enchained> hey Hobbsee 
[05:46] <tobiasschulz> ok
[05:46] <Hobbsee> hi _Enchained.  congratulations :)
[05:46] <gnomefreak> Hobbsee: i never had to have it re-synced :(
[05:46] <Hobbsee> gnomefreak: not without a keyring resync, depending on when he joined.
[05:46] <Hobbsee> gnomefreak: it only resyncs daily, iirc.
[05:46] <Hobbsee> i'm not sure
[05:46] <gnomefreak> oh ok
[05:46] <Hobbsee> i could probably find out, come to think of it
[05:46] <tobiasschulz> i joined yesterday with lanchped
[05:47] <statik> hi! I've written my first package, and would like to upload to revu. I attempted on Sunday, but had some things marked wrong in my package. Can an admin delete my old python-coverage_2.6.orig.tar.gz so I can try uploading a correct one?
[05:47] <persia> gnomefreak: Was there maybe a few hour gap between when you joined C-U-U, and you first uploaded?  Perhaps someone else requested the sync, or the daily sync happened.
[05:47] <gnomefreak> couple of days
[05:47] <_Enchained> Hobbsee :) You seen the update for nautilus-wallpaper ?
[05:47] <persia> gnomefreak: That'd do it.
[05:47] <gnomefreak> maybe thats why
[05:47] <gnomefreak> ah ok ty
[05:47] <Hobbsee> _Enchained: i think i commented once on it
[05:48] <Hobbsee> statik: just upload another one
[05:48] <Hobbsee> statik: it'll overwrite
[05:48] <statik> Hobbsee: I get this "Error '553 Could not create file.' during ftp transfer of python-coverage_2.6.orig.tar.gz
[05:48] <statik> Note: This problem might be caused by files already existent on the server.
[05:48] <statik> "
[05:48] <persia> Hobbsee: Last night, half the package was in rejected, and the other half still in incoming.
[05:49] <Hobbsee> statik: ah right.  fixed.
[05:49] <Hobbsee> persia: true that, i spoke to pitti
[05:49] <_Enchained> Hobbsee http://revu.tauware.de/details.py?upid=5461 uf you have a little time
[05:49] <Hobbsee> persia: er, incoming?
[05:49] <statik> Hobbsee: awesome, thanks!
[05:49] <_Enchained> if*
[05:49] <Hobbsee> persia: i uploaded that to ubuntu.  although there is a version on revu in incoming
[05:49] <persia> Hobbsee: statik's REVU package - you've already fixed it.
[05:49] <Hobbsee> (where can you guys see the incoming queue?)
[05:49] <Hobbsee> ah right
[05:49] <Hobbsee> yes
[05:52] <persia> Hobbsee: I'm guessing you were referring to b5i2iso?  If not, I'm confused.
[05:52] <Hobbsee> persia: @ speaking to pitti?  yes.
[05:52] <persia> Right.  Thanks.  Context restored.
[05:52] <Hobbsee> :)
[05:52] <mok0> how can I prevent an upgrade of a package from overwriting config files?
[05:53] <Hobbsee> darn this "talking on multiple packages at once"
[05:53] <Hobbsee> mok0: dpkg will throw an error, and wont automatically let you.
[05:53] <mok0> It did
[05:53] <persia> mok0: If the config file is a conffile, report a bug.  If not, you can't (except by not upgrading).
[05:53] <mok0> It is in my own package :-)
[05:53] <Hobbsee> mok0: oh...er, remove it from the install file, usually
[05:53] <Hobbsee> depends what ti is
[05:54] <persia> mok0: In that case, register the config file as a conffile (see policy about conffiles)
[05:54] <mok0> I'd like it to keep the old config file around if it's been modified, else install the default one
[05:54] <mok0> conffiles, got it!
[05:59] <mok0> Should the conffile be both in .install and .conffiles?
[06:25] <tobiasschulz> i am uploading my first revu package now.(that program: http://jeliza.sourceforge.net/cms/index.php?page=home). how can i get my package advocated by some motus?
[06:26] <pochu> tobiasschulz: post here the revu link.
[06:26] <tobiasschulz> revu loink?
[06:27] <tobiasschulz> i am uploading it, its not jet finished (in 5 minutes i think). what is a revu link?
[06:27] <Nafallo> !revu
[06:27] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[06:28] <tobiasschulz> i know
[06:28] <tobiasschulz> but what link?
[06:29] <RainCT> tobiasschulz: there url from where that what you are uploading can be downloaded and commented, or? :P
[06:30] <tobiasschulz> rainct: yes. but i am using dput to upload, so how do i get a link to the uploaded package?
[06:31] <Nafallo> tobiasschulz: http
[06:31] <tobiasschulz> ...
[06:31] <tobiasschulz> Uploading to revu (via ftp to revu.tauware.de):
[06:31] <tobiasschulz>   jeliza_2.2.99.2-1.dsc: done.
[06:31] <tobiasschulz>   jeliza_2.2.99.2-1.tar.gz: done.
[06:31] <tobiasschulz>   jeliza_2.2.99.2-1_i386.deb:
[06:31] <tobiasschulz> (not yet finished)
[06:31] <RainCT> tobiasschulz: search it on http://revu.tauware.de/ once it's uploaded
[06:31] <tobiasschulz> ok
[06:31] <RainCT> tobiasschulz: (perhaps there's a better way but I never worked with REVU so I don't really know)
[06:33] <mok0> what debhelper script handles package.manpages?
[06:33] <xxxxx1> mok0: dh_installmanpages
[06:34] <mok0> thx
[06:34] <mok0> Isn't dh_installmanpages deprecated?
[06:34] <xxxxx1> oops
[06:34] <xxxxx1> dh_installman
[06:34] <xxxxx1> sorry
[06:34] <xxxxx1> :>
[06:34] <mok0> :-)
[06:37] <Hobbsee> RainCT: that's hte best way
[06:38] <RainCT> Hobbsee: thanks
[06:38] <RainCT> Do you know of any easy package I could try to package (once I finish some PHP stuff in a few minutes..)?
[06:39] <tobiasschulz> ive finished uploading my revu package, but i cant see it at http://revu.tauware.de/ !?
[06:42] <xxxxx1> tobiasschulz: processing of uploads is done every 5 min.
[06:42] <nixternal> does anyone here respect what ASP.NET does? I have an ASP.NET class and it is horrid...dragging and dropping websites is so 1998
[06:43] <mok0> persia: you suggest that I depend on inet-superserver instead of xinetd, but isn't that a virtual package?
[06:43] <mok0> -- perhaps persia's gone?
[06:48] <tobiasschulz> mh. i ried to recover my password for revu as described in the ubuntu wiki. but when i cliked on "recover" on http://revu.tauware.de/index.py after logging in with no password and after executing the gpg shell commands, gpg prints only "None":
[06:48] <tobiasschulz> gpg: verschlsselt mit 2048-Bit ELG-E Schlssel, ID 6AC5ADD3, erzeugt 2007-06-10
[06:48] <tobiasschulz>       "Tobias Schulz <tobischulz@arcor.de>"
[06:48] <tobiasschulz> None
[06:49] <tobiasschulz> any ideas?
[06:49] <siretart> tobiasschulz: did you already upload a package? does it appear on revu?
[06:50] <tobiasschulz> yes, i used dput. bur it does not appear (after 15 min now):
[06:50] <tobiasschulz> Uploading to revu (via ftp to revu.tauware.de):
[06:50] <tobiasschulz>   jeliza_2.2.99.2-1.dsc: done.
[06:50] <tobiasschulz>   jeliza_2.2.99.2-1.tar.gz: done.
[06:50] <tobiasschulz>   jeliza_2.2.99.2-1_i386.deb: done.
[06:50] <tobiasschulz>   jeliza_2.2.99.2-1_i386.changes: done.
[06:50] <tobiasschulz> Successfully uploaded packages.
[06:50] <tobiasschulz> Not running dinstall.
[06:51] <mok0> tobiasschulz: it's not gonna work
[06:51] <mok0> you have to upload a SOURCE.changes file!
[06:51] <tobiasschulz> what?
[06:51] <tobiasschulz> i have
[06:51] <Hobbsee> that's the i386 changes file
[06:52] <mok0> debuild -S
[06:52] <tobiasschulz> ive executed
[06:52] <tobiasschulz> dput jeliza_2.2.99.2-1_i386.changes
[06:52] <Hobbsee> nevertheless, there is a source there
[06:52] <Hobbsee> use debuild -S -sa to build it, and it'll autogenerate the right changes file
[06:52] <mok0> Yes, but it doesn't work
[06:52] <tobiasschulz> ok
[06:52] <mok0> ... and you need to run dcut to remove the old crud :-)
[06:53] <mok0> from revu that is
[06:53] <tobiasschulz> can you explain how i use dcut? or where can i read that?
[06:53] <mok0> Actually, I am going to file a bug towards dput complaining about this.
[06:54] <mok0> s/complaining/NOT complaining/
[06:55] <Hobbsee> mok0: dcut doesnt work
[06:55] <Hobbsee> on revu
[06:56] <Hobbsee> mok0: how's that a dput bug, sorry?
[06:57] <mok0> It doesn't? I used it :-)
[06:57] <Hobbsee> mok0: dcut doesnt work on revu.
[06:58] <Hobbsee> you didnt use it successfully, i suspect
[06:58] <mok0> Hobbsee: dput should warn user that uploading a i386.changes files will not work
[06:58] <Hobbsee> siretart: can answer why
[06:58] <Hobbsee> mok0: but it does work.
[06:58] <tobiasschulz> and what to use instead?
[06:58] <tobiasschulz> of dcut
[06:58] <Hobbsee> tobiasschulz: ask a revu admin to remove the binaries
[06:58] <Hobbsee> tobiasschulz: (which iv'e done for you)
[06:59] <Hobbsee> mok0: the fact that ubuntu only accepts sources is not a limitation of dcut.
[06:59] <mok0> Hobbsee: I used dcut on revu and it did remove the files
[06:59] <tobiasschulz> Uploading to revu (via ftp to revu.tauware.de):
[06:59] <tobiasschulz>   jeliza_2.2.99.2-1.dsc:
[06:59] <tobiasschulz> Error '553 Could not create file.' during ftp transfer of jeliza_2.2.99.2-1.dsc
[06:59] <tobiasschulz> Note: This problem might be caused by files already existent on the server.
[06:59] <tobiasschulz>       For the official Debian upload queues, the dcut(1) utility can be used
[06:59] <tobiasschulz>       to remove stale files from unsuccessful uploads.
[07:00] <Hobbsee> mok0: also, you wouldnt want to limit things to just sources, as DD's and such can upload to debian from an ubuntu machine
[07:00] <Hobbsee> tobiasschulz: sorry, fixed, try again :)
[07:00] <siretart> tobiasschulz: please do read the instruction. I thought it would be very clear that we don't accept binaries
[07:00] <mok0> Hobbsee: The weird thing is that everything revu needs is there even if you use i386.changes
[07:00] <tobiasschulz> does the ubuntu server build it alone?
[07:01] <siretart> tobiasschulz: and where did you read that dcut would work on revu?
[07:01] <Hobbsee> siretart: it's an output from dput
[07:01] <mok0> siretart: I tried it and it (seemed to) work
[07:01] <tobiasschulz> dput said that
[07:01] <tobiasschulz> Note: This problem might be caused by files already existent on the server.
[07:01] <tobiasschulz>       For the official Debian upload queues, the dcut(1) utility can be used
[07:01] <tobiasschulz>       to remove stale files from unsuccessful uploads.
[07:02] <siretart> please note the part that says 'the official Debian upload queues'
[07:02] <Hobbsee> siretart: does the upload.ubuntu.com actually allow dcut?
[07:02] <tobiasschulz> oh sorry ^^
[07:02] <Hobbsee> siretart: or does anything in the ubuntu world?
[07:02] <siretart> Hobbsee: nope. not that I know, and not that it would be necessary
[07:03] <mok0> Let's try it and see if it works
[07:03] <Hobbsee> siretart: because if not, a patch to that error message saying "this does nto apply for ubuntu" or something woudl be very much welcomed!
[07:03] <siretart> Hobbsee: perhaps we can remove the warning from dput altogether
[07:03] <Hobbsee> it's logical for debian.
[07:03] <Hobbsee> !info dput gutsy
[07:03] <ubotu> dput: Debian package upload tool. In component main, is optional. Version 0.9.2.27ubuntu1 (gutsy), package size 38 kB, installed size 200 kB
[07:03] <tobiasschulz> now it wirks, without dcut
[07:03] <Hobbsee> and it's modified for ubuntu
[07:04] <siretart> Hobbsee: you cannot to uploads to debian built from an ubuntu chroot anyway
[07:04] <siretart> s/to/do/
[07:04] <siretart> tobiasschulz: yes, I manually removed the leftover files
[07:04] <tobiasschulz> thanks
[07:04] <Hobbsee> siretart: of course - but you can have a debian chroot on a ubuntu machine, and happen to upload from the ubuntu machine
[07:05] <mok0> Who programs REVU?
[07:05] <siretart> Hobbsee: you can also dput from the debian chroot. well, okay
[07:05] <siretart> mok0: https://launchpad.net/~revu-hackers
[07:05] <Hobbsee> true that
[07:06] <mok0> Why cant it just zap the binary deb if people use i386.changes?
[07:06] <mok0> It is still getting orig.tar.gz, diff.gz and .dsc
[07:07] <siretart> ajmitch has written something that does that. you might ask him why it doesn't work
[07:08] <mok0> Can I email him?
[07:11] <Hobbsee> he eats people
[07:11] <zul> for breakfast
[07:11] <joejaxx> and lunch
[07:13] <Hobbsee> and dinner.
[07:13] <Hobbsee> in fact, he's not particularly fussed as to when he eats them.
[07:14] <zul> and when he is full he eats more people
[07:16] <joejaxx> he selection method is based off of /dev/random so you never know when you are next
[07:16] <zul> so no emailing him would not be a good idea best catch him on irc
[07:17] <Hobbsee> actually, having seen his inbox..yes, irc is better
[07:20] <mok0> dh_manpages is terrible
[07:20] <mok0> dh_installman is terrible
[07:20] <xxxxx1> mok0: ?
[07:21] <Hobbsee> quicker response
[07:21] <mok0> I HAVE a manpage in debian/tmp/usr/share/man/man8
[07:21] <mok0> in package.manpages I have:
[07:21] <mok0> usr/share/man/man8
[07:21] <mok0> and dh_installman STILL claims it's not there
[07:22] <xxxxx1> this manpages are already on upstream source or you have created?
[07:22] <mok0> rules creates it
[07:23] <xxxxx1> is from upstream source?
[07:23] <mok0> -> upstream makefile installs it in debian/tmp/...
[07:23] <xxxxx1> ok..
[07:23] <xxxxx1> you can put these in .install and not in .manpages
[07:23] <xxxxx1> like
[07:24] <xxxxx1> debian/tmp/usr/share/man/man8/
[07:24] <mok0> He, emmet told me to use .manpages; I did use .install
[07:24] <mok0> I remember having probs with dh_installman and I switched to dh_install
[07:25] <xxxxx1> if these manpages are from upstream source, you should use dh_install
[07:25] <mok0> Prefixing with debian/tmp does not work
[07:26] <mok0> "Cannot determine section for".... 
[07:26] <xxxxx1> dependsd from the param that you passed to dh_
[07:26] <xxxxx1> well
[07:26] <xxxxx1> you package is on revu?
[07:26] <xxxxx1> oops. your
[07:26] <xxxxx1> :)
[07:26] <mok0> It doesn't HAVE to determine section, I already KNOW its section 8 :-(
[07:26] <mok0> Yes, I am working on wulfware atm.
[07:27] <xxxxx1> can you paste the link?
[07:27] <mok0> # 5459
[07:27] <mok0> http://revu.tauware.de/details.py?upid=5459
[07:28] <mok0> dh_install is nice because you can give it a --sourcedir= switch
[07:29] <mok0> but that doesn't work on dh_installman
[07:29] <mok0> grrrrrrrr
[07:29] <tobiasschulz> siretart: my package "jeliza" doesnt appear, and i have uploaded the _sources.changes
[07:30] <mok0> jeliza... is that a java implementation of eliza??
[07:30] <tobiasschulz> no. it was
[07:30] <mok0> I could use a shrink right now
[07:30] <Hobbsee> siretart: it appears that you were the only ever uploader of dput to bzr - did you know what happened to it?
[07:30] <tobiasschulz> now it is really more advanced
[07:31] <tobiasschulz> dput said
[07:31] <tobiasschulz> Uploading to revu (via ftp to revu.tauware.de):
[07:31] <tobiasschulz>   jeliza_2.2.99.2-1.dsc: done.
[07:31] <tobiasschulz>   jeliza_2.2.99.2-1.tar.gz: done.
[07:31] <tobiasschulz>   jeliza_2.2.99.2-1_source.changes: done.
[07:31] <tobiasschulz> Successfully uploaded packages.
[07:31] <tobiasschulz> Not running dinstall.
[07:31] <mok0> tobiasschulz: dput revu jeliza---.source.changes
[07:31] <tobiasschulz> but nothing appears on the website
[07:31] <tobiasschulz> ive executed dput -f jeliza_2.2.99.2-1_source.changes
[07:32] <tobiasschulz> build using debuild
[07:33] <mok0> tobiasschulz: you've been banned from revu ;-)
[07:33] <tobiasschulz> why?
[07:33] <mok0> (joke)
[07:33] <tobiasschulz> ^^
[07:34] <tobiasschulz> but why it doesnt work?
[07:34] <mok0> Hang on, I think the MOTUs are working on it
[07:34] <Hobbsee> it should publish, if it doesnt, poke siretart 
[07:35] <xxxxx1> mok0: you have a lot of work todo in your package.
[07:35] <mok0> I've done it
[07:35] <mok0> except %%$#&! manpages :-)
[07:36] <xxxxx1> nope. manpage is one of other items.
[07:37] <mok0> I have to upload again
[07:37] <xxxxx1> ok
[07:38] <mok0> xxxxx1: Can you tell me about inet-superserver?
[07:39] <mok0> It's a virtual package, yes?
[07:41] <xxxxx1> yep, is used on provide.
[07:41] <xxxxx1> can be openbsd-inetd, xinetd and so on...
[07:41] <mok0> But some of the other inetd's are configured differently that xinetd
[07:41] <mok0> So how do I deal with that?
[07:42] <mok0> xinetd is easy to configure, just drop a file in /etc/xinetd.d and restart the daemon
[07:43] <mok0> The others have an inetd.conf file you have to edit.
[07:44] <mok0> What inetd's do people use, anyway?
[07:48] <geser> !info update-inetd
[07:48] <ubotu> update-inetd: inetd.conf updater. In component main, is important. Version 4.27-0.2 (feisty), package size 9 kB, installed size 88 kB
[07:50] <geser> mok0: you probably want to use update-inetd to update the inetd.conf
[07:52] <mok0> geser: thx I'll check it out
[07:53] <mok0> problem with dh_installman SOLVED. The stupid program wants a FILENAME in package.manpages. Thats great if you have a 100.
[07:53] <mok0> (not)
[08:07] <RainCT> is nautilus's right click -> "make a file" part from fileroller or on what package is it?
[08:07] <icf7>  /j #ubuntu-java
[08:07] <RainCT> (it isn't asking before overwritting a file)
[08:07] <icf7> say oops, ignore that
[08:09] <RainCT> ah ok
[08:09] <icf7> Anyway, is here someone who'd like to review http://revu.tauware.de/details.py?upid=5467 (Sunflow rendering system) ?
[08:18] <tobiasschulz> http://revu.tauware.de/details.py?upid=5474
[08:18] <tobiasschulz> can anyone look at this and advocate the program?
[08:26] <tobiasschulz>  http://revu.tauware.de/details.py?upid=5474
[08:26] <tobiasschulz> can anyone look at this ? what to do next?
[08:29] <RainCT> Any suggestion on easy app to package? :P
[08:33] <tarzeau> RainCT: python or not python?
[08:33] <tarzeau> RainCT: pick any which isn't packaged but you need?
[08:33] <tarzeau> RainCT: this one is easy, but it  don't have a license: http://www.aceinternet.co.uk/~mokona/
[08:34] <tarzeau> (well needs some install target, and path fixing i think)
[08:34] <tarzeau> (but not too hard)
[08:34] <tarzeau> you need to take care of savegames int ~/.hex-a-hop/ and data file into /usr/share/games/hex-a-hop/
[08:35] <ranf> Any MOTU is welcome to comment on "viking" http://revu.tauware.de/details.py?upid=5475
[08:35] <RainCT> tarzeau: how can I do that? just edit the source and create a patch?
[08:36] <jekil> someone can review please? http://revu.tauware.de/details.py?upid=5443
[08:36] <tarzeau> RainCT: debuild creates the patch, but you can also use dpatch or something
[08:38] <bluekuja> ranf, please check your copyright file
[08:38] <tarzeau> oh cool, thanks for the ir obex gui!
[08:38] <bluekuja> ranf, not all copyright holders has been listed
[08:38] <tarzeau> and the copyright year's missing
[08:38] <tobiasschulz> may a motu check http://revu.tauware.de/details.py?upid=5474 , please?
[08:38] <bluekuja> ranf, check source files to find out that 
[08:40] <bluekuja> tobiasschulz, why dont you remove .ex files?
[08:40] <bluekuja> tobiasschulz, package is not clean
[08:41] <bluekuja> tobiasschulz, it got some autogenerated files that need to be removed in clean target
[08:41] <tobiasschulz> bluekuja: only because these auto-gen.-files
[08:41] <tobiasschulz> and the ex files?
[08:41] <tobiasschulz> or something else?
[08:41] <bluekuja> checking
[08:42] <bluekuja> tobiasschulz, your copyright file is really bad
[08:42] <bluekuja> and source files doesnt have copyright headers
[08:43] <bluekuja> tobiasschulz, http://revu.tauware.de/revu1-incoming/jeliza-0706111350/jeliza-2.2.99.2/debian/copyright
[08:43] <bluekuja> tobiasschulz, thats not the right way to do a package desc
[08:43] <tobiasschulz> oh sorry ^^
[08:43] <bluekuja> control file contains lots of errors
[08:44] <bluekuja> tobiasschulz, you can remove dh_* commands that you dont use
[08:44] <ranf> bluekuja, will look. thanks.
[08:44] <RainCT> tarzeau: nice game, will try it :)
[08:44] <bluekuja> in rules
[08:44] <bluekuja> ranf, ;)
[08:45] <bluekuja> tobiasschulz, why do you have config.sub/guess stuff?
[08:45] <tarzeau> RainCT: good luck, if need help, ask me
[08:45] <bluekuja> in rules
[08:46] <bluekuja> tobiasschulz, you didnt add correct details in ubuntu
[08:46] <bluekuja> changelog
[08:46] <tobiasschulz> bluekuja: they should not be there. my program ist using qmake
[08:46] <bluekuja> tobiasschulz, you're not packaging for debian, so why unstable?
[08:46] <bluekuja> changelog entry is bad
[08:46] <bluekuja> that's not the way to descibe initial release
[08:46] <tobiasschulz> bluekuja: which details in ubuntu?
[08:47] <RainCT> if a program has no version should I name it program_releaseYearMonthDay ?
[08:47] <bluekuja> tobiasschulz, same for version
[08:47] <bluekuja> tobiasschulz, 2.2.99.2-2 is ok for debian, not for ubuntu
[08:47] <tobiasschulz> why?
[08:47] <bluekuja> tobiasschulz, example version for ubuntu
[08:47] <bluekuja> 0ubuntu1
[08:47] <bluekuja> if its the first release
[08:48] <bluekuja> tobiasschulz, 2.2.99.2-2ubuntu1
[08:48] <tobiasschulz> the upstream release is 2.3 beta
[08:48] <tobiasschulz> ok
[08:48] <bluekuja> so why do you use 2.2.99.2-2?
[08:48] <bluekuja> if its 2.3 beta?
[08:49] <tobiasschulz> 2.3 is not ready, so i thought i could use 2.2.<high number>
[08:49] <tobiasschulz> its the second beta
[08:49] <bluekuja> tobiasschulz, you have to use the version you're packaging
[08:50] <bluekuja> so if it's beta
[08:50] <bluekuja> it's beta
[08:50] <bluekuja> not previous one
[08:50] <tobiasschulz> 2.3beta2ubuntu1? ^^
[08:50] <tobiasschulz> or what?
[08:50] <bluekuja> version~beta0ubuntu1
[08:51] <bluekuja> use the tilde in this case
[08:51] <tobiasschulz> ok
[08:51] <bluekuja> tobiasschulz, anyway that package is FULL of errors
[08:51] <tobiasschulz> hm
[08:51] <bluekuja> and it cannot be accepted in the archive if you dont ask upstream to add copyright headers
[08:52] <bluekuja> as far as they dont publish it under GPL
[08:52] <tobiasschulz> i am the author ;)
[08:52] <bluekuja> (if its GPL)
[08:52] <tobiasschulz> ans its gpl
[08:52] <tobiasschulz> jeliza.sf.net
[08:52] <bluekuja> so add right headers
[08:52] <bluekuja> to your source
[08:53] <bluekuja> or you cant publish them
[08:53] <tobiasschulz> on top of all source files?
[08:53] <bluekuja> exactly
[08:53] <tobiasschulz> ok
[08:53] <bluekuja> just get an example from an existing package
[08:53] <bluekuja> in the archive
[08:53] <bluekuja> and add them
[08:54] <bluekuja> tobiasschulz, and fix the stuff I told you
[08:54] <bluekuja> example files are not needed
[08:54] <tobiasschulz> but what to add to debian/changelog, if the only new thing in this beta is a new help dialog?
[08:54] <bluekuja> remember to delete whatever you dont need in the maintainer script folder
[08:55] <bluekuja> tobiasschulz, if its a first release
[08:55] <bluekuja> just
[08:55] <bluekuja> * First package release
[08:55] <bluekuja> or somewthing like that
[08:55] <ranf> bluekuja, Is it ok to simply add the output of "grep -R Copyright *" to debian/copyright?
[08:55] <bluekuja> you dont need to close a bug as far as you haven't created one
[08:55] <tobiasschulz> do you think of a first ubuntu release or a first upstream? the first upstream release was a year ago
[08:55] <bluekuja> ranf, that not what I mean
[08:56] <bluekuja> ranf, you can simply see in diff.gz some files
[08:56] <bluekuja> with a copyright holder different from the one you posted
[08:56] <bluekuja> you need to list ALL
[08:56] <bluekuja> of them
[08:56] <RainCT> tarzeau: well, or perhaps I better wait for an answer from the author (I've send him a mail). on the top of the page it says Copyright 2005. Do you know of any other program?
[08:56] <bluekuja> tobiasschulz, changelog is about the *package*
[08:56] <bluekuja> not about source
[08:57] <tarzeau> RainCT: no. i sent hime one too :)
[08:57] <tarzeau> RainCT: did you play it yet?
[08:57] <bluekuja> so why do you add source stuff?
[08:57] <bluekuja> ranf, check modules.h
[08:57] <bluekuja> for example
[08:57] <tobiasschulz> so i have to add all things i have changed since june 2006 in debian/changelog =-O or what?
[08:58] <PriceChild> tobiasschulz, no. int he first package, you just put "Initial Release" or something to that effect.
[08:58] <bluekuja> ranf: please use Copyright Holder: stuff
[08:58] <ranf> oh I see
[08:58] <bluekuja> not the way you did
[08:58] <RainCT> tarzeau: yes, like it :)
[08:58] <bluekuja> tobiasschulz, changelog inside debian/
[08:59] <bluekuja> tobiasschulz, is for *PACKAGE*
[08:59] <bluekuja> revisions/entries
[08:59] <bluekuja> tobiasschulz, nothing to do with source changes
[08:59] <bluekuja> tobiasschulz, that are listed in source changelog (Changelog)
[08:59] <tobiasschulz> ok
[09:00] <bluekuja> tobiasschulz, please fix all this stuff and upload a fixed version
[09:00] <bluekuja> tobiasschulz, if you have any question, feel free to ask
[09:01] <RainCT> tarzeau: do you know Python? (if so, can I ask you a little question?)
[09:01] <bluekuja> tobiasschulz, I hope that the package builds
[09:02] <bluekuja> tobiasschulz, (I didnt check if its builds)
[09:02] <tarzeau> RainCT: no i hate python
[09:02] <RainCT> lol
[09:02] <tarzeau> heh
[09:02] <DktrKranz> d'oh!
[09:03] <tarzeau> but do you play bub-n-bros.sf.net ? or www.sauerbraten.org ?
[09:03] <DktrKranz> python rox :)
[09:03] <tarzeau> or do you know what game this is? telnet 80.219.76.235 27015
[09:04] <RainCT> tarzeau: no. no, but tried it some time ago. no xD
[09:06] <tarzeau> nethack
[09:08] <RainCT> no
[09:08] <tarzeau> best game!
[09:09] <RainCT> great graphics xD
[09:09] <tarzeau> :)
[09:11] <tarzeau> finally, i'm in gnomish mine town, the shopping mall of nethack
[09:12] <tarzeau> i robbed a shop by accident (killed a mimick, there was a bottle behind, i had not enough money for)
[09:12] <TheDumbo> anybody seen Seveas recently.
[09:12] <tarzeau> (but thanks god i had a scroll of teleport that got me near the ladders)
[09:18] <icf7> Call for review(and maybe advocation ;) ): http://revu.tauware.de/details.py?upid=5467 (Sunflow rendering system). Thanks in advance!
[10:09] <StevenHarperUK> Hi I have a REVU package uploaded how do I get a MOTU to review it ? http://revu.tauware.de/details.py?upid=5466
[10:11] <StevenHarperUK> 180 bits here and just me?
[10:11] <StevenHarperUK> **bots
[10:12] <RainCT> no, 179. you are also counted
[10:12] <RainCT> ;)
[10:12] <mok0> I'm getting a weird lintian error: duplicate-conffile -- but when I look at the package contents, there only IS one file
[10:14] <man-di> mok0: lintian -i ...deb gives you more infos about the error
[10:14] <mok0> got it! thx
[10:25] <jrib> http://revu.tauware.de/details.py?upid=5444 free picture of a cookie to the first reviewer!
[10:26] <jrib> StevenHarperUK: you have to offer cookies
[10:30] <crimsun> well, there is a distinction between a free picture of a cookie and a cookie
[10:30] <icf7> crimsun: So you would review for a real cookie? ;)
[10:30] <crimsun> now is it a Free picture of a cookie or just a free picture of a cookie?
[10:31] <jrib> Free, you can modify at as you wish
[10:31] <jrib> it even
[10:32] <crimsun> unfortunately I'm no one for cookies.  Now Free ponies...
[10:32] <jrib> crimsun: Free pictures of ponies?
[10:32] <crimsun> no, Free ponies :)
[10:32] <jrib> heh
[10:32] <jrib> @pony crimsun 
[10:32] <crimsun> I'll look after my bug list is a bit more reasonable
[10:33] <jrib> oh, guess it doesn't work here... I tried
[10:35] <mok0> jrib: Cookie? How about a beer
[10:35] <jrib> I guess I could buy some beer and take a picture of it too
[10:36] <mok0> Is anyone from this afternoon's inetd discussion around?
[10:38] <icf7> mok0: A free picture: http://upload.wikimedia.org/wikipedia/commons/5/57/Beer_mug.svg , pls review http://revu.tauware.de/details.py?upid=5467 !
[10:39] <mok0> icf7: Uhmm
[10:39] <jrib> don't be fooled, it's just foam, no beer
[10:39] <mok0> jrib: If you let it stand, foam -> beer
[11:09] <crimsun> hold onto your wazoos.  alsa-lib merge incoming.
[11:18] <RainCT> goog night
[12:13] <mok0> 1