[00:01] <cjwatson> Laney: still Steve; I'm just doing some of the jaunty bootstrap while Steve is taking a well-deserved holiday
[00:08] <TheMuso> 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] <TheMuso> s/panicing/panicking/
[00:12] <ajmitch> that sounds promising, for such a fundamental part of the desktop
[00:15] <TheMuso> 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] <wgrant> My bits of the system are always 64-bit unsafe!
[00:16] <TheMuso> Pulse being such a moving target I can kind of understand, but alsa, and *SHUDDERS* dmraid?
[00:16] <ajmitch> because you love the pain
[00:17] <TheMuso> 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] <wgrant> Haha.
[00:17] <wgrant> Ouch.
[00:17] <TheMuso> Yeah.
[00:17] <jdong> TheMuso: yeah this is ridiculous I'm swithcing back to stock alsa
[00:18] <TheMuso> 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] <wgrant> This is why we shouldn't have FF.
[00:18] <wgrant> Just push new versions!
[00:18] <TheMuso> wgrant: heh.
[00:19] <TheMuso> 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] <ajmitch> wgrant: including post-release?
[00:19] <wgrant> ajmitch: Yes. Fedora does, why not us?
[00:20] <ajmitch> it'd lessen the complaints about universe, at least
[00:21] <ajmitch> to be honest I wouldn't mind it so much for some parts of the archive :)
[00:21] <TheMuso> Fedora does? ewww. However they are more of a RHEL test bed are they not?
[00:22] <slangasek> directhex: hmm?
[00:27] <wgrant> TheMuso: I've often seen them push new upstreams.
[00:27] <wgrant> And break things.
[00:27] <ScottK> opensuse does too, but they also break things or patch them in very unfortunate ways.
[00:29] <TheMuso> ouch.
[00:29]  * TheMuso subscribes to jaunty-changes, and starts mirroring jaunty.
[00:30] <ajmitch> if only I had the bandwidth for it
[00:30] <TheMuso> 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] <TheMuso> 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] <TheMuso> The biggest bandwidth hog was when I set up the miror initially.
[00:31] <ScottK> ajmitch: I hadn't noticed in increase in bitterness.
[00:31] <ajmitch> I've only got most of main for hardy & intrepid on my laptop
[00:31] <ajmitch> ScottK: good :)
[00:32] <cjwatson> start merging jaunty too! I'm feeling lonely as the only one who's got started on the merge queue
[00:32] <ajmitch> I will very shortly
[00:32] <TheMuso> Jaunty is not open yet...
[00:32] <ScottK> cjwatson: Is it open?
[00:32] <cjwatson> no, but that doesn't stop you uploading
[00:32] <cjwatson> it'll sit in a queue
[00:32] <ScottK> OK
[00:33] <TheMuso> Point.
[00:33] <StevenK> Woot. Now only powerpc and ia64 are busted
[00:33] <TheMuso> StevenK: ??
[00:33] <cjwatson> glibc
[00:33] <ajmitch> hppa isn't?
[00:33] <TheMuso> Oh.
[00:33] <cjwatson> I have ideas for both, will discuss them with doko when he's next up
[00:34] <StevenK> ajmitch: It built on hppa, at least
[00:34] <TheMuso> NCommander: reckons that glibc will need a newer kernel on powerpc to complete at least.
[00:34] <ScottK> Progress.
[00:34] <cjwatson> TheMuso: no, shouldn't
[00:34] <ajmitch> StevenK: if that includes tests, I'm impressed :)
[00:34] <cjwatson> TheMuso: just needs some test exemptions
[00:34] <TheMuso> cjwatson: Right.
[00:34] <cjwatson> but that's trivial, we just need to agree on them
[00:34] <cjwatson> 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] <cjwatson> 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] <NCommander> cjwatson, just out of curosity, what are the buildds running as a host
[00:35] <NCommander> or at least the kernels on each
[00:36] <cjwatson> 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] <NCommander> dapper?
[00:36] <NCommander> Ouch
[00:36] <NCommander> Hardy works fine on PowerPC
[00:36] <cjwatson> I trust infinity not to be lying to me.
[00:36] <cjwatson> He co-administers those buildds and you don't, bluntly :)
[00:36] <NCommander> let me rephrase
[00:37] <NCommander> We were unaware of any issues with hardy on the buildd hardware
[00:37] <TheMuso> NCommander: I'd trust infinity's opinion on this one.
[00:37]  * NCommander nods
[00:37] <StevenK> Hardy doesn't boot on the hardware that the buildds are on
[00:37] <cjwatson> 04:05 <infinity> cjwatson: Actually, powerpc is still dapper, because hardy+powerpc=fail. :/
[00:37] <cjwatson> is all I know
[00:38]  * NCommander nods
[00:39] <cjwatson> 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] <NCommander> cjwatson, Ok, so thats easy to fix
[00:40] <cjwatson> 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] <cjwatson> 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] <NCommander> 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] <NCommander> 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] <cjwatson> NCommander: don't know offhand, ask #canonical-sysadmin I suppose
[00:40] <TheMuso> for intrepid that is
[00:41] <cjwatson> TheMuso: hmm, what fails?
[00:42] <NCommander> 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] <cjwatson> ah
[00:42] <TheMuso> 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] <TheMuso> +/c
[06:41] <dholbach> 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] <lamont> what was the final solution to iwlagn not supporting iwl4965 ?
[06:45] <lamont> s/solution/workaround/
[07:01] <lifeless> lamont: oh. intrepid loses on iwl4965?
[07:02] <lamont> lifeless: interestingly, the livecd works just fine.  hardy upgraded to intrepid? not so happy
[07:02] <pitti> Good morning
[07:02] <pitti> Keybuk: hi
[07:02] <lamont> OTOH, the upgrade hung walking through packages to see what it should remove.. maybe that's relevant...
[07:03] <StevenK> Morning pitti
[07:03] <pitti> 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] <pitti> Keybuk: copying it across from the livefs would be even more elegant indeed
[07:06]  * pitti subscribes to jaunty-changes
[07:06] <lool> morning
[07:16] <NCommander> morning lool, pitti
[07:44] <Mirv> lifeless: release notes tells to install linux-modules-backports for iwl4965 to work
[07:44] <Mirv> oh, lamont, actually
[07:49] <lamont> Mirv: although I'm not seeing panics, nor am I using a G or N network.
[07:49] <lamont> nor is it seeing the network
[07:50] <lamont> fails to allocate an irq for it
[07:50] <lamont> the device, that is
[07:54] <lamont> and anything with 'backports' in its name makes me cry
[08:08] <lifeless> lamont: please tell me if it worked :P
[08:10]  * lamont goes looking for linux-backports-modules-intrepid
[08:18] <soren> lamont: It was renamed to iwlagn, apparantly.
[08:19] <soren> lamont: sha 4fc22b21b3fcb3580c32b70605ef114178f8e611
[08:19] <lamont> soren: and broken, too.
[08:19] <soren> Clever.
[08:19] <lamont> 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] <NCommander> 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] <pitti> 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] <lamont> [   99.140972] iwlagn 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[08:21] <lamont> ^^does not occur on the upgraded hardy box
[08:21] <NCommander> lamont, maybe its a firmware issue
[08:21] <lamont> pitti: the only 3945 issue I've seen is the US default thing
[08:21] <lamont> NCommander: same firmware
[08:21] <cjwatson> lamont: I didn't hear that it was broken across the board
[08:21] <pitti> lamont: what does that do?
[08:21] <lamont> --> bed for me, then slap the kernel guys around in the morning
[08:22] <lamont> pitti: refuses to connect on channel > 11 until you give it permission - see the release notes
[08:22] <NCommander> -1/-2 firmware?
[08:22] <pitti> lamont: sleep well
[08:22] <pitti> lamont: ah, thanks
[08:22] <lamont> NCommander: linux-firmware 1.2
[08:22] <lamont> on both
[08:23] <NCommander> Hrm
[08:23] <NCommander> Odd
[08:23] <NCommander> What specifically does gmesg say on the subject
[08:23] <NCommander> i.e.
[08:23] <NCommander> [   20.947800] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[08:24] <NCommander> lamont, -^
[08:24]  * NCommander guesses lamont left for bed
[08:25] <lamont> http://paste.ubuntu.com/66653/
[08:25] <lamont> that's the grep output
[08:25] <lamont> the 99.* lines are unique to the (working) livecd
[08:25] <NCommander> lamont, we have the same extact hardware as far as the kernel cares
[08:26] <NCommander> 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] <lamont> note that the driver and kernel are perfectly happy... just not when I upgraded my hardy machine to intrepid
[08:26] <lamont> NCommander: you have now caught up with where I was 30 min ago
[08:26] <NCommander> Oh
[08:26] <NCommander> Hrm
[08:26]  * NCommander might know the issue
[08:28]  * NCommander personally doesn't have the requesting firmware line either
[08:29] <lamont> that was 'dmesg | grep iwl'
[08:29] <NCommander> Oh
[08:29] <NCommander> Yeah, I do have it
[08:29] <NCommander> That line is missing when you boot from upgraded box, correct?
[08:29] <lamont> it's more the assigning and IRQ and initialzing the card that i'd like to see...
[08:30] <NCommander> WHat looks like is happing is your card is initalizing to off
[08:30] <NCommander> It will only get an IRQ when the card is on
[08:30] <NCommander> DOes your laptop have a physical RF kill switch?
[08:30] <lamont> yes.  untouched between the two boots
[08:31] <lamont> and, in fact, set to 'on' as it has been for the past 9 months
[08:31] <NCommander> RF kill support was added in intrepid for some dirvers
[08:31] <lamont> and this state is stored in the filesystem???
[08:31] <NCommander> No, but if there is a bug in the driver ...
[08:31] <lamont> note that the same &(%)*^*_ ( driver stack works from livecd, fails from filesystem
[08:31] <NCommander> when I flip the switch to off:
[08:31] <NCommander> I get PCI INT A disabled
[08:31] <NCommander> And then when I flip it back on, it reassiocates with an IRQ
[08:32] <NCommander> 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] <NCommander> (there should be a log message about RF kill switch enabled)
[08:33] <lamont>  grep switch /media/LEXAR/x/dmesg.out
[08:33] <lamont> -mix 547 :
[08:33]  * NCommander found a related bug
[08:33] <NCommander> Still no wireless
[08:33] <NCommander> ^?
[08:34] <NCommander> One other thing
[08:34] <NCommander> Right click Network Manager
[08:34] <lamont> that was the livecd boot dmesg
[08:34] <NCommander> make sure "Enable WIreless" is actually checked
[08:34] <lamont> still booting with the kill switch off
[08:34] <lamont> ISTR it was
[08:34] <NCommander> ISTR?
[08:34] <lamont> I seem to recall
[08:35] <dholbach> wtf is your friend :)
[08:35] <NCommander> Ok
[08:35] <NCommander> 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] <NCommander> 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] <lamont> or not appear
[08:37] <NCommander> bah
[08:37] <lamont> NCommander: but only when booted from the disk?????
[08:37] <NCommander> lamont, do cat /sys/class/rfdisk/*/state
[08:37] <lamont> it's really a question of WTF is installed on the disk that isn't on the livecd (or viceversa)
[08:37] <NCommander> I did a fresh upgrade, no issues
[08:37] <NCommander> Er
[08:37] <NCommander> Dist-upgrade
[08:37] <NCommander> no issues
[08:37] <NCommander> same hardware
[08:37] <NCommander> (its a sony viao VGN660N)
[08:38] <lamont>  /sys/class/rfdisk/*/state -> ENOENT
[08:38] <NCommander> did iwlagn even load?
[08:38]  * lamont did 'do-release-upgreade'
[08:39] <NCommander> Ok, if you flip the switch now, does dmesg say anything?
[08:39] <lamont> 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] <lamont> didn't
[08:39] <NCommander> It sounds like the kernel did not get upgraded
[08:39] <NCommander> 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] <lamont> 2.6.27-7-generic, just like it does on the livecd.
[08:41] <NCommander> so much for that theory
[08:41] <NCommander> does lsmod show iwlagn loaded (with the kill switch disabled)
[08:42] <lamont> wasn't much of a theory.
[08:42]  * lamont -> bed
[08:42] <NCommander> lamont, well, kernel debugging is half guessing, half banging your head on a wall
[08:42] <NCommander> lamont, when you wake up, ping me, and the debugging shall continue! ;-)
[08:44] <lamont> NCommander: in all the years I've been debugging kernels, it very rarely involves guessing
[08:44] <NCommander> not if you can't reproduce locally :-/
[09:01] <cjwatson> 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] <cjwatson> it's the start-udev thing
[09:22] <asac> pitti: hmm ... point them to the ~network-manger PPA
[09:23] <pitti> asac: ah, I told him to try the modprobe.d workaround from the release notes, let's see
[09:23] <pitti> asac: if that doesn't work, I'll have him try the PPA, thanks
[09:23] <asac> pitti: we have: 292054 and 263963
[09:24] <asac> pitti: ppa packages fixes it for about 50% ;)
[09:26] <soren> 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] <asac> soren: tools -> addons -> plugins ?
[09:27] <asac> -> enable ;)
[09:27] <soren> asac: The button says "Disable" :/
[09:27] <asac> soren: heh. why do you need nullplugin?
[09:28] <asac> i mean ... its nullplugin ;)
[09:28] <soren> asac: The description suggested that it was the plugin in charge of helping me install other plugins... Is that wrong?
[09:29] <asac> soren: no that is correct, but enabled/disabled shouldnt matter.  what plugin do you want to install?
[09:29] <soren> 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] <asac> soren: heh ;)
[09:29] <asac> soren: ok
[09:29] <soren> I have no idea what changed (if anything).
[09:29] <liw> soren, Danske Banken?
[09:29] <asac> so go to your banking site ... so that java is used ;)
[09:30] <soren> liw: Nope.
[09:30] <asac> soren: then go to tools -> manage content plugins ... and search for other plugins.
[09:30] <soren> asac: But the thing that offers me to download new plugins doesn't show up. That's the point.
[09:30] <soren> Oh.
[09:30]  * soren goes to try that.
[09:31] <asac> 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] <soren> asac: Oh, I don't. I removed all the java plugins.
[09:31] <soren> br
[09:31] <asac> hmm
[09:31] <soren> brb, even.
[09:32] <asac> soren: i would suggest that you go to some other java driven site then
[09:32] <asac> 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] <asac> cant tell without any details. for me the "missing plugin" puzzle show properly up when the website uses a plugin
[09:33] <soren> asac: Fantastic timing. Their site just went down for maintenance.
[09:34] <soren> asac: I did mention that nullplugin is still listed as "Enabled: No" in the about:plugins page, right?
[09:34] <asac> soren: ok. 1st. there is no java plugin in about:plugins?
[09:35] <asac> soren: well nullplugin isnt important ;)
[09:35] <asac> soren: http://www.dgp.toronto.edu/~mjmcguff/learn/java/01-drawingLines/
[09:35] <asac> if i go there the "install missing ... " bar pops up
[09:35] <soren> asac: No java plugin, no.
[09:35] <soren> Ah, so it does.
[09:35] <asac> soren: right. so that means your bank  wants to be stupid and probes for a javaplugin
[09:36] <asac> if no java plugin found it doesnt even try to display an applet
[09:36] <asac> kick them ;)
[09:36] <soren> Hm... installing the openjdk plugin failed. Can I find out how somehow?
[09:36] <asac> 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] <soren> Er.. I mean "why somehow".
[09:37] <asac> soren: thats an ugly bug
[09:37] <soren> asac: You mean about:config, I presume?
[09:37] <asac> soren: yeah
[09:37] <asac> soren: search for pfs.datasource
[09:37] <asac> soren: and pfs.filehint.url
[09:37] <soren> Changed them both...
[09:37] <asac> soren: both suffer from the same problem :(
[09:37]  * soren tries again.
[09:38]  * soren has two with identical descriptions..
[09:39] <asac> soren: yes. java applets dont have a description ... thats the only class of plugins that wasnt updated
[09:39] <soren> Both of the icedtea ones fail to isntall. :(
[09:40] <asac> soren: when it tries to install ... you can see apturl as a process ... what package does it try to install
[09:40] <asac> ?
[09:41] <soren> asac: I get this on the console: http://pastebin.com/m754814e1
[09:42] <soren> asac: cacao-oj6-plugin
[09:42] <asac> soren: ok. so the error happens reawlly quick?
[09:42] <calc> i'm here in the hotel in beijing, really tired :\
[09:42] <calc> i somehow lost a day during the flight over the north pole
[09:42] <asac> calc: heh ;)
[09:42] <soren> asac: Yes.
[09:43] <calc> got on the plane at 6:30am sunday and got to the hotel at 5:30pm monday
[09:43] <asac> soren: the error is probably something mvo wants to take a look at
[09:43] <soren> asac: Perhaps it's because I'm not using an official mirror and apturl gets all confused.
[09:43] <asac> soren: can you try to run apturl apt:cacao-oj6-plugin ?
[09:43] <calc> 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] <asac> (guessing that thats the packag name)
[09:43] <calc> so i'm stuck in vista (gag)
[09:44] <asac> calc: chinese dhcp
[09:44] <asac> ;)
[09:44] <calc> asac: heh
[09:44] <mvo> soren: are you running jaunty already?
[09:45] <directhex> jaunty is ready for work?
[09:45] <asac> mvo: is that a jaunty bug? ;)
[09:45] <mvo> asac: it looks like it to me :)
[09:45] <soren> mvo: I might be :)
[09:45] <soren> mvo: I updated base-files just for kicks :)
[09:46]  * soren reverts that
[09:46] <mvo> soren: heh :) wait for the python-apt update then - I can push a version into my ppa too if you want?
[09:46] <asac> soren: that might help
[09:46] <soren> it works fine from the command line, though.
[09:46] <soren> (apturl that is)
[09:46] <asac> soren: otherwise you should have replaced 8.04 with 9.04 ;)
[09:46] <soren> brb
[09:46] <asac> (just to be accurate)
[09:47] <soren> Yay, it works.
[09:48] <asac> soren: good .... so now try the tools -> manage content plugins thing
[09:49] <asac> soren: and then file bugs against java to properly support that by also linking the plugin in /usr/share/ubufox/plugins/
[09:49] <soren> asac: I don't have that.
[09:49] <asac> soren: you only have that when you are on a website with java content (or any other content)
[09:49] <asac> soren: you dont have ubufox then
[09:49] <asac> (if you dont have that at all)
[09:49] <soren> ii  ubufox                             0.6-0ubuntu1                       Ubuntu Firefox specific configuration defaults and apt support
[09:50] <asac> soren: and in tools there is no menu entry?
[09:51] <soren> asac: Sorry. I'm an idiot. An illiterate one, even.
[09:51] <soren> You really shouldn't put it all the way at the bottom. It's very hard to spot :)
[09:52] <asac> soren: well. you also get a plugin symbol in the status bar
[09:52] <asac> soren: when you visit a page that has a plugin in-use
[09:52] <asac> soren: not that the color is better to spot ;) ... but we have two hardy-to-spot places now
[09:52] <soren> Ok, progress... I can now login to the homebanking system. Let's see if it works properly...
[09:54] <soren> 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] <siretart> 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] <asac> siretart: wpasupplicant really takes ages for iwl chipsets nowadays ;) ... maybe there is also something broken  on the supplicant side?
[10:12] <asac> siretart: look 263963 272185 292054
[10:12] <siretart> asac: sorry, I don't follow wpasupplicant upstream that closely. how about asking that on the hostap mailing list?
[10:12] <asac> siretart: do they allow to post without suscription ;)?
[10:13] <asac> let me check
[10:13] <pitti> tjaalton: do you still have your -evdev fix for the amd64 joystick misdetection in the pipe? would be good to upload now
[10:13] <siretart> asac: how about subscribing? I'm reading that list via gmane/nntp, btw.
[10:16] <asac> hmm
[10:16] <asac> siretart: yeah. wil,l do that now
[10:16] <asac> i think i cannot ignore that any longer ;)
[10:16] <asac> found some interesting thread about WPA-EAP with TTLS
[10:17] <cjwatson> calc: oh, hmm, doko's in Beijing too isn't he, I completely forgot about that
[10:17] <cjwatson> guess I should just go ahead with the glibc changes I had in mind
[10:18] <directhex> when's the time to talk about demoting a package from main?
[10:19] <cjwatson> 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] <cjwatson> 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] <directhex> cjwatson, it's mono-dbg. i suspect it's in main due to a misunderstanding about its contents
[10:20] <cjwatson> directhex: no, it's in main because *-dbg is automatically in main if any other binaries from the same source are
[10:20] <tjaalton> pitti: yes, will do
[10:20] <directhex> cjwatson, can that be overridden?
[10:20] <cjwatson> directhex: the exception mechanism for that is Extra-Exclude in the supported seed
[10:21] <cjwatson> directhex: you can look up the reasons why packages are in main in http://people.ubuntu.com/~ubuntu-archive/germinate-output/
[10:22] <cjwatson> 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] <pitti> tjaalton: thanks; I can test it, I have an amd64 installation here on my test box
[10:22] <tjaalton> pitti: nice, I'll prepare it after lunch and let you know
[10:23] <directhex> 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] <leszek_fh> hi
[10:24] <cjwatson> directhex: well, that does raise the question of whether mono-debugger should be in main ...
[10:24] <cjwatson> but OK, I agree that for the moment it should be wherever mono-debugger is
[10:24] <directhex> cjwatson, whichever is preferred. i've been trying to ease up on all the promotions i've been requesting lately
[10:25] <cjwatson> 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] <directhex> cjwatson, understood. thanks
[10:26] <elmo> cjwatson/Hobbsee : belatedly done
[10:26] <directhex> 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] <cjwatson> elmo: thanks
[10:28] <cjwatson> directhex: right, hopefully *that* one should be mostly automatic
[10:28] <directhex> this should mean 10-20 meg of space freed up on the jaunty cd, at least from us
[10:28] <cjwatson> Keybuk: http://paste.ubuntu.com/66683/
[10:28] <cjwatson> oh, that will be very nice
[10:29] <directhex> 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] <cjwatson> right
[10:30] <directhex> so gtk-sharp won't pull in ~10 meg of unneeded 1.0 stuff anymore
[10:30] <directhex> but it's not crystal clear on what to drop yet, as some build-depends may remain on 1.0
[10:41] <wgrant> pitti: Thanks for sponsoring #280148.
[10:43]  * wgrant hits Launchpad. It doesn't notify when new series tasks are created.
[10:44] <Hobbsee> elmo: cool, thanks :)
[10:56] <slomo> 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] <pitti> wgrant: you're welcome
[11:11] <calc_> hmm my other account still shows online
[11:12] <calc_> i think i got blocked by the great firewall :\
[11:12] <calc_> i can't tracert past the first hop to my computer at home anymore
[11:15] <calc_> weird its working again now, but my machine hasn't rebooted or anything like that
[11:17] <Q-FUNK> asac: please slow down with bug #112248.  I think you misunderstood what the report was about.
[11:19] <RainCT> slomo: thanks
[11:20] <Q-FUNK> 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] <asac> Q-FUNK: we have a new bug. opening a real old bug for a regression is not the preferred way for me
[11:22] <asac> its 258743
[11:22] <Q-FUNK> asac: closing a valid bug to open a new one doesn't sound to practicla either
[11:23] <asac> Q-FUNK: ok thought it was reopened
[11:23] <asac> if it was never closed then its ok
[11:23] <asac> but we have the other bug which properly tracks that
[11:24] <Q-FUNK> then mark it as a duplicate, not as invalid
[11:24] <asac> Q-FUNK: feel free. .. i posted the info there ,)
[11:24] <Q-FUNK> plus, you haven't answered anyone's question in the thread.  where in NM 0.7?
[11:25] <ranjithk> hi guys
[11:25] <asac> Q-FUNK: i cannot answer all questions. bugs are not questions ;)
[11:26] <asac> Q-FUNK: you can set MTU in connection editor
[11:26] <ranjithk> i m having a small problem with my terminal font settings
[11:26] <ranjithk> anybody here uses monaco font in their terminal?
[11:27] <asac> Q-FUNK: if you want more options open a similar bug as 278309 for openvpn
[11:28] <asac> but be precise which options that should be
[11:28] <asac> (except mtu which is now properly dealt with in the other bug)
[11:29] <Q-FUNK> asac: we *had* a proper bug already, before you marked it as invalid.
[11:30] <Q-FUNK> be more careful in reading reports before you run and invalidate or merge them.
[11:31] <Q-FUNK> 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] <LordMetroid> Is there any reason why USB Wifi-peripherals drivers needs to be installed through ncurses?
[11:31] <asac> Q-FUNK: then the title should have been better
[11:31] <asac> Q-FUNK: only thing i saw is that i had a bunch of MTU bugs open now
[11:31] <asac> and so i dont need the bug that popped up latest
[11:32] <asac> (and it doesnt provide any info which isnt in the other bugs)
[11:32] <Q-FUNK> to asac with a hammer, every NM bug is about the generic MTU feature sticking out ;)
[11:32] <ranjithk> 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] <asac> Q-FUNK:  not sure what you mean
[11:33] <Q-FUNK> cat /dev/coffee  >> /ubuntu/devel/asac
[11:33] <asac> hehe
[11:33] <asac> yeah
[11:34] <asac> but i had coffee already
[11:34] <Q-FUNK> you seem to be on a point and shoot rampage today ;)
[11:34] <wgrant> Q-FUNK: I replied to that bug yesterday...
[11:34] <Q-FUNK> wgrant: with the mention about the final version of the patch?
[11:34] <asac> Q-FUNK: i do post release bug triaging ... yes.
[11:35] <wgrant> Q-FUNK: No, see the end of bug #287462
[11:35] <maxb> In intrepid, my thinkpad seems to have decided that the "mute" softkey is now a "lock screen" softkey, what is the proper package for me to file a bug against?
[11:36] <Q-FUNK> wgrant: odd. I didn't see this one in my mailbox yet.  OK, let's try deleting the xorg.conf and reloading X, then.
[11:36] <Q-FUNK> brb
[11:40] <wgrant> This doesn't, on the whole, look good.
[12:24] <Yoe> hi -- can anyone please tell the relevant persons that nbd hasn't been using sf.net's CVS repository in years anymore, but has switched to SVN instead?
[12:25] <Hobbsee> Yoe: you'd better tell debian that, as we don't modify that package at all.
[12:25] <Mithrandir> Yoe: both intrepid (just released) and jaunty (current release) are pulling the stock package from Debian.
[12:25] <Mithrandir> Hobbsee: ISTR Yoe being the Debian maintainer.
[12:25] <cjwatson> Yoe: do you mean launchpad.net/nbd?
[12:25] <Yoe> cjwatson: yes
[12:25] <Hobbsee> Mithrandir: oh.
[12:25] <cjwatson> Yoe: it's maintained by ~registry, so mere mortals can't change it; you'd need to ask #launchpad
[12:26] <Hobbsee> right, ignore me then :)
[12:26] <Yoe> ah, okay.
[12:26] <Yoe> didn't realize that's a different channel :)
[12:26] <ogra> Yoe,  Wouter Verhelst, wouter@debian.org maintains it in debian, we usually only pull his fixes/changes
[12:26] <cjwatson> ogra: Yoe *is* Wouter.
[12:26] <Yoe> ogra: that's me :)
[12:26] <ogra> err
[12:26] <ogra> lol
[12:26] <ogra> sorry for that :)
[12:26] <Yoe> ogra: nvm :)
[12:27] <cjwatson> Yoe: Ubuntu folks generally don't have god privileges on LP (only demigod at most)
[12:27] <Yoe> right
[12:28] <Mithrandir> cjwatson: you're good at nethack.  You could ascend.
[12:28] <Mithrandir> ;-)
[12:28] <cjwatson> Mithrandir: still only gets you to demigod(dess). :-)
[12:32] <cjwatson> http://launchpadlibrarian.net/19279370/buildlog_ubuntu-jaunty-sparc.glibc_2.8%2B20081027-0ubuntu4_CHROOTWAIT.txt.gz erk, I screwed *that* one up
[12:35] <stefanlsd> cjwatson, is the process you go through for prepping the new release available to read about?  just interested in whats involved.
[12:36] <cjwatson> stefanlsd: http://wiki.ubuntu.com/NewReleaseCycleProcess
[12:36] <stefanlsd> cjwatson, great. thanks!
[12:40] <cjwatson> stefanlsd: getting the toolchain to work and dealing with whatever exciting new changes are coming down the pipe is different every time, of course
[12:40] <cjwatson> so it's just a framework
[12:41] <Mithrandir> cjwatson: for a user, is it possible to remove stuff from the SendEnv list?
[12:41] <stefanlsd> cjwatson, nodnod. i see the schedule says by the 6th. fun!
[12:41] <Mithrandir> (using .ssh/config or similar)
[12:41] <lool> Mithrandir: Don't think so
[12:41] <lool> Mithrandir: I tried once and couldn't
[12:41] <lool> But this was a couple of openssh releases ago
[12:42] <lool> Mithrandir: Pissed of by SendEnv LANG LC_ALL, aren't you?  :)
[12:42] <cjwatson> Mithrandir: I don't think so, sorry
[12:42] <ogra> wasnt there an ugly way to override that ?
[12:42] <lool> Override them in your shell's init :-(
[12:43]  * ogra thinks he remembers an option that drops a lot of security though
[12:43] <cjwatson> Mithrandir: https://bugzilla.mindrot.org/show_bug.cgi?id=1285
[12:43] <SurcouF> hi
[12:43] <cjwatson> ssh -F /dev/null perhaps
[12:43] <cjwatson> or ssh -F ~/.ssh/config
[12:44] <Mithrandir> lool: no, I was barking up the wrong tree.  It looked like a sunos box got really unhappy when I sent it a locale it didn't grok.
[12:44] <Mithrandir> as in, closed the connection.
[12:44] <cjwatson> we could add a quirk for that
[12:44] <cjwatson> get me ssh -vvv output
[12:44] <stefanlsd> cjwatson, where do the new toolchain packages come from? do we sync or merge those from debian (if they have any later, not sure) - or build from source from upstream?
[12:45] <cjwatson> stefanlsd: mixture. Our toolchain maintainer also maintains the toolchain in Debian
[12:45] <cjwatson> or at least large chunks of it
[12:45] <stefanlsd> cjwatson: heh. cool. pretty handy
[12:45] <lool> cjwatson: Nice workaround
[12:46] <lool> Now I just need a way to set -F from .ssh/config   ;-)
[12:46] <SurcouF> how update-manager has known that a new distribution is available ?
[12:46] <lool> SurcouF: It checks a special meta file on the archive
[12:46] <cjwatson> SurcouF: meta-release* files on http://changelogs.ubuntu.com/
[12:47] <SurcouF> cjwatson, to setup an offline mirror, I must download theses meta-files ?
[12:54] <SurcouF> is changelog.ubuntu.com is hardcoded ?
[12:58] <lool> SurcouF: You can override it in update-manager by subclassing, but I don't think you can configure it
[12:59] <SurcouF> I can through /etc/update-manager/meta-release
[13:00] <lool> I stand corrected
[13:03] <SurcouF> thanks for help
[13:12] <ogra> cjwatson, how hard do you think it will be to make gfxboot support syslinux ?
[13:12]  * ogra is preparing a spec for the mobile images to have some kind of bootmenu)
[13:15] <Mithrandir> probably not hard, given the not-huge difference between isolinux and syslinux.
[13:15] <ogra> right, that was my thought
[13:15] <ogra> even though gfxboot is quite painful
[13:16] <ogra> but it makes no sense to invent something new if we use it everywhere else
[13:35] <cjwatson> ogra: I thought it already did
[13:36]  * soren concurs
[13:36] <cjwatson> ogra: the gfxboot patch to syslinux certainly patches ldlinux.asm
[13:37] <ogra> ah, cool, well, nobody ever tried to use it with syslinux to my knowledge
[13:37] <ogra> at least not on the mobile images
[13:49] <anilg> How can i tell dpkg -r <package> to not run the prerm and postrm files.. and just go ahead and remove the files?
[13:50] <tseliot> anilg: try removing the prerm and postrm from /var/lib/dpkg/info/
[14:37] <RainCT> uhm.. is the raw popcon gzip broken?
[14:38] <RainCT> (I mean http://popcon.ubuntu.com/all-popcon-results.txt.gz, not the application)
[14:54] <kirkland> pitti: around?  looks like we finally got to the bottom of bug #259631 ...
[14:55] <kirkland> pitti: obviously (to me), automatic mounting of encrypted private is not going work when the user has chosen to automatically login (with no password)
[14:55] <kirkland> pitti: this isn't obvious to some of our users, though
[14:55] <kirkland> pitti: i'm looking for some help/advice/assistance in solving this in a desktoppy way
[15:03] <superm1> kirkland, there is unfortunately the same type of problem with WPA keys if you do automatic login since your keyring can't be automatically unlocked
[15:03] <kirkland> superm1: ah, thanks, good to know that my case isn't the only one
[15:04] <superm1> kirkland, but that case isn't "horrible", you get a GUI offering for unlocking the keyring with your password at least
[15:04] <kirkland> superm1: i'm thinking we might need something like that for an encrypted Private directory
[15:05]  * kirkland is hoping that a desktop developer will volunteer for this one :-)
[15:06] <superm1> kirkland, well if you can perhaps hook into the same mechanism and unlock it through the gnome keyring instead of the method you currently do, or possibly supplemental to the method you currently do, you can get it for free; I don't agree with it being automatically unlocked for you on an automatic login though without at least a passphrase.  that entirely defeats the purpose
[15:10] <kirkland> superm1: i have to use the kernel keyring, not the gnome keyring
[15:10] <kirkland> superm1: in that the filesystem is mounted in kernel space, not userspace
[15:11] <kirkland> superm1: and you're absolutely right about defeating the purpose, if there's no prompt for passphrase at all
[15:11] <superm1> kirkland, ah didn't consider that the filesystem was mounted in kernel space not userspace, but that makes sense then.
[15:12] <kirkland> superm1: perhaps you know ...  what is the gui method for prompting a user for a passphrase?  with that, this should just be a 3-line shell script
[15:13] <superm1> kirkland, no sorry, i'm not sure
[15:13] <kirkland> superm1: looks like i might be able to do it with gksu
[15:14] <ScottK> kirkland: gnupg-agent uses pinentry and that has ncurses, gtk, and qt support.  Maybe that'd be a place to look.
[15:14] <kirkland> ScottK: cool, thanks, let me check....
[15:18] <pitti> kirkland: hm, I thought we already discussed that; would be cool if going into Private and clicking that magic script would work
[15:18] <pitti> kirkland: a gksu wrapper or something
[15:18] <kirkland> pitti: okay, i'm looking at it now
[15:19] <tjaalton> pitti: ok, here's the diff/dsc for the new evdev: http://users.tkk.fi/~tjaalton/dpkg/
[15:21] <pitti> tjaalton: thanks! please upload
[15:23] <tjaalton> pitti: sure
[15:27] <pitti> asac: hm, n-m is apparently not in https://edge.launchpad.net/~asac/+archive ? that's just an old version
[15:28] <asac> pitti: we have a ~network-manager team
[15:28] <asac> thats the place
[15:37] <pitti> asac: ah, thanks; I asked him to try that (modprobe.d trick didn't work)
[15:37] <asac> pitti: so did you find something about your huawei interfaceNumber bouncing?
[15:38] <pitti> asac: not really; it does bounce between 0 and 1, but both work
[15:38] <Keybuk> cjwatson: m-o-m appears to be working normally
[15:40] <cjwatson> cool
[15:40] <cjwatson> now I just need to track down infinity to re-bootstrap glibc/sparc
[15:40] <pitti> tjaalton: hm, why does your upload remove evdev-with-high-keys.diff ?
[15:41] <cjwatson> lamont: ... or maybe you can help?
[15:44] <asac> pitti: both interfaces work?
[15:44] <pitti> asac: yes, apparently
[15:45] <asac> pitti: hmm. ok. but you still need NM to be restarted?
[15:45] <pitti> asac: only real problem is that the PIN number doesn't work (I followed up in the bug), and the different vodafone tariff
[15:45] <pitti> asac: no, I don't need to restart it
[15:45] <lamont> cjwatson: other stuff that would be ahead of that... RT is love, worst case
[15:45] <asac> pitti: ok and you workaround the pin number by unlocking in phone first?
[15:45] <pitti> asac: right
[15:46] <pitti> asac: well, I actually enabled the PIN again, to test a possible fix
[15:46] <pitti> and to be able to debug it further
[15:46] <pitti> always good to be nagged about bugs :)
[15:46] <asac> pitti: ok i think i saw a mail from you with serial debug
[15:46] <tjaalton> pitti: oh, it was just a temp file from quilt
[15:46] <cjwatson> lamont: already RTed
[15:46] <tjaalton> pitti: didn't notice that 0ubuntu5 had it
[15:47] <cjwatson> lamont: but I'm blocking on this to open jaunty so am trying the nag approach too
[15:47] <tjaalton> pitti: it's already pulled from master
[15:47] <pitti> tjaalton: ah, right, it's patches/, not debian/patches
[15:47] <pitti> tjaalton: someone forgot QUILT_PATCHES apparently :)
[15:48] <tjaalton> pitti: yep, seems like it :)
[15:48] <asac> pitti: so you get a bunch of +CREG: 0,0
[15:48] <asac> at the end
[15:49] <asac> afaik thats an undefined return value for gsm standard. but what i find even more wierd is that it doesnt abort right after seeing that the first time
[15:49] <asac> let me check that in code
[15:49] <lamont> cjwatson: I feel your frustration, if that helps any
[15:49] <pitti> asac: what I found weird is that this debug log didn't have the "PIN timeout" message I got originally from /var/log/daemon.log
[15:51] <asac> hmm 0,4 was the one thats undefined. 0,0 means -> wait a bit longer
[15:51] <asac> most likely we should give it more time and dont use idle_add, but timeout_add
[15:52] <asac> pitti: so if you failed like: http://launchpadlibrarian.net/19271027/nm-serial.txt ... and wait a bit and then try again, does it work then?
[15:53] <pitti> asac: "try" -> disconnect/reconnect in nm-applet?
[15:53] <asac> pitti: without disconnect. just connect again?
[15:59] <asac> pitti: try http://launchpadlibrarian.net/19271027/nm-serial.txt
[15:59] <asac> pitti: sry: http://paste.ubuntu.com/66792/
[15:59] <asac> :)
[16:00] <asac> should give your net more time to find a network and so on
[16:00] <pitti> asac: I love this thing; now PIN actually seems to have succeeded, but now it SIGTERMed pppd
[16:00]  * pitti prepares log
[16:00] <asac> pitti: sigterm most likely happens when NM gave up
[16:00] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt is for my current attempt
[16:00] <pitti> asac: it spun for a while, maybe 10 seconds
[16:01] <pitti> it did get DNS and everything
[16:01] <pitti> tel, brb
[16:01] <asac> pitti: err ... that log doesnt even have "tty" in it ;)
[16:01] <asac> wlan0 + eth0 only ;)
[16:01] <pitti> asac: argh, sorry; seems i killed hte log when restaring n-m to get back eth0
[16:01] <asac> heh
[16:02] <pitti> asac: anyway, I have a confcall, bbl
[16:02] <asac> pitti: yeah. apply and build the patch while callilng ;) (multitask)
[16:02] <asac> 16:59 < asac> pitti: sry: http://paste.ubuntu.com/66792/
[16:04] <pitti> asac: re
[16:06] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt for real now
[16:06] <pitti> asac: your patch is for PIN auth timeout?
[16:07] <asac> pitti: ok thats a different issue. please check whether the patch makes you connect more reliably
[16:07] <asac> (e.g. the last log is ok)
[16:07] <pitti> asac: "last log is ok"?
[16:07] <pitti> asac: I'll apply the patch and try again
[16:07] <asac> pitti: yeah: http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm.txt  that is good
[16:07] <asac> pitti: its a differnt issue that we can fix in a minute i think
[16:08] <pitti> asac: you mean "good for debuggin"?
[16:08] <pitti> ok
[16:08] <mvo> hm, can we do syncs from debian to intrepid-proposed for "SRUs"  (I'm thinking of bug #289603)
[16:08] <asac> pitti: i think bug 268667
[16:09] <asac> pitti: the woarkaround for that bug is to add lcp-echo-failure 0 to /etc/ppp/options
[16:13] <pitti> asac: I did that ^ and now n-m is spinning eternally in an "Sending AT+CREG?" loop
[16:13] <asac> pitti: you mean with the patch?
[16:14] <asac> pitti: with 0,0 ?
[16:14] <asac> or 0,2?
[16:14] <pitti> asac: no, with the patch it's still building
[16:14] <asac> pitti: ah
[16:14] <pitti> asac: with 0,2
[16:14] <asac> pitti: the lcp-echo-failure 0 stuff made it spin eternally?
[16:15] <pitti> asac: well, it's really hard to confirm that, since n-m seems to break in a different way every time I restart it :(
[16:15] <asac> unlikely ... lcp-echo-failure 0 will give you stability if the connect succeeds
[16:15] <asac> shouldnt change anything before that
[16:15] <pitti> asac: I just reconnected again, and now it doesn't loop any more, but says http://paste.ubuntu.com/66799/
[16:16] <pitti> ah, finished building
[16:16] <asac> pitti: hmm. crazy stuff.
[16:17] <kirkland> ScottK: Riddell: is there just a simple, shell-callable program i can use to graphically prompt a user for a password, and print the output to stdout?
[16:17] <kirkland> ScottK: i looked at pinentry
[16:17] <kirkland> ScottK: it's another dependency, that I'd like to avoid at this point
[16:18] <kirkland> ScottK: Riddell: i'm trying kdesu/kdesudo, but it's not behaving like gksu/gksudo
[16:18] <kirkland> note that I don't actually need to run anything as root, or another user.
[16:18] <kirkland> i just need to get their login password, to pass as input
[16:21] <pitti> asac: so the patch did have one effect; now I get two "Searching for network/AT+CREG?" messages per second, and the tray applet spin speed is normal
[16:22] <pitti> asac: before that, the spinning speed was absurdly fast
[16:22] <asac> pitti: ok so more time didnt help
[16:22] <asac> pitti: yeah i can assume that
[16:22] <pitti> asac: it apparently took a while
[16:22] <pitti> asac: seems it finally connected, then ppp died again
[16:23] <Cheery> error in overgod: ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory
[16:23] <asac> pitti: oh it connected?
[16:23] <asac> pitti: did it go from 0,2 ... over 0,0 to 0,1 -> success?
[16:23] <pitti> asac: well, it said "CONNECT 7200000", but then it died
[16:23] <pitti> http://people.ubuntu.com/~pitti/tmp/nm-serial-connect-pppterm-patch.txt
[16:24] <RainCT> Uhm.. can anyone tell me why this doesn't work? "curl https://wiki.ubuntu.com/MOTU/Headers/NextREVUDay?action=raw"
[16:24] <asac> pitti: do you ahve the lcd- stuff in your options now?
[16:24] <pitti> asac: loop with 0,2, then 4 times 0,0, then 0,1 and then COPS and CONNECT
[16:24] <asac> pitti: ok that means the patch is good ;)
[16:24] <RainCT> bah, the wiki is evil :(
[16:24] <pitti> asac: yes, I have "lcp-echo-failure 0"
[16:25] <pitti> asac: patch> yes, it definitively fixes the "retry" speed, and the tray icon appearance
[16:25] <pitti> asac: now that I see what it does, I understand it :)
[16:26] <asac> pitti: well. the main purpose wasnt the applet, but just to give the modem some time and rest ... but ok. lets look at the ppp dying now
[16:26] <pitti> yeah, I know
[16:26] <asac> pitti: can you post the syslog tail too? (it has better timestamps)
[16:27] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/daemon.log
[16:28] <pitti> asac: weird, that worked consistently well while I had the PIN disabled
[16:28] <pitti> asac: and now it never connected a single time while I have PIN enabled
[16:28] <pitti> asac: do you want a daemon.log/serial debug when it works? (i. e. without PIN)?
[16:30] <asac> pitti: no. i want the syslog where you see the ppp sigterm
[16:30] <asac> or tell me at what time i should look above
[16:31] <asac> pitti: at best really the syslog not sure if g_message stuff goes to daemon.log at all
[16:31] <pitti> asac: oh, ok; indeed, syslog has pppd messages, daemon.log doesn't; copying...
[16:32] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/syslog
[16:35] <asac> pitti: ok and you added lcd-echo-failure to options right?
[16:35] <pitti> asac: right, with value "0"
[16:37] <asac> pitti: err sorry ... i think i mistyped
[16:37] <asac> pitti: lcp-echo-failure 0
[16:37] <asac> and while you are at it also add
[16:37] <pitti> asac: yes, that's what I actually have; it was already there, commented
[16:37] <asac> lcp-echo-interval 0
[16:37] <pitti> that's "30" right now
[16:37] <asac> pitti: yeah. make it 0
[16:37] <pitti> done
[16:38] <asac> i had people for which it helped that they instantly got disconnected
[16:38] <pitti> restart n-m, try again, new log?
[16:38] <asac> (and its a known bug)
[16:38] <asac> pitti: yeah. at best a tail
[16:38] <asac> started when you restart NM
[16:38] <pitti> yep
[16:38] <asac> pitti: ensure that no ppp stuff is running
[16:40] <lakitu> hey, no one in ubuntu could help me - i used gparted to shrink an ntfs drive, & now it's file system is damaged.  one, i'd like to report this, two, how do i solve this?
[16:40] <lakitu> #ubuntu/ubuntu
[16:40] <pitti> asac: connected!
[16:41] <asac> pitti: good crack. please do a bit stress testing ;)
[16:41] <asac> like reconnecting, replugging and stuff
[16:41] <asac> if it doesnt work sometimes its ok ... as long as it works most of the time ;)
[16:42] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/syslog-lcp-echo-interval-0.txt
[16:43] <asac> yeah cool. seems ok
[16:43] <pitti> asac: clicking on the connection again (reconnect) doesn't work
[16:43] <asac> pitti: this time the modem didnt even go over 0,0 ... which means you were a bit lucky at least
[16:44] <pitti> asac: http://paste.ubuntu.com/66818/
[16:44] <pitti> ^ reconnect attempt
[16:44] <asac> pitti: yeah. does it work after that again?
[16:44] <pitti> asac: whoops, sorry, that paste was incomplete
[16:44] <asac> pitti: i think i have the same issue when i directly reconnect (without disconnect)
[16:44] <pitti> no, it was complete, sorry
[16:45] <asac> pitti: for me without a disconnect it works every second attempt
[16:46] <asac> e.g. connect -> ok, reconnect -> fail -> connect -> OK ...
[16:46] <asac> and connect -> ok, disconnect -> ok -> connect -> OK
[16:46] <pitti> asac: disconnect/connect worked 4 times in a row
[16:46] <asac> pitti: ok thats good enough.
[16:46] <pitti> I agree
[16:47] <pitti> asac: direct reconnect 3 failures out of 3, but *shrug*
[16:47] <pitti> asac: stress test 3, unplugging/replugging
[16:47] <asac> pitti: ok. so we have: 1st -> fix database (event.vodafone.de), 2nd -> patch for ppp options, 3rd -> patch for "give more time"
[16:47] <asac> 2nd is already scheduled for SRU ... so we should make a bug out of 3
[16:48] <pitti> asac: the changes I did to ppp/options should be done statically for all people?
[16:48] <pitti> how will that affect users of modems?
[16:48] <asac> pitti: no .... it will be done by NM
[16:48] <asac> pitti: its a bug that it forgets to specify a bunch of default options
[16:48] <pitti> asac: 1st (event.v.d) -> I can do that if you want me
[16:49] <asac> pitti: i will do that ... have to talk with upstream guy about next SRU anyway
[16:49] <asac> pitti: not sure if we want to use the bug you posted the log to for the timeout patch though
[16:49] <pitti> asac: yeah, what I thought; accumulate some more fixes; if there aren't any, we can just do it for this own patch, though
[16:50] <pitti> asac: okay, unplug/replug/connect worked 3/3, too \o/
[16:50]  * pitti hugs asac
[16:50] <pitti> asac: I'll revert the changes to /etc/ppp/options now, so that I can test the SRU properly
[16:51] <pitti> asac: bug/timeout patch> depends, is it actually related to the problem of the original reporter?
[16:52] <asac> pitti: nobody can tell. asked now
[16:52] <asac> pitti: will target that bug for -updates
[16:52] <pitti> asac: thanks
[16:52] <asac> pitti: will provide test packages there on next round
[16:53] <asac> have to get all the patches i send out for testing together first ;)
[16:53] <asac> pitti: yeah. the options bug is bug 268667 ;)
[16:53] <asac> (in case you want to subscribe that)
[16:54] <asac> but you will see this soon enough anyway ,)
[16:54] <pitti> done
[16:54] <pitti> asac: whom can I ping about the database SRU?
[16:55] <pitti> I'd like to find out whether it's worth doing an SRU for that websessions tariff, or whether there are more fixes piled up upstream
[16:55] <asac> pitti: last time i talked to him he said he would like to establish a procedure to make a new database release every 2-4 weeks
[16:56] <asac> pitti: his nick is wellark ... he sometimes is in my mozilla channel
[16:56] <asac> pitti: but otherwise he is in #nm or #mbca
[16:56] <asac> pitti: https://bugs.edge.launchpad.net/mobile-broadband-provider-info
[16:56] <Cheery> how to provide /dev/snd/midiC0D0 ?
[16:56] <pitti> asac: ok, he's away right now, I'll discuss that procedure with him
[16:57] <asac> pitti: there are the bugs that wait to be pulled upstream. also there might already be more upstream commits
[16:58] <pitti> asac: right; I pinged him
[16:58] <pitti> asac: thanks a lot for your help!
[16:58] <asac> pitti: welcome
[16:58] <asac> pitti: ok i also told him that he should ping you here ... so double tapping ;)
[17:07] <pitti> Keybuk: after reading https://bugzilla.redhat.com/show_bug.cgi?id=453095, I'm not that convinced any more that bug 280931 (where you commented on) is indeed a kernel bug
[17:08] <Keybuk> oh?
[17:08] <Keybuk> it's a dup of a bug that's filed on the kernel
[17:08] <pitti> Keybuk: I did confirm that reverting a kernel commit fixes it
[17:08] <liw> cd tray closing after eject? I had that, I used setcd (I think) to disable it
[17:08] <pitti> but that RH bug and http://marc.info/?l=linux-hotplug&m=121749053301147&w=2 are pretty convincing, too
[17:08] <Keybuk> what do the RH people say?
[17:08] <Keybuk> having web browser issues
[17:09] <pitti> Keybuk: udev has a rule which causes vol_id to be run on the device, which does open(), which closes the tray
[17:09] <Keybuk> is that a change rule?
[17:09] <pitti> Keybuk: so applying that rule patch allegedly fixes it (haven't tried myself yet, but lots of confirmations)
[17:09] <pitti> and reverting that kernel change fixes it, too
[17:10] <Keybuk> sounds reasonable
[17:10] <pitti> so maybe the kernel change just triggered the udev rule
[17:10] <Keybuk> has anyone filed the bug to udev upstream?
[17:10] <Keybuk> since that's an upstream rules file, I avoid patching it
[17:10] <pitti> the kernel change fixed the DISC_INFO ioctl (open/no disk/etc.)
[17:10] <pitti> Keybuk: yes, it is fixed upstream already
[17:10] <pitti> Keybuk: I'll continue to poke in this
[17:10] <Keybuk> ok, we'll pick up the fix when I update udev then
[17:10] <pitti> Keybuk: I just wanted to ask you whether you just said "itz kernel bug" based on the dup bug, or whether you actually read that RH bug
[17:11] <sebner> pitti: Keybuk already and EST for doing a proposed upload? /me is interested because my family's pc is also infected =)
[17:11] <Keybuk> just based on the previous existance of the dup
[17:11] <Keybuk> sebner: upload of?
[17:11] <pitti> Keybuk: ok, thanks; just wanted to make sure to not discard any insight from you
[17:11] <pitti> sebner: for that cd eject bug?
[17:12] <Keybuk> I'm not planning a udev upload for a few weeks
[17:12] <sebner> yep
[17:12] <Keybuk> jaunty isn't even open yet
[17:12] <pitti> I think I'll read everything again now, check udev upstream status, test the fix myself, and prepare an upload (or Keybuk does it, if he wants to)
[17:12] <pitti> Keybuk: oh, I'm more concerned about intrepid SRU at this point
[17:12] <Keybuk> and I plan to switch to using upstream rules (which need me to do some work on them first) with the jaunty upload
[17:12] <sebner> pitti: so an upload could be ready in the next few days?
[17:12] <Keybuk> I'm uninterested in intrepid SRU :)
[17:12] <Keybuk> it doesn't seem that worthy a bug for it
[17:12] <pitti> Keybuk: ok, I'll do that then
[17:12] <pitti> Keybuk: oh, I regard it as very serious
[17:13] <Keybuk> and I really don't like fiddling with those rules, because you tend to end up breaking other things
[17:13] <Keybuk> very serious?  the CD tray pulls itself back in every now and then?
[17:13] <pitti> Keybuk: I just started appreciating when I used my desktop with a motor tray again :)
[17:13] <Keybuk> vs. "my RAID doesn't boot anymore"
[17:13] <pitti> Keybuk: it does it every time, you can't sanely take out a CD
[17:13] <Keybuk> sure you can, just push the button on the CD drive
[17:13] <Keybuk> works for me ;)
[17:13] <sebner> At least here the tray opens, closes and doesn't open anymore until xserver is restarted
[17:13] <pitti> and since it's so unexpected, it's likely to physically squash media or fingers
[17:14] <pitti> Keybuk: not for me
[17:14] <pitti> eject button or eject program is all the same
[17:14] <Keybuk> make sure you get a lot of testing
[17:14] <pitti> yeah
[17:14] <Keybuk> not just that it fixes it for people, but that it doesn't break things like lvm, raid, etc.
[17:14] <Keybuk> the patch is quite ... widely encompassing
[17:15] <Keybuk> it could make vol_id not be run for all sorts of things
[17:15] <Keybuk> and we need vol_id for mounting disks ;)
[17:15] <pitti> Keybuk: https://bugzilla.redhat.com/attachment.cgi?id=312742 is weird, but it's not what upstream used AFAIK
[17:15] <pitti> is udev upstream in gitweb somewhere?
[17:15] <Keybuk> it's in kay's sekrit git
[17:16] <Keybuk> might also be on gitweb proper
[17:16] <Keybuk> http://git.kernel.org/?p=linux/hotplug/udev.git;a=log
[17:16] <pitti> Keybuk: http://marc.info/?l=linux-hotplug&m=121783305407150&w=2
[17:16] <Keybuk> though be slightly careful
[17:16] <Keybuk> Kay's completely rewritten udev's rules matching engine
[17:17] <Keybuk> pitti: that rule seems entirely sane
[17:17] <Keybuk> (for once, it's completely backwards compatible
[17:17] <pitti> found it
[17:17] <pitti> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f755fd5657b619fd27160ad202fc5d773d096e9c
[17:17] <Keybuk>  but rules written for the new engine won't necessarily work with older udev)
[17:18] <Keybuk> pitti: looks good
[17:18] <Keybuk> rule should work with old udev too
[17:19] <pitti> Keybuk: ok, thanks for review; the upstream commit seems pretty focused and few side effects to me, too
[17:19] <pitti> Keybuk: ok, I'll have some dinner and prepare an SRU afterwards
[17:19] <Keybuk> the basic difference (other than no shared code ;p) is that the new engine supports things like KERNELS=="foo", KERNELS=="bar"
[17:19] <Keybuk> the old engine only allowed one of any match
[17:19] <Keybuk> (or 5 env or attr matches)
[17:19] <pitti> Keybuk: WDYM with "old engine"? intrepid has 124
[17:21] <Keybuk> git head has a rewritten rules matching engine
[17:21] <Keybuk> and, for that matter, rewritten run and device queue
[17:21] <Keybuk> it's quite a lot faster and less memory-hungry
[17:21] <Keybuk> and also less braindead
[17:22] <Keybuk> but WAAAAAAAH!
[17:25] <kirkland> pitti: okay, i have a debdiff for ecryptfs-utils for interactive password prompt, but I'm really, really going to need you or someone on the desktop to have a look at it
[17:26] <kirkland> pitti: to tell me if the user-experience makes sense there
[17:28] <kirkland> pitti: http://pastebin.ubuntu.com/66842/
[17:32] <pwnguin> is anyone interested in getting seekwatcher packaged for jaunty?
[17:33] <pwnguin> http://oss.oracle.com/~mason/seekwatcher/ (check out the videos)
[18:09] <s0u][ight> hello what are big packages that are installed on the live cd that can be missed?
[18:09] <s0u][ight> like sound
[18:09] <s0u][ight> what package manages all the sound?
[18:09] <s0u][ight> so i can remove everything about sound
[18:17] <mohbana> hi, when is texlive 2008 going to be in the repo?
[18:18] <mohbana> also how do i force the installation of a 32bit .deb file, i've got adobe reader but it's only available as 32bit binary
[18:19] <ranjithk>  anybody here uses monaco font in their terminal?
[18:20] <mohbana> ranjithk: i've tried it, but i quickly went back to the default
[18:20] <mohbana> ranjithk: rendering is crap, i bet
[18:20] <mohbana> also how long does it take to resize a partition, i think i've allocated to little to ubuntu
[18:21] <mohbana> ranjithk: i've filled a bug. i understand what you mean
[18:21] <mohbana> it's horrible
[18:22] <s0u][ight> where can i find info about how the live cd of ubuntu is made
[18:22] <mohbana> ranjithk: 1. https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/190848 and 2. https://bugs.launchpad.net/ubuntu/+bug/292375
[18:22] <ranjithk> i m using monospace for now, but monaco was simply superb
[18:22] <mohbana> ranjithk: complain
[18:23] <mohbana> because this is just horrible, i can;t believe they allowed this to get through
[18:23] <ranjithk> yeah!.. very bad.
[18:26] <pitti> kirkland: in general this looks fine to me, however, some notes
[18:26] <pitti> kirkland: (1) so there isn't a convenient KDE counterpart to this?
[18:26] <NCommander> morning world
[18:27] <pitti> kirkland: (2) does ecryptfs have any gettextization so far? it would be important to wrap the strings into a gettext call
[18:28] <pitti> kirkland: (3) I think mpt will have some wording improvements; e. g. "THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA" -> "Your private directory needs to be unlocked with your password. Run me to authenticate" or something?
[18:29] <mpt> ECONTEXT
[18:29] <pitti> mpt: that was a reply about http://pastebin.ubuntu.com/66842/
[18:29] <pitti> mpt: do you know about ~/Private ?
[18:30] <mpt> pitti, no, where is it explained?
[18:30] <pitti> the encrypted directory which is unlocked at login, when you use ecryptfs?
[18:31] <pitti> kirkland: ^ any good doc URL for that?
[18:31] <kirkland> pitti: 1) i farted around with kdesu, and couldn't get it to work correctly; posed a couple of questions above in this channel to the kde developers
[18:31] <kirkland> mpt: pitti: http://help.ubuntu.com/community/EncryptedPrivateDirectory
[18:32] <kirkland> pitti: 2) not much i18n for ecryptfs yet; hoping to improve that in Jaunty timeframe
[18:32] <mpt> There's no button to turn it on?
[18:32] <pitti> kirkland: maybe the dummy file name could say "Run me" if gksu is available (and in the future, the KDE counterpart), or "run ecryptfs-unlock-blabla" if ont?
[18:32] <pitti> mpt: only in the alternate installer so far
[18:32] <mpt> heh
[18:32] <kirkland> pitti: 3) I'd like to keep that wording the same for Intrepid, improve for Jaunty
[18:32] <pitti> kirkland: 2) OK; it's dynamic text, so we can i18n it once the package has i18n infrastructure
[18:33] <kirkland> pitti: i have a new patch, moves around this stuff a little bit
[18:33] <pitti> kirkland: yes, I'm not suggesting to change it for intrepid
[18:33] <kirkland> pitti: i think it might be a little better, i'm testing it now
[18:33] <pitti> kirkland: all three of my points actually refer to jaunty
[18:33] <kirkland> pitti: oh, okay
[18:33] <kirkland> pitti: so tell me this.....
[18:33] <kirkland> pitti: how do we want to handle this in intrepid?
[18:34] <kirkland> pitti: document that encrypted private + automatic login is incompatible?
[18:34] <mohbana> also how long does it take to resize a partition, i think i've allocated to little to ubuntu
[18:35] <pitti> kirkland: TBH I think the existing file stub is enough to point it out, or do you disagree?
[18:35] <pitti> kirkland: I wouldn't worry too much about intrepid for that
[18:35] <pitti> kirkland: ubiquity doesn't even offer it, so people who run it actually have to search and fiddle anyway
[18:36] <kirkland> pitti: we have multiple users, multiple duplicate bug reports complaining about their encrypted private not working .... after 2 weeks of discussing, it finally comes out that their automatically logging in (no password)
[18:36] <pitti> kirkland: gotta run now (Taekwondo), can we continue tomorrow? thanks
[18:36] <kirkland> pitti: please
[18:36] <kirkland> pitti: or ping me if you come back around later
[18:36] <pitti> kirkland: yeah, I'm not *opposed* to fix it in intrepid
[18:36] <pitti> just not the full i18n'ing and all that
[18:36] <kirkland> pitti: i'm just looking for a realistic approach
[18:36] <kirkland> pitti: righto
[18:36] <mpt> pitti, I don't understand what that string is saying
[18:39] <mpt> kirkland, is this a graphical alert or something that appears in the terminal?
[18:39] <mpt> or something else?
[18:40] <kirkland> mpt: when your ~/Private directory is not mounted, you can't see any of your data there
[18:40]  * NCommander looks at evil bug #286175
[18:40] <kirkland> mpt: in its place, you see a single file (actually a symlink) that contains that string, above
[18:40] <kirkland> mpt: the symlink actually points to the binary that can "fix" the situation for you, by mounting your private directory again (prompting you for a password along the way)
[18:41] <mpt> Ah yes, we talked about this at the last UDS
[18:41] <kirkland> mpt: yup, we did
[18:41] <mpt> though I'm pretty sure the word "unmount" wasn't used ;-)
[18:41] <kirkland> mpt: i think it might have been your idea?
[18:41] <kirkland> mpt: the symlink bit?  maybe, maybe not....
[18:42] <mpt> I think that was your idea
[18:42] <mpt> so, if double-clicking will make the Private folder available again
[18:42] <mpt> why are you trying to also include command-line instructions?
[18:43] <kirkland> mpt: because there is no gui in the server
[18:44] <mpt> What difference does that make?
[18:44] <mpt> (for "double-clicking" read "running the script")
[18:44] <kirkland> mpt: from the command line, if you cd to ~Private, and do "ls", you see this informative file name
[18:45] <kirkland> mpt: if you on the command line, you say, "Oh, okay ....  mount.ecryptfs_private"
[18:45] <mpt> Why does it need to be informative instead of imperative?
[18:45] <mpt> ./Show\ the\ Private\ folder
[18:46] <kirkland> mpt: what do you suggest the text should be?
[18:47] <mpt> If it's a script that already does the right thing, why wouldn't people just run the script
[18:47] <kirkland> mpt: it's a symbolic link to a binary
[18:47] <mpt> ok, a binary then
[18:48] <kirkland> mpt: possibly not immediately obvious that it is executable?
[18:49] <mpt> Even without -l, ls shows which items in a directory are executable
[18:49] <kirkland> mpt: take a look at a symlink to an executable
[18:49] <mpt> aha
[18:50] <mpt> Fix ls then ;-)
[18:58] <mpt> I don't have any other particularly great ideas on improving that
[19:04] <s0ullight> what package do i have to remove to remove sound?
[19:07] <azeem> s0ullight: please ask in #ubuntu
[19:07] <calc> i wanted to let everyone know i am out of email contact since linux dhcp doesn't work here :(
[19:07] <azeem> calc: are you running the Hurd now or what?
[19:07] <calc> azeem: vista
[19:07] <azeem> ah
[19:08] <calc> azeem: no matter what i did on ubuntu it wouldn't stop giving me 'message too long' errors
[19:09] <calc> maybe i'll be able to access it from the university but the hotel definitely doesn't work :(
[19:11] <calc> this 14hr offset is really weird getting used to
[19:12] <superm1> calc, you might try calling up the support number at your hotel.  When I was at a hotel in MTV, they actually had some sysctl parameters that needed to be adjusted when that happens
[19:15] <kirkland> is there some tool i can run a .desktop file through, to check compatibility across gnome/kde?
[19:15] <cjwatson> kirkland: desktop-file-validate?
[19:16] <kirkland> cjwatson: perfecto, thanks.
[19:16] <cjwatson> kirkland: perhaps with --warn-kde, not sure of the exact semantics of that
[19:16] <calc> superm1: i'm in beijing i'm lucky to reach anyone who can evern speak english :\
[19:38] <pochu> hi
[19:38] <pochu> when will packages start to be autosynced from Debian?
[19:39] <cjwatson> pochu: next couple of days
[19:40] <pochu> cjwatson: thanks
[19:40] <cjwatson> pochu: currently waiting for sparc to build glibc (delayed for various reasons), then build dpkg merge, then build debhelper merge, then open
[19:41] <pochu> it's ok to upload fixes to intrepid-proposed, and upload them/get them synced to Jaunty when it's opened, right?
[19:41] <NCommander> cjwatson, if I can provide a patch to fix the powerpc's glibc (once I run it by doko), does anything special need to happen to get the powerpc buildds to update?
[19:42] <cjwatson> NCommander: err - it's already done
[19:42] <NCommander> It was?
[19:42] <NCommander> Cool.
[19:42] <cjwatson> yes, I uploaded that earlier
[19:43] <cjwatson> pochu: given how close jaunty is to opening, it would be better to upload to jaunty first
[19:44] <NCommander> thanks cjwatson
[19:44] <cjwatson> on previous form sparc will take about five more hours though
[19:47] <NCommander> cjwatson, I look foward to jaunty as we will hopefully be able to improve support on the port architectures :-)
[19:49] <cjwatson> we won't block everything on working ports of course; glibc is a special case
[19:49] <cjwatson> well, the initial toolchain bootstrap in general
[19:50] <cjwatson> we could have opened primary architectures over the weekend if not for that
[19:55] <NCommander> cjwatson, how is the inital bootstrap of the toolchain done on each architecture?
[19:56] <mohbana> i get an 'exec: 579: /lib/ld-linux.so.2: not found' after i've installed adobe reader
[19:56] <mohbana> what's up
[20:08] <cjwatson> NCommander: by-hand builds of Ubuntu packages in a Debian base system (usually) until we have build-essential going, then bootstrap from that temporary set of builds and build everything again
[20:08] <cjwatson> needs to be done by a buildd admin in order to get into LP though
[20:15] <NCommander> cjwatson, sounds like a very time consuming and tedious process :-/
[20:16] <jcristau> sounds like a bootstrap, actually..
[20:16]  * RainCT is scared :)
[20:17]  * NCommander has done a bootstrap, hence the very time consuming and tedious comment ;-)
[20:17] <cjwatson> NCommander: yes
[21:11]  * Keybuk giggles at Iron Man
[21:11] <Keybuk> nobody who knows Mark can possibly not laugh at one particular line
[21:29] <mDuff> Re bug #129285 -- I've had a patch in the tracker since February, and it still hasn't been applied (or objected to); it still applies (and is needed) on Ibex. Is there anything I can do to help nudge this along?
[21:30] <directhex> ember, and possibly pitti and seb128 and, god, lots of others: PING
[21:31] <seb128> directhex: (I don't reply to contentless questions on IRC)
[21:33] <directhex> seb128, you've got your fingerprints over f-spot in ubuntu. i'm trying to make tomboy/f-spot people aware that the upcoming mono transitions in debian will completely break building packages, without changes to build-deps
[21:33] <seb128> directhex: why would they do that?
[21:33] <james_w> mDuff: hi, if you subscribe the "ubuntu-main-sponsors" team then someone will look at it. Providing debdiffs that showed the exact changes would help the sponsors review, but isn't required.
[21:34] <directhex> seb128, because the changes are needed to significantly shrink the dependency chain of produced packages
[21:34] <seb128> directhex: we will figure than in jaunty anyway, I don't think mono is synced directly so whoever does the merge should figure what to do
[21:34] <mDuff> james_w, thanks
[21:35] <directhex> seb128, sync. been working to allow mono to be synced rather than merged.
[21:35] <directhex> that's another incoming change
[21:36] <seb128> directhex: ok good, seems you have things under control
[21:36] <EspadaV8> hey, just been told to try here instead of #ubuntu...
[21:37] <EspadaV8> basically, i'm trying to get my Qt4 app to compile on ubuntu, i works fine on gentoo (what i developed it on) but on ubuntu it doesn't like a #include <phonon>
[21:37] <EspadaV8> anyone know what i should be including instead?
[21:37] <EspadaV8> or what needs to be apt-get'd to provide it?
[21:38] <directhex> seb128, ... mostly. it's gonna end up in experimental for now. the lagging release of lenny is unfortunately timed for jaunty - but jaunty will look bloody stupid if it ships with the same old release of mono as intrepid
[21:38] <seb128> directhex: I would say most users don't care about mono but having it updated would be nice indeed
[21:39] <directhex> seb128, it's attractive for windows developers
[21:40] <seb128> directhex: right, what I said, users usually don't care ;-)
[21:40] <directhex> seb128, about as much as they care about having the latest & greatest python release, i.e. a few users will bitch & whine, most won't care
[21:40] <seb128> directhex: seeing the number of duplicate and comment on the request to update the version it just doesn't seem to have a real traction
[21:41] <seb128> directhex: right, anyway this discussion has no real interest, having mono updated would be nice indeed
[21:41] <directhex> k
[21:42] <seb128> directhex: experimental is not autosyncing so we will not sync anything by mistake when jaunty opens anyway
[21:43] <seb128> directhex: if you are looking at what debian is doing just ask for syncs when you think the packages are good to be synced, transitionning early in the cycle is better than late that gives time to do the transition
[21:44] <psusi> TheMuso: are you the original author of isw-raid10-nested.dpatch in dmraid?
[21:47] <directhex> seb128, i'll request it when i think it's ready. of course, that's all for mono 2.0 - 2.2 is relased in december -_-
[21:47] <seb128> directhex: will the packaging need to change a lot between those versions?
[21:48] <directhex> seb128, we hope not, but upstream can be a little erratic. we don't think so, barring unforseen changes
[21:48] <seb128> ok good, let's see than, thank you for letting us know about the coming changes
[21:49] <seb128> not something for today in any case and it's late enough to stop working ;-)
[21:49] <seb128> bbl
[21:50] <directhex> seb128, forewarned is forearmed.
[22:00] <cjwatson> Keybuk: I think I know which bit you mean and I think I said exactly the same thing to Kirsten in the cinema :)
[22:26] <trv> does anybody know why linux-image-debug in intrepid is for 2.6.25 kernel and not 2.6.27? i want to find the vmlinux file for the current kernel
[22:27] <cjwatson> it moved to ddebs.ubuntu.com, I believe
[22:27] <cjwatson> so I'm told anyway; not a kernel hacker
[22:34] <Keybuk> it did
[22:34] <Keybuk> despite being a dependency and build-dependency of things in the archive
[22:35] <trv> thank you
[22:35] <trv> there are too many things pointing to the old kernel
[22:35] <trv> like linux-image-i386
[22:35] <trv> and stuff like that
[22:39] <TheMuso> /c/c
[22:39] <psusi> TheMuso: are you the original author of isw-raid10-nested.dpatch in dmraid?
[22:40] <TheMuso> psusi: No it was taken from mandriva.
[22:40] <TheMuso> As noted in an earlier changelog entry when the patch was originally included.
[22:41] <psusi> ahh... I think I found the problem with it but I'm trying to understand the patch better before I'm sure
[22:53] <wasabi> Think apport is ever going to be useful to enable in releases?
[22:53] <wasabi> Like, is anybody actively working on automatic duplicate collapsing?
[23:02] <Keybuk> wasabi: I don't think it'd ever be useful
[23:02] <Keybuk> we don't actively fix bugs in our releases once they're out
[23:02] <Keybuk> our focus is always the next release
[23:03] <wasabi> That is true. I do think collecting stack traces is useful though.
[23:04] <wasabi> I mean, MS does some amazing stuff with their error reporting data.
[23:04] <wasabi> Analyzing trends over time, etc.
[23:04] <trv> ok, can't find the vmlinux image at ddebs.ubuntu.com either.. does anybody know where can one find the vmlinux images for our kernel?
[23:04] <bryce> wasabi: there is risk that the added noise would just dilute the bugs that we can fix
[23:05] <wasabi> I agree. I was just wondering if it's been considered.
[23:05] <bryce> esp. for packages not actively triaged