[00:05] could somebody remind me the nick of Dennis that wrote the theme code in usplash ? [00:05] (please ;)) [00:07] <_MMA_> Seveas (I believe) [00:07] _MMA_: thanks [00:58] 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] well that was a fun exchange [01:25] pwnguin: just remember when ever you feel the need say ubuntu is working on, its mostly a lie :) [01:39] _MMA_: https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/199331 [01:39] Launchpad bug 199331 in wine "Changes in fontforge cause Wine's marlett.ttf to have incorrect available character sets" [Undecided,New] [01:40] pwnguin: explain? Does he mean we work on nothing, or that we work on completely different things than we say we do? [01:40] i think he means no ubuntu developers dont write code [01:41] and, at the risk of exposing the author, fedora does [01:41] err [01:41] wow, my grammar fails today [01:41] no ubuntu developers write code for upstream apparently [01:43] 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] 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] 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] and even then there's the question what "writing code" consists of [01:46] YokoZar: next step is to get someone using wine in ubuntu to confirm the bug. [01:46] YokoZar: in a lot of cases, writing code actually boils down to testing/incorporating existing patches [01:46] YokoZar: that should be easy to do [01:47] that will get the bug on someone's radar [01:47] jcastro: There's one already in the wine bug list actually [01:47] but such is the case in other distro's too I guess [01:47] I mean in launchpad [01:48] pwnguin: there are plenty of upstream projects that ubuntu contributes to. See LTSP5, upstart, jockey, etc. etc. [01:49] 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] jcastro: is jockey something that is used outside of ubuntu? [01:49] Chipzz: it's shown interest by other distros [01:49] YokoZar: sounds like a bad idea [01:49] 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] YokoZar: looks like you're trying to hide one problem with another [01:50] Chipzz: You can see it here: http://wiki.winehq.org/CaseInsensitiveFilenames [01:50] s/looks/sounds/ [01:50] YokoZar: I actively read the wine-dev ml. I still think it's a bad idea [01:51] 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] YokoZar: if wine wants case-insensitivity, they can do so in their codebase (perfectly possible) [01:51] Chipzz: That's exactly the point of a FUSE filesystem driver. Wine would really be the only user of it. [01:52] YokoZar: also, sounds like a recipe to overcomplicate stuff, and make debugging much harder than it needs to be [01:52] also: *unnneeded* overhead [01:52] YokoZar: has someone looked at how this fuse thing works out with the new gvfs thing in gnome? [01:53] 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] 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] 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] Wine bug 3817 in -unknown "InstallShield very slow when copying many small files" [Normal,New] [01:55] 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] jcastro: I just wanted to share that Fosscamp was useful, heh [01:56] Even if it takes months [01:56] yeah [01:57] I am kinf of swamped with upstreams right now, but you know what they say about the squeakey wheel. [01:57] YokoZar: that last team report really rocked btw, keep that up please! [01:58] YokoZar: and how exactly would a fuse fs make that *faster* [01:58] it's still a bad idea [01:58] YokoZar: and you haven't addressed even one of my arguments [02:00] 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] 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] but the fuse fs would have to do 3 checks [02:02] now you have shifted 3 checks from wine to the fuse fs [02:02] and made the process more complicated [02:02] so you have gained nil, and made things more complex [02:02] that derinately sounds like an improvement, yes :P [02:03] additionally, like I said, the fuse layer will actually cause things to slow down [02:03] 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] so you actually *lost* [02:04] and that's merely considering the case where it actually *matters* [02:04] 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] it still doesn't matter IMO; wine can prevent the creation of overlapping filenames itself [02:07] the only thing you gain from having a fuse fs is that other external processes can't careate such files [02:08] which is a very small gain compared to the disadvantages I just listed [02:08] which, as I may point out, you still haven't bother to counter even one of [02:09] *bothered [02:09] ... [02:25] 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] YokoZar: IMO wine should just error out then if it encounters 2 possible files for a file requested [02:27] and IMO, you aleady have lost anyway in that case [02:27] 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] can you actually prove 1)? I seriously doubt that [02:28] you have wine -> kernel -> fuse -> kernel -> wine [02:28] 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] that is *4* context switches [02:28] Chipzz: The overhead is not in software calls, it's in disk I/O [02:29] in which case you are assuming that fuse doesn't get interrupted by another process [02:30] that's 4, and I must add, VERY costly content switches [02:30] and we're talking *best* case scenario [02:31] s/content/context/ [02:31] also [02:31] wine also runs on macosx and solaris [02:31] do you even have fuse there? [02:31] Yes, there is fuse for OS X. Can't exactly remember the name however. [02:32] Chipzz: maybe, maybe not. This doesn't make Wine any worse since the old methods will still be there. [02:32] given alexandres attitude to patches, I have *very* serious doubts this will get accepted upstream [02:33] Chipzz: Alexandre is one of our approvers of summer of code projects. None get started if they won't eventually get in. [02:34] 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] then you're doing it wrong [02:34] You should comment on that bug I linked earlier [02:35] YokoZar: a simple implementation would be a readdir and then subsequently comparing all filenames [02:35] 1) in most cases directory indexes are in subsequent sectors on the disk, so I have serious doubts about IO overhead [02:36] Check out that wiki page and that bug link, seriously. [02:36] 2) after the first readdir, the contents of that dir end up in the fs cache [02:36] I was reading the bug report [02:40] YokoZar: btw, please read: http://www.winehq.org/pipermail/wine-devel/2008-February/062249.html [02:40] 3rd rule [02:41] "* 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] though that may be up for debate [02:43] 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] No we'd need to keep the fuse system mounted when the user logs in [02:44] I'm not sure about the semantics about fuse filesystems [02:45] ie wether they can be mounted automagically [02:45] By the way, I'm not sure I believe you that kernel->FUSE->kernel is an expensive context switch. [02:45] but if they can't, you have to modify the login scripts [02:45] I think it is [02:45] Especially that it's more expensive than having to do many many string comparisons for a given file [02:46] note that cache misses are killer [02:46] and the context switch usually forces a lot of cache and such out [02:46] pwnguin: you mean invalidate cache lines and such? [02:46] sure [02:46] yeah I was getting to that [02:47] i think i need to read the backlog [02:48] 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] We don't have kernel support for keeping a coherent userspace cache anyway [02:49] YokoZar: for stuff like sshfs the fuse overhead is much less, since the slowness is in ssh anyway [02:49] I think it's an entirely different story with something local [02:50] Chipzz: reading the whole directory index is more expensive regarding disk I/O than we should need to just write one file [02:51] 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] OTOH [02:52] you have the same overhead that you have with loop-mounted devices [02:52] YokoZar: what does this hypothetical case-insensitive fuse fs backend onto? [02:53] slangasek: use case is wine, which expects a case-insensitive fs [02:53] I'm asking about the backend [02:53] ah k [02:53] EPARSE in that case [02:53] what's your storage medium - you're writing some sort of loopback filesystem that can only be accessed through fuse? [02:53] or you're writing a shim that sits on top of a POSIX directory? [02:54] YokoZar: anyway, why not just loopback mount a FAT system on top of wine? [02:54] right, that's part of what I was getting at :) [02:54] 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] in case the fuse fs is comparable with a loop mount [02:55] Chipzz: I've done that actually. It's still slow and we lose some things (unix permissions) [02:55] YokoZar: which wine does not expect anyway? [02:56] At UDS we talked about not launching executables unless with WINE unless they had execute bit set, for instance. [02:56] On, say, double click [02:56] ive been wondering about that [02:57] why bother registering wine as a handler if you're not going to let me actually run stuff with it? [02:57] *not launching executables with Wine upon double click unless execute bit (and without it prompting) [02:58] 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] 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] Chipzz: that's why it's a summer of code project ;) [02:59] What about .exe's that aren't for Wine, like mono applications? [03:00] StevenK: There's a way to tell them apart (mono .exe that don't need Wine are ELF) [03:00] 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] and one might argue that wine is not for newbies anyway [03:01] Prevent what? [03:01] The whole point of people like me is to make Wine usable ;) [03:01] prevent something writing to that dir while your fuse fs is not mounted [03:02] /usr/lib/tomboy/Tomboy.exe: MS-DOS executable PE for MS Windows [03:02] .wine/drive_c/Program Files/World of Warcraft/Wow.exe: MS-DOS executable PE for MS Windows [03:02] YokoZar: ^ [03:02] StevenK: hmm.... Wine's already registered in binutils as the handler... [03:03] YokoZar: I'm not sure you can make wine as perfect as being able to run 100% out-of-the-box anyway ;) [03:05] StevenK: You don't execute tomboy by calling /usr/lib/Tomboy.exe though [03:06] StevenK: You execute it by calling /usr/bin/tomboy which then calls mono and points to the exe [03:06] 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] pwnguin: In all the windows-specific dllmaps, I'd expect :P [03:07] 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] dude, seriously [03:08] wait a second [03:08] Let me rephrase that [03:08] if you have been following wine, you should know wine and mono cooperating was discussed in the past and dismissed [03:09] or was that what you were going to rephrase? ;) [03:09] 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] One avenue for solving this is to install the windows version of mono into Wine. [03:10] YokoZar: btw, the .net installer (or one version of it) was recently gotten to install under wine ;) [03:10] Yeah, I read about that :) But that's Microsoft, and we can't ship it. [03:11] are you sure of that actually? [03:12] anyway I think shipping a windows version of mono would be silly and not solve all the problems anyway [03:13] Chipzz: I'm pretty sure the MS .net runtime requires a windows license [03:14] in which case you loose for wine 100% working anyway [03:15] since for example the ie components are implemented with mozilla [03:16] 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] yes [03:16] but I was pointing out something else [03:18] 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] so if you're trying to get wine to be 100% bugfree, I'm saying you lost aleady [03:18] 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] worse [03:19] a use case for wine is something like IES4linux [03:19] (webdevelopers testing their webpages under wine) [03:20] You can replace Wine's builtin shdocvw with a microsoft one (which is what IES4linux does) [03:20] yeah [03:20] In which case then it behaves like IE again [03:20] but you just said you couldn't do such a thing with MS .Net [03:20] so if the point is 100% compat with windows, you loose anyway [03:20] 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] and that would be pretty much impossible too... [03:22] 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] but displays in the rendering engine is *exactly* the whole point of IES4linux ;) [03:23] and you're correct in pointing out that no-one is interested in reproducing IE bugs ;) [03:24] 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] indeed [03:24] the point I'm trying to make is you can't cater to 100% of the users [03:25] 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] so I would argue if they can do that, they can possibly spot the duplicate files too ;) [03:26] As it stands it's a virtually impossible task for even me to do [03:26] Because you have to manually open all the subfolders and so on [03:26] so [03:26] why do you worry then? ;) [03:27] 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] wait [03:27] please explain the word task? [03:28] are you referring to navigating to the correct folder under .wine, and extracting a .zip file? [03:28] Chipzz: yes, but the zip file contains subfolders, and each of those had to be checked, and so on [03:28] 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] an alternative approach would be to have wine bail out in case it sees 2 conflicting filenames [03:29] You'd still have to detect them both then [03:29] And that's the problem we were trying to solve in the first place [03:31] actually, the problem you were trying to avoid was creating them in the first place ;) [03:31] but yeaj [03:31] *yeah [03:33] I'll just point out one last thing and go to bed then [03:33] if a newbie user was to extract said .zip file, a newbie would probably install winzip and use that ;) [03:33] much easier anyway [03:34] btw [03:34] I just thought of a really easy solution (not sure if that's mentioned in the bugreport) [03:35] just have wine lowercase all filenames it opens in .wine/ [03:35] possibly maintaining it's own mapping on-disk (much like, was it joliet?) [03:44] Chipzz: that's sort of how I imagined the FUSE system working [03:45] 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] oh btw the free-est .net MS provides is not free software (shared source, commercial use prohibited) [03:51] 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] colin watson + steve langasek sorry if i was proving a pain a few days back [04:27] please don't eat me - cannot sleep brain will eat me [05:37] c/ === kagou is now known as kagou_ [07:23] Good morning [07:32] 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] *Should your [07:33] s/the //, also. I can't think tonight, appparently. [07:34] morning [07:40] Good morning [07:55] TheMuso: hi [07:55] morning pitti [07:55] et al [07:55] 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] Launchpad bug 177382 in postgresql-8.3 "pg_dump produces invalid SQL" [Undecided,Fix released] https://launchpad.net/bugs/177382 [07:55] hi LaserJock [07:55] TheMuso: if so, is this something you're interested in working on? [07:56] TheMuso: erk, EWRONGBUG, sorry; I mean bug 127705 [07:56] Launchpad bug 127705 in compiz "compiz doesn't "talk" when switching windows" [High,Confirmed] https://launchpad.net/bugs/127705 [07:57] mvo: can I nag you about verifying bug 198129? [07:57] Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129 === \sh_away is now known as \sh [08:08] good morning [08:09] Hey dholbach. [08:09] hiya Fujitsu === \sh is now known as \sh_away === \sh_away is now known as \sh [08:15] pitti: yes [08:15] <\sh> moins [08:16] <\sh> testing alpha6 in vbox :) === \sh is now known as \sh_away === \sh_away is now known as \sh [08:28] pitti: I'm starting my VMs now === The_Company is now known as Company [08:31] Can any one member of ubuntu-release acknowledge an FFe? [08:37] pitti: I've worked around it for the speech/braille profiles on the live CD at least, by turning compiz off. [08:37] But long term, it needs fixing yes. I'm just looking at the upstream bug to see where things stand. [08:37] 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] pitti: soren: ok, i unmilestone the NM bug about virtual interfaces for now. [08:44] 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] I am interested in doing another application this year. :D === hunger_t is now known as hunger [08:47] encompass: http://brainstorm.ubuntu.com/ ? :) [08:49] asac: Ok. We'll revisit for intrepid. [08:50] dholbach: oh yeah, got piles of idea from there [08:50] dholbach: but they are required to have one for the application as an organization, so... were she be :) [08:51] dholbach: thanks for the pointer... it is great for people looking for something to do in linux that people like [08:51] soren: fine. just let me know. [08:51] encompass: no problem :) [08:51] Hi all. [08:52] 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] \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 === jsgotangco is now known as greeneggsnospam [09:08] slangasek: hey ;) [09:08] slangasek: just rebuilt knetworkmanager, but still unable to connect to any wireless network [09:08] slangasek: wired connection works [09:09] slangasek: what is the status of nm-applet ? === Tonio__ is now known as Tonio_ [09:15] 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] Launchpad bug 199413 in vlc "Please include Polish translation for .desktop file (diff included)" [Undecided,New] [09:17] TomaszD: vlc is in universe. you should ask on #ubuntu-motu [09:19] hm, I thought scim was disabled again by default with the latest updates? [09:19] martin 11799 0.0 0.0 0 0 ? Z 09:13 0:00 [scim] [09:19] <\sh> dholbach: would you like to share your "really fix it now" bug fetching script? :) [09:19] and some scim-{launcher,helper-manager,panel-gtk} processes === Tonio__ is now known as Tonio_ [09:24] \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] \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] 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] hi sabdfl, \sh, pitti, dholbach ! [09:32] tjaalton: no, I missed it; on IRC? [09:32] pitti: yes [09:33] 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] tjaalton: ah, you mean --enable and --disable should not ask for confirmation? right, that's true [09:33] pitti: hehe, so that's what it's trying to do [09:33] tjaalton: segfaults?? [09:33] hey Tonio_ [09:34] tjaalton: I didn't implement package installation with out synaptic and $DISPLAY yet, that's still on TODO.txt [09:34] tjaalton: i. e. it shuold fall back to apt-get install [09:34] tjaalton: so that, and not asking for confirmation should do what you want, right? [09:34] <\sh> hoi Tonio_ [09:34] \sh: were our pykdeextensions changes commited upstream ? [09:35] pitti: yes, something like that [09:35] <\sh> Tonio_: it doesn't look like it :( [09:35] \sh: :'( [09:35] pitti: preferably so that it works on the d-i chroot (which shouldn't be a problem) [09:36] 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] pitti: I'm thinking of running jockey at some stage after the packages are installed, so xorg.conf is definately there [09:38] ah, ok [09:38] tjaalton: can you elaborate about the segfault a bit? [09:38] pitti: a bunch of pango errors and then boom.. the box is reinstalling atm so I can give the output in 30min [09:41] hey Tonio_ [09:41] slytherin, ok [09:49] slytherin, but \sh does vlc uploads from what I've noticed, and he's no motu :] [09:53] pitti: Heya [09:53] pitti: I'd like to discuss #186647 [09:54] 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] looking at http://daniel.holba.ch/really-fix-it there are myriads of acpi-support and acpid patches [09:56] dholbach: indeed, but this package is hairy [09:56] Lots of hardware quirks [09:56] yeah [09:56] some people dont even bother with ubuntu [09:56] there seems to be no way to reject a patch such that it will no longer appear on really-fix-it [09:56] they just push upstream and let ubuntu grab it back [09:56] 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] i know a guy's working on toshiba stuff that way [09:57] cjwatson: Even removing the patch flag? [09:57] what, editing the attachment? [09:57] Yes [09:57] cjwatson: I know it's know ideal - deleting the attachment or the patch flag are the only ways right now :/ [09:57] ah, if you can do that ... [09:57] 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] mkay, no problem [09:58] We should have patch statuses like bugzilla [09:58] or having everything in bzr ;-) [09:58] lool: UVF doesn't exist any more [09:59] pitti: Whatever it's called that I talk to MOTU to get a new feature in universe [09:59] lool: since the current packages are completely broken, we need to sync them anyway, I guess ) [09:59] lool: ah, right, for universe you need a bug for new upstream version [09:59] pitti: Ok; I'll push them then [09:59] I keep forgetting [09:59] lool: so please get their formal ack and then turn it into a sync request? [09:59] Since they don't work at all at the moment, it's best to push them and that's all [09:59] pitti: Ok [09:59] right [10:00] Hobbsee will glady give her ack, I'm sure :) [10:00] * Hobbsee looks in [10:00] dholbach: fixed the 5-a-day problem, btw [10:00] Can any release team member ack an FFe? [10:00] Hobbsee: yeah, got the email about it :-))) [10:01] Hobbsee: doko had the same problem: you both weren't part of the team [10:01] soren: which release team? [10:01] ubuntu-release [10:01] Or is it all slangasek these days? [10:01] soren: technically, yes. i don't think tehy would though [10:01] soren: oh. well, i've done the odd bit, and not been shot by slangasek [10:02] bug #186647 [10:02] Launchpad bug 186647 in pigment "promote to main" [Undecided,New] https://launchpad.net/bugs/186647 [10:04] dholbach: some of the acpi-support patches are definitely not right ;) [10:04] lool, pitti: ack given in -motu [10:04] thanks [10:04] Hobbsee: thanksely === pitti changed the topic of #ubuntu-devel to: Archive: Feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [10:07] (topic diff: remove alpha-6 freeze) [10:07] pitti: thanks [10:16] pitti: huh, now it didn't segfault, but the first run gave me an BadAlloc error, second time works [10:17] tjaalton: hm; jockey is 100% python... [10:18] Yeah. Don't you just love it when scripting languages segfault? [10:18] Well, interpreters for scripting languages, that is. [10:18] pitti: it's the gtk stack that failed [10:31] 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] pitti: unless you are happy with regression testing only [10:31] mvo: ah, indeed; I just applied the patch in http://article.gmane.org/gmane.comp.time.tz/2094 [10:32] ok, thanks [10:32] mvo: regression testing appreciated, too (I did some light testing already) [10:39] pitti: I suppose you handle hal-info package, right? I have a question related to same. [10:39] slytherin: yes, I do [10:41] 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] pitti: dapper is good, going for the other ones now [10:42] 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] they're welcome to send them to upstream themselves in addition, of course [10:43] superm1: oh, did soyuz give back your binaries btw? [10:43] The reason I am asking is that it will reduce the headache for configuring internet through mobile (over usb at least). [10:44] provided we have information about enough handsets [10:51] I believe using phone as modem ove BT is waaaaay more popular than by USB [10:52] in fact, I haven't seen anyone with cable to his phone [10:58] cjwatson: bug #198759 is not likely a xkeyboard-config one since it happens in a VT too, where should it be reassigned? [10:58] Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759 [10:58] 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] slytherin: it just need "hcitool cc " to have phone appear as serial port. further configuration is the same as when connecting by USB [11:01] 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] seb128: it is xkeyboard-config [11:03] seb128: the VT keymap is generated from the exact same data [11:04] cjwatson: ah ok [11:04] 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] cjwatson: I though xkeyboard-config was used by xorg only [11:04] but I couldn't see how to get to level4, so I haven't commented on the bug yet [11:04] seb128: not since console-setup in edgy [11:05] alright, thanks [11:05] I asked on IRC because you are not subscribed to the bug [11:05] pitti: verification is done [11:05] so I'm not sure if you were reading comments there [11:05] * pitti hugs mvo, thank you! [11:05] cheers [11:07] seb128: oops, subscribed to it now [11:07] thanks === luisbg_ is now known as luisbg [11:27]