[18:10] <smoser> harmw, 'make test' is failing for me. :-(
[18:10] <smoser> and in test_simple_write_freebsd
[18:10] <smoser> i'm not sure why. o rhow i didn't see it before.
[18:11] <harmw> smoser: harlowja did something in that area recently
[18:12] <harmw> *to fix some fault
[18:22] <harlowja> smoser ya i fixed it
[18:22] <harlowja> smoser try https://code.launchpad.net/~harlowja/cloud-init/test-fixups
[18:23] <harlowja> connected to https://bugs.launchpad.net/cloud-init/+bug/1380424
[18:24] <smoser> harlowja, you rock.
[18:25] <harlowja> ha
[18:26] <harlowja> no u do
[18:36] <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/rpm-spec-fixups also if u want
[18:36] <harlowja> discovered those when rebuilding the rpm for y!
[18:36] <harlowja> and https://code.launchpad.net/~harlowja/cloud-init/fixed-rhel7 if u want
[18:40] <smoser> harlowja, thanks. merged.
[18:41] <harlowja> cool
[18:41] <harlowja> https://code.launchpad.net/~harlowja/cloud-init/rpm-spec-fixups/+merge/238219 might need a freebsd specific distro variable though, not sure
[18:41] <harlowja> harmw let me know and i can adjust that
[18:42] <harlowja> basically distros get a new constant 'usr_lib_exec'
[18:42] <harlowja> which i guess varies between rhel and others
[18:42] <harlowja> mainly used to locate where 'write-ssh-key-fingerprints' is
[18:42] <harmw> hm?
[18:42] <smoser> maybe its time to replace that. :)
[18:43] <harlowja> thats another option, ha
[18:43] <harlowja> cant 'write-ssh-key-fingerprints' just use python to do it all (i'm not to sure why we need it actually)?
[18:43] <harlowja> its not so complex script
[18:44] <smoser> its just vestigial from smoser's love of /bin/sh
[18:44] <harlowja> like that 3rd arm of yours
[18:44] <harlowja> don't make me shake the 3rd arm again in paris
[18:44] <harlowja> lol
[18:44] <harlowja> so thats the other option, i can just replace that, lol
[18:46] <harmw> you both updated to Juno already?
[18:46] <harlowja> no
[18:47]  * harlowja we aren't that quick, ha
[18:47] <harmw> :)
[18:49] <smoser> i'm deploying a juno *right now*!
[18:49] <smoser> and after ditching horizon from my devstack config, devstack actually works a fair aount of the time.
[18:49] <harmw> horizon.. puh
[18:49] <smoser> (rather htan failing due to pip on some horizon dependency)
[18:50] <harmw> I hardly ever use horizon
[18:50] <harmw> Ill probably update to Juno somewhre thursday, to finally go dualstack ipv4/ipv6
[18:51] <harlowja> users like horizon though, so i'll/someday at y! probably have to figure out why horizon broken there, lol
[18:51] <harlowja> *internal users
[18:51] <harmw> :P
[18:51] <harlowja> *i'll/someday -> i'll/somebody
[18:55] <smoser> harlowja, that lockstuff
[18:55] <smoser> tha tyou poitned me at
[18:55] <smoser> thats an entirely local operation right ?
[18:55] <harlowja> define local
[18:56] <harlowja> local to same host?
[18:56] <smoser> right
[18:56] <harlowja> yes
[18:56] <harlowja> it is
[18:56] <smoser> not sending messages to say "hey, let me lock a file please!"
[18:56] <harlowja> do u want more than that?
[18:56] <smoser> no. i do not.
[18:56] <harlowja> kk
[18:56] <smoser> it just seemed slow.
[18:56] <harlowja> i can point u at another library i work on for remote locks, lol
[18:56] <harlowja> https://github.com/stackforge/tooz
[18:56] <harlowja> :-P
[18:57] <harlowja> smoser as for speed, ya, i'm not sure, it not doing anything to crazy
[18:58] <harlowja> mainly https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L141
[18:58] <harlowja> although u might want to see how much contention is happening @ https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L86
[18:58] <harlowja> which depending on the contention rate could be significaent
[18:58] <harlowja> also time.sleep(0.01) there...
[18:59] <harlowja> ^ which is like an eternity in computer time
[18:59] <harlowja> so u might try tweaking that down
[19:06] <smoser> k. yeah, that loks sane.
[22:46] <j12t> Is there some place that describes the difference between "cloud-init init" and "cloud-init modules"? Or in general how to invoke the thing?


[21:19] <adam_g> is 2 factor auth known to be not working currently on the staging server?
[21:21] <czajkowski> adam_g: yes
[21:22] <czajkowski> please talk to webops to ask them to remove it from your ac for staging
[21:22] <adam_g> czajkowski: thanks
[21:22] <czajkowski> np


[11:00] <towo`> hi, i want to report a bug for qemu on launchpad, but log in with the ubuntu one account ends in OOPS-71a8bd47e0cedd7f0720edccb627fe20
[11:16]  * utkarsh2102 waves
[11:16] <utkarsh2102> I've been trying to login to launchpad but every time I do, I get an error.
[11:17] <utkarsh2102> atm, the error ID is OOPS-d1757a7131ebdece1d30cb91731e502e.
[11:17] <utkarsh2102> am I missing something?
[11:32] <towo`> i have the same problem
[11:32] <towo`> and that url helps zero
[12:05] <utkarsh2102> is there something I can do to fix that?
[12:05] <utkarsh2102> I mean, I have no idea who to contact :)
[13:39] <arunpyasi> cjwatson might give some clue if available/around utkarsh2102 ^^
[16:28] <tomwardill> towo`: send an email with the oops ID to<EMAIL_ADDRESS>and we’ll have a look at it when there’s someone around
[16:29] <tomwardill> I’m away from my work computer atm
[16:30] <tomwardill> utkarsh2102: send an email with the oops ID to<EMAIL_ADDRESS>and one of us will look when we can
[16:31] <tomwardill> It’s usually something simple, but I haven’t got my work machine available atm
[16:32] <utkarsh2102> tomwardill: shall do, thanks
[16:32] <utkarsh2102> and no rush, whenever you're free and have time (& machine :))
[16:33] <tomwardill> It’ll probably be Monday at the earliest, unless someone happens to be about 😀
[17:39] <LocutusOfBorg> mmm bos02 is having a sad day?


[00:00] <mpt> crimsun_, "Mono: Playback 25 [81%] [-9.00dB] [on]"
[00:01] <crimsun_> mpt: and, amixer get 'External Amplifier'|grep Playback
[00:02] <mpt>   Playback channels: Mono
[00:02] <mpt>   Mono: Playback [on]
[00:02] <crimsun_> mpt: if you would, please, attach /proc/asound/card0/codec97#0/* contents when sound is audible
[00:03] <mpt> crimsun_, ok, I'll put that in the bug report so I remember :-)
[00:03] <crimsun_> mpt: thanks.
[00:03] <mpt> thank you
[00:12] <TheMuso> slangasek: Re pulse and PC speaker, does backscroll give you enough info, or do you want me to IRC/email you a good description of what the problem is?
[00:15] <slangasek> TheMuso: the one thing I don't have to hand at the moment is the bug number
[00:15] <slangasek> though there's another bug about snd_pcsp breaking KVM, so the fact that snd_pcsp is a problem is already somewhat covered
[00:15] <crimsun_> blacklisting the pc speaker makes more sense, really.
[00:15] <TheMuso> crimsun_: And loose PC speaker functionality entirely?
[00:15] <slangasek> blacklisting the pc speaker /also/ makes sense. :)
[00:15] <crimsun_> (and by "blacklisting", I mean "have PA ignore it")
[00:16] <slangasek> TheMuso: what "functionality" are we losing, exactly?
[00:16] <TheMuso> crimsun_: I've a better idea. I have a patch that will make sure the pc speaker sink is loaded last by the hal module, so its available for those who want it, but not used by default unless there are no sound cards.
[00:16] <slangasek> I don't see that we would ever want to use this as an output device, even when there are no sound cards
[00:16] <crimsun_> I agree w/ Steve.
[00:17] <TheMuso> Well I was talking about this with persia yesterday and he thought it would be considered a bug if it wasn't available.,
[00:18] <crimsun_> has anyone actually said "oh, it works fine at a reasonable volume by default"?  If not, it's a pretty compelling case to not make it available.
[00:18] <TheMuso> slangasek: I  hae one bug in mind, but checking to see whether any others are more relevant.
[00:18] <TheMuso> crimsun_: I am of the same view TBH.
[00:18] <persia> My main thought was that upstream put it there, and there is documentation.  If we can make it not broken (using PC Speaker by default), and still support it for whatever use case it exists to support, that would be better.
[00:19] <persia> If this is especially hard, dropping it is perhaps correct.
[00:19] <slangasek> TheMuso: *I* consider it a longstanding bug that my computer beeps at me like a petulant robot child, and have always blacklisted the pcspkr module on my system; I just have never filed it, or bothered to complain until it became correlated with much more serious bugs
[00:20] <ogra> it just wants to start a conversation ...
[00:20] <ogra> and you ignore it !
[00:20] <crimsun_> persia: the real problem, IMO, is that there's no sane level for "reasonable by default", which is a long-standing issue WRT sane levels attempted in alsa-utils's initscript (to erm, little success).
[00:21] <TheMuso> slangasek: Bug 242966.
[00:24] <TheMuso> Alright, I'll revert to my original patch, which prevents pulse from loading pcspkr as a sink.
[00:25] <TheMuso> Oh, and since pulseaudi o0.9.11 has landed, sooner than I expected, do we want to consider it for intrepid, given that we are a few months out from release?
[00:26] <slangasek> is that the version that requires the alsa upgrade that the kernel team hasn't committed to yet?
[00:28] <persia> crimsun_: True.
[00:28] <TheMuso> slangasek: Yes, what do you mean not ocmmitted to? Is this documented somewhere?
[00:38] <slangasek> TheMuso: weren't you asking just the other day about whether to ask the kernel team to update the version of alsa in the kernel?
[00:39] <slangasek> if you haven't asked them yet, then I guess they haven't committed to it either
[00:39] <TheMuso> slangasek: Right, I haven't asked them due to what you said about considering sticking with 1.0.16.
[00:39] <TheMuso> However, 1.0.17 has support for more hda hardware for notebooks.
[00:40] <TheMuso> So if we don't go that route, those additions will have to be backported.
[00:40] <slangasek> sorry, what did I say that gave you the impression I thought we should stick with 1.0.16?
[00:41] <TheMuso> langCan't exactly remember without checking logs, but thats the impression I got.
[00:41] <TheMuso> slangasek: ^^ gah typing
[00:41] <crimsun_> (you really will want 1.0.17 if for nothing else than vmaster migration to core and HDA codec quirks)
[00:42] <TheMuso> crimsun_: Right.
[00:42] <slangasek> TheMuso: I tend to ask lots of questions about the decision making process when I see that someone is discussing an issue that could become release-critical if things go pear-shaped; this usually doesn't mean that I'm attached to one decision or another unless I explicitly say so :)
[00:42] <slangasek> I'm happy for you to proceed with talking to the kernel team and find out whether 1.0.17 is considered reasonable from their end
[00:42] <TheMuso> slangasek: Ok I'll keep that in mind.
[01:02] <hwilde> is there something on boot that tries to get on any open network??
[01:03] <hwilde> coworker observed it on the client  "I was running iwconfig every second. It shows the free wifi at that point, but by the time everything is loaded we are on the correct ssid. "
[01:04] <hwilde> orion caught the snmp trap    apf_policy.c:538 APF-1-DISCONECT_MOBILE_DUE_TO_WLAN_SWITCH: Disconnecting mobile 00:16:6f:b4:0d:68 due to switch of WLANs from 4 to 6
[01:05] <hwilde> tell me this is not possible, how could ubuntu possibly get onto free wifi on boot before /etc/network/interfaces is loaded up
[01:05] <hwilde> tell me their wlan id are screwed up and ubuntu is infallible
[01:08] <slangasek> hwilde: /etc/network/interfaces is not how wireless is configured by default in Ubuntu; maybe you can provide more information about your setup?
[01:08] <hwilde> slangasek, 8.04 server stripped down, no network manager
[01:09] <hwilde> how is it configured by default in Ubuntu
[01:09] <slangasek> using network manager :)
[01:09] <slangasek> if you aren't using NM, then there's nothing that would bring up a network prior to /etc/network/interfaces
[01:09] <hwilde> they are saying it's hopping onto an ssid for free wifi on boot,   then it goes to correct ssid
[01:09] <slangasek> I can't promise that this means the kernel driver won't associate with an AP on its own
[01:09] <hwilde> how is that even possible
[01:11] <ogra> cjwatson, see bug 251066, i thought i rememebred to fixed the CD unmounting in one of the last alphas ....
[01:11]  * ogra wonders why that returned
[01:11] <ogra> s/to/you/
[01:11] <hwilde> slangasek, is the kernel module ipw2200 or ieee80211 ?
[01:12] <ogra> i doubt the kernel driver doesn aynthing on its own ... you usually need wpasupplicant to do the assocation
[01:12] <Martiini> Has intrepid alpha 3 been released yet ??
[01:13] <hwilde> ogra, thats the thing it's open
[01:13] <ogra> i mean the driver wont do anything on its own
[01:13] <hwilde> it has to be their wlan ids are borked
[01:14] <hwilde> it's just not possible :/
[01:19] <slangasek> Martiini: no, we're in the final stages of validating it
[01:21] <Martiini> slangasek: do you work on ubuntu as we speak ?? do you actually work at canonical as a developer ?
[01:22] <infinity> Martiini: He's the release manager.
[01:22] <Martiini> are you serious ?!
[01:22] <infinity> Always.
[01:22] <ogra> infinity, liar ...
[01:23] <slangasek> well yes, you joined the Ubuntu developers channel, so there are Ubuntu developers here :)
[01:23] <infinity> ogra: s/Always/Often/ ?
[01:23] <ogra> :)
[01:30] <Martiini> Do you work in one geographical location or all over ? how do you communicate .. git and launchpad and irc ??
[01:31] <Martiini> Do you know any developers from scandinavia ?
[01:31] <ogra> we use bzr, not git
[01:31] <Martiini> I just watched google video where Torvalds talks about git
[01:32] <ogra> thats what kernel.org uses to develop the kernel, right
[01:32] <Martiini> apparently ,, I know nothing really
[01:34] <LaserJock> Martiini: there are Ubuntu developers everywhere ....
[01:34] <hwilde> Georgia Institute of Technology??
[01:34] <ogra> heh
[01:34] <LaserJock> Martiini: there's probably one looking over your shoulder right now
[01:34] <Martiini> Thanks, I feel safer now :)
[01:35] <slangasek> Martiini: we have community summits twice a year, and Canonical has team sprints at other times, to allow face-to-face collaboration.  But bzr, launchpad, IRC, and mailing lists are the primary means of collaboration the rest of the time, yes; https://wiki.ubuntu.com/UbuntuDevelopment is a good overview
[01:35] <Martiini> ok, thank you
[01:36] <Lightkey> LaserJock: that one scared me there..
[01:37] <LaserJock> mwuahahahaha
[01:38]  * LaserJock slinks back to his evil lair
[01:38] <ogra> putting a mirror behind your monitor might help :)
[01:39] <ion_> martiini: That video is awesome. :-)
[01:40] <Martiini> Torvalds is a nice person .. typical Helsinki swede
[01:57] <Martiini> ubuntu and linux development is too slow .. all the best developers in the world SHOULD be working on linux .. I have posted countless threads about this subject on ubuntuforums.org .. but the common voice means nothing obviously
[01:58] <Martiini> linux OS-s must become the mainstream os one day .. but as it is .. its going to be a VERY long wait
[01:59] <hwilde> ppl typicaly use that arugment against ubuntu
[01:59] <hwilde> says shuttlesworth should've just funded debian
[02:00] <Martiini> no .. as far as I understand .. they are different distros with different views , strategies ,, organization etc
[02:00] <hwilde> lol what are you in debate class
[02:00] <hwilde> "no"
[02:01] <Martiini> I just cannot see linux provide sufficient competition to OSX and Microsoft ... but this is not the place to start voicing my layman opinions
[02:01] <hwilde> dell.com/ubuntu
[02:01] <ogra> yes, but the competition avoids monoculture like windows brought us ... there are a gazillion different solutions for a problem ...
[02:02] <alex-weej> monoculture isn't all bad, though. it's just bad when it's unhealthy.
[02:02] <ogra> soemtimes ubuntu might not have the right one, but anther distro has, so it can be adapted from there .... that raises the overall quality ...
[02:02] <alex-weej> there is no downside to the entire planet standardising on the metric system, for example.
[02:02] <Martiini> its taking too long .. linux development speed is increasing every year but it still hasnt exploded
[02:02] <alex-weej> Martiini: then be patient
[02:02] <jcastro> Martiini: hop in dude
[02:03] <alex-weej> or do something about it. what did you hack today?
[02:03] <hwilde> lol
[02:03] <hwilde> jcastro,   lol I love telling people at work that complain like that   "well, you do know it's open source..."
[02:03] <ogra> alex-weej, well, on teh other hand only having one kind of birds on the whole planet would be kind of boring and leave us with a lot of nasty insects
[02:03] <ogra> ;)
[02:04] <hwilde> if the birds kept breaking my dual-head nvidia xorg.conf every update they might end up that way...
[02:04] <ogra> dont blame the birds for closed source !!
[02:04] <persia> hwilde: Always remember birds eat bugs
[02:04] <hwilde> birds eat worms dude
[02:04] <Martiini> yes, and why do they still use imperial system in USA
[02:04] <hwilde> spiders eat millions of bugs
[02:04] <persia> Yep.  So we need both birds and spiders.  Diversity is good :)
[02:05] <hwilde> google calculator  will be the end to unit conversion
[02:05] <hwilde> who needs to know that crap when google can translate for you
[02:05] <Martiini> USA is a backwards country  .. imperial :)
[02:05] <alex-weej> Martiini: FWIW though, i agree, but everything we have in place right now with our million different distros is serving a purpose.
[02:05] <ogra> Martiini, because they also run "worldcups" where nobody apart from the US is involved probably :)
[02:05] <alex-weej> ISV support would come more confidently if there was only Ubuntu
[02:05] <alex-weej> but there isn't.
[02:06] <hwilde> what is "ubuntu" anyways?  it doesn't actually exist
[02:06]  * alex-weej blinks
[02:06] <hwilde> it's a collection of packages, gnome, xorg, etc
[02:06] <Martiini> USA World cup and World Series :)
[02:06] <alex-weej> no way
[02:06] <alex-weej> Ubuntu is my operating system.
[02:06] <hwilde> it's a bunch of online tools and forums and communitiies
[02:06] <hwilde> ok then what "is" ubuntu
[02:06] <ogra> and a trademark :)
[02:06] <alex-weej> i don't use Linux.
[02:06] <ogra> you do
[02:06] <hwilde> it's the collective of developers who make it and the people who use it
[02:06] <ogra> but only as part of ubuntu
[02:06] <alex-weej> ogra: *I* don't use Linux.
[02:07] <alex-weej> if all else was the same, Ubuntu could be running NTOSKRNL for all i care
[02:07] <ogra> you developed ubuntu with bsd kernel and made it not available to the community ? evil you !
[02:07] <persia> hwilde: It's the collective of people who create it (not just developers) and the people who use it.
[02:07] <hwilde> lol what like project managers
[02:07] <hwilde> gantt charts dont make modules
[02:07] <alex-weej> and artists, and usability geeks
[02:07] <hwilde> developers and users
[02:07] <hwilde> well those people are included
[02:07] <hwilde> hci = development
[02:07] <alex-weej> seriously though
[02:08] <hwilde> graphics and visualizations = development
[02:08] <persia> Yes, and artists, and musicians and usability reviewers, and testers, and integrators and triagers and more
[02:08] <alex-weej> anyone up for porting Ubuntu to NT?
[02:08] <ogra> feel free
[02:08] <ScottK-laptop> alex-weej: Have fun with that.
[02:08] <alex-weej> :D
[02:08] <ScottK-laptop> Don't forget that Ubuntu is virtually all about integrating the work of others.
[02:08] <hwilde> and improving on it :)
[02:08]  * ogra just had a presentation at OSCON from a company that developd a kind of "reverse wine" to run linux apps on windows :)
[02:08] <hwilde> ubuntu handles rpms better than my redhat box
[02:08] <alex-weej> cygwin?
[02:09] <ogra> no
[02:09] <ogra> LINA
[02:09] <ScottK-laptop> When you say stuff like "I use Ubuntu, I don't use Linux" that, to my mind, devalues the work of the people who actually make the stuff Ubuntu integrates.
[02:09] <alex-weej> ScottK-laptop: well don't take it personally.
[02:09] <hwilde> ScottK-laptop, thank you that is waht i'm saying.  it's really gnome, and ext3, and launchpad, and xorg,  etc
[02:10] <ScottK-laptop> alex-weej: I'm just telling you how it sounds to me.
[02:10] <hwilde> "ubuntu" only means this specific group of creators and users
[02:10] <ScottK-laptop> hwilde: For me except not the Gnome part.
[02:10] <hwilde> fine bash and ssh whatever
[02:10] <ogra> ubuntu is an ancient african word maning ....
[02:10] <ogra> *meaning
[02:10] <hwilde> there is no src code for "ubuntu"
[02:10] <hwilde> its a collective
[02:10] <ScottK-laptop> hwilde: No, an actual DE, KDE.
[02:11] <ogra> its a spirit as well
[02:11] <hwilde> ScottK-laptop, , ice owns u
[02:11]  * ScottK-laptop goes back to trying to make source port randomization work in python-dns.
[02:11] <hwilde> true randomness is elusive.
[02:12] <alex-weej> the problem i find is that every layer of ubuntu itself lacks any form of common design
[02:12] <ogra> ??
[02:12] <alex-weej> operational conventions in linux are dissimilar to those in X are dissimilar to those in GNOME
[02:13] <alex-weej> is everything a file?
[02:13] <hwilde> ?
[02:13] <hwilde> have you ever heard of unix
[02:13]  * Hobbsee looks in
[02:13] <hwilde> that is the common design
[02:13] <ScottK-laptop> hwilde: Fortunately for this to work it doesn't need to be truly random.  It just needs to be not in a really obvious pattern.
[02:13] <alex-weej> hwilde: that's what i'm saying
[02:13] <alex-weej> everything is a file is old unix hangover
[02:13]  * ogra looks out ...
[02:13] <ogra> ... and sees Hobbsee
[02:13] <ogra> :)
[02:13] <hwilde> ScottK-laptop, make sure you seed your random generator   *glares at ssh-keygen*
[02:13] <ScottK-laptop> alex-weej: That's because they weren't designed commonly.
[02:14] <alex-weej> ScottK-laptop: i understand this
[02:14] <hwilde> yeah they also lack the common flaws of microsoft and the stagnation of their monopoly
[02:14] <alex-weej> hwilde: irrelevant
[02:14] <hwilde> what you call lack of common design is actually the competition that makes it successful
[02:14] <hwilde> you don't even use linux
[02:14] <hwilde> why are you even here
[02:14] <hwilde> lol
[02:14] <hwilde> get a mac
[02:14] <alex-weej> hwilde: when was the last time you directly interfaced with Linux
[02:14] <hwilde> make cheesy commercials
[02:14] <ScottK-laptop> hwilde: I looked at Python's SystemRandom takes from /dev/random on Linux, so it's unlikely I'll do better.
[02:15] <ogra> hwilde, because he wants to port ubuntu to NT
[02:15] <alex-weej> and i'm running Ubuntu on a MacBook Pro :P
[02:15] <hwilde> I prefer a wireless keyboard to direct interface
[02:15] <hwilde> lol
[02:15] <ogra> modprobe hwilde
[02:15] <alex-weej> i'm just suggesting it would be a much more attractive platform if, for example, the lower level tools were even using the same TYPE system as the higher level tools
[02:15] <hwilde> that's what ubuntu needs is an advertising plan
[02:15] <Hobbsee> ogra: :D
[02:15] <hwilde> hi I'm linux... and i'm a pc
[02:15]  * ScottK-laptop points hwilde at #ubuntu-marketing.
[02:15] <hwilde> ogra, sudo modprobe duh
[02:15] <ogra> geeez silly me
[02:15] <hwilde> lol
[02:16] <ogra> :)
[02:16] <hwilde> and maybe -r
[02:16] <hwilde> would be more funnier
[02:16] <ogra> that would deinterface you :)
[02:16]  * ogra needs to rush out, the others want to go for dinner
[02:16] <hwilde> you are a jambalaya ingredient typo
[02:16] <alex-weej> bye
[02:17] <hwilde> Hobbsee, are you a dj
[02:17] <Hobbsee> hwilde: no.
[02:18] <alex-weej> DJ Hobbsee on the ones and twos
[02:18] <Hobbsee> do you have something constructive to add?
[02:18] <alex-weej> little bit hostile there.
[02:19] <diogo> hi... How can I get ubuntu patches that it used to compile xorg <IP_ADDRESS> on Hardy... and how do I get the steps it used to compile it?
[02:19] <hwilde> Hobbsee, do you know waht secondayr myogenesis is
[02:20] <StevenK> diogo: The patches are probably split out in the source package.
[02:21] <Hobbsee> hwilde: how does that relate to the development of ubuntu?
[02:21] <diogo> sorry really newbbie on DPKG packages styles... is the source file the xorg 7.3_orig.tar.gz ?
[02:21] <hwilde> holy shit this isn't offtopic ??
[02:21] <Hobbsee> no...it's not...
[02:21]  * hwilde looks around
[02:21] <hwilde> what is with all this jibber jabber go back to idling you offtopickers
[02:21] <diogo> do you provide the source already patched or is it a source with the patches
[02:21] <StevenK> diogo: That's one of three files. And I'd have to check.
[02:22] <hwilde> Hobbsee, now that your here, why would ubuntu associate to free wifi on boot automatically, no network manager?
[02:23] <diogo> could you check it please trying to understand why xorg on ubuntu is having better performance with fglrx than on others... to report it to ATI Devs
[02:23] <Hobbsee> hwilde: i believe that answering such questions counts as "support".
[02:23] <Hobbsee> and apart from that, I don't know.
[02:23] <hwilde> Hobbsee, nobody in support knows... last chance is devs
[02:23] <hwilde> I just don't see how its possible :/
[02:24] <hwilde> I would like to develop a module to stop it
[02:24] <Hobbsee> modprobe -r the card?
[02:24] <hwilde> I need the card obviously
[02:24] <hwilde> but why is it hopping to an open ssid that it knows nothing about
[02:24] <Hobbsee> i've no idea.  mine doesn't.
[02:25] <hwilde> that's what you think
[02:25] <hwilde> that's what I thought up to yesterday
[02:25] <Hobbsee> well, on the basis that i don't have a network connection when i'm not running network manager...
[02:25] <hwilde> i have an eye witness, and an error from the wlan controller, that says on boot it hops to open wifi
[02:25] <slangasek> Hobbsee: it wouldn't bring up your tcp stack; that doesn't guarantee it won't associate with an AP
[02:26] <Hobbsee> slangasek: ah
[02:26] <hwilde> and I don't buy it's the kernel module slanga
[02:26] <persia> AP association may even be driven by firmware without regard for OS directives
[02:26] <hwilde> module just sit there they don't associate automagically
[02:28] <hwilde> Intel says the mini pci card firmware won't do anything unless you tell it to
[02:29] <slangasek> hwilde: well if you don't believe it's the kernel module, then you have something else running on your system that no one else does.
[02:29] <hwilde> believe me, I've spent hours defending ubuntu
[02:29] <hwilde> there's no way I can see it hopping on free wifi
[02:29] <hwilde> but they actually caught it on their controller
[02:29] <hwilde> apf_policy.c:538 APF-1-DISCONECT_MOBILE_DUE_TO_WLAN_SWITCH: Disconnecting mobile 00:16:6f:b4:0d:68 due to switch of WLANs from 4 to 6
[02:30] <ScottK-laptop> As you've been told, it may be out of the kernel's hands.
[02:31] <hwilde> and therein lies the problem
[02:31] <hwilde> you don't see it as an "Ubuntu" problem
[02:31] <ScottK-laptop> Right, but it's nothing to do with Linux or Ubuntu or whatever you call it.
[02:31] <hwilde> blame the kernel, blame the firmware, blame the wlan controller, etc etc
[02:31] <diogo> hey, if I'm not mistaken just looked at the xorg-xserver installation way of ubuntu and saw it added no patches... so Xorg <IP_ADDRESS> has no patches on ubuntu?
[02:32] <ScottK-laptop> diogo: You're mistaken.
[02:33] <ScottK-laptop> hwilde: What wifi chipset and were you using an completely FOSS configuration (no proprietary firmware/driver)?
[02:33] <hwilde> ScottK-laptop, intel 2200bg mini pci card,  ipw2200 module
[02:35] <diogo> so how can I get these patches?
[02:35] <Hobbsee> patches.ubuntu.com?
[02:36] <diogo> on patches.ubuntu.com has the patche for the 1.4.2 and not the <IP_ADDRESS> I need the older group of patches!
[02:36] <StevenK> The patches are in the source package.
[02:36] <diogo> where in the tar.gz package there are a lot of stuff there
[02:37] <Hobbsee> in the .diff.gz
[02:37] <StevenK> The orig.tar.gz is the original upstream source, the .diff.gz contains the Ubuntu and Debian changes and the .dsc ties them both together
[02:38] <slangasek> hwilde: a) this is not a support channel, b) I'm telling you the only thing in the stack that could do this is the kernel module itself because there's nothing else in an Ubuntu system that *could* associate with an AP prior to /etc/network/interfaces if you don't have Network Manager installed; so I'm trying to steer you in the right direction towards a solution, not "blaming" something.
[02:38] <diogo> sorry but I downloaded the http://archive.ubuntu.com/ubuntu/pool/main/x/xorg/xorg_7.3+10ubuntu10.tar.gz and got no .diff.gz on the source
[02:38] <StevenK> diogo: Oh, you want xorg-server, not xorg
[02:38] <diogo> yes xorg-server
[02:38] <slangasek> now, if you're not actually going to make use of such help when it's offered, I don't see what you expect to get out of this channel for your trouble
[02:39] <StevenK> diogo: That link you pasted is 'xorg', though :-)
[02:39] <diogo> k
[02:39] <Hobbsee> diogo: there's a similarly named one there, in the correct directory, ending in .diff.gz - that's the one that contains the ubuntu changes.
[02:39] <diogo> k
[02:41]  * cody-somerville takes a deep breath and goes to bed.
[02:41] <hwilde> slangasek, ok thank you for confirming my suspicion that it just wasn't possible.  i'm blaming their wlan ids it's not ubuntu's fault
[02:41] <diogo> sorry to annoy again but... on http://archive.ubuntu.com/ubuntu/pool/main/x/xorg-server/ there is the patches for lots of versions but the <IP_ADDRESS> is not there the question is... which 1.4.1~git is the ne used on hardy?
[02:41] <hwilde> slangasek, I have to be absolutely sure before throwing down with customer IT
[02:42] <diogo> sorry
[02:42] <diogo> my mistake
[02:42] <diogo> already solved it
[02:42] <diogo> :)
[02:42] <diogo> thx
[02:42] <Hobbsee> :)
[02:42] <hwilde> slangasek, arguing with ubuntu-dev provides that level of confidence.    beyond a reasonable doubt and all that you know
[02:42] <slangasek> hwilde: well, I'm not saying that it's not possible; I'm saying that nothing in userspace on a pristine Ubuntu system does this
[02:42] <hwilde> it's not possible
[02:43] <hwilde> that's my story and i'm stickin to it
[02:43] <slangasek> ok; that's your statement. not mine. :)
[02:43] <hwilde> if nobody here can shoot holes in it then neither can the customer it group
[02:43] <hwilde> they lose.   ubuntu wins
[02:44] <hwilde> I logged the SSID every 5 seconds on all 5 clients today and send them the log file :)     over 38k entries and never once switched ssid's
[02:44] <ScottK-laptop> hwilde: Making stuff up and spreading it is not an Ubuntu win.  It needs to be accurate.
[02:45] <hwilde> so then what would you suggest... Intel says it's not their firmware
[02:45] <hwilde> I don't believe it's the ipw2200 module
[02:45] <hwilde> and it's nothing in ubuntu
[02:45] <hwilde> so their wlan ids are messed up
[02:45] <hwilde> only possible explanation
[03:06] <Hobbsee> right.  who broke thunderbird?
[03:07] <StevenK> Is the next line, "Come on, own up!"
[03:07] <ScottK-laptop> Hobbsee: That would be Mozilla Corp since we can only do stuff they say it OK.
[03:08] <Hobbsee> http://rafb.net/p/W8zgz343.html
[03:08] <ScottK-laptop> Because that's how Free Software <<<<<<< stupid corporate policies work.
[03:10] <RAOF> ScottK-laptop: being a grumpy old man in #ubuntu-* since 1782 ;)
[03:10] <RAOF> (Not that I disagree with the comment at all)
[03:11] <ScottK-laptop> Personally I think we compromised to much on that one.  It's Free as long as you make this other set of changes to change the branding, isn't freedom at all.
[03:12] <RAOF> Yeah.
[03:37] <kirkland> TheMuso: ping
[03:37] <TheMuso> kirkpong
[03:37] <kirkland> TheMuso: :-)
[03:37] <TheMuso> kirkland: PONG
[03:37] <kirkland> TheMuso: howdy, i'm working on bug #120375
[03:37] <kirkland> TheMuso: I just posted a pair of patches, one to mdadm, one to initramfs-tools
[03:38] <kirkland> TheMuso: actually, see the last 3 posts...  the one just before the pair of patches has a decent explanation
[03:38] <TheMuso> kirkland: You'd like me to look them over?
[03:38] <kirkland> TheMuso: I would, very much
[03:38] <kirkland> TheMuso: fwiw, kees pointed me in your direction ;-)
[03:38] <TheMuso> kirkland: Right, no problem.
[03:42] <TheMuso> kirkland: The initramfs-tools patch looks sane. Tooke me a bit to work out why you had to do things as you did, but I understand why so thats fine.
[03:42] <kirkland> TheMuso: can you think of any negative effects of executing the failure hooks code earlier?
[03:43] <kirkland> TheMuso: i certainly benefit from the positive effect of doing it earlier :-)
[03:43] <kirkland> TheMuso: but i was having a hard time thinking of negative effects....
[03:44] <kirkland> TheMuso: also, I remove the "-r" bit from the panic() call ...  the could perhaps go back in (calling the failure hooks in both places)
[03:46] <TheMuso> kirkland: The one problem I can think of that I still need to address in initramfs-tools is the issue where if usplash is used, no failure text is displayed when dumped to the initramfs. Having a separate call failure function makes implementing a solution for this a little more tricky.
[03:46] <TheMuso> To busybox I mean.
[03:46] <kirkland> hmm, how so?
[03:46] <TheMuso> Atm when crashing out of boot when usplash is used, you get an (initramfs) prompt, which is on tty8, and the error text is on tty1.
[03:47] <kirkland> TheMuso: panic -r will still call the failure function
[03:47] <kirkland> TheMuso: erg, that's messy
[03:47] <TheMuso> So we need to switch to tty1 before any text is displayed that the user needs to read.
[03:47] <kirkland> yeah
[03:48] <kirkland> TheMuso: so I see that initramfs-tools is in bzr; i should probably move my debdiff patch over to bzr branch, right?
[03:48] <TheMuso> kirkland: I have a solution in mind, but I need to run it by cjwatson and maybe others before doing it, as it involves putting chvt into the initramfs, and depending on console-tools or whatever package chvt is in.
[03:48] <TheMuso> kirkland: It is?
[03:49] <kirkland> https://launchpad.net/ubuntu/intrepid/+source/initramfs-tools/ makes it look like so
[03:49] <TheMuso> hrm I don't see anything.
[03:50] <kirkland> TheMuso: https://launchpad.net/initramfs-tools
[03:50] <kirkland> upstream anyway
[03:50] <kirkland> TheMuso: okay... the mdadm patch?
[03:51] <kirkland> TheMuso: any comments there?
[03:56] <TheMuso> kirkland: No looks fine.
[03:56] <kirkland> TheMuso: cool, thanks for looking them over
[03:57] <TheMuso> Sorry, my desktop is giving me a little grief atm. After several hours of use, I get an oops + segfaulting. There is something in linux htat I am using that is leaking memory which eventually causes issues. When I reboot and run memtest, memory looks bad, but when I switch off and on again, i.e no reset, everything is fine.
[03:58] <TheMuso> I am just about 100% sure its not hardware.
[04:00] <kirkland> TheMuso: ugh, that's no good
[04:01] <kirkland> TheMuso: out of curiosity, are you using wireless?  if so, which driver?
[04:01] <TheMuso> kirkland: No it isn't good, and no I am using wired, nm is removed. I am using nvidia drivers though, latest envy packaged ones, not from LRM.
[04:02] <kirkland> TheMuso: ah...  well, i'm getting a nasty hard hang if I download something large, and fast over my atheros wireless
[04:02] <TheMuso> Well I am on hardy as well.
[04:03] <kirkland> TheMuso: yep, this is hardy that i'm seeing this
[04:03] <TheMuso> Ouch.
[04:04] <kirkland> i've been meaning to try the ath5k driver
[04:06] <TheMuso> Well I am pretty sure its something X related for me, as I had this desktop running all last week during the sprint, and when SSHing to do stuff, never had this problem.
[04:43] <superm1> kirkland, did you have any luck with trying out that alternate tethering method?
[04:43] <kirkland> superm1: hadn't tried, sorry
[04:43] <superm1> ah okay
[04:43] <kirkland> superm1: been slammed ;-)
[05:19] <srbaker> heya folks
[05:19] <srbaker> is jeff waugh on this chan?
[05:19] <srbaker> or, better yet, anyone from Melbourne, AU?
[05:27] <Hobbsee> srbaker: he goes by jdub, but would be normally found in #slug.
[05:28] <srbaker> great, thanks
[05:28] <Hobbsee> wgrant: is from melbourne, but isn't here atm.
[05:28] <srbaker> ah, he's in sydney not melbourne
[05:28] <srbaker> although i guess anyone from .au is fine
[05:28] <srbaker> it's more cultural questions i have
[05:33] <Hobbsee> try #slug, then
[05:35] <srbaker> thanks
[06:16]  * NCommander investigates the possiblity of bootstrapping Ubuntu ARM
[06:40] <pitti> Good morning
[06:41] <Hobbsee> pitti!
[06:49] <nxvl> hi all
[06:49] <nxvl> Hobbsee: i have just saw your mail on -motu, it's sad to hear that your are going away
[06:49] <nxvl> Hobbsee: but i assume is for personal/time reasons an temporaly
[06:50] <nxvl> Hobbsee: so, have good look doing what you need to do and i hope you will be back soon
[06:50] <nxvl> :D
[06:50] <Hobbsee> nxvl: perhaps.  we'll see :)
[06:51] <nxvl> pitti: you don't even think on steping out, we will need like 100 people to replace you
[06:51] <nxvl> :P
[06:52] <pitti> nxvl: hm? did I say that anywhere?
[06:52] <pitti> (*blush*, thanks)
[06:52] <nxvl> pitti: no, just joking around
[06:52] <pitti> *phew* :)
[06:53] <nxvl> actually repeating a joke i heard on Prague
[06:53] <nxvl> :P
[06:53] <slangasek> about replacing pitti with the crew of a trireme?
[06:54] <nxvl> about how many people will need canonical to replace pitti
[06:55] <pitti> Let me assure you that I am just one person
[06:55] <nxvl> pitti: yes, but working as 40
[06:55] <nxvl> everywhere i try to jump in, someone (or something) mention you
[06:56] <nxvl> is like, you are everywhere
[06:57] <pitti> nxvl: thanks :)
[06:57] <nxvl> pitti: no, thank you for making my system better (almost every part of it)
[06:58] <saivann> +1
[06:58] <LaserJock> I'd like to +1 nxvl on that one
[06:59] <nxvl> yeah, we love pii
[06:59] <nxvl> pitti*
[06:59] <saivann> Sounds like pitti is really appreciated :)
[06:59] <nxvl> damn kayboard
[06:59] <nxvl> keyboard*
[06:59] <StevenK> There's another bug. Random Ubuntu developers seem to lose their 't' key
[06:59] <nxvl> saivann: yes, we love pitti
[06:59] <LaserJock> suuure, blame it on the keyboard
[06:59] <StevenK> kees, ScottK and now nxvl!
[07:01] <nxvl> well, i'm sleepy, and i may not pressing keys hard, also 't' key is in the middle where i need to move my fingers more to press it
[07:01] <pitti> StevenK: haven' noiced so far
[07:01] <nxvl> so it was just not a good pressing
[07:01] <slangasek> --> dvorak
[07:01] <StevenK> pitti: :-P
[07:01] <pitti> slangasek: I actually tried that for a couple of weeks, but my utterly slow response in IRC channels and everywhere else annoyed me so much that I gave up :/
[07:02] <pitti> you have to get "over the hump" with it, I guess
[07:02] <StevenK> slangasek: Did you move the keycaps as well?
[07:03] <nxvl> i have tried a french keyboard (don't remember what type was) and i almost died
[07:03] <slangasek> pitti: yes; I did this a decade ago when I was studying overseas and had a small laptop keyboard that was hurting my hands, and no work-related reasons to be typing :)
[07:03] <slangasek> StevenK: only during training
[07:04] <pitti> oh, and using dvorak in vim is quite confusing as well :/
[07:04] <pitti> I don't actually think about which letters to press most of the time, it's just muscle memory
[07:05] <pitti> so it'd take learning typing *and* controlling vim again
[07:05] <pitti> I think I'll teach my children dvorak straight away, to save them the hassle of switching :)
[07:05] <nxvl> heh
[07:05] <nxvl> yeah
[07:05]  * pitti crosses fingers that this i386 desktop test install will work now
[07:06] <nxvl> is a problem that you notices when some ask "what did you press to do that" and you actually don't know, your fingers just did it somehow
[07:06] <slangasek> right; there are probably vim remappings though, to let you use the keys in the same positions :)
[07:07] <slangasek> since the direction keys aren't so intuitive under dvorak
[07:12] <nxvl> i'm going to sleep
[07:12] <nxvl> read you!
[07:12] <nxvl> have a nice day!
[07:42] <snadge> does anyone happen to know if framebuffer is enabled on the xen kernel image?
[07:42] <snadge> i've spent hours stuffing around trying to get the graphics console to work.. as well as the standard xen serial console (which works)
[07:47] <snadge> i give up
[07:49] <snadge> i can see that framebuffer is compiled as a module.. but i just dont know enough about ubuntu or xen to know why its not working
[07:52] <pitti> siretart: ffmpeg-free was removed in Debian with "obsolete source package", but it's not obsolete in intrepid; what's the current structure supposed to be?
[07:52] <siretart> pitti: the same. intrepid already has 'ffmpeg-debian', which replaces 'ffmpeg-free'
[07:53] <siretart> pitti: good morning, btw :-)
[07:53] <pitti> siretart: but if I would remove ffmpeg-free, a lot of binary packages would go with it, such as libavutil-dev, libavformat52, etc
[07:53] <pitti> siretart: good morning! *hug*
[07:53]  * siretart hugs pitti back
[07:53] <siretart> pitti: err, they all are built by ffmpeg-debian as well
[07:54] <siretart> I don't quite understand why they should be removed?
[07:54] <siretart> ah, dependency wait
[07:55] <pitti> siretart: it seems that ffmpeg-debian isn't current, yes
[07:55] <siretart> libdc1394-22-dev is in universe
[07:55] <pitti> siretart: so I think the display is just confused, it will only remove the even older binaries
[07:55] <siretart> pitti: waht is the plan with libdc1394-22? it is supposed to replace libdc1394-13-dev AFAIUI
[07:55] <pitti> no idea, tell me :)
[07:56] <siretart> well, I was told that it is the new version of firewire libs
[07:56] <siretart> so fabian, my co-maintainer in debian decided to switch to the new libs. I tried to make the package usable against both version, but that caused subtle breakage
[07:56] <siretart> so we fixed the dependencies to the new version
[07:58] <siretart> I don't really have a clue about firewire and libs, but I suspect that it might be a good idea to replace the source package libdc1394-13/main with libdc1394-22/universe
[07:58] <siretart> replace in terms of 'promote -22' and 'demote -13' in exchange
[07:59] <siretart> BenC: can you comment/clarify the situation of libdc1394-22 vs libdc1394-13?
[08:04] <pitti> siretart: yes, I guess this makes sense; however, I'll  do that after alpha-3, just to be sure
[08:08] <pitti> argh, since today's dist-upgrade, seahorse/ssh doesn't work any more -- "Agent admitted failure to sign using the key."
[08:09] <pitti> does that happen to anyone else?
[08:09] <RAOF> pitti: That kindof happens to me; if I try to connect via cooperteam.net it says that, but everything works using raof.local, which refers to the same box.
[08:17] <pitti> siretart: I promoted -22, so that ffmpeg-debian can build
[08:27] <siretart> pitti: thanks!
[08:36] <cjwatson> kirkland: https://wiki.ubuntu.com/BzrContributorHowto
[08:36] <cjwatson> TheMuso: just turn on chvt in the busybox initramfs config?
[08:37] <cjwatson> kirkland: but, as TheMuso implied, I don't think that our initramfs-tools is in bzr; AFAIK (not having checked recently) the one on LP is old, from before upstream moved to git
[08:38] <davmor2> My blog post on planet about how non-devs can get involved seems to of attracted an artist who can I put them onto?
[08:39] <Tm_T> davmor2: #ubuntu-artwork ?
[08:39] <davmor2> cool thanks
[08:50] <Sianis_> mvo: are you here?
[08:51] <mvo> Sianis_: yes
[08:51] <Sianis_> great
[08:51] <Sianis_> can we talk in private or stay here?
[08:54] <Sianis_> mvo:
[08:54] <Sianis_> 1. was the potmodify.py usefully?
[08:54] <Sianis_> 2. can you put it in the brz branch?
[08:54] <mvo> Sianis_: both is fine
[08:54] <snadge> can i try booting the intrepid xen kernel on hardy?
[08:54] <mvo> Sianis_: I think its useful, I have the diff here locally, I have not reviewed it yet but I will do that today
[08:55] <snadge> i've wasted all day trying to figure out why i cant get hardy to output anything on xens graphical framebuffer.. it just comes up black
[08:58] <snadge> fine.. i'll try using opensuse 11's xen kernel
[09:07] <snadge> ok it doesnt boot as you would expect but at least i get graphics
[09:16] <snadge> would a kernel from debian sid work with ubuntu? :P
[09:17] <tkamppeter> pitti, hi
[09:21] <asac> siretart: what do you think are the chances that upstream will make pcsc-lite pluggable?
[09:23] <pitti> hi tkamppeter
[09:25] <asac> tkamppeter: the thing i mentioned during sprint is debian bug 282235 ... the decision to drop that from cups made lexmark z4X printers unusable on debian iirc.
[09:25] <asac> by coincident my RFP was closed yesterday .. thats why i remember now
[09:25] <asac> (auto-closed)
[09:26] <tkamppeter> pitti, I have seen in the debian/changelog that you are rather active on HAL.
[09:27] <pitti> yes, indeed I am
[09:27] <tkamppeter> pitti, HAL needs a little change, in preparation for CUPS 1.4 and also to work better together with HPLIP.
[09:27] <pitti> emgent: sorry for the double rapache reject; at first I rejected the wrong (newer) version instead of the older one; I'll fish out the newer one from rejected, reviewing now
[09:28] <pitti> tkamppeter: sure, which?
[09:28] <tkamppeter> pitti, for HAL a USB printer is present when coupled to the usblp character device.
[09:29] <tkamppeter> HPLIP and CUPS 1.4 use libusb to access USB printers. HPLIP uncouples the printers from the usblp module, letting them disappear for HAL. Same can occur also with CUPS 1.4.
[09:30] <pitti> hm, going from kernel driver to raw device access? that direction sounds backwards to me ...
[09:31] <pitti> ember: oh, it's justified after all, I'll mail you
[09:33] <tkamppeter> pitti, we have to follow upstream here. It seems that for modern printers with ink level readout, and multi-function stuff like scanning a character device is unadequate.
[09:33] <pitti> tkamppeter: right; is there a hal patch already for this?
[09:35] <tkamppeter> pitti, no, but printer detection without usblp is no problem, as the hp CUPS backend and the new usb CUPS backend do it. Also reading out the device ID without the usblp module is no problem.
[09:36] <tkamppeter> pitti, after some transition period the usblp module could probably even get removed from the kernel, like the scanner module.
[09:36] <pitti> tkamppeter: but the printers should appear as USB devices/interfaces in hal even right now, even if they aren't associated to usblp
[09:36] <pitti> don't they?
[09:37] <tkamppeter> pitti, I think I tested once and they did not. Try blacklisting the usblp module and see whether printers get still detected by HAL.
[09:37] <pitti> that would be weird; they will certainly not appear as printers, but the devices should still be there
[09:37] <pitti> tkamppeter: can't do right now, I don't have a printer here
[09:38] <pitti> tkamppeter: maybe you can do an lshal with and without usblp and pastebin the diff -u ?
[09:38] <tkamppeter> pitti, if HAL is correctly set up for detecting printers without usblp, hal-cups-utils should get triggered even with usblp blacklisted.
[09:38] <pitti> tkamppeter: right, I guess hal-cups-utils looks for the "printer" capability
[09:38] <pitti> I guess that's the one which is missing if usblp is not loaded
[09:39] <tkamppeter> pitti, you are Debian maintainer of CUPS and do not own a printer? Should I organize a printer for you?
[09:39] <pitti> tkamppeter: I have one, but not right now
[09:40] <pitti> tkamppeter: according to "modinfo usblp|grep alias", printers can be identified with some particular interface classes and device classes; so it should be easy to set up an fdi rule which does the same
[09:40] <pitti> (FYI)
[09:40] <pitti> tkamppeter: but to confirm this, can you please do the lsusb diff?
[09:40] <tkamppeter> pitti, yes, I think it is this way, the "printer" capability comes from the usblp module.
[09:40] <tkamppeter> pitti, I will send you the diff.
[09:41] <tkamppeter> asac, was z42_cmyk ever packaged for Debian and later dropped?
[09:42] <pitti> tkamppeter: confirmed, current code looks at the sysfs path; if it ends with lp%d, it sets "printer" capability
[09:42] <asac> tkamppeter: yes. it was working at some point. the cups maintainer (not sure who he was) said it was dropped from cups and i should file a RFP ;)
[09:51] <tkamppeter> asac, the upstream CUPS package never contained drivers for Lexmark printers.
[09:51] <tkamppeter> pitti, did the Debian CUPS package ever contain any third-party drivers, like the z42_cmyk driver?
[09:52] <pitti> tkamppeter: I don't know personally; not in my times (but the changelog should tell)
[09:52] <tkamppeter> asac, in general, at least for Ubuntu, we do not ship Foomatic data for which we do not ship the appropriate driver executable. I do not know whether Debian has overtaken this from us.
[09:54] <tkamppeter> asac, the best would be if some volunteer would make an LSB package of the z42_cmyk driver and so distros do not need to hassle with drivers for old printers. These drivers would be auto-downloaded when needed (at least from Intrepid on).
[09:55] <pitti> doko: E: cacao-oj6-jre: no-copyright-file
[09:57] <liw> http://paste.ubuntu.com/30236/ -- would anyone like to give that a quick review and tell me if there's things in there they don't understand? it's the draft manpage for the system-cleaner tool I'm writing
[09:57] <tkamppeter> pitti, biff
[09:57] <cjwatson> liw: typo in first line ;-)
[09:58] <cjwatson> liw: (might want to format that with LANG=C to avoid Unicode that I'm guessing pastebin doesn't understand
[09:58] <cjwatson> )
[09:58] <liw> cjwatson, "administration", check
[09:58] <liw> cjwatson, good point
[09:58] <cjwatson> seems comprehensible to me but of course I already know what it does
[09:59] <pitti> doko: oh, so all the other packages have a symlink of their entire /usr/share/doc/package -> cacao-oj6-jre, and that one doesn't have any /usr/share/doc...
[09:59] <liw> http://paste.ubuntu.com/30238/ -- now without unicode (I hope)
[10:00] <liw> cjwatson, yeah, it's superbly clear to me, too :)
[10:02] <afflux> liw: I think I understand it.
[10:02] <liw> afflux, cool! based on the manual page, does it sound like something that you would try to use?
[10:03] <afflux> definetly. I use my system mostly for playing around, so it might help in some situations.
[10:03] <tkamppeter> pitti, asac, according to the changelog Debian's CUPS package never shipped third-party drivers.
[10:04] <tkamppeter> pitti, I have sent the diff of the lshal output to you by e-mail.
[10:06] <asac> tkamppeter: so why did it work out-of-box before i filed that bug?
[10:06] <mvo> tseliot: could you please have a look at http://launchpadlibrarian.net/16297761/buildlog_ubuntu-intrepid-i386.update-manager_1%3A0.92_FAILEDTOBUILD.txt.gz ? it looks like nvidia-common has a undeclared dependency on lspci
[10:07] <mvo> tseliot: btw, is nvidia-common in bzr yet?
[10:07] <liw> afflux, thanks
[10:07]  * liw goes to commit the manpage into bzr, then
[10:07] <pitti> tkamppeter: hm, weird that it disappears entirely
[10:07] <tkamppeter> asac, this is also strange for me. Can it be that Debian had some driver collection package in former times which they have dropped?
[10:08] <tseliot> mvo: yes it's in bzr and you have your own branch there
[10:08] <pitti> tkamppeter: I guess a hal debug output is in order (https://wiki.ubuntu.com/DebuggingHal), i. e. what happens in hal if you plug in a printer in both cases
[10:08] <mvo> meh, right :)
[10:08] <tkamppeter> pitti, what do you mean? The printer entry in the diff? Or the z42_cmyk driver in Debian?
[10:08]  * mvo coughs
[10:08] <pitti> tkamppeter: can do this later, or if you have time, feel free to do it now
[10:08] <pitti> tkamppeter: the usblp issue
[10:08] <tseliot> mvo: you're right about lspci, since nvidia-common needs it to perform hardware detection
[10:09] <mvo> tseliot: you mind if I fix it and upload a new version?
[10:09] <tseliot> mvo: do you want to add a dependency or change the code?
[10:10] <mvo> tseliot: I add a dependency
[10:10] <tseliot> mvo: ok, then it would be great if you could do it
[10:10] <tkamppeter> pitti, trying the HAL debugging stuff ...
[10:10] <mvo> tseliot: or do you think having conditional code in it is better?
[10:11] <tseliot> mvo: nvidia-common relies on hardware detection therefore it's useless without lspci
[10:11] <mvo> tseliot: yeah, that is what I thought. execellent, you can merge from me
[10:11] <pitti> NEW queue empty \o/
[10:11] <DktrKranz> pitti: I noticed you synced e2fsprogs. It still build-depends on dietlibc though, which is in universe. Are there plans to ship dietlibc in main or should e2fsprogs not bdepend on it?
[10:12] <pitti> DktrKranz: ah, no, I don't think we want dietlibc; thanks for pointing out
[10:12] <DktrKranz> pitti: if you want, I can look at it, it shouldn't be that hard
[10:13] <tseliot> mvo: shall I merge right now or will you ping me later with the fix?
[10:14] <doko> pitti: looking ...
[10:15] <mvo> tseliot: you can merge now
[10:16] <pitti> DktrKranz: oh, that would be nice
[10:17] <tseliot> mvo: bzr tells me "Nothing to do". I did a "bzr merge http://bazaar.launchpad.net/~mvo/nvidia-common/mvo/"
[10:17] <pitti> tseliot: note that http:// takes some 5 minutes to catch up
[10:17] <pitti> tseliot: try lp:~mvo...
[10:18] <tseliot> pitti: no dice
[10:18] <pitti> hm, maybe mvo forgot to push then?
[10:19] <doko> pitti: wrong reject, the docs are in the -headless package
[10:20] <pitti> lrwxrwxrwx root/root         0 2008-07-23 18:08 ./usr/share/doc/cacao-oj6-jre-headless -> cacao-oj6-jre
[10:20] <pitti> ^ in cacao-oj6-jre-headless_6b11-0ubuntu2_i386.deb:
[10:21] <tseliot> mvo: did you use some other branch I'm not aware of?
[10:21] <doko> pitti: in -headless:
[10:21] <doko> drwxr-xr-x root/root         0 2008-07-23 19:08 ./usr/share/doc/cacao-oj6-jre/
[10:21] <doko> -rw-r--r-- root/root       897 2008-07-23 19:07 ./usr/share/doc/cacao-oj6-jre/JAVA_HOME
[10:21] <doko> -rw-r--r-- root/root       415 2008-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/README.Debian
[10:21] <doko> -rw-r--r-- root/root       840 2008-07-23 19:07 ./usr/share/doc/cacao-oj6-jre/README.alternatives
[10:21] <doko> -rw-r--r-- root/root       611 2008-07-23 07:26 ./usr/share/doc/cacao-oj6-jre/NEWS.IcedTea.gz
[10:21] <doko> -rw-r--r-- root/root<PHONE_NUMBER>-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/copyright
[10:21] <doko> -rw-r--r-- root/root       951 2008-05-31 08:46 ./usr/share/doc/cacao-oj6-jre/AUTHORS.IcedTea
[10:21] <doko> -rw-r--r-- root/root      6975 2008-07-23 18:29 ./usr/share/doc/cacao-oj6-jre/changelog.Debian.gz
[10:21] <doko> -rw-r--r-- root/root      2556 2008-07-23 07:26 ./usr/share/doc/cacao-oj6-jre/README.IcedTea.gz
[10:21] <mvo> tseliot: oh, sorry. the branch was not bound yet, it should be fine now
[10:21] <pitti> doko: -headless contains /usr/share/doc/cacao-oj6-jre/ ? that's even weirder...
[10:22] <pitti> but *shrug*
[10:22] <doko> pitti: nothing weird, some in openjdk-6 (-jre-headless did appear after -jre)
[10:23] <pitti> doko: ok, accepted
[10:23] <doko> cacao-oj6 is just a copy of the packaging
[10:25] <tseliot> mvo: merged and pushed. Thanks
[10:25] <tkamppeter> pitti, HAL debug output in mail
[10:43] <DktrKranz> pitti: re e2fsprogs, bug 251746 if you have some time. FYI, I uploaded e2fsprogs on my PPA, it has just been built.
[10:49] <pitti> DktrKranz: thanks a lot! will do in a bit
[10:51] <pitti> DktrKranz: uploaded
[10:51]  * DktrKranz hugs pitti
[10:51]  * pitti hugs DktrKranz back
[11:09] <gnomefreak> is there a way to enalbe all 4 virtual desktops anymore?
[11:10] <tkamppeter> pitti, did you have a look into my usblp specs?
[11:10] <tkamppeter> s/specs/logs/
[11:11] <pitti> tkamppeter: I'm in a phone conf
[11:12] <tkamppeter> pitti, sorry, I saw you talking all the time here on IRC.
[11:12] <tjaalton> ok, compiz on i965 should be fixed now upstream. do other drivers see corruption (wrong colors) on effects like opening the right-click menu on the desktop?
[11:13] <tjaalton> ie. fade-in/fade-out colors are wrong
[11:34] <siretart> asac: I don't think that Jouni (upstream is basically a one man show) will invest energy in creating that patch himself.
[11:34] <siretart> asac: however AFAIU his email, depending on how the patch is written, he is likely to accept, integrate and support it
[11:34] <siretart> asac: my personal feeling is that we have less efford by proting pcsc-lite
[11:35] <siretart> asac: my personal feeling is that we have less efford by promoting pcsc-lite
[11:42] <pitti> tjaalton: -all still depends on -via, but -via is NBS
[11:43] <pitti> tjaalton: oh, sorry, it's just an alternative
[11:43] <tjaalton> pitti: openchrome | via :)
[12:00] <tkamppeter> pitti, finished the telecon?
[12:13] <asac> pitti: ok. so given what siretart said, can you look at the partial MIR for pcsc-lite?
[12:24] <pitti> tkamppeter: hal-log-without-usblp.txt is 0 bytes, hmm; can you send that one again?
[12:29] <snadge> who looks after xen?
[12:31] <snadge> nobody? :P
[12:32] <pitti> asac: ok, promoting
[12:34] <pitti> snadge: try asking zul
[12:35] <pitti> I'm offline for a bit to reinstall my laptop, bbl
[12:35] <soren> snadge: #ubuntu-xen?
[13:06] <asac> pitti: you rock
[13:06] <asac> siretart: ^^
[13:11] <tkamppeter> pitti, it seems to be not possible any more. I do
[13:11] <tkamppeter> sudo hald --verbose=yes --daemon=no 2>&1 | tee /tmp/hal.log
[13:11] <tkamppeter> I get the screen full of messages and /tmp/hal.log has always 0 bytes. tee turned to a no-op
[13:12] <tkamppeter> pitti, I retry without tee
[13:13] <ScottK> pitti: (see I found the 't' key this time) Thanks for all the backports.
[13:15] <tkamppeter> pitti, here it is, I am approaching slowly ...
[13:17] <tkamppeter> pitti, the new usb backend of CUPS 1.4 (http://svn.easysw.com/public/cups/trunk/backend/usb-libusb.c) checks the interface class, whether it is 7 (USB_CLASS_PRINTER, /usr/include/usb.h).
[13:19] <tkamppeter> With HAL one can do this, too. see lshal-without-usblp.txt, section starting with "udi = '/org/freedesktop/Hal/devices/usb_device_3f0_7317_CNK2N34563_if0'", line "usb.interface.class = 7  (0x7)  (int)".
[13:20] <tkamppeter> pitti, only thing missing in the lshal output without usblp is the device ID, hal_lpadmin script could poll it from the printer.
[13:21] <tkamppeter> The new USB CUPS backend also polls the device ID from the printer.
[13:22] <tkamppeter> pitti, using libusb
[13:23] <siretart> asac: pitti :)
[13:24] <asac> anyone here with a b43 wifi driver on intrepid?
[13:30] <Nikratio> Is there some python-apport guy around here?
[13:31] <mvo> anyone here with plenty of diskspace and a kvm capable machine who would want to test the sandbox-upgrader? http://launchpadlibrarian.net/16299860/sandbox-upgrader_0.1%2Bbzr20080724-0ubuntu1%7Eppa1_all.deb
[13:55] <BenC> siretart: No idea off hand
[14:15] <pitti> re
[14:15] <pitti> so, that went reasonably well, aside from my network connection being painfully slow ATM
[14:16] <pitti> tkamppeter: did you manage to get the hal log in the end?
[14:16] <pitti> tkamppeter: you sent me one, I wonder why it worked once, but not the second time...
[14:16] <pitti> tkamppeter: right, adding the capability based on device class shouldn't be a problem
[14:17] <pitti> tkamppeter: however, it concerns me that the entire device disappears
[14:27] <seb128> ogra: there?
[14:28] <pitti> seb128: is it just me, or did seahorse's ssh agent get broken for you today, too? I get "Agent admitted failure to sign using the key"
[14:28] <seb128> pitti: iz gnome-keyring agent and gnome bug #544554
[14:28] <pitti> seb128: merci!
[14:28] <seb128> de rien ;-)
[14:30] <tkamppeter> pitti, I have sent you a new version. Try that one.
[14:31] <tkamppeter> See also my e-mail about printer detection without usblp.
[14:33] <DktrKranz> seb128: is it related to gnupg agent too?
[14:33] <seb128> DktrKranz: what gnupg agent, what too?
[14:34] <cjwatson> ogra: openssh 5.1p1 in intrepid now, enjoy
[14:34] <seb128> gnome-keyring doesn't do gpg agent if that's the question
[14:35] <DktrKranz> seb128: seahorse-agent is not working, it was moved to another source package (I read it from your changelog entry), I though it was related to the gnome bug above
[14:35] <seb128> DktrKranz: there is no seahorse-agent in intrepid
[14:35] <seb128> but no
[14:36] <seb128> gnome-keyring does ssh agent and it's installed correctly
[14:36] <DktrKranz> ok, I'll try to figure out what's wrong here, thanks
[14:41] <seb128> yeah, upstream xrandr capplet code landing in intrepid, we will be able to reduce delta and send bugs upstream now ;-)
[14:45] <pitti> seb128: is that similar to our's?
[14:45]  * pitti likes the current capplet
[14:46] <pitti> or did our's went upstream? (I hope)
[14:46] <seb128> pitti: yes
[14:46] <seb128> well, technical it's rh's capplet
[14:46] <seb128> they did 95% of the job
[14:46] <seb128> we just used their patch for hardy, integrated and fixed some issues
[14:46] <seb128> they landed that upstream now
[14:57] <pitti> ArneGoetje: ah, seems I forgot to drop the ispell dictionaries from *-support-writing; doing now
[14:57] <tkamppeter> pitti, upstream bug #1 (or better feature request) on hal-cups-utils reported: https://fedorahosted.org/hal-cups-utils/ticket/1
[14:58] <pitti> bug #1! wow
[14:59] <doko> infinity, tjaalton: see https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b11-2ubuntu1/+build/676462  now the first xvfb-run succeeds, the second doesn't ...
[14:59] <pitti> tkamppeter: nice, thanks
[15:01] <tkamppeter> pitti, but do not think that hal-cups-utils is perfect software, free of bugs. Tim Waugh moved it from his private box to fedorahosted only 1 week ago.
[15:02] <tkamppeter> pitti, as you are more HAL expert than me, your patch for 10-hal_lpadmin.fdi is welcome.
[15:03] <pitti> tkamppeter: I'll get to that; it's probably best if I try and fix that locally
[15:04] <pitti> ArneGoetje: done
[15:04] <kirkland> pitti: good morning!  i was wondering if there's anything else need by me on the MIRs for opencryptoki, and ultimately ecryptfs?
[15:05] <pitti> kirkland: I haven't taken a look at MIRs for three days or so, sorry
[15:05] <pitti> kirkland: I'll get to it, promised
[15:05] <kirkland> pitti: ;-)  okay, no problem.... i thought someone told me fridays were MIR days, so I've been waiting until today to ask :-)
[15:06] <pitti> kirkland: friday is my archive day; for MIRs there's no magic day usually :)
[15:06] <kirkland> pitti: ah, gotcha :-)
[15:08] <kirkland> doko: did you have a chance to take another look at opencryptoki?  i comprehensive replaced all of the hardcoded 2048 path elements with a #define'd global
[15:08] <doko> oops, yes, the week didn't end yet ;)
[15:09] <kirkland> doko: :-)
[15:17] <pitti> seb128: FYI, ronne has good intrepid chroots now (thanks lamont!), I moved the retracers into intrepid dchroots; that should stop the crashes in the intrepid fakechroots
[15:18] <seb128> pitti: oh, excellent, thanks!
[15:18] <seb128> pitti: btw, sent a gnome-panel SRU your way, ogra was waiting on it, he needs to ability to prevent gnome-panel moves by dnd for some devices where is create issues
[15:20] <kirkland> hi seb128, can you take a look the patch for https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/251375 ?
[15:21] <seb128> kirkland: hi, not today, I'm officially on holiday so I try to not get caught it too many things, trying to catch up on SRU waiting and stop working then
[15:21] <kirkland> seb128: gotcha, have fun ;-)
[15:21] <seb128> thanks
[15:21] <seb128> (do we really need a status action there?)
[15:22] <seb128> (otherwise patch seems to be good)
[15:22] <kirkland> seb128: we're trying to add that to as many init scripts as possible
[15:22] <kirkland> seb128: at least those with daemons
[15:23] <kirkland> seb128: we're focusing on sever pacakages, but an enterprising volunteer from the community decided to patch gdm
[15:23] <seb128> alright, I don't see that being really useful but it doesn't hurt either
[15:23] <kirkland> seb128: we're trying to 'encourage' community participation on this one ;-)
[15:23] <seb128> right :-)
[15:24] <kirkland> seb128: thx!
[15:24] <seb128> I'll include it in the next upload, commenting on the bug to say that now
[15:24] <pitti> seb128: 90_from_svn_fix_random_position_changes.patch
[15:24] <pitti> seb128: ... looks weird; what does that do?
[15:24] <pitti> seb128: by default we have both a top and a bottom panel
[15:24] <kirkland> cjwatson: I took a different approach with the usplash_write EACCES error, was wondering if you could review
[15:24] <pitti> so it seems to 'unconfigure' one and 'configure' the other?
[15:24] <cjwatson> kirkland: ok, where?
[15:25] <kirkland> cjwatson: https://bugs.launchpad.net/bugs/251656
[15:25] <seb128> pitti: it fixes typos in the key names
[15:25] <seb128> pitti: top was used at some place for bottom config, probably extra copy or something
[15:25] <pitti> seb128: so there is no 'top_panel' really?
[15:26] <seb128> pitti: there is, but that's a different section which was correct and doesn't need to be changed
[15:26] <cjwatson> kirkland: I'm not sure, personally I'd prefer changing usplash_write to avoid discarding other error messages
[15:26] <pitti> seb128: ok
[15:26] <kirkland> cjwatson: ah, really?  okay, no problem.... i have that patch too :-)
[15:26] <seb128> pitti: I expect bottom has been made by copying the top config and they forgot to change some instances
[15:26] <cjwatson> kirkland: but I don't seriously object to either I suppose, it's just that as a general rule 2>/dev/null should be wielded with caution
[15:26] <seb128> pitti: the patch comes from upstream and has been verified working in intrepid already
[15:26] <pitti> argh
[15:26] <kirkland> cjwatson: to me, it's really a difference of who decides to throw away that message
[15:26] <seb128> pitti: arg?
[15:26] <pitti> seb128: I already set the bugs as "accepted", but actual acceptin gfails
[15:27] <kirkland> cjwatson: either done across the board with upslash_write itself
[15:27] <cjwatson> kirkland: not really, the lsb patch throws away all possible errors
[15:27] <kirkland> cjwatson: or letting the caller decide
[15:27] <pitti> seb128: FAILED: gnome-panel (The source gnome-panel - 1:2.22.2-0ubuntu2 is already accepted in ubuntu/intrepid and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
[15:27] <cjwatson> kirkland: the usplash_write patch throws away that one specific error
[15:27] <seb128> urg
[15:27] <kirkland> cjwatson: hmm, that's true too
[15:27] <seb128> pitti: changing the version and reuploading
[15:27] <pitti> seb128: 1:2.22.2-0ubuntu1.1 plz :)
[15:27] <cjwatson> kirkland: depends whether you're confident that nobody will ever have to debug any other problem with usplash_write, really :)
[15:27] <kirkland> cjwatson: okay, let me brew some coffee, and I'll post the patch to usplash write
[15:27] <kirkland> cjwatson: :-P
[15:28] <seb128> pitti: uploaded
[15:28] <Riddell> mvo: do we allow utf8 in package descriptions?
[15:28] <cjwatson> we *mandate* UTF-8 in package descriptions, IIRC ;-)
[15:29] <Riddell> good, lots of twiddly characters in this language name
[15:30] <cjwatson> actually policy 3.8.0 doesn't say
[15:30] <cjwatson> I guess it depends whether ddtp will explode
[15:32] <pitti> seb128: oh, F***, in the intrepid dchroot the hardy fakechroot doesn't work any more; switching back to hardy dchroot then, and we'll live with the segfaults (they shouldn't hurt too much, just break fakechroot upgrades every now and then)
[15:33] <kirkland> cjwatson: okay, new patch attached to https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/251656
[15:48] <pitti> hm, seems that compiz forgot how to virtual display desktops in several rows (2 by 2 instead of 4 by 1)
[15:49] <seb128> pitti: ccsm, preferences, make sure you are using the gconf backend there
[15:50] <pitti> hm, installing
[15:50] <seb128> pitti: it likely fallbackend to the text one, which breaks the layout and the shortcuts to switch workspaces
[15:50] <pitti> is that compizconfig-settings-manager or simple-ccsm?
[15:51]  * pitti keeps getting confused about these two
[15:52] <seb128> compizconfig-settings-manager but simple-ccsm is the recommended one nowadays
[15:52] <seb128> I still have ccsm installed and I don't know if you can change the backend using the other one
[15:52] <seb128> but you can try ;-)
[15:52] <pitti> I installed c-c-s-m now
[15:53] <pitti> seb128: right, it seems to have forgotten all my settings (focus-follows-mouse, too, etc.)
[15:53] <pitti> and keybindingd
[15:54] <seb128> pitti: what backend is used? click on preferences in the sidebar to get the option tab
[15:55] <pitti> ah, there, I was still searching
[15:55] <pitti> right, text
[15:55] <seb128> change to gconf
[15:55] <pitti> hah fun, that did it
[15:56] <pitti> my ws switcher looks funny now, but I guess a session restart will do
[15:56] <pitti> seb128: btw, where does it save *that* setting (text/gconf); in gconf? :-)
[15:57] <seb128> pitti: .config/compiz/compizconfig/config
[15:57]  * pitti hugs seb128
[15:57] <pitti> hush, hush, you are on holiday!
[15:57]  * seb128 hugs pitti
[15:58] <seb128> pitti: going to upload a gvfs sru too, I didn't start on the computer before 3pm so that's alright ;-)
[16:00] <pitti> sebner: for your amusement: workspace switcher in a workspace switcher: http://people.ubuntu.com/~pitti/tmp/ws.png :)
[16:01]  * ion_ ewws the blurry font
[16:01] <pitti> sebner: sorry, tab error
[16:01] <pitti> seb128 already offline...
[16:02] <pitti> ion_: what's wrong with it?
[16:02] <seb128> pitti: no, just restarted GNOME to try this gvfs update
[16:03] <ion_> pitti: The blur. :-) As long as our monitors’ resolutions are what they are now, partially translucent subpixels should be avoided where possible.
[16:03] <seb128> pitti: gvfs sru sent your way now
[16:04] <pitti> seb128: for your amusement: workspace switcher in a workspace switcher: http://people.ubuntu.com/~pitti/tmp/ws.png :)
[16:04] <seb128> pitti: lol, try switching between no desktop effects and normal again
[16:04] <pitti> seb128: nah, that will again destroy the placing of all my windows
[16:04] <pitti> seb128: I guess it'll fix itself on next login
[16:05] <seb128> could do
[16:05] <seb128> otherwise do what I said
[16:05] <seb128> the compiz workspace to viewport conversion code still has some bugs
[16:15] <mvo> Riddell: utf-8 should be fine, that is what ddtp uses too
[16:23] <joaopinto> Hello, I am working on package for wich the software is distributed under GPL-2, and the artwork under FAL (Free Artwork License), is this latest license accepted for universe ?
[16:26] <cjwatson> link for the FAL?
[16:26] <cjwatson> is this http://artlibre.org/licence/lal/en/ ?
[16:26] <joaopinto> yes
[16:27] <joaopinto> well, v1.2 on this software
[16:28] <cjwatson> joaopinto: having looked at 1.3, I *think* it's OK
[16:28] <cjwatson> feel free to upload it, and if the archive admin on duty is unhappy with it they'll speak to you
[16:29] <joaopinto> ok thanks :)
[16:31] <kirkland> cjwatson: did that usplash_write patch look better to ya?
[16:55] <Milyardo> ls
[17:13] <devfil> when will archives be resynced?
[17:24] <cr3> Keybuk: upstart question for you: is there a way to set a delay so that a command is run after everything has been initialized?
[17:24]  * cr3 needs to jet, brb
[17:27] <Keybuk> cr3: -v
[17:31] <LucidFox> Why aren't packages being moved from ACCEPTED to DONE?
[17:31] <cjwatson> devfil: err ...?
[17:31] <cjwatson> the publisher is still apparently running
[17:31] <cjwatson> oh, huh, seems to be stuck on a lock
[17:32] <cjwatson> -r--r--r-- 1 lp_publish lp_publish 1 Jul 25 08:03 /srv/launchpad.net/ubuntu-archive/cron.daily.lock
[17:32] <LucidFox> can it be reset?
[17:32] <cjwatson> it is in fact still running, WTF
[17:32] <cjwatson> LucidFox: anything *can* be done, I'm trying to figure out what's a good idea ;-)
[17:45] <cjwatson> LucidFox: I've killed it, but can't guarantee it will work next time
[18:05] <gaspa> pitti: added recommends and lpia to nbs handling.
[18:19] <kees> jdstrand: I'm going to shove my font bolding patches into vte.
[18:19] <jdstrand> sounds good to me
[18:30]  * ogra hugs cjwatson
[18:34] <cr3> Keybuk: to be more verbose on my query about running an upstart event later, I think my script is failing because dbus wasn't initialized first. so, I added a 10 second delay before running my script and it works but I'm wondering if there's a better way
[18:36] <Keybuk> cr3: what is your script?
[18:38] <cr3> Keybuk: hwtest which, if preseeded to do so, can potentially run at startup
[18:38] <cr3> Keybuk: or did you want everything I defined for my event at the exec line?
[18:38] <Keybuk> it uses dbus?
[18:39] <cr3> Keybuk: well, it gathers information through hal which, in turn, uses dbus
[18:39] <Keybuk> right
[18:39] <Keybuk> when do you run it?
[18:39] <cr3> runlevel 2 and 3
[18:40] <Keybuk> start on runlevel [23] ?
[18:40] <cr3> Keybuk: exactly
[18:40] <Keybuk> that won't work so well
[18:40] <Keybuk> but I guess you know that, which is why you're asking me ;)
[18:41] <cr3> Keybuk: right, I don't understand how I can determine when it would be proper for the script to run
[18:41] <Keybuk> start on stopped rc[23]
[18:42] <cr3> Keybuk: aha! now I understand, that'll run after the respective rc scripts have run. so, since there's an S12dbus, I should be good to go
[18:42] <cr3> err, an S12dbus for rc2
[18:43] <Keybuk> exctkly
[18:44] <cr3> Keybuk: cheers man, glad I used upstart rather than init :)
[18:57] <kees> slangasek: based on the discussions about openssl, it sounds like "drop sslv2 support and wait for complaints" is the consensus?  if you agree, I'll upload ivoks's patch...
[18:57] <slangasek> kees: yes, that's fine with me
[18:57] <slangasek> not that my agreement is necessarily a yardstick for "consensus" :)
[18:58] <kees> slangasek: true, but for the people involved in the discussion, it seemed like you were the last to have stronger hesitations.
[18:59] <emgent> heya
[19:02] <infinity> kees: Well, as pointed out, gnutls already doesn't support it, so parts of the distro are already gimped in that fashion (like OpenLDAP), so may as well make the gimping complete and consistent.
[19:03] <kees> infinity: yeah, I agree.
[19:03] <infinity> kees: I can't see making a strong argument for "OpenLDAP shouldn't support old protocols, but Apache should".
[19:03] <infinity> (Seriously, anyone connecting to apache with Mosaic can die)
[19:04]  * Darklock prefers the Mosaic Killer :-D
[19:05] <infinity> Or, more realistically, anyone who still has Mosaic, IE3.0, NS2.0, whatever, can probably figure out how to download a newer browser over plain HTTP, so they can then use HTTPS. :)
[19:05] <infinity> (Which isn't actually as easy as it sounds... I installed NT4.0 for kicks a couple of years ago and discovered that IE3.0 really can't render anything well enough to even FIND a new browser, and had to resort to ftp.exe)
[19:07] <broonie> ~6 years ago it was a struggle convincing it to talk to the MS update site to install any security or other updates :/
[19:14] <sommer> slangasek: just fyi, I merged your changes and re-worked the samba file and print sections to not use security=share... I appreciate your feedback
[19:14] <slangasek> sommer: great, thanks for your work :)
[19:15] <sommer> slangasek: also, you mentioned that enabling acls doesn't require a remount, but I only see the option in the tune2fs man page as a mount option.  am I missing something?
[19:15] <slangasek> sommer: oh, it's possible that it still requires a remount to be seen by the kernel
[19:16] <slangasek> sommer: I just meant it's preferable to have it set as an attribute of the filesystem itself, rather than a mount option in /etc/fstab
[19:16] <sommer> slangasek: okay, just wanted to double check, because that's the only way I could get it to work
[19:16] <slangasek> since mounting a device without acls can sometimes accidentally give users *more* permissions than is intended under the acls that are present
[19:17] <sommer> slangasek: ah gotcha, there's also a new Samba and LDAP section if you have time to review it :)
[19:18] <slangasek> probably not today, but some time. :)
[19:18] <sommer> cool no big rush
[19:50] <pet> Hi. I'm trying to build a package in my Personal Package Archive. One of the Build-Deps is in hardy-proposed, which doesn't seem to be available for the builder. How can I build the package, without waiting for the package to be available in the "hardy" pocket.
[20:07] <slangasek> pet: does PPA accept uploads to hardy-proposed?
[20:07] <slangasek> note that build-deps in the hardy-proposed pockets /never/ reach the hardy pocket, only the hardy-updates pocket; so hopefully PPAs use -updates when building (I don't know)
[20:09] <pet> slangasek: I got an "Rejected: PPA uploads must be for the RELEASE pocket."-error when trying to build it in hardy-proposed
[20:09] <slangasek> then I guess you'll have to wait, sorry
[20:10] <slangasek> or build it somewhere other than in a PPA
[20:11] <pet> I'd been thinking to build the required package (actually a kernel package) in my own PPA, but i think it's a spoil of resources
[20:21] <pet> slangasek: thanks for your time
[20:38] <jdstrand> slangasek: hi!
[20:38] <slangasek> jdstrand: 'lo
[20:38] <jdstrand> slangasek: I wonder if in bug #249881 these aren't omitted by design
[20:39] <jdstrand> slangasek: eg, if you use ldapi://, you see EXTERNAL, but also PLAIN and LOGIN
[20:39] <jdstrand> slangasek: if you use ldap:// you don't get those three
[20:40] <slangasek> jdstrand: the fact that it's omitted may be a symptom of the underlying problem (external auth unavailable), but I don't see how it could be by design
[20:40] <jdstrand> slangasek: maybe a safety 'feature' that crept in?
[20:40] <slangasek> I don't know
[20:40] <jdstrand> slangasek: well, PLAIN and LOGIN go away too-- they are plaintext
[20:40] <slangasek> sure
[20:41] <jdstrand> slangasek: ISTR some setting that turns this off...
[20:41] <slangasek> yes; but 'external' isn't considered a plaintext method, AFAIK?
[20:41] <jdstrand> I don't know
[20:41] <jdstrand> ssf? is that what it is?
[20:41]  * jdstrand goes to look
[20:42] <slangasek> the option is 'sasl-secprops none' to allow plaintext
[20:42] <slangasek> so you can try setting that, to see if it makes EXTERNAL available over ldap://
[20:43] <slangasek> the other possibility is that something's gone wrong in the gnutls/sasl interaction, to make it think that there's no external auth method available
[20:43] <slangasek> but this was /supposed/ to have been addressed explicitly in the gnutls port of openldap, so I don't know
[20:44] <jdstrand> slangasek: it would seem odd that that were the case, since ldapi works-- unless you are saying the gnutls is somehow not used with ldapi
[20:44] <slangasek> I would be surprised if the gnutls were used with ldapi, it's kinda pointless :)
[20:44] <jdstrand> ah yes, sasl-secprops with 'minssf'-- that was what I was thinking of
[20:45] <slangasek> it's possible that over ldapi, sasl is offering a different sort of 'external' auth, in the form of peer creds
[20:45] <slangasek> unix socket peer creds, that is
[20:45] <jdstrand> *shrug*
[20:45] <jdstrand> I'll check with sasl-secprops none
[20:45] <slangasek> yes, that'll tell which one of us is right :)
[20:46] <jdstrand> slangasek: oh, I'm not actually asserting rightness mind you! just thinking out loud :)
[20:49] <jdstrand> slangasek: FWIW, dapper behaves the same
[20:49] <slangasek> on both ldapi and ldap?
[20:49] <slangasek> I thought this was reported to be a regression
[20:49] <jdstrand> slangasek: I mean it is the same as hardy
[20:50] <slangasek> ok
[20:50] <jdstrand> slangasek: LOGIN, PLAIN and EXTERNAL show up with ldapi, but not ldap
[20:50] <jdstrand> certainly doesn't seem like a regression
[20:51] <slangasek> the submitter says it worked on dapper
[20:51] <jdstrand> well, that was a 2.2 -> 2.3 update, maybe he/she forgot to add something
[20:51] <slangasek> fwiw, there was just a bug report in Debian saying that external fails to work now against their AD(!) LDAP server, where it worked before
[20:51] <jdstrand> or the upgrade stripped it out
[20:51] <slangasek> so it could be a client problem
[20:52] <slangasek> rather, a client and server problem, since the submitter here says he tested with fedora ldapsearch too
[20:52] <jdstrand> I of course mean 2.2 -> 2.4
[20:52] <jdstrand> slangasek: I am testing dapper client and server, and hardy client and server
[20:53] <slangasek> also, the submitter says that PLAIN and LOGIN *are* allowed mechs over ldaps
[20:53] <jdstrand> haven't tested ldaps
[20:53] <slangasek> anyway, I'll stop kibbitzing now; let me know what you find with sasl-props none
[20:54] <slangasek> sasl-secprops, too
[20:55] <jdstrand> slangasek: sasl-secprops one pops up PLAIN and LOGIN, but no EXTERNAL
[20:55] <jdstrand> s/one/none/
[20:55] <slangasek> right
[20:55] <slangasek> so I think it's the gnutls integration that's broken
[20:56] <slangasek> you could test /that/ by recompiling against openssl
[20:56] <jdstrand> slangasek: and again, dapper behaves the same way
[20:57] <slangasek> hum, ok
[20:57] <jdstrand> slangasek: well, I wan't actually planning to go that far ;) I was just updating qa-regression-testing and thought I'd share my findings :)
[20:57] <slangasek> well, what about a test with an actual trusted client cert?
[20:57] <slangasek> (or are you already doing that?)
[20:58] <jdstrand> slangasek: I do plan to add ldaps for this test, but won't have it today
[20:58] <slangasek> it ought to work with tls anyway
[20:59] <slangasek> but if you aren't testing where you have a trusted client cert, I'm not surprised if EXTERNAL isn't reported as a valid mech
[20:59] <slangasek> since in that case, there are no external creds to validate against
[21:03] <jdstrand> slangasek: ok
[21:27] <mocha> hello, any devs here?
[21:28] <jpds> mocha: This is the Ubuntu developer channel. Welcome.
[21:28] <mocha> I wanted to talk about backporting Alsa 1.0.17 to Hardy
[21:28] <jpds> mocha: I'd try: #ubuntu-motu .
[21:28] <mocha> oh, okay I'll give that a shot
[21:29] <mocha> thanks
[21:36] <Chipzz> jpds: incorrect
[21:36] <Chipzz> jpds: alsa is main, and hence the relevant channel is this one
[21:37] <Chipzz> mocha: jpds was incorrect in referring you to #ubuntu-motu ; feel free to ask your question here
[21:37] <mocha> Chipzz: hello
[21:37] <mocha> I was just wondering if Alsa 1.0.17 will be updated or backported to Hardy
[21:37] <Chipzz> mocha: though I'm not sure I can be of much help for your specific question
[21:38] <crimsun_> mocha: no.
[21:38] <mocha> 1.0.17 fixes a lot of really annoying issues with the Intel HDA specifically the AD1988 chip
[21:38] <mocha> crimsun_: why not? because of LTS?
[21:39] <crimsun_> mocha: if you're referring to -driver, then that's a possibility for linux-backports-modules-2.6.24.
[21:39] <Chipzz> mocha: alsa is a very central library; updating it may break a lot of stuff
[21:39] <mocha> Chipzz: I realize that, I can tell you in Feisty I manually updated Alsa to 1.0.16
[21:40] <jpds> Chipzz: OK, sorry.
[21:40] <mocha> I probably will do it for Hardy if there are no plans to update the repositories with it
[21:40] <Chipzz> mocha: you are of course free to update it yourself :) but having it as an update for an LTS may negatively affect a lot of people, hence such an update has to be considered very vcarefully
[21:41] <Chipzz> !release
[21:41] <crimsun_> mocha: the revelant component aside from -driver is -lib, and even 1.0.16 has shown regressions.
[21:41] <mocha> crimsun_: aren't those regressions fixed in 1.0.17?
[21:41] <crimsun_> mocha: no
[21:42] <mocha> crimsun_: are they with a specific card?
[21:42] <Chipzz> mocha: even if they were, new regressions could have been introduced
[21:42] <crimsun_> mocha: I'm referring to -lib, not -driver.
[21:42] <mocha> hmm, well I realize this involves a lot of testing on your part
[21:43] <mocha> Generally speaking, if I manually update my modules and something goes wrong, can I just purge and reinstall alsa from the repositories?
[21:43] <Chipzz> mocha: generally speaking: yes, but a downgrade is always manual
[21:44] <mocha> Chipzz: even if you purge?
[21:44] <Chipzz> so you cannot easily push a downgrade once you realize an update is broken
[21:44] <crimsun_> mocha: if by "modules" you only mean the driver, then erasing the newer ones (with find, etc.) and reinstalling linux-ubuntu-modules-$(uname -r) should suffice.
[21:44] <Chipzz> mocha: no, not then. but as I said, purging involves manual interaction
[21:45] <crimsun_> (alternately, you could wait until Debian and Ubuntu have 1.0.17, then request backports of -driver and -lib)
[21:45] <mocha> crimsun_: ?  won't driver, lib, utils, etc all be updated to 1.0.17?
[21:46] <crimsun_> mocha: that is improbable for hardy-updates but possible for hardy-backports
[21:47] <mocha> Chipzz: It was always my understanding that by manually updating alsa driver, lib, and utils, that the manually compiled and installed files simply overwrite the files from the packages from the repositories
[21:48] <mocha> so if something goes wrong it was just a matter of purging -driver -lib -utils and then reinstalling from the repositories
[21:48] <mocha> the "
[21:48] <crimsun_> that is mostly the case.  Doing so also strews files that aren't part of the packages on your fs.
[21:48] <Chipzz> mocha: ah yes, in that way; I was assuming you were referring to a proper way (ie with packages) ;)
[21:48] <mocha> the "reinstalled" files would go back to 1.0.16
[21:49] <mocha> crimsun_: what do you mean?
[21:49] <crimsun_> e.g., /etc/init.d/alsasound, /usr/sbin/alsaconf
[21:50] <mocha> crimsun_: but those files are part of the repository packages, so they would get rewritten with 1.0.16
[21:50] <crimsun_> mocha: no, those files are -not- part of Ubuntu's packages.
[21:50] <asac> anyone here with hardy + b43 wifi chip?
[21:50] <crimsun_> asac: yes.
[21:50] <mocha> where did they come from then?
[21:50] <asac> crimsun_: cool ... can you please paste the lshal output somewhere?
[21:51] <crimsun_> mocha: they are part of the upstream alsa-driver tarball that Ubuntu does not install.
[21:51] <crimsun_> asac: do you mean hardware driven by the b43 driver or bcm43xx hardware generally?
[21:52] <mocha> crimsun_: ok, well how would a person get them on an Ubuntu system then?  because I have them
[21:52] <asac> crimsun_: i think b43 driver is what matters here ;)
[21:53] <crimsun_> mocha: you would get them by compiling and installing alsa-driver from upstream.
[21:53] <crimsun_> asac: ok, then I retract that (I have to use ndiswrapper currently for this 4315)
[21:54] <mocha> crimsun_: I think we are just confusing ourselves.  Obviously there was some package in the repository that put them on my system.
[21:54] <asac> crimsun_: does b43 work at all for you?
[21:55] <crimsun_> asac: on another system with bcm4311 rev 01, yes.  On this system with bcm4315, no.
[21:55] <asac> ok
[21:55] <asac> thanks
[21:55] <MaximLevitsky> Is adding support for easy edit of labels to nautilus considered for ubuntu?
[21:56] <crimsun_> mocha: no Ubuntu or Debian package owns /etc/init.d/alsasound, and only Debian's alsa-utils package owns /usr/sbin/alsaconf.
[21:57] <mocha> crimsun_: okay, so I got alsaconf from alsa-utils 1.0.16
[21:57] <crimsun_> (note that Ubuntu has not shipped alsaconf since warty)
[21:58] <mocha> well, this is strange then
[21:58] <mocha> I will have to double check
[21:59] <mocha> I don't want to keep taking your time, but I think later I will attempt a manual install because I've been waiting for about a year for these bugs to get fixed and I got excited today when I went to Alsa webpage and saw the final release of 1.0.17
[21:59] <mocha> The changelog was even more exciting
[22:00] <crimsun_> it's your system; "off you go".
[22:01] <mocha> FYI, there is a thread in the Ubuntu forums where a guy made a script to download and compile and install -driver -lib -utils, and then he has another script that moves snd-intel-hda.ko to the proper directory
[22:01] <mocha> I don't know if that is necessary since I didn't do that in Feisty
[22:02] <crimsun_> it's necessary due to the default path to snd-hda-intel.ko.
[22:02] <mocha> Okay, I'll make sure I put the modules in the proper places then
[22:02] <crimsun_> [and by "default", I mean the one installed by linux-ubuntu-modules-$(uname -r)]
[22:03] <mocha> heheh, maybe when I did this in Feisty it never actually updated the module
[22:03] <ScottK-palm> pitti: If you're still around, the sauerbraten backport wanted the sauerbraten-data package too and it's uninstallable until that gets done ...
[22:03] <mocha> I never checked /proc/asound/version or whatever file shows the version
[22:04] <crimsun_> mocha: feisty had no such issues with paths.
[22:04] <mocha> crimsun_: why is that?
[22:05] <crimsun_> mocha: because feisty was the last Ubuntu release to not modify the installed path for ALSA modules.
[22:05] <ScottK-palm>  ... or any other archive admin ...
[22:06] <mocha> crimsun_: ah ha.  Finally you have just stated the question I originally had
[22:06] <mocha> I was wondering about that, if the alsa modules location had changed
[22:07] <mocha> So I guess the conclusion is that I better be careful, if I check the current location of snd-intel-hda.ko and make sure that the manually compiled one goes there, is that sufficient?
[22:09]  * ScottK-palm notices the battery level on his phone and quits ...
[22:10] <mocha> crimsun_: do you happen to know of the ubuntuforums thread I'm talking about, sorry can't find the link right now
[22:10] <crimsun_> mocha: no.  You need to ensure that your intended snd-hda-intel.ko is lexicographically sorted first.
[22:11] <crimsun_> mocha: vaguely, yes.
[22:11] <mocha> crimsun_: lexicographically sorted???
[22:11] <mocha> what is that in simple english?
[22:11] <crimsun_> mocha: dictionary/alphabet-wise
[22:11] <mocha> well why wouldn't it be sorted that way?
[22:12] <crimsun_> mocha: because upstream installs into kernel/sound, whereas Ubuntu uses ubuntu/sound
[22:13] <mocha> OK, yes that is what we were already talking about
[22:13] <mocha> got it
[22:13] <mocha> that is what the guy's second script does
[22:14] <mocha> I've run into this same issue when compiling modules for wi-fi cards on Gutsy
[22:14] <crimsun_> err, sorry, I meant "sort last" above instead of "sorted first".
[22:15] <mocha> I have to copy the new module into /ubuntu/whatever because otherwise the older module still gets loaded
[22:15] <crimsun_> anything dictionary-wise after 'ubuntu' will suffice.
[22:16] <mocha> meaning that any modules loaded into the dir blah/ubuntu/xxxx will get loaded?
[22:17] <crimsun_> if you intend your self-compiled version to take precedence, you need it in a path that sorts "after" ubuntu/sound
[22:17] <crimsun_> note that you can pass --with-moddir= to alsa-driver's configure script.
[22:18] <crimsun_> anyhow, ping me offline in #ubuntu if you have further questions, please.
[22:18] <mocha> Ok, I think I understand
[22:19] <mocha> I will just make sure to take account of where snd-intel-hda.ko is currently and what files are installed from the repository before I do the manual install
[22:20] <mocha> anyway, I appreciate your time, thanks very much, I love linux
[22:20] <crimsun_> anytime.
[23:15] <lionfish> Hello all. I asked in #ubuntu, but maybe this is the right place: I thought I'd give USB driver development a go, and tried compiling some of the drivers already there to start with...
[23:15] <lionfish> ...I posted a question on the forum: http://ubuntuforums.org/showthread.php?t=869284
[23:15] <lionfish> with the detail.
[23:15] <lionfish> *details
[23:18] <lionfish> (bbiab)
[23:18] <choudesh> lionfish, do you have the kernel headers package installed?
[23:19] <lionfish> hey. Yup.
[23:19] <lionfish> I also downloaded the source code too.
[23:20] <lionfish> I assume there's probably an easy way of compiling them that I've just not figured out yet...
[23:20] <lionfish> I could pastebin the whole error if you want (I just wrote the first few lines to give an idea of the error)
[23:22] <choudesh> use /lib/modules/$(shell uname -r) for -I paths
[23:22] <lionfish> oh right...
[23:23] <choudesh> also try running make from the kernel root
[23:23] <lionfish> ooh, good thinking.
[23:24] <choudesh> and you make need to kconfig config USB_LD
[23:24] <choudesh> I am too hungery to actually look
[23:24] <lionfish> ah
[23:24] <lionfish> awesome, thanks for the pointers.
[23:28] <lionfish> um, is it even supposed to be possible to compile these files separately?
[23:32] <tormod> lionfish: you want to compile only a subtree of the kernel?
[23:33] <lionfish> I guess so, sorry I'm possibly trying something too advanced for my knowledge.
[23:33] <lionfish> I'm just trying to compile one driver.
[23:33] <lionfish> (in this case drivers/usb/misc/usbled.c) but it could be any driver.
[23:33] <tormod> lionfish: I did it once, made some notes in a forum post. (searching)
[23:34] <lionfish> (indeed my plan is to write my own driver... for my scope, which doesn't seem to have a linux driver for it)
[23:34] <lionfish> cool, awesome. thanks!
[23:35] <tormod> lionfish: http://ubuntuforums.org/showthread.php?t=279628
[23:36] <tormod> lionfish: in many cases you don't need to make a kernel driver, you can use libusb instead
[23:36] <lionfish> Yeah...
[23:36] <lionfish> ...I might have to look into that a bit more...
[23:36] <lionfish> It's for a scope,
[23:36] <lionfish> so it uses uh, ah, can't remember the word: When it allows the device to spew lots of data.
[23:36] <tormod> streaming
[23:37] <lionfish> hang on.
[23:37] <tormod> link to manufacturer?
[23:37] <lionfish> it's embarrassing!
[23:37] <lionfish> it's a Hantek DSO-2100 USB scope... http://www.hantek.com.cn/english/jianjie.asp
[23:37] <lionfish> (the page makes me want to cry)
[23:38] <lionfish> But it was an ebay cheapy, so I guess I get what I pay for.
[23:38] <lionfish> Its front page has sentences such as "antek is willing to display own quantity of heat to provide the sunlight enthusiasm and the service for all customers."
[23:38] <tormod> "own quantity of heat" lol
[23:40] <tormod> is it the 2150 model? I can't see 2100
[23:40] <lionfish> (It's at the bottom of the download list)
[23:40] <lionfish> (If you're looking there)
[23:40] <lionfish> (for the windows driver)
[23:41]  * lionfish tries clicking on "fist"
[23:41] <lionfish> ah, no that's probably "first"
[23:42] <lionfish> well, it's on this page: http://www.hantek.com.cn/english/produce.asp?page=2&classid=11
[23:42] <lionfish> but clicking on it takes me to a frightening page http://www.hantek.com.cn/english/produce.asp?page=2&classid=11
[23:42] <lionfish> anyway, doesn't matter. Kinda wonder if it's worth writing a driver for - or I could just dual boot.
[23:42] <lionfish> Was partly doing it for other people who might need it.
[23:43] <lionfish> I'll look into using usblib anyway.
[23:43] <lionfish> sorry libusb.
[23:43] <tormod> how much are these cards?
[23:46] <lionfish> Uh, I don't know how much they're supposed to be I got this for about £50
[23:46] <lionfish> ($100)
[23:46] <lionfish> (probably fell off the back of a lorry)
[23:46] <tormod> you can also check out that Linux instrumentation driver project, (forgot the name)
[23:46] <lionfish> Usually a scope about 10MHz will cost ~£100 I think.
[23:47] <lionfish> but to get over 100MHz costs a load more, and you need good probes etc...
[23:48] <lionfish> ...and over 1GHz you need very good probes (need amps at the probe itself) and cleverness in the scope. There's lots of other factors though: The impedance the scope can manage, and capacitance... noise, bits/sample, etc..
[23:49] <tormod> "comedi" http://stm.lbl.gov/comedi/intro.html
[23:49]  * lionfish is going to go and read the libusb dev guide (maybe not tonight), thanks for pointing me at it agian.
[23:49] <lionfish> *again
[23:50] <lionfish> fantastic.
[23:50] <sistpoty> lionfish, tormod: maybe you'd like to discuss this on another channel?
[23:50] <lionfish> It might be worth looking inside and seeing if the chips are the same.
[23:50] <lionfish> sistpoty, oh right: Which channel should this be in?
[23:51] <sistpoty> lionfish: that's a good question... not too sure actually ;)
[23:52] <tormod> not that we are disturbing much here right now
[23:52] <lionfish> Anyway, I need to get some sleep.
[23:52] <lionfish> Thanks so much for the help tormod!
[23:52] <tormod> you're welcome, good night
[23:52] <lionfish> I should have looked more at libusb. Ty for reminding me
[23:52] <sistpoty> well, kind of... I usually watch #ubuntu-devel to see development discussion and hence look here from time to time if there's activity ;)
[23:53] <lionfish> (and comedi looks very good - hopefully I'll find that Hantek are just putting boxes around someone elses chip - quite common I find ^_^)
[23:53] <sistpoty> but granted, at this point in time, you don't disturb development too much ;)
[23:53] <lionfish> Very nice OS btw :D - It's getting very user friendly: my gf was dubious at first, but now she's telling everyone at work about it :)
[23:54] <sistpoty> :)
[23:54] <lionfish> Right, better go. Ty all! nn.
[23:54] <sistpoty> cya lionfish