[12:14] <geser> shawarma: looking through my old sync requests ubuntu-archive got additionally subscribed (u-u-s is still subscribed)
[12:42] <LaserJock> yeah, I think just add on  u-u-s
[12:43] <jonh_wendell> any motu guy here?
[12:43] <jonh_wendell> i have a doubt about a review
[12:45] <geser> jonh_wendell: ask
[12:45] <jonh_wendell> http://revu.tauware.de/details.py?upid=3584
[12:46] <jonh_wendell> the 3rd topic on dh@mailempfang.de review. what does he mean?
[12:50] <geser> you mean the python-all-dev build-dependency?
[12:50] <jonh_wendell> geser, yes. i already have this dependency...
[12:51] <jonh_wendell> i didn't understand...
[12:53] <geser> if you build-depend only on python2.4-dev your package will support only python2.4 as the files are only installed in /usr/lib/python2.4/site-packages
[12:53] <geser> if python will change to python2.5 as default you will have to update your package
[12:54] <geser> with python-all-dev it will support python2.5 since now
[12:55] <jonh_wendell> geser, see my build-depend: Build-Depends: debhelper (>= 5.0.0), python-all-dev, python-gtk2-dev
[12:55] <jonh_wendell> where is python2.4??
[12:55] <geser> $ apt-cache show python-all-dev | grep Depends
[12:55] <geser> Depends: python-all (= 2.4.3-11ubuntu3), python-dev (= 2.4.3-11ubuntu3), python2.4-dev, python2.5-dev
[12:56] <geser> it's pulled in though python-all-dev
[12:57] <jonh_wendell> geser, so, what's the solution?
[12:59] <geser> according to the debdiff you already changed it
[12:59] <jonh_wendell> geser, to say the truth, i did not understand one word from dholbach...
[01:00] <geser> it's about which python versions your package will support
[01:00] <geser> if you build-depend on python2.4-dev you will need python2.4 installed
[01:01] <geser> if you build-depend on python-all-dev you need to have python2.4 or python2.5 installed
[01:01] <geser> you don't have to fix your package if everything changes to use python2.5 by default
[01:01] <jonh_wendell> geser, i understand it, but i did not understand why he wrote this if i already depend on python-all-dev, like he suggested
[01:02] <geser> jonh_wendell: if I understand it he commented on the version which didn't have this change yet
[01:03] <jonh_wendell> strange...
[01:03] <jonh_wendell> the 4th comment, did you understand, geser?
[01:07] <geser> your had .svn/ dirs in your tar.gz (if I understand if correctly)
[01:07] <geser> also already fixed according to the last comment
[01:08] <jonh_wendell> geser, so, i have to do nothing so far, right?
[01:09] <jonh_wendell> geser, and about last 3 comments? really i did not understand
[01:10] <shawarma> Laser_away: Er... You mean "just add on u-a", right?
[01:11] <geser> jonh_wendell: have your read the Debian Python Policy?
[01:11] <jonh_wendell> geser, yes
[01:13] <geser> about the "E: fala: python-script-but-no-python-dep" point: I haven't checked but I would assume that the binary package is missing a python depencency
[01:13] <geser> sorry, I'm not very familiar with the python policy
[01:14] <jonh_wendell> right
[01:14] <geser> * debian/control: any -> all : your package is architecture independent therefore doesn't need to be build on every arch
[01:14] <geser> * debian/rules: move the build steps to binary-indep: this has to do with the former point
[01:15] <geser> build target is for architecture specific compilations
[01:15] <geser> and binary-indep is for architecure independent compiles
[01:16] <geser> both can even be used in the same rules file if you build a archictecture specific deb and an arch independent deb (e.g. a -doc package)
[01:39] <fernando> hi all
[01:56] <gnomefreak> was bitlbee merged yet?
[01:58] <ajmitch> gnomefreak: it's not on the merge list
[01:58] <ajmitch>    bitlbee |  1.0.3-1.1 | http://apt-proxy feisty/universe Packages
[01:58] <gnomefreak> that would mean its done?
[01:58] <ajmitch> note that it never needed merged
[01:59] <gnomefreak> ah crap
[01:59] <ajmitch> it was synced automatically
[01:59] <gnomefreak> we have issue with it and i would have thought merge would have handled it
[02:00] <gnomefreak> it doesnt install on feisty with the following error (makes me think its an upstream issue but not sure if merge or upstream)
[02:00] <gnomefreak> /var/lib/dpkg/info/bitlbee.postinst: 25: update-inetd: not found
[02:01] <imbrandon> thats a problem in ltsp server, you have to downgrade netkit
[02:01] <imbrandon> for somereason the netkit binry package dosent have it anymore
[02:02] <imbrandon> i havent had time to look at it
[02:02] <gnomefreak> ok ty imbrandon 
[02:02] <imbrandon> s/in ltsp server/in ltsp server also/
[02:03] <imbrandon> gnomefreak: just manualy downgrade your netkit binary from edgy for a stop-gap , maybe me or someone will get a chance to fix it soon
[02:03] <gnomefreak> ok
[02:04] <imbrandon> woot i love my workstation bandwidth, just wish i could use it for something other than downloading
[02:04] <imbrandon> Download Speed: 9942 kbps (1242.8 KB/sec transfer rate)
[02:04] <imbrandon> Upload Speed: 4713 kbps (589.1 KB/sec transfer rate)
[02:05] <ajmitch> gnomefreak: merges don't magically fix all bugs
[02:05] <ajmitch> imbrandon: the *easy* way is to install update-inetd
[02:05] <gnomefreak> ajmitch: no but syncs do
[02:05] <imbrandon> heya ajmitch 
[02:05] <ajmitch> update-inetd |   4.27-0.2 | http://apt-proxy feisty/main Packages
[02:05] <gnomefreak> that will work?
[02:06] <imbrandon> ahhh , netkit used to include update-inetd iirc 
[02:06] <imbrandon> but yea that would be much easier
[02:06] <imbrandon> :)
[02:06] <gnomefreak> someone is testing it atm
[02:07] <gnomefreak> its his issue but i tried to duplicate it
[02:07] <gnomefreak> and got to wondering
[02:07] <ajmitch> a number of packages are affected
[02:07] <imbrandon> probably got the binary split out and just needs to add it to the depends
[02:07] <ajmitch> maybe
[02:07] <imbrandon> i know ltsp-server is affected
[02:07] <ajmitch> I've heard that's not the case though
[02:07] <ajmitch> & samba
[02:07] <imbrandon> ahh
[02:07] <ajmitch> & anything else using it
[02:08] <imbrandon> wonder what it was if that wasent it
[02:08] <ajmitch> 08:01 < cjwatson> we could also just make our netbase depend on update-inetd for a while
[02:08] <ajmitch> so it may be fixed elsewhere
[02:09] <imbrandon> ahh
[02:09] <imbrandon> not perminately it dosent look like
[02:09] <ajmitch> hence why I haven't added the dependency to samba while merging (iirc)
[02:09] <gnomefreak> that would almost be too easy (just to add a depend to the control file?)
[02:09] <imbrandon> then again not much is perminate in comp[uters
[02:09] <ajmitch> no, the permanent solution is to switch to another -inetd package, I think
[02:09] <imbrandon> yea
[02:10] <ajmitch> that's what they were discussing right before that
[02:10] <ajmitch> 08:00 < cjwatson> one alternative would be switching to openbsd-inetd, since that depends on update-inetd
[02:10] <ajmitch> 08:00 < cjwatson> and then netbase would pull it in
[02:10] <ajmitch> 08:01 < ogra> does it behave any different to netkit-inetd ? i never tried it
[02:10] <ajmitch> 08:01 < cjwatson> we could also just make our netbase depend on update-inetd for a while
[02:10] <imbrandon> ahh
[02:10] <imbrandon> makes sinse
[02:10] <imbrandon> sense*
[02:12] <imbrandon> i almost installed BSD/Debian instead of Ubuntu about 2 years ago :)
[02:43] <jderose> I'm working on a Python app that needs to map iso-639 language codes to a localized language name. It seems I should use the data in the "iso-codes" package... does anyone know of a package that does this that I can look at as an example? Or any quick pointers on how to do this with the Python?
[02:47] <minghua> jderose: I don't know much about python, but iso-codes provides PO files which you can use gettext tool to extract the translations you need
[02:55] <fernando> jderose: http://www.python.org/doc/2.4.1/lib/module-gettext.html
[02:56] <jderose> minghua: yes, I understand how to go from the English name for the language to its translated name based on the locale (e.g., gettext "iso-639" "Spanish"). But I want to map the 639 code to the English name (e.g., es=>Spanish). Maybe the data in iso-codes isn't even what I use for this.
[02:57] <fernando> Somebody can to review http://revu.tauware.de/details.py?upid=3591 ?
[03:00] <minghua> jderose: give me a second, I'm looking at the iso-codes package now
[03:01] <jderose> minghua: thanks so much! (hope this isn't a silly question.)
[03:01] <minghua> jderose: no, not silly at all
[03:01] <minghua> and I am interested in this myself, as one of my package has a long language list as well
[03:02] <minghua> it would be useful to figure out how to use iso-codes in other packages for me
[03:03] <jderose> great. ;) i'm sure i could come up with some hack to do this, but i really what to do it by the current Ubuntu best practice, so i'm asking.
[03:04] <PLEASEHELP> what is this room for?
[03:05] <minghua> jderose: do you have a iso-codes source at hand?
[03:06] <minghua> jderose: I found that iso_3166/iso_3166.xml has the 2/3-letter code and the English name
[03:06] <jderose> minga: after just greping though iso_639.xml a bit, it seems that all the information i need is in there, but the rest of my problem is i just don't know much about xml parsing, like what parser i should use in Python... yeah, i'm looking at the iso-codes files right now.
[03:06] <minghua> jderose: however the README says the XML format is in flux, and you need to contact the author if you want to use it
[03:07] <jderose> hmmm... so there is no ubuntu library that abstracts the current format?
[03:08] <minghua> jderose: well, the notes/Country.pm file seems a perl module to do the transform for you
[03:10] <jderose> minghua: actually, looks like the "language-selector-common" package might hold the key: written in Python, depends on iso-codes. 
[03:10] <minghua> jderose: sounds good :-)
[03:11] <minghua> it seems this is not the problem iso-codes is trying to solve
[03:11] <minghua> python should already have something to translate the code to English name
[03:11] <jderose> maybe not. seems like a handy thing for say, totem when playing a dvd
[03:11] <jderose> do you know where i should look?
[03:12] <minghua> perl has Locale::Country for that (already in perl-modules)
[03:12] <jderose> (for such a module, class, whatever in python?).  gettext doesn't seem able to do that, unless i'm missing something.
[03:12] <minghua> no, that's not gettext's area either
[03:14] <jmon> devolpment?
[03:15] <jderose> minghua: thanks for your help! as far as Python goes, it looks like /usr/lib/python2.4/site-packages/LanguageSelector/LanguageSelector.py is a good example. cheers! ;)
[03:16] <minghua> jderose: you figured that out yourself :-)
[03:17] <jderose> minghua: well, i still appreciate your time.
[04:46] <imbrandon> ...
[04:46] <SAdministrator> hello
[04:47] <SAdministrator> welcome back
[04:47] <SAdministrator> :D
[04:50] <SAdministrator> imbrandon i might start purchasing more xbox's now that they are about ~80-90
[04:51] <zul> hey imbrandon 
[04:51] <SAdministrator> hello zakame 
[04:51] <SAdministrator> zul *
[05:55] <imbrandon> heay zul 
[05:59] <ajmitch> imbrandon: what's up?
[06:05] <imbrandon> ajmitch: nadda
[06:06] <imbrandon> just piddleing with some packages and my mail server
[06:06] <imbrandon> getting ready to head to sleep i think
[06:06] <imbrandon> you?
[06:19] <imbrandon> gnight all
[07:47] <crimsun> ademan: you may wish to ask vil for assistance with eclipse-cdt
[07:48] <ademan> crimsun: thanks I'll bother him, i actually think i may be on to something right now though, but i'll definitely talk to him
[07:52] <ademan> vil: In case crimsun's message didn't highlight, hopefully this one will, I'm trying to package an upstream update of the eclipse-cdt (because the current one doesn't work with eclipse) I'm having no luck thus far. i'd appreciate any help you can offer
[07:59] <ademan> hahah weak
[07:59] <crimsun> ?
[08:00] <ademan> vil has quit (Read error: 110 (Connection timed out))
[08:00] <crimsun> (that was not an intentional disconnect)
[08:00] <ademan> i know, just bad timing
[08:12] <ademan> hey crimsun: i'm trying to do uupdate with the -p option but it dumps a bunch of binary crap to my console and asks me to patch a certain file (whos name is also binary crap),  should i untar everything before i try to patch?
[08:12] <ademan> i assume the binary crap is just cause its gzipped
[08:14] <crimsun> need more details (please pastebin)
[08:15] <ademan> there was so much dump it went off the screen, but i'll show you what i got
[08:16] <ademan> http://www.rafb.net/paste/results/5cYKQQ60.html
[08:22] <crimsun> hmm.
[08:23] <crimsun> I wouldn't use the uupdate(1) approach
[08:23] <ademan> what should i do alternatively?
[08:24] <crimsun> I haven't studied eclipse-cdt, else I'd have walked you through it already :)
[08:24] <ademan> well i think i finally was able to match the source tree that's in the original source package
[08:28] <ademan> maybe i'll just try doing it without the -p option
[08:40] <ademan> crimsun: http://www.rafb.net/paste/results/yd3CAs58.html
[08:48] <ademan> same crap as always, i coulda sworn i had it this time
[08:49] <ademan> if its worth anything i ended up with a folder in the package dir named "results" which was part of the archive
[08:58] <crimsun> ademan: sorry, troubleshooting totem/gst/alsa atm
[09:00] <Burgundavia> crimsun: that fun?
[09:09] <crimsun> ademan: where's the new original upstream tarball?
[09:33] <ademan> crimsun: i believe i got disconnected but did you see the error dump i showed you? same crap as always
[09:33] <ademan> http://www.rafb.net/paste/results/yd3CAs58.html in case it got lost
[09:43] <superm1> hey guys, i'm running into something weird happening with my pbuilder:
[09:43] <superm1> dpkg-genchanges: error: badly formed line in files list file, line 5
[09:43] <superm1> the thing is, i don't have a single debian/files, but instead multiple *.files for the misc packages produced
[09:43] <superm1> and i cna't identify anything particularly wrong with them
[09:48] <ademan> superm1: i wish i could help, but i've got pbuilder problems of my own, plus i suck at this lol
[09:48] <superm1> :)
[09:49] <superm1> the pbuilder itself is good, i've used it dozens of times.  i just can't figure out what i did to the package to mess it up this bad :)
[09:57] <dholbach> good morning
[10:00] <tenshu> hello all
[10:09] <sivang> morning
[10:14] <sivang> dholbach: will you be willing to sponsor me an irda-utils merge btw ? (I know I owe you a gnome-themes merge though ;)) the upload is at http://muse.19inch.net/~sivan/merges/
[10:16] <dholbach> can you file a bug, attach the debdiff and subscribe ubuntu-main-sponsors?
[10:16] <dholbach> I'm quite busy atm
[10:17] <ademan> dholbach: can u subscribe ubuntu-main-sponsors to a bug without a debdiff? i've been butting my head against this stupid eclipse-cdt for about a week and a half to no avail now.  My head's starting to hurt :-)
[10:18] <dholbach> ademan: read again
[10:18] <dholbach> "attach a debdiff" :)
[10:18] <dholbach> but a package should be fine also
[10:18] <ademan> well dholbach that's my whole problem, i can't attach a debdiff, or even a package, i cant get the stupid thing to work
[10:19] <dholbach> ademan: doko is your man for eclipse - he just said that "you can't use uupdate with a zip file"
[10:19] <ademan> i'll continue to work at it, but it would be good if it got some attention from more capable hands
[10:19] <ademan> or a tar.gz?
[10:20] <sivang> dholbach: never mind, slomo turned up ;)
[10:22] <ademan> dholbach: well i bothered doko once and he said he'd never touched the cdt, and he was too busy to mess with it, i don't hold it against him, i just take it he's not in a position to help
[10:22] <dholbach> ok
[10:23] <dholbach> i'm sorry to say that I never touched anything java related, so I'm probably not the best person to talk to
[10:23] <dholbach> and I don't know which parts are important for packaging
[10:24] <dholbach> maybe you could talk to the debian maintainers or the upstream folks about that?
[10:28] <ajmitch> no, it didn't
[10:28] <ajmitch> how odd
[10:30] <\sh> moins
[10:30] <ajmitch> hi \sh 
[10:32] <doko> ademan: you could ask vil as well ...
[10:32] <\sh> hmm...how many days we have to wait until syncs are going through?
[10:33] <slomo> \sh: depends... some of mine are waiting already 3 weeks, some others got processed after 2 days ;)
[10:34] <ademan> doko: yeah, i was about to when he timed out
[10:34] <TheMuso> dholbach: If you were wondering about lsr for feisty, 0.3.2, i.e the latest has been uploaded to feisty.
[10:35] <dholbach> TheMuso: I noticed - thanks a lot for the good work
[10:35] <TheMuso> dholbach: np
[10:38] <TheMuso> Where can I find out more about the backport submission process?
[10:42] <\sh> slomo: hmm...
[10:42] <ajmitch> \sh: depends on how busy they are
[10:43] <\sh> so lets wait after herd 1
[10:44] <ajmitch> which should be "real soon now"
[10:44] <ajmitch> there have been a number of bugs to get sorted 
[10:44] <\sh> any ppc experts there and have time to check this build log? http://librarian.launchpad.net/5255140/buildlog_ubuntu-feisty-powerpc.dietlibc_0.30-4ubuntu1_FAILEDTOBUILD.txt.gz
[10:45] <ajmitch> if we're going to need to care about ppc soon :)
[11:17] <ajmitch> \sh: please make sure you follow the merge policy & list the remaing changes from debian
[11:18] <ajmitch> "Merge from debian unstable" is no longer enough
[11:26] <\sh> ajmitch: including the last changelog entries is not enough?
[11:27] <ajmitch> nope
[11:27] <ajmitch> they don't detail historic ubuntu changes
[11:28] <ajmitch> makes it easier for the next time things are merged
[11:28] <\sh> hmm? did I miss a documentation about that?
[11:28] <ajmitch> yep
[11:29] <ajmitch> it's on ubuntu-devel-announce somewhere
[11:29] <geser> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html
[11:29] <crimsun> nice to see our new MOTU stepping up :)
[11:29] <ajmitch> thanks
[11:30] <\sh> ajmitch:so you mean adding old  changes from ubuntu to actual changelog entry
[11:31] <\sh> e.g. tomcat5.5, doko added libxml4j-dev to build-dep in x.y-zubuntuR , this we have to document in latest changelog entry
[11:32] <crimsun> if it's still there, yep
[11:32] <\sh> .oO(that's too easy for newbies ,->)
[11:33] <\sh> ok...will be done..sorry for the mess
[11:33] <ajmitch> no problem, thanks for doing all these merges :)
[11:33] <ajmitch> I just saw a flood on the changes list
[11:34] <ajmitch> I'm almost at the bottom of the list of packages with my name on them for the merge list
[12:01] <wsb> Hi, I've some troubles formating a eula text to fit in debconf template, did so. know about a script doing this ? (replacing newline adding dots...)
[12:04] <gnomefreak> sun-java5-plugin for some reason is depending on iceweasle and wont install due to that. unless things changed i last remember we are keeping firefox.
[12:05] <StevenK> We were when that whole mess was raised when Debian switched.
[12:05] <StevenK> mdz (from memory) would know more.
[12:06] <StevenK> Maybe we could have our firefox packages Provides: iceweasel ?
[12:06] <StevenK> That's more a question for iwj, though. :-)
[12:08] <gnomefreak> as of right now we are sticking with FF so all packages should depnd on that if they need a browser as a depend not one that might or might not be included. but either way sun-java5-plugin is broken that was what i was meaning. i am filing a bug on it as we speak
[12:11] <StevenK> gnomefreak: Did someone request a sync of sun-java5-plugin, and break it?
[12:11] <gnomefreak> dont know
[12:11] <gnomefreak> i didnt see one
[12:11] <gnomefreak> not that i see
[12:12] <gnomefreak> https://launchpad.net/distros/ubuntu/+source/sun-java5/+bugs
[12:13] <gnomefreak> well thats was i was thinking whomever merged it kept debians version but never changed the control file to not depend on ice*
[12:14] <gnomefreak> brb need to start coffee IV
[12:15] <StevenK> Ahhhh, it's doko
[12:15] <StevenK>  1.5.0-08-0ubuntu1 was imported into Feisty from Edgy, and 1.5.0-10-0ubuntu1 was uploaded directly to Feisty.
[12:15] <StevenK> So get him. :-P
[12:17] <gnomefreak> if i see him ill ping him today. if i had an successful builds i would attempt it
[12:27] <jonh_wendell> dholbach, good morning
[12:27] <dholbach> hi jonh_wendell
[12:29] <jonh_wendell> dholbach, you have reviewed my package, but i guess you got the wrong upload... btw, i tried to follow your comments. can you review it again?
[12:29] <jonh_wendell> http://revu.tauware.de/details.py?upid=3683
[12:29] <dholbach> i'm busy with other stuff now, sorry
[12:29] <dholbach> if you drop me a mail i'll do it
[12:29] <dholbach> i clicked on the link you sent me
[12:29] <jonh_wendell> dholbach, thanks
[12:29] <ajmitch> jonh_wendell: why do you say it's the wrong upload? all comments for previous uploads are displayed on the page
[12:30] <ajmitch> dholbach didn't comment on the last 2 uploads of your package
[12:30] <jonh_wendell> ajmitch, because some daniel comments i had already  done
[12:30] <ajmitch> in the version he reviewed, they weren't done
[12:30] <dholbach> i commented on what was there at the time
[12:30] <jonh_wendell> btw, yesterday i uploaded it again with some modifications
[12:32] <jonh_wendell> ajmitch, dholbach: i'm talking about this because i did not understand some Daniel comments, and geser helped me with that opinion: that comment was 'obsolete' :)
[12:33] <jonh_wendell> sorry if i made any mistake
[12:35] <dholbach> I just reviewed what was there at the time
[12:35] <dholbach> maybe you did an upload shortly afterwards, I don't know
[12:36] <jonh_wendell> dholbach, no problem. i thank you because you're getting some time for me
[12:37] <dholbach> that's fine, i'm happy if I can help
[12:38] <jonh_wendell> definitely it's easier to develop than to package
[12:38] <crimsun> both are difficult
[12:44] <dholbach> vil became MOTU
[12:44] <dholbach> yooohooo
[12:44] <dholbach> can we try to make this a habit? :)
[12:44] <ajmitch> dholbach: don't forget the others!
[12:45] <dholbach> i'm just working my way through it
[12:45] <dholbach> (log)
[12:45] <ajmitch> dholbach: once the motu council is up & running, it should be a more regular thing
[12:45] <ajmitch> to have reporting to UWN, etc
[12:45] <ajmitch> since that's in the job description :)
 both are difficult 
[01:00] <xerxas> Happy to hear that 
[01:00] <xerxas> I was starting to think I'm dumb :)
[01:10] <xerxas> StevenK,  I think I start to understand much stuff 
[01:10] <jonh_wendell> fernando, take a look: http://www.ubuntu.com/ubuntu/TrademarkPolicy
[01:10] <xerxas> just when you learnt something, you use it once but it doesn't apply for the next package 
[01:10] <xerxas> sometimes some python specific stuff, sometime some mono specific stuff 
[01:11] <jonh_wendell> that's why i said it's better to develop than to package :)
[01:11] <xerxas> jonh_wendell,  I do agree with you but I do really suck at coding
[01:12] <fernando> jonh_wendell: thanks
[02:05] <\sh> hmmm...what was the rule to deal with icedove/iceweasel build-deps in debian and ubuntu?
[02:11] <fbond> crimsun: ping
[03:37] <fbond> what compat for feisty?
[03:40] <fbond> err, compat is 5; Standards-Version is 3.7.2 ? (feisty)
[03:50] <slomo> fbond: standards-version is correct, compat whatever you want it to be... <= 3 is deprecated afaik, 4 and 5 are fine
[03:55] <shawarma> Rock'n'roll! I just got my first accept mail!
[03:55] <zul> congrats
[03:56] <shawarma> zul: thanks!
[03:56] <sivang> congrets shawarma 
[04:03] <dholbach> shawarma: ROCK ON
[04:05] <shawarma> dholbach: Yeah! I could definitely get used to this. :-)
[04:05] <dholbach> that's good to hear :)
[04:13] <bddebian> Heya gang
[04:16] <crimsun> shouldn't the new MOTU join ubuntu-universe-sponsors? :)
[04:16] <crimsun> fbond: get it resolved?
[04:22] <dholbach> crimsun: good idea
[04:22] <dholbach> didn't we have a MOTU/OnceYou'veJoined or something? :)
[04:23] <zul> and does it include 30 whacks with a wet noodle? :)
[04:30] <fbond> crimsun, Re: usbfs, I spoke with Keybuk
[04:31] <fbond> He found that the problem is not related to usbfs, but that my udev rules were inappropriate for Edgy...
[04:31] <crimsun> ah, I see the bug report
[04:31] <shawarma> crimsun: Good point. I just applied.
[04:32] <crimsun> shawarma: excellent!
[04:32] <fbond> I will be uploading a version of midisport-firmware to revu for feisty; this will have new rules appropriate for that dist.
[04:32] <crimsun> fbond: great!
[04:32] <fbond> Just checking it in pbuilder right now...
[04:35] <jikanter> What are the advantages to using schroot over pbuilder.  Is one really significantly better than the other?
[04:35] <jikanter> s/./?/
[04:42] <crimsun> instead of sbuild?
[04:43] <proppy> dholbach: i've worked a bit on unittest++, move all the autotools stuff to a .patch
[04:43] <proppy> moved
[04:43] <dholbach> super
[04:44] <dholbach> if you drop me another mail, I'll have another look later on
[04:44] <proppy> dholbach: but i still call autoreconf
[04:44] <dholbach> oh, why?
[04:44] <proppy> dholbach: so the .patch can contains only configure.ac and Makefile.am
[04:44] <proppy> dholbach: and not the generated file
[04:44] <crimsun> yeah, we love auto* spew in the diff.gz :-)
[04:45] <dholbach> hm
[04:45] <dholbach> I usually have two patches then
[04:45] <proppy> dholbach: i fill weird to put generated file (i.e, no source), in a patch
[04:45] <fbond> crimsun, midisport-firmware uploaded, give it a minute, then maybe you can look it over?
[04:45] <dholbach> one for the configure.ac/Makefile.am and one for the changes in generated files
[04:45] <fbond> I have to go put winter tires on my car, be back...
[04:45] <crimsun> fbond: I'm severely backlogged on revu (and generally Ubuntu stuff); will queue it for later
[04:45] <dholbach> proppy: half of the gnome packages do that
[04:46] <dholbach> proppy: launchpad integration for example needs a change in configure.ac - that change will stay there even if there's a new upstream release
[04:46] <proppy> dholbach: i don't get it, there is no change in the generated file, i mean they're generated by autoconf
[04:46] <dholbach> but the autoconf call will have to be updated every now and then
[04:46] <fbond> crimsun, ok; do remember that it did have approval for edgy, but didn't get uploaded.  It's already been looked at several times over.
[04:47] <dholbach> proppy: I'd personally prefer to not run the autotools on the buildd but keep things nice and easy and do it on my box
[04:47] <proppy> dholbach: do you remember of a source package pointer ?
[04:47] <dholbach> source package pointer?
[04:47] <crimsun> fbond: if it has been approved, it hardly needs to block on me; just ask someone to upload it
[04:47] <fbond> crimsun, ok, thanks
[04:47] <proppy> dholbach: "half of the gnome packages do that"
[04:47] <crimsun> I need to train an alsa army or something
[04:47] <dholbach> proppy: gcalctool should be a good example of that
[04:47] <fbond> if anyone caught that, please have a look at http://revu.tauware.de/details.py?upid=3063
[04:47] <fbond> gotta run, BBL
[04:47] <proppy> dholbach: thanks a lot !
[04:48] <dholbach> proppy: de rien
[04:48] <proppy> dholbach: :)
[04:48] <dholbach> crimsun gives alsa classes!
[04:48] <proppy> dholbach: oh ok i get it
[04:49] <proppy> dholbach: you mean not only a package should be able to reconstruct the software from scratch
[04:49] <proppy> dholbach: it should also achieve this task as smooth as possible
[04:49] <proppy> right ?
[04:49] <Gloubiboulga> lfittl: hello, have you uploaded the picard package on REVU? it's a merge, so one ack is enough
[04:50] <dholbach> proppy: there was a brief article about that somewhere
[04:50] <proppy> dholbach: danke scheun
[04:51] <dholbach> hehe
[04:51] <dholbach> hmhmhm, not sure I find it
[04:51] <proppy> np
[04:54] <proppy> dholbach: remember there is no autotools at all in the upstream
[04:54] <proppy> dholbach: if i send the patch to the upstream, i should not send the generated file i guess
[04:54] <dholbach> probably not
[04:54] <proppy> dholbach: but the .ac and .am
[04:55] <dholbach> if you can tell them that they should use       make dist    to roll a release tarball they're probably going to be happy :)
[04:55] <proppy> dholbach: they are windows guy, i guess they're generating release with right click add to zip :(
[04:55] <dholbach> urg :/
[04:56] <dholbach> but how do they build it in windows?
[04:56] <proppy> vcproj
[04:56] <dholbach> hm
[04:56] <dholbach> ok
[04:57] <proppy> they is a Makefile too, but i contributed a autotools patch
[04:57] <proppy> there is
[04:57] <dholbach> then they should have a release manager who's able to roll a release tarball that everybody is happy with
[04:57] <proppy> maybe i should stick to the original Makefile
[04:57] <proppy> and remove all the autotools bloat
[04:57] <dholbach> if there's not chance of getting it accepted in upstream... :/
[04:58] <dholbach> and if it means a lot of maintenance for you
[04:58] <proppy> dunno, what generate the most of work
[04:58] <proppy> the less i put in the package
[04:58] <proppy> the less i have to maintain :)
[04:58] <dholbach> i'll leave the decision up to you ;)
[04:59] <proppy> dholbach: thanks for your thought :)
[04:59] <proppy> btw it is a good learning exercice :)
[05:01] <dholbach> you chose a good package to learn from :-)
[05:13] <proppy> i wonder where do you (maintainers) keep the trunk of your packaging sources (i.e all the file in debian/*) ?
[05:14] <proppy> revision control ?
[05:14] <proppy> bzr ?
[05:15] <crimsun> some of us use LP's bzr
[05:16] <proppy> crimsun: do you put the upstream tarball unpacked with it, or just the debian dir ?
[05:16] <crimsun> I normally dump all the source
[05:17] <proppy> and you import/merge the new source, once there is a new version
[05:17] <crimsun> correct
[05:18] <proppy> do you usely contribute the debian .diff to the upstream ?
[05:19] <crimsun> normally I push to BTS
[05:19] <crimsun> (Debian BTS)
[05:20] <proppy> crimsun: ok
[05:20] <proppy> crimsun: so your change get into the debian package as well
[05:21] <crimsun> yes
[05:21] <crimsun> sometimes it takes a little more poking
[05:21] <proppy> but in the end your file never get in the original upstream cvs ?
[05:21] <crimsun> they do
[05:21] <proppy> oh ok
[05:21] <crimsun> sometimes the changes are pushed through Debian BTS; sometimes directly from Ubuntu
[05:23] <proppy> so you must provide the necessary Makefile patch, to remove debian dir from the dist tar.gz ?
[05:24] <crimsun> are you asking about a specific tarball? Normally the orig.tar.gz doesn't contain a debian/
[05:26] <proppy> you're right, if you don't mention debian dir in the Makefile.am, they never get to the tarball anymay, so you don't have to explicitly remove it
[05:26] <proppy> my bad :)
[05:28] <proppy> crimsun: so in a ideal world, the package source repository, could easily be a branch of the upstream source repository
[05:29] <crimsun> proppy: hmm, that's almost a 'meta' question, and my strengths don't lie in VCS
[05:29] <crimsun> proppy: I'm more accustomed to seeing things like Debian's svn, where just the packaging is in some VCS
[05:35] <proppy> crimsun: thanks for your thoughts ! :)
[05:35] <proppy> oups
[05:36] <dholbach> I wonder when I'll be down to 300 desktop bug mails again
[05:36] <zul> never!
[05:36] <crimsun> d'oh, better disable my desktop-bugs auto-submitter
[05:36] <crimsun> err
[05:37] <dholbach> thanks for the confidence, zul
[05:43] <LaserJock> dholbach: they wouldn't be submitting bugs if they didn't have confidence that you were going to fix them ;-)
[05:45] <LaserJock> crimsun: doh
[05:47] <zul> dholbach: no problem :)
[05:54] <fbond> imbrandon, you had looked at this package for edgy, maybe you'd like to take another peek for the Feisty version? -> http://revu.tauware.de/details.py?upid=3690
[06:02] <crimsun> fbond: the debian/{dirs,install} have leading '/' . Is that intentional?
[06:05] <fbond> no; it should have little impact, however, I'm happy to fix it, of course
[06:06] <fbond> crimsun, thanks for looking
[06:11] <crimsun> fbond: (technically they're not supposed to be there :)
[06:11] <crimsun> fbond: [see dh_installdirs(1)] 
[06:13] <fbond> crimsun, ok I will upload a fixed version; any other issues that you can see?
[06:13] <crimsun> sec, juggling a few dozen things
[06:16] <crimsun> debian/postrm looks dangerous
[06:17] <crimsun> --> rm -f /usr/share/usb/maudio/*.ihx
[06:17] <crimsun> it would be much better to actually enumerate each .ihx file
[06:18] <crimsun> in the chance that there's a user-installed /usr/share/usb/maudio/foo.ihx, that file would be removed, too, which is not what you want
[06:21] <crimsun> debian/postinst needs to be fixed to exit properly if mktemp fails
[06:22] <crimsun> (if you need an example, look at that portion of alsa-utils's debian/patches/20_alsaconf_safe_tmp.dpatch
[06:22] <crimsun> )
[06:28] <palski> Opinions please, is bug #67553 worth of SRU? Siege is not usable at all on edgy because of that bug.
[06:28] <Ubugtu> Malone bug 67553 in siege "double free or corruption in siege" [Undecided,Fix released]  http://launchpad.net/bugs/67553
[06:29] <crimsun> palski: yes, it's worth an SRU
[06:29] <crimsun> the diff is trivial
[06:29] <palski> ok, thanks
[06:31] <crimsun> fbond: (hope you've been noting the above issues; here are more:)
[06:32] <crimsun> fbond: debian/preinst uses ping to test, and that will fail for configurations where a firewall/gateway blocks icmp. I suggest testing for then using ``host www.google.com'' instead.
[06:35] <crimsun> fbond: and finally, please use ATTRS{} in 42-midisport-firmware.rules.in as Scott noted in the last comment of #70968
[06:35] <crimsun> fbond: please fix those issues, and resubmit
[06:37] <crimsun> fbond: again, thanks for working on the packaging!
[06:39] <fbond> crimsun, ok noted all comments, fixed version will be uploaded shortly
[06:39] <fbond> thanks!
[06:39] <proppy> yeah!
[06:39] <crimsun> fbond: np
[06:42] <crimsun> fbond: and to be technically correct, bind9-host would need to be added to debian/control:Depends
[06:43] <crimsun> (sorry, should have caught that sooner)
[06:44] <dholbach> LaserJock: the motu science team should probably subscribe to genius' bugs
[06:45] <dholbach> (not that there are any, but oh well...) :)
[06:49] <bddebian> crimsun IS a genius! :-)
[06:50] <crimsun> nope, but I tend to fixate on sound bugs
[06:50] <crimsun> bddebian is one-third of the resident trinity in here
[06:50] <fbond> crimsun, alright will upload in a sec, however:
[06:51] <bddebian> crimsun: no way man :-(
[06:51] <geser> I'm currently looking at ilohamail on MoM: new package revisions must be greater the current one?
[06:51] <fbond> should the package pre-depend on wget | curl, bind9-host, etc ... since it uses them in preinst/postinst ?
[06:52] <crimsun> isn't ilohamail one of the nasty versioned ones?
[06:52] <crimsun> (I think that was one of mine, no?)
[06:52] <geser> yes, it's one of yours and it a nasty versioning
[06:52] <crimsun> fbond: I tend to use Pre-Depends -very- sparingly
[06:53] <geser> ubuntu has -0rc3ubuntu1 and debian has -0rc3sid3 which is smaller
[06:53] <fbond> yes, I understand it is to be avoided, however, if one happens to be installing wget & midisport-firmware simultaneously, will the download fail ?
[06:53] <NetAdministrator> does anyone know why network interface priority was taken out of the network administration dialog on edgy?
[06:54] <geser> fbond: IIRC you need Pre-Depends for preinst and can use Depends in postinsts
[06:54] <fbond> geser, thanks
[06:54] <fbond> crimsun, does that sound right to you?
[06:54] <crimsun> fbond: yes
[06:54] <fbond> so, bind9-host needs to be Pre-Depends ...
[06:55] <geser> if you use it in your preinst
[06:55] <geser> see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[06:57] <tsmithe> hi geser! how's the new motuship?
[06:58] <HumanPrototype> how can i get involved with helping with ubuntu?
[06:58] <tsmithe> loyd
[06:58] <tsmithe> lots
[06:58] <tsmithe> not loyd
[06:58] <tsmithe> stupid fingers
[06:58] <tsmithe> hang on there's a page
[06:59] <tsmithe> http://www.ubuntu.com/community/participate
[06:59] <HumanPrototype> tsmithe, thanks
[07:00] <tsmithe> it's easiest if you find something you enjoy doing, and do it
[07:00] <tsmithe> so, any direction i give could be more likely than not inappropriate
[07:00] <siretart> HumanPrototype: http://www.ubuntu.com/developers. follow the links, they should you getting started
[07:00] <siretart> should help you, even
[07:02] <HumanPrototype> siretart, thanks
[07:03] <tsmithe> oh; and i guess i'm a motu enthusiast (and i really need to learn the packaging ropes...); but https://wiki.ubuntu.com/MOTU/Enthusiasts is not a page
[07:03] <geser> crimsun: is it ok if I look at the ilohamail merge?
[07:03] <crimsun> geser: absolutely
[07:03] <Sp4rKy> siretart: i've some problem with setup of revu
[07:04] <geser> crimsun: it looks like a sync candidate but can't because of the version. should it be fake sync as -0rc3ubuntu2 and mentioning it in the changelog? or is there a better solution?
[07:05] <crimsun> geser: you'll have to fakesync
[07:05] <geser> as -0rc3ubuntu2?
[07:05] <crimsun> geser: same situation as NMUs for native packages
[07:06] <Sp4rKy> siretart: can you take a look at http://revu.dunnewind.net/
[07:06] <crimsun> geser: 0.8.14-0rc3ubuntu2, yes
[07:07] <Sp4rKy> siretart: whereas the mod_python is installed, and i've follow the README of revu
[07:08] <fbond> crimsun, midisport-firmware is uploading.  thanks again for your help.
[07:08] <siretart> Sp4rKy: it looks to me like a problem in your mod-python setup
[07:08] <crimsun> fbond: np
[07:08] <Sp4rKy> siretart: i've just apt-get install libapache2-mod_python
[07:09] <siretart> Sp4rKy: I'm happy to help you with that next week, okay?
[07:09] <siretart> Sp4rKy: anyway, what do you intend to do with the revu1 code?
[07:10] <Sp4rKy> siretart: to install it on my own server
[07:10] <Sp4rKy> siretart: should i take the revu2 ?
[07:13] <siretart> Sp4rKy: revu1 was rather a proof on concept, and has a really horrible code base. the code for revu2 is unfinished and nowehere usable, but we want to concentrate on that to implement the REVU2 spec
[07:13] <Sp4rKy> k
[07:13] <LaserJock> tsmithe: we don't really use the term MOTU Enthusiast
[07:13] <tsmithe> that's a silly link then
[07:13] <LaserJock> tsmithe: and any references will probably be going away
[07:13] <tsmithe> right on
[07:14] <LaserJock> you're a MOTU Hopeful ;-)
[07:14] <tsmithe> yay!
[07:14] <tsmithe> but i really know very little
[07:14] <tsmithe> except what i've done with asoundconf-gtk
[07:15] <LaserJock> but you're learning, that's the point
[07:16] <tsmithe> no
[07:16] <tsmithe> that didn't come out right
[07:16] <tsmithe> i guess
[07:33] <lfittl> Gloubiboulga: no I haven't uploaded it, but I can do that now if you want
[07:34] <lfittl> (the picard package on REVU)
[07:37] <crimsun> I am so confused.
[07:37] <LaserJock> yikes
[07:37] <crimsun> "I have no sound in Feisty 7.04 ... Anyway - my sound works fine with the headphones"
[07:37] <crimsun> ?!@
[07:37] <LaserJock> hmmm
[07:38] <Gloubiboulga> lfittl: that'd be nice :)
[07:38] <zul> crimsun: i think someone else is confused
[07:42] <LaserJock> crimsun: it makes perfect sense to me :-)
[07:43] <crimsun> LaserJock: I'm happy to assign 74677 to you :-)
[07:46] <LaserJock> crimsun: ummmmmm, no
[07:46] <crimsun> aww c'mon, everyone's doing it
[07:47] <LaserJock> heh
[07:57] <tsmithe> i'm sure someone wants to review my package ;)
[07:58] <LaserJock> maybe when I get my current REVU todo list done ;-)
[07:59] <tsmithe> yay!
[08:00] <tsmithe> whenever's great
[08:06] <LaserJock> tsmithe: what's the URL?
[08:06] <tsmithe> ah corse
[08:06] <tsmithe> http://revu.tauware.de/details.py?upid=3669
[08:07] <tsmithe> thanks :)
[08:07] <LaserJock> ok, well I'll put it on my list
[08:07] <LaserJock> but it could take some time as I have a bunch of work
[08:07] <tsmithe> as do we all
[08:14] <HumanPrototype> is the stuff in the ubuntu server guide at help.ubuntu.com fixed or is it editable like the wiki?
[08:15] <HumanPrototype> also who is responsible for the jabber package?
[08:16] <crimsun> HumanPrototype: MOTU.
[08:16] <LaserJock> HumanPrototype: it's fixed, but you can file a bug report if there's a problem (or talk to #ubuntu-doc)
[08:16] <LaserJock> tag-teamed that one
[08:16] <crimsun> HumanPrototype: meaning, Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists dot ubuntu dot com>
[08:18] <HumanPrototype> if it helps its in universe/net
[08:18] <crimsun> (I just stated who's responsible.)
[09:04] <fbond> crimsun, one last look, maybe? -> http://revu.tauware.de/details.py?upid=3692
[09:05] <fbond> sorry to pester; it's been on my TODO for too long
[09:05] <fbond> of course, if anyone else wants to take a peak, he or she is welcome to do so
[09:09] <superm1_> hey guys is there a way to make pbuilder not clean up after itself?  I am having a package fail on building in my pbuilder, but can't seem to debug the exact problem since pbuilder deletes everything when its done
[09:10] <superm1_> unless i'm missing it, i'm not seeing it in the man page
[09:10] <mr_pouit> you can use "pbuilder login" and build it manually
[09:11] <superm1_> so once i'm in the chroot, just dpkg-buildpackage?
[09:12] <mr_pouit> yes (or debuild), but I am not sure it automatically installs dependencies :/
[09:12] <superm1_> oh that could be ugly..... :)
[09:20] <superm1_> is there an easy way to have debuild or dpkg-buildpackage read the debian/control to figure out the build deps from my package though? i'm not sure what it actually does to resolve these during pbuilding
[09:21] <engla> does the upstream tarball and our package_v.orig.tar.gz have to be bit-identical? I mean even if the files are exactly the same the mtime is different for some reason
[09:21] <engla> but it should be right
[09:23] <engla> superm1_: I'm not sure, why not do that work yourself?
[09:24] <engla> relating to my Q above: the debdiff only contains files in debian/, that's the thing right
[09:25] <fdoving> superm1: you can run '/usr/lib/pbuilder/pbuilder-satisfydepends' if you have pbuilder installed. that will read debian/control to find build-deps.. 
[09:32] <geser> engla: do you mean diff.gz?
[09:35] <engla> yeah, but I was mainly talking about the orig tarball
[09:35] <engla> it's not bit-perfect identical with the upstream one
[09:35] <engla> but the files should be
[09:35] <engla> as I said, the mtimes differ
[09:36] <engla> now, is that a problem? I don't know
[09:36] <geser> but the md5sums are identical of both tarballs?
[09:37] <engla> I don't think they are
[09:39] <engla> the md5sums differ but if I unpack them, recursive diff says they are identical
[09:45] <fdoving> engla: md5 should match if possible.
[09:45] <fdoving> engla: does upstream provide a .tar.gz ? if that's the case, simply rename it to *orig.tar.gz
[09:46] <fdoving> engla: if they supply .bz2 you can bunzip2 and gzip -9 the .tar
[09:56] <engla> I'm upstream. But I really don't care. I think it's just hte config file that is cleaned and regenerated exactly the same
[09:56] <engla> I don't get why the orig file is touched by debuild anyway, so I'll leave it as it is.. after all, the content is identical
[10:09] <superm1_> thanks fdoving 
[10:10] <fdoving> engla: the idea is that you include a debian/watch file, with information (man uscan) on how uscan can fetch your upstream released sources.
[10:11] <fdoving> engla: if you do that, you can maintain the debian/ directory in svn or bzr or any other rcs and easily fetch the upstream source directly.
[10:20] <joejaxx> where are the logs from ubuntu-meeting kept?
[10:22] <joejaxx> nevermind found them
[10:25] <T`> hi.. i want to repackage my own deb package from new sources for verve-plugin... is there some tutorial on how to do this? and is there a .spec equivalent for .deb?
[10:27] <superm1_> chttp://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[10:27] <superm1_> http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[10:27] <superm1_> T`, ^
[10:58] <jorgp> I have edgy installed, trying to backport something to dapper
[10:59] <jorgp> I have a pbuilder of the dapper
[10:59] <jorgp> but when I try to build the app, I get configure: error: C compiler cannot create executables from the configure file
[11:00] <jorgp> what am I missing
[11:01] <phanatic> any MOTUs around for a review? http://revu.tauware.de/details.py?upid=3554
[11:03] <ajmitch> phanatic: I see it's a mono app now?
[11:03] <ajmitch> can you please follow the CLI policy on build-depends, you don't need things like gtk-sharp2
[11:04] <ajmitch> since I doubt you need to drag in everything from gtk#
[11:05] <phanatic> ajmitch: pretty much stuff is needed (almost everything), but i'll try to sort them out. do you have a recent CLI policy link at hand maybe?
[11:05] <ajmitch> also, what's arch-dependent about this package?
[11:05] <slomo> phanatic: http://pkg-mono.alioth.debian.org/cli-policy/
[11:06] <phanatic> slomo: thanks
[11:06] <ajmitch> thanks slomo
[11:08] <phanatic> what's te difference between managed and native code? and how could i find out which one has the given app?
[11:10] <slomo> phanatic: managed is everything compiled to CIL bytecode, native everything compiled to your machine's "bytecode"
[11:10] <jorgp> anyone help me with my pbuilder problem?
[11:11] <slomo> phanatic: and as your package only consists from c# sources it's most likely arch independend and completely managed
[11:11] <phanatic> slomo: thanks a lot!
[11:13] <guibis> Hi slomo
[11:13] <slomo> hi guibis 
[11:15] <guibis> i write to you a mail slomo.
[11:16] <guibis> at your four mail adres writing in LP ( sorry for the flood).
[11:16] <guibis> :/
[11:17] <guibis> it's about packaging.
[11:17] <slomo> ok ;)
[11:19] <guibis> because i try to package .net ...
[11:19] <guibis> and it's quite hard for me.
[11:20] <guibis> you can ansewer now at this chan, or write back to me a mail.
[11:20] <guibis> no problem :-)
[11:21] <slomo> guibis: probably via mail tomorrow :) i wanted to go to bed in a few minutes
[11:21] <slomo> but what exactly do you want to package?
[11:21] <guibis> ok no problem
[11:22] <guibis> exactly i want to package this http://okapi.sourceforge.net/Release/Utilities/Help/dnllistedit.htm
[11:22] <guibis> the dnl soft
[11:24] <guibis> i need this program in order to package sheepshaver  (SheepShaver is a MacOS run-time environment for BeOS and Linux)
[11:41] <phanatic> ajmitch: i did some tests, and the package only compiles with build-dep gnome-sharp2
[11:43] <ajmitch> then add the appropriate packages that gnome-sharp2 depends on 
[11:43] <ajmitch> they should only be the -cil packages you need
[11:46] <phanatic> ajmitch: the funny thing is that if i add the cil packages, it won't build
[11:48] <slomo> phanatic: that's impossible as gnome-sharp2 is only a metapackage and has no real content
[11:49] <phanatic> slomo: yes, sorry... false alarm. missed one dependency
[11:53] <guibis> slomo: i go to my bed sooner as you see you :-) !
[11:56] <vil> hi, I am fresh new MOTU (maybe someone noticed :)
[11:56] <vil> I would like to ask about any uploading policy
[11:58] <LaserJock> what do you need?
[11:59] <vil> i have a package waiting quite some time already and would like to put it in feisty
[11:59] <vil> until now, I always asked doko to do the upload
[12:01] <vil> can i now just go ahead and do dput?
[12:02] <phanatic> ajmitch: do i need to care about this: "E: sysinfo source: build-depends-indep-should-be-build-depends debhelper"?
[12:02] <phanatic> (lintian error)
[12:08] <LaserJock> vil: is this a new package or a patch or a merge or ...?
[12:08] <shawarma> I'm working on merging gimp-dcraw. We had a new upstream version before Debian, but Debian did their own package now and the orig.tar.gz don't match. What to do?
[12:08] <LaserJock> shawarma: same version of upstream?
[12:09] <shawarma> LaserJock: Yup.
[12:09] <LaserJock> how are the 2 .orig.tar.gz's different?
[12:09] <shawarma> LaserJock: Beats me.
[12:09] <phanatic> any ideas about the above? i should fix lintian errors, right?
[12:09] <shawarma> different size and hence md5sum.
[12:09] <LaserJock> shawarma: can you diff them?
[12:09] <vil> LaserJock: new upstream + some additional patches, so I guess ... patch
[12:10] <LaserJock> phanatic: what does it have for Build-Depends?
[12:10] <shawarma> LaserJock: I suppose.
[12:10] <LaserJock> vil: but not a merge?
[12:10] <LaserJock> shawarma: I just wondered
[12:11] <LaserJock> they really shouldn't be different
[12:11] <phanatic> LaserJock: according to the cli policy, i moved all build-deps to Build-Depends-Indep, so currently there is nothing under Build-Depends
[12:11] <vil> LaserJock: no, it's not in Debian at all
[12:12] <mr_pouit> phanatic: I think debhelper should stay in Build-Depends
[12:12] <LaserJock> phanatic: does the clean rule have a dh_* ?
[12:12] <LaserJock> if so then debhelper should be in Build-Depends
[12:12] <phanatic> LaserJock: it has. then i'll move it to Build-Depends
[12:13] <phanatic> thank you guys for the help