[00:04] hallyn: *poke* [00:05] hallyn: The .so belongs in the -dev package, not the library package (re: cgmanager) === infinity_ is now known as infinity [00:19] hey infinity :) [00:21] doko: pitti sponsored that, not me [00:22] I don't even have access to the main component, haha [00:22] but I'm flattered that you think I'm a core dev :P [00:32] Logan_: Hai. [00:32] :) [00:35] Logan_: Or was that just a random hi without a followup? :) [00:37] infinity: oh, just a random hi :P [00:37] zul: Do we ever plan to make use of the "openstack-meta-packages" package from Debian that's been sitting in -proposed for 275 days, or should we remove it and blacklist it as not relevant to how we do openstacky things? [00:37] Logan_: Well, random hi to you too. [00:48] infinity: the .so does? then what is the point of the library package? [00:50] * hallyn goes to edumacate himself at the pkg guide [00:50] hallyn: The .so file is a symlink to the *actual* library, used by ld to resolve -lfoo to libfoo.so to libfoo.so.the.actual.object.with.real.code [00:51] So it's only interesting for development, which is why it goes in the development package :) [00:51] oh, right. [00:51] infinity: so can i re-use that package version since it was rejected? [00:52] hallyn: Yeahp. [00:52] RAOF: Thanks for laying the smack down while I smoked. [00:52] cool. thanks. now i do wonder if i could have kept the .a file in there and hav eit work... [00:52] * infinity needs to start recruiting policy sidekicks. [00:53] hallyn: Why did you remove the static lib? I didn't check the bug. [00:53] * RAOF has _asked_ whether ubuntu-archive needs more members :P [00:53] hallyn: Not that it's required to ship it or not, it's vaguely optional, but it's a nice option to offer in some cases. [00:53] infinity: we were confused as to why cgmanager wasn't showing in ldd for lxc. [00:54] infinity: i didn't notice at first that the .so wasn't in the pkg [00:54] RAOF: Didn't we do some training or other for you on some team or other at some point? [00:54] so i removed the .a file as i figured builds might prefer the static over dynamic lib if available [00:54] hallyn: Oh, right, so yeah, with no .so, it would link statically by default, cause that's all there is. [00:54] infinity: Yeah, enough to use the bits of archive-admin tooling necessary to do SRUs. [00:54] anway if it's all the same whether it is there or not, [00:54] then i'll put it back. [00:55] RAOF: Right, bring it up next week, and let's see about AA indoctrination. [00:55] RAOF: We do need new blood, but it's not something I like to advertise, cause then we get outside pressure to accept people who shouldn't be doing it. [00:55] (And yes, I made that statement publically just now on purpose) [00:55] :) [01:07] infinity: thanks, new version pushed. [01:07] hallyn: Ta. [01:07] infinity: I might be interested [01:08] Logan_: In? [01:08] AA [01:08] Logan_: You're a little on the shiny and new side for that, yet. [01:08] Logan_: Let's work on core-dev first. :P [01:08] okay :P [01:18] oh ffs. [01:18] bzr bd done did me wrong [01:21] UDD <3 [01:22] cjwatson, a debian user just filed a bug report about the issue we found and fixed in ubuntu regarding the out of order partition table entries causing a failure to update the kernel in parted. I had sent you a git bundle a while back with that and one other fix for loop labels. Do you think you could get around to applying it please? ;) [01:25] psusi: oh blast yeah, sorry, I'll take care of that tomorrow [01:25] cjwatson, cool cool... [01:27] or, I think I asked you about getting on the debian parted maintainer team and upload/git write access and you said to ask later ;) [01:27] then I could just push it myself [01:28] also, those partman patches I fixed up per your request are still waiting ;) [01:29] cjwatson: ++ macppc|ppc*) host_arch=ppc ;; [01:29] ++ ppc64*) host_arch=ppc64 ;; [01:29] cjwatson: What's wrong with this case statement? [01:31] psusi: well, those partman patches did require quite a bit of review ... but yeah, I need to get back to the next iterations of those [01:31] infinity: er, oops. in my defence I did test-build on ppc64el [01:32] cjwatson: Well, probably because of this: [01:32] +- ppc|ppc64|powerpc|powerpc64) [01:32] ++ ppc*|powerpc*) [01:32] + arch='ppc' [01:32] yeah, so I think it's just dead code [01:32] IOW, the ppc/ppc64 distinction doesn't appear to matter. [01:32] Still, the case is wrong. :P [01:32] I'll fix it [01:32] Ta. [01:34] Every time I see another one of those uname = target constructs, though, I'm both glad we run linux32 everywhere, and really annoyed that we have to. [01:41] cjwatson: You could have just reversed the order too. :) [01:41] cjwatson: (But that works, I don't think we'll ever actually see a ppcel kernel) [01:41] cjwatson: And, as pointed out, it's probably useless code ANYWAY. [01:43] Right [01:43] I was mostly just trying to line it up roughly with mplayer TBH :) [02:18] grumble. i had to look at that for at least 30 seconds before i saw the problem. [02:27] infinity: remove it and blacklist it [02:31] zul: Ta. [02:31] hallyn: ? [02:31] infinity: the patch you quoted above [02:33] hallyn: Ahh. [02:53] cjwatson, we seem to get a lot of crash bugs caused by people manually partitioning and not setting up an efi system partition.. think partman-efi should check for that and kick them back to the partitioner if they forgot? [02:54] I thought it had a check and warning for that already... [02:55] Template: partman-efi/no_efi [02:55] Type: boolean [02:55] # :sl5: [02:55] _Description: Go back to the menu and resume partitioning? [02:55] No EFI partition was found. [02:55] What triggers that template? [02:55] Ah. [02:56] Only on ia64. [02:56] \o/ [02:56] psusi: See check.d/efi, if you want to sort out a safe way to make that only trip when we need it, but always trip when we do. [03:03] infinity, isn't partman-efi only loaded on an efi system in the first place? [03:03] btw, how goes the util-linux slog? ;) [03:05] psusi: I'm not sure if there's anything smart enough to only load it in the right cases. Plus, see the comment in the code about Macs (yay, Macs, the most busted EFI implementation ever) maybe not needing the partition. [03:05] psusi: Then again, it might be a "who friggin' cares, it's 35MB, suck it up princess" situation there. [03:05] psusi: We unconditionally create a PReP partition on PPC, and not all machines need that, but I doubt anyone gives a crap. [03:10] infinity, I'm mostly just thinking of making sure that you have an efi system partition if you are going to install grub-efi [06:14] yesterday I've started to upgrade 13.10 to 14.04.. let me tell you it's quite an adrenalin rush.. the upgrade told me this morning that it failed.. it's now doing a roll-back.. I hope this machine still boots after all this ;) [06:16] I'll try to reboot now that it finished.. let's see [06:19] Good morning [06:19] infinity: postgresql SRUs> fine for me, no regression reports upstream either [06:20] bdmurray: I do see the symbols here: http://ddebs.ubuntu.com/pool/main/l/lightdm/ [06:20] bdmurray: maybe they got picked up over night and were just held by the freeze? [06:26] Laney, infinity: argh, thanks for fixing the pycxx bits [06:29] hmm. .now I can't tell in what state my os is.. it's partially 14.04, partially 13.10... [06:29] the kernel is 3.11, but some packages are upgraded :) [06:59] lfaraone: Howdy. Mind a PM? [07:10] thrusty repos left behind after upgrade rollback.. this can become interesting === maclin_ is now known as maclin [07:32] doko_: I filed bug 1298824, new libffi is causing havoc :/ [07:32] bug 1298824 in libffi (Ubuntu Trusty) "libffi 3.1~rc1 regression: crashes on i386; python3.4 crashed with SIGSEGV in g_callable_info_free_closure()" [Critical,Confirmed] https://launchpad.net/bugs/1298824 [07:41] doko_: I added two reproducers [07:41] doko_: is that something you can look into today, or should we upload a revert for now? [07:42] jibel: ^ FYI (all the failure messages from overnight); another fail of britney-adt :( [07:49] good morning [07:52] slangasek: I have a question for you in bug 1295521; thanks in advance! [07:52] bug 1295521 in systemd (Ubuntu) "Installing i386 and amd64 PAM stacks causes shutdown/logout/etc. to break" [Undecided,Confirmed] https://launchpad.net/bugs/1295521 [08:05] jibel: is it still possible to get some post-mortem why libffi wasn't held back? new g-i, pygobject, ffi, and others were all uploaded simulataneously due to teh unfreeze, which certainly didn't help to make matters any easier [08:06] pitti, yes, I'm looking into it [08:07] * zyga wonders if there's a way to put any patches into the release at this time [08:07] pure bufixes [08:07] zyga: Yep, same as always, upload away. [08:08] zyga: It just gets held for review, but bugfixes will slide in with no issues, unless they're obviously wrong. [08:08] infinity: ENOUPLOADRIGHTS, we'll release to debian and try to sync them over then [08:08] infinity: those are all short and well documented so we'll try [08:09] doko_: Dude, why are we uploading release candidate versions of new upstream libffi waaaay after feature freeze, and weeks before release? [09:00] was there a known bug with apport retracer on lp recently? [09:00] tjaalton: not known to me; is it stuck again? [09:00] pitti: I'm just going through bugs against the X packages, and see that even crashers with free drivers have useless stacktraces [09:01] this particular one is from mid-feb [09:02] tjaalton: I can look through the logs for messages like "this dbgsym is missing", if you toss me a bug number [09:02] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1278722 is a good example i think [09:02] Launchpad bug 1278722 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in CloseWellKnownConnections()" [Undecided,New] [09:04] doko_, infinity: I prepared and uploaded a revert, tested with python-cffi and python-gi; so it's ready for the release team to accept if/once we decide we want to do that [09:05] pitti: no problem - I was surprised to find a bug like this after so long though! [09:06] Yeah, that surprised me too. [09:06] AFAICT, that's been broken that way since that feature was added. [09:07] tjaalton: ah, too bad we can't catch X.org's assertion messages yet; but that bug still has a core dump, maybe one can pry it out from there [09:07] pitti: Oh, also, I was lazy and didn't write a test-case for multi-level doc symlinks, if you're feeling anal at some point and want to add one to pkgbinarymangler... [09:07] pitti: ah, ok [09:07] pitti: (I briefly considered it, saw the testsuite was in python, and lost motivation :P) [09:08] E: Ignore unavailable version '2:1.15.0-1ubuntu3' of package 'xorg-server' [09:08] and I see fresh bugs with proper traces, so let's just assume it's working now :) [09:08] tjaalton: ^ that was the error [09:08] heh, ok [09:08] tjaalton: so apparently the retracer got stuck for a bit (we had that due to some weird launchpadlib cache problems; worked around now) [09:08] right [09:08] tjaalton: sorry about that [09:08] tjaalton: so, fine to just invalidate those, as they are rather useless [09:08] no worries, hope the bug is fixed anyway, or someone has filed a dupe later [09:10] pitti: Do the autopkgtest machines run ntpd or anything that might jitter the clock? === zyga_ is now known as zyga-vaiop [09:11] pitti: I know qemu sucks and all, but I'm really irked that eglibc's testsuite seems to fairly often get such crap time out of those machines. :/ [09:11] infinity: checking; but they have a lot of VMs running in parallel, so they often get stuck in iowait and similar [09:11] infinity: I just retried eglibc, FTR [09:11] pitti: Thanks. [09:11] ntp 5256 0.0 0.0 43756 3128 ? Ss Mar25 0:21 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 118:124 [09:11] infinity: ^ [09:12] pitti: It mostly bugs me because I don't want to XFAIL a test that passes on real hardware, nor do I want to be holding up some other random person's package migration, so it seems a bit rock and hard place. [09:12] pitti: So, yeah, ntpd on a kvm host where the guests get their RTCs via the system clock of the host might not actually be the best idea. [09:12] we are fairly quick on the retry trigger for unstable tests :) [09:12] pitti: system jitters, and so do all the guests' fake RTCs. [09:13] infinity: I guess a cron'ed ntpdate wouldn't be much better, though ? [09:13] pitti: No, just a boot time ntpdate. The machines can't lose so many ticks that you need it re-jittering often, I hope? It's not an Amiga. [09:14] infinity: e. g. aldebaran has an uptime of 134 days ATM; I guess you can get quite some skew on loaded machines in that time? [09:15] pitti: In theory, yeah. *shrug* [09:16] pitti: A daily cronned ntpdate might be more pleasant, or not worrying about it and retrying tests (or not worrying about skew). Was more an observation than a demand for change. :) [09:16] ntpdate might actually be less destructive, not sure how the system interprets its changes. [09:17] Pretty dure ntpdate actually changes the date, which is entirely different from ntpd inserting and removing ticks. [09:17] Equally possible that my blaming ntpd is a red herring and it's just that qemu sucks under load. [09:19] infinity: multiple qemus in parallel aren't very reliable wrt. timing issues indeed; I often see failures when lots of stuff runs in parallel [09:20] infinity: after the recent eglibc upload I slightly decreased the number of parallel runners, let's hope it helps a bit [09:20] infinity: yearning for the new world where all this will be quite a bit more flexible [09:22] hi! i'm having GPG errors for ubuntu 14.04 official repositories on main server, i've been using 14.04 and until this very day everything it was a smooth sail, anyone else? [09:22] is this a know issue? [09:23] infinity: so xfailing this kind of error would certainly not hurt for autokpgtests (as this pretty much should be a rebuild and coarse smoketest only), but we certainly shouldn't xfail it for package builds [09:23] pitti: That particular failure might at least get harder to trip in 2.20... gettimeofday() was moved to the vDSO, which knock out a few dozen instructions. [09:24] pitti: Yeah, I think the real solution is for me to build a cut down test package and use that, which will also be more doable in 2.20 (or maybe 2.21) as we're sinking work into making the testsuite run out of tree. [09:24] infinity: ah, nice; until then, retry button it is :) [09:27] msx: I haven't seen that, maybe you are behind corrupting http proxy (most are) [09:28] zyga: hei! but this issue just arose earlier today... any idea on how to solve it? may be switching the repo server? [09:28] msx: without knowing what causes it (it's proably something on your network as I also use the same servers and dind't see any gpg issues) it's hard to say [09:29] zyga: btw, i have a 'transparent' connection, by transparent i mean the only proxies out there should be the ones from my isp (hate that stuff) [09:29] hmmm [09:29] msx: transparent proxies are known to misbehave [09:30] msx: try forcing some funny http headers to apt, to force those proxises to refresh, I had issues like that in corporate networks, google for apt http proxy isuses, there's plenty of people with workarounds [09:30] zyga: how do i reset the GPG and force the system to bring them back again? [09:30] msx: but essentially, the network setup is broken [09:30] msx: gpg is not broken, you need to re-download them through the proxy [09:30] It could just be bad timing. Have you tried "apt-get update" again? [09:30] zyga: okay, tnx a lot! [09:30] infinity: o/ [09:31] infinity: yes, a lot within these hours [09:31] msx: and this is not a support channel, sorry, try #ubuntu and google for this, plenty of good workarounds out there [09:31] zyga: ok! i decided to post here since i'm on 14.04 [09:31] msx: sure, no worries [09:31] msx: good luck :) [09:31] :D [09:49] zyga: FTR, there's an archive update in progress: #ubuntu+1 06:42:45 TJ- | msx: Archive update in progress; see http://ftp.ccc.uba.ar/pub/linux/ubuntu/ [09:50] zyga: tought you might be interested in knowing that :) [09:50] msx: So, pick another mirror? [09:50] infinity: can you believe that all the four mirrors I already check are in the same state? bless my luck :D [09:50] infinity: tnx anyways! [09:51] s/check/cheked/g [09:51] msx: archive.ubuntu.com is pretty much never in that state (though is pretty far away from you, sadly) [09:51] infinity: mmm, will give it a try, great [09:58] infinity: error persists using that repo, i keep looking for the error, thanks === doko_ is now known as doko [10:47] zyga: infinity: after more research it came out it's a bug in apt, issue solve, everything's here: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1263540/comments/7 [10:47] Launchpad bug 1263540 in apt (Ubuntu) "Apt-get reports NO_PUBKEY gpg error for keys that are present in trusted.gpg." [Undecided,Confirmed] [10:47] thanks for your help guys [11:02] cjwatson: You know how we keep getting into conversations with people every 7.5 days about when you want C/P/R/B and why? [11:02] cjwatson: A random googling earlier for I don't recall what led me to this table: https://wiki.debian.org/PackageTransition [11:02] cjwatson: Might be a handy thing to just toss at people instead of having the same 20-minute discussion every time. [11:05] Although, it could use some tidying up. 12 is definitely wrong. [11:07] infinity: good idea [11:38] statik: o/ :) [11:38] o/ [11:38] long time :) [11:39] yup :) [12:15] Riddell, is there a reason that calligra needs to be built with GCC 4.7? [12:15] doko: there was, krita wouldn't compile with 4.8 I think, not tested in recent times though [12:46] Riddell, builds with the default [12:46] Maintainer: Michael Vogt [12:46] Standards-Version: 3.7.3 [12:46] mvo: do you know this guy? ^^^ [12:54] doko: oh you tested it? thanks [12:55] Riddell, yes. amd64 only === msbrown_ is now known as msbrown === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ [13:36] Is anyone else seeing https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1281806 ? With the final beta release announcement, I'm concerned that this bug hasn't even been triaged. [13:36] Launchpad bug 1281806 in unity (Ubuntu) "Alt-Tab switcher regularly goes into "flicker loop of death" or just hangs" [Undecided,New] [13:37] I'm guessing unity is the wrong package, but I'm not sure what is. Should I reassign this to compiz? Something else? [13:39] I'm willing to try stuff to help debug this, but I'm not sure what would be helpful. [13:39] nturner_, try #ubuntu-desktop ... [13:39] nturner_, check with bregma but I don't think it's known, first time I see it mentioned, might be due to some specific local options [13:40] ogra_, ok [13:41] seb128, I'm seeing this on both systems I've been testing trusty on, different hardware install histories... [13:41] s/hardware/hardware,/ [13:42] nturner_, stock config, never touched ccsm or any compiz option? [13:44] I'm willing to reset to a stock compiz config (plus disabling Alt = HUG keybinding ;-) to test --- what dirs should I delete? ~/.compiz? Anything else? [13:44] er, s/HUG/HUD/ =) [13:44] try a guest login for a start [13:44] or create a new user [13:47] does my packaging change request here: https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1295723 make sense? [13:47] Launchpad bug 1295723 in mongodb (Ubuntu) "libv8-dev backport breaks some dependencies" [Undecided,New] [13:52] gQuigs: IMHO, technically there is no mongodb packaging bug there, although I understand why it would be useful to you for cloud archive backports. [13:53] gQuigs: except that we don't support doing what you're doing to the cloud archive in that way anyway. [13:53] gQuigs: I think the danger here is that we make the change, you rely on it, and then something upstream changes and breaks you in a way that we can't fix. [13:54] (since the libfoo-ver-dev thing isn't policy or even common) [13:56] Or that we get a future proliferation of bugs wanting the same thing in other packages, all to fix something in the cloud archive which is fundamentally wrong anyway. [13:56] The "right" way to control this is with apt pinning. Could you perhaps view this as a general solution for anybody who wants to install extra packages in such an unsupported combination? Ie. make the cloud archive low pin priority in general? [13:57] rbasak: this is the first I'm hearing that it's ok for the cloud archive to break things like this [13:57] gQuigs: in that case maybe I should get my assertion checked by others in my team [13:57] rbasak: there is no big warning on this page, https://wiki.ubuntu.com/ServerTeam/CloudArchive [13:57] gQuigs: my understanding is that you aren't expected to be able to install arbitrary other packages on a system where the cloud archive is enabled [13:58] (since it bumps versions of dependencies exactly how you're seeing) [13:58] Normally this isn't an issue, since installations running the cloud archive don't run anything else. [14:01] gQuigs: why is pinning the cloud archive not a suitable solution for you? === nturner__ is now known as nturner_ [14:16] pitti: ah, maybe === sil2100_ is now known as sil2100 === MacSlow|lunch is now known as MacSlow [14:54] hi guys, do I need to ping someone about a trusty bug-fix upload? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=landscape-c [14:54] or is it "automatic"? [14:56] tedg, apropos of our earlier convo this just came into existence: http://developer.ubuntu.com/apps/quality/ [14:56] IMO balloons is doing a good job of public writing on 'how we test ubuntu' :) , sure he'd be interested in your feedback [14:59] alesage, Yeah, seems like he's mostly dealing with apps. Which is fine, but we need it for the core as well. [15:00] tedg, what do you need / looking for? [15:00] balloons, we were just having an inspired chat about quality :) and our test plans [15:00] balloons, We were talking about something that pulled together how the different parts of TestPlans and MergeCheck lists work. Like vs. unit tests, etc. [15:01] bdmurray, you have a bot that detects if people have xorg-edgers ppa enabled and invalidates bug reports if they do. Do you think the logic could be included into the release-upgrader and abort with that indication? instead of failing with a generic message and users reporting bug. [15:01] bdmurray, I know it is a specific case but very frequent cause of failure [15:02] balloons, Perhaps a children's book, with illustrations, "The story of a line of code getting into Ubuntu" :-) [15:02] tedg, so funny, like that "I'm just a bill" schoolhouse rock cartoon [15:03] alesage, I was thinking more like the "Water Cycle" cartoons, but that's perhaps just because it's rainy here today :-) [15:03] tedg, did you see http://www.theorangenotebook.com/2014/03/a-simple-look-at-testing-within-ubuntu.html? [15:03] it was inspired by the "explain to me like I'm 5" [15:04] jibel: there is bug 1069133 that xnox was going to work on [15:04] bug 1069133 in ubuntu-release-upgrader (Ubuntu) "Get upgrade error 12.04 - 12.10 "Could not determine upgrade" - xorg from ppa" [Medium,Triaged] https://launchpad.net/bugs/1069133 [15:04] I don't think it mentions anything you don't know, but I'm guessing you want something like this that covers a bit more on the development side? [15:04] bdmurray, ok, thanks [15:05] jibel: they get the generic could not calculate the upgrade error message? [15:06] balloons, Ah, cool, yes. Perhaps the 8 year old version :-) [15:06] tedg, we had a session at vUDS on my ideas of a developer/release workflow from a quality perspective. If I'm understanding you correctly, this is what you'd like to see a highlevel doc on [15:06] it was of course from an app developer perspective [15:06] http://summit.ubuntu.com/uds-1403/meeting/22183/application-development-best-practices/ [15:07] bdmurray, apparently they do, and even experienced users like brendand are trapped by this. See bug 1298891 for example [15:07] bug 1298891 in ubuntu-release-upgrader (Ubuntu) "Can't upgrade from Saucy to Trusty" [Undecided,New] https://launchpad.net/bugs/1298891 [15:08] tedg, I like the childrens book idea :-) How a line of code gets into ubuntu [15:08] great idea :) [15:09] jibel: I guess fixing bug 934371 would help. [15:09] bug 934371 in ubuntu-release-upgrader (Ubuntu) "Unresolvable problem message does not help users and results in less useful bug reports" [Medium,Triaged] https://launchpad.net/bugs/934371 [15:09] tedg also you might be interested in this thomi-post: http://www.tech-foo.net/on-test-levels-and-coverage.html [15:09] ^^ don't expect your 8 yr old to get this :-) [15:10] very true [15:10] more tedg's speed ;) [15:11] jibel, yeah i can't get past that. i assume it's related to the 'unofficial packages' bit, but which ones? [15:14] brendand, try reverting xserver-xorg-video-ati -intel -radeon and -nouveau to the versions from the archive, you currently have somegitrev-0ubuntu0sarvatt~saucy [15:17] jibel, yeah i noticed that in the log - hopefully it works. i have the archive version now [15:17] jibel, http://paste.ubuntu.com/7168918/ [15:18] oop - vmware is still from there [15:18] guess that's not relevant though [15:18] i'll revert it anyway [15:25] mlankhorst, tjaalton: there are xorg ftbfs, weston and xorg-gtest, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html [15:28] jodh, i'm looking for a way to make an upstart job fire only if another job couldnt be started, do you know of any examples for such a case ? [15:29] ogra_: you mean http://upstart.ubuntu.com/cookbook/#run-a-job-only-if-another-job-fails ? [15:29] something like: start on can-not-start foo [15:29] lol [15:29] blind me [15:29] jodh, thanks :) [15:30] ogra_: if you care about exactly _how_ the job failed, you can interrogate the signal/exit code - see stopped(7) [15:30] cool, but i think i'm fine if it simply didnt start [15:32] Sweetshark, seb128: libreoffice-voikko still ftbfs [15:40] doko: against 4.2.3~rc2-0ubuntu1 ? [15:42] Sweetshark, https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5703954 [15:43] ahh, the new didn't yet migrate [15:43] doko: yep. that one still build against 4.2.1 [15:44] pitti: 1295521> the analysis there is hilariously wrong; I don't have time at the moment to dig into it, but the idea that installing i386 pam modules is going to break your amd64 lightdm is absurd === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === salem_ is now known as _salem [16:16] who knows about the messaging menu from the dbus level? [16:18] Chipaca, larsu but he's having a day off today, maybe try email? [16:18] Chipaca, or maybe tedg can help you [16:18] seb128: ta [16:18] yw! [16:20] Chipaca, D-feet :-) What are you looking for? [16:21] tedg: putting something into the messaging menu, via dbus :) [16:22] tedg: I tried looking around for the API, but it seems it's not published [16:22] Chipaca, Sure, we'd really prefer you used the lib. Is there a reason you can't? [16:23] tedg: there doesn't seem to be docs about those either :D [16:24] tedg: but also, unless things have changed, wrapping a lib not built for testability in a testable way is harder than calling dbus directly [16:25] tedg: willing to give it a try though :) [16:26] Chipaca, What is this for, QML/Qt/etc? [16:26] tedg: nope [16:26] tedg: all i'm binding with is glib, at least for now [16:27] tedg: program itself is golang, if that helps? [16:27] Chipaca, Hmm, not sure if the lib will work then as it requires glib mainloop. [16:27] ldd says libwhoopsie, glib-2, pthread, sqlite3, pcre, and the usual system ones [16:27] yeah, that'll be a problem === _salem is now known as salem_ [16:29] Chipaca, What project is this for? [16:29] Chipaca, Or, more specifically, what are you planning to put in the messaging menu? [16:30] tedg: ubuntu-push; push notifications [16:30] Chipaca, Notifications of what? [16:31] tedg: right now, system updates [16:32] tedg: but anything, later on [16:32] Chipaca, Those don't belong in the messaging menu [16:32] tedg: where do they belong? [16:33] longer term, any app that asks to get their notifications there, would [16:33] Chipaca, I would say system settings, but in general the messaging menu is for messages from other humans. Not a computer state. [16:33] tedg: system settings have an indicator? [16:34] Chipaca, Nope, but I believe the plan is it could have emblems [16:35] so, until something else is implemented, where do these go? [16:35] Chipaca, Ether :-) [16:35] * cjwatson grumbles at packages that run configure in their clean target [16:36] Chipaca, what are you talking about? [16:36] oh, wait, maybe this particular one is my fault [16:36] mpt: where to display notification of system updates, beyond the transient bubble [16:37] Riddell, https://bugs.launchpad.net/ubuntu/+source/calligra/+bug/1299096 [16:37] Chipaca, if there is a transient bubble, that is a bug [16:37] Launchpad bug 1299096 in calligra (Ubuntu) "clean up build dependencies" [Undecided,New] [16:37] Chipaca, are you working on PC or Touch? [16:37] mpt: touch [16:37] mpt: why is it a bug? [16:37] Chipaca, https://wiki.ubuntu.com/SoftwareUpdates#Prompting [16:37] mpt: does that apply to touch? [16:37] looks like it [16:38] mpt: wow [16:39] thanks doko [16:41] mpt: do you know if the software packages side of this is implemented? [16:41] well, expect lots of last minute changes from Ubuntu Kylin, :( [16:44] Chipaca, So somewhat related, I don't think push should "put things in the messaging menu" I think it should "notify the app and allow it to put things in the messaging menu" so that local configuration can be take into account. [16:44] tedg: the app is not running [16:45] tedg: that local configuration needs to be in push itself [16:45] Chipaca, Sure, I think that apps should provide an untrusted helper for that, not put that logic in push. [16:45] Chipaca, I know there was work to combine system updates and app updates in the same UI, I haven’t kept track of whether it’s finished [16:46] Chipaca, We can't put logic for, i.e. the Facebook app, in push. [16:46] tedg: i disagree, i think that is exactly where we can put it === roadmr is now known as roadmr_afk [16:46] Chipaca, Hoping you're going to define a Turing complete configuration language :-) [16:47] mpt: do you know who was doing this work? [16:47] Chipaca, I don’t remember, but seb128 will know [16:47] Chipaca, barry was one [16:47] seb128: please pretty please know [16:47] Chipaca, The reality is that the configuration could be as complicated as "only show me notification for members of my family" [16:49] Chipaca: We got click and system updates in system-settings now [16:49] the emblem thing in the scope isn't done, don't know if that is possible atm [16:49] Laney: I'm ... not sure what that means :) [16:49] which bit? [16:49] having click and system updates in there [16:50] That's what you were asking to know. [16:50] hmm [16:51] Laney: ok :) good. How do you display that you have a system update and click updates? [16:51] mpt: maybe that's a question for you; how (if at all) should it look if you have both kind of updates? [16:51] It should do what the design asks for [16:51] it doesn't [16:51] unless "Ubuntu touch" is a system update? [16:53] Laney: is that it? In those pics "Ubuntu Touch" is the system itself? [16:53] Laney: also, does this mean settings:///system/system-update no longer works? [16:53] Yes, and yes it should - that is exactly this [16:54] ah, so click will be listed there as well as the system [16:54] ok [16:54] Laney: who would know about the emblems? [16:55] that is: who would know whether putting an emblem on an icon in the launcher works? seb128? [16:56] mhr3 I guess [16:56] ah, ok [16:56] he's off :( [16:56] ah, no, i spy him :) [16:58] Chipaca, yes, “Ubuntu Touch” is a system update [16:59] mpt: yup. figured that out. [16:59] Laney: but click isn't yet putting a counter up, is it? (so i don't need to bother about syncing with that just yet) [16:59] Chipaca, saviq might know, too [16:59] mhr3 just told me to check with Saviq :) [16:59] Saviq: ehlo [17:00]