[05:04] <jtatum> californians observing eastern time: happy new year
[08:00] <MarkDude> .•°*”˜˜”*°•.¸☆ ★ ☆¸.•°*”˜˜”*°•.¸☆
[08:00] <MarkDude> ╔╗╔╦══╦═╦═╦╗╔╗ ★ ★ ★
[08:00] <MarkDude> ║╚╝║══║═║═║╚╝║ ☆¸.•°*”˜˜”*°•.¸☆
[08:00] <MarkDude> ║╔╗║╔╗║╔╣╔╩╗╔╝ ★ NEW YEAR ☆ 2011
[08:00] <MarkDude> ╚╝╚╩╝╚╩╝╚╝═╚╝ ￥☆★☆★☆￥ ★☆
[08:01] <DarkwingDuck> Same to you too Mark
[08:01]  * MarkDude decided to stay home
[08:02] <MarkDude> Figured partying with some of the Destructoid crew might not be what I need
[08:02] <MarkDude> How are you doing? Do you have exploding stuff outside also?
[08:02] <DarkwingDuck> Oh yes.
[08:03] <DarkwingDuck> I set some crazy stuff off....
[08:03] <DarkwingDuck> I think the cops might show up because of my poppers
[08:03]  * MarkDude has a few marine flares and smoke cannisters
[08:03] <MarkDude> at someone elses house tho
[08:03] <DarkwingDuck> I made a couple of... noise makers that I learned in the Military
[08:04] <MarkDude> With a item that helps freeze stuff?
[08:04] <MarkDude> an item
[08:05] <DarkwingDuck> Naww...
[08:05] <DarkwingDuck> It's ahame brew
[08:05] <DarkwingDuck> *Home brew
[08:06] <MarkDude> Rain just started also
[08:06]  * MarkDude alwys liked lighting off stuff when the ground was a little damp
[08:06] <MarkDude> if not you need some fire inhibitor type thing of some sort
[08:07] <DarkwingDuck> :D
[08:08] <DarkwingDuck> We played around with some stuff in the service. it was mostly to startle
[08:19] <MarkDude> No doubt
[08:20] <MarkDude> I hear car alarms, no dogs tho
[18:09] <pleia2> the rain last night was great, it started on cue when the fireworks at ferry building ended
[18:10] <pleia2> happy new year everyone :)
[21:14] <jledbetter> Happy New year to you too pleia2
[21:15] <jledbetter> Dreary day. Bleh.
[22:21] <MarkDude> jledbetter, we have no snow
[22:26] <seidos> it's the best day ever!  *tries to levitate*


[14:08] <rick_h_> jrwren: it'll totally be open one day... *wink wink*
[15:21] <cmaloney> ?
[15:30] <rick_h_> cmaloney: replying to twitter
[15:31] <rick_h_> sometimes when I'm snarky I just drop it here vs publicly online lol
[15:33] <cmaloney> context is awesome. Let's do more of that. ;)
[15:34] <rick_h_> picky picky
[15:37] <cmaloney> That's me, picky picky
[16:12] <jrwren> oh, lol, even I missed the context on that one.
[16:12] <jrwren> I do like this as a non-public twitter back chat.
[16:14] <greg-g> oh, I should stop my auto-irc-to-twitter posting bot?
[16:16] <rick_h_> hah
[16:16] <rick_h_> my bad, too early in the morning I kicked off the IRC day in a bad way
[16:18] <cmaloney> Nah, that's fine
[16:18] <cmaloney> At least there's activity in the channel. That's a good thing. (TM)


[00:00] <Kano> but i dont get why newer kernels instantly crash with lenny
[00:04] <Kano> i do not compile anything,but atoms need really long to recompress
[00:08] <jjohansen> back on later
[03:22] <Logan_> Anybody here good with XHCI issues?  There's a bug that has "Fix released," but I find that I still need to use a workaround to fix suspending on my USB 3.0 laptop.
[04:29] <jjohansen> Logan_: update the bug with the information
[08:39] <smb> morning
[08:47] <apw> smb, moin
[08:47] <smb> apw, Got past the signals?
[08:48] <apw> smb, yeah about 20 mins sitting on the rail for nothing while they counted trains
[08:48]  * smb hopes "sitting on the rail" is different from "sitting on the rails"
[08:49] <smb> But yeah, some are very "secure"
[08:50] <smb> One here lets you wait quite long before anything happens. Then with another of those you got 5s between the barrier being down and the train being there.
[08:54] <apw> heh me too
[11:39]  * ppisati -> out for food
[11:43] <cking> download .ddebs -> need a faster pipe
[13:36] <ppisati> apw: btw, i tested the image used by Michael and it's working ok on my panda
[13:37] <ppisati> apw: so, faulty hw or a new hw revision
[13:39] <apw> ppisati, the oneiric one you mean ?
[13:40] <ppisati> apw: uhm... no, it was a natty iirc
[13:40] <ppisati> apw: but natty and oneiric omap4-wise are the same
[13:41] <apw> ppisati, well actually no at the moment oniric is behind natty (which it shouldn't be) ... i am looking at fixing that right now
[13:41] <ppisati> ah ok
[14:04] <apw> ppisati, yeah i am just testing a setup for it like mvl-dove
[14:18] <apw> tgardner, so we are starting to get excessive skew between natty and oneiric ti-ompa4.  as officially oneiric should be updated before we can SRU, but also becuase we know we are getting an update for Oneiric "shortly" i am proposing we do a mvl-dove style forward port to oneiric.   as an experiment i am looking to do it the same way we do fro the lucid bacports, ie with oneirici1 (no ~) on the end of the version
[14:18] <apw> tgardner, this is starting to skew testing in oneiric it seems
[14:19] <tgardner> apw, TI has promised to come up with a 2.6.39 kernel. we ought to ask Bryan where that is before we put too much effort into it.
[14:20] <cking> apw, ping
[14:20] <apw> tgardner, from waht i can tell, its a ways away, i think we can do this for very little effort, ie effectivly pass it to stable to handle -- once i have this tested.  so far i've spent just 10 mins on setting up an update-from-xxx style tree for it
[14:21] <apw> and its looking like it works ok
[14:21] <tgardner> apw, ok, but does it run on the HW ?
[14:21] <apw> ppisati, any idea how far out the .39 kernel is for ti ?
[14:22] <smoser> smb, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/614853 . user reporting that they're still seeing that issue with a kernel that should have been fixed
[14:22] <ubot2> Ubuntu bug 614853 in linux-ec2 "kernel panic divide error: 0000 [#1] SMP" [Medium,Fix released]
[14:22] <apw> tgardner, well that is part of the issue, there are compiler issues in the mix here, and unless we're building in the right series the testing is actually useless
[14:22] <tgardner> apw, well, yhou can build in the c-k-t PPA as a test
[14:23] <apw> tgardner, if the priinciple seems sound to you, then yes that is cirtainly the sensible next test step
[14:23] <ppisati> apw: that was yesterday topic and the answer is... unknown
[14:23] <tgardner> apw, if its not too much work then I'm fine with it
[14:23] <ppisati> apw: well, actually linaro has already a .39 kernel
[14:23] <apw> ppisati, your feel?  still at least weeks out ?
[14:24] <cking> apw, want to book those flights before matt closes for business?
[14:24] <apw> cking, yeah if there is a generall arival that saturday before then i guess so
[14:25] <tgardner> cking, apw: plumbers ?
[14:25] <cking> I will book mine and CC you and ask matt to book yours too
[14:25] <cking> tgardner, yep
[14:25] <cking> and pre-kernel sprint too
[14:25] <apw> tgardner, yeah kernel sprint ... what he said
[14:25] <tgardner> cking, ah, I have not encountered tha in my email yet
[14:25] <apw> tgardner, you can practically walk there :)
[14:25] <smb> smoser, Hm, both patches should be in that kernel. Need to check whether it is the exact same place
[14:25] <cking> dude, you need to keep up with your inbox  :-)
[14:25] <ppisati> apw: we won't get it for A2 unfortunately (end of month)
[14:25] <tgardner> apw, its a surprising pain in the ass for me to get there
[14:26] <smoser> smb, i'm commenting.
[14:26] <tgardner> cking, 6 days off produced over 700 emails. blech
[14:26] <ppisati> apw: jcrigby has a .39 linaro kernel
[14:26] <apw> ppisati, blimey ...
[14:26] <ppisati> apw: but that doesn't even boot on my board
[14:26] <apw> ppisati, and that is no good for our use ?
[14:26] <apw> BAH
[14:26] <ppisati> apw: actually i would like to get t ASAP
[14:26] <cking> tgardner, that's why I loathe taking a vacation ;-)
[14:27]  * apw goes away to VENT about how useless that makes the linaro kernel
[14:27] <tgardner> cking, I usually keep up while traveling, but wilderness rafting doesn't really lend itself to electronic communications.
[14:27] <smoser> smoser, commented. i think its user error, or at very least there is user error involved
[14:27]  * cking nods
[14:29] <smb> smoser, Wait... that trace is from -312 and the patch went into -313
[14:31] <smb> smoser, Ok, saw you commented the same...
[15:25] <sforshee> tgardner, could you accept my natty nomination on bug #767192 ?
[15:25] <ubot2> Launchpad bug 767192 in linux "Wireless flaky on Acer Aspire 5100 after installing Natty" [Medium,Fix released] https://launchpad.net/bugs/767192
[15:28] <tgardner> sforshee, done
[15:53] <ppisati> nuntio vobis gaudium magnun: it _seems_ we are going to get 3.0 for oneiric/ti-omap4 too
[15:54] <ppisati> but no ETA yet
[16:46] <sconklin> smb: Your email about the xenmotion and patch, is that a recommendation to publish it or to not publish it?
[16:46] <smb> sconklin, To publish. Actually there has been one verification by now
[16:46] <sconklin> or rather to verify or not to verify, upon which publishing will be decided
[16:47] <sconklin> ok, thanks!
[16:47] <sconklin> I'll nudge that along
[16:47] <smb> Cool thanks
[17:36] <smoser> smb, do you have thoughts on bug 784937 ? I'd rather have hte kernel "fixed" than work around it.
[17:36] <ubot2> Launchpad bug 784937 in cloud-init "/mnt not mounted, swap not used, disk is xvde" [Medium,Confirmed] https://launchpad.net/bugs/784937
[17:37] <smb> smoser, The only thought currently is that I had not thought much about that one...
[17:37]  * smb looks
[17:37] <smoser> verified its still in Ubuntu 3.0-0.1-virtual 3.0.0-rc2
[17:39] <smb> smoser, Could this be something related to that unplug unnecessary thing? That it does not give you sda because it would be the same as xvda...
[17:40] <smb> And the other thing would be, why directly specifying devices, and not uuid or label?
[17:40] <smoser> i dont know. i suppose it could be.
[17:41] <smoser> well, 2 things lead me to care about a name
[17:41] <smoser> a.) xen is stupid, amazon followed xen's lead, and they allow a user to specify "--device" when they attach a volume.
[17:42] <smoser>   the expectation is that that device, will then be what appears in the guest
[17:43] <smoser> b.) in this init case (trying to mount swap), cloud-init is reading the metadata service for "swap", which says "sda2".  It then translates that to xvda2 if there is no sda2.
[17:43] <smoser> but i'd like to avoid more hacks and translations
[17:45] <smb> Ok, I can understand that. Hm, at least the start it odd at first glance... But need to read a bit more details...
[17:59]  * apw calls its a day ... have a good weekend all
[18:00] <smb> apw, same thing
[19:04] <highvoltage> howdy, is there a kernel parameter I could use to disable scsi emulation for usb mass storage devices?
[19:04] <jjohansen> sconklin: could you accept nomination for Bug#798860 and Bug#789409
[19:04] <sconklin> jjohansen: sure, stand by
[19:05] <highvoltage> (I have a sd card reader that shows up as sda on some laptops and it's messing with my d-i mojo since it's preseeded to install to sda)
[19:05] <sconklin> #798860 #789409
[19:05] <jjohansen> sconklin: thanks, you can ignore the accidental oneiric tick, sadly I can't delete nomination mistakes
[19:06] <sconklin> got the first one, there is no 789409
[19:07] <jjohansen> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/789409
[19:07] <ubot2> jjohansen: Error: <Bugtracker.plugin.Launchpad instance at 0x8d65a2c> bug 789409 not found
[19:07] <sconklin> doesn't look good
[19:07] <jjohansen> sconklin: there really is, I am looking at it the browser
[19:07] <charlie-tca> Is it private?
[19:08] <jjohansen> ah yes, but its not supposed to be
[19:08] <jjohansen> sconklin: try now
[19:09] <vish> hi, while building the kernel deb, i get a lot of questions (y/n) or (M/n)  … is it OK if I choose 'y' for all and 'M' when y is not available?
[19:09] <sconklin> jjohansen: all done, I went ahead and declined the Oneiric one so it wouldn't be hanging
[19:09] <jjohansen> vish: maybe, its usually safe to choose the default
[19:10] <jjohansen> sconklin: thanks
[19:10] <jjohansen> vish: if you just hit enter you get the default
[19:10] <vish> jjohansen: how do i know which is default?
[19:10] <vish> jjohansen: ah ok.. :)
[19:10] <jjohansen> vish: it will be the one that is capitalized
[19:10] <vish> thx..
[19:10] <jjohansen> highvoltage: none that I know of
[19:11] <vish> k..
[19:11] <highvoltage> jjohansen: ok thanks
[19:12] <sforshee> tgardner, for the rt2800 firmware updates I started on last week, I discovered that hardy lbm does not include the drivers. Are we no longer updating compat-wireless in hardy? Because if not there's no point in adding the firmware.
[19:14] <tgardner> sforshee, I don't think I ever bothered with Hardy compat-wireless. Lucid shold be sufficient;y old enough for CW backports
[19:16] <sforshee> tgardner, ack. I'll send out the pull requests for lucid and maverick shortly.
[19:23] <tgardner> sconklin, do we have a test victim for the USB 3.0 regression? it should be fixed in <IP_ADDRESS>, right?
[19:25] <sconklin> tgardner: I can't remember, but I think there may still be another patch required after .8. I haven't worried about it because we just reverted it all. We'll circle back after we get these releases out.
[19:27] <sconklin> tgardner: the last time I checked was a week or so ago and one of the fix patches wasn't even in Linus's tree yet
[19:28] <tgardner> sconklin, ok, I'll roll a <IP_ADDRESS> without the xhci patches
[19:40] <vish> check-config: FAIL: value CONFIG_SECURITY_YAMA y
[19:40] <vish> check-config: FAIL: value CONFIG_DEFAULT_SECURITY_APPARMOR y
[19:40] <vish> check-config: 26/28 checks passed -- exit 1
[19:40] <vish> make: *** [config-prepare-check-generic] Error 1
[19:40] <vish> while building i get that^ error; how do i fix that?
[19:40] <vish> building kernel*
[19:45] <vish> i could probably comment it out of /config/enforce , but Apparmor is required for security right?
[19:52] <jjohansen> vish: define required.  It is required for apparmor make, but you still have unix DAC without it
[19:52] <jjohansen> vish: what kernel are you building?  I assume upstream?
[19:53] <vish> jjohansen: required as in; "if i dont have it, bad men will take control of my system" :D
[19:53] <vish> jjohansen: maverick, trying to bisect between .35 and .34
[19:54] <jjohansen> vish: ah, if you are bisecting and debugging I wouldn't worry about yama, or apparmor, they are added near the end of the stack of commits so they will disappear
[19:55] <vish> jjohansen: ok, cool, thanks.. will comment it out.. (the problem started between those kernel and persists even in .39 , so trying to figure out the commit)
[19:55] <jjohansen> vish: you can build without those by putting skipconfig=true on the command line
[19:55] <jjohansen>  eg.  skipconfig=true fakeroot debian/rules binary
[19:56] <vish> oh, k. will do that for the next build.. i just commented it out and its building \o/
[19:56] <jjohansen> you may also need skipmodule=true skipabi=true
[19:57]  * vish makes note
[19:57] <jjohansen> vish there are also files you can touch/modify to get the same effect but if you aren't building a ppa, just putting those on the command line is good enough
[19:58] <vish> jjohansen: nah, not in ppa, just local build
[20:00] <vish> lp hates me atm, i dput the upload and it stops at the last 1 kb and just gets stuck forever, did that like 5 times already o.0
[20:09] <jjohansen> vish: sadly that happens to more than just you
[20:10] <jjohansen> or maybe not so sadly, depending on your pov.  ie. lp hates more than just you :)
[20:10] <vish> lol!!
[21:56] <CarlFK> natty loaded snd-hda-intel - todays oneiric 3.0-1 does not, so no sound.
[21:56] <CarlFK> should I report this somewhere?


[04:27] <alireza> hey
[18:35] <willh> I have been attempting to install Jammy Jellyfish on my HP Pro laptop, using a USB drive, but was getting error messages when I rebooted after the "installation complete" message. After that happened I was able to try it out without installing and had no problems for a couple of days. Then Firefox crashed and could not be reopened. When I rebooted
[18:35] <willh> I got the following message: "ZSTD Compressed data is corrupted - System halted". I am wondering whether this indicates a problem now in the USB drive or if it is rather in the laptop itself.  Tomreyn kindly gave me some help a while back ( before I had a nick) which enabled me to eliminate one original error message I was getting (re VMX). Any
[18:35] <willh> advice would be appreciated.
[20:06] <tomreyn> willh: so you installed to your internal disk? is this a hdd, an ssd, or something else?
[20:25] <willh> to hdd from bootable flash drive.
[20:27] <tomreyn> willh: are you able to boot from the hdd now?
[20:27] <tomreyn> like, does it work sometimes or have you found a workaround?
[20:28] <tomreyn> does this happen to be you? https://forums.linuxmint.com/viewtopic.php?t=395876
[20:28] <tomreyn> it's the only occasion that i can find of the message you reported you see at boot
[20:30] <tomreyn> hmm, you seem to be in canada, not florida, and have a different name, so probably not.
[20:30] <tomreyn> this person also uses hp hardware, though
[20:32] <willh> Cannot boot, have no workaround.  I had read that post at that link. I am in Canada, as you say.
[20:36] <willh> That fellow in Florida clearly has higher level of technical knowledge than I do.
[20:42] <willh> I was thinking that maybe I should create a fresh bootable USB drive and try again with it.
[20:44] <diogenes_Vx15> willh, it looks like your HDD is dying.
[20:50] <willh> So Diogenes, you mean that the ZSTD compressed data is corrupt message relates to the HDD, not the flash drive?
[20:52] <diogenes_Vx15> willh, TLDR, i don't understand what is has to do with the USB drive, it is only used for installing the system, if it gives an error during the installation, in 90% of cases it's a faulty USB drive, in rest, it's HDD.
[20:55] <willh> OK
[22:07] <tomreyn> willh: you can try to boot to grub and then select an older kernel from the "Advanced" menu, this may let you boot
[22:07] <tomreyn> you can also try just booting the default kernel from the grub menu manually, sometimes this also helps.
[22:09] <tomreyn> if you can get the system to boot, you can check system logs with    journalctl -f    (which will print new log records as they are being logged)   OR    journalctl -b (which will show any logs since last boot)
[22:12] <tomreyn> if you suspect that the hdd may be defective, you should look for "media sense" errors on journalctl
[22:31] <willh> Thanks a lot Tomreyn, I will try these. Before the most recent attempt to install Jammy,  I ran an expansive test of the hard drive, and it passed, 100%. I was previously running Mint, by the way.
[22:32] <tomreyn> good luck!
[22:33] <willh> Thanks again.


[00:10] <Guest79344> I just found out about alt+right click for window resizing. Solves my issue above.
[00:11] <Guest79344> I'm now trying to set up Jack Bridge. It was listed in the Connections dialog of QJackCtrl my first day with Ubuntu Studio, but it is no longer there.
[00:11] <Guest79344> Any ideas?
[00:54] <fieryfennix> [kubuntu 13.04 KDE]   hello all.  a quick question, if i may.  how to add the "run command" box permanently to kde desktop?  not a shortcut, but the box itself?
[14:15] <blazemore> does anyone know of a nice way to dynamically adjust the sample rate of Pulseaudio according to the maximum sample rate of the source file being played? Or should I just leave it on the maximum my DAC supports, and use speex 10 to just resample 44.1k to higher frequencies?
[14:15] <blazemore> For example, if I'm playing a CD, it'd be nice to have it actually setting my DAC to 44.1k, whereas if I'm playing a 96k source file I don't want it downsampled
[14:15] <blazemore> At the moment I have pulse set to 96k the entire time, and it just resamples 44.1k, but that's not ideal
[14:16] <holstein> blazemore: i wouldnt worry about that
[14:16] <blazemore> I'm not using the Ubuntu Studio variant (so no JACK etc), but I was directed here from #Ubuntu in the hope one of you would know
[14:16] <holstein> blazemore: the device should be doing the best it can
[14:16] <holstein> and, you wont hear/notice the difference anyway
[14:16] <holstein> unless you do. then, worry about it
[14:17] <holstein> you can try #opensourcemusicians
[14:17] <blazemore> I think my problem stems from the fact I don't *really* understand how it works. Let me explain what I think is happening
[14:17] <holstein> blazemore: i think the problem is, you dont have a problem ;)
[14:17] <holstein> so, dont make one for yourself
[14:17] <blazemore> My DAC will natively play 44.1k, 48k and 96k (it connects over USB)
[14:18] <holstein> if you are using consumer-grade equipment, its likely not even capable of providing you the fidelity to be able to hear the different between what you are worried about
[14:18] <holstein> the device will be playing back at the rate that linux likely can support, as best it can
[14:18] <blazemore> By default, playing a 96Khz file, Pulseaudio downsamples (using speex 1 by default) to 44.1Khz
[14:18] <holstein> if you are "worried" about it, you can check out JACK, where you can set those rates.. but JACK has its own issues
[14:19] <holstein> !proaudio | blazemore
[14:19] <blazemore> Now, I can set Pulseaudio to do 96Khz, and then the display on my DAC changes to show it's recieving 96Khz, but then that means Pulseaudio is upsampling to 96Khz instead
[14:19] <holstein> blazemore: you shouldnt need to set pulse audio to 96k
[14:19] <blazemore> It's consumer-grade hardware, it's a Fiio E17 (Love it btw)
[14:19] <holstein> blazemore: im not debating your affection fo the device
[14:19] <holstein> nor, am i saying its "crap"
[14:19] <blazemore> Now I'm no mathematitian, but 44.1 doesn't go into 96 :)
[14:20] <holstein> blazemore: sure.. but, can you hear a problem?
[14:20] <blazemore> No but it annoys me
[14:20] <holstein> blazemore: i personally cant hear 44.1 vs 96..
[14:20] <holstein> blazemore: what annoys you?
[14:20] <blazemore> On Windows if I play a 44.1Khz in Foobar it sends 44.1Khz to my DAC. If I play a 96Khz file it displays 96Khz on my DAC
[14:20] <holstein> blazemore: that you push play? and the file plays back at a quality that is acceptable?
[14:20] <blazemore> I just want to replicate that functionality
[14:20] <holstein> blazemore: sure
[14:21] <holstein> blazemore: you can use JACK to do that
[14:21] <blazemore> OK I'll look into it with the resources you already provided :)
[14:21] <holstein> blazemore: otherwise, you cant hear the difference, so i dont see that there is a problem
[14:21] <holstein> plus.. does windows do that?
[14:21] <blazemore> I'm not really interested in a discussion on whether or not higher sampling rates are "worth it", since most people enter into one already having their mind made up
[14:21] <blazemore> holstein: Windows XP does, yes
[14:22] <holstein> even if it actually does, and is not just reporting that, you have to keep in mind, that can be on a hardware driver level
[14:22] <holstein> and, you know who is *actuall* responsible for providing alsa with that information
[14:22] <holstein> actually*
[14:22] <blazemore> Yes on Windows XP I did have to install the ASIO driver from FiiO
[14:22] <holstein> blazemore: im not debating that XP "reports" it is doing that
[14:22] <blazemore> The DAC's display gets updated
[14:22] <holstein> blazemore: but, you wouldnt hear the difference if it were or not
[14:22] <blazemore> I'm not sure where the DAC gets its information
[14:22] <holstein> blazemore: so
[14:23] <blazemore> The thing is, some music I have is only in 96Khz
[14:23] <holstein> blazemore: thats just a UI update.. and again, im just being realistic.. not trying to be combative
[14:23] <holstein> blazemore: so
[14:23] <holstein> blazemore: there is not issues playing the music, correct??
[14:23] <blazemore> If I only do one thing, should I set the resampling algorithm in pulse to speex 10?
[14:23] <holstein> blazemore: does it sound "bad" ?
[14:23] <blazemore> no
[14:23] <blazemore> well
[14:23] <blazemore> sometimes pulse crackles
[14:23] <holstein> blazemore: i mean, you *can* "fix" this
[14:24] <holstein> blazemore: pluse crackles
[14:24] <blazemore> But that's just when Java is open and is entirely unrelated
[14:24] <holstein> blazemore: pulse is doing what it is designed to do
[14:24] <holstein> blazemore: java is working with pulse that is working with alsa to the best of its abilities with the support that is available
[14:24] <blazemore> I sort of just mentioned it in #ubuntu as a quick aside to an existing discussion on Pulseaudio
[14:24] <holstein> blazemore: the vendor likely doenst supply alsa with information
[14:24] <blazemore> Java + pulse is a mess IMO
[14:24] <holstein> blazemore: no
[14:25] <holstein> blazemore: JAVA is a messs
[14:25] <blazemore> Yeah
[14:25] <holstein> pulse is doing what it is designed to do
[14:25] <holstein> and, its not made for high priority audio
[14:25] <holstein> thats why we still use, and need JACK
[14:25] <holstein> but, that is a different conversation
[14:25] <OvenWerks> blazemore: as far as I know pulse will try to set the hw rate to the source rate
[14:25] <holstein> blazemore: anyways.. getting back to the end of my rant
[14:25] <blazemore> I'll admit to not knowing completely what JACK does; I assumed it was a way of routing audio signals between devices and applications
[14:26] <holstein> blazemore: you *can* "fix" this "issue"
[14:26] <blazemore> I don't notice an audible difference
[14:26] <blazemore> If that's the point you're getting at
[14:26] <holstein> blazemore: its all open, and freely available for you to change, or for your vendor to provide support for
[14:26] <OvenWerks> If the application sets the rate to less than the souce file rate that is an application problem.
[14:26] <holstein> blazemore: but, you *will* waste a lot of time "fixing" something that will have literally no benifits to you
[14:26] <OvenWerks> the VLC video player for example will resample internally to 48000
[14:27] <holstein> blazemore: and, what if, at the end of a long process, the actual "issue" is the driver support in alsa?
[14:27] <blazemore> OvenWerks: If the sample rate in /etc/pulse/daemon.conf is set to 44.1Khz, and I play a 96Khz file in Aqualung, Pulse resamples it on-the-fly to 44.1Khz using the algorithm defined in that same file
[14:28] <OvenWerks> If there are more than one audio stream and pulse is already streaming at 44100 then the application will be forced to resample
[14:28] <holstein> if not, it should be utilizing the hardare the best that it can
[14:28] <blazemore> I'd prefer it to upsample than downsample though
[14:28] <holstein> blazemore: why?
[14:28] <holstein> blazemore: either, one could argue, is "bad"
[14:28] <holstein> blazemore: plus, you cant hear any probles either way
[14:28] <OvenWerks> most linux (and I think windows) applications resample on the fly to fit what the OS will allow at that time.
[14:28] <blazemore> Because I paid for a FiiO E17 which supports three different sample rates
[14:28] <holstein> yup
[14:29] <holstein> windows would be doing the same, but could have much better driver support
[14:29] <blazemore> And there's not much point if it's just constantly using one
[14:29] <holstein> blazemore: does the device support those rates in linux?
[14:29] <blazemore> Yes holstein
[14:29] <holstein> blazemore: does the device support linux at all
[14:29] <blazemore> Yes
[14:29] <blazemore> But only if I manually set the sample rate in pulse and then restart pulse
[14:30] <OvenWerks> you can set pulse default rate to 96k if you like.
[14:30] <blazemore> OvenWerks: Exactly
[14:30] <blazemore> That will do, to be honest, and is what I am doing currently
[14:30] <blazemore> I also set resample-method = speex-float-10
[14:30] <holstein> blazemore: so, on the box, and in the documentation, the vendor states "linux support"
[14:31] <holstein> ?
[14:31] <blazemore> checking
[14:31] <holstein> otherwise, the support you are experiencing is just the "magic" or alsa
[14:31] <blazemore> It seems to work
[14:31] <holstein> blazemore: seems?
[14:31] <blazemore> In that, it makes my speakers move air
[14:32] <holstein> blazemore: the audio seems to sound fine to you
[14:32] <blazemore> Their website is slow just waiting
[14:32] <blazemore> On an aside, it really is a lovely amp
[14:32] <holstein> blazemore: if you want to be overly particular about the fidelity, you cannot accept "seems"
[14:32] <blazemore> got a battery and aux in
[14:32] <holstein> you must know, for certain
[14:32] <OvenWerks> the config file is in /etc/pulse/
[14:32] <blazemore> Yes OvenWerks /etc/pulse/daemon.conf
[14:32] <holstein> blazemore: and, the alsa driver might not support the full range of functions on that device
[14:33] <OvenWerks> however, even if you do that, if the application decides to downsample internally to 48k, then pulse will set the hw to 48k
[14:33] <blazemore> OvenWerks: I use mpd, and sometimes aqualung
[14:34] <OvenWerks> pulse has no idea that the apllication has a 96k file to play with it only knows what rate the application wants to send the audio to pulse in.
[14:34] <blazemore> Yes I'm aware of that, I'm assuming here that the application isn't resampling (neither mpd or aqualung do)
[14:34] <holstein> what would i do? use JACK and audacious to set the rate.. test the files to see that i cant tell the difference in the quality... then, relax and use the defaults
[14:35] <holstein> but, i have already done such tests
[14:35] <blazemore> Out-of-the-box it sounds a lot better than the dac/amp on my motherboard anyway, so I am very happy with ootb configuration
[14:35] <holstein> then, i wouldnt make an issue for yourself
[14:35] <blazemore> It's *just* a matter of getting native 96Khz playback when I open a 96Khz file, and 44.1Khz when I play a CD
[14:35] <OvenWerks> The pulseaudio-discuss mailing list might be the best place to find answers then.
[14:36] <OvenWerks> The pulseaudio devs use that list to do their development work as well as answer questions
[14:36] <blazemore> I am not taking this further than this channel, I don't care *that* much
[14:36] <holstein> this is something, that, assuming the driver in alsa can support the 96k of the device, you literally will waste days on this, and only your dog would be able to hear a difference, assuming the speakers and the equipment can produce the audio in that range
[14:37] <blazemore> I was kind of hoping one of you would say "yes blazemore just uncomment the line saying pulse-automatic-resampling in daemon.conf" or something :P
[14:37] <OvenWerks> All known computer IFs reporduce 20 to 20k hz only no matter what rate they use.
[14:37] <holstein> assuming the device can be supported by the alsa driver, you can
[14:37] <blazemore> erm
[14:37] <blazemore> I am talking about sample rate of digital audio, not the pitch of a note
[14:37] <holstein> sure
[14:38] <holstein> but, if the device cant produce the frequencied that would be effected, it literally doesnt matter
[14:38] <blazemore> Anyway, I enjoy wasting silly amounts of time on issues like this
[14:38] <holstein> frequencies*
[14:38] <blazemore> I mean, why else would I use Linux?
[14:38] <holstein> lol
[14:38] <holstein> :)
[14:38] <blazemore> I will come out of this knowing *way* more than I did before about Alsa, pulse and jack, and the nature of digital audio in general
[14:38] <OvenWerks> There are good reasons to use 96k even for 20K max audio, but getting frequency output over 20k is not one of them.
[14:39] <holstein> yup ^^
[14:39] <blazemore> My reasoning is, I have files in 96Khz, and obviously on-the-fly resampling isn't ideal
[14:39] <holstein> why?
[14:40] <blazemore> perhaps I should resample them and save the resampled files
[14:40] <holstein> for listening back, on a system that is covering other audio, i would say playing the file is ideal
[14:40] <blazemore> For a system which is only used to play music?
[14:40] <holstein> blazemore: i would literally push the play button, and deal with it if i hear a problem
[14:41] <blazemore> I ask because I'm considering using my Raspberry Pi, FiiO e17 and mpd to make a neat little remote-controlled jukebox
[14:41] <holstein> blazemore: again, setting the system to 96k can be done several ways, assuming the alsa driver supports the hardware, and, you have a system on which the fidelity would report a noted difference, which as OvenWerks states, still wont be a big deal
[14:41] <blazemore> Yeah I know :)
[14:41] <blazemore> Thanks for the tips and resources
[14:42] <holstein> blazemore: set it to 96k, and give it a listen
[14:42] <OvenWerks> There has been a good discusion about the RPi on the LAU mailing list you may be interested in the archive of that mailing list
[14:42] <blazemore> OK thanks OvenWerks
[14:42] <wachin> Hi all, I would like to change the icon of an application which is mousepad, which is equal to that of gedit
[14:42] <wachin> I searched Google but can not find a solution
[14:42] <blazemore> wachin: Ask in #Ubuntu
[14:43] <blazemore> wachin: What distro are you using? Ubuntu Studio?
[14:43] <wachin> could any of you help me
[14:43] <holstein> wachin: on the desktop? in the menu? are you using XFCE?
[14:43] <wachin> Ubuntu Studio 13.04
[14:43] <wachin> Yes, I use XFCE4
[14:44] <OvenWerks> There are two ways to change that icon
[14:44] <wachin> The icon theme that I use is "ubuntustudio-icon-theme" on synaptic
[14:44] <OvenWerks> in both cases you need to look for the desktop file in /usr/share/applications/
[14:45] <wachin> great, I search now
[14:45] <OvenWerks> (I didn't think we shipped mousepad actually)
[14:45] <holstein> AFAIK, we dont, but the process should be the same
[14:46] <cub> no mousepad is not included in default installation
[14:47] <wachin> OH
[14:50] <wachin> I Found /usr/share/applications/mousepad.desktop
[14:50] <wachin> open this with root
[14:50] <wachin> the file said
[14:50] <wachin> Exec=mousepad %F
[14:50] <wachin> Icon=accessories-text-editor
[14:50] <wachin> Terminal=false
[14:50] <wachin> StartupNotify=true
[14:50] <wachin> Type=Application
[14:50] <wachin> Categories=Application;Utility;TextEditor;GTK;
[14:50] <wachin> MimeType=text/plain
[14:50] <holstein> !paste | wachin
[14:51] <wachin> I think that "Icon=accessories-text-editor" is the image of the icon
[14:51] <wachin> Ups
[14:51] <holstein> wachin: you can see the icon listed there
[14:51] <wachin> Thanks
[14:51] <wachin> OK
[14:51] <holstein> wachin: no worries.. its slow-ish in here.. in #ubuntu that would be an issue
[14:52] <wachin> ok
[17:25] <studionovice> When I start jack - background audio from my browser (chrome) quits - is this expected?
[17:25] <holstein> yup
[17:25] <studionovice> I am assuming its a pulseaudio issue from what I have researched?
[17:25] <holstein> there is no issue really
[17:25] <holstein> you are asking JACK to take over the audio device, so it does
[17:26] <holstein> you should have the pulse sync after that to route what you like, if needed
[17:27] <studionovice> Jack runs completely off alsa, correct? would it be okay to unistall pulseaudio completely from my system - as I don't think it's needed?
[17:27] <studionovice> thanks!
[17:28] <holstein> no reason ot
[17:28] <holstein> to*
[17:28] <holstein> i wouldnt suggest it, unless you are having issues
[17:28] <holstein> you can disable the pulse bridge
[17:28] <holstein> untick the dbus checkbox in qjackctl
[17:29] <studionovice> I'm not seeing that option...
[17:30] <studionovice> Is it on the settings tab of qjackctl
[17:30] <holstein> in setup, under the "misc" tab
[17:31] <holstein> Enable dbus interface
[17:32] <studionovice> Got it.  Can you explain what the Dbus interface actually does? thanks for your help - I appreciate it.  I'm fairly versed in *buntu systems but am trying to setup a home recording studio
[17:32] <holstein> the pulse interface we were talking about
[17:32] <holstein> check out #opensourcemusicans .. handy community :)
[17:33] <studionovice> awesome - will do
[17:34] <studionovice> I just got a lexicon pro alpha interface, and I have a nice midi keyboard too
[17:34] <holstein> i have an omega
[23:18] <angel> i'm here again to ask help about wifi and hotspot
[23:24] <angel> someone to help me


[12:55] <Satoris> Anyone else have 4 finger swipe for the dash broken in Unity-2D?
[13:06] <bregma> I'm assuming touchpad?
[13:08] <Satoris> Magic trackpad.
[13:08] <Satoris> s/dash/panel/
[13:11] <Satoris> I get 4 finger touch events through XInput.
[14:00] <Satoris> Unity-2D's bug list seems to indicate that they are reworking 4 finger swipe gesture code as we speak.
[14:14] <tvoss> migrating utouch-jobs to production jenkins, grail, frame and geis are done, evemu to go
[14:15] <bregma> where is the production jenkins located?
[14:15] <cnd> jenkins.qa.ubuntu.com?
[14:15] <Satoris> Bug filing, QA script tuning, randomage.
[14:15] <cnd> I'm still trying to dig out of a ton of X patches that I'm working on for ubuntu and upstream
[14:16] <cnd> it seems that I still don't have touchscreens working quite right
[14:16] <tvoss> cnd, bregma: Results from production jenkins are exported to the public instance
[14:17] <dandrader> my stand-up report: Improving port of unity code to geis v2 API. Making it use regular recognizer (no atomic gestures) and accept()/reject() gestures.
[14:18] <Satoris> cnd: where did you get the sortable multi column kernel report HTML? The code in Arsenal only prints bug id, title and series.
[14:18] <bregma> I'm beavering away on the grail config stuff
[14:19] <cnd> Satoris, I don't know where the code lives, I just noticed it on qa.ubuntu.com
[14:19] <cnd> Satoris, I suggest asking bjf in #ubuntu-kernel
[14:20] <cnd> tvoss, when I try to get to the code coverage, jenkins can't find the source code
[14:20] <cnd> https://jenkins.qa.ubuntu.com/job/ps-utouch-grail-daily-amd64/1/cobertura/_home_ubuntu_jenkins_workspace_ps_utouch_grail_daily_amd64_pbuilder_setup_work_trunk_src_v3/atomic_recognizer_cpp/
[14:20] <tvoss> cnd,
[14:20] <cnd> do you know why that would be?
[14:21] <tvoss> I would guess that the job-publisher plugin does not take into account that it would need to copy the overall source code to provide that annotated view
[14:21] <bregma> hey -- do we need to have a call today (in 10 minutes)?
[14:21] <cnd> bregma, I assume so
[14:21] <cnd> but olli's not online...
[14:21] <Satoris> He's gone until wednesday.
[14:21] <bregma> he's not physically available
[14:22] <cnd> oh ok
[14:22] <cnd> well, then I guess not
[14:22] <cnd> Satoris, tvoss, bregma, dandrader: have you all done peer reviews and the review of olli?
[14:22] <cnd> dandrader, I dunno if you had to do it
[14:22] <tvoss> cnd, ack
[14:22] <Satoris> What is the "review of Olli"?
[14:23] <cnd> Satoris, you have to review your mgr
[14:23] <bregma> I haven't done my taxes yet, either
[14:23] <cnd> bregma, Satoris: these reviews were due last wednesday
[14:23] <Satoris> Allhands does not give me a link to do that.
[14:23] <bregma> right, I'll get right to it
[14:23] <cnd> hmm... maybe you missed it
[14:23] <dandrader> cnd, I think I'm out of it since I'm a newcomer
[14:24] <cnd> Satoris, it should be in your tasks
[14:24] <bregma> check all outstanding tasks, its not always obvious
[14:24] <Satoris> Allhands is not allowing me to log in. Grumble.
[14:25] <Satoris> But last I checked, my outstanding tasks did not have that.
[14:25] <cnd> tvoss, how will we do one-shot builds?
[14:25] <Satoris> Logged in, no manager review task that I can see.
[14:26] <tvoss> cnd, still on staging. Migrating that service is still up to discussion :/
[14:26] <cnd> ok
[14:26] <cnd> tvoss, that doesn't really need to be moved
[14:26] <cnd> but it would be nice to be able to email launchpad
[14:26] <cnd> and we need to figure out why geis is always failing...
[14:26] <tvoss> cnd, ack ... larry is on that, I motivated it with a mail to the mp
[14:27] <cnd> heh
[14:27] <tvoss> the example mailing to the merge-proposal
[14:38] <cnd> Satoris, btw, I found something on friday
[14:38] <cnd> instead of searching for all bugs for specific upstreams, we can use the canonical-utouch meta project
[14:38] <cnd> sorry, canonical-multitouch
[14:38] <cnd> https://bugs.launchpad.net/canonical-multitouch
[14:39] <Satoris> That does not list bugs in e.g. Unity-2D.
[14:39] <cnd> no, we still have to search for them
[14:39] <cnd> right now we have three searches:
[14:39] <cnd> 1. ubuntu packages structurally subscribed by utouch-bugs
[14:40] <cnd> 2. all other ubuntu bugs subscribed by utouch-bugs
[14:40] <cnd> 3. all upstream bugs in a list of packages
[14:40] <cnd> we can replace 3 with all bugs against canonical-multitouch
[14:40] <cnd> so we don't have a static list that must be updated any time we make a new project
[14:41] <Satoris> What is the list of packages that canonical-multitouch provides and why are they not already in 1?
[14:41] <cnd> 1.  is ubuntu packages, canonical-multitouch is for the upstreams of those packages
[14:43] <Satoris> Which are all our projects, right?
[14:44] <cnd> probably, but not necessarily
[14:45] <cnd> for example, we may not have a package for a project yet
[14:45] <cnd> but we may have bugs for it
[14:45] <cnd> to track development
[14:46] <Satoris> The query 1 I currently have does not make any distinction between packages and projects. It takes them all.
[14:46] <cnd> what do you mean?
[14:46] <cnd> I know it only searches for bugs against ubuntu packages because otherwise it would timeout
[14:47] <cnd> unless I'm remembering wrong
[14:47] <Satoris> What timeouts?
[14:47] <bregma> for query 1, isn;t the project 'ubuntu'?
[14:48] <cnd> launchpad times out if the query takes too long
[14:48] <cnd> bregma, right
[14:48] <Satoris> I have never had that issue...
[14:49] <cnd> Satoris, try searching for *all* bugs structurally subscribed by utouch-bugs
[14:49] <cnd> not bugs against the ubuntu project
[14:49] <cnd> it will timeout
[14:50] <Satoris> cnd: as far as I can tell, get_touch_bugs.py already does that. Line 106.
[14:50] <Satoris> Sorry, line 108.
[14:51] <cnd> Satoris, that only gets direct subscriptions
[14:51] <Satoris> Or is structural subscription somewhere else.
[14:51] <cnd> the issue is when you attempt to get structural subscriptions for all bugs
[14:52] <cnd> we don't really query launchpad that way because it times out
[14:52] <Satoris> And you can subscribe to packages, but not to projects?
[14:52] <cnd> you can subscribe to both
[14:52] <cnd> but you can't query based on structural subscriptions effectively because lp times out
[14:53] <Satoris> The other scripts do this by querying tags.
[14:53] <cnd> we have the canonical-multitouch project, so we can use that
[14:53] <cnd> that way we don't have to mess with tags
[14:53] <Satoris> Anyway, I think this is getting way too complicated. We don't create new projects or packages very often. We can just keep them in a list.
[14:54] <cnd> Satoris, how is it complicated?
[14:54] <cnd> I mean, it's already somewhat complicated because lp has issues
[14:54] <cnd> but I don't see how this development makes it "too" complicated
[14:55] <Satoris> To clarify: we want a list of bugs in a) certain projects/packages and b) where utouch-bugs is directly subscribed, right?
[14:55] <cnd> yes, where certain projects is canonical-multitouch upstream, and any ubuntu packages that utouch-bugs is structurally subscribed to
[14:56] <Satoris> And this list of projects changes how often?
[14:57] <cnd> not too often, but why does that matter?
[14:57] <Satoris> Because the time we have spent discussing this is already greater than the amount of time to manually update the list from here to eternity.
[14:58] <Satoris> If LP interface has issues, why use it?
[14:58] <Satoris> Do the simplest possible thing first and only if it is not good enough should you look into more complex solutions.
[14:59] <cnd> I'm trying to make it simpler
[14:59] <Satoris> There are scripts already in Arsenal to query for bugs in a list of packages. We could just use those.
[14:59] <Satoris> If the list is static.
[15:00] <cnd> Satoris, we need the data formatted in ways that other scripts aren't providing, afaict
[15:00] <cnd> we want to see the different tasks of a bug, including the upstream and the ubuntu packaging bugs
[15:00] <Satoris> If we want the tree thing, yes. But those are not sortable.
[15:01] <Satoris> Since we are the upstream and packagers, they are really not that different.
[15:02] <cnd> Satoris, they are because we need to track what has been fixed upstream vs in ubuntu
[15:02] <Satoris> There are two different problems here. 1) what bugs to query and 2) how to present this information.
[15:03] <Satoris> Is there a case where we would fix a bug in Ubuntu and not immediately apply the same fix to trunk?
[15:03] <cnd> Satoris, it's the other way around
[15:03] <cnd> we might have bugs fixed upstream and not in ubuntu yet
[15:03] <cnd> usually
[15:04] <Satoris> But if it is a bug that we are going to fix in Ubuntu, why would we not immediately push it out?
[15:04] <cnd> because you don't make a release for every bug you fix
[15:04] <cnd> releases take time, and we sometimes need to test them more
[15:05] <cnd> such as for SRUs
[15:05] <bregma> feature freezes
[15:05] <bregma> release freezes
[15:05] <Satoris> If it is not tested enough to go out as an SRU, it should not go to trunk.
[15:05] <Satoris> The situation would of course be different if we were not our own upstream.
[15:06] <cnd> Satoris, I don't understand why you are pushing back
[15:06] <bregma> bugs are reported in Ubuntu that are not necessarily reported against the upstream package, too
[15:06] <bregma> we can't always rely on seb for fixing that
[15:07] <Satoris> cnd: the other scripts do not care about bug tasks, only bugs. That makes them simpler than what we are trying to do. Since we are doing more complicated stuff we need to have a good reason for it.
[15:07] <cnd> Satoris, we do have a good reason for it
[15:07] <cnd> and it's not just utouch
[15:08] <cnd> tedg,  was complaining about this exact same issue for his projects
[15:08] <cnd> this has uses throughout PS
[15:08] <Satoris> That's good. Does he have a good description on what he needs? More input is always better.
[15:09] <cnd> I think if we can figure something out that works well for us we then have a good starting point
[15:10] <tedg> I'm sure what the question is exactly, but I'm happy to bitch if needed ;-)
[15:10] <Satoris> I'll leave for today. Please send me an email that outlines what the HTML page should show, how it should be formatted and so on. I currently don't have a clear vision on what you are trying to achieve.
[15:11] <cnd> Satoris, I don't have a great idea either
[15:11] <cnd> we have to experiment
[15:11] <cnd> I think you are getting close
[15:11] <cnd> the sortable web page you sent me today works pretty well
[15:11] <cnd> it just needs the information for the ubuntu packaging task too
[15:11] <Satoris> Hmm, it should be there already...
[15:11] <cnd> secondarily, we should be using canonical-multitouch to search for upstream bug reports
[15:12] <Satoris> My bad, it's not. I'll add it.
[15:13] <Satoris> cnd: the main problem (which I forgot to mention) is that those mako files need a completely different form of JSON, the generator of which is only inside one of the get-bug-foo scripts. And it is intertwingled with everything else.
[15:14] <cnd> Satoris, could you refactor it to make it better?
[15:14] <Satoris> get_touch_bugs.py can not generate it.
[15:15] <Satoris> cnd: now we get into the issue that Arsenal does not have good library design behind it. Code is copypasted. Getting that fixed is a group effort or we just go into madness.
[15:15] <cnd> Satoris, you can start it
[15:16] <Satoris> Perhaps. But not today. I'm off, see you tomorrow. ->
[15:19] <cnd> I'll biab


[20:31] <englishm> oh. it's empty.
[20:31] <englishm> did everyone get booted?
[20:32] <englishm> I'll see myself out.