[00:00] pitti: thanks. [00:12] geser: I'm working on virtualbox-ose-modules.. I wasn't aware that 7 already FTBFS when uploading version 8. Currently waiting for the testbuild in ppa. [00:13] blueyed: good, I just wanted to look at it myself [00:14] blueyed: you need some special case for i386/amd64 as linux-headers-{i386,virtual} doesn't seem to exist on amd64 === doko_ is now known as doko [00:26] this isn't a specific question about ubuntu, but I figured you guys could point me in the right direction.....how can I get the source for Launchpad? [00:26] dcode: You'd be after #launchpad, and you can't. [00:26] the URL for hte project on launchpad is sftp...which obviously requires a user/pass [00:26] dcode: The source for launchpad is not available [00:26] drat [00:26] okeyday.... [00:27] thanks for the infos [00:33] geser: yes, that's what I have in my ppa already. The FTBFS however seems to occur because of KDIR vs. KERN_DIR. [00:34] blueyed: I could successfully build a slightly modified package (changed flavours for amd64) on amd64 [00:34] blueyed: what was the problem there as I didn't need to change here nothing [00:36] geser: seems specific to the buildds, because it worked in my pbuilder, too. See http://launchpadlibrarian.net/11610543/buildlog_ubuntu-hardy-i386.virtualbox-ose-modules_7_FAILEDTOBUILD.txt.gz [00:38] blueyed: looking at your -9~blueeyedppa2 packages: you need to change dh_gencontrol -a to dh_gencontrol -s as else dh_gencontrol will complain that some packages aren't for amd64 [00:38] the same for dh_builddeb [00:39] geser: ok, anything else? [00:41] blueyed: that seems to be the only change between your rules and mine [00:42] blueyed: my package build successfully in my amd64 pbuilder but not in the i386 pbuilder, it failed during the -generic flavour [00:42] at least I've packages for amd64 so I can play with virtualbox tomorrow :) [00:43] geser: fine.. :) i386 does not fail for me.. I'll reupload to my ppa and to universe, if it works out ok. Thanks. [00:43] Thank you. === Taggard is now known as Bunny === roxirc is now known as matttp [02:38] * Hobbsee waves [02:39] Heya Hobbsee [02:46] Heya Hobbsee. [02:46] hiya luke! === asac_ is now known as asac === Bunny is now known as Taggard === antdedyet is now known as E_NOMAD === E_NOMAD is now known as antdedyet === antdedyet is now known as technomad === technomad is now known as technoant === technoant is now known as technogeek === technogeek is now known as technoant === RAOF_ is now known as RAOF === RadiantFire_ is now known as RadiantFire [07:12] Good morning [07:12] morning [07:13] Hobbsee: :) [07:30] good morning [07:32] Good morning [07:33] pitti! [07:33] * pitti hugs Hobbsee [07:33] * Hobbsee hugs pitti back [07:33] Good morning pitti! :) [07:34] hey warp10 [07:37] Hey pitti! [07:40] * pitti waves towards Australia again and sends hugs to StevenK [07:41] * StevenK isn't in Australia right now. Please leave a hug after the beep. [07:41] oy! [07:44] StevenK: oh. sprint. right [07:44] pitti: Right :-) [07:48] doko, are you around? I wanted to chat with you re vnc4's src package. [07:51] doko, particularly regarding bug 184225 whenever you return. [07:51] Launchpad bug 184225 in vnc4 "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/184225 [08:49] aufs support for casper - patch now available - bug #187259 [08:49] Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259 [08:53] asac: so, network-manager in your PPA doesn't seem to manage to support either my wired or my wireless interface. Where do you want me to start with debugging? [09:11] hmm - and my PC now no longer has permission to set an IP address by DHCP [09:22] cjwatson: intersting ... what do you mean by "manage" ... not detected, or just cannot connect? [09:28] what chipsets do you have? [09:28] asac: as soon as I upgraded, it brought the running wired interface (managed by n-m 0.6) down, and the applet now only offers manual configuration as an option [09:28] asac: tg3 (wired), b43 (wireless) [09:28] it recognises both and says "eth0: Device is fully-supported using driver 'tg3'." and "eth1: Device is fully-supported using driver 'b43'." respectively [09:28] for the latter, it says "eth1: driver does not support SSID scans (scan_capa 0x00)." [09:28] (pretty sure it used to though) [09:29] odd [09:30] i think our kernel lacks the linville scan_capa patches ... but that shouldn't make the interfaces completely unusable [09:30] Jan 30 08:52:08 sarantium NetworkManager: eth0: Device is fully-supported using driver 'tg3'. [09:30] that's just weird, too :) [09:30] Jan 30 08:52:08 sarantium NetworkManager: Now managing wired Ethernet (802.3) device 'eth0'. [09:31] Jan 30 08:52:08 sarantium NetworkManager: Bringing down device eth0 [09:31] followed by: [09:31] Jan 30 08:52:10 sarantium NetworkManager: Bringing up device eth0 [09:31] Jan 30 08:52:10 sarantium kernel: [21713.328605] ADDRCONF(NETDEV_UP): eth0: link is not ready [09:31] Jan 30 08:52:10 sarantium NetworkManager: Deactivating device eth0. [09:31] hmm ... do you have the right applet version? [09:32] http://people.ubuntu.com/~cjwatson/tmp/nm-syslog [09:32] is it 0.7 as well? [09:32] cjwatson: Forbidden :) [09:32] ah now [09:32] network-manager-gnome 0.7~~svn20080121t194048-0ubuntu0~pre6 [09:32] 403 fixed [09:33] i assume you tried to restart nm-applet multiple times already? [09:35] *** glibc detected *** nm-applet: munmap_chunk(): invalid pointer: 0x0807ac8e *** [09:35] I don't think it likes me [09:35] yes ... that happens sometimes on startup [09:35] just try another time ... should come up then [09:35] http://people.ubuntu.com/~cjwatson/tmp/nm-applet-crash [09:36] seems to be in the code to migrate gconf from 0.6 [09:36] oh it crashes while migrating [09:36] hmm [09:36] maybe backup your gconf database and wipe everything below /system/networking in gconf [09:36] ok, good call, after restarting nm-applet it detects the wired interface again [09:37] (backup to keep it reproducible) [09:37] pretty messy upgrade issue though [09:37] cjwatson: was the previous start your first start? [09:37] oh, err, I've already restarted nm-applet, so it might be too late; taken a backup now [09:37] yes [09:37] damn :) [09:38] well ... i assume that your previous nm-applet instance running was still the old one then. [09:38] it was [09:38] next start was your first start (migration crashed) ... and now it works [09:38] looks like we need to arrange to restart it though, somehow [09:38] cjwatson: any pointers appreciated :) [09:38] since it takes out networking otherwise [09:39] seb128: i think nm-applet is started by gnome session ... can i somehow trigger a restart for specific apps on upgrade? [09:40] asac: no [09:40] asac: you can get nm-applet react to signals and have the postinst using that though [09:40] seb128: got a handy time machine? :) [09:41] lol [09:41] you could have the postinst search for processes called nm-applet, kill them, switch to the corresponding user(s), and restart them [09:41] (UGLY AS SIN) [09:41] ouch [09:41] ... with the right command-line arguments [09:42] then we should just restart twice as on first start it will crash :-P [09:42] have you tried something like: basic gutsy install, connect to wireless network, save that gconf database? [09:42] yeah ... but at least we could do it somehow [09:42] (restarting) [09:44] cjwatson: nope ... I haven't really looked into this as its just a random snapshot from a quick progressing svn tree. [09:44] if it doesn't go away in next snapshot i know where and how to look now [09:46] unfortunately, i have to stop everything and do mozilla security now ... an exploit leaked so the release was rescheduled to be next mon/tue. [09:47] :( [09:47] hi [09:48] hi Kano. juliank ended up adding aufs to lum today [09:48] i know, i use that kernel already [09:48] but casper is not yet patched [09:48] yeah there is a bug filed regarding it [09:48] live-helper worked however [09:48] just needs a sponsor from core-dev [09:49] bug #187259 [09:49] Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259 [09:49] asac: disassembly says it's the g_object_unref after reading a wireless connection, btw [09:49] * asac looking [09:49] (there are two in that function) [09:50] superm1: i updated my patch a little bit [09:50] Kano, juliank is the one that attached it to the bug. any differences you have you may just want to attach to that same bug [09:50] panic "Unionfs mount failed" is now panic "${UNIONTYPE} mount failed" [09:51] because then you see what ovfs you used [09:51] rest is still the same [09:52] not huge, but looks better [09:52] Kano: it is ${UNIONFS} now, not ${UNIONTYPE} used in Debian. [09:52] call it like you want [09:52] cjwatson: can you see if its the wireless ... or the vpn one? [09:52] but use it at this point [09:53] asac: fairly sure it's the wireless one; it's well under halfway through the function (lots of inlined stuff) [09:53] and the calls before it look to be from the inlined wireless code [09:53] pitti, hi [09:53] hi tkamppeter [09:53] basically some more options from live-helper should be backported, casper is really very primitive against it... [09:54] asac: it might be relevant that the most recent change to gconf-helpers.c was labelled as fixing memory leaks [09:54] pitti, about bug 185602, you fixed the ghostscript documentation issues once, with this bug they reappeared, can you fix this again? [09:54] Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602 [09:54] like live-media-path option [09:55] tkamppeter: it doesn't have anything to do with the toolchain; I suspect the patch was dropped during the last merge, or so [09:55] evand: You are a bloody legend! I have been meaning to do that in casper for quite a while now! I owe you a beer at the next event! [09:55] or how do you combine more than one live cd on dvd? [09:55] tkamppeter: yes, it's in my ubuntu mbox, I'll have a look [09:55] tkamppeter: (feel free to beat me to it :) ) [09:55] pitti, and if you fix that one, can you also apply the proposed patch of bug 183628 [09:55] Launchpad bug 183628 in ghostscript "ghostscript crashes after loading 20 page repeatedly" [Undecided,New] https://launchpad.net/bugs/183628 [09:56] tkamppeter: ok [09:57] pitti, I have marked the bug 185602 as an alpha 4 milestone, as it can break the distro's consistency. [09:57] Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602 [09:57] pitti, thanks in advance [09:58] asac: for the record, wireless works too having restarted nm-applet, so I'm happy for the time being [09:59] Kano: Updated the patch [09:59] fine [09:59] now you only need a number for the new kernel/lum and casper [09:59] and then you can autobuild it [10:00] do you know live-helper? [10:01] Kano: I wrote the patch to add aufs support to live-helper/live-initramfs. [10:01] juliank: well the change is not really huge ;) [10:01] how about adding some things from live-helper back [10:02] toram, media* [10:03] Kano: toram is already in casper [10:04] i think it had a problem in live-helper, then something went wrong [10:04] i think the cd could not be used [10:04] juliank: Perhaps it might be better to branch casper trunk, add your patch, and add the URL to your branch on the bug. [10:04] to burn then [10:04] did you try? [10:04] Then its a matter of a core-dev merging your changes. [10:04] TheMuso: The branch is not working. [10:04] a patch is usually fine, FWIW [10:05] the patch is so small, hard to make any huge mistakes ;) [10:05] cjwatson: Yeah I know. I just remember back in the day when I started the a11y stuff, I was asked to do a branch. :) [10:05] yeah, I think that was larger and more complex, and possibly needed a few iterations of merging and such [10:05] * ogra wonders why he finds his laptop hardlocked every morning :( [10:05] cjwatson: There is truth to that. [10:07] TheMuso, cjwatson: "KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21 [10:07] " [10:07] well, today's alternate CDs seem happier [10:07] juliank: blink; I can only say it works fine for me and suggest #bzr for debugging [10:08] juliank: Where are you getting that branch from? [10:08] could be genuine network data corruption I suppose [10:08] Arch-1:matt.zimmerman@canonical.com%casper--main--0--patch-21 is in the tree I have [10:08] also is it really hard to add a very small patch to mesa? [10:09] (corresponding to r22) [10:09] until you add that i can not boot ubuntu [10:10] https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/151974 [10:10] Launchpad bug 151974 in mesa "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Fix committed] [10:10] that patch is not in the debian package,but debian does not enable compiz by default [10:10] Kano: our X maintainer is GMT-0800 and unlikely to be around right now ... [10:10] TheMuso, cjwatson: lightweight checkout worked - I am also not able to view files using codebrowse.launchpad.net for this project, gives 500 internal error [10:11] debian/changelog [10:11] Kano: (oh, well, tjaalton is in a convenient timezone, I didn't realise he was dealing with this one) [10:11] he added 2 debian patches, a 3rd one would not hurt... [10:11] err 2 ubuntu ones [10:12] cjwatson: re the initramfs error handling spec: I have managed to reproduce the behavior reported in bug 31126, however unlike what one comment in that bug says, dpkg now fails, due to no space left on device. However, the initramfs is still corrupted. So in terms of the spec, I guess aborting is bhappening somewhat, but I am now not sure how part of the spec applies... [10:12] Launchpad bug 31126 in initramfs-tools "Doesn't check for failure due to full filesystem" [High,Confirmed] https://launchpad.net/bugs/31126 [10:13] it is really bad when you boot a system and see a chess board only [10:13] TheMuso: software should recover from out-of-disk-space without corrupting data, as a general rule [10:13] TheMuso: it does indeed abort, but it should leave you with a working initramfs [10:13] cjwatson: Yes, but how do we do that if there is no room? [10:13] TheMuso: see the design in the spec :) [10:13] it should write the new initramfs and move it into place [10:13] that approach defends against this problem [10:14] But thats what happens now is it not? [10:14] no, it is not [10:14] is Ubuntu safe for iso testing? Are there any major bug fixes in process? [10:14] cjwatson: Oh, it gzips it straight into boot? [10:14] TheMuso: right [10:14] juliank: do you work with live-helper on ubuntu? [10:14] TheMuso: the standard approach is gzip -c > foo.new and then move foo.new to foo [10:15] but mkinitramfs just does this: [10:15] (cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip -9 >"${outfile}") || exit 1 [10:15] that's guaranteed to leave a corrupted initramfs if anything goes wrong [10:15] which is what the first part of the suggested code changes in the spec address [10:15] es [10:15] Kano: I don't build ubuntu live disks, I just provided this patch for casper. [10:16] cjwatson: But how does symlinking the .bak help here? (From reading the code in the spec) [10:16] http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/files seems to work for me, FWIW [10:17] cjwatson: Click on debian/changelog [10:17] TheMuso: that's not a symlink [10:17] cjwatson: did you see that left over swp file in the casper package? [10:17] Kano: yes, I don't care, it'll go away next upload [10:17] cjwatson: Ah right, I see that now [10:17] not that you forget that ;) [10:17] evand: ^-- .swp presumably in your tree [10:17] Kano: it doesn't matter, it makes no difference to anything [10:18] TheMuso: let me try to remember, I know that logic was important [10:18] TheMuso: oh, right, it was because the existing initramfs logic tries to leave a .bak file [10:19] cjwatson: So, let me try and get this right in my head. It hard links to a .bak file, conserving some space. The new initramfs is built, and moved into place... If it fails, theres still a useful initramfs? [10:19] TheMuso: at the moment, it moves the old one to .bak first and then regenerates [10:19] cjwatson: Right, I noticed the .bak file using up space on /boot which seemed pointless [10:20] well, it would still be a separate file, but let's not worry about that right now; simplest approach is to preserve existing behaviour while making it safer [10:20] the ln/mkinitramfs/mv approach means that at most 2x the size of the initramfs is used in /boot at any one time [10:20] cp would work as well as ln, but would use 3x the size of the initramfs for a short period [10:21] so hardlinking is more efficient in this case [10:21] the point where the initramfs generation can fail is when it's writing to .new [10:21] cjwatson: Right, So we hard link, generate new initramfs, copy over, if all is well, remove hard link? [10:21] but that's fine, because the boot process doesn't look at it [10:21] oh right .new [10:21] mv (on the same filesystem) is atomic; it either succeeds or fails, but cannot fail part-way through [10:21] right [10:22] don't need to remove the hard link because the mv breaks it [10:22] but safely, so that .bak is still the old fine [10:22] Ah of course. [10:22] file [10:23] tkamppeter: fixed [10:23] cjwatson: Ok, thanks. Things are much clearer, I've got something to go from now. Will hack on it tomorrow and go from there. [10:23] TheMuso: this is all done under 'set -e', so any failures will cause the shell script to terminate immediately [10:23] well, update-initramfs is set -e at any rate; mkinitramfs isn't, but it checks errors in the important places here already [10:24] Right. [10:25] under set -e, you basically get try/catch ;-) [10:25] cjwatson: Yeah I know. I've done a lot of my own stuff under -e. [10:26] * cjwatson nods [10:26] And of course, at set -x would have helped me find that gzip dumps straight to boot. :p [10:27] juliank: good point; I'm not sure whether that's a matter for #bzr or #launchpad but it'll be one of those [10:27] juliank: like I say, a patch is fine for now [10:29] pitti, thanks [10:30] cjwatson, your issues with NM - for some reason I have issues with NM too ... and now can only select manual configuration to have it work properly, as it seems that dhclient is recieving permission denied errors when trying to configure the card (however, when I manually set things up - everything's fine) [10:31] but setting up things manually for wireless isn;t going to be fun [10:33] Mez: unless you're using asac's hardy PPA, it's unrelated [10:33] cjwatson, oh, damn - then I have an issue which I need to fix :( and have no idea where to start [10:36] pitti, important HPLIP bug fix for Alpha 4, biff [10:37] tkamppeter: while you are at touching/testing hplip, could you please make it stop using the 'scanner' group? [10:37] tkamppeter: in theory your user should have an ACL on whichever devices are created for this, so that you can access them without a particular group [10:41] * TheMuso will do CD testing in the morning, and notify accordingly. Need sleep now. :) [10:52] Kano: as I told you it would be nice if you first make sure that the patch will get in 7.0.3. I'm not sure there's time for a new upload for alpha4 though [11:02] having massive issue's with gvfs. I'm an iso tester and I can't burn more than one cd without needing to restart the machine to burn the next :( That's a major regression [11:03] and that's a GVFS issue.. how exactly? [11:04] awalton__: never happened before gvfs was introduced [11:04] that's not really an answer, that's a coincidence. [11:05] hal problems perhaps? [11:06] if it's really a GVFS issue, we've gotta know because it'd be a pretty serious bug.. but from my POV it's hard to see gvfs doing anything special in this regard. [11:06] awalton__: I've been having serious issues with gnomes reliablity sinse gvfs was introduced. I'm no expert by any shape or means but it has only been since it's introduction. Before hand everything worked fine. [11:07] have you tried removing gvfs and seeing if the problem still presents? [11:07] If you can tell me how to track it down I can help. But I have no idea at all [11:07] removing the hal backend? [11:07] I'll give it a bash [11:08] is it just gvfs I need to remove? What is the hal backend called? [11:09] the first thing I'd try is just plain removing all of gvfs.. apt-get remove it [11:09] tjaalton: agd5f merged it, ask him if you don't believe me [11:09] if the problem goes away, then we can pin it down from there [11:10] awalton__: ok nps need to reboot I'm running in kubuntu live at the moment so I could get some discs burnt [11:11] tjaalton: i gave him another patch, he made this one, i tested it and he added it to mesa [11:12] tjaalton: as long as the patch is not applied i can not boot ubuntu with enabled compiz, thats clear or not? [11:14] Kano: ok, that was 20h ago according to the logs [11:20] Kano: uploaded [11:21] fine [11:21] maybe i can test u sooner or later on real hardware then... [11:21] vbox is abit boring ;) [11:26] evand, cjwatson: ubiquity install fails with "The installer needs to remove operating system files from the install target, but was unable to do so. The install cannot continue." [11:28] Riddell: evand was working on that yesterday [11:28] 16:41 ah, so my logic in clear_partitions completely fails to account for the fact that you cannot remove a directory that's a mountpoint. [11:29] I believe it's on the alpha-4 milestone list [11:29] cjwatson: ok thanks [11:32] cjwatson: do you think you could modify initramfs to support a blacklist option BEFORE udev is started. i see no hook to get started before udev [11:33] pitti, about HPLIP, can you upload my package and I remove the scanner group stuff with the next HPLIP upload, as this HPLIP fixes an urgent bug for Alpha 4. [11:33] tkamppeter: I can do that [11:33] thanks, pitti. [11:33] Kano: I don't maintain initramfs-tools routinely; I just edit it when I need to [11:35] tkamppeter: done [11:39] slangasek: I synced debconf 1.5.19; should help with grub/ucf [11:42] hi can someone tell me if the bug where nautilus doesn't fall back on default search if tracker is removed has been resolved please ive been searching the forums but there's no definitive answer that i can see and i dont have the data allowance to download the alpha [11:43] and the closest matching launchpad bug i can see is wishlisted? [11:44] ahh sorry wrong channel :-[ === cjwatson_ is now known as cjwatson [12:13] * Hobbsee stomps on tomboy [12:44] morning, seb128 [12:44] hey jwendell [12:44] seb128, do you plan to package new gdm to hardy? [12:45] jwendell: no [12:45] seb128, :( [12:45] jwendell: it's not tested, has no themed login, no setting migration, no autologin, no graphical config tool, etc [12:46] jwendell: hardy will be a lts, that would not be a smart move, why do you need this one? [12:46] seb128, you mean gdm 2.21.5 ? [12:46] jwendell: no, I mean 2.21 SVN [12:47] jwendell: they should be in freeze and debug bug, not writting thousand of lines of code every week now [12:47] seb128, actually I don't need that version. It's just that I'd want to fill a bug about not playing the sound, and I'd like to test newer version before doing this... [12:48] jwendell: 2.21 is a rewrital, but you can still open 2.20 bugs, it's still maintained and they will another tarball [12:48] they will roll another tarball [12:48] seb128, ok, thanks [12:48] you are welcome === \sh_away is now known as \sh [13:05] how about updateing fuse+ntfs-3g? [13:05] until it is frozen again ;) [13:09] btw. fuse has a newer version in debian. for ntfs-3g you could look at my package if needed... [13:09] Kano: I already updated fuse [13:09] when? [13:09] yesterday [13:09] good [13:09] then only ntfs-3g remains [13:09] I'll do ntfs-3g once the Debian maintainer does it; he's usually pretty quick [13:10] well i am quicker, i had even the rc packaged ;) [13:10] that's nice [13:10] it is a bit different [13:10] because you dont need fuse as build-dep [13:10] has integrated fuse-lite [13:10] I don't see a reason to avoid the fuse build-dep [13:11] i see it [13:11] when ntfs-3g would need an fuse update then you need to update 2 package, so only 1 [13:12] that doesn't count [13:12] well if you dislike it you can enable external fuse [13:12] as you have 2.7.2 this should do too [13:12] a much more important reason *not* to do that is that if a security problem is found in fuse then the security team would have to run around finding everything that's copied it. [13:13] we dislike it and already have enabled external fuse. you do not need to tell us that :) [13:13] http://ntfs-3g.org/releases.html [13:13] New: the --with-fuse=external configure option makes NTFS-3G to be compiled with an external FUSE library. For non-Linux operating systems this is the default and the only compilation option currently. [13:13] then use that option [13:14] I'm sure the Debian maintainer will do so [13:14] I am quite happy to wait [13:14] i am sure he will not [13:14] if he doesn't, the Debian security team will ask him to change [13:14] (as soon as they notice) [13:15] btw. it makes it more easy to backport [13:15] please leave me alone [13:15] I have said no and I mean no [13:15] as long as you update it... [13:16] * cjwatson applies /ignore, as he is getting bad-tempered === ryu2 is now known as ryu [13:23] who is doing release notes for alpha4 ? [13:24] do we add users to the fuse group nowadays? [13:25] * ogra hopes not [13:25] ogra: slangasek [13:25] ogra: why? [13:25] ogra: that's required to get gvfs using fuse which is very handy (allow all GTK applications to use network shares transparently) [13:25] seb128, well, i rely with ltspfs on the fact that users have no local device access by default on thin clients ... [13:25] i would have to rework that model [13:26] my users want this access to be off by default ... [13:26] the fuse group was my switch until now, as nothing else used it by default [13:26] ogra: just don't install gvfs-fuse on ltsp then [13:26] seb128, its not about gvfs ... but the group membership [13:27] an admin has to enable it deliberately currently [13:27] can't you have different membership on ltsp then? [13:27] right [13:27] and I just noticed that's why gvfs fuse mounting is not working [13:27] no, i'd need hacks to ltspfs [13:27] its not designed for extra ACL stuff yet [13:27] and I think transparent access to network share for all gtk applications is something we should have [13:28] that would allow acroread, etc to open files on smb shares [13:28] i bet i can do it easily on a per client base ... but thast not how its documented and would need changes in my users habits [13:28] I take acroread as an example because that's one we can't hack to make it use gvfs ;-) [13:28] since we currently do it on a per-user base [13:29] maybe that should be something to discuss on the mailinglist [13:29] seb128, if thats really decided to be done, please notify me and i'll ask the ltsp community how they like to have it [13:30] well, that's how gvfs work [13:30] probably they would even be happy with all users being able to use localdev out of the box :) [13:30] we can decide to use the feature or not now === edson is now known as puzzle [13:31] ogra: I would :) I never was requested to turn local devices off [13:32] Hi. If someone would have time, please do a rebuilt / binary-only upload of openoffice.org-voikko to have bug #187083 fixed for Alpha 4 testers. [13:32] Launchpad bug 187083 in openoffice.org-voikko "[hardy] openoffice.org-voikko needs a rebuild" [Unknown,Fix released] https://launchpad.net/bugs/187083 [13:33] stgraber, right, when i defaulted to having it on for everyone jammcq and sbalneav complained it should be an opt-in feature and no default [13:33] so i'll return to tehm to discuss it [13:34] ogra: it should be something we can turn on or off for everyone (or eventually a lts.conf option), having to add all the users to the fuse group isn't really admin-friendly [13:34] the prob here is that you cant steer it through the group membership anymore (which is documented everywhere in the edubuntu docs) [13:34] it will tear down other features as well [13:34] thats waht worries me most here [13:35] stgraber, right, but that would work only on a per-client-machine base, not per-user anymore [13:36] lts.conf doesnt know about users [13:36] and i hope it will naver have to :) [13:37] *never [13:38] Mirv: I can do that [13:41] Mirv: uploaded [13:41] ogra: indeed, but are people really using it as a per user filter ? or just as an on/off switch for all the users ? [13:42] Mirv: I didn't even notice that l-s-fi isn't on my systems currently :) [13:44] stgraber, no idea, i have to rely on jammcq and sbalneav, i onlyheard complaints from users that it wasnt on by default [13:44]