[17:40] <Eickmeyer[m]> OvenWrks: studio-controls 2.3.6 appears to be broken under kinetic for some reason.
[17:41] <OvenWrks> broken in which way?
[17:42] <Eickmeyer[m]> Seems to freeze at "checking for phones plugged in"
[17:43] <OvenWrks> I guess I should be able to force install the same package into jammy?
[17:44] <Eickmeyer[m]> I put it in backports, so it should be available to you already.
[17:44] <Eickmeyer[m]> Identical package, really.
[17:45] <Eickmeyer[m]> Not like it has any binaries to compile against. FWIW, 2.3.5 worked fine.
[17:45] <OvenWrks> Yeah no compiling.
[17:47] <Eickmeyer[m]> I have to downgrade so I can work, but hopefully you can find a problem. FWIW, I have an autojack.log if you need it.
[17:48] <OvenWrks> It has decided to remove some kernels... this may take a while
[17:48] <OvenWrks> Eickmeyer[m]: that would be helpful yes. Hoping you have it set to extra.
[17:49] <Eickmeyer[m]> Better, I set it to debug.
[17:49] <OvenWrks> extra has more info than debug but ok.
[17:49] <Eickmeyer[m]> Actually, no, that's not better. heh
[17:52] <Eickmeyer[m]> Getting you the log now.
[17:53] <Eickmeyer[m]> FYI, the UI goes completely unresponsive.\
[17:54]  * Eickmeyer[m] posted a file: (16KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/usUJrMkLpmrseNBARbTFZLEn/autojack.log >
[17:54] <Eickmeyer[m]> OvenWrks: ^
[18:03] <Eickmeyer> OvenWrks: Yep, downgraded to 2.3.5, no issues.
[18:15] <OvenWrks> I need to redo all the logging stuff :P not much there... would have got more from running autojack from the command line I think.
[18:16] <Eickmeyer> Yeah, probably. I can't now because I started my workday, which takes me out for a few hours.
[18:16] <OvenWrks> anyway. I have found something. I think I moved a line at the last minute and the variable it uses is not in the new place
[18:16] <Eickmeyer> Ah.
[19:35] <OvenWrks> 2.3.7 runs on this machine at least  ;)
[20:18] <Eickmeyer[m]> OvenWrks: I'll release it to kinetic, we'll know soon.


[00:35] <DeltaCode> What is an example of a vfs path?
[01:16] <mhall119> smb://
[01:16] <mhall119> vfs can be lots of things
[01:16] <mhall119> IIRC, the are mounted to ~/.gvfs/


[09:22] <verwilst> hello, i would like to test a small patch to the kernel that fixes a kernel oops: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020207/comments/11 but my kernel doesnt seem to build with make-kpkg :(
[09:22] <ubot2`> Ubuntu bug 1020207 in linux "gfs2 kernel oops when deleting file as first action after mounting" [Medium,Confirmed]
[09:22] <verwilst> fsam7400.c:(.text+0x3b0): undefined reference to `populate_rootfs_wait'
[09:22] <verwilst> maybe somebody here feels like creating a new kernel deb with this patch that i can test? :)
[09:22] <apw> verwilst, i'll have a look in a minutre
[09:23] <verwilst> apw, awesome thanks! just gimme a yell
[09:27] <apw> verwilst, so is this against precise ?
[09:27] <verwilst> yip
[09:27] <verwilst> the 12.04 kernel oops'es as soon as you remove a file on gfs2 :)
[09:27] <verwilst> it's fixed in 3.3-rc6, which this mini patch is a backport of
[09:29] <verwilst> if i can test that this patch works, the redhat guy is willing to give his ACK for -stable inclusion mainline
[09:36] <apw> verwilst, whats in the bug is all mangled, and if you want a specific patch included so you can send in a Tested-by it might make sense to email me the patch so i can apply the exact patch
[09:36] <apw> verwilst, email in pm
[09:38] <apw> verwilst, if there isn't a patch i can make one out of that hunk .... let me know
[09:39] <verwilst> apw, well, i just pasted the thing i made :)
[09:39] <verwilst> i can mail the patch itself
[09:39] <apw> which ever you want
[09:39] <verwilst> it's the one in the comments, right? #11, the 4 lines
[09:39] <apw> i am assuming thats the one you wanted
[09:40] <apw> but it is you who is asking, so i derfer to you :)
[09:42] <verwilst> apw, you have mail :)
[09:43] <verwilst> it's done in fs/gfs2 btw
[09:43] <verwilst> maybe i should have done it from the root
[09:47] <apw> verwilst, i'll cope ... which commit in the upstream kernel is this a backport of?  am just doing the commentary
[09:47] <apw> verwilst, and i am going to take the liberty of adding your signon
[09:47] <apw> signoff
[09:48] <verwilst> apw, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=718b97bd6b03445be53098e3c8f896aeebc304aa
[09:49] <apw> verwilst, and we don't need the other hunk ?
[09:50] <verwilst> apw, normally no, since out_inodes doesnt exist in 3.2
[09:51] <verwilst> apw, https://www.redhat.com/archives/linux-cluster/2012-August/msg00151.html
[09:51] <apw> ok.  /me shoves it on a buildder
[10:00] <apw> verwilst, ok looking at this if we take a previous fixup patch we can take the patch you want unaltered
[10:00] <apw> verwilst, so that might be a better solution as the missing error case (which your version doesn't have to fix) looks like something we want to fix also
[10:00] <verwilst> the -EROFS?
[10:01] <verwilst> that would be VERY nice apw :)
[10:02] <verwilst> apw, this patch is actually part of a series with some more handy-looking patches: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=891003abb0db6bfffd61b76ad0ed39bb7c3db8e1
[10:02] <apw> verwilst, ok i'll build a kernel with that as well
[10:03] <verwilst> apw, not sure about the possibility to get those in, just wanted to show you as it might  make gfs2 a better experience on precise :)
[10:03] <apw> hmmm, a tricker proposition if people are not hitting the issue
[10:03] <verwilst> the one i pasted is (for now) the only showstopper for me
[10:04] <apw> from an SRU perspective
[10:04] <verwilst> yeah
[10:04] <verwilst> apw, it was just FYI :)
[10:13] <apw> verwilst, ok here is the first one: http://people.canonical.com/~apw/lp1020207-precise/ with just your one hunk
[10:14] <apw> verwilst, second one with the unaltered patch is building now
[10:30] <apw> verwilst, ok they are both there, the earlier timestamp is your patch, the later timestamp is the two cherry-picks ... test them if you could and let me know
[10:40]  * apw pokes verwilst
[10:48] <verwilst> apw, i was out for f00d :)
[10:49] <verwilst> apw, should i test them both?
[10:49] <ogra_> eat cake then ...
[10:49] <apw> verwilst, i would suggest testing the newer one, and if that works we can suggest that to dave woodhouse
[10:51] <verwilst> alright great
[10:51] <verwilst> so there are more gfs2-related fixes apw?
[10:52] <apw> verwilst, this contains just the foundation patch and the full cherrypick of the patch you were porting part of
[10:52] <apw> we might also suggest separatly that one at least of the other two you mentioned be pushed to stable, but that is a separate transaction me thinks
[10:52] <verwilst> yeah idd
[10:53] <verwilst> the gfs2_grow thing for example
[10:53] <verwilst> oh well, they all look like nice fixes :)
[11:01] <verwilst> apw, with that other patch included, backporting gfs2 fixes should be much more straightforward i guess in the future
[11:19] <ppisati> http://www.cnx-software.com/2012/08/20/codethink-launches-the-baserock-slab-arm-server/
[11:19] <ppisati> ogra_: ^
[11:19] <ppisati> ARMv5? no, i mean, really?
[11:26] <apw> ppisati, ? core ARMv7-A processors
[11:27] <apw> ppisati, i note they all have massive fans on them, not sure thats the idea :)
[11:36] <ogra_> the v5 system is the management
[11:40] <apw> oh thats dumb, so you have to have a different distro on management, awsome
[11:53] <ppisati> but those could be candidates for the arm builders
[12:08] <verwilst> apw, well, it certainly boots in kvm.. :)
[12:09]  * cking reboots
[12:09] <verwilst> apw, will test a normal server with a cluster now :)
[12:09]  * ppisati -> out for lunch
[12:13]  * henrix -> lunch
[12:28] <verwilst> apw, great success!!
[12:31] <apw> verwilst, good news
[12:31] <apw> verwilst, so i'll reply to that original thread with the two patches together
[12:31] <verwilst> yip
[12:32] <verwilst> apw, so, do you decide what goes into the new precise kernel?
[12:32] <apw> verwilst, not on my own no, but a bug with a fix is something which is SRUable
[12:33] <apw> verwilst, and if it goes into stable then it will hit precise without any action anyhow
[12:33] <verwilst> apw, i would certainly think so :) thanks a lot for the help btw!
[12:33] <apw> verwilst, np
[12:33] <verwilst> apw, will you push it towards stable?
[12:35] <apw> verwilst, i think the appropriate thing is for me to add your tested-by (if thats ok) to these two patches and email them as a set in reply to Steven
[12:35] <verwilst> okido
[12:35] <verwilst> apw, i kinda sent a mail to him as well though, but without the tested-by thing.. feel free to reply and take credit where needed :D
[12:35] <verwilst> in all my excitement.. :D
[12:36] <verwilst> ( linux cluster ML )
[12:36] <apw> verwilst, heh just want him to know you tested it, so i'd add Tested-by: your email in the bottom
[12:37] <verwilst> well, i pointed him to the link you gave me, so if you add it to the patches there... :)
[12:38] <rtg> apw, are you guys working on overlayfs ?
[12:38] <apw> rtg, i am working on it yes, but not related to this discussion above; crashing heap of junk
[12:38] <rtg> apw, ah, bummer
[12:39] <verwilst> apw, i'm going to install your kernel on every node of my cluster
[12:40] <apw> verwilst, that is the *1111* one that you tested right ...
[12:40] <verwilst> Linux vm02-test 3.2.0-31-generic #48~lp1020207v201208221111 SMP Wed Aug 22 10:19:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[12:40] <apw> rtg, i have an id patch accepted, an NFS fix pending, and another i am investigating
[12:41] <apw> verwilst, ok i have cleaned up that directory then so only the relevant files are in there, and added the tested-by:, if you want to check its the email you don't mind being in the public record, and if not tell me in PM what you want :)
[12:42] <verwilst> it's fine apw :)
[12:43] <verwilst> nothing my dspam can't handle ;)
[12:50] <apw> verwilst, heh good, as i am not subscribed to that list, i'll let you keep an eye and poke me if i need to do something with those patches, i am hoping Steve will pass them on, if not then i should
[12:51] <verwilst> he usually replies pretty quickly
[12:51] <verwilst> precise is really starting to get somewhere imo
[12:51] <verwilst> 2 months ago i was on the brink of switching everything to centos :)
[12:51] <verwilst> because it felt more enterprisy
[12:52] <verwilst> every step of the way to a working cluster was riddled with bugs :)
[12:52] <verwilst> but now i chased enough people to fix my last hurdle, it's started to look very nice :)
[12:52] <verwilst> my faith has been restored
[12:52] <verwilst> ;)
[12:53] <verwilst> well, 1 hurdle left in lvm2, but hey
[12:54] <xnox> verwilst: clvm?
[12:54] <verwilst> yip
[12:55] <verwilst> the no-monitoring patch thing xnox :)
[12:55] <xnox> verwilst: yes. indeed. Do you think we should not have it? TBH I don't know what that monitoring does.
[12:55] <verwilst> it works for me now because i manually removed the patch from the deb and recompiled, but hey, it will be a warm fuzzy feeling when it will be really fixed
[12:56] <verwilst> xnox, it's only used to build udeb's iirc
[12:56] <xnox> verwilst: also in quantal we had clvm init script borked for a little while. Now fixed.
[12:56] <verwilst> xnox, because dmeventd isnt running or something similar i think
[12:56] <verwilst> xnox, it's the same in debian though
[12:56] <verwilst> xnox, ah, is the init script something backportable to precise?
[12:57] <xnox> verwilst: it should be applied the whole time, it's just in the running system you can specify monitor=1 or whatever the option is.
[12:57] <xnox> verwilst: precise has it. quantal dropped it for couple of months. So if you recompiled from quantal, beware ;-)
[12:57] <verwilst> xnox, yeah, but that's the part that's broken :) monitor=xx isnt read anymore
[12:57] <xnox> verwilst: ah =) interesting.
[12:58] <verwilst> xnox, i think i took it from debian
[12:58] <verwilst> the .95
[12:58] <xnox> verwilst: well quantal now has .95 merge with bug-fixes on top of debian. there are a few things different on debian.
[12:58] <verwilst> xnox, https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368
[12:58] <ubot2`> Ubuntu bug 833368 in resource-agents "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress]
[12:59] <verwilst> xnox, well, it's currently a test setup, i hope to reinstall them once i go production with all the 'native' precise packages :)
[12:59] <verwilst> except like libvirt 0.9.13 etc ;)
[13:00] <xnox> verwilst: well precise has old lvm2 (missed the feature freeze), so you might have to backport lvm2 from quantal.
[13:00] <xnox> verwilst: but I probably should hunt that patch from .96 and apply it in quantal, possibly precise as well.
[13:00] <verwilst> xnox, is there a .96?
[13:01] <verwilst> ah
[13:01] <verwilst> in the bug you mean
[13:01] <xnox> yeah.
[13:01] <verwilst> bugreport*
[13:01] <xnox> from upstream *gasp*
[13:01] <verwilst> that would be awesome idd, my coding foo surely isnt strong enough :)
[13:01] <verwilst> but for the rest, it's working very well
[13:02] <verwilst> now that the gfs2 thing is solved
[13:02] <verwilst> i lost many evenings on that problem :P
[13:02] <xnox> well, we are here to help ;-)
[13:02] <verwilst> xnox, 2.02.95-4ppa1 is my version
[13:03] <verwilst> 2.02.95-4 simply recompiled
[13:03] <verwilst> what did you 'fix' in the init script?
[13:04] <xnox> verwilst: init stayed the same. But for example the debian version is broke some symbols & the multiarch was done fully. Fixed those.
[13:04] <xnox> also applied the usual ubuntu patches.
[13:04] <xnox> I would recomend you to use $ backportpackage to rebuild quantal's lvm2 for precise into your ppa
[13:04] <verwilst> backportpackage?
[13:05] <verwilst> ubuntu-dev-tools.. xnox, am i missing out on some good stuff here? :)
[13:05] <verwilst> i always do apt-get source, dch -v ... debuild -S -sa; dput
[13:05] <verwilst> :)
[13:06] <xnox> verwilst: well it does that... automated... and it can also upload it into the ppa for you or build locally =)
[13:07] <xnox> verwilst: also it has the handy $ pull-lp-source and $ pull-debian source
[13:07] <xnox> verwilst: it takes these arguments: pkgname [exact-package-version | $distro-series]
[13:07] <xnox> by default grab latest ;-)
[13:08] <verwilst> where has that been all my life! :)
[13:19] <cking> bah, setting up chroots on various boxen takes forever
[13:53] <cking> hrm, seemed to have hacked around my blasted Virgin Media Super Hub TCP timeout issue. stupid device
[13:56] <apw> cking, vhub> what did you do?
[13:56] <cking> apw, http://smackerelofopinion.blogspot.co.uk/2012/08/virgin-media-super-hub-and-ssh-timeouts.html
[13:56] <apw> silly me
[13:57] <cking> apw, it is really a ghastly device
[13:57] <apw> cking, it sounds lame indeed, and this is the V2 device the first ones were utter balls i believe
[13:57] <cking> yep
[13:58] <cking> well, I've not had to reboot it like the previous kit I had, so that's a bonus I suppose
[13:58] <apw> heh swings and roundabouts perhaps
[13:59] <cking> apw, well, it is fast, so mustn't grumble really
[13:59] <apw> cking, its like 10x what i have i recon
[13:59] <ppisati> rsalveti: how was kernel testing?
[14:17] <verwilst> apw, you have another mail
[14:43]  * ogasawara back in 20
[14:55] <rsalveti> ppisati: working fine, built a bunch of packages, used glmark for a while, stable still
[14:55] <rsalveti> ppisati: seems we got a winner
[14:57] <brendand> bjf - some forewarning. this DC move has screwed up our server testing capacity, so the next SRU runs may be sans a bunch of servers
[14:58] <bjf> brendand: ack, thanks for the heads up.
[14:58] <ppisati> rsalveti: cool
[14:58] <ppisati> ogra_: ^
[15:00] <ogra_> :)
[15:00] <ppisati> correct me if i'm mistaken but:
[15:01] <ogra_> ppisati, convince ndec, he didnt belive yours is more stable ;)
[15:01] <ppisati> new kernel + pvr-omap4 = unity3d working, right?
[15:08] <ppisati> ogra_: tsk.../me neither, actually... :)
[16:18] <xnox> do we have any bleeding edge / recent kernels backported for lucid?
[16:31] <bjf> xnox, no
[16:31] <xnox> bjf: ok, thanks.
[16:32] <cking> sconklin, ping
[16:35] <sconklin> cking: yes? I'm replying to your email now . . .
[16:36] <cking> sconklin, ack
[16:59] <cking> sconklin, I'm still unsure what kind of "clamping" tool I'm expected to use on that splitter. it is quite chunky and I've only got weedy alligator clips
[17:00] <sconklin> sorry, perhaps that bit of kit hasn't arrived yet
[17:00] <sconklin> stand by for a link/photo
[17:01] <sconklin> oh, and stand by for a revision to my email - I made a mistake in the chart
[17:01] <sconklin> cking ^^
[17:01] <sconklin> http://www.amazon.com/Fluke-i400-AC-Current-Clamp/dp/B000EA1ETC/ref=sr_1_5?ie=UTF8&qid=1345654831&sr=8-5&keywords=fluke+clamp+current+probe
[17:02] <cking> sconklin, OK - did anyone order that for me?
[17:02] <sconklin> yes, you should receive one. I received my later than the splitter, so I suspect it's on the way
[17:02] <sconklin> s/my/mine/
[17:03] <cking> sconklin, ack, do we have a tracking number? I'm having a bad week for deliveries mysteriously not making to my door
[17:03] <sconklin> cking: ask pete, He handled that during the QA sprint in Lexington, and I wasn't there
[17:05]  * cking notes that clamp looks like it has some powerful grip, ideal for keeping the kids under control ;-)
[17:06] <sconklin> cking: it doesn't actually make contact with the wire under test - it measures the sum of the current passing through the clamp loop.
[17:06] <cking> sconklin, yep, I comprehend that. just looks like a mean grip to it
[17:06] <sconklin> cking: yep, watch yoru fingers
[17:08] <sconklin> cking: revised email sent
[17:08] <cking> sconklin, ta
[17:16]  * ppisati goes for some groceries
[17:23]  * rtg -> lunch
[18:08] <jdstrand> smb`: hey, on bug #1031090, am I supposed to be able to load the kvm_intel module in a precise guest on a *quantal* host?
[18:08] <ubot2`> Launchpad bug 1031090 in linux "kvm_intel not loadable in a quantal guest" [High,In progress] https://launchpad.net/bugs/1031090
[18:09] <rtg> jdstrand, smb is on his way to san diego
[18:09] <rtg> apw, ^^
[18:09] <jdstrand> smb`: I updated to 3.2.0-30.47-generic in the guest and am running 3.5.0-10.10-generic on the host
[18:09] <jdstrand> hmm
[18:10]  * apw looks
[18:10] <apw> jdstrand, that was being fixed indeed, i don't think i have seen final resolution on the right fix from upstream
[18:11] <jdstrand> apw: I see. so my quantal host doesn't have the necessary bits either?
[18:11] <apw> well your precise guest is playing host
[18:12] <apw> jdstrand, so i am not 100% sure if that would tickle the same issue or not
[18:12] <jdstrand> apw: this is where it gets confusing-- so, I am running an i7 quantal host (my laptop). I start a precise openstack vm. in the precise vm, loading kvm_intel fails
[18:13] <jdstrand> $ sudo modprobe kvm_intel
[18:13] <jdstrand> FATAL: Error inserting kvm_intel (/lib/modules/3.2.0-30-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported
[18:14] <apw> is there anything at the bottom of dmesg from that invocation ?
[18:14] <jdstrand> [  550.189256] kvm: no hardware support
[18:14] <jdstrand> the kvm module is loaded
[18:15] <apw> this fix was slated to fix he opposite combination so i am not sure if he would have tested the other way round
[18:16] <jdstrand> right
[18:16] <apw> so your test isn't going to test the verification requested there
[18:16] <apw> though being a valid combination we'd expect it to do something
[18:16] <jdstrand> it just happens to be that I upgraded in the meantime and am trying to test an openstack CVE on precise :)
[18:17] <jdstrand> apw: the bit I was concerned about was that the linux task was marked "Won't Fix", but this seems very related
[18:17] <jdstrand> apw: I'm happy to file another bug, or to comment in the existing one
[18:18] <apw> linux should be invalid as in theory invalid as that bug is specific to the other combination
[18:18] <apw> i think we should file a new one, as its as likely to be unrelated as not
[18:18] <apw> in cause if not symptoms, but do put the new bug number in the old bug
[18:19] <jdstrand> apw: interesting. If I do: sudo rmmod kvm_intel ; sudo modprobe kvm_intel nested=1 I get this in dmesg:
[18:19] <jdstrand> [  972.774373] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
[18:19] <apw> jdstrand, you were loading it without nested=1 ?  isn't that required ?
[18:20] <apw> for your use combination?
[18:21] <jdstrand> apw: I was trusting /etc/init/qemu-kvm.conf to dtrt since /etc/default/qemu-kvm has KVM_NESTED=" nested=1"
[18:21] <jdstrand> (the default)
[18:21] <jdstrand> I just wanted to be *sure* nested=1 was set
[18:21] <apw> jdstrand, hmmm ... so i guess can we test nested=1 and see if it makes things work for starters
[18:21] <apw> as yeah indeed what you said should be true, but perhaps is not
[18:22] <jdstrand> ha!
[18:22] <jdstrand> that was it
[18:22] <jdstrand> the upstart job isn't working right
[18:22] <jdstrand> apw: ok, thanks
[18:23] <apw> jdstrand, phew :)
[18:24] <jdstrand> indeed
[18:26] <apw> sconklin, bjf, fyi i hacked on the cve-autotriager to wack armadaxp appropriatly when released, which should clean out the cve matrix some
[18:29]  * henrix -> EOD
[18:29] <bjf> apw, very nice, thanks
[18:31]  * bjf -> lunch
[18:50]  * cking --> EOD
[18:56] <rtg> sforshee, can you subscribe me to bug #1040215
[18:59] <sforshee> rtg, done
[19:00] <rtg> sforshee, thanks


[03:43] -queuebot:#ubuntu-release- Unapproved: mate-screensaver (bionic-proposed/universe) [1.20.0-1 => 1.20.2-1~ubuntu18.04.1] (ubuntu-mate) (sync)
[03:49] <tsimonq2> infinity: That's my (kind of belated) copy-package with binaries: ^
[08:22] -queuebot:#ubuntu-release- New: accepted pushover [amd64] (disco-proposed) [0.0.5+git20180909-3]
[13:17] <bluesabre> Release team, what steps need to be taken to discontinue 32-bit ISOs for Xubuntu? I've prepared a mail to the release mailing list, but not sure if that's the way to go.
[13:19] <bluesabre> (related: https://lists.ubuntu.com/archives/xubuntu-devel/2018-December/011755.html)
[13:22] <infinity> bluesabre: The mail is enough, we'll twiddle the right bits.
[13:22] <bluesabre> infinity: great, thanks
[13:23] <bluesabre> And sent.
[13:24] <infinity> I think that leaves lubuntu as the only i386 image still produced (not counting base and netboot).
[13:24] <infinity> tsimonq2: ^
[13:25] <infinity> bluesabre: Note that "inability to upgrade" probably shouldn't have been a factor, but it certainly hints at future plans. :P
[13:26] <infinity> (we disabled automagic upgrades specifically because if we *do* drop i386 before 20.04, we'd rather leave users with a 5-year-supported 18.04 than stranded on a 9m release after)
[13:26] <bluesabre> Sure
[13:26] <infinity> But if we do 20.04 i386, we'll enable that upgrade.
[13:26] <bluesabre> It was one of several contributing factors :)
[13:26] <infinity> I hope we don't do it.
[13:52] <infinity> bluesabre: It's gone, and scrubbed from your daily-live dirs as well.
[13:53] <bluesabre> infinity: great, thanks for the help!
[13:54] <infinity> bluesabre: Thanks for making lubuntu the last oddball with an i386 image so they can stop using you as precedent. ;)
[13:54] <bluesabre> ha :D
[13:54] <bluesabre> sorry tsimonq2, we've made it a bit harder for you to say no
[13:55] <infinity> I mean, lubuntu can keep producing i386 images right up until we flat-out refuse to build i386 debs anymore, but I'm trying to recommend against it.
[13:56] <infinity> Since ISOs encourage installs and that sets future user expectations.
[13:56] <infinity> So better to wean them off.
[20:49] <mwhudson> they can pay for ISOs by debugging every time x87 goes weird
[21:53]  * acheronuk votes to kill i386 and armhf now....
[23:19] -queuebot:#ubuntu-release- New binary: pdftk [ppc64el] (disco-proposed/universe) [2.02-5] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: pdftk [s390x] (disco-proposed/universe) [2.02-5] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: pdftk [amd64] (disco-proposed/universe) [2.02-5] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: pdftk [i386] (disco-proposed/universe) [2.02-5] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: movim [amd64] (disco-proposed/universe) [0.14-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: pdftk [arm64] (disco-proposed/universe) [2.02-5] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: pdftk [armhf] (disco-proposed/universe) [2.02-5] (no packageset)


[05:29] <mborzecki> morning
[05:31] <mborzecki> mardy: that goes through fakestore in the tests?
[05:35] <mardy> mborzecki: hi! Yes! I'm using the make_snap_installable_with_id(), and that function creates a snap who belongs to "developer1"
[05:35] <mardy> and for some reason this causes the snap to be uninstallable
[05:37] <mardy> https://github.com/mardy/snapd/blob/feature/snap-microk8s-shared-system-usernames/tests/main/system-usernames-microk8s/task.yaml#L35-L39
[05:49] <mborzecki> mardy: this is in spread?
[05:50] <mborzecki> ah, well i see the task so it must be
[05:51] <mborzecki> hm and it's done after the account key of developer1 has been acked
[05:54] <mardy> I will try to move things around. But the installation itself is done later, in the "execute" step
[05:59] <mborzecki> mardy: can you run `snap known account` and `snap known account-key` to make sure that the developer assertions are there?
[06:16]  * mardy tries soon
[06:40] <mborzecki> mardy: can you take a look at https://github.com/snapcore/snapd/pull/10465 ?
[06:59] <mardy> mborzecki: looking. Meanwhile, here's the relevant part of the output for the "snap known" commands: https://paste.ubuntu.com/p/NdYn4bYFc5/
[07:01] <mardy> mborzecki: +1
[07:12] <pstolowski> morning
[07:13] <mborzecki> pstolowski: hey
[07:14] <mardy> pstolowski: hi!
[08:03] <pedronis> hello,  https://github.com/snapcore/snapd/pull/10458 needs reviews
[08:05] <pedronis> https://github.com/snapcore/snapd/pull/10448 also needs 2nd reviews
[08:59] <mvo> pedronis: just finished an interview, will have a look
[09:32] <zyga-mbp> good morning
[13:53] <mborzecki> pedronis: is there a way to generate assertions that can be correctly encoded using assertstest package?
[13:53] <mborzecki> ha, got it
[13:53] <mborzecki> hmm hmm, i'm getting `internal error: content cannot be empty` when trying to Encode() a model generated by boottest.MakeMockUC20Model
[13:53] <mborzecki> do i need the whole store stack for this?
[13:53] <mborzecki> mvo: can you land? https://github.com/snapcore/snapd/pull/10465 this should fix lp builds
[13:54] <pedronis> mborzecki: yes, if you need to Encode them, yes
[13:54] <pedronis> mborzecki: FakeAssertion is just meant for consumption that doesn't need serializing or being put in an actual assertion database
[13:57] <pedronis> mborzecki: mvo: that log is already in 2.51 afaict
[13:58] <pedronis> at last it's on the release branch
[13:58] <pedronis> so it needs a backport
[14:04] <mvo> pedronis: +1 - thanks so much for checking
[14:10] <mvo> pedronis: I cherry picked this now
[15:14] <mborzecki> pedronis: yeah, figured as much, the pr that's up does exactly that
[15:33] <mborzecki> meh, calling seedtest's MakeSeed() in managers tests isn't such a good idea, i get the impression thtat both the managers test set up and seedtest tries to add the same snap and revision declarations
[15:33] <mborzecki> and those bits are actually working against each other
[15:42] <pedronis> mborzecki: mmh,  you should be able to control what happens, it might be that SetUp does too much for your case, but I don't think it adds snaps to the system, but it might sign assertions for them
[20:43]  * cachio_ afk


[04:53] <RAOF> Well, that failure makes *absolutely no sense*
[04:54] <RAOF> ~thread() is dying in if (joinable) std::terminate().
[04:54] <RAOF> But ~thread() is being called after a destructor which has called thread.join();
[04:55] <duflu> RAOF: That means it's been deleted twice, usually. Valgrind should tell where
[04:56] <duflu> Whee, my merge proposals have now been up for review long enough to get conflicts from other things landing :S
[05:00] <RAOF> Huh. MirSocketRpcChannel apparently leaks fds.
[05:17] <RAOF> Oh, wtf? The leak appears in TestClientInput, but if I pass --gtest_filter=TestClientInput\* then it *doesn't* show up?
[05:32] <RAOF> For those playing at home, a stack depth of 24 is insufficient to catch this error :/
[05:35] <RAOF> Did my *monitor* just reboot?
[05:35] <RAOF> ?!
[07:30] <Mirv> RAOF: it needs to do that after it receives a newer version of the surveillance software
[07:31] <Mirv> they're working on updating the monitor's kernel while it's running, though
[07:31] <Mirv> so it should be completely transparent to you soon enough!
[10:04] <duflu> alan_g: You win :) https://bugs.launchpad.net/mir/+bug/1284554
[10:06] <alan_g> I though I'd won something nice. :(
[10:07] <duflu> Sorry.
[10:07] <alf_> duflu: alan_g: anpok_:
[10:07] <alf_> duflu: alan_g: anpok_:
[10:07]  * alf_ curses fingers
[10:08] <anpok_> yes?
[10:08] <alf_> duflu: alan_g: anpok_: @ https://bugs.launchpad.net/mir/+bug/1192908, are you ok with removing the dependency that libegl1-mesa-dev has on libmirclient-dev (see last comment)
[10:09] <duflu> alf_: I'm OK with removing any dependencies possible. Keep in mind though that bug is about source package dependencies (not binary), isn't it?
[10:10] <alf_> duflu: it resolves at least a part of the dependency problem, i.e., currently when mir builds it indirectly depends on the existing libmirclient-dev
[10:11] <duflu> alf_: I suspect the original fix is now gone too. Might be best to do the work in another bug given that one has a branch and Fix Released.
[10:27] <alan_g> alf_: I'm begging to feel that there's a low-level project & package missing.
[10:28] <anpok_> alf_: mesa only needs to load a library and plays with a struct with some callback functions.. that implement the egl platform?
[10:31] <alf_> alan_g: so to solve the greater build dependency cycle, we would either need to have multiple source packages for mir, or move our EGL definitions in Mesa, or have a third independet source package they both depend on
[10:33] <alan_g> alf_: yes. I'm not sure it is the right trade-off, but it is worth considering
[10:34] <alf_> anpok_: all the egl backends are built in Mesa's libegl
[10:35] <alf_> alan_g: anpok_: Anyway, I am not sure it's urgent, and there is the workaround mentioned by Daniel "You might be able to work around the problem by building Mir against vanilla Mesa (which does not depend on Mir)"
[10:36] <alan_g> I'd say it is a discussion for next cycle
[11:28] <alf_> alan_g: are you looking into https://bugs.launchpad.net/mir/+bug/1284161 ? If not, I can take a look.
[11:30] <alan_g> alf_: OK, I hadn't quite got back to that
[11:30] <alf_> alan_g: ok
[11:47] <alan_g> alf_: it is probably something different, but FYI https://bugs.launchpad.net/mir/+bug/1284597
[11:51] <alf_> alan_g: I can't reproduce the problem on laptop with i965. Both --launch-client and running the render_surfaces manually works for me :/
[11:53] <alan_g> alf_: Interesting
[11:58] <alan_g> I was running it on desktop. But that's also intel
[11:58]  * alan_g get laptop out
[12:02] <anpok_>  "" is a helpful shader compilation error message
[12:09] <alf_> anpok_: it's in invisible ink!
[12:11] <anpok_> i guess the color value of invisible ink is an implementation defined value in the ES spec
[12:24] <alan_g> alf_: works on my laptop too.
[12:24]  * alan_g wonders what the important difference is.
[12:25] <alf_> alan_g: my laptop is a bit behind on updates, let me see if updating makes a difference
[12:25] <alan_g> alf_: mine isn't
[12:26]  * alan_g wonders if it is as stupid as number of monitors
[12:27] <alf_> alan_g: certainly worth a try
[12:31] <alan_g> rats. Plugging in a monitor hung the laptop
[12:33] <alan_g> alf_: works with two monitors on the laptop
[12:51] <alan_g> alf_: does this (my desktop) suggest anything? https://pastebin.canonical.com/105514/
[12:53] <alf_> alan_g: nothing seems out of place
[12:54] <alan_g> I guess you can't do much more to investigate
[12:59] <alan_g> alf_: have you noticed that every MP is now failing: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/
[13:03] <alf_> alan_g: yes
[13:03] <alan_g> Do you know what happened?
[13:04]  * alan_g notices time
[13:26] <alf_> alan_g|lunch: seems that we have a new libc version 2.19 and it breaks things
[13:48] <alf_> alan_g|lunch: or rather valgrind needs to be updated to support 2.19 (and produce the correct default suppression files)
[13:49] <alf_> kgunn: ^^
[14:12] <alf_> alan_g: kgunn: https://bugs.launchpad.net/mir/+bug/1284653
[14:12] <kgunn> alf_: ack
[14:13] <kgunn> i guess that's our problem to solve ? ....no real tools team per se :-/
[14:13] <alf_> alan_g: kgunn: although valgrind being out of sync only explains the spurious memory errors, I am not sure about the test failures themselves
[14:14] <alan_g> alf_: thanks
[14:15] <kgunn> Saviq: hey...just wondering, so alf_ found new libc "changed something" that effects our valgrind runs...could that be a source of spurious issues on unity AP tests ?
[14:16] <Saviq> kgunn, if they can cause SIGSEGV on startup...
[14:16] <Saviq> kgunn, our issue seems to be android-size - i.e. I can't get any symbols out of it for the life of me
[14:18] <kgunn> hmm...libc, android...does smell a little fishy
[14:18] <kgunn> potentially
[14:19] <kgunn> i guess its only an issue for reference structures between libc/ubuntu side vs bionic/android side
[14:23] <kgunn> but then that would be a 100%
[14:24] <Saviq> kgunn, yeah, ours is some race
[14:24] <Saviq> crashing on startup maybe 5% of the time
[14:29] <Saviq> kgunn, but well, glibc shouldn't be causing that, IIUC, 'cause we'd had symbols for that ubuntu-side
[14:30] <kgunn> right
[14:30] <kgunn> sounds more like potentially android bin changes
[14:30] <kgunn> Saviq: cause all this is happening on 4.4.2 android right ?
[14:30] <Saviq> kgunn, yes
[14:37] <alan_g> alf_: (@1284597) why would glCreateShader() return 0 and then glGetError() return 0?
[14:42] <alf_> alan_g: perhaps there is no current GL context?
[14:42] <alf_> alan_g: (check with eglGetCurrentContext())
[14:48] <alan_g> alf_: it returns 0 => you guessed right
[14:48] <alan_g> thanks
[14:49] <alf_> alan_g: yw
[15:37] <alan_g> alf_, anpok : (@1284597) I'm trying to decide whether the problem is that mt::ImageRenderer::ImageRenderer() assumes there's a GL context or that there is no GL context in nested mode. Do you have an opinion?
[15:42] <anpok> The former I believe..
[15:44] <anpok> On android driver stacks we might be able to acchieve not needing a gl context on non-nested sessions too..
[15:45] <alf_> alan_g|tea: anpok: Assuming an active GL context is a leftover from when we didn't have the Display::create_gl_context(). Whoever needs access to the shared context can now get one.
[15:46] <anpok> get one where?
[15:46] <alf_> anpok: I mean by calling Display::create_gl_context()
[15:47] <anpok> oh.. too simple
[15:49] <alf_> alan_g: although, it's strange that in the nested case we don't have a context. NestedDisplay makes a context current when being constructed
[15:51] <alan_g> alf_: it does seem strange. But it seems to be the case
[15:52] <alan_g> I'm happy to add the call though - as it makes sense anyway
[15:59] <anpok> https://bugs.launchpad.net/mir/+bug/1268819
[16:00] <anpok> shall we MirMotionEvent contain both, screen coordinates and local surface coordinates?
[16:00] <anpok> or just the latter...
[16:12] <alan_g> anpok: most (all?) clients should only care about local co-ordinates
[16:17] <anpok> within MirMotionEvent there is for evey point float x, and float raw_x - is that meant to be local vs screen co-ordidnates?
[16:22] <alan_g> They *should* be local. Not sure why there are two of them - the distinction probably originates in the android input stack.
[16:23] <anpok> ah because of android
[16:23] <anpok> and for them raw means not transformed by the offset
[16:25] <anpok> but with orientation being a float value too now.. hmm. the code needs more changes.
[21:08] <mterry> Who knows a bunch about Mir + Qt keyboard focus?
[21:08] <mterry> er, key focus I guess.  Like volume up/down
[22:10] <kgunn> mterry: i bet dandrader might
[22:11] <kgunn> alternatively racarr_
[22:11] <dandrader> I recall I did something related to it a long time ago
[22:11] <mterry> :)
[22:12] <RAOF> :)
[22:12] <mterry> My problem is that when using a split greeter, only the user session receives volume presses.  The greeter session does not
[22:12] <mterry> I was curious how such input is routed between Mir sessions
[22:14] <dandrader> no idea
[22:15] <RAOF> mterry: Is the greeter session focussed?
[22:15] <RAOF> ‘split greeter’ implies use of unity-system-compositor, yes?
[22:16] <RAOF> u-s-c should be sending input only to whatever it thinks is focused, which should be either just the greeter or just the user session.
[22:17] <mterry> RAOF, hmm, it is on top because of depth...  Let me see how the version of USC I'm using handles focus
[22:18] <RAOF> Last time I checked (which was some time ago, with the desktop u-s-c) you needed to explicitly switch session focus. This might have changed, though.
[22:20] <mterry> RAOF, aha...  yes.  OK, so the_focus_controller() handles keyboard focus, that makes sense.  And the branch I'm using looks to have a bug around that when using two sessions.  Thanks!  I had forgot about the FocusController
[22:20] <RAOF> Hurray for memory!
[22:50] <mterry> RAOF, just to confirm, yeah, that was it.  Weird set_focus_to behavior in my branch.  Thanks man
[22:51] <RAOF> Bitchn'


[02:02] <marcoceppi> pmatulis: the difference is how juju models it, juju deploy ubuntu will create a machine with the ubuntu charm on it and the service ubuntu in your topology, juju add-machine will simply provoison a machine with no services deployed to it making it available for services to be deployed to it.
[02:13] <pmatulis> marcoceppi: yeah i'm starting to see it better now. thanks for the description
[03:50] <firl> if anyone could help with my vivid-kilo, maas set up that would be awesome. I am running into a ceph issue http://askubuntu.com/questions/668320/ceph-cannot-reformat-because-disk-is-mounted
[12:55] <coreycb> jamespage, looks like we need something like SWIFT_CODENAMES in charm-helpers for all the projects in liberty.  I can start on that if you haven't.
[13:05] <jamespage> coreycb, that should already be covered I think
[13:05] <jamespage> but maybe not
[13:08] <coreycb> jamespage, I think get_os_version_codename() and openstack_upgrade_available() need some updates
[13:54] <jamespage> beisner, are you ware of any trusty/kilo issues?  seeing a instance boot error on a mp I'm reviewing?
[13:57] <beisner> hi jamespage - t-k next mojo spec from yesterday fired up and connected to a new instance ok.  http://paste.ubuntu.com/12253397/   or   http://<IP_ADDRESS>:8080/view/Dashboards/view/Mojo/job/mojo_runner/745/console
[13:58] <jamespage> beisner, this is the MP - https://code.launchpad.net/~bbaqar/charms/trusty/nova-cloud-controller/next/+merge/269897
[14:01] <beisner> jamespage, digging into the logs collected on that run, nova-compute log shows MessagingTimeout and nova conductor woes.  http://paste.ubuntu.com/12253431/
[14:05] <beisner> jamespage, fyi Aug23:  n-c-c/next most recent time-triggered, successfully completed run.  (the Aug30 runs were sabotaged by undercloud storms.)
[14:05] <beisner> jamespage, Aug23 for reference:  http://<IP_ADDRESS>:8080/view/Dashboards/view/Amulet/job/charm_amulet_test/5981/
[14:05] <beisner> jamespage, i've re-triggered a new n-c-c/next amulet run now.
[14:11] <lazyPower> beisner: did any of those MP's come in lastnight?
[14:11] <lazyPower> beisner: i didn't get notice... or i did and they were filtered so i had no idea i had stuff to do
[14:12] <jamespage> gnuoy, hey - could you give https://code.launchpad.net/~james-page/charm-helpers/plumgrid/+merge/269920 a quick +1 (its for the plumgrid SDN stuff - managed to miss they have not proposed to ch's)
[14:13] <gnuoy> jamespage, sur
[14:13] <gnuoy> * sure
[14:13] <jamespage> ta
[14:25] <beisner> hi lazyPower - apologies if i kept ya hanging - that train is delayed, but could be arriving soon.
[14:33] <firl> any openstack charmers on?
[14:34] <lazyPower> beisner: no stress. Just wanted to circle back and make sure I didn't leave you hangin lastnight :)
[14:34] <marcoceppi> firl: do you have a question?
[14:34] <firl> marcoceppi: Yeah, someone helped me get a config ready for vivid-kilo, and I am running into an issue with ceph, and wanted to know if it was me doing something wrong or something else
[14:35] <firl> http://askubuntu.com/questions/668320/ceph-cannot-reformat-because-disk-is-mounted
[14:35] <marcoceppi> beisner jamespage gnuoy coreycb ^ ?
[14:36] <marcoceppi> firl: thanks for opening an Ask Ubuntu question on it
[14:36] <firl> np, yeah it was early morning, and didn’t know if it should be a bug or a question
[14:36] <jamespage> firl, hmm
[14:37] <marcoceppi> firl: question is always a good start, it allows a medium to track history and gives people who arent' always online the ability to readback from there it might be a bug or just a fix to your environment
[14:37] <firl> marcoceppi: good to know, thanks
[14:38] <jamespage> firl, is this a re-deployment?
[14:38] <firl> nope
[14:38] <jamespage> i.e. have you managed to deploy once, and you're now re-deploying on the same hardware?
[14:39] <firl> I am redeploying on same hard ware
[14:39] <firl> but I am using mass to juju destroy-environment
[14:39] <firl> I thought that the osd-reformat would take care of the designation on the newly deployed os ( on the same old hardware )
[14:40] <jamespage> firl: its possible that something systemd-ish is causing a race on the redeployed system
[14:40] <jamespage> i.e. a udev rule fires and mounts the volume at about the same time this process is running
[14:40] <firl> of where it is mounting the drive before ceph allocates it?
[14:40] <jamespage> maybe - tricky to etll
[14:40] <firl> gotcha
[14:41] <jamespage> firl, ceph used udev rules to mount and start osd on reboot - its possible this is the cause
[14:41] <jamespage> although I've not seen this one before
[14:41] <firl> yeah
[14:41] <firl> I have reproduced it 3 times
[14:41] <jamespage> urgh
[14:41] <firl> :)
[14:41] <firl> I try to test before asking haha
[14:41] <jamespage> firl, did you mean to deploy on vivid btw?
[14:41] <jamespage> or was kilo the main requirement?
[14:41] <firl> Kilo is the main
[14:41] <firl> vivid-kilo was for LXD possibility
[14:42] <jamespage> firl, ah!
[14:42] <jamespage> I see
[14:42] <firl> I can do trusty-kilo and see if it reproduces it
[14:42] <jamespage> makes sense
[14:42] <firl> :)
[14:42] <firl> Makes me feel a little less crazy then haha
[14:42] <jamespage> firl, I would probably bet its fine on trusty/kilo - that gets alot of redeployment exercise on hardware in test labs and at customer deployments
[14:43] <jamespage> vivid - less so - so this type of thing can bite.
[14:43] <firl> gotcha
[14:43] <firl> so trusty/kilo is more along the lines of trusted / stable ?
[14:43] <jamespage> firl: absolutely - but we don't provide LXD back to trusty ...
[14:44] <jamespage> so I can see why vivid was making sense for you
[14:44] <firl> yeah, yeah the LXD was just for fun testing
[14:44] <firl> not an immediate need so to speak
[14:44] <jamespage> firl, that said its probably worth highlighting that block device support is not yet implemented in LXD/nc-lxd
[14:44] <jamespage> so cinder/ceph + LXD == ERRNOTSUPPORTED right not
[14:44] <firl> ah that is good to know
[14:44] <firl> yeah I use cinder/ceph so that makes sense
[14:45] <firl> ok off to trusty-kilo
[14:45] <jamespage> that is being worked on - but there are a number fo security concerns with work through in the kernel todo with fs integrity
[14:46] <firl> very true
[14:47] <firl> Do you know of any other customer type example config.yaml for the OS world to compare my set up against by any chance?
[14:49] <jamespage> firl, it looks like you pulled yours from openstack-charm-testing right?
[14:49] <firl> ya
[14:50] <jamespage> firl, it you wanted something a little more concise to work from - https://jujucharms.com/openstack-base/
[14:50] <jamespage> that uses charm-store rather than branches and could easily be adapted
[14:50] <firl> thanks man, I appreciate it
[14:52] <jamespage> firl, that also uses the new bundle format which expresses everything about the environment including the physical machines
[14:52] <jamespage> gnuoy, sorry to nag on that review - pretty please :-)
[14:54] <gnuoy> jamespage, sorry, it's just possible I got distracted by something shiny
[14:54] <jamespage> ha
[14:55] <lazyPower> shiny? where?!
[14:57] <jamespage> ddellav, hey - I see you glance upgrade action stuff got landed - nice work
[14:57] <jamespage> gnuoy, ta
[15:00] <firl> jamespage, the format that I am using? or the openstack-base does?
[15:01] <jamespage> firl, the openstack-base bundle uses the new format
[15:01] <firl> gotcha, yeah I will convert over to the new format and try to specify it
[15:01] <firl> thanks again
[15:04] <jamespage> firl, its worth noting that by using the charm-store for the charms, you can fix charm revisions for repeatable deployments
[15:04] <jamespage> firl, worth doing to avoid an unexpected re-deployment change
[15:04] <jamespage> say a new feature or suchlike
[15:07] <jamespage> lazyPower, plumgrid changes for openstack charms all landed now
[15:07] <jamespage> lazyPower, well into next at least
[15:07] <lazyPower> https://media.giphy.com/media/OJdyjK11k2fLi/giphy.gif
[15:08] <lazyPower> awesome, I'll clean up the technical debt i left behind before EOW and cc you when i get the bundle corrected.
[15:08] <lazyPower> thanks for the update jamespage
[15:10] <jamespage> lazyPower, thanks for the final reviews whilst i was away - appreciated!
[15:11] <lazyPower> jamespage: np, happy to see them land their charms. :)
[15:12] <jamespage> indeed
[16:10] <marcoceppi> rbasak: I've got a debian packaing question, you got a min?
[16:25] <ddellav> jamespage, thanks :) I've also landed the cinder changes as well. Working on ceilometer now.
[16:26] <ddellav> jamespage, https://code.launchpad.net/~ddellav/charms/trusty/cinder/upgrade-action/+merge/269247
[16:26] <ddellav> feel free to take a look and comment.
[16:26] <jamespage> ddellav, good-oh!
[16:33] <rbasak> marcoceppi: sure. Also you just reminded me that I should have something on my todo for you I think. Do you remember what it is?
[16:33] <marcoceppi> rbasak: I think I just found out what I did wrong, let me get back to you in a few mins
[16:34] <marcoceppi> rbasak: so I cleaned up the charm-tools packaging. We left the discussion at "I need to do a 1.6.0 release so we can propose for archive)
[16:34] <marcoceppi> "
[16:34] <rbasak> marcoceppi: ah OK. So no action for me right now?
[16:34] <marcoceppi> however, 1.6.0 added a bunch of deps not packaged that I just wrapped up packaging
[16:34] <marcoceppi> rbasak: so I think after i finish testing/uploading to the PPA we should take another spin through the package to make sure everything is in place
[16:35] <marcoceppi> I'll ping you tomorrow to chat more about
[16:35] <rbasak> marcoceppi: OK. Let me know when you're ready.
[16:35] <rbasak> ack, thanks
[16:52] <marcoceppi> rbasak: okay, i actually do still have a packaging question
[16:52] <rbasak> marcoceppi: shoot :)
[16:52]  * rbasak EODs soon
[16:53] <marcoceppi> rbasak: so there was a  source package, jujubundlelib and it installed jujubundlelib package. I wanted to create a python-jujubundlelib and python3-jujubundlelib package while making sure to maintain backwards compatibility with jujubundlelib package because others packages still depend on it
[16:53] <marcoceppi> rbasak: so I created the following control file
[16:54] <marcoceppi> https://github.com/juju/juju-bundlelib-packaging/blob/master/control
[16:54] <marcoceppi> jujubundlelib depends on the python-jujubundlelib which replaces it, python-jujubundlelib breaks jujubundlelib 0.1.9-1 (this is now 0.1.9-2) and replaces jujubundlelib
[16:55] <marcoceppi> however, if I isntall 0.1.9-1 and perform an upgrade I get this error
[16:55] <marcoceppi> rbasak: http://paste.ubuntu.com/12254887/
[16:55] <marcoceppi> I have to run sudo apt-get install -f after the upgrade to have the package install properly
[16:56] <marcoceppi> so I figured it was because I was dong << I patched to do <= but the same error occurs
[16:56] <rbasak> 0.1.9-1 > 0.1.9-1~
[16:57] <marcoceppi> right so the control file is now
[16:57] <marcoceppi> jujubundlelib (<= 0.1.9-1)
[16:57] <marcoceppi> oh, so should i have done jujubundlelib (<< 0.1.9-2~) >
[16:57] <marcoceppi> ?*
[16:57] <rbasak> Yeah, jujubundlelib (<< 0.1.9-2~) is right
[16:58] <marcoceppi> damnit, okay let me patch taht and try again
[16:58] <marcoceppi> the ~ was throwing me off, I tried googling it but that's pretty ahrd
[16:58] <rbasak> It's fixed in 0.1.9-2, so anything older than that is what it replaces. Suffixing ~ allows for backports and PPAs
[16:59] <marcoceppi> cool
[17:00] <marcoceppi> rbasak: thanks, I'll give this a go
[17:00] <rbasak> Since if someone backports or PPAs 0.1.9-2 then it'll be in 0.1.9-2~, and that should also be treated as one where the transition has occurred.
[17:00] <rbasak> No problem.
[17:00]  * marcoceppi adds a little more packaging knowledge to the tree
[18:59] <skylerberg> How do I make a failed hook as resolved? I am looking for an equivalent to `juju resolved` for a failed hook instead of a failed charm.
[19:38] <lazyPower> skylerberg: juju resolved unit/# resolves just that hook
[19:38] <lazyPower> if a follow up hook fails, the charm re-enters a failed state
[19:40] <skylerberg> lazyPower: Thanks. I got it working a bit ago, but I had tried several things, so I still wasn't sure what actually fixed it.
[19:47] <skylerberg> wolsen: I resubmitted my patch for nova-compute with the changes we discussed: https://code.launchpad.net/~sberg-l/charms/trusty/nova-compute/tintri-interface/+merge/269972.
[19:49] <wolsen> skylerberg, ack - thanks - I'll take a look at it a bit later
[20:43] <beisner> wolsen, ping-o
[20:51] <wolsen> beisner, pong-o
[20:52] <beisner> yo!
[20:54] <wolsen> hey
[20:54] <beisner> wolsen, just touching base re: email (1c-h + 4 charm) review
[20:56] <beisner> wolsen, ah i think we left off with https://code.launchpad.net/~1chb1n/charm-helpers/amulet-svc-restart-race/+merge/269098  <-- rev pushed following review
[20:57] <wolsen> beisner, yep I hadn't gotten back to your updated push on it
[20:57]  * wolsen looks now
[20:59] <beisner> wolsen, np.  we had to let the tests run for the charms that i sync'd it into to confirm.
[20:59] <beisner> ie. those in your email consume these c-h changes
[20:59] <wolsen> beisner, yep
[21:00] <beisner> wolsen, thx man
[21:04] <wolsen> beisner, approved - added yet another comment, but its more of a follow up todo action
[21:09] <beisner> wolsen, replied fyi.  another great question.
[21:11] <wolsen> beisner, oh hah - my comment was misstated - heh, its ambiguous if len(pid_list) > 1 not 0
[21:11] <wolsen> beisner, but let me look at that method
[21:11] <beisner> wolsen, yes indeed, we are ignoring cases where there are multiple pids (as did the ancestor).   which is a good to-do to further examine.
[21:12] <wolsen> beisner, right - that was the crux of my comment - my mistake on the typo there - we both agree though ;)
[21:12] <wolsen> beisner k, I don't have rights to merge that - but its got my blessing fwiw
[21:13] <beisner> wolsen, ack & thank you sir
[21:13] <wolsen> beisner, thank you!
[21:14]  * wolsen turns towards ackk's proposal then to skylerberg's
[21:16] <firl> anyone able to help me diagnose my bundle parse errors ?
[21:27] <firl> nevermind, I needed to use “juju quickstart” instead of “juju-deployer"
[21:27] <marcoceppi> firl: huh, quickstart and deployer should both work, what were teh errors?
[21:28] <firl> http://pastebin.com/vds8YYDh
[21:28] <firl> http://pastebin.com/w9UckkRi
[21:28] <firl> nevermind the quickstart just failed more gracefully
[21:28] <firl> haha
[21:28] <marcoceppi> firl: heh :D
[21:28] <marcoceppi> what version of deployer do you have installed?
[21:30] <marcoceppi> it seems to be an issue with parsing constraints
[21:30] <firl> yeah, worked on my old bundle file
[21:30] <marcoceppi> what changed in this bundle file?
[21:31] <firl> switching from v3 to v4? I think? I mimic’ed the openstack-base charm
[21:31] <firl> and then added in my constraints
[21:31] <marcoceppi> insteresting
[21:31] <marcoceppi> let me check something
[21:31] <firl> and the quick start might have worked? still waiting for the gui to come up
[21:32] <marcoceppi> firl: it's possible
[21:32] <marcoceppi> it seems that "cannon unmarshal string into Go value type []string" means that the API is expecting a list of strings and not just a string
[21:32] <marcoceppi> firl: lets wait for quick start to succeed or fail
[21:32] <marcoceppi> and go from there, I have some ideas
[21:33] <firl> cool
[21:33] <firl> https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml
[21:33] <firl> that constraints only has 1 as well
[21:34] <marcoceppi> firl: yeah, I've not used the v4 bundle format as much as I should
[21:34] <firl> or maybe it’s thinking tags=[“tag1”,”tag2”]
[21:34] <marcoceppi> I don't think so, but it's possible
[21:34] <marcoceppi> rick_h_: ^
[21:40] <firl> juju gui timing out to install, I will blow away and re bootstrap with dragging the yaml file to the gui. I don’t think the gui has a place for maas tags though
[21:40] <marcoceppi> firl: it may not expose it explicitly, but it should respect it
[21:41] <firl> cool
[21:43] <marcoceppi> firl: for what it's worth juju will soon be gaining the ability to just do `juju deploy <bundle>` so it'll be a lot more cohesive and we can finally drop things like deployer and quickstart for bundles
[21:43] <marcoceppi> that's why we're transitioning to the v4 bundle format
[21:43] <firl> sweet; yeah I’ve really enjoyed everything I have encountered when it comes to juju
[21:44] <firl> bringing a co worker with me to the summit too
[21:46] <marcoceppi> firl: \o/ aweseome, see you there
[21:46] <ntpttr> Hi, I'm having some trouble deploying juju-gui to my bootstrapped environment. I run "juju deploy --to 0 --repository=/srv/charmstore local:trusty/juju-gui" and then "juju expose juju-gui", and for a while the service-status is maintenance and the agent-status is running the install hook and the start hook, and then eventually the service-status changes to 'unknown' and the agent-status changes to 'idle', and even though the agent-state is started, going to the
[21:47] <marcoceppi> ntpttr: hey, so since 1.24 juju introduced a new extended status. a service status of unknown and agent-state of idle is for charms not yet using extended status. So that means the juju-gui should be deployed
[21:47] <marcoceppi> ntpttr: are you having issues loading it in your browser?
[21:47] <ntpttr> marcoceppi: Yeah, the browser is showing a spinning wheel under "Connecting to the Juju environment"
[21:48] <marcoceppi> ntpttr: hum, what provider are you using? local, maas, openstack?
[21:48] <ntpttr> marcoceppi: maas
[21:48] <ntpttr> marcoceppi: I have a corporate proxy I'm working behind, but I did configure that in environments.yaml
[21:49] <marcoceppi> ntpttr: ah, that might be the issue
[21:49] <marcoceppi> ntpttr: so the juju-gui uses websockets to communicate with the juju environment
[21:49] <marcoceppi> ntpttr: what browser are you using?
[21:49] <ntpttr> marcoceppi: Firefox
[21:50] <marcoceppi> ntpttr: if you open the developers tool console in firefox and hard refresh the juju-gui I imagine you'll probably see a connection error pop up
[21:51] <ntpttr> marcoceppi: Yeah it's saying can't establish a connection to the server at wss://node0vm0.maas/ws. It was working yesterday for me, but then I updated my juju by adding the stable ppa
[21:51] <marcoceppi> ntpttr: so what version were you on before? 1.22?
[21:51] <ntpttr> marcoceppi: It's also saying the connection was interrupted while the page was loading
[21:52] <ntpttr> marcoceppi: I'm honestly not sure, whichever one comes with the orange box build
[21:52] <marcoceppi> ntpttr: are you doing this on an orangebox right now?
[21:52] <ntpttr> marcoceppi: yes
[21:53] <marcoceppi> ntpttr: what does `env | grep "proxy"` produce on the machine you're trying to access the GUI from
[21:54] <ntpttr> marcoceppi: It produces all of my proxy urls for http_proxy https_proxy ftp_proxy and no_proxy. Yesterday I was having a connection issue as well and I fixed it by adding ".maas,<IP_ADDRESS>" to no_proxy
[21:54] <ntpttr> marcoceppi: Is there an easy way to downgrade juju to what I had before?
[21:54] <marcoceppi> yeah, you're going to have to do that again
[21:54] <marcoceppi> ntpttr: you could remove the stable ppa
[21:55] <firl> marcoceppi: drag to juju-gui seems to work  so far.
[21:55] <ntpttr> marcoceppi: and after I do that if I update it will downgrade?
[21:56] <marcoceppi> ntpttr: you'll have to either apt-get remove juju-core and re-install or do `apt-get install juju-core=1.XX*` whatever the version is
[21:56] <marcoceppi> ntpttr: I suggest the former
[21:56] <marcoceppi> firl: nice! glad to hear the drag and drop is working so far


[00:08] <Unit193> kanashiro: (Re: https://lists.ubuntu.com/archives/devel-permissions/2020-April/001480.html) Good luck!
[01:44] <Eickmeyer> juliank: I know you've been working on grub, so I thought I'd bring this to your attention: bug 1871968
[08:35] <juliank> Eickmeyer: apologies, this should be fixed (thanks xnox and vorlon)
[08:57] <crockedgrind59> hello, I am working on a project to do an iso image to install ubuntu 20.04 on several computers (laptops mostly) and I would like to use Kicsktart on the new 20.04 lts but, I am using a script that I've found on gitub. It works like a charm for the ubuntu server 18.04 distro, but I cannot make it works for 20.04 Desktop, and I think that the problem is related to ubiquity, that ignores the boot txt.cfg I modify
[08:58] <crockedgrind59> I have been helped on ubuntu-installer channel, but the solution a gentle guy gave me is to generate a usb to install the system, but I would need an iso to be able to install also a VM image
[08:59] <crockedgrind59> does anyone here have a clue about how I could make it works  an automatically installation (with some questions, so, interactive) on a Desktop version of Ubuntu, please?
[08:59] <crockedgrind59> any help would be more than appreciated!
[09:04] <crockedgrind59> (or any clue!)
[10:11] <seb128> lathiat, hey, did you have a chance to test avahi?
[12:14] <blahdeblah> Hi all - is this a good place to talk about focal installer crashes, or is #ubuntu-server a better choice?
[12:14] <blahdeblah> (or somewhere else entirely, if that's better)
[12:16] <seb128> blahdeblah, you can try here or on #ubuntu-installer
[12:17] <seb128> today might also not be the best day for questions, quite some people are off for Easter weekend
[12:17] <blahdeblah> seb128: of course
[12:17] <blahdeblah> I'll ask anyway, and try again Mon/Tue if no luck
[12:18] <blahdeblah> My main question is: if I've told the installer to submit a crash report, how can a) check that it was submitted, and b) know if anything else needs doing to get the bug which caused the crash fixed
[12:18] <blahdeblah> ?
[12:19] <blahdeblah> I ended up having to go back to xenial to get a correct install with what I thought was a fairly vanilla disk layout: LVM on encrypted software RAID 1, then upgrade to bionic, then focal
[12:37] <seb128> blahdeblah, was it a desktop or serverl install?
[12:37] <blahdeblah> seb128: server
[12:37] <seb128> blahdeblah, the automatic reports you sent can be seen on https://errors.ubuntu.com/user/ID where ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine.
[12:37] <blahdeblah> hmmm - that's long gone, because the installation failed
[12:37] <seb128> or if you open a bug on launchpad you should know it/have seen the webbrowser page
[12:37] <blahdeblah> so I reinstalled
[12:38] <seb128> blahdeblah, well, the ID depends of the machine so it might be the same still with a new install
[12:38] <blahdeblah> I'll have a look
[12:38] <blahdeblah> Nope, no such directory
[12:39] <seb128> :/
[12:40] <seb128> I don't know then, best to wait for someone from server to be around or maybe ask mwhudson if that's a subiquity install you tried
[12:40] <seb128> (though he's probably eow at this time)
[12:43] <blahdeblah> No worries - thanks seb128
[12:43] <seb128> np!
[15:44] <jibel> vorlon, there is an issue with last upload of grub cf bug 1872077
[15:45] <jibel> actually juliank ^
[15:47] <juliank> jibel: fascinating
[15:50] <juliank> jibel: bug 1872100 is interesting too
[15:50] <juliank> Hmm wrong no
[15:50] <juliank> bug 1872100
[15:51] <juliank> Hurry up ubottu
[15:52] <juliank> This is all confusing
[15:52] <juliank> Who marked that as a duplicate? I unmarked it
[21:27] <Eickmeyer> juliank, seb128: Do either of you have any insight on this? Bug 1871295 came up in #ubuntu-quality


[12:49] <yano> This is a friendly reminder for folks in the US: Please *REGISTER* to **VOTE**, and if you are registered, please *CHECK YOUR REGISTRATION* is active and up-to-date. (this is very important due to voter roll purges in many states) You can do it all at, https://www.vote411.org/ or https://vote.gov/


[02:34] <djb1024> @lart djb1024
[10:23] <BluesKaj> Hey all
[10:29] <lordievader> Good afternoon
[13:28] <BluesKaj> no 15.10 anouncement yet ? for repos or ....?
[13:30] <krabador> BluesKaj, not, and for the codename too
[13:33] <BluesKaj> krabador, seems slow, I recall new repos for the next release were open with a couple of days of the previous official release
[13:33] <BluesKaj> within


[01:48] <guest-hrtikm> Hi my name is Mauricio, I just forgat my password...
[01:49] <guest-hrtikm> could I get some help please!
[02:17] <guest-hrtikm> Would someone please  give me a hand, I am new working with it, and I just forgot my admin password?
[07:34] <Guest91636> giorno
[12:53] <john__> Sup braaa
[13:30] <dooley_da_Vulcan> Hello, I am using Ubuntu-Mate 17.04 and I cannot seem to be able to install Samba. I get a listing under System then Administration for Samba. I choose it and it asks for my pw I put it in and nothing.
[13:30] <dooley_da_Vulcan> think its just a bug of the new version?
[13:30] <dooley_da_Vulcan> I have tried different ways of installing it too.
[13:34] <DarkPsydeLord> samba is installed by default in ubuntu mate
[15:03] <dooley_da_Vulcan> #category5
[19:49] <baraa> braa4ever
[20:14] <emil__> hola
[21:00] <razvan> hola?
[21:01] <razvan> hello
[21:06] <DarkPsydeLord> hola
[21:07] <razvan> una pregunt
[21:07] <razvan> pregunta*
[21:08] <razvan> ¿como podría instalar sopcast?
[21:09] <DarkPsydeLord> en linux? ni idea pero hay muchos otros programas que funcionan similar
[21:10] <razvan> estoy usando ubuntu mate en una Raspberry pi 3
[21:10] <razvan> ah, pues si hay programas similares a sopcast, acestream pero para linux
[21:11] <razvan> pues mejor


[00:00] <SonikkuAmerica> ecips: I'm out of ideas... you said you Googled this, right?
[00:00] <ecips> Yeah
[00:01] <ecips> I'm a 15 year linux user, co-founder of Linux Australia - I'm fairly capable with Linux. This one has me a bit stumped however :)
[00:01] <ecips> I cant see anything in straces I'm taking either
[00:04] <SonikkuAmerica> ecips: I've noticed it's a silent fail. I'm just a college student with ~3-4 years of strictly Ubuntu, and I've never seen this happen in a stable release, but in unstable stuff (such as 13.04 now) this is bound to happen.
[00:04] <ecips> Yeah - life on the bleeding edge :)
[00:05] <ecips> Doesnt seem to be kernel related
[00:06] <SonikkuAmerica> Hmm... is this Kubuntu by any chance?
[00:10] <ecips> No
[00:10] <ecips> xubuntu
[00:10] <ecips> I hate Unity :)
[00:12] <SonikkuAmerica> OK. This pulseaudio-is-broken frequently happens in Kubuntu though, that's why I asked.
[00:19] <ecips> Seems switching to alsa in mplayer makes it work again
[00:20] <ecips> Yeah - definitely Pulse that is broken
[00:20] <ecips> I wonder if there are any packages in incoming.....
[00:22] <SonikkuAmerica> ecips: Just use ALSA until Pulse gets fixed.
[00:22] <ecips> Yeah
[00:22] <ecips> Pulse is not well loved by a lot of people :)
[00:23] <ecips> Thanks for your input anyway :)
[00:23] <SonikkuAmerica> You're welcome
[00:23] <ecips> Maybe you can help me be lazy and help me figure out another annoying thing..... :)
[00:24] <ecips> I'm using the nvidia proprietary driver, and it's not saving my damn display settings.
[00:24] <ecips> reverts back to a single screen after I reboot
[00:25] <SonikkuAmerica> [ sudo apt-get install nvidia-settings ] if you don't have it.
[00:26] <ecips> Yeah - got that
[00:26] <ecips> The settings app works fine
[00:27] <ecips> but the settings arent saved
[00:29] <SonikkuAmerica> ecips: Are you using the nVidia X driver?
[00:29] <SonikkuAmerica> ecips: A message would appear at nvidia-settings startup if you aren't
[00:29] <ecips> yes - as I said - the proprietary one
[00:30] <SonikkuAmerica> ecips: Then set up the display stuff the way you want it, open up nvidia-settings and click "Save to X Configuration File"
[00:31] <ecips> yeah yeah - done all that :)
[00:31] <ecips> it doesnt stick
[00:32] <SonikkuAmerica> Maybe it just doesn't like your xorg.conf
[00:33] <SonikkuAmerica> But then again, this is an alpha. Don't count on stuff working. You might try creating a BASH script though.
[00:37] <ecips> :)
[00:40] <ecips> xorg.conf is on the way out :)
[00:40] <ecips> /usr/share/X11/xorg.conf.d/
[00:40] <ecips> is where it is at these days :)
[00:41] <SonikkuAmerica> NO! THEY SPLIT XORG.CONF!
[00:44] <ecips> :)
[00:44] <ecips> Looks like disper might be the tool I need
[00:59] <bjsnider> pulse is well loved by a lot of people actually
[00:59] <bjsnider> we're out of the growing pains phase now
[00:59] <bjsnider> the diapers are off
[01:04] <ecips> bjsnider, It's just broken right now :)
[01:11] <bjsnider> if this is in a vb guest image, it's not the only thing that's broken
[01:18] <bjsnider> LP: #1124660
[01:19] <ecips> nah, pulse is broken somehow
[02:05] <ahsdak> hi
[02:05] <ahsdak> anybody here?
[02:05] <ahsdak> I've just upgraded to 13.04 and the sound does not work
[02:39] <ecips> pulseaudio is probably broken
[02:39] <ecips> try installing pavucontrol
[02:39] <ecips> see if that fixes it
[02:40] <ecips> otherwise, just change your apps to use ALSA and wait patiently until it is fixed
[02:40] <ecips> ugh
[02:40] <ecips> he's gone
[02:53] <IdleOne> ecips: he waited longer then most
[02:53] <IdleOne> :)
[03:18] <avis-> is it possible for me to install 12.10 ubuntu on a 2012 mid or late mac mini ?
[03:18] <avis-> i'm not banned from #ubuntu but am not able to talk
[03:39] <bjsnider> avis-, unlikely anybody in here knows
[03:39] <bjsnider> try the live cd
[03:42] <IdleOne> avis-: I removed the ban that was likely preventing you from speaking in #ubuntu. Please use the appropriate channel for support and remember to follow the !guidelines.
[03:43] <IdleOne> if you're still unable to send to channel join #ubuntu-ops and we can see what needs to be fixed.
[10:55] <vivid> seems some issues have arisen from the recent pulseaudio update
[11:13] <ironhalik> vivid: the sound stops working? :>
[11:13] <vivid> not entirely, but its problematic
[11:13] <vivid> rhythmbox, for example, is really picky on whether it wants to play my music
[12:04] <oldude67> where can i download the new release?
[12:04] <smartboyhw> oldude67, cdimage.ubuntu.com
[12:04] <oldude67> smartboyhw, ty
[12:29] <oldude67> what are some of the main issues with 13.04
[12:45] <ecips> vivid: I agree, pulseaudio is broken badly.
[13:37] <BluesKaj> Hey all
[13:40] <ecips> Good evening :)
[13:49] <ecips> pulseaudio now appears to be fixed :)
[13:50] <BluesKaj> ecips,yeah a pulse upgrade is in the repos
[13:50] <ecips> installed and working :)
[13:51] <BluesKaj> actually I didn't have a problem with it
[13:51] <ecips> now they just need to fix pidgin and I will be a happy man again :)
[13:51] <BluesKaj> not that I like having to use it
[13:52] <ecips> What else gives multiple simultaneous access to the sound devices however?
[13:52] <BluesKaj> if html5 were implemented on websites then I wouldn't need pulse
[13:53] <ecips> Need pulse to watch pr0n!! :p
[13:53] <ecips> esound?
[13:53] <BluesKaj> not here
[13:53] <BluesKaj> alsa does the job
[13:54] <ecips> alsa doesnt allow multiple apps to play sound at the same time
[13:55] <BluesKaj> i don't use multiple apps to play sound ..one app at a time
[13:56] <ecips> I've got VM's and such running which would not get sound otherwise.
[14:03] <tux__> recent pulseaudio update just borked my sound
[14:03] <tux__> any ideas folks?
[14:04] <ecips> update again
[14:04] <ecips> there is a fixed one
[14:04] <ecips> 2 hours ago
[14:04] <tux__> er.. i just updated right now
[14:04] <BluesKaj> my understanding is that alsa was designed to do all that but a particular developer had the ear of the canonical managers and got his pet app that he helped build into ubuntu on 9.04 and that was beginning of the of further alsa development for multiple apps ...it was mostly political
[14:05] <ecips> 1:3.0-0ubuntu2
[14:05] <ecips> Is that the version you have?
[14:05] <BluesKaj> begining of rhe end
[14:05] <ecips> BluesKaj, I dont believe that to be the case.
[14:05] <tux__> ecips, which package version are you referring to
[14:06] <ecips> The pulseaudio developer actually canned the shit out of the way Ubuntu implemented pulse.
[14:06] <ecips> tux__, pulseaudio
[14:06] <ecips> dpkg -l pulseaudio
[14:06] <tux__> ecips, i recall that, he said when they first used it
[14:07] <tux__> he commented that they didn't do a stellar job implementing it
[14:07] <BluesKaj> that was the story that going around on the ubuntu chats in late 2008, ecips ..I remember it well
[14:07] <tux__> 1:3.0-0ubunt amd64
[14:07] <ecips> heh - make your terminal screen wider
[14:07] <ecips> :)
[14:07] <BluesKaj> ppl were dumping pulseaudio as soon as they upgraded
[14:08] <ecips> apt-cache show pulseaudio|grep Vers
[14:08] <tux__>  1:3.0-0ubuntu2
[14:08] <ecips> Well, thats the one that fixed it for me
[14:08] <ecips> have you rebooted?
[14:08] <tux__> yes i have
[14:09] <BluesKaj> apt-cache policy pulseaudio works too
[14:09] <ecips> BluesKaj, So many ways to skin a cat :)
[14:10] <ecips> tux__, So what are the symptoms you are seeing?
[14:11] <tux__> er.. no pulse ;)
[14:11] <BluesKaj> well, pulseaudio has been allowed to develop into an app that actually works where as alsa is till being upgraded in order to run properly under pulse , but that 's all
[14:11] <ecips> so the server isnt running?
[14:11] <tux__> daemon is already running afaik
[14:12] <tux__> pidof pulseaudio
[14:12] <tux__> 1485
[14:14] <alankila> I have a developer perspective to pulseaudio. Not someone who has written anything in it, but something against it. Pulseaudio is actually simple and pretty to use, especially for simple cases. It's about as good as one other favorite audio abstraction called libao
[14:15] <alankila> also I liked the fact that pulseaudio allows one-place configuration of the resampling algorithm rather than having alsa pick some linear interpolation thing which is pretty aliasy for that purpose, though it is possible to write sound .asoundrc that changes that
[14:15] <alankila> sound=some
[14:16] <alankila> so anyway it has full support for me. libasound2 is a horrible API. It takes 100-line program merely to open an audio device and set it up for some bit depth, sample rate, and buffer sizes, where pulse accomplishes all that in single function call.
[14:17] <alankila> and writing .asoundrc files is so hard that the entire capability of configuring alsa might just as well not exist
[14:17] <BluesKaj> alankila, I'm regretting the lack od development in alsa , it worked fine without pulse for my needs , now alsa doesn't link to webaudio anymore , especially on pci soundcards , my old pc with integrated audio still doesn't need pulse
[14:18] <alankila> alsa's problem is, imho, that it's a 2nd system effect design. OSS was clearly limited and clunky, but ALSA went overboard with flexibility just trying to support every audio feature there might be. In the meantime, all everyone else wanted was something simple and obvious to use.
[14:19] <ecips> alankila, The plague of open sores software :)
[14:19] <alankila> Perhaps if ALSA had worked out how to do dmix before, pulse would not have happened. We shall never know. What did happen was that arts and esound got invented, and I guess they both sucked.
[14:19] <tux__> when i run alsamixer, all it shows is S/PDIF  :(
[14:19] <ecips> pulse seems to be the last man standing
[14:20] <ecips> tux__, pavucontrol
[14:20] <tux__> oh i forgot about that ;)
[14:21] <alankila> the thing is, I do think we need userspace sound daemons, because users expect capabilities like routing audio to headsets. ALSA is a raw hardware interface, and it needs to be "virtualized", so there is actually a need for something that sits atop it.
[14:23] <alankila> I simply wish pulse was designed better. Audio is such a simple problem for modern computing systems, you could do a lot to make it more convenient. Get rid of all the weird sample formats, only support floating point audio; expose audio as a ring buffer with a function that fetches the play cursor position that hardware has read, so you can control latency by deciding how far ahead of the play cursor you are writing, etc.
[14:24] <ecips> alankila, You havent allowed for the Apple and Microsoft factor :)
[14:24] <alankila> but anyway, I'm rambling. None of this changes anything.
[14:24] <ecips> When there is a standard, break it as soon as possible.
[14:24] <BluesKaj> yeah for ppl who , for some reason, need several audio sources running simultaneously, something that i don't need
[14:25] <alankila> well, apple's coreaudio uses floating point, and I'm not aware when they have broken it since designing it; microsoft uses the memory-mapped audio ring buffer concept in directsound and I love it
[14:25] <alankila> this shit is pretty easy if you just copied the best of what your competition has already done for years
[14:27] <ecips> alankila, Your knowledge of these things exceeds mine by several orders of magnitude :) I'm just a humble network plumber. :)
[14:28] <ecips> alankila, You obviously work with this sound stuff regularly :)
[14:28] <alankila> I have some audio-related hobbies that took up more of my time 1-2 years ago
[14:29] <ecips> I remember paying for an OSS license so I could get the sound on my PC going
[14:29] <ecips> That was some time back... :)
[14:29] <alankila> that could have been in 1997 or something
[14:29] <ecips> Yeah, around then I think
[14:30] <alankila> I remember there was a time when the paid version of OSS was ahead of the free version
[14:30] <ecips> I had a toshiba laptop
[14:30] <ecips> that the free version didnt support
[14:30] <alankila> though it seems to me that OSS4 has entirely lost its way, it has become an abstraction that actively hides stuff from users rather than one that tries to engineer a good answer to difficult questions
[14:31] <alankila> for instance you can't ask for OSS4 system what the length of latency is: it just has some symbolic constants with values like "a little", "somewhat", "quite a lot, actually". There used to be ioctls that tried to calculate it but they couldn't always answer correctly because drivers and hardware suck
[14:32] <ecips> heh :)
[14:32] <alankila> incidentally the very same problem that resulted in pulseaudio behaving poorly when it was first widely deployed
[14:32] <ecips> "sort of"
[14:32] <ecips> lol
[14:32] <alankila> sound drivers do not bother to tell because very few people care
[14:32] <ecips> alankila, I think it is one of those things that most people dont even know exist
[14:33] <alankila> to make the latency as obvious as possible, I'd really love to have this "memory mapped ring buffer" thing. DirectSound is great. You can have buffer that plays for 5 seconds if you want, but you can write only 10 ms ahead of the play cursor if you think that's what your program is jitter-free enough to handle.
[14:34] <alankila> so you realize a latency that is entirely up to you, up to the maximum latency value of 5 seconds, which implies you are just behind the play cursor in your writing, and it must play through the whole buffer before it reaches that point
[14:34] <ecips> how does alsa buffer sound?
[14:35] <alankila> it can do memory mapped i/o too, though I'm not sure if it's still the default way. There's typically a function you call that does writing, and something happens which causes the writing to occur
[14:35] <alankila> but I did not really manage to work out how to calculate the latency of ALSA audio from that, because I do not have the concept of a play cursor in a ring buffer, there's just some degree of buffering. :-/
[14:36] <ecips> Well, I think it is bed time for me!
[14:36] <alankila> ALSA structures everything as "periods" with a "period size". The entire buffer is periods * period_size frames long, and you write a period_size chunk at a time
[14:37] <alankila> so I guess it sleeps until it knows the play cursor is past the period you are about to overwrite, and then writes that data. But this doesn't really match how the hardware likely operates, which probably reads in much smaller chunks, or so I imagine...
[14:37] <ecips> 2240hrs here
[14:37]  * ecips yawns
[14:39] <ecips> nite all!
[14:40] <alankila> yes, laters.
[14:40]  * BluesKaj still wonders why i need pulse for a pci m-audio car , but not for a nvidia integrated audio chip
[14:40] <BluesKaj> nite ecips
[14:41] <BluesKaj> of course I'm running 12.04 on the old pc , with very few upgrades
[14:42] <alankila> I think everybody "needs" pulseaudio or should at least use it, if audio output is desired at all. It does a lot of the difficult stuff like allows you to select output configuration from a dropbox rather than muck around in alsa switches trying to work out how to enable iec958 output or something.
[14:42] <alankila> and instead of 30 sliders of which some might control volume, there is only one volume slider now
[14:43] <alankila> and if you are unfortunate enough to listen to cd-quality audio on chip that can internally only clock at 48 kHz, then you don't get linear interpolation based resampling but some higher quality algorithm by default. (Though I've noticed that the default algorithm has progressively become worse over time.)
[14:44] <alankila> actually I'm not sure if the algorithm is better. That would depend on pulse being smart actually. It would have to use the raw hardware rather than plughw and configure it to one of the hardware's native rates to avoid those atrocious alsa defaults
[14:45] <BluesKaj> well, I always the spdif digital output to an audio system ..pc speaker mostly don't do the joib for me , so I let the DAC in the amp do the conversion , and other ctrls like tone etc are done by the amplifier
[14:45] <alankila> I sure hope it uses hw rather than plughw, otherwise it misses an opportunity to undo another wart of ALSA
[14:46] <alankila> the algorithm now is "speex-float-1"
[14:48] <BluesKaj> alankila, so you're syaing also isn't up to the job at the get go , then we have another layer of processing thru pulse
[14:48] <BluesKaj> alsa isn't up
[14:51] <alankila> Hmm. I see. Kaiser window, probably 60 dB SNR, and I guess something like 80 % cutoff though I have to guess, it hasn't been written
[14:55] <alankila> BluesKaj: alsa is a hardware interface, and has dedicated itself to such. But users expect something more "cooked", and capable. For instance, per-application volume level is quite useful, as is the ability to play multiple sounds simultaneously and to change stream to a headset, or lower volume of your music player because you got a phone call over skype, and so on
[14:56] <alankila> this kind of integration makes for great user experience, and it's completely out of scope for alsa
[15:00] <BluesKaj> I just use the pause button , if i get phone call on skype or otherwise ,.and I never use simultaneous audio sources
[15:11] <BluesKaj> alsa doesn't need to be everything to everybody , just let it work/link with webaudio like it used to , that's all I ask...let hose that need multiple audiosources etc use pulse
[15:14] <bjsnider> alankila is right, everybody should be using pulse
[15:15] <BluesKaj> bah humbug
[15:17] <BluesKaj> I don't use it my 12.04 pc because I don't need it , alsa is working fine without pulse
[15:19] <alankila> BluesKaj: what if I told you that not everybody is exactly the same
[15:19] <alankila> when making decisions for a distribution you have to think about what everybody needs. Even if you never needed any features that pulse provided, it shouldn't harm you either that they are there.
[15:20] <BluesKaj> yes , hence my post about "everything to everybody" , aal
[15:20] <BluesKaj> alankila,^
[15:22] <bjsnider> i hope you removed system sounds and made sure only one thing at a time could ever make noise
[15:22] <BluesKaj> well , unfortunately linux audio has obviously become a "dog's breakfast" and it need a new audio suite with better HW integration
[15:22] <BluesKaj> I don't use system sounds
[15:23] <BluesKaj> it needs
[15:23] <bjsnider> no, please, not yet another audio suite
[15:23] <BluesKaj>  a replacement
[15:24] <BluesKaj> a comprehensive one
[15:26] <bjsnider> i think we can just make the current ones better
[16:29] <BluesKaj_> Hiyas all , the timeservers don;'r use the EST settings that i choose , the time is set to UK time at every bootup , altho the EST setting is still eanbled in the date time dialog
[16:30] <BluesKaj_> oops wrong chan
[19:28] <ybon> Anyone here experiencing "ImportError: No module named pyexpat" on Raring after install?
[20:52] <xaph> hi guys,  I'm using ubuntu 13.04 now and installing awesome doesn't creata a slimdm entry.
[20:52] <xaph> how can i add a new entry to slimdm?
[20:53] <xaph> sorry not slimdm, lightdm
[20:55] <trism> xaph: the desktop file seems to be there, though I see in the diff, NoDisplay=true was added in the raring version for some reason
[20:56] <trism> xaph: if you have already restarted lightdm and verified that it still isn't there, you might edit /usr/share/xsessions/awesome.desktop and remove that line
[20:56] <xaph> trism, thanks for your answer. I checked that file but not noticed nodisplay.
[20:56] <xaph> trism, I'll try it now.
[20:57] <xaph> trism, by the way where did you check these file? Where's the diff?
[21:01] <trism> xaph: related bug 1097240 (the diff is here: https://launchpad.net/ubuntu/+source/awesome/3.4.14-1 )
[21:02] <rocky> not sure where the best place to ask this question is... but are the ubuntu unity webapp integration points available for google chrome in stable ubuntu or ubuntu+1 ?
[21:02] <trism> seems like adding NoDisplay=true is the new thing for window managers (seems kind of silly to add that and then have gdm ignore it on purpose)
[21:02] <rocky> actually perhaps a better question is "how do i get started with unity-integrated webapps?"
[21:07] <xaph> trism, thanks for information. I'll try it now.
[21:08] <RNDMb> Hi! I upgraded my ubuntu on my laptop to 13.04 and now it freezes when  I try to put it to sleep. However, only when it is not plugged in. Where should I look?
[21:09] <xaph> trism, it worked now. thanks again :)
[21:38] <alex_mayorga> !raring
[21:39] <alex_mayorga> !schedule
[21:40] <alex_mayorga> !upgrade
[21:45] <rubeni> hi to all
[22:30]  * BluesKaj checks xchat text