| emgent | this is my idea | 00:00 |
|---|---|---|
| sladen | emgent: I suspect it might be more interesting to put money toward "you helping XYZ" when a particular XYZ is known | 00:21 |
| emgent | sure sladen | 00:22 |
| * emgent heya | 02:55 | |
| === ion__ is now known as ion_ | ||
| === stu2 is now known as stub | ||
| === tonyy is now known as tonyyarusso | ||
| lamont | gcc -DHAVE_CONFIG_H -I. -I. -I.. @GLIB_CFLAGS@ -I/usr/include/glib-1.2 -I/usr/lib/glib/include -O2 -Wall -g -Wp,-MD,.deps/library.pp -c library.c -fPIC -DPIC -o .libs/library.o | 05:51 |
| lamont | hrm. | 05:51 |
| lamont | I think I may have auto* issues to fix. | 05:54 |
| lifeless | using auto* gives you fixes | 05:55 |
| lamont | libedsio/Makefile.am: required file `./depcomp' not found | 05:56 |
| lamont | ew | 05:56 |
| lifeless | autoreconf -i | 05:57 |
| lamont | yea | 05:57 |
| lifeless | barbed-wire-me-harder | 05:57 |
| lamont | that does seem to be working better./ | 05:58 |
| lamont | at least right up to all the unsatisfied externals. :-) | 05:58 |
| lamont | go glib | 05:58 |
| lamont | mind you, once I get this happy, I can quit using debmake :-) | 05:59 |
| lifeless | lamont: isn't that deprecated for some years? | 05:59 |
| lamont | iz RC for lenny | 05:59 |
| lifeless | I'm slowly working up a fix for the goat | 06:00 |
| lamont | goat? | 06:01 |
| lamont | as in sacrifice? | 06:01 |
| lamont | if (and only if) you're really bored: git clone git://git.debian.org/~lamont/xdelta.git | 06:02 |
| lamont | as for my part, I'm going to declare bed time./ | 06:03 |
| Hobbsee | no sleep for you! | 06:03 |
| lifeless | lamont: the auto* suite - the goatbook is the official book | 06:03 |
| lifeless | lamont: thus they are the goat tools | 06:03 |
| lamont | how, um, appropriate. | 06:03 |
| lifeless | lamont: so thats what, xdelta package? | 06:03 |
| lamont | yeah. as in xdelta 1 | 06:03 |
| lifeless | lamont: also, have you tried current bzr on for size ? | 06:03 |
| lamont | haven't quite had a reason to yet... | 06:04 |
| lifeless | iz faster | 06:04 |
| ion_ | I used bzr for a long time, but then i finally tried git and found that i like it a lot more4. | 06:04 |
| lamont | although I expect I'll bump into some bzr package soonish | 06:04 |
| lifeless | ion_: what do you like more about git | 06:04 |
| lamont | iz faster than git, or than old-bzr? | 06:05 |
| Hobbsee | ion_: bad move. now lifeless will probably come and hunts you down | 06:05 |
| ion_ | lifeless: The very favorite thing for me is how it handles branches. | 06:05 |
| Hobbsee | lamont: iz much faster. even the original pull. | 06:05 |
| lifeless | lamont: iz faster than hg for a number of things; haven't benched it against git yet, don't plan too until some other todo items (like halving the repository size) are completed. | 06:05 |
| lamont | cool. | 06:05 |
| lamont | given kernel work, I had to learn git anyway, kinda fell in love with it. | 06:06 |
| ion_ | lifeless: I often create branches for features that are going to require more than one commit, and git just handles it so much nicer than bzr. | 06:06 |
| jdong | for kernel-sized trees IMO git/hg still perform better on most operations, though I admit I haven't messed with packs yet | 06:06 |
| lifeless | ion_: in what way ? | 06:06 |
| lamont | as bzr gets the feature set closer, I expect that I'll use it more... git meets my needs quite nicely right now, so there's not so much reason to look at switching. | 06:06 |
| jdong | but for everything more manageably sized I love using bzr. The UI and featureset are awesome | 06:06 |
| lifeless | yay old-sci-fi (V is on :)) | 06:07 |
| jdong | what's V? </ignorance> | 06:07 |
| lifeless | not V for Victory, V the reptilian aliens miniseries | 06:07 |
| lifeless | lamont: please do let us know what things would make bzr more appealing for you (other than speed; we know about that :)) | 06:08 |
| ion_ | lifeless: All the code exists in a single directory. With the git-checkout command, you can switch between branches while staying in the same directory. I find the method to be less hassle than having to clone the repository to separate directories. Or was i using bzr incorrectly? | 06:09 |
| lifeless | ion_: you were using bzr in its simplest form; its quite capable of switching branches (see the 'bzr switch' command ;)) | 06:09 |
| lifeless | ion_: if I was working with a compiled language I would typically do something like: | 06:10 |
| lifeless | bzr init-repo ~/repos/project --no-trees | 06:10 |
| lifeless | that will hold my branches | 06:10 |
| lifeless | then bzr checkout --lightweight ~/repos/project/a-branch ~/source/foo | 06:10 |
| lifeless | to get a source tree | 06:10 |
| ion_ | lifeless: Ok, thanks. bzr’s man page doesn’t mention switch. That’s why i never noticed it. | 06:10 |
| lifeless | and bzr switch ~/repos/project/b-branch to change | 06:11 |
| jdong | ion_: consulting the bzr help command tends to be better than its manpage | 06:11 |
| lifeless | ion_: it's in a plugin; probably the debian package builds the manpage without the plugins installed | 06:11 |
| lifeless | ion_: its now in bzr's core | 06:11 |
| StevenK | % bzr help | grep -c switch | 06:11 |
| StevenK | 0 | 06:11 |
| jdong | StevenK: bzr help commands | 06:12 |
| lifeless | robertc@lifeless-64:~$ bzr help | grep -c switch | 06:12 |
| lifeless | 0 | 06:12 |
| lifeless | robertc@lifeless-64:~$ bzr help switch | 06:12 |
| lifeless | Purpose: Set the branch of a lightweight checkout and update. | 06:12 |
| lifeless | Usage: bzr switch TO_LOCATION | 06:12 |
| jdong | in my 0.92 it still seems to be provided by bzrtools | 06:12 |
| lifeless | jdong: thats correct | 06:12 |
| ion_ | Anyway, git does seem faster than bzr. I haven’t done any benchmarking, though, it’s entirely subjective. | 06:12 |
| * lamont knew one of the V stunt doubles. | 06:12 | |
| StevenK | I don't have a bzr switch | 06:12 |
| jdong | ion_: in my experience Git also tended to be more generous in using my disk space :) | 06:13 |
| wasabi | the mdadm udev stuff is bugging me a bit. requires that /etc/mdadm/mdadm.conf be kept up to date | 06:13 |
| ion_ | jdong: I don’t really care about disk space. | 06:13 |
| lifeless | StevenK: if you have < 1.0alpha, install bzrtools | 06:13 |
| wasabi | especially requires that when you move / to a new md array, you have to remember to update that file | 06:13 |
| wasabi | and update the initramfs | 06:13 |
| jdong | ion_: then I don't think much compares to git's speed. | 06:13 |
| lifeless | git is pretty fast at many things | 06:14 |
| ion_ | With git: git init, do stuff, git commit, git branch feature_x (fork a branch), git checkout feature_x (switch), do stuff, git commit, git checkout master, git merge feature_x, git branch -d feature_x (delete branch). Oh! That reminds me: the deletion of a branch isn’t allowed (unless forced) if the branch contains unmerged changes, which is a nice thing. | 06:15 |
| lamont | lifeless: as I bump into using bzr more, I'll keep that in mind. At the time that I finally standardized my vcs from the 4 that I was using, git made the most sense. Changing that will likely happen because of some as-yet-unseen compelling reason | 06:17 |
| lamont | s/likely/likely only/ | 06:17 |
| lamont | ion_: git checkout -b feature_x :) | 06:17 |
| lamont | (branch and switch) | 06:17 |
| lamont | and yes, that git resists deleting branches that have unmerged changes? love. | 06:17 |
| ion_ | That also removes the need to create a repo in order not to duplicate the common things between branches. | 06:17 |
| Hobbsee | jdong: it would be appreciated if you could track down with gpac blew up on some arches. | 06:18 |
| ion_ | I don’t mind the HDD space usage, but it’s one more thing to do. | 06:18 |
| ion_ | lamont: Thanks, i’ll keep that in mind. :-) | 06:18 |
| lifeless | ion_: well it also forces you to work in a single place. bzr doesn't need a repo to do switch | 06:18 |
| jdong | Hobbsee: certainly on my TODO list to trace that wxgtk related issue | 06:18 |
| lifeless | in fact, you can just 'bzr init-repo ~/repo' and put all your projects in there :) | 06:18 |
| jdong | Hobbsee: can you also look at why x264 "failed to upload"? | 06:18 |
| Hobbsee | jdong: i'm not really sure what it is - it should be there. | 06:18 |
| Hobbsee | jdong: yeah. iz YALPB | 06:19 |
| jdong | Hobbsee: yay! | 06:19 |
| Hobbsee | jdong: that'll go away when i give it back, and then check where it put the binaries. | 06:19 |
| jdong | Hobbsee: ok awesome, just wanted to make sure it wasn't my fault | 06:19 |
| ion_ | It doesn’t really force to work in a single place. There’s always a possibility to clone the branch to multiple places, but usually i find it not to be necessary. | 06:19 |
| lifeless | lamont: we'll have to find some compelling reason | 06:19 |
| Hobbsee | jdong: nah. it got demoted while it had build records, so soyuz blew up over it. YALPB for you. | 06:19 |
| Hobbsee | jdong: (and yes, it did got to main) | 06:20 |
| lifeless | ion_: I find I often have branches where a change requires a mssive rebuild | 06:20 |
| Hobbsee | s/got/get/ | 06:20 |
| lifeless | ion_: so at least for me I want multiple workspaces; all I was really trying to say is its easy to work with one workspace with bzr if thats what you want; and we want to make that easier | 06:20 |
| lifeless | it can never be easy enough | 06:20 |
| ion_ | Anyway, bzr is *hugely* better than a lot of the competition. :-) | 06:21 |
| lifeless | :) | 06:21 |
| Hobbsee | jdong: i may as well give it all back together though - particularly if i need to get someoen else to demote the binaries. | 06:21 |
| jdong | Hobbsee: ok, gpac FTBFS'ed because wxwidgets2.6 FTBFS'ed on affected arches. | 06:23 |
| jdong | Hobbsee: I think a give-back of wxwidgets2.6 on said arches would suffice, as it seems like the libgnomeprintui breakage it had before is now resolved in Hardy | 06:23 |
| Hobbsee | jdong: oh, and rmadison didn't check for those arches, or i didn't notice. | 06:24 |
| Hobbsee | jdong: got it. consider it done. | 06:24 |
| jdong | Hobbsee: thanks very much :) | 06:24 |
| lamont | well, off to bed. | 06:24 |
| jdong | good idea. Me too :) | 06:24 |
| Hobbsee | night lamont | 06:24 |
| choudesh | anyone around? is there a way to blacklist a package from a certain repo? | 07:01 |
| persia | choudesh: Yes, and Yes, and Why? | 07:02 |
| sladen | choudesh: keep talking, do you have an example | 07:02 |
| choudesh | all users have root access to their local boxes - but I want to limit what packages they can install. | 07:03 |
| choudesh | I have a local repo - but I don't want to go through and delete all the packages | 07:03 |
| persia | choudesh: That you can't do, as root can edit the sources.list | 07:03 |
| choudesh | that is pulled from a readonly nfs | 07:03 |
| persia | (unless your firewall blocks all external access, which doesn't seem ideal) | 07:04 |
| sladen | persia: usb; sudo dpkg -i | 07:04 |
| persia | Right. No unless. You just can't do it. | 07:04 |
| sladen | choudesh: you could install a fake meta package that conflicted with anything you weren't keen on | 07:04 |
| choudesh | I see. | 07:05 |
| persia | user = root could uninstall easily | 07:05 |
| persia | choudesh: To ask differently, why would the users have root access? | 07:05 |
| choudesh | they can't uninstall software - apt-get uninstall/purge is caught by a kernel mod and not executed. | 07:05 |
| choudesh | o, college dev lab | 07:06 |
| sladen | choudesh: if you're giving these people sudo rights on their box, then what you have is a social issue ("pretty please, don't install X, Y, or Z---I'm trusting you with sudo and I don't want to have to help you reinstall your machine"_ | 07:06 |
| sladen | ...and technical issues to social problems don't generally work | 07:06 |
| choudesh | well, we already had a few kids uninstall tzdata because it took up too much space | 07:07 |
| * persia thinks about running dpkg -P and/or /var/lib/dpkg/info/foo.prerm; rm -rf `dpkg -S foo`; /var/lib/dpkg/info/foo.postrm | 07:07 | |
| choudesh | they aren't the brightest kids but there are a few "hackers". ;-) | 07:07 |
| persia | choudesh: college dev lab is the worst place to give local users root: you concentrate smart, idle, motivated people and give them the problem of working around your limitations. | 07:08 |
| sladen | choudesh: course they can uninstall. sudo cp -a /usr/bin/apt-{g,w}et && sudo apt-wet --purge remove xyz | 07:08 |
| choudesh | sladen: still won't work since apt-get still calls a remove_file operation in the kernel. I look at the process and kill it if it is in my realm of "no-nos" | 07:09 |
| sladen | choudesh: take a step back. Instead of giving all privs and then trying to take them away. Just limit the sudo commands they can run to one or two commands | 07:09 |
| * persia agrees with sladen | 07:09 | |
| choudesh | sladen: tried. but the professors above me want it done this way. just give me your profession opinion and I just won't do it at all. :-D | 07:10 |
| choudesh | 500+ ubuntu dev machines are hard to admin | 07:10 |
| persia | choudesh: For a "professional opinion", you'd need to pay someone. Most would likely agree with sladen. | 07:10 |
| sladen | choudesh: can't you start each of them in a virtual machine, let them trash it and revert the image to a clean state as easy as 1-2-3 | 07:11 |
| choudesh | persia: heh. I just wanted to send this convo to my boss and show him that. | 07:11 |
| choudesh | don't get me wrong - I agree with both of you | 07:11 |
| choudesh | sladen: some do - others are in a kernel dev class and need direct access to hardware and DMA modifiers | 07:11 |
| persia | Doesn't even need to be virtual, use an EFS boot to prep a clean install on each boot, and reboot after each use (similar practice was done at my uni) | 07:11 |
| persia | Further, if users have direct access to HW & the like, they can swap out your kernel anyway. | 07:12 |
| choudesh | persia: we need that a few years ago - but since these machines are used between kernel-dev-class, opengl-class and a few others - the images was about 2.7gigs and a clean install of reboot took around 40 minutes | 07:12 |
| sladen | persia: good suggestion (PXE boot them with a LiveCD image)... | 07:13 |
| persia | Right. It's PXE now :) | 07:13 |
| persia | If you've the HW, just put a 4GB flash module in each device, and boot liveFS off of that (masking it as R/O in protected BIOS). | 07:14 |
| sladen | so you need a starting point, and their additions | 07:14 |
| persia | (lower network use) | 07:14 |
| choudesh | what I am working on now is a revolving NFS server. basiclly the only thing that machines will have is a /boot and and on reboot it gets a new clean nfs mount, then the servers removed the previous image and copy over a new one | 07:15 |
| sladen | various snapshotting techniques (eg. LVM/dm-snapshot/unionfs) should get this | 07:15 |
| sladen | it's the same technique used on the liveCDs that allows you to apt-get install after boot | 07:15 |
| choudesh | hmm - good idea | 07:15 |
| persia | choudesh: That works, but once they have an image, let them do whatever they want: just make sure it's standard practice to get a new image when they reboot. | 07:16 |
| choudesh | well - hopefully next year it will be in the budget to give every CS/CE major a laptop with ubuntu | 07:16 |
| sladen | stock up on OLPCs :) | 07:16 |
| choudesh | heh. | 07:17 |
| sladen | all seem good solutions | 07:18 |
| sladen | these idea of trying to enfore a policy from inside the package-manager when they have root (and they attempting to cover that by kernel hacks---some of students are *supposed* to be building their own kernels, so that isn't going to help | 07:19 |
| nemik | so in the packages, is the .orig.tar.gz diff'd or not with the diff file below it? | 07:31 |
| nemik | if it's not, how could i apply that diff to that package? | 07:32 |
| ion_ | dpkg-source -x foo.dsc, and now please read the topic. | 07:33 |
| nemik | thanks a lot ion_ | 07:36 |
| slangasek | 17:26 < bddebian> God I suck at pre/post/inst/rm stuff, regexp, shell scripting, just about everything else.. | 08:55 |
| slangasek | erm, ok then | 08:56 |
| ScottK | slangasek: Do you have anything to do with the partner repository as Ubuntu RM? | 08:57 |
| persia | slangasek: It's work in progress :) Also, are you able to purge old, buggy, security-hole ridden things from the partner repo? | 08:57 |
| * ScottK will let persia take up the conversation then and really go to bed. | 08:57 | |
| slangasek | erm... :) | 08:58 |
| ScottK | or not. | 08:58 |
| ScottK | Remember removing openssl097 from Gutsy right before the release? | 08:58 |
| persia | Essentially, in lieu of recompiling the VMWare utilities, libssl0.9.7 was put into partner, but it has open remote exploits available that will not be fixed upstream, so it's not ideal. | 08:58 |
| ScottK | slangasek: It's baaack. | 08:58 |
| persia | Note that the recompile is required by VMWare, not our local freindly ISV packager. | 08:59 |
| ScottK | Now off to bed then. Good night. | 09:01 |
| slangasek | persia: yes, as a matter of fact I had a hand in putting it into partner. Sorry, pulling it back out is not really an option unless a vmware rebuild happens first, which is not up to me; of course by its nature, "partner" is going to contain some things that don't meet various standards for e.g., main | 09:02 |
| * persia translates "erm... :)" into "Maybe, but I'm not sure, and need to talk to people during the week" | 09:02 | |
| persia | slangasek: Sure. I'm just worried about remote exploitation, and wonder if it's preferable to offer a undisclosed remote exploit in partner than to apologise and report that we're working with VMWare to resolve the issue. | 09:03 |
| persia | Further, it's not even up to the standards of universe (or we wouldn't be so voiceferous) | 09:04 |
| slangasek | persia: openssl097 contains no network services, there's no danger of remote exploitation in that package per se | 09:05 |
| * Hobbsee waves | 09:05 | |
| persia | slangasek: Right, but as VMWare server uses libssl for remote management, that means there is likely a remote attack on the management interface. | 09:06 |
| slangasek | possibly | 09:06 |
| persia | Hmmm.. Not good, but I'm too lazy to develop a PoC right now. Maybe it will get fixed soon (and I hope the vendor has been appraised of the situation: it affects all the binaries they distribute). | 09:07 |
| slangasek | I can pass that up the chain to the ISV packaging folks | 09:07 |
| persia | slangasek: Thanks. | 09:08 |
| === azeem_ is now known as azeem | ||
| geser | Hobbsee: please give-back: ocaml-http ocaml-reins ocamldap ocamlodbc ocamlsdl ocsigen mlpcap mldonkey fextremes fcopulae. Thanks. | 12:18 |
| Keybuk | hmm, EXA is still slower than XAA | 12:18 |
| hellboy195 | ahoi | 12:20 |
| Keybuk | damn, there are so many little quirks and foibles that you have to remember if you're using ptrace | 12:58 |
| Hobbsee | you can sort out a botnet in #ubuntu if you prefer | 12:59 |
| Keybuk | I don't think I have ops there | 12:59 |
| Hobbsee | lucky for you | 13:00 |
| Hobbsee | besides, you need k-tickets to do much | 13:00 |
| geser | Hobbsee: are you in a mood to give-back some packages or should I wait for pitti? | 13:04 |
| stdin | geser: she's a tad busy right now, dealing with #ubuntu | 13:15 |
| Hobbsee | dear freenode staff, please kline faster. | 13:17 |
| Hobbsee | stdin: i can't do much, just watch | 13:18 |
| Hobbsee | slowly giving them back | 13:18 |
| stdin | watch and set +rRm as quick as possible | 13:18 |
| sabdfl | emgent: pong | 13:18 |
| Hobbsee | stdin: we already are. and we have staffers on our side. | 13:19 |
| stdin | Hobbsee: I can see and I don't envy you right now ;) | 13:19 |
| Hobbsee | smite them with the mightly kline stick! | 13:20 |
| Hobbsee | all we need are the trains to go faster, adn more regularly | 13:20 |
| stdin | k-line stick is the only thing that beets the long pointy stick :p | 13:20 |
| Hobbsee | yup | 13:21 |
| Hobbsee | i can't kick people off networks. | 13:21 |
| Hobbsee | geser: all given back | 13:22 |
| emgent | sabdfl, see query, when you have time :) | 13:22 |
| * geser hugs Hobbsee | 13:22 | |
| * Hobbsee hugs geser | 13:22 | |
| Hobbsee | stdin: at least Seveas is in a happy mood | 13:23 |
| stdin | Hobbsee: like a kid with a candy | 13:23 |
| Hobbsee | yup | 13:23 |
| Hobbsee | chuga chuga chuga chuga choo choo!!! | 13:23 |
| Seveas | Hobbsee, I thought you quit smoking? :) | 13:27 |
| StevenK | She moved from smoking to shooting up | 13:27 |
| StevenK | Means she doesn't have to explain the haze in her room any more | 13:27 |
| Seveas | StevenK, hehe | 13:29 |
| Hobbsee_ | Seveas: or did two of us with you at the airport make you forget which was which? | 13:30 |
| Seveas | Hobbsee_, neh | 13:30 |
| === Hobbsee_ is now known as Hobbsee | ||
| Seveas | I know you don't smoke when not on fire | 13:31 |
| Seveas | Chimney Draper however ;) | 13:31 |
| Hobbsee | haha | 13:31 |
| glatzor_ | hi luisbg | 14:17 |
| glatzor_ | luisbg: I think that I found a good interface for the xrandr application | 14:18 |
| luisbg | glatzor, ohh really? | 14:38 |
| luisbg | tell me about it | 14:38 |
| jdstrand | slangasek: thanks for looking into openldap-- did you file an upstream/debian/ubuntu bug on this, or shall I? | 14:39 |
| jdstrand | slangasek: oh, btw you can run an individual openldap2.3 with: cd debian/build/tests && ./run test030-relay | 14:49 |
| jdstrand | slangasek: s/individual openldap2.3/individual test/ | 14:49 |
| glatzor | luisbg: I haven't yet found a good way to integrate a "keep settings" dialog, that resets the configuration again | 14:50 |
| glatzor | luisbg: I would like to make it instant apply, since we are already using xrandr | 14:51 |
| glatzor | luisbg: I am just creating a launchpad project | 14:51 |
| luisbg | glatzor, I've been helping the ubuntu studio settings app | 14:52 |
| luisbg | which we started two days ago | 14:52 |
| luisbg | the same concepts could be applied | 14:52 |
| luisbg | want me to work on the interface? | 14:52 |
| luisbg | glatzor, read my PM | 14:54 |
| luisbg | sorry, but I do have to leave | 14:55 |
| luisbg | hope you are still around when I come back =) | 14:55 |
| Viper550 | Hello | 15:02 |
| === Lure_ is now known as Lure | ||
| === luka74 is now known as Lure | ||
| === Pici` is now known as Pici | ||
| juliank | Hey, I'm currently writing a script which creates a bootable USB stick from the livedisk (bit like Fedora's script). (Supports even persistent mode). It will be finished soon, and I think it would be great if it could be added to the hardy disks. What do you think? | 17:51 |
| Lure | juliank: something like this: http://janimo.blogspot.com/2007/10/live-cd-on-usb-key.html | 17:55 |
| Lure | juliank: probably better to ask tommorow when most developers will be online | 17:55 |
| juliank | Lure: I started mine from scratch, and it supports persistent mode. It can also partition the usb stick, if needed. I will blog it within the next days, so it will be visible on planet ubuntu. | 17:58 |
| === luka74 is now known as Lure | ||
| Keybuk | man, I hate UNIX | 19:28 |
| ion_ | There’s always Windows®. ;-) | 19:29 |
| Keybuk | their API is worse, I hear | 19:29 |
| Keybuk | ...since you can wait() on processes to stop, you'd *think* there would be a signal to tell you to wait() wouldn't you? | 19:30 |
| ion_ | Can’t you just wait() and then ignore a possible error? I’m probably missing something obvious. | 19:32 |
| Keybuk | wait is synchronous :-) | 19:33 |
| sjoerd | Keybuk: You do get sigchld right ? | 19:35 |
| Keybuk | no, no sigchld | 19:35 |
| Spads | Keybuk: you mean like a "dear parent, please wait() for me, as I'm about to do something utterly fantastic and then exit()!" | 19:37 |
| lifeless | Keybuk: SIGCHLD tells you to wait | 19:37 |
| Keybuk | hmm | 19:40 |
| Keybuk | *confused* | 19:40 |
| Keybuk | I just don't seem to get be getting SIGCHLD | 19:41 |
| Keybuk | aha, signal flags are a little strange here | 19:45 |
| Keybuk | yes, silly parent shell had stuffed up the signal flags | 20:10 |
| === tonyy is now known as tonyyarusso | ||
| === asac_ is now known as asac | ||
| slangasek | jdstrand: haven't filed any bugs about it, was busy working through the libtool issues and figured I'd just go ahead and commit a fix when I had it working :) | 20:26 |
| lifeless | slangasek: libtool FTW? ;) | 20:36 |
| slangasek | lifeless: "Generated automatically by (GNU OpenLDAP 2.3.38)" FTW | 20:37 |
| lifeless | slangasek: wtf? | 20:38 |
| slangasek | i.e., I think the fix I need is to relibtoolize with something less crackful | 20:38 |
| lifeless | well, that or kill libtool | 20:42 |
| slangasek | that would be more time-consuming and annoying | 20:44 |
| * emgent heya | 20:48 | |
| === Tonio__ is now known as Tonio_ | ||
| Keybuk | !?! | 21:04 |
| Keybuk | Sorry, the program "dash" closed unexpectedly | 21:04 |
| stgraber | ouch :) | 21:04 |
| Keybuk | I think that was my fault | 21:04 |
| ion_ | Heh | 21:04 |
| ion_ | ‘kill -SEGV $$’? :-) | 21:05 |
| Keybuk | -TRAP | 21:05 |
| Keybuk | well | 21:05 |
| Keybuk | but more complicated than that | 21:05 |
| Keybuk | I had exec'd a shell which was to exec another program, so I could see whether ptrace trapped only the first exec or both | 21:06 |
| Keybuk | and I still had the PTRACE_CONT set to deliver the signal to the process | 21:06 |
| === dendrobates is now known as dendro-away | ||
| JanC | does anybody know where this error message comes from: https://answers.launchpad.net/ubuntu/+question/18888 ? | 22:29 |
| pochu | JanC: no idea, but it installs fine here through Synaptic too. x86, Hardy up-to-date. | 23:01 |
| pochu | Have to go, good night everyone. | 23:01 |
| Fujitsu | Night pochu. | 23:01 |
| JanC | pochu: it works fine for me to, on gutsy | 23:04 |
| JanC | but I can't find where this error message comes from, so I can't find what's wrong with this guy's system :-( | 23:05 |
| Fujitsu | JanC: Ask him to run apt-get update or the graphical equivalent and try again. | 23:06 |
| === azeem_ is now known as azeem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!