[03:39] <spasticteapot> I've got a somewhat snaggeltoothed Ubuntu problem, and I figure I should bring it up here, since I've tried asking just about everywhere else on Freenode.
[03:40] <spasticteapot> I've even offered free beer to whoever can help me fix it on the LUG chatroom. (Admittedly, I myself cannot buy said beer, but I can pay for it at least.)
[03:40] <spasticteapot> Under Ubuntu, as a default, the Gnome applet Network-Monitor has some nifty features relating to wifi - it has the "5 bars" when you're connected, and when you click on it, a drop-down menu appears of various wifi connections. However, after accidentally removing the applet and adding another network-manager applet to my panel, my wifi connection (eth1) is treated as an ethernet connection. Perhaps I could rename eth1 to wlan0
[03:40] <spasticteapot> ? Or fix the applet?
[03:44] <spasticteapot> Also, why is IFrename not in Ubuntu?
[03:45] <wasabi> Believe udev deals with renaming hte interfaces.
[03:45] <wasabi> Also, sound slike a bug. File it.
[03:45] <spasticteapot> udev?
[03:45] <spasticteapot> How do I file it?
[03:45] <spasticteapot> And, more importantly, how do I FIX it?
[03:46] <wasabi> https://launchpad.net/malone/+filebug
[03:46] <wasabi> and I have no idea how to fix it. sounds like a bug.
[03:46] <spasticteapot> I was told to try this for renaming my wireless card:  ifrename - -i eth1 -n wlan0 < /dev/null
[03:46] <spasticteapot> How do I do that with udev?
[03:47] <wasabi> Hurm. I don't think that's related.
[03:47] <wasabi> Also, this isn't the appropiate place to ask, as the topic states.
[04:12] <Amaranth> wasabi: actually his probably was he replaced NetworkManager with network-monitor, from what i can tell :)
[04:26] <wasabi> oh?
[04:26] <wasabi> Oh yeah I see.
[04:45] <spasticteapot> Does anyone know where the list of default applets in the dock in Ubuntu is?
[05:59] <fabbione> morning
[07:40] <pitti> Good morning
[07:41] <Burgundavia> hey pitti
[07:41] <Burgundavia> congrats on getting tribe 1 out
[07:44] <pygi> morning pitti, Burgundavia 
[07:46] <pitti> hi Burgundavia 
[07:46] <pitti> hey pygi
[07:46] <pitti> thanks
[07:47] <StevenK> pitti: Do you know anything about packages not registering builds?
[07:47] <StevenK> pitti: Hi, by the way. :-)
[07:47] <pitti> StevenK: no, I don't; when was it uploaded?
[07:48] <StevenK> pitti: There are three; the oldest was uploaded just over 24 hours ago.
[07:48] <pitti> StevenK: and published?
[08:20] <StevenK> pitti: All three are published, yes.
[08:20] <pitti> StevenK: hm, you should ask cprov once he gets online
[08:21] <pitti> StevenK: can you tell me an example package?
[08:21] <StevenK> pitti: It appears to be a wider problem with crimsun also just mentioning in -motu
[08:21] <StevenK> pitti: Take your pick of python-qt4, scim-qtimm or libwibble.
[08:22] <crimsun> (yes, was asked about ruby-gnome2)
[08:22] <pitti> at least all buildds are busy
[08:24] <StevenK> pitti: From what I saw, they *look* to be busy, but they aren't updating the logs that show where the build is up to on LP.
[08:26] <pitti> StevenK: oh, hmm; can you please drop by #canonical-sysadmin and ask there? they might know something
[08:29] <StevenK> pitti: About both issues or just the latter?
[08:30] <pitti> StevenK: they might be related
[08:35] <superm1> mdke, ping
[08:35] <mdke> superm1: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[08:35] <Hobbsee> yay, contentlessping.pl - the modified version
[08:35] <superm1> mdke, I wanted to poke about our mailing list, we still haven't heard anything more about it from rt or anything
[08:36] <superm1> Hobbsee,  rather than contentless pongs version?
[08:36] <Hobbsee> superm1: sorry?
[08:36] <superm1> Hobbsee, the one that responds something like "You've sent me a contentless ping and this is a contentless pong"
[08:36] <superm1> or something to that effect?
[08:37] <Hobbsee> that's the original contentlessping.pl, iirc
[08:37] <Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around. 
[08:37] <superm1> ah
[08:37] <Hobbsee> ^ almost that
[08:37] <mdke> superm1: hi. I'll try chasing by email. What's your mailing list?
[08:37] <superm1> mdke, ubuntu-mythtv was what we were looking to get setup
[08:38] <superm1> mdke, do you want the rt # that we had opened up back in april?
[08:38] <superm1> to include
[08:38] <mdke> yeah, thanks
[08:38] <mdke> email me the details
[08:39] <superm1> okay will do
[08:39] <superm1> thanks mdke 
[08:47] <mdke> superm1: got it, thanks
[09:03] <dholbach> good morning
[09:04] <Fujitsu> Hi dholbach.
[09:04] <dholbach> heya Fujitsu
[09:12] <pygi> morning dholbach 
[09:13] <dholbach> heya pygi
[09:13] <pygi> dholbach, wanna try something? :)
[09:13] <pygi> (if you have time ofcourse ^_^)
[09:14] <dholbach> what is it?
[09:15] <pygi> that telepathy ncurses IM client? :)
[10:24] <cjwatson_> persia: I put rather a lot of work into reducing the number of questions asked by default way back in Warty, as it happens.
[10:24] <cjwatson> shawarma: I don't think it's written down anywhere. It was one of Mark's mandates right at the start.
[10:25] <persia> cjwatson: My apologies.  I wasn't following the lists as closely then, and missed the changes.
[10:26] <shawarma> cjwatson: Alright, thanks. I was considering deviating from it and was hoping the policy's wording or rationale would provide justification for that, but I may have worked around it now.
[10:28] <cjwatson> persia: (though it's true that the introduction of ubiquity made a big dent)
[10:28] <persia> cjwatson: That's the one I remember :)
[10:28] <cjwatson> yeah, it wasn't a new policy then though
[10:31] <Burgundavia> shawarma: for the server installer, we can treat things a bit differently
[10:31] <Burgundavia> we are targetting a different audience, one that probably knows a bit more
[10:32] <shawarma> Burgundavia: That's what I was thinking, too.
[10:33] <shawarma> Burgundavia: I just need to test this a little bit more. Launchpad says it's a 25 minute build, so it's not that bad.
[10:49] <Fjodor> Does anyone know if Bug #110585 is caused by something in kernels > 2.6.18 and that's why we hit it?
[10:49] <ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
[10:49] <cjwatson> well, our parted is essentially the same as Debian's
[10:50] <Fjodor> cjwatson: I think the raid controller driver spits some nasty things in dmesg and that's why we can't see anything on it
[10:53] <cjwatson> that should be easy to verify by checking the logs from a second console
[10:53] <cjwatson> parted> (there are differences, but not relevant ones here)
[10:53] <cjwatson> which basically leaves either udev (seems unlikely, as apparently the device node does exist) or the kernel
[10:54] <Keybuk> the power management in gutsy is definitely futzed
[10:54] <cjwatson> Fjodor: you can copy /var/log/syslog to another machine by doing 'anna-install openssh-client-udeb' and then you'll have scp
[10:55] <Keybuk> laptop usually crashes when AC power is disconnected or reconnnected
[10:55] <cjwatson> then please attach it to the bug
[10:55] <Keybuk> and laptop goes to standby when the lid is closed for a while, even though that's marked as "Never" in prefs
[10:57] <Burgundavia> Keybuk: some of it might be related to the new code for profiling batteries
[10:57] <Keybuk> Burgundavia: that code and I are not friends; it decided my battery only lasted for 20mins and shut down my computer!
[10:57] <Fjodor> cjwatson: Actually, the problem is described on the forums (only saw that now). Have a look at http://ubuntuforums.org/showthread.php?t=384319&highlight=dl360 and http://ubuntuforums.org/showthread.php?t=384319&page=2
[10:57] <Burgundavia> Keybuk: tell me about it
[10:57] <Burgundavia> anyway, is 2am here, time to sleep
[10:57] <shawarma> Burgundavia: right, but your battery actually does only last for 20 minutes.. There's a difference.
[10:58] <shawarma> Burgundavia: :-P
[10:58] <Keybuk> oh, and something about NM/dchdbdbdbdbdbd/ipw3945 is broken too
[10:58] <Keybuk> it won't associate with any network until I toggle the hardware switch
[10:58] <Keybuk> (wonder if this is something to do with HAL gaining knowledge of these)
[11:00] <fabbione> Keybuk: you are not the only one that reported this hw switch issue with some wireless cards.. IIRC they were mentioning something in the kernel
[11:01] <Keybuk> could be kernelish, though running dhclient itself just works
[11:01] <Keybuk> (but then that doesn't check such things)
[11:03] <pygi> hey Zdra 
[11:05] <cjwatson> Fjodor: thanks; I've added a pointer to the relevant post to the bug
[11:07] <Zdra> hello pygi
[11:07] <pygi> Zdra, have time for trying things? :)
[11:08] <Zdra> not really right now, maybe this evening ;)
[11:08] <Zdra> sorry
[11:08] <pygi> Zdra, evil you :P Oki doki :)
[11:28] <hunger> Are there freenx debs in ubuntu?
[12:58] <pitti> hi thekorn_ 
[12:59] <thekorn_> hi pitti
[01:01] <pitti> thekorn_: curious, is there an API for deleting attachments in p-lp-bugs now?
[01:02] <thekorn_> pitti: sorry, not now, you need that as soon as possible, right?
[01:02] <pitti> thekorn_: before we can enable apport again for gutsy, yes (and to clean up the existing core dumps)
[01:03] <pitti> thekorn_: is it hard to do? it's just another page scraping/button click, I figure?
[01:04] <thekorn_> pitti: my problem is, that I'm stilll working on changing the API, I started with other parts
[01:05] <pitti> thekorn_: ah, I see; well, then rather do it right, and I'll use a temporary hack if I need it before
[01:05] <thekorn_> pitti: ok cool, thanks
[01:09] <Fujitsu> pitti: What magical stuff is apport going to do this cycle?
[01:09] <fabbione> StevenK: i am looking at your sparc buildd hangs....
[01:10] <pitti> Fujitsu: I finished https://wiki.ubuntu.com/ApportBetterRetracing except for the wine stuff; currently working on https://wiki.ubuntu.com/ApportCrashDuplicates
[01:10] <pitti> Fujitsu: and we urgently need to do https://wiki.ubuntu.com/CrashReporting
[01:10] <pitti> Fujitsu: the approved gutsy specs list has some more apport stuff
[01:15] <Fujitsu> pitti: Looks pretty good; a lot more manageable for triagers.
[01:15] <pitti> Fujitsu: right, that was the idea
[01:17] <Fujitsu> I don't like the working around the lack of version tracking in Malone, though. Why doesn't Malone grow that feature like it should have ages ago?
[01:18] <pitti> Fujitsu: I don't know
[01:19] <Fujitsu> It's more than a bit annoying
[01:39] <StevenK> fabbione: Ahhhh, great. Thanks. You got me there for a moment, I couldn't recall what you were refering to. :-)
[01:40] <fabbione> StevenK: tig builds fine.. i am somewhere in lyx
[01:40] <StevenK> fabbione: I'm not so sure it's a sparc-only problem, to be honest.
[01:40] <fabbione> StevenK: i suggest you talk to one of our sysadmins to get a manual build of tig (since it's small)
[01:40] <StevenK> fabbione: Couldn't we first just requeue it?
[01:40] <fabbione> i don't think the problem is tig.. it might be that the build exercises some very well hidden bug somewhere
[01:41] <fabbione> StevenK: yes.. that's a possibility, but if it hangs forever, it means killing a buildd
[01:41] <fabbione> StevenK: requeue -> manual build -> build test with a different kernel
[01:41] <fabbione> that's the sequence i would do for testing
[01:41] <StevenK> fabbione: Surely it also allows us/you to keep a close eye on the requeued build?
[01:43] <fabbione> me? no.. i don't have access to the buildd.. it needs to be somebody like infinity2 or one of our admins
[01:43] <fabbione> if it hangs, grab some info... what the hell the machine is doing.. etc..
[01:53] <jmg> anyone know about acpi here?
[01:53] <jmg> i managed to boot windows and reenable wireless after gutsy broke it, but i really really want to fix this bug.
[02:13] <fabbione> StevenK: i am going to finish the lyx build, but it's going fine so far
[02:14] <pitti> StevenK: btw, buildd congestion should be fixed now
[02:15] <StevenK> pitti: Yay! What was the problem, in small words?
[02:16] <pitti> StevenK: <elmo> meh
[02:37] <supervillain> hi, anyone knows what 09_double_text.patch does to slab?
[02:37] <Hobbsee> supervillain: did the changelog say?
[02:37] <supervillain> no..
[02:37] <supervillain> it's just right in there
[02:38] <supervillain> but it cannot be applied
[02:38] <supervillain> seems it's for libslab, not slab
[02:39] <supervillain> I get it, slab and libslab are different package now..
[02:39] <Hobbsee> try asking the person who's done the last few updates of slab, i guess.
[03:25] <Hobbsee> pitti: are you on archive duty today?
[03:25] <pitti> Hobbsee: no, Mithrandir would be, but he's on vac
[03:25] <Hobbsee> pitti: i'm wondering how to tell who's done a reject
[03:26] <Hobbsee> or, alternatively, whether b5i2iso is still in the NEW queue
[03:26] <Hobbsee> (uploaded twice, got one reject ~20 mins ago)
[03:26] <pitti> http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/
[03:26] <Hobbsee> and i was under the impression that launchpad discarded the old version silently, if it had the same version number.
[03:26] <pitti> it's there
[03:27] <Hobbsee> ....
[03:27] <bhale> https://launchpad.net/ubuntu/gutsy/+queue
[03:27] <bhale> i like this page better.
[03:27] <pitti> Hobbsee: no, it'll be in the NEW queue twice
[03:27] <Hobbsee> pitti: ah right.  cool.  that was the answer to the non-stupid part of the question, then :)
[03:27] <Hobbsee> thankyou
[03:28] <pitti> Hobbsee: ISTR cleaning up the NEW duplicates this morning
[03:28] <Hobbsee> ISTR == i seem to remember?
[03:28] <Hobbsee> pitti: fair enough.
[03:28] <pitti> Hobbsee: that's how you got the reject mail
[03:28] <Hobbsee> yep
[03:28] <pitti> Hobbsee: so if the versions were exactly identical, that's fine
[03:29] <Hobbsee> my brain was working along the lines of "so, if i've got a reject, how do i find out what the problem was?"  But as for forgetting to check the NEW queue...i'll blame work for that one.
[03:29] <Hobbsee> or impending exams
[03:29] <Hobbsee> versions were identical, yes
[03:29] <liri> I've migrated to use Ubuntu Dapper LTS from old Debian Sarge and I'm getting errors to compile my code: In function LKb_RETURN OS_MutexInit(LK_MUTEX*): error: union pthread_mutexattr_t has no member named __mutexkind     The makefile is running with: -D_LINUX -D_REENTRANT -march=i586 -I/usr/include -Wall -pipe -DPTHREADS_SUPPORTED -D_UNIX_THREADS_SUPPORTED -O3 -fforce-addr
[03:30] <liri> and my kernel is 2.6.17-11-generic #2 SMP
[03:30] <pitti> Hobbsee: ok, so all is fine now
[03:30] <Hobbsee> pitti: yeah, thanks
[03:30] <liri> any clues on these libraries? could it be that some functions got deprecated?
[04:07] <shawarma> liri: If your kernel is 2.6.17, you're not running Sarge nor Dapper.
[04:10] <ogra> pitti, ltsp-client was split into ltsp-client and ltsp-client-core, the latter will show up in NEW soon, can you wave it through ?
[04:10] <pitti> ogra: can do; please ping me when you uploaded it
[04:10] <ogra> just did :)
[04:11] <pitti> nothing yet, apparently it missed the :10 run
[04:11] <pitti> in 5 minutes then
[04:11] <ogra> ah
[04:11] <ogra> should be 5.0.11
[04:15] <mvo> racarr: do you have some minutes to help me with https://bugs.launchpad.net/compiz/+bug/119199 ? it seems to be a bug in the gconf plugin of compiz, but I need some hints how to debug it efficiently 
[04:15] <ubotu> Launchpad bug 119199 in compiz "[gutsy] latest compiz update causes sytem to lockup when enabling compiz" [High,Confirmed]  
[04:18] <pitti> ogra: still nothing
[04:18] <ogra> hmm, i got the mail from drescher
[04:18] <ogra> its on -changes as well
[04:18] <pitti>   225575 | S- | ltsp                 | 5.0.11               | nine minutes
[04:18] <pitti> ^ in accepted
[04:19] <ogra> ah, indeed, its a new binary
[04:19] <pitti> ogra: oh, you mean there's just a new binary package, no new source
[04:19] <StevenK> The source isn't NEW, the binaries are.
[04:19] <StevenK> ogra: Snap.
[04:19] <pitti> ogra: so, it needs to get built first
[04:19] <ogra> :)
[04:25] <pitti> thekorn: hmm, p-lp-bugs doesn't support marking a bug as dup of another one? or is there a trick to it?
[04:27] <liri> shawarma: true, I was trying it on both dapper and feisty 
[04:27] <StevenK> liri: 2.6.17 isn't the kernel version from Feisty either.
[04:27] <pitti> liri: 2.6.17 is the edgy kernel
[04:27] <liri> shawarma: anyway I solved the problem by using pthread_mutexattr_settype(&MutexAttr, PTHREAD_MUTEX_RECURSIVE_NP);
[04:30] <thekorn> pitti: I'm sorry, that's still not supported,
[04:30] <thekorn> and I don't know odf any trick
[04:31] <pitti> thekorn: ok, so my preliminary implementation of close_duplicate() will be to just add a comment which points to the master bug
[04:33] <pitti> thekorn: sorry, yet another question: if I get a list of all bugs with a certain tag, does this traverse through all batch pages or just the first one?
[04:40] <dholbach> pitti: all of them
[04:40] <pitti> dholbach: cool, thanks
[04:40] <hunger> Why does "mount -o remount,rw /usr" no longer work on gutsy?
[04:40] <hunger> Reports that /usr is already mounted...
[04:49] <mathiaz> I was going through UbuntuMainInclusionQueue wiki page. I was wondering what is the state of libnss-ldap, libpam-ldap and libpam-mount reports ?
[04:49] <pitti> mathiaz: it didn't get much attention since noone prodded us for them so far
[04:49] <mathiaz> It is stated that they should be rewritten first.
[04:50] <mathiaz> what's wrong with the current reports ?
[04:50] <pitti> mathiaz: they do not match the template and thus are lacking some information
[04:53] <mathiaz> pitti: they seem to follow the template.
[04:53] <cjwatson> they follow the template a little too exactly, IIRC ;-)
[04:53] <cjwatson> unless I misremember
[04:54] <ogra> yeah
[04:54] <ogra> i wanted to rewrite the reports if i need them ... feel free to take them :)
[04:55] <Hobbsee> twitch.  i should write a couple.
[04:55] <ogra> uh
[04:55] <ogra> Hobbsee, have fun :)
[04:55] <Hobbsee> ogra: i believe "delegation" is the term that applies.
[04:56] <pitti> Hobbsee: erk, two KDEs in main? fun
[04:56] <Hobbsee> ogra: but then again...as for how much of it would be new upstream versions of the same apps...
[04:56] <ogra> since we cant script them anymore thats a lot of work ....
[04:56] <pitti> Hobbsee: I'm fine with replacing kdexxx with kde4xxx without an MIR
[04:57] <pitti> Hobbsee: however, having both in main at the same time is a question that deserves to be discussed at least in the distro team meeting
[04:57] <hunger> mathiaz: libpam-mount basically works for me, but it lost some functionality in feisty (for encrypted partitions).
[04:58] <Hobbsee> pitti: you couldnt promote dolphin then, without a MIR, then, i assume?  *g*
[04:58] <Hobbsee> pitti: yeah, true that
[04:58] <Hobbsee> pitti: that's a later discussion - including the one about LTS's and such.
[05:00] <Riddell> no need for kde4 in main any time soon
[05:01] <Riddell> but a main inclusion review of strigi and clicene-libs would be lovely if pitti is looking to do some
[05:01] <Hobbsee> morning Riddell 
[05:01] <mathiaz> I guess that libpam-mount is heavily used in edubuntu.
[05:11] <pitti> dholbach, thekorn: hmm, so the BugList ctor takes all those attributes, but if I set the status field to 'Needs Info' I still get all bugs rather than just the needsinfo bugs
[05:11] <pitti> i. e. BugList(Struct(url = 'https://launchpad.net/ubuntu/+source/apport/+bugs', upstream = None, minbug = None, filterbug = None, status = 'Needs Info', importance = '', lastcomment=''))
[05:11] <dholbach> pitti: can you file a bug with a small test case?
[05:12] <pitti> oh, this is only done for 'if opt.upstream and opt.sourcepackage:'; hmm
[05:12] <pitti> I don't want just upstream bugs
[05:12] <pitti> dholbach: can do
[05:12] <dholbach> pitti: rock on - thanks a lot
[05:21] <pitti> dholbach: done; I'll just go ahead and file bugs for the other stuff I need for apport
[05:21] <dholbach> pitti: thanks a lot
[05:23] <pitti> dholbach: hm, noone is subscribed to python-launchpad-bugs
[05:23] <pitti> thekorn: ^ maybe you want to subscribe to that package?
[05:23] <dholbach> bughelper-dev is subscribed to upstream bugs
[05:23] <dholbach> I'll make them subscribed for ubuntu packages too
[05:25] <dholbach> pitti: done
[05:25] <pitti> cool, thanks
[05:25] <pitti> dholbach: so you guys probably just missed my three bug reports, but maybe someone looks at the bug page occasionally :)
[05:27] <dholbach> pitti: will look at them
[05:35] <afflux> hunger: I suppose it's a spelling mistake that your crypttab contains a reference to /dev/vg0/ub_tmp_c and you create the cryptdevice in /dev/vg0-ub_tmp_c? (see your latest cryptsetup bug)
[05:39] <hunger> afflux: That does not matter. both are a symlink to the same /dev/dm-XX
[05:39] <afflux> eh. does dmsetup support mapping a mapped device?
[05:40] <hunger> afflux: I have 7 crypted partitions on that VG, all using the same syntax to address it.
[05:40] <afflux> ah. okay.
[05:40] <hunger> afflux: The other 6 are luks ones and work fine.
[05:40] <afflux> do you get any error messages from cryptsetup?
[05:40] <hunger> afflux: the cryptdisks init script fails... that's all.
[05:40] <afflux> cool. :/
[06:26] <ogra> pitti, ltsp-client-core should be there now
[06:26] <ogra> (at least it built on all arches)
[06:37] <wasabi> Keybuk: you once said this: "Any filesystem that processes file operations out of order is BUGGY!"   In regards to XFS. Do you still consider that true?
[06:43] <pitti> ogra: sparc build is still missing; also, this has some lintian warnings/errors
[06:43] <ogra> oh ?
[06:45] <mikmorg>  /where mdomsch
[06:45] <ogra> pitti, ?
[06:46] <ogra> ogra@laptop:~/devel$ lintian -I ltsp_5.0.11_source.changes
[06:46] <ogra> W: ltsp source: changelog-should-mention-nmu
[06:46] <ogra> W: ltsp source: source-nmu-has-incorrect-version-number 5.0.11
[06:46] <pitti> ogra: check the binaries :)
[06:47] <ogra> gah, pbuilder outdated ... that will take a moment
[06:47] <Keybuk> wasabi: I still think it's stupid for a filesystem to do, yes
[06:48] <wasabi> Why? Doesn't ZFS do the same thing?
[06:48] <Keybuk> wasabi: operations on a given file should be processed in sequence
[06:48] <wasabi> On a given file, sure, but on two different files?
[06:48] <wasabi> Oh I see what you're saying.
[06:48] <Keybuk> two different files - who cares
[06:48] <wasabi> I think I finally realized where I was hung up.
[06:49] <ogra> pitti, hrm, it needs the xfonts-base dep ...
[06:49] <wasabi> The conversation was about ... XFS not working right during crashes of update-alternatives because it doesn't flush the file before proceeding
[06:49] <Keybuk> right
[06:50] <pitti> ogra: oh, that might be unjustified; I was more concerned about the dependencies/debconf stuff
[06:50] <wasabi> trying to reparse it.
[06:50] <Keybuk> what XFS does is process a rename() call on a given file before all queued write()s on that file have been processed
[06:50] <Keybuk> so you do
[06:50] <Keybuk> open (file, O_RDWR)
[06:50] <Keybuk> write (...)
[06:50] <Keybuk> write (...)
[06:50] <Keybuk> close (...)
[06:50] <Keybuk> rename (...)
[06:50] <Keybuk> and you end up with something on disk that isn't fully written
[06:50] <wasabi> So the writes don't go through, but the rename does.
[06:50] <ogra> pitti, right, inputattach is a bug
[06:50] <Keybuk> yeah
[06:51] <wasabi> But still, shouldn't you be forced to fsync the file if you want to be sure that the contents are on disk, irregardless of order of operations?
[06:51] <Keybuk> I don't think so
[06:51] <wasabi> Does a rename guarentee an implicite sync?
[06:51] <pitti> ogra: nothing too serious, if you fix them in the next version, that's fine
[06:51] <wasabi> Who says that?
[06:51] <ogra> pitti, the debconf stuff must come from a debian merge, we dont use debcof in ltsp-server ... checking where that comes from
[06:51] <Keybuk> I think that certain operations should be guaranteed
[06:51] <pitti> ogra: I just want to wait for sparc
[06:51] <Keybuk> nobody says that
[06:51] <ogra> pitti, ok
[06:51] <Keybuk> it's just the way everything behaved until XFS came along :p
[06:51] <wasabi> Heh.
[06:51] <ogra> i have a 0.12 here anyway already, i'll add the fixes
[06:52] <wasabi> But still, an app that DOESN"T rename, would still have to fsync before moving on.
[06:52] <Keybuk> theoretically that app doesn't care whether it's on the disk or not
[06:53] <wasabi> Depending on the app, it might.
[06:53] <Keybuk> the rename() case is special, since the app is clearly trying to do something atomic
[06:53] <wasabi> u-a seems to be an appropiate situation for that. Since it is basically part of the dpkg transaction.
[06:53] <wasabi> dpkg can't consider the package really completely installed until it's sure all the files are commited.
[06:54] <wasabi> If ti does, then you're talking about corrupt/missing metadata between files (dpkg's database and the installed files themselves)
[06:54] <Keybuk> actually, fsync() doesn't guarantee that either
[06:54] <Keybuk> it just guarantees that the kernel filesystem is in sync
[06:54] <wasabi> It guarentees as much as the kernel can know.
[06:55] <Keybuk> it's an interesting point
[06:56] <wasabi> Anyways, it seems wrong that a crash after dpkg says a package is installed could result in corrupt files being installed because they weren't flushed.
[06:56] <wasabi> At least, it seems as if we're not doing what we can do about it, regardless of hardware caches.
[06:56] <Keybuk> a crash?
[06:56] <wasabi> power failure.
[06:56] <Keybuk> power failure has the same problem though
[06:56] <Keybuk> because of the hardware
[06:56] <wasabi> Yes, but sme people can guarentee the hardware does not cache.
[06:56] <wasabi> For good reason they buy hardware like that.
[06:57] <Keybuk> dpkg could say the status is installed, because that reached the hardware, but the files themselves might not have
[06:57] <wasabi> Or, they can guarentee the hardware is battery backed.
[06:57] <iwj> IMO all of these cases are bugs in the filesystem.
[06:57] <wasabi> If their software is undermining that.
[06:57] <Keybuk> wasabi: if they can guarantee that, they can guarantee the same things from the filesystem, no?
[06:57] <wasabi> Hmm. Thinkging. One sec. ;0
[06:57] <iwj> You use fsync if you mean `this data needs to hit the disk because I am about to promise someone else that we're not going to forget it'.
[06:57] <iwj> That's quite different from the general requirement of the filesystem not to fuck up.
[06:58] <wasabi> No... because we're still talking about, two different files.
[06:58] <iwj> Saying `you must fsync if you want the fs not to fuck up' will just lead to every application having to fsync which is obviously daft.
[06:58] <Keybuk> wasabi: if you can guarantee that writes always reach the hardware ...
[06:58] <wasabi> iwj: Never said that.
[06:58] <Keybuk> wasabi: ... then you can guarantee that they always reach the filesystem ...
[06:58] <wasabi> And how can you do that?
[06:58] <Keybuk> "sync"
[06:58] <wasabi> u-a doesn't sync it though.
[06:59] <Keybuk> reaching the filesystem is intrinsically uninteresting, except for the case of file handover
[06:59] <wasabi> You want me to manually type sink between running u-a?
[06:59] <Keybuk> no, I mean mount the filesystem with "sync" as the option!
[06:59] <wasabi> Oh. Hah.
[06:59] <wasabi> Do you really consider taht the solution?
[06:59] <Keybuk> power outage => you care about writes reaching the hardware
[06:59] <Keybuk> which means that you need them to reach the filesystem *and* hardware
[06:59] <wasabi> Destroy all performance improvements of your hardware and file system when there are other appropiate solutions?
[07:00] <Keybuk> since we can only guarantee the later in special cases where the user has made attempt to secure that, it is not unreasonable to expect them to make attempts to secure the same for the intermediate filesystem
[07:00] <wasabi> If you want to ensure a file is written, you call fsync. That is the convention, no?
[07:00] <Keybuk> no
[07:00] <wasabi> That exists for a reason, no?
[07:00] <iwj> I think it's a bug if after a power outage the filesystem has left the disk in a state that doesn't correspond to any of the states which would have been visible to a user process before the crash.
[07:00] <Keybuk> if you want to ensure that the file is available for other processes to read, you call fsync()
[07:00] <iwj> Keybuk: What ?
[07:00] <Keybuk> it does not guarantee that it is written
[07:00] <wasabi> Eh?
[07:00] <iwj> Other processes are supposed to see the file straight away regardless of any fsync.
[07:01] <Keybuk> iwj: then what's the XFS bug?
[07:01] <mjg59> Keybuk: It guarantees it's hit disk. It doesn't guarantee it's hit the filesystem.
[07:01] <iwj> The XFS bug ?  You mean the one where you get a file full of zeroes ?
[07:01] <Keybuk> there's a write()/close()/rename() bug with XFS
[07:01] <wasabi> Keybuk: It happens when there is a power failure after writing two files and renaming.
[07:01] <Keybuk> due to a missing fsync()
[07:01] <wasabi> Because nobody calls fsync.
[07:01] <iwj> Err, earlier you said ZFS.
[07:01] <wasabi> write(); write(); rename(); crash.
[07:01] <Keybuk> ok, well clearly I'm even more confused about all of this than I thought :-)
[07:02] <iwj> Oh, no, I misread.
[07:02] <wasabi> Heh.
[07:02] <wasabi> I just wanted to question what you said in the bug report a year ago... because I find it fundamentally contrary to everything I've been taught. :0
[07:02] <Keybuk> wasabi: I now don't understand why this doesn't work on XFS
[07:02] <iwj> wasabi: It is my view that dpkg does the right thing and if the filesystem causes what dpkg does not to work properly (including in the case of a crash during package installation) then that's a bug in the filesystem.
[07:03] <wasabi> Which is that fsync is to be used to guarentee that at a given point in time something has or has not been commited to the best of the knoweldge of the kernel 
[07:03] <wasabi> Keybuk: u-a writes a file, then renames the old file to the new, but nothing ever calls fsync to ensure the first write happend.
[07:03] <iwj> Keybuk: There are bugs in many journalling filesystems which have a tendency to write out the metadata to disk before the data.  The result is that if you crash at an unfortunate moment, the file you renamed over the top of the old data turns out to contain zeroes (or even garbage).
[07:03] <wasabi> But the renames DOES go through.
[07:03] <Keybuk> wasabi: but why does that matter?
[07:03] <wasabi> So you have a properly named file pointing at invalid data.
[07:03] <Keybuk> any application reading the file would get it from the cache, no?
[07:04] <iwj> Keybuk: No, after a crash.
[07:04] <Keybuk> (assuming no intermediate power outage)
[07:04] <Keybuk> right
[07:04] <wasabi> We're talking about power outages.
[07:04] <Keybuk> so that's just a bug in the filesystem
[07:04] <wasabi> Haha.
[07:04] <Keybuk> stupid filesystem, etc.
[07:04] <wasabi> Why do you think that? That's what boggles my mind.
[07:04] <Keybuk> application did a perfectly reasonable set of syscalls
[07:04] <Keybuk> write(), write(), close(), rename()
[07:04] <Keybuk> it's up to the filesystem to ensure record of those aren't lost
[07:04] <Keybuk> and record them in the journal
[07:04] <mjg59> Why would you then expect the data to be on disk?
[07:04] <mjg59> We don't journal data
[07:04] <mjg59> Because otherwise performance is dreadful
[07:04] <iwj> mjg59: We don't care whether the data are on disk or not.
[07:05] <wasabi> Keybuk: The thing is dpkg moves on, and writes in it's status file that the installation is done.
[07:05] <Keybuk> mjg59: the alternative is to fsync() everything on close though, no?
[07:05] <mjg59> Keybuk: If you want to guarantee that something is on disk, yes
[07:05] <wasabi> Keybuk: So when recovering from the crash, dpkg says it's "done".
[07:05] <iwj> What we care about is that after a crash (or other problem) _either_ the situation is as was before, or as it was after.
[07:05] <wasabi> But in realitity, a few files are corrupt.
[07:05] <iwj> Ie, either the writes should have taken effect or the rename shouldn't.
[07:05] <Keybuk> mjg59: in what circumstances would I want to guarantee that something is on disk?
[07:05] <wasabi> Before dpkg registers that it's done, it should fsync the files it just modified.
[07:05] <wasabi> That's common transactional programming.
[07:05] <iwj> No, fsync is not for making transactions.
[07:05] <Keybuk> wasabi: so we should fsync() everything?
[07:05] <Keybuk> why don't we patch the kernel to fsync() on close() ?
[07:06] <Keybuk> (I'm not being annoying, I seriously do not understand)
[07:06] <wasabi> No, not everything. Only things that form some sort of transactional isolation.
[07:06] <mjg59> Keybuk: Because that would also suck
[07:06] <Keybuk> why is this a special case?
[07:06] <wasabi> a) do file modifications b) record that we did file modifications
[07:06] <pitti> Keybuk: that has acttually been proposed
[07:06] <Keybuk> wasabi: so make close fsync?
[07:06] <wasabi> Do you not think something should happen before b?
[07:06] <mjg59> iwj: Is that assumption codified anywhere?
[07:07] <pitti> Keybuk: http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html
[07:07] <wasabi> Keybuk: No, again, only for things which are transactional. dpkg is that.
[07:07] <Keybuk> wasabi: why is dpkg transactional?
[07:07] <pitti> Keybuk: that was for an entirely different context, though (more sane handling of removable devices)
[07:07] <mjg59> iwj: If you're journalling metadata, it's unsurprising that a crash will result in your metadata/data being out of sync
[07:08] <iwj> mjg59: It's an assumption inherent in the way that EVERY PROPER PROGRAM SINCE THE DAWN OF TIME HAS UPDATED A FILE.
[07:08] <wasabi> Keybuk: It's a good question, and the only answer I have is because that's how people expect it to be. It tells the user "yes, you're install is done."
[07:08] <iwj> The _standard official approach_ is open(".tmp") write rename
[07:09] <Keybuk> wasabi: so should all instances of write()/close()/rename() be transactional?
[07:09] <Keybuk> if so, maybe rename needs to sync the files?
[07:09] <iwj> You use fsync if you want to synchronise with some real-world thing outside the computer.
[07:09] <mjg59> No, nothing should implicitly sync the files
[07:09] <wasabi> Maybe it does. Except I don't think that guarentee is codified anywhere is it
[07:09] <iwj> Like if you're receiving mail.
[07:10] <wasabi> iwj: You mean like a user? heh
[07:11] <wasabi> APPLICATION USAGE    The fsync() function should be used by programs which require modifications to a file to be completed before continuing; for example, a program which contains a simple transaction facility might use it to ensure that all modifications to a file or files caused by a transaction are recorded.
[07:12] <Keybuk> except it doesn't
[07:12] <Keybuk> it just ensures that the kernel has finished with it, and it's heading somewhere near the hardware
[07:12] <wasabi> yes yes yes, we know, hardware will subvert it Sometime.
[07:12] <mjg59> Keybuk: No, fsync() guarantees that it's hit hardware 
[07:13] <mjg59> Whether it's hit platters may be another issue
[07:13] <Keybuk> NOTES
[07:13] <Keybuk>        If the underlying hard disk has write caching enabled,  then  the  data
[07:13] <Keybuk>        may  not  really  be  on  permanent  storage when fsync() / fdatasync()
[07:13] <Keybuk>        return.
[07:13] <Keybuk> right, hit platters
[07:13] <wasabi> Yes, we know that. Hardware will subvert it.
[07:13] <Keybuk> so we're all doomed anyway
[07:13] <wasabi> No, we're not.
[07:13] <Keybuk> let's go shopping instead
[07:13] <wasabi> None of my hardware does that.
[07:13] <wasabi> Because I have battery backed write caches. ;0
[07:13] <Keybuk> wasabi: none of my filesystems fuck up either ;P
[07:13] <Keybuk> because I use sensible ones
[07:13] <wasabi> Heh.
[07:14] <iwj> Keybuk: Nonsense.  There is a right answer here and it's that fsync should guarantee that everything relevant to that file up to that point will survive future crashes etc.
[07:14] <iwj> And if it fails to guarantee that it's a bug.  Consumer hardware in buggy shocker.
[07:14] <wasabi> iwj: "as best it can"
[07:14] <iwj> But that's not relevant.
[07:14] <iwj> wasabi: No, _guarantee_.  But if the hardware is buggy then the machine is buggy.  But this is all irrelevant.
[07:14] <wasabi> Sure. But we fail on non-buggy hardware. The only question is whether the FS is buggy.
[07:15] <iwj> Because dpkg doesn't need to know that the changes it makes with write have it the disk before it calls rename.
[07:15] <wasabi> dpkg should know that before it records in it's status file that they did.
[07:15] <iwj> It doesn't mind at all if the machine crashes and everything is as if the writes and rename never happened.
[07:15] <wasabi> So that upon resuming the machine, the user can identify which packages might be in an inconsistant state.
[07:16] <iwj> No, because that's all internal to the machine.
[07:16] <iwj> dpkg doesn't mind if the whole machine is rewound.
[07:16] <wasabi> Oh, sure. But the thing is dpkg is never marking what needs to happen in what order. =/
[07:16] <iwj> And indeed allowing that possibility makes it possible for dpkg to run much faster because it doesn't need to constantly stop and prat about with fsync.
[07:16] <wasabi> So it can't be rewound. It just gets scrambled.
[07:17] <iwj> wasabi: Yes it is, it makes system calls in that order.
[07:17] <wasabi> And all file operations should happen in order, always?
[07:17] <iwj> A filesystem is buggy if any sequence of system calls results in scrambled data.
[07:17] <wasabi> Even for independent files?
[07:17] <iwj> wasabi: Yes.  That's the whole point of the unix file api.
[07:17] <wasabi> So why are we mounting things async?
[07:18] <wasabi> In fact who invented that?
[07:18] <iwj> I don't know.  The fs authors seem to have made it the default because it goes faster.
[07:18] <iwj> Who cares if it breaks, eh ?
[07:18] <mjg59> We mount thinks async because the alternative is stupid
[07:18] <wasabi> Double infact, how does dpkg know if it's using two file systems?
[07:18] <wasabi> And how does it know they are both in order? heh
[07:18] <iwj> mjg59: We should write data and metadata together rather than deliberately writing one and not the other.
[07:18] <iwj> wasabi: 
[07:19] <mjg59> iwj: ext3 optionally has that behaviour, but it kills performance
[07:19] <iwj> If you like, mount everything sync and see how long your installs take.
[07:19] <wasabi> I think at some point we introduced "points of atomicity", and that's worked great. Except when people forget to mark their points.
[07:19] <iwj> wasabi: That's not what fsync ever did and furthermore what you're doing is not introducing "points of atomicity" but removing them.
[07:19] <Keybuk> wasabi: I suspect it's more that people forget to tell anybody they introduced the requirement to mark their points in the first place, and what kinds of places they should
[07:19] <mjg59> iwj: I think an argument that does make sense is that metadata in the journal should be flagged as to whether it refers to changes that haven't hit disk
[07:20] <iwj> mjg59: I don't care how it's implemented.  I just care that after a crash I see a filesystem that looks vaguely like something reasonable.
[07:20] <Keybuk> I do tend to agree with Ian here
[07:20] <Keybuk> if a filesystem has been told to do A, B and then C
[07:21] <mjg59> Well, the argument is that it's reasonable (ie, consistent)
[07:21] <Keybuk> and does C, without even recording that A and B haven't happened and need to, then that's a filesystem issue
[07:21] <wasabi> Alright. I agree now. Ya'll win.
[07:21] <mjg59> I suspect the XFS authors have different ideas about what "reasonable" means
[07:21] <Keybuk> it's reasonable for it to process things out of order *if* there's a filesystem transaction API
[07:22] <iwj> Keybuk: Right.  And you'd have to ask applications to turn it on explicitly.
[07:22] <Keybuk> which guarantees that all or none of the transaction hits disk
[07:22] <iwj> And applications which didn't say "I'm using the new transaction api" would get the original semantics.
[07:23] <iwj> Or even just an explicit sequence points API.  I don't have objections to that.
[07:23] <Keybuk> for example
[07:23] <Keybuk> how do I fsync() a rename? :p
[07:23] <iwj> I do object to changing the meaning of the existing calls so as to break every previously-reliable program.
[07:23] <Keybuk> or an unlink? 
[07:23] <iwj> But I have to go and have dinner.
[07:23] <iwj> Keybuk: Keep up the good fight :-).
[07:23] <wasabi> iwj: thanks for setting me straight. :0
[07:24] <iwj> Any time :-).
[07:25] <desrt> Keybuk; sup?
[07:25] <Keybuk> desrt: hey
[07:25] <desrt> wasabi; word
[07:25] <wasabi> desrt: sentence
[07:25] <desrt> iwj; goodday :)
[07:26] <desrt> mjg59; if my ata_piix module has usecount 4 and my ahci module has usecount 0 does that mean that linux is ignoring my bios setting of "ahci mode"?
[07:27] <mjg59> Yes
[07:27] <mjg59> dmesg?
[07:27] <desrt> hold on a sec.
[07:27] <desrt> i can't do too much for you right now since it's my home machine and i'm at work, but i can ssh
[07:27] <desrt> what part of dmesg do you need?
[07:27] <mjg59> /var/log/dmesg
[07:28] <desrt> oh.  whole thing.  k :)
[07:28] <desrt> http://desrt.mcmaster.ca/random/dmesg
[07:29] <Hobbsee> hiya desrt 
[07:29] <desrt> Hobbsee; hello.  what's up?
[07:30] <Hobbsee> desrt: i'm pondering uploading to main.
[07:30] <desrt> if you're looking for something to do, acpi-support could use a NMU
[07:32] <Hobbsee> i wasnt....neither can i upload to debian.
[07:32] <desrt> i mean ubuntu's :)
[07:33] <geser> are new source packages still pulled regularly from Debian?
[07:33] <Hobbsee> desrt: that means i'd have to understand what's going on with it
[07:33] <desrt> Hobbsee; it was a joke :)
[07:33] <Hobbsee> :P
[07:34] <mjg59> desrt: Can I have an lspci?
[07:34] <desrt> mjg59; of course
[07:35] <desrt> http://desrt.mcmaster.ca/random/lspci-for-mjg59
[07:35] <Hobbsee> (damn the ' and enter being so close)
[07:35] <thekorn> pitti:  I just added a patch to fix bug 119872
[07:35] <ubotu> Launchpad bug 119872 in python-launchpad-bugs "BugList's filters do not work" [Undecided,Fix committed]  https://launchpad.net/bugs/119872
[07:36] <pitti> thekorn: ooh, rock
[07:36] <mjg59> desrt: Your BIOS isn't setting your chipset to AHCI mode
[07:36] <desrt> mjg59; silly bios.
[07:37] <desrt> mjg59; it has an option for it and i've selected AHCI
[07:37] <mjg59> Well, your jmicron controller is set to AHCI
[07:37] <mjg59> Maybe it's only doing it for that
[07:37] <cjwatson> geser: yes, up to Debian import freeze == 21 June (GutsyReleaseSchedule)
[07:37] <desrt> hmm.  that seems likely
[07:37] <desrt> ich8 is ahci capable with a few bits flipped, i suppose?
[07:37] <mjg59> Yes
[07:37] <cjwatson> though apparently nobody's done it for a few days, so I will
[07:38] <mjg59> Try the patch I posted
[07:38] <desrt> (see your blog for the appropriate patch)
[07:38] <desrt> nod.
[07:38] <desrt> (having a 100%-lrm-free machine reduces the pain quite a lot...)
[07:40] <desrt> mjg59; a rather direct indication of workingness of ahci vs. piix mode is that in ahci hotswap will work and in piix it will not?
[07:41] <mjg59> desrt: Just check dmesg and see if your drives are coming up on ata_piix or not
[07:42] <desrt> (again)
[07:45] <mjg59> Or just make sure the drives are on the jmicron
[08:05] <cjwatson>   * Handle architectures in all dependency fields in debian/control,
[08:05] <cjwatson>     even those of binary packages. Closes: #252657, #324741, #347819
[08:05] <cjwatson> whoa, I never knew that had been done in dpkg
[08:05] <thom> oh, nice
[08:05] <thom> no more arch: any insanity just to get platform deps
[08:06] <cjwatson> well
[08:06] <cjwatson> no, it's done in dpkg-gencontrol
[08:07] <cjwatson> so only applies to architecture: any
[08:36] <nomeata> hi. Has anyone tried to use upstart initscripts to create standard sys-V-init-script from them?
[08:43] <nomeata> Keybuk: Hi. Are you coming to debconf?
[09:04] <Keybuk> nomeata: no, why?
[09:05] <nomeata> Keybuk: Id like to abuse the upstart init script file format :-)
[09:05] <nomeata> Keybuk: I just wrote a mail to upstart-devel
[09:05] <Keybuk> nomeata: the main difference between upstart and Debian's init script format is what will bite you
[09:05] <Keybuk> upstart you specify the daemon to exec, that remains in the foreground
[09:06] <Keybuk> Debian init scripts run the daemon in the background, then return, with some other way of finding the daemon again
[09:06] <nomeata> That is true.
[09:07] <nomeata> Maybe the generated init script could still use a foreground daemon, and handle it through start-stop-daemon
[09:07] <Keybuk> the other problem is that the "when the init script is run" stuff varies so wildly, there's no way to make it common
[09:07] <Keybuk> e.g. Debian uses numbered runlevels, with numbered sequences
[09:08] <Keybuk> others use comments in the generated init script to seed those
[09:08] <Keybuk> other things like initNG use "dependencies"
[09:08] <Keybuk> Upstart uses eventgs
[09:08] <Keybuk> etc.
[09:08] <nomeata> But dont 90% of the daemon have non-specific requirement?
[09:08] <nomeata> ok, the number is just a rough guess.
[09:09] <nomeata> And the solution is not intended to work for every single daemon, just those where init scripts are just repetition.
[09:11] <Keybuk> no idea
[09:11] <nomeata> The big plus would be of course that those daemons would suddently have a real upstart script shipped.
[09:11] <Keybuk> in theory, anyway, in "start" you'd the pre-start script, fork the daemon, then run the post-start script
[09:11] <Keybuk> and in "stop" would run the pre-stop script, kill the daemon, then run the post-stop script
[09:11] <nomeata> right
[09:12] <Keybuk> and then just shim for things like env/umask/chdir/etc.
[09:13] <nomeata> tomorrow well have a BOF on the idea. Do you want to be kept in the loop? 
[11:17] <pygi> Zdra, poke
[11:40] <TheMuso> doko: Just replied to your email with the state of espeak. I'm happy for you to do the merge, but I also don't mind doing it, with your work as a basis. I meant to push my changes to Debian very soon anyway, as I am working with him on other projects.
[11:41] <doko> TheMuso: cool, I wouldn't mind if you go ahead with the upload
[11:41] <TheMuso> doko: Ok. I'll get to it later today. Thanks again
[11:41] <doko> not that urgent ...
[11:41] <TheMuso> Yep I know.
[11:42] <TheMuso> I'm assuming portaudio19 has made its way to main by now?
[11:42] <crimsun> portaudio19 | 19+svn20070125-1ubuntu1 | gutsy/universe | source
[11:43] <TheMuso> crimsun: Yeah I saw that yesterday, which is why I am wondering, as I saw arequest to move it to main the other day...
[11:43] <TheMuso> Haven't had time yet to update my gutsy chroot and look myself.
[11:45] <crimsun> ogra: do you mind if I handle alsa-plugins (after alsa-lib 1.0.14-1ubuntu1 builds)?
[11:46] <geser> TheMuso: have you tried rmadison from devscripts? (rmadison -u ubuntu portaudio19)