| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| hyperair | dobey: i thought unity-greeter only handles the login screen, and not the screensaver? | 02:09 |
|---|---|---|
| hyperair | s/screensaver/lock screen/ | 02:09 |
| Unit193 | light-locker makes it so the greeter is the lock screen as well. | 02:10 |
| bluesabre | unity-greeter is not the lockscreen | 02:11 |
| bluesabre | unity now has its own unity-greeter-esque lockscreen | 02:11 |
| hyperair | https://bugs.launchpad.net/bugs/1292451 <-- well, dobey reassigned this bug to unity-greeter | 02:11 |
| ubottu | Launchpad bug 1292451 in unity-greeter (Ubuntu) "screensaver re-locks itself after unlocking if the configured screen-off timer goes off while screen is locked" [High,Confirmed] | 02:11 |
| hyperair | but the bug is clearly to do with the lockscreen, not the login screen. | 02:12 |
| hyperair | Unit193: what's this light-locker? | 02:13 |
| hyperair | it doesn't show up in dpkg -S for me | 02:13 |
| bluesabre | light-locker uses lightdm as the lockscreen | 02:13 |
| hyperair | apart from a light-locker-settings.desktop | 02:13 |
| hyperair | bluesabre: it doesn't seem to be installed on my machine. | 02:14 |
| hyperair | is it a library of some sort? | 02:14 |
| bluesabre | so, using light-locker with xubuntu makes lightdm-gtk-greeter the lock screen | 02:14 |
| hyperair | i see. | 02:14 |
| bluesabre | I'm not sure what the unity lock screen is called | 02:14 |
| bluesabre | it might just be a component of unity | 02:14 |
| hyperair | how odd, why doesn't unity use light-locker then? | 02:14 |
| hyperair | seems like a better way to ensure consistency | 02:15 |
| bluesabre | that's up to them :) | 02:15 |
| bluesabre | (im a xubuntu dev) | 02:15 |
| * hyperair sighs | 02:15 | |
| hyperair | okay | 02:15 |
| Unit193 | I thought it was, or was planned to be, but seems it's only seeded on Xubuntu and Lubuntu. | 02:15 |
| bluesabre | yeah | 02:16 |
| hyperair | i see. | 02:16 |
| hallyn | infinity: /win 25 | 02:51 |
| hallyn | feh | 02:51 |
| hallyn | infinity: so i'm intending to push the pkg in ppa:ubuntu-virt/candidate plus http://people.canonical.com/~serge/qemu-aarch64-into-arm.debdiff | 02:52 |
| hallyn | slangasek: ^ | 02:52 |
| hallyn | dannf was kind enough to do a test build, and the resulting pkgs look sane | 02:52 |
| hallyn | am i thinking clearly in that what we don't want is for qemu-user-static to include /usr/share/binfmts/qemu-$arch only for the native arch? | 02:53 |
| slangasek | hallyn: what do you mean "only"? | 02:53 |
| hallyn | slangasek: so armhf should have all but qemu-user-armhf, and arm64 should have all but qemu-user-aarch64; but having /usr/bin/qemu-user-armhf on armhf is ok | 02:54 |
| slangasek | hallyn: I guess you mean /usr/bin/qemu-user-aarch64 on armhf? | 02:54 |
| infinity | slangasek: He means that only the native arch should be excluded. | 02:54 |
| infinity | Erm, I hope that's what he means. :P | 02:54 |
| hallyn | and i mean that it's ok in /usr/bin so long as it's not in /usr/share/binfmts/ | 02:54 |
| slangasek | infinity: yes, but that's not the correct rule; i386 is not "the native arch" on amd64, but we exclude it | 02:55 |
| infinity | hallyn: So, it's shipped in /usr/bin on x86, so yes. | 02:55 |
| infinity | hallyn: As to the bin question. | 02:55 |
| infinity | hallyn: For the binfmts question, excluding things that could run natively on that arch makes sense. | 02:56 |
| hallyn | so http://paste.ubuntu.com/7201561/ is the contents of the armhf qemu-user-static pkg, | 02:56 |
| slangasek | hallyn: note that currently, qemu-user-static excludes both i386 and x86_64 on both i386 and amd64 archs | 02:56 |
| hallyn | http://paste.ubuntu.com/7201562/ for the arm64 pkg | 02:56 |
| hallyn | i dunno, i'm befuddled. i t hink i'll push to ppa only tonight :) | 02:56 |
| slangasek | hallyn: enough with the ppas | 02:57 |
| slangasek | :) | 02:57 |
| hallyn | slangasek: but qemu-user-static on my x86 has /usr/bin/qemu-x86_64-static | 02:57 |
| slangasek | hallyn: yes, but it does not install the binfmt for either of i386 or amd64 | 02:57 |
| infinity | hallyn: Yes, it has the binaries, but not the binfmt. | 02:57 |
| hallyn | slangasek: last time i fiddled with qemu-user-static i briefly bricked infinity's box | 02:57 |
| hallyn | slangasek: right that was my q | 02:57 |
| slangasek | and that's intentional, because you can run an i386 userspace on an x86_64 kernel | 02:57 |
| hallyn | just making sure that i was thinking right about that :) | 02:57 |
| infinity | slangasek: So, the binfmts should be skipped for anything that could reasonably be expecte to run natively on the same machine. | 02:58 |
| slangasek | hallyn: so the same should apply to arm+aarch64, since you can run an armhf userspace on an aarch64 kernel | 02:58 |
| infinity | Err, hallyn ^ | 02:58 |
| hallyn | infinity: cool | 02:58 |
| slangasek | provide the emulator in /usr/bin, but don't enable it via binfmt-misc | 02:58 |
| infinity | hallyn: powerpc/ppc64/ppc64el, sparc/sparc64, i386/amd64, armhf/arm64, etc. | 02:58 |
| mwhudson | slangasek: depends on the soc! | 02:58 |
| * mwhudson shuts up again | 02:58 | |
| slangasek | mwhudson: I know ;) | 02:58 |
| slangasek | we've already had /that/ discussion on #debian-qemu | 02:59 |
| mwhudson | hah | 02:59 |
| infinity | mwhudson: Yes, not all SoCs can run both, and not all x86 CPUs can run amd64 binaries, but we're approximating for minimal damage, not maximum support. | 02:59 |
| hallyn | bleh | 02:59 |
| infinity | This is an area where erring on the side of caution is sane. | 02:59 |
| hallyn | but why is there no qemu-user-aarch64 | 02:59 |
| infinity | hallyn: By which you mean qemu-aarch64-static? | 03:00 |
| infinity | hallyn: Or the non-static build that no one cares about? :P | 03:00 |
| slangasek | -rwxr-xr-x root/root 2904560 2014-03-21 09:59 ./usr/bin/qemu-aarch64-static | 03:00 |
| hallyn | yeah i didn't do that part right | 03:01 |
| slangasek | what? what's with all these last-minute changes :) | 03:01 |
| hallyn | slangasek: I'm trying to get the qemu-system-aarch64 pkg into qemu-system-arm, was all, | 03:03 |
| infinity | hallyn: FWIW, those ppc/ppc64 lines should be consolidated the same way you're doing for arm. | 03:03 |
| infinity | (powerpc) echo ppc ;;\ | 03:03 |
| infinity | (ppc64) echo ppc ppc64 ppc64abi32 ;;\ | 03:03 |
| infinity | ^-- Wrong. | 03:03 |
| infinity | Again, for the same reason that i386 and amd64 were consolidated. | 03:03 |
| infinity | hallyn: Anyhow, don't let nitpicking stop you from uploading either. If you're sure you're not breaking x86 with your upload, we can iterate bugfixes for other arches as we go along. | 03:04 |
| hallyn | so (ppc64 | powerpc) echo ppc ppc64 ppc6abi32;;\ | 03:04 |
| infinity | hallyn: And add ppc64el to the () list, yes. :) | 03:05 |
| hallyn | oh that's not in there at all right now | 03:05 |
| infinity | The mips line is probably eually wrong, but I don't know enough about mips to care today, and it doesn't affect us. | 03:06 |
| hallyn | wiat so you mean (ppc64 | powerpc | ppc64el) echo ppc ppc64 ppc64abi32;; | 03:06 |
| slangasek | infinity: aurel32 will be sad | 03:06 |
| slangasek | hallyn: yes | 03:06 |
| slangasek | (though, boggle at the strange shell convention) | 03:07 |
| infinity | hallyn: Aye. It's entirely possible the syscall emulation doesn't work across endian-flips anyway, but again, better safe than sorry here. | 03:07 |
| hallyn | alrighty | 03:07 |
| hallyn | dannf: by any chance od you have a victim on which you could install the aarch64 qemu-user-static pkg we built? that you don't mind if you have to recover? :) | 03:08 |
| hallyn | oh, well, noone's gonna be installing that right now anyway are they, so i guess there's no big hurry on that | 03:08 |
| hallyn | oh one more newbie q, | 03:11 |
| hallyn | shoudl i keep all the changelog entries from the ppa? | 03:11 |
| infinity | hallyn: Yes, though you can ditch all the versions and signatures and collapse it into one big entry for the archive upload if you prefer. | 03:12 |
| infinity | hallyn: But the log of what was done should be preserved. | 03:12 |
| hallyn | oh hey! upstream tagged rc1 in the meantime, guess i should use that | 03:13 |
| hallyn | infinity: ok, thanks, i will consolidate them and push to trusty tonight. | 03:13 |
| stgraber | hallyn: still around? | 03:53 |
| hallyn | stgraber: yeah, | 03:59 |
| stgraber | hallyn: hey, so we have a bit of a critical problem with your systemd fix :) | 03:59 |
| hallyn | i'd fogotten what a pain it is getting rid of all the roms in the qemu release tarballs | 03:59 |
| stgraber | hallyn: http://paste.ubuntu.com/7201679/ | 04:00 |
| stgraber | hallyn: my best guess is that we shouldn't be doing that nih_error_get in the failing nih_dbus_setup case as that seems to be the source of the assert, I'm just not 100% sure that this is right | 04:00 |
| hallyn | hm | 04:02 |
| hallyn | d'oh yeah | 04:03 |
| stgraber | hallyn: this is causing systemd-logind to crash and die on quite a number of machines (potentially all machines that don't have cgmanager...) | 04:03 |
| hallyn | bc it was a dbus nto nih call | 04:03 |
| stgraber | is there a dbus equivalent we need to do, or can we just ignore that and return? | 04:03 |
| hallyn | we already do that | 04:04 |
| hallyn | doing the dbus_error_init | 04:04 |
| hallyn | and _free | 04:04 |
| hallyn | am i doing the same mistake in lxc? | 04:04 |
| hallyn | i'm not! d'oh. | 04:04 |
| stgraber | well, that's good :) | 04:05 |
| hallyn | stgraber: do you want to test first, or push, or do you want me to push? | 04:05 |
| stgraber | hallyn: ok, so http://paste.ubuntu.com/7201696/ should do it right? | 04:05 |
| stgraber | I'll do a test build and send it to jdstrand for testing | 04:05 |
| hallyn | yeah that should do it | 04:05 |
| stgraber | hallyn: fix worked for jdstrand, uploaded to the archive now. | 04:30 |
| hallyn | stgraber: phew - thanks | 04:30 |
| stgraber | hallyn: np, glad I was still around at the time. It was literally in my last run through IRC windows before going to bed. | 04:32 |
| stgraber | wouldn't have been fun waking up to everyone not having logind running anymore | 04:32 |
| hallyn | yeah, for similar reason si probably should stay up awhile and look for qemu disasters :) | 04:35 |
| === thegatta_ is now known as thegattaca | ||
| jdstrand | hallyn: I thought you said you didn't have a libvirt-bin upload? | 04:39 |
| jdstrand | hallyn: we are trying to land libvirt with apparmor signal and ptrace mediation | 04:41 |
| jdstrand | hallyn: bug #1298611 | 04:41 |
| ubottu | bug 1298611 in lxc (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Fix committed] https://launchpad.net/bugs/1298611 | 04:41 |
| stgraber | jdstrand: I've rejected hallyn's upload for now, it's not a critical fix (small feature change) so it can go after yours is through | 04:42 |
| jdstrand | ok, thank you :) | 04:43 |
| hallyn | jdstrand: 'doh, sorry | 04:43 |
| hallyn | stgraber: well, libvirt will have failures with new vms, but.. | 04:44 |
| hallyn | jdstrand: when is the libvirt fix being pushed? | 04:44 |
| jdstrand | so, everything is tested up, just waited on an ack | 04:44 |
| jdstrand | waiting* | 04:44 |
| stgraber | jdstrand: a ack from whom? | 04:44 |
| jdstrand | stgraber: the release team-- specifically infinity since he has been in the loop on all of it | 04:45 |
| stgraber | jdstrand: ok | 04:45 |
| jdstrand | the ffe for apparmor userspace has not been granted yet | 04:45 |
| stgraber | ok, so the situation is, we can't let qemu in without libvirt and we can't let libvirt in because your stuff is in a PPA somewhere | 04:47 |
| stgraber | and we want hallyn's qemu in ASAP because it's a pretty major update and we want as much time as possible to catch problems | 04:48 |
| hallyn | stgraber: i could pop the trusty machien type patch for now in qemu if you've rejected the prvious upload | 04:49 |
| jdstrand | we want the same for apparmor :) | 04:49 |
| jdstrand | I think we are talking about hours | 04:49 |
| hallyn | jdstrand: i was thinking along different time scales regarding 'if i had anything' | 04:49 |
| hallyn | oh | 04:49 |
| stgraber | except hallyn's FFes have already been granted :) | 04:49 |
| jdstrand | I tried to coordinate this ealier | 04:50 |
| stgraber | but yeah, if we can get everything landed tomorrow, then fine but if apparmor is still stuck tomorrow, we should let qemu + libvirt in and you'll have to rebase your libvirt change on top of that next week | 04:50 |
| jdstrand | that works for me | 04:50 |
| hallyn | (both libvirt debdiffs are pretty trivial, no biggie rebasing either one or even merging them, <shrug>) | 04:51 |
| hallyn | jdstrand: i thought we were coordinated - i saw tyhicks' debdiff posted and thought it was done | 04:51 |
| jdstrand | hallyn: right-- you can't push mine before apparmor though, otherwise it will break | 04:52 |
| hallyn | jdstrand: gotcha | 04:52 |
| stgraber | hallyn: ok, so I'll reject your qemu for now just so nobody accepts it by mistake and breaks libvirt. You can still get slangasek or infinity to review it from the rejected queue so that when the apparmor stuff lands we can just accept it from there. | 04:52 |
| hallyn | stgraber: so qemu won't be promoted right? | 04:52 |
| hallyn | uh. ok | 04:52 |
| jdstrand | hallyn: he posted it for review, but it is only Fix Committed in the bug | 04:52 |
| jdstrand | (it is in a ppa) | 04:53 |
| hallyn | jdstrand: yeah it's a monster bug you've got there :) | 04:56 |
| jdstrand | well, it could be worse. the policy changes were minimal due to how we handled the base abstraction | 04:57 |
| hallyn | jdstrand: stgraber: i've got a bad feeling that my precise-plus-ppas-on-trusty-kernel setup is gonna have some broken containers briefly as a result :) | 05:00 |
| stgraber | hallyn: why? | 05:00 |
| jdstrand | it will work fine with a new kernel and old userspace | 05:01 |
| stgraber | I don't backport apparmor to any of my precise PPAs so you should be fine | 05:01 |
| jdstrand | that is specifically tested and supported for backport kernls | 05:01 |
| hallyn | so containers not specifying 'signal,' or wahtever will be fine? | 05:02 |
| jdstrand | if the apparmor userspace doesn't support it, yes | 05:02 |
| stgraber | yep, so long as you don't have the new parser on the host | 05:02 |
| jdstrand | and if you are on precise, then it won't | 05:02 |
| hallyn | very good, i'm reassured :) | 05:02 |
| jdstrand | I personally tested trusty kernel with ipc on precise with lxc | 05:03 |
| jdstrand | (ie, precise system with no changes other than the new kernel) | 05:03 |
| Unit193 | mvo: guten Morgen. | 05:59 |
| jibel | pitti, good morning. FYI I restarted wolfe-0{3,4,6} , dpkg segfaulted and all the tests failed. | 06:30 |
| diwic | hmm, is somebody else experiencing no sound due to lack of acl permissions on /dev/snd/ ? | 06:38 |
| RAOF | diwic: Welcome to the n-1st systemd upload! | 06:40 |
| RAOF | diwic: Updating and restarting should probably fix it for you. | 06:41 |
| diwic | RAOF, thanks. That's what I just did and got this - probably need to switch to main archive instead of mirror then | 06:41 |
| darkxst | cjwatson, any ideas what we can do about Bug 1301045? | 06:41 |
| ubottu | bug 1301045 in gnome-bluetooth (Ubuntu) "gnome-bluetooth and empathy pull in unity-control-center on Ubuntu GNOME packageset installation" [Undecided,New] https://launchpad.net/bugs/1301045 | 06:41 |
| diwic | and of course the GUI does not let me switch mirror :-( | 06:43 |
| sarnold | diwic: it may not yet be in the archive, stgr aber just fixed it roughly two hours ago | 06:44 |
| diwic | ok, thanks | 06:45 |
| dholbach | good morning | 06:51 |
| mvo | hey Unit193 - its waiting in approval queue :) | 07:02 |
| mvo | dholbach: good morning | 07:02 |
| mvo | Unit193: thanks again for your patience | 07:03 |
| Unit193 | mvo: Sweet! Thanks a ton for fixing before trusty. :D | 07:03 |
| dholbach | hey mvo | 07:06 |
| mvo | Unit193: your welcome | 07:10 |
| dholbach | hum..... | 07:20 |
| dholbach | I have upstart-dbus-bridge.2186.pid and upstart-file-bridge.2186.pid in my home directory | 07:20 |
| dholbach | did anyone else dist-upgrade and reboot today who can confirm this? | 07:20 |
| sarnold | dholbach: moment, I saw that in a bugreport earlier.. | 07:20 |
| dholbach | sarnold, you are unstoppable | 07:21 |
| sarnold | dholbach: hehe, I hope not, it's past my bed time :) | 07:22 |
| dholbach | and ~/Testing as well | 07:22 |
| sarnold | dholbach: ugh, sorry, bad news on this one, the report today is kind of all over the place, and the bots dup'd it to an ancient bug that doesn't feel appropriate: https://bugs.launchpad.net/ubuntu/+source/lxpanel/+bug/1302254 | 07:23 |
| ubottu | Launchpad bug 1106945 in lxpanel (Ubuntu) "duplicate for #1302254 lxpanel crashed with SIGSEGV in menu_cache_create()" [Medium,Confirmed] | 07:24 |
| dholbach | jodh, ^ do you have any idea why this might be? | 07:25 |
| torkel | dholbach: they disappeared (again) after the systemd breakage was fixed | 07:25 |
| torkel | new packages in the archive ~10 minutes ago | 07:26 |
| sarnold | ah! | 07:26 |
| dholbach | ah, brilliant | 07:28 |
| dholbach | thanks torkel | 07:28 |
| dholbach | let me try that | 07:28 |
| dholbach | maybe I'll get sound back again as a bonus ;-) | 07:28 |
| jodh | dholbach: yes - XDG_RUNTIME_DIR is unset. | 07:28 |
| jodh | dholbach: logind breakage? | 07:28 |
| dholbach | I don't know what it is - I'll try an upgrade an brb | 07:29 |
| sarnold | jodh: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1302264 | 07:31 |
| ubottu | Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released] | 07:31 |
| pitti | jibel: ah, thanks; so again the "try again" clickery exercise? | 07:34 |
| pitti | good morning | 07:34 |
| dholbach | sarnold, jodh: thanks that solved the issue for me! | 07:35 |
| jibel | pitti, yes, I clicked $world-ppc64el | 07:38 |
| diwic | dholbach, and brought the sound back too | 07:38 |
| dholbach | diwic, it did :) | 07:38 |
| tsdgeos | guys any idea why on login i would have deja-dup-monitor using 6GB of my memory? | 08:31 |
| seb128 | tsdgeos, bug? | 08:34 |
| tsdgeos | seb128: as a devel myself i would hate to get a bug saying "i booted up and deja-dup was using 6gb" | 08:35 |
| tsdgeos | i mean it's non-reproduceable (probably) and doesn't give much info | 08:35 |
| infinity | I'd hate it more if it wasn't reported. :P | 08:35 |
| seb128 | tsdgeos, use ubuntu-bug deja-dup, that might provide some info | 08:35 |
| seb128 | tsdgeos, you are not the only one, somebody mentioned issues earlier on #ubuntu-desktop | 08:36 |
| seb128 | tsdgeos, mterry is the maintainer, but he's probably still sleeping | 08:36 |
| tsdgeos | ok | 08:37 |
| === psivaa_ is now known as psivaa | ||
| tsdgeos | guys, any idea of what's wrong here? | 09:27 |
| tsdgeos | http://paste.ubuntu.com/7202446/ | 09:27 |
| tsdgeos | 2.8.95~2430-0ubuntu5 is not >= 2.8.0-0ubuntu26 ? | 09:28 |
| seb128 | tsdgeos, sudo apt-get install apparmor-easyprof-ubuntu apparmor | 09:34 |
| seb128 | tsdgeos, what does that say/do? | 09:34 |
| tsdgeos | http://paste.ubuntu.com/7202470/ | 09:35 |
| jjohansen | tsdgeos: try and apt-get update first, apparmor-easyprof 1.1.14 is the current version in the archive | 09:37 |
| jjohansen | your apt-get install is trying to install 1.1.13 | 09:37 |
| tsdgeos | jjohansen: i'm updated, maybe my mirror is behind | 09:38 |
| jjohansen | tsdgeos: okay that is possible, the new easyprof landed 18 min ago | 09:38 |
| jjohansen | or at least that is what lp says | 09:39 |
| seb128 | tsdgeos, right, the issue should resolve itself once the new apparmor-easyprof-ubuntu is available, or you can get it from https://launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu | 09:42 |
| === doko_ is now known as doko | ||
| cjwatson | darkxst: hmm, I would have expected this to be handled by the fact that we install the task, so gnome-control-center and mcp-account-manager-goa ought to be marked for install before apt gets round to trying to resolve broken dependencies, which ought to mean that it doesn't need to try the first alternative because the second is already there | 10:17 |
| cjwatson | darkxst: that's how it's meant to work, anyway. if that's not working, somebody probably needs to fiddle with pkgsel.postinst on the fly in the installer to run apt-get with -o Debug::pkgProblemResolver=true so that we can see why it's taking that decision | 10:17 |
| === vibhav is now known as Guest49486 | ||
| infinity | cjwatson: Except that his log clearly shows it installing the metapackage, not the task. | 10:22 |
| infinity | Commandline: apt-get install ubuntu-gnome-desktop | 10:22 |
| infinity | cjwatson: Which would explain why it works for his livefs (task-based) but not d-i. | 10:23 |
| cjwatson | infinity,darkxst: oh, so this just comes down to Jackson's tasksel merge, then | 10:31 |
| cjwatson | (probably) | 10:32 |
| cjwatson | let me sort that out | 10:32 |
| infinity | caribou: Err, tasksel? | 10:32 |
| infinity | cjwatson: ^ | 10:32 |
| * infinity assumes you mean something that's changed more recently than raring. | 10:33 | |
| cjwatson | yeah, so that tasksel is able to install ubuntu-gnome tasks | 10:33 |
| caribou | infinity: ? | 10:33 |
| infinity | caribou: misfire. | 10:33 |
| caribou | infinity: thought so | 10:33 |
| cjwatson | I really do mean tasksel, it never got properly mangled for ubuntu-gnome | 10:33 |
| cjwatson | so something is probably falling back to metapackages as a result | 10:34 |
| infinity | cjwatson: Fair enough. So, I guess this has always been broken like this, but it's just now biting them? Makes some sense. | 10:34 |
| infinity | With all the new control-centre splitting madness. | 10:34 |
| cjwatson | I think so. I'm not too sure *how* it's falling back to metapackages | 10:34 |
| infinity | I guess just some random /xubuntu/ubuntu-gnome/ cargo-cult would DTRT? | 10:36 |
| infinity | Not entirely sure how tasksel would work at all for ubuntu-gnome in its current state. | 10:37 |
| infinity | Not without a pkgsel preseed. | 10:37 |
| cjwatson | And yet. | 10:38 |
| cjwatson | oh, it's not a real d-i log, it's somebody selecting it a bit more manually, I think | 10:40 |
| infinity | Like, perhaps, pkgsel. | 10:41 |
| infinity | The lack of d-i syslog makes it a mystery. | 10:41 |
| cjwatson | Maybe in pkgsel's aptitude mode. | 10:42 |
| cjwatson | Shrug. | 10:42 |
| infinity | cjwatson: You know what would be nice? If metapckages could be tasks. ie: instead of ubuntu-gnome-desktop depending on 300 packages, if it just depended on task:ubuntu-gnome-desktop | 10:48 |
| infinity | cjwatson: Though, I suppose that might screw up your point release hacks. :P | 10:49 |
| cjwatson | Yeah, it's all a mess ... | 10:49 |
| === MacSlow is now known as MacSlow|lunch | ||
| seb128 | pete-woods, hey, why did you mark bug #1296715 invalid for the hud? | 11:40 |
| ubottu | bug 1296715 in indicator-appmenu (Ubuntu) "Menu items are greyed out in Libreoffice menu." [High,Confirmed] https://launchpad.net/bugs/1296715 | 11:40 |
| pete-woods | seb128: I thought it'd been logged against the wrong package? | 11:41 |
| seb128 | pete-woods, I don't know what's the right package, the user says it happens to both the unity menus and the hud | 11:41 |
| seb128 | pete-woods, but I guess fixing the problem for the appmenu might fix the hud as well? | 11:42 |
| seb128 | tedg, hey, do you think you could have a look to ^ | 11:42 |
| pete-woods | seb128: sure, it'd fix the HUD problem too | 11:42 |
| seb128 | k | 11:42 |
| seb128 | pete-woods, thanks | 11:42 |
| seb128 | do you know who is maintaining indicator-appmenu? | 11:43 |
| seb128 | is that ted? | 11:43 |
| pete-woods | seb128: it's certainly not me, but sure, ted would be the right person to ask | 11:43 |
| seb128 | k | 11:43 |
| xnox | Chipaca: sergiusens: jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1302516 | 11:49 |
| ubottu | Launchpad bug 1302516 in upstart (Ubuntu) "upstart-dbus-session-bridge conflicts in stopping certain jobs" [Undecided,New] | 11:49 |
| xnox | Chipaca: sergiusens: jodh: see the comments on the bug, if one does $ stop upstart-dbus-session-bridge, one can stop any job e.g. usensord and it does stop. | 11:49 |
| xnox | i'm not sure if something is connected/listening on upstart and starts up the jobs, or if the dbus-bridge is rogue. | 11:51 |
| mdeslaur | @pilot in | 11:53 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur | ||
| sergiusens | xnox: I don't see the relationship to be honest; but I don't know the innards of the dbus-bridge either | 11:54 |
| xnox | sergiusens: there might be a negative feedback loop.... upstart events are emitted on the dbus, then dbus bridge feeds them back into upstart..... and maybe just maybe that causes havoc =) | 11:55 |
| xnox | sergiusens: or there is somebody noticing that usensord goes away and sends "start usensord" to upstart. | 11:56 |
| xnox | sergiusens: is it a dbus activated service at all? and does something tries to manage it on top of upstart? e.g. unity/life-cycle stuff?! | 11:56 |
| sergiusens | xnox: no dbus activation; the only user of usensord is platform api but that integration has been stuck in a silo forever | 11:57 |
| sergiusens | that said, I could make it dbus activated instead of started through upstart (for usensord), not sure about the others that have symptons and this would just be a workaround | 11:58 |
| ogra_ | usensord runs at a low enough level that unity wont relate to it at all | 11:58 |
| ogra_ | (at least not wrt upstart handling) | 11:58 |
| xnox | sergiusens: nah, no need. it does expose a tricky bug. I'll chat with jodh about it, when he is back from lunch. | 11:59 |
| ogra_ | sergiusens, thats pointless, we need it running constantly anyway for all the sensors | 11:59 |
| ogra_ | (once it supports all of them :P ) | 11:59 |
| xnox | sergiusens: but if you do want to stop unstoppable jobs, stop the two dbus bridges first, for now. | 11:59 |
| sergiusens | ogra_: yeah; it is; as on first activation it would just be there forever | 11:59 |
| ogra_ | right, then we can as well leave that to upstart | 12:00 |
| ogra_ | and not add extra saturation the system dbus for it | 12:00 |
| sergiusens | xnox: ok; Chipaca will find more use of that; I actually don't need to stop anything; he used me to make an example of :-P | 12:00 |
| ogra_ | *of the | 12:00 |
| sergiusens | ogra_: agreed; there's a couple more I'd actually like to move to upstart instead of dbus activation; the first one that comes to mind is telepathy-ofono | 12:01 |
| ogra_ | right | 12:02 |
| ogra_ | for all stuff thats long running we should just use upstart | 12:02 |
| Chipaca | xnox: sergiusens: Hi :) | 12:04 |
| Chipaca | right now if you apt-get install ubuntu-push, you probably want to be able to stop it after tinkering with it a bit | 12:04 |
| Chipaca | just because it's there for testing | 12:04 |
| Chipaca | and ... well, it's rather cussed | 12:04 |
| Chipaca | :) | 12:04 |
| Chipaca | i mean: there's nothing depending on it, nothing calling into it, nothing at all that would make me think something is trying to restart it | 12:05 |
| Chipaca | maybe the upstart .config thing is bad? | 12:05 |
| Chipaca | i just copied usensord's one :) | 12:05 |
| ogra_ | sergiusens, ergh | 12:07 |
| ogra_ | stop on runlevel ? | 12:07 |
| ogra_ | thats a session job | 12:07 |
| ogra_ | you want to stop on session-end or some such | 12:07 |
| ogra_ | Chipaca, ^^ | 12:07 |
| Chipaca | ogra_: is that causing this breakage? | 12:08 |
| xnox | Chipaca: no, usensord is fine and ubuntu-push is fine. | 12:08 |
| ogra_ | we it is causing the daemon not to stop with the session as it should | 12:08 |
| xnox | Chipaca: nah, it simply means usensord is killed, rather than stopped on shutdown. | 12:08 |
| Chipaca | ogra_: will investigate further | 12:09 |
| * ogra_ still thinks we should use system events for session stuff | 12:09 | |
| xnox | ogra_: session force kills all jobs at the end, so one can even leave out "stop on" | 12:09 |
| ogra_ | *shouldnt | 12:09 |
| sergiusens | ogra_: might be a problem to fix, but it shouldn't restart on a stop request | 12:09 |
| ogra_ | xnox, right | 12:09 |
| ogra_ | i dont mind leaving stop on out | 12:09 |
| sergiusens | xnox: ah, nice; I'd rather have that; as in no stop stanza and let it do the right thing | 12:09 |
| xnox | ogra_: well, the runlevel event on session init appears as "sys:runlevel" thus "runlevel" is never emitted on the session init, thus "stop on runlevel" for a session job is equivalent to no "stop on" at all =) | 12:09 |
| ogra_ | but stop on runlevel seems just ugly | 12:09 |
| ogra_ | yeah | 12:10 |
| ogra_ | thats what i mean :) | 12:10 |
| xnox | i can fix that, but that has nothing to do with manually calling $ stop usersensord | 12:10 |
| xnox | cause that's not event triggered. | 12:10 |
| ogra_ | do we actually have a plain dbus event (not started/stopped/starting dbus) | 12:10 |
| Chipaca | maybe it shouldn't be 'start on dbus' either? | 12:10 |
| xnox | Chipaca: for now, $ stop upstart-dbus-sessin-brdige; stop upstart-dbus-system-bridge; and then stopping usernsord/ubuntu-push should work. | 12:10 |
| xnox | ogra_: yes we do, it's the session dbus | 12:11 |
| ogra_ | ok | 12:11 |
| xnox | Chipaca: start on dbus is correct, if your daemon exports itself on dbus and needs dbus running. | 12:11 |
| Chipaca | it'll helpfully wait around until dbus becomes available if it isn't :) | 12:11 |
| Chipaca | but, yeah, better to wait and start it after | 12:12 |
| ogra_ | 14:12:34 LOOP 200 | 12:12 |
| ogra_ | wohooo !!! | 12:12 |
| ogra_ | oops, ECHAN | 12:12 |
| * ogra_ goes to #ubuntu-ci-eng instead | 12:13 | |
| marga | Hi people. I've been debugging a trusty issue that has been driving me crazy. initramfs-tools hangs on image generation, calling /libx32/ld-linux-x32.so.2. I'm running kernel -20, and I've confirmed that on kernel -22 this does not happen. However, since my initramfs generation failed, I couldn't reboot into the new kernel. I've now modified /usr/bin/ldd to not call /libx32/ld-linux-x32.so.2, and with that I can upgrade, but I think that | 12:13 |
| marga | anybody in the same situation will also go crazy. | 12:13 |
| marga | Since this is a problem with dist-upgrading inside trusty... Is it worth reporting a bug about it? | 12:13 |
| ogra_ | sounds like a multiarch issue | 12:13 |
| xnox | ogra_: no, this is multilib issue, not multiarch. | 12:14 |
| marga | Yes, multilib. Happens because I have gcc-multilib installed | 12:14 |
| ogra_ | well, some multi* issue :) | 12:14 |
| xnox | marga: yes, please still report it. And possibly assign it to infinity https://launchpad.net/~adconrad | 12:15 |
| ogra_ | you definitely dont want update-initramfs to process any foreign arch stuff | 12:15 |
| xnox | marga: it may have been fixed, but if it's transient maybe we'll need to do something such that this doesn't happen again. | 12:15 |
| xnox | ogra_: yes you do. | 12:15 |
| === davidcalle_ is now known as davidcalle | ||
| ogra_ | xnox, huh ? what for ? | 12:16 |
| xnox | ogra_: our user-space is multilib, thus it needs to work =) | 12:16 |
| xnox | ogra_: and we have x32 enabled on our stack. | 12:16 |
| ogra_ | but it is pointless to have any non native stuff in your initrd | 12:17 |
| * ogra_ doesnt see a use case for that | 12:17 | |
| xnox | ogra_: the point is that our linker must work, and during initramfs generation we call into linker and ask linker to resolve paths to libraries needed for binaries to generate a full initramfs. And it looks like, marga is reporting that linker got broken and was not resolving libraries. | 12:18 |
| xnox | ogra_: a broken linker is bad, however you look at it =) | 12:18 |
| ogra_ | sure, i know there are hacks in update-initramfs or mkinitrd for that | 12:18 |
| ogra_ | thought only for amr stuff iirc ...to work around hf vs el | 12:18 |
| marga | actually, this was hanging on a copy_exec on a shell script | 12:19 |
| ogra_ | *arm | 12:19 |
| ogra_ | yes | 12:19 |
| marga | Which is likely a bug as well. | 12:19 |
| xnox | ogra_: it's not hacks, but the point is that /usr/bin/ldd should be operational no-matter what for native arch. with or without extra packages, foreign or multlib arches are enabled. | 12:19 |
| ogra_ | copy_exec is what uses ldd to determine reverse deps of libs for a binary | 12:19 |
| marga | But the thing was ld64 was failing, because it was a shell script, and then ldd called ld32 | 12:19 |
| ogra_ | xnox, but you dont want two linkers in the initrd | 12:19 |
| xnox | ogra_: and above it shows that it failed. | 12:20 |
| xnox | ogra_: we don't have two linkers in the initrd. | 12:20 |
| ogra_ | right | 12:20 |
| ogra_ | but you would need an x86 one for x86 binaries, no ? | 12:20 |
| xnox | ogra_: a call to ldd failed, at critical operation, and it should not have. | 12:20 |
| xnox | (during dist-upgrade / initramfs generation) | 12:20 |
| xnox | ogra_: and that's a bug. and has nothing to do with what our initramfs generation does. | 12:21 |
| xnox | (has, should have, doesn't have, etc.) | 12:21 |
| ogra_ | ok, i trust you :) | 12:22 |
| * ogra_ goes back to cursing cgmanager vs cgroup-lite issues and watching the 220th reboot of his phone | 12:23 | |
| xnox | Chipaca: sergiusens: jodh: the jobs are buggy! | 12:23 |
| xnox | Chipaca: sergiusens: jodh: "start on dbus" is start on any system/session dbus event. | 12:23 |
| ogra_ | heh | 12:23 |
| xnox | Chipaca: sergiusens: jodh: "start on started dbus" is start after session/system dbus are available | 12:23 |
| xnox | Chipaca: sergiusens: i'll make merge proposals to fix thsi. | 12:23 |
| Chipaca | xnox: ah! excellent, thanks | 12:24 |
| xnox | Chipaca: where is ubuntu-push code? | 12:24 |
| Chipaca | pedronis: we might have another one-liner fix in today's trunk build, then | 12:24 |
| Chipaca | xnox: i'm getting thing ready to go into a silo; want me to sneak this in too? | 12:24 |
| xnox | Chipaca: well, let me make the merge proposal which project/branch do you use? | 12:25 |
| Chipaca | xnox: lp:ubuntu-push/automatic | 12:25 |
| Chipaca | xnox: branch from there, mp into there; that goes into /trunk once everything is green in the auto tests | 12:25 |
| Chipaca | that is: that goes into a silo that gets needs to pass the on-the-phone test to get to /trunk | 12:26 |
| ogra_ | sergiusens, so with TheMuso uploading lxc-android-config it got out of sync with a bunch of pre-uploaded PPA versions of lxc-android-config ... if you want to release the telephony PPA to a silo please let me know in advance so i can get the package back in sync first | 12:26 |
| sergiusens | ogra_: yeah, we need it in sync | 12:26 |
| sergiusens | saw the upload last night | 12:26 |
| ogra_ | (i'll most likely do an upload of it soon for our desaster phone crashes ) | 12:27 |
| ogra_ | seems i found the issue ... waiting for the 250th reboot to happen | 12:27 |
| sergiusens | xnox: heh; the semantics are on a fine line there :-P | 12:28 |
| === MacSlow|lunch is now known as MacSlow | ||
| xnox | sergiusens: https://code.launchpad.net/~xnox/usensord/fix-upstart-job/+merge/214225 | 12:30 |
| sergiusens | xnox: let me get a silo for that, thanks | 12:30 |
| infinity | pitti: Are you going to self-accept those langpacks after you've had a poke at a random sampling to make sure they look sane? | 12:58 |
| infinity | pitti: Let me rephrase that as a request instead of an inquiry: Please self-accept after you've randomly sampled a couple for sanity. :P | 12:59 |
| pitti | infinity: oh, they are stuck in -proposed? yeah, they aren't meant to | 12:59 |
| pitti | infinity: will do that (sampling + accept) | 13:00 |
| pitti | thanks for the poke | 13:00 |
| seb128 | infinity, pitti: let me check the french ones | 13:00 |
| pitti | looks good enough to me, but sure, let's wait for seb128 | 13:01 |
| xnox | seb128: damn, the one time we sneak-in en into fr, and fr into en language packs and seb128 notices =) | 13:01 |
| seb128 | lol | 13:01 |
| seb128 | xnox, don't worry, I'm not new to this game, pitti already tried to screw french by pretending that they were more german speakers in the world and that de should be ranked before french :p | 13:02 |
| xnox | =) | 13:04 |
| xnox | seb128: yeah, and mvo is back so pitti has extra mates to gang up with =) | 13:04 |
| seb128 | indeed | 13:04 |
| seb128 | pitti, look fine to me, desktop_kubuntu-notification-helper.mo got added to language-pack-fr, is that the right place for kde things? (also it includes ubuntuone-client.mo, which is deprecated) | 13:05 |
| seb128 | but those are minor details | 13:06 |
| pitti | seb128: yes, it is; apachelogger will be happy :) | 13:06 |
| pitti | (I think it was apachelogger, anyway) | 13:06 |
| pitti | seb128: we don't have -kde langpacks any more, just the tiny kubuntu delta in the main pacakges | 13:06 |
| pitti | seb128: thanks, accepting | 13:06 |
| seb128 | pitti, ok, that makes sense | 13:06 |
| seb128 | yw! | 13:06 |
| tedg | seb128, I'll look at the bug, but usually if it's appmenu and HUD it's something in the app. | 13:07 |
| seb128 | tedg, Sweetsha1k is going to be happy! | 13:07 |
| seb128 | tedg, thanks | 13:08 |
| xnox | Chipaca: https://code.launchpad.net/~xnox/ubuntu-push/fix-upstart/+merge/214226 | 13:09 |
| tedg | Uhg, and it looks like the apport hook is broken :-( | 13:09 |
| gQuigs | I believe U1 was the last QT4 app on the desktop image.. does that mean qt-at-spi (qt4 accessibility), sni-qt (indicator support), and libqt4-sql-sqlite can be removed from the image too? | 13:11 |
| gQuigs | would save another 30 M (uncompressed) | 13:12 |
| xnox | well we still need to sort out appmenu thing, for which a packaging solution was worked out. | 13:12 |
| xnox | and then all of above, i think, could go. | 13:12 |
| xnox | unless we do want qt4 a11y installed, such that when user installs with a11y enabled those persist and are in use when later user installed 3rd party apps, e.g. skype. | 13:13 |
| xnox | i'm not sure how we handled a11y across all toolkits. | 13:13 |
| gQuigs | xnox: hmm.. skype would be the big one there.. let me see.. | 13:14 |
| gQuigs | xnox: skype needs the i386 version of everything anyway.. so it's not helpful in that case at least | 13:21 |
| xnox | gQuigs: true. | 13:21 |
| === _salem is now known as salem_ | ||
| jtaylor | fun gdebi is broken :( | 13:39 |
| jtaylor | xnox: http://paste.ubuntu.com/7203304/ | 13:40 |
| jtaylor | II'm pretty sure it worked before the last update | 13:40 |
| jtaylor | oh thats barry change | 13:40 |
| jtaylor | bug 1301422, probably related | 13:41 |
| ubottu | bug 1301422 in gdebi (Ubuntu) ""Could not open ...deb. The package might be corrupted or you are not allowed to open the file. Check the permissions of the file" with latest 0.9.5 " [High,Confirmed] https://launchpad.net/bugs/1301422 | 13:41 |
| Chipaca | is it a known issue that unity goes loopy when changing the display's resolution? | 13:42 |
| xnox | jtaylor: is this gtk, kde, or cli? | 13:42 |
| barry | dang | 13:42 |
| jtaylor | cli | 13:42 |
| xnox | jtaylor: and you are just launching it without any command, or with *.deb as an arg? | 13:42 |
| jtaylor | I'm using it as a pbuilder dependency resolver | 13:42 |
| jtaylor | let me check what it actually runs | 13:42 |
| jtaylor | /usr/bin/gdebi --quiet --apt-line debian/control | 13:43 |
| barry | jtaylor: any .deb in particular? | 13:44 |
| jtaylor | probably any deb, just tried openblas | 13:44 |
| jtaylor | but fftw3, so probably any | 13:45 |
| jtaylor | *too | 13:45 |
| barry | i see it | 13:45 |
| barry | that *should* be shallow | 13:46 |
| barry | hang on | 13:46 |
| marga | infinity, can you take a look at https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605 ? | 13:50 |
| ubottu | Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,New] | 13:50 |
| marga | I would assign it, but launchpad doesn't let me | 13:50 |
| pitti | ev: I sent a reply about your "tag runners for dep8" yesterday; I guess you are busy, but if you think that a coarser "run on any vs. all platforms" is sufficient, that's certainly much easier to maintain | 13:59 |
| pitti | but less explicit | 13:59 |
| barry | jtaylor, xnox branch pushed. if mvo is around, maybe he can review/push to debian, otherwise i can do that. https://code.launchpad.net/~barry/gdebi/lp1301422/+merge/214257 | 14:03 |
| zyga | mvo: hey, what are you going to work on? | 14:03 |
| brendand | mvo, i want to know too :) | 14:04 |
| barry | the only thing mvo *can* work on... awesomeness :) | 14:04 |
| jtaylor | univeral_newlines, never know of that flag | 14:04 |
| mvo | barry: looks good, thanks | 14:04 |
| jtaylor | it causes return as unicode? | 14:04 |
| jtaylor | in which encoding? | 14:04 |
| mvo | zyga, brendand: bugfixing for the release right now :) later click&systemimage I hear | 14:05 |
| barry | jtaylor: https://docs.python.org/3/library/subprocess.html#frequently-used-arguments | 14:05 |
| barry | locale.getpreferredencoding(False) | 14:05 |
| barry | which usually means utf-8 | 14:05 |
| barry | and it's a classic "porting to python 3" addition. sorry i missed that originally | 14:05 |
| xnox | jtaylor: universal_newlines returns str, instead of bytes. In python2 makes no difference, in python3 - big difference =) | 14:06 |
| zyga | mvo: nice | 14:06 |
| xnox | jtaylor: that's how i understood the flag. | 14:06 |
| zyga | mvo: I'm really glad to see you here again :-) | 14:06 |
| jtaylor | interesting | 14:06 |
| barry | mvo: will you merge and upload? | 14:06 |
| xnox | jtaylor: cause python2 casts bytes to string and string to bytes interchangeably, and python3 does not. | 14:06 |
| jtaylor | yes I know that, but didn't know that flag | 14:07 |
| jtaylor | I always added .decode(...) | 14:07 |
| barry | xnox: well, in py2, if you're lucky :) | 14:07 |
| xnox | barry: quite! =) | 14:07 |
| mvo | barry: sure! | 14:07 |
| barry | yep. i think universal_newlines is safer than .decode() | 14:07 |
| mvo | zyga: yeah, I'm very excited as well :) | 14:07 |
| barry | mvo: thanks! | 14:07 |
| xnox | jtaylor: well the flag was added because - hey most of the things that are Popened actually print text, and text is processed, rather than binary streams. | 14:07 |
| brendand | mvo, the 'software install and updates' realm :) | 14:08 |
| mvo | brendand: yeah :) | 14:08 |
| jtaylor | which version of python has this flag? | 14:08 |
| xnox | jtaylor: universal_newlines is better as it's explicit and works in both python2 and python3 and does the right thing. | 14:08 |
| jtaylor | I really wish pythons docstrings were as good as numps ... | 14:08 |
| pitti | shadeslayer_: I responded to https://code.launchpad.net/~rohangarg/apport/fix-for-1282713/+merge/213492 with a proposed fix that hopefully works (and is very simple) | 14:08 |
| dannf | hallyn: i can launch a cloud instance and install qemu-user-static there. what are you looking to see tested, binfmt stuff? | 14:10 |
| jtaylor | seems 2.6 already has it, good so it can be sued upstream :) | 14:11 |
| hallyn | dannf: mostly i wanted to make sure that installing it on an arm and an arm64 box do not brick the box | 14:11 |
| hallyn | dannf: i don't think they will, the packages *look* good... | 14:11 |
| dannf | hallyn: ah. sure, i can test that | 14:11 |
| mvo | barry: uploaded | 14:13 |
| barry | mvo: awesome, thanks. i'll watch debian and sync it over | 14:14 |
| hallyn | Daviey: i'm open to counter arguments... and i dont *foresee* this happening again since this was due to the switch from qemu-kvm to qemu source | 14:15 |
| hallyn | i don't *like* doing this tbh | 14:15 |
| pitti | shadeslayer_: ah, so os._exit() plus the setdestroyonexit() hack both together fixes the crash AND avoids the irritating "can't launch web browser" error? | 14:16 |
| mvo | barry: great, thank you | 14:16 |
| shadeslayer_ | pitti: correct | 14:16 |
| pitti | shadeslayer_: *phew*, awesome! | 14:17 |
| shadeslayer_ | yeah :) | 14:17 |
| pitti | shadeslayer_: sorry if I caused trouble, but I hate introducing regressions knowingly | 14:17 |
| hallyn | zul: kirkland: ^ same with you :) (if you'd like to counter) i've never used rhel so have no idea how much of a benefit/pain it turns out to be | 14:17 |
| shadeslayer_ | pitti: np, I wanted it fixed too, this way we can fix 2 problems in one go :) | 14:17 |
| shadeslayer_ | but would be nice to get this fixed ASAP | 14:17 |
| === Sweetsha1k is now known as Sweetshark | ||
| cjwatson | jtaylor: universal_newlines dates back roughly forever; it's just that it used to be only really useful on non-Unix | 14:20 |
| hallyn | Daviey: kirkland: zul: well, i'll be pushing to trusty soon (really i already did last night :) so, | 14:20 |
| cjwatson | because it also handles \r and \r\n newline conventions | 14:20 |
| pitti | shadeslayer_: committed both; running tests now, and then releasing | 14:22 |
| === roadmr is now known as roadmr_afk | ||
| shadeslayer_ | pitti: \o/ | 14:22 |
| zul | hallyn: reading | 14:23 |
| zul | hallyn: im missing the context | 14:24 |
| xnox | ogra_: i received a txt message, and it was full message in the bubble, in the indicators, but when i clicked the bubble and opened it in the app no text is printed only date and time and no content. | 14:24 |
| xnox | is this a known bug? | 14:24 |
| hallyn | zul: bug #1294823 | 14:24 |
| ubottu | bug 1294823 in qemu (Ubuntu) "FFE: create a trusty machine type" [High,Triaged] https://launchpad.net/bugs/1294823 | 14:24 |
| hallyn | biam | 14:24 |
| ogra_ | xnox, i dont think so, file it against the messaging-app | 14:25 |
| zul | hallyn: im cool with it | 14:25 |
| ogra_ | davmor2, ^^known ? | 14:25 |
| davmor2 | xnox, ogra_: that's an old bug I've not seen for ages and was supposedly fixed let me run some tests | 14:27 |
| xnox | davmor2: this is a real txt, not faked up. | 14:27 |
| davmor2 | xnox: yes I send real texts to myself | 14:28 |
| ogra_ | xnox, do you suggest davmor2 only has fake friends sending him SMS ? | 14:28 |
| ogra_ | :) | 14:28 |
| xnox | davmor2: well, until now i've only used phonesim =)))) | 14:28 |
| hallyn | zul: ok. i'm a bit apprehensive, but it was the best solution to our *last* error :) | 14:28 |
| hallyn | sorry i'm getting snarky with myself | 14:29 |
| xnox | ogra_: davmor2: screenshots http://people.canonical.com/~xnox/sms-fail/ | 14:29 |
| davmor2 | xnox: you can send an SMS to yourself | 14:29 |
| xnox | davmor2: this message is comming from a numberless account, it's from the provider however so the originator is "3Alerts" | 14:30 |
| xnox | let me self send a message. | 14:30 |
| xnox | hm our keyboard has : and ; wrong way around =))) | 14:30 |
| xnox | davmor2: sending fresh one to myself works correctly, the 3Alerts one still doesn't print text in the app. | 14:31 |
| hallyn | all right then, dannf: ^ long as your boxes turn out all right i'll ask infinity to pull the qemu bck out of rejected :) | 14:31 |
| xnox | davmor2: indicator shows both correctly =( | 14:31 |
| xnox | .. | 14:31 |
| xnox | i wonder about making whatsapp client... it's jabber with phone as id and IMEI as login so it should just work... | 14:32 |
| davmor2 | xnox: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-152957.png and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153208.png | 14:32 |
| hallyn | now i guess i can push the libvirt one without the qemu one... | 14:32 |
| hallyn | so i'l do that | 14:32 |
| xnox | davmor2: can you open the app? | 14:33 |
| xnox | davmor2: that's the indicator (both) | 14:33 |
| dannf | hallyn: works fine for me on armhf/arm64 | 14:34 |
| hallyn | dannf: \o/ thanks | 14:34 |
| xnox | davmor2: also see that beginning is shown in: | 14:34 |
| xnox | http://people.canonical.com/~xnox/sms-fail/app-welcome.png | 14:34 |
| xnox | but in | 14:34 |
| xnox | http://people.canonical.com/~xnox/sms-fail/app.png | 14:34 |
| davmor2 | xnox: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153404.png | 14:34 |
| xnox | it's empty | 14:34 |
| pitti | shadeslayer_: 2.14.1 uploaded, now needs an ubuntu-release member to ack it from the queue | 14:34 |
| hallyn | infinity: could you pull the qemu 2.0 out of rejected? (stgraber put it there last night bc we had to wait on libvirt) | 14:34 |
| xnox | davmor2: any logs i can check? | 14:35 |
| hallyn | else i can just re-dput... | 14:35 |
| davmor2 | xnox: also http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153518.png | 14:36 |
| davmor2 | xnox: cyphermox and awe will be the guys to get in touch with I think | 14:36 |
| cyphermox | xnox: latest image? | 14:38 |
| xnox | cyphermox: 276 | 14:38 |
| xnox | cyphermox: from todayish | 14:38 |
| cyphermox | ok | 14:38 |
| cyphermox | looks cute. | 14:39 |
| xnox | cyphermox: my screenshots? =) thanks | 14:39 |
| cyphermox | yeah | 14:39 |
| xnox | cyphermox: i think it may have to do with the fact that it's a fake alpha sender id, rather than a real phone-number. | 14:39 |
| cyphermox | xnox: just to make sure, you don't have phonesim installed right now? | 14:39 |
| xnox | cyphermox: i'm not sure how to send those for real. | 14:39 |
| xnox | dpkg -l | grep phonesim => returns nothing | 14:40 |
| cyphermox | ok | 14:40 |
| cyphermox | because phonesim does break stuff majorly if you're not into testing stuff :) | 14:40 |
| xnox | cyphermox: this is my real phone =) | 14:41 |
| cyphermox | xnox: this goes beyond my knowledge of the sms situation right now; I can check if there was a landing of this stuff recently to explain the failure though, and then possibly who to blame :) | 14:41 |
| === Ursinha-afk is now known as Ursinha | ||
| cyphermox | xnox: were you running 275 before that? | 14:43 |
| xnox | cyphermox: well, it's a fresh flash but i didn't wipe data. | 14:44 |
| xnox | cyphermox: is there a way for me to preserve sms database somehow? | 14:44 |
| xnox | cyphermox: cause the issue is visible if i close and restart the messaging app. | 14:44 |
| cyphermox | right, but I'm trying to pinpoint where it could have started to go wrong | 14:45 |
| cyphermox | xnox: the sms database should always be preserved... | 14:45 |
| xnox | cyphermox: i believe this was the first text message i ever received =) | 14:45 |
| xnox | cyphermox: whilst on ubuntu touch =) | 14:45 |
| cyphermox | right | 14:45 |
| cyphermox | so I think awe_ is more likely to be able to figure it out than I am, I guess it's time to file a bug | 14:47 |
| cyphermox | I'll go put my personal sim back into my nexus 4 and try to get sent such a special sms | 14:47 |
| awe_ | what's the issue? | 14:48 |
| xnox | awe_: how can i dump/copy sms database | 14:48 |
| cyphermox | awe_: well, really, http://people.canonical.com/~xnox/sms-fail/ | 14:48 |
| xnox | awe_: http://people.canonical.com/~xnox/sms-fail/app-welcome.png see 3Alerts <From 3:..... | 14:48 |
| xnox | awe_: when i tap on it, i get http://people.canonical.com/~xnox/sms-fail/app.png | 14:49 |
| xnox | awe_: yet if i pull down indicator i can read the message http://people.canonical.com/~xnox/sms-fail/indicator.png | 14:49 |
| awe_ | seems like a messaging app bug to me | 14:49 |
| awe_ | ofono doesn't store any messages, that's done at the telepathy level | 14:50 |
| awe_ | so it's either a bug in tp-ofono, or the messaging app itself | 14:50 |
| awe_ | that said, i'm not sure if there's a db that holds the original contents of incoming text messages | 14:51 |
| awe_ | ( ie. they may just be decoded and stored ) | 14:51 |
| davmor2 | awe_: out of interest has anyone seen what happens if you send an SMS over 140 characters and do you know if network messages can be more than 140? | 14:52 |
| xnox | awe_: well, indicator and app access the same source of the message, right?! cause indicator showed it correctly. | 14:52 |
| awe_ | xnox, sure but they're two different processes doing the rendering | 14:53 |
| awe_ | and one apparently has a bug | 14:53 |
| awe_ | ;) | 14:53 |
| awe_ | and if I was a betting man, I'd put my money on the messaging app | 14:53 |
| awe_ | I would start with filing a messaging app bug, and let tiago/boiko triage and move if necessary | 14:53 |
| xnox | awe_: i'll file a bug. =) | 14:54 |
| cyphermox | davmor2: it seemed to work for me | 14:54 |
| ev | pitti: I'll have a look after this call. Thanks for raising it - it would've been buried | 14:54 |
| awe_ | davmor2, nope... I haven't specifically tested that. I'm also not sure if ofono does the automatic split of messages that are too large, or whether it's the responsibility of the messaging app | 14:55 |
| cyphermox | davmor2: theoretically you can send a bit more than 140 characters on one single network control message, and if it's much more the split is supposed to happen, yeah ;) | 14:55 |
| awe_ | davmor2, you can send more than 140 chars if the message is 7bit encoded | 14:55 |
| * awe_ isn't going to do the math in his head | 14:56 | |
| cyphermox | awe_: so you think we're not storing the sms outside the sim? | 14:56 |
| awe_ | davmor2, why do you ask? Have you seen something weird that needs explanation? | 14:56 |
| awe_ | cyphermox, we don't store any SMS messages on the SIM | 14:56 |
| cyphermox | awe_: right | 14:56 |
| awe_ | and yes | 14:56 |
| cyphermox | awe_: so there has to be a database that keeps them ;) | 14:57 |
| awe_ | they may be stored outside of the SIM by telepathy | 14:57 |
| cyphermox | right | 14:57 |
| awe_ | not necessarily a db | 14:57 |
| davmor2 | awe_, cyphermox: hence asking if the network messages can be more that the total number of characters available to a standard sms which then might explain the message not being handled correctly in the messaging app | 14:57 |
| awe_ | could be plain text | 14:57 |
| cyphermox | well, I'm saying db in the large sense. a text file can be a database | 14:57 |
| awe_ | davmor2, my guess it that the messaging app is getting screwed up by message content, not length | 14:57 |
| cyphermox | OH | 14:58 |
| cyphermox | yeah, wasn't it starting with a < ? | 14:58 |
| xnox | cyphermox: awe_ it's to do with special chars. | 14:59 |
| xnox | i've sent the message with special char and that does not work: <From 3: Your new ebill is now ready to view. For the full bill go to My3 online or on your mobile. For \ | 14:59 |
| xnox | a summary click on http://mobile.three.co.uk/sms04 > | 14:59 |
| awe_ | ;D | 14:59 |
| cyphermox | right :) | 14:59 |
| xnox | awe_: nevermind the \ and newline break. | 15:00 |
| cyphermox | some piece of the puzzle tries to evaluate that as some kind of xml | 15:00 |
| awe_ | ( or html ) | 15:00 |
| xnox | cyphermox: awe_: so shall i file a bug against messaging app? | 15:00 |
| awe_ | yes | 15:00 |
| cyphermox | xnox: yeah | 15:00 |
| awe_ | please | 15:00 |
| xnox | ack. | 15:00 |
| davmor2 | xnox, awe_, cyphermox: confirmed xnox just sent it to me I see it in the indicator and the notification but just get a date stamp in the messaging app | 15:00 |
| cyphermox | very cute | 15:01 |
| davmor2 | xnox: ping me the bug number and I can confirm it do you want me to add images? | 15:02 |
| mdeslaur | @pilot out | 15:02 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === jono is now known as Guest82898 | ||
| pitti | jamespage: the swift autopkgtest failure looks real (pointing out because you probably got a lot of jenkins fail/success spam recently, as the ppc64el boxes keep exploding) | 15:02 |
| jamespage | pitti, I'm looking at it now | 15:02 |
| jamespage | pitti, rings are being created with odd permissions and I'm not sure why - stops the proxy server from starting | 15:03 |
| xnox | awe_: cyphermox: bug #1302652 | 15:06 |
| ubottu | bug 1302652 in messaging-app (Ubuntu Trusty) "Fails to display special chars in the txt messages" [High,Confirmed] https://launchpad.net/bugs/1302652 | 15:06 |
| === Ursinha is now known as Ursinha-afk | ||
| xnox | awe_: cyphermox: please triage / assign as needed. | 15:06 |
| xnox | davmor2: bug 1302652 | 15:06 |
| xnox | davmor2: https://launchpad.net/bugs/1302652 | 15:06 |
| awe_ | xnox, that's outside of my domain. Please ping Tiago or bfiller | 15:07 |
| xnox | sabdfl: | 15:09 |
| bfiller | assigned to salem_ | 15:09 |
| xnox | sabdfl: do we have the next name? =) | 15:09 |
| xnox | 13 days left.... | 15:10 |
| === brendand_ is now known as brendand | ||
| pitti | smoser, infinity: seems wolfe-03 went AWOL? can't reach it with ssh after a reboot (had to reboot the lot as they were segfaulting again, third time in two days :/) | 15:11 |
| === Ursinha-afk is now known as Ursinha | ||
| === roadmr_afk is now known as roadmr | ||
| pitti | jibel: meh, seems they all got stuck now; WTH | 15:24 |
| dobey | xnox: why'd you break software-center for? | 15:33 |
| xnox | dobey: bug #? | 15:34 |
| xnox | dobey: i didn't break anything on purpose =) | 15:34 |
| dobey | xnox: i don't know if there's a bug # yet. i just noticed you "disabled the qt build" on ubuntu-sso-client | 15:34 |
| xnox | dobey: right, that shouldn't break software-center. Let me check it out here. | 15:35 |
| dobey | xnox: which means that there is no more UI | 15:35 |
| xnox | dobey: i was told software-center has it's own, cause it only depend on ubuntu-sso-client and not on ubuntu-sso-client-qt. | 15:35 |
| dobey | no, it doesn't have its own UI any more | 15:36 |
| xnox | dobey: what's ubuntu-sso used for in software-center? comments / U1 login? | 15:36 |
| bdmurray | seb128: would it make sense to fix bug 1291862 in gnome-control-center for Trusty too? | 15:36 |
| ubottu | bug 1291862 in OEM Priority Project precise "[soundnua]mic volume adjust bar is gray if you open sound-nua input tab earlier than plugging micphone" [Undecided,In progress] https://launchpad.net/bugs/1291862 | 15:36 |
| === bschaefer_ is now known as bschaefer | ||
| dobey | xnox: yes | 15:36 |
| seb128 | bdmurray, not sure, the GNOME remix guys were talking about updating g-c-c to a newer version and dropping more of the Ubuntu patches to it | 15:36 |
| xnox | dobey: it really needs to declare a dependency on ubuntu-sso-client-qt, if it in-fact uses it. As there is nothing else that's pulling that on desktop images anymore. | 15:36 |
| seb128 | bdmurray, check with them I guess, I'm not even sure it's going to apply to the new version | 15:37 |
| dobey | xnox: one of the packages declares a dep on -ui which is only provided by -qt i think | 15:37 |
| bdmurray | seb128: okay, I was just curious and won't let it block the SRU. | 15:37 |
| seb128 | bdmurray, we fixed it in unity-control-center, which is the same codebase as the g-c-c SRU | 15:37 |
| seb128 | bdmurray, thanks | 15:38 |
| xnox | dobey: i don't see such a dep. | 15:38 |
| dobey | xnox: anyway, there's nothing in ubuntu-sso-client that is specific to the file sync, so there's no reason its packages should have changed at all, really | 15:38 |
| xnox | dobey: found it. | 15:38 |
| xnox | dobey: it's pulling in qt4 on desktop images, which is not used anymore. | 15:39 |
| xnox | dobey: =)))) it's a massive debt on the images, which ideally i'd like to drop (~100MB) | 15:39 |
| dobey | xnox: it's used by ubuntu-sso-client | 15:39 |
| dobey | xnox: you're free to port it to qt5 of course | 15:39 |
| xnox | dobey: i thought we have online accounts for u1/sso, which is gtk UI =) | 15:39 |
| dobey | :) | 15:39 |
| dobey | no | 15:39 |
| xnox | dobey: what do you mean, no? | 15:39 |
| dobey | we have no online accounts plug-in for u1 on the desktop | 15:39 |
| xnox | i do =/ | 15:40 |
| dobey | then you've installed the phone packages and added on with the qml system-settings app | 15:40 |
| dobey | because there is no way you added one with the gtk+ control-center ui :) | 15:41 |
| xnox | dobey: well, i was thinking that our control-center should allow Xembeded protocol to embed e.g. qt plugins and python based plugins =) | 15:41 |
| dobey | xnox: well, i'm sure mardy will accept your patch for that too :) | 15:42 |
| xnox | dobey: indeed i'm failing to login in the software center. Let me resurrect sso-qt thing. | 15:42 |
| dobey | i guess oneconf uses sso too, but you also probably only get the login from within software-center as well | 15:43 |
| xnox | dobey: with or without -qt installed, clicking "Write your own review" I get a popup which "Failed to log in" | 15:45 |
| dobey | xnox: hmm | 15:46 |
| xnox | dobey: did we shutdown so many things, that ubuntu-sso-client is logging in into something u1ish instead of login.ubuntu.comish ? | 15:46 |
| dobey | xnox: maybe you already have an account in your keyring, but it's invalid? | 15:46 |
| xnox | dobey: let me try clearing those! | 15:46 |
| xnox | dobey: actually, let me boot a VM that would be easier to test. | 15:47 |
| dobey | :) | 15:47 |
| xnox | dobey: or maybe you should test it =))) instead of being all smart about this ;-) | 15:47 |
| xnox | dobey: i have no clue how oneconf or comments work in the software cneter :P | 15:47 |
| dobey | i don't know how oneconf works either | 15:48 |
| xnox | dobey: awesome =) together we'll fix everything =) | 15:48 |
| dobey | that's didrocks's baby | 15:48 |
| xnox | dobey: right, i need to resurect qt bit and respin desktop image, *sigh* | 15:52 |
| dobey | xnox: with -0ubuntu4 packages, software-center pops up the signup/login dialog correctly, when i don't have an existing login in keyring. | 15:52 |
| dobey | xnox: indeed | 15:52 |
| shadeslayer_ | Riddell: mind ack'ing apport | 15:52 |
| xnox | dobey: oh well qt4 removal will happen in Ubiqutious Unicorn =( | 15:52 |
| shadeslayer_ | Riddell: from the queue | 15:53 |
| Riddell | shadeslayer_: what's new? | 15:56 |
| xnox | dobey: ideally we'd be able to use the qml online account =( | 15:56 |
| shadeslayer_ | Riddell: fixes for apport-kde at the very least, pitti ^^ | 15:56 |
| xnox | dobey: uploading fix. | 15:56 |
| Riddell | shadeslayer_: accepted! | 15:57 |
| dobey | xnox: ideally the sso server would have standard oauth2 endpoints | 16:00 |
| xnox | dobey: what would that change? being able to use any stock oauth2 GUI client? what about teams, 2fa etc? | 16:01 |
| xnox | dobey: thanks a lot for spotting this bug though! | 16:01 |
| xnox | dobey: and we totally have python-gi-gtk implemenetation for auth, we had it ubiquity installer. I'll if I can port that to software-center for next cycle. | 16:02 |
| dobey | xnox: yes, 2fa would be handled on the web server | 16:04 |
| dobey | xnox: if we had oauth2, we wouldn't need to write any special plug-in code. just the simple provider files for uoa | 16:05 |
| rbasak | Is there a way I can specify a versioned relationship that describes "anything before this epoch"? Eg. Breaks/Replaces: foo (<< 2:~) or something? | 16:14 |
| rbasak | I guess that would work - is there any standard convention for describing this? | 16:14 |
| cjwatson | I would probably use "<< 2:0~" | 16:15 |
| rbasak | Great, thanks. | 16:16 |
| * rbasak does what cjwatson would do | 16:16 | |
| cjwatson | dpkg: warning: version '2:~' has bad syntax: version number does not start with a digit | 16:16 |
| rbasak | Ah OK. I was guessing :) | 16:16 |
| cjwatson | So you can't use that | 16:16 |
| cjwatson | 2:0~ isn't perfect (you can construct pathological things like "2:0~~1") but in practice it should be good enough | 16:17 |
| rbasak | << 2:0~~~~~~~~~~~~~~~~~~~~~~~~ :) | 16:17 |
| * hallyn looks around for infinity or slangasek | 16:18 | |
| bdmurray | Laney: thanks for digging into that not whoopsie-preferences bug. | 16:29 |
| Laney | bdmurray: np, it was weird and hurt my head | 16:30 |
| Laney | which was fun at first, then not fun any more | 16:30 |
| slangasek | hallyn: hi, what's up? | 16:34 |
| hallyn | slangasek: oh hi - would you mind pulling the qemu 2.0.0-rc1 out of rejected? (it was placed there lst night bc we were waiting on libvirt) | 16:35 |
| slangasek | hallyn: ok, will be a bit before I can get to it but yes | 16:41 |
| hallyn | slangasek: thanks | 16:41 |
| kirkland | hallyn: what were your questions about? | 16:42 |
| vlada | Not sure if this a material for devel channel, but I have to try. What could possibly prevent Firefox and Chrome from redrawing window content? It gets redrawn by window resize or minimize/maximize action. It's definitely just refreshing visually since app receives events, but is not showing me "reactions" on screen. | 16:42 |
| hallyn | kirkland: about whether introducing a (default) 'trusty' machine type in qemu could end up beign somethign we regret | 16:43 |
| kirkland | hallyn: hmm, what does that mean? | 16:43 |
| kirkland | hallyn: "machine type" | 16:43 |
| hallyn | kirkland: -M trusty akin to -M pc-1.0 | 16:44 |
| kirkland | hallyn: ah | 16:44 |
| hallyn | iti s an alias to the pc-i440-2.0 | 16:44 |
| kirkland | hallyn: so, why "trusty"? | 16:44 |
| hallyn | bc in U it'll alias to something different | 16:44 |
| kirkland | hallyn: yeah, I think of machine types as more of a hardware thing | 16:45 |
| hallyn | kirkland: but you'd be not quite right :) | 16:45 |
| hallyn | kirkland: the problem is pc-1.0 right now means different things whether you're on qemu-kvm or qemu | 16:45 |
| kirkland | hallyn: :-) | 16:45 |
| kirkland | hallyn: I'm very rarely quite right | 16:45 |
| hallyn | and so in trusty, we'll have ppl migrating from precise as well as saucy, | 16:45 |
| hallyn | both with pc-1.0 machine types, but meaning different things | 16:45 |
| hallyn | and qemu doesn't (to my surprise) adjust itself to the soruce machine, but just bails | 16:45 |
| === roadmr is now known as roadmr_afk | ||
| kirkland | -M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook] | 16:46 |
| kirkland | Set the emulated machine type. Default is SS-5. | 16:46 |
| hallyn | So the intent is, at 16.04, | 16:46 |
| hallyn | we should be able to migrate correctly from both 15.10 and 14.04 | 16:46 |
| kirkland | (that's from the manpage of qemu) | 16:46 |
| hallyn | bc pc-i440-2.0 in 15.10 will be different from in 14.04 | 16:46 |
| hallyn | kirkland: do 'kvm -M ?' to get list of machine types | 16:47 |
| kirkland | hallyn: k | 16:47 |
| hallyn | kirkland: sounds like the man page may warrant some updating :) | 16:48 |
| kirkland | hallyn: *definitely* | 16:48 |
| kirkland | hallyn: honestly, I don't think I have an intelligent opinion here; should we ask aliguori | 16:48 |
| hallyn | oh, perhaps | 16:48 |
| hallyn | i' not sure, but the idea may originally ahve come from rharper | 16:49 |
| hallyn | kirkland: in part i fear i may be just addressign a non-issue - it was an issue bco f the divergent qemu and qemu-kvm trees | 16:49 |
| hallyn | upstream *shoudl* never make pc-i440-2.0 in a later qemu have different defaults | 16:50 |
| kirkland | hallyn: yeah | 16:50 |
| hallyn | anyway that's enabled in the current qemu in trusty-proposed (well, rejected for now :) | 16:50 |
| hallyn | but if we think it's a bad idea i can pull it back out in a new upload | 16:50 |
| === roadmr_afk is now known as roadmr | ||
| hallyn | let's think on it over the weekend :) | 16:51 |
| hallyn | kirkland: (aliguori isn't on #qemu right now) | 16:51 |
| === bfiller is now known as bfiller_afk | ||
| kirkland | hallyn: I sent him an SMS | 16:53 |
| hallyn | :) | 16:54 |
| kirkland | hallyn: okay, aliguori says he's going to ping you later today | 17:52 |
| hallyn | kirkland: ok thanks | 18:07 |
| rharper | hallyn: ping me if you chat with aliguori | 18:13 |
| jdstrand | hallyn: not sure if you saw, but libvirt landed last night. thanks for being patient with me (we had been testing our stuff for like 4 days straight :) | 18:14 |
| hallyn | jdstrand: np! yeah i pushed the new one earlier this morning | 18:14 |
| hallyn | rharper: ok | 18:14 |
| jdstrand | cool | 18:14 |
| === hholtmann_ is now known as hholtmann | ||
| === bfiller_afk is now known as bfiller | ||
| === jackson is now known as Guest23530 | ||
| === Guest23530 is now known as Noskcaj_ | ||
| === roadmr is now known as roadmr_afk | ||
| YokoZar | What's the right way to depend on opencl these days? | 19:33 |
| YokoZar | Is it to depend on "ocl-icd-libopencl1 | opencl-icd" | 19:33 |
| === mnepton is now known as mneptok | ||
| bdmurray | infinity: ping about bug 1296386 | 19:40 |
| ubottu | bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386 | 19:40 |
| === roadmr_afk is now known as roadmr | ||
| AnAnt | pitti: LP #1302331 | 20:27 |
| ubottu | Launchpad bug 1302321 in systemd (Ubuntu) "duplicate for #1302331 Missing /lib/systemd/systemd-logind-launch (referred to by /usr/share/dbus-1/system-services/org.freedesktop.login1.service)" [Wishlist,Won't fix] https://launchpad.net/bugs/1302321 | 20:27 |
| AnAnt | hmmm, ubottu is mistaken, the bug is neither a wishlist nor a won't fix ! | 20:28 |
| Unit193 | I clicked the link, I see the same thing. Changed 3 hours ago. | 20:30 |
| AnAnt | Unit193: yes, I was mistaken. it was reporting for 1302321, I was looking at 1302331 | 20:31 |
| calc | I have a bug I'm not sure what package to report against, it might already be reported as well but I'm not sure, frequently on my system the unity hud shows through the screensaver | 20:57 |
| calc | any ideas of where I should report it? | 20:58 |
| Noskcaj_ | calc, Maybe search launchpad for a bug similar to what you have | 21:01 |
| calc | i see something similar that was fixed 2 years ago, but not a current open bug, so I suppose I'll reference that one in a new report for trusty | 21:04 |
| Noskcaj_ | ok | 21:05 |
| Noskcaj_ | Use ubuntu-bug to report it so more info is attached | 21:05 |
| === tkamppeter__ is now known as tkamppeter | ||
| === salem_ is now known as _salem | ||
| slangasek | pitti: fyi, infinity is rebooting wolfe, taking down the autopkgtest VMs, to check if this addresses the stability problems | 21:37 |
| slangasek | pitti: so if you see suddenly-failed jobs, that's why | 21:38 |
| brainwash | can anyone please prepare an abiword bug fix release and upload it? we got 3 pending patches, see https://bugs.launchpad.net/ubuntu/+source/abiword/+bugs?orderby=-id&start=0 | 22:24 |
| hallyn | slangasek: not in a hurry, don't mean to be pushy, but just making sure it didn't slip your mind - still planning on salvaging qemu 2.0 from the rejected queue today? | 23:39 |
| slangasek | hallyn: it's been a busy day ;) I just managed to pull down the sources now | 23:39 |
| slangasek | hallyn: how does this package compare to the last thing you uploaded to the ppa? | 23:40 |
| slangasek | hallyn: also, was just checking and it looks like libvirt should be safe to let through in advance of qemu, right? | 23:40 |
| hallyn | slangasek: yup, libvirt can go through first, | 23:42 |
| slangasek | ok, accepting | 23:42 |
| hallyn | the difference between last ppa upload and current one in queue is: | 23:42 |
| hallyn | 1. based on a different tarball (built from the upstream release tarball, removing the bioses), | 23:42 |
| hallyn | 2. moves qemu-system-aarch64 into qemu-system-arm | 23:42 |
| hallyn | that *shoudl* be the only difference (and i debdiffed a few times to look for mistakes) | 23:43 |
| slangasek | ok | 23:44 |
| slangasek | + - remove -enable-uname-release=2.6.32 | 23:47 |
| slangasek | hallyn: ^^ is that because we decided to not try to run this version on the emulated builders? | 23:47 |
| hallyn | slangasek: i think so. but that's already in the archiv ein 1.7 isn't it? | 23:51 |
| infinity | slangasek: We most definitely want to run it on the buildds. | 23:51 |
| slangasek | hallyn: if qemu-system-aarch64 is a dummy package, the Provides: should have been moved to qemu-system-arm; you're also missing a Breaks:/Replaces: from the new qemu-system-arm to the old qemu-system-aarch64 package | 23:51 |
| slangasek | hallyn: (that alone is reject-worthy, so I'll not be un-rejecting this version - but let me see if there's anything else that needs fixing before you reupload) | 23:52 |
| hallyn | slangasek: removing -enable-uname-release=2.6.32 was bc it's now done in a better way | 23:52 |
| slangasek | infinity: so does that mean this 2.6.32 change is a problem? | 23:52 |
| infinity | hallyn: It's now done in a better way for minimum kernel versions (ie: the aarch64 case), but that doesn't fix our buildd issue, I thought. | 23:52 |
| infinity | hallyn: You haz binaries with this change, so I can test? | 23:52 |
| hallyn | infinity: yup, in ppa:ubuntu-virt/candidate | 23:53 |
| slangasek | hallyn: the mail thread I remember said that we couldn't fix it the "better" way until we got rid of the buildd requirement | 23:53 |
| slangasek | hallyn: but that we could and should confine the 2.6.32 usage to x86 | 23:53 |
| slangasek | or x86/arm, or something | 23:53 |
| infinity | slangasek: To arm, pretty much, since that's all we care about for our weird usecase. | 23:54 |
| slangasek | infinity: I mean "the arm build on x86" | 23:54 |
| infinity | Sure. | 23:54 |
| infinity | Let me have a look at this current binary and see what it really does. | 23:54 |
| infinity | Oh, that would be easier if I had a machine with a hardy kernel. Hrm. | 23:55 |
| slangasek | check in the compost bin | 23:55 |
| xnox | lol | 23:55 |
| hallyn | slangasek: ok, provides and breaks/repalces fixed (hopefully the right way), | 23:56 |
| infinity | So, on my machine, this is reporting 3.13.0-19-generic, which leads me to believe it's the same old leak uname through thing. Though. Maybe the new min_kver way can be patched to just bump it up for ARM instead of forcing uname in rules. | 23:57 |
| infinity | Lemme look at the source here to see what they did for aarch64. | 23:57 |
| hallyn | ./linux-user/openrisc/syscall.h:25:#define UNAME_MINIMUM_RELEASE "2.6.32" | 23:58 |
| hallyn | ./linux-user/aarch64/syscall.h:9:#define UNAME_MINIMUM_RELEASE "3.8.0" | 23:58 |
| hallyn | all are set to 2.6.32 except aarch64 | 23:58 |
| infinity | linux-user/arm/syscall.h:#define UNAME_MINIMUM_RELEASE "2.6.32" | 23:58 |
| infinity | Ah-ha. | 23:58 |
| infinity | That should work for us, then. | 23:58 |
| infinity | \o/ | 23:58 |
| hallyn | but you're saying it is not working?? | 23:58 |
| slangasek | he's saying on his system, host kernel > 2.6.32 so is passed through | 23:59 |
| infinity | hallyn: No, no. I'm not saying it's not working, I'm saying it's hard to tell without an older kernel to test on. :P | 23:59 |
| infinity | hallyn: But I think this should be right. | 23:59 |
| hallyn | ah | 23:59 |
| slangasek | infinity: don't we have a uname faker somewhere? | 23:59 |
| infinity | And yay for upstream picking 2.6.32, since glibc 2.20 won't run on older. :P | 23:59 |
| hallyn | LD_PRELOAD :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
