[00:06] <marcin_ant> hello
[00:06] <nhandler> Hello marcin_ant
[00:07] <marcin_ant> is there any packaging guru that could answer me few questions?
[00:07] <jdong> I'd suggest going ahead and asking instead of asking if you can ask :)
[00:08] <marcin_ant> ok I'll shoot
[00:09] <marcin_ant> I think that debian policy and ubuntu packaging guide are pretty weird and I really don't understand it's policy according to non-native packages
[00:09] <marcin_ant> I got an example
[00:09] <marcin_ant> I want to package application that is available as upstream tar.gx
[00:09] <marcin_ant> gz
[00:11] <marcin_ant> but inside this tar there is a bunch of directories let's say dira dirb dirc
[00:12] <marcin_ant> I want to create few packages from this upstream let's call it test-dira, test-dirb, test-dirc
[00:12] <marcin_ant> so I created directory named test-dira-1.0 then directory named debian
[00:12] <marcin_ant> in it
[00:13] <marcin_ant> and in debian dir I created all required files and watch file with required path
[00:13] <marcin_ant> I also added get-orig-source target with uscan script
[00:14] <Adri2000> marcin_ant: if you have one orig.tar.gz, you have one source package and one debian/ directory. then from that source package you can create multiple binary packages
[00:14] <marcin_ant> then I returned to test-dira-1.0 and: debian/rules get-orig-source
[00:14] <marcin_ant> Adri2000: please read carefully what I write
[00:15] <marcin_ant> Adri2000: I understand that I got one source package and I understand that I can create multiple packages from it
[00:15] <marcin_ant> Adri2000: but this "story" is not about it
[00:15] <jdong> marcin_ant: well you're not doing it correctly
[00:15] <jdong> and that's what Adri2000 is trying to tell you.
[00:16] <jdong> it's unclear from your abstract example exactly what you are trying to do
[00:16] <jdong> what are dira, dirb, and dirc in relation to the orig.tar.gz?
[00:16] <marcin_ant> just few words
[00:17] <marcin_ant> jdong: problems are: 1. orig.tar.gz doesn;t have single directory inside it has 3 directories called dira, dirb, dirc
[00:17] <jdong> you've said that.
[00:17] <marcin_ant> anyway I'll just finish
[00:17] <jdong> I asked what specifically are a b and c?
[00:17] <jdong> and what would you like to turn them into?
[00:17] <marcin_ant> so I run debian/rules get-orig-source
[00:18] <marcin_ant> then get-orig-source downloads upstream package to parent of debian
[00:18] <marcin_ant> this is the place where should upstream orig.tar.gz go
[00:19] <marcin_ant> so I got:
[00:19] <marcin_ant> ~/dira.orig.tar.gz
[00:19] <marcin_ant> ~/test-dira-1.0/
[00:19] <jdong> why do you have dira.orig.tar.gz?
[00:19] <jdong> I thought you said orig.tar.gz contained dira, dirb, and dirc?
[00:20] <marcin_ant> jdong: because it is upstream name
[00:20] <jdong> ok, then what are dirb, and dirc for?
[00:20] <jdong> are they supporting libraries / dependenices?
[00:20] <jdong> related binaries?
[00:20] <marcin_ant> jdong: read again - they are inside of dira.orig.tar.gz
[00:21] <jdong> *YOU SAID THAT*
[00:21] <jdong> I am saying your abstract example is too vague for me to say anything useful.
[00:22] <jdong> I'm trying to understand why upstream has three directories inside a source tarball for a project where one name is dominant
[00:22] <marcin_ant> jdong: get this upstream: http://plone.org/products/archetypes/releases/1.4.6/archetypes-1-4-6-final-bundle-tar.gz
[00:22] <jdong> lol ok that's annoying enough upstream made a bundle that's a tarbomb
[00:24] <marcin_ant> jdong: or maybe better 1.4.5 release because 1.4.6 has bug in it's name...
[00:24] <marcin_ant> http://plone.org/products/archetypes/releases/1.4.5
[00:24] <marcin_ant> anyway take a look what is inside
[00:25] <jdong> yeah I am looking at it right now
[00:25] <jdong> upstream's site is timing out right now (45s and counting), is the software available in an unbundled tarball?
[00:25] <jdong> it seems like the sub-directories are distinct python modules (packages)
[00:26] <marcin_ant> apt-get source zope-archetypes
[00:26] <marcin_ant> you will get orig.tar.gz 1.4.2 version (afair)
[00:27] <jdong> ok, cool, so it has already been packaged
[00:27] <marcin_ant> jdong: packaged 1.4.2 current from 1.4 branch is 1.4.6
[00:28] <jdong> ok, so you just need to update it to the latest upstream version
[00:28] <marcin_ant> jdong: ok but now we can talk about something less abstract ;)
[00:28] <jdong> so, it uses the one "source package generates multiple binary packages" paradigm
[00:29] <marcin_ant> jdong: ok but let's say that I want to make few changes in /debian directory
[00:29] <jdong> the alternate case is repacking the source tarball into several distinct source packages
[00:29] <jdong> alright?
[00:29] <marcin_ant> jdong: ok propably - but it's not a problem for me to produce multiple binaries from this source tar
[00:29] <marcin_ant> jdong: problem is different
[00:29] <jdong> continue :)
[00:30] <marcin_ant> jdong: I really don't understand what to do with it's internal directory structure
[00:30] <ajmitch> NB: zope-archetypes was removed from debian, replaced by zope-plone3
[00:30] <jdong> marcin_ant: what ajmitch is probably relevant now
[00:30] <jdong> marcin_ant: but at any rate, to answer your original question
[00:31] <jdong> marcin_ant: so the orig.tar.gz file is simply the same thing as the tar.gz you get from upstream
[00:31] <marcin_ant> jdong: right
[00:31] <jdong> marcin_ant: the diff.gz file from Debian is a patch to the extracted .tar.gz directory
[00:31] <jdong> marcin_ant: it primarily is supposed to add the debian/ directory
[00:31] <jdong> marcin_ant: roughly what's done when you apt-get source is "tar xzvf orig.tar.gz; cd orig-folder; zpatch -p1 < ../diff.gz"
[00:31] <marcin_ant> jdong: and if I will run tar zxvf on it I will get a bunch of directories instead of single dir
[00:32] <jdong> marcin_ant: in this case, there's a notable exception that the upstream tarball is a tarbomb
[00:32] <jdong> i.e. it blows up into multiiple directories in the current directory :)
[00:32] <jdong> marcin_ant: dpkg-source (the extractor) is smart enough to detect this situation
[00:32] <marcin_ant> jdong: right
[00:32] <jdong> marcin_ant: it automagically creates a sourcepackage-1.2.3 directory first and then unpacks inside of there
[00:33] <pangloss> hey guys, I am trying to do the debian/watch part of the packaging guide, and usan is not finding anything at the url I am putting in
[00:33] <jdong> marcin_ant: if you want to make a change and build a source package again, you simply run debuild -S
[00:33] <marcin_ant> jdong: ok but let's use this as an example
[00:33] <jdong> marcin_ant: the system will be smart enough to detect what you changed, use the orig.tar.gz and update the diff.gz
[00:33] <jdong> marcin_ant: if you want to update to a new version, you need to use the uupdate tool
[00:34] <jdong> marcin_ant: it takes a tarball for the new upstream version as an argument, and correctly rebases the existing diff.gz on top of the new orig.tar.gz
[00:34] <marcin_ant> jdong: let's say that I want to do this from scratch let's forget about 1.4.2.deb etc
[00:34] <jdong> marcin_ant: ok, if you want to do it from scratch, in this case
[00:34] <jdong> marcin_ant: you'd first make a archetypes-1.4.2 directory
[00:35] <jdong> marcin_ant: then you'd unpack the orig.tar.gz into there
[00:35] <marcin_ant> jdong: zope-archetypes-1.4.2
[00:35] <jdong> marcin_ant: yeah, you get my point
[00:35] <marcin_ant> jdong: ok and that is a problem(!)
[00:35] <jdong> marcin_ant: then you can run dh_make inside there, letting it know where your orig.tar.gz is
[00:35] <marcin_ant> jdong: orig.tar.gz will not unpack into this directory
[00:36] <jdong> marcin_ant: why not?
[00:36] <marcin_ant> jdong: https://wiki.ubuntu.com/PackagingGuide/Complete says that:
[00:36] <marcin_ant> mkdir ~/hello && cd ~/hello && wget http://ftp.gnu.org/gnu/hello/hello-2.1.1.tar.gz
[00:37] <jdong> marcin_ant: the packaging guide is written under the assumption upstream isn't retarded and packages their product as a tarbomb.
[00:37] <marcin_ant> jdong: so in our case I should: mkdir ~/zope-archetypes-1.4.2
[00:37] <jdong> marcin_ant: so yes, in our case we have an exceptional case where upstream is retarded
[00:37] <marcin_ant> jdong: cd zope-archetypes-1.4.2
[00:37] <marcin_ant> jdong: ok I get it
[00:37] <marcin_ant> jdong: but another thing
[00:38] <marcin_ant> jdong: this upstream is really nightmare
[00:38] <jdong> marcin_ant: note that the orig.tar.gz doesn't get wgetted into ~/zope-archetypes-1.4.2 :)
[00:38] <jdong> marcin_ant: so it'd be more like mkdir ~/zope; cd ~/zope; mkdir z-a-1.4.2; wget tar.gz, cd z-a-1.4.2; tar xzvf ../*.tar.gz, and so on
[00:38] <jdong> but you get my point
[00:38] <marcin_ant> jdong: yes I noticed and this is a part of my next question
[00:39] <marcin_ant> jdong: there is a lot of packages that have single directory inside tarball
[00:39] <jdong> yep, that's the way it's supposed to be, in fact
[00:40] <marcin_ant> jdong: but these direcories have different name
[00:40] <marcin_ant> jdong: let's say that we want to create package zope-archetypes and got zope-archetypes.orig.tar.gz
[00:40] <marcin_ant> jdong: with single dir inside called Archetypes
[00:41] <jdong> marcin_ant: the dpkg-source helpers that handle the orig.tar.gz for you are generally smart enough to figure this out
[00:41] <jdong> marcin_ant: they work around most of the quirks with packaging conventions
[00:41] <marcin_ant> jdong: then I just can untar and create debian dir inside this Archetypes directory - right?
[00:41] <jdong> marcin_ant: correct
[00:41] <jdong> marcin_ant: note for dh_make to work you must rename that dir to archetypes-1.4.2
[00:41] <marcin_ant> jdong: ok so last thing
[00:42] <jdong> marcin_ant: dh_make requires the current directory to be in format (name)-(upstream version)
[00:42] <marcin_ant> jdong: let's say that I don't have upstream tarball yet
[00:42]  * pangloss pokes nhandler
[00:42] <marcin_ant> jdong: or I want to create new upstream version
[00:43] <marcin_ant> jdong: I got: ~/zope-archetypes/zope-archetypes-1.4.2/debian
[00:43] <marcin_ant> jdong: I create all required files in debian dir and I also watch file with url to upstream and get-orig-source
[00:44] <marcin_ant> jdong: then I cd to ~/zope-archetypes/zope-archetypes-1.4.2 and run debian/rules get-orig-source
[00:45] <marcin_ant> jdong: it will download tar.gz for me and this will be renamed to orig.tar.gz and will go to: ~/zope-archetypes (parent of zope-archetypes-1.4.2)
[00:46] <marcin_ant> jdong: so far so good but it's not good because zope-archetypes-1.4.2.orig.tar.gz will not untar sources to zope-archetypes-1.4.2 (where debian directory is)
[00:46] <jdong> marcin_ant: that's okay
[00:46] <marcin_ant> jdong: it will untar sources to Archetypes.... and what should I do with this?
[00:46] <jdong> marcin_ant: dpkg-source doesn't just blindly run an untar
[00:47] <jdong> marcin_ant: the actual dpkg-source command that unpacks a Debian source figures this out
[00:47] <jdong> marcin_ant: I'll give you an example from your archetypes package:
[00:47] <jdong> marcin_ant: go back to "apt-get source zope-archetypes" like we did before
[00:47] <jdong> marcin_ant: if you notice, it fetches three files: .dsc, .diff.gz, .orig.tar.gz
[00:47] <marcin_ant> jdong: ok I need to test it
[00:47] <jdong> marcin_ant: if you look at the .orig.tar.gz, it's the same 5-different-directory source archive
[00:48] <marcin_ant> jdong: right
[00:48] <jdong> marcin_ant: but when apt-get source runs "dpkg-source -x foo.dsc", it gets unpacked into zope-archetypes-1.4.2/
[00:48] <jdong> marcin_ant: that's what I'm saying -- dpkg-source -x takes care of this discrepancy for you
[00:48] <jdong> it's something that you don't have to worry about
[00:48] <marcin_ant> jdong: what if it;s initial release?
[00:48] <marcin_ant> I need to untar this manually to zope-archetypes-1.4.2?
[00:49] <jdong> marcin_ant: ok so let's say we're dh_making manually because this is the first release
[00:49] <jdong> marcin_ant: remember how we just got over how to manually unpack the tar.gz to the right directory, then run dh_make?
[00:50] <jdong> marcin_ant: well, after you do that *once* , run dh_make, and tweak debian/* to be the way you like it
[00:50] <jdong> then you run debuild -S
[00:50] <jdong> that builds the orig.tar.gz, .diff.gz, and .dsc file in ../
[00:52] <marcin_ant> jdong: ok I (propably) get it ;)
[00:52] <jdong> marcin_ant: alright, cool. hopefully that was a bit helpful :)
[00:52] <jdong> marcin_ant: it takes some time to sink in, and a lot of practice ;-)
[00:53] <marcin_ant> jdong: it's weird and it's NOT described at all in CompleteGuide(!)
[00:53] <jdong> I also might suggest starting off trying your first package with something that goes by the rules a bit better
[00:53] <jdong> marcin_ant: Over my entire course of packaging software for Fedora, Ubuntu, and Gentoo this is about the 3rd time I've seen a tarbomb from upstream
[00:53] <jdong> marcin_ant: it is by far the minority of cases :)
[00:53] <marcin_ant> it's not my first package it's first that has so ugly upstream
[00:54] <jdong> marcin_ant: but I think the key point to take from this is that dpkg-source's extractor and builder has a bunch of magical rules built in that try to intelligently work around these inconsistencies
[00:54] <marcin_ant> jdong: I got bad luck as always ;)
[00:54] <jdong> in general that stuff will work if you trust your tools :)
[00:54] <jdong> otherwise a bit of digging through manpages and script sources might get you a more concrete understanding
[00:54] <jdong> I admit that I'm not in the latter group :)
[00:55] <jdong> I just blindly use my tools and scream loudly here when they don't work!
[00:55] <marcin_ant> jdong: to be honest I really would like just download tar and put it untarred in package and then use tarball.mk from cdbs and it would work without any problem :)
[00:55] <jdong> :)
[00:56] <jdong> holy crap who exploded in my launchpad account?
[00:56] <jdong> I've got 50 new bugmail
[00:56] <marcin_ant> jdong: thank you very much
[00:56] <effie_jayx> Heh
[00:57] <jdong> marcin_ant: you're absolutely welcome :)
[01:02] <StevenHarperUk> Hi, I am submitting a new version of my Package (Easycrypt) I need to update both Hardy and Ibex - do I submit 2 bugs?
[01:09] <Thayle> How can I get involved?
[01:10] <jdong> Thayle: see link in topic
[01:11] <Thayle> Oh, hehe, didn't notice that...
[01:11] <jdong> no probs, let us know if you have any specific questions that doesn't address :)
[01:11] <Thayle> Alright, thanks jdong.
[01:31] <jdong> asac: stupid question: How do you start firefox with a different profile but NOT have it remember that profile the next time you invoke a firefox?
[01:32] <jdong> asac: i.e. I have a "default" and "appliance" profile. How do I make Firefox use profile "default" unless I explicitly start it with the "appliance" profile?
[01:33] <jdong> playing around it seems like FF is pretty good at remember the last profile you told it to use
[01:46] <StevenHarperUk> hi Any MOTUS abot o check https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903
[01:55] <asac> jdong: err not sure ;) -P ?
[01:56] <asac> yeah just -P and then select the profile without "remember" ;)
[01:56] <asac> maybe not the best solution cant really remember that it remembers the last used if you specify it at command line
[01:56] <asac> if it does that then -P is most likely the only workaround
[01:58] <lifeless> asac: hope I have given enough info on  bug 83229
[02:00] <jdong> asac: lol ha like there's a "remember" option ;-)
[02:08] <nhandler> Hi Jazzva
[02:09] <Jazzva> Hello nhandler
[02:58] <nhandler> Is MoM being updated? It only goes up to 'm' right now
[02:58] <lifeless> there was an issue
[03:00] <Keybuk> yes
[03:00] <lifeless> lol
[03:02]  * jdong gives himself stupidity cookie.
[03:02] <jdong>  /usr/bin/skype: "cd /usr/lib/skype && skype"
[03:02] <jdong> 5 minutes and 10 gigs of swap later. D'OH
[03:03] <coppro> huh?
[03:03] <jdong> coppro: think about it.
[03:03]  * coppro is not that familiar with skype...
[03:03] <jdong> coppro: /usr/bin/skype runs "cd /usr/lib/skype && skype"
[03:04] <coppro> oh
[03:04] <coppro> that would be a problem
[03:04] <jdong> :)
[03:04] <coppro> ./ much?
[03:04] <TheMuso> ouch.
[03:04] <jdong> coppro: yeah yeah :P
[03:05] <jdong> coppro: that's revision ~crack2 :P
[03:09] <NCommander> Anyone having any issues uploading to REVU?
[03:09] <coppro> NCommander: I don't think so
[03:09]  * NCommander had one of his uploads rejected
[03:09] <coppro> nope, I'm good
[03:10] <coppro> the update for http://revu.ubuntuwire.com/details.py?package=metakit worked fine
[03:10] <coppro> NCommander: is it set to jaunty? I've had some issues related to that (not with REVU, but other package tools)
[03:10] <NCommander> Yeah
[03:11] <ajmitch> NCommander: you don't deserve to upload yet?
[03:11] <NCommander> ....
[03:11]  * NCommander whacks ajmitch with a stick of DOOM
[03:11] <NCommander> where do the crontab logs end up on spooky?
[03:13] <coppro> spooky?
[03:13] <nhandler> coppro: The server hosting REVU
[03:13] <coppro> oh
[03:58] <NCommander> TheMuso, I have two merges that needs uploading, cegui-mk2, and midori
[03:59] <TheMuso> NCommander: Do you have bugs for them, or do you just have some files I can grab from somewhere?
[03:59] <NCommander> I can kick the changesets onto mentors since REVU is kinda broken ATM
[03:59] <TheMuso> NCommander: Whereever is easiest for you.
[04:01] <NCommander> TheMuso, http://mentors.debian.net/debian/pool/main/m/midori/midori_0.1.0-1ubuntu1.dsc
[04:03] <TheMuso> grabbing.
[04:05] <ajmitch> NCommander: revu ought to work... sort of
[04:05] <NCommander> ajmitch, its been fixed?
[04:05] <NCommander> (or hit with a big enough hammer?)
[04:05] <TheMuso> heh
[04:05] <ajmitch> NCommander: I said that before
[04:05] <ajmitch> mkdir /root/.gnupg to work around it for now
[04:06] <ajmitch> untested with running it from cron, but it should have accepted your upload
[04:07] <ajmitch> the directory just has to exist, it doesn't even need to put anything in there
[04:07] <NCommander> oh good, I can stop using mentors
[04:07] <ajmitch> s/using/abusing/
[04:07] <TheMuso> lol
[04:07] <NCommander> nothing in mentors ToS says it has to be used for Debian review work
[04:07] <NCommander> Or more specifically, nothing outlaws Ubuntu reviewers from using it
[04:08] <ajmitch> I doubt that the admins want the bandwidth & diskspace used for such a purpose
[04:08]  * NCommander notes he uses REVU for Debian package reviewing
[04:08] <NCommander> and mentors for Ubuntu ...
[04:08] <NCommander> Go figure
[04:14] <TheMuso> NCommander: re midori, since it is a merge, you have dropped all prior changelog entries. I.e the only changelog entry you have is the merge entry, and no other entries from previous ubuntu changes.
[04:15] <NCommander> I swore I didn't do that ...
[04:15] <NCommander> Argh
[04:15] <NCommander> TheMuso, hold on
[04:15] <TheMuso> np
[04:17] <NCommander> TheMuso, there
[04:17] <NCommander> Fixed and reuploading
[04:17] <TheMuso> NCommander: Ok.
[04:17] <TheMuso> NCommander: on mentors?
[04:18] <NCommander> no, REVU, since that's working now
[04:18] <TheMuso> oh ok.
[04:18] <TheMuso> not on front page yet.
[04:22]  * ajmitch refreshes & hopes that it shows up
[04:22] <ajmitch> hm..
[04:23] <ajmitch> the directory exists
[04:23] <NCommander> ajmitch, its working
[04:24] <ajmitch> I just didn't see it on the revu frontpage
[04:24] <NCommander> ajmitch, its in updated packages
[04:24] <NCommander> (since its not new)
[04:25] <ajmitch> good
[04:28] <TheMuso> NCommander: test building midori.
[04:30] <TheMuso> NCommander: uploaded.
[04:31] <NCommander> yay for my first jaunty upload
[04:31] <TheMuso> NCommander: And your second merge? Is that ready for review/upload?
[04:31] <NCommander> yup
[04:31]  * ajmitch needs to find something to merge
[04:31] <TheMuso> ok
[04:31] <NCommander> ajmitch, MoM
[04:31] <ajmitch> NCommander: MoM doesn't have its main/universe lists generated at the moment, either
[04:31] <NCommander> ajmitch, yes it does
[04:32] <ajmitch> so it's digging through package directories
[04:32] <ajmitch> http://merges.ubuntu.com/ <-- do you see universe.html there?
[04:32] <NCommander> Oh
[04:32] <NCommander> Hrm
[04:32] <NCommander> Where'd it go
[04:32] <NCommander> It was there less than an hour ago
[04:32] <ajmitch> ran off with DaD
[04:32] <TheMuso> I see it not on revu...
[04:33] <TheMuso> NCommander: cegui-mk2 doesn't seem to be on revu.
[04:33] <NCommander> yeah
[04:33] <NCommander> Odd
[04:33] <NCommander> Oh
[04:33] <NCommander> bah
[04:33] <NCommander> its on its way
[04:34] <TheMuso> ok.
[04:42] <NCommander> Upload complete
[04:42] <TheMuso> ok.
[04:42] <NCommander> ajmitch, run move_uploads.sh for me
[04:42]  * jdong starts debdiffing marillat
[04:45] <TheMuso> Grabbing.
[04:52] <ScottK> StevenK: Would you be around and able to do a sync for me to fix a security bug?
[04:53] <StevenK> ScottK: Possibly
[04:54] <ScottK> StevenK: Would you be up for syncing libspf2 out of incoming.  The Debian Maintainer nicely left the LP reference in debian/changelog and everything.
[04:55] <TheMuso> 8/c
[04:56] <StevenK> ScottK: Version in Intrepid/Jaunty is -0ubuntu1. Do you have a sync bug? :-)
[04:57] <ScottK> I'm writing it as we speak.
[04:58] <ScottK> StevenK: Bug #293956
[04:59] <StevenK> Is it unstable, or incoming?
[04:59] <ScottK> Incoming
[04:59] <ScottK> It's aimed at Unstable.
[05:00] <ScottK> StevenK: ^^
[05:02] <fabrice_sp> Hi all.Can we already request syncs for Jaunty? I've just updated Bug #275534.
[05:04] <ScottK> fabrice_sp: You can, but you shouldn't mark it confirmed unless you are MOTU and have confirmed it is ready.
[05:05] <fabrice_sp> ScottK: ok. So I'll let him as NEW. Thanks.
[05:05] <StevenK> ScottK: Synced
[05:06] <ScottK> StevenK: Thanks.
[05:06]  * StevenK adds one to the beer tally
[05:06] <ScottK> Interestingly enough he nicely said "merge changes from Ubuntu" and left the Ubuntu changelog entries in.
[05:06] <ScottK> That's more generous than I usually see.
[05:07] <NCommander> ScottK, most debian developers like to forget we exist
[05:07]  * ScottK is still not going to UDS, so keep the list in a safe palce.
[05:08] <ScottK> wgrant: I thought you might enjoy Bug 293950
[05:10] <wgrant> ScottK: Its presence in Lenny or Sid is unrelated to Ubuntu.
[05:10] <wgrant> But yes, it's still wrong.
[05:10] <ScottK> wgrant: True.  Feel free to pile on.
[05:11] <wgrant> It might just be because gina was run over Lenny first,.
[05:11] <wgrant> So it should be fine for future packages.
[05:11] <ScottK> wgrant: The why isn't my problem.
[05:11] <ScottK> I'll be able to tell once auto-sync runs.
[05:12] <wgrant> I'm not sure if the autosync is going to be using NSS yet, so that might well be irrelevant.
[05:13] <StevenK> NSS?
[05:14] <StevenK> Which would the autosyncer using Name Service Switch?
[05:14] <wgrant> Native source syncing
[05:14] <StevenK> Oh
[05:15] <TheMuso> NCommander: cegui-mk2 uploaded.
[05:15] <NCommander> \p/
[05:15] <NCommander> uh
[05:15] <NCommander> \o/
[05:17]  * StevenK is trying to understand native source syncing
[05:18] <lifeless> why would it be differnet
[05:18] <lifeless> just don't copy a base tarball
[05:18] <lifeless> or rather, only copy
[05:20] <NCommander> StevenK, new LP interface/CLI?
[05:21] <StevenK> NCommander: Huh?
[05:22] <NCommander> StevenK, I take it some sorta new launchpad interface for doing native source syncing?
[05:22] <StevenK> NCommander: I have no idea
[05:23] <NCommander> Is it active yet?
[05:23] <StevenK> NCommander: I don't know anything about it myself
[05:23] <NCommander> Ah
[05:24] <persia> https://blueprints.launchpad.net/soyuz/+spec/native-source-syncing
[05:30] <ScottK> persia: As is usual for a LP spec the useful information isn't available "You are not allowed to view this page."
[05:31] <persia> ScottK, Certainly, although it helps make it clear that "native" is about native-to-Soyuz, rather than being about native packages.
[05:32] <ScottK> persia: Perhaps for you.  From the small crumbs the customers are allowed to see it's not clear how that relates to syncing at all to me.
[05:33] <persia> Huh?  I don't see anything different than you.
[05:33] <NCommander> https://dev.launchpad.net/ - it will be here soon enough
[05:33] <ScottK> persia: Yes, but it sounds like you (or someone) is making a connection that I'm not understanding.
[05:34] <ScottK> NCommander: It's already past the promised date for it.
[05:34] <ajmitch> NCommander: sorry, I was out, hopefully revu did the right thing for you
[05:35] <persia> ScottK, Oh.  That's me.  As I read it, it's about having some shiny button that lets one sync sources directly, rather than having someone run the syncpackage script.
[05:35] <NCommander> ScottK, ?
[05:36] <persia> Should address the Hobbsee-can't-sync issue.
[05:37] <ScottK> OK.  I don't see that in the snipper, but we'll see someday I guess.
[05:39] <persia> Well, I could be mistaken, but as I understand it, the archive-admins just run a script to work around it missing in Soyuz now, and "natively" means to me "inside Soyuz".
[05:39] <persia> (at least in the context of a Soyuz spec)
[05:41] <ScottK> Right and I read it as mashing stuff from one Ubuntu pocket to another.  No idea if that's at all right.
[05:47] <persia> Ah.  The difference being that I've also looked at the summaries for https://blueprints.launchpad.net/soyuz/+spec/sync-workflows and have seen glimpses of an apparent Debian archive import on staging in the past.
[05:58] <Hobbsee> hmm?
[06:01] <persia> Hobbsee, native-source-syncing possibly meaning you get a button to perform syncs (as I believe that's one of the archive-admin tasks that doesn't work for you).
[06:07] <Hobbsee> oh, that would be nice!
[06:07] <Hobbsee> any ETA, or?
[06:07] <Hobbsee> just that they're planning it?
[06:08] <superm1> i hope the button is shiny.  shiny buttons are always more exciting
[06:08] <persia> No.  The spec just came up in conversation, and the spec is private, so I was guessing as to the effect.
[06:10] <Hobbsee> hmm.  That looks old to me.
[06:10] <persia> Rather old.  Yes.  Still desired by many.
[06:11] <Hobbsee> that's irrelevant, surely :P
[06:11] <Hobbsee> a whole lot of them are sitting with 1.2.x milestones, which, afaik, has long passed, so it certainly doesn't look anywhere near current.
[06:12] <Hobbsee> Threrefore, no point at all getting excited.
[06:12] <wgrant> Hobbsee: NSS is being implemented. That's why we have Debian imported into LP now.
[06:13] <Hobbsee> wgrant: yes, that one is.  That affects a lot more people.
[06:13] <Hobbsee> wgrant: doesn't necessarily mean that anything's happening on related bits.
[06:13] <wgrant> Perhaps.
[06:13] <persia> Hrm?  Doesn't NSS mean a shiny button for archive-admins?  A shiny button for the rest of us would be nice, but I thought that was sync-workflows
[06:14] <Hobbsee> persia: via command line, yes.
[06:14] <wgrant> It makes the shiny button possible to implement.
[06:14] <ScottK> wgrant: What is NSS.
[06:14] <wgrant> ScottK: Native Source Syncing.
[06:15] <ScottK> wgrant: I know what the acronym is.  I don't know what that translates to in the system.
[06:15] <wgrant> ScottK: copy-package.py, but for Debian packages too, basically.
[06:16] <wgrant> So copying the package within Soyuz.
[06:16] <Hobbsee> ScottK: means you can do stuff like copy packages from -proposed to -updates and such, too.
[06:16] <wgrant> Rather than downloading it from Debian and falsifying a changes file.
[06:16] <Hobbsee> or from ppa directly to ubuntu, etc.
[06:16] <wgrant> Right, pocket copies are part of it.
[06:16] <ScottK> Hobbsee: I got that, I'm just having trouble with how it affects syncing.
[06:16] <NCommander> can you copy from backports->updates?
[06:16] <ScottK> NCommander: Yes.
[06:17] <NCommander> oh good
[06:17] <wgrant> ScottK: Since they now run gina over sid and lenny, they can use copy-package.py on it just like they can PPAs or other pockets.
[06:17] <ScottK> That's been possible for some time.
[06:17] <NCommander> That will make it easy to do an SRU of Xfce 4.4.3 <g>
[06:17] <ScottK> NCommander: Look at KDE 3.5.10
[06:17] <NCommander> That was released to SUR?
[06:17] <NCommander> *SRU?
[06:18] <ScottK> Yep.  It's in -updates now.
[06:29] <krishna> ﻿I was trying to build gnome-games from source.. I have built most of the dependencies.. but still i get this error.. http://paste.ubuntu.com/67751/  can someone have a look at it?
[06:31] <persia> krishna, Are you working from upstream sources or Ubuntu sources?
[06:33] <krishna> persia: upstrean
[06:33] <krishna> *upstream
[06:34] <krishna> persia: but how does it really matter?
[06:34] <persia> OK.  Take a look at what gets done before running ./configure in the gnome-games debian/rules from the Ubuntu sources.  It looks to me like you're missing some preparation steps.
[07:45] <iulian> nhandler: ping (Wanted to know if you're working on checkinstall merge. I already merged it and all I have to do now is to file a bug).
[07:46] <StevenK> Argh. No fair merging checkinstall
[07:48] <iulian> Hmm
[07:48]  * iulian wonders why
[07:49] <Hobbsee> unless 'merge' == 'remove'
[07:55] <NCommander> checkinstall is packaged?
[07:55] <NCommander> ew
[07:55]  * NCommander agrees w/ Hobbsee 
[07:55] <Hobbsee> yes,it is
[07:56] <StevenK> checkinstall was one of the first packages I fixed.
[07:56] <StevenK> Hobbsee thanked me by thwaping me
[07:56] <Hobbsee> he deserved it.
[07:57]  * StevenK ponders a removal/blacklist
[07:58] <Hobbsee> that'd be nice
[07:58] <Hobbsee> oh, there must be a release goal for killing yada from the archive, too.
[07:58] <persia> You know, as much as I dislike checkinstall, and somewhat regret being in the changelog, it's probably better to fix it's egregious issues than to ban it, and have people use random buggy versions.
[07:59] <Hobbsee> well, ifthey use random buggy versions, then we don't have to support it.  same deal as automatix, etc.
[07:59] <StevenK> Still 23 things Build-Depend on it
[08:00]  * wgrant stabs Hobbsee dead.
[08:00] <persia> Hobbsee, We don't support checkinstall-created packages now, but we do support checkinstall.
[08:00]  * Hobbsee dies bloodily all over wgrant, and carefully rebuilds him with yada before duying.
[08:00] <persia> There is no careful rebuilding with yada!
[08:00] <Hobbsee> persia: yes, and i'm objecting to the supporting of checkinstall :P
[08:00] <wgrant> I had to SRU a package that used yada once... that hurt.
[08:01] <persia> Hobbsee, I guess.  You know, it could be improved...
[08:01] <persia> It's horrid mostly because it's incomplete, rather than being purely a bad idea.
[08:02] <Hobbsee> i was thinking more based on how people used it,but yes
[08:02] <siretart> uh, archive already open? that was quicker than I expected...
[08:02] <StevenK> siretart: It's a lie
[08:02] <persia> siretart, Indeed.  Opened a few hours ago.
[08:02] <Hobbsee> it's still a lie.  just like the cake.
[08:02] <Hobbsee> and the ponies.
[08:02]  * persia misses the ponies
[08:02] <siretart> ah. so I have a few more days finishing the ffmpeg package :-)
[08:02]  * NCommander reads from the book of the dead and revives Hobbsee 
[08:03] <wgrant> siretart: It would have been earlier if it weren't for some surprise bootstrappings.
[08:03] <Hobbsee> oh, thanks
[08:04] <NCommander> siretart, someone decided to care about ports!
[08:08] <siretart> wow. who did that?
[08:08] <siretart> err. who does care?
[08:08] <Hobbsee> siretart: the insane one.
[08:08] <siretart> elmo?
[08:08] <siretart> ;)
[08:21] <framstag> hi there, the guys from #ubuntu-server told me this is the correct channel for my question:
[08:21] <framstag> I want to add a new server application to ubuntu - where should I start?
[08:22] <persia> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[08:22] <framstag> I am using ubuntu for several years, but only as consument, not as a developper or maintainer
[08:25] <framstag> great, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages is exacrly what I was looking for!
[08:26] <framstag> a meta-question: how difficult is it as non-motu-member to file in a new package?
[08:26] <framstag> in respect to social acceptance of a "newbie" :-)
[08:28] <framstag> I want to avoid of hearing: "we don't know you. go away and earn some recognitions"
[08:29] <NCommander> framstag, generally it is
[08:30] <NCommander> framstag, normally because getting something packaged is a rather large piece of work
[08:30] <NCommander> Once you do a few uploads with people to fix bugs and such, people are usually more receptive to packaging things
[08:34] <framstag> ok, then is this approach better (more successfull): I ask a motu-member to package my software?
[08:35] <framstag> I then only have to convince one thar my software is import enough :-)
[08:37] <framstag> or is there already a huge queue of packinging requests?
[11:41] <verwilst> emgent: ping
[12:16] <StevenHarperUK> hi, are any motus about to check https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903
[12:48] <RainCT> hi
[12:48] <RainCT> porthose: it's all yours
[12:50] <porthose> RainCT:  thx
[13:23] <RainCT> vorian: if you're planning to do the ncpfs merge: the package is maintained by the Debian QA Group now, so try to get any remaining changes directly into Debian
[13:27] <RainCT> vorian: and I forgot the actual question, are you planning to do the merge? :)
[13:32] <nxvl> \o/ jaunty is open!
[13:36] <lfaraone> How exactly does one use MoM?
[13:36] <emgent> go.
[13:37] <lfaraone> emgent: ?
[13:37] <nxvl> emgent: exactly!
[13:43] <stefanlsd> We filing bugs like normal for merges?
[13:45] <nxvl> yep
[13:45] <nxvl> title: Please merge $PACKAGE $VERSION from debian unstable
[13:46] <stefanlsd> nxvl: thanks :)
[13:46] <nxvl> Report: Debian has a new version of $PACKAGE that needs to be merged
[13:46] <nxvl> and attach the debdiff
[13:46] <nxvl> that's pretty much it
[13:50] <ScottK> jdong: I can't set importance on intrepid-backports bugs (just like Hardy started out).
[13:55] <sebner> stefanlsd: and subscribe u-u-s ;) (if it's in universe)
[13:56] <nxvl> james_w: around?
[13:56] <nxvl> sebner: right
[13:56] <nxvl> sebner: are you merging ssmtp or should i?
[13:57] <nxvl> i think i a sync is needed
[13:57] <sebner> nxvl: didn't even know that there is something new :) If you like it you can do it. otherwise I'll do it in the evening
[13:58] <nxvl> sebner: ok, i will take care of it
[13:58] <sebner> nxvl: thank you
[13:58] <nxvl> sebner: indeed it is, you took your patch from debian
[13:58] <nxvl> :P
[13:58] <sebner> nxvl: /me doesn't have a jaunty pbuilder yet ... :P
[13:59] <soren> sebner: Dude, it's been almost 24 hours! :)
[14:00] <lfaraone> Anybody care to explain how a non-motu requests a merge?
[14:00] <sebner> soren: I know, sry :P I didn't have time, I also have to upgrade to jaunty. don't forget that :P
[14:00] <nxvl> lfaraone: file a bug, attach you debdiff and subscribe u-u-s
[14:00] <sebner> nxvl: but in the evening I also need some security power (if you are interested)
[14:00] <nxvl> heh
[14:01] <james_w> nxvl: hey hey!
[14:01] <jdong> ScottK: should be fixed now
[14:01] <soren> sebner: :)
[14:01] <sebner> bbl :)
[14:02] <james_w> lfaraone: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[14:02] <sebner> soren: btw, tell colin, upgrading is *cool*. also that lenny is frozen not that much can break :P
[14:02] <ScottK> jdong: Yep.  Thanks.
[14:03] <soren> sebner: Tell him yourself :)
[14:03]  * sebner hides
[14:08] <nxvl> james_w: now that jaunty is open, are there already any plans on how to do the bzr transition?
[14:08] <nxvl> (as in move everything to bzr)
[14:08]  * geser searches after sebner :)
[14:08] <james_w> nxvl: lots of plans :-)
[14:08] <nxvl> james_w: :D as in starting now?
[14:09] <james_w> nxvl: I have most of the branches ready, we will hopefully be opening them up for testers soon
[14:09] <nxvl> james_w: or we will wait a bit?
[14:09] <nxvl> james_w: ok, count on me
[14:09] <lfaraone> james_w, nxvl , thanks!
[14:09] <james_w> nxvl: launchpad isn't quite ready to host them yet, so they won't be as useful, but we're getting there
[14:09] <james_w> nxvl: and you can't merge from Debian natively in bzr yet, which means it doesn't help this period that much
[14:09] <lfaraone> james_w: this is going to be a very interesting cycle. (with the bzr features yet)
[14:10] <james_w> nxvl: but I look forward to your feedback
[14:10] <james_w> lfaraone: I agree
[14:11] <nxvl> james_w: ok, then when i can put my hands on it please let me know
[14:11] <nxvl> james_w: we can discuss it widely next week with some beers and pisco!
[14:11] <nxvl> :P
[14:11] <james_w> nxvl: I look forward to it :-)
[14:14] <stefanlsd> does anyone have an idea why debian is doing this - http://paste.ubuntu.com/67910/
[14:15] <stefanlsd> its in the .pot file
[14:16] <broonie> stefanlsd: if there's no textual difference I'd expect the .pot file has been edited with a tool that did the reformatting.
[14:16] <StevenHarperUK> hi, are any motus about to check https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903
[14:17] <stefanlsd> broonie: yeah. would appear so.  Should i just delete them from the debdiff, or should we actually just fall in line with what they did so we dont need to keep doing it manually?
[14:18]  * broonie shrugs
[14:18] <nxvl> \o/ i think i'm done with all my packages
[14:18] <nxvl> this is fun
[14:20] <lfaraone> Won't debian devel be slow since they'd be working on perfecting lenny?
[14:23] <verwilst> if i have a deb in my ppa
[14:23] <verwilst> well, ready to be sent to my ppa
[14:23] <verwilst> but i want to build it for hardy and intrepid
[14:23] <verwilst> what do i need to do?
[14:24] <verwilst> make 2 seperate changelogs?
[14:24] <verwilst> one with a hardy entry and one with an intrepid one?
[14:24] <directhex> verwilst, yes
[14:24] <verwilst> strange but ok ;)
[14:25] <ScottK> StevenHarperUK: Unless that's a typo on the bug title, you'll want a 1 on the end of the revision number.
[14:25] <ScottK> stefanlsd: Delete them from the debdiff.
[14:25] <stefanlsd> ScottK: yeah thanks. ended up doing that.
[14:25] <ScottK> verwilst: #launchpad is a more appropriate place for PPA questions.
[14:26] <StevenHarperUK> ScottK: your right - its just a typo - fixing it now
[14:26] <StevenHarperUK> Scottk: another Q I have put ibex in my debian changelog - is that wrong?
[14:27] <ScottK> StevenHarperUK: jaunty
[14:27] <StevenHarperUK> Scottk: its for Hardy -> jaunty
[14:27] <azeem> can maybe somebody quickly install "avogadro" on intrepid and see whether it crashes on startup? (it's a QT4 app)
[14:28] <ScottK> StevenHarperUK: If it's for an upload now, it should say jaunty for the target release.
[14:29] <verwilst> ScottK: ok!
[14:29] <StevenHarperUK> Scottk: i want users og hardy to get it
[14:29] <StevenHarperUK> *of
[14:29] <ScottK> StevenHarperUK: First get it into jaunty and then get it backported.
[14:29] <ScottK> !backports | StevenHarperUK
[14:30] <StevenHarperUK> ScottK: is that a simple job?
[14:30] <ScottK> Generally.
[14:32] <StevenHarperUK> ScottK: I am targetting 2 major bugs in hardy and intrepid, is the correct route the backport one?
[14:32] <directhex> what's the best way to track changes in build-dep names, for backportability?
[14:32] <directhex> use libfoo-dev | libfooold-dev ?
[14:32] <ScottK> StevenHarperUK: If you're fixing major bugs then perhaps not.
[14:33] <james_w> directhex: that would work
[14:33] <directhex> james_w, any better ideas?
[14:33] <ScottK> StevenHarperUK: See https://wiki.ubuntu.com/StableReleaseUpdates
[14:33] <StevenHarperUK> ScottK: ok so I set to hardy - if I do will it get to intrepid also?
[14:33] <james_w> directhex: though a change in -dev name usually indicates a change in API, is that not the case there?
[14:33] <ScottK> StevenHarperUK: No.  You need to provide a debdiff with appropriate naming and numbering for each release.
[14:33] <directhex> james_w, no. or if it is, not enough to prevent building.
[14:34] <StevenHarperUK> Scottk: sounds like a lot of effort
[14:35] <directhex> cups (1.3.7-6) unstable; urgency=low
[14:35] <directhex>   * Rename the package to cups.
[14:35] <ScottK> StevenHarperUK: It can be, but we need to be careful with changes to released versions.
[14:35] <james_w> directhex: what would be the problem with the alternatives approach?
[14:36] <directhex> james_w, just want to make sure to do the right thing. libcupsys2-dev -> libcups2-dev is a build-dep change to worry about between releases
[14:37] <StevenHarperUK> ScottK: can I confirm - hardy (easycrypt_0.2.3.0-0ubuntu1) intrepid (easycrypt_0.2.3.1-0ubuntu1) jaunty (easycrypt_0.2.3.2-0ubuntu1)
[14:37] <james_w> directhex: yeah, I just wondered why you asked if there were any better ideas. I don't see a problem with using "|"
[14:37] <ScottK> StevenHarperUK: For Hardy/Intrepid we don't ship a new upstream release.  We patch the existing one.
[14:37]  * ScottK goes AFK for a while.
[14:38] <StevenHarperUK> ScottK: so I make the Jaunty one (easycrypt_0.2.3.0-0ubuntu1) and it gets patch for me?
[14:40] <james_w> StevenHarperUK: easycrypt is at 0.2.2.10-0ubuntu1 in hardy/intrepid/jaunty
[14:40] <james_w> for jaunty upload your 0.2.3.0-0ubuntu1
[14:41] <StevenHarperUK> ok I will and il diff it against the 0.2.10
[14:41] <james_w> for hardy create a patch to fix the bug and apply it to the existing hardy package, changing the version number to 0.2.2.10-0ubuntu1.08.04.1 or similar
[14:41] <james_w> similar for Intrepid, with 0.2.2.10-0ubuntu1.08.10.1
[14:42] <james_w> StevenHarperUK: https://wiki.ubuntu.com/SecurityUpdateProcedures has a guide to choosing a version number for a particular release
[14:42] <james_w> the last line of that table is your case
[14:42] <StevenHarperUK> james_w: I have never done a patch before as I am upstream I do a full release
[14:43] <james_w> StevenHarperUK: ok that's probably ok as long as the release just fixes major bugs, you may want to check with someone from motu-sru
[14:44] <StevenHarperUK> james_w: do I make 3 seperate bugs in launchpad too?
[14:44] <james_w> nope
[14:45] <james_w> just nominate the bug for the affected releases
[14:54] <jcastro> persia: ~6 minutes!
[15:44] <slytherin> NCommander: there?
[15:50] <StevenHarperUK> james_w: hi you still here?
[15:51] <james_w> StevenHarperUK: yep
[15:52] <StevenHarperUK> james_w: I have done the jaunty one : https://bugs.edge.launchpad.net/ubuntu/+source/easycrypt/+bug/293903
[15:52] <StevenHarperUK> james_w: what should I do for the others?
[15:53] <StevenHarperUK> james_w: just some deb-diffs?
[15:54] <james_w> for the jaunty one please provide the .diff.gz from the source package you created, along with a pointer to the tarball that you released
[15:55] <StevenHarperUK> james_w pointer is there
[15:55] <james_w> the .diff.gz isn't
[15:56] <StevenHarperUK> james_w: is that ok now
[15:57] <james_w> looks better, I haven't reviewed it
[15:58] <StevenHarperUK> james_w: now the other releases - do I need to make anything?
[15:58] <StevenHarperUK> james_w: there the same, its just the changelog that needs to be right
[15:59] <james_w> yes, something needs to be different
[15:59] <james_w> at least the changelog
[15:59] <StevenHarperUK> james_w: do I have to make more and compare them to the 2.2.10 ?
[15:59] <james_w> compare them?
[16:00] <StevenHarperUK> james_w: create the diffs + interdiffs?
[16:00] <james_w> yeah
[16:00] <james_w> interdiffs aren't needed I don't think
[16:01] <james_w> but you need to build source packages for each release and provide the .diff.gz for them
[16:01] <soren> geser: Bored? There's an iptables merge with your name on it :)
[16:01] <StevenHarperUK> james_w: ok back in a few mins :)
[16:02] <sebner> persia: nice session :) btw, /me hasn't seen norsetto for a while now, you?
[16:05] <persia> sebner, Thanks, and not recently.
[16:05] <sebner> kk
[16:07]  * DktrKranz kidnapped norsetto.. but please don't spread word
[16:07] <sebner> lol
[16:10] <geser> soren: on the contrary, too much work is waiting for me. But I will try to get the merge done, so the changes don't get lost again.
[16:10] <soren> geser: No worries. I might do it myself if I can work up the motivation.
[16:12] <karooga> hi, I'm trying to do a new package of someone else's tar.gz.  In the past they have been responsive but now, not so responsive.  What options do I have if I am to make fixes (and rebundle that package) - do I use LP to host the code?
[16:14] <Laney> soren: I can take a look. Is there anything special about it?
[16:14] <geser> soren: perlipq FTBFS on AMD64 without a libipq.a build with -fPIC
[16:14] <nxvl> NCommander: around?
[16:15] <soren> Laney: It's not straightforward, but certainly not rocket science either.
[16:15] <sebner> nxvl: you already updated ssmtp. cool! /me has to update his pbuilder, become a MOTU ASAP you will steal all my syncs and merges :P
[16:15] <persia> karooga, I'd recommend just patching in the packaging initially.  If upstream remains unresponsive for a protracted period, or there is another reason to fork, you might do it, in which case it doesn't matter whether you use LP, sourceforge, google code, savannah, etc. : that's up to you.
[16:16] <soren> Laney: The only thing I didn't manage to do in a snap was geser's PIC libraries.
[16:16] <nxvl> sebner: i asked you and you said that was ok
[16:16] <nxvl> :P
[16:16] <sebner> nxvl: but you are speed :P
[16:16] <sebner> + on
[16:16] <nxvl> :D
[16:17] <nxvl> merges are easy
[16:17] <nxvl> MoM does almost all for you
[16:17] <nxvl> just a little QA is needed
[16:17] <karooga> persia:  thanks.  Define protracted period?  (1 week?) :-)
[16:17] <persia> At least a few months.  Maybe a year?
[16:17] <sebner> nxvl: pssssssstt. MoM is evil. watch out or persia slaps you :P
[16:17] <Laney> soren: Will look tomorrow
[16:18] <persia> karooga, Essentially, if you fork it, you're the new upstream, and unless the entire community surrounding the project joins you, it's just going to be unpleasant.
[16:18] <soren> Laney: Coolness.
[16:18] <geser> soren: without a libipq_pic.a this happens when one tries to build perlipq: http://buildd.debian.org/fetch.cgi?pkg=perlipq;ver=1.25-1.1;arch=amd64;stamp=1215631228
[16:18] <nxvl> sebner: MoM is cool
[16:18] <bobbo> james_w: ping
[16:18] <persia> sebner, MoM isn't evil, it's just not human-equivalent automation.  Blindly using MoM tends to get people in trouble, but some people find some parts of it useful.
[16:18] <sebner> nxvl: if it get's the commenting function like DaD has ... :P
[16:19] <james_w> hey bobbo
[16:19] <sebner> persia: hehe, I know. it was just a joke :)
[16:19] <nxvl> sebner: yeah, it actually has a hack already, but Keybuk still haven't look at it and include it
[16:19] <Laney> Why hasn't Debian adopted the PIC change?
[16:20] <bobbo> james_w: you requested some sponsoring request spam, so Bug #294200 ;)
[16:20] <sebner> nxvl: kk =)
[16:20] <karooga> persia: yeah, I don't think forking is necessary, it's really just minor fixes.  I'm just being over eager and impatient... Thanks.
[16:21] <sebner> persia: though, again bad boys used it. See http://thc.emanuele-gentili.com/utu/utu_jaunty.php  rank 21 :\
[16:21] <james_w> bobbo: has the diff been forwarded?
[16:22] <bobbo> james_w: writing the email as we speak :)
[16:22] <james_w> bobbo: cool
[16:22] <james_w> bobbo: if the Debian bug numbers are in the changelog then you don't make me ask :-)
[16:23] <persia> sebner, Indeed.  You'd be doing a service to figure out who, and reply to the -changes email to -motu discussing why it's important to check.
[16:23] <bobbo> james_w: ah, I didnt know we were supposed to put Debian bug number in changelogs, never seen that before :S
[16:24] <james_w> bobbo: some do, some don't. I advocate it.
[16:24] <james_w> bobbo: mentioning the fact in the bug report would be ok too
[16:24] <geser> Laney: I guess it wasn't forwarded to Debian yet (there is a won't fix bug for PIC version of libiptc only)
[16:24] <Laney> geser: Right, I'll do that too then
[16:25] <sebner> persia: If I have time I'll try
[16:29] <james_w> bobbo: sorry, to disappoint you, but you Intrepid has been released :-)
[16:29] <james_w> bobbo: and no need to mention the maintainer change.
[16:29] <james_w> bobbo: if you could fish out bug numbers for the Ubuntu changes from earlier in the changelog and add them back that would be good as well.
[16:30] <james_w> bobbo: I think it's helpful to have rationale/bugs in the recent entry, rather than having to search for the original place the change was made.
[16:30] <bobbo> james_w: ok thanks! Now I have a debian bug number should I put that into the changelog?
[16:31] <james_w> bobbo: up to you
[16:31] <james_w> I'd like to see it, but where you put it is your choice
[16:31] <bobbo> james_w: ok :)
[16:31] <james_w> sistpoty sent a mail to the mailing list today suggesting that they go in the changelog
[16:35] <StevenHarperUK> james_w: the source tar is teh same for the revisions its just the diff tahts needed
[16:35] <james_w> indeed
[16:35] <StevenHarperUK> james_w: ta
[16:41] <bobbo> james_w: http://pastebin.ubuntu.com/67974/plain/ . Fixed maintainer field, distribution, added Debian bug number. Couldnt add rationales/bug numbers for previous changes because none were given anywhere in the changelog.
[16:42] <james_w> ouch
[16:42] <james_w> thanks
[16:42] <james_w> I'll finish reviewing and upload in a little while
[16:43] <bobbo> james_w: thanks :)
[16:43] <StevenHarperUK> james_w: is that ok now (easycrypt one)
[16:45] <james_w> StevenHarperUK: you should have .1 at the end of the version numbers for Hardy and Intrepid
[16:45] <gouki> What happens when a software is not using any license, and the author doesn't reply when you ask for it's work to be licensed?
[16:45] <lucas> gouki: you lose
[16:45] <StevenHarperUK> james_w: where at the end? or the end of teh version can you give example pls
[16:46] <StevenHarperUK> 08.04.1?
[16:46] <james_w> StevenHarperUK: I gave you a wiki page with examples
[16:46] <gouki> lucas, really? Just like that? Ohh well, was worth a try :)
[16:47] <StevenHarperUK> james_w: right ill fix em
[16:48] <nxvl> gouki: yup
[16:48] <nxvl> gouki: it's merging time
[16:48] <nxvl> the jackalope season is open
[16:50] <nxvl> gouki: go to merge.ubuntu.com
[16:50] <nxvl> and find some package of your interest
[16:51] <nxvl> gouki: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[16:52] <gouki> nxvl, OK
[16:54] <StevenHarperUK> james_w: ok do they look correct now please (thanks again for persisting)
[16:54] <Yasumoto> nxvl: I was about to ask that question, thanks :)
[16:55] <james_w> StevenHarperUK: yeah, I'd have to review diffs to be able to say more though
[16:56] <nxvl> Yasumoto: :D
[16:56] <StevenHarperUK> james_w: thanks
[16:58] <james_w> does anybody want to organise a Debian RC bugs day?
[17:00] <nxvl> james_w: o/
[17:01] <james_w> nxvl: wicked
[17:02] <james_w> I don't have a day off for a couple of weeks, and they might have all gone by then
[17:02] <nxvl> james_w: sunday!
[17:03] <nxvl> james_w: i will head the hotel at noon or early afernoon
[17:03] <james_w> nxvl: that's an idea
[17:20] <bobbo> james_w: fancy some more sponsoring request spam? Bug #294232 :P
[17:23] <james_w> bobbo: I'll take that one, but I don't have much time this week.
[17:23] <bobbo> james_w: ok, all sponsoring is appreciated greatly :D
[17:23] <james_w> also it's better if you come to me with things that are more complicated than what looks to be a straightforward merge, that will show of your skills more
[17:59] <RainCT> argh, why doesn't any of the @lists.ubuntu.com lists set a proper Reply-to header? :/
[18:04] <ScottK> nxvl: Are you using -v when you build your merge packages so the debian/changelog entries of the debian updates you're merging end up in .changes?
[18:05] <ScottK> RainCT: Get a proper MUA with "Reply to list" and you'll be fine.
[18:05] <nxvl> ScottK: huh?
[18:05] <nxvl> oh
[18:05] <nxvl> ScottK: my fault
[18:05] <ScottK> nxvl: I noticed it on courier and ssmtp ...
[18:06] <ScottK> nxvl: Not a big deal.  We've all done it.
[18:06] <nxvl> :D
[18:06] <ScottK> Just wanted to make sure it didn't become a habit.
[18:06] <nxvl> :D
[18:06] <nxvl> i haven't do merges in a while
[18:07] <ScottK> Yep.  No one has.
[18:08] <sebner> RainCT created such a nice "MOTU beginner's page". I hope it's also mentioned there :P
[18:21] <slytherin> Can anyone please tell me if having word 'exec' before a command in the shell script is one of the bashisms?
[18:24] <geser> check "man dash" and also the check-bashism script
[18:32] <slytherin> geser: thanks, exec is valid in dash. Also checkbashisms does not complain about the script.
[18:58] <RainCT> sebner: :)
[19:02] <NCommander> Cool, I got my final MOTU +1
[19:03] <sebner> NCommander: CONGRATULATIONS! :D
[19:03]  * pochu congrats NCommander 
[19:03] <sebner> pochu: hihihi, first one. :P
[19:03] <RainCT> NCommander: gratz!
[19:03] <NCommander> Now only if I was a member of ~motu
[19:03] <laga> neat
[19:03]  * NCommander is shot repeatively
[19:03] <laga> congrats :)
[19:03] <pochu> sebner: I cut my hair last week ;)
[19:03] <sebner> pochu: dito =)
[19:03] <pochu> sebner: did you take pictures before and after? :)
[19:04] <sebner> pochu: nope :P but I'm keen to see yours :P
[19:04] <sebner> NCommander: yeah! know you are the official MOTU FTBFS guy! aweasome =)
[19:04] <NCommander> I'm not an MOTU yet
[19:05] <NCommander> Still need to wait for someone to add me to the gorup
[19:05] <james_w> does uehs exclusively show packages that are in Ubuntu but not Debian?
[19:05] <sebner> NCommander: well, but you are a MOTU now. doesn't matter if you are in the group or just in 10 minutes
[19:06] <NCommander> \o/
[19:06] <RainCT> james_w: afaik, it shows packages which are unmaintained (either not in Debian or owned by the Debian QA Group)
[19:07] <james_w> RainCT: ah, thanks
[19:09] <NCommander> jdong, ping
[19:11]  * NCommander looks at the build backlog
[19:11] <NCommander> Wow
[19:20] <ScottK> NCommander: That's pretty usual on the first autosync run.
[19:20]  * NCommander nods
[19:20] <NCommander> ScottK, I just didn't realize how many packages get uploaded to Debian in six months
[19:21] <ScottK> This one's actually kind of light due to the freeze.
[19:21] <ScottK> I does give you an idea of how much we leverage Debian.
[19:21] <ScottK> I've never seen "Building private build"
[19:21] <ScottK> I guess that's because they're doing security is Soyuz now.
[19:22] <NCommander> ScottK, I've seen it on occansion
[19:23] <kees> ScottK: yeah, that's the SiS stuff.
[19:24]  * ScottK hopes he knows what one of those is.
[19:26] <ScottK> NCommander: This is the time when you can really tell what's Main and what's Universe as Main stuff gets scored to build ahead of Universe.
[19:27] <NCommander> yup
[19:28] <sebner> ScottK: when debian is released before DIF I suppose many packages get from experimental -> unstable -> ubuntu. Isn't there a risk that it breaks our stuff?
[19:29] <ScottK> sebner: There is always risk of getting stuff out of sync via autosync.  I don't think that appreciably changes it.
[19:29] <ScottK> That's part of why it gets turned off as early as it does so we can find and fix such things.
[19:30] <sebner> and sebner sync bot can continue syncing :)
[19:30] <ScottK> sebner: Don't go overboard.  Have a good reason to do it.
[19:31] <sebner> ScottK: why did I know that you react like that ... :P
[19:31] <ScottK> Because it's the right answer.
[19:32] <sebner> yes and because I knew that you'll answer it ^^
[19:32] <sebner> ScottK is always killing my jokes :\
[19:32]  * ScottK is grumpy today even compared to his usual self.
[19:33] <sebner> np
[19:33] <sebner> the fun has just begun so let's be happy =)
[19:48] <RainCT> uhm.. gpg says that my secret key cannot be used, any idea?
[19:51] <geser> RainCT: what's the exact error message?
[19:52] <RainCT> gpg: skipped "rainct@ubuntu.com": la clau secreta és inusable
[19:52] <RainCT> gpg: [stdin]: clearsign failed: la clau secreta és inusable
[19:52] <RainCT> debsign: gpg error occurred!  Aborting....
[19:52] <RainCT> with LANG=C,     unusable secret key
[19:53] <geser> does using gpg still work for you?
[19:54] <RainCT> not sure, I only use it for package signing :P
[19:54] <RainCT> let me try unencripting something
[19:54] <NCommander> RainCT, it sounds like your key went and corrupted itself :-/
[19:54] <NCommander> geser, hey
[19:54] <geser> Hi NCommander
[19:54] <NCommander> geser, how goes it?
[19:55] <geser> NCommander: fine, just very busy the last days and I don't see an improvement in the near future
[19:55] <RainCT> bah, I have to find my backup then.. :(
[19:55] <NCommander> geser, that sucks, but it could be worse
[20:01] <geser> RainCT: compare todays date and the expiry date of your key :)
[20:02] <RainCT> crap!
[20:02] <RainCT> I guess it can't be unexpired? :P
[20:03] <RainCT> and why doesn't that damn gpg thing warn you some days before? :P
[20:03] <geser> I guess you should be able to update the expiry date
[20:04] <RainCT> uop, what is the expiry date for then? to scare you? :D
[20:05] <geser> hmm, perhaps you can't. I didn't find an option on a quick look to update it
[20:05] <RainCT> geser: I can, just did it with seahorse :)
[20:06] <geser> yes, google helped me too: "expire" in the gpg --edit-key menu
[20:07] <RainCT> geser: thanks :)
[20:07] <geser> RainCT: don't forget to tell the Ubuntu keyserver that you changed the expiry date
[20:08] <RainCT> geser: because I have no signature from any DD yet and the window is closed, else I'd have jumped out *g*
[20:08] <geser> I don't know if soyuz will accept your signature otherwise
[20:08] <RainCT> yep, I'm searching how to do this (seahorse can't because there's a bug in the code for it :P)
[20:09] <geser> gpg --send-key rainct@ubuntu.com
[20:09] <geser> or use your keyid instead of the email address
[20:10] <ajmitch> hi
[20:10] <geser> Hi ajmitch
[20:10] <RainCT> ajmitch: hey
[20:12] <iulian> RainCT: You might want to use the keyserver option too.
[20:12] <iulian> geser: I thought that you must specify the keyserver first.
[20:13] <iulian> keyserver.ubuntu.com
[20:13] <geser> iulian: unless you have one set in your .gnupg/gpg.conf
[20:13] <tbielawa> hellooo everybody
[20:13] <iulian> geser: Ah, right.
[20:14] <RainCT> iulian, geser: done, thanks
[20:14] <geser> RainCT: don't forget to put a sticky note on your monitor to remind you when your key expires again :)
[20:15] <RainCT> geser: I won't forget :)
[20:15] <ajmitch> you say that now
[20:15] <iulian> Or set it to never expire?
[20:15]  * iulian agrees with ajmitch.
[20:16]  * RainCT goes to do homework where pbuilder slowly downloads bdeps
[20:17] <iulian> RainCT: I said exactly the same thing when I generated my second key. After a couple of weeks when I tried to sign a document using that key, I couldn't remember my password.
[20:18] <iulian> Fortunately, after ~50 combinations I entered the correct one and recovered my key ;)
[20:18]  * NCommander uses a password but doesn't expire his keys
[20:18] <RainCT> lol
[20:18]  * ajmitch wonders why that RC bug day has to be on sunday
[20:19] <iulian> RainCT: Well, I wrote a small program which gives me the passwords in a nice way. And yes, that file is in a safe place, encrypted.
[20:20] <tbielawa> lol
[20:21] <RainCT> iulian: and if you forget the password to decrypt it? :D
[20:22] <iulian> Yeah, it sucks when you don't remember something which you need it in a few moments.
[20:22] <iulian> RainCT: Impossible. ;)
[20:24]  * iulian goes back to hunt some merges.
[20:25] <ScottK> iulian: I'd rather you hunted patches to send to Debian out of those merges.
[20:25] <tbielawa> Does anyone have time to do a REVU for me? http://revu.ubuntuwire.com/details.py?package=lucidlife it would be much appreciated.
[20:32] <iulian> ScottK: Sure, I'm looking at some of them right now. So, we send the patches to Debian, wait until the patches are included and then sync?
[20:32] <ScottK> iulian: That's my preferred workflow.  If it gets close to DIF and they haven't updated, merge then.
[20:33] <iulian> Cool, thanks.
[20:34] <ScottK> iulian: If there's a case where you know we have changes that won't go in Debian, then you should still send them the stuff that's relevant, but there's no real need to wait to do the merge.
[20:37] <iulian> ScottK: OK, that's what I thought.
[20:39] <pochu> devfil: do you want to take the wx2.6 merge for me? :)
[20:39] <devfil> pochu: there is a wx2.6 merge? ...
[20:40] <devfil> ok :)
[20:40] <devfil> thanks
[20:41] <pochu> devfil: thanks to you! :) I've assigned it to you in a comment in http://dad.dunnewind.net/universe.php
[20:41] <pochu> devfil: this needs to be merged: http://packages.qa.debian.org/w/wxwidgets2.6/news/20080909T143211Z.html
[20:41] <Yasumoto> This is a ridiculous question, but where's the fedora bugzilla?
[20:42] <Yasumoto> my google skills are terrible right now, I guess.. :/
[20:43] <Yasumoto> Does redhat use https://bugzilla.redhat.com/ for both RHEL and fedora?
[20:43] <pochu> I think so
[20:44] <iulian> Yes, IIRC.
[20:44] <Yasumoto> thanks guys. I found the fedora wiki, and it looks like bugzilla.redhat.com is it: http://fedoraproject.org/wiki/Bugzilla
[20:46] <pochu> Laney: you've got to do the fet merge ;)
[20:46] <pochu> nhandler: and the mmorph merge is yours!
[20:47] <pochu> Laney, nhandler: feel free to ping me if you want sponsorship for those
[20:54] <directhex> hm, looking at planet, it seems gnome-do is popular
[20:56] <stefanlsd> can debian still fix stuff in unstable?
[20:57] <ScottK> stefanlsd: Yes.  It just doesn't get into Lenny without approvals (which are very hard to get).
[20:57] <stefanlsd> ScottK: kk. cause we have time still. Some of the merge stuff i'm rather forwarding and getting them to fix so we can just sync.
[20:57] <ScottK> stefanlsd: That's the preferred approach.
[20:58] <directhex> bug fixes will get into lenny. UVF is pretty strict
[20:58] <james_w> any REVU admins around?
[20:58] <james_w> jelmer uploaded a new version of ptabtools yesterday, but it hasn't shown up on REVU, could someone see if there is something wrong?
[20:58] <stefanlsd> anyone having issues with the requestsync script?
[20:59] <pochu> stefanlsd: we can sync from experimental anyway
[20:59] <pochu> in case your changes are uploaded there
[20:59] <ScottK> directhex: Only for RC bugs.
[21:00] <james_w> ah, don't worry, he worked it out, he uploaded binaries, not a source package
[21:01] <ajmitch> james_w: there was an issue with REVU yesterday as well, which meant that packages weren't being accepted for awhile
[21:01] <pochu> ScottK: non-rc are also approved for lenny sometimes
[21:01] <james_w> ah, might have hit that as well, thanks ajmitch
[21:02] <ScottK> pochu: True, but it's definitely the exception.
[21:11] <ScottK> tbielawa: You assert that part of your package is public domain.  How do you know that?
[21:13] <tbielawa> ScottK, you are referring to "pattern archive in patterns/..."?
[21:13] <ScottK> Yes
[21:14] <tbielawa> one moment please.
[21:14] <ScottK> tbielawa: I have to run out, but consider that copyright law in many contries doesn't have the concept of public domain.
[21:15] <tbielawa> ScottK, then I should also provide a reference URL which declares their public domain status, or perhaps including the text of the american public domain definition would be better suitable?
[21:16] <tbielawa> (also, README from upstream tarball is where they are declared as public domain)
[21:18] <ScottK> tbielawa: "Public domain" works can be problematic is some respects.  If they created it then it'd be simplest if they also licensed it under some really broad license like the wtfpl.
[21:20] <tbielawa> ScottK, would you recommend I attempt to contact the public domain author?
[21:21] <laga> the wtfpl sounds neat
[21:26] <tbielawa> I like that license
[21:26] <pochu> i can has jaunty ppa pliz? :)
[21:27] <Yasumoto> So on http://dad.dunnewind.net/universe.php, anything that has a /!\ needs to be looked at by a human, right?
[21:35] <Lutin> Yasumoto: everything needs to. the ones marked /!\ are broken, and consequently the output of DaD should not be taken into account when merging
[21:41] <logari81> hi, I try to upload for first time something on my ppa and I get the following error
[21:41] <logari81> Unable to find distroseries: unstable
[21:41] <logari81> but I see packages in ppa's of other members, built against "unstable", am I missing something?
[21:45] <Yasumoto> Lutin: ah, cool. thanks
[21:53] <ScottK> Yasumoto: They ALL need to be looked at by a human.
[21:58] <Yasumoto> ScottK: yeah, I'm looking at the outstanding merges for universe (300!). reading the UbuntuDevelopment/Merging wiki page now
[21:58] <ScottK> OK.
[21:59] <ajmitch> down to 300 already?
[22:00] <cody-somerville> ajmitch, Debian has been in a freeze
[22:00] <Yasumoto> yeah, according to http://merges.ubuntu.com/universe.html
[22:00] <ajmitch> cody-somerville: yes I know
[22:02] <directhex> jaunty will suffer unless lenny releases pronto. close an RC bug today!
[22:05] <ajmitch> few of the remaining RC bugs in debian will be just quick fixes
[22:08]  * ScottK wraps his head around using pbuilder to build the new pbuilder ...
[22:09] <pochu> logari81: try in #launchpad
[22:11] <logari81> pochu: thnx I ll try, but I think I ll build my packages explicitly against intrepid and/or jaunty
[22:13] <ScottK> logari81: PPA is run by Launchpad.  You need to ask there.
[22:17] <NCommander> ScottK, your pbuildering pbuilder?
[22:17] <ScottK> Yep.
[22:17] <ScottK> And then I'm doing it again to test the result of the first one.
[22:20] <NCommander> ScottK, I ... uh ...
[22:20]  * NCommander feels confused
[22:20] <ScottK> I need to know if the new pbuilder works for the backport, so I need to install it and build something for a test ...
[22:20] <ajmitch> NCommander: I'm surprised
[22:22] <ScottK> BTW, with debchroot from Jaunty backported to Intrepid it's no trouble to make a new pbuilder chroot for Jaunty.
[22:23] <ScottK> Not that I'd have expected anything else.
[22:28] <sebner> ScottK: debchroot = debootstrap?
[22:29] <ScottK> sebner: Yes.  My typo.  Sorry.
[22:29] <sebner> ScottK: np, thx for the hint =)
[22:31] <ajmitch> or you just put in another symlink for jaunty
[22:32] <ScottK> That too.
[22:32] <sebner> ScottK: does autosync already runs?
[22:32] <ScottK> sebner: Yes.
[22:33] <superm1> ScottK, i seem to remember you were tracking some bug where hotkeys are broke in kde 4, like vol+/vol- and play/pause etc?  Do you have that handy?
[22:33] <tuxmaniac> where can I find some information on rising sru for intrepid?
[22:33] <sebner> ScottK: cool thx. so /me has to upgrade to jaunty =)
[22:33] <ScottK> sebner: Look how many are in queue https://launchpad.net/+builds
[22:33] <ScottK> superm1: jdong was working on that.
[22:33]  * ScottK looks
[22:33] <ScottK> superm1: Bug #267245
[22:33] <superm1> great thanks
[22:34] <ScottK> IIRC he was still trying to sort out brightness keys.
[22:34] <wasabi> Hey... trying to get a cdbs package to work and something is eluding me.  Using makebuilddir/source-package-name:: to do some stuff before configure. but it's never being run.
[22:34] <tuxmaniac> ok got it thans
[22:34] <wasabi> Also tried to use a binary package name.
[22:35] <superm1> I just saw some hal-info bug filed which I was pretty confident was actually a KDE bug, there's an upstream tracker for it too, so i'll add that
[22:35] <jdong> ScottK: talked to Riddell regarding the brightness keys; fixing them will require work on qt4-x11 to bring out those hotkeys.
[22:35] <sebner> ScottK: yep, quite busy our mighty machines =)
[22:35] <jdong> superm1 / ScottK: Base problem is qt4 doesn't support the XF86MonBrightness{Up,Down} KeySyms
[22:35] <ScottK> jdong: Sounds like something worth doing in Jaunty then.
[22:35] <jdong> ScottK: agreed.
[22:36] <jdong> superm1: the current Kubuntu workaround is basically xmodmapping brightness keycodes to various "unused"/esoteric keys, in particular XF86Launch4/XF86Launch5 which QT does understand
[22:36] <jdong> superm1: that, though, breaks the brightness keys in GNOME :)
[22:37] <superm1> jdong, gosh how silly
[22:37] <jdong> so yeah, I think this is something to work on in Jaunty, not Intrepid.
[22:37] <jdong> it's quite a hairy mess and I don't want to cause regressions for Kubuntu users who already have working brightness keys
[22:37] <ScottK> Yes.  Please.
[22:38] <superm1> i think crack for jaunty is more fun anyway, get adding :)
[22:42] <sebner> ScottK: btw, another question. if some of my major sponsors are in the MC I don't need to CC them right?
[22:42] <ScottK> sebner: Dunno.
[22:42] <sebner> ^^
[22:43] <ScottK> Personally, I'd cc everyone.  I don't think there's a rule though.
[22:44] <NCommander> sebner, you applying for MOTU?
[22:44]  * sebner hides
[22:45] <sebner> ScottK: I just thought recieving 2 times the same email isn't that fun
[22:46] <nhandler> sebner: If a person is CC'd on a mailing list message, the list will not send them another copy iirc
[22:48] <TheMuso> nhandler: I think it depends on list and user settings.
[22:48] <ScottK> nhandler: That's not the default for mailman.
[22:48] <nhandler> ScottK: I thought it was. I know I don't get duplicate messages if I am CC'd
[22:48] <ScottK> It's a config option.  Dunno how the MC list is set.
[22:48] <RainCT> james_w: https://wiki.ubuntu.com/MOTU/Packages/REVU/JauntyCleanu
[22:48] <RainCT> * https://wiki.ubuntu.com/MOTU/Packages/REVU/JauntyCleanupMessage
[22:49] <RainCT> any improvements welcome ^
[22:49] <ScottK> RainCT: I have a REVU feature request.
[22:49] <ajmitch> ScottK: a 'nuke all' button?
[22:50] <ScottK> RainCT: It'd be nice to have something to click on that would run grep -ir copyright * on the source and output the result.
[22:50]  * sebner is happy that he started a discussion about mail settings  ^^ 
[22:50] <ScottK> ajmitch: That too.
[22:50] <logari81> I got my questions about ppa answered, but now I need some feedback about my first packaging attempt. Could anyone take a look here https://launchpad.net/~logari81/+archive/ and give me feedback?
[22:50] <ScottK> ajmitch: My equivalent is generally "Don't look at REVU".
[22:51] <james_w> RainCT: nice job, I think that strikes a good balance.
[22:51] <james_w> RainCT: thank you
[22:51] <sebner> NCommander: to be honest I wanted to wait some time after I saw your application ;)
[22:52] <ScottK> RainCT: The reason I ask is that I often end up doing reviews just for licensing stuff and that's save me bothering with some downloading.
[22:52] <RainCT> ScottK: That's an interesting proposal. Perhaps it could be written to a file, like with lintian. What exact command would you suggest?  "grep -ir copyright * | tee ...; licensecheck * | tee -a ..." ?
[22:53] <ScottK> RainCT: I don't generally use licensecheck so I'm not able to say about that.
[22:53] <james_w> licensecheck has a copyright flag
[22:53] <ScottK> Maybe that's all we need then.
[22:54] <RainCT> james_w: (re the message) Thanks :). Anything which could be improved?
[22:54] <james_w> "licensecheck -r --copyright . " I think
[22:54] <james_w> is the best way to call it
[22:54] <RainCT> thinking about it again, perhaps dinamically generated is indeed better.. else siretart may kill me for filling up the disk :D
[22:54] <RainCT> alright, let me try if I can get it ready right now
[22:55] <james_w> RainCT: I can't think of anything, I think that is a good message for this point.
[22:56] <nhandler> RainCT: I have another suggestion. Could you please grep the changelog file for (LP: #NNNNNN), and either display a link to the needs-packaging bug or display a warning stating that the package does not close a needs-packaging bug on LP?
[22:56] <RainCT> nhandler: yep, that's on my TODO, too
[22:57] <nhandler> Awesome RainCT
[23:00] <ScottK> nhandler: Why do we care if it closes the bug?  The bug won't close because of that.
[23:00] <nhandler> bobbo: You should really contact the last uploader of a package before doing a merge (especially this early in the cycle). I was already working on the seq24 merge
[23:00] <Yasumoto> wow, I like how I submitted a bug report upstream for clisp, and I just realized the upstream guy already pretty much shot down the bug. whoops..
[23:01] <nhandler> ScottK: It makes it easier to check that it does in fact close a needs-packaging bug (which is a requirement), and it also makes it easier to see what discussion (if any) has occured regarding the package
[23:01] <ScottK> nhandler: I guess I don't see the point in the requirement.
[23:01] <nhandler> ScottK: Well, I'm not the one who made that requirement ;)
[23:04] <bobbo> nhandler: sorry, wont do it again!
[23:05] <nhandler> No problem bobbo. I probably should have opened a bug report when I started working on it
[23:05] <RoAkSoAx> is merging for jaunty open?
[23:06] <sebner> RoAkSoAx: yep
[23:07] <RoAkSoAx> right on!
[23:07] <RAOF> In case anyone's interested, you're welcome to do the miro merge.  Don't think I've got a maintainer-lock on it! :P
[23:08] <Yasumoto> Speaking of which, what's the best way to see if a maintainer's working on a package? ping them on irc?
[23:08] <RAOF> Check the bug page first, and DnD's comment section.
[23:09] <Yasumoto> RAOF: good idea, thanks
[23:09] <RainCT> ScottK: I think this will be discussed Friday 14th (there's "wnpp package for Ubuntu" on the schedule)
[23:10] <RAOF> Then a ping on IRC; if you can't get them on IRC then what you should do next depends on the stage of development, the history of uploads (I'm likely to be much more interested in a merge if, say, I'm the Debian maintainer too, or I've consistently uploaded the package).
[23:13] <Yasumoto> RAOF: yeah, it's probably something you're quite familiar with, and it's at the top of your list
[23:13] <RAOF> Yasumoto: What? Miro?  I'm familiar with it, but you're absolutely welcome to take it if you wish.
[23:14] <Yasumoto> haha :)
[23:14] <RAOF> The merge should be reasonably simple.
[23:14] <Yasumoto> Alright, sounds great to me, I'll grab it now
[23:15] <RAOF> My test-build ability will be somewhat limited for a while by the fact that my something in my buildbox decided to catch fire this morning.
[23:18] <james_w> RainCT: have you considered the timing of that mail with the REVU day?
[23:19] <Yasumoto> RAOF: sounds brutal.. :(
[23:19] <RAOF> It'll be the power supply or something.
[23:20] <RainCT> james_w: Not sure what you mean. "that mail" -> the mail I'll send to announce it?
[23:21] <james_w> RainCT: sorry, I meant moving the packages to "Needs Work"
[23:21] <james_w> RainCT: if you do it today then there will be people who will miss a REVU day
[23:22] <james_w> if you do it after then it doesn't help the reviewers on Friday
[23:22] <james_w> do you know how often the REVU days will be?
[23:22] <RainCT> james_w: weekly, every Friday
[23:22] <james_w> ah, cool
[23:22] <james_w> no problem then
[23:23] <wasabi> Any cdbs people here? I am having trouble getting makebuilddir/ to work.
[23:23] <NCommander> RainCT, stupid question. I got three +1s on my MOTU application, but I'm not in ~motu yet. Can I still +1 on REVU apps?
[23:23] <wasabi> As in, it's simply not being called, and I can't figure out why.
[23:23] <RainCT> NCommander: I can't answer to that :)
[23:23] <NCommander> RainCT, your the REVU coordinate ;-)
[23:23] <NCommander> *cooridinator
[23:24] <james_w> does anybody want to review http://revu.ubuntuwire.com/details.py?package=ptabtools ?
[23:24] <james_w> I haven't advocated yet, but I plan to once I get a build environment sorted out
[23:24] <NCommander> I will
[23:26] <NCommander> james_w, the copyright file is incomplete
[23:26] <james_w> why?
[23:26] <NCommander> It doesn't list who holds the copyright
[23:26] <james_w> ah, downloaded from?
[23:27] <james_w> Copyright (C) 2005-2008 Jelmer Vernooij <jelmer@samba.org>
[23:27] <NCommander> No, the entire line is blank
[23:27] <NCommander> No
[23:27] <NCommander> go one down
[23:27] <NCommander> Oh
[23:27] <NCommander> wait
[23:27] <NCommander> The upstream is the packager?
[23:27] <james_w> yeah
[23:27] <james_w> I don't see a problem with lumping it all in together
[23:28] <james_w> but I'm not an archive admin
[23:28] <NCommander> james_w, ok, fair enough
[23:28] <NCommander> Why does it use *.links?
[23:28] <james_w> because the Makefile is incomplete I believe
[23:29]  * NCommander would normally file a bug w/ the upstream on that ;-)
[23:30] <NCommander> The dirs files can be removed, they are only needed if make install will not create them
[23:32] <james_w> again, the Makefile :-)
[23:32] <NCommander> make install doesn't work?
[23:32] <NCommander> ARGH
[23:32]  * NCommander thunks his head
[23:32] <NCommander> Ok
[23:33] <NCommander> I don't mind +1ing the package if the resulting binaries are lintian clean and it builds in a jaunty pbuilder chroot
[23:33] <james_w> no, that does work
[23:33] <james_w> I'll mention it to him
[23:33] <NCommander> It FTBFS in pbuilder
[23:34] <james_w> NCommander: ok, thanks. Please drop the error in a comment and I'll work with him to get a working package.
[23:35] <coppro> NCommander: http://revu.ubuntuwire.com/details.py?package=metakit? I haven't tried it on a jaunty pbuilder yet, I'm making the chroot now
[23:35] <NCommander> Want me to build it?
[23:38] <coppro> review it, if you would be so kind :)
[23:40] <NCommander> I can already see a critical issue
[23:40] <NCommander> "0ubuntu2"
[23:40] <coppro> yeah, I know
[23:40] <coppro> I'm not sure about REVU's versioning scheme; and it won't let me update without increasing the version
[23:40] <NCommander> Care to explain?
[23:40] <NCommander> coppro, revu will accept anything and it will clobber
[23:41] <NCommander> Is this package from Debian?
[23:41] <coppro> it just straight clobbers, wihtout anything so much as "new upload?"
[23:41] <NCommander> (why are there README.Debian files)
[23:41] <coppro> no, it's not Debian
[23:41] <coppro> oh, what should I be using then?
[23:41] <NCommander> coppro, every upload is perserved
[23:41] <coppro> NCommander: well, last time I tried, it didn't work
[23:41] <NCommander> README.Ubuntu, unless you intend to submit this to Debian
[23:41] <coppro> and someone said to bump the version
[23:41] <coppro> NCommander: ok, I'll change that
[23:41] <NCommander> WHoever said that probably thought you meant PPAs
[23:42] <coppro> oh
[23:43] <coppro> well it didn't work
[23:43] <coppro> my upload never showed up
[23:43] <RainCT> NCommander: README.Ubuntu? o.O
[23:43] <NCommander> REVU last night was having issues
[23:43] <coppro> was a couple of days ago
[23:43] <NCommander> RainCT, as an aside, next time you edit a script, try it afterwards. GPG validation was broken because a permission got screwed up
[23:43] <NCommander> :-)
[23:44] <RainCT> oh ok, I was wondering why there's that much rejected stuff lying around :P
[23:44] <RainCT> NCommander: which file was wrong?
[23:45] <NCommander> You managed to get GPG trying to write scratch files in /root/.gnupg
[23:45] <NCommander> Which didn't exist
[23:45] <NCommander> RainCT, anyway, I thought on Ubuntu specific packaging, the README files should be README.Ubuntu
[23:45] <NCommander> (so if the package ever exists in Debian and then are merged, both are available)
[23:46] <RainCT> there should only be one if they are merged :P
[23:46] <NCommander> Having a README.Debian file seems wrong on a 0ubuntuX package
[23:47] <coppro> well, I've made the change
[23:47] <james_w> I don't see a need to break convention
[23:47] <coppro> *shrug*
[23:48] <james_w> yes, it makes a sense, but why break the association of "information specific to a .deb" => "README.Debian"?
[23:48]  * RainCT agrees with james_w 
[23:52] <RainCT> ScottK: http://revu.ubuntuwire.com/report.py/legal?upid=3818 :)
[23:53] <james_w> RainCT: wow, nice work :-)
[23:54] <RainCT> james_w: was actually quite easy to add :)
[23:54] <james_w> don't say that!
[23:54]  * NCommander gives up on the README.Ubuntu
[23:55] <csilk> If an app came in a zip file can I just unzip, create tar.gz of source, create .orig.tar.gz then get rid of the zip?
[23:55] <RainCT> NCommander: do you have a double personality which fighted against yourself on this? *g*
[23:55] <csilk> making a note in the changelog of course
[23:55] <RainCT> csilk: if that's the only option, yes. but do that automatically using a get-orig-source rule
[23:55] <csilk> RainCT, k thanks
[23:56] <RainCT> (sponsors are supposed to generate the tarball themselves using get-orig-source before updating, to ensure that the tarball wasn't modificated)
[23:57] <RainCT> (not sure if anyone does this, but well, get-orig-source rules are nice nevertheless :))
[23:58] <csilk> using the get-orig-source rule wasn't mentioned in holbachs video tutorials
[23:58] <RainCT> csilk: it's just an additional target in debian/rules, which does whatever you want
[23:59] <csilk> I'll read up on how that works