[00:15] <^arky^> geser: thank you will remember to use update-maintainer in future
=== Anzenketh|away is now known as tuxmaster
=== tuxmaster is now known as anzenketh
=== StevenK_ is now known as StevenK
[05:14] <ddecator> can someone familiar with 'ar' look at this and let me know why it returns "ar: two different operation options specified"?: http://pastebin.ubuntu.com/398155/
[05:14] <ddecator> (i get this while trying to get sqlite to build for songbird)
[05:17] <persia> ddecator: I think you7re missing an instruction.  I think you need `ar r ${FILES}` or similar.  I may be mistaken.
[05:17] <ddecator> persia: i'll give that a shot. thanks
[05:18] <persia> ddecator: man ar : you man need some modifiers (e.g. "rc" rather than "r")
[05:18] <ddecator> persia: thanks. i'm not very good at figuring out when to use which arguments for what yet, haha
[05:19] <persia> The trick is with older programs like tar or ar where the '-' is optional for passed options.
[05:20] <persia> e.g. `tar xf ...` and `tar -xf ...` are equivalent.  Woe betide the person who tries to deal with xf.tgz unprepared.
[05:23] <ddecator> of course, now i get the fun of what script is causing it to revert back to 'ar' instead of 'ar r'
[05:24] <persia> Really, `ar r` may not be complete.
[05:24] <persia> And I'm not a big ar user, I just read the manual, so I could be completely wrong.
[05:24] <persia> So my recommendation would be to play with ar and make sure you understand which command you want.
[05:24] <persia> Only then does it make sense to fiddle the build scripts.
[05:28] <ddecator> i'll do that once i can figure out where the makefile is being auto configured so that any changes i make are reverted...
[05:30] <persia> Usually in ./configure
[05:31] <ddecator> right, it's just a huge file, haha
[05:32] <ddecator> oh wait..
[05:33] <ddecator> looks like it's supposed to use 'ar cr' but the conditions aren't right or something...heading in the right direction though
[05:35] <persia> cr or rc would make sense, based on the manpage.
[05:37] <ddecator> what the...even the configure file got reconfigured on me
[05:37] <persia> Do you have configure.in or configure.am ?
[05:38] <persia> If so, those are the culprits .am -> .in ->
[05:38] <persia> If not, check debian/rules (or for a new package, INSTALL) for guidance.
[05:39] <ddecator> it's just "configure" there is no "configure.am" or "configure.in", but there are "config.*" files and a "configure.ac"
[05:39] <persia> check configure.ac, but check debian/rules and INSTALL
[05:39] <ddecator> configure.ac is blank...
[05:39] <ddecator> nvm
[05:40] <ddecator> typed the name wrong, haha
[05:40] <ddecator> i'm not used to using terminal for everything...
[05:44] <ddecator> yah, even configure.ac is being autoconfiged
[05:53] <ddecator> even config.cache is resetting...
[05:54] <ddecator> nope, never mind, making progress...
[05:55] <persia> Really, check INSTALL or debian/rules.  It will explain how the build happens.
[05:58] <ddecator> i setup the rules file for this part of the build, not sure where the INSTALL file is located
[07:35] <ddecator> i've identified the problem as $(AR) not being defined correctly, but i can't find where it's defined
[07:36] <persia> might be an implicit define : check the make manual (no, not man make, but the real manual)
[07:42] <ddecator> aha, i think i figured it out. thanks persia
[07:43] <ddecator> yup, that did it =)
[07:43] <persia> Great.
[08:08] <anzenketh> Hello i was wondering where there is more information in regards to the rules file. Or a updated version of https://wiki.ubuntu.com/PackagingGuide/Complete
[08:09] <anzenketh> I am trying to make a package from scratch
[08:10] <hyperair> anzenketh: http://www.debian.org/doc/debian-policy/ch-source.html <-- see section 4.9
[08:11] <hyperair> you're advised to use debhelper though
[08:11] <anzenketh> I plan on using debhelper
[08:12] <hyperair> man dh
[08:12] <anzenketh> basicly so far I have run dhmake edit the changelog edited control and edited copyright
[08:12] <hyperair> dh_make's debian/rules is hopelessly outdated.
[08:12] <anzenketh> ahh
[08:13] <hyperair> just rm it and copy the one from /usr/share/doc/debhelper/examples/rules.tiny
[08:13] <hyperair> you'll have to bump debhelper's version in build-depends to 7.0.50 as well
[08:14] <anzenketh> Do I still want to use dh_make to make the other files
[08:15] <anzenketh> Or is there a new updated way to create all of the debian files
[08:25] <anzenketh> Basicly I am looking for the best place to learn how to create my first ubuntu package from scratch.
[08:57] <persia> hyperair: Don't need 7.0.50 for rules.tiny: only 7.0.0.  7.0.50 is for overrides.
[08:58] <persia> anzenketh: I'll really put this on a wiki page soon, but here's the recipe:
[08:58] <persia> 1) mkdir -p ${package}/debian; cd ${package*
[08:59] <persia> 2) echo 7 > debian/compat; cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules
[08:59] <persia> 3) dch --create to generate debian/changelog
[08:59] <persia> 4) create debian/control based on policy 5.2
[09:00] <persia> 5) create debian/watch based on man uscan
[09:00] <persia> 6) uscan to get the latest sources; unpack; move debian/ in there.
[09:00] <persia> 7) review *all* the files and generate debian/copyright (DEP5 is nice)
[09:01] <persia> 8) build the source and fix bugs as you find them
[09:11] <anzenketh> persia: how up to date is the maint-guide obtained though sudo apt-get install maint-guide
[09:12] <persia> anzenketh: Looks like it hasn't changed in at least a year.
[09:12] <persia> anzenketh: Check the changelog for more.
[09:15] <anzenketh> looks like sep 2008 how much would I be missing on that becosue the wiki is not up to date the maitnance guide is not up to date
[09:15] <persia> Both the maint-guide and the wiki will give you usable instructions.
[09:15] <anzenketh> Basicly would I know enough to sucessfuly create a package
[09:15] <anzenketh> ok
[09:15] <persia> Following my quick guide above may or may not be easier/faster depending on your upstream source.
[09:16] <anzenketh> It is a rather complecated package
[09:16] <persia> why?
[09:17] <anzenketh> It is amahi I am trying to port it over to ubuntu. Complecated due to it includes inits and adds to the bins
[09:17] <anzenketh> but that is about the complexity of it
[09:17] <persia> What do you mean "adds to the bins" ?
[09:18] <ddecator> just for the record, i found the MOTU videos to be helpful, even if they are outdated ;)
[09:18] <anzenketh> Ya I watched those too I understand everything but rules
[09:18] <persia> For includes inits, dh_installinit should do the job, and rules.tiny runs that automatically.
[09:19] <persia> Really, unless you need something special, use rules.tiny.
[09:19] <persia> It works 90% of the time without extra thought.
[09:21] <anzenketh> Basicly this package is a ruby source with some c creates some init.d files and most the files go to /usr/bin and changes some config files and adds some directories
[09:23] <persia> Adding init.d files and putting files in /usr/bin is fine (as long as it doesn't conflict with other files there).
[09:24] <anzenketh> it won't
[09:24] <persia> Changing configuration files is only allowed if those configuration files are specifically related to your package.  Changing conffiles is futher only permitted if the user hasn't changed them manually.
[09:25] <anzenketh> the tiny will create the directories as long as i have them specified right?
[09:26] <persia> rules.tiny will install everything in the places specified by the upstream build system install rule.
[09:27] <persia> You can use debian/amahi.install to add anything that is missing.
[09:27] <sebner> hyperair: grrrrr, 87MB updates and no banshee :\
[09:27] <anzenketh> ahh ok
[09:27] <sebner> huhu persia :)
[09:27] <anzenketh> I think I will give it a wearl
[09:27] <persia> anzenketh: It does assume the upstream build system just works.  If that's not true, it's worth fixing it upstream.
[09:30] <directhex> sebner, i'm not leaning on anyone since 1.5.6 is due within hours-ish
[09:30] <sebner> directhex: wasn't that the same with 1.5.5 ^_^
[09:31] <directhex> sebner, ywah, but there was a freez
[09:32] <directhex> also, b-c-e clearing NEW is good news for us
[09:32] <sebner> directhex: freeze, pffffffffffffffffffffffffffff
[09:32] <sebner> directhex: sure
[09:33] <hyperair> sebner: hmm?
[09:33] <directhex> since it means archive admins can just trust debian & don't need to spend any time on ubuntu NEW
[09:33] <sebner> directhex: well, waiting for next week then :)
[09:33] <sebner> hyperair: ~~~ = 0_o = ~~~~
[09:33] <hyperair> sebner: it's in the PPA =D
[09:34] <sebner> hyperair: we need archive!
[09:34] <directhex> hyperair, is b-c-e in the PPA?
[09:34] <hyperair> directhex: er no it isn't.
[09:34] <hyperair> directhex: should we upload b-c-e to ubuntu?
[09:34] <hyperair> directhex: or do we have something we have to wait for... oh wait, stupid question.
[09:35] <directhex> hyperair, we need to wait for banshee to be synced, but given how imminent 1.5.6 is meant to be, i haven't leaned on anyone to sync 1.5.5
[09:35]  * hyperair sighs.
[09:35] <hyperair> oh well.
[09:35] <hyperair> let's hope 1.5.6 doesn't go the same way as the previous two.
[09:35] <Laney> patience, lads
[09:36] <Laney> i expect syncs will be done at the start of the week
[09:36] <hyperair> o yay.
[09:36] <hyperair> i'll be internetless for the next two days or so
[09:36] <hyperair> make that one and a half days.
[09:37]  * Laney pats hyperair 
[09:37] <Laney> it'll be alright in the end, I promise
[09:37] <directhex> download the internets onto your hard disk so you aren't disconnected!
[09:37]  * hyperair weeps
[09:38] <hyperair> to maximize the clicheness of this moment, i suppose i should be burying my face in Laney's chest and bawling my eyes out
[09:39] <directhex> http://www.penny-arcade.com/comic/2002/7/1/
[09:40] <hyperair> ._.
[09:40] <hyperair> sign language?
=== shadeslayer is now known as shadeslayer_
[10:08] <muelli> hey folks :) I want to package a Python application which brings some public modules. It's called Volatility (from http://code.google.com/p/volatility/) and I have some problems with the packaging: setuptools installs everything as ./lib/python.../site-packages/ but Python in Ubuntu does not have site-packages in their PYTHONPATH. Does anybody know how to make setuptools install stuff in dist-packages?
[10:13] <anzenketh> persia: looks like i need to do it the hardware upstream does not have a build system.
[10:14] <persia> Do you know where things belong?
[10:14] <anzenketh> I can tell from the RPM .spec file
[10:15] <persia> Ugh.  Then you have to do the same hack in packaging.
[10:15] <persia> man dh_install, and put stuff in debian/amahi.install
[10:16] <anzenketh> does the amahi.install allow commands like install -m 755 -p file   directory
[10:17] <persia> anzenketh: No.  It allows commands like "bin usr/bin" which then expands into the right set of install -m ... calls.
[10:18] <persia> So it's much more concise: it's just sources and destinations, and doesn't bother the user with the actual implementation details.
[10:18] <anzenketh> ok good that means most of it was done right previously
[10:19] <anzenketh> how does the amahi.install know what permitions to give file?
[10:20] <persia> It uses the permissions from the source.  Later dh_fixperms goes though and tries to clean up.
[10:20] <anzenketh> ahh ok time for me to learn the CDBS
[10:20] <persia> Why?
[10:20]  * persia currently recommends against CDBS for new packaging : rules.tiny achieves the same goals, and is easier to debug
[10:21] <anzenketh> ok
[10:22] <anzenketh> so how would I compile a c file
[10:22] <anzenketh> it has one c file it needs to compile
[10:22] <persia> And that compilation happens in the .spec file?
[10:23] <anzenketh> yes in %prep it has a %setup -q and a make hdactl-hup
[10:24] <persia> Ugh.
[10:24] <persia> Well, you can do that by adding an override_dh_auto_build: rule to debian/rules
[10:25] <persia> But the *better* way to do it is to make an upstream Makefile that does the right thing.
[10:25] <persia> And then to share that for both types of packaging.
[10:25] <persia> That way if it needs to be adjusted, it only needs to be adjusted in one place.
[10:26] <anzenketh> I agree
[10:26] <anzenketh> now I need to think of a way to define upstream build system.
[10:26] <persia> vi Makefile ?
[10:27] <filip> can I debuild an i386 package on an amd64 system?
[10:27] <kklimonda> yes
[10:27] <persia> Um, no.
[10:27] <filip> ;)
[10:27] <persia> One can use sbuild or pbuilder to generate i386 packages on an amd64 system.
[10:27] <filip> you got me confused a bit :P
[10:27] <persia> One cannot use debuild alone
[10:28] <anzenketh> persia:  so a build something is something like a standard config and makefile
[10:28] <persia> anzenketh: Sure.  Or setup.py or build.xml, or ...
[10:34] <anzenketh> ugh upstream author refuses to make a build system.
[10:37] <anzenketh> Ehh oh well
[10:38] <persia> Then you get to duplicate code :(
[10:39] <anzenketh> Yep
[10:40] <anzenketh> He states it is 20 times more work and it never updates
[10:40] <anzenketh> Which may be true it is a old fedora package
[10:43] <persia> It's precisely the same amount of work, and half as much as duplication, *but* it's a bunch of work to migrate from package hacks to a real Makefile.
[10:43] <persia> So for now, just work around it.
[10:43] <persia> If enough people like amahi on Ubuntu, you will have leverage to share code between .spec and debian/rules in ./Makefile
[10:45] <anzenketh> Well it was already semiported I am just updating the port. And as it is there is duplicates of the same file.
[10:45] <anzenketh> Due to some require specific code in fedora and some specific in ubuntu.
[10:45] <persia> There's no good reason for that.  The code should be able to use lsb_release to figure out which distribution it's using, and do the right thing.
[10:46] <anzenketh> I would agree
[10:47] <persia> Then make your version do that, and submit patches upstream :)
[10:47] <muelli> oh, okay. my bad: setuptools installs correctly in ./dist-packages/ for python2.6 but cdbs
[10:47] <persia> Less maintenance overhead in the future.
[10:47] <muelli> ' install stage moves it to site-packages... ?
[10:50] <persia> muelli: Is this a new package, or are you trying to fix a bug?
[10:50] <muelli> persia: a new package. "Volatility" from http://code.google.com/p/volatility/. I'm not used to package stuff at all btw...
[10:51] <persia> muelli: OK.  So my recommendation is: if CDBS doesn't do what you want, use rules.tiny instead.
[10:52] <muelli> persia: hm. a quick google for that resulted in bug reports only. Do you have some more information or pointers to more information about that?
[10:53] <persia> muelli: cp /usr/share/doc/debhelper/rules.tiny debian/rules and `man dh`.  Ask in #ubuntu-packaging if you get stuck.
[10:53] <muelli> persia: thx. will have a look
[11:00] <muelli> heh. funky rules file -.- And the best thing: It (nearly) does what I want! holy cow!
[11:00] <persia> muelli: Are you using python-support?  There should be a built-in dh_pysupport call if you are.
[11:00] <shadeslayer> so... is there someone here who can update me with the latest 3.0 format?
[11:01] <shadeslayer> like point me to a doc..
[11:02] <muelli> persia: Sorry. I don't know whether I'm using "python-support". I started from scratch calling setup.py myself from the debian/rules, but I thought it was wrong. So I tried cdbs which messed installation up and now I'm using your rules.tiny.
[11:02] <persia> muelli: Add python-support to Build-Depends: in debian/control
[11:05] <muelli> persia: k. right now I put debhelper, cdbs, python-setuptools and python-central. But I will get rid of cdbs and python-central in favour of python-support, I guess.
[11:05] <muelli> persia: btw: shall we move this to #ubuntu-packaging? :)
=== lionel_ is now known as lionel
[11:06] <persia> Even odds.  If you're planning to push this package into the main repos for lucid+1, it's equally on-topic in either place.
[11:07] <muelli> persia: k :)
[11:08] <muelli> oh, and I wouldn't mind pushing that but for now I only want to distribute that program easily using the great PPA system :) But I'm willing to do the right^tm steps so that the package is ready for inclusion. And would keep spending my time caring about it.
[11:12] <persia> For PPA stuff, #ubuntu-packaging is more on-topic : this channel is about working on Ubuntu directly
[11:22] <Anzenketh> persia: Thanks for your help I think i convinced him to change to cmake in the future for a packaging system.
[11:23] <Anzenketh> but right now he wants to do it this way
[11:23] <persia> Anzenketh: That's fine.  In my experience the best way to get someone to change their code is to patch it to do it the way you want, and still work the way they want, and share the patch.
[11:24] <Anzenketh> that is basicly what I will be doing is creating the patch to merge over to cmake and do it the way he wants for now.
[11:24] <Anzenketh> that requires me learning cmake
[11:24] <persia> I think make is easier, and powerful enough for what you're doing, but cmake could work.
[11:25] <Anzenketh> well his comment when i said cmake was that will help with a windows port
[11:25] <Anzenketh> I just rolled my eyes
[11:26] <persia> it's true.  cmake probably has better Windows support than make.
[11:26] <Anzenketh> I noticed somewhere if it is installing to a standard directory I only have to specify the file correct?
[11:26] <Anzenketh> or do I have to specify the path in the package.installer file
[11:27] <persia> I recommend using a variable to define the path, so that the various packaging systems can overrride the variable to whatever they need.
[11:28] <Anzenketh> I like that idea
[11:28] <Anzenketh> also reduces mistakes
[11:28]  * Anzenketh is looking for a example of that
[11:31] <Anzenketh> persia:  do you know of a good source I can look at to learn from on doing this
[11:31] <persia> I know nearly nothing about cmake.  Sorry.
[11:32] <Anzenketh> no not cmake the amahi.installer file
[11:33] <muelli> persia: which patch system do you suggest? I used cdbs' simple-patchsys so far but it doesn't work know anymore after I included simple-patchsys: the clean target is messed up.
[11:35] <persia> muelli: I've been using quilt lately, but I'm increasingly tempted by using Format: 3.0 (quilt) and not having a patch system at all (while still using quilt for local patch management).
[11:37] <muelli> persia: can I easily make quilt work with rules.tiny?
[11:37] <persia> Yeah.
[11:37] <persia> Two ways: 1) use Format: 3.0 (quilt), 2) replace "dh $@" with "dh --with quilt $@".  Pick one.  Don't use both.
[11:41] <Anzenketh> how do I make debuilder stop at creating the build directories in the temp files?
[11:46] <persia> Anzenketh: Why do you want it to stop?
[11:47] <Anzenketh> So I can verify the build directories are created correctly
=== shadeslayer is now known as Guest87270
[11:50] <persia> Anzenketh: Just check the build log.
[11:50] <Anzenketh> That is right that is there.
[11:52] <Anzenketh> persia: How do you compile one file that is in c in the rules file.
[11:56] <persia> Anzenketh: Add an override_dh_auto_build: rule to debian/rules.  Add the compilation instructions from the spec file in that rule.
[11:58] <Anzenketh> so something like this
[11:58] <Anzenketh> override_dh_auto_build:
[11:58] <Anzenketh> make hdactl-hup
=== Guest87270 is now known as shadeslayer
[11:59] <Anzenketh> make hdactl-hup is all that was in there before.
[11:59] <Anzenketh> well in the .specs file
[12:02] <persia> Well, try that, and see if it works.
[12:02] <persia> If it doesn't work, then you may have to track down something else fom the .spec file.
[12:02] <Anzenketh> ok
[12:03] <Anzenketh> Thanks a lot for your help persia I am sure what I learn to this I will contribute 10 fold to some other ubuntu package
[12:03] <Anzenketh> And I am learning A ton
[12:16] <Anzenketh> persia: can you do variables in a package.install and if so how to do disclare them.
[12:16] <persia> You can't.
[12:17] <persia> But since you know the location of the source, and you know the destination, you shouldn't need it.
[12:18] <Anzenketh> ok
[12:18] <Anzenketh> I was just wondering to reduce typos
[12:18] <Anzenketh> not that there will be many it is actualy a small package
[12:20]  * abogani waves Anyone could review my merge proposal https://code.launchpad.net/~abogani/ubuntu/lucid/avrdude/avrdude.fix-529444/+merge/21640 Thanks!
[12:20] <Anzenketh> if i call dh_installinit and dh_installcron I should not have to install them in the package.install right?
[12:21] <persia> Anzenketh: dh $@ will call them automatically.
[12:21] <persia> but read the individual dh_* manpages to be sure of behaviour
[12:21] <Anzenketh> ok cool
[12:23] <Anzenketh> it states note Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command. Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts. but dh $@ should take care of that right?
[12:23] <Anzenketh> that is for dh_installinit
[12:25] <persia> dh $@ should take care of that.  You can always check what it will do with `dh --no-act ${COMMAND}`
=== shadeslayer is now known as shadeslayer_
[12:41] <Anzenketh> persia: when I run that command I get dh: specify a sequence to run or dh: Unknown sequence dh_installcron (choose from: binary binary-arch binary-indep build clean install)
[12:44] <persia> Right.  You need to use one of binary, binary-arch, binary-indep, build, clean, or install for ${COMMAND}
[12:45] <Anzenketh> oh ok
[12:47] <Anzenketh>  it goes dh_installinfo -a    dh_installinit -a    dh_installmenu -a
[12:48] <Anzenketh> but it is only called once
[12:48] <Anzenketh> and I have 2 init files
[12:48] <muelli> How can I make debuild produce an architecture independent .deb? It's pure python after all.. debin/control has Architecture: any set.
[12:49] <lifeless> set it to all
[12:49] <lifeless> have a look at the packaging guides for the meaning of Architecture - or debian policy, the primary reference for packaging
[13:03] <Anzenketh> persia: I need to so things post install what is the best way to do that?
[13:05] <persia> Anzenketh: What sort of thing do you need to do?
[13:06] <persia> Also, if you ask questions generally, someone else may answer faster :)
[13:08] <Anzenketh> Sorry Looks like the .spec has a post install that changes permitions of files and directories in addition to running a scruot
[13:08] <Anzenketh> script
[13:09] <Anzenketh> So basicly post install I need to run a shell script
[13:10] <persia> OK.  Permissions changes can be added with something like http://paste.ubuntu.com/398306/ in debian/rules
[13:10] <persia> What does the script do?
[13:14] <Anzenketh> Looks like it changes permitions and ownership of files. Then goes though and moves some files for post configuration. Then restarts some services.
[13:15] <Anzenketh> http://pastebin.ubuntu.com/398308/ that is the script
[13:15] <persia> OK.  Permissions/ownership you do with stuff like my paste.
[13:16] <persia> You *cannot* do the stuff that changes the samba configuration.
[13:16] <persia> (you'll have to work with samba differently)
[13:16] <persia> Same for openvpn
[13:17] <persia> and httpd
[13:17] <Anzenketh> Is there a way to tell the installer to run a shall script post install?
[13:17] <persia> and the apache user
[13:17] <persia> Yes, but first I'm going to tell you the bits that need adjustment :)
[13:18] <Anzenketh> Ya I know some permitions are off
[13:18] <persia> the %preun stuff and the hdactl.cache changes can be done in maintainer scripts.
[13:18] <persia> Not permissions.  You can't mess with other packages.
[13:18] <persia> http://women.debian.org/wiki/English/MaintainerScripts is the best document for maintainer scripts I know.
[13:18] <persia> I believe dh_installinit will do the service restart.
[13:18] <persia> The cache stuff may need manual additions.
[13:20] <Anzenketh> ok so for permitions change I can use the pastbin for the cache stuff I can do maintainer scripts
[13:21] <Anzenketh> Just to clarify There is no wat to change config files of other packages
[13:22] <persia> It is in direct contravention of policy.
[13:22] <persia> Many packages provide a programmatic way to adjust configuration under certain circumstances.
[13:22] <persia> I believe both apache and samba fall into this category.
[13:22] <persia> Read the documentation for those packages: you may be able to do something useful.
[13:37] <Anzenketh> So once I find that programic way how would I have the debian install run those commands.
[13:40] <persia> In the maintainer scripts.
[13:40] <Anzenketh> ok
[13:41] <persia> Note that if the packages you need to adjust *don't* already include such a thing, you'll need to work with those packages to enable such a tool.
[13:42] <Anzenketh> And I can not run commands like sed correct?
[13:53] <persia> http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
[14:27]  * abogani waves
[14:27] <abogani> Anyone could review my merge proposal https://code.launchpad.net/~abogani/ubuntu/lucid/avrdude/avrdude.fix-529444/+merge/21640
[14:27] <abogani> Thanks!
[14:34] <nigelb> anyone noticed trouble with submittodebian?
[14:35] <nigelb> I said that patch has been submitted, but I dont see anything in the bug report
[15:25] <lfaraone> I was wondering if anybody had the time to review the merge proposal attached to bug 540934?
[15:25] <ubottu> Launchpad bug 540934 in lshell "The default configuration lets a user run every system command" [High,Triaged] https://launchpad.net/bugs/540934
[15:28] <DktrKranz> persia: I prepared a preliminary UDD query to display mismatches between sha1sums from Debian and Ubuntu, output is http://merkel.debian.org/~dktrkranz/unmatch_sha1sums
[15:32] <persia> DktrKranz: Thanks.  That's not bad at all.  I'll take a look through them, and see if I can't identify some candidates to get back in sync for lucid+1
[15:33] <DktrKranz> persia: I'll adjust a bit more to be in a better display format and then ask lucas if it can be pushed as UDD cgi
[15:35] <persia> DktrKranz: Don't worry about it.  I think I can hit about 50% of it one-off, and the rest is probably relatively unfixable without deep social engineering.
[15:35] <persia> I actively recognise most of these packages as being special in one way or another.
[15:36] <persia> I may ask you for an update near DIF of lucid+1, but won't need it again until then.
[15:36] <DktrKranz> ok
[15:36] <persia> Adding it to UDD cgi just raises attention to it, and in many cases, we don't want that.
[15:37] <DktrKranz> script is on merkel. so I can run anytime
[15:37] <persia> (because the reason for the variation may reflect badly on Ubuntu<->Debian relationships)
[15:37] <persia> Perfect.  Thanks.
[15:37] <DktrKranz> if you want, I can adapt it to be run on a machine not restricted to DDs
[15:37] <DktrKranz> (alioth, that is)
[15:38] <persia> I certainly don't need that.  If there's another user who wants it, or if you have an interest in doing so yourself... :)
[15:39] <DktrKranz> Not that much, as I use merkel for UDD hacking ;()
[15:40] <persia> Well then :)
[15:40] <persia> But thanks again: as a one-time run, this is hugely useful to me.
[15:41] <nigelb> is submittodebian broken?
[15:42] <lfaraone> nigelb: please elaborate.
[15:42] <nigelb> I followed the instructions but nothing updated on bug
[15:42] <nigelb> and it seems to be diff-ing only the changelog and not the changes made to package
[15:43] <lfaraone> nigelb: it won't modify your bug, it'll submit a new bug to debian.
[15:44] <nigelb> thats strange because it searched debian bugs and asked me which bug this patch corrected
[15:44] <nigelb> I'm not talking about reportbug
[15:44]  * lfaraone will brb, no idea about your problem, it worked for me :)
[15:45]  * nigelb will try again
[15:49] <abogani> Anyone could review my merge proposal https://code.launchpad.net/~abogani/ubuntu/lucid/avrdude/avrdude.fix-529444/+merge/21640 ? Thanks!
[16:22] <nigelb> aha, my submittodebian troubles spring from sendmail I think
=== korn_ is now known as c_korn
[16:26] <nigelb> which I have no clue to fix
=== shadeslayer is now known as Guest56644
=== shadesla1er is now known as shadeslayer
[18:00] <ryanakca> Could someone please take a look at bug 538283 ?
[18:00] <ubottu> Launchpad bug 538283 in turnin-ng "Please merge turnin-ng 1.0.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/538283
[18:12] <crimsun> ryanakca: Uploaded; thanks for your contribution to Ubuntu Lucid!
[18:12] <ryanakca> crimsun: thanks
=== shadeslayer is now known as shadeslayer_
[20:24] <duanedesign> if or current version is 0.32.4-12ubuntu1  and the new upstream is 0.34.1-1 that would make our new package 0.34.1-1ubuntu2 ?
[20:24] <duanedesign> s/or/our
=== james_w` is now known as james_w
[20:41] <geser> duanedesign: almost, 0.34.1-1ubuntu1 as it's the 1st change to 0.34.1-1 (but contains all the unmerged colltected Ubuntu deltas)
[20:51] <duanedesign> geser: thank you. I had a feeling I was thinking about that wrong :)
=== Anzenketh is now known as anzenketh|brb