[12:51] <Utnubu> hi all
[12:53] <calc> i need updated hsqldb <IP_ADDRESS>-1 but it doesn't seem to be in ubuntu and isn't in the merge o matic either?
[12:53] <calc> anyone know how i get it in that case?
[12:53] <Utnubu> Is it known that i810 video playback with compiz works fine but in contrast to the intel driver changelog video playback with compiz doesn't work at all or at least not on all platforms like i915
[12:53] <ajmitch> what do you mean by "isn't in ubuntu"?
[12:53] <mjg59> Yes
[12:54] <ajmitch> given that the source package seems to be there
[12:54] <calc> ajmitch: hmm maybe it is
[12:55] <ajmitch> it's probably a small change, so a manual merge wouldn't take long
[12:55] <calc> ajmitch: i don't see the source there -> http://archive.ubuntu.com/ubuntu/pool/main/h/hsqldb/
[12:55] <ajmitch> strange, since I'm fetching it now with apt-get
[12:56] <calc> ajmitch: <IP_ADDRESS>-1 ?
[12:56] <calc> maybe its so new it isn't fully mirrored yet (dunno?)
[12:56] <ajmitch> calc: no, there's no way that <IP_ADDRESS>-1 could get in the archive without a sync or merge
[12:56] <ajmitch> MoM has its own cache of packages
[12:57] <calc> ajmitch: hmm grab-merge didn't give me anything
[12:57] <calc> and the dir seems empty
[12:57] <calc> + wget -q http://merges.ubuntu.com/h/hsqldb/REPORT
[12:57] <ajmitch> probably because MoM hasn't updated, or isn't updating
[12:57] <ajmitch>  dget -x http://ftp.debian.org/debian/pool/main/h/hsqldb/hsqldb_<IP_ADDRESS>-1.dsc
[12:58] <calc> so you were fetching it via apt-get how?
[12:58] <ajmitch> deb-src lines for gutsy & sid?
[12:58] <calc> ajmitch: ah ok
[12:59] <ajmitch> sole ubuntu change seems to be to debian/{control,rules}
[01:00] <calc> ajmitch: ah i forgot about snapshot.d.n :)
[01:01] <ajmitch> it comes in useful
[01:05] <calc> yep it is
[01:05] <calc> i used it quite a bit with kde
[01:08] <Utnubu> Is it known that ctrl + alt + L (locking) doesn't work with enabled compiz in Gutsy?
[01:08] <Utnubu> Btw. is there a reastion why compiz settings isn't installed by default?
[01:09] <RAOF> Utnubu: Because it's evil, user-unfriendly crack.
[01:10] <RAOF> Utnubu: Also, ctrl+alt+L works for me.  Are you perhaps referring to bug #122549
[01:10] <ubotu> Launchpad bug 122549 in compiz "[gutsy]  compiz fusion breaking gnome-screensaver behaviour" [High,Confirmed]  https://launchpad.net/bugs/122549
[01:15] <Utnubu> RAOF: no, it is a different problem.
[01:15] <Utnubu> Screensaver works fine here.
[01:16] <RAOF> Utnubu: You can't alt+tab past the lock? :)
[01:16] <Utnubu> I think compiz uses the short cut ctrl + alt + L
[01:16] <RAOF> Maybe.  What does it do when you hit them?
[01:17] <Utnubu> Nothing I can realize :)
[01:19] <Utnubu> But it is great that two big compiz bugs have been fixed. (the xv and vnc issue)
[01:20] <Utnubu> Xv only for i810 driver for my card but at least it works :)
[01:28] <Utnubu> And it would be great if this bug https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 could be fixed. I have uploaded a patch which fixes the problem.
[01:28] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybrightness.sh doesn't use the correct value range" [Undecided,New]
[02:35] <Tm_T> hi kids
[03:13] <luisbg> I got accepted as an ubuntero today, who do I have to talk to fo my mail adress?
[03:15] <nixternal> ubuntero or ubuntu member?
[03:16] <luisbg> ubuntu member
[03:16] <luisbg> what's the difference
[03:17] <ajmitch> ubuntero is just signing the CoC
[03:17] <nixternal> ubuntero just means you signed the code of conduct, ubuntu member means you were approved as a contributor to ubuntu by the community council
[03:17] <luisbg> ahhhh I signed the CoC like a year ago
[03:17] <ajmitch> as nixternal said, when you're an ubuntu member you can be special like him :)
[03:17] <luisbg> but since today I'm an ubuntu member
[03:17] <nixternal> cool, welcome then!
[03:17] <luisbg> thanks
[03:17] <luisbg> nixternal, you must be too
[03:17] <ajmitch> congrats
[03:18] <nixternal> luisbg: the admins will forward your @ubuntu.com email address to the email address you have listed in your launchpad account...that can take up to 2 weeks to complete
[03:18] <nixternal> it could take less though...it was only a few days for me a couple of years ago
[03:19] <luisbg> nixternal, which admins?
[03:20] <nixternal> who ever controls that stuff for Ubuntu
[03:20] <luisbg> LOL
[03:20] <luisbg> I see
[03:20] <nixternal> canonical employees
[03:20] <nixternal> hehe
[03:21] <luisbg> ;)
[03:22] <dobey> an ubuntu bofh will do it :P
[03:25] <luisbg> :S
[04:19] <shaya> anyone seeing issues w/ firefox and Xgl (seems gutsy is now launching it automatically)
[04:22] <stdin> shaya: I noticed that, so I just removed Xgl (I don't really need it)
[04:23] <RAOF> shaya: For what it's worth, I don't see any bad firefox/Xgl interaction.
[04:23] <stdin> I noticed FF redrawing slow, well all apps actually
[04:24] <RAOF> Hm.  fglrx, without compiz?
[04:24] <dobey> afaik, xgl is in universe, and not part of the default install...
[04:25] <RAOF> dobey: But the package *has* been changed so that installing it sets it up to be used by default.
[04:25] <dobey> ok
[04:25] <stdin> the strange (I think) thing I noticed too, is that X aswel as Xgl were running
[04:26] <dobey> yes
[04:26] <RAOF> On what I thought were the reasonable grounds that someone who installs xserver-xgl wants to actually use Xgl :)
[04:26] <dobey> Xgl is not a separate individual X server
[04:26] <RAOF> Well, it is.
[04:26] <dobey> it requires Xorg to be running as well
[04:26] <dobey> it's not a mutually exclusive server
[04:26] <RAOF> But the one we ship needs an underlying Xorg server to set up an OpenGL context for it.
[04:26] <dobey> right
[06:12] <fabbione> morning guys
[08:54] <mdke> morning all
[08:55] <soren> mdke: 'morning.
[09:19] <dholbach> good morning
[09:19] <mdke> hiya dholbach
[09:20] <dholbach> hey mdke
[09:20] <LaserJock> hi dholbach
[09:20] <dholbach> hey LaserJock
[09:22] <TheMuso> 11/c
[09:22] <TheMuso> uh
[09:22] <TheMuso> damn orca
[09:33] <Mithrandir> asac: why does firefox claim a restart is required when I just booted the machine?
[10:07] <hunger> ubuntu-desktop is not installable here. diveintopython is not found. Is that a known issue?
[10:07] <Hobbsee> hunger: if it's listed on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[10:08] <Hobbsee> hunger: those are the packages in main which are not installable.
[10:08] <Hobbsee> hunger: however, diveintopython seems to exist there, so...
[10:08] <cjwatson> diveintopython | 5.4-2ubuntu2 |         gutsy | source, all
[10:08] <cjwatson> sounds like a local networking or local mirror issue
[10:09] <Hobbsee> wow, a nice short list for !sparc, close to a tribe...
[10:10] <hunger> cjwatson: My mirror is archive.ubuntu.com
[10:11] <hunger> cjwatson: aptitude gives this error: E: I wasn't able to locate file for the diveintopython package. This might mean you need to manually fix this package.
[10:11] <seb128> hunger: apt-cache policy | grep main?
[10:11] <Hobbsee> mirror seems fine, so the original archive must be fine
[10:13] <hunger> seb128: The usual urls on archive.ubuntu.com (gutsy-security, -backports, -updates, gutsy itself), all on piority 500.
[10:13] <seb128> hunger: apt-cache policy diveintopython ?
[10:13] <hunger> Did a new update... seems that it works now.
[10:14] <hunger> Maybe I grabed something partly updated before or something:-(
[10:15] <cjwatson> iwj: bug 137179 might be your call ...?
[10:15] <ubotu> Launchpad bug 137179 in glibc "2.6.1-1ubuntu3 makes apps crash with Bus error" [Undecided,New]  https://launchpad.net/bugs/137179
[10:35] <asac> Mithrandir: i doubt that its firefox claiming that ... i just copy the restart notification during postinst
[10:36] <Mithrandir> asac: well, the notification shouldn't be there if you reboot.
[10:36] <asac> Mithrandir: but i never really cared of who is doing what for this notification
[10:37] <asac> Mithrandir: yes agree ... but is it a firefox bug?
[10:38] <Mithrandir> asac: I'd say so, yes.
[10:39] <asac> Mithrandir: it has DontShowAfterReboot: True ... so isn't it a problem of update-notifier?
[10:40] <asac> Mithrandir: otherwise i don't really see what firefox can do
[10:40] <asac> Mithrandir: (or maybe we are talking about different things)
[10:40] <Mithrandir> hm, ok, then it's an update-notifier bug
[10:42] <asac> mvo_: ^^^
[10:43] <asac> mvo_: what do you think?
[10:44] <stgraber> morning
[10:44] <asac> hey stgraber
[10:45] <mvo_> Mithrandir: could you please kill it and run it again, if the problem presists, please run it with "update-notifier --debug-hooks" and send me the output (or put it to a pastebin)
[10:45] <stgraber> asac: tried NM+ipw3945 at school, switching between public networks, reconnecting, ... works just fine
[10:46] <asac> stgraber: rock
[10:46] <asac> stgraber: if noone pops up who is willing to test this (which is a bit of a shame), then I will ask the kernel team to review and roll the module update
[10:47] <Mithrandir> mvo_: given I clicked on it, to see what it wanted from me, I guess it won't show again
[10:47] <mvo_> Mithrandir: hrm, good point
[10:47] <Hobbsee> good morning sabdfl, asac, Mithrandir, mvo_, etc
[10:47] <mvo_> hey Hobbsee
[10:47] <asac> hey Hobbsee ....
[10:47] <stgraber> asac: one of my teacher also has a laptop with a ipw3945 card, I may try the fixed driver on his laptop this afternoon
[10:47] <Hobbsee> stgraber: does it seem to be stable/
[10:48] <stgraber> Hobbsee: yup
[10:48] <Hobbsee> stgraber: or does NM drop the connection?
[10:48] <Hobbsee> stgraber: nice!
[10:49] <stgraber> Hobbsee: I'm currently connected on a network with a very weak signal, so sometimes it looses the signal but reconnect just fine afterwards (as expected)
[10:49] <asac> stgraber: that would be nice
[10:50] <asac> (e.g. test on a second laptop)
[10:50] <Hobbsee> stgraber: ok, will try
[10:50] <asac> Hobbsee: great!
[10:50] <Mithrandir> morning Sarah
[10:50] <Hobbsee> asac: do you happen to have the link to the newer driver again?  my other client dropped off the network last night, adn i dont have the scrollback
[10:50] <asac> Hobbsee: still  have the instructions?
[10:50] <Hobbsee> asac: nope :(
[10:50] <asac> Hobbsee: sure
[10:51] <asac> Hobbsee: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
[10:52] <asac> Hobbsee: install kernel headers at al then: make IEEE80211_IGNORE_DUPLICATE=y SHELL=/bin/bash
[10:52] <norsetto> anyone on kubuntu/i386, that can check bug 137222 and report if you have the same problem?
[10:52] <ubotu> Launchpad bug 137222 in adept "Adept description field is wrong" [Undecided,Confirmed]  https://launchpad.net/bugs/137222
[10:53] <Hobbsee> norsetto: checking...patience, patience...
[10:53] <Hobbsee> norsetto: youd' do better in #Kubuntu-devel, FYI
[10:53] <norsetto> Hobbsee: sorry, thanks, wasn't sure you were alive :-)
[10:53] <Hobbsee> :)
[10:54] <asac> mvo_: how does update-notifier determine if the notification was put there before reboot? does it just rm all hints marked as "not display after reboot" during boot?
[10:54] <mvo_> asac: it compare uptime and mtime of the notification
[10:54] <Hobbsee> norsetto: no.
[10:55] <Hobbsee> norsetto: shows the proper description here
[10:55] <norsetto> Hobbsee: ok, thanks, I see the same on mine, which is x86_64 too
[10:55] <norsetto> Hobbsee: I mean, same problem, not same as you
[10:56] <stgraber> Hobbsee: are you running amd64 or i386 ? (I have amd64 driver and package here)
[10:56] <Hobbsee> stgraber: i386
[10:56] <stgraber> ok, so maybe asac has the i386 ones
[10:57] <asac> i am on amd
[10:57] <Hobbsee> stgraber: bah.  this machine builds reasonably fast, anyway
[10:57] <Hobbsee> asac: then just copy the .ko, or do something with the .mod.o too?
[10:58] <asac> Hobbsee: please ask stgraber for the exact procedure
[10:58] <asac> stgraber: can you guide Hobbsee ?
[10:58] <asac> i think: its just replace the .ko module ... then reload the module
[10:59] <Hobbsee> ah cool...  ok, will try
[10:59] <asac> and confirm that modinfo does show the right version afterwards
[10:59] <asac> it should be 1.2.1something ... not 1.2.2something
[10:59] <Hobbsee> gotcha
[11:02] <asac> just the kernel module should improve your situation ... the final cure you only get with a new network-manager:
[11:02] <asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[11:02] <Hobbsee> hmmm.
[11:02] <stgraber> Hobbsee: replace the ipw3945.ko in ubuntu/wireless/ipw3945/, then depmod -a, then ipw3945d-2.6.22-10-generic --kill, then modprobe ipw3945
[11:02] <asac> what happened?
[11:02] <Hobbsee> stgraber: ahhh.  forgot to depmod -a
[11:03] <Hobbsee> no wonder it didnt work!
[11:04] <stgraber> Hobbsee: error message ?
[11:06] <asac> stgraber: i think she said that it didn't work because of not running depmod -a
[11:07] <stgraber> a ok
[11:10] <asac> hmm Hobbsee is offline :) ... that can't be good news ;)
[11:10] <LongPointyStick> asac: no dice, yet
[11:12] <asac> hi LongPointyStick
[11:13] <asac> what topic?
[11:17] <Hobbsee|Remote> asac: is that better?
[11:17] <asac> yeah
[11:17] <Hobbsee|Remote> still no dice.
[11:17] <Hobbsee|Remote> as in, i never seem to get the new version showing up
[11:18] <asac> so do you see the right module version
[11:18] <Hobbsee|Remote> nope
[11:18] <Hobbsee|Remote> i still get 1.2.1*
[11:19] <asac> thats correct
[11:19] <asac> the gutsy is 1.2.2
[11:19] <Hobbsee|Remote> oh, i thought i was suppsoed to get 1.2.2
[11:19] <Hobbsee|Remote> version:        1.2.1d
[11:20] <asac> yes that should be ok
[11:20] <Hobbsee|Remote> ahhh.
[11:20] <Hobbsee|Remote> well, then.  we have dice.
[11:20] <asac> :)
[11:20] <Hobbsee|Remote> so it did work right, all along.
[11:20] <asac> ok it should basically connect now
[11:20] <davmor2> bryce: I have updated bug 134284 with my lspci -nnvv is there any other info you need?
[11:20] <ubotu> Launchpad bug 134284 in xorg "The X intel driver is not functioning correctly" [Undecided,New]  https://launchpad.net/bugs/134284
[11:21] <asac> Hobbsee|Remote: but switching networks might still break at some point ... would be cool if you could test the new nm as well
[11:21] <asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[11:22] <glatzor> davmor2: bryce lives in the USA
[11:22] <asac> Hobbsee|Remote: its a full-source bzr branch ... so you don't need an orig.tar.gz to build
[11:22] <davmor2> damn
[11:22] <Hobbsee|Remote> asac: did you want to know if it works on an open network here too?
[11:22] <Hobbsee|Remote> before testing the new NM?
[11:23] <asac> Hobbsee|Remote: yes please do ...
[11:23] <Hobbsee|Remote> ok.  good thing dad's not home.
[11:23] <asac> ;)
[11:24] <asac> hurry
[11:24] <Hobbsee|Remote> he's out of the state, he wont be home for a few more hours.  i think
[11:24] <Hobbsee|Remote> yay, i win.
[11:25] <Mithrandir> with a big hammer!
[11:26] <asac> i would suggest a screwdriver
[11:26] <asac> its far less destructive ;)
[11:29] <seb128> Riddell: I want to update poppler to 0.6, is that ok with you?
[11:30] <Riddell> seb128: yes, please do
[11:30] <seb128> thanks
[11:31] <kwwii> seb128: did you see that I commited the emblems?
[11:32] <Hobbsee|Remote> Mithrandir: ah.  right.
[11:33] <Hobbsee|Remote> asac: NM still likes falling over, at 14%
[11:33] <Hobbsee|Remote> ooh, hang on.
[11:33] <seb128> kwwii: yes, will you update the package now? ;)
[11:34] <asac> Hobbsee|Remote: falling over? where does it fall to?
[11:34] <asac> btw, 14% network-strength is not really strong
[11:35] <iwj> cjwatson: It might be.
[11:35] <StevenK> Mithrandir: Can I beg you to release virtualbox from binary NEW? It's built on both amd64 and i386, which is what it's meant to.
[11:35] <seb128> StevenK: I can do it
[11:35] <iwj> Hmm.
[11:35] <StevenK> seb128: Thanks
[11:36] <Mithrandir> seb128: care to do ume-config-common too?
[11:36] <Mithrandir> (I've uploaded it, so I'd rather not NEW it)
[11:36] <asac> stgraber: can you reproduce the nm crash you mentioned yesterday?
[11:36] <Hobbsee|Remote> asac: ok, seems like NM likes playing funny buggers.  it's all working now.
[11:36] <asac> Hobbsee|Remote: ok cool, please upgrade nm and it should just rock
[11:36] <seb128> Mithrandir: I'll look at this one as well
[11:36] <asac> Hobbsee|Remote: thanks for testing
[11:37] <Hobbsee|Remote> asac: it would fall over at 14% (preparing devices, i think), go back to disconnected, then show $AP as wpa-encrypted, again
[11:37] <Hobbsee|Remote> after using dhclient, etc, to connect, and killing NM a few times, it seems to work, properly, with NM again
[11:37] <asac> well ... if you have log i can verify if its the bug that nm fixes
[11:37] <asac> otherwise just try the new nm
[11:37] <Hobbsee|Remote> asac: dmesg, or what?
[11:37] <asac> syslog
[11:38] <seb128> StevenK: virtualbox binary newed
[11:38] <asac> Hobbsee|Remote: but maybe just upgrade nm ... the bug it fixes sounds similar
[11:38] <Hobbsee|Remote> asac: what in particular were you looking for in it?
[11:39] <asac> Hobbsee|Remote: damn i don't know the exact string .. should be something like: cannot connect to wpa supplicant
[11:39] <Mithrandir> seb128: cheers
[11:40] <asac> Hobbsee|Remote: couldn't connect to the supplicant
[11:41] <Hobbsee|Remote> asac: a couple of Sep  4 19:21:05 LongPointyStick NetworkManager: <WARN>  supplicant_cleanup(): couldn't disable network in supplicant_cleanup
[11:41] <asac> yeah
[11:41] <asac> upgrade nm and it should never fail again :)
[11:41] <kwwii> seb128: if dholbach walks me through it, sure :-)
[11:42] <Hobbsee|Remote> asac: are you planning to get that upgrade into gutsy?
[11:42] <asac> (wow ... what a stupid claim :))
[11:42] <seb128> dholbach: ^
[11:42] <asac> Hobbsee|Remote: definitly
[11:42] <dholbach> kwwii, seb128: through what?
[11:42] <asac> Hobbsee|Remote: but i need the new kernel module first
[11:42] <Hobbsee|Remote> ah right
[11:42] <dholbach> updating which package?
[11:42] <Hobbsee|Remote> well, the new module seems to work, which is good
[11:42] <asac> Hobbsee|Remote: as the new nm drops a workaround that fixes a few wpa problems atm
[11:42] <Hobbsee|Remote> dholbach: the mangler
[11:42] <kwwii> dholbach: h-i-t
[11:42] <seb128> dholbach: human-icon-theme
[11:42] <Hobbsee|Remote> asac: ahhh.
[11:43] <Hobbsee|Remote> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[11:43] <asac> yes
[11:43] <dholbach> seb128: do you think we should update it to run autogen itself and make it native packaging?
[11:43] <asac> you can just build ... it has full source
[11:44] <seb128> dholbach: native packaging
[11:44] <seb128> dholbach: what do you think?
[11:44] <dholbach> seb128: plus ./autogen.sh before the build
[11:44] <dholbach> so you don't have to bother roling a release of it
[11:48] <seb128> dholbach: what is the easier for you
[11:48] <dholbach> to make it as easy as possible for ken
[11:49] <seb128> Mithrandir: ume-config-common accepted, shouldn't ume-gui-start be in /usr/share though?
[11:50] <Mithrandir> seb128: it should, yes.
[11:51] <Hobbsee|Remote> grrr.  not another nutter assigning things to the ubuntu-dev team, as they're the maintainer.
[11:52] <dholbach> Hobbsee|Remote: relax... it's not really easy for people to understand all the concepts at once - although I'm not quite sure how we could fix that problem easily
[11:53] <Hobbsee|Remote> i wonder if it's in the documentation, to assign it to it's maintainer.
[11:54] <dholbach> no, not really, but that mistake is easy to make
[11:54] <dholbach> we had it a couple of times before
[11:56] <broonie> Perhaps it would help to rename the "Nobody" assignee to "Needs triage" or something that read less like the bug was getting ignored?
[11:57] <Hobbsee|Remote> dholbach: might be a thought to black-hole that address.
[11:57] <asac> dholbach: i think you cannot do much except fixing the assignment and stating the reason ... then hope that the triager reads the reply
[11:57] <dholbach> asac: that's what we currently do
[11:58] <Hobbsee|Remote> it seems to be something that's come from the kubuntu team - they do it all the time
[11:58] <Hobbsee|Remote> fortunately, that address is blackholed.
[12:02] <Hobbsee|Remote> broonie: for a lot of applications, we dont assign bugs anyway
[12:03] <Hobbsee|Remote> bad Fujitsu!  no cookie!
[12:03] <Hobbsee|Remote> broonie: besides, assignment should only really be used for "i will fix this, i'm assigning this to person x, because they say they will fix it, or i'm assigning this to person y, because i'm their boss, and i say they have to fix this"
[12:04] <Hobbsee|Remote> the others dnot *have* to fix bugs, and have other ways of subscribing to them
[12:15] <dholbach> http://daniel.holba.ch/sponsoring/ works again
[12:23] <dholbach> seb128: done
[12:23] <seb128> dholbach: thanks
[12:23] <dholbach> kwwii: I just change human-icon-theme so that you can simply edit the changelog (using dch), then run debuild -S -sa to create a source package
[12:23] <dholbach> kwwii: or run debuild to build a package
[12:25] <kwwii> dholbach: cool, after I create the source package what should I do with it?
[12:27] <asac> stgraber: another thing i would be curious about would be to test if nm.asac + ipw3945.asac play nice together even if you modprobe the ipw module with auto associate on
[12:28] <dholbach> kwwii: upload it somewhere and either tell somebody to grab and upload it or file a bug and subscribe ubuntu-main-sponsors to it, so it's in the queue for review and upload
[12:28] <kwwii> dholbach: cool, thanks :-)
[12:28] <dholbach> rock and roll :)
[12:29] <asac> stgraber: (even if you are associated before clicking on that network, nm should retrieve an "associated" event and run dhclient)
[12:29] <dholbach> kwwii: next time we need changes in tangerine-icon-theme or tango-icon-theme-common I'll transition them to the same pattern
[12:29] <kwwii> killer, that should save others a bit of work in the long run
[12:29] <dholbach> yeah :-)
[12:40] <seb128> Riddell: the dummy knetworkmanager should be arch all, not any
[12:42] <Riddell> mm, did I forget that?
[12:42] <Riddell> I remember thinking "that needs to be changed"
[12:43] <Riddell> seb128: uploading fix.  are you doing New queue?
[12:43] <seb128> Riddell: there is a binary for each arch in the new queue
[12:43] <seb128> Riddell: yes
[12:43] <seb128> I'll accept the previous ones since it doesn't make really sense to reject binaries
[12:58] <cjwatson> argh
[01:15] <asac> Hobbsee|Remote: stgraber: i upgraded my ipw3945 branch to 1.2.2 and added .ubuntu1 suffix to version info ... would be great if you could test that it doesn't introduce new regressions.
[01:16] <asac> Hobbsee|Remote: stgraber: if you give me an ack on this, I'll ask kernel-team to update lum
[01:29] <asac> Hobbsee|Remote: welcome back ;)
[01:30] <Hobbsee|Remote> asac: thankyou :)
[01:30] <Hobbsee|Remote> new mangler works, at least on wpa
[01:30] <asac> mangler?
[01:30] <Hobbsee|Remote> asac: you want the new ipw with the new mangler presumably?
[01:30] <Hobbsee|Remote> nm
[01:31] <Hobbsee|Remote> aka, the mangler.
[01:31] <asac> Hobbsee|Remote: ah :)
[01:31] <Hobbsee|Remote> havent you heard of network mangler?
[01:31] <asac> Hobbsee|Remote: yeah ... please try first the 1.2.1 module with new nm
[01:31] <asac> if that works well just upgrade to new driver version
[01:31] <Hobbsee|Remote> that's working, at least on wpa
[01:31] <Hobbsee|Remote> did you want me to test it on open, as well?
[01:31] <asac> Hobbsee|Remote: try to stress it
[01:31] <asac> Hobbsee|Remote: yes please
[01:32] <asac> Hobbsee|Remote: wpa worked for you before?
[01:32] <davmor2> I'm trying to track down a fault with seahorse in gutsy in preferences keyservers can you actually hilight automatically retrieve keys? everytime I go back to it it's disabled again.
[01:32] <asac> Hobbsee|Remote: i only know that open didn't work for anyone ... wpa worked for some, but not for others
[01:33] <asac> ogra: you need a well trained head ... nothing if you haven't been to university :-P
[01:34] <ogra> ah, thats it then :)
[01:34] <asac> hehe
[01:34] <Hobbsee|Remote> asac: yes.  open's working, after a little persuading.  seems slightly patchy, perhaps.
[01:35] <asac> Hobbsee|Remote: what do you mean? i know that nm has problem to recognize if you change the encryption on the same access point
[01:35] <asac> Hobbsee|Remote: is that what you are seeing?
[01:36] <Hobbsee|Remote> asac: yeah.  it seems to still see it as encrypted until you restart nm a couple of times
[01:36] <Hobbsee|Remote> also seeing the bug about it finding no wifi networks until you run iwlist eth3 scan
[01:38] <cjwatson> ogra: frequent prayer
[01:38] <ogra> heh
[01:38] <cjwatson> draw it out on paper if you get stuck
[01:38] <ogra> good idea !
[01:38] <asac_> Hobbsee|Remote: daily reconnect
[01:38] <cjwatson> it helps that I know the usual elements so I don't have to think about all the individual pieces
[01:39] <asac_> 3:35 < Hobbsee|Remote> also seeing the bug about it finding no wifi networks until you run iwlist eth3 scan
[01:39] <asac_> 13:36 < asac> Hobbsee|Remote: you areprobably associated
[01:39] <Hobbsee|Remote> asac_: associated how, sorry?
[01:39] <cjwatson> but yes, debconf-apt-progress in particular required me to stare at the screen for a few days
[01:39] <asac_> Hobbsee|Remote: when your interface is associated, scanning is not done frequently anymore
[01:39] <Hobbsee|Remote> it's showing me as not connected to any network, at that point in time
[01:39] <asac_> Hobbsee|Remote: yes ... what does iwconfig show?
[01:39] <Mithrandir> cjwatson: this is why we should do debconf-over-unix-socket, IMO.
[01:39] <ogra> cjwatson, thats waht i di atm :)
[01:39] <ogra> *do
[01:40] <Hobbsee|Remote> asac_: what, now?
[01:40] <cjwatson> Mithrandir: I won't argue that ...
[01:40] <asac_> no ... when you see don't see the networks (if you can reproduce)
[01:40] <Hobbsee|Remote> asac_: iwlist shows all the networks, which then makes them show up (eventually) in nm
[01:40] <Hobbsee|Remote> yes, there's a bug open about it
[01:42] <asac_> Hobbsee|Remote: iwlist as user or as root/sudo ?
[01:43] <Hobbsee|Remote> asac_: root
[01:43] <Hobbsee|Remote> well, sudo
[01:44] <asac_> Hobbsee|Remote: ok thats normal then ... the point is as soon as iwconfig shows the interface as associated to some ap, the driver won't scan on its own that frequently anymore
[01:45] <asac_> Hobbsee|Remote: which is why i asked you to verify if iwconfig shows your interfaces associated when you don't see networks in nm
[01:45] <Hobbsee> asac_: ah right
[01:47] <Hobbsee|Remote> hmmm.  the LED flashes from time to time, but it still seems to be connected.
[01:52] <asac_> Hobbsee|Remote: what does LED flashing mean? associating/roaming?
[01:52] <asac_> Hobbsee|Remote: ok ... are you using 1.2.2 module already?
[01:53] <Hobbsee> asac_: oh, hmmm, apparently it's just the speed it's doing.  it usually stays solid on.
[01:53] <Hobbsee> no, not yet
[01:54] <Hobbsee> asac_: bzr up reports that we're at revision 2, and that's the latest
[01:54] <asac_> Hobbsee: strange ... bzr pull ?
[01:54] <asac_> https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
[01:54] <asac_> its rev 4
[01:55] <Hobbsee> ah, there we go
[01:56] <asac> Hobbsee: one more question about wpa: did wpa with NM work for you before? or is there improvement for you as well?
[01:57] <Hobbsee> asac: wpa has always worked here
[01:57] <asac> ok
[01:57] <asac> Hobbsee: with NM ?
[01:57] <Hobbsee> yes
[01:57] <asac> ok ... then you are one of the lucky-girls :)
[02:01] <Treenaks> WPA works, WPA2 doesn't
[02:01] <Treenaks> (for me.. ipw2200)
[02:03] <broonie> Hobbsee: My point was that I can see how someone just looking at the UI could believe that they needed to pick an assignee; it'd be nice if the UI provided more indication that unassigned bugs aren't being ignored.
[02:04] <asac> Treenaks: what setup? NM ... or also when using ifup/down ?
[02:04] <Treenaks> asac: nm, I haven't tried with ifup/down because nm tends to get in the way
[02:04] <Treenaks> asac: ifdown <n-m brings it up again>
[02:04] <Treenaks> stuff like that
[02:05] <asac> ok .. i think i would need a driver debug log
[02:05] <Hobbsee|Remote> asac: oh, wpa2 btw
[02:05] <Treenaks> asac: I can get the daemon.log n-m generates (tonight)
[02:06] <asac> Treenaks: thats not enough ... i need driver debug messages as well
[02:06] <Hobbsee|Remote> broonie: suggestion:  file a bug on launchpad (malone) about that.
[02:06] <Treenaks> asac: I'll try to get as much as possible when I get home, is there already a bug, or should i open a new one?
[02:06] <asac> Hobbsee|Remote: what do you mean?
[02:06] <Hobbsee|Remote> asac: right, 1.2.2ubuntu1, new mangler is working (eventually)
[02:07] <asac> Hobbsee|Remote: ok cool
[02:07] <asac> Hobbsee|Remote: what about wpa2?
[02:07] <Hobbsee|Remote> asac: that my wpa has always worked.  (where wpa == wpa2)
[02:07] <asac> ah ok
[02:08] <ogra> cjwatson, when you told me to look at in-target for my prob with ltsp-build-client you meant using passthrough and setting DEBCONF_READFD, DEBCONF_WRITEFD ?
[02:10] <cjwatson> ogra: yeah
[02:10] <Hobbsee|Remote> asac: +1.  good job.  works on wpa-psk (new ipw3945, new nm)
[02:10] <ogra> cjwatson, it says it cant initialize passthrough ...
[02:10] <ogra> and indeed falls back to noninteractive which exits with the same error
[02:11] <cjwatson> ogra: it will do if you're running it without a debconf frontend
[02:11] <asac> Hobbsee|Remote: thanks a lot for testing ... i wait for stgraber to confirm that new driver is good then lets roll this fix
[02:11] <ogra> well, the udeb sits in a debconf frontend already ...
[02:11] <Hobbsee|Remote> asac: excellent :)
[02:11] <cjwatson> it might be worth taking a bit of time to step back and read and understand how the various frontends work
[02:11] <cjwatson> ok, in that case you did something wrong :-)
[02:11] <ogra> yeah, thats where i'm trying to wrap my head around atm
[02:12] <davmor2> asac: think stgraber is back at school now so he might be a while
[02:12] <asac> Hobbsee|Remote: there is only one bug i would like someone to test ... there are claioms that if you boot with wireless off, that turning on wireless later will not load the driver, bring up the interface
[02:12] <asac> Hobbsee|Remote: have you ever seen this?
[02:12] <Hobbsee> hmmm...i've seen something similar, i think.  will test the next time i boot
[02:12] <cjwatson> ogra: if readfd or writefd is getting lost somewhere then that would happen
[02:12] <ogra> right
[02:12] <asac> davmor2: thanks. But since nm with ipw3945 was broken such a long time I can wait for a few more hours :)
[02:13] <asac> Hobbsee|Remote: great.
[02:13] <ogra> debconf: kann Frontend nicht initialisieren: Passthrough
[02:13] <ogra>  debconf: (Failed to open fd 3: Bad file descriptor at (eval 20) line 3)
[02:13] <ogra> fails with the same error as noninteractive
[02:13] <cjwatson> ogra: you also need to unset the things in-target unsets
[02:13] <cjwatson> ogra: or rather that chroot-setup.sh unsets
[02:14] <ogra> ah, ok
[02:14] <ogra> lol, ok, thats a lot stuff i'm missing :)
[02:30] <ogra> yay
[02:31] <ogra> still broken (need to redirect stdout somehow to the fifo) but it moves on :)
[02:50] <jdong> schplee! "Inconsistency detected by ld.so...."
[03:02] <doko> cjwatson: can we close bug 61861, or would an edgy task more appropriate?
[03:02] <ubotu> Launchpad bug 61861 in ruby1.8 "ruby1.8: fails to build on ppc under 2.6.15 kernel" [Medium,Confirmed]  https://launchpad.net/bugs/61861
[03:08] <cjwatson> doko: I'd suggest closing the ruby1.8 task (since it built fine on edgy in the end) and leaving the linux-source-2.6.15 task open in case it becomes important later
[03:09] <cjwatson> doko: FYI: diff -u <(wget -q -O- http://people.ubuntu.com/~ubuntu-archive/component-mismatches{-mobile,}.txt)
[03:09] <cjwatson> doko: it's not perfect (and, for reasons involving part of the code being in Launchpad and difficult to modify, it's hard to do better) but it clears away a lot of the mobile-specific stuff from the main component-mismatches list
[03:10] <cjwatson> so it should help matters for the time being
[03:11] <doko> type-handling into main???
[03:12] <cjwatson> clearly an error
[03:12] <cjwatson> germinate gets confused sometimes because type-handling Provides: linux
[03:13] <cjwatson> we routinely ignore that :-)
[03:14] <cjwatson> I've fixed it in the past - not sure why it's showing up here
[03:14] <doko> ok, this list helps
[03:14] <cjwatson> oh, I see, it should be linux-image on gobuntu not linux
[03:14] <cjwatson> I'll fix the seeds
[03:34] <stgraber> asac: Sorry was afk, so 1) No, 2) I'll try tonight, 3) I'll build both now
[03:35] <stgraber> s/both//
[03:37] <stgraber> asac: looks like I have enough wifi network around so I can try everything now, will be back in a minute
[03:45] <stgraber> asac: with associate=0 : Wired -> Public1 -> Wired -> Public1 -> Public2 -> Public1 -> Wired = OK
[03:45] <stgraber> asac: with associate=1 : Wired -> Public1 -> Wired = Failed
[03:46] <stgraber> asac: it failed when switching back to wired
[03:46] <stgraber> Sep  4 15:43:50 laptop NetworkManager: <WARN>  nm_utils_supplicant_request_with_check(): nm_device_802_11_wireless_scan: supplicant error for 'SCAN'.  Response: '^F'
[03:46] <stgraber> Sep  4 15:43:50 laptop NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: Transport endpoint is not connected
[03:46] <stgraber> also had : Sep  4 15:43:30 laptop NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: Connection refused
[03:46] <asac> oh another bogus response path
[03:47] <asac> in wpa_ctrl
[03:47] <stgraber> anyway, associate is default to 0, people using it with 1 aren't NM users imo
[03:47] <asac> let me see
[03:47] <asac> sure
[03:49] <stgraber> I don't have WPA around, but if Public1 -> Public2 -> Public1 works and the WPA code wasn't changed it should works just fine
[03:49] <asac> stgraber: can you see what wpa command is send before you get that Response: ... ?
[03:49] <asac> ah SCAN :)
[03:49] <asac> sorry
[03:50] <asac> stgraber: you sure you have new nm?
[03:50] <stgraber> new NM = .dev.opennet ?
[03:51] <asac> yes
[03:51] <cjwatson> seb128: re mail, want me to take https://bugs.launchpad.net/ubuntu/+source/libgtk2-perl/+bug/127985?
[03:51] <stgraber> it's rev57 here and no revision to pull
[03:51] <ubotu> Launchpad bug 127985 in libgtk2-perl "gutsy/amd64: ftbfs / autopkgtest failure" [High,Confirmed]
[03:52] <cjwatson> seb128: or are you already on it?
[03:58] <asac> stgraber: can you get a full driver log for associate:1 ?
[03:59] <bddebian> Heya
[04:00] <stgraber> asac: sure
[04:04] <stgraber> asac: the warnings only appear when I try to switch to wired the second time
[04:04] <stgraber> asac: I'm uploading the full log
[04:04] <asac> thanks
[04:05] <stgraber> asac: http://www.stgraber.org/download/nm-debug-associate
[04:06] <asac> stgraber: i can't find that warning
[04:06] <stgraber> asac: so 2 last NM warnings are caused by me clicking wired a second time
[04:06] <stgraber> asac: cat debug-nm-associate | grep -v ipw3945:
[04:07] <asac> stgraber: i only see a warn: " supplicant_cleanup(): supplicant_cleanup - couldn't set AP_SCAN 0 "
[04:07] <asac> stgraber: (and the line above that)
[04:10] <stgraber> when I select wired for the first time I have "Sep  4 16:02:21 laptop NetworkManager: <info>  nm_device_set_active_link start
[04:10] <stgraber> " being written every 2s
[04:10] <stgraber> but not switching back to wired
[04:10] <stgraber> :)
[04:10] <asac> stgraber: yes i see that ... but i don't see the warn you pasted above
[04:11] <asac> stgraber: any idea about when you hit wired for the second time?
[04:11] <stgraber> 16:02:23
[04:11] <asac> stgraber: and first time works?
[04:12] <stgraber> first being 16:01:52
[04:12] <stgraber> no, first time trigger the nm_device_set_active_link_start every 2s
[04:12] <asac> ah
[04:12] <stgraber> second trigger the WARN
[04:13] <asac> stgraber: well but thats not the WARN i was particular interested in :)
[04:13] <asac> stgraber: nm_device_802_11_wireless_scan: supplicant error for 'SCAN'.  Response: '^F'
[04:13] <asac> thats the one i need ;)
[04:14] <stgraber> asac: do you have 16:02:28 in the log ?
[04:14] <asac> no
[04:15] <asac> 16:02:24 is the last i see
[04:15] <stgraber> ok
[04:15] <asac> stgraber: i see that you try to active your eth0 on 16:01:52
[04:17] <stgraber> asac: http://www.stgraber.org/download/nm-debug-associate1
[04:18] <asac> stgraber: what happens after 16:02:35 ?
[04:20] <asac> stgraber: for me it looks a bit like it wants to boot up eth0 at that point? does that succeed?
[04:20] <stgraber> asac: no
[04:21] <asac> what happens?
[04:22] <stgraber> asac: http://www.stgraber.org/download/nm-debug-end
[04:22] <stgraber> asac: I just can't remember when I killed NM
[04:24] <asac> stgraber: ok at 16:02:41 it succeeds
[04:24] <asac> stgraber: did you restart nm?
[04:34] <stgraber> asac: I think so yes
[04:58] <seb128> cjwatson: I'm not on it, feel free to do it
[05:00] <dobey> hey seb128
[05:01] <seb128> hi dobey
[05:06] <bddebian> Hi seb128 :-)
[05:06] <seb128> hey bddebian
[05:07] <dobey> how's it going?
[05:07] <kblin> hi folks
[05:09] <kblin> who'd be the person to talk to to stop ubuntu from mapping `hostname` to <IP_ADDRESS> ?
[05:09] <seb128> dobey: good, thanks ;) What about you?
[05:09] <seb128> Hi kblin
[05:09] <dobey> doing ok
[05:10] <dobey> hoping to get a job soon ;)
[05:10] <seb128> :)
[05:10] <seb128> kblin: try mentioning it on this chan (what you are doing) and if you get no reply maybe mail<EMAIL_ADDRESS>with some details on what is your issue and what you suggest doing this change
[05:11] <kblin> ok, fair enough
[05:11] <dobey> red tape takes a while to get around though :P
[05:12] <kblin> doing this kind of stunt will break applications that depend on the hostname resolving to the real IP address of the host
[05:13] <kblin> it seems to be a pretty popular thing to do in distributions recently, and I'd like to explain why it's a bad idea :)
[05:15] <Mithrandir> kblin: "the real IP of the host" doesn't really make any sense.
[05:15] <Mithrandir> hosts don't have ip addresses, interfaces does.
[05:16] <kblin> I'm a Wine developer working on Wine networking, and we've seen lots of bug reports recently that are due to windows applications assume that gethostbyname( gethostname() ) will give them the network interface IP address so they can bind to that
[05:17] <dobey> kblin: what happens when no network interface outside of lo is up?
[05:17] <kblin> Mithrandir: ok, sorry. but how about using the IP address of an active network interface that's not loopback if possible
[05:17] <Mithrandir> kblin: that can change at any time, so it's not suitable for /etc/hosts
[05:17] <kblin> this also tends to break kerberos once in a while..
[05:18] <dobey> kblin: not having it there, tends to break things that expect $hostname to resolve to something
[05:18] <Mithrandir> works fine on my kerberos-enabled workstation.
[05:19] <kblin> Mithrandir: I haven't touched kerberos in a while.. current mit kerberos might be able to cope
[05:19] <Mithrandir> I'm using heimdal, though
[05:20] <kblin> oh, ok
[05:20] <kblin> heimdal design is more robust for all that I'm aware :)
[05:20] <Mithrandir> or rather, a mixture of them, since some apps like one, some the other libraries.
[05:21] <kblin> but as I said, I'm more concerned about  this breaking for a lot of windows apps where I can't just fix the bloody app
[05:22] <dobey> obviously. being a wine developer, your primary concern is wine. :)
[05:23] <kblin> this is probably the most popular networking bug we currently get in our bugzilla
[05:23] <Mithrandir> if you have a better way of having /etc/hosts set up that works in all cases, please tell us
[05:24] <doko> ./.ext/include/i686-linux-lp
[05:24] <doko> ./.ext/i686-linux-lp
[05:24] <doko> \o/
[05:25] <kblin> well, assuming the host has a fixed IP address for a non-loopback interface, that should be useable
[05:25] <kblin> that would fix it for some of the users, right?
[05:28] <doko> AC_CANONICAL_TARGET
[05:28] <doko> target_os=`echo $target_os | sed 's/linux-gnu$/linux/;s/linux-gnu/linux-/'`
[05:29] <Mithrandir> kblin: that assumption holds for very few users.
[05:30] <ogra> yeah, static interfaces got rare nowadays
[05:30] <kblin> hmm
[05:32] <Mithrandir> why would you do static?  I have more DHCP servers than I know what to do with.
[05:33] <Mithrandir> (I have three within 1m of me here..)
[05:33] <kblin> maybe I'm old fashioned
[05:34] <bddebian> kblin: I'm with ya, I love static interfaces :-)
[05:34] <bddebian> Of course I'm old
[05:34] <ScottK> And grumpy.
[05:34] <realist> Even our static/fixed IPs are actually on DHCP leases
[05:34] <realist> If that makes any sense
[05:34] <bddebian> ScottK: Always :)
[05:34] <Mithrandir> realist: fixed DHCP is quite common.
[05:34] <bddebian> realist: Yeah but that's a PITA for a home network
[05:34] <kblin> I'm just trying to come up with some  way to fix that for joe user in some sane way
[05:35] <realist> bddebian: depends how many hosts on your home network
[05:35] <bddebian> 12
[05:35] <ogra> kblin, as long as you dont break it for jane user, thats fine :)
[05:35] <thom> static interfaces are such a pain
[05:35] <realist> That's enough for me to want dhcp + ddns
[05:35] <bddebian> ogra: :)
[05:36] <bddebian> Not me, dhcp is a hassle
[05:36] <kblin> My first attempt to fix this was to work around this in Wine
[05:36] <realist> A blessing :-)
[05:36] <kblin> but that approach wasn't accepted
[05:36] <Mithrandir> I think you might be able to write an NSS module providing the necessary workaround
[05:36] <kblin> hmm, true
[05:36] <ogra> but the wine fix would probably be the right way
[05:37] <realist> Static is a hassle, so is MAC based switch port security
[05:37] <realist> Management overhead++
[05:37] <realist> Goodnight all
[05:37] <Mithrandir> ogra: no, the right way to fix it would be to apply a suitable tool to the author of said applications. :-P
[05:38] <ogra> Mithrandir, indeed, but if many/all distros use the <IP_ADDRESS> notation, the fix should be in wine, not in the distros ;)
[05:38] <kblin> ogra: I've tried
[05:40] <kblin> but this is kind of clumsy to fix, unless you iterate over all interfaces, check if they're active and then kind of switch addresses before it actually ends up with the caller
[05:41] <ogra> cant you just ignore the 127.0.1.* space ?
[05:42] <kblin> some distros map the hostname to <IP_ADDRESS>
[05:42] <kblin> which tells me this should not be fixed in wine
[05:42] <kblin> at least not until there's an agreement across distros to what IP address the hostname will map to
[05:42] <Mithrandir> you'd want to look at the scope for the address on the interface, somehow.
[05:44] <kblin> hm, thinking about this some more, I think that returning the IP address of the interface that has the default route would make sense for most people who'd do a gethostbyname( gethostname() )
[05:45] <kblin> but yeah, maybe a nss module would be the best place to actually fix this
[05:45] <Mithrandir> you could easily have that in an NSS module.
[05:45] <kblin> what would my chances of actually getting something like that into distros?
[05:46] <ogra> kblin, you could make it part of the wine package i guess
[05:46] <dobey> exactly
[05:46] <kblin> but it's not wine-specific
[05:47] <kblin> I won't ever get something like that into the wine tree
[05:47] <dobey> then you make a new package, and make wine depend on it
[05:48] <ogra> kblin, a package isnt only upstream source :)
[05:48] <ogra> well, ideally it would be ... but thats rarely the case
[05:49] <cjwatson> kblin: it doesn't seem clear from scrollback, but normally we resolve the hostname to <IP_ADDRESS>, not <IP_ADDRESS>, precisely to avoid this kind of problem
[05:49] <cjwatson> kblin: there doesn't need to be agreement across distros - it just needs to not be <IP_ADDRESS>, that's all
[05:50] <kblin> cjwatson: as I said, there's a distro that maps to <IP_ADDRESS>
[05:50] <cjwatson> kblin: the reports you've been getting might be from users who installed Ubuntu a long time ago, before we made this change
[05:50] <Mithrandir> cjwatson: the problem is some apps thinks that the address returned by gethostbyname(gethostname()) is a sane choice for binding to for doing public communication.
[05:50] <cjwatson> kblin: sure, and that's ok
[05:50] <kblin> yeah
[05:50] <kblin> what Mithrandir said :)
[05:50] <cjwatson> I don't understand how that wouldn't break on Windows from time to time as well
[05:50] <cjwatson> dynamic networking is kind of a fact of life there too
[05:51] <cjwatson> ok, sorry for the slight misunderstanding, I was reading an hour of scrollback at once and the hostname=><IP_ADDRESS> thing used to be a common complaint for other reasons ...
[05:52] <kblin> oh, actually this tends to break on windows if you have more than one active NIC
[05:52] <dobey> what if you have no active NICs?
[05:52] <cjwatson> kblin: the correct range to skip would be simply <IP_ADDRESS>/8
[05:52] <cjwatson> any address there is local, per whatever RFC it is
[05:52] <bddebian> 1918 I think
[05:52] <ogra> or ignore the lo interface and everything related
[05:52] <kblin> dobey: that's not that much of a concern, but matter of fact windows returns <IP_ADDRESS> in that case
[05:52] <cjwatson> so you don't need to worry about <IP_ADDRESS> vs. <IP_ADDRESS> vs. <IP_ADDRESS>
[05:53] <seb128> cjwatson: there is bug #94048 which is quite long on the using <IP_ADDRESS> creating issue for users
[05:53] <ubotu> Launchpad bug 94048 in hostname "[feisty]  Slow gnome application startup due to /etc/hosts misconfiguration" [Undecided,Incomplete]  https://launchpad.net/bugs/94048
[05:53] <bddebian> Or 192.168.x.x or 169.x.x :)
[05:53] <seb128> I didn't really investigate
[05:53] <cjwatson> bddebian: no, RFC1918 is private use ranges which is different
[05:53] <seb128> but according to the number of comment it seems to create issues
[05:53] <bddebian> Oh, sorry
[05:53] <cjwatson> seb128: the old way created issues too, so just going back wouldn't achieve much
[05:55] <cjwatson> seb128: it is exceedingly unclear from that bug what the problem actually is, and the number of comments could actually be a conflation of several different problems
[05:55] <kblin> well, I don't have a ready fix for this, creating a nss module might be worth investigating
[05:55] <dholbach> cjwatson: do you think bug 83690 makes sense? shall I assign it to you?
[05:55] <ubotu> Launchpad bug 83690 in grub "update-grub hardcodes to 'Ubuntu'" [Undecided,Confirmed]  https://launchpad.net/bugs/83690
[05:56] <cjwatson> dholbach: yes, it's clearly a bug and I agreed with the gnewsense folks some time ago that we'd fix it
[05:56] <cjwatson> dholbach: sure, can be assigned to me
[05:56] <dholbach> cjwatson: rock on, cheers
[05:57] <seb128> cjwatson: right
[05:57] <kblin> I'll probably need to give this some more thought.
[05:58] <kblin> but I need to catch my bus to catch my plane, so I'll get back to you folks later
[05:58] <kblin> thanks for your input in any case
[06:01] <cjwatson> seb128: starting gnome-terminal in strace doesn't seem to mention <IP_ADDRESS> at all here
[06:02] <cjwatson> though I'm on a network where my hostname resolves locally ...
[06:02] <dholbach> kylem: if you have the time can you upload the patch of bug 57755?
[06:02] <ubotu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Undecided,New]  https://launchpad.net/bugs/57755
[06:02] <cjwatson> but it doesn't talk to my nameserver either
[06:04] <dholbach> lamont: I think you asked me to prod you wrt bug 33586 :-)
[06:04] <ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
[06:06] <Mithrandir> dholbach: for 57755; those rules are shipped by libccid already
[06:07] <dholbach> could you follow up on the bug report? I have no clue about libccid and friends at all
[06:07] <Mithrandir> sure
[06:07] <dholbach> gracias
[06:07] <dholbach> Riddell: could you check out bug 136425? it's a small fix for qt4
[06:07] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
[06:08] <Riddell> dholbach: isn't that the one you've been poking me at for a while?
[06:08] <Riddell> mm, no, different
[06:08] <dholbach> Riddell: not sure
[06:08] <Riddell> well, I'll add it to my todo
[06:09] <dholbach> rock on - thanks
[06:10] <seb128> cjwatson: right, same for me
[06:10] <dholbach> calc: what do you think about bug 134112 and bug 133793?
[06:10] <seb128> cjwatson: there seems to be an issue for some people, but the mix of comments doesn't make it easy to figure something clear
[06:10] <ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
[06:10] <ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Confirmed]  https://launchpad.net/bugs/133793
[06:11] <cjwatson> seb128: the "host name lookup failure on localhost" message seems to be from gnome-session
[06:11] <cjwatson> seb128: (look, an application of Google Code Search!)
[06:12] <cypherbios> mvo_: are you around?
[06:12] <cjwatson> seb128: though from the code it looks to me that it will always emit that message at least once, no matter what?
[06:12] <lamont`> dholbach: yeah, I did.
[06:13] <cjwatson> oh, no, I'm misreading its intent
[06:13] <lamont`> dholbach: I made progress towards my goals, but did not finish getting things together
[06:13] <dholbach> lamont`: that sounds good :)
[06:13] <lamont`> yeah - it's on the list for this evening to spend more time on such things
[06:14] <dholbach> thanks a lot
[06:16] <ogra> wow, now that was bad
[06:16] <dholbach> doko: do you think that the patch on bug 103929 makes sense?
[06:16] <ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress]  https://launchpad.net/bugs/103929
[06:17] <bryce> morning
[06:17] <dholbach> hey bryce
[06:18] <bryce> heya dholbach
[06:20] <dholbach> bryce: you think we can upload the patch on bug 117939?
[06:20] <ubotu> Launchpad bug 117939 in inkscape "tutorial-basic.svg has wrong text" [Undecided,Fix committed]  https://launchpad.net/bugs/117939
[06:20] <dholbach> or do you want to wait for the new upstream version?
[06:21] <bryce> upload the patch; there won't be a new upstream release for at least a couple months
[06:21] <doko> dholbach: maybe, it's wishlist, I have to work on bash anyway, but not now ...
[06:21] <dholbach> doko: ok
[06:21] <dholbach> bryce: ok, will upload it
[06:22] <bryce> dholbach: I'd proposed doing a release in time for gutsy, but everyone pretty much felt that a release should wait until after the GSoC code additions had been finished and had time to stabilize
[06:22] <dholbach> ah ok, that makes sense
[06:23] <bryce> (as an aside, I wonder if the GSoC timeline may be affecting other OS projects similarly?)
[06:28] <ogra_> grmblfjx
[06:30] <bddebian> grmblfjx?
[06:30] <ogra> yes
[06:31] <ogra> with three !!!
[06:31] <ogra> somehow my system just freaked out ...
[06:31] <bddebian> Hrm
[06:31] <ogra> after the hardlock i rebooted ...
[06:31] <ogra> after reboot i couldnt sudo anymore
[06:31] <bddebian> Doh :-(
[06:32] <ogra> well, i could, but every command took about 10mins to return a line in the terminal
[06:34] <Revel> I've asked in the general channel like 5 times and no one seems to be able to help.  This cannot be that hard...
[06:34] <Revel> Having problems mounting a transcend ide flash disk.  DMESG shows errors but I am unable to find anything good on google related to this besides some PCMCIA problems with external drives.  Help please ;( 2nd week on this one.
[06:34] <Revel> dmesg: http://paste.ubuntu-nl.org/36340/
[06:37] <bddebian> Hmm, still on GLwDraw in Gutsy either eh?
[06:37] <bddebian> s/on/no/
[06:38] <lucky_lucas> Hi
[06:42] <stgraber> asac: I've just finished a full test of switching between WPA, Public and Wired networks (I'm back at home), didn't see any real problem
[06:42] <stgraber> just sometime the "AP_SCAN 0" taking ~4-5 seconds to timeout which causes NM to stay connected on the network before connecting to the new one (or wired)
[06:44] <Revel> w/in3
[06:45] <stgraber> asac: oh, something else I just noticed, any reason to have a wpa_supplicant process running when connected to wired ?
[06:45] <stgraber> asac: I have a wpa_supplicant -g /var/run/wpa_supplicant-global2 running
[06:47] <stgraber> asac: and NM didn't deassociate from my public WLAN when switching to wired (may be caused by the remaining wpa_supplicant)
[06:48] <Chipzz> asac: since you've been talking about it the last couple of days...
[06:49] <Chipzz> is there a way to prevent the ipw2200 chipset from associating with a random accesspoint?
[06:50] <Chipzz> (I have an essid specified in /e/n/i, but sometimes it just ignores that)
[06:52] <Riddell> azeem: were you looking at packaging the new opensync?
[06:52] <azeem> so far, lifeless did the library and I did the modules
[06:55] <Riddell> azeem: so what's left?
[06:56] <azeem> Riddell: so far, the libraries haven't been updated
[06:56] <azeem> and really, it's quite unclear to which version
[06:57] <Riddell> lamont`: calc was wanting it I think
[06:58] <cjwatson> lamont`: yes, Riddell is correct
[06:59] <Riddell> azeem: but you said lifeless was doing the library
[06:59] <cjwatson> lamont`: "back"? it seems to be entirely new in gutsy
[06:59] <azeem> Riddell: well, for the previous uploads I meant
[07:00] <mathiaz> keescook: if we do a merge from debian that includes a security fix, should you be involved in that ?
[07:00] <Riddell> right
[07:01] <azeem> Riddell: there's also the problem with the user data being incompatible between the current gutsy/feisty version and upstream
[07:01] <azeem> so at least I have waited for a stable upstream version
[07:01] <geser> calc: Hi, when you have time can you sponsor the debdiff for bug #130583?
[07:01] <ubotu> Launchpad bug 130583 in xmlsec1 "libxmlsec1-nss missing pkgconfig file" [Undecided,New]  https://launchpad.net/bugs/130583
[07:03] <Riddell> azeem: is the current version considered stable?
[07:03] <azeem> no
[07:03] <Riddell> right
[07:03] <azeem> or do you mean the current version in gutsy?
[07:03] <Riddell> no, the newest upstream release I ment
[07:04] <azeem> yeah, that's the problem
[07:04] <azeem> there's been a 0.22 release which was moderately stable I think, but it's incompatible to both current gutsy and next upstream stable
[07:16] <keescook> mathiaz: if it needs back-porting to earlier releases, yeah, I'll need to publish them through the security queue
[07:17] <keescook> has anyone started using the new python launchpad API?  I can't get it to set status...  :(
[07:18] <soren> keescook: Bughelper uses it, I believe.
[07:19] <keescook> soren: right, but it's a read-only tool.  Also, the Wiki examples don't work (there is no "apply", though "commit" fails too)
[07:22] <mathiaz> keescook: should I file a new bug or flag the current bug as a security issue ?
[07:23] <keescook> mathiaz: no reason for duplication; just flag it as security.  which bug is there?
[07:23] <keescook> er, *is this?
[07:24] <mathiaz> keescook: well... there is a cve assigned to it.
[07:24] <mathiaz> keescook: bug 136596
[07:24] <ubotu> Launchpad bug 136596 in fetchmail "[Merge]  fetchmail 6.3.8-8ubuntu1" [Undecided,New]  https://launchpad.net/bugs/136596
[07:24] <mathiaz> keescook: fetchmail-SA-2007-02: Crash when a local warning message is rejected
[07:25] <keescook> ah yeah, very minor issue.  It's a bit down on my todo list, but if people have already generated and tested patches, I can publish them.
[07:25] <mathiaz> keescook: well. It came from the debian unstable.
[07:25] <mathiaz> keescook: that's why I asked.
[07:26] <keescook> right, what I mean is, if this applies to feisty, edgy, dapper, we'll need patches for those releases too.  (This is already on my todo list, but lower down due to the very low priority of this CVE)
[07:26] <mathiaz> keescook: ok.
[07:28] <thekorn> keescook: python-launchpad-bugs is not working for you?
[07:29] <thekorn> maybe this might help: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
[07:29] <keescook> thekorn: ah-ha!  just the person I need to ask lots of questions.  :)
[07:31] <keescook> thekorn: http://paste.ubuntu-nl.org/36351/    that doesn't work.  only the comment is recorded.
[07:31] <keescook> thekorn: also, "Bug" seems to require an "int", it doesn't like getting a string, which is odd, given the code.  :P
[07:32] <thekorn> keescook: does your code not work for all bugs, do you have a test case
[07:33] <keescook> thekorn: well, I only tried it on a single bug, but it always failed (137018)
[07:36] <thekorn> keescook: looking...
[07:38] <thekorn> keescook: it just fails becaus 'ubuntu-security' is not subscribed to this bug
[07:39] <keescook> thekorn: ah, is there some way to make the error more meaningful?  :)
[07:40] <keescook> I should add a check for 'ubuntu-security' in .subscribers?
[07:40] <thekorn> yes, that might be the easiest way
[07:41] <keescook> cool!  thanks.  :)
[07:41] <thekorn> or try:...except:...
[07:41] <keescook> but that's just around the "commit".  I'd have to commit each change separately, which seems ugly.  :)
[07:43] <thekorn> no, you can commit all changes to a bug at once
[07:43] <thekorn> or you can commit all changes to all changed bugs at once
[07:43] <janimo> asac: hi
[07:45] <thekorn> keescook: but it won't reduce the traffic
[07:46] <keescook> thekorn: right, but I meant, to find the problems with input (without better error reporting) I'd need to make one change, try:commit, repeat.
[07:48] <thekorn> keescook: no, I would put try:..except:... around bug.subscribtions.remove("ubuntu-security") for example
[07:49] <keescook> thekorn: but that's not where my script failed.  :)  (at the time, ubuntu-security was subscribed).  It exploded at .commit
[07:50] <thekorn> aha
[07:53] <thekorn> keescook: my problem at this point is: I'm unable to reproduce any kind of errors on this
[07:53] <amitk> bryce: --> #ubuntu-mobile
[07:53] <keescook> thekorn: let me create a test bug, one sec
[07:53] <thekorn> thanks
[07:56] <keescook> thekorn: okay, 137325 dumps on me with the previously pasted script.  Here are my errors: http://paste.ubuntu-nl.org/36353/
[07:57] <keescook> (I've subscribed you to it)
[08:02] <thekorn> keescook: will have a look at it
[08:03] <thekorn> this message is useless, have to fix this
[08:04] <\sh> thekorn, how do I authenticate with the bughelper class? :)
[08:05] <thekorn> \sh: Bug.authenticate=<file> where file is a valid mozilla/firefox cookie-file
[08:05] <\sh> thekorn, ah ok :)
[08:20] <asac> stgraber: is that with associate:1 ?
[08:20] <lucky_lucas> hi bryce
[08:20] <asac> stgraber: the wpa supplicant process is normal as nm scans using wpa
[08:20] <thekorn> keescook: thanks for pointing me to this error,
[08:20] <bryce> hi lucky_lucas
[08:21] <keescook> thekorn: sure! glad I could help.  :)
[08:21] <asac> Chipzz: ok i could take a look ... can you ping me tomorrow?
[08:21] <stgraber> asac: no, that was normal use (associate=0)
[08:21] <lucky_lucas> I m trying to figure out where the crashes of X/linux come from and I may need guidance
[08:21] <asac> stgraber: hmm do you see that the device is deactivated?
[08:21] <asac> stgraber: e.g. when you switch to wired?
[08:21] <asac> stgraber: or is it just after initial startup?
[08:21] <stgraber> asac: ok, so it seems that NM doesn't send a deassociate when switching back to wired
[08:22] <lucky_lucas> bryce: I'm talking about  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
[08:22] <ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,Incomplete]
[08:22] <stgraber> asac: usually I have off/any as essid with iwconfig
[08:22] <thekorn> keescook: will have a closer look at it tomorrow
[08:22] <stgraber> asac: but here I have the last wifi network I have been connected to (public wifi)
[08:22] <keescook> thekorn: okay, thanks
[08:22] <asac> stgraber: is that reproducible? does it happen always when you switch back to wired?
[08:23] <asac> stgraber: and you don't see: deactivating device (eth1) in log when to wired?
[08:25] <stgraber> asac: I just did one more test
[08:25] <davmor2> bryce: ping
[08:25] <stgraber> asac: result is that I have that deassociation problem only when moving back to Wired from Public
[08:26] <stgraber> asac: and when I have the AP_SCAN 0 timeout thing
[08:26] <Chipzz> asac: I can
[08:26] <bryce> lucky_lucas: as I said in the bug report, there isn't an error message or anything we can troubleshoot from, so all I can offer is vague guesses - test the proposed -ati 6.7.192 patch.  My latest xorg-server upload is just now out, which has a handful of random fixes, so try that too.  If it still is a problem, follow the directions on DebuggingXorg
[08:26] <Chipzz> asac: problem is, it is not really reproducable
[08:26] <bryce> davmor2: yup
[08:27] <lucky_lucas> bryce: That's what I m doing
[08:27] <davmor2> bryce: I've updated bug 134284 is there another info you need or is that enough?
[08:27] <ubotu> Launchpad bug 134284 in xorg "The X intel driver is not functioning correctly" [Undecided,New]  https://launchpad.net/bugs/134284
[08:27] <lucky_lucas> I attached the Xorg process in gdm and it blocks the system I can let it run by doing cont but I don't know if I m doing right
[08:28] <Chipzz> asac: and, I'm not using wpa_supplicant/networkmanager, so dunnow how far you're reallly interested :P
[08:29] <bryce> davmor2: sorry, I was looking at that but got interrupted.
[08:29] <davmor2> np
[08:29] <davmor2> your a busy man
[08:32] <bryce> so to doublecheck - when you load the livecd, X comes up with the -intel driver?
[08:33] <davmor2> correct.  ed/ubuntu both usable but k/xubuntu are unusable because of it.
[08:34] <bryce> sort of the inverse problem we normally have
[08:34] <bryce> ok there are two entries by this pciid in discover data
[08:35] <davmor2> probably
[08:35] <bryce> one is 'NC2400', the other 'Thinkpad R60e model 0657' - either of those sound familiar?
[08:36] <davmor2> no mine is compaq c300 I think just get it and double check
[08:37] <davmor2> yep compaq presario c300
[08:37] <bryce> hrm
[08:39] <bryce> odd, your card's not in the database - http://pci-ids.ucw.cz/iii/?i=808627a2
[08:40] <davmor2> interesting
[08:40] <davmor2> is there any other info I can give you in order to track it down a bit more?
[08:41] <EvanCarroll> I wanted to throw idea out, a multithreaded dpkg-installer, with the ability to predetermine collisions with other isntalling processes...
[08:42] <Amaranth> no
[08:43] <Amaranth> wouldn't help, main bottleneck should be the disk
[08:43] <bryce> davmor2: the only missing piece of info is the 'subsystem_name'.  In your lspci output it displays Subsystem: Creative Labs Unknown device [1102:1003]
[08:43] <EvanCarroll> well in a perlbal, you have a MANIFEST which stores the modified files, dpkg could just as well read from a manifest and determine if other installing processes are wanting to minipulate the same files.
[08:43] <bryce> it'd be nice to know what it should be instead of 'Unknown device'
[08:43] <bryce> er whoops
[08:43] <bryce> Subsystem: Hewlett-Packard Company Unknown device [103c:30a5]
[08:45] <davmor2> 2 secs
[08:45] <zasf> enrico: ping
[08:46] <stgraber> bryce: hehe, funny, 3 hours ago I noticed that Gutsy wasn't working with our computers at school due to frequency problem with our Acer monitors, I come back home, check my mails and see the fix being uploaded :) thanks
[08:48] <asac> Chipzz: if the driver deliberately associates its also a problem for nm and supplicant :) ...
[08:48] <asac> Chipzz: isn't nm running at all?
[08:48] <bryce> stgraber: awesome, did the fix fix it?
[08:49] <stgraber> bryce: no idea, I will check tomorrow but I think so as it's exactly the issue I saw
[08:49] <bryce> cool
[08:50] <bryce> well let me know either way; I'm curious how many issues these backports are going to fix in practice
[08:52] <stgraber> bryce: should be in tommorow daily right ? (they are generated early in the morning (europe) IIRC)
[08:55] <zasf> glatzor: I'm looking in g-a-i for a way to call it
[08:56] <bryce> stgraber: yup
[08:56] <glatzor> zasf: do you have got a closer idea what you want to do?
[08:56] <zasf> glatzor: it turns not to be an easy job as you were saying yestarday
[08:57] <zasf> glatzor: g-a-i_install_this_and_enable_component_if_necessary(package)
[08:57] <zasf> :)
[08:57] <glatzor> zasf: I have voted against such an approach.
[08:57] <Kopfgeldjaeger> hi
[08:57] <zasf> glatzor: I paste something if you have time to look at ti
[08:58] <davmor2> bryce: what is likely to be?
[08:58] <zasf> glatzor: http://www.pastebin.ca/681311
[08:58] <glatzor> zasf: I would suggest to use some low level classes of g-a-i
[08:59] <zasf> glatzor: I'm all ears :)
[08:59] <glatzor> zasf: introducing a new activation style was what I wanted to avoid
[09:00] <glatzor> zasf: I don't think that you will include any third party repositories in restricted manager
[09:01] <bryce> davmor2: no clue, it'll be some sort of subsystem name like C1234 or Acme FooMeister 3000
[09:01] <glatzor> zasf: I started working on an application view for update-manager, perhaps I will find the code again
[09:01] <Amaranth> hrm
[09:02] <bryce> actually we know it's HP, so it'd be a HP FooMeister 3000
[09:02] <Amaranth> does a random crash in malloc mean something bad? :)
[09:02] <glatzor> zasf: perhaps we should move the caching to the CoreApplicationMenu
[09:02] <glatzor> zasf: but that is another issue.
[09:02] <zasf> glatzor: I thought that I needed and instance of AppInstall, so that I use tryinstall or something
[09:03] <glatzor> zasf: you could use the CoreApplicationMenu class to locate the component of a package
[09:04] <glatzor> zasf: this will blow up your code a lot.
[09:04] <glatzor> zasf: what you really need ist packagekit.org :)
[09:05] <zasf> glatzor: I'm just experimenting for fun :)
[09:05] <glatzor> zasf: you want to do this in the gutsy time frame?
[09:05] <zasf> glatzor: I do it in my spare time, no hurries
[09:06] <davmor2> bryce: online docs it is
[09:06] <zasf> glatzor: if I can help, I'll be happy
[09:08] <glatzor> zasf: I think copy and paste of the tryinstall method would be easier
[09:09] <bryce> davmor2, anyway, so once you have that info, let me know and I can add the quirk for it to use -i810 in discover-data.  You probably ought to also submit the info here:  http://pciids.sourceforge.net/
[09:09] <bryce> davmor2: you might find it worthwhile to submit that data for the other 'unknown device' entries in your lspci -vvnn, as it may help your device support in the future
[09:09] <glatzor> zasf: but do you really have got any data that could not be available?
[09:09] <zasf> glatzor: if g-a-i turns out not to be helpful, I don't see any other alternatives
[09:10] <davmor2> bryce: Where?
[09:10] <zasf> glatzor: I checked command-not-found but its data is based on the fact that a specific package contains commands (ie c-n-f has no data for packages with no commands in it)
[09:10] <bryce> see the 'How to submit new data' at http://pciids.sourceforge.net/
[09:11] <davmor2> ta
[09:12] <glatzor> zasf: take a look at _confirm_source_activation in AppInstall
[09:14] <glatzor> zasf: but I am currently also a little bit clueless.
[09:15] <glatzor> perhaps it is already too late :)
[09:15] <zasf> glatzor: you're right :) thanks for your support
[09:15] <zasf> glatzor: going to dinner
[09:19] <glatzor> zasf: the best solution would be to provide a high level install package method that also can enable components. but since this is not available yet, I think that there is no ideal solution.
[09:20] <zasf> glatzor: ok, that is bad news for me but still an important piece of information
[09:20] <glatzor> zasf: showing the main window of gnome-app-install would result in a quite strange workflow
[09:21] <cjwatson> Amaranth: typically means that at some earlier point the process corrupted the malloc arena by freeing something that was already freed, or trying to allocate or free memory in a signal handler, or trying to free/realloc something not returned by malloc, or various other such things. valgrind is usually the best way to find what actually went wrong
[09:22] <Amaranth> cjwatson: but random?
[09:22] <Amaranth> i mean, that's what the bug reporter said, i've never seen the problem
[09:23] <zasf> glatzor: yes, what I tought is: don't show it, trough modifyUserInterface, call something in background to get the work done and most importantly show accept dialogs
[09:23] <Amaranth> it died somewhere far inside libxml2 and he said it usually doesn't happen and was actually using compiz when filing the bug
[09:24] <glatzor> zasf: you could also modify it even more by replacing all appplication widgets with a text label "Do you want to install the drivers for 'your new hardware here'?"
[09:25] <glatzor> zasf: oh wait. but when to show the enabling dialogs
[09:25] <zasf> glatzor: I just don't need the main window, all the rest is very good
[09:28] <glatzor> zasf: right. the apply changes method should be called after enabling the components afaik
[09:29] <glatzor> zasf: you could use on_install_toggle(None, item)
[09:31] <cjwatson> Amaranth: could be anything within the calling process, at any other point
[09:31] <Amaranth> fun
[09:31] <zasf> glatzor: yes, I haven't found the right method to call yet. That applyChanges in my test is just the first guess
[09:32] <glatzor> zasf: perhaps you are on a good way
[09:32] <cjwatson> Amaranth: you could try having him set MALLOC_CHECK_=3 in compiz's environment if using valgrind is too hard; it might help
[09:32] <zasf> glatzor: hehe nice to hear from you
[09:33] <zasf> glatzor: now I really have to go, thanks for your support
[09:33] <zasf> bye all
[09:33] <glatzor> bye
[09:46] <davmor2> bryce: I've done a bunch of browsing and everyone lists it as a Intel Graphics Media Accelerator 950 so could that be the issue?
[09:51] <davmor2> bryce: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00797501&lc=en&cc=uk&dlc=en&product=3318980&rule=38923&lang=en#N331
[09:52] <holymoly> hi
[09:54] <holymoly> i would like to have hplip packaged for dapper
[09:54] <holymoly> latest is 2.7.7 and is in gutsy but backport don't show it available
[09:54] <holymoly> any tips on the easiest way to create an ubuntu package for hplip?
[09:55] <dobey> get the source
[09:55] <dobey> install the build dependencies
[09:55] <dobey> and dpkg-buildpkg -rfakeroot
[09:55] <holymoly> thats it?
[09:55] <dobey> source being the "source" from gutsy
[09:55] <holymoly> nice thanks
[09:55] <holymoly> aha!
[09:56] <holymoly> righto, IMPORTANT piece of info
[09:56] <dobey> add the deb-src line for gutsy to /etc/apt/sources.list
[09:56] <dobey> then apt-get update
[09:56] <dobey> and apt-get build-dep hplip
[09:56] <dobey> then apt-get source hplip
[09:56] <dobey> cd into the hplip source dir
[09:56] <dobey> and dpkg-buildpkg -rfakeroot
[09:57] <holymoly> wow thats  great
[09:57] <dobey> you probably need to install fakeroot for that to towkr also
[09:57] <dobey> to work
[09:57] <holymoly> right
[09:57] <holymoly> didn't know it was that easy, more or less
[09:57] <cjwatson> note that dpkg-buildpackage is misspelled above
[09:57] <holymoly> right
[09:57] <dobey> oh yeah
[09:57] <dobey> dpkg-build<tab>
[09:57] <dobey> :)
[09:58] <holymoly> once i build it i would be happy to donate it to backports
[09:58] <holymoly> how is that done?
[09:58] <dobey> cjwatson: i always get tripped up with that, because dpkg has it as pkg, and buildpackage has it as package :-/
[09:58] <dobey> that i don't know
[09:58] <holymoly> no problem i'll find out
[09:58] <cjwatson> holymoly: it isn't - backports is done semi-automatically and the packages are always built on the archive master system
[09:59] <seb128> use debuild ;)
[09:59] <holymoly> thank you very muchly
[09:59] <cjwatson> holymoly: but you can certainly contribute the fact that the backport works for you
[09:59] <holymoly> aha
[09:59] <holymoly> okay thanks
[09:59] <dobey> personally, i would just wait 4 weeks or whatever, and install gutsy
[09:59] <cjwatson> they use bugs on {dapper,edgy,feisty}-backports to track that sort of thing, and there's probably something on the wiki about the process
[10:00] <dobey> seb128: debuild? isn't that the opposite of building something? :)
[10:01] <seb128> dobey: not, that's debianbuild ;)
[10:08] <holymoly> dobey: i haveto make a decision about buying a printer today unfortunately
[10:08] <holymoly> and hp has these new multifunctions that are actually cheaper to run than laser printers for black and white printers
[10:09] <dobey> uh, ok
[10:09] <holymoly> so it would be nice to have hplip actually packaged so we can deploy to 30 or so boxes, it will be much harder for us to upgrade gutsy instead
[10:09] <dobey> sure
[10:21] <sistpoty> desrt: any idea about bug #137354 ?
[10:21] <ubotu> Launchpad bug 137354 in missingpy "sparc build fails with "[test-ghc6]  Bus error"" [Undecided,New]  https://launchpad.net/bugs/137354
[10:24] <holymoly> cjwatson: what are the rules for deciding what is backported ... is there a request system of some sort?
[10:25] <cypherbios> mvo_: the package is ready at the same url
[10:25] <cypherbios> I gotta go
[10:27] <jamiemcc> seb128: when is the cut off point for tribe 6?
[10:32] <davmor2> bryce: Would intel release a chipset with a beta driver?  If so then maybe there is a bios update which changes the driver for the chip?  long stretch guess I know but just a thought.
[10:33] <sladen> holymoly: I thought hplip was already installed by default?
[10:33] <bryce> davmor2: it's possible
[10:33] <sladen> holymoly: ps aux | grep hplip ...
[10:34] <davmor2> right on the hunt for a bios update then :)
[10:34] <bryce> davmor2: however more likely is that compaq added something that conflicted, or else did something to result in the incompatibility
[10:34] <bryce> davmor2: is this just a personal machine, or is it a hardware series we're going to be providing support for?
[10:35] <davmor2> personal machine as far as I know
[10:36] <bryce> ok, well that rules out going through business channels ;-)
[10:37] <holymoly> sladen: 0.9.7 is in dapper
[10:37] <holymoly> hplip is already up to 2.7.7
[10:37] <holymoly> the old vesion is not exactly spectacular
[10:38] <bryce> davmor2: if it is just a personal machine, what is the motivation for getting it to boot the right driver from the installer?  Are you just working to get the hardware support improved for your machine?
[10:40] <sladen> holymoly: right, so file  a bug saying that, detailing the changelog and the differences
[10:40] <davmor2> No I would just like it to work correctly.  If it is as compaq say a 950 graphics card then it has better 3d stuff than the 945.  So it would be good if it worked correctly.
[10:41] <holymoly> sladen: that would be considered a bug?   sure i'll do that
[10:47] <sladen> holymoly: if something doesn't work automatically out-of-the-box as you expect, then that's a bug
[10:47] <holymoly> this is more of a backport tho
[10:48] <holymoly> hplip works it just isn't the latest version
[10:48] <holymoly> tomato tomato :)
[10:48] <holymoly> filing
[11:05] <ionstorm> is ubuntu's goal for everything to run out of the box
[11:06] <ionstorm> https://bugs.launchpad.net/ubuntu/+bug/34902 should be criticle since belkin is used by thousands, if not millions of people
[11:07] <ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed]
[11:07] <ionstorm> critical*
[11:08] <ionstorm> define "high" priority, will it be fixed?
[11:11] <cjwatson> holymoly: yeah, there's a request system - basically has to build cleanly without modifications, has to be new features (i.e. outside the normal stable updates procedure), has to not make core developers scream in horror (yes, this is subjective)
[11:12] <holymoly> right
[11:12] <holymoly> danke
[11:12] <holymoly> i have a terribly noob questioneven though i'm not
[11:12] <holymoly> lol
[11:12] <holymoly> i'm trying to find the hplip gutsy src package and i can't see it
[11:12] <holymoly> i just have one src line in my sources.list file for gutsy and i don't see an hplip-src file
[11:12] <holymoly> *hmm*
[11:15] <cjwatson> holymoly: 'apt-get source hplip'
[11:15] <cjwatson> source packages are not named like "foo-src" as a general rle
[11:15] <cjwatson> rule
[11:16] <holymoly> ohhhhh
[11:16] <holymoly> okay thank you very muchly
[11:16] <cjwatson> the files are all in http://archive.ubuntu.com/ubuntu/pool/main/h/hplip/ if you need to get them by hand, but you shouldn't have to
[11:17] <holymoly> coolness, adding to my notes
[11:22] <holymoly> would this indicate the dependencies in dapper are not in line with what source code expects in gutsy: E: Build-Depends dependency for hplip cannot be satisfied because no available versions of package debhelper can satisfy the version requirements
[11:24] <gnomefreak> was it just me or yesterdays updates (give or take a day) mounted filesystem((bin var ect..) as an externel drive?
[11:40] <desrt> sistpoty; sorry.  no.  haven't hacked ghc for a while
[11:40] <desrt> and never on sparc :)
[11:49] <Hurga> Hi there... not sure if I'm right here, but folks on #ubuntu directed me here. I have trouble on 6.06 with mkisofs and genisoimage on 7.04, file size of more than 2 GB seems not to be supported. Is that correct, a bug or a feature?
[11:53] <Hurga> ok. mkisofs and genisoimage, who to ask?
[11:53] <Trewas> Hurga: feature afaik, iso9660 does not support large files and udf support in linux cd-burning programs is (or was when I researched a few months back) a bit sketchy... actually I ended up buying nero linux for burning >4GB files :/
[11:54] <Hurga> Trewas: http://en.wikipedia.org/wiki/ISO_9660#The_2_GiB_.28or_4.2GB_depending_on_implementation.29_file_size_limit
[11:54] <Hurga> "The free software mkisofs is able to create filesystems that use multi-extent files to support file sizes up to 8 TB."
[11:56] <Hurga> Trewas: I definetely have been able to create UDF discs of 4.5 GB a few years ago. These days UDF craps out at 1 GB when I copy a larger file on it.
[11:58] <Trewas> Hurga: according to that article nothing except windows xp can read those fragmented large iso9660 files, not very useful...