[00:01] Laney: still Steve; I'm just doing some of the jaunty bootstrap while Steve is taking a well-deserved holiday [00:08] jdong: alsa panicing? Now theres a surprise. It seems that not much testing goes into the tarballs when upstream creates them. From reading alsa-dev recently, all they do is check that the tarballs build it seems. [00:08] s/panicing/panicking/ [00:12] that sounds promising, for such a fundamental part of the desktop [00:15] ajmitch: Indeed. [00:15] * TheMuso can't understand why the bits of the system he is interested in working on are not always quality controlled... [00:16] My bits of the system are always 64-bit unsafe! [00:16] Pulse being such a moving target I can kind of understand, but alsa, and *SHUDDERS* dmraid? [00:16] because you love the pain [00:17] Dmraid being one of the worst, due to the upstream author not being very descriptive in his changelogs and vcs commits. Added to that, his vcs commits are in huge chunks, with messages like "such and such version checkin." [00:17] Haha. [00:17] Ouch. [00:17] Yeah. [00:17] TheMuso: yeah this is ridiculous I'm swithcing back to stock alsa [00:18] Oh, and added to that, dmraid can be split into a backend and frontend. So when you attempt to build with the split backend and frontend, what happens, the library needed for the backend is requested to be linked against the frontend, which of course doesn't work. [00:18] This is why we shouldn't have FF. [00:18] Just push new versions! [00:18] wgrant: heh. [00:19] I think the opinion relating to anything kernel related is that people just pull patches to fix things anyway, so version releases aren't very important in terms of QA. [00:19] wgrant: including post-release? [00:19] ajmitch: Yes. Fedora does, why not us? [00:20] it'd lessen the complaints about universe, at least [00:21] to be honest I wouldn't mind it so much for some parts of the archive :) [00:21] Fedora does? ewww. However they are more of a RHEL test bed are they not? [00:22] directhex: hmm? [00:27] TheMuso: I've often seen them push new upstreams. [00:27] And break things. [00:27] opensuse does too, but they also break things or patch them in very unfortunate ways. [00:29] ouch. [00:29] * TheMuso subscribes to jaunty-changes, and starts mirroring jaunty. [00:30] if only I had the bandwidth for it [00:30] Well I already have intrepid, so mirroring jaunty is a matter of fetching new indexes, as well as the 6 updated packages in jaunty so far, so there is not much. [00:30] Actually, not 6 packages, there have been 6 uploads. [00:31] * ajmitch isn't bitter at all about being very close to capped to 64Kbp for the next 2 weeks [00:31] The biggest bandwidth hog was when I set up the miror initially. [00:31] ajmitch: I hadn't noticed in increase in bitterness. [00:31] I've only got most of main for hardy & intrepid on my laptop [00:31] ScottK: good :) [00:32] start merging jaunty too! I'm feeling lonely as the only one who's got started on the merge queue [00:32] I will very shortly [00:32] Jaunty is not open yet... [00:32] cjwatson: Is it open? [00:32] no, but that doesn't stop you uploading [00:32] it'll sit in a queue [00:32] OK [00:33] Point. [00:33] Woot. Now only powerpc and ia64 are busted [00:33] StevenK: ?? [00:33] glibc [00:33] hppa isn't? [00:33] Oh. [00:33] I have ideas for both, will discuss them with doko when he's next up [00:34] ajmitch: It built on hppa, at least [00:34] NCommander: reckons that glibc will need a newer kernel on powerpc to complete at least. [00:34] Progress. [00:34] TheMuso: no, shouldn't [00:34] StevenK: if that includes tests, I'm impressed :) [00:34] TheMuso: just needs some test exemptions [00:34] cjwatson: Right. [00:34] but that's trivial, we just need to agree on them [00:34] pselect wasn't implemented in the kernel until after what the buildds are currently running so I think that's probably an obvious exemption [00:35] I'm waiting for infinity to tell me whether the ia64 buildd has the relevant filesystem mounted with relatime in order to find out whether that's the cause of its failure [00:35] cjwatson, just out of curosity, what are the buildds running as a host [00:35] or at least the kernels on each [00:36] NCommander: apparently hardy+powerpc is busted on the buildds so they're running dapper. You can tell what kernel they're running by searching for "current=" in any recent glibc build log [00:36] dapper? [00:36] Ouch [00:36] Hardy works fine on PowerPC [00:36] I trust infinity not to be lying to me. [00:36] He co-administers those buildds and you don't, bluntly :) [00:36] let me rephrase [00:37] We were unaware of any issues with hardy on the buildd hardware [00:37] NCommander: I'd trust infinity's opinion on this one. [00:37] * NCommander nods [00:37] Hardy doesn't boot on the hardware that the buildds are on [00:37] 04:05 cjwatson: Actually, powerpc is still dapper, because hardy+powerpc=fail. :/ [00:37] is all I know [00:38] * NCommander nods [00:39] but this is not really a huge problem. The glibc build was all fine, it was just the tests at the end that exhibited regressions that hadn't been explicitly tagged as OK. [00:39] cjwatson, Ok, so thats easy to fix [00:40] yes, like I say I just want to agree it with doko [00:40] * NCommander would never touch the toolchain without doko's seal of approval :-) [00:40] ia64 I'm less sure about; if it's due to relatime then that's a simple test fix, if it's not then I'm unsure of the right answer [00:40] cjwatson, is it possible to find out the extact modem of machines used a buildds for PowerPC? (I've been told they are XServes, but I dunno what model xserve) [00:40] s/modem/model [00:40] * TheMuso also needs to look into d-i fixes for powerpc as well. d-i for powerpc generic hardware is... broken... at least for CD installs. :) [00:40] NCommander: don't know offhand, ask #canonical-sysadmin I suppose [00:40] for intrepid that is [00:41] TheMuso: hmm, what fails? [00:42] cjwatson, the IDE modules udeb is broken due the fact the IDE module itself was renamed and no one updated the ports kernel d-i files to reflect this change [00:42] ah [00:42] cjwatson: a combination of important udebs being dropped for the cdrom initrd, and the ide-cd module being renamed and we missed it. [01:19] +/c === nxvl_ is now known as nxvl === tjaalton_ is now known as tjaalton [06:41] good morning [06:44] * lamont grumbles at wireless being b0rked on his dell 1520 [06:45] * StevenK grumbles at Compiz not showing the titlebar of the active window properly [06:45] what was the final solution to iwlagn not supporting iwl4965 ? [06:45] s/solution/workaround/ [07:01] lamont: oh. intrepid loses on iwl4965? [07:02] lifeless: interestingly, the livecd works just fine. hardy upgraded to intrepid? not so happy [07:02] Good morning [07:02] Keybuk: hi [07:02] OTOH, the upgrade hung walking through packages to see what it should remove.. maybe that's relevant... [07:03] Morning pitti [07:03] Keybuk: hm, in previous releases the apt cache wasn't present at all, so you only got the driver notification on second login (after the cron job); that was fairly okay [07:04] Keybuk: copying it across from the livefs would be even more elegant indeed [07:06] * pitti subscribes to jaunty-changes [07:06] morning [07:16] morning lool, pitti === tkamppeter__ is now known as tkamppeter [07:44] lifeless: release notes tells to install linux-modules-backports for iwl4965 to work [07:44] oh, lamont, actually [07:49] Mirv: although I'm not seeing panics, nor am I using a G or N network. [07:49] nor is it seeing the network [07:50] fails to allocate an irq for it [07:50] the device, that is [07:54] and anything with 'backports' in its name makes me cry [08:08] lamont: please tell me if it worked :P [08:10] * lamont goes looking for linux-backports-modules-intrepid [08:18] lamont: It was renamed to iwlagn, apparantly. [08:19] lamont: sha 4fc22b21b3fcb3580c32b70605ef114178f8e611 [08:19] soren: and broken, too. [08:19] Clever. [08:19] I suppose I could flatline the poor 320GB drive, since the livecd works just fine, and the upgraded hardy machine not at all [08:19] lamont, depends on your hardware. I upgraded hardy to intrepid from iwl4965 -> iwlagn no issue [08:20] * lamont even downreved his upgraded machine from 7.15 to 7.14 to better reflect the livecd [08:20] asac: do you happen to know about iwl3945 not connecting to WPA/WPA2? (just got a PM with that problem descsription, but I don't have any encrypted network here for testing) [08:21] [ 99.140972] iwlagn 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [08:21] ^^does not occur on the upgraded hardy box [08:21] lamont, maybe its a firmware issue [08:21] pitti: the only 3945 issue I've seen is the US default thing [08:21] NCommander: same firmware [08:21] lamont: I didn't hear that it was broken across the board [08:21] lamont: what does that do? [08:21] --> bed for me, then slap the kernel guys around in the morning [08:22] pitti: refuses to connect on channel > 11 until you give it permission - see the release notes [08:22] -1/-2 firmware? [08:22] lamont: sleep well [08:22] lamont: ah, thanks [08:22] NCommander: linux-firmware 1.2 [08:22] on both [08:23] Hrm [08:23] Odd [08:23] What specifically does gmesg say on the subject [08:23] i.e. [08:23] [ 20.947800] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4 [08:24] lamont, -^ [08:24] * NCommander guesses lamont left for bed [08:25] http://paste.ubuntu.com/66653/ [08:25] that's the grep output [08:25] the 99.* lines are unique to the (working) livecd [08:25] lamont, we have the same extact hardware as far as the kernel cares [08:26] lamont, so we know the driver works on this hardware, its just a matter of figuring out why it doesn't work for you [08:26] note that the driver and kernel are perfectly happy... just not when I upgraded my hardy machine to intrepid [08:26] NCommander: you have now caught up with where I was 30 min ago [08:26] Oh [08:26] Hrm [08:26] * NCommander might know the issue [08:28] * NCommander personally doesn't have the requesting firmware line either [08:29] that was 'dmesg | grep iwl' [08:29] Oh [08:29] Yeah, I do have it [08:29] That line is missing when you boot from upgraded box, correct? [08:29] it's more the assigning and IRQ and initialzing the card that i'd like to see... [08:30] WHat looks like is happing is your card is initalizing to off [08:30] It will only get an IRQ when the card is on [08:30] DOes your laptop have a physical RF kill switch? [08:30] yes. untouched between the two boots [08:31] and, in fact, set to 'on' as it has been for the past 9 months [08:31] RF kill support was added in intrepid for some dirvers [08:31] and this state is stored in the filesystem??? [08:31] No, but if there is a bug in the driver ... [08:31] note that the same &(%)*^*_ ( driver stack works from livecd, fails from filesystem [08:31] when I flip the switch to off: [08:31] I get PCI INT A disabled [08:31] And then when I flip it back on, it reassiocates with an IRQ [08:32] This might just be boardline crazy, but try booting up with the switch off (make sure iwl sees the card), and then flip it to on and see if it initalizes [08:32] (there should be a log message about RF kill switch enabled) [08:33] grep switch /media/LEXAR/x/dmesg.out [08:33] -mix 547 : [08:33] * NCommander found a related bug [08:33] Still no wireless [08:33] ^? [08:34] One other thing [08:34] Right click Network Manager [08:34] that was the livecd boot dmesg [08:34] make sure "Enable WIreless" is actually checked [08:34] still booting with the kill switch off [08:34] ISTR it was [08:34] ISTR? [08:34] I seem to recall [08:35] wtf is your friend :) [08:35] Ok [08:35] Looking at the history, there was a bug involving the RF kill switch on Hardy, that caused a crash if it was switched [08:35] That patch might be causing something to go wrong with you [08:36] * lamont plugs back in the wired lan cable, so that the network manager icon will appear [08:36] or not appear [08:37] bah [08:37] NCommander: but only when booted from the disk????? [08:37] lamont, do cat /sys/class/rfdisk/*/state [08:37] it's really a question of WTF is installed on the disk that isn't on the livecd (or viceversa) [08:37] I did a fresh upgrade, no issues [08:37] Er [08:37] Dist-upgrade [08:37] no issues [08:37] same hardware [08:37] (its a sony viao VGN660N) [08:38] /sys/class/rfdisk/*/state -> ENOENT [08:38] did iwlagn even load? [08:38] * lamont did 'do-release-upgreade' [08:39] Ok, if you flip the switch now, does dmesg say anything? [08:39] which did the dist-upgrade, then went into a seemingly infinite loop that I killed after about an hour, while it tried to figure out what packages it should be removing [08:39] didn't [08:39] It sounds like the kernel did not get upgraded [08:39] What's uname -a say [08:40] * NCommander notes if the linux metapackage wasn't properly upgraded, you could end up in a situation with an old kernel, and dist-upgrade not saying anything [08:41] 2.6.27-7-generic, just like it does on the livecd. [08:41] so much for that theory [08:41] does lsmod show iwlagn loaded (with the kill switch disabled) [08:42] wasn't much of a theory. [08:42] * lamont -> bed [08:42] lamont, well, kernel debugging is half guessing, half banging your head on a wall [08:42] lamont, when you wake up, ping me, and the debugging shall continue! ;-) [08:44] NCommander: in all the years I've been debugging kernels, it very rarely involves guessing [08:44] not if you can't reproduce locally :-/ [09:01] Keybuk: there's one Debian change to udev that I need to make the installer keep working in jaunty. Mind if I merge it in advance of whatever other merge plans you have? [09:02] it's the start-udev thing [09:22] pitti: hmm ... point them to the ~network-manger PPA [09:23] asac: ah, I told him to try the modprobe.d workaround from the release notes, let's see [09:23] asac: if that doesn't work, I'll have him try the PPA, thanks [09:23] pitti: we have: 292054 and 263963 [09:24] pitti: ppa packages fixes it for about 50% ;) [09:26] asac: Hey. About the mullplugin thing I mentioned on Friday before running out the door. It's listed, but the "Enabled" column says "no". [09:27] soren: tools -> addons -> plugins ? [09:27] -> enable ;) [09:27] asac: The button says "Disable" :/ [09:27] soren: heh. why do you need nullplugin? [09:28] i mean ... its nullplugin ;) [09:28] asac: The description suggested that it was the plugin in charge of helping me install other plugins... Is that wrong? [09:29] soren: no that is correct, but enabled/disabled shouldnt matter. what plugin do you want to install? [09:29] asac: What I really wanted was a java plugin. A month before Intrepid released, my homebanking system worked fine. Now it doesn't, and I want to find another java plugin that works. [09:29] soren: heh ;) [09:29] soren: ok [09:29] I have no idea what changed (if anything). [09:29] soren, Danske Banken? [09:29] so go to your banking site ... so that java is used ;) [09:30] liw: Nope. [09:30] soren: then go to tools -> manage content plugins ... and search for other plugins. [09:30] asac: But the thing that offers me to download new plugins doesn't show up. That's the point. [09:30] Oh. [09:30] * soren goes to try that. [09:31] soren: well if you have a plugin installed it wont show up because you already have one. thats why we the tools -> manage contnt pluginst stuff exist [09:31] asac: Oh, I don't. I removed all the java plugins. [09:31] br [09:31] hmm [09:31] brb, even. [09:32] soren: i would suggest that you go to some other java driven site then [09:32] soren: most likely your banking site wants to be smart and uses javascript code to gather whether it makes sense to load an applet at all [09:33] cant tell without any details. for me the "missing plugin" puzzle show properly up when the website uses a plugin [09:33] asac: Fantastic timing. Their site just went down for maintenance. [09:34] asac: I did mention that nullplugin is still listed as "Enabled: No" in the about:plugins page, right? [09:34] soren: ok. 1st. there is no java plugin in about:plugins? [09:35] soren: well nullplugin isnt important ;) [09:35] soren: http://www.dgp.toronto.edu/~mjmcguff/learn/java/01-drawingLines/ [09:35] if i go there the "install missing ... " bar pops up [09:35] asac: No java plugin, no. [09:35] Ah, so it does. [09:35] soren: right. so that means your bank wants to be stupid and probes for a javaplugin [09:36] if no java plugin found it doesnt even try to display an applet [09:36] kick them ;) [09:36] Hm... installing the openjdk plugin failed. Can I find out how somehow? [09:36] soren: to get he real results you should go to about:plugins .... edit the pfs.datasource.url pref and replace 8.04 with 8.10 [09:36] Er.. I mean "why somehow". [09:37] soren: thats an ugly bug [09:37] asac: You mean about:config, I presume? [09:37] soren: yeah [09:37] soren: search for pfs.datasource [09:37] soren: and pfs.filehint.url [09:37] Changed them both... [09:37] soren: both suffer from the same problem :( [09:37] * soren tries again. [09:38] * soren has two with identical descriptions.. [09:39] soren: yes. java applets dont have a description ... thats the only class of plugins that wasnt updated [09:39] Both of the icedtea ones fail to isntall. :( [09:40] soren: when it tries to install ... you can see apturl as a process ... what package does it try to install [09:40] ? [09:41] asac: I get this on the console: http://pastebin.com/m754814e1 [09:42] asac: cacao-oj6-plugin [09:42] soren: ok. so the error happens reawlly quick? [09:42] i'm here in the hotel in beijing, really tired :\ [09:42] i somehow lost a day during the flight over the north pole [09:42] calc: heh ;) [09:42] asac: Yes. [09:43] got on the plane at 6:30am sunday and got to the hotel at 5:30pm monday [09:43] soren: the error is probably something mvo wants to take a look at [09:43] asac: Perhaps it's because I'm not using an official mirror and apturl gets all confused. [09:43] soren: can you try to run apturl apt:cacao-oj6-plugin ? [09:43] and something is weird with their dhcp i can't get an address in linux it claims the message length is too long [09:43] (guessing that thats the packag name) [09:43] so i'm stuck in vista (gag) [09:44] calc: chinese dhcp [09:44] ;) [09:44] asac: heh [09:44] soren: are you running jaunty already? [09:45] jaunty is ready for work? [09:45] mvo: is that a jaunty bug? ;) [09:45] asac: it looks like it to me :) [09:45] mvo: I might be :) [09:45] mvo: I updated base-files just for kicks :) [09:46] * soren reverts that [09:46] soren: heh :) wait for the python-apt update then - I can push a version into my ppa too if you want? [09:46] soren: that might help [09:46] it works fine from the command line, though. [09:46] (apturl that is) [09:46] soren: otherwise you should have replaced 8.04 with 9.04 ;) [09:46] brb [09:46] (just to be accurate) [09:47] Yay, it works. [09:48] soren: good .... so now try the tools -> manage content plugins thing [09:49] soren: and then file bugs against java to properly support that by also linking the plugin in /usr/share/ubufox/plugins/ [09:49] asac: I don't have that. [09:49] soren: you only have that when you are on a website with java content (or any other content) [09:49] soren: you dont have ubufox then [09:49] (if you dont have that at all) [09:49] ii ubufox 0.6-0ubuntu1 Ubuntu Firefox specific configuration defaults and apt support [09:50] soren: and in tools there is no menu entry? [09:51] asac: Sorry. I'm an idiot. An illiterate one, even. [09:51] You really shouldn't put it all the way at the bottom. It's very hard to spot :) [09:52] soren: well. you also get a plugin symbol in the status bar [09:52] soren: when you visit a page that has a plugin in-use [09:52] soren: not that the color is better to spot ;) ... but we have two hardy-to-spot places now [09:52] Ok, progress... I can now login to the homebanking system. Let's see if it works properly... [09:54] asac: Their status page says that the system is unstable at the moment... I'll wait until they think it's stable before I start distributing blame between firefox, java and my bank :) [10:09] slomo: lool: I think I understand both of your arguments. still, I'd like to hear Mithrandir's opinion on the issue where this should be fixed: the package, ffmpeg upstream, pkg-config or gstreamer0.10-ffmpeg [10:11] siretart: wpasupplicant really takes ages for iwl chipsets nowadays ;) ... maybe there is also something broken on the supplicant side? [10:12] siretart: look 263963 272185 292054 [10:12] asac: sorry, I don't follow wpasupplicant upstream that closely. how about asking that on the hostap mailing list? [10:12] siretart: do they allow to post without suscription ;)? [10:13] let me check [10:13] tjaalton: do you still have your -evdev fix for the amd64 joystick misdetection in the pipe? would be good to upload now [10:13] asac: how about subscribing? I'm reading that list via gmane/nntp, btw. [10:16] hmm [10:16] siretart: yeah. wil,l do that now [10:16] i think i cannot ignore that any longer ;) [10:16] found some interesting thread about WPA-EAP with TTLS [10:17] calc: oh, hmm, doko's in Beijing too isn't he, I completely forgot about that [10:17] guess I should just go ahead with the glibc changes I had in mind [10:18] when's the time to talk about demoting a package from main? [10:19] directhex: normally you don't need to talk about it much ... if the package isn't seeded or depended upon by anything seeded, we'll eventually get around to removing it [10:19] check http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt to find out if it's supposed to be on its way out [10:20] cjwatson, it's mono-dbg. i suspect it's in main due to a misunderstanding about its contents [10:20] directhex: no, it's in main because *-dbg is automatically in main if any other binaries from the same source are [10:20] pitti: yes, will do [10:20] cjwatson, can that be overridden? [10:20] directhex: the exception mechanism for that is Extra-Exclude in the supported seed [10:21] directhex: you can look up the reasons why packages are in main in http://people.ubuntu.com/~ubuntu-archive/germinate-output/ [10:22] directhex: so explain to me why we don't want mono-dbg? the package description says it contains debugging symbols for various libmono-* and mono-* packages, which seems like something we'd normally want [10:22] tjaalton: thanks; I can test it, I have an amd64 installation here on my test box [10:22] pitti: nice, I'll prepare it after lunch and let you know [10:23] cjwatson, it contains managed mono debugger symbols, which aren't much use unless you're using the (universe-based) mono-debugger. the symbols for crashes of the mono runtime itself are in mono-jit-dbg [10:23] hi [10:24] directhex: well, that does raise the question of whether mono-debugger should be in main ... [10:24] but OK, I agree that for the moment it should be wherever mono-debugger is [10:24] cjwatson, whichever is preferred. i've been trying to ease up on all the promotions i've been requesting lately [10:25] directhex: I've taken it out of ubuntu.jaunty/supported; might need to come out of some of the other flavours' supported seeds too [10:25] cjwatson, understood. thanks [10:26] cjwatson/Hobbsee : belatedly done [10:26] cjwatson, i'd like to have a discussion at a later point about what from to drop to universe in mono - the big restructure being worked on in debian means a significant reduction in tomboy/f-spot dependencies, which really means a reduction in things that need to be in main too. but i won't have a proper handle on exactly what until packaging work is complete [10:27] elmo: thanks [10:28] directhex: right, hopefully *that* one should be mostly automatic [10:28] this should mean 10-20 meg of space freed up on the jaunty cd, at least from us [10:28] Keybuk: http://paste.ubuntu.com/66683/ [10:28] oh, that will be very nice [10:29] cjwatson, short version: there are two versions of .net - 1.0 and 2.0. apps like tomboy are 2.0 apps using 2.0 libs, but many tools & libs in the dep chain are compatible with both 9and have 1.0) deps. we're making tomboy/f-spot 2.0-pure, by essentially removing 1.0 support from packages & building everything as 2.0-only [10:30] right [10:30] so gtk-sharp won't pull in ~10 meg of unneeded 1.0 stuff anymore [10:30] but it's not crystal clear on what to drop yet, as some build-depends may remain on 1.0 [10:41] pitti: Thanks for sponsoring #280148. [10:43] * wgrant hits Launchpad. It doesn't notify when new series tasks are created. [10:44] elmo: cool, thanks :) [10:56] siretart: ok, great... the last part shouldn't need fixing though as gst-ffmpeg doesn't even use the libtheora/vorbis/raw1394 stuff from ffmpeg ;) [11:03] wgrant: you're welcome [11:11] hmm my other account still shows online [11:12] i think i got blocked by the great firewall :\ [11:12] i can't tracert past the first hop to my computer at home anymore [11:15] weird its working again now, but my machine hasn't rebooted or anything like that [11:17] asac: please slow down with bug #112248. I think you misunderstood what the report was about. [11:17] Launchpad bug 112248 in network-manager "fields to set MTU and MSS missing" [Wishlist,Fix released] https://launchpad.net/bugs/112248 [11:19] slomo: thanks [11:20] wgrant: did the X logs I attached to the g-s-d bug provide anything useful? is there anything else I can test for? [11:21] Q-FUNK: we have a new bug. opening a real old bug for a regression is not the preferred way for me [11:22] its 258743 [11:22] asac: closing a valid bug to open a new one doesn't sound to practicla either [11:23] Q-FUNK: ok thought it was reopened [11:23] if it was never closed then its ok [11:23] but we have the other bug which properly tracks that [11:24] then mark it as a duplicate, not as invalid [11:24] Q-FUNK: feel free. .. i posted the info there ,) [11:24] plus, you haven't answered anyone's question in the thread. where in NM 0.7? [11:25] hi guys [11:25] Q-FUNK: i cannot answer all questions. bugs are not questions ;) [11:26] Q-FUNK: you can set MTU in connection editor [11:26] i m having a small problem with my terminal font settings [11:26] anybody here uses monaco font in their terminal? [11:27] Q-FUNK: if you want more options open a similar bug as 278309 for openvpn [11:28] but be precise which options that should be [11:28] (except mtu which is now properly dealt with in the other bug) [11:29] asac: we *had* a proper bug already, before you marked it as invalid. [11:30] be more careful in reading reports before you run and invalidate or merge them. [11:31] it wasn't only about MTU. the report clearly said that the NM pluging for OpenVPN doesn't support even half of what OpenVPN itself supports and that this is the real issue. [11:31] Is there any reason why USB Wifi-peripherals drivers needs to be installed through ncurses? [11:31] Q-FUNK: then the title should have been better [11:31] Q-FUNK: only thing i saw is that i had a bunch of MTU bugs open now [11:31] and so i dont need the bug that popped up latest [11:32] (and it doesnt provide any info which isnt in the other bugs) [11:32] to asac with a hammer, every NM bug is about the generic MTU feature sticking out ;) [11:32] guys . when I select monaco as the font for my terminal the spacing between the letters in terminal increases, it looks very bad... any idea how to solve it? [11:33] Q-FUNK: not sure what you mean [11:33] cat /dev/coffee >> /ubuntu/devel/asac [11:33] hehe [11:33] yeah [11:34] but i had coffee already [11:34] you seem to be on a point and shoot rampage today ;) [11:34] Q-FUNK: I replied to that bug yesterday... [11:34] wgrant: with the mention about the final version of the patch? [11:34]