=== karlheg [~karlheg@host-250-237.resnet.pdx.edu] has joined #ubuntu-toolchain [05:44] morning === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [08:04] fabbione; gamin issues still/again [08:05] desrt: such as? [08:05] desktop not showing new files [08:05] desrt: that's a gamin/nautilus problem [08:05] nod. [08:06] if it works for a while and than stop working, blame userland [08:06] ah. gotcha. [08:06] it's a flow in the way in which gamin handles the "locks" on dirs to monitor [08:06] i told upstream [08:06] he shitted on me [08:06] DV? [08:06] and i am not going to pick up another discussion with him [08:07] i think so yeahg [08:07] it has been a while ago [08:07] he's really bad at being critisised [08:07] i didn't criticise him [08:07] i explained to him a problem [08:07] with all the debugging info [08:07] bugs reports are critisism :) [08:07] he didn't care [08:07] there are no bugs [08:07] and he did run out of arguments [08:07] sigh. [08:07] so he started complaining about my non-perfect english [08:08] makes you wonder why we all switched from fam [08:08] oh crikey [08:08] and yes, i know my english is not perfect [08:08] here's a neat question [08:08] what is the problem with applications using libnotify themselves, directly? [08:08] as i told him.. and he suggest to go to a school [08:08] *inotify [08:08] and i suggest him to remove a dildo from his $(where the sun doesn't shine" [08:09] i don't know.. [08:09] i didn't even know it existed such a lib [08:09] it doesn't. i made a mistake :) [08:09] i meant to say "inotify" but said "libnotify" instead [08:09] hmmmmm [08:10] you gotta figure that almost everything that uses fam uses it via the gnome-vfs [08:10] gamin uses inotify directly [08:10] which means that you'd just need to add inotify support to gnome-vfs's file method [08:10] the point is that it does it in a very stupid way [08:10] gamin would be cut out of the picture [08:10] oh yeah [08:10] and all of its silly problems would go away automatically [08:10] that would be awesome [08:10] (and hopefully not too many new silly problems are introduced) [08:11] i'm sufficiently intrigued to attempt this [08:11] desrt: the main issue with gamin are: [08:11] i wonder if robert is around [08:11] - it doesn't keep an association table between clients and monitored directories [08:12] - it uses signals even if there is a BIG FAT WARNING TO NOT USE SIGNALS for that kind of thing [08:12] so it is basically bad designed [08:12] it is possible to rewrite the code without changing the API [08:12] but why bother? [08:12] but i really have no interest in doing it [08:12] i mean.. why gam_server? [08:12] the kernel is the new gam_server ala inotify [08:13] hmm no [08:13] and honestly, i trust the kernel to not screw up an awful lot more than i trust the gam_server [08:13] there is a difference [08:13] be careful [08:13] the kernel provide the feature [08:13] but you need a link layer between the kernel and the clients [08:13] inotify has not been designed to be used directly by many clients afaik [08:13] so you need a "collector" or server [08:13] what else in ubuntu uses libfam other than gnome-vfs? [08:14] ah [08:14] apt-cache rdepends libfam ? [08:14] hm. that's an odd one. [08:14] apt-cache rdepends libgamin0 | wc -l [08:15] 174 [08:15] so you think the kernel will start to suffer if it has to notify several clients of updates to a inode? [08:15] at least 174 pkgs [08:15] the point is the info dispatcher [08:15] example: [08:15] you change something in dir foo [08:15] the kernel sends a notification to gamin [08:16] gamin redistribute it to the clients that are registerd to that dir [08:16] the last step is clearly not a kernel job [08:16] i don't understand why it isn't [08:16] the kernel has no need to know how many clients are monitoring a dir [08:16] each client can open inotify for itself [08:16] and the kernel can tell all of them [08:16] yes, that's correct [08:16] it actually seems silly to me that we have the indirection at all [08:16] but the point is that inotify will make the kernel suffer during that operation [08:17] it made more sense with dnotify simply because dnotify was such a pain to use [08:17] hmm [08:17] because you are stalling on kernel execution time [08:17] when that kind of processing can be done in userland [08:17] i can't imagine it's worse (or better) than O(n) [08:18] plus... we have preempt :) [08:29] oh. inotify is a syscall these days [08:29] weird. [08:30] that sort of seems a lot more reasonable.... [08:30] except that i don't know how you poll for a syscall [08:32] check how gamin does it [08:32] the connection between gamin and the kernel is "okish" [08:32] the issue with gamin is the rest [08:32] i bet the syscall creates an fd [08:32] like socket() [08:33] iirc they use sysfs [08:33] i can just picture the politics [08:33] include inotify in linus kernel! [08:33] over my dead body if it uses /dev/inotify. such a hack! [08:33] *weird solution* [08:34] ehehhe [08:35] yup. [08:35] inotify_init is a new syscall which returns an fd [08:35] then instead of ioctling it you use inotify_add_watch, etc (also new syscalls) [08:35] yes i saw the syscalls [08:36] when backporting inotify from .13-rc [08:36] that's perfect [08:36] i really like this design [08:36] still lets you use standard poll/read io loop stuff with it [08:45] wow. something fantastically bad just happened [08:45] oh. it's an oops. [08:58] doko: ping? [09:00] doko: unping === desrt tries to reproduce [09:00] something has gone terribly wrong inside the inotify code === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [09:01] http://bugzilla.ubuntu.com/show_bug.cgi?id=12987 [09:02] fabbione: pong anyway [09:02] doko: thanks i already solved [09:03] desrt: NOTABUG [09:03] # define __NR_inotify_init 291 [09:03] # define __NR_inotify_add_watch 292 [09:03] # define __NR_inotify_rm_watch 293 [09:03] wrong syscalls [09:03] kthxbyw [09:03] uhm [09:03] so userspace calling the wrong syscalls should generate oopses that take out the entire kernel? [09:04] it is correctly OOPSING to tell you that you are calling the wrong syscall [09:04] it's not crashing [09:04] you need to use the inotify include or whatever defines the syscall [09:04] no need to redifine them [09:04] no... the process goes into uninterruptable sleep [09:04] and then anything else that i try to open oopses from then on [09:05] at best that's a critical security flaw [09:06] can you try do a syscall on another kernel that's not inotify related? [09:06] calling syscall that way is delicate [09:07] i'm gonna figure out what actual syscall number causes it [09:07] btw: if i do it from the console, the virtual terminal stops working [09:07] the 3 syscalls you are using are invalid [09:07] that's as simple as it gets [09:07] it seems that whatever i am calling trashes the stdin/out/err/tty of the calling process [09:08] it's 291 [09:10] inotify_rm_watch ... [09:10] what arch is that? [09:10] i386 [09:11] asm/unistd.h:#define __NR_inotify_rm_watch 291 [09:11] asm-i386/unistd.h:#define __NR_inotify_rm_watch 291 [09:11] nod. [09:11] #define __NR_inotify_init 289 [09:11] #define __NR_inotify_add_watch 290 [09:11] #define __NR_inotify_rm_watch 291 [09:11] #define NR_syscalls 292 [09:11] so i'm calling inotify_rm_watch as a void function [09:11] the inotify_rm_watch syscall doesn't do proper input validation [09:12] i really hope this isn't a problem in the upstream kernel...... [09:12] it is probably [09:12] ok [09:12] can you try to use another syscall to something completely different? [09:12] i'm gonna figure out exactly what registers i'm passing it and what's on the stack [09:12] it can be a flaw in inotify [09:12] i think it is a flaw in inotify [09:13] also.. to use syscalls include asm/unistd.h [09:13] nod. [09:13] so you don't need to care about numbering [09:13] i just copied those out of gamin [09:13] you will need kernel includes... [09:13] i have them. i was just being lazy [09:13] :/ [09:13] sort of glad i was though. found a nice bug :P [09:14] does the kernel oops with gamin?= [09:14] debian/patches/sth-fs_inotify.dpatch:+asmlinkage long sys_inotify_rm_watch(int fd, u32 wd) [09:14] debian/patches/sth-fs_inotify.dpatch:+ int inotify_rm_watch (int fd, __u32 mask); [09:14] debian/patches/sth-fs_inotify.dpatch:+cond_syscall(sys_inotify_rm_watch); [09:14] SYS_291(0, 0xbf993e00, 0x41111d8a, 0x8048438, 0x8049634) [09:14] ^^ this is the baddy. [09:15] it's probably easier if i allign the numbers of our kernel [09:15] ya.. probably [09:15] is .13 out yet? [09:15] desrt: i don't have much time right now [09:15] i will send you a kernel to test [09:15] fabbione; it's ok. i'm gonna download and build a vanilla kernel [09:15] oh. ok. [09:15] .13 is not out yet [09:15] well, i'll try vanilla too [09:15] this probably isn't ubuntu's fault [09:15] ok that would be nice [09:16] it might as well be .. but a double check will save me time [09:39] ok [09:39] problem appears to be in vanilla [09:39] and i've found the source of it [09:40] sys_inotify_rm_watch( int fd, u32 wd ) [09:40] struct file *filp; [09:40] struct inotify_device *dev; [09:40] filp = fget(fd); [09:40] if(!filp) return -EBADF; [09:40] /* no check to find out what type of fd filp is */ [09:41] dev = filp->private_data; /* assign unknown datatype to an inotify_device pointer */ [09:41] /* all downhill from hear */ [09:41] *here [09:45] desrt: meh.... [09:45] should i email LKML or what? [09:46] mail rlove first [09:46] ok [09:46] just avoid the speech about different syscall nums [09:46] use the vanilla one as reference [09:46] otherwise we will start bouncing emails back and forward about ubuntu kernel being broken [09:46] when the problem is in vanilla too [09:47] fabbione, lamont: did the new curl 7.14 build on sparc and hppa? [09:47] :) [09:48] doko: is it in universe or main=? [09:49] well i guess until seb128 will learn to use versioned build-dep, it doesn't really matter.. [09:49] all of gnome on sparc is broken [09:49] fabbione: main [09:49] because it keeps coming up with _XOPEN_SOURCE somewhere [09:50] doko: it's probably queued [09:50] curl_7.14.0-2ubuntu1 [09:50] yeah it is [10:01] ok, thanks === desrt doesn't suppose there's any danger of 2.6.13 coming out tomorrow [10:02] desrt: ehehhe [10:02] i don't really think there's a need to email andrew morton [10:02] no i don't think so [10:02] btw [10:03] does 'UPSTREAM' mean upstream has been notified about the issue? [10:03] desrt: yes [10:03] cool. [10:04] now that that's over and done with === desrt goes back to playing with inotify :) [10:04] thanks for your help [10:04] as per usual :) === chmj [~chmj@196.36.161.235] has joined #ubuntu-toolchain [10:07] desrt: thanks to you for being so nice! [10:08] morning [10:08] O.O [10:35] hey chmj [12:21] doko: [12:21] configure: error: jni.h could not be found. Mismatch between gcc and libgcj or libgcj-devel missing? [12:21] (building OO2) [12:21] what can cause that? [12:22] strange. the build-deps are all there. which version do you build? [12:22] 1.9.116-0.pre1ubuntu1 [12:22] the one in the archive [12:25] i will forward the build log [12:25] it's only 300K [12:26] ok [12:29] ls -l /usr/lib/jvm/java-gcj/include [12:29] ok, we need an update for java-gcj-compat [12:29] ok :) [12:29] good to know [12:29] see.. sparc isn't completely useless :) [12:29] doko [12:29] any news about binutils? [12:30] what did I forget? :( [12:30] sparc starts to feel the pressure of building half of the desktop [12:30] the linking problem? [12:30] with -Wl,--as-needed? [12:31] https://bugzilla.ubuntu.com/show_bug.cgi?id=12822 <- [12:31] hmm, I thought that was a libtool/pkgconfig problem, which keybuk and jbailey would address? [12:31] no no [12:31] look at the bug [12:31] there is a simple test case [12:31] with hello world [12:32] ok, I'll look [12:32] the other bug you are talking about is to do in such a way that gnome doesn't need --as-needed [12:32] but binutils is still buggy :) [12:32] on sparc and alpha [12:33] i need to grab something to eat [12:33] later === doko [~doko___@dsl-084-059-067-130.arcor-ip.net] has joined #ubuntu-toolchain === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain === chmj [~chmj@196.36.161.235] has joined #ubuntu-toolchain [03:09] doko: several timeouts on hppa with defunct processes, during tests [03:09] hey lamont [03:09] lamont: any news about ia64? [03:10] lamont: java? [03:10] doko: curl [03:10] fabbione: will have news either way in a few hours [03:10] lamont: ok thanks [03:11] lamont: hmm, I suspect, that is the buildd environment, I'll check here locally [03:12] doko: wouldn't terribly surprise me === lamont__ [~lamont@15.238.5.126] has joined #ubuntu-toolchain [05:32] desrt: there is a big bunch of patches in git for inotify [05:32] one of them is the one we need [05:32] they will be in for the next upload [05:50] fabbione; ya. i just got an email from robert :) [05:50] desrt: i just finished the rediffing [05:50] :) [05:50] that was my first kernel security vuln [05:51] i'm sort of disappointed that it was already fixed :P [05:51] ehhee [06:03] let see if it builds [06:04] desrt: anyway we should seriously move our kernel talks to #ubuntu-kernel :) [06:05] heh. i swear i originally came here to talk about the toolchain :) === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [06:16] elmo: ping? Breezy-i386 chroot on concordia seems to have way out of date apt sources. === doko [~doko___@dsl-084-059-085-139.arcor-ip.net] has joined #ubuntu-toolchain === elmo_ [~james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-toolchain