#ubuntu-toolchain 2005-08-01
<fabbione> morning
<desrt> fabbione; gamin issues still/again
<fabbione> desrt: such as?
<desrt> desktop not showing new files
<fabbione> desrt: that's a gamin/nautilus problem
<desrt> nod.
<fabbione> if it works for a while and than stop working, blame userland
<desrt> ah.  gotcha.
<fabbione> it's a flow in the way in which gamin handles the "locks" on dirs to monitor
<fabbione> i told upstream
<fabbione> he shitted on me
<desrt> DV?
<fabbione> and i am not going to pick up another discussion with him
<fabbione> i think so yeahg
<fabbione> it has been a while ago
<desrt> he's really bad at being critisised
<fabbione> i didn't criticise him
<fabbione> i explained to him a problem
<fabbione> with all the debugging info
<desrt> bugs reports are critisism :)
<fabbione> he didn't care
<fabbione> there are no bugs
<fabbione> and he did run out of arguments
<desrt> sigh.
<fabbione> so he started complaining about my non-perfect english
<desrt> makes you wonder why we all switched from fam
<desrt> oh crikey
<fabbione> and yes, i know my english is not perfect
<desrt> here's a neat question
<desrt> what is the problem with applications using libnotify themselves, directly?
<fabbione> as i told him.. and he suggest to go to a school
<desrt> *inotify
<fabbione> and i suggest him to remove a dildo from his $(where the sun doesn't shine"
<fabbione> i don't know..
<fabbione> i didn't even know it existed such a lib
<desrt> it doesn't.  i made a mistake :)
<desrt> i meant to say "inotify" but said "libnotify" instead
<desrt> hmmmmm
<desrt> you gotta figure that almost everything that uses fam uses it via the gnome-vfs
<fabbione> gamin uses inotify directly
<desrt> which means that you'd just need to add inotify support to gnome-vfs's file method
<fabbione> the point is that it does it in a very stupid way
<desrt> gamin would be cut out of the picture
<fabbione> oh yeah
<desrt> and all of its silly problems would go away automatically
<fabbione> that would be awesome
<desrt> (and hopefully not too many new silly problems are introduced)
<desrt> i'm sufficiently intrigued to attempt this
<fabbione> desrt: the main issue with gamin are:
<desrt> i wonder if robert is around
<fabbione> - it doesn't keep an association table between clients and monitored directories
<fabbione> - it uses signals even if there is a BIG FAT WARNING TO NOT USE SIGNALS for that kind of thing
<fabbione> so it is basically bad designed
<fabbione> it is possible to rewrite the code without changing the API
<desrt> but why bother?
<fabbione> but i really have no interest in doing it
<desrt> i mean.. why gam_server?
<desrt> the kernel is the new gam_server ala inotify
<fabbione> hmm no
<desrt> and honestly, i trust the kernel to not screw up an awful lot more than i trust the gam_server
<fabbione> there is a difference
<fabbione> be careful
<fabbione> the kernel provide the feature
<fabbione> but you need a link layer between the kernel and the clients
<fabbione> inotify has not been designed to be used directly by many clients afaik
<fabbione> so you need a "collector" or server
<desrt> what else in ubuntu uses libfam other than gnome-vfs?
<desrt> ah
<fabbione> apt-cache rdepends libfam ?
<desrt> hm.  that's an odd one.
<fabbione> apt-cache rdepends libgamin0 | wc -l
<fabbione> 174
<desrt> so you think the kernel will start to suffer if it has to notify several clients of updates to a inode?
<fabbione> at least 174 pkgs
<fabbione> the point is the info dispatcher
<fabbione> example:
<fabbione> you change something in dir foo
<fabbione> the kernel sends a notification to gamin
<fabbione> gamin redistribute it to the clients that are registerd to that dir
<fabbione> the last step is clearly not a kernel job
<desrt> i don't understand why it isn't
<fabbione> the kernel has no need to know how many clients are monitoring a dir
<desrt> each client can open inotify for itself
<desrt> and the kernel can tell all of them
<fabbione> yes, that's correct
<desrt> it actually seems silly to me that we have the indirection at all
<fabbione> but the point is that inotify will make the kernel suffer during that operation
<desrt> it made more sense with dnotify simply because dnotify was such a pain to use
<desrt> hmm
<fabbione> because you are stalling on kernel execution time
<fabbione> when that kind of processing can be done in userland
<desrt> i can't imagine it's worse (or better) than O(n)
<desrt> plus... we have preempt :)
<desrt> oh.  inotify is a syscall these days
<desrt> weird.
<desrt> that sort of seems a lot more reasonable....
<desrt> except that i don't know how you poll for a syscall
<fabbione> check how gamin does it
<fabbione> the connection between gamin and the kernel is "okish"
<fabbione> the issue with gamin is the rest
<desrt> i bet the syscall creates an fd
<desrt> like socket()
<fabbione> iirc they use sysfs
<desrt> i can just picture the politics
<desrt> <rml> include inotify in linus kernel!
<desrt> <linus/andrew/whoever> over my dead body if it uses /dev/inotify.  such a hack!
<desrt> *weird solution*
<fabbione> ehehhe
<desrt> yup.
<desrt> inotify_init is a new syscall which returns an fd
<desrt> then instead of ioctling it you use inotify_add_watch, etc (also new syscalls)
<fabbione> yes i saw the syscalls
<fabbione> when backporting inotify from .13-rc
<desrt> that's perfect
<desrt> i really like this design
<desrt> still lets you use standard poll/read io loop stuff with it
<desrt> wow.  something fantastically bad just happened
<desrt> oh.  it's an oops.
<fabbione> doko: ping?
<fabbione> doko: unping
* desrt tries to reproduce
<desrt> something has gone terribly wrong inside the inotify code
<desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=12987
<doko> fabbione: pong anyway
<fabbione> doko: thanks i already solved
<fabbione> desrt: NOTABUG
<fabbione> # define __NR_inotify_init      291
<fabbione> # define __NR_inotify_add_watch 292
<fabbione> # define __NR_inotify_rm_watch  293
<fabbione> wrong syscalls
<fabbione> kthxbyw
<desrt> uhm
<desrt> so userspace calling the wrong syscalls should generate oopses that take out the entire kernel?
<fabbione> it is correctly OOPSING to tell you that you are calling the wrong syscall
<fabbione> it's not crashing
<fabbione> you need to use the inotify include or whatever defines the syscall
<fabbione> no need to redifine them
<desrt> no... the process goes into uninterruptable sleep
<desrt> and then anything else that i try to open oopses from then on
<desrt> at best that's a critical security flaw
<fabbione> can you try do a syscall on another kernel that's not inotify related?
<fabbione> calling syscall that way is delicate
<desrt> i'm gonna figure out what actual syscall number causes it
<desrt> btw: if i do it from the console, the virtual terminal stops working
<fabbione> the 3 syscalls you are using are invalid
<fabbione> that's as simple as it gets
<desrt> it seems that whatever i am calling trashes the stdin/out/err/tty of the calling process
<desrt> it's 291
<desrt> inotify_rm_watch ...
<fabbione> what arch is that?
<desrt> i386
<fabbione> asm/unistd.h:#define __NR_inotify_rm_watch      291
<fabbione> asm-i386/unistd.h:#define __NR_inotify_rm_watch 291
<desrt> nod.
<fabbione> #define __NR_inotify_init       289
<fabbione> #define __NR_inotify_add_watch  290
<fabbione> #define __NR_inotify_rm_watch   291
<fabbione> #define NR_syscalls 292
<desrt> so i'm calling inotify_rm_watch as a void function
<desrt> the inotify_rm_watch syscall doesn't do proper input validation
<desrt> i really hope this isn't a problem in the upstream kernel......
<fabbione> it is probably
<desrt> ok
<fabbione> can you try to use another syscall to something completely different?
<desrt> i'm gonna figure out exactly what registers i'm passing it and what's on the stack
<fabbione> it can be a flaw in inotify
<desrt> i think it is a flaw in inotify
<fabbione> also.. to use syscalls include asm/unistd.h
<desrt> nod.
<fabbione> so you don't need to care about numbering
<desrt> i just copied those out of gamin
<fabbione> you will need kernel includes...
<desrt> i have them.  i was just being lazy
<desrt> :/
<desrt> sort of glad i was though.  found a nice bug :P
<fabbione> does the kernel oops with gamin?=
<fabbione> debian/patches/sth-fs_inotify.dpatch:+asmlinkage long sys_inotify_rm_watch(int fd, u32 wd)
<fabbione> debian/patches/sth-fs_inotify.dpatch:+  int inotify_rm_watch (int fd, __u32 mask);
<fabbione> debian/patches/sth-fs_inotify.dpatch:+cond_syscall(sys_inotify_rm_watch);
<desrt> SYS_291(0, 0xbf993e00, 0x41111d8a, 0x8048438, 0x8049634)
<desrt> ^^ this is the baddy.
<fabbione> it's probably easier if i allign the numbers of our kernel
<desrt> ya.. probably
<desrt> is .13 out yet?
<fabbione> desrt: i don't have much time right now
<fabbione> i will send you a kernel to test
<desrt> fabbione; it's ok.  i'm gonna download and build a vanilla kernel
<desrt> oh.  ok.
<fabbione> .13 is not out yet
<desrt> well, i'll try vanilla too
<desrt> this probably isn't ubuntu's fault
<fabbione> ok that would be nice
<fabbione> it might as well be .. but a double check will save me time
<desrt> ok
<desrt> problem appears to be in vanilla
<desrt> and i've found the source of it
<desrt> sys_inotify_rm_watch( int fd, u32 wd )
<desrt> struct file *filp;
<desrt> struct inotify_device *dev;
<desrt> filp = fget(fd);
<desrt> if(!filp) return -EBADF;
<desrt> /* no check to find out what type of fd filp is */
<desrt> dev = filp->private_data;   /* assign unknown datatype to an inotify_device pointer */
<desrt> /* all downhill from hear */
<desrt> *here
<fabbione> desrt: meh....
<desrt> should i email LKML or what?
<fabbione> mail rlove first
<desrt> ok
<fabbione> just avoid the speech about different syscall nums
<fabbione> use the vanilla one as reference
<fabbione> otherwise we will start bouncing emails back and forward about ubuntu kernel being broken
<fabbione> when the problem is in vanilla too
<doko> fabbione, lamont: did the new curl 7.14 build on sparc and hppa?
<desrt> :)
<fabbione> doko: is it in universe or main=?
<fabbione> well i guess until seb128 will learn to use versioned build-dep, it doesn't really matter..
<fabbione> all of gnome on sparc is broken
<doko> fabbione: main
<fabbione> because it keeps coming up with _XOPEN_SOURCE somewhere
<fabbione> doko: it's probably queued
<fabbione>   curl_7.14.0-2ubuntu1
<fabbione> yeah it is
<doko> ok, thanks
* desrt doesn't suppose there's any danger of 2.6.13 coming out tomorrow
<fabbione> desrt: ehehhe
<desrt> i don't really think there's a need to email andrew morton
<fabbione> no i don't think so
<desrt> btw
<desrt> does 'UPSTREAM' mean upstream has been notified about the issue?
<fabbione> desrt: yes
<desrt> cool.
<desrt> now that that's over and done with
* desrt goes back to playing with inotify :)
<desrt> thanks for your help
<desrt> as per usual :)
<fabbione> desrt: thanks to you for being so nice!
<chmj> morning 
<chmj> O.O
<fabbione> hey chmj 
<fabbione> doko:
<fabbione> configure: error: jni.h could not be found. Mismatch between gcc and libgcj or libgcj-devel missing?
<fabbione> (building OO2)
<fabbione> what can cause that?
<doko> strange. the build-deps are all there. which version do you build?
<fabbione> 1.9.116-0.pre1ubuntu1
<fabbione> the one in the archive
<fabbione> i will forward the build log
<fabbione> it's only 300K
<doko> ok
<doko> ls -l /usr/lib/jvm/java-gcj/include
<doko> ok, we need an update for java-gcj-compat
<fabbione> ok :)
<fabbione> good to know
<fabbione> see.. sparc isn't completely useless :)
<fabbione> doko
<fabbione> any news about binutils?
<doko> what did I forget? :(
<fabbione> sparc starts to feel the pressure of building half of the desktop
<fabbione> the linking problem?
<fabbione> with -Wl,--as-needed?
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=12822 <-
<doko> hmm, I thought that was a libtool/pkgconfig problem, which keybuk and jbailey would address?
<fabbione> no no
<fabbione> look at the bug
<fabbione> there is a simple test case
<fabbione> with hello world
<doko> ok, I'll look
<fabbione> the other bug you are talking about is to do in such a way that gnome doesn't need --as-needed
<fabbione> but binutils is still buggy :)
<fabbione> on sparc and alpha
<fabbione> i need to grab something to eat
<fabbione> later
<lamont> doko: several timeouts on hppa with defunct processes, during tests
<fabbione> hey lamont 
<fabbione> lamont: any news about ia64?
<doko> lamont: java?
<lamont> doko: curl
<lamont> fabbione: will have news either way in a few hours
<fabbione> lamont: ok thanks
<doko> lamont: hmm, I suspect, that is the buildd environment, I'll check here locally
<lamont> doko: wouldn't terribly surprise me
<fabbione> desrt: there is a big bunch of patches in git for inotify
<fabbione> one of them is the one we need
<fabbione> they will be in for the next upload
<desrt> fabbione; ya.  i just got an email from robert :)
<fabbione> desrt: i just finished the rediffing
<fabbione> :)
<desrt> that was my first kernel security vuln
<desrt> i'm sort of disappointed that it was already fixed :P
<fabbione> ehhee
<fabbione> let see if it builds
<fabbione> desrt: anyway we should seriously move our kernel talks to #ubuntu-kernel :)
<desrt> heh.  i swear i originally came here to talk about the toolchain :)
<jbailey> elmo: ping?   Breezy-i386 chroot on concordia seems to have way out of date apt sources.
#ubuntu-toolchain 2005-08-02
<jbailey> doko: Step 1 for getting you amd64 biarch stuff back completed.  I now have an amd64 box.
<jbailey> (Or will when my wife is finished with the screwdriver and such - she builds the computers at our place)
<fabbione> morning
<lamont> we need -Orandom in the compiler. :-)
<doko> jbailey: please put some photos online ;)
#ubuntu-toolchain 2005-08-03
<fabbione> morning
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: how do i use gcc-snapshot?
<fabbione> should i just prefix my path with /usr/lib/gcc-snapshot/bin ?
<doko> yes, that should do it. And the kernel build doesn't need any shared libs, so you don't need to set LD_LIBRARY_PATH
<fabbione> ok
<fabbione> i am trying to reproduce the ice on ppc
<fabbione> doko: good news or bad news?
<fabbione> which one do you want first?
<doko> you can reproduce it, but you get a preprocessed source file?
<fabbione> doko: no.. after unionfs upgrade from this morning i cannot reproduce it anymore...
<fabbione> atleast on breezy-64 chroot
<fabbione> i am testing in the normal one
<doko> hmm, nice, or not nice? ;)
<fabbione> well it's nice because we can ship the driver
<fabbione> it's not nice because we don't know if it is a code change that fixed it or something in recent gcc
<doko> you did test with 3.4 or 4.0?
<fabbione> 3.4
<fabbione> but i did do a normal test without using gcc-snapshot 
<fabbione> so i guess it's the code in unionfs to be changed and doesn't trigger the ice anymore
<jbailey> doko: Around>
<doko> jb-support: yes :-)
<jbailey> *lol*
<jbailey> Bah, you just want me to be nice to you ;)
<jbailey> I think I figured out how to morgue worked enough to find an old copy of gcc-3.4 anyway.
<jbailey> Yup, Just made a 64 bit binary that works, woohoo
<jbailey> Should I call the package libc6-amd64 ?
<jbailey> And the matching libc6-dev-amd64
<doko> yes, sounds ok. although I hate the naming ... but it's consistent with the other ones
<doko> btw, the debian gcc-3.4 versions are still biarch, so these should work as well
<jbailey> Cool.
<doko> jbailey: will you sort it out tonight with infinity or lamont?
<jbailey> doko: I'm going to try to put together a glibc and gcc-3.4 package now that they can use.
<doko> ok, I uploaded a new 3.4 today, which FTBFS on i386. I'll send you a patch later today
<jbailey> Cool, thanks.
<jbailey> I'll also post the biarch glibc on people as soon as I have it.
<doko> ok, then maybe we can merge the changes into one gcc-3.4 upload, which laminity can use
<jbailey> *G*!
<doko> hmm, when do you plan the glibc uploads/builds? still Monday?
* lamont ph3ars
<jbailey> doko: Subject to the availability of Lamont or Adam, that sounds right.
<jbailey> Unless one of them was bored this weekend.
<jbailey> doko: What I'd like to do is hand them .deb's and sources and say "Install these debs.  Rebuild them with their matching sources.  Stuff the new binaries into the archive"
<jbailey> That way it can be done at their convenience.
<jbailey> lamont: Assuming I've got the steps right, yes?
<doko> jabiley: yes, that sounds fine. do you prepare both biarch builds (i386 and amd64)?
<lamont> jbailey: works for me.
<lamont> I'm off to a birthday party at Renn Faire all day tomorrow, but we should be able to schedule something in...
<lamont> is this just i386 we're doing funky bootstrapping stuff on, or is it more than just the one?
<lamont> back in a fdew
<jbailey> lamont: Just i386 for this round.  
<jbailey> The i386-libs has a whole pile of crack in it that I'm not sure what the right answer to it is.
<jbailey> Or even how much people on amd64 actually care about producing i386 binaries yet.
<doko> jbailey: grub needs it
<lamont> jbailey: yeah, what doko said.  grub is a 32-bit executable on amd64
<jbailey> Ah, interesting.
<jbailey> Ouch:
<jbailey> checking build system type... i486-pc-linux-gnu
<jbailey> checking host system type... powerpc64-unknown-linux-gnu
* jbailey fixes the pasto
<lamont> dude - that's serious multiarch
<fabbione> ahaha
<lamont> ccache sucks
<lamont> cache hit                            296
<lamont> cache miss                         12401
<lamont> that or kernel option hacking sucks
<fabbione> the latter
<lamont> the latter makes the former suck
<fabbione> i agree
<fabbione> that's why i tend to build with -j200
<fabbione> it scrolls faster and it looks that is compiling much more
<fabbione> jbailey: to your knowledge.. how difficult it is to setup a cross compiler?
<doko> fabbione: get Dan Kegel's crosstools
<jbailey> fabbione: I don't have any troubles, but Dan's crosstools are supposed to be quite nice.
<fabbione> doko: is it packaged?
<doko> no, and the current cross build support in binutils/gcc-4.0 is a bit broken
<jbailey> doko: Do you think Lamont would kill us if we built cross compilers for every arch on every arch?
<doko> jbailey: so the build deps are: amd64-libs-dev [i386] , i386-build-deps [amd64]  ?
<doko> jbailey: he doesn't have that many machines ...
<fabbione> actually i am only curious to try to build sparc and m68k on i386
<fabbione> but given that's broken i don't think i am going to spend time on it this night
<doko> you start feeling bored during your vacations from the first day? :-P
<jbailey> it's not even his first day yet.
<jbailey> Like a Heroin addict... =)
<fabbione> ahaha
<jbailey> MUST HACK
<fabbione> unfortunatly my evening has been ruined
<fabbione> so better to hack than do nothing
<jbailey>  /msg fabbione I told you bringing out the goat would be a mistake.
<fabbione> ahahhaaha
#ubuntu-toolchain 2005-08-04
<doko> jbailey: chinstrap:~doko/gcc-3.4.diff is my version of the biarch stuff
<lamont> i386 0.910676
<lamont> powerpc 0.902914
<lamont> amd64 0.897059
<lamont> ia64 0.892823
<lamont> sparc 0.756632
<lamont> hppa 0.721035
<lamont> getting closer to #5 :-)
<lamont> so if someone has an hppa box, and some time to argue with ld.so....
<lamont> debootstrap a chroot from http://people.ubuntu.com/~lamont/ubuntu-hppa/tree (hoary), then dist-upgrade to ports.ubuntu.com/ubuntu-ports breezy, and tell me why librsvg2-dev goes bugnutso in postinst...
* lamont suspects quite strongly that it's in the loader trying to load the rsvg2 shlib
<lamont> on that note, gnight
#ubuntu-toolchain 2005-08-05
<fabbione> doko:
<fabbione>  e44e9ad88081fd0ac6834cb0b7e59a8f 764 libs optional lib64g2c0_3.4.4-6ubuntu2_sparc.deb
<fabbione> i think something is missing from that package...
<doko> fabbione: what is missing?
<fabbione> doko: it's 764 bytes?
<doko__> ahh, no. need to find out, why there's no lib ...
<lamont> dpkg --contents pool/main/b/binutils/binutils-hppa64_2.16.1-2ubuntu2_hppa.deb | grep objdump
<lamont> -rwxr-xr-x root/root    262376 2005-07-27 10:15:56 ./usr/bin/hppa64-linux-gnu-objdump
<lamont>  /bin/sh: hppa64-linux-objdump: command not found
<lamont> which one is wrong, I wonder?
* lamont fixes the kernel makefile
#ubuntu-toolchain 2005-08-06
<lamont> vim is ftbfs... sys/time.h and time.h exist is the immediate cause
* lamont files a bug so that jbailey feels wanted.
<lamont> ./normal >normal.dist
<lamont> *** glibc detected *** double free or corruption (!prev): 0x00021050 ***
<lamont> jbailey: iproute is still busted...
<fabbione> morning
<lamont> i386 0.910521
<lamont> powerpc 0.904475
<lamont> amd64 0.898227
<lamont> ia64 0.894112
<lamont> sparc 0.758345
<lamont> hppa 0.732369
<lamont> fabbione: closing in on you.. :)
<fabbione> lamont: i know :(
<fabbione> i have all of GNOME FTBFS
<fabbione> and i still need to check the c++ abi transition in universe
<fabbione> that means i have 600 pkgs still in not-for-us
<lamont> 162 packages more to tie.. :-)
<fabbione> and my second buildd died again!
<fabbione> hell
<fabbione> so it's hw problem...
<fabbione> tested 3 kernels on it
<lamont> yeah - hppa has it a bit easier on c++ transition - if I limit the buildd to just breezy packages, then it'll only build transitioned stuff...
<fabbione> yeah i know
<fabbione> i am pretty sure i did transition everything
<fabbione> but i need to double check
* desrt eyes fabbione 
<fabbione> hey desrt
<desrt> you're bad at taking vacation, dude :P
<fabbione> no! i have a wife that forgets to turn off the alarm clock at 5:30!
<fabbione> she can fall asleep again
<fabbione> i can't
<desrt> ah
<desrt> and too early to start housework, i suppose
<fabbione> she is sleeping.. i am not supposed to make noise :)
<desrt> i see :)
<desrt> irc is a good way to do that
<desrt> have you seen the frogpad?
<fabbione> frogpad?
<desrt> one-handed keyboard
<desrt> i'm thinking of buying one (or two)
<fabbione> no i am actually completing a distupgrade on the first (slowest) of the 2 amigas i have
<desrt> amiga?
<desrt> what arch?
<fabbione> but i am having some timeout issues with the mirror
<fabbione> amiga = m68k
<desrt> debian?
<fabbione> yes
* desrt doesn't understand the point in having m68k hardware :)
<desrt> brb.  testing gdm changes
<fabbione> AH CRAP
<fabbione> one of the routers on the way is having pkt loss
<desrt> there we go
<fabbione> nope.. too much pkt loss
<fabbione>  7  pos5-0.2488M.bynxg1.ip.tele.dk (80.63.80.101)  202.106 ms * *
<fabbione> yeah
<desrt> no.. not packet loss
<desrt> that host just has a "one ping packet per ip per day" policy :)
<fabbione> desrt: not to disappoint you, but remember that ppc is a processor born on top of m68k :)
<fabbione> respect for the grandaddy of your machines ;)
<desrt> boring :P
<fabbione> it's fun...
<fabbione> desrt: + there are some benefits in keeping these arches around
<fabbione> because they are still used for a bunch of embedded devices
<desrt> ah ya.. i suppose that's true
<fabbione> if you remember.. not too long ago, NASA was searching 8086 on ebay to replace some parts for the shuttle :)
<desrt> i don't remember that
<desrt> that's cool, though :)
<desrt> well.. i mean
<fabbione> there are several reasons to use old processors
<desrt> 8086 elss cool than m68k
<desrt> but whatever :)
<fabbione> they are very well known
<fabbione> super tested
<fabbione> actually m68k >> 8086 :)
<fabbione> m68k has always been faster than 8086
<fabbione> up to 68080 that was more or less a pentium 120 or 150 in terms of performances 
<desrt> well ya
<desrt> * > x86 in bang-per-mhz
* lamont__ mutters about gcc-3.4 being 7 hours into its build on hppa
<doko> well, it builds the cross compiler as well
<doko> lamont__, lamont, fabbione: you may not want to build the following uploads for sparc and hppa, until the i386/amd64 biarch integration is done
* lamont__ waits for the list...
<lamont__> doko: true.
<lamont__> that does slow it down
<jbailey> doko: there/
<jbailey> ?
<lamont__> jbailey: fwiw, iptables still hates hppa
<doko> * lamont__ mutters about gcc-3.4 being 7 hours into its build on hppa
<doko> <doko> well, it builds the cross compiler as well
<doko> <doko> lamont__, lamont, fabbione: you may not want to build the following uploads for sparc and hppa, until the i386/amd64 biarch integration is done
<doko> * lamont__ waits for the list...
<doko> yes
<jbailey> lamont__: Joy.  rsync'ing logs to somewhere I can see them yet?
<lamont__> doko: the following gcc-3.4 uploads?
<lamont__> jbailey: still blocked
<jbailey> Yar.
* lamont__ makes a note to pester the resident muppet
<doko> lamont__: yes
<lamont__> elmo: logs@buildd.u.c ready for me yet?  eta?
<lamont__> doko: will there be -4.0 uploads too?
<doko> yes
<lamont__> and should I just kill the 3.4 build?
<lamont__> doko: so you're recommending not building gcc-* until you say so?
<doko> depends on jbailey 
<lamont__> what about glibc
<doko> yep, maybe stop that as well
<lamont__> jbailey:
<lamont__> ./normal >normal.dist
<lamont__> *** glibc detected *** double free or corruption (!prev): 0x00021050 ***
<lamont__> /bin/sh: line 1:  5737 Aborted                 ./normal >normal.dist
<lamont__> :-(
<jbailey> Is that iptables?
<jbailey> (I don't know where ./normal might come from...)
<lamont__> iptables
<lamont__> do.
<lamont__> iproute
<lamont__> my bad. :-(
<jbailey> And only dying on hppa? =(
<lamont__> of course
<lamont__> :-(
<lamont__> the rest of the log is pretty uninteresting, if that helps...
<jbailey> No, it'll mostly be feeding that address into gdb and figuring out what thedouble free is.
<jbailey> Probably some define missing for you guys.
<jbailey> BTW, libc6-{dev-}amd64 should be ready today.  It all worked well, except that it hardcoded /usr/lib instead of /usr/lib64.
<lamont__> jbailey: btw, any progress on palo?  I told bame I'd make it good, and then you wanted to play so I didn't do anything, and he should be back soon...
<jbailey> Ugh,  INTERP on amd64 seems to be allowed to be either /lib/ld-linux-x86-64.so.2 or /lib64/ld-linux-x86-64.so.2
#ubuntu-toolchain 2005-08-07
<lamont__> jbailey: what determines what modules are loaded into the initrd?
<infinity> lamont : Did you clean up ross?
<infinity> lamont : I got a message from elmo last night that it was out of disk space; seems (more than) fine now..
<elmo> [01-08-2005 09:46:18]  SERVICE ALERT: ross;Disk Space of /;CRITICAL;HARD;3;DISK CRITICAL [39041 kB (3%) free on /dev/sda3] 
<elmo> I wasn't making it up :-P
<infinity> I assume not. :)
<infinity> Also, speaking of ross, it seems confused about SSH keys... Hrm.
<elmo> yeah, it will be, it's hostname is fucked
<infinity> I have 4 keys in LDAP (all show up in /var/lib/misc just fine, so ud-ldap is syncing okay), but I can only auth from one host, not the other.
<elmo> try now
<infinity> Oo.  Much better.
<infinity> Was it authenticating against the hdb.com stuff?
<elmo> actually ross has done this for like the last 5 or 6 days in a row
<elmo> i.e. dropped to 2-5% free at ~9am local
<elmo> so whatever's happening then is Bad(tm)
<infinity> Evil cronjob?
<elmo> infinity: yah, if you find a buildd not called .buildd (in hostname -f), yell
<infinity> Yeah, I think there are a few others that hate me.  I'll loop through all 12 and see.
<infinity> crested and floe seem to be the only other two.
<infinity> 9am local, you say?  Hrm.
<elmo> fixed
<infinity> The only possibly nasty cronjob I can see if the DI build (which shouldn't be nasty anyway) at 6:15...
<infinity> I guess if it's going out of control, it could take 3 hours to fill the disks.
<infinity> s/if the/is the/
<elmo> I'm fairly sure the d-i daily build is finished well before then
<elmo> is ross not live CD image builder?
<infinity> Nope.
<elmo> damn, that was my first thought
<infinity> The LiveCD builds are commented out on ross.
<elmo> acct's useless for this sort of thing - unless lamont knows, I guess we should cron some ps auxfw's
<lamont> ross is d-i
* lamont goes digging
<lamont> hrm.. clearly someone cleaned it up
<lamont> royal is livecd
<infinity> Not I, and not elmo.  That doesn't leave many options.
<lamont> ross is d-i
<lamont> hrm... is 23% atm
<infinity> Yes, I noticed. :)
<elmo> yeah, but somethings using 20% of 150Gb and it's not a package
<elmo> and it's not d-i
<infinity> So, there's a mystery process that eats the disk at 9am every day, and then happily cleans up after itself.
<lamont> at 39MB, gcc-4.0 wins for logfile size
<lamont> oh, joy.
<lamont> 9AM DC time?
<infinity> Yeah.
<infinity> elmo : I would assume the majority of that 20% of 150GB is ccache.
<infinity> We do have ungodly large caches.
<elmo> ccache doesn't clean upitself ?
<elmo> oh 23% USED?
<infinity> Yes, 23% used.
<elmo> so something is using 100Gb ... W_T_F?
<infinity> Yeah, at 9am, something is eating 110GB.
<infinity> Yum.
<infinity> It is really at the same time every day, or just coincidentally rather close?
<elmo> all between 9am and 10am
<lamont> did tdb-dev finally show up (migrate to main)?  or did bogofilter just pick a diff machine to annoy after 9:40?
<lamont> elmo: that's bizare!  and about 0300 for me.
* lamont will be in and out for much of the evening, need to get ready and go fetch my niece from the airport in about 3 hours, etc.
<infinity> Infinite loop in the find or checksecurity cron.daily jobs, perhaps? 
<infinity> They clean up after themselves, and couldtake 3 hours to build a 110 gig log file.
* infinity whimpers when he realises that the $sshcmd{$dist} thing means some serious fiddling with backporting sshsocket stuff.
<infinity> Oh well, halfway there.
<doko> lamont: hppa is lacking libdb4.3, so python cannot be installed
<lamont> infinity: yeah, I guess it would.
<lamont> doko: correct
<doko> laminity: please requeue: sigc jabberoo libgnomemm2.0
<doko> lamont, infinity: ^^^
<lamont> doko: on ppc?
<doko> lamont: all
<lamont> I only have logs for sigc/ppc and jabberoo/ppc.
<lamont> I'll kick the others in a bit, when my meeting hits a break and I can type faster...
#ubuntu-toolchain 2006-08-01
<Keybuk> jbailey: is edgy n-m working for you today?
<Keybuk> (on atheros)
<mdz> Keybuk:  what was the fuss over nm 0.6.4?  are you saying it could get worse?
<Keybuk> mdz: yeah, some of the patches in there is a bit dodgy
<Keybuk> and frankly, I don't see the need, given that patch, to break from Debian at this point
<Keybuk> NM isn't going to get magically fixed over night
<Keybuk> so I don't believe we should spend any particular effort on it, other than keeping it working as it is now
<Keybuk> updating ahead of Debian will just make the merge harder for edgy+1
<mdz> Keybuk: has netapplet improved any?
<Keybuk> netapplet is entirely unmaintained
<Keybuk> n-m works for those it works for, and is the best solution
<Keybuk> the problem isn't in n-m, the problem is in the kernel
<Keybuk> without consistently behaving wireless drivers, it's all just hackery
<doko> jbailey: are you going to upload glibc?
<jbailey> doko: I sorted out the best way to fix the header problem with Steve Munroe yesterday evening, so yes, soon.
<jbailey> I'll have to find my backup gpg key, or get someone to sponsor it though.  My home machine is dead atm.
<infinity> jbailey: You can always poke me.
<jbailey> infinity: Cool, thanks.
<doko> jbailey: please upload the additional /usr/include/powerpc64-linux-gnu link / dir as well. we need both until 3.4 and 4.0 are built again
<jbailey> Right.  Ben didn't keep the lkh multi-arch stuff, so that makes that easier too.
#ubuntu-toolchain 2006-08-03
<ogra> klibc's mount doesnt do nfs mounting anymore ... is that intentional ?
<ogra> (nfsmount doesnt work either and i cant find a changelog entry even mentioning mount)
<ogra> oh, ignore that ... udev didnt create any network devices
<doko> jbailey: another thing ... long-bl-128 for powerpc and sparc
#ubuntu-toolchain 2006-08-04
<bod> lamont: around?
#ubuntu-toolchain 2015-07-29
<zaytsev> doko: any news on 5.2 for precise? just caught an ice on a wrong decltype with 5.1 and wonder if it's worth reporting, could be that it's fixed already
#ubuntu-toolchain 2016-08-02
<zaytsev> hmmm, not much going on here
