[02:46] <psusi> switching back and forth between packages that leave quilt patches applied in bzr and ones that don't is driving me up the fscking wall!  for the love of root, will someone fix the auto package importer to deapply patches before committing?
[02:49] <poolie> psusi, you're pretty sure that would be better across the board?
[02:49] <poolie> there was a thread about this recently
[02:50] <poolie> i can see the inconsistency would suck
[02:51] <psusi> poolie, yes!  reviewing commits that add a quilt patch, AND modify the files the quilt patch touches is a royal pain in the ass
[02:51] <poolie> yeah
[02:51] <psusi> but yea, inconsistency is worse than that
[02:51] <psusi> not to mention a needless bloating of the archive
[02:54]  * ScottK still has trouble with Source V3 because starting with the patches already applied just feels wrong.
[02:57] <psusi> indeed... they need to be deapplied in bzr
[02:58] <psusi> working on packages where they are not applied is so nice... backporting to older releases is cake
[03:08] <aroman> what in Ubuntu's livecd causes a "Desktop" folder to be created in the livecd desktop user's home folder?
[03:09] <aroman> ls
[03:25] <IanLiu> I'm trying to fix bitesize bugs from unity, but I'm in doubt on how to replace the current unity with my compiled one. Any help?
[03:26] <ScottK> IanLiu: You might have more luck in #ubuntu-desktop or #ayatana.  I'm not sure which would be better.
[03:27] <IanLiu> ScottK: Thanks, I will try asking there
[03:38] <ohsix> ugh, random right clicks coming from touchpad, and mouse realllly slow even with the sensitivity set all the way up in natty
[07:33] <tkamppeter> OdyX, we are after FF, I think activating a new sync after FF is not possible.
[07:36] <micahg> tkamppeter, depending on the change, we can still sync, what's the question?
[07:39] <tkamppeter> I have uploaded foomatic-db to Ubuntu, a new upstream source which adds a bug fix. This package is the same in Ubuntu and Debian. We want to have a sync here, but as we are after FF I thought that the sync is not possible, because arbitrary Debian uploads cannot go into Ubuntu.
[07:40] <tkamppeter> micahg, does a sync not mean that every Debian upload goes automatically into Ubuntu?
[07:40] <slangasek> no, syncs can be processed on packages individually
[07:40] <slangasek> this is the purpose of the 'requestsync' tool, for instance
[07:42] <pitti> Good morning
[07:42] <micahg> tkamppeter, after DIF, syncs must be requested individually
[08:14] <dholbach> good morning
[09:04] <abhinav-> pitti, Good morning. I was wondering if we should call upgrade only for the package(s) for which the user was trying to report a bug/crash or simply run upgrade for all packages ?
[09:41] <pitti> dpm: all maverick langpacks are built and in the archive, btw, so they can be tested now
[09:42] <dpm> pitti, ok, cool, thanks, I'll send the announcement and prepare the wiki page. What's the version number?
[09:42] <pitti> dpm: 1:10.10+20110315
[09:48] <pitti>  kees, jdstrand: releaseing maverick kernel to -updates/-security (linux linux-backports-modules-2.6.35 linux-meta linux-ports-meta)
[10:12] <brendand> has anyone noticed that bootchart has stopped working in recent natty images?
[10:12] <brendand> it doesn't generate any data to /var/logs/bootchart
[10:12] <brendand> when i install it i can see initrd is updated
[10:40] <tjaalton> something wrong on the amd64 build chroot? nvidia fails to build, although the earlier upload today did build
[10:40] <tjaalton> http://launchpadlibrarian.net/66646771/buildlog_ubuntu-natty-amd64.nvidia-graphics-drivers_270.30-0ubuntu2_FAILEDTOBUILD.txt.gz
[10:41] <OdyX> What chance do I have to see usb-modeswitch{,-data} to get sync'ed from Debian ? IMHO it's worth having (less complication).
[10:46] <jhunt> bdrung, elmo, cjwatson: could you try out the latest gdm.conf on bug 436936 (https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/436936/+attachment/1915134/+files/gdm.conf) when you get a chance?
[10:47] <jhunt> bdrung, elmo, cjwatson: the "start on" is getting a bit "hairy". We have a cunning plan to simplify using abstract jobs for the next cycle.
[10:47] <bdrung> jhunt: i will try it once restored everything after an harddisk upgrade
[10:48] <jhunt> bdrung: thx!
[11:53] <jelmer> pitti: hi
[11:53] <pitti> hey jelmer, how are you?
[11:53] <jelmer> pitti: I'm well, thanks :)
[11:54] <jelmer> pitti: Vila and I are looking at a FFe for a bzr microrelease for natty
[11:54] <jelmer> pitti: do we need one, even if bzr is part of MRE ?
[11:54] <pitti> jelmer: should be fine
[11:54] <pitti> jelmer: if they meet the MRE standards, it's mostly bug fixes anyway, is it?
[11:54] <jelmer> pitti: yes
[11:55] <pitti> bug fixes don't require a FFE
[11:55] <ogra_> OptiPNG 0.6.4: Advanced PNG optimizer.
[11:55] <ogra_> Copyright (C) 2001-2010 Cosmin Truta.
[11:55] <ogra_> what calls that during a package build ?
[11:56] <ogra_> it breaks unity-2d and i somehow need to disable it
[11:56] <jelmer> pitti: thanks
[11:56] <pitti> ogra_: that's pkgbinarnymangler
[11:56] <pitti> ogra_: you can export NO_PNG_PKG_MANGLE=1 in debian/rules
[11:57] <pitti> ogra_: but out of interest, how does it break?
[11:57] <brendand> cjwatson - do you know that bootchart is broken in recent natty images? it seems since yesterday
[11:57] <ogra_> pitti, but that will suppress other optimizations, no ?
[11:57] <ogra_> pitti, Qt seems to not be able to handle 8bit images for stacking them onto alpha blended ones :)
[11:57] <pitti> ogra_: no, that one just disables png optimizations
[11:57] <pitti> ogra_: NO_PKG_MANGLE disables everything
[11:58] <ogra_> ah, k
[11:58] <ogra_> we could convert them during load but that would slow down the code
[11:58] <janimo> ogra_, is this a known Qt issue, maybe with bug filed?
[11:59] <ogra_> janimo, no bug afailk
[12:04] <cjwatson> brendand: is that bug 723663, or something different?
[12:05] <brendand> cjwatson - no, that's just one machine generating bad data
[12:05] <brendand> cjwatson - this is *everything* generating *no data*
[12:05] <brendand> cjwatson - tried on vbox too
[12:05] <cjwatson> ok, is there a bug?
[12:06] <brendand> cjwatson - just now
[12:06] <brendand> cjwatson - i ran ubuntu-bug bootchart. hope that gives decent logs
[12:06] <cjwatson> bootchart itself hasn't been changed since lucid
[12:06] <brendand> cjwatson - i believe you
[12:06] <brendand> cjwatson - wonder what's affected it then
[12:06] <cjwatson> not asserting your bug doesn't exist, just that it was likely caused by something else
[12:07] <brendand> cjwatson - https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/737487
[12:07] <brendand> cjwatson - if there's anything further needed i'll be glad to gather it for you
[12:07] <cjwatson> thanks, bumped to high
[12:07] <cjwatson> jhunt: ^- do you have time to have a look at that?
[12:29] <brendand> cjwatson, jhunt - do you reckon maybe the process which bootchart looks for to stop has changed somehow?
[12:36] <cjwatson> brendand: it's multiarch fallout, we're discussing it
[12:43] <brendand> cjwatson - it certainly looks like the problem is that it hasn't stopped
[12:43] <brendand> cjwatson - on my Maverick system, the /var/run/bootchart directory is not there (because it's supposed to get cleaned up)
[12:43] <brendand> cjwatson - but when the bootchart.tgz doesn't exist, the /var/run/bootchart directory does
[12:43] <brendand> cjwatson - in this case
[12:45] <cjwatson> brendand: jhunt has found the root cause, we're working on a fix
[12:45] <cjwatson> as I say it's multiarch fallout - libc moved
[12:47] <brendand> cjwatson - thanks
[13:23] <jdstrand> kirkland: hi! you probably saw this, but qemu-kvm ftbfs on i386, which make qemu-kvm on amd64 uninstallable (cause of qemu-common)
[13:23] <jdstrand> s/make/makes/
[13:23] <jdstrand> hallyn: ^
[13:23] <kirkland> jdstrand: hmm, i have not seen that
[13:23] <jdstrand> kirkland: https://launchpad.net/ubuntu/+source/qemu-kvm/0.14.0+noroms-0ubuntu3/+buildjob/2325646
[13:23] <kirkland> jdstrand: hallyn is out today, let me take a look ...
[13:24] <kirkland> jdstrand: hmm, ugly
[13:24] <kirkland> jdstrand: i wonder if that's multi-arch breakage?
[13:25] <kirkland> gcc: Internal error: Killed (program cc1)
[13:25] <jdstrand> yeah, I don't know :\
[13:25] <kirkland> jdstrand: it built locally here before i uploaded
[13:26] <kirkland> cjwatson: could you have a quick look at this build breakage for qemu-kvm and tell me if you think it's multi-arch related?  https://launchpad.net/ubuntu/+source/qemu-kvm/0.14.0+noroms-0ubuntu3/+buildjob/2325646
[13:26] <kirkland> cjwatson: strange gcc error with little-to-no debug information
[13:29] <abhinav-> dholbach, nice article, very informative :-)
[13:29] <dholbach> thanks abhinav-
[13:29] <dholbach> if you have any more feedback, let me know (or comment on the article)
[13:29] <abhinav-> yup, sure, I will :)
[13:30] <cjwatson> kirkland: doesn't seem likely
[13:30] <cjwatson> "Killed" sounds like "somebody sent me SIGKILL"
[13:30] <cjwatson> perhaps OOM?
[13:37] <kirkland> cjwatson: yeah, that does sound like it
[13:49] <mterry> If a friendly archive admin wanted to push the button on bug 736807, I'd be grateful
[13:58] <abhinav-> dholbach, I am doing a session on UDD in my college during an open source unconference. I was just going to repeat whatever I learnt during developer week, but the ubuntu-packaging-guide will be an excellent source to get more information :)
[13:58] <dholbach> abhinav-, sweet - I'm glad you like it!
[13:58] <dholbach> let me know how the session goes!
[13:58] <abhinav-> sure. I will :)
[14:00] <ogra_> cjwatson, adding debian-installer/framebuffer=false to the headles images cmdline didnt change anything
[14:02] <ogra_> oh, wait, its gone after first boot :P so once d-i starts it has a framebuffer again ... silly me
[14:07] <cjwatson> ogra_: I mean preseeding it in the debconf database used by oem-config
[14:08] <ogra_> cdmline wouldnt suffice ?
[14:08] <ogra_> *cmd
[14:08] <cjwatson> dunno offhand
[14:09] <ogra_> its hard to distinguish if i'm on headless or not, but the initial cmdline is set during build based on $PROJECT
[14:09] <ogra_> so setting it in advance is the easiest way, else i need detection code
[14:09] <cjwatson> this is just for experimental purposes
[14:10] <cjwatson> I want to know whether that makes a difference to narrow down the problem
[14:10] <ScottK> OdyX: It depends a lot on what's in the update.  If it's pure bugfix it's no problem at all.
[14:10] <ogra_> hmm, k
[14:11] <OdyX> ScottK: it's not… But usb-modeswitc has rarely been broken by upstream…
[14:11] <OdyX> ScottK: anyway, your call people. :-)
[14:11] <ScottK> OdyX: You recommend we update?
[14:12] <OdyX> ScottK: I do, as it gets rid of the -packed flavour (see -data changelog), but it is in unstable for two days only...
[14:13] <OdyX> the -packed flavour finally was transitional, so It'd be nice to not have it in Natty.
[14:13] <ScottK> OdyX: We need someone to make a Feature Freeze exception so the release team can evaluate it.  Unfortunately my schedule is packed right now.
[14:13] <OdyX> ScottK: mine too.
[14:15] <ScottK> cyphermox: ^^^ would you be interested in taking care of the FFe?
[14:16] <ScottK> dholbach: You uploaded a fix for Bug #612885 that seems to both make appindicator support optional and add python-appindicator to depends.  As commented in the bug, I think adding the dependency now is wrong.
[14:31] <cyphermox> ScottK, reading the backlog now
[14:32] <cyphermox> OdyX, so there's a new release of usb-modeswitch-data?
[14:33] <OdyX> cyphermox: yes, 20110227-2
[14:33] <OdyX> cyphermox: released 3 weeks ago, uploaded yesterday to unstable.
[14:34] <cyphermox> OdyX, ok, I'll file the FFe bug in a minute
[14:34] <cyphermox> ScottK, thanks for the notice :)
[14:35] <OdyX> cyphermox: nice. Note you need usb-modeswitch 1.1.7 too
[14:35] <cyphermox> OdyX, ok. both non-bugfix right?
[14:35] <OdyX> cyphermox: it's debatable. :-)
[14:36] <cyphermox> AFAIK if there isn't already an SRU special case for usb-modeswitch I think we might want one... it's not necessarily uncommon to see people with new usb 3g devices on a "final" release
[14:37] <cyphermox> OdyX, usb-modeswitch is one thing that doesn't worry me too much. Plus if it breaks you're around, so we'll just blame it on you :)
[14:40] <OdyX> cyphermox: fine for me.
[14:44] <ogra_> cjwatson, cmdline didnt make a difference ... i'll try an explicit debconf-communicate call from the inird setup script to set it directly
[14:44] <ogra_> *initrd
[14:49] <dholbach> ScottK, I guess that depends on which experience we want users to have
[14:50] <dholbach> ScottK, making it "optional" is something that would make sense upstream in any case
[14:50] <mdz> skaet, where can I find a complete list of natty FFE requests and their status?
[14:50] <ScottK> dholbach: For non-Ubuntu flavors that depends drags in the entire appindicator stack.
[14:51] <ScottK> dholbach: If it were only about Ubuntu, I'd agree.
[14:52] <ScottK> mdz: https://bugs.launchpad.net/~ubuntu-release has them for all releases.
[14:52] <skaet> mdz, have been using launchpad, and tracking through new status.   https://bugs.launchpad.net/~ubuntu-release/+bugs?orderby=datecreated&field.status%3Alist=NEW
[14:53] <kirkland> hmm, any gcc/toolchain experts around, in doko's absence?
[14:53] <ogra> pitti, heh, the tag isnt enough for armel bugs ?
[14:54] <dholbach> ScottK, alright, you have a point - I'll make it a Recommends
[14:54] <kirkland> i'm trying to debug a build failure of qemu-kvm i386 on the buildd's
[14:54] <ScottK> dholbach: Suggests please.  Recommends still get installed by default.  It's non-trivial for normal users to avoid them.
[14:54] <dholbach> ScottK, my thinking was that for a gtk app that still makes sense
[14:55] <dholbach> seb128, what do you think? moving python-appindicator from depends to recommends?
[14:55] <dholbach> https://bugs.launchpad.net/ubuntu/+source/gtk-recordmydesktop/+bug/612885/comments/10
[14:55] <ScottK> dholbach: People should be able to use an application in their DE of choice independent of what toolkit it's writtenwith.
[14:55] <ScottK> So I think "It's GTK" is not relevant.
[14:56] <seb128> dholbach, recommends seems right to me
[14:56] <mdz> skaet, thanks!
[14:57] <ScottK> seb128: That's going to pull in a lot of dependencies for non Ubuntu-desktop users.
[14:57] <seb128> ScottK, how so? libappindicator has been splitted out this cycle it's a small lib
[14:58] <ScottK> seb128: Does it work with xfce or lxde?
[14:58] <seb128> ScottK, the indicators do fallbacking to gtkstatusicon when there is no indicator loader from day one
[14:58] <ScottK> (I think it would work correctly with Kubuntu since we seed libindicate-qt)
[14:58] <ScottK> OK.
[14:59] <ScottK> I guess it's OK then.  I'd forgotten it was a lot smaller now.
[14:59] <dholbach> ok, great - I'll make it recommends and upload in a bit
[14:59] <seb128> dholbach, ^ recommends
[14:59] <seb128> dholbach, thanks
[14:59] <dholbach> thanks ScottK for bringing it up
[15:05] <kirkland> mdeslaur: jdstrand: the qemu-kvm build break has to be multiarch, or something else in the tool chain;  the diff since the last upload (and successful build) is trivial and unrelated: http://launchpadlibrarian.net/66546963/qemu-kvm_0.14.0%2Bnoroms-0ubuntu2_0.14.0%2Bnoroms-0ubuntu3.diff.gz
[15:09] <jdstrand> kirkland: did you retry the build?
[15:11] <abhinav-> pitti, what does  ui_shutdown do ? I am calling it inside the exception handler while running the run_package_upgrade method .
[15:11] <kirkland> jdstrand: just pressed retry ~10 minutes ago
[15:12] <kirkland> jdstrand: 13 minutes in;  last failure was at 17 minutes
[15:12]  * jdstrand crosses fingers
[15:12] <jdstrand> :)
[15:13] <jdstrand> though if it is the toolchain, an up to date chroot should reproduce it locally
[15:17] <kirkland> jdstrand: mdeslaur: kees: qemu-kvm i386 rebuild succeeded
[15:17] <jdstrand> \o/
[15:17]  * kirkland has no explanation
[15:18] <jdstrand> probably a problem with the buildd
[15:19] <mdeslaur> kirkland: cool
[15:22] <pitti> abhinav-: see its docstring; it's not actually used anywhere in the gtk/kde/cli implementations, so I guess calls to it are fairly inconsistent
[15:22] <pitti> abhinav-: but you shouldn't call it when you call the package update
[15:23] <abhinav-> pitti, so if an error occurs I should simply return after displaying an error message ?
[15:24] <pitti> abhinav-: yes; you should only call ui_shutdown() if you do an exit()
[15:25] <abhinav-> ok. I think I got it
[15:47] <micahg> ScottK, >re comment in ubuntu-meeting, I thought DSO linking wasn't reverted, just --as-needed
[15:48] <ScottK> micahg: I think you're right.  The idea is still good though.  Thanks.
[16:02] <mdeslaur> anybody know why gdm is showing me the "postfix" user in the chooser?
[16:05] <seb128> mdeslaur, bug #696038
[16:05] <seb128> mdeslaur, it likely comes from the ck-history log
[16:05] <seb128> not sure why it got a ck session now
[16:05] <seb128> now -> though
[16:06] <mdeslaur> seb128: ah, yes, that seems to be the appropriate bug...thanks!
[16:06] <seb128> mdeslaur, you're welcome
[16:14] <apw> slangasek, are the compilers stable for the moment?
[16:35] <slangasek> apw: for the next while at least
[16:38] <smoser> @pilot-in
[16:38] <udevbot> Error: "pilot-in" is not a valid command.
[16:38] <smoser> @pilot in
[16:39]  * dholbach hugs smoser :)
[16:50] <pitti> ScottK: do you have some further info about bug 712554? (see comment 4)
[16:51] <ScottK> pitti: No.  I'll do install testing for Beta 1 and I'll see if it still happens.
[16:52] <ScottK> (I didn't get the chance for Alpha 3).
[16:54] <pitti> ScottK: ok, thanks
[17:09] <mok0> My friend is a sysadm who has just found the need to enable disk-quotas. We are thinking about writing software that gives a users a notification (every 30 minutes, say) if the users' disk quota is exceeded. Do you think there is an interest in such a system for Ubuntu in general?
[17:10] <abhinav-> pitti, I have added code for upgrading packages, but I dont seem to have any  obsolete packages to test with :-/
[17:11] <pitti> abhinav-: just grab an older one from launchpad?
[17:11] <abhinav-> pitti, oh ok. I will try with that. thanks
[17:12] <beuno> chrisccoulson, ping
[17:13] <chrisccoulson> hi beuno
[17:13] <beuno> hey chrisccoulson, I just got poked about missing search providers in FF
[17:13] <beuno> know anything about this?
[17:13] <chrisccoulson> in maverick?
[17:14] <beuno> chrisccoulson, yes
[17:14] <chrisccoulson> beuno, i think that should be fixed already
[17:15] <chrisccoulson> pitti - did the new langpacks get uploaded to maverick-proposed?
[17:15] <pitti> chrisccoulson: yes, they are in
[17:15] <chrisccoulson> beuno, how long ago was this?
[17:15] <chrisccoulson> pitti - thanks
[17:15] <pitti> chrisccoulson: I tested search plugins with de, dpm tested es and ca
[17:15] <pitti> beuno: do you have language-pack-... 1:10.10+20110315 ?
[17:16] <beuno> pitti, I haven't upgraded today, this is second-hand complaining  :)
[17:19] <smoser> anyone with correct perms able to accept a trivial merge proposal ? https://bugs.launchpad.net/ubuntu/+source/txt2regex/+bug/736326
[17:20] <beuno> chrisccoulson, any ideas how long its been broken?
[17:21] <chrisccoulson> beuno, since last friday
[17:22] <beuno> chrisccoulson, and this is just maverick?
[17:22] <chrisccoulson> beuno, just maverick-proposed
[17:23] <beuno> chrisccoulson, ah, so low impact?
[17:24] <chrisccoulson> beuno, yeah
[17:24] <beuno> chrisccoulson, cool, thanks
[17:25] <slangasek> jamespage: I'm not sure who normally takes care of openjdk-6 packaging; if you want to have a look at fixing bug #737603 I'm happy to provide support, or if you need this to be a foundations problem I can queue it up to work on here today/tomorrow
[17:25] <cjwatson> slangasek: normally doko
[17:26] <jamespage> cjwatson beat me to it....
[17:26] <slangasek> ok
[17:35] <SpamapS> So.. the runit-run package uses dpkg-divert to replace /sbin/init ...
[17:40] <SpamapS> I'm not sure if this is a huge critical bug or just an insanely weird package.
[17:43] <jamespage> slangasek: it would be great if foundations could pick this up - is doko around?
[17:46] <abhinav-> pitti, Interestingly, I have the latest linux header updates pending in the update manager, but apport simply starts with asking questions. I was thinking that report.obsolete_packages() checks the cache
[17:46] <pitti> abhinav-: it only checks (transitive) dependencies of the crashed program, not all packages
[17:49] <abhinav-> pitti, so apport-bug linux would check for linux and its dependencies ?
[17:49] <pitti> abhinav-: yes, and as the kernel doesn't have many, it won't complain
[17:49] <abhinav-> hmm
[17:50] <pitti> abhinav-: you could e. g. install acl (or another small package) from maverick, and then try to report a bug against it
[17:51] <pitti> abhinav-: or from lucid, if you are on natty; try installing http://archive.ubuntu.com/ubuntu/pool/main/a/acl/acl_2.2.49-2_i386.deb and then ubuntu-bug acl
[17:51] <abhinav-> pitti, ah ok thanks. I am on maverick though.
[17:52] <pitti> abhinav-: above is lucid's version, will work
[17:52] <abhinav-> pitti, ok thanks. trying :)
[17:55] <slangasek> jamespage: I think doko may still be traveling back from pycon?  at least that's what his TZ availability this week seems to suggest
[17:56] <slangasek> right, PyCon ran through yesterday, so I guess he's traveling no
[17:56] <slangasek> w
[17:56] <slangasek> so I'll have a look at this
[17:57] <slangasek> SpamapS: the runit-run package that no longer exists in Debian due to this critical bug? :)
[17:58] <SpamapS> slangasek: YES that one.
[17:58] <SpamapS> slangasek: shall we drop it as well?
[17:58] <slangasek> I would think so
[17:58] <SpamapS> slangasek: its also usurping 'man init' on manpages.ubuntu.com .. doh
[17:58]  * slangasek chuckles
[18:15] <abhinav_> pitti, acl is also in apt's cache, but apport is not reporting it as obsolete. I checked with my new code as well as with the current trunk
[18:18] <slangasek> Riddell: if I understand your cmake change correctly, this populates the search path by invoking dpkg-architecture at runtime, right?
[18:19] <slangasek> Riddell: in that case, you probably also want cmake to depend on dpkg-dev, since dpkg-dev isn't guaranteed to be installed on the systems of end users who are doing non-package-related development
[18:20] <jamespage> slangasek: thankyou
[18:20] <slangasek> (but this is a minor bug - the fix looks very nice, glad you guys were able to come up with a solution)
[18:22] <slangasek> Riddell: as a side effect, this seems to fix cmake behavior for cross-compilation against libraries in multiarch paths... which is exactly what we want to see :-)
[18:40] <Riddell> slangasek: yes, we're currently discussing in #k-d if we want to depend on dpkg-dev or hardcode it at package build time
[18:50] <penguin42> smoser: Hi
[18:52] <smoser> penguin42, hi
[18:53] <penguin42> smoser: I proposed the merge of a branch against bug 725044 and wouldn't if I should do anything else
[18:53] <smoser> penguin42, i'll take a look
[18:55] <penguin42> Thanks - ampelbein helped me through the process for the 1st time
[18:57] <christer1>  /quit
[18:57] <christer1> clear
[19:10] <smoser> penguin42, i do not have upload access for libsdl, so i can't upload it. it looks good to me though.  I commented with one nitpick in the bug, and i think you  might as well fix that.
[19:10] <smoser> s/bug/branch merge proposal/
[19:18] <chrisccoulson> hi slangasek. would you mind taking a quick look at bug 737641? :)
[19:18] <chrisccoulson> it seems multi-arch related
[19:23] <penguin42> smoser: OK, thanks I can fix that up
[19:24] <slangasek> chrisccoulson: sigh :/  what build system is this?
[19:26] <slangasek> chrisccoulson: also, what's the corresponding source package in the archive that I should look at? I don't see thunderbird-3.3 anywhere
[19:26] <chrisccoulson> slangasek, that's hard to describe, it's a fairly complex and customized build system just built around make
[19:27] <chrisccoulson> slangasek, yeah, thunderbird-3.3 is in one of our PPA's, but the failure also affects the firefox and thunderbird packages in the archive
[19:27] <chrisccoulson> although, they haven't been rebuilt since the changes yesterday. i wanted to upload the new release today before i hit the problem locally
[19:58] <slangasek> chrisccoulson: ok, found the code responsible in make-dfsg; working on making it smarter
[19:58] <chrisccoulson> slangasek, excellent, thank you :)
[20:00] <MadCow108> is natty going to have multiarch support? I'm a bit surprised at all these uploads with multiarch in the changelog after feature freeze o_o
[20:32] <vish> ScottK: hmm, Aubergine is not Ubuntu's color either, its just Canonical's color.. so its not flavored in anyway.. ;)
[20:33] <vish> any* way
[20:33] <ScottK> vish: OK.  It goes better with Orange than Blue in any case.
[20:33]  * vish nods..
[20:33] <ScottK> It would nice if such things were discussed before they were langed, particularly after feature freeze.
[20:43] <charlie-tca> +1 ScottK
[20:44] <slangasek> chrisccoulson: make fix uploaded
[20:44] <chrisccoulson> slangasek, you rock! thanks :)
[20:45] <slangasek> chrisccoulson: n/p, sorry for the breakage
[21:21] <ScottK> charlie-tca: Please reply to the thread on ubuntu-devel.
[21:28] <charlie-tca> I can't. I don't have rights there
[21:28] <ScottK> charlie-tca: You can.  It just goes into a moderation queue.  It'll be delayed, but it will get there.
[21:29] <charlie-tca> okay. I will then!
[22:03] <till_> in my the dependencies in my control file, is there a way to say package depends on another package foo or a package bar, but if none is installed, just get foo?
[22:04] <Ampelbein> till_: Depends: foo | bar
[22:06]  * till_ facepalms
[22:06] <till_> Ampelbein: thanks =)
[22:28] <RoAkSoAx> bryceh: ping
[22:30] <RoAkSoAx> bryceh: any ideas what might be cause this? http://me.roaksoax.com/dual-monitor.jpeg (Intel Video driver maybe?)
[22:31] <bryceh> RoAkSoAx, could be a few things
[22:31] <bryceh> RoAkSoAx, do you have compiz running?  (looks like no?)
[22:32] <RoAkSoAx> bryceh: nope
[22:32] <bryceh> RoAkSoAx, what video driver?
[22:32] <RoAkSoAx> bryceh: just happens when laptop's LCD is off though
[22:32] <bryceh> heh, here comes a game of 20 questions
[22:32] <bryceh> RoAkSoAx, why don't you describe a bit more about your setup
[22:32] <bryceh> what you did to reproduce, etc.
[22:33] <RoAkSoAx> bryceh: Intel HD Video graphics. Lenovo x201 recently purchased. I connect it to VGA and when having the laptop's LCD on, then the external monitors work just fine
[22:33] <RoAkSoAx> when turning off the LCD displayt and just leaving the external monitors, it shows that
[22:34] <RoAkSoAx> bryceh: i connect to both external monitors via a dualhead2go, though when using another laptop with nvidia drivers, this doesn't happen
[22:35] <RoAkSoAx> bryceh: and it doesn;t matter if I connect it to one external monitors, or the two (via dualhead2go). Same result
[22:36] <bryceh> when you connect to one monitor, is that through the dualhead2go device or straight thru?
[22:36] <RoAkSoAx> bryceh: straight thru
[22:36] <bryceh> in what manner do you turn off the LCD display?
[22:37] <RoAkSoAx> bryceh: gnome-display-properties
[22:37] <bryceh> hmm
[22:38] <slangasek> pitti: heh, fontconfig is not the only package broken by cdbs+python-scour; atk is as well
[22:38] <bryceh> alright, so most likely it's either a kernel (KMS) problem with drm or potentially gnome-display-properties
[22:38] <slangasek> and I just broke it
[22:38] <slangasek> (on powerpc, anyway)
[22:38] <RoAkSoAx> bryceh: if I use my other laptop with nVidia proprietary or with nouveau, I don't experience this at all
[22:39] <bryceh> RoAkSoAx, well, it is almost certainly something unusual about that particular laptop's vga port
[22:39] <bryceh> RoAkSoAx, however that does tend to rule out bad edid I suppose
[22:40] <bryceh> RoAkSoAx, here is what I would do to diagnose it a bit further
[22:40] <bryceh> a.  reboot with the monitor attached, and verify the problem still occurs
[22:40] <bryceh> actually
[22:41] <RoAkSoAx> bryceh: (oh forgot to mention, this worked fine in Maverick) and I've done a. and the problem persists
[22:41] <bryceh> a.  reboot with the monitor attached and lvds left on, you should not see the problem
[22:41] <bryceh> b.  now use xrandr to disable the lvds (not gnome-display-properties)
[22:42] <bryceh> c.  if the issue still occurs at this point, run 'ubuntu-bug xorg' and I'll take a look
[22:42]  * RoAkSoAx on it now
[22:42] <bryceh> RoAkSoAx, otoh if it does not occur when disabling the monitor using xrandr, then the bug probably should be filed against gnome-display-properties
[22:43] <bryceh> although, in either case I suspect the root cause may be kernel kms drm driver issues, but probably best to start from userspace for diagnostic purposes
[22:44] <bryceh> RoAkSoAx, if you can also post a Xorg.0.log and 'xrandr --verbose' output from when it's working *correctly* for comparison purposes, that'll probably help
[22:45] <cjwatson> bryceh: FYI Andy's kernel/udev/plymouth/gdm/etc. suite of changes is on its way up now
[22:45] <bryceh> cjwatson, awesome!  many bug reports are about to fall
[22:45] <cjwatson> nvidia is still problematic I think, but I added plymouth:force-drm which lets people experiment with the plymouth drm driver again on nouveau
[22:45] <cjwatson> can't speak for ati
[22:46] <bryceh> I'll email AMD and let them know
[22:46] <bryceh> -fglrx is still unreleased
[22:47] <cjwatson> haven't yet touched kdm
[22:47] <cjwatson> but it shouldn't break them
[22:49] <RoAkSoAx> bryceh: yeah ut seens to be gnome-display-properties then as I disable with xrandr and external monitors work just fine with LVDS off
[22:50] <bryceh> RoAkSoAx, ok good, that narrows it down nicely
[22:51] <bryceh> RoAkSoAx, ok i think you have enough info to file a bug report against gnome-display-properties, and xrandr should give you a workaround for now, but feel free to let me know if you have any other questions
[22:51] <RoAkSoAx> bryceh: awesome! Tha nks a lot for the help
[22:57] <bryceh> cjwatson, ok AMD is notified of the change.  Hopefully they'll catch any issues in their testing
[22:59] <ScottK> cjwatson: Is there something it would be beneficial to do for KDM?
[23:01] <slangasek> ScottK: yes, kdm needs an update to adjust its upstart start condition (cjwatson just commented it in the bug)
[23:01] <ScottK> slangasek: Which bug?
[23:02] <cjwatson> ScottK: bug 702090
[23:02] <ScottK> cjwatson: Thanks.
[23:02] <slangasek> cjwatson: force-drm> so drm is now off by default?  I'm clearly out of the loop on plymouth; is there a refresher course available to get me up to speed on the current architecture / assumptions ?:)
[23:02] <cjwatson> ScottK: should be something along the lines of http://paste.ubuntu.com/582287/
[23:02] <cjwatson> slangasek: that's specifically for nouveau, and you were the one who turned it off :-)
[23:02] <cjwatson> slangasek: bug 539655, for a refresher
[23:03] <ScottK> Thanks.  Now to figure out if cmake is fixed yet.
[23:03] <slangasek> cjwatson: oh, that :-)
[23:03] <slangasek> ok, so it's only needed on nouveau, gotcha :)
[23:03] <cjwatson> slangasek: I just wanted to make it run-time so that we could test fixes
[23:03]  * slangasek nods
[23:03] <cjwatson> (if any)
[23:22] <debfx> cjwatson: do you know why component-mismatches says that kdesvn-kio-plugins needs to be promoted to main even though it is only an alternate dependency of kdesdk?
[23:41] <cjwatson> debfx: because the primary alternative, kdesdk-kio-plugins, is uninstallable on armel at the moment (it's out of sync, which is presumably why), so germinate fails to resolve it and falls back to the secondary alternative
[23:45] <debfx> cjwatson: ok, thanks for the explanation