[04:55] hi [06:49] o/ [06:53] Good morning! [07:06] hey guys [07:11] pitti: hey! I have a very stupid question about the resolved email thread, you wrote: [07:11] "That's the reason why the dnsmasq instance we spawn [07:11] with Network Manager doesn't have caching enabled" [07:12] what is the use of dnsmasq without cache? [07:12] for me, that was the only reason we had it [07:16] didrocks: yeah, that's my worry as well [07:17] didrocks: that's what I'm currently discussing with stgraber [07:17] I'm not convinced that cache poisoning actually works that way [07:17] * pitti is typing another reply [07:17] didrocks: and indeed I don't like this at all (neither does awe) [07:18] pitti: ok, so if I get it right, there is no use of resolved or dnsmasq without cache, it's just a process in the middle forwarding requests? [07:19] well, it does local DHCP I guess… [07:19] in case you connect through ethernet another device [07:19] but that's it [07:20] didrocks: there still is [07:20] didrocks: better failure handling with multiple DNS servers [07:20] perhaps directing specific domain or reverses to specific recursors? [07:20] didrocks: and resolved does DNSSEC [07:20] but indeed, the main point is moot [07:21] pitti: oh right, you mentioned the multiple DNS servers fallback [07:21] pitti: got it, thanks :-) [07:36] is it easy to flush the cache? Just restarting the daemon? [07:37] needs root [07:37] fair enough [07:37] ok, I sent two more replies [07:58] good morning desktopers [07:58] hey seb128 [07:58] hey willcooke [08:01] bonjour seb128 [08:01] salut pitti, ça va ? [08:02] ça va bien, merci ! [08:02] * seb128 is reading the dns resolver discussion, interesting one [08:03] why hello [08:03] hoi Laney! [08:03] seb128: indeed [08:03] hey Laney, good morning [08:03] what's up! [08:04] Laney: because hey [08:07] I dropped my phone on the concrete floor at climbing last night and broke it :| [08:07] :(( [08:07] Laney, I've replaced a couple of screens on my phone - it's fiddly but do-able. [08:07] it's not a smashed screen actually [08:07] oh [08:07] that's bad then [08:08] already had that replaced out of warranty on this one, so no insurance for me! [08:08] Hello all! [08:08] it's some cable/connector inside it [08:08] it does actually work until it's moved [08:09] so can get the data off hopefully [08:10] argh Laney :/ [08:10] hey alexarnaud [08:10] didrocks: I was trying to wait for the Oneplus 3! [08:11] when is it going to be out? [08:11] hey didrocks, how are you today? Are you still sick? [08:12] rumours say june 14 [08:12] alexarnaud: yeah, still… [08:13] Laney: you can do it! wait wait wait :) [08:13] Laney, time to get an ubuntu phone! ;-) [08:13] /part [08:13] a snapcraft part? [08:14] :-( [08:14] :P [08:14] * Laney looks up when he got this phone [08:15] 13 July 2014 [08:15] this is poor [08:18] seb128: it seems that Ubuntu Phone is good :) ! Unfortunately, it seems not accessible with a screenreader. I don't know if the work on Android and Firefox OS about this subject could event. I read that Mir use event manager of Android. Talkback aad Android accessibility stack change the way to interact with the phone ^^. [08:19] alexarnaud, yeah, it's improving but it still has feature gaps compared to main OSes [08:26] oh btw, on the LTS, I have gnome-terminal with weird tabs layout since yesterday's upgrade, is that known? [08:27] what does weird tabs layout mean? [08:27] let me do a screenshot [08:27] did you check what got upgraded? :) [08:27] * Laney suggests you do that first [08:29] blame willcooke! [08:29] * seb128 ducks [08:29] Laney: I did and there was light-themes :p [08:29] * Laney is leading didrocks down the path [08:30] http://people.canonical.com/~didrocks/tmp/terminal_tabs.png [08:30] ruh row [08:30] the tab colors changed and it's a little bit (IMHO) ;) [08:30] ugly* [08:30] :p [08:30] open the gate marked /usr/share/doc/light-themes/changelog.Debian.gz [08:31] who is this guy? [08:31] Will Cooke? [08:31] .. what, no screenshot from yesterday too? :) [08:31] didrocks, that's how it's supposed to look. [08:31] new devs? :) [08:31] new design ;) [08:31] It's a feature, not a bug \o/ [08:31] willcooke: ok, it's weird to notice them now when I didn't before :) [08:31] (but I guess that was the point of the change) [08:32] didrocks, https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/762349 [08:32] Launchpad bug 762349 in Ayatana Design "[SRU] Difficult to distinguish which tab is selected" [Undecided,Fix committed] [08:32] 2 tabs are ok and great, it's when you have more (but I'm guilty of that) [08:32] willcooke: yeah, I'm looking now [08:32] at least, it's not my eyes which have derailed [08:32] and I can notice changes! [08:33] ok, this is when I should paste this: https://xkcd.com/1172/ :) [08:33] :D [08:34] at least, not a regression, but weird (and nice in some way) to have a visual change in a LTS for once! [08:34] I just wasn't expecting it, hence the "something should have broke" [08:34] :) I agree, it's a tad on the ugly side, but it does the job. [08:34] thx for answering about it guys! :) [08:34] yep [08:35] Laney, can you remind me what to add to the search providers in my browser so I can search LP bugs from the URL bar again? The URL was something like bugs.launchpad.com/+bug/%s but I can't get it to work [08:37] http://launchpad.net/bugs/%s [08:37] I use pad.lv/%s [08:37] https://wiki.canonical.com/UbuntuEngineering/Security/Tips [08:37] then you can use the other pad.lv patterns too [08:37] willcooke, what browser do you use? [08:37] seb128 *cough* Chrome *cough* [08:37] I HAVE A REASON TO USE IT!! [08:37] thanks Laney sarnold [08:40] willcooke: what was that it was hard to hear over the coughing it didn't sound like the default browser installed on the system though [08:42] willcooke, right click on the url bar -> edit search engine and you can add custom entries [08:42] seb128, yeah all done, thx [08:42] it's less specific that pad.lv [08:42] and less to type :p [08:43] like I've "bts %s" which sends me to the bts page for the package [08:43] shortcut wars [08:43] I do "lbp 123456" [08:43] or bzg for the gnome bugzilla [08:43] *lpb [08:43] that's my "lp" ;-) [08:43] "lps" for the bugs list "lpc" for the component page :p [08:44] but yeah, seems like everyone has their own custom tricks [08:50] ok, after days of rain we have some sun, going to use the opportunity to get some pre-lunch exercice [08:50] seb128, enjoy! It's raining here still :( [08:50] * willcooke considers building an ark [08:51] * Laney whines "MIR please" at tedg [08:52] thanks! [08:54] pitti: is "rm pending.json" not enough to get britney to fix its knowledge of pending tests? [08:54] kcalcore -> ktnef is falsely in progress [08:55] Laney: ah, did you do that? [08:56] yesterday [08:56] Laney: I'm currently investigating what happened to the lost armhf requests [08:56] Laney: so either you did that while britney was running, or it lost them again [08:56] I checked britney wasn't running at the time [08:56] or it was running but not for yakkety [08:56] Laney: let me look at the runners; test requests are not supposed to get simply lost [08:56] it's been in progress for some days now [08:57] e. g. gvfs/armhf for systemd 230-2 is still "in progress", but https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/armhf/g/gvfs has no result [08:57] first I re-requested them but that didn't clear it [08:57] but it's also not in the AMQP queues any more [08:57] so they just get eaten somehow, which Should Not Happen™ [08:58] Laney: might still be a leftover swift glitch of course [08:59] Feb 12 04:13:16 cyclops-node23 worker[495]: 2016-02-12 04:13:16,425 INFO:worker Received request for package gvfs on yakkety/armhf; params: {u'triggers': [u'systemd/230-2']} [08:59] Feb 12 04:17:07 cyclops-node23 worker[495]: 2016-02-12 04:17:07,030 INFO:worker Putting results into swift autopkgtest-yakkety yakkety/armhf/g/gvfs/20160212_041707@ [08:59] Feb 12 04:17:09 cyclops-node23 worker[495]: 2016-02-12 04:17:09,778 INFO:worker Acknowledging request gvfs [08:59] that looks fine [09:00] willcooke: Go find Rhod Gilbert ask the audience how old they were when they realised they could take a kagool off ;) [09:00] Laney: err, wait -- that's a completely bogus timestamp [09:00] davmor2, :D:D:D [09:00] pitti: errrm, quite [09:00] Laney: indeed, one of the runners has date == Fri Feb 12 11:21:48 UTC 2016 [09:01] I guess something expects the timestamps to be monotonic [09:01] Laney: yes, in britney we remember the last timestamp and query for results newer than that [09:01] willcooke: followed up with "In the bible it rained for 40 days and forty nights, that's still the best summer I ever remember" [09:01] Laney: ok, let me fix the date on this, then I'll mass re-run all the RUNNING ones [09:01] merci [09:01] Laney: btw, you don't need to wait for britney and rm pending any more [09:02] I did try re-running first [09:02] that was http://autopkgtest.ubuntu.com/data/packages/yakkety/amd64/k/ktnef/20160531_205915@.log [09:02] but it's still RUNNING on britney [09:02] no, lies, it was http://autopkgtest.ubuntu.com/data/packages/yakkety/amd64/k/ktnef/20160531_171644@.log - but still [09:02] Laney: hm, that sounds like something else then [09:03] I think there were still some swift problems at that time [09:03] ah, could be [09:03] it took debci ages to catch up with the results being put into swift [09:03] Laney: ah, that arm box has ntpd installed [09:03] so timesyncd disables itself [09:03] and apparently ntpd doesn't work so well [09:03] "oops" [09:04] kwality [09:05] ok, ntp purged, timesyncd started, date is correct [09:05] time for retry-autopkgtest-regressions -s yakkety --state RUNNING |grep armhf [09:06] (done) [09:07] * Laney runs ktnef locally [09:07] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/k/ktnef/20160531_205915@/log.gz unhelpful [09:07] Laney: oh, I was looking at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/l/linux-raspi2/20160601_020110@/log.gz which is similar [09:08] Laney: thanks for that, investigating this on amd64 is much easier [09:08] it means 'uninstallable' right? [09:08] Laney: no, this means that apt-get source ktnef somehow failed [09:10] pitti: oh right, and apt's stdout/err isn't saved anywhere? [09:10] Laney: but I see why it might fail for linux-raspi2 (version mismatch wit NBS binaries), but not the same case for ktnef [09:12] Laney: it's actually suposed to print the apt stdout/err on failure [09:12] .. or not, hang on [09:12] yeah, I think it doesn't [09:12] Laney: does that reproduce locally? [09:13] not with schroot anyway [09:13] probably not minimal enough [09:14] Laney: does reproduce here [09:14] runner/adt-run ktnef --- schroot yakkety [09:16] Laney: right, bug in the heuristics for determining which source package to download [09:16] *throws hands into air*, /me really wants an apt-get source foo=version [09:16] this is excruciatingly difficult [09:16] err, apt-get source foo/yakkety-proposed [09:17] (=version works) [09:21] pitti: /me screams [09:21] just saw this code [09:23] Laney: it's pure joy, isn't it [09:54] pitti: https://paste.debian.net/713146 [09:54] Laney: argh, that trap again [09:56] Laney: I'm a moron: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=7c1a251a4 [09:56] pitti: haha [09:56] Laney: so we need to not specify it for precise, but everywhere else [09:56] we have autopkgtest for 12.04? [09:56] yes [09:56] kernel mostly [09:57] TheMuso: Hello! I'm visual impaired and I would like to know if you have some type of experience about computer with EFI and Windows dual-boot. Is it possible from a new computer buy in the market with Windows to boot on a Ubuntu USB stick without sighted help that will disable fast boot or something like that ? [09:57] there's another showsrc in lib/adt_testbed.py [09:57] E: Command line option --only-source is not understood [09:57] yep, need to conditionalize that [09:57] runner/adt-run -d pmount --- schroot precise [09:58] ^ [09:58] Laney: thanks, will clean this up too [10:00] pitti: you can call "apt-cache showsrc --only-source" and look at the exit code [10:00] you get 0 if it accepts the argument and 100 otherwise [10:00] $(grep -q 12.04 /etc/os-release || echo --only-source) [10:00] Laney: oh, and it helpfully exits with 0 if you specify a nonexisting source package [10:00] *#)$#(*$# [10:07] Laney: http://paste.ubuntu.com/16886653/ seems to work [10:08] this fixes ktnef and linux-raspi2 [10:09] there's still something wrong with this logic for precise, though, but later on [10:09] --apt-pocket self-tests still succeed [10:10] precise> ah, it fails because it still behaves like in xenial without --only-source, it just doesn't have an option for thsi [10:11] apt-cache showsrc ^linux$ [10:11] and that doesn't work either [10:13] I suppose you have to look for Package: [10:14] grep-dctrl would be easier for that [10:15] apt-cache showsrc ktnef | grep-dctrl -S -sPackage-List -n ktnef [10:17] Laney: I pushed http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=56ac53b for now and will re-retry stuff [10:18] ok, thanks! [10:18] to unblock promotions; but this indeed is in dire need for cleaning up [10:18] I wonder why this became a problem right now [10:18] ktnef last succeeded not long ago [10:18] maybe with the new KDE upload two weeks ago binaries got shuffled [10:19] looks the same on xenial too [10:19] ah well [10:20] libgmpada too [10:21] and http://autopkgtest.ubuntu.com/packages/k/kactivities/yakkety/amd64/ [10:21] all retriggered [10:40] Mirv: I'll upload goldencheetah to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035/+packages to test your theory, ok? [10:42] (done) [11:02] Laney: thank you [11:02] still building on arm64 [11:07] Mirv: failed [11:08] Laney: I see. do you know how to get a list of packages that don't have armhf build at all (like goldencheetah)? I could cross-check that to my list of packages depending on libqt5core5a to find other candidates that need some action [11:08] goldencheetah was indeed on this second list, but not on my first list (armhf ftbfs) [11:17] Mirv: In [13]: yakketyarmhf = lp.load('https://api.launchpad.net/devel/ubuntu/yakkety/armhf/') [11:17] In [14]: ftbfs = yakketyarmhf.getBuildRecords(build_state='Failed to build') [11:17] In [15]: len(ftbfs) [11:17] Out[15]: 472 [11:18] hmm [11:18] not sure that is right [11:18] I suppose you need to filter it for published records only [11:19] ok that copy-paste should be enough to get me forward with lplib [11:24] Mirv: seems "current_ftbfs = [f for f in ftbfs if f.current_source_publication is not None]" filters it to the current ones [11:24] can there really only be 198? [11:24] I'm a bit suspicious [11:25] Laney: so ftbfs would list also those without package like build dep missing, for example goldencheetah? my ftbfs (really failed to build) was 181 [11:26] you want to add build_state='Dependency wait' too for those [11:26] ok [11:26] Laney: and what about if package is built only for selected architectures? [11:27] I wonder if this is only showing packages which have been uploaded to y [11:28] http://qa.ubuntuwire.org/ftbfs/ [11:28] this agrees with my number [11:31] ah right I was on xenial, I maybe lost a few when translating the list of binary packages to source package with apt-cache. I can see from my bash history that I did filter for armhf (F) [11:33] hmm, no, since those are source packages, I used apt-cache for the libqt5core5a reverse deps. ok, going over again. [11:35] this is the only one I care about right now since it is blocking libical :) === hikiko is now known as hikiko|ln [11:52] Morning all [11:52] hey andyrock, how are you? [11:53] Hey seb128 not bad you? [11:53] ok I reproduced the ftbfs list and also got three more candidate packages from the depwait list, and goldencheetah too. checking in 035 and updating the bug report. I think I could subscribe ubuntu-archive now too, even if I'd still find a package or two in my remaining re-re-checks. === hikiko|ln is now known as hikiko === hikiko is now known as hikiko|ln [12:24] good morning [12:26] hi desrt [12:27] hey desrt === hikiko|ln is now known as hikiko === seb128_ is now known as seb128 [12:34] willcooke, omw for that call, having some wifi issues though [12:35] seb128, ha! Thought exactly that :) [12:36] willcooke, can you hear me when I talk? [12:36] seb128, nope! [12:37] fail :-/ [12:55] attente, sorry I saw the bug but still unsure what you are trying to solve [12:57] seb128: if you build the galculator snap without that, the snap looks for resources in the parts directory of the build dir instead of inside the final snap itself [12:57] desrt, attente, sorry audio was not good in that hangout and I didn't really understand if we had more specific issues than the ones we are filing/tagging since Prague [12:57] attente, so basically https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1583250 ? [12:57] Launchpad bug 1583250 in snapcraft (Ubuntu) "No way for dealing without distro patching configure DATADIR (and alike) path" [Undecided,New] [12:58] seb128: yep, exactly that [12:58] seb128: so that workaround is to modify the autotools snapcraft plugin locally and add it to the repo [12:58] but there we hard code the destination of the mounted snap [12:59] /snap//current [12:59] right [12:59] change the app to use gresources :p [12:59] but they don't like this because it's hard-coded, and removes any future possibility of relocating the snap [13:00] what do they suggest doing? [13:00] what is flatpak doing? do they make the archive content being seen as /? [13:01] i don't know what flatpak is doing, but our workaround right now with the hacked autotools plugin seems to be the only thing we have [13:01] yeah, Trevinho made a quilt plugin to patch the source before building [13:02] not that is the cleanest solution eh :) [13:02] hey Trevinho! [13:02] but... ti seems that there some discussion if we want that part of snapcraft or not [13:02] hey seb128 [13:02] that's about the same as just fixing all upstreams to be relocatable though [13:02] seb128, attente: relevant bug is https://bugs.launchpad.net/snapcraft/+bug/1551716 it would be nice your input too [13:02] Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New] [13:03] Trevinho, well ideally you wouldn't need to patch a source to snap it [13:03] no, ideally not... But you know the world we live in [13:03] and forking just for a single patch is annoying to me [13:04] all the main pieces in core (nm, bluez) are still using patching in any case [13:05] yeah, that's fine for our stack [13:05] we create work for ourself so it's our choice [13:05] we shouldn't require that from app writers though [13:05] sure, upstream has not to do that [13:06] * desrt hugs the upstreams of the world [13:06] "we're all in this together, guys" [13:07] desrt, attente, do you me to write that email to the snappy list? [13:07] seb128: if you would like to, that would be great [13:08] k [13:08] i do have a slight aversion to getting involved in discussions that i know almost nothing about =) [13:08] seb128, attente: however one thing I was hacking on and that I think could be useful for this, is that IMHO when opened a snap should be do something like a bind mount on /this-snap or whatever that points to $STAN [13:08] $SNAP [13:08] in this way, we can just compile using /this-snap/ as prefix [13:09] *cough* filesystem *cough* namespaces [13:09] *cough* *cough* [13:09] well, naming can be better... But it's not the point [13:10] it's entirely the point [13:10] we could have some standard path that all snaps used without stepping on each others toes... [13:10] we could even give it a nice short easy-to-type name that looks friendly and familiar to everyone [13:10] maybe... oh... /usr, for example [13:11] * desrt twitches [13:11] :) [13:11] there might be a reason why they don't want to go that road [13:12] let's see what the discussion gives [13:12] at least filesystems namespaces can"t be used to restrict root apps [13:12] Mirv: can you point me to your list? [13:12] so it would work for desktop examples [13:12] but not for system services [13:12] * Laney knows a friendly archive admin [13:12] * Laney sniggers [13:14] seb128: filesystem namespaces can be used for root apps no problem [13:14] seb128: the basis of that discussion was that it may still be necessary to _also_ use apparmor for some things as well [13:15] (although i believe that the core kernel will improve to the point where this is not necessary... and if you use user namespaces, i'd say it's already there, modulo the horrifying bugs that appear on a semi-regular basis) [13:15] Trevinho: isn't the same problem still going to happen? that's still going to be a hard-coded path in the final snap [13:16] attente: yeah, it's hardcoded, but it's always there [13:16] attente: while it won't be dependent on version or pkgname [13:17] since i can't really talk about the weather... [13:17] how many of you have stopped using firefox and switched entirely to chrome? [13:18] * desrt is starting to suspect that she may be the last holdout [13:18] desrt: although I've plenty of ram, chrome is too much a memory hog to me.. So no. [13:18] so.. firefox for life. [13:19] ....or until your next laptop upgrade :) [13:19] desrt: I did that.. And I've 32GB of ram, but still... I can't manage all my tabs in chrome :) [13:19] i use firefox too [13:20] * desrt very often gets into situations where firefox takes a very very long time to quit [13:21] clearing out history/awesomebar/etc/etc databases seems to help that for a bit, but it's not too long before it's back to where it was... and during that time, if i try to open another window (within 20 seconds, say, of last exit), i get "firefox is already running. plz reboot." [13:21] any tips? [13:21] Laney: bug #1586026 - ubuntu-archive not yet subscribed [13:21] bug 1586026 in vite (Ubuntu) "Remove arm64 binaries for packages failing to build with Qt compiled with OpenGL ES" [Undecided,New] https://launchpad.net/bugs/1586026 [13:23] Mirv: what does candidates: mean for yade? [13:26] desrt: seen the "firefox is still running" thing from time to time, but not slow quitting [13:26] no help from me then :( [13:26] the "firefox is still running" thing happens because it hasn't exited yet from the previous tim e [13:26] desrt: I'm stil on firefox [13:26] ie: the windows are closed, but the process is still there, seemingly doing something in the background [13:27] jbicha: hey! [13:27] when i've seen it it's been a long time after quitting [13:27] grrr, got bitten again by docking my laptop changing connection which confuses IRC [13:27] jbicha: welcome back! [13:27] like the thing never managed to exit properly [13:27] if somebody talked to me since less than 10 min please repeat what you wrote [13:28] * Laney gets recruiter spam hiring for a cloud based tax and accounting platform [13:28] hmmmmmmmmmmmmmmmmmmmm maybe not [13:28] Laney: that it was found in the cross-check list but check if it's failing a rebuild is not ready yet [13:29] ie it did fail on armhf, but not yet sure if it would now fail on arm64. build still ongoing. [13:29] seb128: it breaks your existing network connections if you do that? [13:30] no, but I think it changes the routing [13:30] my dock is cable/eth connected [13:30] which becomes default over the wifi [13:31] not sure that should break established connections [13:31] did it always do that? [13:31] yes [13:31] annoying [13:32] indeed! [13:34] seb128: don't suppose you have a few minutes to process https://bugs.launchpad.net/ubuntu/+source/bino/+bug/1586026 do you? [13:34] Launchpad bug 1586026 in vite (Ubuntu) "Remove arm64 binaries for packages failing to build with Qt compiled with OpenGL ES" [Undecided,New] [13:34] if not then just goldencheetah would be appreciated [13:35] * Laney is attacking libical with maximum force [13:35] let me have a look [13:35] pretty sure the only thing left after that is indicator-datetime [13:35] * Laney stares at texas hard [13:35] why would they fail now if rebuilt? [13:36] teddddd [13:36] some gl change on arm64 [13:37] shouldn't we fix gl/those then? [13:37] sure if you get the phone team that made this change to put it on their list [13:38] is goldencheetah blocking libical? [13:38] yep [13:48] Laney, done for goldencheetah, going to wait to hear more from Mirv before removing the others, looks like things that should be fixed to me [13:50] fine for me, fixing things is good, hope that happens ;-) [13:50] * Laney is bored of punching his phone [14:55] seb128: http://people.canonical.com/~bjoern/yakkety/5.1.3/ <- 5.1.3 yakkety for poppler transition and to avoid breaking against mdds [14:56] Sweet5hark, k, adding to my todo [14:57] seb128: I looked at bug 1586497 -- cant get any wiser from the logs there on what happened there really. I only see dpkg returning -1 in https://launchpadlibrarian.net/261979138/DpkgHistoryLog.txt but cant see why. I also note this happened with other packages before in the log ... [14:57] bug 1586497 in libreoffice (Ubuntu) "package libreoffice 1:5.1.3-0ubuntu1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting a removal" [Undecided,New] https://launchpad.net/bugs/1586497 [14:57] seb128: is that enough to mark it bot-stop-nagging? [14:58] Sweet5hark, right, maybe full disk or something, yeah just tag it [15:03] seb128: done (all SRU bugs now verification-done0. [15:03] Sweet5hark, thanks [15:31] Laney, ubuntu-app-launch was in main and demoted in xenial, I don't think it needs a MIR? [15:32] Sweet5hark, sponsored, ignore the rejected email, you included the orig in the libreoffice upload where it was already in yakkety, I hacked the .changes and reuploaded [15:41] seb128: you'd promote it? [15:41] I didn't find an mir bug [15:42] it looks like it went straight to main [15:43] Laney, https://bugs.launchpad.net/ubuntu/+source/upstart-app-launch/+bug/1218952 [15:43]