[04:36] <memguy> ok so i insmod every single oss .ko module i could http://pastebin.com/VsiPgkWJ   then i created the dsp  device file major 14 minor 3 character device then tried to uses it nothing said  No such device or address
[04:38] <memguy> How does the /dev/dsp module get associated with the oss modules  from the lsmod seems like everything depends on osscore but not sure on why the device file is not working would have thought one of the LKM would register /uses /dev/dsp i mean what creates this or links this to usable device file
[04:41] <mjg59> memguy: Why are you trying to use the oss drivers?
[04:41] <memguy> I know i may have installed the modules in the incorrect order or didn't pass parameters so maybe thats the issue. in dmesg i do have a lot of
[04:41] <memguy> oss_ali5455: Unknown symbol ac97_spdifout_ctl (err 0)
[04:42] <mjg59> If all you want is /dev/dsp, then use alsa and load the OSS compatibilty module
[04:42] <memguy> ...etc so maybe its those issue... though i am spining my head on what modules and what parameters to uses with this audio hardware 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
[04:42] <memguy> I just want to uses the old oss as opposed to the alsa stuff for right now
[04:43] <mjg59> If the alsa driver is loaded then OSS won't be able to bind
[04:47] <memguy> well this kind of sucks i am trying to remove the alsa module or all the snd.* LKM but i get Module snd is in uses
[04:48] <memguy> humm so first off how does one locate dependencies or process currently using an LKM  so i can terminate these resources so i can modprobe -r snd.* all away
[04:50] <memguy> Thats my first issue my second issue is what .ko to load to get oss sound working  mjg59 you mentioned using the alsa loading the oss compatiblity module what name would that be for the .ko what location
[04:53] <memguy> ya kind of sucks seems if i kill pulseaudio or hd-audio it just recreates the process something so those are not the root process
[04:53] <memguy> so i am kind of stuck not able to unload these lkm's and not able to kill the sound audio process that probably uses these LKM
[04:58] <mjg59> memguy: load snd_pcm_oss
[04:58] <mjg59> That'll give you /dev/dsp
[04:59] <memguy> where would that .ko file be located /lib/modules/???
[05:00] <mjg59> Why?
[05:00] <memguy> doing a find for it gave me nothing
[05:00] <mjg59> Just do modprobe snd_pcm_oss
[05:00] <memguy> modprobe: FATAL: Module snd_pcm_oss not found.
[05:01] <mjg59> Oh hm. I haven't actually checked whether that's still built.
[05:02] <memguy> either way my more general issue is how to uninstall all the snd LKM's rmmod with out getting dependency issues or module in uses
[05:02] <mjg59> Try installing osspd instead? That uses CUSE to emulate /dev/dsp
[05:03] <memguy> ya i will give that a try some time but really rather then using some software  character driver analogy to FUSE .. i want to understand how to load and unload the different sound modules properly from scratch
[05:04] <ohsix> why?
[05:05] <memguy> because to me understanding how to load and unload proper lkm's for devices you have more control in the end of troubleshooting and getting hardware to work
[05:05] <ohsix> that doesn't follow but OK
[05:05] <memguy> Plus to me this is the missing piece in understanding what creates the /dev/dsp what LKM's and how they are associated to an LKM the device files them selfs
[05:07] <memguy> Ideally i would have like to uninstall /rmmod/modprobe -r all the snd.* modules i had from lsmod ... then  go to the oss .ko and insmod/ modprobe them to create the /dev/dsp ...etc devices
[05:08] <memguy> And the other important thing to understand would have been how to trace down what is holding some LKM from not unloading
[05:10] <memguy> any help would be great on the uninstalling in use modules how one can remedy this
[05:37] <memguy> so i guess if rmmod -f doesn't work because kernel wasn't compiled with the ability to force modules to unload then one would have  to track down all dependencies by hand and kill those... and if there is circular dependencies then  the only way i can see it is a reboot with blacklisting
[05:46] <memguy>   483 ?        00:00:00 pulseaudio
[05:46] <memguy>  1442 ?        00:00:00 hd-audio0
[05:46] <memguy>   387 ?        00:00:00 indicator-sound
[05:46] <memguy> does anybody know how to kill these process because they get like recreated
[05:47] <memguy> and i am thinking that these are part of my problem of not being able to rmmod -f the snd.* LKM
[06:15] <memguy> ok well i got it down to  1442 ?        00:00:00 hd-audio0
[06:15] <memguy>   removing pulseaudio because it auto regenerates so trying to figure out this last one
[06:40] <memguy> never mind figured it out  after i removed rmmod -f  in the correct order from 0 dependencies onward i finally was able to remove all the snd.* based modules which when i looked took care of the ps 1442 process. Which this all was held up by pulseaudio being installed. I am curious of one thing when i relooked at /dev/snd all the devices pretty much disappeared but i am left with seq and  timer so curious maybe there is still
[06:40] <memguy>  an LKM that is for audio just not named snd.* that i am missing?
[06:40] <memguy> Or why are these 2 devices left behind
[08:42] <apw> memguy, or that is from something which is built in
[10:47] <ricotz> apw, hi, isnt that essential for the 4.7 mainline builds? https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=a3b42405327c946274fe8ee0e737a27b396ce7bf
[10:48] <apw> ricotz, i am not sure what you are asking
[10:49] <ricotz> apw, I have a "missing-symbols" problem of nvidia dkms module with the 4.7 mainline kernel
[10:49] <apw> ricotz, with which one
[10:50] <apw> ricotz, these are only debug builds, they not intended for long term use
[10:50] <ricotz> apw, sorry, currently can't say with exact symbol it was
[10:51] <apw> ricotz, no which version of the mainline build ... as they are built with whatever tim applies
[10:51] <apw> so any which are newer than when he applied that will have that
[10:51] <ricotz> 4.7rc4 worked, none after that
[10:51] <apw> ricotz, which is the latest you have tried
[10:51] <ricotz> rc6
[10:52] <apw> -rc7 built at 5 UTC this morning which would have been after so it should be "fixed" if that is your issue
[10:52] <ricotz> the initrd size shrunk by over 1MB with it
[10:52] <apw> symbol tables are big
[10:53] <ricotz> -rw-r--r--  1 root root 45060130 Jul 11 12:29 initrd.img-4.6.0-8-generic
[10:53] <ricotz> -rw-r--r--  1 root root 43939988 Jul 11 12:28 initrd.img-4.7.0-040700rc6-generic
[10:54] <apw> so i guess test -rc7 if that resolves the issue, then it may be worth rebuilding 5 and 6
[10:56] <ricotz> will reinstall rc4/rc5 in a bit
[10:58]  * apw is confused, but will let you report whatever you do
[10:59] <ricotz> I just want to double check the old kernels and having the dkms module with the current toolchain
[11:04] <ricotz> apw, btw, the rc7 build doesnt include the mentioned commit
[11:04] <apw> ricotz, it wouldn't need to include a commit
[11:04] <apw> ricotz, the changelog is dropped in wholesale
[11:06] <ricotz> ok
[11:21] <ricotz> apw, https://paste.debian.net/plain/780375
[11:21] <apw> ricotz, with which version
[11:22] <ricotz> seems rc7 is more complete compared to rc5/rc6 and grepping the Symbols.map listings matches the rc4 one
[11:23] <ricotz> 367.27
[11:23] <ricotz> this was from a log of rc5
[11:24] <ricotz> e.g. "grep -r _smp_call_function$ System.map-*"
[11:38] <ricotz> apw, looks like the rc7 build works again with nvidia here
[11:38] <apw> ricotz, ack
[11:40] <ricotz> apw, was this a known issue with those missing symbols like  *_smp_call_function ?
[11:41] <apw> ricotz, upstream added an option to remove redundant exports from the symbol tables to save space, this broke out of tree modules using any of them
[11:47] <ricotz> ok
[16:23] <rtg> dannf, I think the only kernels we're accepting patches for are P,T,LTS-U,X, and Y. V and W are now EOL. kamal - correct me if I'm wrong.
[16:24] <dannf> rtg: yeah, already sync'd with kamal - W is EOL, but V isn't for some reason
[16:24] <rtg> dannf, ack
[16:24] <kamal> rtg, the ones that just went EOL are   LTS-U and W   (V is still alive)
[16:24] <rtg> kamal, ack
[18:26] <memguy> is /dev/pcm0,1,2 and /dev/pcmin0,1 the oss device files for speakers/lineout and mic/line in if so how do you know which device file is associated to which device without trial and error
[18:31] <memguy> O never mind ossinfo tells me everything i need to know except i still don't get what /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0 devices is for is this some kind of digital in/out port or something
[18:34] <memguy> i imagine
[18:48] <memguy> SPDIF seems as it for an output port also digital but never used it of all the other port i think this and midi are the ones i never used


[05:17] <mardy> mborzecki: hi! Where is the source code that you are using for testing the library symbols in https://github.com/snapcore/snapd/pull/10540?
[05:17] <mup> PR #10540: cmd/snap-confine: handle CURRENT_TAGS on systems that support it <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10540>
[05:18] <mborzecki> mardy: https://paste.ubuntu.com/p/stbjYyJSSf/ this is the code I was using, `gcc main.c $(pkg-config --cflags --libs libudev)`
[05:23] <mardy> would using dlsym(RTLD_DEFAULT, "udev_device_has_current_tag") change anything?
[05:59] <mborzecki> mardy: that would be like the first version i proposed, just without dlopen()
[05:59] <mborzecki> the idea behind using a weak symbol was that we would not have to do any of that explicitly
[06:03] <mardy> mborzecki: well, it's just a function call :-)
[06:04] <mardy> I guess it should be pretty fast, since it doesn't have to load anything
[06:09] <mborzecki> mardy: yeah, though i'd like ld.so to do the heavy lifting for us, since it's already doing this anyway :)
[06:13] <pstolowski> morning
[06:23] <mborzecki> pstolowski: hey
[06:26] <mborzecki> mardy: i'm wondering if there's maybe some additional attribute needed to make it work with a binary built on 16.04
[06:44] <jamesh> mardy: I've provided some feedback on https://github.com/snapcore/snapd/pull/10628
[06:44] <mup> PR #10628: usersession/xdgopenproxy: move PortalLauncher class to own package <Created by mardy> <https://github.com/snapcore/snapd/pull/10628>
[08:02] <mup> PR snapd#10631 opened: cmd/libsnap-confine-private: fix issues identified by coverity <Needs security review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10631>
[08:21] <zyga-mbp> mborzecki +1
[08:22] <zyga-mbp> mwhudson are you planing to promote go 1.17 to latest/stable?
[09:33] <pstolowski> mborzecki: can you take a look at https://github.com/snapcore/snapd/pull/10528 , should be relatively simple
[09:33] <mup> PR #10528: o/hookstate: allow snapctl refresh --proceed from snaps <Needs Samuele review> <Refresh control> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10528>
[09:52] <mup> PR snapd#10632 opened: spread: temporarily fix the ownership of /home/ubuntu/.ssh on 21.10 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10632>
[09:52] <mup> PR snapd#10633 opened: tests: spread test for snapctl refresh --pending/--proceed from the snap <Refresh control> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10633>
[09:55] <mwhudson> zyga-mbp: i do that on .1
[10:00] <zyga-mbp> ah, I see
[10:00] <zyga-mbp> thank you :)
[10:10]  * pstolowski lunch
[10:52] <mup> PR snapd#10634 opened: many: move to go modules gradeually  <Created by mvo5> <https://github.com/snapcore/snapd/pull/10634>
[11:02] <mvo> woah, is it just me or if GH showing a merge button even if required tests did *not* run?
[11:02] <mup> PR snapd#10631 closed: cmd/libsnap-confine-private: fix issues identified by coverity <Needs security review> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10631>
[11:05] <mvo> aha, nevermind, looked at the wrong PR, all good
[11:29] <mardy> mborzecki: the reason for your suggestion, is it code readability, or is there something else? https://github.com/snapcore/snapd/pull/10623#pullrequestreview-731865699
[11:29] <mup> PR #10623: usersession/agent: refactor common JSON validation into own function <Created by mardy> <https://github.com/snapcore/snapd/pull/10623>
[11:29] <mborzecki> mardy: just readability
[11:30] <mardy> mborzecki: thanks, applied
[12:33] <mup> PR snapd#10528 closed: o/hookstate: allow snapctl refresh --proceed from snaps <Needs Samuele review> <Refresh control> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/10528>
[12:48] <mup> PR snapd#10635 opened: tests: update systems for sru validation <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10635>
[13:43] <mup> PR snapd#10622 closed: many: merge release/2.51 change to release/2.52 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10622>
[13:58] <mup> PR snapd#10623 closed: usersession/agent: refactor common JSON validation into own function <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/10623>
[14:53] <mup> PR snapd#10636 opened: interfaces, o/snapstate: introduce DisruptiveForPlugOnRefresh flag <Needs Samuele review> <Refresh control> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10636>
[15:08] <mardy> it would be nice if https://github.com/snapcore/snapd/pull/8926 got another review from more experienced team members :-)
[15:08] <mup> PR #8926: interfaces: add microstack-support interface <:birthday:> <Needs security review> <Created by dshcherb> <https://github.com/snapcore/snapd/pull/8926>
[15:19] <ijohnson[m]> mardy: it's on my queue, haven't gotten it to it yet though
[16:23] <mup> PR snapd#10594 closed: bootloader: fix double extract of the kernel assets <⛔ Blocked> <Needs Samuele review> <Run nested> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/10594>
[16:23] <mup> PR snapd#10611 closed: gadget,secboot: add support to specify KDF options in the gadget <⛔ Blocked> <:rocket: bootspeed> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/10611>
[18:19] <mup> PR snapd#10637 opened: tests: remove the test user just when it was installed on create-user-2 test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10637>
[19:24] <mup> PR snapd#10638 opened: tests: stop the service when is active in test interfaces-firewall-control test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10638>
[19:29] <mup> PR snapd#10639 opened: vendor.c: new vendor.c subdir <Created by mvo5> <https://github.com/snapcore/snapd/pull/10639>
[20:45]  * cachio_ afk


[03:39] <psusi> is it an error to try to use gtk code in a thread you create with pthread_create()?  isn't there some thread local initialization that needs done so you should use g_thread_new?
[03:40] <RAOF> psusi: I don't *believe* so, but you obviously need to take the necessary locks.
[03:41] <psusi> what locks?
[03:41] <RAOF> The gdk lock.
[03:41] <psusi> what's that?
[03:41] <RAOF> It's an error to call (almost?) any gtk function without the lock held.
[03:41] <psusi> I got this: [xcb] Unknown request in queue while dequeuing
[03:41] <psusi> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[03:42] <RAOF> http://www.gtk.org/api/2.6/gdk/gdk-Threads.html
[03:42] <psusi> holy shit, you're kidding?
[03:42] <RAOF> Specifically - gdk_threads_enter() and gdk_threads_leave()
[03:43] <RAOF> Oh, yeah.  You'll need to tell gtk to actually initialise the XCB threads, too :)
[03:43] <psusi> how do you do that?  is that done automatically by g_thread_new?
[03:43] <RAOF> "As always, you must also surround any calls to GTK+ not made within a signal handler with a gdk_threads_enter()/gdk_threads_leave() pair. "
[03:44] <RAOF> "You must call g_thread_init() and gdk_threads_init() before executing any other GTK+ or GDK functions in a threaded GTK+ program. "
[03:44] <RAOF> Threading and GTK is a bit of a minefield.
[03:45] <psusi> so you can't have two threads running their own message loop in parallel with gtk?
[03:45] <psusi> it sounds like it
[03:46] <RAOF> You mean, have two different gtk mainloops running on different threads?
[03:46] <psusi> yea
[03:47] <psusi> each thread controlling its own window
[03:47] <RAOF> I don't think so; there's no context for any of the gtk calls.  How would you distinguish which mainloop to dispatch to?
[03:47] <psusi> X takes care of that
[03:47] <psusi> the message goes into the queue for the window that corresponds to the thread... thread picks up message, dispatches, etc
[03:48] <RAOF> I'm pretty sure there are gtk calls that aren't associated with a Window; how would they be dispatched?
[03:48] <psusi> as long as you don't try to bounce the window back and forth between threads, it should be fairly straight forward... it was in windows
[03:49] <psusi> well if they don't have anything to do with a window, then they shouldn't be using the message queue should they?
[03:50] <RAOF> Why not?  The mainloop's not just for X message processing.
[03:51] <psusi> well, how does i tknow what message queue to use then?  it has to find a queue somehow
[03:51] <RAOF> It uses the default, singleton, gtk glib mainloop.
[03:52] <psusi> and there's only one?  there should be one per thread
[03:52] <RAOF> You *can* create other glib mainloops, but as far as I'm aware there's exactly one gtk mainloop.
[03:52] <psusi> in windows, every thread has its own message queue/loop
[03:52] <RAOF> No, there's definitely not one per thread.
[03:53] <psusi> ohh, yea, there's only one initially, sure
[03:53] <psusi> but if you want, you can make another one in another thread so it can run concurrently can't you?
[03:54]  * psusi is coasting mostly on 10 year old windows programming knowledge trying to debug gparted
[03:56] <RAOF> No; everything I see says "exactly one thread can call a GTK function at a time; protect calls with gdk_threads_enter/leave"
[04:00] <psusi> hrm... I guess that's the limitation of using a class toolkit... now that I think about it, I think MFC had the same problem
[04:00] <psusi> but I always just used straight winapi
[04:06] <RAOF> Yeah.  My memory is that Win32 didn't give you a general-purpose mainloop; you just got the window-system events there, and could(?) build a proper mainloop on that if you wanted.
[04:07] <RAOF> It's been *some time* since I played with win32, though.
[04:20] <psusi> so it's pretty much an error to pthread_create a background thread and have it emit a signal without any of that lock stuff right?
[04:21] <psusi> and basically if you want to make any blocking calls while handling events in the background thread, it's pointless since it would block while holding the gtk lock, thus preventing the other threads from doing gui things?
[04:33] <RAOF> Well, the background thread could emit a signal - it's ambiguous between gobject signals and posix signals, but I think either are fine - just not call any gtk functions without the lock.
[04:34] <broder> does gobject have an equivalent to qt's queued signals? i.e. wait until you hit the main loop and then handle this signal emission?
[04:34] <broder> it makes cross-thread signals in qt very easy to reason about
[04:34] <RAOF> g_idle_add would do it, roughly speaking.
[04:34] <broder> i guess you could take the lame way out and use g_idle_add
[04:35] <broder> :)
[04:35] <RAOF> Similarly, if you make all your blocking calls in the background thread you can happily rock along, taking the lock as appropriate when the background thread wants to signal completion.
[04:35]  * RAOF just notices that psusi has left :(
[04:40] <TiMiDo> lol
[08:14] <dholbach> good morning
[08:19] <micahg> udienz__: hi!, just wanted to point out you have a couple merges where you're the person who touched it last in universe
[09:08] <udienz__> micahg, yes, ~3 packages. gstm, clutter-gesture, and lighttpd
[19:06] <jtaylor> maybe we should remove argparse from precise?
[19:07] <jtaylor> the current debian version is py 2.6 only which would make all rdepends uninstallable I think
[19:07] <ScottK> Yes.  It should go now that Ubuntu is 2.7 only.
[19:08] <micahg> well, we still have python2.6 in precise
[19:08] <jtaylor> but it won't stay?
[19:08] <micahg> I don't think so, I've been meaning to ask about it
[19:09] <jtaylor> if we remove it we could let python2.7 provide argparse saving us the trouble of fixing the argparse rdepends
[19:09] <ScottK> micahg: It's still there, but it's not supported for module building.
[19:09] <ScottK> So argparse can go as it's pointless.
[19:09] <micahg> it still has a few rdepends, so it can't go yet
[19:10] <jtaylor> unless 2.7 provides it instead
[19:10] <jtaylor> (on the other hand I still hope the 2.6 only change will be reverted in debian)
[19:11] <micahg> jtaylor: I don't see a provides
[19:11] <jtaylor> not yet :)
[19:11] <jtaylor> 2.7 includes argparse so it could
[19:12] <ScottK> I think having 2.7 provide argparse makes sense.
[19:12] <ScottK> I'll defer to doko on that though.
[19:27]  * ajmitch thought the argparse situation was mostly sorted on the debian-python list
[19:28] <tumbleweed> it's different here, though
[19:28] <tumbleweed> debian has 2.6, we don't
[19:28] <tumbleweed> (well, it's in the archiv, but that doesn't count)
[19:29] <ajmitch> they haven't made 2.7 provide argparse then?
[19:29] <tumbleweed> no, that would have the wrong behavior in debian
[19:29] <tumbleweed> for $python in `pyversions -v`; do setup.py test; done <- that'd break if 2.7 provided argparse in debian
[19:29] <ajmitch> yes, it'd be a pain for a package to depend on python-argparse & pull in 2.7 instead
[19:30] <ajmitch> python is such a fun mess
[19:30]  * tumbleweed is busy playing with pypy, which adds an extra layer of fun
[19:30] <jtaylor> better than javascript though ._.
[19:30] <tumbleweed> I suppose I should send an e-mail saying what I've been doing...
[19:30] <ajmitch> jtaylor: that's a pretty low bar :)
[19:31] <jtaylor> < now has a package with javascript and python
[19:31] <jtaylor> pure joy
[19:31] <tumbleweed> is the javascript minified? :)
[19:31] <ajmitch> tumbleweed: it'd be interesting to read
[19:31] <jtaylor> yes and it has a nice .custom in the file name
[19:31] <ajmitch> oh, that one :)
[19:31] <jtaylor> so I have no idea if I can even use the packaged one
[19:32] <tumbleweed> use it, and wait for bug reports :P
[19:32] <ajmitch> since custom jqueryui can mean that a certain subset of it was chosen & minified
[19:33] <ajmitch> it was ipython that you were looking at, wasn't it?
[19:33] <jtaylor> yes
[19:33]  * tumbleweed doesn't want to know why ipython has javascript
[19:33]  * ajmitch is trying to come up with a good reason why it would
[19:34] <jtaylor> it now has a mathematica-like web interface
[19:34] <jtaylor> very nice, but I would not dare open that up beyond localhost :/
[19:34] <ajmitch> that makes so much sense to have...
[19:34] <jtaylor> it is very useful for data analysis
[19:34] <tumbleweed> really?
[19:35] <tumbleweed> what does it give you that a console doesn't?
[19:35] <jtaylor> you can edit the same cell again
[19:35] <jtaylor> so you end up with the end result instead of haviong to sieve through the history and removing the lines that did not work
[19:35] <tumbleweed> ah, bpythonish
[19:35] <ajmitch> from the look of screenshots on the website, it lets you have images in there?
[19:35] <jtaylor> yes
[19:36] <jtaylor> but qtconsole also had that feature already
[19:37] <micahg> jtaylor: there are only about a 18 or so rdepends of argparse, so quite doable to do away with it
[19:40] <micahg> jtaylor: if you get the handful of main rdeps fixed, it'll drop to universe and you can take it from there
[19:41]  * ajmitch is sort of glad that we probably won't be switching to php 5.4 for precise
[19:41] <tumbleweed> I assume it isn't as bad as 5.3 was?
[19:41] <ajmitch> tumbleweed: it's still php, so a real pain to test with
[19:41] <micahg> yeah, don't follow Debian into the take the PHP .0 release black hole
[19:42] <ajmitch> micahg: not really my call, I've got an RC in my PPA to test though, so it at least builds :)
[19:42] <jtaylor> micahg: k, if it will be removed I'll take care of universe
[19:42] <tumbleweed> well, it won't be removed unless we deal with the rdepends
[19:42] <micahg> jtaylor: well, I don't see it happening automatically, you probably want to have a conversation with doko, then drive it
[19:42] <tumbleweed> (or cpython starts providing it)
[19:49] <ajmitch> jtaylor: btw, I was told that the firefox developer tools will allow debugging minified javascript soon, so it may reduce your pain fractionally ;)
[19:49] <jtaylor> how will that work?
[19:50] <tumbleweed> as long as developers don't start giving that as an excuse for shipping minified js
[19:50] <ajmitch> no idea
[19:51] <ajmitch> http://www.infoq.com/news/2011/08/debug-languages-on-javascript-vm has some explanation of it
[19:52] <jtaylor> mh you need a mapping
[19:52] <jtaylor> so it will only work for upstreams that support it
[19:52] <bdrung> tumbleweed: can i release u-d-t 0.138?
[19:52] <ajmitch> yeah, not quite as useful as first thought
[19:53] <tumbleweed> bdrung: sure, it's pretty minor
[19:53] <tumbleweed> oh hang on
[19:53] <tumbleweed> I meant to look at the open debian bugs
[19:55] <bdrung> tumbleweed: do you want to fix lp 904288?
[19:55] <tumbleweed> bdrung: there was debian bug 652000, but that's about sticking it in /usr/local on squeeze...
[19:55] <tumbleweed> I should drop the severity of that...
[20:02] <tumbleweed> broder: any thoughts on debian bug 651546?
[20:03] <ScottK> tumbleweed: Invalid.  No such thing as a release socket.
[20:03] <ScottK> ;-)
[20:03] <ajmitch> ScottK: I'm sure one could be added to LP if you really want it
[20:03] <ScottK> No, because then it'd be a real bug and we dont' want that.
[20:03] <tumbleweed> heh
[20:04] <ScottK> Actually I think the bug report makes sense.
[20:04] <ScottK> I'd probably tag it help and say patches welcome though.
[20:04] <ajmitch> add another option to disable adding -backports to the release name?
[20:04] <tumbleweed> yeah, it's something that irritated me (I dput from debian where we can't use ppa:) but it's really trivial to edit the changes file
[20:05] <ajmitch> tumbleweed: does it still have -backports in debian/changelog, or just in the .changes file?
[20:05] <tumbleweed> ajmitch: yes, it only modifies .changes
[20:19] <EvilResistance> anyone know where i can find the precise dev team on irc?  someone asked a question in #kubuntu about a specific version of Qt, and would need the dev team to answer their question
[20:20] <tumbleweed> EvilResistance: "the precise dev team" ?
[20:20] <EvilResistance> tumbleweed:  generally speaking the people producing the alpha/beta versions of precise...
[20:20] <EvilResistance> if i may copy/paste a line or two into here...
[20:20] <tumbleweed> EvilResistance: that's pretty much all ubuntu developers
[20:21] <EvilResistance> are there any specific devs assigned to the kubuntu parts?
[20:21] <tumbleweed> yes, the kubuntu developers
[20:21] <EvilResistance> and they are... where :P
[20:21] <tumbleweed> #kubuntu-devel
[20:23] <EvilResistance> thanks
[20:23] <bdrung> tumbleweed: can you have a look and http://paste.ubuntu.com/777873/ and tell me what i do wrong?
[20:25] <bdrung> i found it
[20:44] <bdrung> tumbleweed: pushed
[20:49] <tumbleweed> bdrung: pushed
[20:49] <tumbleweed> eep, wrong bug
[20:51] <tumbleweed> I'm crazy tired, so please check that
[21:02] <broder> tumbleweed: not sure if there's a better option than a --pocket flag or something
[21:05] <tumbleweed> broder: I just committed http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1264
[21:06] <broder> tumbleweed: sure, lgtm
[21:10] <tumbleweed> bdrung: ok? https://bugs.staging.launchpad.net/ubuntu/+source/webkitkde/+bug/848916
[21:10] <tumbleweed> (ignore the content of that bug)
[21:12] <bdrung> tumbleweed: sponsored for me?
[21:12] <tumbleweed> sure, :)
[21:12] <bdrung> tumbleweed: would it be better to have it at the top (= more prominent)?
[21:13] <tumbleweed> yeah, it looks a bit silly there
[21:13] <bdrung> tumbleweed: pushed, please check
[21:16] <tumbleweed> seems ok
[21:18] <tumbleweed> that's prettier: https://bugs.staging.launchpad.net/ubuntu/+source/pygame/+bug/898062
[21:19] <bdrung> tumbleweed: lgtm
[21:20] <tumbleweed> committed it
[21:21] <tumbleweed> feel free to upload it, I'm off to bed
[21:28] <tumbleweed> we should send a mail to devel-announce about native sync sponsoring (and native syncing in general)...
[21:29] <tumbleweed> Laney: I assume you saw bigjools' UI component to native sync sponsoring? It just added an input box on +localpackagediffs, no indication of sponsorship anywhere yet...
[23:52] <broder> ScottK: is there a reason you didn't just sync python-pypcap yourself?
[23:53]  * micahg was kinda wondering the same thing


[11:16] <Aavar> How can I select line input (not micrphone) in arecord?
[11:22] <diogenes_> Aavar, why not in pavucontrol?
[11:25] <Aavar> diogenes_: I dont know. What is pavucontrol?
[11:26] <Aavar> diogenes_: I'm sorry, I asked this in the wrong channel. I don't use x11
[11:27] <diogenes_> happens
[11:27] <Aavar> :)
[12:30] <xubuntu80w> I am 85 and am running a new barebones NUC multi-boot with 6 linux OS's. XUBUNTU is my favorite and Xfce is my favorite desktop.  I have inquired here and at Xfce, but I guess I didn't watch closely enough for answers. Weeks have gone and I figured someone in the world would also wa
[12:30] <xubuntu80w> nt a left mouse, and the bug would get fixed. NOTHING. Now, there is a possibility that either Mr. Mouse or the NUC is fubar. If you can provide me with something it will be appreciated.
[12:39] <Unit193> I appear to have left option right in xfce4-mouse-settings..
[13:19] <Unit193> xubuntu54w/xubuntu80w: You asked about left handed mice, I see the option right in xfce4-mouse-settings for left handed ones both with a real mouse and trackpad.  On 4.12 and 4.13.
[13:21] <xubuntu80w> Unit193 right, but IT DOES NOT WORK!
[13:22] <Unit193> Just tried it now, my mouse is now funky and the buttons are reversed.
[13:23] <brainwash> I've seen a bug report for this issue
[13:23] <Unit193> I believe there's been some sort of issues if both synaptics and libinput are installed.
[13:24] <Unit193> ...Though I have xserver-xorg-input-libinput and xserver-xorg-input-synaptics so perhaps not.
[13:25] <brainwash> but only one is loaded and used
[13:27] <xubuntu54w> Thanks 193. this is happening to me on 3 Xfce's
[13:29] <xubuntu54w> Ku, U, and Mint seem to be OK
[13:30] <brainwash> which xubuntu release is that?
[13:42] <xubuntu80w> Thanks 193. and all of You. I can be reached at:  natboth@gmail.com


[02:30] <lotuspsychje> good morning
[05:51] <Maik> arraybolt3[m]: this is what users who enter #ubuntu get top see, no matter which irc client they use: https://paste.ubuntu.com/p/gSMWbvvBYN/
[05:52] <arraybolt3[m]> Maik: True. And in a perfect world, everyone would see that and know what was happening. But in my experience, IRC clients generally do one or more of three things that make it so that a user doesn't hardly ever see the topic.
[05:52] <arraybolt3[m]> For one, they color it grey, and all the other messages white, which communicates, "Background info, no need to read."
[05:53] <arraybolt3[m]> For two, they mix it in with various other server messages and arbitrary other junk so that the user thinks it's just part of the "safe to ignore" stuff.
[05:53] <arraybolt3[m]> For three, Matrix (the client I use) colors the topic light-grey, sticks it at the top of the screen when all the action occurs at the bottom of the screen (so you don't hardly notice it even exists), shrinks it so that you can't even see all of it on some screens, AND colors it light-grey.
[05:54] <arraybolt3[m]> (Wow, I must not like the light-grey thing, since I accidentally mentioned it twice in the last point LOL)
[05:55] <arraybolt3[m]> So for an experienced IRC user who already knows all of the quirks and whatnot of using IRC, scanning the junk section for the topic is easy. For someone who just stumbled across Konversation and is thinking, "Ooh, shiny, what's that?", intuition is going to lead them down the trail of topic-ignoring.
[05:57] <Maik> True, thanks for elaborating. I will keep that in mind. :)
[06:23] <jdmark> hello
[06:24] <lotuspsychje> welcome jdmark


[01:05] <cmaloney> mrgoodcat: We're still meeting at the Bean and Leaf
[12:23] <cmaloney> morning
[13:29] <rick_h_> morning
[13:33] <cmaloney> is it time for bed yet?
[13:34] <jrwren> lol. good morning
[13:35] <rick_h_> hmmm, not a bad idea
[13:48] <jrwren> woke up to NO HEAT. brr its cold in here.
[13:48] <cmaloney> ugh
[13:48]  * rick_h_ sends north some heat
[13:54] <mrgoodcat> rick_h_: somewhere warm?
[13:56] <rick_h_> mrgoodcat: Texas
[14:03] <cmaloney> Texas? What's there?
[14:03] <cmaloney> Besides the title of a Revolting Cocks album
[14:04] <rick_h_> customers! well potential ones at least
[14:04] <rick_h_> so dog and pony show day!
[14:04] <cmaloney> Woo woo
[14:04] <cmaloney> Hope you have some fun down there
[14:05] <cmaloney> And get more AT&Ts onboard. :)
[14:08] <cmaloney> Yay, AD password will expire every 90 days at work
[14:09] <cmaloney> FML
[14:09] <cmaloney> Requires at least one numeric, one Upper Case, one lower case, one special character, and one haiku praising Discordia
[14:10] <cmaloney> (Hail Eris)
[14:11] <jrwren> sticky note with password written on it stuck to monitor works.
[14:11] <cmaloney> Even better, I have to change this on a windows machine
[14:12] <cmaloney> which usually leads to my account being locked in some way because Microsoft hates me
[15:21] <jrwren> greg-g: hateful eight was so good, you may have made the wrong choice. ;]
[15:45] <greg-g> jrwren: another trusted source said it sucked: "it is reservoir dogs with more racism & fewer good monologues in a western setting"
[15:45] <jrwren> that is exactdly it
[15:46] <greg-g> heh
[15:46] <jrwren> and its shot better than reservoir dogs
[15:46] <jrwren> and the fewer monologues are better.
[15:46] <jrwren> and its shot beautifully.
[15:46] <jrwren> and i love that its reservoir dogs in a western setting.
[15:46] <greg-g> I might go see it then :)
[15:46] <jrwren> and its shot beautifully.
[15:46] <jrwren> hehehe.
[15:56] <cmaloney> And it's shot beautifully.
[15:57] <cmaloney> So I have heard
[15:58] <jrwren> :)
[21:12] <ColonelPanic001> *burp*
[21:18] <_stink_> you are disgraceful


[09:09] <Keybuk> *bounce*
[09:09] <AlexExtreme> hey
[09:09] <AlexExtreme> i'll test out 0.3.7 tomorrow hopefully
[09:09] <Keybuk> cool
[09:09] <Keybuk> I've not had any death threats yet, so it seems to be working
[09:09] <AlexExtreme> heh
[09:13] <Keybuk> already thinking what to put in the next version
[09:13] <Keybuk> think the big change will have to be re-implementing restart
[09:39] <_ion> keybuk: The resources idea sounds great.
[09:39] <Keybuk> difficult it is deciding which state it needs to stay in
[09:39] <Keybuk> start/waiting I gues
[09:40] <_ion> keybuk: It would be nice if a shell script could make the 'uses' information.
[09:41] <_ion> E.g. block-device-added could find out the actual physical device for any of /dev/sda1, /dev/mdsomething and /dev/lvm-volumegroup/something, and say 'uses $DISKNAME' based on that.
[09:42] <_ion> s/block-device-added/the fsck job/
[09:43] <Keybuk> why would the disk size make a difference?
[09:43] <_ion> Size?
[09:43] <Keybuk> oh
[09:43] <Keybuk> dunno where I read that
[09:43] <_ion> :-)
[09:45] <Keybuk> yeah, the problem there is you'd have to either include that in the event, or compute it in the jobs
[09:46] <Keybuk> I'm inclined to suggest the event is better there though, since it probably *has* that information in the first place
[09:47] <Keybuk> and it's cheaper than calculating it on every single job
[09:47] <_ion> Good point.
[09:47] <Keybuk> it's just DEVICE=$(readlink /sys$DEVPATH/device) after all
[09:52] <_ion> For LVM and MD, /sys/block/$foo/slaves seems to be the right way to find the physical device.
[09:53] <Keybuk> yeah, it'd be annoying to code all the different logic into the "check the filesystem" event
[09:53] <Keybuk> uh job
[09:53] <Keybuk> AND any other job that wants it
[09:53] <_ion> True.
[09:53] <Keybuk> much easier to handle it in the specific events
[09:53] <Md> be sure to check a > 2.6.20 kernel with the compat sysfs links disabled :-)
[09:53] <_ion> Oh, 'slaves' is deprecated?
[09:54] <Keybuk> no, device is going away
[09:54] <_ion> Ah
[09:54] <Keybuk> because /sys/block/hda itself is a symlink
[09:54] <Keybuk> like I said, much easier to put this into the event emission
[09:55] <Keybuk> Md: that hasn't happened yet though?
[09:55] <Md> what?
[09:56] <Keybuk> the move of block devices to under the physical device
[09:56] <Keybuk> (which means the device symlink is still necessary)
[09:57] <Md> I am not sure, I had to roll back because the 2.6.21rcsomething rawhide kernel broke resume from RAM on my system (any clue about how to debug this? the screen is not working, but I can reboot using magic sysrq)
[09:57] <Keybuk> 2.6.20 here, /block/hda is still a directory
[09:58] <Keybuk> that may be caused by the deprecated option though, looking at the code
[09:58] <Keybuk> might have to try turning it off and see what happens
[09:59] <AlexExtreme> wait
[09:59] <AlexExtreme> umm
[09:59] <AlexExtreme> wrong channel
[09:59] <AlexExtreme> sorry
[10:15] <cortana> dumb question, perhaps, but how stable are the contents of /sys?
[10:16] <Md> not much so far
[10:17] <Keybuk> about as stable as upstart's job definition syntax :p
[10:26] <_ion> Excuse my ignorance, but what's the correct way to find the corresponding /sys/block/... path for a file in /dev, e.g. sda*, md*, mapper/*? Comparing the contents of /sys/block/**/dev to the device types of the /dev files probably works, but there's a better way, isn't there?
[10:27] <Md> _ion: udevinfo -n I think
[10:28] <Keybuk> udevinfo -q path -n hda1
[10:28] <Keybuk> though you're not *really* supposed to use udevinfo as a database <g>
[10:29] <_ion> Thanks. Works for sda1 and md0, but not /dev/mapper/*.
[10:29] <Keybuk> did you try dm-0 as the name?
[10:29] <Md> _ion: because these are not managed by udev
[10:29] <Keybuk> udevinfo -q path -n dm-0
[10:29] <Keybuk> Md: they are in Ubuntu
[10:30] <_ion> "no record for 'dm-0' in database" (an Edgy box)
[10:32] <Keybuk> hmm
[10:32] <Keybuk> dunno how to make a devmapper device
[10:32] <Keybuk> dmsetup create foo just blocks
[10:33] <Keybuk> ah
[10:33] <Keybuk> wing-commander scott# udevinfo -q path -n mapper/foo
[10:33] <Keybuk> /block/dm-0
[10:39] <_ion> Funny, doesn't work here.
[10:48] <Keybuk> hmm
[10:48] <Keybuk> feisty?