[17:09] <grantbow> staring now in #olpc-sf is our 2014 summit
[17:09] <grantbow> starting
[17:09] <grantbow> http://olpcsf.org
[17:09] <darthrobot> [R: www.olpcsf.org] Title: [OLPC San Francisco | one laptop per child san francisco volunteer community]


[00:02] <ogra> heh
[00:03]  * ogra votes for a discworld
[18:30] <jacksonn> I'm having some trouble loading the file system with my boot loader.  It loads from flash as read-only and I would like to load it into ram, but I can't figure out how.  Can someone help me?


[02:39] <super-6-1> hello
[02:40] <super-6-1> can anyone help with wireless network for linux?
[02:40] <crimsun> for development?
[02:40] <super-6-1> umm
[02:40] <super-6-1> no really
[02:41] <super-6-1> my wireless doesent work after 5 or so hours after installed
[02:42] <super-6-1> any reason why?
[02:43] <crimsun> this belongs in #ubuntu
[02:43] <super-6-1> iv tryed there
[02:43] <crimsun> please tell more about the hardware config there.
[02:43] <super-6-1> no one can help
[02:44] <super-6-1> iv told them everythibg
[02:44] <super-6-1> thing
[02:44] <crimsun> I haven't seen it  (I've been addressing alsa support)
[02:45] <super-6-1> Okey ~
[02:45] <super-6-1> its a netgear
[02:46] <super-6-1> does linux support it
[02:46] <crimsun> as I stated previously, please migrate to #ubuntu  (I'm there; just address me)
[02:46] <super-6-1> Okey ~
[02:47] <super-6-1> whats ur addresse?
[02:47] <crimsun> I have the same "address" as you see here.
[02:47] <super-6-1> never mind crimsun i think i got one groupe for me
[02:47] <super-6-1> if thay dont work ill see you thee
[02:50] <defendguin> what are the reasons that /dev/video0 would not get created?
[02:52] <defendguin> nevermind
[06:06] (zdzichuBG/#ubuntu-kernel) can I safely install and user gutsy kernel on feisty?
[07:24] <baget> I have problem porting USB Kernel module from 2.4 to 2.6
[07:24] <baget> can someone help me?
[07:31] <baget> anyone?


[13:56] <arjuncr> hi, how i get Ubuntu official membership ?,  what is the procedure ?.
[13:58] <rbasak> arjuncr: https://wiki.ubuntu.com/Membership


[00:08] <ScottK> slangasek or any other archive admin that might happen to be around: libfile-temp-perl was deleted this morning and now libmime-tools-perl and thus amavisd-new are uninstallable.  No bug to hint why it might have been removed.
[00:08] <slangasek> hrm
[00:09] <slangasek> StevenK: do you know anything about that? ^^
[00:10] <superm1> ScottK, just uploaded a new mimi-tools that should help
[00:10] <superm1> mimi? mime
[00:10] <slangasek> ah, no, https://launchpad.net/ubuntu/+source/libfile-temp-perl/0.20-1ubuntu1 shows the reason
[00:10] <slangasek> pitti: why was libfile-temp-perl deleted?
[00:11] <ScottK> superm1: Great.  That should help.
[00:15] <ScottK> It looks to me like the version conflicts for perl-modules should have been bumped too then.
[00:20] <ScottK> superm1: Bonus points for fixing it in a backports friendly way.
[00:21] <superm1> ScottK, blame that mostly on debian.  when laga caught it breaking stuff, I saw debian did it nice so figured lets do it nice too :)
[00:40] <lycannyc-work> whats the work around for the update that removed all the gnome panel stuff?
[00:41] <wgrant> lycannyc-work: Install ubuntu-desktop and xserver-xorg-input-all. Or watch for these removals in the first place and stop them.
[00:41] <wgrant> I'm surprised how many people got caught in that 3 hour window.
[00:41] <persia> There's a lot of testers out there at this point.
[00:41] <wgrant> A lot of testers who blindly upgrade, too.
[00:42] <lycannyc-work> ^^^
[00:42]  * Twigathy_ wonders if the ipconfig / NFS root bug will still be present in 8.10...
[00:42] <persia> Well, that's because someone suggested that `apt-get dist-upgrade` was a useful command.
[00:42]  * Twigathy_ has not had time to test :|
[00:42] <lycannyc-work> i reinstalled hardy on my other partition since i have no net whatsoever on intrepid at the moment
[00:42] <lycannyc-work> im trying to chroot and its still not working, failed to fetch
[00:43] <wgrant> lycannyc-work: What's the actual error message? (this is better in #ubuntu+1)
[00:43] <jcristau> persia: it is. there's a reason it asks for confirmation though.
[00:44] <persia> jcristau, Yeah, so you press return a few times.  Although I'm a long-time aptitude user, I rather like just how much update-manager refuses to upgrade lots of things, and encourages the user to to investigate in synaptic.  It strikes me as the right solution.
[00:46] <persia> Mind you, it gets a little too aggressive about removals for dist-upgrades in my opinion, but for regular daily upgrades, it's pleasantly conservative.
[00:56] <ScottK> persia: apt-get dist-upgrade is a useful command.  Reading what it says it's going to do before agreeing to is is also useful.
[00:57] <persia> ScottK, Well, I suppose.  I tend to only use it when things are somewhat broken.
[00:58]  * wgrant hopes that users will only do it once.
[01:00]  * ScottK just mistyped ... greater long term flexibility and discovered that flammability comes up right next to flexiblilty in the spelling correction options.
[01:08] <stgraber> slangasek: hmm, I was just wondering, we have a bugfix release of ltspfs that'll be released soon but it'll also introduce some missing or out-of-date documentation. Does that require a freeze exception or is considered as bugfix-only ?
[01:09] <slangasek> stgraber: how does introducing missing or out-of-date documentation qualify as a "bugfix release"...?
[01:10] <stgraber> slangasek: well, we have 0.5.3 in Ubuntu, 0.5.4 adds the missing doc and 0.5.5 is the bugfix-only :)
[01:11] <ScottK> stgraber: I gather you're trying to say it will provide documentation that is currently missing/outdated?
[01:11] <stgraber> ScottK: yep and fix a bug that made it segfaulting in some cases
[01:11] <slangasek> stgraber: then that doesn't count as bugfix-only
[01:12] <ScottK> i.e. make it better (your sentence parsed rather the opposite to me)
[01:12] <ScottK> Fixing docs isn't a bugfix?
[01:12] <slangasek> hrm?  oh, I should be parsing that the other way?
[01:12]  * slangasek shakes his fist
[01:12] <slangasek> yes, fixing docs is a bugfix
[01:12] <ScottK> I read it the other way too at first.
[01:13] <slangasek> stgraber: yes, that's fine then
[01:13] <stgraber> slangasek: ok, thanks.
[01:27] <slangasek> why is update-notifier telling me "(null)"?
[01:33] <Hobbsee> hmmm, mvo's not here.  I was going to ask if he had plans to force https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/254840 to be fixed, by including -evdev as a required package in the installer.
[01:36] <wgrant> Can somebody running a recent (less than 12 hours out of date) Intrepid installation try to run 'xinput list-props "<Some input device that you have>"' and tell me if you get fetch failures or other X errors?
[01:37] <stgraber> wgrant: X Error of failed request:  BadDevice, invalid or uninitialized input device
[01:37] <stgraber> wgrant: something like that ?
[01:38] <wgrant> stgraber: You have xserver-xorg-core 2:1.5.1-1ubuntu3, xserver-xorg-input-evdev 1:2.0.99+git20080912-0ubuntu3, and have restarted X since upgrading?
[01:39] <stgraber> system is up to date (from a few minutes) but I haven't restarted X yet, will do and tell you if it improved
[01:40] <wgrant> Ah, that would do it.
[01:40] <wgrant> I'm sort of hoping that you'll get an error.
[01:40] <wgrant> (a different one from this)
[01:43] <stgraber> wgrant: Device Enabled:		Fetch failure
[01:44] <wgrant> AHA!
[01:45] <stgraber> btw, what's the easiest way to know the current color depth ? I have some doubts my video card is configured correctly at the moment
[01:45] <wgrant> A non-forum machine that exhibits it. Finally.
[01:45] <wgrant> stgraber: Which device are you attempting to list?
[01:45] <stgraber> Synpatic touchpad
[01:45] <stgraber> *Synaptic
[01:45] <stgraber> xinput list-props "SynPS/2 Synaptics TouchPad"
[01:46] <wgrant> stgraber: What if you list some other device that doesn't use the synaptics driver?
[01:46] <stgraber> same with "PS/2 Generic Mouse"
[01:47] <stgraber> and same with the keyboard
[01:48] <jcristau> stgraber: xdpyinfo?
[01:49] <jcristau> (tells you the depth, among other things)
[01:49] <wgrant> stgraber: What if you run 'xinput set-int-prop "SynPS/2 Synaptics TouchPad" "anything at all" 8 1'? You might get a more useful error.
[01:50] <stgraber> stgraber@castiana:~$ xinput set-int-prop "SynPS/2 Synaptics TouchPad" "anything at all" 8 1
[01:50] <stgraber> stgraber@castiana:~$
[01:50] <wgrant> Blink.
[01:50] <stgraber> jcristau: ok, so my problem doesn't seem to be color depth as it returns "24 planes" for the root window which I assume = 24bit
[01:50] <wgrant> xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Two-Finger Scrolling" 8 1 0
[01:51] <wgrant> See if you can vertically two-finger scroll after you run that.
[01:51] <stgraber> jcristau: When watching videos it looks like I'm limited to 16bit and the gdm login screen looks the same (haven't checked if it's not just an issue with the theme itself though)
[01:52] <stgraber> ok, according to "file", in the case of gdm, the theme is the problem.
[01:53] <stgraber> so I'll go back at checking my mplayer options then (probably something wrong there as I had to tweak it to run without XV ... bad radeon hd)
[01:55] <persia> slangasek: Because /var/lib/update-notifier/user.d/fusa-applet.note doesn't include a "Name: " header.
[01:56] <wgrant> stgraber: Did setting that property do anything?
[01:56] <persia> It also doesn't include a DisplayIf: or DontShowAfterReboot: header, either of which is probably at least confusing.
[01:57] <stgraber> wgrant: nope, standard vertical scrolling still work but two-finger scroll doesn't
[01:57] <wgrant> stgraber: But it didn't give you an error?
[01:58] <stgraber> no
[01:58] <wgrant> Grrr.
[02:09] <slangasek> persia: thanks, will file a bug
[02:10] <wgrant> stgraber: Can you grab http://www.qeuni.net/f/1/2008/getprop, and run it like './getprop 2 "Wheel Emulation Y Axis"', replacing 2 with the numerical ID of your non-Synaptics mouse?
[02:11] <stgraber> wgrant: http://ubuntu.pastebin.com/f4f7283b7
[02:12] <wgrant> Blurgh.
[02:13] <wgrant> What.
[02:13] <wgrant> Um.
[02:13] <wgrant> 41 doesn't exist any more.
[02:13] <wgrant> So I guess libxi must be wrong.
[02:14] <stgraber> wgrant: oh, just thought of something
[02:14] <stgraber> wgrant: you may want to compile your binary again in 64bit or give me the source
[02:15] <stgraber> as I'm running 64bit and I don't think lib32 is up to date
[02:15] <wgrant> getprop.c, same place.
[02:15] <wgrant> Ahh, that would do it.
[02:15] <wgrant> Sorry.
[02:15] <wgrant> You need to link it against Xi
[02:15] <wgrant> gcc -o getprop -lXi getprop.c
[02:16] <stgraber> stgraber@castiana:~$ ./getprop 3 "Wheel Emulation Y Axis"
[02:16] <stgraber> stgraber@castiana:~$
[02:16] <wgrant> OK, "Synaptics Off" with the ID of your Synaptics device.
[02:17] <stgraber> same result ...
[02:17] <wgrant> OK, so the Get is actually failing.
[02:17] <wgrant> Hmmm.
[02:18] <stgraber> strace shows some: -1 EAGAIN (Resource temporarily unavailable)
[02:18] <wgrant> As does mine.
[02:23] <wgrant> stgraber: Can you grab getprop.c again, try it out on your mouse again, and tell me the result?
[02:24] <wgrant> 27
[02:24] <wgrant> Damn.
[02:24] <stgraber> stgraber@castiana:~$ ./getprop 3 "Wheel Emulation Y Axis"
[02:24] <stgraber> result: 0
[02:36]  * wgrant wonders both why it occurs at all, and why it won't occur on any of his boxes.
[02:36] <wgrant> stgraber: There's an even more verbose version there now. Try it on both properties I've referenced here.
[02:40] <stgraber> wgrant: http://paste.ubuntu.com/56161/
[02:42] <wgrant> That should never be able to happen.
[02:43] <wgrant> jcristau: Any ideas how to debug this further?
[02:43] <wgrant> The only difference between our setups that I can of is the arch. But surely not...
[02:44] <jcristau> format 51 is unexpected...
[02:44] <wgrant> jcristau: Isn't it never, ever meant to not be a multiple of 8?
[02:45] <wgrant> Even on failure?
[02:46] <jcristau> i was looking at libxi, i'll look at the server now..
[02:47] <wgrant> I don't think it can be libxi's fault.
[02:47] <wgrant> And ProcXGetDeviceProperty is fairly large.
[02:54] <jcristau> wgrant: i'd step through ProcXGetDeviceProperty in gdb
[02:55] <wgrant> jcristau: I've never run X in a debugger before... and I have no hardware that this afflicts.
[03:00] <jcristau> x runs mostly fine in gdb, except it's better to attach the debugger after startup (because xkbcomp bonghits), and you need to do it from ssh
[03:00] <jcristau> the 'no hardware' part is harder :)
[03:00] <wgrant> Yes...
[03:00] <wgrant> None of my five machines here exhibit the problem, which is mighty confusing and annoying...
[03:01] <jcristau> i'd offer to build stuff with the patches and play here, but it's 4am already :/
[03:01] <wgrant> Ew.
[03:09] <wgrant> jcristau: Pretty much everybody reporting the error mentions that they're running amd64.
[03:09] <wgrant> None of my i386 machines exhibit the problem.
[03:09] <wgrant> This is unlikely to be a conincidence.
[03:09] <wgrant> -n
[03:12] <persia> wgrant, How much information do you need to track it?  I'm sure there's not a few people who have amd64 & synaptics, and would be willing to test.
[03:12] <wgrant> persia: I don't believe it's just Synaptics people, actually.
[03:13] <persia> You think it affects any input device?  Just things that look like mice and keyboards to HAL?
[03:13] <wgrant> Looking through HWDB submissions for all of the people complaining about this and the previous version of the error on the bug are either running amd64 or on the same hardware that others are running amd64 on.
[03:13] <persia> I'm more than happy to attach a wide variety of input devices on amd64 with up-to-date hardy.
[03:13] <wgrant> persia: It should affect input device properties in general.
[03:13] <wgrant> Synaptics just happens to be the main user.
[03:14] <wgrant> evdev provides various properties on any mouse.
[03:14] <wgrant> So a touchpad is not required.
[03:14] <superm1> wgrant, do you have a good test case?  I can help out with and amd64 live cd if need be
[03:14] <jcristau> persia: this is intrepid, not hardy
[03:14] <persia> Right. s/hardy/intrepid/
[03:15]  * persia is not thinking clearly, as it's getting on quarter past thirty-five
[03:15] <jcristau> xtrace can also be helpful, but it doesn't seem to support XI
[03:16] <persia> Anyway, I've mice, touchpads, keyboards, joysticks, and several things somewhere inbetween on intrepid.  What's the test case?
[03:16] <wgrant> superm1: Ideally: On the same machine, on both i386 and amd64 Intrepid beta live CDs, run 'xinput list', find your mouse, and 'xinput list-props "Your Mouse Name Here"'
[03:16] <wgrant> On the beta I expect that you will get a BadDevice on amd64. As of last night, it's different.
[03:17] <persia> Is there a special reason to use beta vs. current?
[03:17] <wgrant> Current live CDs aren't guaranteed to work.
[03:17] <wgrant> Nor exist.
[03:18] <jcristau> or, wireshark, on a server that listens on tcp.
[03:18] <wgrant> And people aren't likely to have both an i386 and amd64 instance on one machine, so live CDs are required.
[03:18] <persia> Oh.  I overwrote my betas.  Today's liveCD doesn't exist, but yesterday's does, and there's an ubuntu-mobile image for today which can do i386 X testing.
[03:18] <wgrant> That should do.
[03:18] <wgrant> You just need X, evdev and xinput.
[03:20] <persia> That's all standard.  I'm about 60% done with today's ubuntu-mobile image download, so I'll plug in a variety of things that X thinks are mice, and collect.  Probably be about 30 minutes for both amd64 and i386.
[03:20] <wgrant> Any single mousey device should do.
[03:20] <persia> Even easier then :)
[03:22] <persia> Confirmed the BadValue on amd64 at least.
[03:23] <wgrant> OK, good.
[03:23] <wgrant> This would explain why it was impossible to reproduce.
[03:24] <persia> Yeah, seems to affect any arbitrary pointing device, or at least the two I've tried so far.
[03:25] <wgrant> Actually, it should affect anything - all input devices should have a property to disable them
[03:25] <wgrant> That's not encouraging...
[03:27] <persia> OK.  Attaching some pointing devices appears to restart X, which can't be good.
[03:27] <wgrant> 13:25:41 < wgrant> That's not encouraging...
[03:28] <wgrant> Indeed...
[03:28] <wgrant> Now we need to see if it still happens on i386.
[03:28] <persia> unfortunately, it killed my download, and it was overwriting, so it'll be a bit :(
[03:30] <persia> Interesting, I get two different kinds of errors.  The touchpad and mouse get BadValue.  The FPS controller gets "Fetch Failure".
[03:31] <wgrant> Some controllers have a habit of killing X on button press.
[03:31] <wgrant> Might not be unrelated.
[03:31] <wgrant> Oh dear.
[03:33] <persia> It appears that the Saitek Pro Gamer Command Unit is such a controller.
[03:33] <wgrant> persia: Anything like http://ubuntuforums.org/showthread.php?t=943898?
[03:34] <superm1> wgrant, any particulars on X versions necessary, or just the general information?
[03:34] <wgrant> More amd64 showing up there...
[03:34] <persia> wgrant, No, that's a gamepad.  I'll try that next.
[03:34] <wgrant> superm1: Something upgraded in the last 12 hours would be excellent.
[03:34]  * persia is trying a hybrid mouse/keyboard combo now
[03:34] <superm1> wgrant, would today's dailies suffice?
[03:34] <superm1> i can grab i386 and amd64 of each
[03:34] <persia> superm1, Indeed.
[03:35] <wgrant> superm1: I'm not entirely sure when they are generated.
[03:35] <superm1> wgrant, well what package needs to be upgraded on them?
[03:35] <superm1> i'll grab the daily, and upgrade that one package
[03:35] <superm1> and restart X
[03:35] <wgrant> superm1: xserver-xorg-core, libxi6, xserver-xorg-input-evdev, xinput.
[03:35] <persia> superm1, I didn't see an i386 daily yet today (I'm not watching amd64).  You might get yesterday.
[03:35] <wgrant> That should pull in new g-c-c, g-s-d, and a couple of other related things.
[03:35] <superm1> persia, oh well they're oversized
[03:35] <superm1> that will make this more difficult i think...
[03:36] <wgrant> Grab an older daily, then?
[03:36] <superm1> yeah
[03:40] <persia> Yeah, I can reproduce crashing X with a game pad :)  Just press a button.
[03:41] <wgrant> persia: Bug #274203
[03:41] <persia> Oh, it's not detecting as a mouse, it's using the X joystick input interface,
[03:43] <persia> Hrm.  Or maybe it is.  I'm confused.
[03:44] <wgrant> What does lshal give as its capabilities?
[03:44] <persia> I'm low on USB ports, I'll let you know when the dd for the i386 boot completes.
[03:45] <wgrant> Thanks.
[03:45] <persia> I don't suppose there's some useful set of information that could be collected about a USB input device?  I've all but two varieties I've seen for sale, and would be happy to contribute data points.
[03:46] <persia> (the two missing being the 6D CAD controller and the Jog/Shuttle controller)
[03:47]  * wgrant moves that sort of thing to the kernel, so doesn't quite know.
[03:48] <persia> It belongs in the kernel?  They all get recognised, and usually work in most cycles (although I've not been fiddling with them much during intrepid).  I was thinking more HAL/DeviceKit level.
[03:48] <wgrant> Ah.
[03:48] <wgrant> Maybe -joystick needs an fdi file to claim them.
[03:48] <persia> For joysticks, that would make sense.
[03:49] <persia> I'm not sure what to do with FPS controllers, but they're fairly nonstandard anyway.
[03:49] <persia> gamepads are effectively joysticks, as far as the kernel is concerned.
[03:49] <wgrant> What do you mean "FPS controllers"?
[03:50] <persia> Like the Belkin n52 or the Saitek Gamer Pro Command Unit.  They're sorta half-keyboards with maybe a D pad, or a joystick or a trackpoint for the thumb.
[03:50] <wgrant> Oh.
[03:50] <wgrant> Interesting.
[03:50] <persia> The idea is that you put your left hand on one, and the right hand on a mouse when playing a FPS.
[03:51] <wgrant> I've no idea, then.
[03:51] <persia> There's a wide variety of them : I only have two, as I don't really play FPS games much, and they aren't useful for much else.
[03:51] <wgrant> I guess they'd best show up as a joystick and keyboard.
[03:52] <persia> Or a mouse and keyboard, or just a joystick, or just a keyboard, depending on the internals.
[03:52] <persia> I'd like some sensible mapping for them generally (which is why I have two with different internals), but just fixing joysticks is probably all that makes sense for intrepid.
[03:53] <persia> Anyway, rebooting for i386 tests (won't be on IRC), and will get lshal on the gamepad.
[03:53] <wgrant> Thanks.
[04:00] <persia> wgrant, Must it be the same computer, or just the same input device?  I don't seem to be able to boot this one off USB.  I can rerun the tests on something I can boot either way, or just run i386 on the same input devices on another computer.
[04:00] <wgrant> persia: Ideally the identical hardware.
[04:01] <persia> Hrm.  OK.  I'll try to set that up then.
[04:01] <wgrant> Of course, if it fails on i386, that will do fine.
[04:02] <wgrant> But I don't think it will.
[04:02] <persia> Let's try that first then, as it's easier :)
[04:06] <Connecting> aaaaaafdsfdf
[04:06] <Connecting> d
[04:06] <Connecting> v
[04:06] <Connecting> dd
[04:06] <Connecting> fddd
[04:06] <Connecting> d
[04:06] <Connecting> d
[04:06] <Connecting> ddddddddddddddddddddddd
[04:06] <Connecting> ddddddddddddd
[04:06] <Connecting> ddddddddd
[04:06] <wgrant> Hobbsee: ^^
[04:06] <Connecting> dd
[04:06] <Connecting> d
[04:06] <Connecting> dddddddddddd
[04:06] <Connecting> dddddddddddddddddddd
[04:06] <Connecting> dddddddddddddddddddddddddd
[04:06] <Connecting> ddddddddddddddddddddddddddddd
[04:06] <Connecting> ddddddddddddddddddddddddddddddddddddddddddddd
[04:06] <persia> Hobbsee, vv
[04:06] <Connecting> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
[04:06] <Connecting> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
[04:06] <stgraber> thanks
[04:06] <desrt> ...
[04:06] <Connecting> hi
[04:06] <desrt> Connecting; welcome back
[04:07] <desrt> Hobbsee; maybe ban the username
[04:07] <Hobbsee> desrt: nah, this will work
[04:07] <desrt> i love people
[04:08] <desrt> they're totally awesome :)
[04:08] <ajmitch> hugs all around for the special people
[04:08] <Hobbsee> Connecting: spammed the channel.  And i can see you're from ppp-70-247-119-16.dsl.rcsntx.swbell.net, so there's no need to hide on mibbit.
[04:08] <Hobbsee> Connecting: don't spam, and you won't get kicked.
[04:10] <Hobbsee> hey desrting
[04:10]  * desrt is silenced :(
[04:10] <Hobbsee> desrt: yes, yes you are - or at least, on that host
[04:10] <desrt> oh well :)
[04:10] <desrt> i didn't know about that.  pretty cool service.
[04:10] <ajmitch> when not abused
[04:10] <Hobbsee> desrt: yeah
[04:10] <Hobbsee> ajmitch: well, it's hard to abuse it, as their IPs show up as well.
[04:11] <desrt> i wonder what it is about web and tor that makes people more likely to abuse
[04:11] <Hobbsee> so you can just silence mibbit, and block their IP.
[04:11] <Hobbsee> it used to be more abusable
[04:11] <desrt> like... do people avoid doing it over normal IRC because they're worried about sullying the good name of their IP address?
[04:11] <Hobbsee> desrt: well, if your IP address is very dynamic, you can get around bans more easily
[04:13] <Hobbsee> desrt: mibbit's been improving their stuff, which means they're one of the few web-based IRC services that are allowed into ubuntu channels
[04:13] <Hobbsee> desrt: the fact that everyone's now uniquely identifiable helps.
[04:13] <desrt> it's cool how freenode actually tries to work with services like tor, etc instead of klining them
[04:14] <Hobbsee> indeed.
[04:14] <wgrant> persia: Everything's working?
[04:14] <persia> Never mind.  The i386 image I have won't even boot on i386 HW :/
[04:14] <wgrant> Special.
[04:15]  * wgrant looks for other willing victims with amd64 hardware and the ability to boot into both i386 and amd64 Intrepid.
[04:16]  * ajmitch has 1 of the 4 criteria
[04:17] <wgrant> ajmitch: You're a willing victim?
[04:17] <ajmitch> I have amd64 hardware
[04:18]  * ScottK is currently a bit distracted having discovered that the entire Dilbert archive since the start of 1992 is available online through their web site.
[04:18] <wgrant> ScottK: Haha.
[04:18]  * ScottK is 0 for 4 anyway.
[04:18] <ajmitch> ScottK: thanks, now you've distracted half the people who were here
[04:18] <ScottK> Not kidding.  Up to 1994 so far.  http://dilbert.com/fast/
[04:18] <wgrant> ajmitch: I think you underestimate.
[04:18] <ajmitch> quite likely
[04:19] <ajmitch> but I have to hope that some of the rest have stronger wills than I do
[04:20] <ScottK> The interesting thing is the plain, simple, no fancy graphics version of their archive is linked to off the main page a Linux/Unix.
[04:20] <ScottK> As you see from the link, internally they just call it fast.
[04:20] <wgrant> It lives up to its name.
[04:22] <StevenK> slangasek: I know I go mad and delete stuff, but it wasn't me :-)
[04:23]  * wgrant decrufts StevenK.
[04:27] <StevenK> Right.
[04:27] <StevenK> Seven FTBFS out of 59 sources
[04:29] <persia> wgrant, I can't get any errors on i386.  The gamepad doesn't crash.  lshal says the gamepad uses evdev and provides 'input' and 'input.mouse'.  Note that the gamepad axes do not move the pointer (the pointer is moved on amd64)
[04:29] <wgrant> persia: Excellent! Thanks.
[04:29] <persia> StevenK, Only 7?  That's not nearly as frightening as it looked yesterday.
[04:29]  * wgrant removes amd64 from the archive, fixing the problem.
[04:30] <persia> wgrant, Erm.  Is there another way to solve this?  I'm willing to crash my system *lots* of times to 1) make joysticks/gamepads not crash, and 2) generally make whatever thing you're trying to do with input properties work better.
[04:31] <superm1> wgrant, well i've got you i386 data, but amd64 isn't booting right now
[04:32] <superm1> wgrant, is the i386 useful without amd64, or you need both?
[04:32] <persia> Both from identical hardware is apparently ideal.
[04:32] <wgrant> Ideally both.
[04:32] <superm1> okay, i'll keep futzing here
[04:32] <StevenK> Right. checkrdepends for libgnutls13 is *much* better.
[04:33] <StevenK> Bug filed
[04:33] <wgrant> I suspect something wrong in xserver's ProcXGetDeviceProperty, but I can't see anything obvious.
[04:34] <StevenK> persia: There's seven, do we want to dole out one or two and assign those tasks to people who want to help?
[04:34] <StevenK> superm1: Since you're here, where's ussp-push? :-)
[04:34] <persia> StevenK, Sure.  I'm always happy to assign people work.  What's the bug number?
[04:34] <superm1> StevenK, on TODO ;)
[04:34] <StevenK> persia: I'll paste in here when LP creates it
[04:34] <superm1> StevenK, i think that was one of yours before too, i dont have logs from building it locally at least
[04:35] <StevenK> superm1: Neither do I
[04:35] <superm1> StevenK, hum.  phantom build.
[04:35] <StevenK> superm1: I was going to ask you who uploaded it to the PPA
[04:35] <persia> Does it FTBFS?
[04:35] <superm1> StevenK, is it still on the PPA?
[04:35] <StevenK> steven@liquified:~/ubuntu/bluetooth-cruft/ussp-push% grep FAILED current
[04:35] <StevenK> FAILED [dpkg-buildpackage died]
[04:35] <StevenK> superm1: Not that I can see
[04:36] <superm1> StevenK, okay well i'll take a look after I get this box booting amd64
[04:36] <persia> I just checked the deleted packages : it looks like it was never in the PPA.
[04:37] <StevenK> Oh.
[04:37] <StevenK> obex_socket.c:(.text+0x97a): undefined reference to `hci_remote_name'
[04:38] <StevenK> What's the fix for that, it's a simple one
[04:39] <StevenK> persia: Bug 281561
[04:40] <StevenK> persia: There is tasks for all seven, I'd suggest you dole them out. I'd like one, please.
[04:44] <StevenK> superm1: Right, test building my ussp-push changes.
[04:44] <persia> StevenK, Do we know which architectures are affected?
[04:45] <StevenK> persia: For the ones I've filed, most of them are.
[04:45] <StevenK> There was one other build failure, which was hppa, so I'm ignoring it
[04:45] <persia> hppa belongs to people with hppas
[04:46] <persia> StevenK, So, you can have curl.  I know it's one of your favorites.
[04:46] <StevenK> Oh, yay
[04:46] <StevenK> :-P
[04:46] <persia> ScottK, Up for libtunepimp, or is there one you'd rather?
[04:46] <StevenK> I was thinking about the curl build failure while I was out. I think it's a one line patch
[04:47] <persia> This is the advantage of your previous experience with curl :)
[04:47] <ScottK> I'd rather finish fixing amavisd-new and kdvi for right now.
[04:47] <StevenK> superm1: ussp-push uploaded
[04:47] <persia> ScottK, OK.  Any of the gnutls13 ones you want for later?
[04:49] <ScottK> Looking
[04:51] <StevenK> Oh, damn. Forgot to put the bug into ussp-push's changelog
[04:51] <persia> NCommander, You about at this hour?
[04:52] <superm1> wgrant, http://paste.ubuntu.com/56182/
[04:53] <ScottK> persia: Just for grins I'll have a look at kio-sword.    You can have kazehakase if you like.
[04:55] <superm1> StevenK, okay great.  i'm guessing it was an easy fix then
[04:55] <StevenK> superm1: Yeah, one line patch
[04:55] <superm1> StevenK, okay cool, good
[04:55] <StevenK> superm1: That closes all of the transition bug tasks
[04:56] <persia> That means the removal bugs can be processed.  Now we just need solid sorted.
[04:56] <StevenK> persia, superm1: Can one of you sort out https://bugs.launchpad.net/bugs/191704
[04:57] <StevenK> One guy is complaining it's missing with 4.12-0ubuntu2. I suspect that's indented
[04:57] <superm1> StevenK, yeah it's intentional
[04:57] <persia> Anyone from the docteam about?
[04:57] <superm1> StevenK, that functionality is provided directly from bluetoothd and the wizard
[04:57] <StevenK> persia: Taking kazehakase
[04:57] <persia> StevenK, Great.  That's them all assigned then.  Thanks.
[04:58] <superm1> StevenK, if people really want hidd and throw arms up, the binaries can be put into a NEW bluez-compat package, but people really shouldn't be needing them...
[04:58]  * persia goes off to find the docteam
[04:59] <StevenK> superm1: I think you should reply to that bug saying that it shouldn't be needed, and if stuff doesn't work, file a new bug
[05:00] <persia> No, there's a documentation bug.  help.ubuntu.com specifically mentions hidd
[05:00] <StevenK> Ahhhh
[05:00] <StevenK> It probably ought not to
[05:00] <persia> The bug isn't currently triaged ideally : I'll chase the docteam, and try to get it sorted.  We *really* need solid fixed to do it right.
[05:01] <StevenK> solid is a package?
[05:01]  * persia digs up the bug
[05:02] <persia> bug #280997
[05:03] <persia> See, before the transition bluetooth was broken for everything but OBEX for some people.  After the transition, bluetooth is broken for KDE.
[05:03] <superm1> solid is part of the massive kdebase-workspace library
[05:03] <persia> Being broken for KDE is bad because 1) it annoys people, 2) it delays my plans for kubuntu-mid, and 3)
[05:04] <persia> It leads to annoying blog posts.
[05:04]  * persia misses Qtopia
[05:04] <ScottK> persia: All I know is I have less bluetooth than I had before.
[05:05] <persia> ScottK, Right.  Which devices were you using?  Just the phone, right?
[05:05] <ScottK> Yes
[05:05] <ScottK> This was going to be the first release I could actually use it.
[05:05] <ScottK> It was a wonderful week while it lasted.
[05:06] <ScottK> persia: It leads to accurate blog posts.
[05:06] <persia> That's what I thought.  If you had a keyboard or mouse, you'd have more bluetooth, but this isn't ideal.
[05:06] <ScottK> No, I wouldn't.  I'd still be at zero.
[05:06] <persia> Would you?  I was able to connect with the command line to my keyboard.
[05:07] <ScottK> I wouldn't have minded so much if it'd been tested with KDE and known to break it and the options considered and it was decided it needed to be done.
[05:07] <persia> Anyway, not important.  The important thing is to fix it.
[05:07] <ScottK> The thing is it's not the first time it's happened this cycle and the predominant response from Ubuntu devs seems to be 'tough'.
[05:07] <ScottK> Not the best way to build togetherness.
[05:07] <persia> Understood, although as I said before, having anyone respond to the call for testing would have been a good step.
[05:08] <persia> No, that's not good.
[05:08] <ScottK> And if someone had said "And we need it tested by ..." it would have been on a different place on my list.
[05:08] <persia> This was the first I heard about it, and while I'm wishing someone tested it, I do sympathise.
[05:08] <persia> OK.  I can see that.
[05:08] <ScottK> I said I'd test it, but I had no idea when it needed to be done by and the upload came as a total suprise.
[05:10] <persia> That puts a different light on things.
[05:10] <persia> I'd seen calls for testing with no response, and I'd seen lots of traffic in -motu and here about it.
[05:10] <persia> I hadn't seen you commit to testing, and then not be checked with before upload.
[05:10]  * StevenK uploads curl
[05:37] <ScottK> persia and StevenK: kio-sword has a happy ending.  It's not yet been ported to KDE4 and can't work with the remainind KDE3 bits we have in Intrepid, so we get to remove the package.
[05:38] <StevenK> \o/
[05:38] <StevenK> ScottK: Won't fix the FTBFS bug and file a removal bug
[05:38] <persia> Excellent.
[05:39] <ScottK> Already did the wontfix.  It has to get dropped from Ichthux-meta first.
[05:39] <persia> jd failes to FTBFS for me.  StevenK: what did you do differently?
[05:39] <StevenK> Argh. Ichthux again
[05:39] <persia> If I try to process the open sync request, it FTBFS, but if I just recompile the current intrepid package it works.
[05:40] <persia> StevenK, NBS again?
[05:40] <StevenK> persia: I just added a changelog entry for jd and uploaded it
[05:40]  * persia hunts LP
[05:40]  * persia also goes to find the ichthux people
[05:41] <StevenK> persia: Ah ha. I uploaded 1:1.9.9-080415-3build1 which broke, and james_w uploaded 1:1.9.9-080415-3ubuntu1 which built
[05:41] <ScottK> persia: I already talked to txwikinger
[05:41] <ScottK> He's going to take care of it.
[05:41] <persia> Oh.  Cool.  Thanks.
[05:44] <persia> StevenK, As usual, you're faster than I.  I suppose I need to swap packages with james-w then.
[06:14] <NCommander> persia, I am now
[06:16] <StevenK> NCommander: You haz a bug
[06:16] <persia> NCommander, I gave you one of the gnutls13 killing FTBFSs
[06:18] <NCommander> persia, cool, but I'll look it into tommorow unless there is a pressing concern to do it tonight. (just came back from the bar ...)
[06:19] <persia> NCommander, No pressing concern.  pitti gave us a green light to rebuild ~60 packages to drop gnutls13 yesterday, and we're nearly done.  One of them (nufw) is yours.  You can get to it tomorrow or so.  I think pitti wants to remove the gnutls13 source on Monday.
[06:19] <NCommander> Its' nice seeing the cruftbuster group getting used :-)
[06:19] <ajmitch> NCommander: if you just came back from the bar, I won't bug you now about a rebuild FTFBS
[06:19]  * persia likes having a handy list of people who can be assigned bugs
[06:20] <NCommander> ajmitch, I'm just buzzed, not drunk
[06:20] <StevenK> persia: gnash is still outstanding
[06:20] <ajmitch> NCommander: libtool acting silly, your specialty
[06:20] <StevenK> persia: I didn't touch that one, but I want to hit up asac
[06:20] <NCommander> ajmitch, build log?
[06:20] <persia> StevenK, I thought asac had a plan for that.
[06:20] <StevenK> persia: Since it's now holding up libtool and gnutls
[06:21] <StevenK> persia: He does, I just can't remember what it is
[06:21] <persia> libtool too!  That's not ideal.
[06:21] <ajmitch> NCommander: http://paste.ubuntu.com/56205/
[06:21]  * ajmitch didn't have time to look at it any further than saying 'oh bother'
[06:21] <NCommander> oh
[06:21] <NCommander> THAT issue
[06:21] <ajmitch> I thought you'd recognise something
[06:22] <NCommander> Shouldn't be that hard to fix
[06:22] <persia> rezound never seems to make it through a transition intact, for some reason.
[06:22] <ajmitch> persia: right, this is one of the cups ones
[06:23]  * NCommander tries building nufw
[06:24] <ajmitch> NCommander: so, from 'not hard to fix', got any info?
[06:24] <NCommander> ajmitch, the usual issue if the md5 macros aren't getting pulled in
[06:25] <NCommander> *MD4
[06:25] <NCommander> Two ways to fix
[06:25] <NCommander> Remove the changes to configure.ac to prevent requiring relibtoolizing the package
[06:25] <NCommander> Run libtoolize -I/usr/share/*libtool-ver*/m4 or something like that, and PRAY you get a working libtool
[06:25] <NCommander> persia, finished with nufw
[06:25] <persia> NCommander, patch?
[06:26] <NCommander> Didn't need one
[06:26] <NCommander> It just rebuild without issue
[06:26] <persia> Just give-backs?
[06:26] <NCommander> Retesting in pbuilder just incase thats a fluke
[06:26]  * persia gives it back
[06:26] <NCommander> Yeah
[06:26] <ajmitch> NCommander: sounds suitably evil
[06:26] <NCommander> I op for the former if its possible
[06:26] <NCommander> (i.e. courier)
[06:26] <NCommander> The later is sometimes necessary though (i.e. php-clamav)
[06:27]  * persia decides to sponsor 214512 rather than doing a give-back
[06:27] <NCommander> wait
[06:27] <NCommander> Hold on that give-back
[06:27] <NCommander> Might be a false negetive
[06:27] <NCommander> I haven't updated my system within 48 hours
[06:27] <persia> Err, yeah, you'll want to do that :)
[06:27] <NCommander> (pbuilder is pulling in a bunch of updates now that I'm testing with that)
[06:27] <NCommander> yeah
[06:27] <NCommander> :-)
[06:27]  * NCommander blames the booze
[06:28] <NCommander> libgnutls-dev is already the newest version.
[06:28] <persia> NCommander, If you do need a patch, consider adding also Dave Love's patch from 214512.  If you don't need a patch, tell me, and I'll upload.
[06:29] <NCommander> Give it five minutes and I'll know
[06:29] <NCommander> (pbuilder pulling build-deps)
[06:29] <persia> NCommander, Does it help if I tell you that it only FTBFS on sparc, powerpc, and hppa?
[06:29] <NCommander> -_-;
[06:29] <NCommander> That WOULD be helpful ;-)
[06:30] <persia> https://launchpad.net/ubuntu/intrepid/+source/nufw/2.2.15-1build1
[06:30] <NCommander> persia, oh, that fix is trival
[06:31] <persia> Thought so.  Wrap with Dave's http://launchpadlibrarian.net/13274956/nufw.diff, slap on a changelog entry, and post it.
[06:31] <NCommander> er
[06:31] <NCommander> Scratch that
[06:31] <NCommander> I can't
[06:31] <NCommander> PPC box is dead ATM
[06:31] <persia> Hrm?
[06:31] <NCommander> Leave me subscribed
[06:31] <persia> sparc/hppa ?
[06:31] <NCommander> hppa just has issues ;-)
[06:32] <NCommander> And the sparc box I have access to is spooky which is hardy
[06:32] <persia> OK.  Another day then.
[06:32] <NCommander> Yeah
[06:32]  * NCommander marks it Fix Committed, and Wishlist
[06:33] <NCommander> Not strictly right, but it is fixed on amd64/i386 :-)
[06:33] <persia> Hrm?  Why Fix Committed?
[06:33] <NCommander> Hrm
[06:33] <NCommander> Maybe in progress
[06:33] <persia> That sounds better.
[06:33]  * NCommander recommends you ignore me :-)
[06:33] <NCommander> ajmitch, is the package I need to try building in the archive, or where do I need to get the source?
[06:36] <wgrant> superm1: Excellent. Thanks. Same hardware, with around the same version of Intrepid?
[06:36] <superm1> wgrant, exact same hardware.
[06:36] <superm1> wgrant, i installed the packages you indicated to the latest on the archive
[06:36] <wgrant> superm1: Great, so it's confirmed. Thanks for your help.
[06:37] <persia> So it's that amd64 is broken?
[06:37] <superm1> wgrant, yesterday's daily of amd64, and then a fully up to date i386 "install"
[06:37] <NCommander> persia, thanks for subscribing me
[06:37] <superm1> wgrant, so what did I confirm exactly?
[06:37] <superm1> what's broke?
[06:37] <persia> superm1, Getting input properties on amd64
[06:37] <superm1> ah
[06:38] <wgrant> So some internal bit of xserver is broken on amd64.
[06:38] <wgrant> Or some lib is broken, I guess.
[06:38] <wgrant> But that seems less likely, AFAICT.
[06:38] <persia> Any way to track it down easily, or is it a matter of attaching gdb to X, and digging through the noise?
[06:39] <wgrant> Monitoring the conversation would work - it's not too difficult, because TCP can be used.
[06:40] <ajmitch> NCommander: yes, rezound, in the archive. Only change I did was changing libcupsys2.dev to libcups2-dev, iirc
[06:40] <wgrant> But it will likely end up as an unfortunate session with gdb.
[06:41] <StevenK> Hmmm.
[06:41] <persia> wgrant, I don't understand the parts, but I'm comfortable with GDB, have affected hardware, and a willingness to test.  What should I do?
[06:41] <StevenK> superm1: libgnomebt0 is now in NBS, and gnome-phone-manager requires it.
[06:41] <superm1> StevenK, why is it NBS?
[06:42] <StevenK> superm1: Because it part of gnome-bluetooth
[06:42] <superm1> gah
[06:42] <superm1> that's not cool :(
[06:42] <StevenK> -- intrepid/main build deps on libgnomebt0-dev:
[06:42] <StevenK> nautilus-sendto
[06:42] <StevenK> -- intrepid/universe build deps on libgnomebt0-dev:
[06:42] <StevenK> gnome-phone-manager
[06:42] <persia> superm1, Erm.  Didn't we discuss that oddity of a dependency when we were looking at PPA uploads?
[06:43] <superm1> oh that's even worse.
[06:43] <superm1> persia, not this one
[06:43] <superm1> persia, we were talking about build order dependencies
[06:43]  * persia can dig up logs, if required
[06:43] <superm1> StevenK, given nautilus-sendto is broke, too, i think gnome-bluetooth needs to be reinstated that means, and we'll have to resolve it's problem
[06:44] <StevenK> Grumble

[06:44] <persia> The problem with gnome-bluetooth is that it's not been maintained for three years.
[06:44] <StevenK> superm1: Are you coming to UDS? *evil grin*
[06:44] <superm1> StevenK, yeah i am
[06:44] <superm1> persia, agreed
[06:44] <StevenK> Right. I'll get you.
[06:45]  * superm1 hides in advance
[06:45]  * NCommander looks forward to seeing what you folks look like at UDS
[06:45] <slangasek> StevenK: you're not supposed to tell him that until after you've passed the TSA checkpoint
[06:45] <StevenK> Haha
[06:46] <StevenK> Soyuz, please grow an undelete feature
[06:46] <persia> Isn't that called dput?
[06:46] <cprov> StevenK: we can use copy-package.py to undelete stuff
[06:46] <persia> Ooh.  Even better :)
[06:46] <StevenK> cprov: Sweet!
[06:47] <slangasek> methinks cprov has a highlight on 'soyuz'
[06:47] <StevenK> Haha
[06:47]  * wgrant agrees with slangasek.
[06:47] <persia> This is a good thing, as it comes with excellent solutions
[06:48] <NCommander> StevenK, well, if your fast, you can download the package before its deleted ;-)
[06:48] <persia> So, aside from the problems I had with gnome-bluetooth in Breezy, what's the new problem with it?
[06:48] <StevenK> I have locally anyway
[06:51] <wgrant> persia: OK, you basically need to ensure your X likes TCP connections, export DISPLAY=localhost:0.0, fire up Wireshark or similar on lo, and run various xinput actions.
[06:52] <ScottK-laptop> NCommander: Any conclusions on openexr?
[06:52] <NCommander> ScottK-laptop, talking with lamont, override the test suite
[06:52] <NCommander> Its NPTL thats broken, which means threading in general pretty borked
[06:53] <persia> wgrant, Is it safe to run wireshark in the X session, or should I be looking for tcpdump or similar in a VC?
[06:53] <ScottK-laptop> NCommander: Debdiff me?
[06:53] <wgrant> persia: As long as you run Wireshark with DISPLAY set to something normal it won't use TCP, so it will be fine.
[06:54] <NCommander> ScottK-laptop, I can't testbuild the change ATM, so I'm just going to add hppa to the NOTEST list, and hope for the best
[06:54] <persia> OK.  So start wireshark in a normal session.  Open a special xterm with DISPLAY set to localhost0:0. and perform some mousing?
[06:54] <ScottK-laptop> NCommander: Sounds reasonable.
[06:55] <wgrant> persia: I set DISPLAY to localhost:0.0 in another gnome-terminal tab, then 'xinput list-props 3'
[06:55] <wgrant> Your integer may vary.
[06:56] <persia> RIght.
[06:56] <wgrant> Wireshark then very nicely dissects the X packets for me, giving all of the arguments.
[06:56] <wgrant> It's rather nicer than I expected
[06:56] <StevenK> Wireshark is *GOOD*
[06:56] <wgrant> Not security-wise.
[06:56] <wgrant> But it is very useful otherwise.
[06:56] <wgrant> I just hadn't used it for X before.
[06:57] <NCommander> ScottK, http://paste.ubuntu.com/56216/
[06:57] <wgrant> Actually, even better, use my getprop thing which should minimise the number of extraneous requests.
[06:57] <wgrant> http://www.qeuni.net/f/1/2008/getprop.c
[06:57] <NCommander> ScottK, I'm test building now just to make sure I didn't break i386's build
[06:57] <wgrant> gcc -o getprop -lXi getprop.c
[06:58] <wgrant> ./getprop <some device ID> <some property name>
[07:00] <persia> OK.  What do I need to do to make my X like localhost?
[07:00] <wgrant> persia: System->Administration->Login Window->Security->Deny TCP connections to XServer.
[07:02] <wgrant> persia: You'll likely need to restart X afterwards.
[07:04] <wgrant> I've been seeing that all too frequently today.
[07:04] <StevenK> Haha
[07:06]  * StevenK resurrects gnome-bluetooth
[07:06] <persia> StevenK, Now, check if gnome-phone-manager actually works for you.
[07:07] <StevenK> persia: I can't
[07:07] <StevenK> I need to wait for the publisher
[07:08] <wgrant> StevenK: Grab the binaries from LP?
[07:08] <StevenK> That requires thinking
[07:08] <wgrant> Point.
[07:09] <persia> Not much thinking...
[07:13] <persia> wgrant, ./getprop segfaulted.    Works fine.  7*3=21
[07:15] <wgrant> persia: Does getprop work if you use a more normal DISPLAY?
[07:16] <persia> I see lots of keyboard and mouse events in wireshark.  It's just your code that segfaults.
[07:16] <persia> No.  segfaults normally too.
[07:16] <wgrant> persia: Which version of libxi6 do you have installed?
[07:16] <persia> 2:1.1.3-1ubuntu4
[07:17] <wgrant> libxi-dev?
[07:17] <wgrant> That's very interesting that it should segfault.
[07:17] <persia> 2:1.1.3-1ubuntu4
[07:17] <wgrant> You aren't specifying an invalid device? I guess a backtrace would show the issue.
[07:18] <persia> Oh, that's probably it.
[07:18] <persia> That works sanely.
[07:19] <persia> Sorry :)  Now, I've a clean TCP trace of the getprop interactions.  What info do you want?
[07:19] <wgrant> The request and response of the GetProperty call.
[07:20] <persia> Just the interpreted X11 data?
[07:20] <wgrant> (the digested X11 dump that wireshark gives)
[07:20] <wgrant> Yes.
[07:20] <StevenK> persia: I don't have an Intrepid virtual machine, and gnome-phone-manager wants dbus, which doesn't work through a chroot
[07:23] <persia> http://paste.ubuntu.com/56220/
[07:23] <persia> StevenK, And it wants bluetooth, which is tricky with either virtual machines or chroots.  Don't you have an intrepid machine with bluetooth around somewhere?
[07:24] <wgrant> persia: Which property did you try to get?
[07:24] <StevenK> persia: My Jax, but that's hard to get working
[07:24] <persia> I just did ./getprop 4
[07:24] <persia> Should I have done something else?
[07:24] <persia> StevenK, Yeah, that doesn't work very well.  I thought you had one of those Samsung slabs.
[07:25] <wgrant> persia: I'm surprised that didn't segfault... It wants a second argument - the name of the property. "Device Enabled" should do for anything.
[07:25] <StevenK> persia: Oh, I keep forgetting the Q1 has Bluetooth
[07:25] <persia> heh
[07:25] <wgrant> One of the more informative quit messages I've seen lately.
[07:26] <StevenK> There is, too
[07:26] <wgrant> It's the warmest day for a while down here, with no rain predicted for another 24 hours.
[07:26] <StevenK> Tropical day here
[07:26] <StevenK> Hot and humid and storm clouds gathering
[07:27] <persia> wgrant, `./getprop 4 "Device Enabled"` produces the exact same dump.
[07:27] <wgrant> Charming.
[07:27] <StevenK> Few cracks of thunder, so it probably break soonish
[07:27] <ajmitch> wgrant: mid-30s?
[07:29]  * didrocks hugs NCommander (you are the only one who hl me by error :))
[07:29] <wgrant> ajmitch: 25°C
[07:30] <didrocks> (morning)
[07:31] <wgrant> persia: Oh, of course, it's GetDeviceProperty, which doesn't seem to be showing up.
[07:32] <wgrant> I guess Wireshark doesn't know about it... let's see what I can find.
[07:32] <persia> heh.  hppa beat ia64 for gss.
[07:32] <wgrant> hppa has been beating ia64 for a few days.
[07:32]  * StevenK can't fix kazehakase.
[07:32] <ajmitch> so has the minor X breakage been fixed? I should really upgrade the laptop to intrepid
[07:32] <ajmitch> StevenK: can't?
[07:32] <wgrant> I was very surprised when I saw "ia64: Needs building" and "hppa: Succesfully built (DONE)" last night.
[07:33] <wgrant> ajmitch: g-c-c and g-s-d were uninstallable for 3 hours last night... is that what you mean?
[07:33] <StevenK> I have added a patch that should fix it, but doesn't
[07:33] <persia> wgrant, after GetProperty, I have InternAtom, QueryExtension, and several XInputExtensions, if any of those would help you.
[07:33] <ajmitch> wgrant: more the removal of input drivers
[07:33] <wgrant> ajmitch: Right, same thing.
[07:33] <wgrant> That's all fixed.
[07:33] <wgrant> It was never really broken, just needed three publishers to settle down.
[07:34] <persia> StevenK, Does it fail in a non gnutls place, or in the same place?
[07:34] <wgrant> persia: I'm grabbing the Wireshark source to see if I can teach it about XI properties.
[07:34] <persia> StevenK, james-w had to do some reordering of some includes for jd, if I'm properly mapping discussion times to upload times.
[07:34] <StevenK> persia: It never did
[07:34] <wgrant> Or maybe xtrace. That looks easier.
[07:34] <StevenK> persia: It failed due to GTK symbol deprecation
[07:35] <persia> wgrant, OK.  I intend to go outside today.  Should I do that sooner, or later?
[07:35] <StevenK> persia: It still does, just in a different place
[07:35] <wgrant> persia: Sooner is probably good.
[07:35] <persia> StevenK, Ah, so it was probably FTBFS before the transition?
[07:35] <persia> wgrant, OK.  I'll do that, and pull a new version of whatever you end up patching this evening.
[07:36] <wgrant> persia: Sounds good.
[07:36] <persia> So, who knows GTK well and can fix kazehakase?
[07:37] <StevenK> persia: I have a patch that should fix it.
[07:37] <persia> StevenK, Yes, but it doesn't, right?
[07:37] <StevenK> I think it just needs a second pair of eyes
[07:39] <persia> OK.  Who knows GTK well and can look at StevenK's patch for kazehakase?
[07:45] <StevenK> http://people.ubuntu.com/~stevenk/kazehakase/
[09:27] <wgrant> in 8
[09:27] <wgrant> Damn.
[09:44] <wgrant> persia: Around again?
[10:21] <persia> wgrant, Just got back.
[10:22] <wgrant> persia: Hi.
[10:23] <wgrant> persia: When you have time, grab and install http://www.qeuni.net/f/1/2008/xtrace_0.9.1-1+wgrant1_amd64.deb.
[10:23] <wgrant> When run, it will run a proxy X server on :9 - run getprop on that display, and we can see what's going to/from the xserver.
[10:24] <persia> wgrant, How did you construct that without amd64?
[10:27] <wgrant> persia: I have no local amd64 machine, but stratos is amd64.
[10:27] <persia> Oh, right :)
[10:28] <persia> So just xtrace, or does it take arguments?
[10:28] <wgrant> Just xtrace.
[10:28] <wgrant> It should sit there and tell you which display it's running on.
[10:28] <persia> It's running on :9
[10:28] <wgrant> Sounds right.
[10:28] <persia> Then set something to localhost:9.0 and run getopts
[10:29] <persia> Err getprop?
[10:29] <wgrant> export DISPLAY=:9
[10:29] <wgrant> Then getprop as usual, yes.
[10:29] <wgrant> xtrace will display all of the X traffic, then terminate.
[10:29] <persia> ./getprop 4 "something" : what's the something again?
[10:29] <wgrant> XIGetDeviceProperty is the problematic call, so that request and response would be nice.
[10:30] <wgrant> "Device Enabled"
[10:30] <persia> core dump.
[10:31] <wgrant> What coredumped?
[10:31] <persia> getprop
[10:31] <wgrant> Is xtrace still running?
[10:32] <persia> Yep.
[10:32] <wgrant> Hum. gdb getprop and see where it fails?
[10:32] <wgrant> Probably XGetDeviceProperty, because device or display might be NULL.
[10:35] <persia> #0 in XInternAtom #1 in main
[10:35] <wgrant> display is NULL?
[10:38] <persia> Ah.  I missed a character.  Right.  Sorry.
[10:38]  * wgrant likes nice easy fixes like that.
[10:38] <persia> OK.  That worked.  I thought export DISPLAY=9 was wrong, but figured you knew better than I, and failed to consider that I wasn't reading carefully :)
[10:38] <persia> I've an xtrace
[10:39] <wgrant> OK, pastebinit if it's not too huge.
[10:41] <persia> http://paste.ubuntu.com/56244/
[10:42] <wgrant> OK, that makes sense, and shows it's not entirely on crack.
[10:42] <wgrant> Device 0 isn't a real device, so won't have properties. Can you try one which does?
[10:42] <wgrant> (it is informative, however, in that it correctly notifies us that it doesn't know about the property)
[10:43] <persia> I asked for device 4, which was my touchpad.
[10:43] <persia> http://paste.ubuntu.com/56245/ is the other terminal
[10:43]  * StevenK returns
[10:43] <wgrant> Hmmm.
[10:44] <wgrant> "deviceid=0"
[10:44] <persia> http://paste.ubuntu.com/56246/ was xinput list
[10:44] <wgrant> That's what's being sent.
[10:44] <wgrant> It looks like the server might actually be fine.
[10:44] <StevenK> Awww. No one fixed my kazehakase annoyance
[10:45] <wgrant> persia: Here's mine, for example: http://paste.ubuntu.com/56247/
[10:45] <persia> wgrant, That's odd.
[10:46] <persia> wgrant, That's for your keyboard, or a pointing device?
[10:46] <wgrant> persia: 4 is my touchpad.
[10:46] <persia> same as I, but the output is quite different.
[10:47] <wgrant> I note that you have an xorg.conf entry for your touchpad, but I doubt that matters here.
[10:47] <wgrant> What if you do it to your keyboard?
[10:49] <persia> http://paste.ubuntu.com/56249/ is my keyboard (device 5)
[10:50] <wgrant> Hmmm.
[10:50] <jcristau> property=0x5("BITMAP") type=0x6d("Device Enabled")
[10:50] <jcristau> the 0x5 should be device
[10:50] <jcristau> and the 0x6d should be the property, afaict
[10:50] <wgrant> Yes.
[10:50] <wgrant> That's what I'm noticing.
[10:50] <persia> RIght.  That is correct for the keyboard.  Now look at 56244
[10:51] <wgrant> I can't see that it's a problem with xtrace, but one would have to inspect in Wireshark to be sure.
[10:52] <wgrant> persia: Do you still have a trace in Wireshark?
[10:52] <persia> OK.  Is that just running wireshark again, and running against localhost:0.0 ?
[10:52] <persia> Not now, but I can regenerate.  Hold on.
[10:52] <wgrant> Yep.
[10:52] <wgrant> You need the second-last XInputExtension request.
[10:52] <mdke> asac_: i see it, but can you explain more?
[10:54] <persia> "opcode: Unknown (146)\nundecoded\n"
[10:54] <wgrant> persia: I need the hex after and including 0x92 0x27.
[10:54] <wgrant> If you select "undecoded" it should be selected.
[10:55] <mdke> persia: on your post in #ubuntu-doc, we don't currently have any bluetooth documentation in ubuntu-docs, it might be a good idea to add some (judging from the confused results you get if you search for "bluetooth" in yelp). It might fit as a section in "Internet and Networks" I guess
[10:55] <persia> 46 8e 92 27 06 00 04 00 00 00 6d 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00
[10:55] <wgrant> Hmmm.
[10:55] <persia> mdke, I was just going to ask you about that.  How do I do that?
[10:55] <wgrant> persia: Was the 46 8e part of the undecoded too?
[10:56] <wgrant> Wait.
[10:56] <wgrant> Huh.
[10:56] <persia> wgrant, Yep.  There's more before that, but I thought 2 bytes was probably enough left context.
[10:56] <wgrant> What the...
[10:56] <mdke> persia: are you interested in writing the material yourself? If so the best way is to checkout https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation. If not, the best way is just to file a bug
[10:57] <wgrant> jcristau: Something is going very, very wrong, probably in libxi..
[10:57] <wgrant> It should be property, type, offset, length, device.
[10:57] <wgrant> But yours shows device first.
[10:57] <wgrant> Wow.
[10:57] <persia> mdke, I'm not really interested in writing it, but I'm sufficiently interested in it being written that I'll be the author if nobody else has time.  Ideally, I'd collaborate with someone.
[10:58] <persia> mdke, Bug against which project?   ubuntu-doc?
[10:58] <wgrant> device, property, offset, type, length, I think.
[10:58] <mdke> persia: ok, filing the bug is a good start then, we'll mark it as a task for new contributors and hopefully someone will pick it up. Yes, project is ubuntu-doc
[10:58] <mdke> persia: gtg for now but feel free to email the list as well if you want to follow up
[10:59] <persia> mdke, OK.  I'll watch the bug, and note that I'm willing to collaborate.  If I don't hear anything, I'll poke the list, and if that also fails, try to write something.
[10:59] <persia> mdke, Thanks for the explanation.
[11:01] <persia> wgrant, I've been fiddling with the wireshark interface, and it appears "undecoded" starts at "27" in the above string.
[11:02] <wgrant> persia: Sounds right. I was just misreading it.
[11:02] <wgrant> But it certainly seems to have a strange order.
[11:03] <persia> I'll take your word for it.  I don't understand what I'm reading here :)
[11:03] <wgrant> /usr/include/X11/extensions/XIproto.h is useful.
[11:03] <wgrant> xGetDevicePropertyReq correctly represents things on i386.
[11:04] <rom1v> hi, since yesterday (or 2 days ago), compiz + nvidia is unusable
[11:04] <rom1v> screen is not refreshed
[11:04] <persia> rom1v, Did you file a bug?
[11:04] <rom1v> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/281065
[11:05] <rom1v> I commented a reported bug 5 hours before
[11:05] <persia> rom1v, OK.  You probably want to chat with the folks in #ubuntu-bugs about it.
[11:05] <rom1v> ok, thank you
[11:05] <persia> rom1v, Good luck.
[11:05] <rom1v> ;)
[11:07] <wgrant> persia: What does the GetProperty request look like?
[11:08] <Laney> persia, superm1: Do you know what's going on with gnome-bluetooth? Looks like it was removed and then put back.
[11:08] <persia> Any specific part, or you want the whole thing?
[11:08] <persia> Laney, gnome-phone-manager depends on it : it shouldn't have been removed.
[11:08]  * Laney was eyeing up the NBS list
[11:08] <Laney> k
[11:08] <wgrant> persia: The whole thing from the start of the X request (ie. the bit selected when you select the X11 item)
[11:09] <persia> hex?
[11:09] <wgrant> Yes please.
[11:09] <persia> 14 00 06 00 99 00 00 00 17 00 00 00 1f 00 00 00 00 00 00 00 00 e1 f5 05
[11:09] <wgrant> That's in the right order.
[11:15] <crushy> join #plone
[11:18] <persia> wgrant, So it's libxli that's changing the order, or something else, or just confusing?
[11:18] <wgrant> persia: It doesn't look like xserver's problem.
[11:18] <persia> OK.  Somewhere else then?
[11:18] <wgrant> xserver is returning correctly, given the crap that the client is giving it.
[11:19]  * wgrant is looking.
[11:39]  * ogra hugs pitti for the quick ltsp response :)
[13:04] <persia> wgrant, I'm out for the night, and won't be about much tomorrow.  Feel free to mail me if you want me to test something specific, or catch me tomorrow night.
[13:05] <wgrant> persia: Thanks for your help today,.
[13:05] <persia> wgrant, No, thanks for investigating this.  I'd like it to work right, and want to move on to the attaching-joystick-crashes-the-system once we get mice working.
[13:06] <persia> Ideally we could swap laptops for a couple weeks, but there's all that water...
[13:07] <wgrant> They can swim, I'm sure.
[13:07] <persia> heh
[13:41] <james_w> StevenK: hey, you around?
[13:42] <StevenK> james_w: I am
[13:42] <james_w> StevenK: kazhehakase is due to GTK_DISABLE_DEPRECATED
[13:43] <james_w> I've got a candidate fix, but I gave up fighting dpatch last night
[13:43] <StevenK> james_w: I had a patch that stopped using the deprecated macros
[13:43] <james_w> even better
[13:43] <StevenK> james_w: If you'd like, we can sit down together and discuss care and feeding of dpatch, if you like.
[13:44] <StevenK> james_w: (At UDS, I mean)
[13:44] <james_w> I'd like it if it didn't try and convert an existing diff to a context diff when I add a hunk to it
[13:44] <StevenK> http://people.ubuntu.com/~stevenk/kazehakase/
[13:44] <james_w> I've never seen it before
[13:45] <fta> wgrant, hi, what do you suggest for my evdev issue ?
[13:45] <StevenK> james_w: That's my source for it, but it still fails, and I'm not sure where it's picking up the deprecated macros from if I'm patching them out
[13:45] <StevenK> james_w: You're using dpatch-edit-patch ?
[13:45] <wgrant> fta: Which evdev issues?
[13:46] <fta> wgrant, the one you just commented on in the forum
[13:46] <james_w> StevenK: yeah
[13:46] <wgrant> fta: Oh, right. Umm... make your computer slower.
[13:46] <wgrant> I'm not sure how it should be fixed.
[13:46] <wgrant> There's a bug on it somewhere.
[13:47] <fta> wgrant, i'd like it to be faster ;)
[14:34] <directhex> any objections to me merging mono 1.9.1+dfsg-4? it's a bugfix-only release
[14:36] <james_w> we have -3?
[14:40] <directhex> yeah, intrepid has -3
[14:40] <directhex> well, 3ubuntu2
[14:46] <james_w> directhex: I don't think that would be a problem, assuming the fixes in -4 are worthwhile.
[14:47] <directhex> james_w, http://svn.debian.org/viewsvn/pkg-mono/mono/trunk/debian/changelog?rev=3719&view=auto
[14:47] <james_w> yeah, that looks worthwhile
[14:49] <directhex> trying to determine whether we can backport another fix before tagging for upload
[15:47] <Riddell> ArneGoetje: you're doing langpacks now?  bug 281779 is important
[15:48] <ScottK-laptop> slangasek, pitti, and superm1: Following up on our discussion about libfile-temp-perl from yesterday, the new mime-tools hit depwait.  It looks like Soyuz's versioned provides problem has resurfaced: http://launchpadlibrarian.net/18424754/buildlog_ubuntu-intrepid-i386.mime-tools_5.426-1ubuntu1_MANUALDEPWAIT.txt.gz
[15:49] <ScottK-laptop> libfile-temp-perl(inst =*=PROVIDED=*= ! >= wanted 0.18)
[15:50] <ScottK-laptop> Actually a different incarnation, not the exact same one again.
[15:53] <superm1> ScottK-laptop, so it is surely a bug in soyuz though?
[15:53] <ScottK-laptop> superm1: Yes.  I agree.
[15:53] <ScottK-laptop> It was more FYI for you.
[15:53] <superm1> ok thx
[15:54] <cprov> ScottK-laptop: launchpad-buildd bug, right ?
[15:54] <ScottK-laptop> cprov: Presumably.
[15:54] <cprov> ScottK-laptop: sbuild strikes again :(
[15:55] <ScottK-laptop> We had a problem similar to this before that caused problems with perl modules (yes)
[15:55] <cprov> I remember.
[15:56] <ScottK-laptop> So it's kind of out of my hands to fix ...
[16:00] <cprov> ScottK-laptop: https://bugs.edge.launchpad.net/launchpad-buildd/+bug/184565 ?
[16:03] <ScottK-laptop> cprov: Similar.
[16:04] <ScottK-laptop> I'm guessing this will be another one for infinity to look at though.
[16:04] <cprov> ScottK-laptop: okay, could you or superm1, please file a new bug on lp-buildd ?
[16:04] <cprov> ScottK-laptop: no doubt ;)
[16:08] <ScottK-laptop> cprov: Bug #281796 if you'd please give it an appropriately urgent importance.  I think it's safe to confirm it too.
[16:09] <cprov> ScottK-laptop: done, thanks, I will talk to infinity Mondy.
[16:09] <cprov> Monday, even (keyboard from hell)
[16:52] <asac> mdke: there?
[16:52] <mdke> asac: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[16:53] <asac> mdke: oh ... so yes. you think we can get that in the documentation or is all over?
[16:54] <asac> mdke: those screenshots are about the mobile broadband wizard (3g)
[16:55] <asac> mdke: when user plugs his device in for first time he sees the bubble and can click configure
[16:55] <asac> mdke: next steps are wizard pages. and finally a confirmation that the new connection was added
[17:25] <ArneGoetje> Riddell: I'm not sure how to fix that... is entry.desktop not an upstream file?
[17:27] <Riddell> ArneGoetje: yes but it shouldn't be hard to create one, it's just [KCM Locale]\nname=Whatever
[17:27] <Riddell> ArneGoetje: well, fix what?  the location of the file must be decided somewhere in the language pack scripts
[17:28] <Riddell> ArneGoetje: and the existance of the file for languages we have but which aren't upstream as I say shouldn't be hard to fix
[17:28] <ArneGoetje> Riddell: does this only affect languages which don't exist in upstreram?
[17:29] <Riddell> ArneGoetje: does which, we have two related issues :)
[17:29] <ArneGoetje> Riddell: ?
[17:29] <Riddell> ArneGoetje: 1) location of file is wrong for en_GB and possibly others
[17:29] <Riddell> 2) no file for languages we add, like the all important en_CA
[17:30] <ArneGoetje> Riddell: well, that loks like a bug in the export script from rossetta then... no?
[17:32] <Riddell> ArneGoetje: you tell me, it's your area :)
[17:32] <ArneGoetje> Riddell: (I don't really know when that file is generated, I hear from its existence for the first time now.
[17:32] <Riddell> ArneGoetje: don't you have access to the scripts that makes the language packs?
[17:33] <ArneGoetje> Riddell: I do have access to those scripts which do the final packaging, yes.
[17:34] <Riddell> ArneGoetje: does grep show up anything?
[17:34] <Riddell> ArneGoetje: are they public somewhere?
[17:35] <ArneGoetje> Riddell: I'm searching...
[17:37] <ArneGoetje> Riddell: seems I need to ask pitti and jtv about those...
[17:39] <Riddell> ArneGoetje: ok, I expect pitti knows all, he usually does :)
[17:39] <ArneGoetje> Riddell: the wrong locations seems to be a bug in langpack-o-matic... they are in the extra-files/kde-$lang.tar tarballs. But I have no idea where those tarballs come from...
[17:40] <Riddell> ArneGoetje: probably unrelated question.  in locale terms what does en@quot and en@boldquot mean?
[17:40] <ArneGoetje> Riddell: no idea. ask the guy who made it. :P
[17:41] <ArneGoetje> Riddell: @ just denotes a variant. Means something is different from the default 'en'. What exactly is different can only be found out by looking into the locale file itself.
[17:54] <glade88> hi.. I recently had multiple X crashes with Kubuntu Intrepid
[17:54] <glade88> X kept restarting until I did a hard reboot
[18:01] <Zen_Clar`> How can I find the changes made to a program by the Ubuntu guys?
[18:02] <dholbach> Zen_Clar`: zless /usr/share/doc/<package>/changelog.Debian.gz
[18:02] <Zen_Clar`> Thanks.
[18:19] <liw> evand, or someone else who might know: when usb-creator creates the usb stick, does it put grub on it?
[19:18] <evand> liw: syslinux
[19:19] <liw> evand, yeah, found that out later... I had some trouble getting a usb-creator created stick to boot, but I got it to work now
[19:19] <liw> evand, looking at 274076, by the way
[19:20] <liw> evand, I am seeing /dev/sdc1 (the usb stick; sda and sdb are SATA hard disks) mounted twice inside initramfs, this is probably a problem
[19:25] <evand> liw: indeed, I poked at that a bit but didn't get anywhere yet
[19:26] <liw> evand, I don't see evidence of double-mounting in the casper.log you attached to the bug report, though
[19:26] <evand> hrm
[19:26] <liw> evand, but there is a bind mount (which is conspicuosly missing from me): would that be enough to prevent a re-mount?
[19:26] <emgent> evening
[19:27] <evand> liw: If it's double mounted, I am pretty sure.
[19:28] <liw> evand, I tested: a bind mount does not prevent re-mounting
[19:28] <evand> ah, hrm
[19:29] <liw> double-mounting the same filesystem is surely an error, so my test is probably irrelevant for the original bug
[19:30]  * liw reboots the desktop
[19:33] <liw> evand, I need to leave now, but I'm subscribed to the bug, and would be happy to help when I'm back
[19:35] <evand> liw: much appreciated.  I'll give it another look over this afternoon after I'm done with ubiquity/grub work.
[19:36] <evand> anyone else running amd64 experiencing constant flashplugin-nonfree crashes?
[19:37] <zul> i get sound cutting in and out sometimes
[19:56] <psypointer> hi
[19:56] <psypointer> will there be a bugfix for https://bugs.launchpad.net/ubuntu/+bug/181221 in hardy?
[19:56] <psypointer> (it also crashs in mozilla)
[20:01] <Riddell> psypointer: flash is provided by adobe not us
[20:02] <psypointer> Riddell: yep, i know. but it seems to be a nspluginwrapper issue - on other platforms the flashplayer works ..
[20:02] <Riddell> if it crashes in mozilla, it's not an nspluginwrapper issue
[20:04] <psypointer> oh.. damn. it doesn't crash in mozilla. i'm sorr
[20:04] <psypointer> y
[21:07] <alkisg> In an acer aspire 5920g laptop, some keys worked in hardy but do not work in intrepid. E.g. the brightness key does change the brightness but also echoes a "±"... I have both ubuntu versions installed, can I look for the differences somewhere and file a bug with a proposed fix?
[21:35] <philipp> hi
[21:35] <philipp> i encounter a strange issue with 8.10: i have a lot of segmentation fault errors.... software crashes very often....
[23:57] <kebomix>  i have problem while compress file in ZIP format , it give me this Error "An error occurred while adding files to the archive." , any one help me with that


[17:03] <pleia2> ok, we need summaries! http://bit.ly/vDkJyf
[17:03]  * pleia2 just sent the email out
[17:07]  * pleia2 off to run some errands
[18:50] <Silverlion> re
[18:52] <JoseeAntonioR> Silverlion: Huh?
[18:54] <MrChrisDruif> Sweet chili =P
[18:54] <Silverlion> MrChrisDruif, at least one language i know :D
[23:07] <pleia2> no summaries yet (except the couple I did), anyone have some time for them?
[23:12] <JoseeAntonioR> I'd like to, but I'm not so good at writing :(
[23:12]  * benonsoftware is free atm
[23:14] <pleia2> JoseeAntonioR: no worries, you do enough already :)
[23:14] <pleia2> benonsoftware: http://bit.ly/vDkJyf is the link to the doc, if you could pop in and summaries even just a couple links it would be super helpful
[23:14] <benonsoftware> Okies
[23:15] <pleia2> summarize
[23:30] <benonsoftware> pleia2: You make writing the UWN a piece of cake!
[23:31] <pleia2> I try :)


[00:43] <nacc> rbasak: i'm thinkning i need to rethink the quiltify and changelogify logic, so feel free to pause that review
[05:28] <cpaelzer> good morning
[07:33] <vinayus> hi guys i have an issue while deploying ubuntu-server via preseed.. same preseed file works fine with ubuntu-server-16.04.2 iso image but not with 16.04.3.. basically all i am trying is to automate postgres server installation.. can anyone help?
[07:33] <vinayus> https://pastebin.com/xDpViuaw
[07:33] <vinayus> https://i.stack.imgur.com/xLvLl.png
[07:34] <vinayus> above links are preseed file and the image.. i would really appreciate if anyone can help me with this.. issue is also seen on daily release builds as well..
[07:38] <vinayus> and to note, these installations are attempted on an isolated environment where connection to internet is not there..
[08:51] <cpaelzer> jamespage: hi, can you see the effects of bug 1720887 or do I have to wait for cnewcomer / freyes to be around to check?
[08:57] <RoyK> hi all. how can I check when bareos first came in to the ubuntu repos?
[09:00] <ikonia> RoyK: packages.ubuntu.com
[09:00] <ikonia> RoyK: it will show you the first time it was in the repos
[09:00] <oerheks> RoyK, launchpad > https://packages.ubuntu.com/search?keywords=bareos  i think Xenial 16.04
[09:00] <RoyK> danke
[09:03] <oerheks> the 1st build support is way back, 8.04 https://github.com/bareos/bareos/tree/master/platforms/ubuntu
[09:04] <RoyK> sure - I was just wondering about when it came in officially
[09:04] <RoyK> I still think it lacks lz4, though, unless newer bareos uses the normal libs
[09:19] <RoyK> hm… it's a bit annoying that libfastlz isn't in the repos
[09:19] <RoyK> why was this again? Bareos uses it for lz4
[09:44] <Jenshae> o7
[09:51] <jamespage> cpaelzer: no I've not directly seen that so we'll need freyes
[09:54] <Jenshae> Is ppa:xorg-edgers known and considered to be safe?
[09:56] <Jenshae> wiki.ubuntu.com/XorgOnTheEdge same thing?
[09:57] <oerheks> i would recommend https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa for testing
[09:58] <Jenshae> Context: Someone managed to yank on a cable so hard that they broke a graphics card port and since all the staff use dual monitor setups, I tossed the Nvidia GeForce 9500 into the archive server I am making. (Will it assist when running virtual machines that do have graphics processing?)
[09:58] <Jenshae> Thank you oerheks I would prefer just a stable driver if possible?
[09:59] <oerheks> yes, for that card i would use the regular drivers in our repos
[09:59] <Jenshae> www.binarytides.com/install-nvidia-drivers-ubuntu-14-04/ is that guide I am following but I was unfamiliar with the PPA they direct me toward.
[09:59] <oerheks> broken port.. we cannot tell you if that affects the use of the card
[10:00] <Jenshae> I think it is just physical damage to the pins.
[10:00] <Jenshae> The card itself seems fine.
[10:01] <oerheks> well, worth a try
[10:01] <Jenshae> I was fiddling with a program that wanted a library, which is found in mesa, so I "updated" the graphics and lost them completely. I forgot it is not longer Intel / AMD and is now Nvidia.
[10:02] <Jenshae> SSH is still working praise the Nix gods!  ;D
[10:05] <Jenshae> Thanks oerheks I didn't even think you would have default repositories for Nvidia. Good stuff.
[10:24] <joelio> RoyK: submit a ITP then?
[11:32] <Jenshae> On the bright side, the graphics are working now, however, getting a lot of message on boot along these lines now, "[FAILED] Failed to start Login Service ... "
[11:34] <Jenshae> ... and ssh now has, "Connection refused."
[11:34] <Jenshae> Is it possible to make a live USB of ubuntu-server?
[11:36] <Jenshae> Seems to have died, hardware is on, disk activity dropped off and screen went blank. Not entirely frozen because the NumLock is going on and off.
[11:44] <Jenshae> Hard reboot has worked for some reason.
[11:46] <Jenshae> I noticed it loaded SMB/CIFS, that is the protocol that was also vulnerable to WannaCry, right? How about the new one, Anubi, is it safe from that one?
[12:09] <lordievader> Good afternoon
[12:52] <freakyy> 18.04 will be the next LTS right? ;D
[12:52] <freakyy> that's cool ;D
[12:53] <freakyy> im running 17.10 right now
[12:53] <freakyy> oh well but not on the server nm ;D
[12:53] <freakyy> on my server i run 16.04 ;D
[12:54] <lordievader> !lts
[12:54] <lordievader> Right, even years. So yes, next is 18.04, then 20.04, etc.
[13:03] <Jenshae> Salutations lordie :)
[13:06] <Jenshae> iostat seems to be weird. Why is the raid volume on a lower kB_read/s than the physical drives?
[13:07] <lordievader> Caching, probably.
[14:44] <mnaser> jamespage coreycb - have you done any recent changes to the neutron packaging?  puppet openstack integration jobs are failing -- http://logs.openstack.org/08/511708/2/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ab9e376/logs/neutron/neutron-l3-agent.txt.gz#_2017-10-17_11_29_13_858 (alongside a timeout assigning floating ip to port)
[14:48] <coreycb> mnaser: what release is that?
[14:49] <mnaser> coreycb pike -- http://logs.openstack.org/08/511708/2/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ab9e376/logs/dpkg-l.txt.gz
[14:51] <coreycb> mnaser: that's pike-updates (vs pike-proposed) so you should be running with the same versions we released when upstream pike released.
[14:52] <mnaser> coreycb could it be an unrelated packages that broke things (maybe ovs, kernel?)
[14:52] <mnaser> because things were working okay until a week ago where we started noticing that failure
[14:57] <coreycb> mnaser: do you run with the default xenial kernel?
[14:57] <coreycb> mnaser: arp seems to be having issues in your log
[14:59] <mnaser> coreycb the booted kernel is 4.4.0-97-generic
[14:59] <mnaser> which seems to be the latest
[15:13] <coreycb> mnaser: ok i'm deploying xenial-pike and running tempest against it on my end now. i'll double check the kernel version matches.
[15:22] <mnaser> thanks coreycb
[15:52] <Jenshae> I just went through typing "logout" on all the ttys and hit ctrl+alt+F7, discovered there is a graphical login!?
[15:52] <Jenshae> It won't start a session. What is it?
[16:25] <teward> dpb1: sorry for nonresponse earlier.  Got stuck with no Internet because Comcast decided to do 'maintenance'
[16:25] <teward> that schedule *should* be fine, I'll triple check and get back to you.
[16:26] <dpb1> teward: thanks!
[17:10] <mnaser> coreycb sorry to bug you, any update on your side?
[17:11] <coreycb> mnaser: good timing, tests finished.
[17:11]  * mnaser ducks from window behind you :p
[17:11] <coreycb> mnaser: i didn't hit any issues running tempest smoke against a xenial-pike deployment
[17:11] <coreycb> mnaser: confirmed too that the kernel is at 4.4.0-97-generic
[17:12] <mnaser> the failing test is: tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON -- not sure if smoke runs it
[17:12] <mnaser> but it's consistently failing
[17:12] <mnaser> coreycb deployed with ovs?
[17:12] <coreycb> mnaser: yes
[17:13] <mnaser> https://github.com/openstack/puppet-openstack-integration -- scenario001 is failing, rest are all passing
[17:35] <coreycb> mnaser: i don't know if this is related but worth sharing: https://ihrachyshka.com/2017/05/17/gratuitous-arp-for-openstack-neutron/
[17:35] <coreycb> mnaser: search for "bind: Cannot assign requested address"
[17:35] <coreycb> mnaser: are you using router HA?
[17:36] <mnaser> coreycb ran into that exact article but didnt get a chance to start reading the whole thing yet.. will take sometime today.  it is possible we are, i'll have to check the manifests.  but the same manifest works in centos 7
[17:36] <mnaser> https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/neutron.pp
[17:41] <coreycb> mnaser: there's this too https://bugs.launchpad.net/neutron/+bug/1717302
[17:43] <mnaser> oh thats very recent and interesting coreycb
[22:16] <nacc> rbasak: ok, I just force pushed my branch up that seems to work
[22:16] <nacc> rbasak: we'll see if it can pass jenkins