[12:55] <apw> stgraber, more lxc test regression fun for you: LP: #1556931
[14:59] <dsmythies> on my 16.04 test server, and as of maybe a day or two now, I can not compile "perf" (tools/perf). At the   "LINK     perf" step there is an error: "/usr/bin/ld: cannot find -liberty".  I haven't been able to figure out what package or whatever is missing. I successfully compiled perf just 48 hours ago, on March12th, but have done updates and some cleanup in between. Any ideas?
[15:02] <apw> dsmythies, sounds like a lack of build-deps ? libiberty-dev or something ?
[15:06]  * dsmythies goes off to check stuff...
[15:11] <dsmythies> apw: Yes, I agree, but I haven't been able to figure out what exactly is missing. By the way, compiling the kernel (mainline) is working fine.
[15:11] <apw> dsmythies, well -liberty is "give me library iberty, which is libiberty.so et al
[15:12] <apw> have you checked libiberty-dev was installed ?
[15:19] <dsmythies> apw: It wasn't. And with it, now compiles fine. Thanks. Still do not understand: There is no "/usr/lib/x86_64-linux-gnu/liberty.so"; Why it worked 2 days ago, but not now. Anyway, thanks very much.
[15:27] <apw> libiberty.so
[15:34] <dsmythies> apw: yes, but I didn't know to look for that, my only clue was "/usr/bin/ld: cannot find -liberty" which I thought meant liberty.so. Anyway it was autoremove that didn't realize I needed it and removed the package: "2016-03-13 13:02:21 remove libiberty-dev:amd64 20160215-1 <none>". Conclusion: My mistake (like that is a surprise to anyone reading this).
[15:37] <apw> dsmythies, well your build-deps are defined in debian/control in the package, so you should be building in a chroot with all those deps installed to match what the code is expecting
[15:43] <dsmythies> apw: I never build that way. I only build mainline and only use, for example, "time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-test"
[15:44] <apw> dsmythies, right, so then you get to work out your build-deps using the "extreme pain and guesswork" way
[15:44] <apw> as you are finding, though if it was me, i would install the build-deps for the ubuntu kernel into a chroot, and build my mainline ones in that chroot
[15:49] <dsmythies> apw: I have never had much success with that method. I also seem to get better error reporting with the way I do it (which is similar to: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild ) or so I think (it has been years since I did your method).
[16:22] <stgraber> apw: fine to ignore, we don't have ppc64el images on images.linuxcontainers.org right now
[16:23] <apw> stgraber, ack thanks, i'll hint those
[16:36] <jdstrand> jsalisbury: hey, you gave me a new kernel for bug #1547619, but I'm not 100% sure 4.3.0-040300-generic (#201603101009) doesn't have the bug
[16:37] <jdstrand> jsalisbury: my comments today were saying that the I needed an ubuntu kernel for overlayfs, so tried the latest xenial when doing that and it had the bug. I am back to testing 4.3.0-040300-generic (#201603101009) now
[16:37] <jdstrand> I suspect it doesn't have the bug, but I'm not sure yet
[17:16] <jsalisbury> jdstrand, ack
[17:17] <jsalisbury> jdstrand, I'll remove that kernel and reset the bisect
[17:22] <cristian_c> jsalisbury: hi
[17:31] <jsalisbury> cristian_c, hello
[17:31] <cristian_c> jsalisbury: I'd like to know if upstream has received the patch
[17:32] <cristian_c> *wether
[17:32] <jsalisbury> cristian_c, not yet, I'll send it today
[17:32] <cristian_c> ok
[17:33] <jdstrand> jsalisbury: sorry for the confusion
[17:40] <jsalisbury> jdstrand, np
[18:34] <melodie> hi
[18:34] <melodie> to install the 4.4 kernel on a Kubuntu Wily, is that the right place to get the packages and the only one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
[18:35] <apw> those are only debug kernels, they have no ubuntu sauce
[18:35] <melodie> hi apw
[18:35] <melodie> "ubuntu sauce" ?
[18:36] <melodie> which packages do I need and where should I get them from?
[18:36] <melodie> http://linuxdaddy.com/blog/install-kernel-4-4-on-ubuntu/
[18:36] <apw> there are no official packages for wily of 4.4
[18:36] <melodie> what this gui said: would that be ok?
[18:36]  * apw bets that is the guy who tells you to wget foo | sudo bash
[18:36] <melodie> kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.4-wily/  ?
[18:36] <apw> that well known security plan
[18:37] <apw> those are debug kernels, with no ubuntu additional patches, no stable updates, no bug fixes etc
[18:37] <apw> no updates
[18:38] <melodie> I need 4.4.x kernel and headers for someone who buys a machine with the latest Intel Skylake CPU
[18:38] <melodie> he will be aware that it will be a temporary solution
[18:38] <melodie> already aware...
[18:38] <melodie> and will need to upgrade to Xenial later
[18:39] <melodie> he will also be aware how to unlock the kernel thing and make it the "linux-image" and "linux-image-generic" rules in his package manager
[18:39] <apw> why not just upgrade him to xenial anyhow
[18:39] <apw> anyhow iirc skylake is not stabled with 4.4
[18:39] <melodie> last time I wanted to install Kubuntu Xenial in virtualbox the installer just didn't work there (in Mate, it did though)
[18:40] <apw> i seem to recall we have like a 100 commits on top of 4.4 in xenial just for skylake and broadwell
[18:40] <melodie> ok, so do we stick with the kernel that's in Wily by default?
[18:40] <apw> if it was me i'd upgrade to xenial, warts and all
[18:40] <apw> i mean i run it on all my kit, and its been pretty good
[18:40] <melodie> I can't afford to take the risk
[18:40] <apw> which risk
[18:41] <melodie> Kubuntu?
[18:41] <apw> runnign a kernel with no security is a hell of a risk
[18:41] <melodie> I'm one hour and half far from this man's office
[18:41] <melodie> and he is just a user
[18:41] <apw> i can probabally find 3-4 root exploits in 4.4
[18:41] <apw> just by reading the changelog
[18:41] <sbeattie> did the 4.4.0-12.28 tag not get pushed to the xenial git tree?
[18:41] <melodie> I believe you, just if he can use the actual kernel that's in Wily, I'm ok with that
[18:42] <melodie> I run Xenial in my own machine (upgraded from former installs) and I have 4.4.0-12-generic #28-Ubuntu
[18:42] <melodie> sbeattie is that the one version you are talking about?
[18:44] <apw> sbeattie, i have it in my tree, have you git fetch --tags origin that repo
[18:44] <apw> sbeattie, as we are rebasing some in some cases you can miss tags if we wen from 11 -> 13 before you fetch
[18:44] <apw> (without --tags)
[18:47] <sbeattie> apw: ah, it's there, just not on master
[18:47] <apw> right, a little rebase in there somewhere
[18:48] <melodie> I'll be doing the install next thursday. Can I have a 4.3 or a 4.4 that's ok for an end user who has high demands? :) (and has been using Ubuntu boxes only since several years!)
[18:50] <apw> if he has skylake i think he is out of luck for reliablity before xenial, or lts-xenial
[18:51] <sbeattie> melodie: sorry, my question was unrelated to yours, was trying to figure out which commits are in that kernel, and which are in the next one.
[18:51] <apw> sbeattie, yep
[18:51] <melodie> apw the store where they put the computer together tried Kubuntu Wily on it and they said as live it booted fine
[18:51] <melodie> sbeattie yes sure
[18:52] <apw> melodie, then he shouldn't need 4.4
[18:52] <melodie> sbeattie now the users out there, at "askubuntu" and such all seem to agree to use the 4.3 or 4.4 in Wily, while Xenial is being worked on to reach the final
[18:53] <apw> xenial is pretty much stablised now, we're not making huge changes any more, we are past FF and on the home straight
[18:53] <apw> xenial seems pretty stable in the main to me
[18:53] <melodie> apw boot is one thing, then he does image processing with very high resolution (and the machine besides Skylake has a good asus mobo, 8 GB Ram)
[18:53] <melodie> what is FF ?
[18:54] <melodie> is it a beta now?
[18:54] <apw> feature freeze, change gets much harder to apply now that is past
[18:54] <melodie> ok let me grab one :)
[18:54] <apw> we've produced some betas yeah
[18:54] <melodie> apw from my former experiences, LTS used to be stable after the first version of the new edition, for Xenial it would be 16.04.1 ^^
[18:55] <sbeattie> melodie: if kubuntu is needed, I'm unsure what the state of kubuntu/xenial is. you might ask sgclark in #kubuntu-devel, as she's been doing a lot of the packaging work for kubuntu.
[18:55] <melodie> ok, I'll head there right now, thanks for the info
[18:56] <melodie> I'll grab one anyway to give it a whirl
[18:59] <melodie> my iso is feb 8th. can someone remind me what is the zsync command line to update the ISO?
[18:59] <melodie> this is the link to the actual iso: http://cdimage.ubuntu.com/kubuntu/daily-live/current/xenial-desktop-amd64.iso
[19:00] <apw> zsync -o <file> <url.zsync>
[19:00] <melodie> apw thks!
[19:01] <melodie> starting! nice! :D
[19:05] <dsmythies> melodie: There are always example commands ( I use rsync and can never remember) on the daily testing page at : http://iso.qa.ubuntu.com/qatracker/milestones/351/builds/114631/downloads which in turn I got to from http://iso.qa.ubuntu.com/qatracker/milestones/351/builds
[19:06] <stgraber> apw: hey, so looks like powerpc (not 64el) isn't booting with current 4.4 from xenial
[19:06] <stgraber> apw: smoser may have some more details for you, all I know is that I dist-upgraded my ppc VM and it stopped booting, smoser had to reboot me into 3.19 manually
[19:08] <apw> stgraber, which versoin number is that ?
[19:08] <melodie> dsmythies thanks but that would be even worse for me to remember, just now I realised what the structure of the command line is, and as for the -o option, I guess a "zsync --help" will remind it to me next time
[19:08] <stgraber> ii  linux-image-4.4.0-12-powerpc64-smp    4.4.0-12.28                     powerpc      Linux kernel image for version 4.4.0 on 64-bit PowerPC SMP
[19:08] <apw> stgraber, and do you have one which did boot before that, in 4.4 ?
[19:08] <smoser> 3.19 booted
[19:08] <apw> stgraber, i think we need a bug and i'll get jsalisbury to get this bisected
[19:08] <apw> i just realised we don't run adt on power, sigh
[19:08] <stgraber> apw: nope, I upgraded from trusty to xenial so it's the first 4.4 I try
[19:09] <smoser> qemu cmdline that results in "cant find root" looks like this
[19:09] <smoser> qemu-system-ppc64 -name rockne-01 -echr 0x05 -enable-kvm -M pseries -cpu host -smp cores=2,threads=1 -m 8G -net nic,macaddr=52:54:00:00:42:01 -net tap,script=no,downscript=no,ifname=tap4201 -device spapr-vscsi -drive file=/var/lib/libvirt/images/shared/rockne-01/disk1.img -drive file=/var/lib/libvirt/images/shared/rockne-01/eph0.img -drive file=/var/lib/libvirt/images/shared/rockne-01/save.img -nographic -vga none
[19:09] <jsalisbury> apw, I'll watch for the bug to come in
[19:09] <smoser> where disk1.img has the root filesystem on it.
[19:09] <stgraber> apw: the issue is storage related, smoser got dropped into a shell with no block listed in /proc/partitions
[19:09] <smoser> only ram disks.
[19:10] <apw> stgraber, we may have lost a storage driver from the initrd, this is all new initramfs-tool
[19:10] <apw> s
[19:10] <apw> jsalisbury, this might also not be the kernel, this might be initrafs-tools
[19:10] <jsalisbury> apw, ack
[19:11] <apw> i wonder if its possible to downgrade initramfs-tools on there to wily and see if that boots
[19:11] <apw> stgraber, ^
[19:11] <apw> to eliminate that
[19:12] <stgraber> there doesn't appear to be any storage related module loaded on the 3.19, so I'm assuming it was all built-in then
[19:12] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557130
[19:12] <apw> ok so going back won't help
[19:12] <stgraber> pseries_rng             3547  0
[19:12] <stgraber> rtc_generic             2711  0
[19:12] <stgraber> autofs4                53194  2
[19:12] <stgraber> ibmveth                29947  0
[19:12] <apw> stgraber, does that have a dmesg, i might be able to tell from that
[19:13] <stgraber> that's all I've got loaded on 3.19, none of them sound storage related
[19:13] <stgraber> apw: it doesn't as I don't have access to that, smoser may be able to get it if I reboot back into the busted kernel
[19:13] <apw> stgraber, a dmesg from the good kernel is what i want
[19:13] <stgraber> ah
[19:13] <apw> so i can see waht driver has the device
[19:13] <stgraber> that I can give you
[19:15] <stgraber> apw: http://paste.ubuntu.com/15386280/
[19:15] <smoser> well,
[19:15] <smoser>  http://bazaar.launchpad.net/~smoser/+junk/powerkvm-install/view/head:/README
[19:16] <smoser> i did:
[19:16] <smoser>  http://cdimage.ubuntu.com/ubuntu-server/daily/current/xenial-server-powerpc.iso
[19:16] <infinity> apw: The first port of call here would be diffing configs from ppc64-smp and generic/ppc64el, since they're meant to be identical minus endian flip and some Mac drivers.
[19:16] <smoser>  ./ubuntu-boot-iso ./ubuntu-14.04.3-server-powerpc.iso sda.img --stuff-preseed=ubuntu.preseed
[19:16] <apw> infinity, and indeed as far as i know they are
[19:16] <smoser> which works to isntall trusty
[19:16] <smoser> and that fails loading usb drivers with xenial iso
[19:16] <infinity> apw: Lemme tear apart the debs and look.
[19:17] <stgraber> apw: so ibmvscsi it looks like
[19:17] <apw> infinity, i'll look see if this dmesg tells me the driver name
[19:17] <smoser> running ^ shows:
[19:17] <smoser>  Error while running 'modprobe -v usb-storage'
[19:17] <stgraber> oh, could it be as simple as me missing the -extra package?
[19:17] <apw> smoser, well its now a module
[19:18] <apw> if you have no extras, you are likely in a hole
[19:18] <stgraber> I just did a package diff between the ppc64el and powerpc box and they don't have the same set of kernel packages installed...
[19:18] <apw> as you have no hardware drivers
[19:18] <infinity> stgraber: There is no extra for ppc64-smp
[19:18] <infinity> It's not split.
[19:18] <stgraber> infinity: ah
[19:18] <apw> oh, heh, except that
[19:18]  * apw checks this is in the initrd, might not be
[19:18] <apw> and it was builtin in W so you'd be fine
[19:18] <infinity> It would also be a bug if the virt drivers were in extra, of course. ;)
[19:19] <apw> heh yeah
[19:19] <smoser> well, it seems to me that powerpc at least under qemu and '-device spapr-vscsi' -cdrom needs some love)
[19:19] <apw> but a _differnet_ one
[19:19] <apw> ok this is most likelyu an initramfs-tools issue
[19:19] <smoser> after a while, it fails saying:  Detect and mount CD-ROM ... could not be mounted
[19:19] <stgraber> root@1ss-powerpc:~# lsinitramfs /boot/initrd.img-4.4.0-12-powerpc64-smp | grep ibmvscsi
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi
[19:19] <apw> as this moved =y -> =m
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvfc.ko
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvscsi.ko
[19:19] <stgraber> so the module is in the initrd apparently
[19:19] <apw> oh hrm
[19:20] <apw> that is less expected
[19:20] <smoser> and yeah, no disk device there either
[19:20] <smoser> so seems iso shows same failure that stgraber is hitting.
[19:21] <apw> smoser, if you boot that to the initramfs prompt, does ibmvscsi appear in lsmod, and if not does modprobe ibmvscsi make the disks appear
[19:21] <apw> maybe we have a missing device alias
[19:21] <smoser> i just killed it. but i tried modprobing it and not there.
[19:21] <smoser> i can get it back to the iso failure quick enough
[19:21] <apw> ack
[19:23] <smoser> apw, exactly zero modules loaded in the initramfs
[19:23] <smoser> er... in the installer environment
[19:24] <apw> and if you attempt to load them by hand ?
[19:24] <smoser> ~ # modprobe ibmvscsi
[19:24] <smoser> modprobe: ERROR: could not insert 'ibmvscsi': Unknown symbol in module, or unknown parameter (see dmesg)
[19:24] <apw> wtf
[19:24] <smoser> dmesg | tail -n 4
[19:24] <smoser> [   12.006176] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> [   12.016503] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> [   13.070630] usb_storage: Unknown symbol mcount (err 0)
[19:24] <smoser> [  125.209403] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> so it did try to load it.
[19:24] <stgraber> so missing dependency it looks like
[19:24] <apw> i thought the kernel rewrite the mcount bits
[19:24] <smoser> also
[19:24] <smoser> [    0.839630] ibmvscsi: module verification failed: signature and/or required key missing - tainting kernel
[19:25] <apw> ?
[19:25] <infinity> Oh!
[19:26] <infinity> That's a bug I knew about already but hadn't had time to look at.
[19:26] <infinity> Silly me for not having 48 hour days.
[19:26] <apw> infinity, happenign in all ppc kernels, or just this one
[19:27] <apw> smoser, can you get an entire dmesg off there somehow ?
[19:27] <infinity> apw: Hard to say, this is the one most people exercise.
[19:27] <smoser> http://paste.ubuntu.com/15386345/
[19:27] <infinity> apw: But for weird reasons, only happening on big-endian.
[19:27] <infinity> apw: Maybe due to the CPU support being different between powerpc and ppc64el, leading to different optimised routines and submodules.  Hadn't had a chance to look.
[19:27] <smoser> you want anything else there?
[19:28] <apw> i am sure mcount is -g stuff, and i have this feeling the kernel uses that and rewrites it for ftrace, or something vile
[19:28] <apw> so i am not expecting to see mcount in there
[19:29] <infinity> apw: I'll get a VM booted into that kernel with some violence so we can examine it a bit better.
[19:29] <apw> infinity, oh not it is called mcount, we do use that we just supply an mcount which does ftrace and not counting
[19:29] <apw> so perhaps ftrace is busted on there
[19:30] <smoser> you can probably boot it in qemu-system-ppc64 on intel
[19:30] <smoser> in lightning fast speed. https://gist.github.com/smoser/7a07d9f8929dc11b4ed9
[19:36] <smoser> oh well, attempt at that failed
[19:36] <infinity> apw: Huh.
[19:36] <apw> infinity, i might have found it
[19:37] <infinity> apw: So, I happened to have a very old xenial ISO.
[19:37] <apw> infinity, go ahead
[19:37] <infinity> apw: And this broke between 4.2.0-16.19 and 4.2.0-17.21
[19:37] <infinity> Which is curious.
[19:37] <infinity> Since nothing changed there...
[19:38] <infinity> Maybe that's a red herring, and it's actually how the initrd was built that broke.
[19:38] <apw> there is a fix after 4.4, which could account for this
[19:38] <infinity> apw: Yeah, but that doesn't account for why wily.iso works and xenial.iso with almost the same kernel doesn't. :P
[19:39] <apw> oh no we have it in via stable
[19:39] <apw> yes, it would if the compiler changes, what gcc are we using in x
[19:39] <infinity> It must be a userspace thing...
[19:39] <infinity> Not a compiler issue.
[19:39] <infinity> This kernel was built in wily.
[19:39] <infinity> With the same toolchain as the working one.
[19:39] <infinity> https://launchpad.net/ubuntu/+source/linux/4.2.0-17.21
[19:39] <infinity> That's the delta between working and not.
[19:40] <infinity> So I don't think it's the kernel's fault.
[19:40] <apw> infinity, ok ... not that then
[19:40] <infinity> I need to tear apart these initrds.
[19:40] <melodie> hi infinity o/
[19:40] <apw> infinity, kmod ?
[19:40] <apw> no you say in wily, hrm
[19:40] <infinity> apw: The kernels were both built in wily.  The userspace for the second is xenial.
[19:41] <infinity> apw: Which is, I'm sure, the key.
[19:41] <apw> well what else does one use other than kmod to load a kernel
[19:41] <apw> module, and fial in this case
[19:42] <apw> i guess any depedency libraries
[19:42] <infinity> 20151021 -> 20151203
[19:43] <infinity> That's our date range for breakage.
[19:43] <infinity> Based on the two ISOs I have here.
[19:43] <apw> infinity, and kmod is almost the same
[19:43] <apw> last year, so before kmod
[19:43] <apw> but, we use very little in userspace in initramfs
[19:44] <infinity> apw: No difference in file lists in the two initrds.
[19:45] <apw> phththt
[19:45] <apw> infinity, and you have the same mcount oddness
[19:46] <apw> infinity, and this regression is in the wild on wily, argle
[19:46] <infinity> apw: I don't think it is.
[19:46] <infinity> apw: I think it requires xenial userspace to be fucked.
[19:46] <apw> oh i see, but
[19:46] <infinity> apw: But I could install wily and upgrade to be sure.
[19:47] <apw> i don't thnk that isnecessar
[19:47] <apw> y
[19:47] <apw> as we are clear the same kernel is broke with xenial
[19:47] <apw> so what is in the initrd that is not busy box
[19:48] <apw> to load a module we just map it and offer it to the kernel
[19:50] <infinity> Hahaha.
[19:50] <infinity> I thought I was going to be clever by using virtio to work around the issue so I could get installed.
[19:50] <infinity> [   16.884617] isofs: Unknown symbol mcount (err 0)
[19:50] <infinity> So, no ISO for me.
[19:50] <infinity> Time for netboot.
[19:52] <apw> infinity, can you install any modules at all, or are tey all broken
[19:53] <infinity> apw: Some work.
[19:53] <infinity> apw: Switching to virtio for both nic and scsi is getting me tooling along, luckily.
[19:54] <infinity> Oh Em Gee, d-i has a "show password" toggle now!
[19:56] <infinity> apw: Install grinding along decently now.  Will revisit in a bit and we can investigate on a live system with the issue.  Might make more sense there than trying to unwind the code blind.
[19:57] <apw> infinity, indeed
[19:59] <infinity> Man, I've been spoiled by live-installer on the server ISOs.  A full netinst is much slower.
[19:59] <infinity> Reminds me that I wanted to publish those base images and use live-installer for netinst too.
[19:59] <infinity> Probably too late to wedge that into xenial. :/
[19:59] <apw> infinity, when quilt 3.0 applied patches it is meant to barf if they have any fuzz right ?
[19:59] <infinity> apw: Fuzz, yes, offsets no.
[20:00] <infinity> (Thankfully)
[20:00] <apw> ahh ok, then that makes more sense
[20:00] <infinity> You can feed it some extra options to make it reject on offset mismatches too, if you're paranoid about code blocks migrating.
[20:01] <apw> infinity, i am getting an odd behaviour on debdiff where the diff is not including the applied patches, which ... it should
[20:02] <melodie> infinity seeing you makes me think, I'd like to ask if you remember having considered adding a conf file for zram-config in the next LTS?
[20:02] <apw> and yet when you unpack it it is applied ok
[20:02] <infinity> apw: The debdiff shouldn't show patches applied.
[20:02] <apw> thats stupid
[20:03] <melodie> infinity one allowing to setup / choose the size of blocks and the number?
[20:03] <infinity> You say stupid, I say working as intended. :P
[20:03] <infinity> melodie: It would be lovely to do, but I can't commit any time right now.  Maybe after Beta2.
[20:03] <infinity> melodie: My life is remarkably hectic right now.
[20:04] <melodie> infinity I just wanted to remind you about it, to be sure you didn't forget our discussion a few months ago and for you to try to stick it to some kanban somewhere. :)
[20:05] <melodie> the users of zram-config would all really appreciate, especially the long time users :)
[20:05] <infinity> apw: If debdiff showed patches applied, you'd get the diff twice, essentially.
[20:06] <apw> i guess, hrm
[20:06] <apw> still makes my head hurt :)
[20:08] <infinity> apw: Alright, on a full system, it still can't probe it.  So it's not just a missing dep in the initrd.
[20:08] <apw> infinity, no can't be that i can see
[20:09] <apw> if you are running modprobe foo, and it fails there are not a whole heap of things involved
[20:09] <apw> kmod and the kernel, and a teensy bit of libc
[20:09] <apw> infinity, and that is the same kernel that works in wily
[20:10] <apw> and indeed libc is its only library
[20:11] <infinity> Well, not the same kernel now, I installed with 4.4.0-12
[20:11] <infinity> But I can downgrade to wily's for a proper comparison.
[20:13]  * infinity gets all sciency.
[20:16] <apw> heh
[20:18] <infinity> ARGH.
[20:18] <infinity> WHAT.  THE...
[20:18] <infinity> apw: 4.2.0-16.19 (wily's ship kernel) works fine.
[20:18] <infinity> On xenial userspace.
[20:19]  * infinity tries -17 again to see if he's insane.
[20:20] <infinity> apw: is toolchain stuff in the .deb somewhere, or do I have to scrub build logs?
[20:21] <apw> if it does, work forward to find the last one
[20:21] <apw> build logs i would think
[20:21] <apw> we should record that, oh we must record the compiler in /boot somewhere
[20:21] <apw> not anything else though
[20:21] <apw> infinity, ^
[20:22] <apw> infinity, oh no, we grep it out of the kernel
[20:22] <rtg> apw, don't we record it in the .deb ?
[20:23] <apw> infinity, rtg, we record it in every .ko, which is how i check it apparently
[20:23] <apw> readelf -p .comment "$ko"
[20:24] <infinity> Okay, now I'm going to lose my mind slightly.
[20:24] <infinity> 4.2.0-17-powerpc64-smp, which failed on an old xenial server ISO, works fine on my installed system.
[20:25] <apw> well that is more believeable, can you hop skip and jump forward
[20:25] <apw> looking for the first bad
[20:26] <apw> as you've just eliminated userspace i assume
[20:26] <infinity> apw: It's more believable, but why did that ISO show the problem?  It's asking more questions than it answers. :P
[20:26] <apw> shhhh it'll hear you and change
[20:26]  * infinity goes to find an early 4.3.0
[20:28]  * apw puts a small bet on 4.4.0-3.17 as the first bad
[20:28] <infinity> apw: Any particular reason?
[20:28] <infinity> apw: Is that where the commit you thought was the "fix" was introduced?
[20:28] <apw> there is only one fix to the module scraper, fixnign a gcc-6 thing in the tree
[20:28] <apw> and i want it to be that
[20:29] <infinity> apw: Was that pulled into 4.2.0 stables too?
[20:29] <apw> it looks benign but ... maybe its not
[20:29] <infinity> (I have no access to the librarian here, it's much easier if I can pull from the archive. :P)
[20:29] <apw> infinity, looks like it was
[20:29] <infinity> apw: Tags?
[20:30] <apw> Ubuntu-4.2.0-28.33 was the first one with in 4.2
[20:30] <apw> Ubuntu-4.4.0-3.17 in 4.4
[20:30] <apw> dunno if that is it of course, but it is a worry
[20:31] <apw> though if you can test one of those version brackets i guess it might eliminate easily
[20:32] <apw> Ubuntu-4.2.0-27.32 is prev on 4.2 and Ubuntu-4.4.0-2.16 on 4.4 if that helps any
[20:33] <infinity> 28 and 29 don't exist, grabbing 30.
[20:33] <infinity> Must have been respin hell.
[20:33] <apw> oh yeah, probabally, we did a lot back there
[20:34] <apw> oh we don't reap nbs in -updates, handy for you here
[20:34] <infinity> Quite.
[20:35] <infinity> Booting 27.
[20:37] <infinity> That seems fine.
[20:38] <apw> these are the "first sane" looking 4.3 and 4.4s Ubuntu-4.3.0-1.10 Ubuntu-4.4.0-1.15
[20:38] <infinity> -30 is also fine.
[20:38] <apw> ok so not that then, pup
[20:38] <apw> your search continues then
[20:39] <apw> of course you will get to -12 and it will work
[20:39] <apw> such is the nature of the world
[20:39] <infinity> Yeah, I'm worried about that myself.
[20:43] <infinity> apw: Well, at least 4.4.0-12 still fails.  So, I'm not completely insane.
[20:44] <infinity> I'm going to have to mirror a bunch of kernels and scp them up to test more interim ones.
[20:44] <apw> ack
[21:08]  * apw wonders how it is going
[21:26] <Beret> man
[21:27] <Beret> unplugging a usb key from my xenial machine just hard locked it
[22:20] <nusch> how to get broadcomm wireless driver (bcmwl-kernel-source) working with mainline(4.5) kernel to test for some bug?
[22:21] <apw> nusch, i doubt that anyone has made one yet
[23:31] <nusch> @apw would would you then suggest to debug this https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1545320 ? I need wireless to reproduce this bug. Use 4.4? Or somehow backport only relevant functionality of i915 ?
[23:34] <apw> nusch: i am not sure why you need wifi for a graphics bug, could you use an ethernet or wifi usb dongle


[07:19] <ripps> fta: is there a way to change the priority of a ppa-bot run? in case I have a fix for a broken packages that I don't want to wait 36 hours for.
[08:50] <eagles0513875> morning
[20:07] <asac> micahg: hi
[20:07] <asac> finally here if you need me ;)
[20:07] <micahg> ok :)
[20:08] <micahg> just wanted to fix xul191 and xul192 in dailies yesterday fta helped me
[20:08] <asac> great
[20:09] <asac> anyone has a 64-bit install?
[20:09]  * micahg has 64 bit
[20:09] <asac> not sure what happened, but since release day my browser starts to block for a while regularly
[20:09] <asac> firefox 3.5 that is
[20:09] <micahg> asac: 3.5.5 is being released today
[20:09] <asac> i thought it was the sqlite update i added to -security PPA ... but that seems to be not the only reason
[20:10] <asac> micahg: right. i got that from backlog :/
[20:10] <asac> i think i will stay hard this time and dont stop vacation for that
[20:10] <asac> did that like 3 times in the past already
[20:11] <micahg> sqlite got bumped anyways, so it won't matter till lucid
[20:11] <asac> micahg1: sqlite got bumped in 3.5 branch?
[20:11] <micahg1> wait, it wasn't bumped until 3.5.6 I think
[20:11] <micahg1> yeah
[20:11] <micahg> 3.5.6
[20:12] <asac> ok. thats still some time for us to react
[20:12] <micahg> but 3.5.5 is being released today because of some crashes with 3.5.4
[20:12] <asac> not sure what to do
[20:12] <asac> yeah. it was a safe bet to see that coming
[20:12] <asac> they landed like 140+ bug fixes for 3.5.4 ...
[20:12] <micahg> I bumped it for the dailies
[20:12] <micahg> wow
[20:12] <asac> i wouldnt even be shocked if they do a 3.5.6 next week ;)
[20:13] <micahg> well, the GTK fixed was approved for 3.5.6
[20:13] <asac> yeah. but if they do a firedrill 3.5.6 they would push everything else back to 3.5.7
[20:14] <micahg> yeah
[20:14] <micahg> asac: where should I put the stuff I want to talk about for Lucid?
[20:14] <asac> https://wiki.ubuntu.com/MozillaTeam/Lucid/Ideas
[20:14] <asac> thx ;)
[20:14] <asac> one second
[20:15] <asac> not sure if i already added anthe page
[20:17] <asac> ok added three things there
[20:17] <asac> damn ... wiki is slow ;)
[20:18] <asac> micahg: go ahead and add your stuff there ;)
[20:18] <asac> the brackets is just so one knows who added the idea  (e.g. no assignment etc.)
[20:19] <asac> micahg: which version did they bump sqlite to?
[20:19] <micahg> <IP_ADDRESS>
[20:19] <asac> ok. thats just a minor bump then
[20:20] <asac> we have 3.6.16
[20:20] <micahg> yeah
[20:20] <micahg> maybe can get <IP_ADDRESS> as WRU?
[20:20] <micahg> *SRU?
[20:20] <asac> we probably have to
[20:21] <asac> the risk of internalizing a sqlite for xulrunner feels higher
[20:22] <micahg> is it clear we'll be moving to TB3 in lucid?
[20:23] <asac> there is no news about 16.1 :( http://www.sqlite.org/news.html
[20:23] <asac> micahg: i would think its safe to assume that. yes.
[20:23] <micahg> weird
[20:23] <asac> is tb3 out yet?
[20:23] <asac> anyway. we should push that up asap
[20:23] <micahg> which?
[20:24] <asac> tb3
[20:24] <micahg> RC1 should be later this month
[20:24] <micahg> I think we should wait for that
[20:24] <asac> yeah
[20:24] <micahg> will it take over the thunderbird package?
[20:24] <BUGabundo> bRoas o/
[20:24] <asac> but shouldnt matter ... the earlier the better
[20:25] <asac> micahg: i have no strong opinion on that
[20:25] <asac> on the one hand i already see folks screeming
[20:25] <micahg> well, I think it's better to put a stable version in
[20:25] <asac> if they get migrated to 3.0
[20:25] <asac> because of different memory footprint ;)
[20:25] <micahg> well, TB2 will be EOL shortly after lucid release
[20:25] <asac> otoh i dont think that tbird 2 will be supported much longer
[20:25] <micahg> we can't leave it
[20:25] <asac> especially not throughout the full LTS cycle
[20:25] <asac> right
[20:25] <micahg> I think it's easier if we just replace it
[20:26] <asac> so yeah. i dont think we have a choice and need to replace it
[20:26] <micahg> other major apps do it
[20:26] <asac> sure
[20:26] <micahg> the only problem will be TB2 on hardy
[20:26] <asac> not sure if we should automatically take over on first upload
[20:27] <asac> yeah
[20:27] <micahg> that's why I think we should wait for RC1
[20:27] <asac> but most rendering engine issues are not really issues for TB2
[20:27] <asac> so we might get through with backporting the rare security issues that pop up in the mail stack
[20:27] <asac> micahg: i am sure that even RC1 is not stable enough.
[20:27] <asac> tb is the most popuplar mailclient in ubuntu
[20:27] <asac> it will cause huge amount of complains etc.
[20:28] <micahg> asac: http://www.sqlite.org/src/vinfo/2a832b19b657ba02a2caaafbc15be19cc6b80fd9
[20:28] <asac> s/most popular/most popular based on the fact that users explicitly opt-in/
[20:28] <micahg> hmm
[20:28] <asac> micahg: yes. but where is the changelog ;)
[20:28] <micahg> well, maybe wait for release before upgrading if it's before Feb 2010
[20:29] <BUGabundo> then we will have a shirt test windows
[20:29] <asac> i think we should upload tbird 3 with versioned packaging scheme so users can opt-in now and report issues
[20:29] <asac> then we take the other package over later this cycle
[20:29] <asac> hopefully when tbird is at 3.0.2 or something
[20:29] <micahg> is that hard to do?
[20:29] <asac> no
[20:29] <asac> its what we do with firefox
[20:29] <micahg> ok
[20:30] <asac> have two versions in parallel ... then take over the older ones
[20:30] <asac> once we consider it ready enough
[20:31] <micahg> asac: http://www.sqlite.org/releaselog/3_6_16_1.html
[20:32] <asac> ok. so its a special-fix-for-mozilla ... i would guess
[20:32] <asac> thx
[20:32] <micahg> asac: can I get a testimonial on my wiki page? https://wiki.ubuntu.com/micahg
[20:34] <asac> micahg: when did you start on ffox bugs? april? jun? (sorry .. time runs fast ;))
[20:34] <micahg> april
[20:37] <asac> micahg: applying for motu or membership?
[20:37] <micahg> membership right now
[20:37] <micahg> MOTU when you get tired of pushing my uploads :)
[20:37] <BUGabundo> lol
[20:38] <av`> MOTU team has 3 months life
[20:38] <av`> ;)
[20:38] <micahg> oh, probably not worth it then :)
[20:38] <av`> then with archive reorg there will be a general Ubuntu Developers plus various seeds
[20:39] <BUGabundo> av`: chaning it again?
[20:39] <BUGabundo> ahh nice
[20:47] <asac> micahg: ok done
[20:48] <asac> my english had some hick-ups ... but i think that should be good ;)
[20:49] <asac> hi BUGabundo
[20:49] <asac> ;)
[20:49] <asac> hope you missed me ;) .... hehe
[20:49] <asac> will be off in an hour again and back on monday ;)
[20:50] <BUGabundo> asac: took you while :D
[20:50] <BUGabundo> enjoy the long weekend
[20:50] <asac> yep ;)
[20:50] <asac> that will be 8 days in total then
[20:50] <asac> ;)
[20:50] <BUGabundo> asac: I 've seen users
[20:50] <BUGabundo> getting again that assertion error
[20:50] <BUGabundo> on NM
[20:50] <asac> sorry. i lost context ;)?
[20:51] <BUGabundo> similar to the one I had a while ago with wireless networks
[20:51] <BUGabundo> out of range
[20:51] <asac> hmm. my brain sems to be tabula rasa atm ;)
[20:51] <asac> is there a bug i could check?
[20:52] <micahg> thanks asac
[20:52] <asac> very welcome
[20:52] <asac> micahg: how does memberswhip work nowadays?
[20:52] <asac> is that still done in a IRC meeting?
[20:52] <asac> like community council?
[20:52] <av`> asac, yes
[20:52] <asac> if so, ping me ahead so i can be there
[20:52] <micahg> can you help me with a TB3 daily breakage?
[20:53] <asac> sure :)
[20:53] <asac> will be here for another hour as it seems :)
[20:53] <asac> av`: thx!!
[20:53] <micahg> ok, I'm still waiting for the meeting to be planned
[20:53] <av`> community council process everything through irc as alwias :)
[20:53] <asac> yeah. i remember mammoth meetings in the past
[20:53] <micahg> ok, fta added a patch to fix the eula: http://bazaar.launchpad.net/~mozillateam/thunderbird/thunderbird-3.0.head/revision/34
[20:53] <asac> which made me think that maybe they redid the whole process
[20:53] <micahg> this landed which I think takes care of it: http://hg.mozilla.org/releases/comm-1.9.1/rev/f1b37d88d156
[20:54] <micahg> if it does, I'll just drop the old patch, but I wasn't sure
[20:55] <asac> hmm
[20:55] <asac> not sure why the initial patch was needed
[20:56] <asac> where was APP_EULA_BLOCK used?
[20:56] <asac> anyway
[20:56] <asac> they dropped the holw APP_EULA_BLOCK business
[20:56] <asac> so yeah
[20:56] <asac> i would just drop it
[20:56] <micahg> ok
[20:56] <micahg> I'll fix the daily then
[20:56] <asac> and see if somethign else causes issues
[20:56] <micahg> BTW, I started using fta's pbuilder script
[20:56] <micahg> it's nice
[20:56] <asac> micahg: yeah. graeat
[20:57] <asac> micahg: just include in the "drop" comment what landing triggered this
[20:57] <asac> but you probably do that automatically alreadcy ;)
[20:57] <micahg> it took me 3 hours to build xulrunner though
[20:57] <asac> micahg: hmm. maybe i should check them too ;)
[20:57] <asac> micahg: thats long
[20:57] <BUGabundo> asac: back
[20:57] <BUGabundo> no bug... at least not from memory
[20:57] <micahg> fta told me I should add -j4 to pbuilder
[20:57] <BUGabundo> PPA fixed it for me
[20:57] <asac> micahg: why does it take so long=? because setting up pbuilder tgz takes ages?
[20:58] <asac> micahg: well. 3 hours is rewally long. i mean on my quite old system xulrunner building takes about 20-25 minutes
[20:58] <asac> without -jX
[20:58] <asac> so just on a single core
[20:58] <micahg> wow
[20:58] <micahg> I have a P3 1Ghz dual core
[20:58] <micahg> wasn't tasking my system
[20:58] <micahg> but took forever
[20:58] <asac> micahg: oh. ok. P3 ... thats old
[20:58] <micahg> :) IBM x330
[20:58] <asac> micahg: i am not sure you want to use -j4 on that one ;)
[20:58] <av`> asac, up for sponsoring me a merge?
[20:59] <asac> i mean ... if you have like 1g of mem thats bad ;)
[20:59] <micahg> asac: I have 1.5G
[20:59] <mac_v> yeah asac's back \o/
[20:59] <asac> thats not good enough for -j4 either ;)
[20:59] <micahg> anyways, wwe got the PPAs back, so I won't need it as much
[20:59] <micahg> or rather the builders
[20:59] <asac> micahg: i mean .. .linking libxul.so takes about 1.5G ;)
[20:59] <asac> micahg: right. PPAs are better ... though builders are currently scares resource as it seems
[21:00] <asac> mac_v: hi ... dont be too happy. i will just drop out later today till monday ;)
[21:00] <asac> (or sunday ... not so sure yet :))
[21:00] <BUGabundo> dinner
[21:00] <BUGabundo> bbl later
[21:00] <asac> holy vacation ;)
[21:00] <micahg> we got the builders back: https://edge.launchpad.net/builders
[21:00] <mac_v> hehe ;)
[21:00] <asac> av`: what sponsoring?
[21:00] <av`> asac, zenity for desktop-team (main)
[21:00] <asac> micahg: grewat. so QA team has finished whatever thy did with them ;)
[21:00] <asac> those are QA team machines afaik... that only help out on ppa
[21:01] <mac_v> asac: just wanted to know if this Bug #386900 , was ever fixed... andrew marked it as fixed an now its not working... is it a regression or .. was it wrongly marked as fix released in th emiddle
[21:01] <asac> av`: i would prefer to ask someone from desktop team to do that ;) ... want me to prod someone ?
[21:02] <asac> mac_v: i havent fixed it. not sure why it was ever marked as fixed
[21:02] <mac_v> asac: yeah , my thoughts.. too... thanks :)
[21:02] <asac> mac_v: it was a papercut we never got toi
[21:02] <av`> asac, no, don't need to, it's a package I update in Debian too and there is a bug open and ubuntu-main-sponsors are already subscribed
[21:02] <asac> ok
[21:03] <asac> av`: if noone gets to it let me know i will do that on sunday then ;) (or if i check back before that, then)
[21:03] <av`> so will be done somewhen, just wanted to ask you if you were free :)
[21:03] <asac> i am free for chat ;)
[21:03] <asac> aka nice converstaions with mozillateam ;)
[21:03] <av`> ok, great, it's a really small merge, e.g one less B-D, watch file changed to look at unstable versions too
[21:04] <micahg> asac: should I note the bmo issue in the changelog for tb3?
[21:04] <av`> so nothing too hard, I gonna commit part of the delta to the Debian's SVN later
[21:04] <av`> ok, great, it's a really small merge, e.g one less B-D, watch file changed to look at unstable versions too :)
[21:04] <mac_v> asac: when we were checking what bugs were actually fixed in the papercuts , we found this was not ... thanks for confirming :)
[21:04] <av`> damn keyboard
[21:04] <asac> av`: ok. at best we would get to "sync" state again. is there a reason why ubuntu has a diff?
[21:05] <asac> mac_v: thx. add it for this cycle again. we definitly should fix it for LTS
[21:05] <asac> please not in round-1 ;)
[21:05] <av`> asac, the delta is just a less B-D and a watch file change, after this merge we can sync
[21:05] <mac_v> asac: lol , sure :)
[21:05] <asac> av`: why not directly sync then?
[21:05] <av`> asac, cause debian don't look at unstable versions
[21:05] <av`> and cause debian still has that B-D
[21:06] <micahg> asac: upstream broke lpia in xul193: http://launchpadlibrarian.net/35181733/buildlog_ubuntu-karmic-lpia.xulrunner-1.9.3_1.9.3~a1~hg20091105r34606%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[21:06] <asac> av`: right. so fix the B-D in debian and then sync ... the unstable watch file is not worse keeping a diff imo
[21:07] <asac> micahg: hmm. did you retry the build?
[21:07] <asac> oh wait. only me and fta can retry i guess
[21:07] <micahg> itt's been that way for days
[21:07] <asac> hmm
[21:07] <asac> ok
[21:07] <av`> asac, exactly, I gonna commit part of the delta but it won't be uploaded just for that, so we have to wait before syncing anyway :)
[21:07] <asac> ok
[21:08] <asac> micahg: do you have a netbook ;)?
[21:08] <micahg> nope
[21:08] <av`> but for sure it will be the last merge of zenity :)
[21:08] <asac> ok
[21:08] <av`> asac, I'm on a netbook
[21:08] <asac> av`: with lpia kernel?
[21:08] <asac> i guess you run i386?
[21:09] <av`> nope, I run i386
[21:09] <av`> yes
[21:09] <asac> micahg: do we know when this started? feels like its a change to tracemonkey triggering this
[21:09] <micahg> I can check
[21:10] <micahg> I"m testing TB3 now in my ppa without the patch
[21:10] <asac> kk
[21:10] <micahg> about 2 hours
[21:13] <micahg> asac: started on 31/10/2009
[21:13] <asac> huh?
[21:13] <micahg> lpia FTBFS
[21:13] <asac> av`: where is the bug id?
[21:14] <av`> asac, https://bugs.launchpad.net/bugs/474072
[21:15] <asac> av`: did you use "bzr" for that ;) ... just wondering because MoM seems to be down (found a mail from james_w)
[21:15] <asac> av`: debian .dsc plz
[21:15] <av`> asac, yeah, I just saw the bzr merge thing, it rocks! anyway I did that merge manually
[21:15] <av`> yes, just a second
[21:15] <asac> sure
[21:16] <asac> gimme .dsc ;)
[21:16] <av`> asac, http://ftp.de.debian.org/debian/pool/main/z/zenity/zenity_2.28.0-1.dsc
[21:16] <asac> av`: why the diff on the Uploaders?
[21:16] <asac> just prepatch from debian svn?
[21:17] <asac> i assume you tested it?
[21:17] <av`> asac, it's autogenerated
[21:17] <av`> I'm a GNOME Debian member
[21:17] <av`> so I'm into gnome-pkg-tools
[21:17] <av`> that auto-generate the control file
[21:17] <micahg> I found a cool pull-debian-source tool in ubuntu-dev-tools
[21:17]  * asac runs debuild -S -sa -kasac@deb -v2.28.0-0ubuntu2
[21:18] <av`> check debian/control.in you'll see Uploaders: @GNOME_TEAM@
[21:18] <asac> kk
[21:18] <asac> pushed
[21:18] <av`> you rock thanks :)
[21:19] <asac> micahg: thx ;) ... i always thought there must be something for that :)
[21:19] <av`> asac, you didnt do an upload for me since ages, I feel happy now :)
[21:19] <micahg> I think it's pulling from unstable still
[21:19] <asac> av`: at least one count on my sponsoring list ;)
[21:19] <av`> lol
[21:19] <asac> haha
[21:19] <asac> welcome
[21:19]  * asac happy too
[21:19] <av`> :)
[21:20] <micahg> oops TB borked
[21:20] <asac> av`: my first upload to lucid ;)
[21:21] <av`> asac, yes! I hope you gonna remember it since it is your first upload into lucid!!! :)
[21:21] <asac> i will
[21:22] <av`> asac, I hope you gonna take a good word for me to seb when there won't be ubuntu-dev / ubuntu-core-dev anymore, e.g for joining desktop seed
[21:22] <av`> since I gonna focus on general uploads plus GNOME
[21:22] <av`> and mozilla stuff of course
[21:23] <asac> not during vacation ... but atm i feel positive on that
[21:23] <av`> not now, it will happen around genuary, so no hurry!!
[21:23] <asac> i try to avoid -desktop channel ;) ... otherwise rick will hunt me for working etc.
[21:23] <micahg> asac: apparently, there's no changelog history for TB3 in bzr. so do I need to add a changelog entry or just a bzr entry for the patch drop
[21:24] <asac> micahg: i think so far we didnt put anything in changelog ... so just drop with proper comment in bzr
[21:24] <av`> asac, desktop seed will be open in around 3-4 months, so you have time :)
[21:24] <micahg> ok
[21:24] <asac> maybe i will gen a gigantic changelog from bzr on first upload to archive
[21:24] <av`> it's not needed now
[21:24] <asac> not so sure yet
[21:24] <asac> av`: thx for the update on that. seems i have enough time to check out mozilla seed et al during UDS
[21:25] <micahg> well, I think we should generate it based on a diff of the debian dir between TB2 and TB3
[21:25] <av`> asac, yeah, please ask to have a mozilla seed, if not everyone will be able to upload extension's stuff
[21:25] <asac> micahg: i think we started a fresh branch when we forked it
[21:25] <asac> micahg: so its probably the whole bzr changelog
[21:25] <micahg> yeah, it seems that way
[21:26] <asac> dont ask me why we have a fresh brnach ;)
[21:26] <micahg> well this patch that I'm dropping was only added for TB3 AFAIK
[21:26] <asac> but we should add all tb2 changelog
[21:26] <asac> for sure
[21:26] <micahg> so tehre's no reason for it to be in the changelog
[21:26] <asac> right. but thats difficult to filter out manually
[21:26] <micahg> oh, can I set up the series in the tb project?
[21:27] <asac> will be back in 5 minutes ... hold still ;)
[21:32] <asac> micahg: we can setup series for tb projects ... prob is that we kind of misuse them in ffox
[21:32] <asac> usually the series should point to upstream branch not packaging branch
[21:32] <asac> how does it help?
[21:32] <micahg> bzr branch lp:thunderbird/series :)
[21:32] <asac> right
[21:33] <asac> is there a way to create "sub-seriesssed"?
[21:33] <asac> serieses
[21:33] <micahg> I was going to make 2.0, 3.0, and 3.1 with focus on 3.0
[21:33] <asac> like thunderbird/3.0/ubuntu-packing
[21:33] <asac> micahg: focus should always be trunk imo
[21:33] <asac> e.g. we should have a matching series for upstream branches
[21:34] <micahg> ok
[21:34] <asac> and only create versioned seriessses for things that go a branch != trunkJ/central
[21:34] <micahg> so focus on 3.1
[21:34] <micahg> or should I call the series trunk
[21:34] <asac> let me check
[21:34] <asac> ok since we use versions for firefox we probably should do the same for tbird
[21:35] <micahg> ok
[21:35] <micahg> so, focus on 3.1
[21:35] <asac> if that is what comes out of a plain build of comm-central clone then yes
[21:37] <asac> ok ... /me does some cooking too now ...
[21:37] <asac> ~30min
[22:12] <asac> back (for a bit)
[22:15] <micahg> ok, TB looks like it'll finish now, I'll update the branch in a little bit
[22:15] <asac> cool. go ahead
[22:16] <micahg> dropping 2 patches
[22:16] <asac> every patch gone is a clear win ;)
[22:44] <asac> micahg: someone updated stanfoird-pwdhash without updating branch ;) ... wanna hunt him down :)
[22:45] <asac> hmm
[22:45] <asac> ok
[22:45] <asac> micahg: someone updated stanfoird-pwdhash without updating branch ;) ... wanna hunt him down :)
[22:45] <asac> hmm ... doesnt look like it ended up in ubuntu
[22:45] <asac> maybe debian?
[22:46] <BUGabundo> asac: a few users being hit with DPI bugs on FF on clean installs?
[22:46] <asac> havent heard of it
[22:46] <asac> !whois quadrispro
[22:46] <BUGabundo> 4 reports on LoCo ML
[22:46] <BUGabundo> and a bug on LP
[22:46] <BUGabundo> to firefox 3.0
[22:46] <BUGabundo> DIUH
[22:46] <av`> asac, I know him
[22:47] <av`> asac, it's from the italian team
[22:47] <BUGabundo> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/220568
[22:47] <asac> 23:30 [freenode] [quadrispro(n=alessio@ubuntu/member/quadrispro)] hi, please apologize me, I've uploaded stanford-pwdhash just a moment  before reading this -> https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/stanford-pwdhash.ubuntu :(
[22:47] <asac> 23:31 [freenode] [quadrispro(n=alessio@ubuntu/member/quadrispro)] going away, but again: I'm sorry
[22:47] <BUGabundo> asac: ^^^^
[22:47] <asac> av`: can you check with him?
[22:47] <asac> i said: "please replay and submit a merge request
[22:47] <asac> "
[22:47] <asac> but he was gone
[22:47] <asac> but now i dont even see any upload for that package
[22:47] <av`> why he uploaded that?
[22:47] <asac> seems he failed to spot that its done in extension team
[22:47] <asac> but not sure where it is
[22:47] <BUGabundo> man, so many 3G modems probs :(
[22:48] <BUGabundo> I told the release guys :(
[22:48] <asac> av`: yeah so its uploaded
[22:48] <asac> https://edge.launchpad.net/ubuntu/+source/stanford-pwdhash/+publishinghistory
[22:48] <asac> what a mess
[22:48] <asac> av`: tell him to do a 1.7+real-0ubuntu1
[22:48] <asac> using branches so we can produce it uses get-orig-source etc.
[22:49] <asac> av`: let me send him a mail and CC you
[22:49] <asac><EMAIL_ADDRESS>[22:49] <jcastro> hey asac
[22:49] <av`> yes
[22:49] <jcastro> are you back from holiday?
[22:49] <av`> asac, damn it, we had to update m-d stuff there : /
[22:49] <BUGabundo> jcastro: lol
[22:53] <asac> av`<EMAIL_ADDRESS>?
[22:53] <asac> jcastro: no ... please don't tell my boss :-P
[22:53] <asac> monday
[22:53] <jcastro> asac, I swear to god I will
[22:53] <jcastro> :)
[22:53] <av`> asac, yes, or<EMAIL_ADDRESS>[22:53] <asac> ok sent
[22:53] <asac> thanks
[22:55] <av`> np, gonna slap him tomorrow
[22:55] <av`> ehehe
[22:56] <asac> be nice ;)
[22:56] <asac> its a clear win if he understands how to use the branches in future
[22:56] <asac> he seems to like stanford-pwdjhash ;)
[22:56] <asac> maybe also tell him to fix the mozilla-devscripts part :-P
[22:56] <asac> whzile he is at it ...
[22:56] <asac> of course not mandatory ;)
[22:59] <asac> micahg: anything else you need from me before i drop out again?
[22:59] <asac> same for anyone else ;) of course
[23:01] <micahg> asac: I don't think so, there's one file I have to remove form the TB.install file (license.html), but I think I shoul dbe ok
[23:01] <micahg> asac: when will you return?
[23:01] <av`> lol, I will, finishing an SRU now
[23:01] <asac> sunday?
[23:01] <micahg> ok
[23:01] <asac> is that ok?
[23:01] <asac> good
[23:01] <micahg> of course :)
[23:01] <asac> i might be here tomorrow during day
[23:02] <asac> but then a friend comes and i wont be back till sunday afternoon
[23:02] <micahg> I just know not to ping you if I need something
[23:02] <asac> hmm
[23:02] <asac> i will set my irc client to away
[23:02] <asac> i think i will see all pings when back then
[23:02] <micahg> ok
[23:02]  * asac didnt do that the last few days
[23:02] <asac> so ... now away ;)
[23:02] <micahg> ok, have fun
[23:03] <asac> so at least your pings are not lost
[23:03] <asac> thx
[23:03] <asac> byebye and greetz to fta if he comes back ;)
[23:03] <micahg> ok


[08:59] <CIA-85> ubiquity: evand * r4179 maverick-redesign/ (3 files in 3 dirs):
[08:59] <CIA-85> ubiquity: * Pack a VTE in a GtkScrolledWindow and wire it up to /var/log/installer/debug
[08:59] <CIA-85> ubiquity: * Use a better color for the PartitionBox dots.
[08:59] <CIA-85> ubiquity: * Bring back the Skip button, showing it alongside the GtkExpander when
[08:59] <CIA-85> ubiquity:  the GtkExpander is expanded.
[16:47] <CIA-85> ubiquity: evand * r4180 maverick-redesign/ (gui/gtk/stepPartAdvanced.ui ubiquity/plugins/ubi-partman.py): Add spacing around the advanced partitioning page.
[16:54] <CIA-85> ubiquity: evand * r4181 maverick-redesign/ubiquity/plugins/ubi-console-setup.py: Fix reference to currently disabled greyed overlay.
[18:03] <CIA-85> ubiquity: evand * r4182 maverick-redesign/ (4 files in 3 dirs): Bring in some new artwork from the just-finished greeter page design.
[18:32] <shtylman> ev: hows the pizza? :p


[07:13] <abeato> trainguards, is it possible to land https://requests.ci-train.ubuntu.com/#/ticket/1109 ? it is needed for turbo
[07:15] <robru> abeato: looks like sil tried to publish but then didn't due to packaging changes. better ask him why he didn't, eg maybe there's a problem with the packaging
[07:16] <abeato> robru, but it passed automated signoff
[07:17] <robru> abeato: all i know is that sil hit publish and then didn't follow it up when it prompted him to ack the packaging changes. either he forgot, or there's something wrong
[07:17] <abeato> robru, got it, thanks
[07:18] <robru> abeato: you're welcome! I'd offer to take a look but I don't have permission to publish anyway. best to follow up with sil, or find some other core dev if you're really in a hurry
[07:18] <abeato> robru, can wait for sil :)
[07:40] <Mirv> abeato: the packaging changes cause no reason for doubt, so I assume sil2100 just forgot to check the ack_packaging
[07:40] <Mirv> abeato: publishing
[07:41] <abeato> Mirv, actually I remember he asked about the new library dependency, and I told him why it was needed. So yes, he must have forgotten to push the button
[07:41] <abeato> Mirv, thanks
[12:32] <mterry> robru: I notice silo 41 failed its "automated signoff" -- can you tell me what that's about?
[12:32] <mterry> oh you're probably not up now
[12:32] <mterry> trainguards ^
[12:34] <jibel> mterry, there is lot of red on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-041/excuses.html
[12:35] <jibel> mterry, unsatisfiable deps
[12:35] <jibel> on xenial
[12:35] <mterry> jibel: ah thank you.  I see the links to the excuses now in the train -- I didn't notice that
[12:39] <mterry> jibel: it's because a binary is left in the ppa?  A binary that was temporarily built by unity8 in the ppa, but is no longer built.  But somehow is still hanging around
[12:40] <mterry> jibel: do you have clues on how to clean that out?
[12:40] <mterry> The remove-package archive-tools script only handles sources, and it doesn't see that version of the source in the ppa anymore
[12:41] <mterry> jibel: ah, I found the -b argument to work on binaries
[12:43] <jibel> mterry, sorry, I've no idea how to clean that out
[12:43] <mterry> jibel: I just cleaned.  How can I retest vivid auto signoff tests?
[12:44] <mterry> jibel: clicking "regression" isn't enough in this case because u8 doesn't offer a regression button, it just says there are old binaries
[12:45] <mterry> mzanetti: which toggle started the auto signoff?  I guess we can reset lander and qa signoff fields and then move them back to restart auto signoff?
[12:46] <mterry> That would start xenial and vivid.  When we only need vivid
[12:46] <mterry> But it would work
[12:46] <mzanetti> mterry, I think it was the Lander signoff one
[12:47] <mzanetti> robru, can you give us some hints here? ^
[12:47] <mterry> mzanetti: I just reset it
[12:47] <mzanetti> ah ok
[12:47] <mterry> mzanetti: would take more time to figure it out than just do it  :)
[12:58] <Mirv> mterry: there is a superseded unity8 in the PPA that can be deleted that will probably help
[12:58] <Mirv> mterry: I now deleted it
[12:59] <Mirv> mterry: mzanetti: it's far better to retry the failed tests instead of restarting the whole process in general, but I see you do have lots of lots of red
[13:01] <mterry> Mirv: I would like to restart the failed tests, but there was no button for this failure (it wasn't a dep8 regresion).  Is there another way to restart?
[13:02] <mzanetti> mterry, just skimming over some logs, it looks like some other things are weird in the system, right? not really like a real test failure
[13:03] <mterry> mzanetti: no I think it's just due to stale binaries in the ppa
[13:03] <mzanetti> mterry, can you keep retrying. I need to eat a bite... starving
[13:03] <mterry> mzanetti: which I'm surprised weren't automatically cleaned (from when we deleted unity8-schemas -- sorry that it ended up causing trouble :-/)
[13:03] <mterry> mzanetti: I did
[13:03] <Mirv> mterry: if it's a claim about missing packages instead of red Regression with logs, it'd be autodetected when it's fixed in the next britney run.
[13:04] <Mirv> mterry: mzanetti: stale binaries always stay around in the PPA:s like this and need to be manually deleted
[13:04] <mterry> Mirv: it was a claim about leftover binaries, but sure same diff.  How frequent are the britney runs for landing silos?
[13:04] <mterry> Mirv: that's a pain :)
[13:05] <Mirv> mterry: too rarely IMHO. it seems to fluctuate from 30mins to 90mins, at least when it comes to updating the web pages with results (time stamp at the top)
[13:10] <mterry> Mirv: hrm.  I'm removing the packages from the ppa with the following command:
[13:10] <mterry> ./remove-package -A ppa:ci-train-ppa-service/ubuntu/landing-041 -s xenial -m 'obsolete' -b -e  8.12+16.04.20160315.2-0ubuntu1 unity8-schemas
[13:10] <mterry> Mirv: and it claims to remove them.  But if I run it again, it says they are still there and offers to remove them again
[13:12] <Mirv> mterry: I delete with the webui and then it changes from Superseded to Deleted and it has helped in identical situations in the past with britney
[13:13] <mterry> Mirv: where do you see it in the webui?  I couldn't find the old package
[13:14] <Mirv> mterry: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+delete-packages
[13:14] <mterry> Mirv: ah thanks, didn't see it on just +packages
[13:15] <mterry> Mirv: so it says deleted, but the brittney results are the same, presumably I have to wait for another brittney run and can't seepd that up?
[13:15] <Mirv> mterry: yes it needs some time
[13:21] <mterry> mzanetti: so I guess we're waiting on brittney for another pass at the xenial bits
[13:21] <mterry> mzanetti: for vivid, I'm seeing a qmluitest failure?  But I can't find which test is failing in the logs
[13:21] <mzanetti> mterry, link
[13:22] <mterry> mzanetti<EMAIL_ADDRESS>[13:22] <mterry> mzanetti: same test passed on i386, but failed on amd64.  Might just be a fluke
[13:23] <mzanetti> mterry, the log doesn't contain a "FAIL!" string, which is what qmltestrunner would print
[13:23] <mterry> mzanetti: yeah exactly  :-/
[13:23] <mterry> mzanetti: the stderr output shows a build warning, but I didn't get the sense that we failed the test because stderr was non-empty
[13:29] <michi> trainguards: I have question with one of my silo builds
[13:29] <michi> Anyone around?
[13:30] <sil2100> michi: what's up?
[13:30] <michi> Hi
[13:30] <michi> Latest revision here is 144: https://code.launchpad.net/~michihenning/thumbnailer/fix-1556835/+merge/289321
[13:31] <michi> Currently building in silo 3. But I’ve tried twice now, and the train only picks up revision 143: https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/36/console
[13:31] <michi> I don’t understand why.
[13:32]  * sil2100 takes a look
[13:34] <sil2100> 2016-03-17 13:27:40,810 INFO Merging https://code.launchpad.net/~michihenning/thumbnailer/fix-1556835 at r144. <- this line says the train uses rev 144
[13:34] <sil2100> Is that not true?
[13:34] <michi> Let me look...
[13:35] <michi> My apologies.
[13:35] <michi> False alarm.
[13:35] <sil2100> No worries :)
[13:35] <michi> I was looking a few lines further down, where it mentions r143
[13:35] <michi> All is well then, sorry to bother you!
[13:47] <dobey> rvr: hi, can you recreate bug #1537105 using a fake card on staging with "3D" as the cardholder name? you might need silo 64 to be able to use the add card page. i'm having trouble recreating the issue, as i'm always getting a failure dialog
[13:48] <rvr> dobey: Hi. I read your comment... right now I'm busy with silo 41 verification will try to check that ASAP
[13:50] <sil2100> dobey: hey! Just confirming: removing payui click from rc-proposed is fine, right?
[13:51] <sil2100> dobey: is the pay-ui deb installed on images already?
[13:51] <sil2100> Or do we need a seed change?
[13:51] <dobey> sil2100: it should be installed as pay-service depends on it
[13:52] <sil2100> I'll double-check and proceed, ok
[13:53] <sil2100> dobey: ok, I see it as installed, removing the click in that case - thanks!
[13:53] <dobey> great
[14:36] <mterry> jibel: if a silo is in "qa-signoff: ready", does the qa happen even if it's failing its automatic signoff bits?
[14:36] <sil2100> mterry: no, not in most cases
[14:36] <mterry> bummer
[14:37] <sil2100> mterry: the scripts only consider a silo good once both are approved
[14:37] <sil2100> mterry: what's up with the autopkgtests?
[14:38] <jibel> mterry, it depends
[14:38] <mterry> sil2100: I'm trying to figure it out, but it seems like stale package nonsense or flaky tests.  Not something I would think would affect manual testing.  But I'm workign oni t
[14:38] <jibel> mterry, it depends on the nature of the failure
[14:38] <sil2100> QA can consider manually adding it to the queue
[14:39] <mterry> jibel, sil2100: OK, if I have more information I may ping.  Thanks
[14:40] <jibel> mterry, the the failure is well understood and has nothing to do with the change then it is possible to force it
[14:40] <jibel> s/the the/if the/
[15:11] <robru> mterry: mzanetti: any non autopkgtest is going to be re run by britney in every run. There's no need to "clear the result" and "re trigger", it is just always triggered every run. Unfortunately each run takes an hour or so due to high load
[15:11] <mterry> robru: makes sense OK
[15:33] <mterry> jibel: http://autopkgtest.ubuntu.com/running.shtml#pkg-qtcreator-plugin-ubuntu shows britney blocked on creating nova instances for like 18 minutes.  Is that common?
[15:38] <awe> trainguards, can someone confirm that the following silo needs core-dev acking due to packaging changes?
[15:38] <awe> https://requests.ci-train.ubuntu.com/#/ticket/1093
[15:39] <robru> awe: yes it shows packaging changes in the artifacts field
[15:42] <mterry> robru: do you know much about britney?  It seems to be getting stuck on amd64 a lot, creating nova instances
[15:44] <robru> mterry: autopkgtests you mean? (britney just triggers them, it doesn't *run* them).
[15:45] <mterry> robru: yeah autopktests triggered by britney
[15:45] <robru> mterry: no i dunno anything about it, best to ask pitti
[15:45] <mterry> robru: ok thanks
[15:46] <robru> mterry: yw
[15:53] <awe> cyphermox, can you ack the packaging changes in the NM silo?
[15:53] <awe> https://requests.ci-train.ubuntu.com/#/ticket/1093
[15:54] <awe> robru, thanks; now I see; might this be a discrete state ( ie. CoreDev review needed? )
[15:55] <robru> awe: well, strictly speaking, not necessarily core dev, just anybody with upload rights (so eg if it's a universe package, you can get MOTU instead of core dev)
[15:56] <robru> awe: in this case it is a main package so it would be core dev, or somebody with per-package rights on that package specifically
[15:57] <awe> k
[15:59] <cyphermox> awe: sorry, I can't right now
[16:03] <awe> morphis, can you try to get someone to ack the silo packaging changes?  If not, I deal with it when I return
[16:04] <morphis> awe: on it!
[16:04] <morphis> kenvandine: ping
[16:06] <awe> morphis, thanks!!!
[17:18] <rvr> sil2100: Do you know why Kaleo can't set this silo as "ready for testing"? https://requests.ci-train.ubuntu.com/#/ticket/1096
[17:21] <sil2100> rvr: looking
[17:21] <sil2100> rvr: not sure, I just switched it to ready
[17:22] <Kaleo> thx!
[17:23] <robru> morphis: just curious why the version of n-m here: https://requests.ci-train.ubuntu.com/#/ticket/1093 is lower than the one in vivid. why not just copy the vivid version?
[17:24] <morphis> robru: I think that is simply because we didn't synced back yet with what has landed in vivid since we branched  of
[17:25] <morphis> robru: but we can't just copy as there touch specific changes in the package
[17:25] <morphis> so for now we ahve to live with that
[17:26] <robru> morphis: ok, yeah it's a weird situation. it breaks britney because it refuses to test a lower-versioned package. it won't break the phone though because the phone uses ppa pinning to ensure the overlay version is chosen over the distro version, but eg anybody trying to use overlay ppa on vivid desktop would not get this package, but I guess that doesn't
[17:26] <robru> matter anyway since vivid is eol
[17:26] <morphis> robru: right
[17:27] <morphis> robru: thing is, this package has to land by tomorrow
[17:27] <morphis> so syncing back etc. isn't an option
[17:27] <morphis> and awe has done it for some time like this
[17:28] <robru> morphis: ok, well it's in qa queue, maybe ask qa people to bump up priority. I just happened to notice that britney said "N/A" which is very strange, it should really be "failed" from britney but I guess there's a bug in my parsing of britney output.
[17:28] <kenvandine> morphis, pong
[17:28] <morphis> sil2100, robru, kenvandine: can one of you review the package https://requests.ci-train.ubuntu.com/#/ticket/1093 so that nothing expect QA is in the way for landing this?
[17:28] <morphis> robru: could be ;-)
[17:29] <kenvandine> sure
[17:29] <morphis> kenvandine: thanks!
[17:29] <morphis> kenvandine, robru, sil2100: redirect any further comments to awe, dropping off now
[17:30] <kenvandine> morphis, looks fine
[17:30] <kenvandine> awe, ^^
[17:30] <robru> morphis: thanks
[17:46]  * dobey hopes 41 gets approved soon
[17:47]  * kenvandine too
[17:53] <awe> robru, so... we pinned the version of NM in the PPA as we don't want to pull in a change that had landed in distro that could've potentially de-stablized touch
[17:53] <awe> that said, not sure if anyone looked over .2 and .3 to see if there were any bits applicable to the phone
[17:53] <awe> if CVE related, I would've expected someone to ping me about it
[17:53] <awe> but maybe that's a hole in our process
[17:54] <awe> needless to say, I'm working on NM 1.2 for post OTA10
[17:54] <awe> which hopefully will line us back up again with the distro again
[17:56] <robru> awe: glad to hear it, thanks
[17:56] <awe> np
[17:56] <awe> I'll also chase down what landed in .2 and .3, just to make sure nothing urgent was missed
[18:22] <charles> meh
[18:43] <dobey> oh
[18:43] <dobey> charles: ^^ that's your problem then
[19:07] <charles> robru, could you take a look at this build failure?
[19:08] <charles> robru, it's failing to find the upstream tarball and I'm not sure why that's failing
[19:31] <robru> charles: your branch has removed .bzr-builddeb dir which the train cannot build without
[19:32] <robru> (although I'm working on removing the need for that; it's still necessary today)
[19:33] <charles> robru, you're right. ok. So I'll copy .bzr-builddeb from trunk to the branch where it's missing, and try again
[19:34] <dobey> oh why did i not catch that
[19:34] <charles> robru, thanks
[19:34] <charles> and dobey, thanks to you for looking as well
[19:36] <dobey> sure
[19:36] <dobey> now i have my own problems; flipping nonsense conflicts
[19:37] <charles> :)
[19:50] <robru> charles: yw


[12:53] <Adriannom> hi.  i have ubuntu studio 9.10 and two usb soundcards.  when i plug one in, it appears in pulseaudio.  when i plug the second one in, it does not.  it doesn't matter which order i plug them in.  here's /var/log/messages: http://pastebin.me/052dcc9003cca903c754e4039e098106 - any idea what's happening?
[12:58] <ailo> Adriannom, It's always the same device that doesn't appear? What is it called?
[12:58] <ailo> Two of the same kind?
[13:00] <Adriannom> it's not always the same device that appears, it's whatever is plugged in first ailo
[13:01] <Adriannom> and yes two of the same kind
[13:01] <ailo> Adriannom, When you say, only one appears, do you mean, you only find one of them from the devices menu in pulseaudio preferences?
[13:01] <ailo> How about jack=?
[13:03] <Adriannom> never used jack, how do i check?
[13:04] <ailo> Adriannom, Well, ok. If you open sound preferences, and look in the tab "hardware", you only see one device?
[13:04] <ailo> pulseaudio, that is
[13:04] <ailo> Or, are you using UBuntu Studio?
[13:04] <ailo> In which case it would be opening pulseaudio volume control from the menu
[13:04] <Adriannom> correct, only one device.  i'm using studio 9.10
[13:05] <Adriannom> yup, only one in volume control
[13:05] <ailo> Adriannom, If you do: cat /proc/asound/cards
[13:05] <ailo> Do you see both?
[13:06] <Adriannom> yup
[13:06] <ailo> Adriannom, They will both work with jack, then, most probably
[13:06] <ailo> Don't know why pulseaudio is not showing them both. What is it that you want to do with them?
[13:07] <ailo> Why do you want to connect two at the same time?
[13:07] <Adriannom> the soundcards are inside a mixer, i'm using ultramixer to send to two hardware channels
[13:08] <Adriannom> http://djkit.com/jb-systems/mix3-usb-mixer.html?highlight=mix%203
[13:08] <Adriannom> looking at the image of the back of it should make it clear
[13:08] <ailo> Adriannom, Ok, so it's usb1 + usb 2
[13:10] <Adriannom> hm?
[13:12] <Adriannom> grr, some apps are just not loading on here
[13:12] <Adriannom> like sound preferences :s
[13:12] <Adriannom> and some jack apps
[13:12] <ailo> Adriannom, jack apps won't load if you didn't start jack first
[13:12] <Adriannom> aha
[13:12] <Adriannom> go error messages ;)
[13:13] <Adriannom> so do i need to replace pulseaudio with jack?
[13:13] <ailo> Adriannom, I'm not sure how that device is supposed to work
[13:13] <ailo> Adriannom, pulseaudio is the desktop audio system. Jack is a pro audio system
[13:14] <ailo> You don't need to replace pulseaudio
[13:14] <ailo> Just start jack
[13:14] <ailo> You can install it by doing: sudo apt-get install qjackctl
[13:15] <ailo> That will install the jack control program called qjackctl and jackd, the sound server
[13:15] <ailo> Adriannom, But, to use two cards at the same time, that won't happen automatically
[13:15] <ailo> Adriannom, You would need to create a custom configuration, and I'm not sure if that can be done
[13:16] <Adriannom> :o
[13:16] <ailo> Adriannom, Still, I don't know how your device is supposed to work. 2 devices sounds a little strange
[13:17] <ailo> Adriannom, Try talking with people on #opensourcemusicians and #jack
[13:17] <ailo> There's also #alsa
[13:17] <Adriannom> ailo, do you know normal mixers?
[13:17] <ailo> Sure
[13:17] <ailo> Adriannom, What do you need to know?
[13:18] <Adriannom> it's like that except instead of just plugging audio jacks in as inputs you can plug usb cables in
[13:18] <Adriannom> so i can change the volumes of the music playing through each channel independantly on the hardware mixer
[13:18] <ailo> Well, usb cables are not like audio cables. Each needs a driver
[13:19] <ailo> And, for two devices to work at the same time, you need to create a common interface for them
[13:19] <Adriannom> correct.  in computer terms the mixer just has two normal usb soundcards in it
[13:19] <Adriannom> well, i had another very similar mixer which worked fine like this before
[13:19] <Adriannom> no extra config or anything
[13:19] <ailo> Two usb cables, on Linux?
[13:19] <Adriannom> same os, i just got a new mixer cause the old one broke
[13:20] <Adriannom> yup
[13:20] <Adriannom> making 3 soundcards in total
[13:20] <Adriannom> (onboard included)
[13:20] <Adriannom> all worked fine
[13:20] <ailo> With pulseaudio?
[13:20] <Adriannom> yup
[13:20] <Adriannom> all appeared on pulseaudio separately
[13:20] <ailo> So, you are sure they are not working as one now?
[13:21] <Adriannom> well, maybe they are working as one, i don't know.  i don't know how to check
[13:21] <ailo> It would sound strange to me, though
[13:21] <ailo> If they did
[13:21] <Adriannom> yeah
[13:22] <ailo> So, you used pulseaudio mixer to choose which card was used with which program?
[13:22] <Adriannom> seems i can play music out of both soundcards fine
[13:22] <ailo> Ah, but you use a special program, you said
[13:23] <ailo> Ultra mixer, right?
[13:23] <Adriannom> yeah, but i bet it'd work with any program, it's jsut using oss to play to the sound cards
[13:23] <Adriannom> i can see both soundcards fine
[13:23] <Adriannom> just not in the volume control, and one channel is quieter than the other
[13:23] <ailo> oss would be a different story all togehter
[13:23] <Adriannom> ah
[13:24] <Adriannom> oss has nothing to do with pulseaudio?
[13:24] <ailo> In oss you can use two cards just fine. But not with pulseaudio
[13:24] <ailo> pulseaudio is using alsa
[13:24] <Adriannom> oooh, sorry, my mistake
[13:24] <ailo> So, does ultra mixer not work?
[13:24] <Adriannom> it works
[13:24] <Adriannom> so i guess i could try an oss mixer
[13:25] <ailo> I don't know the specifics of oss. It is the oldest audio system
[13:26] <ailo> What else do you want to do, if ultra mixer already works?
[13:28] <ailo> Well, if you do have problems with pulseaudio, one way to turn pulseaudio off is to run a command like this: pasuspender -- mycommand
[13:28] <ailo> I think you have that on Karmic. Not sure
[13:29] <Adriannom> well, if i can get an oss mixer to work then there's no problem, probably best to not try to fix it any further, after all this is a production machine :p
[13:30] <ailo> pasuspender only suspends PA
[13:30] <ailo> Don't know what you are intending to use OSS for
[13:30] <ailo> Adriannom, I have to go, though
[13:31] <Adriannom> all i need to do is adjust the volumes of each soundcard because they are off
[13:31] <Adriannom> i'm researching that now.  thanks a lot for your help :)
[13:31] <Adriannom> you've basically solved my problem
[13:31] <ailo> Adriannom, Sure. Good luck
[13:31] <Adriannom> later!
[13:32] <ailo> Adriannom, Try alsamixer, btw. Don't know if that will work
[13:32] <ailo> Use F6 to switch between cards
[13:32] <Adriannom> fixed :D
[13:32] <ailo> Ok. Good
[13:33] <Adriannom> ok i'll try that, might make it easier
[13:33] <Adriannom> thanks again :)
[21:45] <taddaaaaa> hey im trying 2 get ubs to work on vmware for test but only get the terminal
[21:46] <ailo> taddaaaaa, Which one did you install?
[21:46] <taddaaaaa> 10.10
[21:46] <taddaaaaa> 64 bit
[21:47] <ailo> taddaaaaa, Sounds odd.
[21:47] <ailo> taddaaaaa, You could try 32bit.
[21:47] <ailo> taddaaaaa, I've had no problems
[21:48] <ailo> Don't try it that often, though
[21:48] <taddaaaaa> it's in vmware
[21:48] <taddaaaaa> if i have to boot interface or something??
[21:49] <ailo> taddaaaaa, Actually, I've never tried wmware. Only Virtual Box
[21:49] <taddaaaaa> yea i just need to get into the interface
[21:49] <ailo> taddaaaaa, But, if there is some strange problem with the graphics, you could try recovery mode
[21:50] <taddaaaaa> i just get the terminal
[21:51] <ailo> taddaaaaa, When you boot, press down shift to get to the grub boot menyu
[21:51] <ailo> There, you'll find recovery mode
[21:52] <ailo> taddaaaaa, But, I would bet, that won't help
[21:52] <ailo> taddaaaaa, It works on Virtual Box for me
[21:53] <taddaaaaa> ill try 2 c ok babai