[00:00] this is my idea [00:21] emgent: I suspect it might be more interesting to put money toward "you helping XYZ" when a particular XYZ is known [00:22] sure sladen [02:55] * emgent heya === ion__ is now known as ion_ === stu2 is now known as stub === tonyy is now known as tonyyarusso [05:51] 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] hrm. [05:54] I think I may have auto* issues to fix. [05:55] using auto* gives you fixes [05:56] libedsio/Makefile.am: required file `./depcomp' not found [05:56] ew [05:57] autoreconf -i [05:57] yea [05:57] barbed-wire-me-harder [05:58] that does seem to be working better./ [05:58] at least right up to all the unsatisfied externals. :-) [05:58] go glib [05:59] mind you, once I get this happy, I can quit using debmake :-) [05:59] lamont: isn't that deprecated for some years? [05:59] iz RC for lenny [06:00] I'm slowly working up a fix for the goat [06:01] goat? [06:01] as in sacrifice? [06:02] if (and only if) you're really bored: git clone git://git.debian.org/~lamont/xdelta.git [06:03] as for my part, I'm going to declare bed time./ [06:03] no sleep for you! [06:03] lamont: the auto* suite - the goatbook is the official book [06:03] lamont: thus they are the goat tools [06:03] how, um, appropriate. [06:03] lamont: so thats what, xdelta package? [06:03] yeah. as in xdelta 1 [06:03] lamont: also, have you tried current bzr on for size ? [06:04] haven't quite had a reason to yet... [06:04] iz faster [06:04] I used bzr for a long time, but then i finally tried git and found that i like it a lot more4. [06:04] although I expect I'll bump into some bzr package soonish [06:04] ion_: what do you like more about git [06:05] iz faster than git, or than old-bzr? [06:05] ion_: bad move. now lifeless will probably come and hunts you down [06:05] lifeless: The very favorite thing for me is how it handles branches. [06:05] lamont: iz much faster. even the original pull. [06:05] 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] cool. [06:06] given kernel work, I had to learn git anyway, kinda fell in love with it. [06:06] 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] 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] ion_: in what way ? [06:06] 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] but for everything more manageably sized I love using bzr. The UI and featureset are awesome [06:07] yay old-sci-fi (V is on :)) [06:07] what's V? [06:07] not V for Victory, V the reptilian aliens miniseries [06:08] lamont: please do let us know what things would make bzr more appealing for you (other than speed; we know about that :)) [06:09] 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] ion_: you were using bzr in its simplest form; its quite capable of switching branches (see the 'bzr switch' command ;)) [06:10] ion_: if I was working with a compiled language I would typically do something like: [06:10] bzr init-repo ~/repos/project --no-trees [06:10] that will hold my branches [06:10] then bzr checkout --lightweight ~/repos/project/a-branch ~/source/foo [06:10] to get a source tree [06:10] lifeless: Ok, thanks. bzr’s man page doesn’t mention switch. That’s why i never noticed it. [06:11] and bzr switch ~/repos/project/b-branch to change [06:11] ion_: consulting the bzr help command tends to be better than its manpage [06:11] ion_: it's in a plugin; probably the debian package builds the manpage without the plugins installed [06:11] ion_: its now in bzr's core [06:11] % bzr help | grep -c switch [06:11] 0 [06:12] StevenK: bzr help commands [06:12] robertc@lifeless-64:~$ bzr help | grep -c switch [06:12] 0 [06:12] robertc@lifeless-64:~$ bzr help switch [06:12] Purpose: Set the branch of a lightweight checkout and update. [06:12] Usage: bzr switch TO_LOCATION [06:12] in my 0.92 it still seems to be provided by bzrtools [06:12] jdong: thats correct [06:12] 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] I don't have a bzr switch [06:13] ion_: in my experience Git also tended to be more generous in using my disk space :) [06:13] the mdadm udev stuff is bugging me a bit. requires that /etc/mdadm/mdadm.conf be kept up to date [06:13] jdong: I don’t really care about disk space. [06:13] StevenK: if you have < 1.0alpha, install bzrtools [06:13] especially requires that when you move / to a new md array, you have to remember to update that file [06:13] and update the initramfs [06:13] ion_: then I don't think much compares to git's speed. [06:14] git is pretty fast at many things [06:15] 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:17] 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] s/likely/likely only/ [06:17] ion_: git checkout -b feature_x :) [06:17] (branch and switch) [06:17] and yes, that git resists deleting branches that have unmerged changes? love. [06:17] That also removes the need to create a repo in order not to duplicate the common things between branches. [06:18] jdong: it would be appreciated if you could track down with gpac blew up on some arches. [06:18] I don’t mind the HDD space usage, but it’s one more thing to do. [06:18] lamont: Thanks, i’ll keep that in mind. :-) [06:18] ion_: well it also forces you to work in a single place. bzr doesn't need a repo to do switch [06:18] Hobbsee: certainly on my TODO list to trace that wxgtk related issue [06:18] in fact, you can just 'bzr init-repo ~/repo' and put all your projects in there :) [06:18] Hobbsee: can you also look at why x264 "failed to upload"? [06:18] jdong: i'm not really sure what it is - it should be there. [06:19] jdong: yeah. iz YALPB [06:19] Hobbsee: yay! [06:19] jdong: that'll go away when i give it back, and then check where it put the binaries. [06:19] Hobbsee: ok awesome, just wanted to make sure it wasn't my fault [06:19] 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] lamont: we'll have to find some compelling reason [06:19] jdong: nah. it got demoted while it had build records, so soyuz blew up over it. YALPB for you. [06:20] jdong: (and yes, it did got to main) [06:20] ion_: I find I often have branches where a change requires a mssive rebuild [06:20] s/got/get/ [06:20] 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] it can never be easy enough [06:21] Anyway, bzr is *hugely* better than a lot of the competition. :-) [06:21] :) [06:21] jdong: i may as well give it all back together though - particularly if i need to get someoen else to demote the binaries. [06:23] Hobbsee: ok, gpac FTBFS'ed because wxwidgets2.6 FTBFS'ed on affected arches. [06:23] 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:24] jdong: oh, and rmadison didn't check for those arches, or i didn't notice. [06:24] jdong: got it. consider it done. [06:24] Hobbsee: thanks very much :) [06:24] well, off to bed. [06:24] good idea. Me too :) [06:24] night lamont [07:01] anyone around? is there a way to blacklist a package from a certain repo? [07:02] choudesh: Yes, and Yes, and Why? [07:02] choudesh: keep talking, do you have an example [07:03] all users have root access to their local boxes - but I want to limit what packages they can install. [07:03] I have a local repo - but I don't want to go through and delete all the packages [07:03] choudesh: That you can't do, as root can edit the sources.list [07:03] that is pulled from a readonly nfs [07:04] (unless your firewall blocks all external access, which doesn't seem ideal) [07:04] persia: usb; sudo dpkg -i [07:04] Right. No unless. You just can't do it. [07:04] choudesh: you could install a fake meta package that conflicted with anything you weren't keen on [07:05] I see. [07:05] user = root could uninstall easily [07:05] choudesh: To ask differently, why would the users have root access? [07:05] they can't uninstall software - apt-get uninstall/purge is caught by a kernel mod and not executed. [07:06] o, college dev lab [07:06] 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] ...and technical issues to social problems don't generally work [07:07] 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] they aren't the brightest kids but there are a few "hackers". ;-) [07:08] 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] choudesh: course they can uninstall. sudo cp -a /usr/bin/apt-{g,w}et && sudo apt-wet --purge remove xyz [07:09] 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] 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:10] 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] 500+ ubuntu dev machines are hard to admin [07:10] choudesh: For a "professional opinion", you'd need to pay someone. Most would likely agree with sladen. [07:11] 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] persia: heh. I just wanted to send this convo to my boss and show him that. [07:11] don't get me wrong - I agree with both of you [07:11] sladen: some do - others are in a kernel dev class and need direct access to hardware and DMA modifiers [07:11] 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:12] Further, if users have direct access to HW & the like, they can swap out your kernel anyway. [07:12] 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:13] persia: good suggestion (PXE boot them with a LiveCD image)... [07:13] Right. It's PXE now :) [07:14] 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] so you need a starting point, and their additions [07:14] (lower network use) [07:15] 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] various snapshotting techniques (eg. LVM/dm-snapshot/unionfs) should get this [07:15] it's the same technique used on the liveCDs that allows you to apt-get install after boot [07:15] hmm - good idea [07:16] 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] well - hopefully next year it will be in the budget to give every CS/CE major a laptop with ubuntu [07:16] stock up on OLPCs :) [07:17] heh. [07:18] all seem good solutions [07:19] 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:31] so in the packages, is the .orig.tar.gz diff'd or not with the diff file below it? [07:32] if it's not, how could i apply that diff to that package? [07:33] dpkg-source -x foo.dsc, and now please read the topic. [07:36] thanks a lot ion_ [08:55] 17:26 < bddebian> God I suck at pre/post/inst/rm stuff, regexp, shell scripting, just about everything else.. [08:56] erm, ok then [08:57] slangasek: Do you have anything to do with the partner repository as Ubuntu RM? [08:57] 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:58] erm... :) [08:58] or not. [08:58] Remember removing openssl097 from Gutsy right before the release? [08:58] 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] slangasek: It's baaack. [08:59] Note that the recompile is required by VMWare, not our local freindly ISV packager. [09:01] Now off to bed then. Good night. [09:02] 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:03] 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:04] Further, it's not even up to the standards of universe (or we wouldn't be so voiceferous) [09:05] persia: openssl097 contains no network services, there's no danger of remote exploitation in that package per se [09:05] * Hobbsee waves [09:06] 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] possibly [09:07] 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] I can pass that up the chain to the ISV packaging folks [09:08] slangasek: Thanks. === azeem_ is now known as azeem [12:18] Hobbsee: please give-back: ocaml-http ocaml-reins ocamldap ocamlodbc ocamlsdl ocsigen mlpcap mldonkey fextremes fcopulae. Thanks. [12:18] hmm, EXA is still slower than XAA [12:20] ahoi [12:58] damn, there are so many little quirks and foibles that you have to remember if you're using ptrace [12:59] you can sort out a botnet in #ubuntu if you prefer [12:59] I don't think I have ops there [13:00] lucky for you [13:00] besides, you need k-tickets to do much [13:04] Hobbsee: are you in a mood to give-back some packages or should I wait for pitti? [13:15] geser: she's a tad busy right now, dealing with #ubuntu [13:17] dear freenode staff, please kline faster. [13:18] stdin: i can't do much, just watch [13:18] slowly giving them back [13:18] watch and set +rRm as quick as possible [13:18] emgent: pong [13:19] stdin: we already are. and we have staffers on our side. [13:19] Hobbsee: I can see and I don't envy you right now ;) [13:20] smite them with the mightly kline stick! [13:20] all we need are the trains to go faster, adn more regularly [13:20] k-line stick is the only thing that beets the long pointy stick :p [13:21] yup [13:21] i can't kick people off networks. [13:22] geser: all given back [13:22] sabdfl, see query, when you have time :) [13:22] * geser hugs Hobbsee [13:22] * Hobbsee hugs geser [13:23] stdin: at least Seveas is in a happy mood [13:23] Hobbsee: like a kid with a candy [13:23] yup [13:23] chuga chuga chuga chuga choo choo!!! [13:27] Hobbsee, I thought you quit smoking? :) [13:27] She moved from smoking to shooting up [13:27] Means she doesn't have to explain the haze in her room any more [13:29] StevenK, hehe [13:30] Seveas: or did two of us with you at the airport make you forget which was which? [13:30] Hobbsee_, neh === Hobbsee_ is now known as Hobbsee [13:31] I know you don't smoke when not on fire [13:31] Chimney Draper however ;) [13:31] haha [14:17] hi luisbg [14:18] luisbg: I think that I found a good interface for the xrandr application [14:38] glatzor, ohh really? [14:38] tell me about it [14:39] slangasek: thanks for looking into openldap-- did you file an upstream/debian/ubuntu bug on this, or shall I? [14:49] slangasek: oh, btw you can run an individual openldap2.3 with: cd debian/build/tests && ./run test030-relay [14:49] slangasek: s/individual openldap2.3/individual test/ [14:50] luisbg: I haven't yet found a good way to integrate a "keep settings" dialog, that resets the configuration again [14:51] luisbg: I would like to make it instant apply, since we are already using xrandr [14:51] luisbg: I am just creating a launchpad project [14:52] glatzor, I've been helping the ubuntu studio settings app [14:52] which we started two days ago [14:52] the same concepts could be applied [14:52] want me to work on the interface? [14:54] glatzor, read my PM [14:55] sorry, but I do have to leave [14:55] hope you are still around when I come back =) [15:02] Hello === Lure_ is now known as Lure === luka74 is now known as Lure === Pici` is now known as Pici [17:51] 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:55] juliank: something like this: http://janimo.blogspot.com/2007/10/live-cd-on-usb-key.html [17:55] juliank: probably better to ask tommorow when most developers will be online [17:58] 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. === luka74 is now known as Lure [19:28] man, I hate UNIX [19:29] There’s always Windows®. ;-) [19:29] their API is worse, I hear [19:30] ...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:32] Can’t you just wait() and then ignore a possible error? I’m probably missing something obvious. [19:33] wait is synchronous :-) [19:35] Keybuk: You do get sigchld right ? [19:35] no, no sigchld [19:37] 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] Keybuk: SIGCHLD tells you to wait [19:40] hmm [19:40] *confused* [19:41] I just don't seem to get be getting SIGCHLD [19:45] aha, signal flags are a little strange here [20:10] yes, silly parent shell had stuffed up the signal flags === tonyy is now known as tonyyarusso === asac_ is now known as asac [20:26] 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:36] slangasek: libtool FTW? ;) [20:37] lifeless: "Generated automatically by (GNU OpenLDAP 2.3.38)" FTW [20:38] slangasek: wtf? [20:38] i.e., I think the fix I need is to relibtoolize with something less crackful [20:42] well, that or kill libtool [20:44] that would be more time-consuming and annoying [20:48] * emgent heya === Tonio__ is now known as Tonio_ [21:04] !?! [21:04] Sorry, the program "dash" closed unexpectedly [21:04] ouch :) [21:04] I think that was my fault [21:04] Heh [21:05] ‘kill -SEGV $$’? :-) [21:05] -TRAP [21:05] well [21:05] but more complicated than that [21:06] 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] and I still had the PTRACE_CONT set to deliver the signal to the process === dendrobates is now known as dendro-away [22:29] does anybody know where this error message comes from: https://answers.launchpad.net/ubuntu/+question/18888 ? [23:01] JanC: no idea, but it installs fine here through Synaptic too. x86, Hardy up-to-date. [23:01] Have to go, good night everyone. [23:01] Night pochu. [23:04] pochu: it works fine for me to, on gutsy [23:05] 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:06] JanC: Ask him to run apt-get update or the graphical equivalent and try again. === azeem_ is now known as azeem