[01:25] <Fujitsu> Morning all.
[01:26] <geser> Hi Fujitsu
[01:29] <jrib> hey Fujitsu
[01:29] <Fujitsu> Hi geser, jrib.
[01:45] <LaserJock> hi hi hi MOTU Land!
[01:46] <geser> Hi LaserJock
[01:48] <Fujitsu> Hi LaserJock.
[01:48] <LaserJock> Fujitsu!!
[01:48] <LaserJock> hi geser
[01:48] <LaserJock> Fujitsu: you still doing MOTU Science lists?
[01:50] <LaserJock> hi imbrandon
[01:50] <imbrandon> heya LaserJock
[01:50] <Fujitsu> LaserJock: What kind of lists?
[01:50] <Fujitsu> Hi imbrandon.
[01:50] <LaserJock> Fujitsu: the mdt and bug lists
[01:50] <Fujitsu> MDT: yes. Bugs: I don't think so... the script broke, and we can do it in the normal interface anyway.
[01:51] <Fujitsu> geser: Night.
[01:51] <LaserJock> Fujitsu: I don't like the normal interface
[01:51] <LaserJock> but that's a small thing
[01:51] <LaserJock> the mdt lists are a bigger deal
[01:51] <Fujitsu> I'll see how broken the bug thing is.
[01:51] <Fujitsu> But as far as I know mdt is still going fine.
[01:51] <LaserJock> I can make the lists, but I can't really cron it
[01:52] <LaserJock> as my server isn't running Debian/Ubuntu
[01:52] <Fujitsu> Ah.
[01:52] <Fujitsu> I was fortunately on one of the ServerPronto servers that wasn't compromised.
[01:52] <Fujitsu> We've had a pretty good security policy from the start.
[01:56] <Fujitsu> LaserJock: Back up at http://people.ubuntu.org.au/~fujitsu/motuscience/bugs/
[01:58] <LaserJock> Fujitsu: excellent
[01:59] <Fujitsu> LaserJock: Do we want to kill of scigraphica like Debian?
[01:59] <Fujitsu> *off
[02:00] <LaserJock> oh, did they finally get rid of it?
[02:00] <Fujitsu> We've only got the two nasty bugs.
[02:00] <Fujitsu> They did.
[02:00] <Fujitsu> Debian bug #438774
[02:00] <ubotu> Debian bug 438774 in ftp.debian.org "RM: scigraphica -- RoQA; unmaintained; dead upstream" [Normal,Open]  http://bugs.debian.org/438774
[02:00] <LaserJock> Fujitsu: sounds reasonable to me
[02:01] <Fujitsu> Ah, and textopo can die too, as it's replaced by texlive-science.
[04:31] <bddebian> Heya gang
[04:32] <justinwray> Hola
[04:32] <LaserJock> hola Barryson
[04:32] <bddebian> Heh, hi justinwray, LaserJock
[04:32] <Fujitsu> Hi bddebian.
[04:33] <bddebian> Heya Fujitsu
[04:33] <bddebian> Now why the heck would the binaries of jmagick end up in NEW?
[04:37] <Fujitsu> bddebian: It has never built before.
[04:38] <Fujitsu> We got it building rather then removing it? So I wasn't entirely on crack?
[04:39] <Fujitsu> tonyyarusso: `they'?
[04:41] <bddebian> Fujitsu: Yeah, even though the Debian changelog said it added a b-d for kaffe-dev, they didn't.  All I had to do was change the kaffe b-d to kaffe-dev
[04:41] <tonyyarusso> Fujitsu: archive gods
[04:45] <Fujitsu> The archive guys don't build things...
[04:45] <LaserJock> i.e. LP cron jobs
[04:51] <tonyyarusso> Fujitsu: They "approve" or some such, right?  I don't know...there's some sort of step between sitting in +queue and sitting in +builds
[05:04] <Fujitsu> tonyyarusso: Ah, they approve sources from NEW, but only if they're NEW.
[05:04] <tonyyarusso> Fujitsu: Ah.
[05:05] <tonyyarusso> Fujitsu: So then some sort of "A Okay" tag gets thrown on, and the auto-building stuff looks for that?
[05:11] <Fujitsu> tonyyarusso: The package is approved from NEW, moves to ACCEPTED, then to DONE, then the build-queuer sees it and queues builds.
[05:12] <tonyyarusso> Fujitsu: How can you view those different stages on LP ?
[05:12] <Fujitsu> tonyyarusso: /ubuntu/gutsy/+queue, the dropdown at the top.
[05:13] <tonyyarusso> Fujitsu: Ooooh (My eyes always ignore helpful dropdowns on LP for some reason - this happens a lot)
[05:13] <Fujitsu> Mhm.
[05:14] <tonyyarusso> so mine's not even accepted yet :(
[05:14] <Fujitsu> Sources can sit in new for a while.
[05:15] <tonyyarusso> Now, when things are accepted or rejected, is any sort of comment attached?
[05:16] <Fujitsu> tonyyarusso: NAFAIK
[05:23] <tonyyarusso> ok
[05:26] <ScottK> Is there a way to specify to requestsync which GPG key/email address to use?
[05:29] <tonyyarusso> Speaking of GPG keys...I could use some advice:
[05:29] <xtknight> is there a guide to making an orig.tar.gz?  do you just tar.gz up the folder into the tar?  e.g. asdf.tar.gz\asdf\[source files are here] ?  or, asdf.tar.gz\[source files are here]  (omitting redundant dir name)?
[05:29] <bddebian> You do not want the redundant sub-dir, no
[05:29] <xtknight> likewise speaking of gpg keys i was wondering what happens if you lose the key you made for yourself.  are you doomed?  (not that i did)
[05:30] <tonyyarusso> I have to use a mobile drive for school - it's a real 3.5" hard drive, installed into a removable tray, which then fits into a rack that installs into any 5 1/4" bay.  This means I can boot my systems on any computer at school.  Should I create a GPG key on there for those purposes I may use it for, or just avoid it altogether b/c of the security risk?
[05:30] <ScottK> xtknight: You should have a backup, but if you lose either your secret key or the passphrase, you need to make a new one.
[05:30] <tonyyarusso> I anticipate that this drive will never leave my sight, but I'm not 100% sure.
[05:30] <xtknight> ScottK, what if i remember the PW i just didn't export the public or private key?
[05:31] <xtknight> e.g. data loss
[05:31] <ScottK> You need to have the private key or you need to start over.
[05:31] <xtknight> if i start over, won't they think im an imposter?
[05:31] <ScottK> Who?
[05:31] <tonyyarusso> "they" being?
[05:31] <ScottK> For LP, just add the new key to your LP ID.
[05:31] <xtknight> ah ok
[05:32] <xtknight> the point of signing something is so that they know it's "you".  if i created a new key all of a sudden that didnt match any of my previous ones, that probably wouldnt go over too well.
[05:32] <ScottK> As long as it's in LP, LP won't care.
[05:32] <xtknight> k
[05:40] <xtknight> how would you make a .diff.gz?
[05:41] <xtknight> does that sound good? "diff -u ../orig/hugin/ hugin > hugin_0.7~svn2420.diff.gz"
[05:41] <Fujitsu> xtknight: debuild
[05:41] <Fujitsu> Or dpkg-buildpackage
[05:42] <xtknight> Fujitsu,  oh so debuild will make it once i give it the orig in ../ ?
[05:42] <tonyyarusso> xtknight: yeah
[05:42] <xtknight> cool beans :)
[05:42] <bddebian> Is there a better replacement for j2re1.4?
[05:42] <tonyyarusso> (how do debuild and dpkg-buildpackage differ?)
[05:42] <Fujitsu> bddebian: Yeah. Not java.
[05:43] <bddebian> Fujitsu: Well that's obvious, but besides that :-)
[05:43] <Fujitsu> tonyyarusso: debuild does some build environment cleaning and various other magic... it's basically a wrapper around dpkg-buildpackage.
[05:43] <tonyyarusso> Fujitsu: so debuild would be preferred then.
[05:43] <LaserJock> debuild is *the* way to go
[05:43] <zakame> pdebuild too
[05:44] <LaserJock> I don't know why people use dpkg-buildpackage
[05:44] <xtknight> now if i'm updating "somebody else"'s package, should the maintainer be him, me, or Ubuntu MOTU?  The XSBC-Orig should still be the first Debian maintainer of the package?
[05:44] <LaserJock> debuild is shorter
[05:44] <bddebian> LaserJock: I do :-)
[05:44] <Fujitsu> zakame: sbuild > pbuilder
[05:44] <bddebian> I'm old and crusty ya know :-)
[05:44] <LaserJock> bddebian: well, we know you are special
[05:44] <LaserJock> ;-)
[05:44] <bddebian> That's spethial ;-P
[05:45] <bddebian> So let me ask differently.  Is there a runtime match for gcj ?
[05:45] <Fujitsu> gij?
[05:45] <zakame> Fujitsu: right
[05:45] <LaserJock> I like pbuilder
[05:45] <LaserJock> I need to try sbuild out, but I've just not had time
[05:45] <zakame> but I still find pdebuild/cowdancer easier to set up
[05:45] <LaserJock> but I don't use LVM so I'm not sure why it would be that much better
[05:46] <bddebian> Fujitsu: But that's just the interpreter.  It doesn't include a vm right?
[05:47] <bddebian> I wonder if kaffe would work
[05:47] <Fujitsu> bddebian: No idea. I don't do Java.
[05:47] <bddebian> Me either :-(
[05:49] <nixternal> bddebian: there is no better replacement for any of the sun java components
[05:49] <nixternal> blackdown was the closest on the jre side
[05:49] <bddebian> j2re1.4 is blackdown isn't it?
[05:50] <LaserJock> that's why I just won't deal with Java until Sun open sources their stuff
[05:50] <LaserJock> it's just to messy for me to get straight
[05:50] <nixternal> blackdown is something different I thought
[05:51] <nixternal> I just use all of the java components right now because they are the only ones that work worth a darn for my java classes
[05:51] <tonyyarusso> LaserJock: I think part of the wiki still says dpkg-buildpackage, or I wouldn't have tried it.
[05:51] <bddebian> !j2re1.4
[05:51] <ubotu> Sorry, I don't know anything about j2re1.4 - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:51] <bddebian> pfft
[05:51] <zakame> blackdown is still sun java right?
[05:51] <LaserJock> well, it's not a "still" thing. Some people prefer dpkg-buildpackage it seems
[05:51] <nixternal> !jre
[05:51] <ubotu> Sorry, I don't know anything about jre - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:51] <nixternal> !java
[05:51] <ubotu> To install a Java compiler/interpreter on Ubuntu, look at https://help.ubuntu.com/community/Java - For the Sun Java runtime install sun-java5-jre from the !Multiverse repository. Enable the backports repository on Edgy to install sun-java6-jre
[05:52] <nixternal> ahh, you are right about blackdown
[05:52] <nixternal> j2* is blackdown
[05:53] <bddebian> Well freemind fails to build with j2sdk1.4.  I can build it with gcj but I don't know what that will do to the runtime environment
[05:57] <ScottK> StevenK: If I came up with a patch for requestsync to add the equivalent of -k in dpkg-buildpackage, would you take the patch?
[05:58] <ScottK> Not saying on what schedule, but I'll add it to the TODO if you're good with the idea.
[06:00] <tonyyarusso> Freemind is going into gutsy?
[06:00] <bddebian> It's already in but FTBFSs
[06:01] <tonyyarusso> Fun.  Hope it gets fixed - could be useful.
[06:01] <bddebian> Well as I said, I can build it with gcj but that doesn't help the runtime environment
[06:02] <tonyyarusso> bddebian: Have you talked to Eric Lavarde yet?
[06:02] <bddebian> Nope
[06:02] <tonyyarusso> bddebian: Seems to manage it in Debian, according to http://packages.debian.org/unstable/text/freemind
[06:02] <bddebian> Yep
[06:04] <tonyyarusso> bddebian: Have you been able to compare your source packages yet?
[06:04] <bddebian> tonyyarusso: ??
[06:05] <tonyyarusso> bddebian: Were you working from his, or starting from scratch?
[06:06] <bddebian> tonyyarusso: It was synced from Debian.  Same version
[06:07] <tonyyarusso> bddebian: oh.  nvm me then :S
[06:08] <bddebian> :-)
[06:09] <xtknight> what tells debian to make multiple debs for one source package?
[06:09] <bddebian> debian/control
[06:09] <xtknight> how does it know which files to give to each deb?
[06:10] <bddebian> There is 1 source entry and x binary package entries
[06:10] <bddebian> Oh
[06:10] <bddebian> Depends on the packaging type
[06:10] <xtknight> hmm
[06:10] <LaserJock> generally you can use a .install file
[06:11] <LaserJock> so like binarypackage1.install binarypackage2.install
[06:11] <LaserJock> if you are using debhelper/cdbs
[06:11] <xtknight> .install is a static thing that it always looks for, i assume?
[06:11] <xtknight> i dont see .install referenced
[06:11] <crimsun> debian/*.install
[06:11] <LaserJock> there isn't a .install file in debian/ ?
[06:11] <bddebian> They are inside the debian/ dir as well
[06:11] <LaserJock> crimsun!!!
[06:11] <LaserJock> holy cow!
[06:11] <xtknight> there is, but what tells it to look at .install and not .destroy? :)
[06:12] <LaserJock> dh_install is a debhelper script
[06:12] <xtknight> it always has to be "binarypkg.install"?
[06:12] <LaserJock> and it know to look at .install
[06:12] <bddebian> heh
[06:12] <LaserJock> well, if you don't have to distinguish you can do just install
[06:13] <LaserJock> but yeah, if you have multiple binaries you do <binarypackage>.install
[06:13] <LaserJock> crimsun: nice to see you are still alive
[06:14] <white> !info polipo gutsy
[06:14] <ubotu> polipo: a small, caching web proxy. In component universe, is optional. Version 1.0.1-2ubuntu1 (gutsy), package size 186 kB, installed size 800 kB
[06:14] <white> someone might want to look into an upgrade for polipo
[06:15] <bddebian> ho hum
[06:15] <crimsun> to 1.0.2-1?
[06:15] <white> !info backup-manager gutsy
[06:15] <ubotu> backup-manager: command-line backup tool. In component universe, is optional. Version 0.7.6-1 (gutsy), package size 111 kB, installed size 604 kB
[06:15] <white> crimsun: that is the version, which is marked as fixed, yes
[06:15] <xtknight> ok what is  ${shlibs:Depends} replaced by?
[06:15] <white> backup-manager to 0.7.6-3
[06:16] <white> !info mapserver gutsy
[06:16] <ubotu> Package mapserver does not exist in gutsy
[06:16] <crimsun> likely just needs UVF exception requests
[06:16] <white> !info perl-mapscript gutsy
[06:16] <ubotu> perl-mapscript: perl mapserver library. In component universe, is optional. Version 4.10.2-1 (gutsy), package size 699 kB, installed size 2048 kB
[06:16] <crimsun> I've been away most of this dev cycle, so I'm not 100% on the protocol
[06:17] <white> mapserver to 4.10.3-1 , but the patch could probably be backportet
[06:20] <LaserJock> white: do you have time to file bugs?
[06:20] <LaserJock> white: if so tag them with "upgrade"
[06:21] <ScottK> LaserJock: white serves as a communication device from Debian to Ubuntu.  AFAIK he doesn't actually do stuff like that.
[06:22] <LaserJock> communication is much nicer via bugs than IRC though
[06:22] <LaserJock> or at least email
[06:23] <LaserJock> but I realize he probably doesn't have a  lot of time, hence my first question
[06:23] <ScottK> Sure.  Just saying.
[06:24] <ScottK> Maybe there's a motu hopeful here that would be willing to file bugs ...
[06:24] <white> LaserJock: nope, sorry just wanted to forward the stuff from last night and after i upload the bugzilla NMU i need to study a bit :/
[06:25] <LaserJock> no problemo
[06:26] <bddebian> Yes lord knows we need more bugs :-)
[06:26] <crimsun> well you two are 2/3 of the trinity, so that's a non-issue ;)
[06:27] <bddebian> Hah, not anymore.  I'm pretty much more useless than ever :-(
[06:34] <minghua> banshee's "shuffle playback mode" seems to be completely broken.
[06:34] <minghua> It neither is random nor covers all the songs.
[06:35] <minghua> I have five songs in my list, and banshee gives me 1->3->5->1->3->5... in this shuffle mode.
[06:35] <minghua> :-(
[06:35] <Flannel> minghua: How do you know that's not random?
[06:36] <minghua> Flannel: I am not exactly sure, but I can calculate the probability if you really want...
[06:36] <xtknight> so dpkg-shlibdeps makes shlibs:Depends what does the misc Depends?
[06:36] <minghua> I think this is the fourth round it starts with no. 1.
[06:37] <minghua> xtknight: Please rephrase, I don't understand you question.
[06:37] <xtknight> minghua, how do i get ${misc:Depends} ?
[06:37] <Flannel> minghua: maybe you should go play the lottery if it keeps playing 1,3,5...
[06:37] <minghua> xtknight: ${misc:Depends} is added by different programs.
[06:37] <xtknight> minghua, dpkg-shlibdeps made substvars that set ${shlibs:Depends}, but there is a ${misc:Depends} i need to set
[06:38] <xtknight> (basically i'm using another package as a template and these variables don't exist anymore, i'm not sure how to create them for what's in the package now)
[06:38] <LaserJock>  misc:Depends is used by debhelper
[06:38] <LaserJock> to add in stuff it needs
[06:39] <minghua> xtknight: For example, I believe dh_installdebconf adds debconf into ${misc:Depends}.
[06:40] <xtknight> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[06:40] <xtknight> ?
[06:40] <minghua> xtknight: Exactly what do you want to set ${misc:Depends} to?
[06:40] <xtknight> that happened for shlibs.  then i ran dpkg-shlibdeps and the shlibs error is gone.  now i need to deal with misc
[06:40] <minghua> xtknight: If you don't need/use ${misc:Depends}, don't add it in Depends: line in debian/control.
[06:40] <xtknight> minghua,  hmm.  i guess i dont.  i can always check deps with pbuilder right?
[06:41] <minghua> xtknight: pbuilder usually only find problems in build dependencies, not (binary) dependencies.
[06:41] <xtknight> i'm wondering where ${misc:Depends} is set, though.  what tells debuild what the variable misc:Depends is ?  i would like to take a look at what another pkg has this variable set to, for example
[06:42] <minghua> You really need to know your package to decide if you need ${misc:Depends} or not.
[06:42] <xtknight> it's pretty small, so probably nothing
[06:42] <minghua> xtknight: After building, the value of ${misc:Depends} is in debian/<package-name>.substvars.
[06:42] <xtknight> ahh ok
[06:43] <xtknight> if it installs and runs on a fresh chroot, the it Depends on nothing, is that righT?
[06:44] <xtknight> or maybe if it needs a specific version of something
[06:44] <minghua> Okay, I got my no. 2 song.  Never mind what I complained about banshee.
[06:44] <minghua> (I still suspect there is something wrong, though.)
[06:44] <xtknight> what did shlibdeps do?  didn't that just detect the dependencies of my binary package?
[06:45] <RAOF> minghua: It's because it's actually random, not a shuffle.
[06:45] <RAOF> I think you'll find that rhythmbox does an actual shuffle without replacement, but banshee doesn't (yet).
[06:46] <minghua> RAOF: Yeah, good point.  Still many 1->3->5 rounds should be a rather small probability event...
[06:46] <minghua> Yes, rhythmbox's shuffle mode goes over all songs before starting next round.
[06:46] <RAOF> minghua: That's actually really hard to determine :).
[06:47] <minghua> I'll report a bug after some more experimentation.
[06:47] <RAOF> The next banshee release is getting an actual play queue as a part of it's huge rewriting.  Maybe that'll turn "random" into "shuffle".
[06:47] <minghua> At least, there is a "call it random mode instead of shuffle mode" bug to report.
[06:47] <RAOF> Point.
[06:48] <minghua> RAOF: Nice.  Do you happen to know the ETA of next banshee release?
[06:48] <RAOF> minghua: No.  We've actually got all the code (it's in the 0.13.1 release we've currently got), it's just not hooked up to anything yet!
[06:48] <minghua> Hmm.
[06:49] <minghua> RAOF: Thanks for the explanation.
[06:49] <white> !info bugzilla gutsy
[06:49] <ubotu> bugzilla: web-based bug tracking system. In component universe, is optional. Version 2.22.1-2.1ubuntu1 (gutsy), package size 811 kB, installed size 4436 kB
[06:49] <RAOF> Actually, the next banshee release should bring it pretty much up to parity with rhythmbox.  There's a lot of performance work done, play queue, etc.
[06:50] <white> you might want to check out the NMU 2.22.1-2.2
[06:50] <white> there was another CVE fixed
[06:50] <LaserJock> heah, is anybody writing this down? :-)
[06:50] <RAOF> Eh, it's all logged :)
[06:50] <crimsun> nmu should be a non-issue, since it's not an uv
[06:51] <white> LaserJock: actually it might be a good idea, if one MOTU would subscribe to the testing-security tracker list and maybe he and me could have a list somewhere, so you guys could work on syncing/merging it
[06:51] <LaserJock> RAOF: yeah, but people need to actually do it, you know ;-)
[06:51] <white> LaserJock: or someone subscribes to the whole crap i am saying here
[06:51] <white> anyway, see you later
[06:51] <LaserJock> thanks white
[06:52] <RAOF> Yeah, thanks.
[06:52] <bddebian> Any of you use/know audacious?
[06:52] <LaserJock> is that the audo editor app?
[06:52] <LaserJock> *audio
[06:52] <bddebian> Yeah I think
[06:52] <RAOF> Isn't that the xmms forky thing?
[06:53] <RAOF> There's audacious & audacity, and they're two different projects, right?
[06:53] <LaserJock> yeah
[06:53] <LaserJock> maybe audacity is the audio editor
[06:54] <RAOF> That's what aptitude thinks, too :)
[06:54] <bddebian> Yeah audacious is a fork of xmms
[07:02] <xtknight> well i've got my package built with debuild.  all goes well it is installs my program.  but im having troubles with pbuilder, ./configure script permission denied.  i think this is why: " dpkg-source: warning: executable mode 0755 of 'configure' will not be represented in diff." but how can i solve this?  the orig.tar.gz uses a "bootstrap" that creates a configure file.
[07:02] <xtknight> it installs my program*
[07:04] <minghua> xtknight: Don't put the configure script in .diff.gz, and run bootstrap at build time, is one option.
[07:05] <xtknight> ok
[07:05] <xtknight> minghua, the package of "hugin" (that i am updating) which is in gutsy uses a "configure" in its main dir which is why i went that route to begin with
[07:06] <minghua> xtknight: Is the configure script in gutsy package in .orig.tar.gz or .diff.gz?
[07:06] <bddebian> Gnight folks
[07:07] <xtknight> minghua, well he put it in the orig
[07:07] <xtknight> minghua, i don't think that is the "true" original though, because that orig file still has a bootstrap
[07:08] <xtknight> my orig is a direct mirror of what i got off sourceforge
[07:08] <minghua> xtknight: Are you packaging a new upstream?
[07:09] <minghua> !info hugin gutsy
[07:09] <ubotu> hugin: a Panorama Tools GUI to make panoramas from multiple pictures. In component universe, is optional. Version 0.7~beta4-0ubuntu1 (gutsy), package size 88 kB, installed size 132 kB
[07:09] <xtknight> minghua,  ok a bit complicated.  i am packaging part of "Hugin SVN", align_image_stack which needs to be built against Hugin SVN.  it will not build against the hugin in there.  so i made a new pkg with align_image_stack and all the updates headers it needs to compile.  great, so with no dynamic libraries we're all set right?
[07:10] <xtknight> ( i could not simply update hugin to hugin svn for regressions reasons )
[07:10] <xtknight> align_image_stack is only in Hugin svn
[07:10] <xtknight> there is no release which contains it
[07:11] <minghua> xtknight: Honestly I don't see much point talking about updating a package to an SVN version at this stage of release cycle.
[07:11] <xtknight> minghua,  this is a different package, not an update
[07:12] <minghua> xtknight: It's essentially the same.  I don't think it stands any chance of getting into gutsy.
[07:12] <xtknight> minghua, ok well i wouldn't really like to explain the whole situation again.  Bug 135111
[07:12] <ubotu> Launchpad bug 135111 in hugin "[UVFe]  hugin svn needs packaged for qtpfsgui" [Wishlist,Confirmed]  https://launchpad.net/bugs/135111
[07:13] <xtknight> basically i decided i could not update it because it may cause regressions (see last comment)
[07:13] <xtknight> so instead i am making a new pkg to include the program i need, standalone
[07:13] <xtknight> i think this is the best option for best user experience
[07:14] <xtknight> in fact i should add this to the comments there to clarify things
[07:14] <xtknight> sorry for the confusion
[07:16] <minghua> xtknight: I see the whole picture now.  However you didn't put you new plan (two packages) in the bug report, and you haven't got approval yet.  And this time you need a New Package Freeze exception, and I doubt the current UVF exception approval counts.
[07:18] <xtknight> minghua, ok I have no problem filing for the New Package Freeze exception and ditching the previous UVFe idea.  i would like the new program included in Gutsy (it is very small and depends on very little), but I don't want to cause regressions by needlessly updating hugin
[07:19] <minghua> xtknight: I understands you goal.  However I don't think you approach is a good idea, and I wouldn't grant approval if I were the release manager.
[07:20] <xtknight> minghua, how would you go about it?
[07:21] <minghua> xtknight: I would just bite the bullet and prepare the updated hugin and new package for hardy.
[07:21] <minghua> xtknight: Because in my opinion release pre-mature packages is worse than not release anything at all.
[07:22] <xtknight> since align_image_stack is in no hugin release then i will probably just forget about it, and make a new package once it is contained in a stable release which probably won't be until Hardy
[07:23] <xtknight> it would save a lot of trouble but i don't see how the current solution is any worse than what was already approved
[07:24] <xtknight> it would be the same code basically in a different package to avoid conflicts
[07:24] <minghua> "what is already approved" is not achieved yet.
[07:25] <minghua> In case it's not clear, my preference is "keeping the status quo", no updating hugin package, nor new hugin-svn package, everything can wait for hardy.
[07:26] <ScottK> xtknight: You are on a different plan now than we acked.  IMO you need to ask again.
[07:26] <xtknight> ScottK, oh, i have no problem asking for a New Package approval instead, but i am confused about the resistance to my current plan
[07:27] <xtknight> well i'll just do it and see what happens.  if they think it will wait until Hardy they will disapprove it, right?
[07:27] <ScottK> From my perspective, you asked for one thing and now you do another.
[07:27] <minghua> xtknight: I'm not a release manager (or motu-uvf team member?), so my resistance doesn't really matter.
[07:28] <ScottK> So it's not a freebie option.
[07:28] <minghua> xtknight: My suggestion would be "ask first".
[07:29] <xtknight> don't know it is probably too much trouble than it's worth for everybody
[07:32] <ScottK> xtknight: Off the top of my head, I'd say wait for Hardy.
[07:33] <ScottK> That's my advice, not speaking as motu-uvg
[07:33] <ScottK> err uvf
[07:36] <StevenK> ScottK: Re: your patch for requestsync, why?
[07:37] <ScottK> Because requestsync takes the first secret key on your keyring.
[07:37] <ScottK> In my case, that's not the one I use for Ubuntu, so it's  PITA.
[07:38] <ScottK> Note that I don't have the patch yet, just the annoyance factor that may rise into motivation.
[07:41] <ScottK> I think I should get to bed.  Good night all.
[07:42] <tonyyarusso> g'night
[07:48] <StevenK> ScottK: Drat, I missed you since I was putting shopping away. I'm happy to wait for a patch. If you have any trouble writting it, I'm happy to fix/debug, too.
[07:50] <xtknight> ScottK, minghua thank you for your thoughts.  i will see what my mentor thinks but most likely i will wait until Hardy
[07:50] <minghua> xtknight: You are welcome.
[07:50] <xtknight> i wasn't too happy about this but worst case i can put up a page about "how to get qtpfsgui" working in ubuntu on the forums, etc in absense of a package
[07:51] <ScottK> StevenK: I'm actually still here.
[07:52] <ScottK> StevenK: If you feel motivated, feel free to go ahead.  I've a long TODO list, so I don't know how soon I'd get to it.
[07:54] <StevenK> ScottK: I had to add the code for option parsing to requestsync due to sponsorship and such like, and it's actually a nice request. I think I can knock it over quickly, unless you want to cut your teeth on some Python.
[07:55] <ScottK> No.  I do enough Python on other things, so go ahead.
[07:55] <ScottK> Thanks for looking into it.
[07:56] <StevenK> It seems more interesting than looking at unmetdeps right now.
[07:56] <ScottK> Heh.
[08:07] <ScottK> OK.  Off to bed, really this time...  Good night once again.
[08:07] <StevenK> Night ScottK
[08:57] <TheMuso> Hey folks
[10:13] <RAOF> So, I'm trying to debug why trackerd segfaults somewhere in my $HOME.
[10:14] <RAOF> It's nice and reproducible.  However, the gdb backtrace is populated by 71 ?? calls.
[10:14] <RAOF> Also, valgrind SIGILLs when I try to run valgrind against it.
[11:01] <\sh> moins
[11:10] <\sh> anyone upto sponsor some bugfixes to universe? :)
[11:12] <geser> morning
[11:20] <jeromeg> geser : hello, have you been able to test dvgrab 3.0 with your dv camera ?
[11:26] <geser> not yet, will do it today
[11:27] <jeromeg> geser : thx very much, could you add your comments on the LP bug ?
[11:28] <jeromeg> cause I'll be away today
[11:37] <enyc> Hrrm'' i should suggest -motu include  nsd3 in ubuntu universe (please) -- its in debian testing, low dependancies, no non-free troubles, small and efficient ;-)
[11:38] <enyc> [please]  ;-) --   shoul i be posting a wishlist bug or something?  should i be testing it myself somehow?
[11:38] <minghua> !info nsd3
[11:38] <ubotu> Package nsd3 does not exist in feisty, feisty-seveas
[11:38] <minghua> !info nsd3 gutsy
[11:38] <ubotu> Package nsd3 does not exist in gutsy
[11:39] <enyc> ('nsd' is there already, which is NSD2)
[11:39] <enyc> nsd3 is not compatible config, the debian packgae uses /etc/nsd3 instead of /etc/nsd  etc.
[11:39] <enyc> !info nsd gutsy
[11:39] <minghua> enyc: You need to file an UVF exception request if you want to get it into gutsy.
[11:39] <ubotu> nsd: authoritative name domain server. In component universe, is optional. Version 2.3.7-1 (gutsy), package size 152 kB, installed size 516 kB
[11:40] <enyc> minghua: o
[11:40] <minghua> enyc: s/UVF exception/Universe New Package Freeze exception/
[11:41] <minghua> enyc: Briefly -- probably too late to ask at this time.
[11:41] <minghua> enyc: It should be automatically imported in the next release (a.k.a. hardy) though.
[11:46] <enyc> minghua: i see ;-)
[11:46] <enyc> minghua: so "Briefly" 'all' debian packages are normally imported into ubuntu one way or another?
[11:48] <minghua> enyc: Yes, at the start of a development cycle.  All main package (i.e. the free stuff) in unstable anyway.
[11:48] <enyc> minghua: got you
[11:49] <minghua> enyc: Which means special care probably needs to be taken for contrib/non-free or experimental packages.
[11:49] <enyc> minghua: actually I would rather that ubuntu supported some of the newer NSD tools (i.e. not bind*) in main but thats another story ;-)
[11:49] <enyc> minghua: yes... some go into multiverse... some may be medubuntu and not in  uubuntu as-such
[11:49] <minghua> Yeah, get it into universe first before talking about main inclusion...
[11:49] <enyc> minghua: ;-)
[11:54] <jussi01> Hmmm, can someone point me to a page that explains the philosofy of why we update every 6 months and not when the app comes out?
[11:54] <jussi01> ie. the release system?
[11:54] <jussi01> Its not I dont understand it, I just want it in writing... :)
[12:01] <\sh> jussi01, what needs to be written? there are several documents about "why is gentoo not enterprise ready", and that's all about it, that's why ubuntu is releasing every six months, or opensuse every year or so...
[12:02] <jussi01> \sh: I was just meaning is there something on the official site (as I cant see it) that explains that we release every 6 months and a breif reason for it??
[12:03] <\sh> isn't anywhere an blog article of Mark about it...hmm
[12:08] <\sh> if anyone has time, and is so nice to sponsor some uploads...please see bug 136544 , bug 136547 and bug 136552 , thx :)
[12:08] <ubotu> Launchpad bug 136544 in etoken "[FTBFS]  etoken " [Undecided,New]  https://launchpad.net/bugs/136544
[12:08] <ubotu> Launchpad bug 136547 in fxload "[FTBFS]  fxload (needs to be synced)" [Undecided,New]  https://launchpad.net/bugs/136547
[12:08] <ubotu> Launchpad bug 136552 in galculator "[FTBFS]  galculator " [Undecided,New]  https://launchpad.net/bugs/136552
[12:10] <\sh> cu later
[12:13] <jussi01> see ya \sh
[12:23] <zakame> quit
[12:44] <emiri_> good morning, someone can advice me to get involved with ubuntu dev?
[12:45] <geser> emiri_: hello, have you read https://wiki.ubuntu.com/MOTU already?
[12:45] <emiri_> no, im going
[12:45] <emiri_> Masters of the Universe?
[12:46] <minghua> (or just read the channel topic...)
[12:49] <emiri_> im reading the MOTU Recruitment page
[12:50] <geser> emiri_: the community cared part from the archive is called universe and the dev responsible for it are called MOTUs
[12:52] <emiri_> i knew universe and multiverse archives...
[12:52] <emiri_> generate a contributor name as 'Masters of universe' from this is little bit funny
[12:52] <emiri_> thats all
[01:37] <DarkSun88> Hi
[02:15] <soren> Could someone set the clock on the new revu machine? It's waaaay off.
[03:06] <bluefoxicy> freaking crashers
[03:07] <bluefoxicy> and damnit the -rt restricted modules don't have the nvidia driver >:|
[03:07] <zakame> what crashers?
[03:09] <bluefoxicy> I don't know
[03:09] <bluefoxicy> my system was hanged this morning
[03:14] <zakame> what were the charges?
[03:43] <emiri_> can anyone add me to patch my first package?
[03:45] <emiri_> I'm having problems in signing changes step
[03:48] <geser> what problem do you have?
[03:49] <emiri_> im following this tuto
[03:49] <emiri_> https://wiki.ubuntu.com/MeetingLogs/openweekedgy/Packaging101
[04:08] <emiri_> i have this problem : apparently doing a patch we need to sign the changes
[04:08] <emiri_> and my home dir .gnupg is owned by root
[04:08] <gnomefreak> emiri_: change the owner
[04:09] <gnomefreak> chmod
[04:09] <geser> emiri_: signing is only important if you want to upload it somewhere
[04:14] <emiri_> there is an option to tell "debuild" command to not sign the changes?
[04:14] <geser> -uc -us
[04:14] <emiri_> thanks I try
[04:20] <emiri_> I have my .deb without signature
[04:21] <emiri_> but I can't no longer clean the source
[04:21] <emiri_> if I do "fakeroot debian/rules clean"
[04:22] <emiri_> I find the following error:
[04:22] <emiri_> Trying reverse patch debian/patches/01-fix-gtk-breakage.patch at level 1 ... 0 ... 2 ... failure.
[04:23] <emiri_> how can I clean the source+patch to do another job?
[04:23] <emiri_> such as a new source package with the changes (for example)
[04:29] <emiri_> there's another way to clean the source?
[04:30] <geser> have you modified the file this patch patches?
[04:31] <emiri_> yes, I have executed the "cdbs-edit-patch" command
[04:31] <emiri_> logged in a console
[04:31] <emiri_> edit and save the file
[04:31] <emiri_> and Control-D
[04:31] <emiri_> after this I have compiled the .deb file
[04:32] <emiri_> now I want to clean the compiled source to make a source .deb
[04:33] <emiri_> thats ok?
[04:33] <geser> should be, I don't see the error right now
[04:34] <emiri_> usually do you use "fakeroot debian/rules clean" to clean the source?
[04:34] <geser> I usually patch and build then the source package and let then a pbuilder build it
[04:35] <geser> you could now save your patch outside the package dir and start from fresh
[04:36] <geser> you need then only to copy back your saved patch to the patches dir again
[04:37] <emiri_> pbuilder build packageName?
[04:39] <geser> pbuilder build package.dsc
[04:40] <emiri_> I try
[04:41] <emiri_> it is instally many packages
[04:41] <emiri_> excuse-me, instally->installing
[04:42] <emiri_> argh!
[04:42] <emiri_> "No package 'gtk+-2.0' found"
[04:42] <emiri_> it may look for libgtk+-2.0
[04:42] <emiri_> but it looks for gtk+-2.0
[04:43] <emiri_> I thing the tuto its a bit out-of-date
[04:44] <emiri_> I have to edit debian/control file?
[04:44] <zakame> libgtk2.0-0
[04:44] <emiri_> thx
[04:48] <geser> emiri_: is that from running configure?
[05:05] <luisbg> IT Crowd 2x2 is out!
[05:05] <luisbg> =)
[05:07] <Fujitsu> Ooh, didn't know 2x had started.
[05:11] <StevenK> Neither did I.
[05:12] <Fujitsu> Probably won't get it in .au for a few months.
[05:13] <soren> ScottK: Thanks for the ack on system-config-samba
[05:13] <ScottK> soren: No problem.  I agree it's something we really need.
[05:14] <Fujitsu> Sounds nice and shiny.
[05:14] <luisbg> =)
[05:14] <ScottK> StevenK and soren: There are a number of UVFe's that I think are reasonable looking for a 2nd ack, so I'd commend the queue to you for a look...
[05:14] <soren> ScottK: First thing Monday morning.
[05:15] <soren> ScottK: I've got a huge backlog of real world shit to take care of after my holiday, too.
[05:15] <StevenK> ScottK: I was planning to sleep, it being 1:20am
[05:15] <ScottK> K
[05:16] <StevenK> ScottK: In other news, http://wedontsleep.org/~steven/requestsync.py
[05:16] <ScottK> Most of them are sync's so now or Monday doesn't may much difference.
[05:16] <StevenK> ScottK: Please test that -k works before I upload it.
[05:18] <Fujitsu> Damn, 2x2 will take >1h :(
[05:25] <ScottK> StevenK: Does not appear to be working for me.  Let me investigate.
[05:27] <StevenK> ScottK: I add -r <keyid> to the gpg command line. I'm not certain if that is the right option.
[05:28] <ScottK> I'm reading man gpg right now and I don't think it is.
[05:28] <ScottK> From that man page that looks like an encryption recipient thing.
[05:28] <StevenK> Doh
[05:29] <ScottK> StevenK: -u
[05:30] <StevenK> ScottK: Since it's a one-char change: the line number in question is 155, s/-r/-u/
[05:30] <ScottK> Yes and it works.
[05:31] <ScottK> You've also got an extraneous debug print statement left in there too.
[05:31] <StevenK> Noted and killed, ta.
[05:32] <ScottK> This is a separate feature request that just ocurred to me...
[05:32] <ScottK> If DEBEMAIL isn't set properly the script dies on the assert myemailaddress
[05:33] <ScottK> It would be handy to trap that error and raise a useful error message.
[05:34] <ScottK> Right now it just says "AssertionError"
[05:34] <ScottK> Maybe something for the next upload ...
[05:35] <StevenK> I haven't uploaded yet, and it sounds like a short change
[05:36] <ScottK> OK.
[05:36] <ScottK> Would you rather just do it or I give you a diff?
[05:36] <ScottK> It'll be ~ 3 lines
[05:38] <StevenK> I've just done it.
[05:38] <StevenK> But thanks for the offer. :-)
[05:38] <ScottK> OK.  Not a problem.
[05:40] <StevenK> ScottK: I'll upload devscripts after I get up.
[05:41] <ScottK> Sounds good.
[05:41] <ScottK> Havd a good night.
[05:41] <ScottK> Havd/Have
[05:51] <ScottK> soren: Are you there?
[05:54] <soren> ScottK: Yes?
[05:54] <ScottK> soren: I'm looking at the samba config thing now.
[05:54] <ScottK> Why XS-Python-Version: current?
[05:55] <soren> Either someone told me to, or I copied it from a similar package.
[05:55] <soren> I packaged it months ago, you see.
[05:55] <ScottK> OK.
[05:55] <ScottK> I see.
[05:55] <soren> It's a good question, though.
[05:56] <ScottK> I've seen Debian Python experts get in deep arguements about what current means/should mean.
[05:56] <ScottK> If the poeple that are writing the tools can't agree on the semantics of current (and it doesn't appear to me that they can), I think it should be avoided.
[05:56] <soren> I still haven't quite wrapped my head around the difference between current and all.
[05:56] <POX_> ScottK: use it if you want to compile pyc files for one Python version only
[05:57] <POX_> it's useful for python applications
[05:57] <ScottK> OK.
[05:57] <POX_> python modules should be compiled for all supported (and installed) Python versions
[05:58] <ScottK> Why would you not want to do the same for apps?
[05:58] <soren> POX_: I just don't quite understand how the statement "I believe this package will work with whatever is current at any given time" is different from "I believe this package can work with any version".
[05:58] <POX_> if app is using /usr/bin/python, why shoul it's modules be compiled for other python versions?
[05:58] <POX_> it's just a waste of space
[06:00] <ScottK> Good morning mohammad
[06:00] <mohammad> Good morning ScottK
[06:01] <mohammad> it seems that the binary of https://launchpad.net/ubuntu/gutsy/+source/ttf-sil-scheherazade has not been generated yet. is that ok?
[06:01] <POX_> soren: the difference is that you will not have pyc files compiled for python2.3, python2.4 and python2.6 if you use python2.5 only
[06:02] <ScottK> mohammad: ttf-sil-scheherazade is now in Binary NEW, this means the source was accepted: https://launchpad.net/ubuntu/gutsy/+queue?queue_state=0&queue_text=&start=0
[06:02] <ScottK> Once the binary is accepted, please file a removal request for ttf-scheherazade
[06:03] <ScottK> POX_: So I guess it's a tradeoff between do you want the app compiled for all installed Python versions versus just one.  Disk space versus performance if someone uses the non-default Python.
[06:03] <mohammad> how can I file this removal request? is there any special form?
[06:04] <ScottK> mohammad: https://wiki.ubuntu.com/MOTU/Removal
[06:05] <ScottK> We'll want to do a revision to zekr removing the dependency first.
[06:05] <ScottK> soren: I guess my view tends to be that disk space is cheap, so why not make .pyc for all installed Python versions.
[06:06] <POX_> ScottK: if someone uses non-default Python version, he will not be able to use this module, other python versions will simply not see it
[06:06] <POX_> if module can be used outside application, sure - compile it for all versions
[06:07] <ScottK> POX_: Thanks.
[06:08] <mohammad> ScottK: Nicolas Spalinger asked me to synch ttf-sil-scheherazade in Ubuntu with http://yosch.org/packages/debian/ . Should I wait until the binary of ttf-sil-scheherazade be accepted?
[06:09] <ScottK> mohammad: Let me look.
[06:09] <yosch> mohammad, ScottK: hi guys
[06:09] <ScottK> Hello.
[06:09] <mohammad> Hello
[06:09] <yosch> actually there are no changes between the package as uploaded to Debian and the one on my personal website
[06:09] <ScottK> OK.
[06:10] <yosch> and thanks for the quick reaction :)
[06:10] <ScottK> If it's in Debian and the upstream source is the same version, it should'n't be a problem to sync it.  I would wait until after it gets out of Binary NEW.
[06:10] <yosch> ScottK: ideally we should aim at reducing the deltas between font packages between Debian and Ubuntu (and other derivatives)
[06:11] <mohammad> yosch: ok, but I think you sent me an email regarding the synch a few minutes ago.
[06:11] <ScottK> yosch: I agree.  In general the smaller the diff with Debian, the better for both Ubuntu and Debian.
[06:12] <ScottK> joing/joined
[06:12] <mohammad> yosch: I think in debian/ttf-sil-scheherazade.defoma-hints Farsi should be replaced by Persian
[06:13] <soren> ScottK: I suppose all would make more sense, then. I've already uploaded it, so I'll wait until it gets through NEW.
[06:14] <yosch> mohammad: sorry. A bit confused here...
[06:15] <ScottK> yosch: mohammad and I argued about this the other day.
[06:15] <yosch> mohammad: the sync was to keep packages similar but the package I see in the queue has an ubuntu tag.
[06:15] <mohammad> yosch: I am a persian native speaker, and as far as I know the official name of our language in English is Persian
[06:16] <ScottK> soren: It's also be nice if you added comments in your patches DP# ...
[06:16] <ScottK> yosch: Once we sync from Debian, that will go away.
[06:16] <yosch> ScottK: OK got it.
[06:18] <ScottK> mohammad: In general, there should be a good reason to maintain a difference between Debian and Ubuntu.  Since yosch is the Debian maintainer, I expect that Ubuntu will respect his choice on this.  So whatever he decides is fine here.
[06:18] <ScottK> Each time there is an Ubuntu unique revision, it means more manual work by people who are already busy.
[06:19] <yosch> mohammad: about the defoma hints. ISO 639-3 is "pes", I see alternate names:  	Persian, New Persian, Parsi, Irani
[06:19] <mohammad> I agree to use the debian package :)
[06:19] <yosch> mohammad: but you're the native speaker, we can change if needed
[06:19] <mohammad> just take a look here: http://osdir.com/ml/misc.persiancomputing/2004-06/msg00158.html
[06:20] <yosch> ScottK: mohammad has nicely agreed to join the fonts team and help the overall font efforts :)
[06:20] <ScottK> Sounds great.
[06:20] <yosch> mohammad: but I admit defoma is still misterious to me...
[06:21] <ScottK> The more of this work gets done in Debian, the better for all of us.
[06:21] <yosch> the goal is to enable the language communities to have good fonts and have packaging that make sense and is easier to maintain long term
[06:22] <yosch> ScottK: yep teamwork
[06:23] <mohammad> yosch, ScottK: I have to go, see you later
[06:23] <ScottK> See you later.
[06:24] <yosch> mohammad: OK bye
[06:38] <LaserJock> hi Nafallo
[06:38] <Nafallo> how much resources is needed for an ubuntuwirebox?
[06:48] <Nafallo> imbrandon: awake? ;-)
[06:50] <Nafallo> would C2D suffice or would C2Q be better? x86 + x86-64 builders
[06:51] <LaserJock> I think anything that boots would suffice ;-)
[06:52] <Nafallo> baah.
[06:52] <Nafallo> if I would do this I would want to do it proper.
[06:53] <LaserJock> Nafallo: maybe send imbrandon an email
[06:53] <Nafallo> probably place the server in the same building where Canonical has their servers as well.
[06:54] <Nafallo> LaserJock: good idea.
[07:02] <Nafallo> do we need ubuntuwire now that PPA is in place btw?
[07:05] <LaserJock> PPA is only i386 and amd64
[07:06] <LaserJock> and I'm starting to wonder if the build queue is going to be a problem
[07:06] <LaserJock> cbx33 uploaded a small package to his PPA yesterday and it took over 2hr before it got to the buildds
[07:06] <geser> and you can't debug an FTBFS on an arch you don't have on PPA
[07:07] <zul> heylo
[07:09] <Nafallo> the box I'm thinking of would be x86 and x86_64 as well
[07:10] <LaserJock> I think anything we get will be put to use
[07:10] <Nafallo> oki :-)
[07:10] <LaserJock> but it might be good to discuss it with a larger set of the team
[07:10] <LaserJock> I personally don't know how much the current machines are being used
[07:11] <Nafallo> agreed, and get pricing before I promise anything :-)
[07:11] <LaserJock> other than I know sparky has been running REVU for us
[07:11] <Nafallo> I think the current machines are offline, no?
[07:13] <Nafallo> 3wared RAID10 with WD RE2 at least.
[07:13] <Nafallo> that is probably as far as my spec has landed :-P
[07:14] <norsetto> hello any and all
[07:15] <Nafallo> and I would make sure it's in the same building as Canonicals racks
[07:15] <LaserJock> wahoo, we are gonna have a good Behind MOTU interview
[07:16] <norsetto> LaserJock: hmmm, I thought they were all good ....
[07:16] <LaserJock> well, they are
[07:16] <LaserJock> but it's been a while
[07:16] <LaserJock> and this will  be a good one
[07:17] <norsetto> LaserJock: is she good looking :-)
[07:18] <LaserJock> no, I wouldn't necessarily call him good looking. I'm sure his girlfriend would though ;-)
[07:18] <zul> argh...baby is on acid or something
[07:19] <LaserJock> ?
[07:19] <norsetto> how is sciovinist spelled? if I have to die for it at least I would like to be able to write it properly
[07:19] <LaserJock> zul: you're giving your baby acid?
[07:20] <zul> LaserJock: hes acting like he is on acid
[07:20] <LaserJock> you guys don't have any pot smokers around do you? :-)
[07:21] <zul> umm...no of course not
[07:21] <norsetto> chauvinist ... who would have thought
[07:22] <norsetto> !jdong
[07:22] <ubotu> jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
[07:22] <jdong> who rang?
[07:22] <norsetto> .me hides behind laserjock
[07:23] <Nafallo> jdong: hi :-)
[07:23] <jdong> hi :)
[07:23] <norsetto> anyone feel like reviewing an easy one on REVU?
[07:24] <Nafallo> jdong: now that you're here. what's a good ubuntuwire box for x86 x86_64 when speaking resources?
[07:25] <norsetto> just in case: http://revu.tauware.de/details.py?upid=197. It should be an easy one
[07:25] <norsetto> zul: thx for the ditto
[07:26] <zul> norsetto: np
[07:27] <jdong> Nafallo: hmm, sorry, I woudln't know....
[07:27] <Nafallo> jdong: thought you built a lot of stuff :-P
[07:27] <geser> Nafallo: it can't never be to big
[07:29] <norsetto> geser: hi there
[07:29] <\sh> hey guys, if anyone has time, and is so nice to sponsor some uploads...please see bug 136544 , bug 136547 and bug 136552 , thx :)
[07:29] <ubotu> Launchpad bug 136544 in etoken "[FTBFS]  etoken " [Undecided,New]  https://launchpad.net/bugs/136544
[07:29] <ubotu> Launchpad bug 136547 in fxload "[FTBFS]  fxload (needs to be synced)" [Undecided,New]  https://launchpad.net/bugs/136547
[07:29] <ubotu> Launchpad bug 136552 in galculator "[FTBFS]  galculator " [Undecided,New]  https://launchpad.net/bugs/136552
[07:30] <Nafallo> geser: I know :-P
[07:30] <Nafallo> geser: but I should be able to afford it as well ;-)
[07:31] <geser> Hi norsetto
[07:32] <geser> \sh: can you subscribe u-u-s the next time so it doesn't get lost?
[07:32] <\sh> geser, u-u-s?
[07:34] <geser> ubuntu-universe-sponsors
[07:36] <norsetto> zul: for bug 131325: just to be sure, is it ok for me to send the package to REVU for review? Or should I wait until the bug report is confirmed?
[07:36] <ubotu> Launchpad bug 131325 in conky "Gutsy uses old version of conky." [Undecided,Fix committed]  https://launchpad.net/bugs/131325
[07:36] <\sh> done
[07:37] <\sh> ok..now switching to windows and fireing up css
[07:50] <xtknight> a package can still be in universe if the maintainer is Ubuntu Core developers ?  i was under impression that these packages would be main but is that not always the case?  Ubotu is saying universe for qt4-qtconfig
[07:51] <norsetto> xtknight: the criteria for the package to be in a certain repository is not related to the maintainer
[07:52] <geser> xtknight: a source package can be in main but a binary package in universe
[07:52] <xtknight> hmm
[07:52] <xtknight> is ubotu giving the location of the src package or the binary package?  since the debdiff would be of the source package qt4-x11?  (ubotu doesn't have qt4-x11 in its memory, though)
[07:53] <xtknight> a bit confused, i guess qt4-qtconfig is the binary and qt4-x11 is the source.  Bug 136425
[07:53] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,New]  https://launchpad.net/bugs/136425
[07:53] <xtknight> i had a debdiff ready just not sure to subscribe ubuntu motu or ubuntu main
[07:54] <geser> ubotu knows only binary package (see also bug #135690)
[07:54] <xtknight> Bug 135690
[07:54] <ubotu> Launchpad bug 135690 in ubuntu-bots "ubotu doesn't handle source packages" [Undecided,New]  https://launchpad.net/bugs/135690
[07:55] <norsetto> xtknight: yes, qt4-x11 is a source package which provides, amongst others, qt4-qtconfig
[07:55] <xtknight> k, packages.ubuntu.com has qt4-x11.  it's universe
[07:55] <LaserJock> I filed a bug against ubotu for that, btw
[07:56] <xtknight> well, it was for dapper.  it's not mentioned for gutsy.  http://packages.ubuntu.com/gutsy/source/qt4-x11
[07:56] <norsetto> xtknight: qt4-x11 is reported in main
[07:56] <xtknight> ok so it was universe in dapper, main for gutsy
[07:56] <norsetto> xtknight: yes, its main for gutsy
[07:56] <xtknight> thanks
[07:56] <norsetto> xtknight: and indeed universe for dapper
[07:59] <norsetto> this package too: http://revu.tauware.de/details.py?upid=200 could do with some reviewing
[08:07] <LaserJock> ok everybody
[08:08] <LaserJock> Behind MOTU is up!
[08:13] <soren> ScottK: I thought the dpatches were pretty self-explanatory, actually. Anything in particular in there that isn't?
[08:18] <ScottK> soren: I could tell what they were from looking at them and the changelog, I just think it's a good general practice to say something in the dpatch comment line.  Not a big deal.
[08:46] <jdong> Lutin: hey are we gonna get ffmpeg medibuntu for gutsy? :)
[08:46] <Lutin> jdong: hopefully yes :)
[08:47] <jdong> Lutin: fantastic
[08:47] <Lutin> jdong: although I don't know when ... we're quite busy with gutsy stuff atm ;)
[08:48] <jdong> Lutin: okay, no rush
[08:58] <ScottK> norsetto: Ping
[09:13] <ScottK> norsetto: There's a new clamav revision from Debian, but with a little changelog fiddling your patch applied, so I'm using it and leaving your name on it.
[09:24] <norsetto> ScottK: as you wish, you can also use your name, I don't mind at all
[09:36] <norsetto> What would you guys say about a package that has its own copy of a library that its already in the repositories (although two different snapshots with some API incompatibilities).
[09:39] <geser> norsetto: for a security point of view the external copy should be used if possible
[09:40] <norsetto> geser: external you mean, the self shipped one?
[09:43] <broonie> No, you want to minimise the number of live copies of the library in the archive.
[09:44] <crimsun> norsetto: meaning don't use the bundled one if at all possible.
[09:44] <broonie> That way if there's a security problem in the library only one copy has to be updated.
[09:47] <norsetto> broonie, crimsun: I'm glad to hear it, it confirms what I think. But let me play the devil's advocate for a moment. In this case, we carry and old snapshot (09/06) while for this package the developer wants to use a more recent snapshot (08/07) otherwise his package will not work (or might not work totally correctly). The problem is that this lib (libspeex) is unstanble, and the API is still in development.
[09:48] <norsetto> broonie, crimsun: would it make sense to update our library too? Should we wait until the API is stable? Or we just impose our version upstream?
[09:52] <norsetto> broonie, crimsun: let me add that our version is in sync with Debian
[09:53] <crimsun> I think it would be very unwise to bundle a snapshot if we were in the 8.04 LTS dev cycle.  Given that we're not, I'm a bit less rigid.  You should assess how risky it will be to bundle a snapshot where the API is known to be a moving target.
[09:56] <crimsun> 1) Despite -backports and -updates being options, we should act as if binary packages will only be installed once and not updated via any mechanism.  Will the program using the libspeex snapshot be stable and useful for 18 months?
[09:57] <norsetto> crimsun: perhaps we can be pragmatic, the supposedly stable api is now in beta, so it could make sense to wait until this is officially released, which should be in time for 8.04
[09:58] <geser> norsetto: given that libspeex1 has some rdepends, it's questionable if updating libspeex is a wise option
[09:58] <crimsun> 2) Since our resources for Universe are limited, remaining synced with Debian's source versions poses less of a risk, generally, than bundling our own.
[09:59] <crimsun> 3) Since speex is a main source package, my opinion is that we should not bundle further updates of our (Ubuntu) own this late in this dev cycle.
[09:59] <crimsun> [to which geser has alluded] 
[10:04] <norsetto> thanks, I think I have enough munitions
[10:08] <norsetto> sorry, I forgot to give the bug number. Its bug 129081; I'm summarising the result of our discussion here, feel free to add to it if you think it necessary
[10:08] <ubotu> Launchpad bug 129081 in ubuntu "[needs-packaging]  Mumble" [Wishlist,In progress]  https://launchpad.net/bugs/129081
[10:20] <xtknight> what should i do about bugs like this?  Bug 136641 and 136643    they say that SVN fixes an issue, does that mean we should update mono to svn, or does it mean we should find which patch fixed the problem and backport it to the current version?
[10:20] <ubotu> Launchpad bug 136641 in mono "Mono: Exception attempting to join IPv6 multicast group" [Undecided,New]  https://launchpad.net/bugs/136641
[10:20] <ubotu> Launchpad bug 136643 in mono "Mono: System.Net.Sockets.SocketOptionName 0xe is not supported at IPv6 level" [Undecided,New]  https://launchpad.net/bugs/136643
[10:20] <LaserJock> xtknight: the latter at this point
[10:21] <xtknight> if i try and work on it, should be "In Progress" and assigned to me?
[10:21] <LaserJock> sure
[10:21] <xtknight> thx
[10:22] <xtknight> LaserJock, now there will probably be two patches for both of these.  do i need to a debdiff for each or should i just do one debdiff and do both at once?  (since if the package is updated my same old debdiff may have trouble applying)
[10:23] <LaserJock> one debdiff should suffice
[10:24] <xtknight> one debdiff that fixes both at once?
[10:24] <LaserJock> yes
[10:24] <xtknight> k
[10:26] <norsetto> LaserJock: I thought BMOTU was out already!?
[10:28] <geser> xtknight: I haven't checked if mono uses a patch system but if yes: put each fix into an own patch but you can provide only one debdiff for both bugs (containing both patch files)
[10:29] <xtknight> geser, ok
[10:34] <norsetto> LaserJock: http://laserjock.us/files/geser_screenshot.jpg => Page not found (geser: only 2 desktops: booooo :-))
[10:36] <cbx33> ping imbrandon
[10:36] <ScottK> norsetto: Uploaded already.  Used your name since you did all the work.
[10:37] <norsetto> ScottK: actually, you did it, but never mind
[10:38] <norsetto> scottK: well, my patch its your stuff (I only added the dependancies changes)
[10:38] <ScottK> norsetto: If you are feeling guilty, expunge your guilt by filing Debian bugs on the differences .... ;-)
[10:39] <ScottK> Wow.  It even built for lpia already....
[10:39] <norsetto> superm1: if you ever read this, your desk is a shame on the hackers category (not even a crust of old pizza....)
[10:41] <norsetto> scottK; hehe, you volunteered already to file that bug :-D
[11:06] <LaserJock> norsetto: where was that link?
[11:07] <norsetto> laserjock: geser's interview I think
[11:12] <norsetto> scottK: do you remember by any chance which executable required libcurl? Can't find any with ldd :-(
[11:13] <LaserJock> norsetto: k, fixed
[11:15] <ScottK> In clamav?
[11:15] <norsetto> scottK: yes
[11:15] <ScottK> norsetto: ^^
[11:16] <ScottK> It was all the ones that I listed the dependency for it (3 IIRC).
[11:16] <ScottK> I confess to guessing on the -dev dependency
[11:17] <prak> is there a piklab on the list?
[11:18] <norsetto> scottK: these 3 then: clamav-freshclam, clamav-milter, clamav-daemon. I didn't check the last two yet, but freshclam seems libcurl free
[11:19] <nixternal> woo, new behind motu :)
[11:21] <ScottK> Hmmm
[11:21] <ScottK> norsetto: clamd definitely died with no libcurl.
[11:22] <norsetto> cesare@desktop:~/clamav/clamav-0.91.2$ ldd /usr/sbin/clamd
[11:22] <norsetto>         libclamav.so.2 => /usr/lib/libclamav.so.2 (0x00002b4091987000)
[11:22] <norsetto>         libnsl.so.1 => /lib/libnsl.so.1 (0x00002b4091c26000)
[11:22] <norsetto>         libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4091e3f000)
[11:22] <norsetto>         libc.so.6 => /lib/libc.so.6 (0x00002b409205a000)
[11:22] <norsetto>         libz.so.1 => /usr/lib/libz.so.1 (0x00002b40923b6000)
[11:22] <ScottK> Maybe it got fixed in the 0.91.2 release.  The 0.91 changelog claimed they had dropped libcurl.
[11:22] <norsetto>         libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00002b40925cd000)
[11:22] <norsetto>         libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00002b40927dd000)
[11:22] <norsetto>         /lib64/ld-linux-x86-64.so.2 (0x00002b4091769000)
[11:22] <joejaxx> norsetto: please use pastebin
[11:22] <norsetto> joejaxx: sorry
[11:23] <ScottK> norsetto: Force remove libcurl and start clamd.  If it doesn't die, then I'll believe ldd.
[11:23] <joejaxx> norsetto: no problem :)
[11:23] <joejaxx> nixternal: where do you see the new behind motu?
[11:23] <nixternal> planet ubuntu
[11:24] <joejaxx> ok
[11:25] <norsetto> ScottK: if I remove libcurl I remove half of my packages too .....
[11:25] <ScottK> OK.  Let me try.
[11:36] <ScottK> norsetto: I see what you mean.
[11:37] <prak> is there a piklab on the list?
[11:37] <ScottK> I'm building a non curl version now.  I should be able to install that on another machine that doesn't have X
[11:37] <prak> for the deb packages?
[11:37] <prak> or any plans of doing so?
[11:37] <ScottK> prak: Are you asking if anyone has packaged it?
[11:38] <prak> yes
[11:38] <prak> or planning to package it?
[11:38] <prak> i used to be able to look it up on adept/synaptic, but can't do it anymore
[11:38] <ScottK> Hmm.  I didn't see it on Launchpad, so I don't think it's packaged.
[11:39] <ScottK> For Gutsy, we are not accepting new packages anymore.
[11:39] <norsetto> scottK: yeah, I've build one too
[11:39] <prak> ScottK: ok
[11:39] <Baby> which package?
[11:40] <ScottK> prak: I don't see a needs-packaging bug either, so I doubt anyone has plans.
[11:40] <ScottK> Baby: piklab
[11:40] <Baby> hmmm it is for pic processors, isn't it?
[11:40] <ScottK> prak: ^^^
[11:42] <Baby> it would be nice to have piklab in debian too, btw
[11:42] <Baby> doesn't seem to be there
[11:45] <geser> MOTU now also maintains packages in Debian?
[11:46] <Baby> nope, afaik
[11:46] <Baby> but i'm interested in PICs :)
[11:46] <norsetto> geser: U = Universe .....
[11:46] <Baby> so I'll probably file an ITP for that
[11:46] <geser> http://packages.qa.debian.org/g/gcc-snapshot/news/20070830T230223Z.html
[11:47] <ScottK> It would be nice if someone would make that stop.
[11:48] <Baby> stop what?
[11:49] <ScottK> doko apparently uploaded something to Debian with MOTU still set as maintainer.
[11:49] <ScottK> doko: http://packages.qa.debian.org/g/gcc-snapshot.html
[11:49] <ScottK> So our mailing list is getting the bugmail.
[11:50] <mr_pouit> ^^'
[11:51] <doko> ScottK: shit happens
[11:51] <ScottK> It does.
[11:57] <Baby> prak: I'll probably package piklab for Debian, I've just emailed upstream about that, so I guess it'll enter Ubuntu afterwards
[11:57] <Baby> if anyone else is interested in packaging it, please get in contact with me :)
[11:57] <prak> Baby: how long do you think it will take?
[11:58] <prak> and will it be in the Debian repository?
[11:58] <Baby> yup
[11:58] <Baby> probably 2 or 3 weeks
[11:59] <Baby> and then whatever it takes to Ubuntu to syncronize with Debian SID
[11:59] <ScottK> For Ubuntu it won't be until after Gutsy releases.
[11:59] <Baby> yup I guess so
[12:00] <Baby> but I don't know how much time that'll be
[12:00] <Baby> piklab seems a really cool program
[12:00] <Baby> i didn't know about it
[12:01] <prak> Baby: it looks like it's the only program which supports my current PIC programmer
[12:01] <prak> in linux
[12:01] <prak> I've been having problems with mplab and PicKit 2 programs in Windows
[12:02] <prak> always freezes
[12:03] <ScottK> Note that once stuff is uploaded to the "Hardy Herron" repositories, it can be backported to gutsy-backports after Gutsy is released.
[12:07] <Baby> prak: once I have it ready, in one or two weeks, we can port it to gutsy and try it in your system if you want
[12:07] <prak> Baby: thank you
[12:07] <Baby> :)
[12:08] <Baby> there's already a quick and dirty package for it, it seems
[12:08] <Baby> so i won't have to start from scratch
[12:14] <prak> what do you mean, Baby?
[12:14] <prak> rpm?
[12:14] <Baby> .deb
[12:15] <Baby> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387703
[12:15] <ubotu> Debian bug 387703 in wnpp "RFP: piklab -- IDE for PIC and dsPIC microcontrollers" [Wishlist,Open] 
[12:15] <Baby> http://www.janw.dommel.be/piklab/i386/
[12:17] <Baby> but it doesn't even have the build-dependencies OK
[12:18] <prak> what do you mean about the build-dependencies?
[12:18] <Baby> if you want to create the binary package from the source
[12:19] <Baby> anyway, enough for today :)
[12:19] <Baby> goodnight all!
[12:20] <norsetto> bye bye
[12:23] <prak> Baby: turns out that i can install a older version of piklab that has a deb package
[12:23] <prak> thanks for your help
[12:29] <norsetto> time to go
[12:30] <norsetto> g'bye all, good luck scottK ;-)