[12:03] <omeg> Aha. I always thought it was 640x480 by default.
[12:07] <Amaranth> infinity: 640x480?
[12:07] <Amaranth> 640x400 is 8:5
[12:07] <infinity> Yes, I know.
[12:08] <infinity> And it's also the default resolution for the EGA/VGA BIOS of most PC video cards, and the default resolution of vga16fb.
[12:08] <omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/zeta_8x5-bold.png <-- here we go.
[12:09] <omeg> Now to make a mock-up of how it would look in usplash.
[12:16] <omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_7.png <-- hmm... I kind of liked the font also used on the CD a bit better. It might be nice for the logging, but most (including myself) believe we should not do logging anymore.
[12:16] <omeg> *CD splash screen
[12:17] <infinity> As I already said, the logging won't be going away for dapper.
[12:18] <infinity> And even if it goes away in edgy, you will be able to optionally turn it back on.
[12:18] <omeg> Okay... so it's not possible to get rid of the logging before release?
[12:18] <infinity> I doubt it'll happen.
[12:18] <omeg> What about the possibility of making the change and then installing it into the system at a later update?
[12:19] <infinity> That's even worse. :)
[12:19] <omeg> Well, I guess I can kind of agree with that...
[12:19] <infinity> We don't make UI changes to stable releases, and we try not to make them after the UI freeze (which is long past)
[12:20] <omeg> What if I supplied you with a BDF font somewhere in the next few days?
[12:20] <infinity> And, other than the "it'll irritate people and cause a time consuming flamewar" issue, there's also just the issue that people like me need to spend the next 3 weeks fixing as many bugs as possible, not implementing feature changes.
[12:20] <infinity> If you supply me with a less crap font, I can get that in with minimal effort on my part (and minimal impact on the UI), so I don't see that one being an issue.
[12:22] <omeg> I'll try my best to tame that xmbdfed thing you were talking about, then. Since my main issue here is the fact that, well, I find the current logging font at startup to be really ugly.
[12:22] <infinity> (As for the mockup you just gave me, I suspect that the "text-free" version will be REALLY text-free... "System is starting up" is redundant, when everyone knows what the progress bar means)
[12:22] <omeg> Maybe. I think that's up for debate. I don't think it's entirely illogical to state what's happening.
[12:23] <infinity> I suspect I'll just have a logo and a progress bar... And maybe, for the first 5 seconds, a "F1: boot messages, F2: text-mode" hint at the bottom.  Or something.
[12:23] <infinity> I've not put too muhc thought into it, since the latter part (allowing keystrokes to do something) requires real effort.
[12:24] <infinity> Right now, the keyboard passes straight through to init.  Which is actually really handy.  So, trapping one or two keys, while passing the rest through, will require some thoughtful coding.
[12:27] <sits> does anyone have a usb printer?
[12:27] <sits> I have a small test
[12:27] <omeg> infinity: I'll try to come up with some things for future releases. I should really have checked in before UI freeze, though, I guess. :)
[12:28] <infinity> omeg: I'm open to plenty of suggestions for edgy (though, I'd prefer not to spend much time thinking about them until after June 1st) :)
[12:29] <omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_8.png <-- what do you think of this?
[12:29] <omeg> The font, that is.
[12:29] <omeg> What is Edgy, by the way? The stable release that comes after Dapper?
[12:29] <infinity> omeg: Yeah, Edgy Eft.  Ubuntu 6.10.
[12:30] <infinity> omeg: That font's probably a bit too large, I'd guess, to get all the text in horizontally.
[12:30] <omeg> Hmm, you're right. Maybe if it has 1 px spacing instead of 2?
[12:30] <infinity> Experimentation++
[12:31] <infinity> omeg: Mail me (adconrad@ubuntu.com) when you have more stuff to look at.
[12:31] <infinity> omeg: Bonus points if one of those things is a font. :)
[12:32] <infinity> omeg: You're only the third person in the last 3 months who's offered a new font, so I'm becoming skeptical. :)
[12:32] <infinity> omeg: Deliver that pixel font of yours in a useable state, and you'll be my new best friend.
[12:33] <omeg> http://omega.avalanchestudios.net/personal/dropbox/usplash/_usplash_misc_9.png
[12:33] <omeg> Thanks. I'll try to make a BDF font out of it.
[01:09] <mdke> any asian font geeks still around?
[01:15] <neuralis> hmm. my dapper just broke very strangely.
[01:27] <mdke> or perhaps even anyone who knows even something vague about fonts?
[08:11] <kagou> hi
[08:31] <czr> hi. a bit ot question. is it easy to setup a cross-arch toolchain (gcc/libc) inside ubuntu (5.10)?
[08:31] <czr> (running on i386, want to build x86-64 stuff)
[10:06] <zakame> hi all
[10:09] <infinity> czr: "apt-get install libc6-dev-amd64" and compile with "gcc -m64"
[10:17] <pygi> please do see and comment http://students.mimuw.edu.pl/~mb219407/ubuntuRPG.html
[10:17] <pygi> thanks :)
[10:18] <Mithrandir> pygi: I'd love to see it real-time, but apart from that, interesting.
[10:19] <pygi> Mithrandir: I suggested real-time, but turn-based on combat :)
[10:19] <pygi> Mithrandir: problem is who would mentor that?
[10:19] <Mithrandir> pygi: no idea; prefereably somebody with some gfx experience, etc.
[10:21] <pygi> Mithrandir: indeed :)
[10:21] <ajmitch> pygi: having developers battling it out?
[10:21] <pygi> ajmitch: hehe :)
[10:22] <zakame> ooh!
[10:23] <pygi> I indeed don't know...I'll let you decide :)
[10:23] <infinity> Ooo, I could run around killing hordes of Mithrandirs and banging infinities on the head with my mace.  Count me in.
[10:24] <pygi> ok, 3 votes by now :(
[10:24] <zakame> indeed
[10:24] <Mithrandir> I'll be chucking live cds at anybody who dares come near me?
[10:24] <Mithrandir> and have an armour made of amd64 dualcores?
[10:24] <infinity> Sounds about right. :)
[10:24] <highvoltage> Mithrandir: in that case, you'll have lots of people running to you :)
[10:24] <infinity> highvoltage: Not if they're razor-sharp LiveCDs that decapitate you.
[10:25] <Mithrandir> they won't run for long, at least. :-P
[10:25] <pygi> more votes? :P
[10:25] <highvoltage> infinity: probably not :)
[10:25] <pygi> for or against? :P
[10:25] <highvoltage> Mithrandir: if you throw out Windows XP cd's, perhaps we'd keep our distance then
[10:25] <ajmitch> for an ubuntu SoC project, I think it's crack :)
[10:25] <highvoltage> Mithrandir: but we'll also be putting in more effort to kill you
[10:25] <infinity> Yeah, I don't think it's a sane SoC project.
[10:25] <pygi> but other things are higher priority I believe, so he's right :)
[10:25] <infinity> We can't really claim we need this feature in Ubuntu.
[10:26] <pygi> infinity: agreed :)
[10:26] <infinity> But it's a cool project for someone to do in non-sponsored space.
[10:26] <Mithrandir> I want somebody to sit down and write a clone of syndicate or syndicate wars.
[10:26] <infinity> Especially if I get to crush opponents with my pedantry, and wear an armour of +12 build logs.
[10:27] <pygi> :P
[10:27] <highvoltage> you can have a level with 10000 bugs you have to kill, to save dholbach from insanity
[10:28] <zakame> don't forget the X god :)
[10:28] <pygi> infinity: have you looked over the samba applications?
[10:31] <infinity> Well, the comments on the GUI config tool seemed to end up in it being a "not really necessary" spec.
[10:31] <infinity> What was the other one?
[10:31] <pygi> well, there are several ones
[10:31] <infinity> Oh boy.  Links?
[10:32] <pygi> lemme go check it out :
[10:32] <pygi> :)
[10:32] <pygi> none are good by my opinion tho :P
[10:32] <pygi> http://code.google.com/soc/ubuntu/app.html?csaid=io.alex.2002@gmail.com:0b88daa9:90900c7c
[10:32] <pygi> one
[10:33] <pygi> http://code.google.com/soc/ubuntu/app.html?csaid=sed.nivo@gmail.com:0450af38:273c59fb
[10:33] <pygi> two
[10:33] <pygi> third you saw probably
[10:33] <infinity> LOAD FASTER.
[10:33] <pygi> :)
[10:34] <pygi> not so much good applications this year I am afraid :(
[10:34] <infinity> I don't suppose we have any students interested in running more underwater fiber to Australia as their SoC project?
[10:34] <pygi> but those we selected are good
[10:34] <pygi> no, indeed :)
[10:34] <ajmitch> I could try & do that
[10:34] <ajmitch> but I doubt you'd care about faster connectivity to NZ
[10:35] <infinity> Bah, there's no one worth talking to in NZ anyway. :P
[10:35] <infinity> Oh, this isn't bandwidth anyway, it's broken Google.
[10:35] <infinity> Awesome.
[10:35] <infinity> The server encountered a temporary error and could not complete your request.
[10:35] <infinity> Please try again in 30 seconds. 
[10:37] <infinity> pygi: Meh.  It's not loading for me.
[10:37] <infinity> pygi: Do they link to specs in the wiki or something?
[10:38] <pygi> infinity: nop, but I could pm you applications?
[10:38] <neuralis> infinity: i don't think it's just .au; it's not loading here either.
[10:39] <infinity> pygi: Sure.
[10:43] <pygi> tell  me when you are done with this one
[10:50] <pvanhoof> guys ... update-manager (which runs as root) has a very critical security problem
[10:51] <pvanhoof> I don't understand howcome nobody has yet written a malware software for it, please ask me .. I filed it as a non-public bug #43328
[10:52] <pygi> pvanhoof: please subscribe me to the bug
[10:52] <pvanhoof> I'm certain I can cook a prove of concept for this one. For any gtk+ (or maybe even x11) developer this wouldn't be very hard at all
[10:52] <pvanhoof> s/prove/proof
[10:54] <infinity> pvanhoof: The builtin terminal is intenationally not read-only for the (now rare, but still real) case where a maintainer script will prompt on stdout/stdin without using debconf.
[10:54] <infinity> pvanhoof: Currently, the assumption is that people running update-manager have full admin rights, so it's not really a security bug.
[10:55] <pvanhoof> infinity, shall I prove it by writing a little tool that listens for the user-passwords?
[10:55] <pvanhoof> I can do this in 50 minutes
[10:55] <infinity> pvanhoof: I'm not sure what that would prove.
[10:55] <infinity> pvanhoof: Being able to listen for user passwords is an inherent problem with sudo and friends in general.
[10:55] <highvoltage> pvanhoof: as soon as you write a tool that listens for passwords, there'd be millions of ways you can get root on a system
[10:56] <pvanhoof> that I can run the tool and get it to become root, then only thing I'd have to do is sending keytrokes to it. I'm certain the terminal widget has security issues
[10:56] <infinity> pvanhoof: There's not much you can do to fix that except to never allow a user to escalate their privileges.
[10:56] <infinity> pvanhoof: It's assumed that users who have sudo privileges also practice reasonably safe software practices.  If that's not the case for you, you're handing out sudo to the wrong users.
[10:57] <pvanhoof> look, first of all it's absolutely not good to run a gtk+ application as root .. but lets say that's okay
[10:57] <infinity> (For instance, you do NOT give sudo to everyone in a university computer lab so they can use update-manager, you just do updates remotely via SSH behind their backs)
[10:57] <pvanhoof> then second of all .. the program (written with gtk+ libraries) that runs as root has a terminal which gives access to send characters to a root-console
[10:58] <pvanhoof> and that terminal isn't set read-only
[10:58] <pvanhoof> and I can make the tool being run in that terminal interrupt by sending ctrl+c
[10:58] <infinity> Yes, but the root console is started by someone who HAS ROOT PRIVILEGES.
[10:58] <infinity> This is no different than you typing "sudo su - root" in a gnome-terminal.
[10:58] <pvanhoof> the password I have to enter is the same as the password of my user
[10:59] <pvanhoof> I don't understand why ubuntu doesn't develop a helper program for this 
[10:59] <pvanhoof> and pipes that output to a read-only widget
[10:59] <Mithrandir> how would using a helper program help?
[10:59] <pvanhoof> that would be perfectly secure
[10:59] <infinity> Because if it's read-only, how do you interact with the terminal?
[10:59] <pvanhoof> because that way the gtk+ application wouldn't have to be root Mithrandir 
[11:00] <infinity> (Note that sometimes, you WILL need to interact with the terminal, that's one reason why it's there)
[11:00] <highvoltage> you'd still have your user password, you could just open a terminal and type sudo su -, like infinity pointed out :)  so how would it be more secure?
[11:00] <infinity> The fact that Ubuntu has tried really really hard to remove al postinst prompting may have spoiled you a bit, but plenty of .deb packages still prompt in maintainer scripts.
[11:00] <pvanhoof> then patch the apt-get libraries so that you never have to interact with the terminal? the fact that you have to interact with the temrinal simply tells me the complete design is wrong
[11:00] <Mithrandir> pvanhoof: if you can interact with a user's X session, you can listen for any keystrokes.  How's that news?
[11:01] <pvanhoof> highvoltage, using a helper tool you wouldn't have to use sudo
[11:01] <Mithrandir> pvanhoof: it's not apt, it's not dpkg, it's maintainer scripts.
[11:01] <infinity> pvanhoof: apt-get has nothing to do with a PACKAGE using the maintainer scripts to interact with the user.
[11:02] <pvanhoof> don't allow such scripts in your packages? It's ubuntu people who maintain the packages
[11:02] <infinity> pvanhoof: And as pointed out, if you have sudo access and you ever intend to use it at all, for anything, if I'm running an application in your X session, I can snarf your password.
[11:02] <pvanhoof> this is silly finger pointing. If you create a distro, you are responsible for the packages
[11:02] <infinity> pvanhoof: This is why you don't run untrusted software on a trusted account.
[11:02] <pvanhoof> yes, so why do you guys allow this ?!
[11:03] <Mithrandir> infinity: not only that, you can drive more or less any application too.
[11:03] <pvanhoof> people do run untrusted software on trusted accounts 
[11:03] <infinity> pvanhoof: Then they shouldn't.  This is inherent in how X works.
[11:03] <Mithrandir> I don't think we'll rework X today at least.
[11:03] <pvanhoof> again, finger pointing. If you'd simply use a helper application that can ONLY upgrade the system, you wouldn't have to put that sudo thing there
[11:03] <highvoltage> pvanhoof: is there any system in the world that doesn't let you run untrusted software on a trusted account?
[11:03] <ajmitch> this is why we need SEX - security-enhanced X
[11:04] <infinity> pvanhoof: And the any number of other things you may want to use sudo to do?..
[11:04] <highvoltage> hehe
[11:04] <ivoks> pvanhoof: ? only root can upgrade system 
[11:04] <pvanhoof> ivoks, correct, but now there's a ui tool that also runs root and to which I can send keystrokes .. and that tool even has a root terminal non read only
[11:04] <pvanhoof> and it's predictable .. so it's ten times worse than running su - in a xterm
[11:05] <ivoks> pvanhoof: and this is something you can do if you run apt-get dist-upgrade?
[11:05] <ivoks> pvanhoof: s/can/can't/
[11:05] <pvanhoof> ivoks, no it's something I can invoke from another application
[11:05] <pvanhoof> ivoks, right but that isn't invokable by an application, nor predicatable
[11:05] <pvanhoof> this is
[11:05] <ivoks> what's not invocable?
[11:06] <pvanhoof> when I run a xterm and I do a su -, I know as an admin I might be in danger
[11:06] <czr> thanks infinity
[11:06] <ivoks> ok
[11:06] <pvanhoof> but this tool , I can run it from an application
[11:06] <pvanhoof> and I can send it keystrokes from that application
[11:06] <infinity> pvanhoof: And same for update-manager, which is WHY we only allow admin users to do it.
[11:06] <pvanhoof> and once it runs, it has a writable terminal
[11:06] <ivoks> pvanhoof: but when you run update-manager you know you run it as root
[11:07] <ivoks> pvanhoof: so, again, you know you are in risk
[11:07] <infinity> pvanhoof: update-manager isn't SUID or anything.  You're still being asked to authenticate with sudo (well, gksudo).
[11:07] <pvanhoof> infinity, 99% of the desktop computers have one or two user accounts .. and the setup does not let you make user accounts that don't have this possibility
[11:08] <pvanhoof> infinity, and since the password is the same as the one the user must enter, I can very easily know that password
[11:08] <infinity> pvanhoof: Erm, what?  New users created with the GUI user admin tool, or from the CLI with adduser are NOT in the admin group.
[11:08] <pvanhoof> most people will enter the same password for every question, and I can mimic the dialog box
[11:08] <infinity> pvanhoof: You're just talking about the inherent scariness of sudo in general here, this has nothing to do with update-manager at all.
[11:08] <_ion> User stupidity cannot be fixed with software solutions.
[11:08] <pvanhoof> for example I can replace a menu-item, mimic the dialog box and launch the original application and send the password to the gtkentry
[11:09] <pvanhoof> all this can be done in a little script
[11:09] <infinity> pvanhoof: And it's an attack vector we're aware of, and one we really can't do anything about without going back to the days of pure user/root separation that pisses people off cause they can't get anything done.
[11:09] <ivoks> pvanhoof: and you can't do this with a shell app?
[11:09] <pvanhoof> and then I have an application with a root termal not being read-only
[11:09] <infinity> pvanhoof: sudo is a tradeoff, and we all know it.
[11:09] <Mithrandir> pvanhoof: you still need to get your exploit onto the user's machine.
[11:09] <pvanhoof> infinity, if you don't add that sudo entry .. and if you create a little helper tool that has SUID root priveledges but can ONLY upgrade the system
[11:09] <pvanhoof> you wouldn't have this problem
[11:10] <pvanhoof> and creating such a tool is not difficult
[11:10] <pvanhoof> and you can pipe commands to such a tool, while it's being run as a suid tool
[11:10] <_ion> Update/] ] 
[11:10] <_ion> Whoops.
[11:10] <pvanhoof> and that pipe can be made VERY secure
[11:10] <_ion> Update-manager isn't the only piece of software that needs root privileges.
[11:11] <pvanhoof> _ion, then do that for all the softwares that need root priviledges
[11:11] <infinity> pvanhoof: This isn't the only reason users have sudo access.
[11:11] <infinity> pvanhoof: We made a conscious decision to give the first user sudo access and disable root's password.
[11:11] <_ion> pvanhoof: I'm sure the Ubuntu folks appreciate your patches that make software more secure.
[11:11] <pvanhoof> that is just telling me: because it's a lot of work: we prefer to introduce a security problem
[11:11] <infinity> pvanhoof: If you want it setup your way on your machines, set a password for root and remove the sudo config.
[11:12] <ivoks> pvanhoof: suid isn't perfect solution either
[11:12] <pvanhoof> infinity, I know I will not run untrusted softwares ... but common users will
[11:12] <ivoks> pvanhoof: you would have to suid apt-get, or dpkg
[11:12] <highvoltage> update-manager isn't something that you'd want suid anyway
[11:12] <ivoks> pvanhoof: and, again, you have security issue
[11:12] <pvanhoof> infinity, for my system this isn't important, but for normal people (which is the target audience of ubuntu, right?) it is
[11:13] <pvanhoof> ivoks, that is wrong, you probably do upgrades and etc using a apt-get library
[11:13] <pvanhoof> or a dpkg library
[11:13] <pvanhoof> and since you can specify which tools to run and how
[11:13] <pvanhoof> even that wouldn't be a problem
[11:13] <infinity> pvanhoof: Actually, no.  update-manager does some stuff as root that isn't directly apt-get related.
[11:14] <pvanhoof> if I from a user tool pipe 'e' to a SUID application
[11:14] <infinity> (fiddling with sources.list, running dist-upgrade recipes, etc)
[11:14] <pvanhoof> and cause of that 'e' the application will launch apt-get install bla
[11:14] <infinity> update-manager NEEDS root.
[11:14] <ivoks> pvanhoof: but, what will prevent you from installing my .deb package wich will sniff your password?
[11:14] <infinity> Not everyone on a machine NEEDS to be able to run update-manager.
[11:14] <pvanhoof> infinity, even updating such a text file can be made secure
[11:14] <infinity> If.  You.  Don't.   Trust.  Your.  Users.  Don't.  Give.  Them.  A.  Trusted.  Account.
[11:15] <infinity> pvanhoof: If they have the privileges to update sources.list, they have the privileges to add a source to it and install malware.  You lose.
[11:15] <pvanhoof> ivoks, if you don't allow untrusted changes to the sources.list file, how can they isntall one?
[11:15] <ivoks> pvanhoof: dpkg -i ?
[11:15] <pvanhoof> infinity, then don't give the normal user account those privileges
[11:15] <pvanhoof> ivoks, they are a user , they can't install using dpkg -i
[11:15] <infinity> pvanhoof: Now we're in circles.  I just told you not to give them those privs. :)
[11:15] <pvanhoof> only the suid root tool can do that
[11:16] <infinity> pvanhoof: OTOH, if you want them to be able to update the system, they need those privs.  Catch-22.
[11:16] <pvanhoof> infinity, you can allow the suid root tool to make specific changes, not any change
[11:16] <infinity> pvanhoof: There's no way to allow someone to do something without allowing them to do it.
[11:16] <ivoks> pvanhoof: so, they won't be able to upgrade?
[11:16] <pvanhoof> infinity, you could for example make a command like: "change mirror to Belgian"
[11:16] <ivoks> pvanhoof: I'm sure, you understand, we are talking about admin user here?
[11:16] <pvanhoof> infinity, and it would upgrade the sources.list file to the belgian mirrir
[11:16] <Mithrandir> pvanhoof: uh, how about adding custom mirrors, which people tend to do?
[11:16] <infinity> pvanhoof: And why would a user who you don't trust to install new software NEED to change the mirror list at all?
[11:16] <pvanhoof> ivoks, if you really need to trust an admin user, then the ubuntu installation should prompt and warn for that during the installation procedure
[11:17] <infinity> pvanhoof: Either you trust them to install software, and they have (transitive) root.  Or you don't.
[11:17] <ivoks> pvanhoof: it does
[11:17] <pvanhoof> Mithrandir, that is something a person who knows how to use the root account should do
[11:17] <pvanhoof> ivoks, howcome it didn't let me add more NORMAL users then?
[11:17] <infinity> pvanhoof: So, for the "regular home user with one user on the system", you're suggesting they should all employ someone (you?) to be root on their computer whenever they need it?
[11:17] <ivoks> pvanhoof: it didn't, but it has a note that you should do that after install
[11:17] <pvanhoof> or why wasn't that the default and the last account created, with a big fat warning, the admin account?
[11:18] <infinity> pvanhoof: Because they're too stupid to use their own computers?
[11:18] <infinity> pvanhoof: A compelling argument, but not one that users are likely to agree with.
[11:19] <pvanhoof> well then, just wait for ubuntu to become more popular .. you'll see the malwares that abuse this with 1000ths
[11:19] <ivoks> pvanhoof: i understand our concern, but people need a way to administer computers
[11:19] <ivoks> eh...
[11:19] <pvanhoof> ivoks, then stop finger pointing and make softwares in a secure way that do this
[11:19] <ivoks> pvanhoof: you don't understand
[11:19] <pvanhoof> I do
[11:19] <ivoks> pvanhoof: malware would do harm in shell as in GUI
[11:20] <pvanhoof> I'm one of the guys that make the ubuntu softwares. I TELL you it's NOT difficult and it IS possible
[11:20] <ivoks> you can't force people not to install malware
[11:20] <ivoks> pvanhoof: sure it's possible
[11:20] <ivoks> pvanhoof: but you have to get user to install malware
[11:20] <pvanhoof> so why don't you guys do it?!
[11:20] <ivoks> pvanhoof: it won't install by it self
[11:20] <Mithrandir> pvanhoof: if you can come up with a non-movie attack scenario and patches to fix it, I'm sure they'll be appreciated.
[11:20] <ivoks> pvanhoof: you don't listen to anything other people tell you, right?
[11:21] <pvanhoof> I am listening, but right now ubuntu implements the exact same type of security problems the windows platform has
[11:21] <ivoks> it's not malware, virus or worm if user has to install it
[11:21] <pvanhoof> and ubuntu simply fingerpoints just like how microsoft fingerpoints
[11:21] <pvanhoof> it is not the solution
[11:21] <ivoks> pvanhoof: no, these two are not a like
[11:22] <ivoks> pvanhoof: ubuntu starts all users apps with non-root privileges
[11:22] <ivoks> pvanhoof: that's not something windows doo
[11:22] <ivoks> pvanhoof: if you take a look at windows problems
[11:22] <ivoks> pvanhoof: 99% of them aren't cause of instalation of programrs
[11:22] <ivoks> pvanhoof: but holls in explorer, outlook, etc
[11:22] <ivoks> pvanhoof: wich run as admin user
[11:23] <ivoks> pvanhoof: this is not the case with ubuntu
[11:23] <pvanhoof> percentages aren't very important for security issues. That one security problem, can be so major it will defect every ubuntu install
[11:24] <pvanhoof> running gtk+ applications as root is not smart .. and putting a writable terminal inside that tool is , well , insane
[11:24] <fabbione> pvanhoof: since you make Ubuntu, mind to tell me exactly what is your LP account?
[11:24] <azeem> so is there an analysis how many packages still use the terminal for i/o during installation?
[11:24] <fabbione> pvanhoof: i am curious to see what you do for it
[11:24] <pvanhoof> fabbione, I don't 'make ubuntu', I develop softwares, my gnome foundation e-mail is pvanhoof@gnome.org, feel free to mail me
[11:24] <azeem> I think OEM packagers should get told NOT to do this if they want their packages to work
[11:25] <pvanhoof> fabbione, and I'm not into that type of discussions
[11:25] <infinity> fabbione: That would be https://launchpad.net/people/pvanhoof
[11:25] <ivoks> eh, come on guys...
[11:25] <pvanhoof> indeed, come on
[11:25] <fabbione> infinity: thanks
[11:25] <infinity> 03:20 < pvanhoof> I'm one of the guys that make the ubuntu softwares.
[11:25] <infinity> Come on indeed.
[11:25] <pvanhoof> azeem, indeed
[11:25] <infinity> Supporting your position with a (false, no less) power play is fun!
[11:26] <pvanhoof> azeem, just tell the oem packagers not to do this
[11:26] <azeem> infinity: he said, he's one of the upstream GNOME people
[11:26] <ivoks> :)
[11:26] <fabbione> pvanhoof: did you come here to troll or something?
[11:26] <azeem> (thought it wasn't very clear)
[11:26] <pvanhoof> pvanhoof, I came here to tell update-manager has a serious security issue
[11:26] <pvanhoof> well, I didn't came here, I just mentioned it
[11:27] <pvanhoof> and people started asking me about it
[11:27] <ivoks> pvanhoof: ok, but with an attacking attitude
[11:27] <azeem> pvanhoof: the developers have analysed your report
[11:27] <pvanhoof> ok. which is fine for me .. I was just responding the questions being thrown at me
[11:28] <ivoks> and insted of translating desktop guide, i'm flamimng here :)
[11:35] <infinity> pvanhoof: Can you actually obtain a root shell through update-manager itself?
[11:35] <infinity> pvanhoof: Ctrl-C shouldn't give you one, since it's not running an interactive shell in the first place.
[11:35] <pvanhoof> I don't yet know that
[11:35] <infinity> pvanhoof: That will just cancel the current operation and leave you with a non-functional terminal.
[11:36] <pvanhoof> but I'm more or less certain it would be possible. Also given the fact that there's a lot bugs in that widget
[11:36] <infinity> pvanhoof: So, your complain seems to be with gksudo itself, which one would hope invokes X tricks to block keyboard grabs.
[11:36] <pvanhoof> and a lot known and unknown bugs in any gtk+ widget
[11:36] <pvanhoof> gtk+ was never designed with security in mind
[11:36] <infinity> pvanhoof: Which then leaves us with the attack vector of "I can spoof a gksudo window to ask a user for their password"
[11:37] <infinity> pvanhoof: Which is a valid attack vector for ANYTHING, and also requires the user to INSTALL and RUN your spoofing app.
[11:37] <pvanhoof> gksudo , because it only asks for the user-password, can be tricked .. and since its also a gtk+ application it can probably be cracked as well
[11:37] <infinity> pvanhoof: If the embedded terminal is insecure, that's a bug.
[11:38] <infinity> Anyhow, I'm done arguing.  You can argue with mvo in the bug log instead, I guess.
[11:38] <pvanhoof> sure .. but if ubuntu wouldn't use sudo, but a helper tool that runs with root priveledges but has a very limited interface (using stdin: a pipe): it wouldn't be a security problem
[11:38] <infinity> But without a proof of concept, this all seems rather vague and hand-wavey.
[11:38] <pvanhoof> well, just wait for a buffer overflow or something like that in the terminal widget. Which isn't very hard to find
[11:39] <infinity> Yes, we have such bugs all the time, and we fix them.  Oddly enough.
[11:39] <pvanhoof> or in the application being launched in that terminal
[11:39] <infinity> Doesn't change the fact that you'd have to run something specifically designed to exploit it for the bug to be a problem.
[11:40] <pvanhoof> you are done agruing about this, you said, infinity. If you want to do this in a constructive way .. I'm available
[11:42] <ivoks> bye all
[11:42] <pvanhoof> it's a security problem, and a proof of concept will probably some day be build. I have more important things (and certainly more interesting things) todo than to proof something which is basically .. basic knowledge
[11:43] <pvanhoof> and something that is known for years .. perhaps check out the security warnings on a tool (which I once wrote) xsu, gnome superuser, etc
[11:43] <pvanhoof> a long time ago when I was naive and yough
[11:43] <pvanhoof> young
[11:43] <Mithrandir>  * Security
[11:43] <Mithrandir>  Gnome Xsu 2.0 uses the standard su binary to gain it's root access. This way,
[11:43] <Mithrandir>  all security issues should be solve
[11:43] <Mithrandir> +d.
[11:43] <pvanhoof> which wasn't true
[11:44] <pvanhoof> and I don't recommend using gnome xsu 2.0
[11:44] <Mithrandir> it's what the description currently says.
[11:44] <pvanhoof> I gave maintainership to Mark Finlay, who died a few years ago
[11:44] <pvanhoof> and I stopped developing that little tool, for it shouldn't be used
[11:45] <pvanhoof> the main security problem with gnome xsu is that is sends the password over a hidden vte terminal widget
[11:45] <pvanhoof> and then of course it does try to clear that memory and destroy the widget asap, but still it's insecure (of course)
[11:46] <Mithrandir> if you have access to a user's X terminal, you can find out what's going on there.  It's really as simple as that.
[11:46] <pvanhoof> I agree, but the update software does not need to run a tool using su or sudo
[11:47] <pvanhoof> a tool that will do this can be developed, and put suid root. If that tool is secure (which is far more easy than making a sudo-entry in the sudoers file secure), there's no problem
[11:48] <Mithrandir> you're aware that the first user is allowed to execute anything, right?
[11:48] <pvanhoof> in that case it would only be allowed to execute that suid root application and feed it commands via the stdin, and those commands would always only cause upgrade procedures
[11:49] <pvanhoof> which is legal for the first user
[11:49] <pvanhoof> just don't introduce security problems in that tool, of course
[11:49] <pvanhoof> that would be catastrophical of course 
[11:50] <Mithrandir> I still don't see why you think this is more secure as it doesn't address the real problem (X), but just changes one of many tools which require root to function properly.
[11:50] <pvanhoof> because there's no more sudo or su which can run anything.. you can only run that tool (which is +s indeed)
[11:51] <pvanhoof> and that tool (because it's programmed that way) can only run commands it is designed to run
[11:51] <pvanhoof> or perform procedures or etcetera
[11:52] <Mithrandir> I see it as lots of complexity for not much gain -- you'll have a lot more applications which have to be run as root.
[11:52] <pvanhoof> and whatever X tries .. only the commands being fed to that tool will be accepted. And those commands are not like: run this program
[11:52] <pvanhoof> no the commands are: upgrade, switch mirror, install package x
[11:53] <pvanhoof> Mithrandir, well, you gain not having to secure that first user cause of the sudoers file
[11:53] <pvanhoof> which is far more complex it seems
[11:53] <pvanhoof> because of X problems, indeed
[11:53] <Mithrandir> uh, no.  The first user still needs to be able to, say, run synaptic or network-admin
[11:53] <pvanhoof> you can build-in such commands in the tool
[11:53] <pvanhoof> synaptic can also instruct the same tool
[11:54] <pvanhoof> you wouldn't run synaptic as root
[11:54] <Mithrandir> synaptic is able to, and needs to be able to add any repositories.
[11:54] <Mithrandir> so you've just abstracted the attack one step away.
[11:54] <pvanhoof> well, I'd make selecting specific repo's possible, but not adding custom ones
[11:54] <pvanhoof> if you want to add a custom one, I'd tell the user to gain real root priveledges
[11:55] <Mithrandir> synaptic needs to be able to add custom ones.
[11:55] <pvanhoof> and specific ones can have a public key etcetera
[11:55] <pvanhoof> well, you'd loose that functionality .. 
[11:55] <Mithrandir> that's not acceptable.
[11:55] <pvanhoof> but then again, I don't know a lot normal users who'd care
[11:55] <pvanhoof> and the expert users know how to become root anyway
[11:56] <pvanhoof> and face it, those people use apt-get from a terminal, not synaptic
[11:56] <Mithrandir> some do, some don't.
[11:56] <pvanhoof> sure but, making ubuntu insecure because some experts want to use synaptic to add a custom mirror?
[11:57] <pvanhoof> It's not a valid reason anymore
[11:57] <Mithrandir> saying that "since this functionality is impossible to secure, we'll remove it and force people who need it to use a terminal" is not acceptable.
[11:57] <pvanhoof> synaptic can also work via that tool
[11:57] <pvanhoof> well then, you could make it possible
[11:57] <pvanhoof> by allowing the tool to accept a custom url
[11:58] <Mithrandir> other examples are disk-conf or user-admin
[11:58] <pvanhoof> but for example would the tool try to get a public key 
[11:58] <pvanhoof> and return a question to the user like: are you sure you want to accept this key
[11:58] <Mithrandir> apt already does that, but that doesn't help you at all.
[11:58] <pvanhoof> true
[11:58] <Mithrandir> how many people would say "no"?
[11:58] <Mithrandir> how many people do you know who checks SSL certs?
[11:58] <pvanhoof> yes, I agree. which is why I wouldn't make that possible
[11:58] <pvanhoof> but if its a key feature, even that would be possible
[11:59] <pvanhoof> and it would be at least more secure
[11:59] <Mithrandir> so you'll remove the ability to add system users, partition disks, change network settings, etc because you can't secure it?
[11:59] <pvanhoof> all those features are features for the real administrator .. so
[11:59] <Mithrandir> s/it/them/
[11:59] <pvanhoof> if such a person is needed
[12:00] <Mithrandir> who is the real admin on a single-user system?
[12:00] <pvanhoof> then it shouldn't be the first/default user created
[12:00] <Mithrandir> it seems like you want to secure the system from the admin itself.
[12:00] <pvanhoof> but the setup procedure should ask for normal users first
[12:00] <pvanhoof> and then ask for the administrative user last
[12:00] <Mithrandir> so you argue.  We disagree.
[12:00] <pvanhoof> Mithrandir, okay, then ask during the setup procedure: is this a single user system? and then warn about those priveledges
[12:01] <Mithrandir> not acceptable.
[12:01] <Mithrandir> we want to ask as few questions as possible
[12:01] <pvanhoof> Well, then you have the same security issues Win XP has, which implements the same security problem
[12:01] <HrdwrBoB> yes.;
[12:01] <Mithrandir> no, you don't.
[12:01] <HrdwrBoB> it has a person on the other end.
[12:01] <HrdwrBoB> that's an inherent security risk
[12:02] <pvanhoof> Mithrandir, I can imagine muiltiple users having the priveledge to upgrade the system, or the non-admin user or a normal-user having the priveledge to upgrade the system
[12:02] <Mithrandir> if you don't see the difference between "run everything with administrative priviledges whether it needs it or not" and "ask for (the users) password when priviledge escalation is needed", I don't think this discussion is going anywhere.
[12:02] <pvanhoof> and that doing the tasks you described shouldn't therefore also be a priveledge for that same user
[12:03] <HrdwrBoB> pvanhoof: ... you can do that now
[12:03] <HrdwrBoB> restrict sudo access to update-manager
[12:03] <pvanhoof> HrdwrBoB, right, and cause of that .. there's a security problem
[12:03] <Mithrandir> so your design will protect against the case of "somebody getting access to update-manager, but not root on the system".
[12:04] <pvanhoof> Mithrandir, correct , but then you make it one step more easy to secure the entire system. The tasks you mention aren't common tasks
[12:04] <pvanhoof> a common task is running openoffice and writing an email
[12:04] <pvanhoof> such a user doesn't need to repartition the drive
[12:04] <Mithrandir> then that user won't be an admin user.
[12:05] <pvanhoof> Mithrandir, the current installation procedure of ubuntu does not help the person who installs the operating system with that
[12:05] <pvanhoof> so I can assure you for 80% of all installations, it's at this moment the same user
[12:05] <HrdwrBoB> either a) they are a single user machine and they should have access to everything because to do otherwise is a PITA for the user
[12:05] <pvanhoof> probably more
[12:05] <HrdwrBoB> or b) they are a non priveleged user, in which case, there is no issue
[12:05] <HrdwrBoB> EOF
[12:06] <Mithrandir> pvanhoof: did you know that 73.2% of all statistics are made up on the spot?
[12:06] <pvanhoof> Mithrandir, which is why I said: probably
[12:06] <pvanhoof> I don't know that statistic , but I'm more or less certain about it
[12:07] <Mithrandir> be honest, you're guesstimating numbers.
[12:07] <pvanhoof> is it worth the risk? What if tomorrow somebody does write a poc ?
[12:07] <HrdwrBoB> so you're saying you don't trust people to partition their disks either
[12:07] <pvanhoof> HrdwrBoB, I trust a priveledges account to do that .. but not the standard account. It doesn't have to do that
[12:07] <HrdwrBoB> ... so again
[12:08] <HrdwrBoB> you're back to standard roiot/normal user practise
[12:08] <pvanhoof> on the standard account, people work. Which means they use the internet, they read email and they launch applications and click on buttons like: [Yes] 
[12:08] <HrdwrBoB> which, as has been established, is not good for normal users
[12:08] <HrdwrBoB> which apparently make up 80%
[12:08] <Mithrandir> users added by users-admin won't be members of group admin by default, if you add them to a group whose description is "Executing system administration task" you better understand what that means.
[12:09] <highvoltage> but when the browse the web, read mail, they're not running firefox or whatever with sudo, so what's the problem?
[12:09] <pvanhoof> Mithrandir, so why not create two users during the installation procedure, and explain the difference?
[12:09] <Mithrandir> pvanhoof: so you're saying that you want the full separation of root/user.  That's trivial to do; sudo passwd root ; sudo rm /etc/sudoers 
[12:09] <Mithrandir> because people have trouble relating to it, they forget passwords, etc.
[12:09] <HrdwrBoB> pvanhoof: because it's supposed to be EASY 
[12:09] <HrdwrBoB> not HARD
[12:09] <pvanhoof> highvoltage, because as that user, I can let an application launch that gksudo
[12:10] <highvoltage> but why would a user with admin rights purposely run gksudo firefox?
[12:10] <pvanhoof> highvoltage, a user who downloads some malware and tries to install it (accidently) or runs it, allows the tool to use gksudo
[12:11] <HrdwrBoB> highvoltage: if they had severe brain damage
[12:11] <pvanhoof> and that tool can abuse the design problems of X
[12:11] <highvoltage> HrdwrBoB: so how would a root user change that? then they'd just be prompted by gksu, and the same thing will happen
[12:11] <pvanhoof> and those design problems probably make it possible to abuse update-manager
[12:11] <Mithrandir> pvanhoof: you're getting very close to what Bruce Scheier calls a movie-plot threat.  See http://www.schneier.com/blog/archives/2006/04/announcing_movi.html
[12:11] <pvanhoof> highvoltage, the root user wouldn't be used for normal tasks
[12:11] <HrdwrBoB> pvanhoof: so, rather than make it easier for everyone, and have a VERY VERY small attack vector that's pretty much available anyway
[12:12] <HrdwrBoB> you'd like to make life really hard for everyone to make security a poofteenth better.
[12:12] <pvanhoof> actually, with the terminal widget being writable .. the attack vector is rather huge
[12:12] <HrdwrBoB> ... no, it's not
[12:12] <\sh> morning
[12:12] <highvoltage> hi \sh 
[12:13] <pvanhoof> HrdwrBoB, as a (upstream) gnome developer myself, I tell you it is
[12:14] <pvanhoof> HrdwrBoB, I can point you to multiple locations that are not audited for security in the code of that widget
[12:14] <pvanhoof> nor are designed with security in mind at all
[12:15] <Mithrandir> anyway, I have to go out in the great weather here to visit my grandfather, so I'm sorry I can't follow this ever-so-exciting discussion any further. :-)
[12:18] <pvanhoof> oh and, the last months people have been doing a lot developments in improving improvemance of that widget .. I know behad and federico have been doing very cool but also complex and crazy tricks with subsystems like pango and the vte widget
[12:18] <pvanhoof> It's very possible those introduced new problems
[12:18] <pvanhoof> and they are not putting their focus on security
[12:19] <pvanhoof> nor should they, the gtk+ statement is clearly that gtk+ is NOT designed with security in mind
[01:28] <Omeg> Hey infinity. Did you receive that font I sent you?
[02:29] <kos_tom> hi
[02:30] <kos_tom> i'd like to modify the Ubuntu LiveCD, so that the kernel has support for network and NFS. Where can I get the sources and .config of the 2.6.12-9-386 kernel used in the LiveCD ?
[02:31] <kos_tom> or is there a procedure to regenerate the Ubuntu LiveCD initrd ?
[02:32] <infinity> kos_tom: The LiveCD kernel has support for network and NFS already.
[02:34] <kos_tom> infinity: the Breezy LiveCD ?
[02:34] <tseng> yes
[02:35] <kos_tom> hum, strange. let me test it again, then ;)
[02:35] <tseng> the livecd in breezy has the same kernel you use on your real install
[02:36] <kos_tom> what I'd like to do is to modify the LiveCD initrd to mount the LiveCD cdrom from NFS.
[02:36] <tseng> do what?
[02:36] <tseng> nfs root?
[02:37] <tseng> i think you should probably spell out exactly what you are doing, instead of throwing out hints, it seems sortof exotic
[02:39] <kos_tom> i'm sorry, but I don't see network support in the LiveCD kernel. I've booted it, it didn't detect a network, and there are no modules for it (checked with modprobe -l)
[02:40] <tseng> then your network hardware isnt supported or autodetection failed
[02:40] <kos_tom> tseng: well. Here's my use case. I'm from a Linux User Group, and we often go in places where there are multiples computers with Windows, and we use Ubuntu LiveCD during our meetings.
[02:40] <tseng> the livecd doesnt support any more or less than the real install
[02:40] <kos_tom> tseng: my network hardware is the one emulated by Qemu, a standard NE2k card.
[02:41] <tseng> "or autodetection failed"
[02:41] <infinity> The LiveCD definitely supports that.
[02:41] <kos_tom> tseng: so, we use CDs, but CDs are really slow to read, and I except the network to be much faster.
[02:41] <kos_tom> tseng: so, I wanted to allow the computers to boot "Live", but from the network, instead of from the CD.
[02:42] <kos_tom> see what I mean ?
[02:42] <tseng> sure
[02:43] <infinity> This would actually be much simpler with dapper, I suspect.
[02:43] <infinity> Where you would just have the casper initramfs fire up an NFS connection, then grab the squashfs from the nfs share instead of from the CD.
[02:43] <kos_tom> infinity: the /lib/modules/<version>/kernel/drivers/net/ is empty in the initrd. I don't see how it can support the network, then.
[02:44] <infinity> kos_tom: I said the kernel did, I didn't say the initrd did.
[02:44] <tseng> (sigh)
[02:44] <tseng> its on the 'real' filesystem
[02:45] <kos_tom> tseng: yep, but I cannot access the 'real' filesystem without the network, in my case. So what I need, is to have more modules in the initrd.
[02:46] <infinity> Which just requires firing up a livecd locally, editing /etc/mkinitramfs/* to taste, then running "mkinitramfs -o /tmp/mynewinitrd"
[02:46] <infinity> Err, with a kernel version on the end of that. :)
[02:47] <mdke> freeflying: around?
[02:48] <tseng> edubuntu probably has ootb support for nfs root
[02:48] <tseng> i am guessing
[02:48] <infinity> The workstations do, not the LiveCD.
[02:48] <infinity> Not it's a single change in /etc/mkinitramfs/initramfs.conf
[02:48] <infinity> s/Not/But/
[02:57] <freeflying> mdke: pong
[02:58] <mdke> freeflying: ah awesome. So I'm trying fonts to find one which supports the right characters. I've tried Freefont and Dejavu and neither have worked. which can I use?
[02:59] <mdke> freeflying: is there a font which contains fonts for all the asian characters that I might need for asian translations of the documentation?
[02:59] <freeflying> mdke: fop can not support chinese fonts, so you can not get it work, especially the version u r using now 
[02:59] <mdke> freeflying: the fop developers say it does.
[02:59] <mdke> and I've got 0.92beta working as well
[02:59] <mdke> I just need a few fonts to try out
[03:00] <freeflying> mdke: seems theree haven't a fonts inlude all asian fonts
[03:01] <bddebian> Hello peoples
[03:01] <mdke> freeflying: ok. In that case I would think that we'll have to get a list of fonts for the various languages. What works for zh_CN?
[03:01] <freeflying> mdke: we r using ttf-arphic-uming
[03:01] <mdke> preferably ttf
[03:02] <bddebian> mdke is still messing with fonts? :-)
[03:02] <mdke> freeflying: ok. I haven't got that installed for some reason. I'll check it out
[03:02] <mdke> freeflying: is that likely to work well in print?
[03:02] <mdke> bddebian: yeah :/
[03:02] <bddebian> doko: You around by any chance?
[03:03] <freeflying> mdke: it's in ubuntu/kubuntu/edubuntu install cd,  it can work well in print
[03:03] <doko> bddebian: not for work
[03:03] <bddebian> ?
[03:03] <mdke> freeflying: yeah actually I have it installed, but it's not in /usr/share/fonts/truetype, I'll dig around
[03:04] <bddebian> doko: Not for a quick question? :-)
[03:04] <freeflying> mdke: it's in /usr/share/fonts/truetype/arphic/ 
[03:05] <mdke> oh yeah :)
[03:05] <bddebian> Anyone else know anything about eclipse/libswt?
[03:06] <doko> bddebian: what is wrong with eclipse?
[03:06] <mdke> freeflying: I'll mail you if I get a pdf working :)
[03:06] <freeflying> mdke: ok
[03:06] <bddebian> doko: Nothing, I'm looking at swingwt which needs libswt-gtk-dev.  Has something in eclipse replaced that?
[03:13] <_ion> Btw, here's my gimp-resynthesizer package in case anyone's interested. http://johan.kiviniemi.name/ubuntu/
[03:14] <bddebian> farg
[03:15] <doko> bddebian: please join #ubuntu-java
[03:15] <mdke> freeflying: fop is crashing with uming :-( I'm so unlucky
[03:15] <freeflying> mdke:  heh
[03:18] <popey> Can anyone tell me if evolution-caldav is likely to be ready for dapper?
[03:26] <Omeg> Hey infinity
[03:26] <Omeg> I e-mailed you a BDF font which I converted from that Zeta font that I showed earlier (the really small one).
[03:27] <Omeg> If that one seems to be operable, I'll remake that other font in BDF.
[03:27] <Omeg> It could be that your mail server ignored the e-mail because maybe it thinks "BDF" is a scary file format. :P
[03:40] <infinity> Omeg: No, I got it, but I'm also very busy.
[03:41] <Mithrandir> infinity: not to mention it being Sunday?
[03:42] <infinity> Mithrandir: Which makes it suck that much more that I'm ALSO busy. :/
[03:43] <bddebian> Who wants cheese with their whine?
[03:43] <Omeg> I do!
[03:43] <Omeg> Er.
[03:43] <Omeg> I thought you said wine.
[03:43] <Omeg> Tsh.
[03:43] <infinity> He was trying to be funny.
[03:44] <infinity> It didn't work.
[03:45] <tseng> hi bddebian 
[03:45] <bddebian> Heya tseng
[03:48] <kos_tom> is there any documentation about the procedure used to build the Ubuntu LiveCD (and particularly the initrd stuff) ?
[03:49] <Mithrandir> kos_tom: the initrd is built by just installing casper.
[03:51] <tseng> Mithrandir: it would be great if LiveCDCustomizationHowto were updated, hint wink
[03:51] <Mithrandir> tseng: it would be great if my day had 48 hours in it too. :-)
[03:51] <tseng> :)
[03:54] <pygi> Mithrandir, tseng, whoever: patch to enable internet connection settings in g-n-p .... do we need that? :)
[03:54] <Treenaks> Mithrandir: move a bit further north, you'll get 6-month days ;)
[03:56] <Mithrandir> Treenaks: true dat.  I'll get 6-month nights too, though.
[03:56] <Treenaks> Mithrandir: so? just skip a release cycle ;)
[03:56] <Mithrandir> pygi: uh, unsure.
[03:57] <Mithrandir> Treenaks: I think my boss might be unhappy about that. :-)
[03:57] <tseng> pygi: g* = seb128
[03:57] <tseng> pygi: but i doubt it, we are post feature freeze
[03:58] <tseng> since a long time ago
[03:59] <pygi> tseng: I know...someone suggested that as a SoC project :-/
[04:02] <tseng> oh, i dont know anything about that, sorry
[04:11] <j^> would it be possible to add something like 'find -name \*.glade -exec sed -i "s/<property name=\"invisible_char\">\*<\/property>//g" \{\} \;' to dh_install so that the default invisble char is used?
[04:16] <_ion> That would be nice.
[04:18] <j^> to also get those with translatable="yes", it would have to be: find -name \*.glade -exec sed -i "s/<property name=\"invisible_char\".*>\*<\/property>//g" \{\} \;
[04:22] <_ion> .* wouldn't be good, rather [^>] * instead.
[04:23] <_ion> sed -i 's#<property\>[^>] *\<name="invisible_char"[^>] *>\*</property>##g'
[04:23] <_ion> Maybe something like that.
[04:24] <infinity> Not sure why you're escaping < and > occasionally in that regex. :)
[04:24] <_ion> infinity: word boundary
[04:27] <infinity> Anyhow, adding hat sort of thing to dh_install is just plain wrong.
[04:27] <infinity> debhelper isn't meant to fix random bugs and odditied in packages, you should just patch the packages that do things "wrong".
[04:29] <j^> infinity i filed it as #bug 43369 
[04:29] <infinity> It seems about as silly as asking dh_clean to walk your source tree before you compile and fix random poor programming practices.
[04:29] <_ion> Maybe lintian should complain about <property\>[^>] *\<name="invisible_char"[^>] *>\*</property>
[04:29] <j^> the problem with fixing glade-2, which is generating those wrong glade files is that this will not fix it until the upstream author opens and saved the file in glade-2 again
[04:29] <j^> which could be -- never.
[04:30] <infinity> And you can't fix the packages directly with a simple patch?
[04:30] <j^> infinity this is again something you would have to do over and over again until glade-2 is fixed
[04:31] <infinity> And if I have documentation that has the above string in it, your dh_install hack wipes it out.
[04:31] <infinity> Yay.
[04:31] <infinity> (Or any other random scenario I can come up with where such a hack is obviously just plain wrong)
[04:32] <j^> infinity, fine with me that was just a suggestion, feel free to gome up with a better way
[04:32] <infinity> glade is source code, just like any other language.  If the source is buggy, fix it, don't rely on hepler tools to munge it.
[04:32] <infinity> (Sure, it's a whacky pseudo-source generated by an IDE, but that doesn't change anything)
[04:33] <infinity> If you really want invisible_char to be ignored completely, make libglade ignore it and always use the default.
[04:33] <j^> infinity http://bugzilla.gnome.org/show_bug.cgi?id=335702 is the bug to fix glade-2
[04:33] <infinity> (Or whatever will end up interpreting it at runtime)
[04:35] <j^> i dont want it to be ignored, i dont want the default to be set in each app again and again
[04:37] <j^> but since fixing this in every app that uses glade is not possible, patching libglade to ingore it + fixing glade-2 to not output it by default might be better than fixing .glade files during install
[04:38] <\sh> j^: so if the default is set in the .glade file, and libglade finds it, it overrules the global system setting?
[04:39] <infinity> (For that app)
[04:39] <\sh> strange..it sounds to me more a problem in handling application defaults over user/system defaults
[04:41] <j^> \sh global system setting is more changing the default in form of a patch
[04:41] <j^> so setting vs. default is lost
[04:42] <\sh> j^: well, application ships with default settings, e.g. password char #...now system settings should overrule the application setting, and user setting the system setting
[05:20] <kos_tom> huhu, modifying the initrd to support NFS seems to be trickier than I expected ;-(
[05:58] <sivang> who's the right person to bug about adding my blog to planet ubuntu feeds?
[05:59] <highvoltage> sivang: jdub
[05:59] <highvoltage> btw, am i right that you would be able to, upgrade from one enterprise release of ubuntu to the next, without all the steps inbetween?
[06:00] <sivang> highvoltage: no idea, but this seems rather something we should be better support.
[06:00] <highvoltage> sivang: *big nods*
[06:00] <sivang> highvoltage: I don't expect enterprises to hae to go throught troulbe of in-between releases, 
[06:00] <sivang> highvoltage: they might just swich to other distro.
[06:02] <highvoltage> as far as i understand, it might cost a lot of work for package maintainers to make sure the scripts inside the deb makes sure that it properly upgrades from the last version, and from a distro released 2 years ago... but then again, perhaps it's been thought through and solved already.
[06:03] <highvoltage> on the other side, re-installing once every three years isn't *that* bad... but i would like to see an upgrade, if i need it.
[06:03] <sivang> highvoltage: indeed. we need to remember that the universal operating system which we base off, promises no reinstalls. we should probably stick to this :)
[06:04] <highvoltage> yeah :)
[06:07] <HiddenWolf> a problem here is that it becomes rather difficult to see if your system gets damaged by the upgrade.
[06:07] <HiddenWolf> bugs aren't decent enough to tell if they stem from upgrading or not. :)
[06:08] <sivang> this could be solved by ridgid vmware enabled , release X to Y upgrades, and testing that system is usable and not flawed.
[06:09] <sivang> it could consume alot fo time, but I suspect there might not be fully automatic or better way to do so.
[06:10] <HiddenWolf> hm, is vmware free yet?
[06:11] <HiddenWolf> I was asked to test if a bug was around on the livecd too, but I'm too lazy to burn&reboot
[06:11] <HiddenWolf> :)
[06:16] <sivang> HiddenWolf: btw, you know I released a beta of hubackup to universe?
[06:17] <HiddenWolf> sivang: I saw. :)
[06:17] <HiddenWolf> sivang: will it eat my data, or can I try it? 
[06:18] <sivang> HiddenWolf: well, it's a beta, and experimental :) but I took great measures so it won't eat your data, but you know how the GPL goes..:)
[06:18] <sivang> "shall not be responsible.....nor for any purpose...etc blah"
[06:18] <HiddenWolf> sivang: licence good and well, but I know your IP. ;)
[06:19] <HiddenWolf> sivang: this is the part where you shiver. ;)
[06:19] <sivang> :)
[06:20] <sivang> HiddenWolf: well, could just be nice if you give it a test. I needs as much feedback to make this a worthy product. See about bugs already filed against the source package in LP, I provided there soem expleneation why media must reside (or usb drives must be plugged) prior to firing up the program so it ill find backup target devices. let me know if it finds your extenral hard drive
[06:21] <sivang> HiddenWolf: feel free to be aparnoid and run it on a dummy home folder of a dummy user
[06:21] <sivang> HiddenWolf: I won\t get offended :-)
[06:21] <HiddenWolf> sivang: as soon as I have an external drive. ;)
[06:21] <sivang> ah, well, you have a CDRW?
[06:22] <HiddenWolf> yeah. usbstick too. 
[06:23] <sivang> HiddenWolf: if you don't back up media files then usbstick could probably contain all your home
[06:23] <HiddenWolf> should be able to, yeah
[06:25] <sivang> anyway, time for some break.
[06:25] <sivang> laters
[06:25] <HiddenWolf> sivang: relax man, it's sunday :)
[06:26] <sivang> HiddenWolf: will do , thanks :)
[06:26] <HiddenWolf> sivang: shoo, go enjoy some good weather. :)
[06:27] <sivang> HiddenWolf: I actually need to take a nap, had a bad night and couldn't get too much sleep. but thanks for the offer
[06:27] <HiddenWolf> you should've napped this afternoon, in the sun somewhere. :)
[06:28] <HiddenWolf> (hint: works better without a laptop)
[06:29] <sivang> HiddenWolf: yeah, well, being sick I had to go to the doctor (actually sunday is a regular work day in .IL but I'm in a sick-day) , buy some stuff to eat etc, and then attended to some email and stuff. now is rest time :)
[06:29] <HiddenWolf> fair enough.
[06:30] <HiddenWolf> sivang: get well. :)
[06:38] <highvoltage> 2/win 4
[07:53] <elmo> doko: did you break apt on ia64?
[07:53] <elmo> apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory
[07:54] <doko> elmo: didn't touch that in the last months
[07:54] <elmo> well I haven't updated this chroot in a few months, but that's the state of apt after a dist-upgrade
[07:55] <elmo> oh, blah, sorry, I'm losing my mind
[07:55] <doko> it's from last July
[07:56] <elmo> I was in the wrong chroot (sid != dapper) - don't mind me
[07:58] <j^> svn: Unrecognized URL scheme for 'https:// ... hm
[08:23] <sivang>  /whois robertj robertj 
[08:24] <sivang> oops :)
[08:24] <sivang> robertj: I was trying to recall if you are the robertj I talked to about VideoCon framework that will be usable through client FOSS programs 
[08:24] <sivang> (that told me he takes part in development)
[08:49] <_ion> http://homepage.mac.com/bradster/iarchitect/images/mdsclue.gif :-D
[09:21] <sivang> _ion: nice to recall those horrific dialogs :) in which it it shows you it's always a loose-loose situation :)
[09:57] <Tuxist> hi
[10:59] <robertj> sivang: not me
[11:00] <robertj> sivang: was afk, but that's not me
[11:02] <ryan_rousseau> Hi everyone, I have submitted a proposal for a quizzing application to included in Edubuntu.  It is meant to be replacement for KWordQuiz.  I was wondering if there is anyone interested in mentoring such a project?
[11:24] <maxco> hello
[11:25] <maxco> is there graphical designer of ubuntu here ?
[11:25] <maxco> (not only programmer please)
[11:25] <winkle> try #ubuntu-art or something
[11:26] <maxco> okay thank you
[11:26] <winkle> seems to be +i though
[11:26] <maxco> arm
[11:26] <sivang> yes, I also cannot connect
[11:26] <mdke> *work
[11:28] <maxco> it is #ubuntu-artwork
[11:28] <maxco> I have a question for here
[11:28] <maxco> what does the developpers do for ubuntu ?
[11:29] <mdke> they maintain the software
[11:30] <maxco> they put their hands into C/C++ or it is only maintaining/organizing ubuntu in the hard system part ?
[11:30] <mdke> they do a bit of everything :) Lots of software gets written from scratch, lots is already written
[11:31] <maxco> okay
[11:32] <maxco> is one of the aims of ubuntu to create a "ubuntu desktop", ie. not only a customized Gnome ?
[11:32] <Seveas> @config channel plugins.bugtracker.bugsnarfer True
[11:33] <mdke> maxco: no, Ubuntu uses existing desktops, like Gnome (Ubuntu), KDE (Kubuntu), xfce (Xubuntu) etc
[11:34] <maxco> yes, but I mean, "making more than a Gnome with orange themes and icons"
[11:35] <maxco> "ubuntu software" or something like that
[11:36] <maxco> a Gnome desktop but with some tools/modifications only for ubuntu
[11:36] <maxco> hum I think it would be to Gnome devs to do that, not you
[11:37] <mdke> maxco: that's basically what is happening now. Things like Add/Remove Applications, and Update-Manager are tools which Ubuntu has added
[11:38] <maxco> yes exactly what I wanted to say !
[11:39] <maxco> okay, that mean that ubuntu devs takes care about developping more users friendly tools, great
[11:39] <sivang> they also make sure to push them back to the relevenat communities,
[11:40] <sivang> there is not too much ubuntu specifci parts, unless something limits their use in other communities like GNOME upstream, debian etc.
[11:40] <maxco> okay you make stuff in function of the community demands ?
[11:46] <sivang> maxco: mostly, yes.
[11:46] <sivang> maxco: every new feature starts as a specifciation proposal, then it's discussed drafter and get feedback from the community
[11:47] <sivang> maxco: the community can also participate in development, bug fixing etc
[11:47] <maxco> I think you are a lot claimed for XGL stuff ?
[11:58] <sivang> maxco: me?
[11:58] <maxco> developpers in general
[11:59] <sivang> maxco: well, Matthew Garret has indeed made XGL available from universe for dapper, with realtively fussless installation :)
[11:59] <maxco> ho, cool
[12:00] <maxco> personnally I will wait to get a more decent video card ( non ati ) :p
[12:01] <sivang> heh