[00:05] <sivang> could somebody remind me the nick of Dennis that wrote the theme code in usplash ?
[00:05] <sivang> (please ;))
[00:07] <_MMA_> Seveas (I believe)
[00:07] <sivang> _MMA_: thanks
[00:58] <YokoZar> Is there any hope for getting a newer (or older) fontforge?  The version in Hardy has a regression that's breaking Wine
[01:11] <_MMA_> YokoZar: Please file a bug in Launchpad.
[01:25] <pwnguin> well that was a fun exchange
 pwnguin: just remember when ever you feel the need say ubuntu is working on, its mostly a lie :)
[01:39] <YokoZar> _MMA_: https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/199331
[01:39] <ubotu> Launchpad bug 199331 in wine "Changes in fontforge cause Wine's marlett.ttf to have incorrect available character sets" [Undecided,New]
[01:40] <YokoZar> pwnguin: explain?  Does he mean we work on nothing, or that we work on completely different things than we say we do?
[01:40] <pwnguin> i think he means no ubuntu developers dont write code
[01:41] <pwnguin> and, at the risk of exposing the author, fedora does
[01:41] <pwnguin> err
[01:41] <pwnguin> wow, my grammar fails today
[01:41] <pwnguin> no ubuntu developers write code for upstream apparently
[01:43] <YokoZar> It wouldn't surprise me if, proportionately, the ratio of "ubuntu developers" writing code for upstream was less since we had more "upstream developers" essentially writing for Ubuntu
[01:45] <Chipzz> YokoZar: heh. 1) ubuntu doesn't have much developers writing code 2) most of the code being written by ubuntu developers is not for upstream, but for ubuntu itself
[01:45] <YokoZar> There's a few projects for which Ubuntu a majority of the user base, and the upstream developers run Ubuntu.  They're not technically Ubuntu devs, but it's not a terribly meaningful distinction.
[01:46] <Chipzz> and even then there's the question what "writing code" consists of
[01:46] <jcastro> YokoZar: next step is to get someone using wine in ubuntu to confirm the bug.
[01:46] <Chipzz> YokoZar: in a lot of cases, writing code actually boils down to testing/incorporating existing patches
[01:46] <jcastro> YokoZar: that should be easy to do
[01:47] <jcastro> that will get the bug on someone's radar
[01:47] <YokoZar> jcastro: There's one already in the wine bug list actually
[01:47] <Chipzz> but such is the case in other distro's too I guess
[01:47] <jcastro> I  mean in launchpad
[01:48] <jcastro> pwnguin: there are plenty of upstream projects that ubuntu contributes to. See LTSP5, upstart, jockey, etc. etc.
[01:49] <YokoZar> jcastro: By the way, I wanted to share with you something.  When I was at Fosscamp I came up with an idea that never would have occured to me without the interactions and suggestions of some of the other projects there (namely, a case-insensitive FUSE filesystem for Wine to put it's virtual drive in).  It's beyond my own abilities, so after getting back, I posted the idea in our wiki, and hoped someone else would take up the pr
[01:49] <Chipzz> jcastro: is jockey something that is used outside of ubuntu?
[01:49] <jcastro> Chipzz: it's shown interest by other distros
[01:49] <Chipzz> YokoZar: sounds like a bad idea
[01:49] <YokoZar> jcastro: This week we were talking about Google summer of code proposals on our devel list, so I mentioned the idea, and now someone is writing an application to do it.  There's a very good chance it'll happen by Hardy+1
[01:50] <Chipzz> YokoZar: looks like you're trying to hide one problem with another
[01:50] <YokoZar> Chipzz: You can see it here: http://wiki.winehq.org/CaseInsensitiveFilenames
[01:50] <Chipzz> s/looks/sounds/
[01:50] <Chipzz> YokoZar: I actively read the wine-dev ml. I still think it's a bad idea
[01:51] <YokoZar> There are a few problems really.  One is speed.  The other is that when a user extracts a zip file (say, a patch for a windows program) into his .wine folder, sometimes it doesn't overwrite everything it's supposed to due to case differences.  Wine can't tell which file to use then.
[01:51] <Chipzz> YokoZar: if wine wants case-insensitivity, they can do so in their codebase (perfectly possible)
[01:51] <YokoZar> Chipzz: That's exactly the point of a FUSE filesystem driver.  Wine would really be the only user of it.
[01:52] <Chipzz> YokoZar: also, sounds like a recipe to overcomplicate stuff, and make debugging much harder than it needs to be
[01:52] <Chipzz> also: *unnneeded* overhead
[01:52] <jcastro> YokoZar: has someone looked at how this fuse thing works out with the new gvfs thing in gnome?
[01:53] <YokoZar> Chipzz: Wine already does a bunch of software workarounds to get case insensitivity, and many of them are necessarily slow since they run in user space and we can't assume the folder is case-insensitive.  It's even why a bunch of applications don't work (see link) due to speed
[01:54] <Chipzz> YokoZar: can you explain to me why you would want a fuse file-system that 1) incurs overhead, 2) complicates debugging, 3) needs to be mounted, 4) requires the fuse kernel module when you can do all of this in the fopen calls wine implements?
[01:55] <YokoZar> Chipzz: You can read this bug to get an idea of what's going on: http://bugs.winehq.org/show_bug.cgi?id=3817
[01:55] <ubotu> Wine bug 3817 in -unknown "InstallShield very slow when copying many small files" [Normal,New]
[01:55] <jcastro> YokoZar: btw, if you run into things like this where you think I should know, just spam the bugs to me, jorge@ubuntu.com
[01:56] <YokoZar> jcastro: I just wanted to share that Fosscamp was useful, heh
[01:56] <YokoZar> Even if it takes months
[01:56] <jcastro> yeah
[01:57] <jcastro> I am kinf of swamped with upstreams right now, but you know what they say about the squeakey wheel.
[01:57] <jcastro> YokoZar: that last team report really rocked btw, keep that up please!
[01:58] <Chipzz> YokoZar: and how exactly would a fuse fs make that *faster*
[01:58] <Chipzz> it's still a bad idea
[01:58] <Chipzz> YokoZar: and you haven't addressed even one of my arguments
[02:00] <Chipzz> YokoZar: let alone the fact that 5) we probably won't use a fuse fs by default, or we would need to patch our version of wine, and the user would have the application fail at first, and then have to retry with a fuse fs?
[02:01] <YokoZar> Chipzz: Imagine Installshield is asking Wine to copy/overwrite FileFoo.bar to a folder.  In order to properly keep things in order, Wine has to make sure that FileFoo.bar, FileFOO.bar, FileFOo.bar, etc. don't exist - or if they do, that they be overwritten.  If Wine is in a case-insensitive FUSE filesystem, then it only has to do one check.
[02:02] <Chipzz> but the fuse fs would have to do 3 checks
[02:02] <Chipzz> now you have shifted 3 checks from wine to the fuse fs
[02:02] <Chipzz> and made the process more complicated
[02:02] <Chipzz> so you have gained nil, and made things more complex
[02:02] <Chipzz> that derinately sounds like an improvement, yes :P
[02:03] <Chipzz> additionally, like I said, the fuse layer will actually cause things to slow down
[02:03] <YokoZar> Chipzz: I'm not sure you understand the idea.  With the FUSE filesystem in control over the entirety of .wine, that's not an issue.  Imagine if it just put everything in upper case, then stored a text file next to it of what it translates to.  That doesn't require extra checks.
[02:03] <Chipzz> so you actually *lost*
[02:04] <Chipzz> and that's merely considering the case where it actually *matters*
[02:04] <YokoZar> Regarding compatilbilty: the developer is working with Wine upstream.  The likely migration path is for the FUSE folder to be created at wineprefixcreate time, and then stamp .wine somehow so Wine knows if it can assume case-insensitivity or if it has to use it's current workarounds.
[02:06] <Chipzz> it still doesn't matter IMO; wine can prevent the creation of overlapping filenames itself
[02:07] <Chipzz> the only thing you gain from having a fuse fs is that other external processes can't careate such files
[02:08] <Chipzz> which is a very small gain compared to the disadvantages I just listed
[02:08] <Chipzz> which, as I may point out, you still haven't bother to counter even one of
[02:09] <Chipzz> *bothered
[02:09] <Chipzz> ...
[02:25] <YokoZar> Chipzz: No, Wine can't.  The user might install overlapping filenames (such as by extracting a zip file, which is how many windows patches are distributed)
[02:26] <Chipzz> YokoZar: IMO wine should just error out then if it encounters 2 possible files for a file requested
[02:27] <Chipzz> and IMO, you aleady have lost anyway in that case
[02:27] <YokoZar> Regarding points: 1) Less overhead with FUSE than with Wine's constant filesystem checks.  2) The two systems are separate and it's not hard to have the debugger know what file it's operating on and when FUSE is being called. 3) wineserver itself can mount them, stuff like that is what it's for.  4) Wine's fopen calls are too slow (see bug)
[02:28] <Chipzz> can you actually prove 1)? I seriously doubt that
[02:28] <Chipzz> you have wine -> kernel -> fuse -> kernel -> wine
[02:28] <YokoZar> Chipzz: How do you propose getting those applications to work, then?  Asking the user to manually rename every individual file and cross check that it matches the name already in .wine?  I've done this myself, and it's a huge pain even when you know what to do.
[02:28] <Chipzz> that is *4* context switches
[02:28] <YokoZar> Chipzz: The overhead is not in software calls, it's in disk I/O
[02:29] <Chipzz> in which case you are assuming that fuse doesn't get interrupted by another process
[02:30] <Chipzz> that's 4, and I must add, VERY costly content switches
[02:30] <Chipzz> and we're talking *best* case scenario
[02:31] <Chipzz> s/content/context/
[02:31] <Chipzz> also
[02:31] <Chipzz> wine also runs on macosx and solaris
[02:31] <Chipzz> do you even have fuse there?
[02:31] <TheMuso> Yes, there is fuse for OS X. Can't exactly remember the name however.
[02:32] <YokoZar> Chipzz: maybe, maybe not.  This doesn't make Wine any worse since the old methods will still be there.
[02:32] <Chipzz> given alexandres attitude to patches, I have *very* serious doubts this will get accepted upstream
[02:33] <YokoZar> Chipzz: Alexandre is one of our approvers of summer of code projects.  None get started if they won't eventually get in.
[02:34] <YokoZar> Chipzz: The problem is we read from the disk too much to prove that a case insensitive file isn't there (or to find it if it is).  We do this many many times more often than once - in fact the number of times we need to do it grows with the length of a filename.
[02:34] <Chipzz> then you're doing it wrong
[02:34] <YokoZar> You should comment on that bug I linked earlier
[02:35] <Chipzz> YokoZar: a simple implementation would be a readdir and then subsequently comparing all filenames
[02:35] <Chipzz> 1) in most cases directory indexes are in subsequent sectors on the disk, so I have serious doubts about IO overhead
[02:36] <YokoZar> Check out that wiki page and that bug link, seriously.
[02:36] <Chipzz> 2) after the first readdir, the contents of that dir end up in the fs cache
[02:36] <Chipzz> I was reading the bug report
[02:40] <Chipzz> YokoZar: btw, please read: http://www.winehq.org/pipermail/wine-devel/2008-February/062249.html
[02:40] <Chipzz> 3rd rule
[02:41] <Chipzz> "* Comparing a 'windows string' with a unix one is out altogether (whether case insensitive or not) because they may not even be in the same encoding."
[02:41] <Chipzz> though that may be up for debate
[02:43] <Chipzz> YokoZar: also, lets say this does get implemented. Imagine the following use case: user starts wine, fuse fs gets mounted. user reboots, fuse fs not mounted yet. user says like you say he does, for example extract a zip file.
[02:44] <YokoZar> No we'd need to keep the fuse system mounted when the user logs in
[02:44] <Chipzz> I'm not sure about the semantics about fuse filesystems
[02:45] <Chipzz> ie wether they can be mounted automagically
[02:45] <YokoZar> By the way, I'm not sure I believe you that kernel->FUSE->kernel is an expensive context switch.
[02:45] <Chipzz> but if they can't, you have to modify the login scripts
[02:45] <Chipzz> I think it is
[02:45] <YokoZar> Especially that it's more expensive than having to do many many string comparisons for a given file
[02:46] <pwnguin> note that cache misses are killer
[02:46] <pwnguin> and the context switch usually forces a lot of cache and such out
[02:46] <Chipzz> pwnguin: you mean invalidate cache lines and such?
[02:46] <pwnguin> sure
[02:46] <Chipzz> yeah I was getting to that
[02:47] <pwnguin> i think i need to read the backlog
[02:48] <Chipzz> YokoZar: if I'm not mistaken kernel space and user space see two different address spaces. iirc this requires tlb trickery and such...
[02:48] <YokoZar> We don't have kernel support for keeping a coherent userspace cache anyway
[02:49] <Chipzz> YokoZar: for stuff like sshfs the fuse overhead is much less, since the slowness is in ssh anyway
[02:49] <Chipzz> I think it's an entirely different story with something local
[02:50] <YokoZar> Chipzz: reading the whole directory index is more expensive regarding disk I/O than we should need to just write one file
[02:51] <Chipzz> the one advantage fuse does have is indeed that you can keep the directory in some kind of cache, and you don't have to deal with inotify and such
[02:51] <Chipzz> OTOH
[02:52] <Chipzz> you have the same overhead that you have with loop-mounted devices
[02:52] <slangasek> YokoZar: what does this hypothetical case-insensitive fuse fs backend onto?
[02:53] <Chipzz> slangasek: use case is wine, which expects a case-insensitive fs
[02:53] <slangasek> I'm asking about the backend
[02:53] <Chipzz> ah k
[02:53] <Chipzz> EPARSE in that case
[02:53] <slangasek> what's your storage medium - you're writing some sort of loopback filesystem that can only be accessed through fuse?
[02:53] <slangasek> or you're writing a shim that sits on top of a POSIX directory?
[02:54] <Chipzz> YokoZar: anyway, why not just loopback mount a FAT system on top of wine?
[02:54] <slangasek> right, that's part of what I was getting at :)
[02:54] <YokoZar> slangasek: Good question.  That's yet to be determined, I think.  The shim sounds like it would be simpler, though we would have to worry about something other than FUSE writing to the folder.
[02:54] <Chipzz> in case the fuse fs is comparable with a loop mount
[02:55] <YokoZar> Chipzz: I've done that actually.  It's still slow and we lose some things (unix permissions)
[02:55] <Chipzz> YokoZar: which wine does not expect anyway?
[02:56] <YokoZar> At UDS we talked about not launching executables unless with WINE unless they had execute bit set, for instance.
[02:56] <YokoZar> On, say, double click
[02:56] <pwnguin> ive been wondering about that
[02:57] <pwnguin> why bother registering wine as a handler if you're not going to let me actually run stuff with it?
[02:57] <YokoZar> *not launching executables with Wine upon double click unless execute bit (and without it prompting)
[02:58] <Chipzz> YokoZar: also, like I pointed out, wine currently does not have any dependency on any special kernel interface. While this may happen in the future anyway, I'm guessing Alexandres reaction would be later rather than sooner
[02:58] <YokoZar> So, if you click a shortcut to run an application in Wine's start menu, that's an obvious "I want this application to run" command and we'll respect that.  If you double click a .exe file with execute bit, we'll run that too.  If you double click a .exe file without execute bit, we'll tell you it's an executable and ask you once (and only once) if you'd like to actually run it.
[02:59] <YokoZar> Chipzz: that's why it's a summer of code project ;)
[02:59] <StevenK> What about .exe's that aren't for Wine, like mono applications?
[03:00] <YokoZar> StevenK: There's a way to tell them apart (mono .exe that don't need Wine are ELF)
[03:00] <Chipzz> YokoZar: anyway, in my opinion a) you loose anyway since you can not, like I demonstrated earlier, actually prevent this from happening anyway, b) significant overhead
[03:00] <Chipzz> and one might argue that wine is not for newbies anyway
[03:01] <YokoZar> Prevent what?
[03:01] <YokoZar> The whole point of people like me is to make Wine usable ;)
[03:01] <Chipzz> prevent something writing to that dir while your fuse fs is not mounted
[03:02] <StevenK> /usr/lib/tomboy/Tomboy.exe: MS-DOS executable PE  for MS Windows
[03:02] <StevenK> .wine/drive_c/Program Files/World of Warcraft/Wow.exe: MS-DOS executable PE  for MS Windows
[03:02] <StevenK> YokoZar: ^
[03:02] <YokoZar> StevenK: hmm....  Wine's already registered in binutils as the handler...
[03:03] <Chipzz> YokoZar: I'm not sure you can make wine as perfect as being able to run 100% out-of-the-box anyway ;)
[03:05] <YokoZar> StevenK: You don't execute tomboy by calling /usr/lib/Tomboy.exe though
[03:06] <YokoZar> StevenK: You execute it by calling /usr/bin/tomboy which then calls mono and points to the exe
[03:06] <RAOF> But you can.  And people building other mono apps may run their executables directly.
[03:06]  * pwnguin wonders where paint.net would fall
[03:06] <RAOF> pwnguin: In all the windows-specific dllmaps, I'd expect :P
[03:07] <YokoZar> RAOF: That may be a bad idea.  The trouble is that we have no way to tell apart a mono app that requires Wine and one that can just run on Mono.  There are a bunch of mono apps that also use Win API stuff out there.  Getting (windows) mono working in Wine and gluing the two together is another project to tackle
[03:08]  * Chipzz gazes in disbelief at YokoZar 
[03:08] <Chipzz> dude, seriously
[03:08] <YokoZar> wait a second
[03:08] <YokoZar> Let me rephrase that
[03:08] <Chipzz> if you have been following wine, you should know wine and mono cooperating was discussed in the past and dismissed
[03:09] <Chipzz> or was that what you were going to rephrase? ;)
[03:09] <YokoZar> So right now Wine has trouble running .net apps.  Some of these are apps that use win32 apis that can't run in linux mono
[03:10] <YokoZar> One avenue for solving this is to install the windows version of mono into Wine.
[03:10] <Chipzz> YokoZar: btw, the .net installer (or one version of it) was recently gotten to install under wine ;)
[03:10] <YokoZar> Yeah, I read about that :)  But that's Microsoft, and we can't ship it.
[03:11] <Chipzz> are you sure of that actually?
[03:12] <Chipzz> anyway I think shipping a windows version of mono would be silly and not solve all the problems anyway
[03:13] <YokoZar> Chipzz: I'm pretty sure the MS .net runtime requires a windows license
[03:14] <Chipzz> in which case you loose for wine 100% working anyway
[03:15] <Chipzz> since for example the ie components are implemented with mozilla
[03:16] <YokoZar> Chipzz: The idea is if you can run the application on Windows XP with mono installed you should be able to run it in Wine (with mono installed)
[03:16] <Chipzz> yes
[03:16] <Chipzz> but I was pointing out something else
[03:18] <Chipzz> I was pointing out that since the wine guys are shipping mozilla, and some users expect html rendering to be done like IE does, you loose in these cases anyway
[03:18] <Chipzz> so if you're trying to get wine to be 100% bugfree, I'm saying you lost aleady
[03:18] <YokoZar> Yeah, we do.  An application like, say, steam might have its store render as though it were in firefox.  If they were relying on IE quirks it'd look weird.
[03:19] <Chipzz> worse
[03:19] <Chipzz> a use case for wine is something like IES4linux
[03:19] <Chipzz> (webdevelopers testing their webpages under wine)
[03:20] <YokoZar> You can replace Wine's builtin shdocvw with a microsoft one (which is what IES4linux does)
[03:20] <Chipzz> yeah
[03:20] <YokoZar> In which case then it behaves like IE again
[03:20] <Chipzz> but you just said you couldn't do such a thing with MS .Net
[03:20] <Chipzz> so if the point is 100% compat with windows, you loose anyway
[03:20] <YokoZar> All IE is is a wrapper around a rendering engine and a bunch of other calls.  We implement those calls, and provide the rendering engine using Gecko.  Ideally we'd use a Gecko in "IE quirks" mode, but no one's written that yet.
[03:21] <Chipzz> and that would be pretty much impossible too...
[03:22] <YokoZar> It'd be pretty boring to do, really.  What mozilla developer would want to replicate IE bugs?  Still, the kind of bugs this would cause would be limited to displays in the rendering engine, and would be fixable by installing native IE.
[03:23] <Chipzz> but displays in the rendering engine is *exactly* the whole point of IES4linux ;)
[03:23] <Chipzz> and you're correct in pointing out that no-one is interested in reproducing IE bugs ;)
[03:24] <YokoZar> Chipzz: Well, yeah.  If you need to test IE, you should install IE.  If you need to run steam, gecko will be fine.
[03:24] <Chipzz> indeed
[03:24] <Chipzz> the point I'm trying to make is you can't cater to 100% of the users
[03:25] <Chipzz> and quite frankly, I think someone extracting a zip file under linux on top of the fuse fs is someone who is not a total newbie anyway ;)
[03:26] <Chipzz> so I would argue if they can do that, they can possibly spot the duplicate files too ;)
[03:26] <YokoZar> As it stands it's a virtually impossible task for even me to do
[03:26] <YokoZar> Because you have to manually open all the subfolders and so on
[03:26] <Chipzz> so
[03:26] <Chipzz> why do you worry then? ;)
[03:27] <YokoZar> Because I can't install a patch that way without a huge headache, as easy as I can on Windows
[03:27]  * Chipzz notes this discussion is getting a bit... erm... well :P
[03:27] <Chipzz> wait
[03:27] <Chipzz> please explain the word task?
[03:28] <Chipzz> are you referring to navigating to the correct folder under .wine, and extracting a .zip file?
[03:28] <YokoZar> Chipzz: yes, but the zip file contains subfolders, and each of those had to be checked, and so on
[03:28] <YokoZar> Our current implementation in Wine is too slow (stuff like System Shock 2 takes literally hours to load a level).  I don't see how that can get any worse.
[03:28] <Chipzz> an alternative approach would be to have wine bail out in case it sees 2 conflicting filenames
[03:29] <YokoZar> You'd still have to detect them both then
[03:29] <YokoZar> And that's the problem we were trying to solve in the first place
[03:31] <Chipzz> actually, the problem you were trying to avoid was creating them in the first place ;)
[03:31] <Chipzz> but yeaj
[03:31] <Chipzz> *yeah
[03:33] <Chipzz> I'll just point out one last thing and go to bed then
[03:33] <Chipzz> if a newbie user was to extract said .zip file, a newbie would probably install winzip and use that ;)
[03:33] <Chipzz> much easier anyway
[03:34] <Chipzz> btw
[03:34] <Chipzz> I just thought of a really easy solution (not sure if that's mentioned in the bugreport)
[03:35] <Chipzz> just have wine lowercase all filenames it opens in .wine/<drive>
[03:35] <Chipzz> possibly maintaining it's own mapping on-disk (much like, was it joliet?)
[03:44] <YokoZar> Chipzz: that's sort of how I imagined the FUSE system working
[03:45] <YokoZar> Chipzz: the advantage of having FUSE do this rather than Wine is then we guarantee that something outside Wine's control isn't happening (say, zip file) and then don't still need to check for non lowercase files
[03:48] <YokoZar> oh btw the free-est .net MS provides is not free software (shared source, commercial use prohibited)
[03:51] <bddebian> Can we ask for a give-back just for a failed build?  I don't understand why testresources failed on i386.  It worked on the other archs and it builds fine for me in an i386 hardy pbuilder?
[04:26] <dbmoodb> colin watson + steve langasek  sorry if i was proving a pain a few days back
[04:27] <dbmoodb> please don't eat me - cannot sleep brain will eat me
[05:37] <TheMuso> c/
[07:23] <pitti> Good morning
[07:32] <Fujitsu> doko: Should you change to the ignore unknown -W* options in gcc-4.2 4.2.3-2ubuntu2 have caused anything to FTBFS? I've got a really strange one caused by it.
[07:33] <Fujitsu> *Should your
[07:33] <Fujitsu> s/the //, also. I can't think tonight, appparently.
[07:34] <emgent> morning
[07:40] <warp10> Good morning
[07:55] <pitti> TheMuso: hi
[07:55] <LaserJock> morning pitti
[07:55] <LaserJock> et al
[07:55] <pitti> TheMuso: can you please have a look at bug 177382? Do you think it's something that we shuold fix for hardy? (it's marked as qa-hardy-list)
[07:55] <ubotu> Launchpad bug 177382 in postgresql-8.3 "pg_dump produces invalid SQL" [Undecided,Fix released] https://launchpad.net/bugs/177382
[07:55] <pitti> hi LaserJock
[07:55] <pitti> TheMuso: if so, is this something you're interested in working on?
[07:56] <pitti> TheMuso: erk, EWRONGBUG, sorry; I mean bug 127705
[07:56] <ubotu> Launchpad bug 127705 in compiz "compiz doesn't "talk" when switching windows" [High,Confirmed] https://launchpad.net/bugs/127705
[07:57] <pitti> mvo: can I nag you about verifying bug 198129?
[07:57] <ubotu> Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129
[08:08] <dholbach> good morning
[08:09] <Fujitsu> Hey dholbach.
[08:09] <dholbach> hiya Fujitsu
[08:15] <mvo> pitti: yes
[08:15] <\sh> moins
[08:16] <\sh> testing alpha6 in vbox :)
[08:28] <mvo> pitti: I'm starting my VMs now
[08:31] <soren> Can any one member of ubuntu-release acknowledge an FFe?
[08:37] <TheMuso> pitti: I've worked around it for the speech/braille profiles on the live CD at least, by turning compiz off.
[08:37] <TheMuso> But long term, it needs fixing yes. I'm just looking at the upstream bug to see where things stand.
[08:37] <tjaalton> pitti: how does the jockey cmdline-interface work? I can't find a way to enable a driver, "jockey-gtk -e kmod:nvidia_new" segfaults
[08:43] <asac> pitti: soren: ok, i unmilestone the NM bug about virtual interfaces for now.
[08:44] <encompass> hi guys, I know your all really busy with alpha 6 but just wondering if we have a list for GSoC ideas yet?
[08:45] <encompass> I am interested in doing another application this year. :D
[08:47] <dholbach> encompass:  http://brainstorm.ubuntu.com/ ? :)
[08:49] <soren> asac: Ok. We'll revisit for intrepid.
[08:50] <encompass> dholbach: oh yeah, got piles of idea from there
[08:50] <encompass> dholbach: but they are required to have one for the application as an organization, so... were she be :)
[08:51] <encompass> dholbach: thanks for the pointer... it is great for people looking for something to do in linux that people like
[08:51] <asac> soren: fine. just let me know.
[08:51] <dholbach> encompass: no problem :)
[08:51] <slytherin> Hi all.
[08:52] <slytherin> Network manager applet is not updated to 6.6rc2 but network-manager is. Was this intentional?
[08:54] <\sh> grmpf...hardy-server kernel doesn't like vbox
[08:56] <soren> \sh: I'm guessing it's really the other way around, but ok.. :)
[09:00] <\sh> soren: yeah :)
[09:01] <\sh> oh vmwares patched via vmware-any-any-update vmmon.tar needs a another patch...asm/bitopts.h is wrong in vcpuset.h
[09:07] <\sh> but I have to say...hardy looks real cool...the language selection directly in the cd boot screen is awesome
[09:08] <Tonio__> slangasek: hey ;)
[09:08] <Tonio__> slangasek: just rebuilt knetworkmanager, but still unable to connect to any wireless network
[09:08] <Tonio__> slangasek: wired connection works
[09:09] <Tonio__> slangasek: what is the status of nm-applet ?
[09:15] <TomaszD> hello friendly devs! :] a bite-size bug for anyone who has two minutes to spare https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/199413
[09:15] <ubotu> Launchpad bug 199413 in vlc "Please include Polish translation for .desktop file (diff included)" [Undecided,New]
[09:17] <slytherin> TomaszD: vlc is in universe. you should ask on #ubuntu-motu
[09:19] <pitti> hm, I thought scim was disabled again by default with the latest updates?
[09:19] <pitti> martin   11799  0.0  0.0      0     0 ?        Z    09:13   0:00 [scim] <defunct>
[09:19] <\sh> dholbach: would you like to share your "really fix it now" bug fetching script? :)
[09:19] <pitti> and some scim-{launcher,helper-manager,panel-gtk} processes
[09:24] <dholbach> \sh: it's in a really hacked-up state right now - let me fix up a few problems first :)
[09:25] <\sh> dholbach: ok :) I just wondered how many times you let it run (once per day?) :)
[09:26] <dholbach> \sh: it was broken that's why it did not run overnight - I think it runs every 4 hours right now
[09:26] <\sh> dholbach: cool :)
[09:32] <tjaalton> pitti: did you notice my question about jockey? the bug was about adding a real cmndline tool to enable the drivers, not just starting the gui with some options :)
[09:32] <Tonio_> hi sabdfl, \sh, pitti, dholbach !
[09:32] <pitti> tjaalton: no, I missed it; on IRC?
[09:32] <tjaalton> pitti: yes
[09:33] <tjaalton> pitti: how does the jockey cmdline-interface work? I can't find a way to enable a driver, "jockey-gtk -e kmod:nvidia_new" segfaults
[09:33] <pitti> tjaalton: ah, you mean --enable and --disable should not ask for confirmation? right, that's true
[09:33] <tjaalton> pitti: hehe, so that's what it's trying to do
[09:33] <pitti> tjaalton: segfaults??
[09:33] <dholbach> hey Tonio_
[09:34] <pitti> tjaalton: I didn't implement package installation with out synaptic and $DISPLAY yet, that's still on TODO.txt
[09:34] <pitti> tjaalton: i. e. it shuold fall back to apt-get install
[09:34] <pitti> tjaalton: so that, and not asking for confirmation should do what you want, right?
[09:34] <\sh> hoi Tonio_
[09:34] <Tonio_> \sh: were our pykdeextensions changes commited upstream ?
[09:35] <tjaalton> pitti: yes, something like that
[09:35] <\sh> Tonio_: it doesn't look like it :(
[09:35] <Tonio_> \sh: :'(
[09:35] <tjaalton> pitti: preferably so that it works on the d-i chroot (which shouldn't be a problem)
[09:36] <pitti> tjaalton: hm, no xorg.conf there yet, right? another bug in jockey (doesn't support creating xorg.conf from scratch, also on TODO)
[09:37] <tjaalton> pitti: I'm thinking of running jockey at some stage after the packages are installed, so xorg.conf is definately there
[09:38] <pitti> ah, ok
[09:38] <pitti> tjaalton: can you elaborate about the segfault a bit?
[09:38] <tjaalton> pitti: a bunch of pango errors and then boom.. the box is reinstalling atm so I can give the output in 30min
[09:41] <sabdfl> hey Tonio_
[09:41] <TomaszD> slytherin, ok
[09:49] <TomaszD> slytherin, but \sh does vlc uploads from what I've noticed, and he's no motu :]
[09:53] <lool> pitti: Heya
[09:53] <lool> pitti: I'd like to discuss #186647
[09:54] <lool> pitti: I need testers and I also wonder whether I should go for an UVF and then talk to you for the promotion or rather whether you should test and promote it because it's related anyway?
[09:55] <dholbach> looking at http://daniel.holba.ch/really-fix-it there are myriads of acpi-support and acpid patches
[09:56] <lool> dholbach: indeed, but this package is hairy
[09:56] <lool> Lots of hardware quirks
[09:56] <dholbach> yeah
[09:56] <pwnguin> some people dont even bother with ubuntu
[09:56] <cjwatson> there seems to be no way to reject a patch such that it will no longer appear on really-fix-it
[09:56] <pwnguin> they just push upstream and let ubuntu grab it back
[09:56] <lool> I tried maintaining it in Debian for some time, but it was too much work and I left it to buxy and a NM
[09:57] <pwnguin> i know a guy's working on toshiba stuff that way
[09:57] <lool> cjwatson: Even removing the patch flag?
[09:57] <cjwatson> what, editing the attachment?
[09:57] <lool> Yes
[09:57] <dholbach> cjwatson: I know it's know ideal - deleting the attachment or the patch flag are the only ways right now :/
[09:57] <cjwatson> ah, if you can do that ...
[09:57] <lool> That's what I've been doing at least; I know it's the improper thing to do, but it is an approximation
[09:57] <cjwatson> mkay, no problem
[09:58] <lool> We should have patch statuses like bugzilla
[09:58] <dholbach> or having everything in bzr ;-)
[09:58] <pitti> lool: UVF doesn't exist any more
[09:59] <lool> pitti: Whatever it's called that I talk to MOTU to get a new feature in universe
[09:59] <pitti> lool: since the current packages are completely broken, we need to sync them anyway, I guess )
[09:59] <pitti> lool: ah, right, for universe you need a bug for new upstream version
[09:59] <lool> pitti: Ok; I'll push them then
[09:59] <pitti> I keep forgetting
[09:59] <pitti> lool: so please get their formal ack and then turn it into a sync request?
[09:59] <lool> Since they don't work at all at the moment, it's best to push them and that's all
[09:59] <lool> pitti: Ok
[09:59] <pitti> right
[10:00] <pitti> Hobbsee will glady give her ack, I'm sure :)
[10:00]  * Hobbsee looks in
[10:00] <Hobbsee> dholbach: fixed the 5-a-day problem, btw
[10:00] <soren> Can any release team member ack an FFe?
[10:00] <dholbach> Hobbsee: yeah, got the email about it :-)))
[10:01] <dholbach> Hobbsee: doko had the same problem: you both weren't part of the team
[10:01] <Hobbsee> soren: which release team?
[10:01] <soren> ubuntu-release
[10:01] <soren> Or is it all slangasek these days?
[10:01] <Hobbsee> soren: technically, yes.  i don't think tehy would though
[10:01] <Hobbsee> soren: oh.  well, i've done the odd bit, and not been shot by slangasek
[10:02] <Hobbsee> bug #186647
[10:02] <ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New] https://launchpad.net/bugs/186647
[10:04] <Ng> dholbach: some of the acpi-support patches are definitely not right ;)
[10:04] <Hobbsee> lool, pitti:  ack given in -motu
[10:04] <pitti> thanks
[10:04] <lool> Hobbsee: thanksely
[10:07] <pitti> (topic diff: remove alpha-6 freeze)
[10:07] <seb128> pitti: thanks
[10:16] <tjaalton> pitti: huh, now it didn't segfault, but the first run gave me an BadAlloc error, second time works
[10:17] <pitti> tjaalton: hm; jockey is 100% python...
[10:18] <soren> Yeah. Don't you just love it when scripting languages segfault?
[10:18] <soren> Well, interpreters for scripting languages, that is.
[10:18] <tjaalton> pitti: it's the gtk stack that failed
[10:31] <mvo> pitti: a debdiff would be nice for the verification so that I get a better idea what changed and what tzdump commands will give me a clue if the changes are there
[10:31] <mvo> pitti: unless you are happy with regression testing only
[10:31] <pitti> mvo: ah, indeed; I just applied the patch in http://article.gmane.org/gmane.comp.time.tz/2094
[10:32] <mvo> ok, thanks
[10:32] <pitti> mvo: regression testing appreciated, too (I did some light testing already)
[10:39] <slytherin> pitti: I suppose you handle hal-info package, right? I have a question related to same.
[10:39] <pitti> slytherin: yes, I do
[10:41] <slytherin> pitti: I noticed a blog on planet GNOME recently which says network-manager should also work with GSM phone connections over usb provided appropriate information is available in fdi files. Do you think we should make a 'call for phone informations (tried and tested)'. Or do you think users should send such information directly to upstream?
[10:41] <mvo> pitti: dapper is good, going for the other ones now
[10:42] <pitti> slytherin: it's fine to send them to the ubuntu bug tracker; I usually collect them, clean them up a bit, and forward them to upstream
[10:42] <pitti> they're welcome to send them to upstream themselves in addition, of course
[10:43] <Hobbsee> superm1: oh, did soyuz give back your binaries btw?
[10:43] <slytherin> The reason I am asking is that it will reduce the headache for configuring internet through mobile (over usb at least).
[10:44] <slytherin> provided we have information about enough handsets
[10:51] <zdzichu_1> I believe using phone as modem ove BT is waaaaay more popular than by USB
[10:52] <zdzichu_1> in fact, I haven't seen anyone with cable to his phone
[10:58] <seb128> cjwatson: bug #198759 is not likely a xkeyboard-config one since it happens in a VT too, where should it be reassigned?
[10:58] <ubotu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759
[10:58] <slytherin> zdzichu_1: Right, but BT configuration still needs many file changes I think. So if we can automate at least one way (USB) with help of NM it is better than nothing.
[10:59] <zdzichu_1> slytherin: it just need "hcitool cc <mac_of_phone>" to have phone appear as serial port. further configuration is the same as when connecting by USB
[11:01] <slytherin> zdzichu_1: No that is what I am saying. As per this blog - http://blogs.gnome.org/dcbw/2008/03/02/networkmanager-your-gsm-mobile-and-you/ - the step to create a chatscript is eliminated. And the connection is managed with NM.
[11:03] <cjwatson> seb128: it is xkeyboard-config
[11:03] <cjwatson> seb128: the VT keymap is generated from the exact same data
[11:04] <seb128> cjwatson: ah ok
[11:04] <cjwatson> seb128: I was looking at it this morning; it seems intentional to some extent, rctrl is set to be a level5 shift in that keymap
[11:04] <seb128> cjwatson: I though xkeyboard-config was used by xorg only
[11:04] <cjwatson> but I couldn't see how to get to level4, so I haven't commented on the bug yet
[11:04] <cjwatson> seb128: not since console-setup in edgy
[11:05] <seb128> alright, thanks
[11:05] <seb128> I asked on IRC because you are not subscribed to the bug
[11:05] <mvo> pitti: verification is done
[11:05] <seb128> so I'm not sure if you were reading comments there
[11:05]  * pitti hugs mvo, thank you!
[11:05] <mvo> cheers
[11:07] <cjwatson> seb128: oops, subscribed to it now
[11:07] <seb128> thanks
[11:27] <pitti> doko: did you get any feedback about the new sun-java5 in dapper-proposed?
[11:28] <doko> pitti: no, I have to ping people again
[11:41] <tjaalton> there are new security releases of sun-java*
[12:00] <PecisDarbs> nm 0.6.6 will be in hardy?
[12:00] <pitti> PecisDarbs: already uploaded
[12:00] <PecisDarbs> great
[12:01] <PecisDarbs> thanks for info :)
[12:02] <slytherin> So does the new version of nm-applet also include so called 'configuration UI'?
[12:53] <dholbach> MOTU Q&A Session in 7 minutes in #ubuntu-classroom
[12:57] <dholbach> keescook, doko: does the patch at bug 196274 make sense?
[12:57] <ubotu> Launchpad bug 196274 in gdb "gdb 6.7 can SIGSEGV when printing state" [Undecided,New] https://launchpad.net/bugs/196274
[13:00] <doko> dholbach: 6.8 would be nicer =)
[13:01] <dholbach> right :)
[13:30] <bbg1> hei
[13:30] <bbg1> nobody say something ?
[13:37] <ogra_cmpc> pitti, i have re-uploaded classmate-tools (now with copyright files :) ) ... if you find a spare minute
[13:43] <Riddell> evand: where is progress_cancel_button hidden in the ubiquity gtk_ui?
[13:44] <Riddell> debconf_progress_cancellable() never seems to get called
[13:46] <pitti> ogra_cmpc: oh, sure
[13:46] <ogra_cmpc> thanks
[13:47] <ogra_cmpc> pitti, the current package still has the dep on classmate-settings (sorry, missed that) , i have fixed that locally already ...
[13:47] <ogra_cmpc> (i can upload ubuntu2 if you need)
[13:50] <pitti> ogra_cmpc: that's fine (upload it anyway)
[13:50] <pitti> ogra_cmpc: btw, no XSBC-O-M necessary for ubuntu specific packages (just FYI, it's not actually a problem)
[13:51] <pitti> ogra_cmpc: and you might want to remove the double dependency on ubuntu-desktop
[13:51] <ogra_cmpc> who knows probably debian pulls it some day :)
[13:51] <pitti> Recommends: xserver-xorg-video-i810
[13:51] <pitti> that's really intended?
[13:51] <pitti> (not -intel?)
[13:51] <ogra_cmpc> well
[13:51] <ogra_cmpc> it actually depends on it
[13:52] <ogra_cmpc> but i didnt want to make it a hard dep since you could use it o non classmate (eeepc)
[13:52] <ogra_cmpc> with other non xrandr drivers
[13:52] <pitti> ok, so -i810 instead of -intel is deliberate
[13:52] <ogra_cmpc> -intel doesnt allow panning
[13:52] <ogra_cmpc> if you set the Virtual directive in intel it expects a second monitor
[13:53] <ogra_cmpc> if you do the same in i810 you get a panning screen
[13:53] <pitti> Encoding=UTF-8
[13:53] <pitti> ogra_cmpc: ^ please remove that from the .desktop files
[13:53] <ogra_cmpc> i'd prefer intel but he two functions are mutually exclusive
[13:53] <ogra_cmpc> oh, why ?
[13:53] <pitti> that's fine; if you say "yes, that's correct and wanted", I'm good
[13:53] <pitti> Encoding: is obsolete; lintian should complain
[13:54] <ogra_cmpc> ok
[13:54] <pitti> accepted
[13:54] <ogra_cmpc> (it didnt when i created the package)
[13:54] <pitti> ogra_cmpc: feel free to upload your fix now
[13:54] <ogra_cmpc> oki, thanks for that :)
[14:07] <evand> Riddell: it's called in components/install.py and the button is defined in gui/glade/ubiquity.glade
[14:19] <Riddell> evand: but if I add a debug line to debconf_progress_cancellable() it never gets called
[14:20] <evand> hrm
[14:27] <Riddell> evand: so it gets hidden in the gtk frontend, but I don't know how.  it doesn't get hidden in the qt frontend and we do implement debconf_progress_cancellable()
[14:33] <evand> Riddell: I'm taking a look now
[14:33] <amitk> ogra_cmpc: you plan to use i386-generic kernels for classmate, correct?
[14:34] <ogra_cmpc> `i use -generic atm
[14:34] <ogra_cmpc> not i386
[14:34] <amitk> ogra_cmpc: the arch is 1386 though
[14:34] <ogra_cmpc> it proved to not be slower anymore with 2.6.24 unlike gutsys kernel
[14:34] <ogra_cmpc> yeah
[14:35] <amitk> ogra_cmpc: splendid, just enabling USB_PERSIST for you, you can try it with the beta release
[14:35] <ogra_cmpc> yay
[14:35]  * ogra_cmpc dances
[14:35] <amitk> ogra_cmpc: :)
[14:36]  * ogra_cmpc makes a tag on the "beer for amit" list
[14:36] <ogra_cmpc> :)
[15:27] <evand> Riddell: Fixed and committed.  setCancelButton causes the cancelButton to be shown again, so I just moved the call to hide after that.
[15:29] <Keybuk> random question of the day -- anyone know of a syscall to find out the name of a core file? :)
[15:30] <Riddell> evand: ah hah, thanks
[15:30] <pitti> Keybuk: syscall? you mean /proc/sys/kernel/core_pattern ?
[15:30] <Keybuk> pitti: that won't tell me the name of a core dump
[15:30] <evand> Riddell: you're welcome
[15:30] <pitti> Keybuk: well, that's what the kernel uses as core file name (plus .$pid)
[15:30] <Keybuk> ie. wait() returns CLD_DUMPED for a child process; how do I find the dump?
[15:31] <Keybuk> pitti: right, but because of %t, it's impossible to expand that to figure out what the core file is actually called
[15:31] <pitti> ah; for that you'd need to know the cwd of the crashed process, and with apport core_pattern is a pipe, etc.
[15:31] <pitti> so in summary I don't think that there's a 100% robust method
[15:31] <Keybuk> exactly
[15:31]  * Keybuk was kinda hoping there was a prctl() or something
[15:32] <pitti> Keybuk: last time I read that kernel code there wasn't :(
[16:09] <Amaranth> ogra_: can you take a look at bug 192882?
[16:09] <ubotu> Launchpad bug 192882 in xaos "Xaos display problem with compiz" [Low,Confirmed] https://launchpad.net/bugs/192882
[16:10] <Amaranth> ogra_cmpc: ^
[16:16] <ogra_cmpc> Amaranth, there is some work going on in debian i hope to get in, i have to check, might be the fix is included
[16:18] <ogra_cmpc> Amaranth, bug 197261 there are some changes in xlib.c and ui_x11.c ... i suspect thats related
[16:18] <ubotu> Launchpad bug 197261 in xaos "please merge xaos 3.2-7 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/197261
[16:24] <Amaranth> ogra_cmpc: Nope, that doesn't appear to be related
[16:25] <ogra_cmpc> ok
[16:25] <ogra_cmpc> i'll include it in the merge then
[16:28] <Amaranth> ogra_cmpc: thanks
[16:29] <Amaranth> now i just have to figure out a way to do the same thing to eagle
[16:42] <Riddell> evand: you might want to look at my last ubiquity commit and see if it's sensible and should be done to the gtk side
[16:44] <evand> Riddell: will do, thanks
[17:04] <keescook> dholbach: I don't know the gdb code base very well, but if the patch is in upstream, it sounds like it wouldn't hurt to add it
[17:06] <dholbach> keescook: doko said we might want the new upstream version *shrug*
[17:06] <dholbach> keescook: it was just one of the things on  http://daniel.holba.ch/really-fix-it  that looked interesting
[17:09] <keescook> dholbach: yeah.  I'm disappointed with gdb upstream in general -- they continue to not incorporate PIE-handling patches.
[17:10] <keescook> dholbach: should I just upload the patch anyway?  If we get 6.8 it'll already be in there.
[17:10] <dholbach> keescook: I know about gdb much much less than you do :)
[17:10] <dholbach> doko: ^ what do you think?
[17:11] <doko> keescook: what about the pie patch?
[17:12] <keescook> doko: is it actually in 6.7?
[17:13] <doko> keescook: disabled
[17:13] <keescook> doko: yeah, that's what I thought.  :(
[17:14] <lool> dholbach: Do you recall the glom issue with updating it in stable?
[17:14] <doko> keescook: who did you contact for that patch, or did you pull it from somewhere?
[17:14] <lool> dholbach: murrayc is bringing it up again, he mentions https://bugs.edge.launchpad.net/ubuntu/+source/glom/+bug/186869
[17:14] <ubotu> Launchpad bug 186869 in glom "Can't change field types" [Undecided,Incomplete]
[17:14] <lool> dholbach: Would you like to take a look?
[17:15] <keescook> doko: Elena Zannoni, no reply.  the patch is carried by every distro, but it doesn't apply to 6.7.
[17:15] <dholbach> lool: -backports might be a better idea then if the patch is really that big
[17:16] <lool> dholbach: Ack; if you recall the history, he complains that users don't get backports by default
[17:16] <dholbach> well... he can attach the full diff, then subscribe motu-sru to get an ACK for it
[17:18] <lool> dholbach: I thought you were updating glom and deps in the past so thought you wanted to guide him further in the process, but I can suggest what you just said if you prefer me to
[17:19] <dholbach> lool: I don't a lot of packages any more - I can add that myself
[17:19] <dholbach> don't maintain
[17:21] <dholbach> DktrKranz2 already mentioned how to proceed in this case
[17:23] <lool> dholbach: thanks
[17:24] <dholbach> de rien
[17:40] <lool> pitti: Re: elisa and stuff, python-twill currently uninstallable which is a dep of elisa; doko told me to check with jinty whether it was ok to update python-mechanize and I just got a yet
[17:40] <lool> *yes
[17:40] <lool> pitti: Could you please sync python-mechanize/0.1.7b-2 from unstable?
[17:41] <lool> Will solve python-twill installability
[17:41] <pitti> any new features that need an exception in 1.7b?
[17:42] <lool> pitti: Not that I know of, but it's only used to run the testsuite of schooltool and zope, so it only endangers not being able to run the testsuite
[17:45] <pitti> ah, ok
[17:45] <pitti> lool: zzzzzzzzzynced
[17:46] <lool> pitti: thanksssss and good WE
[17:46] <pitti> lool: and to you!
[18:04] <tkamppeter> Anyone of Ubiquity here?
[18:05] <tkamppeter> Riddell, ping
[18:07] <Keybuk> GRRRRR
[18:07] <Keybuk> dear gnome-power-manager/HAL - STOP PLAYING MY SCREEN BRIGHTNESS
[18:07] <Riddell> tkamppeter: hi
[18:08] <tkamppeter> Riddell, AFAIR you are working with dual-GUI (KDE/GNOME) applications in Ubuntu.
[18:08] <tkamppeter> Is this correct?
[18:09] <Ng> Keybuk: 137598? ;)
[18:09] <Keybuk> it's not resetting to maximum
[18:09] <Keybuk> it's dimming
[18:09] <tkamppeter> bug 137598
[18:09] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [High,Triaged] https://launchpad.net/bugs/137598
[18:11] <Riddell> tkamppeter: yes a bit
[18:12] <tkamppeter> Riddell, I am organizing the mentoring organization application of the Linux Foundation, especially because most project ideas are from OpenPrinting.
[18:13] <tkamppeter> One of the project ideas is the coding of the Common Printing Dialog:
[18:13] <tkamppeter> https://www.linux-foundation.org/en/Google_Summer_of_Code#Common_Printing_Dialog:_Coding_on_the_dialog_designed_by_OpenUsability.2C_for_KDE_and.2For_GNOME
[18:13] <ion_> Dear scim, please do not তুডগী with my keyboard layout by default each time i hit ctrl-space or shift-space, kthxbye. :-)
[18:14] <Riddell> tkamppeter: looks like a good project, what do you need me for?
[18:15] <tkamppeter> Riddell, this is a printing dialog which OpenUsability has designed in the last two years.
[18:15] <tkamppeter> Applications should all use this dialog called via Portland and the desktop (KDE or GNOME) should provide it.
[18:16] <tkamppeter> To minimize coding effort it would be great to implement it as a dual-GUI app.
[18:16] <Keybuk> eurgh
[18:16] <tkamppeter> Now I am searching for an expert on dual-GUI apps to mentor this project.
[18:16] <Keybuk> I *HATE* Portland
[18:16] <tkamppeter> Keybuk, why?
[18:16]  * slangasek bristles patriotically
[18:17] <slangasek> :-)
[18:17] <Keybuk> because Qt and GTK+ are more than just a "theme"
[18:17] <Keybuk> they're a way of working, interface guidelines, etc.
[18:19] <Keybuk> trying to make a Qt application look like a GTK+ one means that you confuse people who know Qt applications because it doesn't look like one, but works like one
[18:19] <Keybuk> and you confuse people who know GTK+ applications because it looks like one, but doesn't work like one
[18:19] <Keybuk> and we end up with hideous "cross platform" monstrosities like Firefox and OpenOffice
[18:20] <Keybuk> where the most basic functionality like copy and paste don't even work right
[18:20] <tkamppeter> Keybuk how would you implement that the user sees the same "Open", "Save as", "Print", and "Export to PDF" dialogs, all from the desktop currently in use, independent of the application which the user is using, for example if a user starts a KDE application under GNOME he gets the standard dialogs from GNOME?
[18:20] <Keybuk> let alone file opening, etc.
[18:20] <Keybuk> tkamppeter: I don't think they *SHOULD*
[18:20] <ion_> Is there a program where copy and paste work right? ;-)
[18:20] <Keybuk> a KDE application uses KIOParts to access files, etc.
[18:21] <Keybuk> a GNOME application use GVFS
[18:21] <Keybuk> these two fundamentally different systems mean that they access files in fundamentally different ways
[18:21] <zul> slangasek:  samba question for you about the if-up.d bug if you were around
[18:21] <slangasek> zul: shoot
[18:21] <Keybuk> so the GNOME dialog boxes aren't even feature compatible with what KDE applications can do
[18:22] <Keybuk> and then you have the ridiculous affair where the user is using KDE/Qt application
[18:22] <Keybuk> is used to the way they look, the way they work, etc.
[18:22] <Keybuk> the tabbing order, button order, layout
[18:22] <Keybuk> and clicks a perfectly ordinary looking button, and gets *something else*
[18:22] <Keybuk> so a Qt application suddenly has a GTK+ dialog box
[18:22] <zul> slangasek: there is a fix for it upstream https://bugzilla.samba.org/show_bug.cgi?id=5267 patch looks ok to mathiaz and me
[18:22] <ubotu> bugzilla.samba.org bug 5267 in nmbd "nmbd shuts down when network interfaces go down" [Normal,Resolved: fixed]
[18:23] <trip0> offtopic: who owns trolltech now?
[18:23] <Keybuk> trip0: Nokia, iirc
[18:23] <Riddell> tkamppeter: I mostly do python apps, but this would presumably be c/c++ so I expect less code could be shared.  but yes I could in principle mentor that
[18:23] <trip0> keybuk: i think you are right, thansk
[18:23] <Riddell> trip0: trolltech's shareholders until the Nokia deal goes through
[18:25] <tkamppeter> Keybuk, the idea of the Common Print Dialog is to not confuse users. Users will see the same OpenUsability-designed printing dialog with all applications and so if they are familiar with printing in one app, printing in another app will be trivial for him.
[18:25] <Keybuk> I really, honestly, think that Portland is a nightmare waiting to happen
[18:25] <Keybuk> the right thing to do is to separate the model and policy from the view
[18:25] <Keybuk> so you can write separate native UIs for each desktop environment
[18:25] <Keybuk> where the UI follows the interface guidelines of that DE
[18:25] <Keybuk> and hook into the common model/control code
[18:25] <ion_> True
[18:26] <slangasek> zul: I think in the end it's less elegant than doing an if-up.d script because it gives us an nmbd process that has to poll when we already have an OS that *knows* when the interfaces come up and can trigger an nmbd restart, but if it's committed upstream then I guess there's no harm in taking it
[18:26] <Keybuk> tkamppeter: so they will see a dialog box that doesn't fit in with any desktop environment?
[18:26] <Keybuk> and behaves differently to anything else they might have used?
[18:26] <Riddell> tkamppeter: I'm about to go out now, e-mail me if you have more questions
[18:26] <zul> slangasek: sounds good
[18:26]  * Keybuk fails to see how the term "Usability" applies here
[18:26] <tkamppeter> And the parameters needed to print (printer, paper size, quality, n-Up, ...) are given by CUPS and the printer driver and so they are the same under KDE and GNOME.
[18:26] <Keybuk> tkamppeter: but the dialog *should not be* the same
[18:26] <slangasek> zul: oh, what happens for nmbd started at *boot* time when there are no active interfaces?  will it go into this same "reload_interfaces" loop, or will it still just shut down?
[18:27] <zul> slangasek: no idea
[18:27] <tkamppeter> Riddell, thank you for your offer, if you know someone more into C/C++ working on dual-GUI apps, please tell me.
[18:27] <slangasek> zul: might want to check that first then, the if-up.d solution might still be the cleaner option :)
[18:28] <zul> slangasek: ok will do
[18:29] <tkamppeter> Riddell, to be a GSoC mentor you need to have a Google account, if you have none yet, create one. Please tell me your Google user name or GMail address. Thanks.
[18:30] <Riddell> tkamppeter: "riddell"
[18:30] <Riddell> @gmail.com
[18:33] <zul> slangasek: it looks like its controlled by NMBD_INTERFACES_RELOAD
[18:34] <tkamppeter> Riddell, thank you very much. I will add you as a mentor for this project. If you find someone who is even more suitable in terms of dual-GUI apps in C/C++, please let me know.
[19:23] <keescook> asac: is 44062 fixed in ff3 now?  I was just reviewing security bugs in "fix committed" state.
[19:23] <mathiaz> slangasek: I've got a merge of mysql-dfsg-5.0 ready to be uploaded - do I need a FFe before I upload ?
[19:23] <Daviey> dreamnid:
[19:24] <asac> bug 44062
[19:24] <ubotu> Launchpad bug 44062 in firefox-3.0 "Firefox allows cookies to be set for second-level domain hierarchies" [Undecided,Fix committed] https://launchpad.net/bugs/44062
[19:26] <mathiaz> slangasek: http://paste.ubuntu-nl.org/58787/ - .changes file
[19:29] <slangasek> mathiaz: you need a FFe if it introduces new features
[19:30] <mathiaz> slangasek: ok. In that case, no.
[20:34] <slangasek> hmm... maybe we should refresh the screenshot of the world clock applet in the alpha release notes to not show a version which thinks it's simultaneously 6:18 AM in Sydney, Cape Town, and Porto Alegre
[20:35] <Mithrandir> it's evidence of a flat world.
[21:09] <davmor2> Hi guys the new world clock applet just crashed out my system when I hit okay for selecting Birmingham as location name :(  (The one in England rather than state side)  Is this known at all?
[21:11] <LaserJock> maybe it's got something against England ;-)
[21:11] <davmor2> LaserJock: :P
[21:13] <Seveas> LaserJock, probably just birmingham
[21:14] <Seveas> we can live without it
[21:14] <davmor2> I can select London as timezone but when I go for Birmingham as location it dies.
[21:14] <davmor2> Seveas: True but then I'm in wolverhampton so it don't bother me ;)
[21:18] <_MMA_> davmor2: Does the same here to me. Kills the whole panel.
[21:19] <davmor2> _MMA_: Ah found a bug then :)
[21:19] <LaserJock> maybe it's an Easter egg
[21:21] <_MMA_> davmor2: You can add it manually but you have to find the Lat/Long.
[21:22] <davmor2> _MMA_ I cheated I just selected London as Time zone then changed London the Birmingham.  Probably not right but I didn't care :)
[21:23] <davmor2> LaserJock: That's just wrong!
[21:24] <LaserJock> davmor2: a little tribute to Birmingham residents ;-)
[21:24] <_MMA_> I also notice that if I try to change the time settings (set system time) using the button on the applet the Authentication dialog comes up *under* the time settings. Where I cant get to it.
[21:25] <_MMA_> I have to move the Time Settings dialog out of the center of the screen 1st.
[21:25] <seb128> _MMA_: the focus issue is a known bug
[21:25] <seb128> changing locations work correctly here
[21:26] <slangasek> davmor2: are you editing or adding a new location?
[21:26] <seb128> system crashing is not an applet bug, whatever an user app is doing the system should not crash
[21:26] <davmor2> Adding new
[21:27] <jdstrand> slangasek: hi!
[21:27] <slangasek> davmor2: awesome, confirmed here
[21:27] <_MMA_> seb128: Hmm... Also after authentication the Time Settings dialog crashes. Lemmie see if I can figure it out.
[21:27] <slangasek> I love the world clock
[21:27] <jdstrand> slangasek: so does removing strings in an initscript require an FFe?
[21:27] <davmor2> seb128: I has only done it once the rest of the time the taskbars vanish and reappear
[21:28] <slangasek> jdstrand: "removing strings"?
[21:28] <davmor2> s/I/It
[21:28] <_MMA_> slangasek: I would also if I could set it to use UTC independent of the system settings like the old one. :(
[21:28] <seb128> davmor2: that is a gnome-panel bug and a known issue I think
[21:28] <jdstrand> slangasek: thinking of string freeze-- these aren't translated
[21:28] <jdstrand> slangasek: there was some debugging output in ufw's initscript that I just removed
[21:28] <slangasek> jdstrand: oh, no (and string freeze is separate from Feature Freeze)
[21:28] <seb128> slangasek: btw I doubt your "don't use network" bug will be fixed before hardy so you are welcome to work on a patch if you really care
[21:28] <blueyed> jdstrand: removing is no problem. it means less work in the worst case.
[21:28] <jdstrand> it wasn't just debugging, but it was too verbose
[21:29] <slangasek> seb128: can't we just revert to the one that wasn't insane and weather-y? ;)
[21:29] <davmor2> Cosford works which is up the road so it is just Birmingham
[21:29] <seb128> jdstrand: feeze string is about no adding new strings, because doing that make non-english users have not translated strings, removing some should be no issue
[21:29] <slangasek> seb128: another bug report coming, btw :)
[21:30] <jdstrand> seb128, blueyed, slangasek: I thought as much, but wanted to be sure.  thanks!
[21:30] <seb128> slangasek: and about duplicate old bugs from new one, I duplicate new comers, the other one was confirmed and milestoned already
[21:30] <slangasek> seb128: the "newcomer" was also milestoned, fwiw...
[21:31] <seb128> because you milestoned it when you found about it
[21:31] <davmor2> seb128: slangasek: Do you want me to report the clock issue if it isn't already?
[21:31] <seb128> let's say I had the other one at the right place and handled
[21:31] <slangasek> seb128: I'm pretty sure someone else milestoned it and all I did was move the milestone around
[21:31] <seb128> davmor2: no
[21:32] <davmor2> Okay Np's
[21:32] <slangasek> no?  because it's already reported, or...?
[21:32] <seb128> slangasek: alright, no big deal anyway, it just has been reassigned this week and I got mail then when I already had the other one handled some time ago
[21:32] <seb128> slangasek: no because it's a known issue yes
[21:32] <seb128> let me get the bug number
[21:33] <slangasek> ok
[21:33] <_MMA_> seb128: The clock applet is called gnome-clock-applet? I want to put in a feature request to add back the ability to use UTC.
[21:33] <seb128> _MMA_: it's in gnome-panel
[21:33] <seb128> _MMA_: can't you add an UTC location and use this one?
[21:34] <_MMA_> The old clock could use 12hr/24hr/UTC. I no longer see this option.
[21:34] <seb128> I've 12-24 on the top of the dialog there
[21:35] <_MMA_> Yep
[21:35] <seb128> ok, so you just don't see utc
[21:35] <seb128> why using an utc location doesn't work?
[21:35] <_MMA_> I personally set 1 clock to local and a 2nd to UTC. Lets me coordinate better with people.
[21:38] <_MMA_> seb128: And all the location gives me is GMT which isnt always the same. I also cant just look at the panel and see at a glance.
[21:38] <seb128> what do you mean?
[21:39] <_MMA_> If you set the old clock to UTC it showed that in the panel correct?
[21:39] <seb128> right
[21:39] <_MMA_> That's what I'm after.
[21:39] <seb128> well, feel free to open a bug, better on bugzilla
[21:39] <seb128> that's a valid wishlist
[21:40] <seb128> nobody complained about that yet I think
[21:40] <_MMA_> Sure. Hence the request for the applet name.
[21:40]  * _MMA_ goes off to find the place to request it.
[21:40] <seb128> not sure how many users really want that on the panel all the time rather than having a location for it and if upstream removed it on purpose because it's not that useful
[21:40] <seb128> _MMA_: gnome-panel, clock applet
[21:41] <_MMA_> k
[21:41] <_MMA_> Thanx
[21:42] <seb128> davmor2, slangasek: http://bugzilla.gnome.org/show_bug.cgi?id=513284
[21:42] <ubotu> Gnome bug 513284 in clock "crash in Panel: Clicking Ok in the 'add ..." [Critical,New]
[21:43] <davmor2> seb128: Cool np's
[21:51] <amitk> keescook: we don't have any plans to move to gcc 4.3, right? http://lwn.net/Articles/272048/rss
[21:59] <keescook> amitk: for intrepid yes.  (I can't read the article -- subscriber only)
[22:00] <slangasek> keescook: summary: gcc-4.3 is now respecting a bit of the x86 ABI that it's never respected before, and the kernel doesn't comply with this bit of the x86 ABI, so the "direction flag" bit is now leaking
[22:01] <slangasek> seems like it would be a good idea to get the kernel for hardy fixed wrt this issue regardless, who knows who else will be building binaries with gcc-4.3
[22:01] <amitk> keescook: slangasek: but there is already a fix to the kernel upstream, so we will have it in intrepid
[22:01] <keescook> eeexcellent.  :)
[22:01] <slangasek> amitk: right; but third-party binaries might be built with gcc-4.3 for installation on hardy...
[22:03] <amitk> slangasek: true
[22:04] <amitk> and hardy is LTS
[22:07] <slangasek> seb128: one more worldclock bug filed for you; I'm done now, at least for the nonce ;)
[22:16] <seb128> slangasek: right
[22:16] <seb128> anyway that will be for next week, enough work for this one
[22:16] <seb128> see you later
[22:39] <Kopfgeldjaeger> n8
[23:02] <nepbabu> Is it OK to copy over snippet of text from https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700 while giving the full link in my blog?
[23:03] <nepbabu> is this the right place to ask or what?
[23:05] <jdong> nepbabu: I believe the license for wiki content is https://wiki.ubuntu.com/DocumentationTeam/License
[23:05] <nepbabu> jdong, reading :D
[23:05] <jdong> IANAL but it sounds like what you are doing meets the requirements
[23:06] <nepbabu> jdong, it's just a personal blog
[23:06] <nepbabu> nothing fancy
[23:06] <nepbabu> jdong, tia