[12:14] <mwolson> persia: i'm pretty sure it's safe to upload the updates, because they depend (and build-depend) on either emacs22 or emacs21 in all cases
[12:14] <mwolson> but if you want to wait, that's fine
[12:15] <persia> mwolson: That makes sense, but I'm not an emacs expert, so I'd prefer to get a second opinion as well before pushing them :)
[12:17] <siretart> persia: from what I've seen the dependencies are all alternative, with preference on emacs22
[12:17] <siretart> persia: I'm about to upload emacs22 to gutsy
[12:17] <persia> siretart: Thanks.  Other than emacs22, they looked clean, so I'll push them in the near future.
[12:18] <siretart> yes
[12:18] <siretart> I was about to upload some of them as well, but decided to focus on emacs22
[12:19] <persia> siretart: Don't let me block (I'm currently waiting for another build-test), just unsub & assign when you're processing so we don't step on each other's toes :)
[12:20] <siretart> sure
[12:20] <siretart> persia: OTH, let's just make sure that the bug gets closed by changelog properly, no need to unsub that wayt
[12:21] <persia> siretart: I like unsubs because assignment doesn't show in the default listing, so that anything shown is a candidate for upload.
[12:22] <siretart> persia: err, if a bug is fixreleased, it won't show up anyway. do I miss something here?
[12:23] <persia> siretart: Just small timing.  Alternately, if a respin of the debdiff is required, it's nice to have it already off the list while waiting for the author to fix the issues.
[12:24] <persia> siretart: Then again, I upload from the list several times daily: the workflow experience may be different for others.
[12:24] <siretart> ah, sure
[12:29] <mwolson> siretart: does "bzr bd" automatically add -rfakeroot when building?
[12:30] <siretart> mwolson: yes
[12:30] <siretart> mwolson: see section Builders in /usr/share/doc/bzr-builddeb/README.gz
[12:31] <mwolson> ah, missed that the first time around
[12:32] <joejaxx> Good Evening All :)
[12:32] <siretart> you can use 'bzr bd -S' to create a source package only
[12:33] <siretart> (sorry, the -sa switch is not implemented yet, you need to workaroud that by specifying --builder='debuild -S -sa -rfakeroot'
[12:33] <RainCT> good night
[12:37] <siretart> good night folks, see you tomorrow!
[12:37] <joejaxx> Goodnight siretart 
[12:37] <persia> mwolson: Just to confirm, if these packages are built against emacs21, they'll still later work properly against emacs22 as well, right?
[12:37] <mwolson> persia: yes
[12:37] <persia> mwolson: Thanks.
[12:43] <persia> Grrr.   sbuild does not choose to parse "|" in Build-Dep-Indep.  Some of these will have to wait...
[12:43] <mwolson> hmm, didn't realize that
[12:44] <persia> mwolson: No worries :)  That's why I try to replicate the buildd environment locally when sponsoring.  Based on the earlier statement, I suspect it will work in a day or two.
[12:45] <persia> mwolson: Alternately, if you're in a hurry, you could respin everything to use emacs21 | emacs22 | emacs-snapshot, but I suspect it's a waste of time, considering that emacs22 will be in soon enough.
[12:45] <mwolson> meh, let's just wait for emacs22 then
[12:46] <mwolson> can sbuild be patched to do the right thing?  i believe this behavior would be considered a bug
[12:50] <persia> mwolson: Perhaps, but you'd probably want to patch in Debian, and it'll be a few releases before the buildds get updated.  Putting a local patch in gutsy just makes it harder to see when the buildds will fail in advance.  My memory is that this has been discussed on debian-devel@ before, and it was decided that the first of the possible packages should be used by the maintainer to show the preferred target against which to build, hence not parsin
[12:52] <mwolson> that last message got clipped after "build, hence not" (overlong line probably)
[12:52] <persia> mwolson: Sorry.  I dislike buffer limits.  "...the first of the possible packages should be used by the maintainer to show the preferred target against which to build, hence not parsing the remaining available packages.".
[12:52] <mwolson> ah
[12:54] <mwolson> well, if it has been discussed before on debian-devel, it's unlikely to change, so i guess i'll have to forget about trying to change it
[12:54] <mwolson> not a huge deal
[12:54] <persia> mwolson: My memory could well be incorrect, or that could have been a discussion by various maintainers that did not involve either the sbuild or buildd maintainers.
[12:55] <persia> mwolson: Also, I believe it was four or five years ago: practices may have changed since then.
[01:26] <mwolson> interesting -- i was just editing the patch manually via Emacs
[01:26] <mwolson> filterdiff might be quicker
[01:29] <persia> mwolson: Isn't there also a diff editing mode that allows you to delete all patches to specific files in emacs, and otherwise make manual editing easy?
[01:30] <mwolson> i don't recall
[01:30] <persia> mwolson: http://atrey.karlin.mff.cuni.cz/~pavel/patch-mode.html
[01:30] <mwolson> diff-mode lets you apply parts of patches and reverse the patch while editing
[01:32] <persia> mwolson: diff-mode sounds interesting as well.  On the other hand, no reason not to use the shell tools :)
[01:32] <mwolson> unless you don't fully trust the tools yet :^)
[01:36] <pochu> hey sacater 
[01:39] <jussi01> hello everyone :)
[01:47] <DarkSun88> G'Night.
[02:45] <leonel> I've made a script to download  Packages.bz2  for  feisty-universe  and  check those packages with the ones in /var/lib/dpkg/status    so I can see what packages I have installed that came from universe and  to see on what can I help patching bugs   
[02:45] <leonel> is there a easy way to know that ?
[02:50] <Fujitsu> leonel: I'm sure you could use grep-dctrl or Synaptic to give you a list.
[02:51] <leonel> Fujitsu: synaptic on a server without X ?
[03:00] <persia> leonel: You might be able to get what you want from grep-dctrl
[03:15] <minghua> http://www.littleubuntu.com/blog/?p=3  # "hidden gem" packages in Ubuntu
[03:15] <minghua> A nice list.
[04:10] <minghua> Fujitsu: debian bug 426953 says we need to upgrade to python-matplotlib >= 0.90
[04:10] <ubotu> Debian bug 426953 in python-matplotlib "Installing python-matplotlib, python-numpy gets removed" [Grave,Open]  http://bugs.debian.org/426953
[04:10] <Fujitsu> minghua: Yep, I'm trying to build it now.
[04:11] <Fujitsu> It nicely FTBFSes (Debian bug #422475), but I think the patch there works.
[04:11] <ubotu> Debian bug 422475 in matplotlib "matplotlib: FTBFS: Missing plugin file _ns_transforms.so: Failing build" [Serious,Open]  http://bugs.debian.org/422475
[04:12] <minghua> Fujitsu: Good luck, I see three RC Debian bugs against the 0.90.x version in experimental.
[04:13] <Fujitsu> minghua: I can't reproduce the GTK one, and the python-gst looks a little strange...
[04:14] <minghua> Fujitsu: Maybe the GTK header one is amd64 only.
[04:15] <Fujitsu> minghua: Possibly. I might check after it builds here on i386.
[04:16] <minghua> matplotlib really needs some love, it seems 2/3 of the Debian uploads are NMUs...
[04:16] <Fujitsu> Yeah :(
[04:26] <DarkMageZ> persia, about my usage of automake1.7 instead of 1.9. would a comment in the bug do or is the reason required in the changelog itself?
[04:26] <persia> DarkMageZ: Either is fine.  This is a good place for discussion.  Did something break with 1.9?
[04:26] <Fujitsu> DarkMageZ: I like to see them in the changelog.
[04:27] <DarkMageZ> i used 1.7 to keep the size of the diff.gz as small as possible.
[04:27] <DarkMageZ> using 1.9 requires too much extra wastage.
[04:28] <persia> DarkMageZ: Ah.  I understand.  I think we probably want to keep the previous migration to 1.9 then.  It might make diff.gz larger, but it should make the debdiff smaller.
[04:28] <Fujitsu> The debdiff is all that matters.
[04:29] <persia> DarkMageZ: https://wiki.ubuntu.com/AutomakeTransition is one of the reasons why updating Automake is preferred.
[04:29] <persia> Fujitsu: Depends on the perspective.  I agree with you, but a mirror admin might not :)
[04:31] <Fujitsu> I care about maintainability, not a few hundred extra kilobytes on a mirror :P
[04:31] <persia> DarkMageZ: Further, if /usr/share/cdbs/1/class/autotools.mk works, you could regenerate at build time, which makes diff.gz small, yet still uses a newer automake.
[04:32] <persia> Fujitsu: Ah.  That's even better: neither the diff.gz nor the debdiff size really matter, just the ease with which future patches are applied :)
[04:32] <DarkMageZ> i've got that in my rules file. but how do i make it regenerate?
[04:33] <Fujitsu> persia: Maintainability is inversely proportional to the size of the debdiff.
[04:44] <DarkMageZ> but if the majority of the debdiff is cleaning up the crap of the old package? then does that reduce the desire for a small debdiff?
[04:44] <Fujitsu> That makes merging from Debian hell, though.
[04:44] <Fujitsu> And a lot of what we do is merging.
[04:44] <persia> Fujitsu: Actually, due to coordination, it allowed a Debian sync, but the debdiff was *huge*
[04:44] <minghua> I agree with Fujitsu.  Unless you plan to maintain the package in the future, or better, push changes to Debian/upstream, a lot of clean up is not worth the hassle it creates for later merge.
[04:44] <Fujitsu> persia: Well, that's OK then.
[04:44] <persia> DarkMageZ: It looks like you set some variables: see /usr/share/cdbs/1/class/autotools-vars.mk for some of the hooks.
[04:44] <persia> I agree entirely with minghua
[04:44] <Fujitsu> I've made a major change to a package in Ubuntu once, and I took over the Debian package a day later.
[04:44] <Fujitsu> In other circumstances it's just not worth the hassle.
[04:44] <Fujitsu> Damn, minghua already said that :(
[04:44] <Fujitsu> persia: This Debian maintainer dropped the package as soon as he saw it had changed to autotools.
[04:44] <minghua> Fujitsu: what was it using before?
[04:44] <Fujitsu> minghua: dh_install, I believe.
[04:44] <Fujitsu> It had no installation mechanism as such.
[04:44] <persia> Fujitsu: Ah.  In that case I prefer to work with Debian QA, or ask for adoption by a team, but that's mostly because of my own ability to commit to long-term maintenance.
[04:44] <Fujitsu> minghua: This is a Python app, so I found autotools a very strange choice.
[04:44] <Hobbsee> hi all
[04:44] <Fujitsu> Hi Hobbsee.
[04:44] <persia> Wouldn't setup.py be the normal solution for python installation?
[04:44] <persia> hi Hobbsee
[04:44] <minghua> Fujitsu: Hmm, yes, in that case setup.py is probably better than autotools.
[04:44] <minghua> Hi Hobbsee.
[04:44] <Fujitsu> minghua: You'd think so.
[04:44] <DarkMageZ> persia, you might be interested in using the first debdiff i built if this is the case then.
[04:44] <persia> DarkMageZ: I'll take a look.  I think I prefer the use of simple-patchsys anyway...
[04:44] <Fujitsu> Why are we introducing a patch system?
[04:44] <persia> DarkMageZ: No, I already didn't like that one :)  Somewhere in-between makes sense.
[05:06] <DarkMageZ> so in english. what do i throw into debian/rules to make it reautotool? i can't seem to figure out that autotools-vars.mk file
[05:09] <persia> DarkMageZ: There are lots of ifneq(, $(VARIABLE)) tests in the file.  If you want to execute the contents of one of those, you need to add a line like VARIABLE := true (or whatever is appropriate for that variable) in debian/rules.
[05:11] <persia> DarkMageZ: For example, you might want DEB_AUTO_UPDATE_AUTOMAKE := 1.9
[05:11] <DarkMageZ> so i'd add that .mk file to the rules and then add whatevervariable := something
[05:12] <persia> DarkMageZ: It might be pulled in by the autotools.mk file.  Try it without the extra include first.
[05:13] <persia> DarkMageZ: Looking at your patch, you might also want to update ACLOCAL, etc.  Depends on what you need.
[05:17] <DarkMageZ> if i'm reading that correctly, then isn't this also automatically adding the new dependencies of automake and autoconf for me?
[05:18] <DarkMageZ> i might need to add $(CDBS_BUILD_DEPENDS) to the build depends?
[05:19] <persia> DarkMageZ: Only if you use CDBS to automatically update debian/control.  This is considered bad, unless you configure it to only be via a manual rule.  I'd stick with manual management of control: it's much less confusing that way.
[05:19] <DarkMageZ> ah, that would explain those control.in files in other packages
[05:19] <persia> DarkMageZ: See http://ftp-master.debian.org/REJECT-FAQ.html for more discussion
[05:37] <DarkMageZ> oh, while i'm thinking about it. has anyone else noticed the serious drop in speed in which build-deps are checked (feisty vs dapper)?
[06:00] <StevenK> DarkMageZ: Using pbuilder?
[06:00] <DarkMageZ> yeah
[06:00] <StevenK> PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
[06:00] <StevenK> Try that in your .pbuilderrc if you're using Feisty.
[06:04] <DarkMageZ> that's about as fast as dapper was :)
[06:06] <DarkMageZ> is there a bug than i haven't managed to find about this regression?
[06:23] <DarkMageZ> ScottK, only on revu? or are you up for reviewing a debdiff against a current package?
[06:26] <ScottK> DarkMageZ: I'll look at a bugfix.
[06:26] <ScottK> What bug?
[06:26] <DarkMageZ> bug #123934
[06:26] <ubotu> Launchpad bug 123934 in libvisual-plugins "[debdiff]  bunch of fixes for libvisual-plugins" [Medium,In progress]  https://launchpad.net/bugs/123934
[06:28] <DarkMageZ> the majority of the patch is removing the to source changes to the makefile.in files which the debian guys did which are now regenerated by autotools.
[06:28] <DarkMageZ>  @ buildtime
[06:28] <ScottK> DarkMageZ: Did you ask persia to look at it again?
[06:28] <DarkMageZ> persia's gone offline
[06:29] <DarkMageZ> and the new patch contains the requested fixes.
[06:29] <ScottK> The size of the diff is pretty impressive (more than I'm up to digging through), so I think not that one for me tonight.  Sorry.  I'd suggest keep working with persia when he re-appears.
[06:30] <DarkMageZ> k. thanks anyways.
[06:32] <Fujitsu> DarkMageZ: Did I miss the reason for dropping back to the original automake1.7 stuff?
[06:35] <DarkMageZ> Fujitsu, i've removed the dropback. but there were 2 good reasons. 1 was to reduce the size of the diff.gz and the other was to dodge a slight issue in the regen.
[06:36] <DarkMageZ> regen is done @ buildtime now and there's a very small patch to avoid the slight issue in the regen.
[06:37] <DarkMageZ> the new diff.gz sits @ under 6KB
[06:37] <Fujitsu> DarkMageZ: The debdiff is what matters.
[06:37] <Fujitsu> The current one still has stuff like:
[06:37] <Fujitsu> -# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
[06:37] <Fujitsu> +# generated automatically by aclocal 1.7.9 -*- Autoconf -*-
[06:40] <StevenK> Fujitsu: Have a look at the .diff.gz size for gnome-applets.
[06:42] <DarkMageZ> Fujitsu, this is true. but it is because the autotooling that the debian guys did to the diff.gz was removed. so it's saying that it's being returned to how it is in the orig.tar.gz.
[06:46] <DarkMageZ> it is now regened @ buildtime so it'll read 1.10.something if built on feisty.
[06:46] <Fujitsu> DarkMageZ: I'd prefer it if that stuff wasn't removed. I don't want to merge a 1.3MiB diff, really.
[06:47] <Fujitsu> .diff.gz size is inconsequential.
[06:47] <Fujitsu> StevenK: No thanks,
[06:50] <DarkMageZ> it's about maintainability. it's easier to work with my version later on than to have to figure out why there are changes against the makefile.in's which get regened over later anyways
[06:50] <TheMuso> Heya folks. What have I missed? :p
[06:51] <Fujitsu> DarkMageZ: It makes merging pretty close to impossible.
[06:51] <StevenK> TheMuso: Lots.
[06:52] <TheMuso> StevenK: I'm sure about that.
[06:52] <ScottK> TheMuso: Lots of packages waiting on REVU...
[06:52] <DarkMageZ> well, i won't be signing it with that mess in the digg.gz there's no point in it being there
[06:52] <Hobbsee> TheMuso!!!
[06:53] <TheMuso> Hobbsee!!!
[06:53] <Fujitsu> Hi Hobbsee.
[06:53] <Hobbsee> hiya Fujitsu 
[06:53] <Fujitsu> DarkMageZ: But there's point in it being in the Debian-Ubuntu delta.
[06:54] <Fujitsu> Um, s/point/no point/
[07:01] <Fujitsu> I see that apport has now started marking its bugs private. Are we meant to unmark them when we confirm there's nothing sensitive?
[07:01] <ScottK> pitti sent mail to -devel and IIRC that's what it said.
[07:02] <minghua> libvisual-plugins has two Debian uploads in total.  I would be rather worried if we differ a lot from Debian without an active maintainer of our own.
[07:02] <Fujitsu> Ah, I hadn't checked -devel-announce today
[07:02] <minghua> -deve-announce, rather
[07:02] <ScottK> Ah, right.
[07:03] <ScottK> Good night all.
[07:03] <Fujitsu> Night.
[07:03] <minghua> ScottK: Yeah, me too.  Many packages I'm interested are in main.
[07:03] <minghua> Night ScottK.
[07:04] <ScottK> StevenK: If you get bored, there's a proposed gnupg upload in Bug #76983.  keescook agreed that the first three should be fixed, but has not reviewed the patches.  geser added the 4th bugfix to the mix.
[07:04] <ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Medium,In progress]  https://launchpad.net/bugs/76983
[08:22] <AnAnt> Hello, could someone REVU this package please: http://revu.tauware.de/details.py?upid=5906
[08:23] <superm1_> AnAnt, I'm not a MOTU, but at a glance I can already see a few things that standout
[08:24] <AnAnt> superm1_: ?
[08:24] <superm1_> in debian/control: you need to make sure the maintainer has an @ubuntu.com address
[08:24] <superm1_> typically ubuntu-motu@lists.ubuntu.com is used
[08:24] <AnAnt> superm1_: ah yes, I forgot that
[08:25] <superm1_> AnAnt, also is this the first revision to make it into Ubuntu?
[08:25] <superm1_> debian/changelog seems to imply other releases
[08:25] <AnAnt> superm1_: I thought I fixed that
[08:25] <AnAnt> superm1_: huh, why do you say so 
[08:25] <AnAnt> ?
[08:26] <AnAnt> it is first revision indeed
[08:26] <AnAnt> what's wrong with debian/changelog ?
[08:26] <superm1_> AnAnt, because putting in things like "removed """" implies there were other releases
[08:26] <superm1_> (which should have been in debian/changelog)
[08:26] <AnAnt> oh !
[08:26] <AnAnt> I made a previous package, but didn't upload it
[08:27] <superm1_> I would just put down "Initial Release" 
[08:27] <superm1_> then
[08:27] <minghua> AnAnt: don't use "-$(MAKE) clean", run your package in a gutsy lintian and it will tell you how to do it correctly
[08:29] <AnAnt> minghua: how ?
[08:30] <AnAnt> lintian /tmp/thwab-lib_1.1.2-0ubuntu1.dsc doesn't say anything about make clean
[08:31] <AnAnt> minghua: hello ?
[08:33] <minghua> AnAnt: Are you using lintian in gutsy?
[08:33] <AnAnt> minghua: nope, feisty
[08:34] <minghua> Well, I said "a gutsy lintian".
[08:35] <AnAnt> what version of lintian is on REVU ?
[08:35] <minghua> feisty, most likely.
[08:36] <AnAnt> can you send me the output of gutsy lintian on my package ?
[08:37] <minghua> AnAnt: http://revu.tauware.de/details.py?upid=5848 has a copy of the message which you can take as a reference
[08:37] <minghua> AnAnt: search for "debian-rules-ignores-make-clean-error"
[08:39] <AnAnt> minghua: thx
[08:43] <minghua> AnAnt: Also, that man page is rather useless.
[08:44] <AnAnt> minghua: well, I was told to make a manpage even if the binary has no options
[08:44] <minghua> AnAnt: does it process any files?
[08:44] <minghua> AnAnt: At least say it doesn't take any options in man page.
[08:45] <AnAnt> minghua: ok
[08:47] <AnAnt> minghua: in which section should I mention that ?
[08:49] <minghua> AnAnt: SYNOPSIS should give a example without options (does it take any file as command-line arguments), I think that would be enough.
[08:49] <minghua> AnAnt: I don't know much about man page though.
[08:49] <AnAnt> minghua: it doesn't take any file as command line args
[08:50] <AnAnt> that's why it just says thwab-lib in SYNOPSIS
[08:50] <minghua> I see.
[08:51] <minghua> AnAnt: I'm not picking on the man page anymore, then.
[08:51] <minghua> Although this doesn't make me feel good about upstream.
[08:51] <AnAnt> minghua: how ?
[08:54] <minghua> Well, just my personal opinion, but -- (1) a user program, executable binary named xxx-lib; (2) a program that takes no options, not even --version and --help.  These make me feel the upstream is not very experienced in programming.
[08:54] <man-di> minghua: I agree
[08:55] <AnAnt> ic
[08:56] <minghua> man-di: Glad I am not alone. :-)
[09:03] <zakame> what's in a thwab?
[09:04] <AnAnt> zakame: meaning ?
[09:06] <AnAnt> can someone remove the thwab-lib incomplete upload ?
[10:44] <AnAnt> Hello, can anyone remove an incomplete upload from REVU's ftp ?
[10:59] <Kmos> AnAnt: ask a motu member
[10:59] <AnAnt> Kmos: who's a motu member here ?
[11:00] <RAOF> imbrandon, crimsun, laserjock, and others all have REVU fixing powers :)
[11:01] <Kmos> AnAnt: check at launchpad.net
[11:04] <Fujitsu> RAOF: Only revu admins can do it.
[11:04] <Fujitsu> I'm a MOTU, and I can't.
[11:04] <RAOF> Fujitsu: I thought the people I named were revu admins :/
[11:05] <Fujitsu> RAOF: Oops, it was Kmos that said that. Sorry.
[11:06] <RAOF> NP :)
[11:06] <AnAnt> Fujitsu: ok, where can I find a revu admin?
[11:06] <AnAnt> oh
[11:07] <AnAnt> crimsun: could you please remove my thwab-lib incomplete uploads ?
[11:10] <AnAnt> Fujitsu: can you REVU this upload http://revu.tauware.de/details.py?upid=5906 ?
[11:26] <Sp4rKy> i'm merging initramfs-tools, someone to check my debdiff ? http://paste.dunnewind.net/15
[11:27] <Fujitsu> william@irranat:~/MOTUing$ rmadison -u ubuntu -s gutsy initramfs-tools
[11:27] <Fujitsu> initramfs-tools | 0.85eubuntu14 |         gutsy | source, all
[11:27] <Fujitsu> Hm.
[11:27] <Fujitsu> That doesn't give the component :(
[11:27] <Sp4rKy> i'm merging from 0.89
[11:27] <Sp4rKy> main
[11:27] <Fujitsu> Sp4rKy: That was my point.
[11:29] <man-di> Sp4rKy: the change in initramfs-tools-0.89/scripts/nfs looks a bit pointless, removing an empty line...
[11:29] <Sp4rKy> yep ^^
[11:30] <Sp4rKy> i asked the debian maintainer about some change (espcially in preinst file)
[11:30] <RAOF> The changelog seems a little wrong, too.  You mention only load "vga16fb on amd64", but also "don't use vga16fb on amd64" :)
[11:32] <Sp4rKy> so i should add 'don't use ...' ?
[11:33] <Sp4rKy> Don't load vga16fb on amd64 either, usplash 0.4-36 fixes things so that we don't need to use it anymore.
[11:33] <Sp4rKy> is it correct ?
[11:33] <RAOF> No, I mean there are two, contradictory entries.  One says "only use vga16fb on amd64 (not i386)"
[11:33] <Sp4rKy> oups yes ^^
[11:33] <RAOF> The other one you have listed :)
[11:34] <Sp4rKy> so the last entry must be removed :)
[11:35] <jussi01> good morning!
[11:35] <jussi01> ScottK: ping
[11:36] <Sp4rKy> RAOF: ok, removed
[11:37] <Sp4rKy> do you see any other things ?
[11:37] <Fujitsu> jussi01: He went to bed 4.5 hours ago.
[11:37] <jussi01> Fujitsu: ok, thanks :)
[11:37] <StevenK> So he should be up now, he has young kids. :-P
[11:38] <Sp4rKy> ^^
[11:38] <RAOF> Sp4rKy: Since it's seriously in main, I'd think you'd be better off in #ubuntu-devel
[11:39] <Sp4rKy> ok, go there so
[11:39] <Sp4rKy> thx
[11:50] <laomao> hi everyone
[11:57] <jussi01> hi laomao
[11:58] <StevenK> Lure: Successfully uploaded packages.
[11:59] <Lure> StevenK: thanks a lot!
[11:59] <StevenK> Lure: No problem!
[12:00] <jekil> hello
[12:10] <Fujitsu> And only 18 are SEP :(
[12:17] <geser> Fujitsu: a large part is the libboost-* transition
[12:18] <geser> another large part is ghc6 related
[12:19] <Fujitsu> And there are a few apache bits floating around.
[12:49] <DarkSun88> Hi all
[01:13] <ScottK> StevenK was right.
[01:14] <persia> ScottK: That's a tautology
[01:14] <ScottK> Yeah, but I was just pointing out that I was in fact up due to a small child.
[01:14] <ScottK> jussi01: What?
[01:15] <ScottK> grujpy/grumpy
[01:15] <jussi01> ScottK: go to bed, Ill talk to you another time. Its not urgent
[01:16] <ScottK> jussi01: I'm up due to the 4 year old and actually not that grumpy.
[01:16] <ScottK> What's up?
[01:16] <jussi01> not much, I was hoping to go through som mnemosyne stuff with you. (copyright stuff)
[01:17] <ScottK> Ah.
[01:17] <ScottK> Well the short version is you need to understand why it got rejected and answer those concerns.
[01:17] <jussi01> ScottK: so no big hurry
[01:18] <ScottK> What I expect you are going to need to do is do an actual code comparison and see if there is, in fact, any code left from the predecessor package.
[01:19] <jussi01> ok
[01:19] <ScottK> If there isn't, then it's copyright info can and should be dropped.
[01:19] <jussi01> ScottK: is there an easy way to do that?
[01:19] <jussi01> some sort of diff program?
[01:19] <ScottK> jussi01: diff would be one.
[01:19] <ScottK> Sorry.  Couldn't resit.
[01:20] <ScottK> resist
[01:20] <jussi01> lol
[01:20] <jussi01> ScottK: I understand... its late.. :P
[01:20] <ScottK> If the file structure is similar, then you could use diff.
[01:21] <ScottK> I think you are going to have to spend some time with the code of both packages to understand if there are structural similarities.
[01:21] <persia> jussi01: Also, be sure to check the copyright on the memaid files: many of them were actually written by the mnemosyne team.
[01:21] <ScottK> I would also grep the names of the memaid people to see if they show up in mnemosyne anywhere.
[01:22] <ScottK> jussi01: I would encourage you to do this work.  It'll be a good learning experience and it'll get your package in.
[01:22] <jussi01> ok, thanks for that, I now have something to go on! 
[01:23] <ScottK> persia: DarkMageZ was around last night (here) with a new debdiff for bug #123934.  I pointed him at you, but you weren't around.
[01:23] <ubotu> Launchpad bug 123934 in libvisual-plugins "[debdiff]  bunch of fixes for libvisual-plugins" [Medium,In progress]  https://launchpad.net/bugs/123934
[01:24] <ScottK> You might have a look.
[01:24] <persia> ScottK: Yep.  Thanks.
[01:24] <DarkMageZ> ScottK, we're talking via pm right now :P
[01:24] <ScottK> Ah.  OK.
[01:28] <jussi01> :)
[01:33] <persia> Just to verify my understanding, could someone else please confirm that we do source maintainer mangling for an $(Debian-revision)ubuntu1 revision, and don't for a $(Debian-revision)build1 revision?
[01:35] <geser> persia: that's how I do it
[01:36] <persia> geser: Thanks.
[01:36] <geser> and dpkg-buildpackage doesn't complain that build1 has no XSBC-O-M field
[01:37] <persia> geser: True, although I'm not sure if that's a intentional feature, or an accidental feature, given the history of that change.
[01:38] <geser> build1 shouldn't have any additional changes made by Ubuntu (besides the new changelog entry) so there should be no need to change the maintainer
[01:40] <persia> geser: That's my reasoning: I'm glad that you concur.  Now to instruct others :)
[01:47] <StevenK> persia: Dear me, flattery much?
[01:56] <jekil> anyone can review please? http://revu.tauware.de/details.py?upid=5896
[01:56] <TheMuso> persia: Did you request an ardour sync
[01:57] <persia> TheMuso: Welcome back.  I hope you've had a good trip.  Yes.  Did you ever figure out the scons issue?  It appears to have occurred again.
[01:58] <TheMuso> persia: No. As I have stated before, it builds here in a local sbuild no problem. I think we need to talk to the build system admins about this one.
[01:59] <persia> TheMuso: I think you're right.  I've a couple other things I want to try, but I'll ping someone Monday CET if I can't find a way to replicate without spamming the repository.
[02:00] <TheMuso> persia: I am just updating my sbuild for gutsy on my powerpc box and will try again, but I feel that it will succeed.
[02:00] <geser> Another package using scons fails to build only on the buildds?
[02:00] <persia> TheMuso: It worked for me with gutsy sbuild on amd64 a couple days ago (when I requested the sync).
[02:00] <TheMuso> Right.
[02:00] <persia> geser: Yep, but in a different way this time.
[02:01] <geser> which package is it this time?
[02:02] <persia> geser: ardour (although I still haven7t fixed aqsis either)
[02:03] <jussi01> persia: do you have time for me atm? (sbuild setup?)
[02:03] <persia> jussi01: I should in 15-20 minutes.
[02:03] <jussi01> persia: no hurry though
[02:03] <jussi01> ok :)
[02:05] <geser> persia: how it is this different this time?
[02:06] <geser> one could upload a package which outputs the config.log if it fails
[02:06] <persia> geser: Rather than being a problem with configure, it fails when trying to get the correct version for pkg-config
[02:08] <persia> DktrKranz: Just to confirm, for the mod-ruby changes, do you mean to delete the old files from debian/?
[02:08] <DktrKranz> persia, I'm checking
[02:08] <man-di> I wonder what is better: 1) file new sync bugs, subscribe u-u-s and close other bug when sync was done/closed or 2) take an existing bug, and sync request and subscribe u-u-s?
[02:08] <man-di> what is the ubuntu way for this?
[02:08] <geser> if it's really the same problem as with xmms2, it's because dash stumbles over an error in the environment and exist independent of pkg-config being there or not
[02:09] <man-di> (I mean for cases where a bug was fixed in Debian)
[02:09] <geser> man-di: I usually to 2) if there is a bug asking for a new version
[02:09] <DktrKranz> persia, I removed every file related to apache 1
[02:09] <persia> man-di: Either works.  I prefer #2 when the bug history is small, and #1 when the bug history is large (and there are many subscribers).  In either case, be sure to retitle and redescribe the bug for the convenience of the archive admins.
[02:09] <DktrKranz> to apache1 package
[02:10] <man-di> is there a way to automatically close other bugs when bug XXXX gets closed?
[02:10] <persia> DktrKranz: Thanks for the confirmation.  The patch only removed the contents of the files, so I'll manually delete the 0-byte leftovers.
[02:10] <geser> man-di: afaik no
[02:11] <DktrKranz> persia, thanks :)
[02:11] <persia> man-di: not really.  Duplicates are hidden by default, but left "open" when the master is closed.
[02:12] <man-di> okay
[02:12] <man-di> seems like there are some bugs in java packages which are fixed in debian and synced to ubuntu a long time ago
[02:13] <geser> persia: do you mind if I upload adour to output the config.log if scons fails to see where the problem is?
[02:13] <ScottK> Kmos: What did you do: https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/001875.html
[02:13] <persia> man-di: That happens often, unfortunately.  There's an open spec for better coordination with Debian bugs, but there's still significant discussion of the best way to handle it.  For now, we've been closing bugs with a comment (Fixed with version X.Y-Z) for reference.
[02:14] <persia> geser: I don't mind, but I'd rather push it against PPA tomorrow to see if I can replicate before we churn the repositories.
[02:14] <TheMuso> persia: Are there any instructions anywhere about using PPA?
[02:14] <man-di> persia: thx for the info
[02:14] <persia> TheMuso: Not to my knowledge.
[02:14] <geser> persia: is PPA using the same build environment as the normal archive?
[02:15] <TheMuso> persia: So how do we use it?
[02:15] <Fujitsu> geser: The buildds are in Xen, but otherwise the same.
[02:15] <Kmos> ScottK: ignore it! i want to merge motu-media with ubuntu-motu
[02:15] <persia> geser: I'm not sure.  I know there is a different queue, but I'm not sure if the buildds are the same or different.
[02:16] <Fujitsu> You upload to incoming.dogfood.launchpad.net:~fujitsu/ubuntu, and it builds on a separate set of extra-isolated Xenified, cleaned-after-each-build buildds.
[02:18] <geser> are the build logs available for PPA?
[02:18] <persia> Fujitsu: Do you know if the configuration is the same?  Should we expect the same scons failures?
[02:18] <Fujitsu> geser: You should be able to look it up in the separate buildd histories, but I don't think they're findable from the package/person pages.
[02:19] <Fujitsu> persia: They're identical, AFAIK.
[02:55] <TheMuso> persia: Latest ardour does build fine in an updated gutsy sbuild for me.
[02:56] <persia> TheMuso: That's annoying.  I'm just prepping gezer's suggestion with aqsis, and if it works as I think it ought, I'll try with ardour as well.
[02:56] <TheMuso> Ok.
[02:57] <geser> persia: I try ardour already in PPA, let's see how it works out
[02:58] <persia> geser: Great.  Let's hope it fails.
[02:58] <geser> Fujitsu: does one get a mail for successful uploads to PPA?
[02:58] <Hobbsee> geser: yes
[02:59] <geser> hmm, then something has gone wrong as I didn't get a mail yet
[03:00] <Hobbsee> then you're probably uploading to the wrong place, or something.  when did you upload?
[03:01] <geser> Hobbsee: 2007-07-07 14:40 ardour_2.0.2-2ubuntu1_source.upload (it's UTC+2)
[03:01] <geser> this makes it 20 minutes ago
[03:01] <geser> Hobbsee: can you paste your dput config for ppa?
[03:02] <Hobbsee> geser: /query me yours?
[03:09] <man-di> hmmm, multidistrotools shows bugs that are invalid
[03:14] <Fujitsu> man-di: It doesn't do any filtering at all. That would be a lot of page requests, and LP doesn't like that.
[03:16] <man-di> Fujitsu: interesting, but I wonder how it found https://launchpad.net/bugs/21029 for libgnumail-java
[03:16] <ubotu> Launchpad bug 21029 in libgnumail-java "libgnumail-java: FTBFS: Semantic Error: No applicable overload was found for a constructor with signature "POP3Connection(java.lang.String, int, int, int, boolean)"" [Unknown,Fix released]  
[03:17] <Fujitsu> man-di: AFAIK it looks at https://bugs.launchpad.net/ubuntu/+source/libgnumail-java/+bugs-text
[03:18] <Fujitsu> And now, I'd better be off to bed.
[03:18] <man-di> Fujitsu: this lists 3 bug numbers but mtd shows only one bug for libgnumail-java
[03:18] <man-di> Fujitsu: have a good nite
[03:19] <Fujitsu> man-di: Hm, that's strange... You might want to look at the code.
[03:22] <man-di> Fujitsu: when I would understand python...
[04:34] <AnAnt> ping crimsun 
[04:50] <PhinnFort> my package isn't showing up on revu
[04:50] <Hobbsee> !revu
[04:50] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[04:50] <Hobbsee> PhinnFort: are you in teh group there?  ^
[04:50] <PhinnFort> Hobbsee: yup
[04:51] <Hobbsee> PhinnFort: right.  which package?
[04:51] <PhinnFort> Hobbsee: bookreader
[04:51] <PhinnFort> and I haven't gotten any nasty mails or anything either (like when I mistakenly uploaded to upload.ubuntu.com;)
[04:51] <AnAnt> Hobbsee: can you remove an incomplete upload ?
[04:52] <PhinnFort> "You are a member of this team."
[04:52] <Hobbsee> PhinnFort: which version were you trying to upload?
[04:52] <PhinnFort> Hobbsee: 2.0
[04:52] <PhinnFort> 0.2
[04:52] <PhinnFort> ;)
[04:52] <Hobbsee> hrm.  wonder why it landed in rejected.  apart from the fact that the 0.1 also did
[04:53] <PhinnFort> well, the first one was kind of broken
[04:53] <Hobbsee> AnAnt: would help if you'd mention the package....
[04:53] <AnAnt> Hobbsee: thwab-lib
[04:53] <PhinnFort> Hobbsee: should I try to upload again?
[04:53] <persia> AnAnt: If you have an incomplete upload that needs clearing, you'll get the best response with something like "Could someone please remove the partial upload of libfoo2.8-0ubuntu1 from REVU".
[04:53] <Hobbsee> PhinnFort: wait 5 mins
[04:53] <Hobbsee> PhinnFort: for it to reprocess
[04:53] <PhinnFort> ok
[04:53] <Hobbsee> and poke me again if it hasnt published in that time
[04:53] <AnAnt> persia: I did so many times today !
[04:54] <PhinnFort> apropos?
[04:54] <Hobbsee> wonder who sabnzbd_0.2.5-0ubuntu1.dsc is
[04:54] <persia> AnAnt: Ah.  Sorry then.  I suspect that the timing was just off (and people are around less on the weekends).
[05:09] <PhinnFort> Hobbsee: no fun :(
[05:09] <PhinnFort> poke, poke
[05:10] <Hobbsee> okay, so why did it move to rejected again?  hmmm.
[05:11] <StevenK> slomo: Gah! dbus-glib 0.74 requires dbus 1.1.1. Didn't you check it was installable before requesting the sync?
[05:11] <AnAnt> Hobbsee: thanks
[05:12] <Hobbsee> AnAnt: no problem
[05:13] <PhinnFort> Hobbsee: what are the normal reasons for a package to get rejected automatically?
[05:14] <PhinnFort> *s/normal/usual
[05:14] <PhinnFort>  /
[05:14] <Hobbsee> PhinnFort: user not in the keyring, normally
[05:15] <PhinnFort> Hobbsee: can you check if I'm in the keyring if I give you the fingerprint?
[05:15] <Hobbsee> i think ther'es more stuffed bits here though
[05:15] <Hobbsee> siretart: ping
[05:23] <PhinnFort> [17:23]  [Away]  siretart is away: not here... - screen detached
[05:24] <Hobbsee> darn
[05:34] <AnAnt_> Could someone REVU this upload: http://revu.tauware.de/details.py?upid=5910 
[05:39] <AnAnt_> Hobbsee: you still do REVUing ?
[05:39] <persia> PhinnFort: Just in case the issue is the keyring, I'm resyncing now...
[05:39] <PhinnFort> oki
[05:40] <Hobbsee> AnAnt_: occasionally
[05:40] <Hobbsee> AnAnt_: when i'm in a nitpicky mood
[05:40] <AnAnt_>  are you in that mood now ?
[05:42] <Hobbsee> no
[05:43] <Nafallo> crimsun: bug 124590 might be something for Tribe 3 when I get one of those machines ;-)
[05:43] <ubotu> Launchpad bug 124590 in Ubuntu "No sound card in Gutsy with D630" [Undecided,New]  https://launchpad.net/bugs/124590
[05:48] <stgraber> Just a new upstream version : http://revu.tauware.de/details.py?upid=5120 if someone has time to review
[05:54] <persia> PhinnFort: Is http://revu.tauware.de/details.py?upid=5913 what you sought?
[05:54] <PhinnFort> hurray!
[05:55] <PhinnFort> yes
[05:55] <persia> PhinnFort: next time should just work.  Sorry for the processing issues.
[05:55] <PhinnFort> no problem at all
[05:55] <PhinnFort> thanks for the help
[06:04] <PhinnFort> does REVU automatically mail me when my package is commented?
[06:04] <Hobbsee> no
[06:23] <siretart> LongPointyStick: huh?
[06:28] <PhinnFort> this would be a darn nice addition to kubuntu gutsy (or later): http://kde-apps.org/content/download.php?content=56982&id=1
[06:34] <sacater> anyone think gutsy is stable enough yet?
[06:34] <PhinnFort> yeah, just release it;)
[06:35] <geser> sacater: for an update from feisty?
[06:36] <PhinnFort> I'm not upgrading before it has KDE 4 packages;)
[06:36] <sacater> geser: mmhmm
[06:36] <stgraber> TheMuso: if you have some time reviewing a pastebinit update : http://revu.tauware.de/details.py?upid=5120
[06:38] <stgraber> sacater: There currently are the apt and openoffice dependency problem, but otherwise it's quite stable (at least here), but keep in mind that you may have a broken X, kernel, ... at any time
[06:38] <sacater> eeep
[06:42] <sacater> stgraber: ty
[06:46] <geser> sacater: if you really want to upgrade look again when the next tribe is due
[06:47] <sacater> k
[06:50] <ScottK> PhinnFort: If you want e-mail of package comments, you have to join http://lists.tauware.de/listinfo/motu-reviewers mailing list (and you get them all, not just yours).
[06:50] <PhinnFort> ScottK: nothing that a filter in KMail won't handle;)
[06:50] <ScottK> Exactly.
[06:52] <sacater> hrm
[06:52] <sacater> my blog posts arnt showing up on planet ubuntu
[06:53] <ScottK> PhinnFort: You might find reading the comments on other packages useful to learn more about what not to do.
[06:54] <PhinnFort> ScottK: I have been peeking around a bit
[06:54] <ScottK> OK.
[06:54] <PhinnFort> ScottK: like setting motu as maintainter, etc.
[06:54] <PhinnFort> should be a list with "Top 10 errors new packagers make" or something, somewhere
[06:57] <ScottK> stgraber: In your debian/changelog, instead of - Closing launchpad bug #119723 "Implement gettext localization" (David Paleino) it should be - Implement gettext localization (David Paleino) (LP: #119723) - LP will "Fix Released" the bugs automatically then.
[06:57] <ubotu> Launchpad bug 119723 in pastebinit "Implement gettext localization" [Wishlist,Fix released]  https://launchpad.net/bugs/119723
[06:58] <stgraber> ScottK: right, will do
[06:59] <ScottK> Also need to update your copyright statements to include 2007.
[07:00] <sacater> anyone know when the next CC meeting is going to be
[07:00] <sacater> it isnt published yet
[07:02] <ScottK> stgraber: Doesn't it need some kind of build-dep for some Python?
[07:02] <stgraber> ScottK: nope, it's a non-compiled software
[07:03] <ScottK> But it is Python, right?
[07:03] <stgraber> yes
[07:03] <ScottK> Why don't you make it a proper Python package then?
[07:04] <stgraber> I had a discussion about that at the beginning and the result was that as this package only provide a single script and it's "short", there was no real need to use all the python stuff as you'd do for a "big" software
[07:06] <ScottK> OK.  Actually all you would need to add would be a very simple setup.py.
[07:07] <ScottK> As it is, you have a Python script here that doesn't seem (at at glance) to comply with the Python policy.  
[07:07] <ScottK> If you had setup.py, you could use cdbs and actually your package would get simpler/smaller.
[07:08] <t3ch> status
[07:08] <t3ch> eh
[07:15] <ScottK> stgraber: Now your missing the empty line between the version/distro line and the first changelog entry in debian/changelog
[07:16] <ScottK> stgraber: In debian/control, Depends: python, ${python:Depends} is excessive.  ${python:Depends} includes python.
[07:22] <stgraber> ScottK: just re-uploaded with above fix, I've re-read the debian python policy and don't see where they talk about a setup.py for a non-module/non-extension .py and I don't really see what a setup.py can do more than copying a file to a dir ...
[07:23] <ScottK> stgraber: Setup.py isn't required.  
[07:23] <ScottK> It'd just make it easier.
[07:24] <ScottK> I'd have to go look again and check, but your script does get installed to the correct location, so it may well be compliant.
[07:46] <ScottK> stgraber: Uploaded
[07:47] <ScottK> stgraber: My final conclusion was unusual, but not wrong.
[07:52] <stgraber> ScottK: thanks
[08:06] <slomo> StevenK: sorry? i have dbus 1.0.1 and it installs fine here
[08:26] <sacater> can anyone help me with my planet-ubuntu thing. Ive set it all up. and the feed is http://sacater.codewiz.net/?cat=3, is there anything wrong with this?
[08:42] <ScottK> A package that can be distributed, but not modified has to go into multiverse, right?
[08:42] <geser> yes
[08:44] <minghua> Actually I doubt it.  What counts as "modified" in its license?  What about repackaging whatever format it's in as .deb?
[08:45] <sacater> grr
[08:45] <geser> minghua: think of qmail
[08:45] <sacater> is there a channel for planet
[08:47] <minghua> geser: Right.  I was more thinking about MS web core fonts though.
[08:48] <minghua> Hmm, can someone maybe ban icf7_?
[08:48] <geser> !ops
[08:48] <ubotu> Help! Hobbsee, Riddell, sladen, or fbond
[08:48] <poningru> woah
[08:48] <joejaxx> yeah
[08:51] <joejaxx> hmm
[08:53] <nixternal> wth
[08:54] <nixternal> argh, who has ops to stop this?
[08:54] <nixternal> oh, I do
[08:54] <Nafallo> lol
[08:54] <nixternal> hehe
[08:54] <man-di> nixternal: hehe
[08:54] <man-di> nixternal: now you jsut need to hit the right time when icf7 is in
[08:55] <joejaxx> nixternal: you are a freenode staffer? :P
[08:55] <Nafallo> just ban him :-)
[08:55] <nixternal> I have his ip, but I need to figure out the banforward channel for bogus routers
[08:56] <nixternal> err
[08:56] <PriceChild> nixternal, that banforward is only for dcc exploitable people...
[08:56] <PriceChild> just do a straight ban
[08:56] <nixternal> bady copy/paste there
[08:56] <nixternal> my lord, the bans I have to remove now :)
[08:56] <Nafallo> that's more like it. thanks.
[08:56] <joejaxx> nixternal: thanks
[08:57] <nixternal> there we go
[08:57] <nixternal> that was insane
[08:57] <nixternal> OK, now to my question
[08:57] <minghua> thanks nixternal
[08:57] <nixternal> what are some decent build specs for a build server?
[08:57] <nixternal> should I focus on memory or cpu?
[08:58] <minghua> what does a build server mean?
[08:58] <Nafallo> minghua: a server that compile stuff :-)
[08:58] <nixternal> a server that will pbuild everything for me, so I don't have to sit here and spend 2 days compiling and building packages
[08:58] <nixternal> like the Ubuntu build boxes
[08:58] <joejaxx> build a cluster :)
[08:58] <joejaxx> :p
[08:58] <joejaxx> j/k
[08:58] <nixternal> it would be nice if I could run multiple builders at once, so possibly a xen config
[08:59] <Nafallo> imbrandon has those things :-)
[08:59] <nixternal> I am on my way to a cluster actually, so that isn't a bad idea either
[08:59] <minghua> I think neither CPU or memory is the main bottle neck for buildd.
[08:59] <joejaxx> nixternal: :)
[08:59] <Nafallo> why XEN for pbuilder?
[08:59] <Nafallo> you can run multiple on a bare system
[08:59] <man-di> using pbuilder for a buildd is too much overhead
[09:00] <Nafallo> but make sure not to use the tarball method :-)
[09:00] <nixternal> well, I can run a pbuilder in each xen session, so if I do 2 dual cores, that would be 4 sessions, as I have seen running 2 pbuilds at once isn't such a good idea
[09:00] <man-di> with sbuild, buildd and wanna-build its cheaper, performace wise
[09:00] <nixternal> I need to check out this sbuild, everyone who uses it speaks highly of it
[09:00] <man-di> and pbuilder handles deps slightly different to sbuild and this can cause issues
[09:01] <imbrandon> nixternal, multi pbuilders is fine, but sbuild + lvm snapshots rock
[09:01] <joejaxx> security?/win las
[09:01] <nixternal> the ubuntu build farm uses sbuild right?
[09:01] <joejaxx> bah
[09:01] <nixternal> imbrandon: my god I am glad you spoke up ;)
[09:01] <nixternal> I thought I was gonna have to go KC Masterpiece on your arse :)
[09:02] <imbrandon> lol
[09:02] <nixternal> imbrandon: is there any doco for sbuild+lvm snapshots?
[09:02] <imbrandon> i just got back from takin my girl to the mall to get her a teddy bear at build-a-bear
[09:02] <imbrandon> fun fun
[09:02] <imbrandon> lol
[09:02] <joejaxx> lol
[09:02] <nixternal> build-a-bear will break-the-bank
[09:02] <joejaxx> go imbrandon 
[09:02] <imbrandon> no doubt
[09:02] <nixternal> I gotta walk around that place when I have my daughter
[09:02] <joejaxx> nixternal: lol
[09:03] <nixternal> last time I tried to walk around it though I landed in front of the apple store...not a good place for a kid either
[09:03] <nixternal> iWant
[09:03] <Nafallo> lol
[09:03] <Nafallo> hi imbrandon :-)
[09:04] <imbrandon> heya Nafallo 
[09:04] <nixternal> iWant might be funny, but not when it leads to iBroke
[09:04] <imbrandon> ltns
[09:04] <Nafallo> indeed is :-)
[09:05] <Nafallo> New work, new life, less time ;-)
[09:05] <imbrandon> hehe same here 
[09:07] <Nafallo> did you know you need a broadband connection, a broadband modem and a networkcable with a RJ-45 connector to make a wireless connection? :-)
[09:07] <Nafallo> I sure didn't :-)
[09:07] <imbrandon> hahaha
[09:08] <ScottK> imbrandon: Build-a-Bear has a nice mailing list you can sign $KIDS up for too.
[09:08] <ScottK> ;-)
[09:08] <imbrandon> ScottK, lol i know, this was like her 4th bear
[09:08] <imbrandon> :)
[09:10] <ScottK> imbrandon: How old is your daughter?
[09:13] <imbrandon> ScottK, 10
[09:13] <imbrandon> well will be 10 in november
[09:13] <imbrandon> going on 21
[09:13] <imbrandon> lol
[09:13] <ScottK> Ah.  You've got another couple of years of build-a-bear then.
[09:14] <imbrandon> yup :)
[09:14] <imbrandon> and thats my oldest
[09:14] <imbrandon> the next is a boy, then nother girl, then aboy ( i have 4 kids )
[09:15] <vijay2000> Hi all 
[09:15] <vijay2000> can anybody tell me what this error means http://paste.ubuntu-nl.org/29030/
[09:16] <ScottK> imbrandon: I have 3: 15, 13, and 4.  Two are past build-a-bear, but one's still a threat.
[09:17] <imbrandon> looks like your package dosent depend on dpatch ( or you dont have it installed if thats not a pbuilder )
[09:17] <imbrandon> vijay2000, ^
[09:17] <vijay2000> ScottK: can you please help me with this http://paste.ubuntu-nl.org/29030/
[09:17] <imbrandon> ScottK, :) i have 9 , 3 , 2, 1
[09:17] <vijay2000> imbrandon: yes imbrandon
[09:17] <ScottK> vijay2000: What imbrandon told you is correct.
[09:18] <vijay2000> imbrandon: i didn't understand what you told
[09:19] <man-di> damn, build-a-bear exists in germany too
[09:19] <Nafallo> what happended to just haveing a dog or cat? bear!? FFS, get real :-)
[09:20] <vijay2000> ScottK: what did imbrandon tell . I didnt understand
[09:20] <ScottK> You need to have dpatch as a build-depend for your package.
[09:21] <vijay2000> ScottK: got it I shall install dpatch
[09:22] <ScottK> Yes
[09:23] <minghua> Rather, you should build depend on dpatch.
[09:24] <joejaxx> minghua: yes based on the control i believe
[09:24] <joejaxx> the control file*
[09:26] <vijay2000> now i get this error when i build http://paste.ubuntu-nl.org/29032/
[09:28] <imbrandon> do you have universe and multiverse enabled in your pbuilder ? and its updated ?
[09:28] <imbrandon> looks not to be
[09:28] <joejaxx> imbrandon: yeah i was just about to ask that :P
[09:28] <joejaxx> :)
[09:28] <vijay2000> imbrandon: universe is updated 
[09:29] <vijay2000> i checked for libxvidcore4-dev
[09:29] <vijay2000> and i get this http://paste.ubuntu-nl.org/29033/
[09:29] <joejaxx> vijay2000: no as in enabled in the pbuilerrc :)
[09:29] <vijay2000> i am not sure 
[09:30] <vijay2000> how to check that 
[09:30] <joejaxx> vijay2000: open /etc/pbuilder/pbuilderrc
[09:30] <joejaxx> and make sure that
[09:30] <joejaxx> #COMPONENTS="main restricted universe multiverse"
[09:30] <joejaxx> is uncommented
[09:31] <joejaxx> then you need to update your pbuilder
[09:32] <vijay2000> how to update the pbuilder
[09:33] <minghua> vijay2000: Read https://wiki.ubuntu.com/PbuilderHowto
[09:33] <vijay2000>  minghua: Thanks 
[09:55] <Qball> Seveas mia again
[10:33] <mohammad> any motu online here?
[10:35] <ScottK> Sure
[10:36] <mohammad> Hello ScottK, thank you for your comments I have applied them all
[10:36] <mohammad> http://revu.tauware.de/details.py?upid=5921
[10:36] <mohammad> ScottK would you please review again ?
[10:36] <ScottK> I'm looking at it now.
[10:38] <ScottK> mohammad: Have a look at http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz paragraph 6.7.8.2.  Since you had to remove stuff from the original tarball, you need to document it as they describe there.
[10:42] <ScottK> mohammad: If you assert a copyright over the packaging, then you have to license it some way.  There's no right to distribute otherwise.
[10:44] <ScottK> mohammad: I'm not sure if combining those different licenses into a single package is workable or not.  I'd prefer to have someone more experienced comment on that.
[10:44] <mohammad> ScottK: So you mean "Debian packaging is (C) 2006, Mohammad Derakhshani" and "This software is Copyright (c) 2004-2007 Siahe.com" should be removed?
[10:44] <ScottK> Switching the Quranic verses to GPL does simplify things considerable.
[10:44] <ScottK> No
[10:45] <ScottK> I mean that if you assert copyright, you need to give permission to distribute.  
[10:46] <ScottK> We (meaning you and someone who knows more about those licenses than I do) just need to figure out the best way to do that.
[10:47] <mohammad> ScottK: thank you. does it have any other problem?
[10:48] <ScottK> mohammad: I don't see any, but I haven't tried to build the package and I got very little sleep right now, so the odds of me having missed something are pretty good.
[10:49] <mohammad> ScottK: Then would you please when you have time build it later ?
[10:51] <ScottK> Possibly.  I about out of Ubuntu time for today.
[10:51] <ScottK> I would encourage you to ask persia about the licensing issues when he's here.
[10:52] <mohammad> ScottK thank you for your help :)
[10:58] <ScottK> mohammad: You're welcome.  Thank you for contributing.  Getting a package (particularly one of the complexity you are attempting) is a lot of work, but many will benifit if you succeed.
[11:26] <geser> keescook: please look at bug #124629
[11:26] <ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,New]  https://launchpad.net/bugs/124629
[11:29] <sacater> on planet ubuntu, my name is down the side as a registered member. but my name links to planet.ubuntu.com. while my feed is correct. I need some help pretty badly with this
[11:30] <mohammad> geser: libcommons-io-java 1.3.1 is in repos now thanks :)
[11:56] <sommer> w