[00:00] <emgent> this is my idea
[00:21] <sladen> emgent: I suspect it might be more interesting to put money toward "you helping XYZ" when a particular XYZ is known
[00:22] <emgent> sure sladen
[02:55]  * emgent heya
[05:51] <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:54] <lamont> I think I may have auto* issues to fix.
[05:55] <lifeless> using auto* gives you fixes
[05:56] <lamont> libedsio/Makefile.am: required file `./depcomp' not found
[05:56] <lamont> ew
[05:57] <lifeless> autoreconf -i
[05:57] <lamont> yea
[05:57] <lifeless> barbed-wire-me-harder
[05:58] <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:59] <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
[06:00] <lifeless> I'm slowly working up a fix for the goat
[06:01] <lamont> goat?
[06:01] <lamont> as in sacrifice?
[06:02] <lamont> if (and only if) you're really bored: git clone git://git.debian.org/~lamont/xdelta.git
[06:03] <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:04] <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:05] <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:06] <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:07] <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:08] <lifeless> lamont: please do let us know what things would make bzr more appealing for you (other than speed; we know about that :))
[06:09] <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:10] <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:11] <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:12] <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:13] <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:14] <lifeless> git is pretty fast at many things
[06:15] <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:17] <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:18] <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:19] <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:20] <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:21] <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:23] <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:24] <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
[07:01] <choudesh> anyone around? is there a way to blacklist a package from a certain repo?
[07:02] <persia> choudesh: Yes, and Yes, and Why?
[07:02] <sladen> choudesh: keep talking, do you have an example
[07:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <sladen> persia: good suggestion (PXE boot them with a LiveCD image)...
[07:13] <persia> Right.  It's PXE now :)
[07:14] <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:15] <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:16] <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:17] <choudesh> heh.
[07:18] <sladen> all seem good solutions
[07:19] <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:31] <nemik> so in the packages, is the .orig.tar.gz diff'd or not with the diff file below it?
[07:32] <nemik> if it's not, how could i apply that diff to that package?
[07:33] <ion_> dpkg-source -x foo.dsc, and now please read the topic.
[07:36] <nemik> thanks a lot ion_
[08:55] <slangasek> 17:26 < bddebian> God I suck at pre/post/inst/rm stuff, regexp, shell scripting, just about everything else..
[08:56] <slangasek> erm, ok then
[08:57] <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:58] <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:59] <persia> Note that the recompile is required by VMWare, not our local freindly ISV packager.
[09:01] <ScottK> Now off to bed then.  Good night.
[09:02] <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:03] <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:04] <persia> Further, it's not even up to the standards of universe (or we wouldn't be so voiceferous)
[09:05] <slangasek> persia: openssl097 contains no network services, there's no danger of remote exploitation in that package per se
[09:05]  * Hobbsee waves
[09:06] <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:07] <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:08] <persia> slangasek: Thanks.
[12:18] <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:20] <hellboy195> ahoi
[12:58] <Keybuk> damn, there are so many little quirks and foibles that you have to remember if you're using ptrace
[12:59] <Hobbsee> you can sort out a botnet in #ubuntu if you prefer
[12:59] <Keybuk> I don't think I have ops there
[13:00] <Hobbsee> lucky for you
[13:00] <Hobbsee> besides, you need k-tickets to do much
[13:04] <geser> Hobbsee: are you in a mood to give-back some packages or should I wait for pitti?
[13:15] <stdin> geser: she's a tad busy right now, dealing with #ubuntu
[13:17] <Hobbsee> dear freenode staff, please kline faster.
[13:18] <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:19] <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:20] <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:21] <Hobbsee> yup
[13:21] <Hobbsee> i can't kick people off networks.
[13:22] <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:23] <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:27] <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:29] <Seveas> StevenK, hehe
[13:30] <Hobbsee_> Seveas: or did two of us with you at the airport make you forget which was which?
[13:30] <Seveas> Hobbsee_, neh
[13:31] <Seveas> I know you don't smoke when not on fire
[13:31] <Seveas> Chimney Draper however ;)
[13:31] <Hobbsee> haha
[14:17] <glatzor_> hi luisbg
[14:18] <glatzor_> luisbg: I think that I found a good interface for the xrandr application
[14:38] <luisbg> glatzor, ohh really?
[14:38] <luisbg> tell me about it
[14:39] <jdstrand> slangasek: thanks for looking into openldap-- did you file an upstream/debian/ubuntu bug on this, or shall I?
[14:49] <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:50] <glatzor> luisbg: I haven't yet found a good way to integrate a "keep settings" dialog, that resets the configuration again
[14:51] <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:52] <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:54] <luisbg> glatzor, read my PM
[14:55] <luisbg> sorry, but I do have to leave
[14:55] <luisbg> hope you are still around when I come back =)
[15:02] <Viper550> Hello
[17:51] <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:55] <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:58] <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.
[19:28] <Keybuk> man, I hate UNIX
[19:29] <ion_> There’s always Windows®. ;-)
[19:29] <Keybuk> their API is worse, I hear
[19:30] <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:32] <ion_> Can’t you just wait() and then ignore a possible error? I’m probably missing something obvious.
[19:33] <Keybuk> wait is synchronous :-)
[19:35] <sjoerd> Keybuk: You do get sigchld right ?
[19:35] <Keybuk> no, no sigchld
[19:37] <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:40] <Keybuk> hmm
[19:40] <Keybuk> *confused*
[19:41] <Keybuk> I just don't seem to get be getting SIGCHLD
[19:45] <Keybuk> aha, signal flags are a little strange here
[20:10] <Keybuk> yes, silly parent shell had stuffed up the signal flags
[20:26] <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:36] <lifeless> slangasek: libtool FTW?  ;)
[20:37] <slangasek> lifeless: "Generated automatically by  (GNU OpenLDAP 2.3.38)" FTW
[20:38] <lifeless> slangasek: wtf?
[20:38] <slangasek> i.e., I think the fix I need is to relibtoolize with something less crackful
[20:42] <lifeless> well, that or kill libtool
[20:44] <slangasek> that would be more time-consuming and annoying
[20:48]  * emgent heya
[21:04] <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:05] <ion_> ‘kill -SEGV $$’? :-)
[21:05] <Keybuk> -TRAP
[21:05] <Keybuk> well
[21:05] <Keybuk> but more complicated than that
[21:06] <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
[22:29] <JanC> does anybody know where this error message comes from: https://answers.launchpad.net/ubuntu/+question/18888 ?
[23:01] <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:04] <JanC> pochu: it works fine for me to, on gutsy
[23:05] <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:06] <Fujitsu> JanC: Ask him to run apt-get update or the graphical equivalent and try again.