[00:14] <hallyn> jtaylor: just a note, because (to my chagrin) packaging trees are stored with patches applied, it can confuse matters when you don't do so in your merge proposals :)
[00:15] <jtaylor> I know, but I don't like it, I like my diffs small ;)
[00:15] <jtaylor> hasn't that also changed now?
[00:15] <hallyn> jtaylor: i dunno.  but my first build somehow failed to get your fix (i thought debian/rules build would quilt push, but apparently it didn't)
[00:16] <hallyn> cjwatson: (cause i'm not sure who else to ask) once a merge proposal is approved, if the approver doesn't have upload rights, does that hit another queue where someone will see it and push it?
[00:17] <hallyn> (i'd ask dholbach but don't see him here)
[00:17] <hallyn> i just want to make sure the mp didn't just get buried in a hole somewhere
[00:17] <hallyn> @pilot out
[00:20] <cjwatson> hallyn: not afaik but I think it stays on the sponsorship queue
[00:21] <hallyn> cjwatson: oh, sorry - I thought when I looked earlier it had been removed, but i see it's still there.  thx
[00:35] <broder> hallyn: jtaylor: do you guys still need sponsorship for svn? i have 45 minutes at the airport before my flight boards :)
[00:40] <broder> hallyn: the code for the sponsor queue is in lp:ubuntu-sponsoring - i believe that approved/disapproved/etc. reviews have no impact on whether or not something's in the queue; my recollection is that it's all based on the "status" (i.e. "work in progress", "needs review", etc.) at the top of the page
[00:40] <broder> which is why you'll see people reject changes by changing the status to "WIP"
[00:48] <broder> bah. it may take me all 45 of these minutes to manage to clone the bzr branch over airport wifi
[00:57] <stgraber> broder: bzr co --lightweight?
[00:57] <broder> huh, interesting. maybe sponsor-patch should support that
[01:07] <hallyn> broder: sorry, was afk (obviously).  yeah there are two merge proposals by jtaylor that i approved but don't have rights to upload
[01:07] <hallyn> svn and python-numpy
[01:08] <broder> hallyn: i'm, uh, 4/5ths through downloading the build-deps for a test build, so i don't think that's likely to finish before i have to pack up
[01:08] <hallyn> broder: thanks for trying :)
[01:08] <hallyn> sounds like my experience trying wifi at portland airport...
[01:08] <hallyn> everyone tells me it was atypical though
[01:09] <broder> yeah, sfo is always crappy, but at least it's free :)
[01:12] <broder> and that's my cue to leave. i can try again later, but maybe someone else will show up
[01:16] <ajmitch>  /win 44
[01:16] <ion> /lose 45
[01:34] <cnd> slangasek, I'm having some issues with creating a new package using the debian X git guidelines
[01:34] <cnd> are you still around?
[01:35] <slangasek> cnd: barely
[01:35] <slangasek> what's the problem?
[01:35] <cnd> dpkg-source: info: local changes detected, the modified files are:
[01:35] <cnd>  xorg-gtest/autogen.sh
[01:35] <cnd> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/xorg-gtest_0.1.0+git5b26608-1.diff.a_LeY9
[01:35] <cnd> upstream git has autogen.sh
[01:35] <cnd> the shipped tarball does not
[01:35] <cnd> somehow this isn't a problem in all the X packages
[01:35] <cnd> but I can't figure out why it's different for this package
[01:36] <slangasek> is this package source format 3.0 (quilt) where the others are not?
[01:36] <slangasek> I think I've seen this error message before on a package in X git, but I don't remember the solution offhand
[01:36] <cnd> yeah
[01:36] <cnd> I just noticed that
[01:36] <cnd> maybe that's why they haven't switched to 3.0 (quilt)?
[01:37] <slangasek> I doubt that's the reason
[01:37] <slangasek> you could just git rm autogen.sh on the packaging branch
[01:37] <slangasek> but if debian/rules is calling dh_autoreconf, that may not be what you want
[01:38] <cnd> the X stuff requires being able to call dh_autoreconf
[01:38] <cnd> I'm trying to follow their approach for a new X package we're developing
[01:38] <slangasek> then you probably want to stick with format 1.0 for now :)
[01:38] <cnd> but moving to (3.0) quilt if possible
[01:38] <cnd> heh
[01:38] <slangasek> but you could ask on #debian-x@OFTC
[01:39] <cnd> yeah, I just did, but I thought I'd ping you too in case you knew :)
[01:39] <slangasek> yeah, dunno a perfect fix here, sorry
[01:39] <cnd> slangasek, one last question, where is dpkg-source called from
[01:39] <cnd> if I want to override dh
[01:39] <cnd> it looks like dh_clean
[01:39] <cnd> but I can't find any reference in the man page
[01:39] <slangasek> dpkg-source isn't called from debian/rules at all
[01:40] <cnd> what would be calling it?
[01:40] <slangasek> uh
[01:40] <slangasek> what command are you running? :)
[01:40] <cnd> debuild -i -I
[01:40] <cnd> http://paste.ubuntu.com/828346/
[01:40] <slangasek> ok, then the layering is debuild -> dpkg-buildpackage -> dpkg-source
[01:41] <cnd> so is dpkg-buildpackage calling dh_clean and then dpkg-source?
[01:41] <cnd> yeah, man dpkg-buildpackage spells it out
[01:41] <cnd> alright, I'll poke some more
[01:41] <cnd> thanks :)
[01:41] <slangasek> dpkg-buildpackage is calling "dpkg-source -i -I --before-build xorg-gtest", then "fakeroot debian/rules clean", then "dpkg-source -i -I -b xorg-gtest"
[01:41] <slangasek> sure thing
[02:15] <cjwatson> slangasek: I've promoted python-debtagshw and its source package in order to unbreak things.  Do you think it needs an MIR, given that it was previously in main and I don't remember this being a problem?
[02:21] <cjwatson> the original MIR predates our use of bugs for them; https://wiki.ubuntu.com/MainInclusionReportDebtags
[02:26]  * ScottK thought previously in Main was one of the "you don't need a MIR" reasons.
[02:33] <cjwatson> I think I only asked because it was a while back.  Normally, certainly yes.
[07:27] <slangasek> cjwatson: not sure how much my opinion counts for there :)  But debtags is pretty low-risk anyway...
[09:06] <doko> cjwatson, slangasek java-atk-wrapper has a resolved MIR, pitti is just to quick to demote things ... :-/
[09:08] <koolhead17> cjwatson: hello there
[10:14] <rrs> m4n1sh: You there. PM ?
[10:14] <m4n1sh> rrs: yes
[10:14] <rrs> Or let me ask here itself.
[10:14] <m4n1sh> yes, ask
[10:14] <rrs> I recently switched to Ubuntu. Impressed with the work.
[10:15] <rrs> My pbuilder (cowbuilder) is not honoring APTCACHE value. Do you have any clue?
[10:15] <rrs> Could something be interfering? Is the cow/pbuilder patched here?
[10:15] <m4n1sh> let me check
[10:15] <rrs> Could apparmor be denying?
[10:16] <rrs> I tries to acquire the cache (mine set is /var/cache/apt/archives/), stalls for 2 seconds, and then silently proceeds. I'm sure there's a failure there, just that it doesn't show up.
[10:17] <rrs> *It
[10:18] <m4n1sh> rrs: this is the package https://launchpad.net/ubuntu/precise/+source/cowdancer/0.67
[10:18] <rrs> yup
[10:18] <rrs> BTW, I'm using it for sid and precise.
[10:18] <m4n1sh> doesnt look patched, looks like a direct import
[10:18] <rrs> Followed the excellent howto by doko: https://wiki.ubuntu.com/PbuilderHowto
[10:19] <rrs> Just that the cache never gets honored. The cached packages are there in /var/cache/apt/archives/ . But on next build, it again triggers a download.
[10:19] <m4n1sh> that's bad. Bandwidth is limited
[10:20] <m4n1sh> does it work on sid?
[10:20] <rrs> Who'd be the cowbuilder maintainer here?
[10:20] <rrs> Yes. It used to. Now that I'm on ubuntu, can re-check it rightaway.
[10:20] <m4n1sh> yes
[10:20] <m4n1sh> and here is how to check for apparmour issue (if any) https://wiki.ubuntu.com/DebuggingApparmor
[10:21] <rrs> I looked at that.
[10:21] <rrs> By that doc, and from what I investigated, apparmor only confines a set of apps. Not the entire system. So I doubt that apparmor is interfering.
[10:21] <rrs> Who'd be the cowbuilder maintainer here? Or should I just file the bug report?
[10:22] <m4n1sh> rrs: there is no specific maintainer
[10:22] <rrs> A Team ?
[10:22] <cjwatson> It's maintained in Debian.
[10:22] <m4n1sh> universe repository is in hands of MOTU ( #ubuntu-motu )
[10:22] <rrs> Hello Colin.
[10:22] <cjwatson> We don't modify it for Ubuntu.
[10:23] <m4n1sh> rrs: Debian maintainer shows as "Junichi Uekawa <dancer@debian.org"
[10:23] <rrs> OKay!!! I guess I'll have to root cause it myself then :-)
[10:24] <m4n1sh> if you find the issue, then please try to fix it in ubuntu too
[10:24] <rrs> Definitely. I really love the desktop integration so far.
[14:21] <dafox> hi all. Could anyone please clarify why the lcdlegacy filter does not seem to be present in the freetype package?
[14:22] <dafox> other settings in /etc/fonts/local.conf are respected, even setting lcdfilter none or slight, but no matter what I do I seem to be unable to get lcdlegacy.
[14:38] <ion> dafox: If you’re using gnome-settings-daemon, it needs a patch not to override that setting. If you feel like trusting my PPA, the sharp-text-rendering package should fix the issue: https://launchpad.net/~ion/+archive/gsd-lcdfilter
[14:38] <dafox> ion: I have installed the sharp-text-ppa, but for some reason it doesn;t seem to be working
[14:39] <dafox> I installed it on another laptop last week, and there it did work
[14:39] <ion> Huh
[14:39] <dafox> the difference is that that was 'regular' ubuntu, and this is xubuntu.
[14:39] <ion> Ah, Xubuntu doesn’t use gnome-settings-daemon indeed. If you figure out how to fix the issue in Xubuntu, i’d be happy to add that change to the package.
[14:40] <dafox> I've been trying everything I can find, but nothing seems to work short of compiling freetype with the force_legacy option
[14:40] <dafox> ion: any ideas what could be wrong or where to look?
[14:40] <dafox> e.g. is this an xfce issue, or some other library?
[14:41] <ion> I’d try to figure out whether Xubuntu has some config files i’ve missed and whether it has some kind of a desktop settings daemon that overrides other configuration (à la gnome-settings-daemon).
[14:42] <dafox> I'll try
[14:43] <dafox> but the built-in freetype should have lcdlegacy built-in? (is there any way to check this?)
[14:44] <ion> grep the binaries, the source packages and/or the respective /usr/share/doc/*/changelogs.
[14:44] <ion> grep them for lcddefault since that’s what something forces your system to use.
[14:45] <dafox> tried the binaries already, it's not there (but neither on my other system), I'm looking into getting the source packages now but I'm not sure where to get them
[14:45] <dafox> launchpad probably?
[14:46] <ion> apt-get source packagename (but that’s not that helpful unless you already have an idea which packages you want to look at).
[14:47] <ion> The changelogs should have an entry about any lcdfilter-specific patches in installed packages.
[14:47] <dafox> but would that include the configuration? e.g. the configure line, or edits done to include/freetype/config/ftoption.h
[14:48] <ion> Difficult to say in advance.
[14:49] <dafox> ok
[15:13] <falkoned> I just can't stand this http://pastebin.com/smrNHCHe
[15:13] <falkoned> Ubuntu 10.04.3 amd64
[15:13] <falkoned> how to fix this?
[15:15] <falkoned> many people filled a bug on launchpad
[15:15] <falkoned> no fix or workaround at the moment
[15:17] <falkoned> why even developers allow users to encrypt their /home when ecryptfs is so unstable and problematic?
[15:18] <falkoned> this should be disabled by default until these bugs will not be definitely fixed
[15:19] <falkoned> many other operating systems which have a way better support for encryption _do_not_ suggest by one-click way to encrypt any of filesystems as ubuntu does
[15:20] <falkoned> and this ecryptfs errors are horrifying as hell
[15:20] <falkoned> s/this/these
[15:21] <mdeslaur> falkoned: that is LP: #842647, please track progress there
[15:23] <falkoned> mdeslaur: so lets say some dev will fix this- will it affect release 10.04?
[15:24] <mdeslaur> falkoned: tyhicks would know
[15:24] <mdeslaur> tyhicks: ^
[15:30] <dafox> ion: the xfce people are saying that it is impossible that xfce is at fault, since xfce-4.8 (which is used in xubuntu-11.10) does not yet support setting these options, and relies on fontconfig
[15:33] <koolhead17> cjwatson: ping
[15:36] <mr_pouit> dafox: check your ~/.Xdefaults file too
[15:39] <falkoned> shouldn't we use ~/.Xresources these days?
[15:39] <dafox> mr_pouit: Thank you!! That was it!
[15:40] <dafox> the file was already there, and it contained .Xft rules setting the hinting to slight and the filter to default
[15:40] <dafox> mr_pouit: you're my hero of the day :D
[15:48] <falkoned> tyhicks: ping
[15:50] <ion> dafox: Duh :-D
[15:52] <dafox> still should probably file a bug