[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<EMAIL_ADDRESS>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.  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!  :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 <IP_ADDRESS>.  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


[00:23] <crayon> hi, why am i banned from the main chan?
[01:04] <elky> ^ no idea
[01:22] <elky> crayon: no idea, you pinged out just over an hour ago and i see no bans. did you try joining again?
[02:06] <crayon> thanks elky, in now...
[02:50] <avis> can i please be unbanned from #ubuntu-offtopic.  the last two times i am banned from there is is for extended periods of time that is never warraranted for the offense.  can you please docuement that ?  thanks
[07:13] <ikonia> @btlogin


[00:01] <chatter29> hey guys
[00:01] <chatter29> allah is doing
[00:01] <chatter29> sun is not doing allah is doing
[00:01] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[08:39] <lotus2418> hi all is it posible to install ubuntu touch on motorola x force? have been searching the web. but cant find any thing.. was hoping because is runs the same software like nexus phones
[18:29] <vortic> hi!


[22:42]  * phillw my apologies for DragonEyes keep dropping off the channel. I'm having connection issues. Two things are planned, 1) Relocate the router, 2) move DragonEyes to a server. Please bear with us as we get this done.


 thank you
[01:18] <lool> pitti: I bisected udev; thanks for the idea!  it was rather painful as I've hit many different races during boot, but the revision which caused me to be dropped in an initramfs prompt was "libudev: monitor - use SOCK_NONBLOCK"
[01:18] <lool> pitti: Unfortunately, I've build 171 ubuntu1 + this patch reverted, and my system wouldn't boot, one error message on screen related to dmsetup
[01:18] <lool> pitti: I wanted to mention that I use LVM
[01:19] <lool> pitti: During tests, I've hit races with mountall and fsck checks, it was hard to tell whether it was another regression from 171 or an already existing bug which just got more visible
[01:22] <lool> pitti: after looking at the other commits, I can't see another one in 171 which would introduce more races (except the above SOCK_NONBLOCK); the rest is mainly changes to symbols and to the systemd configs
[01:54] <lool> pitti: Ok; fixed my system now: both your ubuntu2 with the reverted 171 changes and my 171 ubuntu1 + reverted broken commit from bisect were failing to boot in strange ways; only some LVM volumes were brought up, /home was missing; I disabled the /home volume and enabled it again, and everything worked with both your ubuntu2 package and with my 171ubuntu1 + reverted broken commit
[01:55] <lool> pitti: So the bisected commit was the right one can be patched on top of latest udev
[01:55] <lool> I'm pushing a package to my PPA for others to test
[02:03] <Keybuk> I wonder why that breaks things
[03:41] <cdbs> lool: So the udev fix is now in the archive?
[03:42] <cdbs> Even I get an initramfs shell at boot
[03:46] <cdbs> okay, pitti reverted those
[05:25] <Gacy> http://www.blogtalkradio.com/billywalshe/2011/06/01/youre-too-chicken-shit-to-call-into-this-radio-show?ie8c=0
[05:26] <micahg> !offtopic | Gacy
[05:26] <micahg> that wasn't what I expected that to do...
[05:26] <Gacy> oh
[05:26] <micahg> second part applies though
[05:33] <pitti> Good morning
[05:33] <stgraber> morning pitti
[05:34] <StevenK> Hai pitti
[05:34] <pitti> lool: ah, thanks for bisecting
[06:08] <TheMuso> c
[06:27] <pitti> lool: I changed the udev bzr back to 171 plus SOCK_NONBLOCK reverted, but I'll upload it after a1 only; once Kay is up, I'll discuss with him
[07:08] <micahg> if I"m going to have an armel specific  version of a source package, should I append -arm or -armel?
[07:15] <infinity> micahg: Ideally, you shouldn't have one at all...
[07:15] <infinity> micahg: What's the scenario that's preventing you from shipping a patch in the regular source package and only applying it for ARM?
[07:15] <micahg> infinity: I know, it's a special case :)
[07:15] <infinity> micahg: Or having ARM-specific rules in debian/rules, etc?
[07:17] <StevenK> micahg: And if you're having an armel specific version of the source, are you going to Conflict with the non-armel, or change them too? What about the rdepends?
[07:17] <StevenK> This is a rabbit hole.
[07:17] <micahg> no, it's for chromium, since the arm build takes over a day and we have no advanced notice, I split the source in the stable release so we can get the non-arm binaries out faster
[07:17] <infinity> micahg: Err, but we release everything at once anyway.  I'm failing to see how this helps...
[07:18] <infinity> micahg: If glibc and gcc get to suffer, so does chromium?
[07:19] <micahg> I didn't really want to start the why debate...but in short, there's no USN so they can be published as they're ready
[07:19] <infinity> micahg: Which is true even if you release while ARM is still building...
[07:19] <micahg> infinity: no, you can only copy a source once
[07:20] <infinity> micahg: Yes, and?
[07:20] <infinity> micahg: You can then release the binaries later.
[07:20] <infinity> micahg: We've been doing that for years.
[07:20] <micahg> infinity: no, the binaries + source can only be copied once
[07:20] <infinity> micahg: I suspect I'm not the person you want to argue with about this.  At all.
[07:20]  * micahg didn't want to argue with anyone
[07:21] <infinity> micahg: You can release binaries for architectures whenever you feel the urge.
[07:21] <infinity> micahg: A USN could, in theory, be source-only, if someone thought that was a sane thing to do (which it isn't), and you could trickle the arches down one at a time.
[07:21] <micahg> soyuz doesn't work like that AFAIK
[07:21] <infinity> It really does.
[07:22] <sbeattie> infinity: that's not what the security team's been told.
[07:23] <infinity> sbeattie: They were lied to.  Or there was a miscommunication.
[07:23] <infinity> sbeattie: Either way, I don't see us splitting other long-building packages for the sake of one slow arch.  Still not seeing the unique snowflake case.
[07:24] <infinity> sbeattie: But at the level we're dealing with here, BPRs are all tied to SPRs, yes, but there's no reason you need to move/copy all the BPRs with an SPR.
[07:25] <dholbach> good morning
[07:26] <wgrant> infinity: Due to the current way that security updates are unembargoed, that's not really possible at the moment.
[07:26] <wgrant> We should be able to.
[07:26] <wgrant> It's easy enough to do.
[07:26] <wgrant> Just need to expose the interface.
[07:26] <wgrant> But we've not been asked with any significant importance.
[07:27] <wgrant> micahg: So, please ask for LP to be fixed before you start implementing such hacks!
[07:27] <infinity> wgrant: I suspect the above is significant enough, before people get unique snowflakey more. :P
[07:27] <wgrant> infinity: Probably.
[07:27] <infinity> wgrant: What's the issue?  I only vaguely recall the security-on-PPA hackery (I was doing security when it was a proper pocket)... Are the SPRs moved/wiped with a release?
[07:27] <wgrant> Basically, delayed copies are a vile hack.
[07:27] <infinity> wgrant: Thus leaving the BPRs effectively orphaned?
[07:27] <micahg> wgrant: I thought I talked to the relevant parties, I guess I forgot to chat with you about it :)
[07:27] <infinity> wgrant: Cause that's about the only way I could see it breaking.
[07:28] <micahg> wgrant: they're not in the private PPA
[07:28] <wgrant> micahg: Unless you talked to bigjools or me or possibly Stevenk, you were probably misinformed.
[07:28] <wgrant> infinity: So, there are two ways this breaks:
[07:29] <wgrant> 1) The copy checker will forbid copies when the source has pending builds, because multi-stage copies don't work very well. This can be easily fixed once multi-stage copies are.
[07:29] <infinity> wgrant: (1) isn't an issue, it's a tool that needs unbreaking. :)
[07:29] <wgrant> 2) Delayed copies (used for private copies) create a fake PackageUpload, and more than one of those for a single source won't be accepted into a particular suite.
[07:29] <wgrant> 2 will go away once StevenK deletes delayed copies in a few weeks.
[07:30] <wgrant> 3) The copy APIs provide no facility to copy binaries, only sources. And they're not set up to copy only missing things.
[07:30] <wgrant> Well, for binaries it already mostly works. It won't create duplicate publications.
[07:30] <wgrant> But it will republish the sources and break a few worlds.
[07:30] <infinity> Republishing source is a non-issue, IIRC.
[07:31] <infinity> It just no-ops at the level that any human cares about it.
[07:31] <wgrant> It will create a new publication.
[07:31] <wgrant> It might not break much, but it's undesirable.
[07:31] <wgrant> and easily fixable.
[07:31] <infinity> Well, see the "any human" bit. :)
[07:31] <wgrant> Heh.
[07:31] <infinity> Pretty sure we used to do it all the time.
[07:31] <infinity> And if it made Soyuz cry, Celso never slapped me.
[07:31] <wgrant> infinity: Pre-s-i-s, maybe.
[07:32] <wgrant> Or back when the copier was less pedantic.
[07:32] <wgrant> It was made more bullet-proof to stop PPA users from killing themselves.
[07:32] <micahg> wgrant: so, should we have a longer chat later today?
[07:32] <infinity> Hahahaha.
[07:32] <StevenK> You mean back when the package copier was er, Celso?
[07:32] <infinity> But yes, I'd love to see people not attempting these crazy hacks.
[07:32] <wgrant> micahg: I think so.
[07:32] <micahg> wgrant: what time do you start (UTC)?
[07:32] <wgrant> micahg: This is a reasonable thing for a maintenance squad to take on in a post-critical era (probably Septemberish)
[07:32] <infinity> StevenK: Well, okay, there was a time when copying packages was actually some SQL hacks that I'd do.
[07:33] <infinity> StevenK: But no, I vaguely recall having something more fancy.
[07:33] <wgrant> micahg: 2300-0800 are my coreish hours.
[07:33] <wgrant> micahg: But I'm often floating around several hours later
[07:33] <wgrant> infinity: Sure you're not recalling the wonderful dak hack?
[07:33] <micahg> wgrant: ok, feel free to grab me when you start tomorrow, I should be around
[07:33] <infinity> wgrant: No, that would be entirely different.
[07:33] <wgrant> micahg: Will do.
[07:34] <micahg> wgrant: thanks
[07:34] <infinity> wgrant: With DAK, it was a series of real uploads.
[07:34] <wgrant> infinity: Yeah :/
[07:34] <infinity> wgrant: But I'm talking pocket copying, versus PPA->pocket insanity which SiS uses.
[07:34] <infinity> wgrant: And I'm pretty sure pocket copying, and triggering source republishing, and other fun arch-skew issues were a non-issue, in practice.
[07:34] <wgrant> infinity: Ah, that must have been before the pedantry.
[07:34] <infinity> wgrant: Though I can see how they're irksome in theory.
[07:35] <wgrant> infinity: Now it will outright forbid those copies, because there are builds in the wild.
[07:35] <wgrant> (somewhat draconian, but the copier is a mess and doesn't handle duplication perfectly)
[07:35] <infinity> wgrant: I'd respectfully claim that's broken. :P
[07:35] <wgrant> It's all being cleaned up at the moment.
[07:35] <wgrant> Which will make it feasibleish to fix in a few months.
[07:35] <infinity> wgrant: Since BPRs have no relation to SPRs as a whole unit, only as a related child.
[07:36] <wgrant> infinity: Right.
[07:36] <wgrant> infinity: But it's a bit messy.
[07:36] <infinity> wgrant: Story of Soyuz's life, yes. ;)
[07:36] <wgrant> infinity: Because normally on a copy we create missing builds in the target.
[07:36] <wgrant> infinity: For multi-stage copies we'd have to suppress that.
[07:37] <wgrant> Basically, binaries are messy, everyone should just use source :)
[07:37] <infinity> wgrant: Copies creating builds in the target should probably be the exception, not the rule.  Source-only copies (say, in PPAs), and new-release mass copies.
[07:37] <StevenK> wgrant: Who do you think we are, Gentoo?
[07:38] <infinity> wgrant: (And yes, that's an argument I probably should have made years ago)
[07:38] <wgrant> infinity: I was about to say ENOT2006
[07:38] <StevenK> infinity: i-f-p does not use the package copier, thank $DEITY
[07:38] <infinity> wgrant: Because the "copy-creates-build" semantic is just as broken if you have an FTBFS in security and then copy to updates and create an updates build, for instance.
[07:38] <infinity> wgrant: Which you really don't want.
[07:38] <wgrant> infinity: Yes.
[07:39] <wgrant> infinity: I have long argued that this needs to be rethought.
[07:39] <wgrant> But it's hard, particularly in the new structure.
[07:39] <wgrant> (there is no Soyuz team)
[07:39] <infinity> I'll bottle some essence of cprov and mail it to you.
[07:39] <wgrant> Heh
[07:40] <infinity> StevenK: Except, note the irony that i-f-p is one of the few times when you DO want builds created. ;)
[07:40] <StevenK> Heh
[07:40] <wgrant> infinity: ... and it doesn't!
[07:40] <wgrant> queue-builder used to.
[07:40] <infinity> Yup.
[07:40] <wgrant> But we destroyed queue-builder.
[07:40] <wgrant> Because it is evil.
[07:40] <infinity> I remember painful q-b runs after opening a new release.
[07:40] <wgrant> Heh.
[07:41] <StevenK> Oh, that took many hours?
[07:41] <infinity> It would take a whole day at UDS.
[07:41] <StevenK> Ugh
[07:41] <wgrant> queue-builder took 30 minutes even in a good case.
[07:41] <infinity> I'd keep popping open a screen session to tell people "no, not there yet".
[07:41] <infinity> Good times.
[07:41] <infinity> FSVO "good".
[07:42] <StevenK> Haha
[07:50] <wgrant> Hmm, using karma for search works pretty well.
[07:54] <didrocks> good morning
[07:56] <pitti> $ sudo rm -r /home/dchroot/dapper/
[07:57]  * pitti sheds a tear
[07:57] <pitti> dragon vs. duck anyone?
[07:57] <wgrant> Oh, already? I thought it was next week.
[07:57] <wgrant> Sad.
[07:58] <infinity> Poor Dapper.
[07:58] <wgrant> Means we can upgrade the buildds, yay.
[07:59] <pitti> wgrant: yes, but as we don't have a pending tzdata update, I don't need it any more
[07:59] <infinity> To?
[08:00] <infinity> wgrant: Unless CAT has an urge to start supporting their own kernels again, I imagine the thing stopping buildds from being upgraded is the lack of Xen dom0 kernels in newer releases.
[08:00] <infinity> (But that's just speculation)
[08:02] <wgrant> infinity: Yeah, dom0 will stay on hardy, but I don't care about dom0.
[08:02] <wgrant> launchpad-buildd doesn't have to work there.
[08:02] <infinity> wgrant: Fair point.
[08:24] <jaap_> goodmorning
[08:24] <jaap_> i'am trying to install FTjam
[08:24] <leoquant> goodmorning jaap_
[08:25] <jaap_> i don't can use the software center of install by apt-get
[08:25] <jaap_> i  need to changes some string in the software
[08:26] <leoquant> so you are modifying software to improve it
[08:27] <jaap_> yes to compile argyll
[08:28] <leoquant> ok seems difficult  ツ
[08:31] <jaap_> hello??
[11:28] <hrw> pitti: https://launchpad.net/ubuntu/+source/gcc-4.6-armel-cross exists now. can I get PPU permissions for it (as it was given me by DMB)?
[11:28] <hrw> pitti: package got uploaded into NEW queue
[11:39] <hrw> cjwatson: archive administration page lists you as today's admin. can I get gcc-4.6-armel-cross from NEW to archive? I can answer any questions about package.
[11:53] <lool> dholbach, jibel: https://launchpad.net/~lool/+archive/ppa/+build/2539347 (amd64) https://launchpad.net/~lool/+archive/ppa/+build/2539348 (i386) has udev 171 + reverted patch; it fixes the boot with real 171 for me
[11:55] <lool> pitti: You mentioned udev' bzr this morning, but yesterday it was failing to import http://package-import.ubuntu.com/status/udev.html#2011-05-16 09:17:00.101675
[12:05] <cjwatson> hrw: I'm on holiday today
[12:10] <hrw> cjwatson: sorry then
[12:10] <pitti> lool: I meant the ubuntu package branch at https://code.launchpad.net/~ubuntu-core-dev/ubuntu/natty/udev/ubuntu
[12:10] <pitti> hrw: added
[12:14] <hrw> pitti: thank you
[12:24] <dholbach> lool, confirmed
[12:31] <lool> dholbach: cool, thanks
[12:31] <lool> pitti: ^
[12:41] <pitti> lool: do you have any idea what actually happens in the initramfs? is udevd running? does udevadm info --export-db work, for example?
[12:41] <pitti> it certainly seems to be a race condidtion, as it doesn't happen everywhere
[12:58] <lool> pitti: No, I didn't know how to debug this much; I saw that some devices by UUID had been created, I'm getting messages from udev that it can't open /dev/null and such, so it's definitely being started
[12:59] <lool> pitti: if you like, we can try investigating together
[12:59] <pitti> I'd still love to be able to reproduce this
[12:59] <pitti> I still didn't try installing the faulty udev on my mini 10
[13:00] <pitti> kvm and my laptop work
[13:00] <lool> pitti: are you using lvm?
[13:00] <pitti> lool: no, just plain ext4 /
[13:00] <lool> dholbach, jibel: You folks using LVM?
[13:00] <pitti> I think jibel reproduced it with the faulty desktop iso
[13:03] <soren> Where can I find a list of things that changed in python 2.7.2? I have a test case that fails under 2.7.2, but works under 2.7.1.
[13:05] <soren> Err.. /me tries in #python instead
[13:07] <jibel> lool, pitti , right, default desktop install with the faulty iso.
[13:19] <alkisg> Hi, in bug #737728 I put a "verification-done" tag but it was removed and "verification-needed" was inserted without explanation. Why? Is it some kind of meta-bug which needs some special form of verification? If so, how can I identify such bugs so that I don't put tags on them?
[13:29] <pitti> alkisg: kernel is special, only the QA team signs them off
[13:29] <alkisg> pitti: so when I see verification-needed in kernels, I shouldn't put verification-done, right? Thanks.
[13:29] <pitti> feedback is still appreciated, of course
[13:29] <pitti> alkisg: well, for "real" kernel bugs you are welcome to
[13:30] <pitti> just not for the tracking meta-bugs
[13:30] <alkisg> Got it. Thanks for the explanation.
[13:45] <mterry> @pilot in
[14:01] <pitti> mterry: happy flying
[14:01] <mterry> pitti, :)
[14:05] <sladen> my goodness. soft freezes already
[14:05] <sladen> development moves fast
[14:07] <Laney> still looks like a long way if you look at the release schedule :-)
[14:13] <dholbach> lool, kvm
[14:16] <lool> dholbach: kvm or lvm ? :-)
[14:16] <\sh> moins
[14:17] <dholbach> lool, whatever natty qemu-kvm gives me
[14:18] <lool> dholbach: ok
[15:44] <achiang> chrisccoulson: what does the ~mfs mean in this version string? 4.0.1+build1+nobinonly-0ubuntu<IP_ADDRESS>~mfs~lucid1
[15:56] <EtienneG> Looking for the release schedule of the lts-backport kernel, wondering whent he natty one will show up in lucid.  Anybody know?
[16:05] <pitti> ScottK: what kind of shrinking did we use to do in pkg-kde-tools' cdbs rules?
[16:06] <pitti> ScottK: we recently moved the remaining ubuntu specific bits of gnome.mk/debhelper.mk to pkgbinarymangler, seems we should just add the KDE bits there as well?
[16:09] <JontheEchidna> pitti: lzma compression
[16:11] <JontheEchidna> might need to be added to the new dhmk magic from Debian
[16:13] <JontheEchidna> pitti: Yeah, this chunk is in the old debian-qt-kde.mk but not in the new one: http://paste.ubuntu.com/615911/
[16:16] <JontheEchidna> oh, but it also uses the kde.pm sequence, which should include lzma compression there....
[16:21] <ScottK> JontheEchidna: I think we need to look and make sure.
[16:21] <ScottK> pitti: Is the changelog symlinking in the pkg-binarymangler now?
[16:25] <sladen> doesn't each symlink still take up a full block on the disk?
[16:26] <pitti> ScottK: yes, it is
[16:27] <pitti> sladen: depends on the file system; but certainly not in .debs or the squashfs
[16:28] <ScottK> pitti: We may be OK then if the lzma situation is good.  Fortuitous that you moved stuff.
[16:40] <mterry> @pilot out
[16:44] <JontheEchidna> ScottK: we seem to have pulled GTK in to the CD via libcanberra0
[16:44] <JontheEchidna> that is at least part of our space problems
[16:44] <ScottK> JontheEchidna: Ah.  Well that would do it.
[16:44] <ScottK> So we can work on that for Alpha 2.
[16:44] <ev> mvo: can you point me in the direction of this GIR wrapper you were talking about earlier?
[16:45] <JontheEchidna> apachelogger: ^
[16:47] <mvo> ev: bzr+ssh://bazaar.launchpad.net/~kamstrup/%2Bjunk/giraffe/
[16:48] <ev> mvo: thanks!
[16:48] <mvo> yw
[16:53] <apachelogger> JontheEchidna: oh good
[16:53] <apachelogger> JontheEchidna: you should split the gtk stuff out :P
[16:54]  * apachelogger will likely not have time until tomorrow afternoon
[16:54] <JontheEchidna> it's not a priority for alpha1, so there should be plenty of time for you to fix it :P
[16:55] <apachelogger> JontheEchidna: oh, ok
[16:56] <apachelogger> JontheEchidna: I have an upload pending for libcanberra anyway
[16:56] <JontheEchidna> cool
[16:56] <apachelogger> I'll do the changes on my way to randa and upload past alpha
[16:56] <JontheEchidna> apachelogger: technically I think the GTK stuff is already split out, but libcanberra0 depends on the gtk package
[16:56] <apachelogger> IIRC it should only depend on glib
[16:57] <apachelogger> it was particularly designed to not depend on arguable stuff :P
[16:57] <JontheEchidna> well somehow libcanberra-gtk0 made it on to the CD :P
[17:08] <apachelogger> JontheEchidna: maybe it likes us
[19:11] <smoser> ok. i'm looking at build output of a ubuntu cloud image: http://uec-images.ubuntu.com/lucid/20110531.1/
[19:11] <smoser> this image was built yesterday, but did not receive 1.1.1-2ubuntu5 from lucid-updates.
[19:12] <smoser> instead it received 1.1.1-2ubuntu2 (release).
[19:13] <smoser> it *did* get other things from -updates. looking at https://launchpad.net/ubuntu/+source/pam it looks like maybe there was just a bad-timing snafu in correlation with security update 1.1.1-2ubuntu5.3 .
[19:13] <smoser> anyone else able to explain that ?
[19:23] <geser> doko_: is the "python3.2-config --ldflags" behaviour correct with including the libs to link too? ("python3.2-config --libs" just lists the libs as expected)
[19:36] <slangasek> smoser: there was a severe SRU regression in pam yesterday that led to 1.1.1-2ubuntu5.2 being marked unreadable to block the damage from spreading
[19:37] <ScottK> So that means 'feature.  not-a-bug.'
[19:37] <slangasek> smoser: as a result, apt would probably have fallen back to the release pocket during that window, since 1.1.1-2ubuntu5.2 was unavailable, 1.1.1-2ubuntu5.1 was superseded, and 1.1.1-2ubuntu5.3 was not yet available
[19:37] <smoser> slangasek, thank you. bad timing then for me :-(
[19:39] <mdeslaur> smoser: sorry for that. my bad.
[19:40] <lifeless> smoser: hi
[19:40] <lifeless> smoser: jkakar says you've worked with / build a highly component-based thing before
[19:41] <lifeless> smoser: in Launchpad we're just starting down a migration to such a setup, and I'd like to tap your knowledge, if I may :)
[19:41] <elmo> lifeless: i thought that was smagoun?
[19:41] <smoser> "highly component based thing"
[19:41] <lifeless> hahhha
[19:41] <lifeless> smoser: sorry.
[19:41] <smoser> whew
[19:41] <lifeless> smoser: E-EARLY-MORNINGS
[19:41] <lifeless> elmo: thank you
[21:09] <sebner> persia: I'm wondering if you ever become DD (thinking about your #1 bug) :P
[21:15] <psusi> persia: could you get around to adding me to universe-contrib per last week's DMB?
[21:20] <geser> psusi: done
[21:21] <psusi> geser: yay!  thanks!
[21:21] <Laney> we have been naughty on the minutes
[21:23] <geser> Laney: we (DMB) should perhaps update the team description for https://launchpad.net/~ubuntu-dev a little bit
[21:23] <Laney> geser: yeah, and rename https://launchpad.net/~universe-contributors to UCD probably
[21:27] <geser> Laney: if I didn't miss anything only the bzr package set and PPU for John Rigby needs to be done from the last meeting
[21:34] <Laney> not sure, I haven't been following the outcomes
[22:24] <dart> Hello, I am experiencing some regression after a new natty SRU but I am not 100% sure
[22:25] <jdstrand> dart: what is the regression?
[22:26] <dart> after a fix to this bug --> Bug #774938, My pointer has started behaving oddly. I have also commented on the bug report.
[22:28] <dart> I am not sure if its related to this update or not but i started experiencing this problem only two days back.
[22:32] <ScottK> !regression
[22:32] <ScottK> Sigh.
[22:32] <dart> Downgrade to earlier xorg-server will be safe?
[22:33] <ScottK> !regression-alert
[22:33] <slangasek> hoboy
[22:34] <ScottK> It's probably a bit late for blacklisting, but here you go ...
[22:34] <slangasek> dart: can you try downgrading the package to the natty release version, to verify that the problem is resolved?
[22:35] <dart> Ok. I will do it. It is safe right?
[22:35] <slangasek> dart: please also file a bug with 'ubuntu-bug xserver-xorg-core' and attach /var/log/apt/term.log
[22:35] <dart> I got some data should i take a backup
[22:36] <slangasek> dart: nothing in this world is provably safe; downgrading that package won't eat any data from your system, however
[22:36] <ScottK> Downgrading the package should be safe.   You should always have current backups, I don't think you particularly need them more because of downgrading the package.
[22:37] <dart> ok...I am doing it now
[22:37] <ScottK> You'll need to restart X after the downgrade.
[22:37] <dart> ok wait
[22:39] <dart> The exact package is xserver-xorg-core or anything else?
[22:39] <ScottK> xserver-common as well
[22:39] <dart> ok
[22:42] <slangasek> cnd: hey there!  dart is reporting cursor misbehavior after upgrading his X server; has commented on the bottom of bug #774938
[22:43] <cnd> slangasek, thanks
[22:43] <slangasek> ah, dart has just disconnected, presumably to test his X server downgrade
[22:43] <cnd> ahh
[22:44] <slangasek> I've asked him to file a new bug as well, so we get the apport goodness
[22:44] <cnd> good
[22:44] <cnd> thanks
[22:44] <ScottK> If we killed his computer and don't have to deal with it, that's a form of win too.
[22:44] <ScottK> ;-)
[22:44] <cnd> heh
[22:44] <cnd> any luck?
[22:45] <dart> hello, I downgraded xorg server and the problem seems to have gone but I need more time to confirm this
[22:45] <cnd> dart, is this with a trackpad?
[22:45] <cnd> or a touchscreen?
[22:45] <cnd> or?
[22:46] <dart> I am mostly using external mouse. No touchscreen.
[22:47] <cnd> dart, can you do the steps noted here: https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
[22:48] <dart> There is a difference between touchpad and mouse sensitivity on my system. Its more noticeable with external mouse
[22:48] <cnd> skip steps 3, 4, and 9
[22:48] <cnd> and instead of looking for a touch device node, use the node for your mouse
[22:48] <cnd> let me know if you need help figuring out what event node it is
[22:51] <dart> ok  m doing it now
[22:52] <cnd> once you have the device.prop and device.record files, upload them to the new bug you created
[22:55] <dart> its /dev/input/event7 for optical mouse
[22:55] <cnd> ok
[22:59] <dart> how long it takes for evemu-record?
[23:00] <cnd> dart, it should time out after about 10 seconds
[23:00] <cnd> 10 seconds of no motion
[23:00] <dart> no motion? I moved my pointer around
[23:00] <cnd> yeah, move your pointer, then stop and wait 10 seconds
[23:01] <dart> not sure if i did like this...should I do it again coz i moved pointer all the time
[23:02] <cnd> dart, I just need a recording exhibiting the bug
[23:02] <cnd> it can be 5 seconds of motion
[23:02] <cnd> or it can be more
[23:04] <dart> ok, one last thing...I am currently doing this with stock xorg server in natty repos and not the SRU one. That would be fine?
[23:04] <cnd> yeah
[23:04] <dart> ok
[23:07] <dart> where are these prop and record files are stored?
[23:08] <cnd> if you copy and pasted the commands, they should be saved in the directory in which you ran them
[23:08] <cnd> probably your home directory
[23:08] <ScottK> cnd: Should he do it against with the xserver from -updates?
[23:08] <dart> ok got them
[23:08] <cnd> ScottK, we are recording events from the kernel, so it doesn't matter what the x server is
[23:08] <ScottK> Ah.  OK.
[23:09] <cnd> dart, which bug have you created for this issue?
[23:10] <dart> I have yet to create...its 3 am here I am a bit slow in doing things : )
[23:10] <cnd> ahh
[23:10] <cnd> np
[23:10] <cnd> dart, when you create the bug, please subscribe me
[23:10] <cnd> my launchpad id is chasedouglas
[23:10] <dart> ok
[23:10] <cnd> in fact, instead of subscribing just assign it to me
[23:11] <cnd> I have to go to an appointment now, but I'll be back later to check on things
[23:11] <cnd> thanks!
[23:22] <dart> in apport  should i select this -->  the problem started after system software update or I don't know would be fine
[23:22] <ScottK> Either is fine, but after update would be better.
[23:22] <dart> ok thanks
[23:34] <dart> all right done -- Bug #791596
[23:36] <dart> ScottK, Plz check bug. Do I need to add some more information?
[23:47] <RAOF> dart: I've assigned that bug to cnd as he asked; he's got the most insight into X input behaviour.  You should probably attach /var/log/apt/term.log to the bug as well, but it looks like you've got all the info cnd asked for.
[23:47] <nemo> Hey guys, I ran into a ubuntu forum article that fixed suspend/hibernate on my Sony VPC-F11 - is there an ubuntu wiki page where I can check to see if this problem is reported?
[23:48] <nemo> I'd just like to make sure it gets picked up for future releases.  Fix from forums was adding acpi_sleep=nonvs to boot params
[23:50] <nemo> Other issue was it was totem (not mplayer) having a black screen until I set output to No Xv in gstreamer
[23:51] <nemo> Oh, and it seems helpless to pick up the built in microphone, but since I haven't found a fix for that yet, no point in reporting it anywhere
[23:51] <RAOF> nemo: For the suspend issue you'd be wanting to check the bugs against the kernel on lanchupad.net.
[23:52] <nemo> RAOF: I was hoping there was maybe some laptop compatibility database I could just dump these issues in :)
[23:52] <nemo> but 'k. I'll stick with "check for existing bugs and report as necessary"
[23:52] <RAOF> I'm not sure why you'd think that just because you can't fix it you shouldn't report it!  Launchpad is full of bugs that people reported but couldn't fix :)
[23:53] <nemo> RAOF: 'cause I was hoping to add to some list of known fixes - I certainly do report bugs I don't know how to fix on launchpad
[23:54] <RAOF> There's an ad-hoc collection of pages on wiki.ubuntu.com.  There's also an effort to get more structured reporting happening, but I'm not sure where that is :)
[23:54] <nemo> I'm playing around with /usr/share/doc/alsa-base/driver/HD-Audio-Models.txt.gz hoping I can find a magic profile that fixes the mic
[23:55] <nemo> RAOF: ah, yeah. that's what I'd more be looking for. something like the Linux on Laptops writeups, but more rigorous and ubuntu version focused
[23:57] <dart> RAOF, I have attached term.log


[00:53] <brousch> Atwater Decadent Dark Chocolate Ale FTW
[00:54] <brousch> It smells like hot chocolate
[01:23] <snap-l> Had a Double Cream Porter at the Royal Oak Brewery.
[01:30] <brousch> I had a Dark Horse Too Cream Stout. It was gross
[02:27] <brousch> geekers https://bitbucket.org/pygame/pygame/issue/140/pip-install-pygame-fails-on-ubuntu-1204
[02:39] <snap-l> brousch: I have never used pygame in virtualenv. I use the packages.
[10:23] <brousch> snap-l: barbaric
[11:09] <snap-l> Good morning
[11:09] <rick_h_> party
[12:45] <rick_h_> lmao http://goo.gl/RJrci
[12:45] <rick_h_> anyone have an S3? I want to test something out :P
[12:48] <brousch> https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1055766
[12:51] <rick_h_> no one uses gnome terminal :P
[12:52] <rick_h_> man, can we please send this bug submitter to a conference I'm also at? grrrr people
[12:52] <brousch> So you can hug him and buy him a beer?
[12:53] <rick_h_> oh yea...definitely
[13:03] <dzho> I love that bug.
[13:03] <dzho> I should submit an "affects me too"
[13:03] <dzho> rick_h_: which conference?
[13:03] <dzho> anyone hitting olf later this week, for instance?
[13:04] <rick_h_> dzho: just talking smack
[13:04] <rick_h_> not making OLF this year but some people are
[13:04] <dzho> oh, darn.  I was hoping for the beer part of that, at least.
[13:04] <dzho> ;-)
[13:06] <snap-l> I'm attending OLF
[13:06] <dzho> cool.
[13:06] <dzho> I think I met you and rick_h_ last year.
[13:06] <dzho> this way, maybe I'll be able to learn which nick goes with whom.
[13:07] <brousch> snap-l has hair on his head. rick_h_ has hair on his face
[13:07] <rick_h_> yea, snap-l and I ran a Lococast booth last year
[13:08] <rick_h_> and had some michigan loco stuff
[13:08] <snap-l> dzho: Beware my natural tendencies to screw with people.
[13:08] <snap-l> brousch: not for long
[13:08] <snap-l> If i have hair on my face, it's because the stuff on top jumped ship
[13:09] <dzho> snap-l: this is IRC, isn't it?  I think that kind of caution is pretty much default setting.
[13:10] <snap-l> heh
[13:11] <dzho> but, still, confirmation is always nice, thanks!
[16:49] <rick_h_> blackberry fun http://www.androidcentral.com/can-t-believe-all-your-former-blackberry-users-left-behind
[16:50] <rick_h_> took a little break from work to do a nice music video for their devs, how sweet
[16:58] <greg-g> I kind of find that gnome-terminal bug funny :)
[16:59] <greg-g> even sabdfl had a sense of humor about it
[17:00] <brousch> ohmy http://www.theregister.co.uk/2012/09/25/google_maps_on_ios6/
[17:05] <greg-g> rick_h_: btw, was that your first LP blog post?
[17:05] <rick_h_> greg-g: yea, I think so
[17:05] <rick_h_> what's cool is that it was my project I picked to do/start on back in Jan after I'd been there all of 2 months.
[17:05] <rick_h_> so kind of my baby
[17:05] <greg-g> awesome, well done sir
[17:06] <rick_h_> well hopefully there's some more snap for some of you guys
[17:06] <rick_h_> not going to change the world, but should be slightly noticable
[17:07] <snap-l> brousch: That's a non-story re: Google iOS maps
[17:07]  * greg-g doesn't do much LP stuff anymore
[17:07] <greg-g> my days of bug triaging are effectively over
[17:07] <snap-l> They didn't say they wouldn't, they said they have no plans
[17:07] <rick_h_> greg-g: yea, most don't
[17:07] <snap-l> greg-g: Yeah, lst jam I spent the hours on askubuntu
[17:08] <brousch> snap-l: But I see so many Apple fanboys saying Google will rescue them from ios6 maps misery
[17:08] <snap-l> Nice: got a mail from Pandora re: backing the Internet Radio Fairness act
[17:08] <brousch> This is saying they have no plans to do so
[17:09] <snap-l> brousch: No, it's someone asking an exec a question that he likely wasn't ready for, or didn't want to tip his hand
[17:09] <greg-g> uh, he was ready for it, you know that for sure
[17:09] <snap-l> saying "We have no plans" is like a reflex action for CEOs
[17:09] <greg-g> he's been thinking about how to answer that question since iOS6 came out
[17:09] <snap-l> That's their "Uh"
[17:10] <greg-g> no, it is "you guys made the wrong choice going with apple"
[17:10] <rick_h_> I'm so sick of apple and their fans. Even my boss was going "how does google get open credit?" crap today
[17:10] <greg-g> who's your boss? :)
[17:10] <greg-g>
[17:10] <brousch> open credit?
[17:11] <snap-l> Even so, Apple has been pretty clear about making competing apps being a big no-no in their app store
[17:11] <rick_h_> https://twitter.com/deryckh
[17:11] <rick_h_> well we debated what counts as 'open' a little bit
[17:11] <rick_h_> there's levels to it for sure
[17:12] <snap-l> yeah, I loved discussing open APIs as a replacement for OSS with some developers
[17:12] <rick_h_> and I won't say android is OSS since it's closed door dev'd and then opened
[17:12] <snap-l> it was like trying to debate the merits of chocolate over the merits of canned peas.
[17:13] <snap-l> In the end, nobody was convinced.
[17:13] <rick_h_> it's turned into religion and politics
[17:13] <rick_h_> I've never had a discussion and had someone walk away with their mind changed
[17:13] <snap-l> The biggest problem is arguing pragmatism with idealism.
[17:14] <rick_h_> even with languages you can discuss and walk away with new ideas/thoughts about languages/uses
[17:14] <snap-l> pragmatically, you can get things done quite efficiently with Apple hardware
[17:14] <snap-l> but from a FOSS idealistic perspective, you may as well be bathing in baby blood if you even think lustfully over an Apple product.
[17:16] <snap-l> Also, fuck the Football talk
[17:16] <rick_h_> lol
[17:17] <snap-l> Seriously, if the NFL suddenly up and vanished into thin air, I'd be hard pressed to notice
[17:18] <snap-l> And quite convinced I wouldn't care.
[17:18] <jrwren> OSS has always been about religeon and politics. stallman says atheism and communism respectively.
[17:19] <rick_h_> yea, but I don't think the phone wars is OSS or not
[17:19] <rick_h_> I think it's much more the old MS vs Apple, choice vs one true path
[17:19] <dzho> free licensing has almost always been about pragmatism to me
[17:19] <brousch> I posted this to my friend who spammed my twitter and FB feeds with football crap last night http://knowyourmeme.com/photos/127663
[17:19] <dzho> I *hate* licensing paperwork
[17:20] <snap-l> rick_h_: The phone wars are somewhat driven by licensing
[17:20]  * greg-g ignores the convo for a bit ;)
[17:20] <rick_h_> snap-l: 'somewhat'
[17:20] <brousch> dzho++
[17:20] <dzho> I just switched a bunch of macs from osx to windows in large part because windows will sell us licenses for a currently-supported version of their OS that runs on that hardware, that *Apple* hardware, and Apple won't.
[17:20] <snap-l> greg-g: Calling you out on purpose. ;)
[17:20] <rick_h_> snap-l: it's also that I can choose to have a 3.5", 4", 5" phone. Or run amazon or google on it. Or get one that's locked or an unlocked dev phone.
[17:21] <dzho> the other part is that we have to run some instrumentation software that runs only on one or the other.
[17:21] <snap-l> rick_h_: Yeah, that's the main thing about Android: the abundance of choice
[17:21] <jrwren> i liked this one on google being "open" http://daringfireball.net/2011/08/google_patently_absurd
[17:21] <dzho> otherwise, of course, I think I could make a good case at this point for Ubuntu
[17:21] <dzho> Android is sort of quasi-free
[17:21]  * greg-g plugs his ears "la la la la la la"
[17:21] <greg-g> :P
[17:21] <dzho> it has free stuff in it, but the whole bit of it isn't.
[17:22] <rick_h_> jrwren: right, which is why I don't think the debate is on that level
[17:22] <rick_h_> but if you put the two side by side and ask why one gets more 'open' credit than the other...there's a lot of other stuff to choose from that feed the feeling 'open'
[17:23] <snap-l> jrwren: Honestly, I don't blame any company for their patent actions.  You can be humorless together for ever
[17:47] <rick_h_> ok, seriously? I mean f*@$#@ seriously? http://techcrunch.com/2012/09/25/for-microsoft-googles-robohornet-browser-benchmark-isnt-real-world-enough-launches-its-own-version/
[17:48] <rick_h_> so rather than say...submit a patch to the 'alpha' tool you just add "Pro" to the end and do your own thing. DIE IE DIE
[17:57] <snap-l> Control the message
[17:57] <snap-l> That's the Microsoft way
[17:57] <rick_h_> I mean it's on github, in alpha, and pull requests welcome. So they add "Pro" to the end...of course!
[17:58] <rick_h_> and it completes in 6s in chrome while the non-pro thing runs tests for minutes
[17:58] <snap-l> It's like the guy that took a hex editor and started marketing SY-DOS (instead of MS-DOS)
[17:59] <snap-l> rick_h_: So clearly it's a more optimized benchmark. ;)
[17:59] <snap-l> most people only use the web for short bursts anyway.
[17:59] <snap-l> (roll with that as you see fit)
[17:59]  * rick_h_ just jumps out the window.  It's a great day for the Internet
[18:00] <snap-l> NFL Sub Refs, Twitter replacing followers with Klout?, Robohornet Pro, What should I do with my life so I can work for Facebook / Google / Apple?
[18:01] <rick_h_> don't forget that grep fails to search amazon
[18:01] <snap-l> Not just amazon, but the whole universe.
[18:05] <brousch> I just made a West MI Dutchman cry
[18:05] <brousch> He showed me his shiny iPhone5 and I showed him my bigger, faster, cheaper Android
[18:05] <jrwren> so what is the story about ads?
[18:07] <jrwren> oh, the ads lens.
[18:08] <jrwren> maybe a duckduckgo lens there too so that search is search, local or web.
[18:08] <rick_h_> jrwren: so see https://twitter.com/alex_gaynor/status/250650329899753472
[18:08] <rick_h_> for the lovely community response to the lense hitting amazon by default
[18:08] <rick_h_> snap-l: going to email this to my wife http://blog.appfog.com/could-portland-be-the-best-city-in-the-country-for-developers-right-now/ :P
[18:10] <jcastro_> jrwren, there's going to be a toggle to turn it on and off
[18:10] <jcastro_> and it's not ads really
[18:10] <jcastro_> it's just amazon results in your dash
[18:10] <jcastro_> so if you search for "megadeth" it shows you CDs, DVDs and whatnot
[18:20] <snap-l> rick_h_: You just put in new floors. ;)
[18:21] <rick_h_> snap-l: *sigh* true
[18:21] <snap-l> "Okay, so I’m biased. I’m a native Portlander and I love living here. I’m Portland’s staunchest defender and was so way before Portland was considered cool."
[18:21] <snap-l> Oh come on
[18:22] <snap-l> "But what makes it even better is that it acts as the de facto hub of the Portland tech scene. Whenever I go there, it feels like a scene from Cheers."
[18:23] <snap-l> Not exactly the kind of aspirational thing I'd expect from a bar.
[18:23] <snap-l> The weather. This is a source of almost endless complaint, but if you ask AppFog founder and CEO Lucas Carlson, having 8-9 months a year of crummy weather offers a hidden productivity boost: “The great thing about Portland is that it’s rainy 9 months out of the year. I’m more productive here than I am anywhere else.” As a native, I couldn’t agree more.
[18:24] <rick_h_> lol, that's the part I was waiting for you to hit
[18:24] <snap-l> OK, the church of elvis might sell me.
[18:24] <rick_h_> "it's not a bug, it's a feature"
[18:24] <snap-l> 24 hours
[18:26] <jcastro_> the beer in portland
[18:26] <jcastro_> period.
[18:27] <snap-l> Well, that sinks it then. Their beer has periods
[18:28] <snap-l> or do they have period beer, as in I'd like a Renaissance Porter?
[18:28] <snap-l> and it's served by a jolly looking chap with a bad English accent?
[18:37] <jrwren> no way is their beer as good as MI beer :)
[18:39] <snap-l> beer smackdown in t-minus...
[18:46] <rick_h_> ok, so this is about the coolest thing ever http://paste.mitechie.com/show/ueNU9dCI8MZEmDpc2OFM/
[18:48] <brousch> Is it a patch to make grep search Amazon?
[18:48] <rick_h_> lol, almost :P
[18:48] <brousch> hah, that is cool
[18:48] <brousch> Other than the MSU part
[18:49] <rick_h_> my wife went to med school at MSU so I have to forgive it for existing
[18:50] <brousch> I thought that was only for vets
[18:50] <snap-l> rick_h_: That's awesome.
[18:51] <rick_h_> brousch: no, they've got a pretty high up there vet program, but they also have a medical school
[18:53] <rick_h_> ok, today is trying to get some awesome to it https://twitter.com/nchan/status/250662314607538176 wow
[18:54] <rick_h_> I want to go drive wherever that it at and see it in person
[19:00] <brousch> Germany
[19:00] <brousch> http://www.brickshelf.com/cgi-bin/gallery.cgi?f=126969
[19:00] <brousch> Why did a German create an american aircraft carrier? I have not a clue
[19:02] <rick_h_> because they learned that carriers + planes > u-boats?
[19:03] <brousch> There's a Legoland in Chicago that's supposed to be good
[19:40] <brousch> $2 off discount code for LEGO Kidsfest in Novi Oct 12-14 (GRK12)
[20:21] <greg-g> snap-l: can I troll you for just a second?
[20:21] <greg-g> ;)
[20:21] <greg-g> http://identi.ca/conversation/96184387
[20:22] <greg-g> (not sure if you follow @mlinksva or not)
[20:23] <snap-l> Yeah, and Michał Andrzej Woźniak tried trolling me too
[20:23] <greg-g> :)
[20:24] <greg-g> sorry, just wanted to point you toward it. Though, retrospectively, I realize it is unneeded and potentially only blood pressure rising.
[20:25] <snap-l> No worries
[20:26] <snap-l> They're in love with the medium, not the message
[20:26] <snap-l> And that's fine.
[20:29] <greg-g> That's unfair.
[20:30] <snap-l> my "Communication without an audience is meaningless." quote was probably too broad. Should have been "communication without recipients is meaningless", but whatever. Point is, no matter how awesomely a tree falls, if nobody hears it, it doesn't matter.
[20:30] <snap-l> (in the context of social media)
[20:30] <greg-g> good thing identi.ca isn't empty, then ;)
[20:30] <greg-g> and, since I'm not going for ad-clicks.... ;)
[20:30] <snap-l> Well, it's also why people have left identi.ca: they didn't like the audience
[20:31] <greg-g> sure, it has some specific communities in it, tightly bound
[20:31] <snap-l> It has a pretty high crank ratio
[20:31] <snap-l> (of which I include myself in that category)
[20:31] <greg-g> bah, I never see it
[20:32] <greg-g> (other than you, of course ;) )
[20:32] <greg-g> I've determined that groups make sense in the huge internal corporate network use case, but not on identi.ca
[20:32] <snap-l> Groups were poorly though out tags
[20:32] <greg-g> (and even that use case is up for debate, just because I haven't tested it)
[20:33] <greg-g> CC's 'internal' status.net is quite small (we're quite small)
[20:33] <snap-l> It's nice to be able to subscribe to a particular group (tag)
[20:33] <snap-l> but the usage became synonymous with tags
[20:34] <snap-l> !ubuntu !debian !metal !alpacafuckers
[20:35] <greg-g> yeah
[20:35]  * greg-g will brb
[20:44]  * ColonelPanic001 notes greg-g's tweet about foreign cars
[20:44] <ColonelPanic001> Ohio-made Civic here.
[20:44] <ColonelPanic001> last car was a Cavalier, many of which (though not mine) were made in Mexico
[20:46] <greg-g> ColonelPanic001: haha, glad someone was paying attention
[20:47] <greg-g> his private response: "I know, I almost defined that, but was lazy. And I agree. But this parking lot was mostly Fords.  I care about real jobs. Apparently, Ford drivers are just like Apple users (zing!). "
[20:47] <ColonelPanic001> haha
[20:47] <ColonelPanic001> I sort of wish my Chevy had been made in Mexico, just so it'd be a better example. heh
[20:47] <greg-g> :)
[20:47] <ColonelPanic001> but alas. Stupid american factories, making my cars
[20:47] <greg-g> yeah, my Ford Ranger was made in St. Paul ;)
[20:48] <ColonelPanic001> is the Expedition they make out by Toronto area?
[20:48] <ColonelPanic001> I know they've got a Ford plant or two out there, can't remember for what
[20:48] <greg-g> before The Great Deer Collision of 2007
[20:49] <ColonelPanic001> hm. maybe it's GM? Now I can't remember. I know they make cars out there, damnit
[23:42] <brousch> I got into the cheaper-than-S3 Dreamhost storage beta