[00:01] <barry> lifeless: sorry, i got distracted by work and dinner. ;)  can you please ping me again tomorrow (i have to go out for a while now)
[00:01] <lifeless> k
[00:08] <SpamapS> lifeless: I've been following the thread.. and you know I'd like to help solve that issue.. have been pulled far away from that stuff though. :-P
[00:09] <lifeless> SpamapS: cool
[00:09] <lifeless> SpamapS: feel free to jump in :)
[00:10] <SpamapS> At this point I think the "educate people" argument has proven ineffective, even if it is "the right way" .. its not helping much. :-P
[00:11] <lifeless> the python community has little interest in naming modules with api versions on /every/ incompatibility
[00:12] <lifeless> heck, unittest2 mentioned in that thread *isn't* an API version
[00:12] <lifeless> its 'unittest backported for python 2.x'
[00:12] <SpamapS> To be honest I think ruby might even do a better job of this.
[00:23] <SpamapS> 192.168.122.1:/home/clint /mnt/clint nfs ro,soft 0 0
[00:23] <SpamapS> what am I missing.. mountall is skipping that mount
[01:56] <lifeless> SpamapS: not sure :)
[05:52] <ScottK> doko: I still couldn't get libreoffice to fail with KDE enabled.  Would you please publish the source of what fails somehwere?
[06:04] <kees> weird. https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/694983
[06:11] <dholbach> good morning
[07:09] <siretart> Riddell: unping my comment from yesterday, I've just noticed the notice in the buglog. sorry for the trouble
[07:59] <pitti> Good morning
[08:00] <pitti> bdmurray: will do
[09:37] <evfool> #libreoffice
[10:00] <pitti> mdke: here by chance?
[10:12] <ara> doko, ping
[12:40] <didrocks> jdstrand: hey, are you around for some apparmor questions?
[13:04] <doko> ScottK: that the uploaded code, with the kde config options commented out in the natty section of the rules file
[13:05] <raphink> hello
[13:10] <raphink> is there someone here who knows net-snmp (and libsnmp-base in particular) well?
[13:11] <raphink> I'm wondering if the wget (strong) dependency is really necessary
[13:11] <raphink> it seems justified because mibfetch needs it in the README, but we don't ship mibfetch
[13:12] <raphink> and on standard server installs, wget seems to be only pulled by libsnmp-base
[13:14] <Chipaca> hi all. What was the process of asking for an update to a package (i.e. upstream is at a new version)? I know it starts with "write a bug", I've done it before, but can't remember more than that, and that I then had to subscribe somebody to it (who?), and ... anything else?
[13:15] <cjwatson> "file a bug" seems sufficient.  anything more depends on how much you want/need to harass people about it
[13:15] <raphink> Chipaca, you mean in natty?
[13:15] <Chipaca> raphink: yep
[13:16] <raphink> by upstream, do you mean debian or real upstream (sourceforge, LP, etc.)?
[13:16] <cjwatson> FWIW, it's usually smoothest if the upstream can go via Debian
[13:16] <Chipaca> real upstream :) -- checking debian
[13:16] <cjwatson> means everything follows the natural grain
[13:17] <raphink> Chipaca, right, like cjwatson said, it's always better to go through Debian (when possible)
[13:17] <raphink> so the first step is to check if Debian has it
[13:17] <raphink> if Debian has it, the package might be listed here: https://merges.ubuntu.com/
[13:17] <raphink> see https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing
[13:18] <raphink> ... which actually tells you to look at https://wiki.ubuntu.com/UbuntuDevelopment/Merging for the reference :-)
[13:19] <Chipaca> debian has the old version
[13:19] <Chipaca> I've even got the new packages working (so I can develop against the newly added api), and it was just a ... bzr merge-upstream iirc
[13:19]  * Chipaca reads the wiki
[13:20] <raphink> anyone has an opinion on the libsnmp-base wget dependency?
[13:24] <zul> raphink: hmm? what
[13:25] <raphink>  I'm wondering if the wget (strong) dependency is really necessary. It seems justified because mibfetch needs it in the README, but we don't ship mibfetch and on standard server installs, wget seems to be only pulled by libsnmp-base.
[13:26] <jdstrand> didrocks: hi! fire away
[13:26] <cjwatson> wget is going to be pulled in by ssh-import-id RSN anyway
[13:26] <cjwatson> so may not be worth worrying about?
[13:27] <cjwatson> though of course if we don't ship mibfetch we shouldn't claim its dependencies!
[13:27] <didrocks> jdstrand: hey, is there any kind of debug/logs of what access have been prevented in apparmor? I can't launch unity in the guest session only if the apparmor guest profile is here
[13:27] <Chipzz> cjwatson: although the same could probably be achieved by curl
[13:28] <Chipzz> which makes me wonder if it wouldn't be worth writing simple wrappers for both for the simple use case "fetch a file" and depend on wget | curl
[13:28] <jdstrand> didrocks: yes. they show up in dmesg/kern.log. if you have auditd installed, they show up in /var/log/audit/audit.log. use 'grep -i denied <file>'
[13:29] <raphink> cjwatson, I do not see any ssh package being removed when I remove wget
[13:29] <didrocks> jdstrand: ok thanks, let's have a look then. I was looking at /var/log/apparmor/ desperatly :)
[13:29] <cjwatson> raphink: you haven't upgraded sufficiently recently
[13:29] <cjwatson> ssh-import-id was newed today
[13:30] <cjwatson> and is recommended by openssh-server now
[13:30] <jdstrand> didrocks: that said, the kernel does rate limiting of apparmor when not using auditd, so if debugging and profiling you will want to do: sudo sysctl -w kernel.printk_ratelimit=0
[13:30] <raphink> cjwatson, possibly, my servers are on lucid ;-)
[13:30] <cjwatson> Chipzz: what would that gain?  wget is in standard; curl is not
[13:30] <cjwatson> it's not as if both wget and curl are installed on default server installs
[13:31] <raphink> yes indeed
[13:31] <Chipzz> cjwatson: not having both installed because a depends: wget and b depends: curl
[13:31] <cjwatson> Chipzz: which isn't happening on default server installs right now, which is what raphink was asking about
[13:31] <raphink> (some big company where I happen to be working considers wget|curl to be harmful programs on servers)
[13:31] <Chipzz> you're only thinking "main" now
[13:31] <cjwatson> I'm not interested in this discussion so will withdraw
[13:31] <Chipzz> ok w/e
[13:32] <raphink> haha :-)
[13:32] <Chipzz> raphink: the same can probably be achieved be a pretty stock perl install; or netcat
[13:32] <Chipzz> so tey're misguided
[13:32] <Chipzz> *they
[13:33] <raphink> they certainly are
[13:33] <didrocks> jdstrand: ok, seems that the issue is it's denying to open my config compiz file: http://paste.ubuntu.com/550632/
[13:33] <raphink> but the company is 100k+ employees and the corporate security team has an opinion that matters much more than mine
[13:33] <raphink> ;-)
[13:33] <raphink> not like wget is useful for monitoring either, heh ;-)
[13:35] <Chipzz> stock python can get a file too
[13:35] <Chipzz> to make it impossible to download a file from a server is basically impossible
[13:48] <janimo> Laney, hi, any news re ghc6 ?
[13:53] <Laney> janimo: not had time yet
[13:53] <Laney> if you want you can try a merge with experimental
[13:53] <Laney> i'll sponsor that for you if you need it
[13:54] <janimo> Laney, I have upload rights, but thanks
[13:54] <Laney> ok cool
[13:54] <Laney> please do that then
[13:54] <janimo> Laney, problem is on my arm build even the current one succeeded
[13:54] <Laney> it's what i was/am going to do when time allows
[13:55] <janimo> unlike in the buildd
[13:55] <Laney> yeah i don't understand it really
[13:55] <janimo> Laney, ok, I'll check it out these days
[13:56] <Laney> thanks
[14:44] <geser> doko: do you have an idea what's the issue here: http://paste.ubuntu.com/550656/
[14:51] <bcurtiswx_> anyone here successfully add a PPA to their pbuilder-dist,  I try the --othermirror option with no luck (it appears).. look at http://paste.ubuntu.com/550660/
[14:54] <nigelb> bcurtiswx_: shouldn't that go into the sources.list of the pbuilder?
[14:54] <bcurtiswx_> nigelb, i would normally, except pbuilder-dist overwrites the config on every load..
[14:55] <nigelb> hrm, isn't there some option to stop that?
[14:55] <bcurtiswx_> nigelb, maybe I missed it, but i've scoured the man pages
[14:55] <tumbleweed> no, there isn't
[14:56] <tumbleweed> bcurtiswx_: easy answer, use pbuilder, and point it at your pbuilder-dist root tgz
[14:58] <raphink> bcurtiswx_, did you try with APTCONFDIR ?
[15:02] <bcurtiswx_> raphink, APTCONFDIR="/home/ken/.pbuilder/apt.conf.d" in my .pbuilderrc where in the apt.conf.d where I have a bcurtis@wx:~/.pbuilder/apt.conf.d/apt/sources.list.d$
[15:02] <bcurtiswx_> ??
[15:05] <doko> geser: not at first glance. ./e-map/libemap.a as the last argument looks odd
[15:07] <raphink> bcurtiswx_, that should do
[15:07] <raphink> do an update --override-config
[15:11] <jhunt> notify
[15:11] <jhunt> oops :)
[15:16] <RoAkSoAx> /win 8
[15:18] <bcurtiswx_> raphink, it seems to work now.. thx.  tumbleweed you too :)
[15:29] <seb128> Laney, directhex: do you have any clue about bug 596727?
[15:29] <seb128> the title is misleading, the crash is rather the one from comment #11
[15:32] <cjwatson> Sarvatt: I'm just about ready to finally upload a console-setup with keyboard-configuration
[15:32] <cjwatson> Sarvatt: how long would it take you / other X folks to prepare an upload that switches back to that, in line with Debian?
[15:32] <directhex> seb128, can't look at it until the weekend. email me so i don't forget
[15:33] <seb128> directhex, ok
[15:33] <seb128> directhex, can I just subscribe you to the bug or do you prefer an email?
[15:33] <directhex> subscribe is fine as long as something pings the bug so i end up with an email from it
[15:36] <seb128> directhex, ok thanks
[15:37] <Laney> the code of that Xorg() function looks a bit suspicious
[15:44] <doko> kees: had to update one chunk in the default-ssp patch. now building in the ubuntu-toolchain-r ppa
[15:45] <seb128> Laney, ok, I think I know what it doesn't like
[15:45] <Laney> seb128: yeah I reproed it
[15:45] <Laney> If you empty /var/log/Xorg.0.log then it happens
[15:45] <seb128> Laney, the log lines start with [....]
[15:45] <seb128> Laney, even non empty
[15:45] <seb128> on ubuntu it has the stamps
[15:45] <seb128> so no line matches what it wants
[15:46] <Laney> ok I'm on Debian ATM, so ...
[15:46] <seb128> try copying a random file over the log I guess will do the same
[15:46] <Laney> where's the NRE? 320?
[15:47] <seb128> nre?
[15:48] <seb128> oh
[15:48] <Laney> null reference exception
[15:48] <seb128> System.NullReferenceException: Object reference not set to an instance of an object
[15:48] <seb128>   at Sysinfo.SystemInfo.Xorg () [0x00000] in <filename unknown>:0
[15:48] <Laney> yeah doesn't say which line :(
[15:48] <seb128> how do you tell it to say the line?
[15:48] <seb128> Laney, I guess it's the "						temp = textread.ReadLine();" when reaching the end of file without match though
[15:49] <seb128> brb
[15:50] <Laney> that is my thought
[15:51] <Laney> so just break the loop if temp == null is easiest
[15:52] <Laney> ideally that whole method would be refactored, there has to be a better way of doing that
[15:58] <Laney> nm, will fix it if that is right. thanks seb128
[15:59] <Laney> [edit] PowerPC
[16:02] <seb128> Laney, I confirm that removing the [...] before "Build Date" fixes the crash
[16:03] <Laney> seems that ReadLine() returns null if there is nothing to read
[16:03] <seb128> Laney, thanks, btw do you think you could review and maybe grab the 2 small changes we have in ubuntu and get back in sync?
[16:03] <Laney> yep I will take those too
[16:04] <seb128> Laney, thank you, can I assign the bug to you on launchpad?
[16:04] <Laney> if you want to try the patch it'll be to change the loop condition to have while (... && (temp = ... != null))
[16:04] <seb128> oh you did
[16:05] <seb128> Laney, I don't have the mono build-depends on that box but I will try later
[16:07] <seb128> Laney, btw what you suggest will fix the crash but not make the version to be read
[16:08] <Laney> yeah make it substring
[16:08] <seb128> Laney, ideally it would strip the "[.*] "
[16:16] <Bravewolf> latest update of lucid breaks "kde-l10n-engb" "kde-l10n-it".
[16:16] <Riddell> Bravewolf: can you be more specific than "breaks"?
[16:17] <Bravewolf> sure
[16:17] <Riddell> pastebin the apt-get output for example
[16:17] <Bravewolf> The following packages are BROKEN:
[16:17] <Bravewolf>   kde-l10n-engb kde-l10n-it
[16:17] <Bravewolf> 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[16:17] <Bravewolf> Need to get 10,2MB of archives. After unpacking 160kB will be used.
[16:17] <Bravewolf> The following packages have unmet dependencies:
[16:17] <Bravewolf>   kde-l10n-it: Depends: libkdecore5 (>= 4:4.5.0) which is a virtual package.
[16:17] <Bravewolf>   kde-l10n-engb: Depends: libkdecore5 (>= 4:4.5.0) which is a virtual package.
[16:17] <Bravewolf> The following actions will resolve these dependencies:
[16:17] <Bravewolf> Remove the following packages:
[16:17] <Bravewolf> kde-l10n-it
[16:17] <Bravewolf> Keep the following packages at their current version:
[16:17] <Bravewolf> kde-l10n-engb [4:4.4.2-0ubuntu6 (lucid, now)]
[16:17] <Bravewolf> Score is 189
[16:17] <micahg> !pastebin | Bravewolf
[16:17] <Bravewolf> $ apt-cache policy  libkdecore
[16:17] <Bravewolf> W: Unable to locate package libkdecore
[16:18] <Bravewolf> http://paste.ubuntu.com/550710/
[16:19] <Bravewolf> http://paste.ubuntu.com/550711/
[16:19] <Bravewolf> Riddell: here is the output
[16:19] <Bravewolf> micahg: ok
[16:19] <Riddell> Bravewolf: thanks
[16:19] <Riddell> Bravewolf: also pastebin  apt-cache policy kde-l10n-it
[16:20] <Bravewolf> Riddell: http://paste.ubuntu.com/550712/
[16:22] <psusi> ok, I have uploaded a bzr branch, requested merge, filed a bug requesting merge, linked to branch.. anything else I need to do?  like subscribe patch pilots, or tag the bug or anything?
[16:23] <micahg> psusi: if there's a merge proposal, that should show up in the sponsoring queue, when there's not a merge proposal, you need to subscribe ubuntu-sponsors to the bug
[16:23] <Riddell> Bravewolf: hmm, looks like you have found a significant problem
[16:23] <Riddell> Bravewolf: well the good news is that you can safely remove those packages, unless you care about documentation translations, they don't contain the application translations
[16:23] <Riddell> ScottK: wibble ^^
[16:32] <Bravewolf> Riddell: right, I can remove them. By the way I don't know why this problem appears with the latest update. I seems that something is wrong with the dependencies and/or the new version requires some libraries not available. Who is supposed to fix to it? Should I file a bug?
[16:33] <Riddell> Bravewolf: yes it's bug and we need to fix it
[16:33] <Riddell> Bravewolf: please do file a bug and let me know the number
[16:33] <Bravewolf> Riddell: ok
[16:40] <Sarvatt> cjwatson: apologies for the delay, I'm on it now
[16:44] <cjwatson> Sarvatt: great, thanks - http://paste.ubuntu.com/550726/ perhaps?  looks like the rest of that file is still useful
[16:45] <Sarvatt> http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/     http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/xorg-server_1.9.0.902-1ubuntu2.debdiff
[16:45] <Sarvatt> ah ok, good point
[16:45] <Sarvatt> fixing
[16:50] <cjwatson> Sarvatt: IMPORT{file}="/etc/default/keyboard" works fine in this VM, at least
[16:50] <cjwatson> so I'm going to go ahead and upload c-s
[16:52] <Bravewolf> Riddell: I was sending the bug report when I found https://bugs.launchpad.net/bugs/696675
[16:56] <Riddell> thanks Bravewolf
[16:59] <mvo> cjwatson: I just played with the latest grub and btrfs a little bit, it complains that ""only detection is support for btrfs, you need to load the kernel first" (v1.99~0101221). is there something missing in code or am I not driving it correctly (this is from the grub shell at boot)
[17:01] <Bravewolf> Riddell: thanks for your help
[17:02] <cjwatson> mvo: you need 1.99~20110104-1
[17:02] <cjwatson> mvo: if you're on amd64, it hasn't quite landed yet
[17:04] <mvo> cjwatson: indeed, that is the problem. thanks
[17:07] <cjwatson> Sarvatt: uploaded now - please go ahead and upload xorg-server when you get a chance
[17:10] <Sarvatt> cjwatson: I have no upload permissions but I am attempting to find a sponsor and have fixed it up in git as well as http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/ . bryceh should be on soon, we had some other changes queued up in git that might be a bit scary to review :)
[17:13] <cjwatson> Sarvatt: I suppose I could upload it, but the X team might prefer I didn't
[17:18] <Sarvatt> I can't speak for the other guys but the complaints usually come from it being maintained in git and changes not pushed to pkg-xorg, already ran the nvidia/fglrx change past tseliot and bryce and RAOF is on vacation
[17:19] <tseliot> Sarvatt: what's up?
[17:20] <tseliot> Sarvatt: what kind of change?
[17:20] <Sarvatt> tseliot: cjwatson uploaded a console-setup with keyboard-config and xorg-server needs a sponsor, fixed it up but it includes the other stuff queued up in git
[17:20] <Sarvatt> tseliot: the fglrx/nvidia no xorg.conf needed change
[17:21] <tseliot> Sarvatt: ok, how can I help? Aren't those changes ready?
[17:22] <Sarvatt> been running it for 2 months now with no side effects, yeah just need a sponsor for http://sarvatt.com/downloads/merges/xorg-server-keyboard-config/ if you have a bit of time
[17:22] <Sarvatt> (and it's been enabled in xorg-edgers for the same amount of time)
[17:22] <tseliot> sweet, there's a debdiff :)
[17:22] <tseliot> Sarvatt: I'll review it and upload
[17:22] <Sarvatt> tseliot: thanks a ton!
[17:24] <tseliot> Sarvatt: the fix that RAOF included is something that I wanted to include myself so this basically saves me some time
[17:25] <superm1> Sarvatt, with 105_* what happens if you actually still use an xorg.conf?  are you able to force it back and forth to radeonhd, ati etc ?
[17:25] <Sarvatt> superm1: no difference
[17:26] <superm1> i just seem to remember that there were some concerns raised with that a year back or so in #ubuntu-x
[17:26] <superm1> where it broke a particular scenario
[17:26] <Sarvatt> superm1: it just adds fglrx/nvidia to the autoconfig pool which isn't used when an xorg.conf is present
[17:26] <tseliot> right
[17:26] <tseliot> they are 2 different paths
[17:26] <Sarvatt> superm1: the problem before was that it needed the DefaultDepth option to work
[17:27] <superm1> oh right
[17:27] <tseliot> and you really need that with fglrx and nvidia
[17:27] <tseliot> ;)
[17:28] <Sarvatt> only difference this will make is things will actually work if people install via a package manager and not jockey since jockey makes the xorg.conf
[17:28] <tseliot> the debdiff looks good to me (I remember reviewing the same patch)
[17:28] <superm1> well very cool then.  i suppose after that publishes jockey should have the functionality of making an xorg.conf disabled too
[17:28] <Sarvatt> well it doesn't hurt having it in jockey, I didn't add the NoLogo option there :)
[17:30] <Sarvatt> sometimes we need to add IgnoreABI to nvidia temporarily via jockey too
[17:32] <tseliot> yes, we don't want the logo to show up when the session starts and we can add workarounds too, as Sarvatt says
[17:35] <bdrung> doko: the press picked up your mail about libreoffice: http://www.golem.de/1101/80502.html
[17:37] <tseliot> Sarvatt: maybe the change to panoramiXprocs.c should have been a patch
[17:37] <tseliot> instead of a direct change
[17:37] <tseliot> but I guess it's fine
[17:40] <tseliot> Sarvatt: maybe the change to panoramiXprocs.c should have been a patch instead of a direct change but I guess it's fine
[17:41] <tseliot> you use git to track these changes so it's definitely fine
[17:42] <tseliot> Sarvatt: uploaded
[17:43] <Sarvatt> tseliot: yeah i'd prefer it that way too, at least he actually cherry picked it into git this time instead of just updating the changelog :) thanks a bunch tseliot
[17:43] <tseliot> np
[17:56] <SpamapS> slangasek: so I think i have a handle on the statd issue. unfortunately it involves spinning waiting for statd to start the same way we had to spin and wait for portmap.
[17:56] <slangasek> oh?
[17:56] <SpamapS> the problem is that we *must* block mounting TYPE=nfs
[17:57] <SpamapS> until statd is started
[17:57] <slangasek> and why is that not happening?  isn't it just because statd forks before listen?
[17:57] <SpamapS> so the timeline is.. we hit local-filesystems and started portmap ON_BOOT=y .. but then net-device-up fires at the same time, which tries to start statd, but does not block mounting .. so the mount fails
[17:58] <SpamapS> basically if an event in upstart doesn't actually change the goal.. it doesn't block
[17:58] <SpamapS> I think
[17:58] <slangasek> oh; so the problem is statd is being triggered by an event other than 'mounting'
[17:58] <SpamapS> right
[17:58] <SpamapS> which it must be
[17:58] <SpamapS> because of the requirement that it also be running for nfs-kernel-server in runlevel 2
[17:59] <slangasek> right, certainly
[17:59] <slangasek> so how do you solve this?  Not sure what you're talking about spinning waiting
[17:59] <SpamapS> http://paste.ubuntu.com/550745/
[18:00] <dobey> /usr/share/cdbs/1/rules/buildcore.mk:34: *** multiple target patterns.  Stop.
[18:00] <dobey> anyone know why one would get that all of a sudden?
[18:00] <SpamapS> slangasek: on review of statd, it should hit 'started' very quickly.
[18:00] <SpamapS> slangasek: so 5 seconds is an eternity.
[18:01] <cjwatson> mvo: I'm uploading grub2 1.99~20110104-2ubuntu1 now - that should build on amd64
[18:01] <slangasek> SpamapS: I think you're a missing a comment in that file: "icky blech hack hack hack, remove when upstart is fixed" :)
[18:02] <SpamapS> slangasek: the rant I put in the file was too long for the pastebin.. ;)
[18:02] <slangasek> heh
[18:02] <cjwatson> Fermat's Last Rant
[18:04] <SpamapS> so yeah, there just needs to be a way to have new events attach to existing events
[18:09] <dobey> is it really impossible to use substvars in package names?
[18:09] <SpamapS> one thing that I'm confused on is how we can possibly run sm-notify on an NFS root system, since /var/lib/nfs would have to be unique to the machine
[18:10] <kees> doko: oh? what was missed? it worked when I built it.
[18:10] <ebroder> dobey: I'd expect that you'd need some major hackery that cdbs probably can't deal with
[18:11] <dobey> ebroder: hrmm. not cool :-/
[18:12] <ebroder> dobey: cdbs does things like calculate paths based on package names, but substvars aren't substituted until very close to the end of the build
[18:12] <dobey> yeah i get that. it's still annoying :)
[18:12] <doko> kees: just something not applying, maybe because of an update from the trunk. btw, it now ftbfs on amd64 with the hardening patches enabled
[18:13] <ebroder> dobey: There are also all of the things like the automatically populated foo/package make targets
[18:15] <kees> doko: gah. what fails?
[18:16] <dobey> ebroder: yeah, which is why it should probably figure out the substitutions early, for internal use as well
[18:16] <ebroder> dobey: I don't think you can do that many levels of code generation with make
[18:18] <kees> doko: and you did get https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/696990/+attachment/1783015/+files/gcc-4.6_4.6-20101220-1ubuntu0.1.debdiff not the earlier one?
[18:20] <slangasek> SpamapS: NFS root doesn't imply shared; indeed, /var/ *must* be unique, so anyone doing serious NFS rooting has to make provisions for this
[18:21] <SpamapS> slangasek: actually I think we may be able to ditch the polling. If I do 'stop on started statd or stopped statd' then .. as evil as it sounds, we can just run 'start statd' and wait forever. *one* of those events will happen, and we'll be killed.
[18:22] <slangasek> oh, that sounds less evil to me, yes :)
[18:23] <dobey> ebroder: do you know if there is some other way to conditionally name packages?
[18:24] <SpamapS> slangasek: any suggestions on how to wait forever? sleep 1bazillion seems a little silly
[18:24] <geser> doko: re my linking problem: your hint seems to be correct: when I move the last .a more to the front the linking works
[18:25] <slangasek> SpamapS: 'while sleep 3600; :; done' ? Pretty sure an hour-long nap is long enough :)
[18:25] <ebroder> dobey: i think you'd need to use pure (pre-7) debhelper
[18:25] <ebroder> dobey: i think i've seen something sort of like that done with the zephyr package, so you could look at that (it has provisions for building krb4 or krb5 versions of a bunch of packages, and figures out which at build-time)
[18:36] <SpamapS> slangasek: one thing it does is it flags the event with an error.. so mountall bitches
[18:36] <SpamapS> slangasek: but it doesn't affect any other events tied to the mounting event
[18:45] <meebey> can I hint the software-center and/or app-install-data which package should be installed instead of the package it found the .desktop file in? the issue is that the package that contains the desktop file is only a portion of the software, instead a higher level metapackage should be installed
[18:46] <sebner> huhu meebey :)
[18:47] <meebey> sebner: hiya
[18:50] <dobey> ebroder: is there any way to perhaps alter the list of packages being built in cdbs?
[18:50] <cdbs> \o/
[18:50] <dobey> ebroder: by mucking with a variable somehow, for example?
[18:52] <cjwatson> dobey: you can generate debian/control from debian/control.in in your clean rule
[18:53] <cjwatson> that's the usual way to dynamically generate binary package names
[18:53] <cjwatson> you may also have to generate some other files, depending on how your packaging is laid out
[18:53] <dobey> so just sed -e blah blah inside clean::?
[18:54] <cjwatson> yeah
[18:54] <cdbs> dobey: yup
[18:54] <cjwatson> it has to be in clean because debian/control is read at the very start of the build, and the .dsc needs to match for archive consistency
[18:55] <dobey> ok, i'll try that
[18:57] <lifeless> barry: ping; nag.
[18:59] <meebey> looks like a desktop file can be blacklisted, so I could add a symlink in the metapackage and get the other one backlisted
[19:17] <doko> kees: see https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages (gcc-4.6 failures)
[19:18] <kees> doko: you're building on maverick, not natty? I only tested natty.
[19:19] <kees> ../../src/gcc/lto/lto.c:2464:1: internal compiler error: in ready_remove_first, at haifa-sched.c:1414
[19:19] <kees> uuuhm, whoa
[19:19] <kees> I don't think the hardening patches touch that file
[19:20] <SpamapS> slangasek: this works to avoid spinning for portmap too. I think its probably the way to go for waiting for an event.
[19:22] <doko> kees: same snapshot builds on unstable. will recheck next week with a new snapshot
[19:22] <dobey> cjwatson: that seems to work sufficiently for what i need it for; thanks!
[19:23] <kees> doko: hm, I wonder if maverick vs natty makes a difference?
[19:30] <Sarvatt> cjwatson: console-setup in depwait for bdfresize thats in universe if you didn't see :(
[19:32] <cjwatson> oh, bah
[19:33] <barry> lifeless: hi.  thanks for the reminder.
[19:34] <cjwatson> I got it MIR-approved eons ago - I'll promote it shortly
[19:34] <cjwatson> Sarvatt: ^-
[19:34] <Sarvatt> cjwatson: ah nice, thanks cjwatson!
[19:46] <manjo> superm1, do you have any insight into  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588194 ?
[20:04] <zyga-efika> is the Toolchain WG call over
[20:04] <zyga-efika> I'd like to see michael hope
[20:07] <superm1> manjo, no sorry i can't say i've seen that before
[20:08] <manjo> superm1, existed since lucid apparently
[20:08] <manjo> superm1, looks like acpi related
[20:14] <evfool> hi all
[20:16] <evfool> trying to build unity from source, but I guess the https://wiki.ubuntu.com/Unity/InstallationGuideFromSource needs an update, cause nux can-t be built without gnome-common from svn
[20:31] <cyphermox> evfool, maybe not so helpful for you, but if you're on natty, you can use the packages provided, unless you need to change them ;)
[20:43] <SpamapS> slangasek: ok, pormap and nfs-utils changes are pushed up and merges proposed
[20:43] <SpamapS> portmap even
[21:03] <bdrung> cjwatson: you synced pwdhash 1.7-9, but it doesn't appear on https://launchpad.net/ubuntu/+source/pwdhash . what's going on?
[21:20] <sebner> bdrung: cjwatson : Same with monobristol
[21:21] <bdrung> same with audacious
[21:23] <sebner> meh
[21:24] <micahg> it's the same with everything that was sync'd today AFAICT
[21:25] <sebner> breaaaaaaaaaaaaakage
[21:47] <geser> syncs not flushed yet?
[22:29] <kirkland> barry: howdy, around?
[22:30] <barry> kirkland: hi
[22:48] <hallyn> has anyone noticed that debdiff on natty always seems to add a bunch of .po files to the diff, when in fact you made no changes by hand to those files?
[22:49] <ebroder> that's usually due a broken clean target
[22:49] <hallyn> hm.  i've seen that with just about every package i've touched in the last two months,
[22:50] <ebroder> i mean...debdiff isn't going to go making that sort of thing up
[22:50] <hallyn> ebroder: right, I just don't know what to blame :)  automake?
[22:51] <ebroder> hallyn: i don't really know. i haven't run into one of those sorts of packages recently, and it's never quite bugged me enough to chase after me
[22:52] <hallyn> ebroder: yeah, ditto.  It might be getting close enough.  If I can close some other bugs I may have to go chase that down
[22:52] <hallyn> thanks
[22:52] <ebroder> err, chase after *it, as i'm sure you figured
[22:53] <hallyn> heh, somehow i hadn't even noticed htat :)
[23:10] <bdrung> hallyn: that (.po files to the diff) happens often if you build the binaries.
[23:15] <hallyn> bdrung: I just don't remember ever seeing that with maverick, but am seeing it all the time with natty
[23:16] <bdrung> hallyn: i assume this workaround should work: build only source (debuild -S) and build the binaries with pbuilder/sbuild.
[23:17] <hallyn> bdrung: I *thought* I'd had this happen even with taht workflow, but can't swear by it.
[23:17] <hallyn> if it happens again I'll ring :)
[23:18] <bdrung> yes, and then let's find this bug that triggers the diff
[23:39] <lifeless> barry: what version of python did .pth files start working in?
[23:41] <cjwatson> bdrung: sorry, I just forgot to flush them.  flushing now
[23:42] <bdrung> thanks