[00:51] <binarymutant> if someone has the time, http://revu.ubuntuwire.com/p/pidgin-mbpurple , needs advocation. I'm trying to beat the Freeze :)
[01:12] <h6w> The Debian new maintainers guide appears to assume that we're using Make for the compile process.  Are there any docs for other compiling script languages (e.g. ant)?
[02:25] <slayton> maxb thanks again for your help yesterday... in the end I figured that because i only needed the libhdf5-serial and none of the other packages built by default anyway I could just package up hdf5-serial-1.8.3 using cdbs and forgetting about what was done for 1.6.6
[02:44]  * ScottK relaxes when he notices the  mono discussion ended several hours ago.
[02:49] <ajmitch> ScottK: I only wish that were true
[02:49] <ScottK> ajmitch: I'm limiting my relaxation of this channel.
[02:50]  * ScottK finished dredging through email about an hour ago and currently isn't looking.
[02:50] <ajmitch> unsubscribe looks awfully tempting for u-d-d
[02:50] <ScottK> You wouldn't be the first.
[02:50] <ajmitch> I know, that's the worrying part
[03:38] <TheMuso> Unsubscribing from u-d-d is something I'm considering as well.
[03:39] <TheMuso> In fact, I feel its become more a windgepool than anything constructive. However, it could only be a handfull of people who do windge.
[03:41] <persia> The main issue with unsubscribing is that there ought be some useful forum for some of the discussions, just not others.
[03:42] <TheMuso> persia: Yes, thats exactly the dilemma.
[03:43] <persia> Personally, I blame the demise of usenet.  mailreaders all suck for this sort of fora.
[03:43] <persia> (and no, it's not worth setting up a mail2news gateway: the issue is as much that *everyone else* uses mailreaders as that I do)
[03:45] <ScottK> Personally, I'm treating it as a personal growth opportunity.
[03:46] <ScottK> Excercising the restraint to not reply is a useful exercise.
[03:46] <ajmitch> I never find that a problem
[03:47] <ScottK> Holding my tongue in the face of idiocy has never been one of my strengths.  Even in cases where intellectually it was clearly the better move.
[04:07] <rawang> Hi, why I can manage to build my package by pbuilder, but failed at my PPA build?
[04:10] <Hobbsee> because the stars didn't align.  YOu'll need to give us more information than that.
[04:10] <Hobbsee> like, a pastebin of what the last ~20 lines of the ppa build log is
[04:10] <Hobbsee> (or the build log itself)
[04:11] <Hobbsee> one common reason would be because your build requires internet access during build
[04:13] <rawang> Hobbsee, http://launchpadlibrarian.net/27717912/buildlog_ubuntu-karmic-i386.mono-uiautomationwinforms_1.0-1ubuntu3_FAILEDTOBUILD.txt.gz
[04:14] <rawang> Hobbsee, it fails at the it requires gtk-sharp2, and this is the one i haven't add it in Build-Depends tag.
[04:14] <rawang> Hobbsee, but the problem is when i use pbuilder to build it, it succeed, it's so weird,
[04:15] <rawang> Hobbsee, i think pbuilder should fail to build it, because I'm not fulfill the dependency :(
[04:18] <Hobbsee> that's kinda weird
[04:18] <Hobbsee> maybe add teh build dependancy anyway
[04:18] <Hobbsee> (you've not used --save-after-login at all on the pbuilde, have you?)
[04:20] <StevenK> rawang: Can you pastebin the pbuilder log?
[04:20] <StevenK> rawang: Perhaps your pbuilder base tarball has mono in it ...
[04:21] <rawang> sure, i will paste pbuilder log
[04:21] <rawang> btw where is the pbuilder log? :)
[04:21] <StevenK> You need to use 'tee' or pass a --logfile option, I think
[04:22]  * StevenK uses sbuild, not pbuilder
[04:23] <rawang> ok, thank you guys :)
[04:23] <nellery> it's --logfile
[04:24] <rawang> sure
[04:36] <TheMuso> StevenK: I thought at one time you were going to stick to pbuilder...
[04:37] <StevenK> I've been using sbuild for about 4 releases now
[04:37] <TheMuso> ah ok
[04:37] <StevenK> Hm. Maybe only three
[04:39] <persia> StevenK, hardy, jaunty, intrepid, karmic: four
[04:39] <StevenK> persia: And how are you keeping better track of my use of sbuild than I am?
[04:40] <persia> StevenK, Because I spent a long time arguing with you about it, and remember the day I didn't have to do so anymore.  Instead, I had the evening free to cook.
[04:40] <StevenK> Hmmm. I don't recall that argument.
[04:40] <StevenK> Probably because I lost
[04:41] <persia> Best thing not to remember :)
[04:41] <bddebian> eh
[04:41] <bddebian> Err heh
[04:44] <StevenK> bddebian: When did you start hiding here again?
[04:45] <persia> I don't remember bddebian ever leaving here, just not saying anything much for the past long time (since deciding to go fix stuff in Debian QA).
[04:45] <StevenK> Ahhh
[04:46] <ajmitch> he's always lurking in the shadows
[04:46] <StevenK> Now that's a scary thought
[04:46] <ajmitch> trying to convince us of the One True OS, Debian GNU/Hurd
[04:46] <bddebian> Heh
[04:46] <StevenK> Ha!
[04:46] <bddebian> Exactly!
[04:46] <persia> bddebian, Does Hurd work now?  Is there an Ubuntu port?
[04:46] <ajmitch> bddebian: btw, I saw phil charles last night :)
[04:46] <bddebian> ajmitch: Really?
[04:47] <bddebian> persia: It's always worked.. ;-)  No, no Ubuntu port :(
[04:47] <ajmitch> bddebian: yeah, I showed up at a LUG meeting for a change
[04:47] <ajmitch> where LUG meeting = sit in pub & drink beer
[04:47] <bddebian> heh
[04:47] <StevenK> Good. Ubuntu doesn't need a Hurd port
[04:47] <StevenK> ajmitch: Sounds like SLUG to me
[04:47] <ajmitch> it's a good thing
[04:48] <ajmitch> especially when the pub in question has a lot of different beers on tap
[04:48] <StevenK> Hmm.
[04:49] <StevenK> Given a list of PIDs, tell me what the process name is
[04:49]  * StevenK hacks a shell one liner
[04:51] <bddebian> yuck yuck
[04:53]  * ScottK thought that was going to be be, "Given a list of PIDs, tell me what the appropriate beer to go with them is?"
[04:54] <StevenK> ScottK: A cold one
[05:55] <ausimage> wgrant?
[05:56] <ausimage> wgrant: ahh!
[05:56]  * ausimage attempts to shift his launchpad conv to motu
[05:57] <wgrant> ausimage: Perhaps somebody else here can help - I've really got to study.
[05:57] <ausimage> k
[05:58]  * RoAkSoAx is sick of studying
[05:59] <ausimage> I am wondering if anyone can look over https://code.edge.launchpad.net/~ausimage/soovee/trunk...
[05:59] <ausimage> My packaging skills seem to just kill revu :/
[06:00] <ausimage> It is a serial audio feed manager that is coded in python
[06:00]  * ausimage not sure if he will get a response this way... but has little choice ATM
[06:01]  * ausimage needs rest but is accepting PMs and email comments to help him further getting soovee into karmic
[06:07] <persia> ausimage, How is it killing REVU?
[06:09] <ausimage> persia: um... http://revu.ubuntuwire.com/p/soovee
[06:10] <wgrant> ausimage: Use dch to edit your changelog in future.
[06:10] <ausimage> k
[06:10] <wgrant> It has lots of trailing whitespace and extra blank lines.
[06:10] <ausimage> I can do that...
[06:11] <wgrant> In ppa4's changelog, delete line 6, and trim the trailing whitespace from 5, 8, 15.
[06:11] <wgrant> Then REVU might work.
[06:11] <StevenK> Line 8 and 15 take into account that line 6 no longer exists? :-)
[06:11] <persia> Anyway, quick review: 1) debian/changelog appears to be an upstream changelog, Conflicts: is useless in a source stanza, Pre-Depends is probably unnecessary, installing symlinks with setup.py is likely to cause errors.
[06:12] <wgrant> StevenK: Eh, no.
[06:12] <StevenK> ausimage: debian/changelog is required to be a certain format -- tools like REVU and dpkg-buildpackage depend on it
[06:13] <StevenK> What does it Pre-Depend on?
[06:14] <ausimage> I used depend before and it complained that the package was not installed
[06:14] <wgrant> Also, as I mentioned in #launchpad, it shouldn't be native.
[06:14] <ausimage> when I switched it pre-depend it did not complain
[06:14] <wgrant> What complained?
[06:15] <persia> ausimage, that's the wrong hammer for that screw.  What complained?
[06:15] <ausimage> synaptic
[06:15] <wgrant> At what point did it complain?
[06:16] <ausimage> When I attempted to choose to install the soovee-all
[06:16] <ausimage> I think that was the point... it said something to the fact that package a needs to be installed but is not...
[06:16] <wgrant> Try moving the Pre-Depends packages into Depends instead. It should work just as well.
[06:16] <ausimage> and the depends for it were in the package
[06:16] <wgrant> If it doesn't work, Pre-Depends is certainly not the solution.
[06:17] <persia> ausimage, There is no "souvell-all" package in your debian/control.  From where did you get that?
[06:17] <ausimage> i meant soovee :/
[06:18] <ausimage> soovee is like a meta-package that pulls in the rest....
[06:18] <ausimage> but is not necessary perse...
[06:19] <persia> That should probably only depend on souvee-gui and souvee-cli, with the rest pulled recursively.
[06:19] <ausimage> as soovee-cli and soovee-gui can be installed seperately
[06:19] <ausimage> I thought about that.... but was not sure
[06:20] <persia> Also, ${python:Depends} is *useless* for a non-python package (like your metapackage).
[06:21] <ausimage> yeah I see that...
[06:28] <LordKow> what debian/rules target occurs before configure? i need to do some source work prior to patching and configuring
[06:28] <StevenK> Using CDBS?
[06:28] <LordKow> nope
[06:28] <StevenK> Since the first target called by dpkg-buildpackage is 'build'
[06:31] <LordKow> the problem is trying to get work done before patching. i can simply dh_override the configure part but that would be after patching
[06:33] <ausimage> I just pushed your suggestions into my soovee package and up to revu I hope :S
[06:34] <ausimage> http://revu.ubuntuwire.com/details.py?upid=5990
[06:35] <ausimage> Yeah! danke merce gracias thanks :)
[06:35] <persia> LordKow, So, debian/rules is a makefile.  The first target called is 'build'.  Construct your rules file such that you do what you need before you do the other stuff that you need.
[06:35] <fabrice_sp__> ausimage, you should take care of the 2 errors that appear at the top of the revu page
[06:35] <fabrice_sp__> (watch file and close bug report in your changelog)
[06:35] <LordKow> ah okay
[06:37] <ausimage> fabrice_sp: not sure i know of a bug for it... just a personal itch of mine... and I will add the upstream watch once I learn how to do it correctly
[06:37] <persia> ausimage, Conflicts is still useless in the source stanza
[06:38] <fabrice_sp> ausimage, create a packaging request bug, then
[06:38] <ausimage> persia: how do you force removal of a prior package
[06:38] <ausimage> fabrice_sp: that I will then
[06:39] <ausimage> fabrice_sp: can the original source be a package or repository ?
[06:40] <ausimage> though I still need the exact tag to put in :/
[06:41] <iulian> If it's a new package, just file the bug against Ubuntu.  The tag should be 'needs-packaging'.
[06:41] <ausimage> gah... it is EDT here :/
[06:41] <ausimage> iulian: I can do that ;) but tomorrow
[06:43] <persia> ausimage, The point is that a *source* package can't conflict with anything in any meaningful way.  If you need a binary package to conflict, you can do that, but you need a filename or port conflict.
[06:43] <persia> ausimage, The general guideline is that one *doesn't* force removal of anything.
[06:43] <ausimage> hmmm how does one deal with file shuffles 'tween packages?
[06:44] <ausimage> so files are only were there are supposed to be in the current package?
[06:45] <ausimage> the conflicts that is there is due to a package name change I did... so the old package is removed prior to installing the new
[06:47]  * ausimage is only attempting to find the most obvious tool in sight to handle that situation...
[06:47] <ausimage> :S
[06:48] <StevenK> The problem is sometimes the most obvious tool is a fairly big hammer, which is the wrong thing to use
[06:49] <wgrant> In this case, the appropriate screwdriver is probably not needed here.
[06:49] <wgrant> Because the Conflicts field has been happily sitting in the wrong paragraph, doing nothing. So it probably wasn't needed in the first place.
[06:49] <ausimage> I guess I can drop it from the next revision
[06:49] <wgrant> Particularly since the package against which you Conflict doesn't seem to be in Ubuntu.
[06:50] <ausimage> ah true there...
[06:50] <ausimage> it was in my ppa though
[06:51] <ausimage> but I will drop the conflicts when I next package
[07:18] <\sh> moins
[07:24] <didrocks> good morning
[07:28] <dholbach> good morning
[07:37] <\sh> hey dholbach
[07:39] <dholbach> hiya \sh
[07:39] <geser> good morning
[07:39] <dholbach> how are you guys doing?
[07:40] <dholbach> so who feels like doing some sponsoring today? :)
[07:40] <dholbach> hiya Bambi03 - the beer was excellent! thanks again!
[07:41] <dholbach> hola DktrKranz!
[07:41] <DktrKranz> good morning dholbach!
[07:42] <Bambi03> Hi Daniel, glad you liked it :)
[07:42] <\sh> working on FAI, back working on Leonov planning, going to have a heavy datacenter move from next week on...and thinking about chaging ubuntu-devel-discussion ML into a ubuntu-devel-discussion forum on ubuntuusers.org and wishing for having decent discussions about technical issues back on ubuntu-devel ML...
[07:43] <\sh> so doing quite fine ;)
[07:44] <\sh> oh wow..."update on ubuntuone-client...changes: Failed to detect distribution" looks like we need some fixes for update-manager and PPAs
[07:54] <wgrant> \sh: update-manager's changelog support relies on changelogs.ubuntu.com, which doesn't do PPAs.
[08:10] <\sh> wgrant: yes...but we could have some infrastructure to support changelogs from PPAs too
[09:52] <gaspa> slytherin: hi, do you have a minute or two? :P
[09:53] <slytherin> gaspa: sure
[09:53] <gaspa> slytherin: about that: https://lists.ubuntu.com/archives/ubuntu-motu/2009-June/005811.html
[09:53] <slytherin> gaspa: I was reading your mail. You seem to have telepathy powers. :-D
[09:53] <gaspa> slytherin: yes, i'm training ;)
[09:54] <gaspa> I think the problem is that one: https://bugs.edge.launchpad.net/ubuntu/+source/w3c-dtd-xhtml/+bug/183164
[09:54] <slytherin> gaspa: I was going to reply to that mail. Is that fine?
[09:54] <gaspa> sure.
[09:54] <gaspa> thanks.
[09:59] <slytherin> gaspa: some work has come up. I am in office. I will surely reply to the mail today.
[10:00] <gaspa> slytherin: np, ikiwiki has been a merge since long time, it could wait after all... :P
[10:14] <slytherin> calc: Is there any plan to move lucene2 to main adn use it as build depends for openoffice.org?
[10:34] <AnAnt> Hello, I need to discuss the dependencies of velocity, why does velocity depend on ant ?
[10:37] <AnAnt> the dependancy of velocity on ant makes it also pull in the default-jdk package (since default-jdk is Recommended by ant)
[10:38] <AnAnt> although velocity (as far as I know) is just a bunch of classes that can be used by other java software
[10:38] <AnAnt> hmmm, nevermind, I'll take this to -java channel
[11:18] <\sh> siretart`: ping
[11:18] <siretart`> \sh: yes?
[11:19] <\sh> siretart`: I just ran into a problem during ubuntu installation via fai...udev and a missing udevadm which makes mkinitramfs unusable...
[11:20] <\sh> siretart`: regarding the installation log, udev diverts udevadm with udevadm.upgrade and removes it later ... but strange, after that udevadm doesn't exists anymore on the installed system
[11:20] <siretart`> if you ask Keybuk, udev is required on every ubuntu system (probably not in chroots, though)
[11:20] <\sh> siretart`: sure...without it, I can't reconfigure a kernel ;)
[11:20] <\sh> siretart`: but I wonder why it's being deleted instead
[11:20] <\sh> of being still there
[11:21] <siretart`> hm. are both udev and mdadm referenced from your packages selection?
[11:21] <\sh> siretart`: udev package is installed...everything is there but not /sbin/udevadm
[11:22] <\sh> I wonder if it has something to do you did during fai in ubuntu in version 2.10.1ubuntu1:  make-fai-nfs-root: patch $NFSROOT/etc/init.d/udev to call start-stop-daemon.distrib instead of start-stop-daemon, because the latter
[11:22] <siretart`> "because the later..." ?
[11:22] <siretart`> (your line is cut)
[11:22] <\sh>  is disabled in the nfsroot
[11:23] <siretart`> ah right, thomas disables s-s-d, as he doesn't want any daemons started in the nfsroot
[11:23] <siretart`> this on the other hand broke "something" in ubuntu, but I don't really remember what
[11:23] <\sh> ok...that it has nothing to do with the installation actually
[11:23] <siretart`> might be worth to try reverting this change to find out what it was
[11:23] <\sh> because udevadm is missing from the /target/* tree
[11:24] <siretart`> more or less it does.
[11:24] <siretart`> is mdadm referenced from your packages selection?
[11:24] <\sh> siretart`: mdadm yes.it's installed
[11:25] <\sh> argl
[11:25] <siretart`> so the package is installed, but the binary /target/sbin/mdadm is missing?
[11:25] <siretart`> are you sure here?
[11:25] <\sh> stop...
[11:25] <\sh> not mdadm...udevadm ;)
[11:25] <siretart`> aaaah
[11:26] <siretart`> so we are not talking about mdadm here at all, right?
[11:26] <\sh> siretart`: nope...it's more important udev we are talking about :)
[11:27] <siretart`> okay, so the package udev and the binary /target/sbin/udevd are installed, but the /target/sbin/udevadm binary is missing?
[11:27] <siretart`> is that your diagnosis?
[11:27] <\sh> yepp
[11:27] <siretart`> that's really strange
[11:27] <siretart`> can you check if there is some diversion on that file in the chroot?
[11:27] <\sh> and I think it has something to do with udev.preinst: disable_udevadm() function #Disable udevadm from being run during an upgrade
[11:28] <\sh> yes..udev.preinst diverts /sbin/udevadm to /sbin/udevadm.upgrade and removes this divert again after upgrade
[11:28] <siretart`> okay, so that part seems intended
[11:28] <siretart`> when exactly is "after upgrade" supposed to be?
[11:28] <\sh> but I don't see any "rm -f /sbin/udevadm"
[11:29] <siretart`> I suppose dpkg-divert does this on its own
[11:29] <\sh> siretart`: http://paste.ubuntu.com/192432/ <- this is the snippet of fai.log
[11:31] <siretart`> okay, I see
[11:32] <siretart`> err, look in udev.postinst. The function enable_udevadm() does exactly that: rm -f /sbin/udevadm and then dpkg-divert  --local --rename --divert /sbin/udevadm.upgrade --remove /sbin/udevadm
[11:33] <\sh> hmmm.but that works during normall install
[11:33] <siretart`> since udevadm is missing and the fai.log shows the output of dpkg-divert, we can suppose that for some reason, dpkg-divert fails in a very subtle way here
[11:33] <siretart`> can you chroot into that chroot and list the local diversions?
[11:34] <\sh> will do a bit later...meeting right nwo
[11:34] <siretart`> and does /sbin/udevadm.upgrade still exist?
[11:34] <siretart`> k
[11:48] <AnAnt_> Hello, how is the archive reorganisation going to affect us (those who make packages for Ubuntu) ?
[11:52] <\sh> siretart`: totally gon
[11:52] <\sh> e
[11:53] <\sh> siretart`: and dpkg-divert --list doesn't show anything about udevadm
[11:55] <siretart`> so both /sbin/udevadm and /sbin/udevadm.upgrade are gone?
[11:55] <slytherin> AnAnt_: Do you have specific questions?
[11:55] <siretart`> sounds to me that you've either found a bug in dpkg-divert, or something else is stealing/removing /sbin/udevadm
[11:56] <AnAnt_> slytherin: yes, does that mean that when I make a package, what archive should I put it in ?
[11:56] <\sh> siretart`: yepp
[11:57] <AnAnt_> slytherin: there's no universe I understand
[11:58] <slytherin> AnAnt_: I don't think universe as a component is going away.
[11:59] <AnAnt_> I see
[12:01] <slytherin> AnAnt_: AnAnt___: Regarding your question about velocity, you should send mail to debian java mailing list.
[12:02] <AnAnt___> slytherin: I got a lousy connection here !
[12:03] <\sh> siretart`: I'll remove the dist-upgrade now...and try to interactive upgrade udev
[12:03] <siretart`> ok
[12:04] <AnAnt____> slytherin: thanks, I discussed that on -java btw
[12:05] <AnAnt____> slytherin: ok, another thing is that packages in main cannot depend on packages in universe, is that going to change ?
[12:06] <slytherin> AnAnt____: AFAIK, that will still be true.
[12:06] <AnAnt____> ok, thanks
[12:24] <slytherin> can anyone please tell me what this error is - dpkg-trigger: dpkg-trigger must be called from a maintainer script (or with a --by-package option) ?
[12:27] <cody-somerville> slytherin, When does it occur?
[12:28] <slytherin> cody-somerville: it is occuring on powerpc buildd while setting up texlive-base. I am trying to investigate FTBFS of tuxguitar.
[12:34] <\sh> siretart`: dpkg-reconfigure -a -f noninteractive kills my udevadm
[12:35] <\sh> siretart`: thinking that there is a divert which isn't there...when I chroot into $target without this calkl
[12:43] <\sh> siretart`: that is the problem...after dpkg-reconfigure -a ... No diversion `local diversion of /sbin/udevadm to /sbin/udevadm.upgrade', none removed
[12:43] <\sh> and then udevadm is gone
[12:52] <Ampelbein> hi. i have a question regarding build-retries. I have the package viking (https://edge.launchpad.net/ubuntu/+source/viking/0.9.8-2) FTBFS on sparc. This is because gpsd2.39 (https://edge.launchpad.net/ubuntu/+source/gpsd/2.39-1ubuntu1) is still not build on sparc. How do I request a build-retry? Do I just poke my sponsor to retry? Or file a question on Launchpad?
[12:53] <Ampelbein> Note: I want to retry when gpsd2.39 is built, of course.
[12:56] <Ampelbein> Thinking about it: Shouldn't the packaging of viking be changed to reflect the build-depends correctly? i.e. Build-Dep: libgpsd-dev (>= 2.39)
[12:58] <siretart`> \sh: so you blame udev?
[12:58] <Ampelbein> cjwatson: as you sponsored my upload of viking: should I create a -2ubuntu1 with the correct build-depends and submit the change to debian, too? or is it sufficient to just retry once gpsd is built?
[13:00] <\sh> siretart`: I blame no one :) I'm just wondering why dpkg-reconfigure triggers a reconfig of udev and then /sbin/udevadm is gone away, because there is no diversion anymore
[13:01] <\sh> siretart`: the postinst script I saw and this evil rm -f /sbin/udevadm is known...but the update of udev was successfull without any errors...so there should nothing to be reconfigured, and actually there is no diversion anymore...
[13:01] <siretart`> \sh: still dpkg-reconfigure should (if not *must*) be idempotent, at least when running non-interactively
[13:01] <\sh> siretart`: ok...then the error is "rm -f /sbin/udevadm" while not knowing that there is no diversion
[13:02] <siretart`> and of course not kill critical binaries from the system
[13:02] <\sh> siretart`: well at preinst stage they moved the orig file out of the way (divert) and replaced it with a shell script..and in postinst they think "remove that shellscript" without checking that there is nothing to do because the divert is not there anymore
[13:03] <siretart`> \sh: wophs. you're totally right. I'd call that a really critical bug in the udev package
[13:03] <\sh> i'll talk to cjwatson
[13:03] <siretart`> \sh: the postinst must check that there is a diversion in place at all before killing the binary
[13:04] <siretart`> \sh: or better: don't rm -f it, but move it out of the way, and restore the contents if dpkg-divert fails for any reason
[13:04] <\sh> siretart`: -> ubuntu-devel ;)
[13:12] <cjwatson> Ampelbein: I wouldn't bother, just retry once it's built
[13:13] <cjwatson> Ampelbein: gpsd doesn't need a retry on sparc - it's already queued for building
[13:14] <Ampelbein> cjwatson: yeah, but viking failed to build and needs to be retried once gpsd built.
[13:16] <cjwatson> Ampelbein: sure, I know
[13:16] <cjwatson> ah, I misread your question about requesting a build-retry
[13:16] <cjwatson> Ampelbein: yes, just ask me when it's ready
[13:32] <binarymutant> if someone could review and possibly advocate http://revu.ubuntuwire.com/p/pidgin-mbpurple , I will be forever grateful :)
[13:33] <Laney> binarymutant: doesn't libpurple suppport microblogging itself?
[13:34] <binarymutant> Laney, not that I'm aware of
[13:35] <Laney> well Adium does, so unless it doesn't use libpurple for that part
[13:39] <Laney> anyway I suggest you use the DEP5 copyright format if you want to get it into Debian (http://dep.debian.net/deps/dep5/)
[13:39] <Laney> I can't build/test now but that's really my only comment based on reading it
[13:39] <binarymutant> Laney, are you sure that you haven't installed a plugin? or did you compile from their trunk?
[13:40] <binarymutant> Laney, http://trac.adium.im/wiki/TwitterSupport
[13:40] <Laney> 1.4 beta 6
[13:41] <binarymutant> ah
[13:41] <Laney> it may not be using libpurple for that part
[13:44] <binarymutant> Laney, can you send and receive from your microblogging service?
[13:44] <Laney> binarymutant: yes
[13:45] <binarymutant> Laney, thanks for the help, I'll check out that link and look more in depth into libpurple to see if microblogging is supported
[13:46] <slytherin> binarymutant: Laney: That page doesn't say adium has microblogging support.
[13:47] <binarymutant> slytherin, it says it's a feature in their next release
[13:48] <slytherin> binarymutant: right, but doesn't specify how they are going to implement it.
[13:48] <Laney> slytherin: this was my question
[13:48] <binarymutant> I will look into their trunk for how they implement it
[13:49] <Laney> I'd just look at protocols/ (or whatever) in libpurple trunk
[13:49] <binarymutant> that too ^
[13:50] <binarymutant> urgh pidgin's vcs is down :(
[13:52] <Laney> you might get results just asking either project on irc
[13:52] <directhex> it's a Laney!
[13:53]  * Laney gets a piggyback from directhex 
[13:53] <Laney> I should have a chair today, so might be able to actually do some packaging stuffs
[13:53] <Laney> that would be an exciting development
[13:55] <directhex> :o chair!
[13:55] <Laney> floor computing is not good
[13:59] <directhex> laptop plus bed?
[14:00] <mterry> cjwatson: I'm surprised by your statement that Ubuntu tries to avoid adding patch systems (even simple-patchsys).  It seems like not that much of a delta to carry.  I like patch systems.  :)
[14:01] <cjwatson> mterry: it is nevertheless true, because not everyone likes patch systems
[14:01]  * mterry believes they just haven't met the right patch system yet
[14:01] <cjwatson> I, for instance, avoid them like the plague because they have the effect that you have to do additional work after 'dpkg-source -x' to see what's actually being applied. (But I won't force that decision on everyone.
[14:01] <cjwatson> )
[14:02] <cjwatson> I'm confident in saying that I have met all the patch systems in the archive
[14:02] <mterry> cjwatson: Your a real man's man.  Your patch system is Debian.
[14:03] <cjwatson> right now the only way to get the property I want is to have a patch system *and* to ship the source package with the patches pre-applied; and that's pretty ugly, although there are a few packages that do it
[14:03] <cjwatson> dpkg-source v3 may turn out better, since then dpkg-source -x can understand the patch system in use
[14:03] <cjwatson> anyway, that's all a distraction; it's still a long-standing convention that we try to keep changes minimal and avoid making essentially cosmetic packaging changes
[14:04] <cjwatson> and it's not because it's a delta to carry, it's because it avoids arguments when Debian maintainers come to look at the patches we have
[14:04] <directhex> patch systems keep me honest. if there's a big ol' .rej file in there, i notice
[14:04] <mterry> cjwatson: Well, is it official Ubuntu policy?  If so, maybe it should be more obvious to n00bs than the one paragrah I've now found at the bottom of PackagingGuide/PatchSystems.  It even words it in an advisory way.
[14:05] <cjwatson> mterry: I have no idea; it's *my* policy for sponsorship if nothing else ...
[14:06] <cjwatson> (and I don't think it's way out of line with everyone else, although I haven't gone to check exactly where it's stated)
[14:06] <mterry> cjwatson: Interesting that it's been your experience that maintainers prefer us not to use patch systems.  I would have thought they'd like to have patches split into logical chunks for them
[14:06] <cjwatson> I didn't say that
[14:06] <cjwatson> maintainers generally prefer us to follow whatever they're currently doing
[14:06] <mterry> cjwatson: Right, but in the case they haven't had to patch anything yet, and thus don't have a patch sys.  Obviously if they already have one, we use that
[14:07] <cjwatson> they could have had a patch system in the package with no patches, if they wanted that
[14:07] <cjwatson> the safe option is to not attempt to add anything to the packaging when it isn't necessary
[14:07] <mterry> cjwatson: Or if it's a native package, and we want to modify it
[14:07] <cjwatson> native packages should absolutely never never never have patch systems
[14:08] <cjwatson> it's daft
[14:08] <mterry> cjwatson: I'm surprised again.  I would think it's very much the same relationship between us and Debian at that point as between Debian and true-upstream at that point.  Same rationales for wanting a patch sys and all that.
[14:08] <cjwatson> if you're faced with a native package, just change the source directly
[14:08] <cjwatson> well, I have five years of experience with native packages and this works very well
[14:09] <cjwatson> if you try to add a patch system then logically you have to change the versioning scheme to non-native too and you get into a massive horrible can of worms
[14:09] <mterry> cjwatson: I believe ya.  It's just not the equilibrium I would have thought.
[14:09] <cjwatson> I was extremely surprised when the OEM team added a patch system to oem-config, let's put it that way :)
[14:10] <directhex> hm. round and round the flame war goes. where it stops, nobody knows
[14:10] <directhex> yay for mailing lists
[14:10] <cjwatson> for native packages it's usually straightforward to arrange version control, which is better at dealing with these things
[14:10] <mterry> cjwatson: Man, though.  It's the only way we could have done it.  We have to make lots of small changes and share them between projects.  We have like 10 distributions.
[14:10] <cjwatson> you could have branched from the existing version control ...
[14:10] <mterry> cjwatson: Fair enough
[14:10] <mterry> cjwatson: Well, that was my doing.  Blame me and my love of patch systems then.
[14:10] <cjwatson> 'bzr merge' for managing that kind of thing would probably actually have been *easier*
[14:11] <mterry> directhex: Naw, I'm not arguing for patch systems, really.  Just trying to understand Ubuntu's experiences with 'em
[14:11] <directhex> mterry, oh, i didn't mean your discussion with colin
[14:11] <directhex> mterry, in my PERSONAL opinion, he's right, with exceptions
[14:11] <mterry> directhex: Oh, right.  I missed your mailing list comment
[14:11] <cjwatson> I'm probably the most anti-patch-systems in Ubuntu; lots of people like them and that's fine, I have no quarrel with that since I've inevitably reached an accommodation
[14:12] <cjwatson> but I've seen a lot of cases where Debian maintainers blog about the mess that Ubuntu people made of their packages
[14:12] <cjwatson> rightly or wrongly :)
[14:12] <cjwatson> usually it's more difference of opinion than anything else - but it underscores that we can give ourselves an easier time if we avoid rocking certain boats
[14:13] <directhex> mterry, and the primary exception is policy-based packaging. if package foo is handled in debian by the libfoo team, and the libfoo team have a foo packaging policy which mentions a patch system, i'd want the patch system integrated at that stage so the -1ubuntu1 can be applied directly as a -2
[14:13] <cjwatson> and patch systems are so incredibly contentious that it's a sensitive boat to rock
[14:13] <mterry> cjwatson: So, I'm not the bzr wizard that some are.  Let's say I have a logical feature that I added to oem-config.  And I've made several changes over time to that 'feature' in several commits.  What's the best way of pulling that feature out?  Do I use feature branches or is there a way of tagging commits?
[14:13] <directhex> i.e. where there's clear policy over patch systems
[14:13] <directhex> don't just pick *your* favourite for "someone else's" package
[14:13] <cjwatson> mterry: you can use feature branches, or there's a feature in bzr called "looms" (which I'm not very familiar with personally, but they exist to solve this problem)
[14:14] <cjwatson> a loom is basically like a patch system represented in version control
[14:14] <cjwatson> https://launchpad.net/bzr-loom
[14:14] <mterry> cjwatson: Hmm...  I'll look into it next time I'm butchering a package you maintain in bzr then.  :)
[14:15] <cjwatson> personally I'm too disorganised to use them ;-)
[14:16] <mterry> cjwatson: So an ideological distaste for patch systems and too disorganized to use version control replacements.  I'm shocked that you set yourself up to be a downstream twice-removed.  ;)
[14:17] <cjwatson> oh, no, I use version control, just not looms as yet
[14:17] <directhex> mterry, he's a DD, so he can pretend it's only once removed
[14:17] <cjwatson> (and I definitely couldn't live without version control these days)
[14:19] <cjwatson> mterry: of course, as a number of people are wont to remind us, the fewer things we carry as long-lived patches the better ...
[14:19] <mterry> cjwatson: Well, the take away here is that it would be nice if we could make a more up-front guideline for MOTUs, maybe decide that it would be Ubuntu policy to not add patch systems.  Unless that runs into the same problems that Debian has with picking one.
[14:19] <mok0> All this patch stuff is a lot easier if we could use source package format version 3.0
[14:20] <mterry> cjwatson: I'm with ya.  The ideal Ubuntu would just be all Debian-synced packages but with branding.  ;)
[14:20] <directhex> mterry, workin' on it for my little neck of the woods
[14:20] <mterry> Is there a wiki page for version 3.0?  I don't know it well.
[14:21] <cjwatson> we don't have a great place for normative packaging *practices* (as opposed to the things you put into packages) right now
[14:21] <cjwatson> it's been on my list for ages to create an Ubuntu version of developers-reference
[14:21] <mterry> cjwatson: A page in wiki.ubuntu.com/PackagingGuide would be good.  Or add it to the ubuntu-policy mirror of debian-policy
[14:21] <cjwatson> right now, scattered wiki pages are about the best we have :-/
[14:21] <cjwatson> it doesn't belong in ubuntu-policy - that's about what goes into packages, not the practices for maintaining them
[14:22] <mok0> The wiki is more-or-less unmaintainable
[14:23]  * mok0 looks forward to seeing what google wave can do
[14:23] <cjwatson> mterry: 'man dpkg-source' has a section on source package formats
[14:24] <mterry> cjwatson: Well, it may be semantics, but 'adding a patchsys' seems like something that goes into packages
[14:24] <cjwatson> 3.0 (quilt) is the relevant one
[14:24] <cjwatson> mterry: it's generally been considered a matter of best-practice kind of documentation rather than technical policy
[14:24] <binarymutant> mok0, did you see the video for google wave? looks awesome so far
[14:24] <mok0> binarymutant: it blew me away
[14:24] <binarymutant> ya
[14:25] <mok0> binarymutant: It could potentially be great for us
[14:26] <binarymutant> mok0, for Ubuntu in general or for collaboration?
[14:26] <mok0> binarymutant: I am sure in general, but I am thinking of Ubuntu
[14:27] <binarymutant> mok0, I can see how it could be great for collaboration, how would it help Ubuntu though?
[14:27] <mok0> binarymutant: it could replace gobby and the wiki
[14:28] <mok0> binarymutant: possibly the mailing list
[14:28] <binarymutant> mok0, wouldn't be more like a supplement to the wiki/mailing list ?
[14:28] <mok0> binarymutant: which would reduce the complexity of communication; atm you have to look in a whole bunch of places
[14:29] <mok0> binarymutant: in reality, probably :-) ... but I think it would be useful to reduce communication channels
[14:29] <mok0> binarymutant: people are now using identi.ca as well
[14:30] <binarymutant> I can't wait to see how Wave unfolds over time, it is definitely a very smart concept
[14:31] <binarymutant> dep5 is confusing, do I have to use it?
[14:32] <binarymutant> people in debian-mentors said that it is unlikely to become policy
[14:44] <gaspa> mok0: hi. commented about your comment. :P
[14:45] <gaspa> just for curiosity: what do you use to build packages?
[14:45] <mok0> gaspa: I use sbuild, mostly
[14:45] <mok0> gaspa: remind me of the bug number, please?
[14:45] <gaspa> mok0: bug #384758
[14:46] <gaspa> mok0: do sbuild use /dev/shm to maintain the whole build process?!? (hope not...)
[14:46] <mok0> gaspa: I don't know how it works
[14:47] <mok0> gaspa: I can try on another one though
[14:47] <mok0> gaspa: but the buildd's use sbuild too
[14:47] <persia> gaspa, sbuild relies on schroot to construct a working chroot.  Many people run schroot over LVM, but there's other ways to do it.
[14:48] <persia> (note that some varieties of sbuild use dchroot, but this isn't recommended nor the default behaviour, and may not even be supported in latest packaged sbuild)
[14:48] <gaspa> mok0: can't be a glitch of your machine? that filenames haven't nothing to do with matita...
[14:48] <gaspa> persia: ;) k.
[14:48] <mok0> gaspa: more likely a glitch in matita :-P
[14:49] <gaspa> why?
[14:49] <mok0> gaspa: Occam's razor
[14:49] <gaspa> :D
[14:49] <calc> slytherin: no
[14:49] <mok0> gaspa: I will try another builder, but I need to set it up for karmic first
[14:50] <calc> slytherin: iirc when we used lucene2 before it caused too much to be pulled onto the cd
[14:51] <slytherin> calc: the reason I asked is that only change in Ubuntu is build-dep/dep set to default-jdk/jre. Are these changes relevant anymore if the package is not moving to main?
[14:52] <gaspa> mok0: ...well, if it continue to appear that fail, I really don't know what's going on...
[14:52] <gaspa> it builds fine both in a italian server (debomatic+pbuilder) and in ppa...
[14:52] <gaspa> anyway... let's see... :P
[14:52] <mok0> gaspa: hm, I can also check the the patch was applied properly
[14:53] <calc> slytherin: hmm let me see
[14:53] <slytherin> calc: if they are not then lucene2 can be synced (instead of merge).
[14:55] <calc> slytherin: they can probably be dropped as its in universe, but it would be better to see if Debian will take the changes, as if i understand correctly Debian is transitioning to it as well
[14:55] <calc> slytherin: it seems i forgot to file a bug report about it in the debian bts
[14:55]  * calc bbia 10m
[14:56] <mok0> gaspa: failed again, with another error message I've also seen on my netbook
[14:57] <mok0> gzip: stdout: Broken pipe
[14:57] <mok0> Undefined subroutine &Dpkg::Source::CompressedFile::subprocerr called at /usr/share/perl5/Dpkg/Source/CompressedFile.pm line 144.
[14:57] <gaspa> :|
[14:57] <mok0> Impressive, huh?
[14:57] <gaspa> Have you the 'builder broken' magic? :D
[14:57] <mok0> I will rebuild the source package, perhaps it is corrupted
[14:58] <gaspa> no, jokes apart, I'll investigate.
[14:59] <binarymutant> is this a decent copyright file? http://revu.ubuntuwire.com/revu1-incoming/pidgin-mbpurple-0906101557/pidgin-mbpurple-0.2.1/debian/copyright
[15:01] <slytherin> calc: Debian has not even started transition yet. default-jdk still points to gcj.
[15:02] <calc> well its still default-jdk, just not transitioned to openjdk
[15:02] <mok0> binarymutant: looks like an intermediate between the old and the new formats...
[15:04] <binarymutant> mok0, yeah I don't really like the header section on dep5 :/
[15:04] <binarymutant> mok0, but is that okay to do?
[15:05] <calc> slytherin: but i am not certain if they have started converting over to default-jdk yet (i think they have though)
[15:06] <slytherin> calc: only when the package compiles with gcj, which is still default-jdk. lucene2 does not build with gcj.
[15:06] <mok0> binarymutant: actually, no
[15:07] <mok0> binarymutant: write it in the new machine-readable format
[15:07] <binarymutant> :(
[15:07] <mok0> binarymutant: it'll only take you 2 minutes
[15:21] <binarymutant> mok0, like this http://revu.ubuntuwire.com/revu1-incoming/pidgin-mbpurple-0906101621/pidgin-mbpurple-0.2.1/debian/copyright ?
[15:22] <mok0> binarymutant: almost... think "debian/control" ... the file must be in RFC822 format
[15:23] <mok0> binarymutant: get rid of the first 3 lines, and add " ." to the paragraphs in the license text
[15:26] <binarymutant> mok0, like " .This program is free software;"[...] ? I'm not understanding the " ."
[15:27] <mok0> binarymutant: like in the long description, when you have an empty line, you put space-dot
[15:27] <binarymutant> ah yes okay
[15:28] <mok0> binarymutant: the file is supposed to be readable by the same parser that parses debian/control
[15:29] <mok0> gaspa: the build succeeded now. I've uploaded your merge
[15:29] <gaspa> ah, cooool.. thank you
[15:29] <gaspa> do you understood what happened?!
[15:30] <mok0> gaspa: no... something must have been corrupted in my source package
[15:31] <gaspa> strange...
[15:31] <gaspa> anyway, thanks, again
[15:31] <mok0> gaspa: please watch the package and see if it's now builds
[15:34] <binarymutant> mok0, do I need to put " ." in between the license and " On Debian systems, the complete text[...]" ? http://revu.ubuntuwire.com/revu1-incoming/pidgin-mbpurple-0906101633/pidgin-mbpurple-0.2.1/debian/copyright
[15:36] <mok0> binarymutant: Yes, if you want it to be a part of the text above it. I usually put it in a home-made field called "X-Comment: " (RFC822 allows that)
[15:36] <binarymutant> ah ok
[15:42] <gaspa> mok0: karmic amd64: Successfully built.(ACCEPTED)
[15:42] <gaspa> waiting for the arch-indep...
[15:43] <mok0> gaspa: I did build both
[15:43] <mok0> gaspa: the matita build runs a lot of unit tests... takes forever
[15:44] <mok0> gaspa: I guess you know that :-)
[15:44] <gaspa> yep...
[15:44] <gaspa> I tried a lot of time...
[15:45] <binarymutant> so this copyright file is uber-great right? http://revu.ubuntuwire.com/revu1-incoming/pidgin-mbpurple-0906101645/pidgin-mbpurple-0.2.1/debian/copyright
[15:46] <mok0> binarymutant: looks great
[15:47] <binarymutant> awesome, the old debian/copyright style looks better though
[15:47] <Laney> binarymutant: your dot alignment is weird
[15:47] <binarymutant> thanks or all your help mok0 it was very educational :)
[15:47] <binarymutant> Laney, what do you mean?
[15:47] <mok0> binarymutant: you think so? I like the new format much better. More systematic and easy to write... especially if there are several licenses
[15:48] <Laney> it should be like http://paste.debian.net/38627/
[15:49] <mok0> Laney: is that the new shortened version of the GPL?
[15:50] <Laney> RMS told me he likes it :)
[15:50] <mok0> hehehe
[15:51] <mok0> shorter than the WTFPL
[15:51] <persia> More flexible as well :)
[15:51] <binarymutant> Laney, gotcha thank you, it has been updated
[15:51] <directhex> i feel the baz clause is too restrictive :(
[15:52] <mok0> directhex: it follows naturally from foo & bar IMHO
[15:53] <binarymutant> I heard on #debian-mentors that dep5 was unlikely to become policy
[15:54] <mok0> binarymutant: hm?
[15:54] <binarymutant> anyone want to advocate http://revu.ubuntuwire.com/p/pidgin-mbpurple now that it's copyright file is super great? :)
[15:54] <mok0> binarymutant: /me volunteers
[15:55] <binarymutant> mok0, someone told me it wasn't going to become policy is this true? seems like in this channel that most agree that it will become policy
[15:56] <mok0> binarymutant: Hard to predict what Debian decides
[15:56] <binarymutant> when does Debian vote on things like that?
[15:59] <mok0> binarymutant: don't know... it's been made a DEP now, so it's moving slowly along
[15:59] <mok0> binarymutant: some debian teams are already using it
[16:00] <binarymutant> hopefully not papt or pkg-ruby-extas :/
[16:17] <persia> binarymutant, Whether DEP5 becomes a requirement or not is separate from whether DEP5-complaint copyright files happen to be policy compliant.
[16:18] <persia> As I understand the current discussion (which may be incorrect), it's somewhat like rectangles and quadrilaterals, with DEP5 representing the spec for rectangles.
[16:21] <binarymutant> I understand that dep5 is policy compliant, but I was having issues with complying to a proposal. What I understand better is pleasing the sponsors, which is why I switched styles in that copyright file :)
[16:25] <persia> binarymutant, Pleasing the sponsors by doing it the way they do it is not a bad way to learn, but you'll really please the sponsors if you demonstate a deep enough understanding to argue that the way you've done it is correct (and be right).
[16:25] <directhex> and/or bribe them
[16:25] <binarymutant> lols
[16:26] <binarymutant> I was told cookies work the best for sponsor bribes
[16:29] <binarymutant> persia, I understand, I just don't agree with dep5 it seems like change for the sake of change. I do understand the argument for dep5 however too although I feel it isn't enough to become policy
[16:30] <persia> binarymutant, That's fine.  Don't use it.  There's no requirement you must.
[16:30] <binarymutant> it would be easier to gather statistics on licenses but what else would dep5 accomplish?
[16:30] <persia> Just be sure of yourself, and be sure that the result of whatever method you use is compliant with policy.
[16:31] <binarymutant> thank you persia :)
[16:31] <persia> One could write a script that generated most of debian/copyright based on licensecheck.  Still needs manual review, but would hit a fair bit, and probably highlight stuff that needed closer review.
[16:31] <persia> I'm undecided as to whether such a script is a good thing.
[16:32] <stefanlsd> binarymutant: i've done 1 package with dep5, and it really helped in finding and listing the license requirment for each file.  I think by its nature will also make it easier for sponsors to check and also assist for future updates (i can just check those files listed now).  maybe its more useful on packages with many different licenses.
[16:32] <directhex> i'd want licensecheck to suck less first
[16:32] <directhex> stefanlsd, i dep5'd openjdk. more or less. now THAT was an ordeal
[16:33] <binarymutant> gah I've started the dep5 talk on two irc servers now :/
[16:34] <stefanlsd> directhex: yeah, a bit of a pain, but probably more correct because of it right?
[16:34] <directhex> stefanlsd, oh, sure. not that any ftpmaster would want to actually double-check it
[16:34] <binarymutant> mok0, does the package look good? http://revu.ubuntuwire.com/p/pidgin-mbpurple
[16:35] <stefanlsd> directhex: heh. yeah. but the fact that its so explict and detailed, they probably can trust it...  also, for newer upstreams, you can do quick checks against the explicit files to ensure they are the same license
[16:35] <mok0> binarymutant: I was interrupted, hang on
[16:35] <binarymutant> oh sorry :/
[16:35] <directhex> stefanlsd, a tool to parse dep5 would be great - i.e. "dep5check src/foo/bar/baz.cs" would say what your debian/copyright proclaims, you could then check by hand
[16:36] <stefanlsd> directhex: yeah ,i think thats the whole reason behind dep5. some computer parsable license file.
[16:39] <binarymutant> couldn't the maintainer of an old style copyright file just write a script with a regex to do that?
[16:39] <binarymutant> *nevermind*
[16:42] <mok0> binarymutant: does this package differ from the one found in upstream's ppa?
[16:44] <binarymutant> mok0, yes the upstream's version does not conform to policy and uses cdbs, etc
[16:44] <binarymutant> and doesn't follow dep5 :P
[16:44] <mok0> binarymutant: so they're ok with your work on the package?
[16:45] <binarymutant> mok0, should I ask? It didn't seem like they were trying to push it into Debian or Ubuntu, no ITPs and again their's does not conform to policy
[16:46] <mok0> binarymutant: it would be polite to talk to them... most likely they will be happy about it
[16:46] <binarymutant> I'll write a ticket on their vcs :)
[16:47] <mok0> binarymutant: great. At the same time, tell them to put copyright blurps in the source code files :-)
[16:47] <binarymutant> mok0, I've already brought that up, it seems like they did not want to though :/
[16:48] <binarymutant> ^ that ticket was filed around 2 weeks ago
[16:48] <mok0> binarymutant: hm, it means someone could take one of their code files and put it in another project, and no-one would know where it came from
[16:49] <binarymutant> mok0, I understand, the maintainer replied at first but then has ignored it ever since
[16:49] <mok0> binarymutant: most upstreams aren't aware of the problems involving distribution of software
[16:50] <mok0> binarymutant: it's no blocker though
[16:53] <mok0> binarymutant: how would you add this plugin to pidgin, for example?
[16:53] <binarymutant> mok0, it installs itself to pidgin's plugin directory if that's what you mean
[16:54] <mok0> binarymutant: ok, nice. What about other apps?
[16:55] <mok0> binarymutant: you mention Finch
[16:56] <binarymutant> mok0, sorry it installs to lib/purple-2/ directory so it will work with Finch and other libpurple based apps
[16:57] <binarymutant> had to rebuild it to see :/
[16:57] <mok0> binarymutant: I think that should be made more clear in the long description
[16:58] <mok0> binarymutant: "If you install this package, the plugin will work with all libpurple based clients" or something like that
[16:58] <binarymutant> mok0, what do you mean? it works with Finch by default since it installs under libpurple instead of being app specific
[16:58] <binarymutant> ah
[16:59] <mok0> binarymutant: it would be useful if was explained to dummies like me
[16:59] <binarymutant> mok0, "it works for other LibPurple base clients like Finch."
[16:59] <mok0> binarymutant: sure
[16:59] <binarymutant> thats what it says now :/
[17:01] <binarymutant> err I mean that's what it says in revu already
[17:02] <mok0> binarymutant: perhaps, but just add another sentence that says what happens when you install the pacakge
[17:04] <mok0> binarymutant: then I will advocate ;-)
[17:07] <binarymutant> mok0, I'm not sure how I could explain that, and looking at other pidgin plugins' descriptions is not helping either :/
[17:10] <mok0> binarymutant: http://pastebin.com/f3db3d79d
[17:12] <binarymutant> mok0, Isn't that being to specific to twitter?
[17:12] <mok0> binarymutant: yes, perhaps "microblogging"
[17:17] <\sh> siretart: ping if you have time...
[17:18] <Laney> This plugin enables microblogging support for Pidgin and other libpurple clients such as finch. It supports Twitter and laconi.ca based services such as identi.ca.
[17:18] <binarymutant> mok0, thank you for the comment, it has been successfully updated if you still have the time to advocate :)
[17:19] <binarymutant> Laney, you like the old desc. too?
[17:19] <mok0> binarymutant: +1
[17:20] <binarymutant> Laney, oh I see, the "." in identica
[17:20] <binarymutant> thanks mok0
[17:21] <Laney> dunno what is the new one?
[17:22] <binarymutant> Laney, http://revu.ubuntuwire.com/revu1-incoming/pidgin-mbpurple-0906101818/pidgin-mbpurple-0.2.1/debian/control
[17:23] <Laney> I don't know what "seamless" is supposed to mean here
[17:23] <Laney> and the "Therefore" is weird - that sentence doesn't actually follow directly from the previous one
[17:23] <mok0> That's right actually. I am responsible for that one
[17:24] <binarymutant> Laney, continuous = seamless
[17:25] <Laney> I'd just say "This plugin allows the sending and receiving of messages to microblogging services"
[17:25] <Laney> or something like that
[17:25] <mterry> What is a 'fakesync?'  Like when a changelog says 'fakesync from debian'
[17:25] <Laney> and I don't think libpurple is capitalised in that way - see http://209.85.229.132/search?q=cache:dXp1svHGKrgJ:developer.pidgin.im/wiki/WhatIsLibpurple+libpurple&cd=1&hl=en&ct=clnk&client=safari
[17:26] <Laney> mterry: it's when the orig.tar.gz is different in debian and ubuntu
[17:26] <mok0> mterry, when a real sync can't be performed because the versions are the same
[17:26] <binarymutant> Laney, it was copied from upstream http://code.google.com/p/microblog-purple/
[17:27] <Laney> binarymutant: Doesn't matter - you should improve it if you can
[17:27] <mok0> poor binarymutant :-D
[17:27] <Laney> it's quite obvious from that page that it wasn't written by a native speaker
[17:27] <mterry> mok0, Laney: Thanks.  Or possibly when we take some pending Debian changes from their git, but they haven't released?
[17:28] <Laney> mterry: No, that's not a sync
[17:29] <mterry> Laney: OK, thanks
[17:41] <binarymutant> mok0, Laney, http://paste.ubuntu.com/192750/ this seems better (?)
[17:43] <mok0> binarymutant: you don't mention finch anymore?
[17:45] <binarymutant> mok0, "[...] other libpurple based clients"
[17:45] <mok0> binarymutant: that requires that you know that finch is libpurple based...
[17:46] <binarymutant> true
[17:48] <mok0> binarymutant: I would like it to be clear to the non-technical user coming from Windows what the package is good for
[17:49] <mok0> binarymutant: people know what microblogging is, but nobody knows what libpurple is
[17:50] <mok0> binarymutant: how would you explain it to your mother?
[17:51] <mok0> binarymutant: that's what it should be like
[17:53] <cjwatson> mterry: the underlying constraint here is that once we've published a file with a given name to the archive, we can't change its contents
[17:54] <cjwatson> mterry: there are two reasons for this. Firstly it would be impossible to make both old and new versions available at the same time if we did that; secondly it allows a very significant rsync optimisation for mirrors (i.e. once they have a file with the right name and size, they don't need to recheck its checksum)
[17:55] <mterry> cjwatson: Understood
[17:55] <binarymutant> mok0, http://paste.ubuntu.com/192764/ a better revision :)
[17:56] <mok0> It's better
[17:57] <mok0> binarymutant: ping me later for a new vote, I have to go
[17:57] <binarymutant> mok0, thanks for all your help
[19:28] <ausimage> hey all
[19:28] <ausimage> I am trying to get my package into universe....
[19:28] <ausimage> I am trying to understand get-orig-source...
[19:29] <ausimage> This goes in the rules ??
[19:29] <ausimage> but what if it is a pure python pacakage without sections like it shows?
[19:29] <ausimage> is it better as watch then?
[19:31] <cjwatson> get-orig-source goes in debian/rules, yes, but it's optional and it's usually only provided in weird cases
[19:31] <ausimage> cjwatson: but revu thinks it is required?
[19:31]  * cjwatson blinks
[19:31] <cjwatson> guess none of my packages would pass revu then ;-)
[19:32] <ausimage> http://revu.ubuntuwire.com/details.py?upid=5990
[19:32] <ausimage> This package has no debian/watch file or get-orig-source rule.
[19:32] <cjwatson> (a) I think that means one or the other not both (b) it's a warning
[19:33] <cjwatson> these days, debian/watch is more usual for simple cases, I believe
[19:33] <ausimage> cjwatson: I am asking given the rules is a DEB_PYTHON
[19:33] <cjwatson> it doesn't matter what language it's in
[19:33] <cjwatson> get-orig-source / debian/watch is about where the original source comes from
[19:33] <cjwatson> what language it's written in is startlingly irrelevant
[19:34] <cjwatson> anyway, off to watch a film :)
[19:34] <ausimage> I can append sections to a virtually blank rules then?
[19:34] <cjwatson> sure
[19:34] <cjwatson> they're called 'targets'
[19:34] <cjwatson> see 'info make'
[19:34] <cjwatson> (you might need the make-doc package installed for that)
[19:34] <ausimage> ahh it seems easier I guess
[19:35] <cjwatson> like I say though, if your .orig.tar.gz is just downloaded directly from some upstream site and there's no funny business going on with repacking it, then I'd advise using debian/watch and not get-orig-source
[19:36] <cjwatson> I'd only advise get-orig-source when the process of constructing the .orig.tar.gz is more than just downloading something
[19:36] <cjwatson> e.g. removing non-free material, or converting between compression formats
[19:36] <ausimage> oh?
[19:36] <cjwatson> but anyhow, really gone
[19:46] <ausimage> is http://ze-dinosaur.livejournal.com/6368.html relevant for creating watch files?
[19:46] <ausimage> the version on ubu wiki is so much more complicated :/
[19:50] <fabrice_sp_> ausimage, in the debian/watch filecreated by default, you have the same content
[19:51] <fabrice_sp_> you can then test it by running uscan --verbosse to check the watch file is correct
[19:51] <ausimage> ok...
[19:54] <fabrice_sp_> s/verbosse/verbose
[20:37] <ausimage> anyone know how to set dch to use a different email addies?
[20:37] <nhandler> ausimage: The DEBEMAIL environment variable controls that
[20:37] <geser> export DEBEMAIL and export DEBFULLNAME
[20:37] <ausimage> ahhh...
[20:37] <ausimage> k
[20:38] <ausimage> google and -h were not helpful to that end
[20:40] <nhandler> ausimage: It is in the manpage
[20:41] <ausimage> ahhh... guess I never think about that :/
[20:48] <james_w> I'd appreciate reviews of http://revu.ubuntuwire.com/p/lazr.uri if anyone has a minute
[20:49] <james_w> it's a new dependency of launchpadlib
[21:04] <ajmitch> james_w: not going with the normal python-foo naming?
[21:04] <james_w> for the binary
[21:05] <binarymutant> what does PR mean in a debian/changelog ?
[21:05] <binarymutant> patch released?
[21:07] <hyperair> binarymutant: which changelog?
[21:08] <binarymutant> hyperair, it's in gcc4.4 ie "PR bootstrap/40027,"
[21:09] <hyperair> O_o
[21:09] <hyperair> ask the gcc guys
[21:09] <Laney> james_w: Newer debian policy, no watch file. And on a style note, consider DEP5 copyright and DH7 watch file
[21:09]  * Laney test builds
[21:09] <sebner> Laney: dh7 watch file. did I miss something?
[21:10] <james_w> rules :-)
[21:10] <binarymutant> hyperair, thanks for trying :)
[21:10] <Laney> erm
[21:10] <Laney> rules
[21:10] <Laney> I'm distracted by TV
[21:10] <hyperair> binarymutant: heheh
[21:10] <sebner> heh
[21:10] <sebner> dh7 rules ftw!
[21:10] <hyperair> hehe
[21:10] <hyperair> dh7 watchfile eh
[21:10] <fabrice_sp_> binarymutant, Problem Report?
[21:10]  * Laney watches hyperair 
[21:11]  * hyperair watches Laney 
[21:11] <james_w> are you going to make me upgrade to karmic so that I can read upgrading-checklist for the latest policy?
[21:12] <Laney> it's not online?
[21:12] <directhex> and ix 5 bugs, too
[21:12] <sebner> james_w: yeah, dev upgrade \o/
[21:12] <james_w> found the announcement of the release now
[21:14] <james_w> watch file isn't easy though :-)
[21:16] <iulian> james_w: Please don't use dh_clean -k because it's deprecated, you can use dh_prep instead.
[21:16] <james_w> no I can't
[21:16] <james_w> that's dh7 only
[21:17] <iulian> Don't you use dh7?
[21:17] <iulian> Ah, misread.
[21:19] <iulian> There are two lintian warnings as well (W: python-lazr-uri: copyright-lists-upstream-authors-with-dh_make-boilerplate and W: python-lazr-uri: spelling-error-in-description python Python)
[21:20] <iulian> That's all from me.
[21:20]  * iulian goes to bed.
[21:21] <james_w>  o/~ join us now and carefully edit debian/copyright files! o/~
[21:21] <james_w> thanks iulian
[21:28] <ramvi> I'm creating a bash script, I chroot, but then my choot lose control () it can't keep running commands. Why is that?
[21:29] <hyperair> because chroot spawns a shell inside the new root.
[21:29] <hyperair> any subsequent commands in the bash script will be run *after* that shell has exited
[21:30] <hyperair> if you want to get it to run commands, you'll have to dump it into a script inside the chroot, and then run chroot with the path to that script.
[21:30] <james_w> thanks for all the comments, http://revu.ubuntuwire.com/p/lazr.uri updated
[21:32] <ramvi> hyperair: thanks!!
[21:34] <Laney> james_w: I'm trying to build the source package and it's attempting to download some file and 404ing
[21:34] <Laney> http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c8-py2.6.egg
[21:35] <james_w> you don't have Build-Depends installed?
[21:36] <hyperair> ramvi: np
[21:36] <Laney> huh, evidently not
[21:36] <Laney> but that's an unfriendly way to bail
[21:36] <Laney> not your package's problem though
[21:37] <james_w> nope, I'll file a bug
[21:37] <ajmitch> Laney: probably python stuff trying to be smart
[21:44] <Laney> james_w: ok I'm happy with it. Advocated
[21:44] <james_w> thanks Laney
[21:46] <Daviey> Hey, what is the best way to have a version number that includes the date (ie, 20090610) in the changelog to ensure it is a newer sub-version?
[21:46]  * ajmitch wonders if it'll cause a precedent for naming python modules like that
[21:46] <Daviey> so, for example = 1.0-20090610 ?
[21:47] <Daviey> should it be -, ~ or _ ? :)
[21:48] <directhex> Daviey, "newer"? what is it now?
[21:48] <Daviey> 1.0
[21:48] <directhex> Daviey, +
[21:48] <Laney> Daviey: Is this an SVN snapshot type of situation?
[21:48] <Daviey> directhex: it's not for a ubuntu repo package, but ppa
[21:48] <Daviey> Laney: pretty much
[21:49] <Laney> 1.0+svnyyyymmdd
[21:49] <directhex> -1
[21:49] <Daviey> so 1.0+yyyymmdd will show it as the most recent when built?
[21:49] <directhex> Daviey, + is always higher than nothing
[21:49] <directhex> Daviey, so "1.0+" > "1.0"
[21:50] <Daviey> directhex: sure, but is 1.0+20090611 > 1.0+20090610
[21:50] <Laney> you can use dpkg --compare-versions to check
[21:50] <directhex> Daviey, well, yes
[21:50] <directhex> Daviey, that's the point of iso date order
[21:50] <Daviey> that'll do, thanks chaps
[21:50] <Laney> dpkg --compare-versions x gt y && echo true
[21:55] <binarymutant> is the FeatureFreeze for universe on the 18th or is it just main?
[21:56] <Laney> 18th?!
[21:56] <ajmitch> binarymutant: FeatureDefinitionFreeze != FeatureFreeze
[21:56] <binarymutant> oh
[21:56] <Laney> I don't think that affects us much, if at all
[21:56] <ajmitch> the first is getting specs finalised
[21:56] <directhex> August 27th
[21:56] <directhex> FeatureFreeze
[21:57] <ajmitch> do you really think there'd only be ~2 weeks of feature development for karmic since UDS? :)
[21:57] <binarymutant> ah thanks you
[21:58] <binarymutant> s/thanks/thank
[22:26] <siretart> \sh: pong
[22:39] <maxb> Why does bzr strip leading whitespace when automatically seeding the commit message from debian/changelog?
[22:40] <maxb> I'm so used to properly formatted debian/changelogs that it looks really wrong to me
[22:41] <james_w> maxb: that's the convention from debcommit
[22:44] <maxb> ok, why is it the convention? :-)
[23:02] <cjwatson> ausimage: belatedly, watch file reference and examples: 'man uscan'
[23:03] <cjwatson> maxb: I like it myself, it produces much neater commit messages that are closer to what you'd get if you were typing the commit message into bzr commit directly
[23:04] <cjwatson> (well, of course I like it, I made that change to bzr-builddeb ...)
[23:12]  * directhex is confused. is maco confused too?
[23:20] <directhex> popey, is listening to this podcast going to make me want to stab something?
[23:31] <ausimage> thanks cjwatson ;)
[23:33] <ausimage> I'd appreciate any python or packaging experts comments on http://revu.ubuntuwire.com/details.py?upid=6008 :)