[02:12] <__keybuk> kees: weird
[02:13] <__keybuk> your patch to vte to fix bold fonts seems to break subpixel rendering
[02:14] <__keybuk> I can't see why it would though
[02:36] <__keybuk> oh, no, weird
[02:36] <__keybuk> it's a fontconfig issue
[02:38] <__keybuk> seems that its settings override gnome's, at least for gnome-terminal
[02:38] <__keybuk> ArneGoetje: ?
[02:49] <ArneGoetje> Keybuk: gnome-terminal uses vte for its terminal. vte does not use gnome settings but fontconfig. That's why.
[02:50] <ArneGoetje> __keybuk: ^
[03:14] <Keybuk> ArneGoetje: but it worked in gutsy?
[03:15] <Keybuk> oddly enough, if I remove the fontconfig directory, gnome-terminal does appear to obey gnome settings
[03:16] <Keybuk> indeed, it obeys them enough that they update live with changes to the font rendering dialog
[03:16] <Keybuk> so it seems that it's more that vte allows fontconfig to override xsetting
[03:16] <Keybuk> whereas other gnome apps only obey xsetting ?
[03:17] <Keybuk> (with the added sub-bugs that fontconfig doesn't follow the preferences *and* fontconfig doesn't honour user changes to its conf.d directory)
[03:25] <TheMuso> Yay for daily alternate CD brokenness.
[03:34] <ArneGoetje> Keybuk: yeah... seems like there is more to fix...
[03:38] <ArneGoetje> Keybuk: I guess that other gnome apps allow fontconfig to override xsetting...
[03:39] <ArneGoetje> Keybuk: err... do not allow, of course
[03:46] <TheMuso> oh its to do with a new kernel I think...
[04:08] <kirkland> TheMuso: you get a chance to look at the mdadm/initramfs-tools stuff i was working on?
[04:28] <TheMuso> kirkland: Yeah looks fine to me. I also got my change uploaded as well. Now if someone uses usplash and has such errors, they will actually see them.
[04:29] <kirkland> TheMuso: ;-)  cool
[04:29] <kirkland> thanks for taking a look
[04:30] <TheMuso> kirkland: np.
[04:30] <TheMuso> kirkland: One thing I forgot to check is that the documentation in the manpage was updated...
[04:31] <TheMuso> Rather, whether the docs were updated.
[04:31] <TheMuso> in the example script and the manpage.
[04:32] <kirkland> i didn't touch the docs (yet)
[04:32] <TheMuso> kirkland: Right, because nothing is finalized?
[04:33] <kirkland> TheMuso: right, i definitely have more to do on this
[04:33] <TheMuso> kirkland: Ok.
[04:33] <kirkland> TheMuso: but my current focus has been shifted to iscsi support in the installer
[04:33] <TheMuso> kirkland: Gotcha.
[04:33] <TheMuso> kirkland: How is that going by the way?
[04:34] <kirkland> TheMuso: well, i saw an iscsi target as a block device on the initiator for the first time today ;-)
[04:34] <kirkland> TheMuso: it was an "aha" moment :-)
[04:34] <kirkland> TheMuso: evand is here in Austin this week, so he's given me some good pointers
[04:35] <TheMuso> Ah ok.
[04:35] <TheMuso> kirkland: How much work was it to get the device to be seen in the initiator?
[04:35] <kirkland> TheMuso: anyway, i've figured out the userspace magic to get it to the point of seeing a block device, so I'm over the initial hump
[04:35] <TheMuso> kirkland: Nice.
[04:36] <kirkland> TheMuso: fairly well documented here: http://www.howtoforge.com/iscsi_on_linux
[04:36] <TheMuso> ah ok.
[04:36] <kirkland> TheMuso: once you've discovered the target identifier, it's not much more than:
[04:36] <kirkland> iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84211978 -p 192.168.2.222:3260 --login
[04:37] <TheMuso> kirkland: Nice.
[04:37] <kirkland> where "iqn...." is the identifier and 192..... is the IP
[04:37] <kirkland> TheMuso: discovery is fairly straight forward too:
[04:37] <kirkland> iscsiadm -m discovery -t st -p 192.168.2.222
[04:37] <kirkland> that should print out some awk-able  iqn.1992-08.com.netapp:sn.84211978 looking strings
[04:38] <TheMuso> Nice.
[04:38] <kirkland> TheMuso: I still need to figure out the /etc/fstab magic
[04:39] <kirkland> TheMuso: i better call it a night... we're at Dell again tomorrow
[04:40] <TheMuso> kirkland: Ok have fun.,
[04:51] <jack> hi
[04:51] <jack> any packages.ubuntu.com admin around?
[05:02] <LaserJock> jack: Frank Lichtenheld's email address is on the packages.ubuntu.com page
[05:05] <jack> uhm, ok
[05:06] <jack> just wanted to let someone know all source download links are broken
[05:06] <LaserJock> well, packages.ubuntu.com is still in a state of flux perhaps
[05:07] <jack> how/why this?
[05:07] <LaserJock> jack: packages.ubuntu.com isn't formally run by the Ubuntu
[05:07] <LaserJock> it is/was Frank's service
[05:07] <jack> oh ok
[05:07] <LaserJock> but he emailed a while back to say that he was running out of resources to do
[05:08] <LaserJock> it
[05:08] <jack> a nicce service, though
[05:08] <LaserJock> so I'm not sure if it's on a new host now or not
[05:08] <LaserJock> perhaps that's what broke it
[05:08] <LaserJock> yes, it's a very needed service
[05:08] <jack> you should sponsor that guy a bit maybe ;(
[05:09] <johanbr> Well, the IP it's on now belongs to canonical.
[05:09] <LaserJock> well, I've just got a DSL connection and an old machine ;-)
[05:09] <LaserJock> johanbr: ah good
[05:10] <LaserJock> jack: my guess is that the move is still being worked out
[05:10] <jack> ok
[05:10] <LaserJock> I'm not sure who'd responsible for it right now
[05:10] <LaserJock> *who'd be
[05:11] <jack> it's a minor flaw anyway
[05:11] <jack> i can find out the links of course
[05:12] <LaserJock> well, it'd be nice to get it fixed though
[05:12] <jack> just a bit ugly ;)
[05:12] <jack> yeah
[05:30] <pwnguin> anyone have a good citation for the time someone realize Debian had a ton of money just sitting around?
[05:34] <pwnguin> (am i miremembering it?)
[05:35] <slangasek> doesn't ring a bell
[05:37] <pwnguin> i coulda sworn there was someone who was like "oh, we have all this money we forgot about" maybe im thinking of the linux fund?
[05:37] <pwnguin> like 2003, 2004-ish
[05:38] <RAOF> I seem to recall something like that, too.  Didn't a bunch of porter boxes get bought with it?
[05:38] <pwnguin> basically, im trying to do the research jeff atwood didnt
[05:38] <pwnguin> provided i dont get hit by tornado
[05:39] <pwnguin> sounds pretty bad outside right now
[05:43]  * RAOF doesn't get the reference
[05:44] <pwnguin> theres a thunderstorm
[05:44] <pwnguin> i mean a literal tornado; no metaphor here
[05:45] <pwnguin> http://www.wunderground.com/
[05:45] <pwnguin> anyways, back to digging
[05:53] <slangasek> pwnguin: I don't believe we ever discovered money we'd forgotten about; Debian's parent corporation, SPI, has a checkered history when it comes to receiving and accounting for donations
[05:54] <slangasek> ("accounting for" in the sense that donations were received and in the early days, no records were kept of the earmarking and it wasn't clear how much of the money was meant to be an SPI cut vs. a Debian cut)
[05:55] <pwnguin> i guess it was linuxfund
[05:56] <pwnguin> not the spi
[05:57] <StevenK> slangasek: But there was a period in 2003 or 2004 where we just spend any of it. I'm not sure if that has changed.
[05:58] <slangasek> Debian did go through a phase when SPI suddenly was roused and became functional and Debian actually started /using/ some of the money, so I guess that sorta fits the description
[05:58] <pwnguin> heh
[06:45] <pitti> Good morning
[06:45] <pitti> ScottK: ah, not ATM; it won't give you the error for @kubuntu.org, although it probably should
[06:53] <emgent> moin pitti :-)
[07:07] <dr-know> hi
[09:16] <huats> morning all
[09:48] <mvo> pitti: do you have any idea about bug #249024 ? its the second report I have seen about this, it seems that for some reason localedef hangs for some people (#253180 is the other one)
[09:48] <pitti> mvo: incidentally I'm just debugging this
[09:49] <mvo> pitti: heh :) is there another bug already that I should duplicate this to?
[09:49] <pitti> mvo: I'm using bug 249340
[10:15] <cjwatson> mvo: localedef uses a metric shitload of memory
[10:15] <cjwatson> mvo: in my "spare" time (ho ho) I've been working on paring it down, though am having some difficulty ensuring that it remains correct at the same time
[10:16] <cjwatson> mvo: but given that at the moment it uses 50MB or so, it's quite plausible that people's systems are simply thrashing to death
[10:16] <pitti> I just tried to create a gutsy chroot and upgrade locales, belocs-locales-bin, and libc6 to hardy, and it worked well (with the same locales as mentioned in the bug)
[10:16] <cjwatson> though that said I see that 253180 claims 1.2GB of memory, so probably not that in that case
[10:16] <pitti> cjwatson: hm, but 50 MB doesn't sound too scary?
[10:16] <pitti> I mean relative to modern memory sizes, not relative to the task it has to do
[10:17] <cjwatson> pitti: on a 256MB system it's probably enough to shove lots of other things into swap
[10:17] <mvo> cjwatson: I got a report by someone with 1,2gb of ram, so that is probably not the reason
[10:17] <cjwatson> it's certainly a chunk of what's responsible for making installations suck on 256MB systems
[10:17] <mvo> I was wondering if it might be a fd leak (update-manager might leak some)
[10:18] <mvo> but I haven't seen this problem in all my upgrade testing so far
[10:20] <Hobbsee> cjwatson: ah, thanks for the reminder about memory thrashing.
[10:20]  * Hobbsee goes to burn an alternate cd, for the friend with 230mb of ram.
[10:21] <cjwatson> fd leak does seem plausible-ish if it only seems to happen in u-m
[10:25] <pitti> sjoerd: any idea how to forge intrepid's kvm to boot a gutsy CD? I just get an unintelligible exception dump
[10:26] <pitti> erm, soren ^ I mean; sorry, sjoerd
[10:38] <soren> pitti: I actually thought it would Just Work[tm], but if not, there's the hack in the "How to boot Dapper, Edgy, Feisty or Gutsy ISO" section of https://help.ubuntu.com/community/KVM
[10:55] <tseliot> pitti: why does Jockey think that nvidia-glx-96 is the right driver for my card (ubuntu-core-dev/jockey/ubuntu branch)?
[10:59] <tseliot> pitti: my card is supported by 177, 171, 96 and Jockey doesn't show multiple version (on purpose, I guess) and installs 96. The highest number should be preferred over the lowest
[11:02] <tseliot> unless there's a driver which supports all the available graphics cards
[11:08] <pitti> tseliot: it should show all three of them actually
[11:09] <tseliot> pitti: I built jockey from the ubuntu-core-dev/jockey/ubuntu branch
[11:09] <pitti> tseliot: hm; do you have all modalias packages installed?
[11:10] <tseliot> pitti: yes, they are installed
[11:12] <pitti> tseliot: hm; can you please do the foreground daemon/--debug exercise then?
[11:12] <pitti> tseliot: it did work fine the last time we tested it, didn't it?
[11:13] <tseliot> pitti: yes, it did. I have modified xorg_driver.py and the custom handler but that should affect only the X part
[11:13] <pitti> aah
[11:13] <pitti> tseliot: does it work with the current intrepid packages?
[11:14] <tseliot> pitti: I haven't checked yet
[11:14] <tseliot> pitti: http://pastebin.com/m28cd8458 log
[11:14] <pitti> I currently have my amd64/nvidia box running, trying here..
[11:15]  * tseliot gets the current package
[11:16] <pitti> 2008-07-30 11:11:30,712 DEBUG: querying driver db <jockey.detection.LocalKernelModulesDriverDB instance at 0x9c4c8cc> about HardwareID('modalias', 'pci:v000010DEd000002E2sv00000000sd00000000bc03sc00i00')
[11:16] <pitti> 2008-07-30 11:11:31,264 DEBUG: no corresponding handler available
[11:16] <pitti> tseliot: ^ seems it doesn't find it at all for you ATM
[11:17] <pitti> tseliot: with the current intrepid packages I get all three versions
[11:17] <pitti> (my GeForce 5200 is supported by all of them, it seems)
[11:17] <pitti> tseliot: did you run the test suite? any regressions from your modifications?
[11:18] <tseliot> pitti: it seems to work well with the current package.
[11:18] <tseliot> I'll do some testing with it
[11:19] <tseliot> pitti: no, I didn't run your test suite. I would like to write something customised but I have to study your test suite first
[11:19] <pitti> tseliot: just try running it
[11:19] <pitti> tseliot: it doesn't make assumptions about guidance, it just does blackbox testing
[11:20] <pitti> after the move to x-kit, the entire set of tests should still succeed
[11:22] <tseliot> pitti: is there a file which executes all the tests?
[11:22] <pitti> tseliot: just call "tests/run"
[11:25] <tseliot> pitti: 3 failures and 2 errors. 2 errors and 1 failure should be my fault
[11:25]  * tseliot tries to debug things a bit
[11:25] <pitti> tseliot: please compare with current trunk
[11:26] <pitti> tseliot: occasionally one of the XML-RPC tests fails due to a race condition in the test suite
[11:26] <pitti> tseliot: feel free to pastebin and let me comment
[11:26] <tseliot> pitti: ok, I'll try the current trunk
[11:28] <tseliot> pitti: failures=2, errors=2
[11:28] <tseliot> errors for trunk:
[11:28] <pitti> tseliot: hm, fun; please show me? (they all succeed for me)
[11:30] <tseliot> pitti: the log for trunk: http://pastebin.com/m4f1751bf
[11:31] <pitti> tseliot: can you please pastebin the test suite output?
[11:31] <pitti> tseliot: log is only helpful together with it
[11:32] <tseliot> pitti: yes, I know, I'm uploading the output
[11:33] <tseliot> pitti: output: http://pastebin.com/m4788c4fb
[11:34] <tseliot> this is without X-Kit
[11:34] <pitti> mvo: hm, I just tried to upgrade a freshly installed gutsy to hardy in vmware; it gets as far as updating the package index, and then just disappears
[11:35] <pitti> mvo: main.log ends with "runing doUpdate() (showErrors=True)", no exception or so
[11:36] <pitti> mvo: http://piware.de/tmp/apt.log -> does that tell anything to you?
[11:36] <pitti> mvo: no exceptions on stdout/stderr either, BTW
[11:38] <pitti> tseliot: ah, the package thing is certainly because you don't have packagekit installed
[11:40]  * tseliot installs packagekit-gnome
[11:40] <pitti> tseliot: no, not -gnome
[11:40] <pitti> tseliot: the ubuntu branch doesn't use packagekit yet, but trunk does
[11:40] <pitti> (well, -gnome doesn't hurt of course, but jockey doesn't use it)
[11:40] <tseliot> pitti: packagekit is a dependency of packagekit-gnome
[11:41]  * tseliot runs the test suit again
[11:43] <tseliot> pitti: http://pastebin.com/m2a674f05 http://pastebin.com/m7d290e80
[11:44] <pitti> tseliot: hm, no real idea right now about those two failures
[11:44] <pitti> but they should be totally unrelated to the xorg drivers, so maybe ignore them for now
[11:45] <pitti> tseliot: let's track those down later, shall we?
[11:45] <tseliot> pitti: ok
[11:47] <pitti> mvo: I tried it again, this time with enabling universe/multiverse; same failure
[12:08] <sebner> tseliot: ping =)
[12:08] <tseliot> sebner: yes?
[12:09] <sebner> tseliot: I was on holidays ^^, now time to look at my Xorg.log to discover why nvidia-glx isn't working?
[12:10] <tseliot> sebner: can you send me an email with the log? I'll have a look at it later
[12:10] <sebner> tseliot: great, thx
[12:12] <mvo> pitti: oh, how strange. let me try that
[12:15] <mvo> pitti: could you strace it just to get some idea what might go wrong? maybe its segfaulting somewhere?
[12:16] <pitti> mvo: currently running apt-get dist-upgrade; I can do that afterwards, yes
[12:16] <pitti> mvo: shouldn't a segfault be displayed in the terminal, thuogh?
[12:17] <pitti> hm, maybe the root backend crashed, and the user-invoked GUI just exited with it
[12:18] <pitti> mvo: does it crash on unsatisfieable dependencies or so? apt.log seemed to have some resolution trouble, but nothing it couldn't handle AFAICS
[12:20] <mvo> pitti: it should not crash because of dependencies or anything like this, but if it does, the only explaination I have right now is a segfault somewhere
[12:20] <mvo> pitti: thanks, Please let me know what you found
[12:20] <pitti> ok, will do
[12:20] <pitti> mvo: dist-upgrade will still take a while, though
[12:21] <mvo> no problem, I fire up my vmware just to see if that is a general problem here
[12:22] <pitti> mvo: argh, I just accidentally killed the d-u, so I can as well do it now
[12:23] <pitti> mvo: how do I strace the 'inner' u-m which runs as roo?
[12:23] <pitti> mvo: or can I just call "sudo strace update-manager", does that work?
[12:24] <mvo> pitti: sudo strace -f update-manager should work I think
[12:24] <pitti> ok, doing
[12:24] <mvo> thanks
[12:25] <pitti> ok, crashed again
[12:26] <pitti> mvo: you were right, segfault
[12:27]  * pitti runs under gdb
[12:28] <pitti> mvo: ah, it's ignored by apport because it happens in the downloaded code
[12:30] <mvo> pitti: hm, that sets itself to /usr/bin/update-manager iirc. where does the crash happen ? somewhere in python-apt/libapt?
[12:30] <pitti> mvo: ?? -> ?? -> PyString_FromString () -> ??
[12:30] <pitti> the second ?? is in libglib
[12:31] <pitti> and the topmost (first) ?? is at address 0
[12:31] <pitti> not too helpful, I guess?
[12:31] <mvo> pitti: could you please paste the full thing somewhere? or is that all relevant information?
[12:31] <pitti> mvo: stack trace? that's all
[12:31] <mvo> pitti: meh, that is indeed not a lot
[12:32] <pitti> mvo: you can have the strace if you want, but it's largely uninteresting
[12:33] <pitti> it was a standard i386 gutsy desktop install, then apt-cdrom add the hardy.1 dvd
[12:33] <pitti> and then u-m
[12:34] <mvo> pitti: how big is the virutal image? I suppose to big to sent it over the network?
[12:34] <mvo> pitti: I will try to reproduce it here
[12:34] <pitti> mvo: ugh, 8 GB; I'm afraid it is, yes :/
[12:35] <mvo> pitti: hm, could you tar up /var/lib/dpkg and /var/lib/apt and /var/cache/apt (after apt-get clean) and /etc/apt/ and put that somewhere? maybe that is enough to reproduce it
[12:35] <pitti> sure
[12:37] <pitti> mvo: I'll add /var/log/dist-upgrade and /etc/apt, too
[12:37] <mvo> pitti: thanks
[12:42] <pitti> mvo: http://www.piware.de/tmp/apt-status-gutsy-about-to-upgrade.tar.bz2
[12:43] <mvo> pitti: thanks, downloading
[12:44] <pitti> mvo: hm, hang on; I ran gutsy-final, not gutsy-updates; might that be it?
[12:45] <mvo> pitti: I can reproduce it here it seems, let me debug it further. it might be because of this, but I don't remember a fix in python-apt in gutsy-updates that would have this effect
[12:45] <pitti> mvo: there's no p-a in gutsy-updates
[12:46] <pitti> mvo: I'll upgrade some essential bits of this gutsy install before I dist-upgrade to hardy
[12:48] <mvo> pitti: ok
[12:48] <pitti> mvo: (python2.5, apt, update-manager)
[12:49] <ScottK> Good morning pitti.  I think allowing kubutu.org addresses is a good thing.  I know a number of people who use those and not ubuntu.com even though they have one.
[12:50] <pitti> ScottK: it's not a matter of "allow"; it's a matter of requiring correct Maintainer: fields from @kubuntu.org maintainers, too
[12:50] <pitti> so it doesn't break, but of course I agree that the regexp shold be fixed
[12:50] <ScottK> Ah.
[12:52] <pitti> mvo: damn, same segfault with those guty-updates packages :/
[12:53] <mvo> pitti: :( I think I found the bug, strange that it wasn't seen earlier
[12:53] <pitti> mvo: oh, wow, that was fast. you rock!
[12:54] <mvo> pitti: it seems like the Priority is NULL for some package on the CD and that makes it crash, I'm trying to figure out which package is causing this now and add some safeguard against this kind of failure
[12:56]  * pitti runs another test dist-upgrade and toddles off to lunch in the meantime
[12:58] <doko> err, there is both webkit and webkitkde???
[13:05] <mvo> pitti: for some reason openssh-blacklist and openssl-blacklist have no priority, this is causing the crash. I'm preparing a sru for python-apt now so that it at least does not crash
[13:07] <doko> seb128, asac_ : did gnome just copy webkit, and we now have two copies in main? one in qt4/kde4 and one for gnome?
[13:08] <seb128> doko: "webkit" is not a GNOME thing, it's upstream webkit
[13:09] <doko> but kde doesn't use it?
[13:09] <ogra> its an apple thing :)
[13:09] <doko> Riddell: ^^^
[13:10] <mvo> pitti: seems to be only happening with the CD too
[13:11] <stefanlsd> am i allowed to ask a silly bash question here?
[13:17] <mvo> pitti: I filed #253255 for this crash
[13:49] <sommer> slangasek: wondering if you have time for a pam, kerberos, auth-client-config question?
[13:50] <mvo> pitti: I wonder how it happens that the priority did not end up on the CD for those packages. I'm preparing fixes now
[13:56] <pitti> re
[13:57] <pitti> mvo: maybe because the 8.04.1 CD has a special hack to use ssh from hardy-final? we wanted to avoid adding the openssh-blacklist package to the live CD, since it took too much space and isn't necessary for the live environment
[14:04] <pitti> Riddell (CC: doko): how come that webkitkde doesn't build-depend on webkit? /me sniffs a code copy
[14:05] <doko> pitti: afaiu webkitkde is included in kdelibs5-dev
[14:05] <mvo> pitti: would that affect the alternate cd as well? because this is where I see the error
[14:06] <pitti> mvo: oh, right, of course the desktop CD is irrelevant here (I'm using /pool on the DVD as an apt source)
[14:07] <tkamppeter> pitti, doko, https://wiki.ubuntu.com/MainInclusionProcess has a bug: Step 7 is unnecessary, as this part is already done in step 5.
[14:08] <pitti> doko: ah, and webkitkde is just the plugin, not the engine
[14:08] <tkamppeter> doko, what does it mean that you have set my MIR bug 253123 to "In Progress"? Are you currently reviewing it?
[14:09] <doko> tkamppeter: waiting for an archive-admin to process
[14:10] <pitti> tkamppeter: I just promoted it FYI, and closed the bug
[14:13] <pitti> doko: ISTR that we can demote lesstif2 again? or was this just a dream?
[14:13] <pitti> oh, it is already
[14:13]  * pitti closes the bug then
[14:13] <tkamppeter> pitti, thanks.
[14:14] <pitti> so, all remaining bugs on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs are incomplete
[14:14] <doko> lesstif can go
[14:14]  * pitti hugs doko for his reviewing
[14:16] <tkamppeter> Riddell, hal-cups-utils should get installable again in some hours.
[14:26] <pitti> mvo: is bug 253255 actually an issue in update-manager? or only in p-apt?
[14:26] <mvo> pitti: python-apt, but I added a workaround into update-manager too for good measure
[14:27] <pitti> mvo: ah, sweet; do you think we need the workaround in hardy-updates, too? or will the p-apt fix suffice?
[14:27] <pitti> mvo: oh, I see; you mean for the cases where you dist-upgrade from gutsy-final instead of gutsy-updates
[14:27] <mvo> pitti: I think it won't hurt to have it in hardy-updates in updat-emanager too, its a pretty small workaround
[14:27] <pitti> mvo: I keep that VM around for verifying the SRU
[14:27] <mvo> pitti: thanks a lot!
[14:27] <pitti> mvo: I agree
[14:28] <pitti> mvo: thanks to you for the fast fix!
[14:28] <mvo> I still wonder how that slipped during the 8.04.1 qa :(
[14:31] <mvo> pitti: any luck with the localegen hang yet?
[14:33] <pitti> mvo: no, it worked fine in all three scenarios that I tried
[14:33] <pitti> I guess I have to try again with u-m
[14:39] <erikg> does ubuntu have a recovery mode invokable when the system's root partition fills up and writes become impossible?
[14:44] <pitti> erikg: in this case we mount an 1 MB tmpfs to /tmp, so that you can at least log in
[14:45] <pitti> we are still working on a program to do some guided cleaning, though, ATM you have to clean up yourself
[14:45] <erikg> pitti: i've worked out a scheme to run a union mount
[14:46] <mvo> erikg: there is also a recovery-menu that might be useful, however it does not have a "make free space" item yet (also that is probably a good idea to add)
[14:46] <erikg> ... a tmpfs+root overlay
[14:46] <erikg> with aufs (and the uber-buggy unionfs) you can run a script which checks which files are 'deleted' and remove them from the underlying fs
[14:46] <erikg> all software will run provided there is enough ram
[14:47] <erikg> is this roughly what y'all are doing?
[14:48] <cjwatson> we don't use a unionfs, we just slap a tmpfs on /tmp which is enough to get gdm going
[14:48] <cjwatson> we'd rather not have any kind of union filesystem involved outside the live CD
[14:48] <erikg> is the concern about code stability?
[14:49] <cjwatson> once bitten, twice shy
[14:49] <erikg> have you tested aufs?
[14:49]  * erikg is a two-brick kind've guy
[14:49] <cjwatson> I don't care :)
[14:49] <pitti> *cough*
[14:49] <cjwatson> the less code involved when your system is already screwed, the better
[14:49] <cjwatson> KISS
[14:50] <cjwatson> we're using aufs on the live CD now
[14:50] <emgent> evening
[14:50] <erikg> cool
[14:50] <cjwatson> that seems sufficient
[14:50] <erikg> cjwatson: yup.  makes sense.
[14:51] <cjwatson> although, since I'm a pessimist, I assume that it will simply exchange the bugs we knew about for different bugs we haven't worked around yet :P
[14:52] <cjwatson> we had tested unionfs exhaustively in the live CD for two years, and worked around or fixed the major problems that bit us
[14:52] <cjwatson> we have tested aufs for one milestone release of intrepid
[14:52] <cjwatson> not really the same thing :)
[14:53] <pitti> I wonder which interesting interactions it will do with AppArmor this time
[14:53] <erikg> i ran into serious issues using unionfs on top of jffs2.  aufs didn't smoke nearly as much.
[14:53] <cjwatson> I'll let you know in two years
[14:54] <erikg> i'll be happy to hear
[14:54] <cjwatson> until then, I'll remain sceptical, I think ;)
[14:54] <erikg> i admire your skepticism :)
[14:55] <erikg> if, in two years you find aufs to be trustable, you can use it to implement system recovery at a low enough level that software on the system need not be told what's going on.
[14:55] <erikg> that's my thought.  i've been working on the idea for a week or so.
[14:56] <cjwatson> I don't think you'd want to run it too silently
[14:56] <erikg> you just need a flag of some kind that a recovery console can find on dm startup to inform the user of what's going on and offer recovery solutions.
[14:56] <cjwatson> after all, if the overlay is a tmpfs, power failures will lose any data that an unwitting user creates
[14:56] <erikg> right.  ^^
[14:56] <erikg> you have to tell them very loudly what's going on.
[14:57] <cjwatson> it seems like unnecessary complexity when you could just mount a tmpfs and help them to delete unnecessary files, though
[14:57] <cjwatson> what is the *advantage* of a union filesystem approach?
[14:58] <cjwatson> seems like you actively wouldn't want the user to be able to run all applications completely smoothly
[14:58] <cjwatson> because then, well, they might use them ... and start trying to save files etc. "well, it all seems to work, I'll just get this done"
[14:58] <erikg> right
[14:59] <erikg> you're just trading one set of problems for another
[14:59] <erikg> if you go the recovery console approach then there is no specific advantage.
[15:00] <erikg> in that case the union filesystem code paths add a lot of potential complexity.
[15:02] <erikg> the specific advantage of the recovery-mode solution is the amount of code change required to get unaware applications, dms, etc. running on the recovery-mode system is much less.
[15:02] <erikg> because the system presents a familiar face to them.
[15:03] <erikg> that's maybe totally unnecessary
[15:04] <erikg> and as you said potentially confusing.
[15:08] <Hattory> Hi asac, can you please take a look at bug 252793 ?
[15:20] <lamont> jdstrand: wth is /etc/apparmor/severity.db named that?  it's not a *&)*^% db file
[15:20] <tseliot> pitti: what does XorgDriverHandler.can_change() do?
[15:23] <jdstrand> lamont: *shrug*
[15:23] <lamont> meh
[15:23] <lamont> it offends me
[15:24] <pitti> tseliot: if can_change() returns a string (and not None), it is the rationale why the driver cannot be enabled/disabled
[15:24] <pitti> tseliot: see Handler.can_change() documentation
[15:25] <pitti> tseliot: if current xorg.conf cannot be parsed, we better not modify it any further
[15:25] <jdstrand> lamont: apparently apparmor uses that file to map events into severity levels when logging
[15:25] <jdstrand> lamont: this is a nice touch though:
[15:25] <jdstrand> $ file ./severity.db
[15:25] <jdstrand> ./severity.db: ASCII Pascal program text
[15:26] <pitti> pah, it doesn't even end with "END."
[15:27] <lamont> jdstrand: yeah, but it means I can't tell my /etc-VCS of any choice to ignore '*.db'
[15:27] <pitti> . o O { IMHO real .db files don't belong into /etc in the first place }
[15:27] <pitti> *cough* postfix *cough*
[15:27] <mvo> pitti: a dist-upgrade just finished for me (in vmware, gutsy->hardy with no hangs via update-manager)
[15:27] <mvo> just fyi
[15:28] <pitti> mvo: with thew new p-apt? rocking!
[15:28] <tseliot> pitti: ok, thanks
[15:28] <mvo> yes
[15:28]  * pitti hugs mvo
[15:28] <jdstrand> pitti: well, it's not just postfix-- sendmail will do the same thing
[15:28] <mvo> pitti: but no hangs in localegen
[15:28] <pitti> jdstrand: yeah, unfortunately
[15:28] <pitti> but IMHO these belong into /var/cache/
[15:29] <jdstrand> I'd agree with that
[15:29] <pitti> or at least /var/lib, if people want to deliberately keep the /etc/ master and .db file inconsistent
[15:29] <jdstrand> I see your point though-- users aren't suppoed to touch those .db files, so why in /etc?
[15:30] <pitti> /etc/libgda-3.0/sales_test.db
[15:30] <pitti> *blink*
[15:30] <ogra> haha
[15:31] <ogra> great
[15:31] <lamont> pitti: yeah - is historical in origin
[15:33]  * lamont wonders idly if xkb is needed anywhere outside of, um, X
[15:33] <lamont> (with apologies to the name-pedants from MIT)
[15:34] <lamont>  /etc/hddtemp.db: ISO-8859 English text
[15:34] <lamont> sigh
[15:38] <geser> soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge?
[15:40] <pitti> lamont: even then, what's wrong with ignoring all *.db by default? did you actually come across any which you would actively want to manage in VCS?
[15:40] <pitti> lamont: (even then you can still explicitly add it...)
[15:41] <lamont> pitti: depending on the vcs
[15:41] <lamont> but yeah
[15:41] <ion_> I’d suggest managing /etc with e.g. puppet and having puppetmaster’s rules in VCS, not the actual /etc.
[15:41] <lamont> one could also argue that keeping *.db in the vcs is perfectly fine
[15:42] <lamont> ion_: too much work. :-)
[15:42] <zul> tkamppeter: ping
[15:42] <pitti> lamont: I only add/manage files I actually touched
[15:43] <lamont> pitti: managing everything is wonderful for noticing when (and how) a dist-upgrade trashed something you care about (now that it's wrong^Wdifferent)
[15:44] <pitti> I usually ignore unmodified conffiles, but yeah, for those purposes it's certainly handy
[15:44] <pitti> but too much noise for my taste
[15:45] <ion_> lamont: Initially there’s some work for sure, but if you ever have to replace the box with another that should behave identically, or replicate a certain change to multiple boxes, something like puppet will pay for itself.
[15:46] <lamont> true enough
[15:46] <lamont> ion_: is puppet VCS-centric?
[15:46] <ion_> Nope, you can pick any VCS you want.
[15:50] <lamont> ruby.  vomit
[15:51] <ion_> ruby ♥
[15:51] <lamont> language-du-jour crap
[15:51] <ion_> Not that you ever need to know or care which language puppet’s implemented in when using it.
[15:52] <ion_> AFAIU
[15:53] <thom> indeed
[15:57] <ion_> Hey, at least it’s nicer than python. :-)
[16:00] <jcastro> puppet is fantastic
[16:01] <cjwatson> lamont: yes, xkb is used by console-setup too
[16:06] <lamont> cjwatson: ok
[16:07] <lamont> thanks
[16:19] <pitti> I usually ignore unmodified conffiles, but yeah, for those purposes it's certainly handyoperation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=114 name="/etc/"
[16:19] <pitti> argh, what was that...
[16:20] <pitti> kees: do you know which apparmor rule is missing here: operation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=114 name="/etc/"
[16:20] <pitti> kees: I already have
[16:20] <pitti>   /etc r,
[16:20] <pitti>   /etc/** rmk,
[16:21] <pitti> kees: many rejects look like "wk::" (whcih is fine, I'll fix that); does the first, second, third position (separated by colons) matter?
[16:21] <sbeattie> pitti: change the first rule to /etc/ r, there was some small semantic changes around how directories are handled.
[16:21] <pitti> oh, trailing slash?
[16:22] <sbeattie> yes
[16:22] <pitti> aaah
[16:22] <pitti> thanks
[16:22] <sbeattie> Though I thought that came into effect in hardy or before.
[16:22] <kees> pitti: sbeattie beat me.  :)
[16:23] <pitti> the one thing I really don't like is that I essentially have to write all rules twice
[16:23] <pitti> once for the directory itself (/etc/), once for everything in it (/etc/**)
[16:23] <kees> pitti: the position wrt :'s indicates the type of access (user::group::other)
[16:23] <sbeattie> yes, that's a slight pain.
[16:23] <pitti> kees: ah, helpful; thanks
[16:24] <kees> pitti: but it doesn't really matter for writing rules, it's a future extention, AIUI
[16:26] <sbeattie> Yes, that's mostly correct; in particular the semantics around the group stuff will likely change.
[16:26] <pitti> ok, one other question while I have you both on the wire
[16:26] <pitti> [ 4350.726750] type=1502 audit(1217431494.911:211638): operation="file_lock" requested_mask="::wk" denied_mask="::k" fsuid=114 name="/var/log/wtmp" pid=19878 profile="/usr/share/gdm/guest-session/Xsession"
[16:27] <pitti> I have   #include <abstractions/wutmp>
[16:27] <pitti> I think I should file this as a bug, /etc/apparmor.d/abstractions/wutmp is missing a 'k' privilege
[16:27] <pitti> right?
[16:27] <sbeattie> I agree.
[16:27] <pitti> or is there any reason to deny this by default in wutmp?
[16:28] <sbeattie> Not that I'm aware of; I'd assume everyone that's going to write to wutmp will try to lock it.
[16:28] <pitti> I think 'k' is fairly new (intrepid?)
[16:28] <pitti> at least it was new to me, last time I wrote AA rules was hardy (for cups)
[16:29] <pitti> ok, done (253328)
[16:30] <pitti> sbeattie, kees: thanks!
[16:30] <sbeattie> Hmm, I'm not actually sure what version of apparmor went in to hardy; it may be new.
[16:30] <tkamppeter> zul, hi
[16:30] <zul> tkamppeter: I noticed that you uploaded system-config-printer which version of samba does that work with?
[16:31] <sbeattie> pitti: you're welcome, always glad to have users of and feedback for apparmor!
[16:31] <pitti> sbeattie: I'm currently writing a profile for the guest user, and AA rules are handy for that (locking out of /home, etc.)
[16:31] <sbeattie> Cool!
[16:33] <tkamppeter> zul, the current upload is the s-c-p 1.0.x series and it works with Samba 3.0.x or later. It accesses Samba by calling command line tools.
[16:34] <zul> tkamppeter: ok because we have samba-3.2 for intrepid
[16:34] <pitti> sbeattie, kees: hm, seems @{HOME} gets hardcoded to /home instead of the fsuid's home directory?
[16:34] <kees> pitti: unfortunately, yes.
[16:35] <pitti> argh
[16:35] <kees> AIUI, the kernel has no way to knowing fsuid's home dir
[16:35] <tkamppeter> zul, the GIT head branch (1.1.x) of s-c-p needs Samba 3.2.x. It access es via a Python bindings library written by Tim Wuagh.
[16:35] <pitti> kees: hm, how does that work then? i. e. what's the particular substituded value?
[16:35] <pitti> bash:  @{HOME}/.bashrc                  r,
[16:35] <pitti> is that basically "/home/*" ?
[16:35] <ion_> pitti: /me ♥ the guest account spec
[16:36] <pitti> ion_: you're welcome to try and test it, first version is in intrepid (pretty crappy still, though)
[16:36] <tkamppeter> zul, for now I have uploaded 1.0.x as Samab 3.2 did not arrive. According to yesterday's IRC talk it is waiting for a MIR on talloc.
[16:36] <kees> pitti: /etc/apparmor.d/tunables/home
[16:36] <pitti> ah, nice
[16:36] <pitti> eww, that has /root/, too
[16:36] <kees> pitti: feel free to branch the AA bzr tree and make patches to stuff as you see fit.
[16:37] <kees> pitti: doing an AA profile for a _user_ instead of a _process_ is likely going to be tricky.
[16:37] <zul> tkamppeter: uh ok..
[16:37] <ion_> pitti: /me aptitude updates. Yesterday there was still no guest-account package in the archive.
[16:37] <pitti> kees: yeah, I guess it would be pretty expensive to teach the kernel the fsuid's home dir
[16:37] <pitti> ion_: went in this morning
[16:37] <ion_> Cool
[16:38] <pitti> kees: well, to be precise it is for the process /usr/share/gdm/guest-session/Xsession and all of its descendants
[16:38] <pitti> kees: I wrapped that script around /etc/gdm/Xsession precisely to have a process anchor for AA
[16:39] <kees> ah-ha, okay.
[16:39] <pitti> that's much easier in SELinux, but that way it works in AA, too
[16:45] <pitti> denied_mask="::r" fsuid=114 name="/home/"
[16:45] <pitti> MUHAHA
[16:49] <ion_> pitti: /usr/share/gdm/guest-session/guest-session-launch started a new gdm login, but didn’t seem to run any of /usr/share/gdm/guest-session/*.sh
[16:49] <davmor2> I've noticed an issue with intrepid.  Everytime the screen goes blank (for the screensaver) a second or two after it wakes back up.  This means that it isn't cutting into power saving mode correctly :(
[16:49] <davmor2> What do I report it against?
[16:50] <pitti> ion_: just a gdm login? with the greeter?
[16:51] <pitti> ion_: you should have gotten a guest session right away
[16:51] <ion_> pitti: Yeah. Asking for a password.
[16:51] <pitti> ion_: do you have gdm 2.20.7-0ubuntu3 ?
[16:51] <ion_> pitti: Yeah
[16:51]  * pitti fixes that dependency
[16:51] <pitti> ion_: and restarted gdm since the upgrade?
[16:52] <ion_> pitti: Oh! Haven’t done that. Will do.
[16:52] <tseliot> pitti: xorg_driver + XKit passed all your tests. Yay!
[16:52] <pitti> tseliot: rocking!
[16:52] <pitti> ion_: dependency fixed in bzr head, thanks
[17:10] <aos101> bdmurray: Could you have a look at bug 199393 and see why it hasn't been verified yet?
[17:13] <jack> dolphin is obsolete now anyway
[17:13] <jack> successor = d3lphin
[17:14] <aos101> jack: But it's a SRU.  People still use Kubuntu 8.04 KDE3 :-)
[17:14] <jack> d3lphin is kde3
[17:15] <jack> the upstream folks dropped developing kde3 stuff, hence dolphin->d3lphin
[17:15] <jack> new guy
[17:16] <aos101> jack: The package was renamed I think.  The dolphin package is the KDE3 version in Hardy.
[17:16] <jack> oke
[17:18] <sbeattie> aos101: I haven't gotten around to verifying it yet, I'll try to get to it in the next day or so.
[17:19] <slangasek> sommer: shifted time, perhaps. :)
[17:19] <aos101> sbeattie: Thanks for taking a look.
[17:20] <sommer> slangasek: with the current auth-client-config kerberos example: http://paste.ubuntu.com/32251/ you can't get a ticket if your system password is the same as the kerberos principal password
[17:21] <sommer> slangasek: I was just wondering if there was some way to adjust it to where you can
[17:21] <sommer> slangasek: at least in my testing when the passwords are the same, it only authenticates using the shadow password
[17:22] <slangasek> sommer: configure 'minimum_uid' for pam_krb5, then list pam_krb5 first
[17:22] <slangasek> or 'ignore_root' instead of 'minimum_uid'
[17:23] <sommer> slangasek: awesome, I'll look into that... heard you were a pam genius, so I thought I'd ask, thanks
[17:30] <sommer> slangasek: thanks again, the 'ignore_root' worked great
[17:50] <warren> Hey folks, I suspect Adobe is about to release a VERY broken flash 10, and I need quick testing to confirm.
[17:50] <warren> I need testers using 32bit Ubuntu.
[17:50] <ogra> asac, ^^^^
[17:50] <warren> The test is simple:
[17:50] <warren> 1) Make sure you don't either do not have nspluginwrapper, or nspluginwrapper-1.1.0.  (nspluginwrapper-0.9.x does not support windowless plugins, which hides the crasher.)
[17:51] <warren> 2) http://labs.adobe.com/technologies/flashplayer10/  install Flash 10 beta plugin
[17:51] <warren> 3) Run firefox, check about:plugins, make sure you are running the plugin
[17:51] <warren> 4) go to http://weather.com
[17:51] <warren> kaboom?
[17:51] <ogra> warren, note that we dont have nspluginwrapper for 32bit anyway
[17:51] <warren> ok good, simpler test.
[17:51] <cody-somerville> warren, that issue is known
[17:51] <cody-somerville> warren, the bug is in Firefox
[17:51] <warren> bug #?
[17:51] <warren> oh?
[17:51] <warren> bug URL?
[17:52] <ogra> cody-somerville, not the pulse bug
[17:52] <warren> This has nothing to do with sound
[17:52] <ogra> warren knows about it
[17:52] <ion_> I’d like to have nspluginwrapper. :-)
[17:52] <warren> Flash (or something) is giving a NULL pointer and it crashes firefox somewhere in cairo.
[17:52] <warren> btw, where is your pulseaudio bug?
[17:52] <ogra> warren, asac would be the best to comment here (he maintains ff) but seems not around
[17:53] <warren> ogra: Any other tester with 32bit Ubuntu would be fine.
[17:53] <cody-somerville> warren, https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025779.html
[17:54] <warren> no lauchpad bug?
[17:54] <ogra> cody-somerville, that was because someone backported libflashplugin together with flash 10
[17:54] <warren> cody-somerville: where is the pulse bug?
[17:54] <warren> cody-somerville: did you backtrace it to cairo?
[17:54] <ogra> thats cant work, libflashplugin clashes with flash 10
[17:54] <warren> btw, you might want to try flash 10 without libflashplugin
[17:54] <cody-somerville> ogra, I don't think so
[17:55] <ogra> cody-somerville, wel, the only backport i saw depended on libflashplugin
[17:55] <cody-somerville> This was the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=435764
[17:55] <warren> We RH gave adobe some advice, and now pulseaudio alsa can handle flash directly without libflashplugin.
[17:56] <ogra> cody-somerville, so there was a backport without depentding on libflashplugin ? else trying out backports is moot
[17:56] <ogra> since thats definately broken
[17:57] <warren> oh, I see Adobe already knows about htis.
[17:57] <cody-somerville> ogra, The backport is not related to this discussion besides the face that the same bug showed its head then.
[17:57] <cody-somerville> s/face/fact
[17:57] <ogra> cjwatson, btw, another package to pull from the archive :)
[17:58] <cody-somerville> ogra, sorry if my lack of context with the link was confusing
[17:58] <ogra> cody-somerville, well, i always block on the fact that i know someone did that broken backport
[17:58] <ogra> and that it has to crash by design
[17:59] <warren> thanks for pointing out that upstreaa bug #
[17:59] <warren> that seems to be it
[17:59] <ogra> good
[17:59] <LaserJock> Ubuntu QA meeting in #ubuntu-meeting in 1 minute, if anybody's interested
[17:59] <ogra> well, that was good inter distro work :)
[18:00] <ogra> warren, we should definately talk more across the borders ;)
[18:00] <warren> ogra: I rather continue the war.
[18:00] <ogra> :P
[18:00] <warren> ogra: I forget why this war started.
[18:00] <warren> I just know I'm supposed to hate.
[18:00] <warren> =)
[18:00] <ogra> who cares as long as we can fight *g*
[18:01] <warren> ogra: oh right, the war started because we both needed propaganda to excite our users.
[18:01] <jcole> anyone here know where to find information on rebuilding a live cd, but re-building it in such a way that files are placed "in order" as they would boot up on the live cd? this supposedly drastically decreases the boot time... i read something about this trick a while back but cannot seem to find a link
[18:01] <ogra> heh
[18:06] <ogra> jcole, afaik you hav to patch the squashfs module for that
[18:07] <jcole> ogra: oh ok... ﻿this looks a looks like this may be a start to what im looking for -> http://lichota.net/~krzysiek/projects/kubuntu/dapper-livecd-optimization/
[18:08] <jcole> ogra: i would rather have a howto though, lol
[18:09] <ogra> yeah, i dont know how to make squashfs spit out the info though, but i know you need to add a patch
[18:55] <warren> ogra: ok, so I might spy.
[18:56] <ogra> :)
[20:01] <ion_> pitti: The guest session still doesn’t seem to work after restarting gdm. How to debug this? The screen goes blank, but then it just returns to my original session.
[20:03] <pitti> ion_: can you please enable debugging in gdm, try one guest login, and send me /var/log/syslog ?
[20:03] <pitti> /etc/gdm/gdm.conf-custom:
[20:03] <pitti> [debug]
[20:03] <pitti> Enable=True
[20:03] <ion_> Thanks, will do.
[20:03] <pitti> ion_: appreciated
[20:06] <ion_> pitti: Duh, it was my fault. I had created a ‘guest’ account before, and the script didn’t like that. “User account guest already exists and is not locked”
[20:06] <ion_> I’ll just remove the account.
[20:06] <pitti> ion_: ah, that's indeed a safety measure I built in
[20:06] <pitti> ion_: I think in that case I should create a guest2 account or so
[20:06] <pitti> the -setup.sh script should iterate until it finds a unused one, until a reasonable limit
[20:07] <pitti> but that's a bit hairy
[20:07] <ion_> Perhaps guest-$(uuidgen) :-P
[20:07] <pitti> if you exit the guest session normally, the temporary account is deleted again, but that doesn't always work (if your system crashes, or you don't log out the server, etc.)
[20:07] <hwilde> anybody for help on ssh ? :(
[20:08] <hwilde> I can ping and telnet to port 22 but ssh rejected :((    http://paste.ubuntu.com/32303/
[20:09] <pitti> hwilde: anything more helpful in the server-side log?
[20:10] <hwilde> if I could get to it
[20:10] <hwilde> :/
[20:11] <hwilde> it fails right after the KEXINIT but the keys are (were) setup and even so it should failover to keyboard-interactive
[20:11] <pitti> the "connection reset by peer" doesn't actually look like a proper ssh message; rather rejection by firewall or something
[20:11] <hwilde> no firewall, it's a direct connect, on the same subnet even
[20:12] <hwilde> 10.0.84.100 to 10.0.84.202
[20:12] <hwilde> and I can get to .201 and .203
[20:12] <hwilde> plus a firewall would reject before it tries kexinit right?
[20:12] <hwilde> it would just straight up block port 22
[20:12] <hwilde> so it wouldn't get to  debug1: Connection established.
[20:12] <hwilde> and telnet would also fail then
[20:13] <ion_> pitti: The session opened nicely, but gnome-settings-daemon died almost immediately and the Gtk theme changed to the default grey theme until i started gnome-settings-daemon manually. Strange.
[20:14] <pitti> ion_: right, here too; but that's not specific to the guest session, that happens on normal fresh profiles as well
[20:14] <pitti> itz seb128 bug
[20:15] <ion_> Ah, okay
[20:19] <hwilde> pitti, any ideas I could try to login?
[20:19] <hwilde> dead in the water right now :/
[20:19] <pitti> hwilde: sorry, no :( I have only user level ssh fu, I'm afraid
[20:19] <pitti> hwilde: try giving a good ale to cjwatson or so...
[20:20] <hwilde> lol he will just take an hour to explain to me why I shouldn't need to ssh to it
[20:20] <pitti> really? I thought Colin can solve every problem with a clever combination of ssh, xargs, and join?
[20:20] <hwilde> ha
[20:20] <hwilde> +expect
[20:21] <hwilde> he usually just tells me I shouldn't be doing what I'm doing :)
[20:21] <hwilde> and in this case he will be like why don't you just reboot it
[20:21] <hwilde> as if I can get to it to reboot it
[20:21] <pitti> if it's the same subnet, it should be in walking distance? :-)
[20:23] <hwilde> yeah, if I was in Alabama
[20:23] <hwilde> but I am not
[20:23] <hwilde> that's a long walk.
[20:23] <hwilde> I have 7 machines there and I can only ssh to 6 of them :(
[20:24] <ion_> pitti: I managed to get the session to crash (by playing with xrandr). Running /usr/share/gdm/guest-session/guest-session-cleanup.sh manually fails with “userdel: user guest is currently logged in”.
[20:24] <pitti> ion_: it at least removed the tmpfs, and so on
[20:24] <ion_> pitti: Yeah
[20:24] <pitti> ion_: the last error is a bit of a mystery to me, too, I've seen it as well
[20:25] <pitti> no idea what userdel checks for this
[20:26] <ion_> utmp probably.
[20:28] <pitti> do you see any guest in "who"?
[20:28] <ion_> No
[20:32] <ion_> % grep guest /var/run/utmp
[20:32] <ion_> Binary file /var/run/utmp matches
[20:33] <pitti> maybe wtmp then?
[20:33] <pitti> last | head   -> any "still logged in"?
[20:33] <Mithrandir> ps axu | grep guest ?
[20:33] <ion_> guest    tty9         :20              Wed Jul 30 22:14    gone - no logout
[20:34] <ion_> mithrandir: Nope, the cleanup script kills all guest’s processes.
[20:35] <hwilde> who -u
[20:35] <ion_> No guest there.
[20:37] <pitti> ion_: bug 239449
[20:39] <ion_> The latter lines in who -a’s output are interesting: http://heh.fi/tmp/typescript
[20:40] <seb128> doko: you really don't want to use sync request tool to request syncs?
[20:40] <pitti> ion_: oh, uh...
[20:42] <ion_> who -d, to be more accurate
[21:08] <totopalma> hi all :)
[21:09] <hwilde> why... I can ping and telnet to port 22 but ssh rejected :(   http://paste.ubuntu.com/32303/
[21:09]  * pitti fends off seb128 sponsor bug subscription attack with a triple dput move
[21:10] <seb128> ;-)
[21:10]  * seb128 hugs pitti
[21:11] <pitti> seb128: if only seahorse would remember my gpg key... :-)
[21:11]  * pitti hugs seb128
[21:12] <seb128> my issue is rather gnome-keyring not remembering my ssh key at the moment :--
[21:12] <seb128> :-(
[21:12] <pitti> seb128: but that can be circumvented with a single ssh-add at session start
[21:12] <pitti> but I don't know an equivalent thing for gpg
[21:13] <seb128> right
[21:13] <seb128> downgrade seahorse to the hardy version, that should work on intrepid too ;-)
[21:14] <pitti> seahorse? not g-k?
[21:15] <pitti> seb128: looking at kwwii's new theme package, too, while I am at it
[21:15] <seb128> ah, thanks
[21:15] <seb128> pitti: seahorse does gpg, gnome-keyring does ssh
[21:15] <pitti> oh, so they broke at the very same time? strange
[21:15] <seb128> pitti: they splitted seahorse but didn't roll a new tarball for the extra package which has the gedit, epiphany-browser, agent, etc
[21:15] <seb128> well seahorse is technically not a bug
[21:16] <seb128> they decided to move all the side features to a new component
[21:16] <seb128> I'm not sure I agree about the agent being a side feature though
[21:16] <seb128> but it's good to have the epiphany-browser, gedit, etc plugins splitted
[21:17] <seb128> they just didn't roll a tarball for that yet
[21:17] <totopalma> hi Riddell , can you please take a look at bug #39383 and 250459?
[21:19] <Riddell> hi tonohono_
[21:20] <tonohono_> howdy
[21:20] <norsetto> lol
[21:21] <Riddell> totopalma: I asked tonio look at that, he's more familiar with kdebluetooth
[21:21] <Riddell> totopalma: he says he'll change it in the next upload, he's currently packaging kdebluetooth4 and I guess things will change
[21:22] <Riddell> totopalma: I've assigned it to tonio, let me know if he doesn't upload it by the end of the week
[21:23] <slangasek> TheMuso: is this issue with pulseaudio indexing the alsa devices backwards one that you're working on?
[21:23] <slangasek> TheMuso: looks like there was a pulseaudio update, then the bug was reopened
[21:26] <totopalma> Riddell, ok :)
[21:41] <slangasek> ogra: there are a number of bugs in ltsp that have been fixed in hardy SRU but are still open for intrepid; are these in progress somewhere?
[21:43] <totopalma> Riddell, can you please take a look at bug #250459?
[21:46] <ion_> pitti: utmp contains a ut_type=USER_PROCESS, ut_user=guest entry with a nonexistent pid. who doesn’t list it because coreutils lib/readutmp.c desirable_utmp_entry causes who to ignore any USER_PROCESS entries that kill -0 fails for. deluser does not have such a test.
[21:48] <ion_> pitti: who ceases to do the kill -0 check if it is passed an utmp filename:
[21:48] <ion_> % who /var/run/utmp | grep guest
[21:48] <ion_> guest    tty9         2008-07-30 22:14 (:20)
[22:01] <geser> seb128: re bug 250632: could you please rerun the sync script with the option to overwrite Ubuntu changes? thanks. (I've reopen the bug already)
[22:01] <ogra> slangasek, oh, i havent closed them, most were fixed last week when i was in portland at the freegeek hackfest ... i added it to my TODO to go through them tomorrow
[22:02] <slangasek> ogra: ok, thanks
[22:02] <seb128> geser: hum, the script should not close bugs in such cases, thanks for noticing
[22:02] <ogra> (currently classmate has higher prio)
[22:03] <seb128> geser: synced
[22:14] <geser> doko: re the java changes in intrepid: is it safe to assume that a lib*-java package will be fine with a -headless dependency?
[22:37] <doko> geser: depends on the package
[22:39] <geser> so if I'm not sure better use default-jre?
[22:40] <calc> doko: oh btw OOo currently fails to build with openjdk but there is an open bug upstream about it
[22:41] <doko> calc: URL?
[22:41] <calc> lemme find it
[22:41] <calc> http://qa.openoffice.org/issues/show_bug.cgi?id=91641
[22:42] <doko> geser: if a package doesn't provide a UI, -headless should be ok.
[22:42] <doko> UI = X based UI
[22:43] <doko> calc: build with the rhino from the system?
[22:44] <geser> doko: is looking at the package contents enough? e.g. a package which ships only some jars in /usr/shar/java and nothing in /usr/bin?
[22:45] <calc> doko: rene was the person who pointed me to the bug, he claimed its not possible to build with external rhino or he would have already switched it over himself
[22:45] <calc> doko: i haven't taken the time yet to look at what would be involved to attempt to do so
[22:45] <doko> geser: no, e.g. a library on top of awt/swing must not only depend on -headless
[22:46] <calc> doko: he said he has already set OOo to use everything from the system possible (or i guess at least has hooks to do so)
[22:46] <geser> doko: ah, I guess I understand
[22:49] <geser> doko: an other question (build-dependencies): does the use of default-jdk-builddep only apply for package names ending in -gcj? so for package (lib*-java) build depending currently on java-gcj-compat-dev it's correct to replace it with default-jdk?
[22:52] <doko> geser: yes, this should work
[22:52] <geser> doko: thanks
[23:00] <TheMuso> slangasek: The upload I made for that bug was to fix it. I'll read into why it was re-opened this morning, but suspect someone has settings laying around to set the pc speaker as the output device.
[23:52] <calc> slangasek: how does it break windows browsing?
[23:52] <slangasek> calc: it lies and returns A records for all hosts, breaking Samba's fall-through name resolution mechanism
[23:53] <ogra> and its not really a content filter, is it?
[23:53] <slangasek> to work around this, you have to do broadcast NBNS resolution before DNS resolution, when looking for a server's IP; this would be a horrible thing to have to set as a default, we were almost rid of NBNS
[23:54] <TheMuso> slangasek: Ah people think its not entirely fixed due to the crackling. Hopefully that can be solved by muting the device, but I'll have a look today.
[23:54] <slangasek> TheMuso: excellent, thanks :)
[23:54] <calc> slangasek: can't you disable the bit that causes it to pop up for non-existant hosts?
[23:55] <calc> s/pop up/return A records/g
[23:55] <slangasek> calc: I don't know, but I can infer that their /default/ setting breaks Samba browsing
[23:56] <liw> opendns falsifies dns responses?
[23:57] <calc> iirc there is way to not have it do that for non-existent domains
[23:57] <calc> liw: it shows a page if you go to a non-existent site, so er yea more or less
[23:57] <ogra> liw, in black/whitelist manner ...
[23:58] <ion_> Ew
[23:58]  * ogra wishes he had more time for willowng ...
[23:58] <slangasek> liw: yes, it helpfully directs you to their customized "page not found" page, basically
[23:59] <slangasek> which doesn't work so well *when the thing doing the lookup doesn't speak HTTP*
[23:59] <liw> er, um. er, um. er. um. um. er. um. er. and um.
[23:59] <ogra> heh