[00:09] <TheMuso> c/
[00:09] <Kano> hi, did you see the new security update for ntfs-3g?
[00:10] <Kano> http://ntfs-3g.org/releases.html
[00:10] <Kano> http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/418
[00:47] <Kano> i updated it for kanotix already...
[01:10] <superm1> Kano, please file a bug and mark it as a security vulnerability
[01:11] <Kano> how about you
[01:15]  * TheMuso shakse his head.
[01:15] <TheMuso> shakes
[01:31] <Hobbsee> greetings!
[01:42] <zul> welcome back Hobbsee
[01:43] <Hobbsee> ty, but i'm still on VAC
[01:45] <superm1> Hobbsee, where to?
[01:47] <Hobbsee> superm1: adelaide
[01:47]  * Hobbsee has finally renewed ubuntu membership
[02:38] <lamont> slangase`: heh
[02:38] <lamont> your k got eaten.
[02:38] <lamont> wondering about your thoughts on making the 64-bit implicit-ptr conversions fatal for hardy..
[02:40] <lifeless> lamont-break-your-buildly-yours
[02:41] <lamont> lifeless: that's what I does. yep.
[02:42] <lifeless> lamont: better to make it fatal in debian ;)
[02:42] <lamont> lifeless: it is
[02:42] <lifeless> lamont: ah, then you have my vote
[02:42] <lifeless> lamont for prez!
[03:16] <ScottK> Dear lamont: You're postfix package doesn't automatically bathe the baby and feed me candy.  Plz fix.  kthnksbye.
[03:17] <ScottK> Sorry.  Tiring of reading postfix-users and "I installed postfix on Ubuntu and used some random 3rd party web site cargo cult script to configure it how come it doesn't work?" posts
[03:24]  * StevenK still has to figure out how to do SMTP AUTH with postfix.
[03:24] <koolkat> How do I become a Documentation Member?
[03:25] <nixternal> koolkat: you were int he right channel, but left before I could say anything :)
[03:25] <koolkat> Ok
[03:25] <koolkat> what chanel was that?
[03:25] <nixternal> #ubuntu-doc
[03:26] <koolkat> nixternal: so how do I become a member?
[03:26] <nixternal> go to #ubuntu-doc and we can talk about it there
[03:34] <ScottK> StevenK: Give me a root login to your server and I'll be glad to set it up for you. ;-)
[03:35] <nixternal> careful now, ScottK stole my credit card and social security number with that trick :p
[03:40] <StevenK> Haha
[03:40] <StevenK> ScottK: Like I even trust myself with root access. :-P
[03:41] <ScottK> StevenK: I trust me more than I trust you.  Why shouldn't you too?
[03:41]  * StevenK blinks, trying to dereference
[03:43] <StevenK> ScottK: My main problem is "Postfix SMTP AUTH (and TLS) HOWTO" is all Postfix 1.x
[03:44] <superm1> nixternal, those are replaceable, at least he didn't take your gpg key like he took mine with that trick
[03:44] <ScottK> StevenK: IIRC Ubuntu postfix docs are sensible.  I'll find you a link if you're interested.
[03:44] <StevenK> ScottK: Sounds great
[03:45] <ScottK> StevenK: Which release?
[03:49] <StevenK> ScottK: Dapper
[03:49] <ScottK> StevenK: https://help.ubuntu.com/7.10/server/C/postfix.html#postfix-smtp-authentication isn't exactly how I do it (I use sasldb and auxprop), but I believe this will work for Dapper - Gutsy.  For Hardy I'd recommend Dovecot.
[03:49] <TheMuso> What package in hardy provides the gpg agent facilities?
[03:50] <ScottK> TheMuso: There are several.
[03:50] <TheMuso> Whats used by default then.
[03:50] <TheMuso> ah seahorse
[03:51] <StevenK> ScottK: Yes, since I use dovecot for IMAP/POP3, I was pondering waiting for Hardy
[03:51] <lifeless> I used gnome-gpg
[03:51] <lifeless> I likes it.
[03:52] <ScottK> TheMuso: gnupg-agent will be used by Default actually.  I think it's the only one in Main.
[03:52] <TheMuso> Well I need to investigate why 1) seahorse gpg sign passphrase windows don't get proper focus, and 2) why they are completely inaccessible.
[03:53] <ScottK> TheMuso: For gnupg-agent the U/I is provided by pinentry.  I don't know if that relates at all to Seahorse.
[03:53] <StevenK> Hrm. I have SMTP AUTH half setup
[03:53] <StevenK> I think
[03:54] <ScottK> StevenK: If you've got a recent enough Dovecot for SMTP Auth (I'm not at all familiar with that), I do know the Postfix in dapper-backports will support it.
[03:55] <StevenK> ScottK: I don't think so, I think it requires a newer dovecot. Besides, I don't like running backports.
[03:56] <ScottK> StevenK: Sure.  If it helps any on this one, lamont runs a backported Postfix on his Dapper boxen and he did the backport.
[03:57] <StevenK> Hrm. I think I have all of the bits, it just doesn't work ...
[03:57]  * StevenK is unsure
[03:57] <ScottK> StevenK: If you want to get it sorted I'll be glad to help.  Here or on #ubuntu-server (where help is in fact on topic).
[03:59] <StevenK> ScottK: I think I need to sort out two things -- 1) Does my SASL setup work, and 2) Does Postfix then work, since it looks to be configured correctly
[04:00] <ScottK> What do the logs say?
[04:02]  * StevenK tries to remember how to speak SMTP AUTH
[04:04] <ScottK> If you're doing it by hand you'll have to speak TLS too if you're set up correctly.
[04:05] <StevenK> I just turned off TLS so I don't have to speak that bit.
[04:08] <StevenK> Ack. Can't remember enough about how to speak it.
[04:09]  * ScottK neither.  I usually just use an MUA and read logs to figure out what I forgot (for me it's usually forgot to copy the update sasldb into the chroot - won't be your problem if you're using the documented approach)
[04:11] <ScottK> If someone's got a minute, I'd appreciate a look at http://launchpadlibrarian.net/12048829/buildlog_ubuntu-hardy-i386.kdebase_4%3A3.5.9-0ubuntu1_FAILEDTOBUILD.txt.gz - it's claiming dependencies that I'm pretty sure should be available weren't.
[04:14] <nixternal> ScottK: I think there is a repo issue
[04:15] <ScottK> nixternal: Do you know if someone is working on it?
[04:15] <nixternal> don't know...myself and superm1 are having the same exact problem
[04:15] <nixternal> because graphviz is fine, I just installed it here
[04:15]  * ScottK too.
[04:15] <superm1> it was reported in #launchpad yesterday by Fujitsu
[04:16] <superm1> and cprov said that its probably further in the mirroring mechanics
[04:16] <ScottK> OK
[04:16] <nixternal> ya, if I do 'sudo apt-get update' it flies through, and I know there are a couple of updates available
[04:18] <ScottK> nixternal: lifeless figured it out.  libgraphiz4 is in Universe.
[04:18] <ScottK> Or however you spell it.
[04:18] <StevenK> And there's the smoking gun.
[04:18] <nixternal> you were close, forgot the v :)
[04:19] <nixternal> ScottK: but why would it be a problem now, and never was a problem before?
[04:19] <nixternal> is the universe repos bunked up or something?
[04:20] <StevenK> nixternal: Because kdebase is in main ...
[04:20]  * StevenK goes to take something for his headache
[04:20] <ScottK> nixternal: My guess is a soname jump when graphviz 2.16 was uploaded on 2/7 and the new lib version got left in Universe by mistake.
[04:21] <nixternal> ahhhh
[04:21] <ScottK> Maybe slangase` is still present and up for a little archive admin work so we can build it.
[04:22] <nixternal> hehe
[05:23] <Hobbsee> boo
[05:24] <blistov> hey, why is the ubuntu livecd automatically killing all my mbrs from every disk it finds, on boot?
[05:26] <blistov> I put in the cd, booted off it, the framebuffer never loaded correctly, waited 5 minutes till i was sure nothing was going on, tried again in safe mode (i assumed that wouldn't use a splash, no change, took the cd out, rebooted, and of my the mbr's from both raids, and my one single drive, were all wiped out.
[05:26] <blistov> i booted off a backup usb drive, put grub back in the mbr to all disks, reboot, everything works again. boot the ubuntu cd, and once again, the mbr's all die.
[05:27] <blistov> any ideas on this? is ubuntu cleverly installing something to the mbr of every disk it see's?
[05:31] <TheMuso> blistov: Which live CD?
[05:31] <TheMuso> blistov: Is it a hardy daily image?
[05:32] <blistov> ubuntu-7.10-desktop-amd64.iso
[05:33] <blistov> I hate to bitch, especially to the devs, and more especially, when i'm not even part of the ubuntu community, but it seems like every time I try a ubuntu livecd, it results in something being deleted, formatted, repartitioned, or broken in general, without input from me, and i can't very well stop it because the live disks always use fbsplash, which i've never seen work on any recent hardware.
[05:34] <blistov> I can't imagine my experience is the majority, as there is a huge userbase.
[05:35] <blistov> I keep thinking of moving away from Gentoo because of the idiot politics with communtication between userland and dev, but I run into major limitations in every other direction (ie, the live disk wipes out my mbr's without my knowledge.)
[05:35] <blistov> Am I running an unstable/untested version of the livecd?
[05:37] <StevenK> blistov: That filename indicates that it's the released version. I've never seen a Live CD touch the MBR of another disk like that, either.
[05:39] <blistov> Ok. Well... It did, and does.  I'm not sure why.  I don't know if anyone is interested in the Ubuntu community.
[05:39] <blistov> Is there any known weirdness with geforce 8800 cards and fb/gensplash?
[05:39] <mjg59> We don't use fbsplash or gensplash
[05:39] <blistov> What's used?
[05:40] <mjg59> But there is an issue with x86emu and recent nvidia BIOSes
[05:40] <mjg59> I need to find some time to work on that
[05:40] <mjg59> usplash
[05:40] <blistov> But no one's ever heard of the livecd arbitrarily wiping out mbrs?
[05:40] <mjg59> Nope
[05:40] <mjg59> If it's reproducable, it's certainly concerning
[05:41] <mjg59> But there's no code that touches the hard drives until you hit the installer, and that's not autostarted
[05:41] <mjg59> So there's no obvious reason for it to be happening
[05:41] <mjg59> Which makes it weird and awkward to diagnose
[05:41] <blistov> k. well its possible (not plausible though) that i accidentally and quite blindly started the install...
[05:42] <blistov> any idea why the video never comes up?
[05:42] <mjg59> Yeah, that's also weird
[05:42] <mjg59> The lack of splash is easy enough to explain, but X ought to start eventually
[05:42] <blistov> I left it for 5 minutes exactly.
[05:42] <mjg59> I'm relatively sure that you can encourage the livecd to start without a splash
[05:42] <mjg59> One of the F keys should give you a dialog that lets you edit the boot options - delete quiet and splash from there
[05:43] <blistov> Is there any chance on a  6.8Ghz machine with 2GB of 1Ghz ram, would take longer than 5 mintues to start x?
[05:43] <blistov> mjg59: i did that.
[05:43] <mjg59> And no text output at all?
[05:43] <mjg59> You should at least get the kernel startup output
[05:43] <blistov> no, i got a console, but it almost immediately failed to mount vfs
[05:43] <mjg59> Uh.
[05:43] <mjg59> Right.
[05:43] <mjg59> Something is very horribly wrong.
[05:44] <blistov> took about 5 seconds till it paniced
[05:44] <mjg59> Yeah
[05:44] <mjg59> Are you able to scroll the output with shift+pgup?
[05:44] <blistov> buuuut, when i leave the splash on, it runs and does stuff for about a full minute before the hd's stop and cpu stops doing anything (external cpu monitor)
[05:44] <blistov> not able to scroll.
[05:44] <blistov> said something about hd8,0 vfs
[05:45] <mjg59> Sigh. Sometimes the kernel is mean.
[05:46] <blistov> Hrm.  Any suggestions?  I'm getting fed up with the Gentoo devs, so I do need to start looking at an alternative.  In the past, I've been turned off by Ubuntu simply because it wasn't as easily scalable in the long term, but I've heard that's changed.
[05:46] <mjg59> Nope, no suggestions
[05:46] <mjg59> (Sorry, it's past midnight here - I'm not necessarily as sharp as I could be
[05:46] <mjg59> )
[05:46] <TheMuso> blistov: Have you tried an alternate CD?
[05:47] <mjg59> In fact, I really need to hit bed now
[05:51] <blistov> heh, i'll give the alt a try.
[05:51] <blistov> thanks
[05:53] <blistov> any chance some of the weirdness could be caused by my bios initially forcing the tertiary sata controller to present itself as primary for the purpose of bringing up grub ?
[05:53] <dholbach> good morning
[05:54] <ion_> good evening
[05:54] <blistov> wait, any chance the x86 build doesn't run at all on a 64bit cpu?
[05:55] <TheMuso> blistov: No idea at this stage sorry, have you tried updating your BIOS?
[05:55] <blistov> (i can't imagine why..)
[05:55] <blistov> Bios is up to date.
[05:55] <TheMuso> blistov: The i386 build shoudl work fine.
[05:55] <blistov> Meh, I'll try alternate.
[05:55] <blistov> Thanks guys.
[05:55] <TheMuso> blistov: np, good luck.
[06:09] <pitti> Good morning
[06:10] <pitti> thegodfather: mythplugins> looking
[06:11] <thegodfather> pitti: just read a few lines more in the scrollback
[06:11] <thegodfather> pitti: it seems to be a known problem with the mirroring
[06:12] <pitti> thegodfather: on drescher it looks good, can't check LP until my dist-upgrading is done and ff works again
[06:12] <pitti> thegodfather: on, I see
[06:12] <thegodfather> but it's still broken.. that's for sure
[06:14] <pitti> thegodfather: didn't see anything truly enlightening in scrollback; that's something for IS, I think
[06:14] <pitti> thegodfather: drescher-wise it's fine, and that's where my powers end
[06:16] <thegodfather> pitti: yes i know. thanks for checking. I thought in the beginning it was a publisher issue...
[06:16] <thegodfather> we will need to check with elmo and cprov when they are around
[06:22] <pitti> Riddell: did you see the last comment in bug 184149? that worried me a bit
[06:22] <ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
[06:32] <slangasek> lamont: 64-bit implicit-ptr conversions: fatal on which archs?
[06:57] <warp10> Good morning
[07:04] <pitti> hi warp10
[07:05] <warp10> Hey pitti
[07:43] <thegodfather> superm1: ping? :)
[07:44] <thegodfather> slangasek: i assume ia64 and others :)
[07:48] <slangasek> thegodfather: the "and others" that would be relevant here is amd64...
[07:49] <thegodfather> slangasek: probably... :)
[08:02] <mdke> hiya dholbach
[08:05] <poolie> i'm working on bzr packaging
[08:06] <poolie> and am getting an error from pdebuild if i have a build-depend that in turn depends on a virtual package
[08:06] <poolie> in this paces
[08:06] <poolie> case
[08:06] <poolie> The following packages have unmet dependencies:
[08:06] <poolie>   graphviz: Depends: libgraphviz4 (>= 2.16) which is a virtual package.
[08:06] <poolie> Resolving dependencies...
[08:06] <poolie> removing that lets it pass
[08:07] <slangasek> poolie: libgraphviz4 was stuffed in universe by mistake; fixed in next publisher run
[08:07] <poolie> oh i see
[08:08] <poolie> so, i should just go ahead and upload with that dependency to our ppa, and it'll come out in the wash?
[08:09] <slangasek> well, I don't know how often ppa failed builds are retried; for guaranteed results you may want to wait a couple of hours
[08:09] <poolie> ok
[08:09] <poolie> but, basically, not my fault
[08:09] <slangasek> yah
[08:12] <mdke> dholbach: thanks a lot for those uploads
[08:13] <dholbach> mdke: no problem
[08:14] <mdke> dholbach: were there any major problems with ubuntu-docs?
[08:14] <dholbach> I just added myriads of (LP: #xxxxxxx) entries
[08:14] <dholbach> mdke: I'll attach the diff
[08:15] <mdke> :) thanks for that. I was thinking about it but didn't know how to include more than one of those entries. Now I see they are comma separated, I'll do it in the future
[08:16] <dholbach> no problem
[08:16] <dholbach> mdke: attached
[08:18] <mdke> mmm, lots of closed bugs :)
[08:20] <dholbach> :)
[08:52] <slytherin> Is anyone already working on evolution build failures?
[08:58] <lool> slytherin: bug id?
[08:59] <slytherin> lool: I am looking for bug. I was checking build logs and see FTBFS for everything except powerpc. And surprisingly it doesn't let me upgrade on powerpc due to some version conflicts.
[08:59] <seb128> slytherin: looking
[08:59] <seb128> it just needs a retry
[09:00] <seb128> pitti: can you give a retry to evolution?
[09:00] <pitti> seb128: done
[09:00] <seb128> danke
[09:00]  * seb128 hugs pitti
[09:00] <seb128> pitti: hey btw, had a good week end? ;-)
[09:00] <slytherin> seb128: That is waht I thought. But I am trying to build locally just to make sure
[09:01] <seb128> slytherin: upstream should learn to update the evolution-data-server configure requirements
[09:02] <pitti> seb128: yes, it was wonderful; we celebrated our 7th anniversary and our 0.5th wedding anniversary :)
[09:02] <pitti> (same day)
[09:02] <pitti> seb128: brunch at the Sarrasani circus/variete
[09:02] <seb128> ah, nice ;-)
[09:08] <poolie> hello europe
[09:09] <poolie> i'm trying to build a bzr backport using pbuild
[09:09] <pitti> hi poolie
[09:09] <poolie> pbuild
[09:09] <poolie> pbuild returns 0 and doesn't give an obvious error, but doesn't give me a deb either :-/
[09:09] <poolie> any clues?
[09:09] <pitti> poolie: you did look in /var/cache/pbuilder/result?
[09:10] <pitti> it's not there?
[09:10] <pitti> (that's where pbuilder puts them by default at least)
[09:10] <pitti> I don't know the pbuild script, sounds like a wrapper
[09:10] <poolie> huh
[09:10] <poolie> yes, it's there
[09:10]  * pitti just knows "pbuilder build" and "pdebuild"
[09:10] <poolie> sorry, i meant pbuilder --build
[09:11] <poolie> so there's a deb in /var/cache/pbuilder/result
[09:11] <poolie> but i thought previously it was copying them back to the directory above my source directory
[09:11] <poolie> was i confused before?
[09:11]  * slytherin declares pbuild as new acronym for 'pbuilder --build' :-)
[09:12] <Fujitsu> poolie: I don't believe pbuilder ever does that, though sane builders like sbuild do.
[09:12] <poolie> ok
[09:12] <poolie> should i be using sbuild insteadL
[09:12] <poolie> ?
[09:12] <pitti> poolie: maybe pdebuild does that, but I haven't used it much (usually I want to build a .dsc, not an unpacked source)
[09:12] <slytherin> poolie: pbuilder doesn't do that. But if you build packages using dpkg-buildpackage -b the you will get the deb where you are looking right now
[09:12] <poolie> i probably saw a file produced by another command, maybe pdebuild
[09:13] <poolie> there are certainly a lot of different tools
[09:13] <poolie> i'm basically just trying to run it here as a dry run for a PPA upload
[09:14] <poolie> to get a result with less delay
[09:14] <Fujitsu> You should always do that anyway, rather than uploading builds that you don't know to work...
[09:15] <poolie> ok
[09:16] <poolie> so what's the best way to test that something will build on say dapper?
[09:16] <poolie> i agree that it's a good practice
[09:16] <poolie> both wrt launchpad cpu resources, and also latency of waiting for the rebuild
[09:17] <Fujitsu> One can use the pbuilder-dist script to use pbuilder for multiple releases, but I use sbuild with a chroot for each release.
[09:20] <poolie> so sbuild is an alternative to pbuilder, rather than built on top of it?
[09:21] <TheMuso> poolie: Yes, but its a little more involved to set up.
[09:22] <soren> If you use kees' mk-sbuild-lv.sh from ubuntu-dev-tools, it's quite trivial.
[09:22] <soren> ..assuming you already have lvm set up.
[09:24] <geser> good morning
[09:28] <slytherin> seb128: evolution built locally. It was really just a matter of retry. :-)
[09:28] <seb128> slytherin: I didn't doubt it, I built it myself before uploading
[09:29] <slytherin> No will have to check whether it updates properly on my ibook
[09:34] <geser> pitti: Hi, can you move libxstream-java from universe to multiverse please. It build-depends on sun-java6-jdk.
[09:40] <cjwatson> thegodfather: mirroring brokenness is (ultimately) my fault, so don't bug cprov about it please; I'll work on it
[09:42] <pitti> mvo: any idea why bash autocompletion for apt-get stopped working?
[09:45] <mvo> pitti: no
[09:46] <mvo> pitti: did it maybe moved to the bash-completion package or something?
[09:47] <pitti> no idea, I just noticed it
[09:47] <pitti> (while cleaning up the old kernels)
[09:47] <pitti> geser: will do as soon as my ssh gets unbroken ((#*$# ISP)
[09:47] <geser> I see libgraphviz4 got moved from universe to main today. Could an archive admin please also move libgraphviz-dev too? graphviz-dev (main) depends on it and imagemagick is in depwait on it. Thanks
[09:48] <pitti> how come that this is something new?
[09:48] <Chipzz> while on the topic of bash-completion; could that file please be split up in smaller files?
[09:48] <Chipzz> it is a very real performance hit on starting a terminal and such
[09:49] <pitti> geser: oh, it was graphviz-dev before, I see
[09:49] <mvo> pitti: slangasek mentioned libgraphviz got accidentely moved to universe I think
[09:49] <thegodfather> cjwatson: ok, i didn't even ping him tbh as i was told he already knew
[09:51] <Chipzz> heh
[09:51] <Chipzz> doko is not on IRC anymore?
[09:52] <Chipzz> !seen doko
[09:52] <ubotu> Sorry, I don't know anything about seen doko - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[09:52] <Chipzz> meh
[09:52]  * Chipzz kicks ubotu :P
[09:53] <Chipzz> anyway
[09:53] <Chipzz> since bash-completion got split out of bash
[09:54] <Chipzz> I think it would be a better idea to split the script in small pieces and ship those pieces with the relevant packages
[09:54] <Chipzz> how does that sound?
[09:57] <Chipzz> mvo: would that be possible for apt for example?
[09:59] <jpatrick> Chipzz: /msg SeenServ seen doko
[09:59] <mvo> Chipzz: sure
[09:59] <cjwatson> some packages do that already. Looking at e.g. the ssh completion, the main obvious problem for me in shipping that separately is that it's not a trivial chunk of code to copy and paste, and it would require me to take on maintenance of it; as soon as I copy it then we lose out on the benefits of the work done by bash-completion upstream.
[09:59] <Chipzz> cjwatson: bash-completion is unmaintained upstream
[10:00] <cjwatson> that's an accident and might well not always be the case
[10:00] <Chipzz> cjwatson: says both on https://launchpad.net/ubuntu/+source/bash-completion, and the last update on the homepage is a long time ago
[10:00] <tjaalton> let's switch to zsh \o/ :)
[10:01] <Chipzz> cjwatson: the problem is the delay from having bash_completion enabled in .bashrc is very noticable; ie over 1 second delay when starting a terminal
[10:01] <cjwatson> zsh is an interesting thing to mention. It also ships a lot of completion. How many shells should packages ship completion for?
[10:01] <cjwatson> one? two? 300?
[10:02] <cjwatson> it's not entirely obvious whether it belongs in a shell-specific package or in a feature-specific package, is my point
[10:02] <Chipzz> point taken
[10:02] <Chipzz> but
[10:02] <Chipzz> I don't think there's that many shells to start with, and even less that support completion?
[10:03] <cjwatson> sure, but I certainly couldn't maintain zsh completion rules because I don't speak zsh
[10:03] <Chipzz> dash/ksh variants/etc all don't even support completion at all
[10:03] <cjwatson> so even right now it is impossible for me to cater in the same way for all shells supporting completion
[10:03] <cjwatson> the shell maintainers will do a better job
[10:03] <tjaalton> zsh upstream maintains all the completions
[10:04] <Chipzz> cjwatson: but I guess my reply to that is: zsh completion is optional; if it's already written, integrate in your package; if it isn't, accept patches that do implement it
[10:05] <cjwatson> on the performance hit, I would suggest simply disabling it, and sourcing it when you need it
[10:05] <Chipzz> that way you wouldn't have a feature regression
[10:05] <cjwatson> that's what I do
[10:05] <cjwatson> and doesn't seem significantly more complex than sourcing a bunch of different files whose names are likely to change over time, etc., etc., tedium
[10:05] <Chipzz> well the thing is that there is some functionality of bash_completion that I use on a daily basis
[10:05] <Chipzz> and
[10:05] <cjwatson> please don't do that thing with putting conjunctions on a single line of IRC
[10:06] <Chipzz> . /etc/bash_completion doesn't complete very nicely
[10:06] <cjwatson> well, it's in /etc, you *could* just strip out the stuff you don't want :-)
[10:07] <Chipzz> maybe we could consider splitting out the most often used parts of it
[10:07] <Chipzz> altough it wouldn't be immediately obvious what those parts are or how that's going to benefit
[10:08] <Chipzz> for me the most often used functionality is ssh completion and apt/dpkg completion
[10:11] <Chipzz> cjwatson: as a reference point, last upstream update was 20060301, which is almost 2 years old
[10:12] <lool> cjwatson: I filed bugs against quilt, dpatch and cdbs to use touch --date or similar to set the timestamp as dpkg-source does
[10:12] <Chipzz> http://www.caliban.org/bash/#completion_download
[10:12] <lool> I was surprized to not find any bug on this subject on all three packages
[10:12] <cjwatson> lool: cool, thanks
[10:13] <lool> cjwatson: Thanks for the idea; I didn't know dpkg-source was clever
[10:13] <cjwatson> lool: it hadn't occurred to me that they would have the same problem, though it's obvious in retrospect
[10:13] <lool> First I suspected it had a broken trick such as sorting files or so
[10:14] <ogra> cjwatson, is there *any* documentation of gfxboot somewhere (beyond teh code) ? i tried to wrap my head around it on the weekend but failed (actually i wanted to have a patch for an LTSP entry in the modes menu ready for you)
[10:14] <ogra> (and the basic knowledge to get the addon welcome screen going)
[10:15] <cjwatson> ogra: there's language-evel documentation in gfxboot/doc/ (you have to build it), but otherwise no
[10:15] <cjwatson> language-level
[10:15] <ogra> i'll look at that
[10:15] <ogra> it looks like it is using its own interpreter language
[10:15] <cjwatson> it will at least give you the minimum knowledge to decipher the language - unfortunately practical use requires building a bunch of stuff on top of the basic facilities
[10:15] <cjwatson> yes
[10:16] <cjwatson> it's a forth-like bytecode-compiled language
[10:16] <cjwatson> or postscript-like, if you prefer
[10:16] <ogra> ps is something i used before ... forth now really :)
[10:17] <ogra> s/now/not/
[10:17] <pitti> geser: both done (multiverse/main)
[10:17] <geser> pitti: thanks
[10:40] <Riddell> anyone know why graphviz was moved to universe?
[10:40] <pitti> Riddell: I just kicked the binaries back
[10:40] <pitti> wrong override apparenlty
[10:41] <Riddell> pitti: ok, could you give back kdelibs
[10:41] <pitti> done
[10:44] <geser> pitti: please also give-back: bzr doxygen. It FTBFS because graphviz wasn't installable. Thanks.
[10:45] <pitti> geser: done
[10:50] <lool> pitti: Do you know why Debian's sysvinit didn't merge "multiuser"?
[10:51] <pitti> lool: they changed sysvinit to respect the LSB headers
[10:51] <lool> (I'm seeing this in the dbus package and I guess it speeds up shutdown as we don't need to stop dbus
[10:51] <pitti> lool: but it's not enabled by default AFAIK
[10:51] <pitti> I think this is a better approach than our multiuser hack
[10:51] <lool> So we should stop using multiuser in ubuntu and simply list nothing in stop levels?
[10:51] <pitti> but nobody had time to work on that yet
[10:52] <pitti> lool: ideally yes, but the code doesn't respect it by default ATM
[10:52] <pitti> and we haven't merged sysvinit for ages
[10:52] <lool> The sysvinit one?
[10:52] <pitti> yes, because of upstart & co
[10:52] <lool> Do you know whether it's honored in Debian at least?
[10:52] <pitti> not 100% sure, but I think it's not enabled by defautl
[10:52] <lool> Anyway, doesn't hurt to list nothing in stop-levels
[10:53] <pitti> right
[10:54] <lool> pitti: (thanks!)
[10:54] <geser> pitti: did the give-back of bzr succeed? because https://edge.launchpad.net/ubuntu/hardy/+source/bzr/+builds shows no sign of a new build attempt
[10:55] <pitti> I wasn't asked to give it back
[10:55] <pitti> done now
[10:55] <geser> pitti: [11:44:56]        geser | pitti: please also give-back: bzr doxygen.
[10:55] <pitti> geser: oh, that slipped my mind, sorry
[10:56] <geser> np
[11:12] <pitti> seb128: is it safe to restart the i386 retracer?
[11:12] <seb128> pitti: if it doesn't crash yes
[11:12] <seb128> pitti: it has not been stopped on purpose, it's just crashing
[11:12] <seb128> pitti: did you figure what was wrong?
[11:12] <pitti> ValueError: Unsupported attachment-type '<type 'set'>'
[11:12] <seb128> yes, that one
[11:12] <pitti> seb128: no, I haven't looked into it at all
[11:13] <pitti> first time I see it
[11:13] <seb128> I told you about it some days ago
[11:13] <pitti> thekorn, any idea?
[11:13] <pitti> seb128: yes, that it's stopped and that you asked thekorn about it
[11:13] <seb128> pitti: https://bugs.edge.launchpad.net/python-launchpad-bugs/+bug/191963
[11:13] <ubotu> Launchpad bug 191963 in python-launchpad-bugs "ValueError: Unsupported attachment-type '<type 'set'>' " [Undecided,In progress]
[11:13] <pitti> seb128: Friday was too crazy to look into it, sorry
[11:14] <seb128> pitti: that's alright, thekorn said he doesn't got the issue and that he would try on a dapper vm later
[11:14] <seb128> pitti: maybe untag the bug which makes it crashing for now and restart?
[11:14] <pitti> ah, thanks for the bug #; subscribed
[11:14] <pitti> yep
[11:14] <seb128> pitti: you are welcome ;-)
[11:19] <thekorn> seb128, pitti , sorry forgot to mention, I can not reproduce this error in a dapper vm
[11:20] <seb128> thekorn: hum, ok, thanks
[11:26] <geser> thekorn: is there an other way to specify the cookie python-lp-bugs should use instead of "exporting" the lp cookie with a small script from cookies.sqlite (Firefox 3) and writing it into a file?
[11:27] <geser> or is the old cookies.txt format the only one supported by python-lp-bugs?
[11:28] <thekorn> geser: I'm working on a solution for the .sqlite format, but in the hardy version of py-lp-bugs you can also use:
[11:28] <thekorn> Bug.authentication = {"password":<password>,"email":<email>}
[11:28] <thekorn> geser, where password and email are you login data in LP
[11:30] <geser> good to know
[11:36] <davmor2> How's Alpha 5 shaping up, is it ready to test?
[11:41] <cjwatson> davmor2: seems a bit early yet
[11:42] <cjwatson> davmor2: a few bits of the archive and CD processes are busted at the moment so probably not very
[11:42] <davmor2> cjwatson: np's just queried as there had been no daily updates so thought it might be safe to test.
[11:43] <cjwatson> davmor2: that's due to the archive bustedness :-)
[11:43] <cjwatson> there have been updates, they just aren't getting mirrored out ...
[11:43] <davmor2> ahhh
[11:45] <ogra> pitti, about the classamate-settings package, i can drop the user parts (can go to the installer script) as well as the firefox cache disabling (can go into an initramfs bottom script) ... but i cant drop the static xorg.conf since i have to a) force a driver we dont detect for that card and b) need to have a virtual screenwhich we dont support at all in the default configurator in any case
[11:46] <ogra> *screenwidth
[11:46] <pitti> ogra: why does it have to be a package at all? this seems to unfitting
[11:46] <ogra> pitti, would the package be ok with you with tehse changes ?
[11:47] <davmor2> is it possible to get f-spot to change backends for burning or not does anyone know?
[11:47] <pitti> breaking X.org's configuration file is still bad IMHO
[11:47] <ogra> pitti, we will always need to ship a static one for classmate
[11:47] <pitti> seb128_: retracer is running again for now
[11:48] <pitti> ogra: we can't fix the X.org detection to properly treat the classmate?
[11:48] <ogra> pitti, we have an agreement that we will support screen panning thast something we (and upsteam) just weeded out completely from the config ools
[11:48] <pitti> that will improve it for similar hardware, too
[11:48] <ogra> detection is only one part of it
[11:48] <pitti> ogra: ok, I see
[11:48] <ogra> and we cant do any detection mechanisms during bot anyway
[11:48] <pitti> well, why not make it part of the install script then?
[11:49] <ogra> (i.e. like the livecd does)
[11:49] <pitti> meh, retracer already failed again
[11:49] <ogra> pitti, it will even get more tricky as we probably have to support two diaply variants ... both dont return any EDID data
[11:49] <ogra> *display
[11:50] <ogra> (its not clear yet if we need to support both for hardy final though, but if thats the case i need t even supply two static files that are used alternating depending on the HW it runs on
[11:50] <ogra> )
[11:51] <MacSlow> asac, is a corrupt language-support-writing-en package perhaps moe more issue due to firefox3? I just ran into that.
[11:52] <pitti> MacSlow: that got fixed this morning
[11:53] <MacSlow> pitti, but why does it show up for me then still? New/fixed packages not yet fully exposed via the repos?
[11:53] <pitti> MacSlow: might not yet be published
[11:53] <ogra> MacSlow, btw cairo-dock rules the world on the classmate :) i tried a setup with cairo-dock, pcmanfm an metacity with composite enabled yesterday ... its the fastest and most responsive desktop setup i've tried so far :) (things like awn just eat your ressourcesm, cairo-dock seems to not do that by some reason)
[11:53] <seb128_> pitti: cool, did you workaround the bug or just untagged the bug?
[11:53] <pitti> seb128_: just untagged; but as I said above it already failed again on a different bug
[11:54] <pitti> and if my ssh ever comes back, I could actually report it and untag/restart
[11:54] <ogra> MacSlow, is there a roadmap anywhere for it ?
[11:54] <seb128_> pitti: you likely commented when my dsl disconnected
[11:54] <seb128_> ok
[11:55] <MacSlow> ogra, well I don't know how much of the original approach the french folks, who picked it up changed... but back when I started it, I made sure to stick to best practises regarding cairo-usage
[11:55] <pitti> thekorn: FYI, bug 192892
[11:55] <ubotu> Launchpad bug 192892 in python-launchpad-bugs "TypeError: argument 2 to map() must support iteration" [Undecided,New] https://launchpad.net/bugs/192892
[11:55] <pitti> seb128_: ^
[11:55] <pitti> MacSlow: right, not published yet; fixed in version 8.04+20080218
[11:56] <ogra> yeah. its incredibly "non stuttering" on that HW ... all the others do their autohide "in several steps" :)
[11:56] <MacSlow> ogra, maybe... I never wanted to do more than experimenting with cairo, when I started cairo-dock... I'm actually surprised that it stayed "alive"
[11:56] <MacSlow> pitti, ok
[11:56] <ogra> well, compared to AWN or that wxwindows based one its just a ton better
[11:57] <MacSlow> ogra, I cannot really remember if I did add image/xlib/glitz-surface support in cairo-dock, like I did for some other cairo-things I wrote... that would allow the user to choose the best available option for rendering (acceleration)
[11:58] <ogra> it depends on glitz so i think you used glitz functions there
[11:58] <ogra> not sure it does that b default
[11:59] <MacSlow> ogra atm it is expected to get best results form using cairo's xlib-surfaces (which would benefit from EXA... if the xorg-driver is properly written/complete)
[11:59] <ogra> well, anyway, we should look into that for a lowend desktop variant in hardy+1 :)
[12:00] <pochu> pitti: did you get libcrypto++ out of NEW? It's already available in archive.u.c for amd64 and ppc, but missing for the rest. (bug #189243)
[12:00] <ubotu> Launchpad bug 189243 in libcrypto++ "please sync libcrypto++ 5.5.2-1 from Debian testing" [Wishlist,Fix released] https://launchpad.net/bugs/189243
[12:00] <ogra> i'd like to get away from gnome for the classmate if we have to do more images for that ... its just to heavyweight
[12:00] <ogra> and i guess such a desktop would help with the other subnotebooks as well ...
[12:01] <geser> pochu: a.u.c is out-of-date since Friday
[12:03] <pochu> geser: oh, that would explain it.
[12:03] <pochu> pitti: ^-- nevermind. thanks anyway
[12:04] <pitti> ok
[12:05] <mdz> what's the difference between ~/.Trash and ~/.local/share/Trash?
[12:05] <mdz> I have files in both
[12:06] <pochu> geser: I assume there's someone working on it? :)
[12:06] <pochu> mdz: the latter is the new one in gio. I thought there was a migration path
[12:06] <pochu> the latter is fdo compliant
[12:06] <mdz> if so, it doesn't seem to have worked for me.  on my desktop, I have files in both places.  on my laptop, all my trash is in ~/.Trash, but the trashapplet only looks at the other one
[12:07] <geser> pochu: afaik cjwatson_ is working on it
[12:11] <pochu> mdz: there's http://bugzilla.gnome.org/show_bug.cgi?id=509759. Perhaps I was wrong with the migration path
[12:11] <ubotu> Gnome bug 509759 in trash applet "Migrate from GnomeVFS to GIO" [Major,Resolved: fixed]
[12:15] <cjwatson> geser,pochu: yes, I am, amid other things
[12:17] <davmor2> cjwatson: can you change the burning backend of f-spot to use gvfs if so how?
[12:17] <cjwatson> davmor2: I have no idea, and am not quite sure why you're asking me :)
[12:17] <ogra> heh
[12:17] <ogra> davmor2, thats rather a question for one of our gnome guys
[12:18] <seb128_> mdz: .Trash is the old gnome-vfs location, .local/share/Trash is the new gvfs freedesktop one
[12:18] <davmor2> sorry just thought I'd ask
[12:19] <seb128_> mdz: upstream will add some code to migrate .Trash to the new location, likely to gnome-session, that has not been done yet though
[12:19] <cjwatson> I don't mind being asked, but you'd have a better hit rate from picking somebody who works on the package in question
[12:20] <davmor2> np's I've written a bug report for it anyway just wondered if anyone knew.  It's still using gnome-vfs by default.
[12:28] <seb128_> davmor2: gnome-vfs doesn't do burning, I don't know the f-spot code though
[12:29] <pitti> yay, I think I fixed the p-lp-bug
[12:32]  * thekorn hugs pitti!!
[12:33] <pitti> thekorn: I dumped it all into the bug report, including a patch
[12:33] <thekorn> pitti, reading it
[12:41] <davmor2> seb128_: bug 192510
[12:41] <ubotu> Launchpad bug 192510 in f-spot "F-spot still depends on gnome-vfs to burn cds and fails" [High,Triaged] https://launchpad.net/bugs/192510
[12:42] <davmor2> seb128_: there is a screenshot attached of the bug I get
[12:45] <Riddell> pitti: mega giveback if you could.  kdebase kdeaccessibility kdeadmin kdebindings kdeedu kdegames kdegraphics kdemultimedia kdenetwork kdepim kdesdk kdetoys kdeutils kdewebdev kdevelop
[12:58] <MacSlow> bryce, didn't the patch for fixing the drop-shadow-decoration rendering under EXA (intel, i965) work?
[13:18] <pitti> re
[13:19] <pitti> Riddell: done
[13:21] <Riddell> thanks
[13:25] <pitti> hmm, just started current live CD
[13:26] <pitti> what's the difference between "Try Ubuntu without any changes" and "Install Ubuntu"? Shouldn't both be a live system with ubiquity?
[13:26] <mjg59> pitti: The latter just starts the installer, not a GNOME session?
[13:27] <pitti> Possibly; haven't tried it yet
[13:27] <cjwatson> mjg59 is correct
[13:27] <cjwatson> cf. hardy-bootloader-review
[13:33] <ogra> seb128_, where do we hide the ssh connection options for nautilus nowadays ? i just searched my ass off but seem to be to blind to find it
[13:34] <seb128_> ogra: what ssh options?
[13:34] <ogra> it was called "connect to server" once and created a folder with the connection transparently on the desktop
[13:35] <seb128_> ah, no
[13:35] <ogra> seems that whole thing has vaished
[13:35] <ogra> *vanished
[13:35] <seb128_> the thing is that gnome-vfs didn't have persistent mount, it was just using the URIs
[13:35] <seb128_> those were a workaround to sort of "bookmark" the connection for easy use
[13:35] <seb128_> the new gvfs stack mounts thing on first access and they stay mounted for the session
[13:35] <seb128_> so that's not required
[13:35] <ogra> well, i cant create the connection first place
[13:36] <seb128_> the first time you access it in nautilus it'll be mounted and be listed in all applications
[13:36] <ogra> since we dont have the UI bits anymore
[13:36] <seb128_> just type the ssh url in nautilus
[13:36] <ogra> ah, k
[13:36] <seb128_> you can add standard bookmarks and use it too
[13:36] <seb128_> you are not the only one confused though
[13:36] <ogra> will we get a UI for final ?
[13:36] <seb128_> they will add a connect to serrver which creates bookmark before GNOME 2.22
[13:36] <seb128_> yes
[13:37] <ogra> (feels very KDEish to have to type urls in the filemanager :) )
[13:37] <ogra> ah, cool then
[13:39] <ogra> hmm, doesnt seem to want to connect
[13:40] <seb128_> what is the prompt you get using ssh on a command line?
[13:40] <seb128_> did you specify an user?
[13:41] <ogra> i tried both: ssh://ogra@rookery.ubuntu.com/ as well as the same with sftp protocol
[13:42] <seb128_> and without specifying an user?
[13:42] <ogra> hmm, wait a sec, seems not to work on cmdline
[13:47] <ogra> seb128_, hmm, it helps to have ~/.ssh/config in place :P ...
[13:48] <ogra> but beyond that it always only offers me to have a connetcion to / on my desk, seems the mount doesnt handle subdirs
[13:48] <seb128_> ogra: ;-)
[13:48] <ogra> so drag n drop like i had it before would end up in / on rookery if i dont open a browser win and navigate to the dir forst
[13:48] <seb128_> ogra: that's a mount, the same way than mounting a partition or a CDROM or an usbkey only mount the device and not subdirs
[13:49] <frafu> Hello doko, I wanted to let you know that Henrik and Luke have replied to your question in the mir process of mousetweaks: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
[13:49] <ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,Incomplete]
[13:49] <ogra> yeah, but te former variant offered me to have a shortcut on the desktop with the right dir directly selected
[13:49] <seb128_> ogra: use bookmarks
[13:49] <seb128_> what with wrong with adding the directory to your bookmarks?
[13:49] <ogra> apparently i cant drag a bookmark from the treeview to the desktop  ...
[13:50] <ogra> waht i used to use before (i.e. for screenshots) was a folder on the desktop that scp's to my public_html on drop ... tahst apparently not possible with te new way
[13:51] <ogra> ARGH
[13:51] <seb128_> ogra: not yet, those are lot of changes
[13:51] <ogra> and dragging from te places menu starts to copy / from rookery !!
[13:51] <ogra> (copying 3.9G)
[13:52] <seb128_> they are working fast a fixing regressions and issues don't worry it'll be in shape for hardy
[13:52] <ogra> good
[13:52] <ogra> would be odd if our users suddenly find the / of their servers everywhere *g*
[13:52] <MacSlow> seb128_, there's a debian/control and debian/control.in file in libwnck. Which sould I touch if I want to add a new build-/dependency? Just the debian/control.in I assume?!
[13:52] <ogra> thabnks for the hints, i'll live with what i have atm :)
[13:53] <ogra> ohh, the trayicon is sweet :)
[13:53] <pitti> thekorn: ah, thanks for the patch; that might explain other spurious bugs, too
[13:54] <ogra> so back to what i needed the scp for ...
[13:54] <ogra> asac, http://people.ubuntu.com/~ogra/firefox_weirdness.png
[13:55] <asac> ogra: known issue
[13:55] <asac> ogra: if you have a chance to use EXA ... that will fix it
[13:55] <ogra> k
[13:55] <asac> its a bug in XAA create picture implementation for REPEAT_NORMAL
[13:55] <ogra> i dont think my thin client has EXA capabilities
[13:56] <asac> nobody knows how to fix :)
[13:56] <seb128_> MacSlow: control.in
[13:56] <ogra> i can try to tweak xorg.conf though
[13:56] <asac> (well we have a patch for that for cairo ... but thats a workaround)
[13:56] <MacSlow> seb128_, ok, thanks
[13:56] <seb128_> MacSlow: it's copied over the control during the clean target
[13:56] <seb128_> you are welcome
[13:56] <seb128_> do you can "debuild clean" to update control
[13:56] <ogra> asac, ok, just wanted to show it in case its not known yet ... its funny that the url bar updates if i type in th real one :)
[13:57] <asac> seb128_: any news on fixing the issue that configure is run during clean for all gnome packages btw?
[13:57] <asac> (i bumped into that for seahorse today again)
[13:57] <seb128_> asac: is that bug discussed upstream? We got a libcairo debdiff from fta I think but I prefer to not apply workarounds if the issue is not being worked at the right place
[13:58] <seb128_> asac: no, it doesn't annoy me and I've other things on my todolist to do before looking at that ;-)
[13:59] <MacSlow> seb128_, would the "+git20080214" of "0.6.99+git20080214" belong to the version-number one has to state in "package (>= some.version.number)" in debian/control?
[13:59] <asac> seb128_: you have a bug id for fta patch?
[14:00] <asac> seb128_: upstream knows about it
[14:00] <seb128_> asac: bug #186186
[14:00] <ubotu> Launchpad bug 186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
[14:00] <seb128_> MacSlow: yes
[14:05] <asac> seb128_: commented
[14:07] <seb128_> asac: thanks
[14:38] <cjwatson_> ogra_cmpc: please excuse the zillion Edubuntu CD builds today - I'm using you as a test case
[14:39] <ogra> cjwatson, dont excuse :)
[14:39] <ogra> s/excuse/apologize/ :)
[14:42] <frafu> doko : ping
[15:13] <HighNo> are there gdebi developers available?
[15:13] <lamont> slangasek: if we deployed it, it would be on all archs (which would mostly mean that it failed on amd64/ia64)..
[15:13] <mvo> HighNo: yes
[15:14] <HighNo> My problem is a hand edited .deb file gets installed perfectly by dpkg but get rejected as being unreadable or corrupt by gdebi
[15:14] <mvo> HighNo: I see, could you please file a bugreport with the deb attached ?
[15:15] <HighNo> mvo - ok, will do
[15:23] <HighNo> mvo: created as https://bugs.launchpad.net/gdebi/+bug/192939
[15:23] <ubotu> Launchpad bug 192939 in gdebi "gdebi rejects a package that dpkg does accept" [Undecided,New]
[15:23] <HighNo> mvo: ah - forgot to say I am running feisty
[15:35] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek about to start in 25 minutes in #ubuntu-classroom
[16:24] <mruiz> hi all . I tried to install five-a-day but it complained:   five-a-day: Depends: python-central (>= 0.5.50) but 0.5.15ubuntu3 is to be installed
[16:32] <lool> dholbach: ^^^
[16:33] <dholbach> lool: python-central has built on the buildd, but it's not published yet it seems
[16:33] <lool> Aha
[16:33] <lool> nm then, sorry for the useless ping
[16:33] <dholbach> but it's since a few hours already
[16:33] <dholbach> I wonder if soyuz has a hiccup
[16:34] <dholbach> https://launchpad.net/ubuntu/+source/python-central/0.5.50ubuntu1
[16:38] <mruiz> thanks dholbach
[16:55] <soren> Has anyone tried the daily alternate installer lately?
[16:57] <ogra_cmpc> soren, friday the last time
[16:57] <soren> ogra_cmpc: And it worked, I suspect?
[16:57] <ogra_cmpc> yeah
[16:57] <soren> What are the memory requirements for the alternate installer?
[16:57] <ogra_cmpc> i just checked, it was the image from the 14th though
[16:58] <ogra_cmpc> i think something around 64M should work
[16:58] <soren> ogra_cmpc: Ok, that's not it, then.
[16:58] <ogra_cmpc> migth have increased though, i ddint test d-i in such small setups lately
[16:58] <soren> I'm reliably informed that it gets stuck during "saving language settings" if you run it inside kvm.
[16:59] <soren> Meh... I'll look into it.
[17:00] <mvo> soren: I did a netinstall at sunday
[17:01] <soren> mvo: That doesn't help much, I'm afraid. The server install works just fine, too.
[17:01] <soren> Don't worry about it just yet. I'll test it myself and do some digging.
[17:01] <slangasek> lamont: ok; I'm concerned there that, TTBOMK, the amd64 loader will rarely map libraries above the 32-bit mark, so it seems kinda late in the cycle to add a bunch of new RC bugs for an issue with no practical impact on the release archs
[17:02] <ogra_cmpc> soren, savaing language settings is the very end before grub-install starts i think
[17:02] <ogra_cmpc> might be the grub part locking up here
[17:02] <soren> ogra_cmpc: It could be, but isnt :)
[17:02] <soren> ogra_cmpc: Thanks for the hint, though.
[17:03] <ogra_cmpc> ah, no, it canht, the screen would have been cleared already if you are i n the next st4ep
[17:03] <ogra_cmpc> meh i need to train more on that keyboard again
[17:03] <soren> ogra_cmpc: Also, the syslog shows when each finish-install script is invoked, and it doesn't say anything after localechooser (afair)
[17:17] <mtaylor> um... why does ubuntu-minimal depend on alsa-base alsa-utils? Do I really need sound on a minimal system?
[17:18] <crimsun_> that point has been raised several times.
[17:19] <mtaylor> ok
[17:19] <mtaylor> any chance there's a ranting web page explaining the choice somewhere?
[17:19] <crimsun_> I don't know offhand.
[17:20] <Nafallo> crimsun_: what's your opinion on that one? :-)
[17:20] <Nafallo> just curious
[17:20] <crimsun_> it should be at most Recommends.
[17:21]  * mtaylor thinks that if we think sound is an integral part of the system, there should be an alternate ubuntu-server package one can install ...
[17:21] <Nafallo> yea. of standard :-)
[17:21] <mtaylor> Nafallo++
[17:21] <Nafallo> mtaylor: all servers are diverse and different. so I don't believe in a server seed
[17:22] <mtaylor> Nafallo: I don't really either...
[17:22] <emgent> heya thegodfather
[17:22] <mtaylor> Nafallo: I'm just saying that if minimal is going to stick desktop need in... I would like a server thing that doesn't have them
[17:22] <Nafallo> hehe
[17:31] <cjwatson> mtaylor: the reason we put that stuff in ubuntu-minimal is because alsa-* is needed for stability of hardware detection
[17:31] <mtaylor> cjwatson: wow. really?
[17:32] <cjwatson> mtaylor: all possible server profiles are by design supersets of minimal
[17:32] <cjwatson> we certainly won't be offering anything that's less than that
[17:32] <mtaylor> cjwatson: I would certainly expect them to be supersets of minimal
[17:32] <cjwatson> I would like to see stuff organised such that we didn't need alsa-* in minimal for stability though
[17:32] <mtaylor> I would agree.
[17:33] <mtaylor> I can understand their existence there for that reason - but I would suggest that it's a bug in hardware detection that that is the case
[17:33] <cjwatson> it's not as important as it used to be, actually
[17:33] <jwendell> asac, have you noticed that java plugin doesn't work with firefox 3?
[17:34] <cjwatson> it used to be that the installer was two-stage; after installing a minimal system, it rebooted to install everything else, and then dropped you into the final system without rebooting again
[17:34] <cjwatson> so, if stuff like alsa-base that provides /etc/modprobe.d files and alsa-utils that provides udev rules weren't installed in the first pass, your first boot would be different from all the rest
[17:35] <cjwatson> however, in dapper, we finally got the installer reorganised so that it could all operate in a single stage
[17:35] <cjwatson> so I think there is now a case for moving alsa-* to desktop
[17:36] <cjwatson> crimsun_: what do you think?
[17:36] <crimsun_> cjwatson: agreed.
[17:36] <asac> jwendell: which java plugin?
[17:36] <jwendell> asac, sun-java6, which doesn't even appear in about:plugins
[17:37] <jeromeg> asac: jwendell : there seems to be bugs about it
[17:37] <jeromeg> bug 192962 for example
[17:37] <ubotu> Launchpad bug 192962 in sun-java6 "sun-java6-plugin does not work in firefox3" [Undecided,New] https://launchpad.net/bugs/192962
[17:37] <jwendell> reported 11 minutes ago hehe
[17:38] <asac> jwendell: yes, the package post* scripts haven't been updated yet
[17:38] <ogra_cmpc> cjwatson, why not have an alsa-common that only ships modprobe.d files and udev rules ?
[17:38] <cjwatson> ogra_cmpc: no need, per the above
[17:39] <jwendell> asac, but the slinks seem to be ok... is there any other thing that needs to be done in order to make it work?
[17:39] <mtaylor> cjwatson: should I file a bug somewhere?
[17:39] <asac> jwendell: which slink?
[17:39] <mgunes> hi all. when submitting a debdiff for sponsorship by u-m-s should I keep the maintainer field intact and add myself to "Uploaders"?
[17:39] <cjwatson> mtaylor: no need, I'll just do it and send mail to ubuntu-devel for the record
[17:39] <mtaylor> cjwatson: great
[17:39] <jwendell> asac, /usr/lib/firefox/plugins/libjavaplugin.so -> /etc/alternatives/firefox-javaplugin.so
[17:40] <asac> jwendell: thats the old place. new place is /usr/lib/xulrunner-addons/plugins/
[17:40] <jwendell> hmmm
[17:40] <cjwatson> ogra_cmpc: do you have a specific concern about those files moving to desktop?
[17:40] <ogra_cmpc> cjwatson, nope
[17:40] <cjwatson> ok, good
[17:40] <crimsun_> mgunes: See https://wiki.ubuntu.com/DebianMaintainerField.
[17:40] <ogra_cmpc> i just saw your comment that the only reason were modprobe.d and udev
[17:41] <ogra_cmpc> and was wondering why we never solved it like that
[17:42] <cjwatson> ogra_cmpc: because this was put in place before the single-stage installer work, and we never revisited it afterwards
[17:42] <ogra_cmpc> quite a while :)
[17:42] <cjwatson> indeed :)
[17:42] <ogra_cmpc> but now that you point it out, i need to add it to the ltsp-client deps then :)
[17:42]  * ogra_cmpc notes down on whiteboard
[17:43] <mtaylor> also... while I'm being annoying, is there any reason why the ubuntu version of lintian in hardy needs to complain about invalid distro name for hardy and gutsy and stuff?
[17:43] <cjwatson> ogra_cmpc: *nod*
[17:43] <cjwatson> mtaylor: it only does that if the package's version number doesn't contain 'ubuntu'
[17:43] <cjwatson> it's a heuristic to try to avoid skew between Debian's lintian and Ubuntu's
[17:43] <jwendell> asac, thanks, plugin working now :)
[17:44] <mtaylor> cjwatson: any way we could get it to also search for gutsy or hardy, etc in the version number field?
[17:44] <mtaylor> sometimes having -1ubuntu1gutsy1 starts to get ridiculous
[17:44] <cjwatson> mtaylor: that sounds like unusual versioning
[17:44] <cjwatson> mtaylor: are these packages in the Ubuntu archive?
[17:44] <mtaylor> cjwatson: no
[17:44] <ogra_cmpc> that would be broken
[17:44] <cjwatson> mtaylor: ok, the reason we do this is because 'ubuntu' is actually magic in Ubuntu version numbers
[17:44] <cjwatson> mtaylor: it inhibits the autosyncer from syncing those packages from Debian
[17:44] <mtaylor> ah
[17:45] <MacSlow> pitti, any idea if de.archive.ubuntu.com is down? It's being unresponsive for me here.
[17:45] <cjwatson> mtaylor: but sure, I could make that change in Lintian upstream
[17:45] <cjwatson> though not sure if it'll make it into hardy
[17:45] <pitti> MacSlow: same for me
[17:45] <mtaylor> cjwatson: it's not _pressing_ of course
[17:45] <MacSlow> pitti, pk
[17:45] <MacSlow> pitti, ok
[17:45] <cjwatson> mtaylor: right, you can clearly just ignore those warnings
[17:46] <mtaylor> cjwatson: my thing is, I'm trying to make ubuntu package of mysql to be distributed by MySQL... so we'll have a feisty, gutsy and hardy package for a release we do, right?
[17:46] <mtaylor> cjwatson: and there's no real need in that case to have ubuntu in the version string
[17:47] <cjwatson> mtaylor: the only thing I'd say there is that it's worth following Ubuntu versioning practices as closely as possible in order that upgrades work properly in both directions
[17:48] <cjwatson> mtaylor: but I don't think it'll make a huge difference, and in your position I would probably just ignore the warning
[17:48] <mtaylor> cjwatson: yes... I'm actually quite interested in upgrades working in both directions :)
[17:48] <mtaylor> ok
[17:49] <cjwatson> -               if ($data->{'version'} =~ /ubuntu/) {
[17:49] <cjwatson> +               if ($data->{'version'} =~ /ubuntu|hardy|gutsy|feisty|edgy|dapper/) {
[17:49] <cjwatson> mtaylor: ^-- committed upstream
[17:50] <mtaylor> cjwatson: you rock!
[17:50] <ogra_cmpc> mtaylor, he does :)
[17:50] <superm1_> cjwatson, did you by chance glance over the changes i made to cdimage, to see if they can be merged into mainline?
[17:51] <cjwatson> superm1_: I think I missed them
[17:51] <superm1_> cjwatson, let me grab the branch url again then, sec
[17:51] <cjwatson> superm1_: my main concern is that I'm pretty sure we're out of space to host more derivatives
[17:52] <cjwatson> superm1_: so if it's just to have the code merged, fine, but a hosting request is more difficult
[17:52] <superm1_> cjwatson, would it be possible to only keep one of the daily images generated, and toss any older ones?
[17:52] <superm1_> that way it would be minimal space requirements?
[17:52] <cjwatson> yes, but even then we're really getting painfully close to the wire
[17:52]  * ogra_cmpc sees edubuntu on cdimage seems to buikld now :)
[17:52] <cjwatson> it becomes a serious problem every now and again
[17:53] <cjwatson> ogra_cmpc: yeah, I think I got it working, though it needs testing
[17:53] <superm1_> cjwatson, well getting the code merged would be a good start for now at least
[17:53] <cjwatson> superm1_: could you run it by slangasek and ask him to look at the merge?
[17:53] <ogra_cmpc> cjwatson, btw, did you see amits mail about the usb suspend ? i'm not reallly fond of having a separate kernel package just for that one change
[17:53] <cjwatson> ogra_cmpc: no, where?
[17:54] <ogra_cmpc> i CCed you in my answer
[17:54] <cjwatson> ogra_cmpc: oh, that's been a contentious problem for some time
[17:54] <superm1_> cjwatson, sure.  I had figured I should run it by you since I branched I pushed them to http://bazaar.launchpad.net/~mythbuntu/ubuntu-cdimage/mythbuntu-cdimage/, is that not the main branch then?
[17:54] <ogra_cmpc> apparently the patch for poersistent USB disks is in the kernel since some time already
[17:54] <superm1_> er from
[17:54] <cjwatson> ogra_cmpc: it's one of those things where if you turn it on, you break one set of hardware, and if you turn it off, you break a different set
[17:54] <ogra_cmpc> but we never enabled it in out builds
[17:54] <superm1_> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/
[17:55] <cjwatson> ogra_cmpc: Ben has looked into it before
[17:55] <ogra_cmpc> ah, k
[17:55] <ogra_cmpc> so i actually need a separate build :(
[17:55] <cjwatson> superm1_: yeah, the public mirror is mine but actually all of ~ubuntu-cdimage have magic write access behind the scenes
[17:55] <superm1_> cjwatson, ah okay.  i'll check with slangasek then.  thanks.
[17:55] <cjwatson> the real master copy is on the cdimage build machine
[17:56] <cjwatson> ogra_cmpc: I agree that it would be useful to have it as a boot option
[17:56] <cjwatson> ogra_cmpc: but I can't answer as to whether that's feasible
[17:56] <ogra_cmpc> right
[18:00] <soren> Ok, I've reproduced the alternate install CD's stuckage.
[18:01] <ogra_cmpc> what is it ?
[18:01] <soren> localedef seems to be stuck in an infinite loop somewhere.
[18:01] <soren> strace and ltrace are both silen.
[18:01] <soren> +t
[18:01] <soren> It's eaten 33 minutes and 16 seconds of CPU time already.
[18:03] <soren> Does anyone have a physical machine they can try to reproduce this on? (i'm doing this in kvm)
[18:03] <ogra_cmpc> cjwatson, i assume report.html doesnt gain me any info anymore for the addon now ?
[18:04] <ogra_cmpc> seems it lists all packages ...
[18:04] <cjwatson> ogra_cmpc: oh, err, yeah, it's probably completely useless
[18:04] <ogra_cmpc> right
[18:04] <cjwatson> ogra_cmpc: please turn it off in cdimage/bin/build-image-set
[18:04] <cjwatson> check for [ ! "$CDIMAGE_ADDON" ] or some such
[18:05] <ogra_cmpc> ok
[18:05] <cjwatson> soren: localedef is notoriously memory-hungry and can easily suck 50M
[18:05] <cjwatson> soren: how much have you got?
[18:05] <cjwatson> soren: swap's supposed to be switched on by that point so it isn't normally a problem
[18:06] <soren> cjwatson: 128MB. 10 of which are free, and there's 150MB swap free.
[18:07] <soren> I suppose it could be semi-interesting to try it with significantly more memory, but as it's completely CPU bound..
[18:08] <soren> 40 minutes, 44 seconds (on a 1.2GHz box).
[18:10] <cjwatson> it generates UTF-8 locales by building up a gigantic table in memory
[18:10] <cjwatson> soren: capture the command line it's using and try it somewhere else?
[18:10] <cjwatson> could be a genuine locale-specific bug
[18:11] <soren> I'm guessing someone would have caught it.. It's en_US.UTF-8 :)
[18:11] <soren> But sure.
[18:13] <soren> Er... I can't even kill -9 it.
[18:16]  * soren sighs
[18:37] <cjwatson> soren: that would suggest a kernel problem ...
[18:39] <ogra_cmpc> hmm, why cant i9 access lithium anymore
[18:40] <elmo> because it's not lithium
[18:40] <elmo> and hasn't been for months
[18:40] <ogra_cmpc> i didt have to touch it for ages
[18:40] <elmo> you asked the same question last time dude
[18:40] <elmo> try antimony
[18:41] <ogra_cmpc> gah
[18:41] <ogra_cmpc> i use it to rarely ...
[18:41] <ogra_cmpc> elmo, thanks
[18:42] <cjwatson> ogra_cmpc: I suggest that you keep a record of this by way of e.g. comments in ~/.ssh/config so that you don't forget again
[19:03] <slangasek> infinity: can you give compiz back on all archs !i386?
[20:06] <danimo> hi
[20:06] <danimo> did anyone test wine on hardy lately? I get a core dump on like every binary I am trying to execute, immediately on start.
[20:07] <danimo> in libwine
[20:08] <danimo> uni2cp_low is the last useful function I get in the bt, I need to try with dbg packages if that's not a known problem
[20:08] <\sh> danimo: it's known and I#m working on it
[20:08] <danimo> \sh: ah, good to know
[20:09] <\sh> danimo: I'm compiling this damn thing since this morning
[20:33] <andresj> hello! I'm not sure if this is the right channel, but is there a tool for making svn snapshot source packages? I want to regularly upload them to Launchpad PPA...
[20:33] <andresj> I want to use blender as my first test. I have downloaded the latest stable source package already.
[20:35] <Chipzz> andresj: if you don't get an answer here, try #ubuntu-motu
[20:35] <Chipzz> slightly more on-topic there
[20:37] <andresj> thanks Chipzz. askin there... :)
[20:37] <superm1_> Is there an equivalent package to desktop-base that would provide a similar 640x480 wallpaper for Ubuntu?
[21:23] <cjwatson> pitti: what's happening with getting Arne's language-support changes merges?
[21:23] <cjwatson> merged
[21:23] <cjwatson> pitti: that really should happen tomorrow if we want it for hardy
[21:24] <cjwatson> which I think we do
[21:47] <lamont> slangasek: "rarely" just means that it's a royal bitch to track down when the bug _is_ hit
[21:52] <slangasek> lamont: but isn't "rarely" on amd64 really "in extreme circumstances that would only be encountered by users running a ucLinux kernel in their madness"?
[21:53] <slangasek> or "load the program, allocate a 4GB array, then dlopen a plugin linked to every library on the system"...
[21:53] <lamont> dunno.. I know I had some bind bugs that were related to 64-bit beyond 4GB on amd64
[21:54] <slangasek> hmm, ok
[21:54] <slangasek> that's a different story, then.  is there any hope of a rebuild test of main with this option before switching it on the buildds, though?
[21:59] <slangasek> lamont: otherwise, without a full rebuild test we have no assurance of noticing the issue before, say, we need to do a post-release security update...
[21:59] <lamont> slangasek: I believe that we can process all of the autotest logs...
[21:59] <lamont> at least I think we still have these
[21:59] <lamont> :-)
[22:00] <lamont> I'll check with infinity in the morning about where the current autotest logs are, and we can certainly scrape them for the failures
[22:00] <slangasek> ok, cool
[22:33] <bryce> MacSlow: yes the patch I did for drop-shadow-decoration works great; I've got it installed on my 965 laptop and am having no problems with it
[22:34] <bryce> MacSlow: I asked tjaalton about uploading it, but he suggested turning on greedy by default instead, which I gather also solves the issue but in a different way, and also addresses performance and other issues
[22:34] <bryce> MacSlow: anyway, so I've done up a patch for that too, but it doesn't quite work yet.  Planning on tinkering with it more tomorrow or Wednesday
[22:35] <bryce> MacSlow: I also passed my drop-shadow-decoration patch upstream, but didn't get a response
[22:48] <alvarezp> Please excuse me, I'm looking for guides on how to rebuild a package with newer versions of the source code. I already did apt-get source p, apt-get build-dep p, and wget new-source, but I don't know how to tell debuild to use the new version of the source code to build a new package.
[22:49] <tjaalton> bryce: there were three replies to the post ;)
[22:49] <tjaalton> bottom line was that it'll get fixed properly in 2.3
[22:50] <bryce> tjaalton: hmm I only saw jesse's
[22:52] <bryce> oh right
[22:53] <bryce> tjaalton: well eric and zhenyu didn't really give feedback on the patch, just said they needed to "fix it properly in 2.3", but didn't give any indication what they meant by that
[22:53] <bryce> so, I got a response, but not quite what I was hoping for...
[22:54] <tjaalton> heh
[22:54] <bryce> maybe eric just doesn't like me ;-)
[22:56] <tjaalton> bryce: maybe he doesn't like the state of intel code atm ;)
[22:58] <bryce> tjaalton: well he definitely doesn't seem to like it when I put up patches to work around the problems ;-)
[22:58] <tjaalton> "I'm working on it, leave me alone" :)
[22:58] <bryce> heh exactly
[22:59] <bryce> but jesse is helpful - "for a work around, that looks good enough" :-)
[22:59] <bryce> (aside from that it didn't actually work... but at least I know I'm not way off base)
[23:00] <tjaalton> yep, I'll test it again once you have something
[23:00] <bryce> cool
[23:00] <bryce> I'm going to allocate tomorrow to focus on it
[23:01] <bryce> I'm guessing that either my logic is screwy, or else it requires something in addition to greedy to be turned on.  I'll just slip in some debug statements and that should prove it one way or the other.
[23:05] <lamont> slangasek: and then there's the current gconf (one of many with ldap issues):
[23:05] <lamont> Function `ldap_get_values' implicitly converted to pointer at evoldap-backend.c:265
[23:05] <lamont> Function `ldap_init' implicitly converted to pointer at evoldap-backend.c:579
[23:06] <lamont> and gnome-mount
[23:08] <slangasek> lamont: that's not the current gconf, I fixed that over 12 hours ago ;)
[23:08] <lamont> heh
[23:08] <lamont> that's autotest
[23:08]  * slangasek nods
[23:08] <tjaalton> does gconf now have a usable ldap backend?
[23:09] <slangasek> lamont: cyrus-sasl2 still has the same problem, but those are the only two ldap incompatibilities left in main that I know of
[23:09] <slangasek> oh, I guess autofs is in main too
[23:19] <nxvl_work> if a bug has been fixed on upstream, how do i mark the bug? as fix commited?
[23:19] <Fujitsu> nxvl_work: You mark the upstream task of the bug Fix Released.
[23:20] <bryce> nxvl_work: generally I would use "Also affects project" to link to the upstream bug report with the fix
[23:20] <nxvl_work> bryce: already done
[23:20] <nxvl_work> Fujitsu: but the ubuntu one, stay as confirmed?
[23:20] <Fujitsu> nxvl_work: Correct.
[23:20] <Fujitsu> Some people set it to Fix Committed, but that's wrong.
[23:20] <bryce> nxvl_work: in case it's not clear what the fix is, it can sometimes be useful to also attach the patch to the Ubuntu bug; this way if someone searches bugs with patches, it'll show up
[23:21] <nxvl_work> the patch has been sended to upstream
[23:21] <nxvl_work> and they included the fix
[23:22] <nxvl_work> the upstream part of LP is marked as fix released
[23:22] <nxvl_work> but i don't know how to mark the ubuntu part
[23:22] <nxvl_work> since that bug must to be closed one or other way
[23:22] <slangasek> Fujitsu: I wonder, why is 'fix committed' wrong? I'm not aware of anything saying /where/ the fix has to be committed to use that status
[23:22] <Fujitsu> Leave it as it is. It will appear in the list of bugs fixed upstream but not in Ubuntu.
[23:22] <Fujitsu> slangasek: It's not committed to anything Ubuntu-related, therefore it can't be right.
[23:23] <slangasek> well, I think the definition of "Ubuntu-related" is fuzzy... if an Ubuntu package is maintained on alioth, is "fix committed" warranted?
[23:23] <Fujitsu> One doesn't set a bug in Ubuntu as In Progress just because upstream is working on it.
[23:27] <crimsun_> the protocol needs to be clarified/documented on the wiki, at least.
[23:35] <mathiaz> nxvl_work: you're probably refering to bug 24777 - marking it as confirmed or triagged is the best option I think.
[23:35] <ubotu> Launchpad bug 24777 in openssh "Apply openssh sftp-chroot patch to openssh-server" [Medium,Confirmed] https://launchpad.net/bugs/24777
[23:35] <nxvl_work> mathiaz: yep, this one
[23:35] <nxvl_work> mathiaz: ok, so i will mark it as confirmed as i can't use triaged
[23:35] <mathiaz> nxvl_work: even if it's been committed to upstream openssh, it hasn't been included in ubuntu (yet).
[23:36] <nxvl_work> mathiaz: and there are no plans to include it on this release, that's what i thought :D
[23:36] <nxvl_work> mathiaz: thnx
[23:37] <mathiaz> nxvl_work: well - considering that we're in FeatureFreeze I don't think it will be included in hardy.
[23:37] <mathiaz> nxvl_work: but you can always to try to convince cjwatson_ to include it.