[00:00] <stgraber> The new binary in question is lxd-utils which contains fuidshift. It's a tool we've had upstream forever but that lxd itself doesn't use (it just uses the same internal functions). I added it as it's useful on its own for users dealing with user namespaces and because our newly introduced autopkgtest tests it too.
[13:44] <arges> Can I have release team review bug 1492271? Need FFE ack for new package in universe. Thanks
[13:52] <arges> n/m need to fix some arch build issues first. Also I'm not entirely sure i need an FFE for this... tried reading the wiki a few times and wasn't completely sure.
[14:49] <infinity> arges: It's a new package, doesn't need an FFe unless you intend to also get it installed by default.
[14:49] <infinity> arges: What build issues, though?  Seems to build on Debian on all arches we care about.
[14:50] <arges> infinity: I'm going to re-check for user error on this end, I think my armhf cross-schroot is messed up
[14:50] <arges> infinity: but once it looks good, i"ll syncpackage then
[14:52] <infinity> arges: Well, it might not cross, but that's hardly a blocker. :P
[14:52] <infinity> arges: It seems to build natively fine in Debian.
[14:54] <arges> Yea, most likely its a cross issue.
[21:38] <cyphermox> so, I was looking at component-mismatches, noticed a large tree because of libtype-tiny-perl
[21:39] <cyphermox> I can't seem to find what wants libtype-tiny-perl to be in main though, it doesn't appear to have reverse-(build-)depends in main, nor be in seeds.
[21:40] <cyphermox> rmadison also shows it's not in main in other releases, so I'm not sure what to think of it :)
[21:40] <cjwatson> It's listed for movement to universe in component-mismatches but not in component-mismatches-proposed, which may be a clue
[21:41] <cyphermox> ah, I was only looking at -proposed
[21:41] <cyphermox> d'oh.
[21:41] <cyphermox> cjwatson: thanks.
[21:42] <cjwatson> libpod-readme-perl is in main and has a newer version in -proposed which newly B-Ds on libtype-tiny-perl (and a pile of other stuff)
[21:51] <cyphermox> cjwatson, shouldn't that be attached in the svg then?
[21:52] <cjwatson> cyphermox: No, because libtype-tiny-perl has already been promoted
[21:52] <cyphermox> oh, I see
[21:52] <cjwatson> The svg only shows the graph of stuff that needs to be moved to main/restricted, plus the immediate parents of nodes in that graph that are already in main/restricted
[21:52] <cjwatson> IYSWIM
[21:53] <cyphermox> I couldn't find what wanted libtype-tiny-perl because I wasn't including -proposed when searching for things anyway.


[07:09] <mup> PR snapd#13334 closed: o/snapstate: check properly conflicts when refreshing snapd <Run nested> <Created by alfonsosanchezbeato> <Merged by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/13334>
[07:09] <mup> PR snapd#13336 opened: usersession: implement restart controls and status querying for user services <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/13336>
[07:24] <mup> PR snapd#13337 opened: wrappers: support for restarting user-daemons <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/13337>
[08:39] <mup> PR snapd#13338 opened: daemon,o/servicestate: support for scopes and users in API for services <Needs Documentation -auto-> <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/13338>
[10:05] <mup> PR snapd#13339 opened:  go.mod: move to latest secboot #13278 with snakeoil <Run nested> <Run Nested -auto-> <Created by valentindavid> <https://github.com/snapcore/snapd/pull/13339>
[12:00] <mup> PR snapd#13304 closed: interfaces/desktop: allow access to Mutter IdleMonitor idle time <Created by alexmurray> <Merged by MiguelPires> <https://github.com/snapcore/snapd/pull/13304>
[12:20] <mup> PR snapd#13340 opened: many: introduce and use snap.SelfContainedSetPrereqTracker <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/13340>
[12:40] <mup> PR snapcraft#4427 closed: fix(remote-build): parse `--launchpad-timeout` argument <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4427>
[13:40] <mup> PR snapd#13341 opened: tests/main/postrm-purge: make check units more robust <Created by valentindavid> <https://github.com/snapcore/snapd/pull/13341>
[14:10] <mup> PR snapd#13342 opened: cmd/libsnap-confine-private: add snap-update-ns support for ensure-dir mounts <Created by ernestl> <https://github.com/snapcore/snapd/pull/13342>
[14:20] <mup> PR snapd#13274 closed: cmd/snap-update-ns: support ensure-dir mount <Squash-merge> <Needs Samuele review> <Security-High> <Needs security review> <Created by ernestl> <Closed by ernestl> <https://github.com/snapcore/snapd/pull/13274>
[14:31] <mup> PR snapd#13343 opened: cmd/snap: use updated "current" revision after snap refresh run inhibition <Needs Documentation -auto-> <Created by ZeyadYasser> <https://github.com/snapcore/snapd/pull/13343>
[15:16] <mup> PR snapd#13344 opened: tests : backport fixes to spread tests (2.60) <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/13344>
[18:16] <mup> PR snapd#13345 opened: a/snapasserts, o/assertstate: add functions to help during remodel <Created by andrewphelpsj> <https://github.com/snapcore/snapd/pull/13345>
[20:56] <mup> PR snapcraft#4423 closed: chore(pyproject): quote versions <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4423>


[10:05] <s-fox> Hello.
[15:20] <dscassel> Morning, s-fox
[15:21] <s-fox> Hello dscassel,  how are you?
[15:21] <dscassel> (5am? I hope you're on the west coast. :)
[15:21] <dscassel> Pretty good.   :D
[17:02] <s-fox> Nice.  Sorry for slow reply, gad an issue here to deal with. dscassel
[20:17] <dscassel> No worries. I disappear all the time. :)


[08:15] <m15k> Is named a default enabled ubuntu server service? I'm a little bit unsure who starts the process...
[10:04] <Neo1> I've installed mysql and got error
[10:04] <Neo1> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
[10:04] <Neo1> I used this mysql_secure_installation
[10:05] <Neo1> commands mysql doesnt work
[10:05] <Neo1> I press $ sudo mysql also doesn't help
[10:30] <m15k> Neo1: Seems that you've assigned a password for mysql.
[10:30] <Neo1> yes
[10:31] <Neo1> I've soled it use sudo mysql -u root -p
[10:31] <m15k> try mysql -u root -p
[10:31] <Neo1> yes, thanks
[11:04] <Neo1> I'd installed LAMP a few minutes ago, What shall I do now? How I can create databases?
[11:05] <Neo1> m15k: ?
[11:05] <m15k> Neo1: It's a little bit unclear what you want to achive...
[11:06] <Neo1> this is my real site http://american-chat.ru , I want create database and a few subdomains such as test.american-chat.ru, test1.americanchat.ru and whatnot...
[11:06] <Neo1> m15k: I want doing chat on node.js and install there wordpress
[11:07] <m15k> And what's your problem?
[11:07] <Neo1> m15k: see at first I think about databases
[11:07] <Neo1> m15k: I don't know how it create, what do you use for it? I am thinking about phpmyadmin?
[11:08] <m15k> If you want to install wordpress that worpress should take care about creating the databse
[11:08] <m15k> If you want to do it manullay you could use phpmyadmin or even mysql command
[11:08] <Neo1> m15k: yes, exactly, therefor I need create a few databases, before I used ISPManager and there all was
[11:09] <Neo1> m15k: I want to do it in easier way, probably not manual?
[11:10] <Neo1> m15k: yes I misunderstood, and how you do it?
[11:10] <m15k> Easier is just a perspective. For me it's easier to just use command line instead of installing a webapp
[11:10] <m15k> that way: https://dev.mysql.com/doc/refman/5.7/en/creating-database.html
[11:11] <Neo1> m15k: phpmyadmin is necessary app unless you don't use LAMP?
[11:12] <Neo1> m15k: and in phpmyadmin shall I create users not root too?
[11:12] <Neo1> we don't use root for server and probably we don't use root for MySQL
[11:12] <m15k> Hopefully ^^
[11:14] <m15k> "phpmyadmin is necessary app unless you don't use LAMP?" The sentence does not make sense for me.
[11:15] <Neo1> well, 3 commands and you can create dB in console...., but nevertheless phpmyadmin is much better, more opportunities
[11:15] <m15k> phpmyadmin is just a frontend for mysql. You can use and/or create user as you like.
[11:15] <Neo1> m15k: why? unless means if not
[11:15] <Neo1> m15k: phpmyadmin is necessary app if not you don't use (without) LAMP
[11:16] <m15k> LAMP is just a tech stack: LinuxApacheMysqlPhp
[11:16] <m15k> And phpmyadmin is a frontend for Mysql based on Php
[11:17] <m15k> So phpmyadmin is never necessary at all.
[11:17] <Neo1> yes and I think we should always install phpmyadmin if we use mysql, yes?
[11:17] <m15k> I don't agree. But that's not the question rightß
[11:17] <Neo1> ok
[11:18] <Neo1> m15k: well it's personal preferences rather )
[11:18] <m15k> On that I can agree :)
[11:41] <Neo1> I'm going to do this 3 things namely: install phpmyadmin, create a few virtual hosts and setup free tsl/ssl certificut,
[11:41] <Neo1> Then install node.js.
[11:41] <Neo1> Afterwards make conclusions, write short plan how to do and reinstall everything again follow plans again correct plan and again a few times reinstall everything....
[11:42] <Neo1> Seems this way give me skill of customize server over SSH
[11:43] <Neo1> and at the end write shell script that will automatically to do all of this routine work....
[13:36] <Neo1> I've got this error:
[13:36] <Neo1> Job for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.
[14:57] <tomreyn> then do as it says
[16:21] <[Kid]> anyone use corosync and/or pacemaker with CLVM for clustered storage?
[16:21] <[Kid]> got a question mainly about corosync and pacemaker
[20:37] <Doow> Hi, I'm running backups with duplicity as the user backup. One of the things I'm backing up is gitolite folders, to do this properly I need to run the gitolite writable command as the gitolite user. The gitolite user doesn't have a login shell. What's the best way to do this?
[20:38] <Doow> Right now I'm running the duplicity scripts from a python script, but I could change that if needed.


[02:22] <mwhudson> i don't suppose anyone who can log into autopkgtest infra is around?
[02:26] <handsome_feng> Hi, ukui-menu 2.0.1-1 is blocked when migrating from -proposed to release because missing build on i386, but the i386 package (ukui-menu=1.1.12-1) is migrate from eoan to focal, how to deal with this situation? Thanks!
[02:31] <xnox> mwhudson:  i think i actually have the right permissions to do that.
[02:31] <xnox> mwhudson:  but after initial training, it might be a while for me to dig up the right hostnames to ssh into
[02:31] <xnox> mwhudson:  what specifically are you after?
[02:31] <mwhudson> xnox: do you have any way of deriving what is causing https://autopkgtest.ubuntu.com/running#pkg-docker.io to hang?
[02:31] <mwhudson> xnox: it doesn't hang when i run it locally :(
[02:33] <xnox> le sigh
[02:33] <xnox> for that one may need to ssh all the way into the guest os, and i'm not sure i've done that, I only got to the queus and workers.
[02:33] <xnox> it should be all local, cause it is importing a tarball and running it.
[02:34] <mwhudson> actually i think it's possible you need to launch a job in a special way to allow a human to log into it, i forget
[02:34] <xnox> unless dockerd is dead, or hung up, with a new kernel....
[02:34] <mwhudson> xnox: it's triggered by the new containerd
[02:34] <xnox> that also sounds like something familear
[02:34] <mwhudson> (in focal-proposed)
[02:35] <xnox> once it times out and fails, there should be a log right. i wonder if things are not happy with new kernel, new systmed, new apparmor and the like with the new containerd.
[02:35] <xnox> plus i thought debian has broken networking
[02:35]  * xnox wonders if ubuntu true test would just work
[02:35] <xnox> although networking stuff should have been fixed by now
[02:35] <xnox> horum
[02:36] <xnox> i'm gonna finish my mint tea and go to bed =)
[02:44] <mwhudson> xnox: nothing in logs iirc but maybe i should check an old failure indeed
[02:44] <mwhudson> xnox: good night
[02:45] <mwhudson> no nothing useful in artifacts
[02:48] <mwhudson> xnox: i want to talk to you about vtoc tomorrow :)
[03:12] -queuebot:#ubuntu-release- New: accepted gitless [amd64] (focal-proposed) [0.8.8-2]
[03:52] <handsome_feng> Sorry, I got it, It's because it migrate from python to qt, and the architecture changes from all to any.
[03:52] <wxl> handsome_feng: p.s. kylin's looking good in qt :)
[03:53] <handsome_feng> wxl, Thanks! :)
[04:00] <handsome_feng> And anyone know how to deal with this situation? I didn't find the document. :(
[05:24] -queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-418 [amd64] (focal-proposed/multiverse) [418.116.00-3] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-tesla-418 [ppc64el] (focal-proposed/multiverse) [418.116.00-3] (no packageset)
[05:34] <infinity> handsome_feng: Fixing ukui-menu (and panel appears to have the same issue).
[06:08] <handsome_feng> infinity: Thanks!
[06:14] -queuebot:#ubuntu-release- New binary: cinnamon-control-center [s390x] (focal-proposed/universe) [4.4.0-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: cinnamon-control-center [ppc64el] (focal-proposed/universe) [4.4.0-2] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: cinnamon-control-center [amd64] (focal-proposed/universe) [4.4.0-2] (no packageset)
[06:20] -queuebot:#ubuntu-release- New binary: cinnamon-control-center [arm64] (focal-proposed/universe) [4.4.0-2] (no packageset)
[06:20] -queuebot:#ubuntu-release- New binary: cinnamon-control-center [armhf] (focal-proposed/universe) [4.4.0-2] (no packageset)
[07:05] <RAOF> So, now that Mir builds and passes it's !i386 autopkgtests, the thing try do is to delete the stale i386 binaries and everything is hunky-dory, right?
[07:27] <doko> RAOF: did you you schedule the rebuilds for the soname change?
[07:31] -queuebot:#ubuntu-release- New: accepted cinnamon-control-center [amd64] (focal-proposed) [4.4.0-2]
[07:31] -queuebot:#ubuntu-release- New: accepted cinnamon-control-center [armhf] (focal-proposed) [4.4.0-2]
[07:31] -queuebot:#ubuntu-release- New: accepted cinnamon-control-center [s390x] (focal-proposed) [4.4.0-2]
[07:31] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-418 [ppc64el] (focal-proposed) [418.116.00-3]
[07:31] -queuebot:#ubuntu-release- New: accepted cinnamon-control-center [arm64] (focal-proposed) [4.4.0-2]
[07:31] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-tesla-418 [amd64] (focal-proposed) [418.116.00-3]
[07:31] -queuebot:#ubuntu-release- New: accepted cinnamon-control-center [ppc64el] (focal-proposed) [4.4.0-2]
[07:46] <RAOF> doko: To my knowledge there are no rdepends of Mir-built binaries (at present)
[07:47] <RAOF> (At least, ones that are not built from the Mir source package)
[07:51] -queuebot:#ubuntu-release- New binary: icu [s390x] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
[07:52] -queuebot:#ubuntu-release- New binary: icu [i386] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
[07:55] -queuebot:#ubuntu-release- New binary: icu [amd64] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
[08:07] -queuebot:#ubuntu-release- New binary: icu [arm64] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
[08:08] -queuebot:#ubuntu-release- New binary: icu [armhf] (focal-proposed/main) [65.1-1] (core, i386-whitelist)
[09:35] <locutus_> mwhudson, hello, I did sync python-traits, not sure but flaky tests seems to be not flaky anymore?
[09:36] <locutus_> it built fine on first attempt
[09:48] <mwhudson> locutus_: i don't remember that package i'm afraid
[09:48] <mwhudson> i guess it's s good thing it's building :)
[10:32] <tseliot> hello admins, I don't think nvidia-graphics-drivers-tesla-418 should have been synced, since we don't sync nvidia drivers from Debian
[10:32] <tseliot> apw ^^
[10:32] <tseliot> also sil2100 ^
[12:05] <rbalint> sil2100, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378651 for systemd?
[12:25] <apw> tseliot, i'll pull it, and that should also cause it to be blacklisted
[12:27] <tseliot> apw, thanks, I think this one should go with it too https://launchpad.net/ubuntu/+source/nvidia-settings-tesla-418
[12:27] <apw> tseliot, yeah ... both done
[12:27] <tseliot> apw, thanks again
[13:23] <cpaelzer> hiho, why is wal2json in update_excuses complaining about "missing build on armhf: postgresql-12-wal2json (from 2.0-1)"
[13:23] <cpaelzer> the whole point of 2.0-2 was to drop armhf and i386
[13:24] <cpaelzer> please do not that is misses the "2.0-1" binary
[13:24] <cpaelzer> but this is for 2.0-2
[13:25] <cpaelzer> or it misses the armhf binary "coming from 2.0-1"
[13:25] <cpaelzer> but never the less - the current 2.0-2 doesn't want to have the armhf/i386 binaries
[13:25] <cpaelzer> anything I can do to resolve that and get it moving again?
[13:26] <cjwatson> Because 2.0-1 was built on armhf in focal-proposed and not migrated, and proposed-migration doesn't automatically handle that case
[13:26] <cjwatson> I'll remove it by hand
[13:26] <cpaelzer> Full discplaimer: in a few days hopefulyl there will be a 2.1-1 which will re-add armhf/i386 but I'd prefer not to rely on that
[13:26] <cpaelzer> cjwatson: ah so it really is because 2.0-1 had armhf and it is now missing
[13:26] <cpaelzer> thanks cjwatson
[13:27] <cjwatson> done
[13:27] <cpaelzer> great, checking back later how migration goes on then
[13:46] -queuebot:#ubuntu-release- Unapproved: shim-signed (eoan-proposed/main) [1.39.1 => 1.41] (core) (sync)
[13:46] -queuebot:#ubuntu-release- Unapproved: shim (eoan-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
[13:46] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.41] (core) (sync)
[13:46] -queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
[13:47] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.5 => 1.41] (core) (sync)
[13:47] -queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu1] (core) (sync)
[13:47] <juliank> xnox: ^ shims for everyone :)
[13:47] <juliank> Not sure how this is going to work SRU wise, as we don't have an SRU bug number
[13:48] <juliank> last one did not have one either, though
[13:48] <xnox> juliank:  blame the guy who quit! =)
[13:49] <juliank> We can reuse my bug, and tag it update-excuses maybe?
[13:49] <juliank> idk
[13:49] <juliank> certainly we can tag it block-proposed-{xenial,bionic,eoan}
[13:49] <juliank> idk
[13:49] <xnox> oooh update-excuse yeah
[13:49]  * xnox ponders if update-excuse tag should be renamed to udpate-excuses
[13:51]  * RikMills wonders who decided that a test error should show a red grinning face emoji
[14:17] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1071.81] (kernel)
[14:24] <infinity> RikMills: I believe the "design" (I use that term loosely) of most of that UI was pitti.
[14:25] <rbalint> sil2100, could you please drop current ec2-instance-connect srus from from the unapproved queue? I'm about to upload a new set instead
[14:38] <juliank> hmm should I only have copied shim, and not shim-signed?
[14:38]  * juliank confused
[14:38] -queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-release/partner) [<IP_ADDRESS>-0ubuntu1 => <IP_ADDRESS>-0ubuntu1] (no packageset) (sync)
[14:39] <juliank> or should I have used proper backport SRUs for shim-signed, so that we get an SRU bug in there?
[14:40] <juliank> wiki page just said copy binaries, but shim-signed seems to have been uploaded with version per release
[15:07] <apw> juliank, if i am remembering correctly (and that is questionable) we have switched things like enforcement at different times which might have necessitated skew
[15:08] <juliank> Hmm
[15:09] <juliank> I think those should be hardcoded in the binaries, and they're the same
[15:09] <juliank> but surrounding might be different
[15:09] <juliank> e.g. update-secureboot-policy
[15:09] <juliank> someone should probably reject the shim-signed uploads
[15:10] <juliank> and then they need redoing
[15:10] <juliank> Well, eoan probably nobody cares
[15:11] <juliank> ah we do
[15:12] <juliank> Yup gotta redo those
[15:12] <apw> juliank, so reject the lot, or just -signed
[15:12] <juliank> apw: just signed is fine, if you reject all, I could copy the unsigned ones back, though, it doesn't really matter
[15:13] <apw> juliank, ack
[15:15] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (bionic-proposed) [1.41]
[15:15] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (eoan-proposed) [1.41]
[15:15] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1071.81]
[15:15] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [sync] (xenial-proposed) [1.41]
[15:15] <apw> juliank, ^
[15:15] <juliank> thanks, apw
[15:44] -queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (eoan-proposed) [0.102.1+dfsg-0ubuntu<IP_ADDRESS>]
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (bionic-proposed) [0.102.1+dfsg-0ubuntu<IP_ADDRESS>]
[15:59] <slashd> Big thanks sil2100 ^
[16:07] -queuebot:#ubuntu-release- Unapproved: accepted clamav [source] (xenial-proposed) [0.102.1+dfsg-0ubuntu<IP_ADDRESS>]
[16:08] <sil2100> yw!
[16:19] <bashfulrobot> infinity: I'm just curious. Are you by chance aware as to when the LTS applications have to be in by?
[16:29] -queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (bionic-proposed) [1.1.12+dfsg1-0ubuntu2~18.04.0]
[16:29] -queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (eoan-proposed) [1.1.12+dfsg1-0ubuntu2~19.10.0]
[16:30] -queuebot:#ubuntu-release- Unapproved: rejected ec2-instance-connect [source] (xenial-proposed) [1.1.12+dfsg1-0ubuntu2~16.04.0]
[16:40] <sil2100> vorlon: hey! Looking at the xenial queue, I see a new ibm-java80 for partner, but the target destination seems to be the Release pocket - guess when I accept it, it will bypass partner proposed, right?
[17:08] -queuebot:#ubuntu-release- New source: python-gffutils (focal-proposed/primary) [0.10.1-1ubuntu1]
[17:34] <vorlon> sil2100_: yeah, if it's targeted to the release pocket, that's the case
[17:34] <vorlon> dannf: ^^
[17:40] <dannf> vorlon, sil2100_ ah, sorry - probably me failing at trying to use copy-package again. should i retry w/ --to-suite xenial-proposed?
[17:41] <vorlon> dannf: yes please :-)
[17:41] <dannf> vorlon: ok - that looks better.
[17:42] -queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [<IP_ADDRESS>-0ubuntu1 => <IP_ADDRESS>-0ubuntu1] (no packageset) (sync)
[17:56] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.37~18.04.5] (core)
[17:58] <vorlon> sil2100_: ^^ if you're doing reviews, this is a one-liner fix for a regression in the previous -proposed upload
[18:09] <sil2100_> vorlon: on it o/
[18:19] <sil2100_> vorlon: is this also fixing the previous issue? Since the previous LP bug got lost in the .changes, probably needs a reupload with -v
[18:20] <vorlon> sil2100_: I can do that
[18:20] <vorlon> plz reject
[18:21] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.4 => 1.37~18.04.5] (core)
[18:22] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.5]
[18:22] <vorlon> rbalint, xnox: should LP: #1860432 be wontfix for systemd?  sounds like juju is going to change their behavior
[18:23] <xnox> i still wanted to at least file an upstream issue about it
[18:25] <doko> so we still have a lot of b-d's on python and python-dev, which showed up in NBS a while ago. but not anymore. why not?
[18:26] <vorlon> doko: because python and python-dev are not NBS because they have been removed?
[18:26] <vorlon> they were uninstallable, so there was no reason in terms of archive consistency to keep them around in the release pocket
[18:26] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.5]
[18:27] -queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [sync] (xenial-proposed) [<IP_ADDRESS>-0ubuntu1]
[18:27] -queuebot:#ubuntu-release- Unapproved: rejected ibm-java80 [sync] (xenial-release) [<IP_ADDRESS>-0ubuntu1]
[18:28] <doko> ok, then I assume we need to setup a transition tracker to point out the remaining ones
[20:14] -queuebot:#ubuntu-release- New binary: icu [amd64] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[20:14] -queuebot:#ubuntu-release- New binary: icu [s390x] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[20:15] -queuebot:#ubuntu-release- New binary: icu [i386] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[20:15] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[20:23] -queuebot:#ubuntu-release- New binary: icu [armhf] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[20:29] -queuebot:#ubuntu-release- New binary: icu [arm64] (focal-proposed/main) [65.1-1ubuntu1] (core, i386-whitelist)
[21:14] <mwhudson> vorlon: ok https://autopkgtest.ubuntu.com/running#pkg-docker.io is hanging, if you could log in and run ps / lsof / strace any likely looking things / etc that would be great
[21:17] <ddstreet> infinity i see you're listed in the sru rotation for today, though i'm not sure if that's still accurate, but if it is could you release qemu for b/e and network-manager for e
[21:45] <vorlon> mwhudson: ps: https://paste.ubuntu.com/p/Yp84qQWhp2/
[21:46] <vorlon> mwhudson: docker ps: https://paste.ubuntu.com/p/48jhgHGY7s/
[21:49] <vorlon> mwhudson: lsof/strace on the 'docker run': https://paste.ubuntu.com/p/tTVWNJ79H9/
[21:50] <vorlon> mwhudson: a second 'docker run' also hangs
[21:56] <mwhudson> vorlon: can you strace the containerd-shim process?
[21:57] <mwhudson> vorlon: also lsof
[22:25] <mwhudson> vorlon: ideally before the test times out :)
[22:27] <vorlon> mwhudson: there are 2 containerd-shim processes, do you know if I should be looking at parent or child?
[22:28] <mwhudson> vorlon: i only see one in your first ps listing, is that because you ran docker run again?
[22:28] <vorlon> oh, maybe?
[22:28] <mwhudson> https://paste.ubuntu.com/p/Yp84qQWhp2/ only has 8092
[22:28] <vorlon> right, it's not parent/child
[22:28] <mwhudson> aiui docker run talks to dockerd talks to containerd
[22:29] <vorlon> mwhudson: https://paste.ubuntu.com/p/bJ4CKfS6tS/
[22:30] <vorlon> the thread eventually woke up again, but it's just more futex/nanosleep nonsense
[22:30] <mwhudson> yeah that's doing a whole lot of nothing isn't it
[22:31] <mwhudson> i wonder if there's any way to see what the eventpoll things are
[22:35] <mwhudson> yeah i definitely think that containerd-shim should have exited
[22:35] <mwhudson> biab
[22:58] <mwhudson> vorlon: i don't suppose it'll reveal much but "ls -l /var/lib/containerd/io.containerd.runtime.v1.linux/moby/c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a/" ?
[22:59] <mwhudson> vorlon: and maybe ls -l /run/docker/containerd/
[23:01] <mwhudson> vorlon: also can you gdb -p to a containerd-shim and 'thread apply all bt' or whatever that command is?
[23:02] <mwhudson> hm might need to install the ddeb for that to be at all useful :(
[23:02] <vorlon> mwhudson: $ sudo ls -l /var/lib/containerd/io.containerd.runtime.v1.linux/moby/c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a/
[23:02] <vorlon> total 0
[23:02] <vorlon> prwx------ 1 root root 0 Feb 10 21:05 shim.stderr.log
[23:02] <vorlon> prwx------ 1 root root 0 Feb 10 21:05 shim.stdout.log
[23:02] <vorlon> $ sudo ls -l /run/docker/containerd/
[23:02] <vorlon> total 0
[23:02] <vorlon> drwxr-xr-x 2 root root 80 Feb 10 21:05 c37559527799313b65be7e8b63736947312b28986a3d6fcf3ee9a5a20cdd415a
[23:03] <vorlon> drwxr-xr-x 2 root root 80 Feb 10 21:50 f8d72d17248ce5eb41b87f63a63c7507332bee28f7bee0214a79e3f60c09cff7
[23:03] <mwhudson> hm no we don't strip go things still
[23:03] <mwhudson> hm no apparently we do but there is no ddeb on https://launchpad.net/ubuntu/+source/containerd/1.3.1-0ubuntu1/+build/18193736 ?
[23:04] <vorlon> heh oops
[23:04] <mwhudson> how did we manage that
[23:04] <vorlon> ask the go maintainers
[23:04] <mwhudson> yeah unfortunately that's me
[23:05] <vorlon> mwhudson: yeah, a whole lot of No symbol table info
[23:06] <mwhudson> ah upstream Makefile
[23:06] <mwhudson> ifndef GODEBUG
[23:06] <mwhudson>         EXTRA_LDFLAGS += -s -w
[23:06] <mwhudson> ffffffffffffuuuuuuuuuuuu
[23:12] <mwhudson> oh heh i have containerd 1.3.2 in git locally
[23:16] <vorlon> I do not think I want to define a God EBUG
[23:17] <mwhudson> oh wait maybe we want this fix https://github.com/containerd/containerd/pull/3857
[23:17] <mwhudson> so maybe if i just upload things will start working by magic
[23:17] <gitbot> containerd issue (Pull request) 3857 in containerd "Fix container pid race condition." [Cherry-Pick/1.3.X, Cherry-Picked/1.3.X, Priority/P0, Closed]
[23:24] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
[23:28] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
[23:28] -queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.7-2 => 1.3.7-3] (core)
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.7-3]
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.7-3]
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.7-3]
[23:44] -queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [s390x] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
[23:51] -queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [amd64] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)
[23:54] -queuebot:#ubuntu-release- New binary: qtlocation-opensource-src [ppc64el] (focal-proposed/universe) [5.12.5+dfsg-5] (i386-whitelist, kubuntu, qt5)


[00:48] <robru> oh
[00:49] <robru> Ursinha: what's happening? is stuff working now? looks like silo 20 migrated
[00:57] <Ursinha> robru: it's slowly coming together
[00:57] <robru> Ursinha: I'm confused as hell. train migration thinks 27.1 is in wily and thus merged, but lp reports latest wily version of media-hub as 22 (eg the proper 27.1 is nowhere to be found)
[00:59] <Ursinha> robru: uh, I can understand there will be lots of inconsistencies, or might be, I'd ask wgrant for advice there
[01:01] <wgrant> robru: https://launchpad.net/ubuntu/+source/media-hub will only show things that are published. https://launchpad.net/ubuntu/+source/media-hub/+publishinghistory would have shown 27.1 as pending at the time of your query.
[01:03] <robru> wgrant: thanks, I see it now
[01:51] <kenvandine> jgdx, :(
[01:51] <kenvandine> random failures suck
[06:39] <oSoMoN> good morning
[06:40] <oSoMoN> ubuntu-qa: migration of oxide-qt and webbrowser-app from proposed to release in wily is blocked by a boottest regression, both of them seem to be bug #1421009 (timed out waiting for Unity greeter), can these tests be re-run please?
[06:58] <jibel> Hey oSoMoN, cihelp ^ can you help ?
[07:34] <seb128> cihelp is anyone working on making those boot test reliable?
[07:34] <seb128> the current address-book-app version is blocked the same way
[07:34] <seb128> the log indicates "EnvironmentError: Unsupported device, autodetect fails device" as the error
[07:34] <seb128> not likely something due to the addressbook itself in this case
[07:36] <seb128> shrug
[07:37] <seb128> sil2100, Mirv, pmcgowan, slangasek, I guess that's not wanted but my bq which was on  rtm-proposed got the vivid update but apparently non-bq version
[07:38] <seb128> e.g it lost HERE, cut the rope, today's lens, etc
[07:38] <seb128> shrug, I knew I shouldn't have applied that update and waited for more feedback from others :-/
[07:55] <Mirv> seb128: urgh. I think there was some channel change before too, those definitely need to be correct.
[07:56] <seb128> do you know how I can fix my device to get my apps/lenses back
[07:56] <seb128> ?
[08:12] <Mirv> seb128: no I don't know (for sure), even though flashing an older image should work
[08:13] <seb128> Mirv, right, I especially don't want to do that
[08:13] <seb128> it's my main phone
[08:14] <seb128> I don't want to wipe it
[08:27] <Mirv> seb128: shouldn't flashing a system image be safe, in general? to user data.
[08:27] <Mirv> without --wipe etc
[08:27] <Mirv> it'd help if we had good backup functionality..
[08:29] <seb128> Mirv, I don't want to do that, I want the upgrade to be fixed for everyone
[08:31] <Mirv> sil2100: hangouts or no hangouts today?
[08:31] <Mirv> seb128: sure, if it's not only rtm-proposed -> vivid it's completely broken, and pretty broken even if it's just rtm-proposed -> vivid
[08:32] <popey> landing call toay?
[08:32] <popey> *today
[08:32] <Mirv> no-one yet besides me, I guess it's up to sil2100 to decide
[08:34] <seb128> Mirv, I didn't change anything, my phone is on rtm-proposed for ever
[08:35] <seb128> Mirv, and that just proposed me an upgrade that wiped out HERE and cut the rope and the bq lenses
[09:30] <pstolowski> trainguards hey, a question; since landings are closed for vivid-overlay atm, what happens to 'dual' landings? will packages be released to wily but queue up and blocked for vivid-overlay?
[09:33] <seb128> I guess no cihelp this yesterday?
[09:33] <seb128> since*
[09:37] <alf_> cihelp: Hi! I would like to change the default parameters of the mir-mediumtests-runner-mako job to add another test suite to run ('mir_privileged_tests').
[09:49] <Mirv> pstolowski: I'd think both are blocked since the landing line is blocked waiting for QA signoff until QA starts again with the queue.
[09:50]  * Mirv hasn't yet published any dual landings, not sure if half of it can be done earlier and half later
[09:54] <pstolowski> Mirv, oh, i see the problem. but that's not good :(
[09:58] <Mirv> pstolowski: the development focus for now is vivid, so delaying wily as itself is not that bad. but it breaks the _flow_ of development if something tested cannot be QA signoff:d / landed so hopefully the gates would be reopened sooner rather than later. but I fear it might be another week.
[09:58] <pstolowski> Mirv, ack :(
[09:59] <Mirv> pstolowski: https://ci-train.ubuntu.com/job/prepare-silo/5048/console some non-MP url:s, could you fix?
[10:01] <pstolowski> Mirv, fixed, sorry about that!
[10:08] <Mirv> thanks!
[10:49] <oSoMoN> cihelp: anyone around to help me with those oxide-qt and webbrowser-app packages blocked in -proposed because of a boottest failure?
[10:58] <Mirv> oh right sil2100 is away today, I had even marked it on my calendar :) well, no-one has anything specific to ask from sil anyway so far.
[10:59] <Mirv> seb128: I still don't seen an actual answer on why you got to vivid from rtm-proposed, but I guess the answer is that only the new ones documented at https://wiki.ubuntu.com/Touch/Channels are "supported" in a sense
[11:00] <Mirv> seb128: I assume current rtm non-proposed channelers will be guided correctly to the ubuntu-touch/stable/bq-aquaris.en
[11:01] <jibel> oSoMoN, I triggered boottests for oxide-qt and webbrowser-app
[11:01] <oSoMoN> jibel, thanks
[11:18] <Mirv> if the boottest problems have reappeared on wily, they should be investigated (when did they start?). the problem was resolved/workarounded on vivid.
[11:19] <Mirv> if it's the same problem in the first place.. that can be seen with the bug report's test case and attaching to the unity8 process.
[11:29] <jibel> oSoMoN, webbrowser passed but oxide-qt failed in test getpkgsrc
[11:31] <oSoMoN> jibel, what does that test do?
[11:31] <jibel> oSoMoN, I have no idea, I don't maintain oxide :)
[11:32] <oSoMoN> jibel, this is not an oxide test
[11:34] <psivaa> oSoMoN: jibel: Failures in boottesting with oxide-qt is known and iirc, the release team does add hint for that to be forced
[11:35] <oSoMoN> psivaa, who do we need to ping to get that whitelisted?
[11:35] <psivaa> oSoMoN: someone in the release team, afaik
[11:35] <psivaa> Foundations i suppose
[11:42] <jibel> psivaa, getpkgsrc is something specific to boottest?
[11:43] <psivaa> jibel: for oxide-qt in phones getpkgsrc doesn't have enough space
[11:43] <jibel> psivaa, OK
[11:43] <jibel> psivaa, maybe it should fail with an error a human can understand?
[11:45] <Laney> It should probably not fail in a way that requires a release team override
[11:45] <Laney> Can someone fix that?
[11:47] <seb128> is somebody supposed to watch the cihelp thing?
[11:47] <Laney> yes
[11:48] <Mirv> the CI team, but I've found cihelp doesn't respond much during early EU hours, more like during afternoon and then onwards. I've been thinking that it should be clearer if the messages go to /dev/null or if they're being logged.
[11:49] <Mirv> the trainguards tag does work since at least me and robert have IRC on 24h so we can take a look at even past requests. but if CI team doesn't have anyone with IRC in a shell it doesn't work and the requesters don't get notified that no-one is listening
[11:49] <jibel> psivaa, looking at getpkgsrc you don't need the source package to find the list of binaries to install, you have all the information you need in the apt index files
[11:50] <Laney> Mirv: In that case maybe it would be better if there were to be a named vanguard in the topic
[11:50] <Laney> So you can know whether to expect service or not
[11:50] <psivaa> ping to cihelp will be answered by the vanguard of the day and most of the days the vanguards are not in the EU timezone
[11:54] <psivaa> jibel: boottesting has some other issues too and is not in the current backlog to take deeper look at... if you would not mind sending an email to the team about any issues that you find it would help
[11:55]  * psivaa slaps him both sides for answering when he is not vanguard
[11:55] <Laney> psivaa-lunch: should we disable it then?
[11:55] <Laney> for wily
[11:55] <Laney> I'm interested in people not wasting their time looking at issues
[11:58] <jibel> Laney, it is not my call but there is no way this test will ever pass, it tries to unpack a package bigger than the physical space available on the device.
[11:59] <jibel> Laney, and the history in jenkins shows that it never passed, and there is no reason to mark it as regression in update_excuses
[12:00] <Laney> jibel: Mmm. Who gives britney that information?
[12:01] <jibel> Laney, CI would know, I never worked on boottest
[12:01] <Laney> Is it their side and not britney's side?
[12:05] <seb128> Mirv, I tried to ping cihelp yesterday european afternoon, this european morning and this european midday, so basically all around the clock on a day and nobody seems to read those...
[12:05] <seb128> ev, ^ is anybody supposed to watch cihelp?
[12:09] <Mirv> seb128: yes, it's most of all that CI is not in Europe at all. usually I've gotten some response at some point in my afternoon, but never in my morning.
[12:09] <seb128> Mirv, well, as said I tried in the afternoon yesterday
[12:09] <Mirv> yep
[12:09] <seb128> and they had all night to look at the issue
[12:09] <seb128> it's a bit ridiculous things just get blocked and ignored this way
[12:10] <Mirv> I agree the 'cihelp' tag should be stopped to be advertised when there's no-one to hear it
[12:11] <cprov> seb128: I was the slack vanguard yesterday (UTC-3), it's probably my personal fault, not the team's. We all watch IRC around the clock (irccloud, mostly)
[12:11] <seb128> cprov, hey
[12:12] <seb128> cprov, how are you?
[12:12] <seb128> cprov, maybe you can help today then? ;-)
[12:13] <cprov> seb128: hey! yes, always. Can you re-paste the issue and save me the time to find it in the logs ... yesterday was pretty hectic on us (PS4 outage)
[12:14] <seb128> cprov, basically address-book-app is blocked in wily-proposed because it has "boot regression" (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[12:14] <seb128> cprov, https://jenkins.qa.ubuntu.com/job/wily-boottest-address-book-app/1/console
[12:15] <seb128> cprov, the error is "EnvironmentError: Unsupported device, autodetect fails device" so I doubt it's something due to the package
[12:15] <Laney> jibel: Looks like boottest doesn't have this concept of regressions
[12:15] <Laney> s/regressions/always failed/
[12:16] <seb128> Laney, are we talking about the issue problem or just similar ones on different packages? ;-)
[12:16] <seb128> the same problem*
[12:16] <Laney> seb128: not the same
[12:16] <seb128> k
[12:16] <cprov> seb128: okay, I am on it, looks like a retry would sort it out, but let me find exactly what caused it
[12:16] <seb128> cprov, it has been retried
[12:16] <seb128> cprov, https://jenkins.qa.ubuntu.com/job/wily-boottest-address-book-app/2/console is the same
[12:17] <seb128> well "retried"
[12:17] <seb128> it's a new upload
[12:17] <seb128> but that's another run and it hit the same error
[12:18] <Laney> jibel: Where did you find the source of the test script? It might be easier to try to fix it or at least make it skip rather than fail
[12:18] <jibel> Laney, lp:ubuntu-test-cases/touch
[12:18] <Laney> thx
[12:18] <jibel> Laney, I found it from the console output
[12:18] <Laney> yeah I'm sure it's in there
[12:19] <Laney> but ... it's pretty hard to read and I knew you had found it :)
[12:19] <cprov> seb128: there was a phone recovering-task at some point last afternoon, let me check if it already helped this issue. If not we will dig further
[12:19] <seb128> cprov, thanks, let me know if I should file a bug about that or something
[12:20] <cprov> seb128: will do
[12:30] <cprov> seb128: it's behaving nicer this time -> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-address-book-app/3/console
[12:30] <seb128> cprov, great, do you know what happened in the previous tries? is that a flacky test? is somebody working on making it more reliable?
[12:32] <cprov> seb128: the phone provisioning has a potential/subtle issue and we are working on isolating and fixing it. It's rare, but known at this point.
[12:32] <seb128> k
[12:33] <seb128> is there any report I can subscribe to to see work ongoing there?
[12:34] <cprov> seb128: I wil have to double-check with plars in a bit when he starts, I will subscribe you.
[12:34] <Ursinha> Mirv: seb128, cihelp is the CI vanguard of the day, and as psivaa-lunch said most of us aren't in EU timezone
[12:34] <seb128> cprov, thanks
[12:35] <Ursinha> yesterday there was the outage and we had to firefight that moving to old infrastructure
[12:35] <cprov> seb128: and you have a test-pass
[12:35] <seb128> cprov, thanks!
[12:36] <Mirv> Ursinha: yep, thanks, it's as I thought it was. it might be useful to respond with something to the early EU requests so that they don't feel like going to /dev/null.
[12:36] <seb128> Ursinha, ok, fair enough, I did ping first yesterday on 13:30 utc (http://irclogs.ubuntu.com/2015/05/28/%23ubuntu-ci-eng.html#t15:24), which was after start of day for U.S and several hours before the outage, still got no reply at all, not even an ack that somebody read the ping
[12:41] <Ursinha> seb128: sorry we overlooked your request, if that happens again and you don't mind pinging us again that helps (I've replied to several requests yesterday but I missed yours)
[12:41] <cprov> seb128: when it happens, please escalate to ev or Ursinha, email, phone ... don't be blocked, ever.
[12:43] <Ursinha> Mirv: and what cprov said :) when we don't reply we're not ignoring you, we're just really busy possibly firefighting something else, but we'll always try to get to all requests
[12:43] <cprov> seb128: and since I was the vanguard, the shame is on me.
[12:45] <seb128> Ursinha, hey, no worry, thanks
[12:45] <seb128> cprov, don't be too harsh, I guess I just got unlucky the few times I used "cihelp"
[12:45] <seb128> but as Mirv pointed out, that system doesn't give you back any feedback that your request/question is going to be read
[12:46] <Ursinha> we need a cibot
[12:46] <Ursinha> :)
[12:46] <seb128> so it's easy to get lost wondering if you did the right thing
[12:46] <seb128> if we used bugs or a ticket system you could see the status
[12:46] <Ursinha> "your request is really important to us. please wait on hold while there is no vanguard available"
[12:47] <Laney> cprov: hmm, you know boottest, right?
[12:47] <Laney> cprov: does getpkgsrc have a purpose or can I replace it with a call later on to apt-get source --diff-only?
[12:48] <Ursinha> seb128: that is an interesting idea that might have been suggested and discarded at some point, I'll go today and figure out how to improve that
[12:49] <cprov> Laney: I can't tell you precisely, but how would "apt-get source --diff-only" be better in that case ?
[12:49] <Laney> cprov: oxide-qt's test fails because it is too big to be downloaded to whatever device is being used
[12:49] <Laney> I don't see that it is necessary to download the whole source
[12:50] <Laney> you just copy its debian directory out
[12:50] <seb128> Ursinha, thanks
[12:50] <jibel> Mirv, can you assign an id to lines 22 and 23 of the tarballs sheet?
[12:51] <jibel> I tried from the menu as sil2100 told me but it did assign anything
[12:51] <jibel> didn't*
[12:54] <cprov> Laney: I see, the big-sources issue. It looks like a good idea that I don't remember being mentioned before. I will check with team how it could work and will get back to you, okay ?
[12:55] <Laney> cprov: I have a MP, let me propose it and we can discuss there
[12:55] <cprov> Laney: fantastic! thank you
[13:04] <Laney> cprov: https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[13:04] <Laney> cprov: Sorry to be annoying but it's blocking oxide-qt so I'd appreciate it if someone could review soon-ish :)
[13:05] <Laney> I could skip it but then we lose the real-world test cases
[13:05] <Laney> s/cases/case/
[13:05] <Laney> oSoMoN: ^ btw this is a fix for your issue
[13:07] <Mirv> jibel: sure
[13:07] <jibel> Mirv, sorry, I finally did it
[13:07] <Mirv> jibel: oh, ok :)
[13:07]  * Laney goes to lunch
[13:08] <jibel> Mirv, the requests were not marked 'tested'
[13:08] <Mirv> I haven't used the tarballs sheet myself either
[13:10] <oSoMoN> Laney, awesome, thanks!
[13:12] <plars> cprov: seb128: was there anything else you needed me to look at related to that device? We did see a problem on it yesterday and cprov fixed it iirc, which probably helped clear this up also
[13:12] <seb128> plars, seems fine now, so nothing else from my side for the moment, thanks
[13:27]  * Mirv preparing for sprint, next up in guarding train robert in ~3h. I'll try to glance here though as sil is away today.
[14:22] <oSoMoN> trainguards: can I have a silo for line 59 please?
[14:47] <Mirv> oSoMoN: 001
[14:47] <oSoMoN> Mirv, thanks!
[14:50] <oSoMoN> Mirv, what does this mean? ERROR webbrowser-app 0.23+15.10.20150522.1-0ubuntu1 is missing from the changelog, which has up to 0.23+15.04.20150522.1-0ubuntu1. Please sync destination version back to trunk.
[14:55] <Mirv> oSoMoN: I'm eod and on phone already so I can't check well, but sounds like vivid - wily version clash.
[14:56] <oSoMoN> yeah, I guess it’s expecting wily entries in the changelog, but lp:webbrowser-app only has vivid entries, because so far everything landed first in vivid and was then synced back to wily
[15:02] <jibel> kgunn, ^ silo 19 passed verification, but won't be published to vivid, only wily. correct?
[15:04] <kgunn> jibel: it does actually need to be both...
[15:05] <kgunn> vivid+overlay was in an incorrect state, qtubuntu using an old libmircommon version
[15:05] <kgunn> it obvisously didn't break anything in vivid+overlay since it passed everyones testing
[15:06] <kgunn> but was wrong
[15:06] <kgunn> wily proposed is truly stuck, so we really need to land it there
[15:07] <kgunn> jibel: another way to look at it, that qtubuntu landing _should_ have been part of our original mir0.13.0 landing
[15:07] <kgunn> for vivid+overlay
[15:07] <jibel> kgunn, I understand, publication to vivid will have wait until the image is released. There will be a rebuild to include the last location fix and we don't want silo 19 in.
[15:18] <kgunn> jibel: ok, i understand....wily is the real problem
[15:18] <kgunn> we've clogged the proposed pipe
[15:21] <kgunn> jibel: i noticed alan_g had picked "dual landing" so will it still auto-magically go into wily, even tho it's being held out of vivid+ ??
[15:21] <kgunn> actually might be a question for trainguards ^
[15:35] <kgunn> gotta go dark for a sec
[15:38] <slangasek> seb128: the previous channels had a lot of ambiguity wrt things having the BQ custom or not, and there is no way to redirect a channel to different new channels for the different devices in the channel.  If you want the BQ custom, you should re-flash from one of the bq-aquaris.en channels
[15:39] <seb128> slangasek, couldn't we just not redirect those users and let them opt in to the right channel manually?
[15:39] <slangasek> seb128: as for "fixed for everyone", you were on a -proposed channel, and -proposed channels are meant for developers not users
[15:39] <ogra_> slangasek, then we should block the old channel
[15:39] <ogra_> and not point it to a communiity one
[15:39] <slangasek> seb128: you can do that right now by re-flashing
[15:39] <seb128> slangasek, that's the point, let users do that, rather than propose them an update that screw their device
[15:40] <gQuigs> so it looks like apt (http://people.canonical.com/~ubuntu-archive/pending-sru.html) is stuck as "In Progress"   any idea how to get that reset?
[15:40] <gQuigs> (for precise)
[15:40] <ogra_> you can switch channels very easily with the system-image-cli --switch command ... and i know many bq users did that to switch to a more recent dogfood channel (14.09-proposed) to help finding bugs
[15:41] <ogra_> these users all end up without HERE and without the bq custom stuff with todays update
[15:41] <seb128> that's going to teach them to try to help testing :p
[15:41] <ogra_> yeah
[15:41] <slangasek> seb128: how does this "screw" the device?  It just gives you different content and you have to reflash
[15:41] <slangasek> leaving you on a stale image is also "screwing" the device
[15:41] <ogra_> slangasek, i dont mind either way, but blindly switching users without announcement is slightly evil i think
[15:41] <seb128> slangasek, well, it wiped out some of my config and the apps I use
[15:42] <seb128> HERE, today's scope, ...
[15:42] <slangasek> I'm happy to send out an announcement today
[15:42] <slangasek> seb128: it shouldn't have wiped the config
[15:42] <slangasek> it removes the apps, which you'll get back when you reflash
[15:42] <ogra_> there should at least be an annoncement how to use system-image-cli to switch to a sane channel again
[15:42] <seb128> slangasek, well, unity8 goes "oh, those scope in your config don't exist anymore, they are invalid, let's clean out"
[15:42] <slangasek> oh really
[15:42] <ogra_> re-flashing means you need a PC
[15:42] <slangasek> ok, that's bad
[15:42] <seb128> that as well
[15:42] <slangasek> yes, I'll drop the redirect channel
[15:42] <seb128> thanks
[15:43] <slangasek> well, system-image-cli --switch too
[15:43] <ogra_> yeah, i thinnk thats the easier option
[15:44] <slangasek> seb128: ubuntu-touch/ubuntu-rtm/devel-proposed was the one we were advertising?
[15:44] <ogra_> yeah, ubuntu-touch/ubuntu-rtm/14.09-proposed was the alias
[15:44] <ogra_> (or the other way round, not sure)
[15:44] <slangasek> yes, I'm not after the alias but the name that was in the documentation
[15:45]  * ogra_ has ubuntu-touch/ubuntu-rtm/14.09-proposed in channel.ini
[15:45] <seb128> slangasek, I'm unsure if it was devel- or 14.09-
[15:45] <seb128> I had 14.09
[15:45] <slangasek> the one ogra_ showed me yesterday was ubuntu-touch/ubuntu-rtm/devel-proposed
[15:45] <ogra_> but i dont think we advertised the versioned channels recently
[15:46] <ogra_> knowing they are dead ends
[15:46] <slangasek> it wasn't the 14.09 one, that one had already been changed
[15:46] <ogra_> well, what i showed yesterday was my active krillin ... curremntly on #277 offering me an update to 233
[15:47] <ogra_> (which i didnt apply after reading sebs mail)
[15:47] <slangasek> I've removed the ubuntu-touch/ubuntu-rtm/devel-proposed redirect now
[15:47] <seb128> slangasek, thanks
[15:48] <ogra_> urgh ... i just noticed my krillin only has 39MB free
[15:48] <ogra_> i guess i'll find oout this weekend what happens when i hit the limit
[15:58] <jibel> trainguards, could you publish silo 19 to wily but not to vivid or the overlay ppa?
[16:36] <robru> jibel: yes that can be done, but it involves deleting the vivid packages. is that ok, or should we copy those somewhere safe first?
[16:41] <robru> Mirv: publishing a silo will publish what it finds in the PPA (even if you reconfigure it not as a dual landing!) so if you want to publish only the wily pckages from a dual, you have to delete the vivid packages.
[16:42] <robru> cihelp: can I get a boottest retry on https://jenkins.qa.ubuntu.com/job/wily-boottest-oxide-qt/  ? thanks
[16:42]  * ev looks
[16:44] <robru> ev: oh a couple more here too: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-themes
[16:44] <ev> why are we retrying these?
[16:45] <Laney> these boottests seem seriously fragile
[16:45] <Laney> did it get worse?
[16:46] <robru> ev: because those packages are blocked in proposed?
[16:47] <robru> Laney: yeah I see this a lot, stuff held in proposed because of failed boottest, retry and it works.
[16:47] <ev> retry without understanding if the failure is the test itself?
[16:47] <robru> ev: well I don't know much about boottest. all I know is that I've never seen one that failed honestly. I've only ever seen false positives that went away after retrying.
[16:48] <ev> are you going to retry every time there's a failure at all?
[16:48] <robru> ev: so far it seems like the right approach, if the failure is never indicative of an actual problem in the package.
[16:48] <Laney> it's easy to scan the log to see if it's a real failure
[16:48] <Laney> for example: https://jenkins.qa.ubuntu.com/job/wily-boottest-ubuntu-themes/lastBuild/console
[16:48] <Laney> it tells you that boottest passed and then something blew up afterwards
[16:51] <Laney> this happens so frequently that it's probably worth looking into though
[16:51] <Ursinha> Laney: we will next week
[16:51] <Laney> great
[16:51] <robru> Laney: ev: so you guys think it's legit that a change in ubuntu themes causes a timeout loading unity greeter? my money's on infra issue, needs to be retried.
[16:51] <Ursinha> two cases that are on our radar for investigation and fix are the src being too large (like oxide-qt) and the provisioning having problems
[16:52] <Ursinha> robru: timeout loading unity greeter was a legit bug
[16:52] <Laney> robru: No I explicitly think that this is an infrastructure problem, I'm on your side here
[16:52] <Laney> Ursinha: I filed a merge proposal for that first issue
[16:52] <Ursinha> not in the infra
[16:52] <ev> robru: if there's an underlying bug in unity greeter we should push on that to get fixed, not continously hit CI with the retry hammer
[16:52] <ev> the latter is a great way to paper over serious bugs
[16:52] <robru> Laney: ok thanks. I just find so many stuck boottests that I just ask to retry them without looking at the log anymore.
[16:52] <Laney> Ursinha: if someone wants to review that :)
[16:53] <ev> Laney: where is this?
[16:53] <ev> I'll happily do so
[16:53] <Laney> https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[16:53] <ev> cheers
[16:53] <Laney> oxide-qt is there as a current test case
[16:53] <robru> jgdx: kenvandine: https://ci-train.ubuntu.com/job/ubuntu-landing-036-1-build/12/console is caused by having a wily version number in trunk but having your branch targetted at vivid. you need to either do a dual landing, branch vivid, or mangle the changelog yourself
[16:55] <robru> davmor2: do we want silo 5 in vivid overlay?
[16:56] <ogra_> i think it is supposed to be part of the OTA
[16:58] <Ursinha> Laney: from the top of my head there are only two packages that have big sources, oxide-qt and boost
[16:59] <Mirv> robru: ok thanks
[16:59] <Mirv> makes sense
[16:59] <kenvandine> robru, yeah i think we'll be changing that to a backport branch
[17:00] <kgunn> trainguards hey there, will silo 19 still land/migrate to wily even tho its a dual landing and it's being held out of vivid+ (due to freeze)
[17:00] <kenvandine> jgdx, should we just kill that silo for now?
[17:00] <kgunn> wily is stuck atm for several projects until that lands
[17:00] <Mirv> kgunn: robru answered that 19mins ago. the silo contents need to be exactly what's wanted to be published, ie vivid deleted
[17:01] <robru> kgunn: yeah I need to know if you want the vivid packages deleted, or if we should copy those somewhere safe, because publishing only wily requires deleting vivid packages.
[17:01] <kgunn> thanks Mirv, i was off
[17:01] <kgunn> robru: right, we do eventually want those in vivid+
[17:02] <kgunn> it's just that vivid+ is considered locked down for those
[17:02] <robru> kgunn: ok I'll make a new silo for those and delete them from the current silo so we can publish just wily then.
[17:02] <kgunn> so happy to do whatever we're told
[17:02] <kgunn> e.g. if you can copy somewhere safe for later great
[17:02] <robru> jibel: any ETA on when vivid gates will open again? just curious.
[17:03] <kgunn> robru: and thanks, sorry it's all still a little dynamic
[17:03] <Laney> Ursinha: Maybe now, but we don't know about the future - and more importantly it seems like there's no reason to need the full source anyway
[17:04] <Mirv> mandel: tvoss: needs top-approval https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910
[17:04] <Ursinha> Laney: sure, just giving you the current situation about the packages I know that fail
[17:04] <robru> kgunn: no worries. just growing pains for the new dual landing feature
[17:04] <Ursinha> Laney: or, I agree :)
[17:05] <Mirv> or rsalveti ^ 005 top-approval
[17:06] <kgunn> thanks, i'll keep an eye on silo32 for the vivid+ thaw
[17:07] <jibel> rsalveti, ^^ can you approve the merges for silo 5?
[17:08] <robru> kgunn: ok I'm not sure why that's exploding but rest assured the packages are safe in the ppa anyway
[17:08] <jibel> robru, after OTA4 on krillin
[17:08] <kgunn> ;)
[17:09] <robru> jibel: yeah but like... how many days away is that? ;-)
[17:15] <robru> kgunn: ok more hiccups, should be publishing now
[17:17] <jibel> robru, when it is ready, sometimes next week
[17:19] <jibel> or tvoss if you're still online, there are unapproved merges in silo 5. that's the last bit we need.
[17:25] <rsalveti> jibel: Mirv: let me check
[17:26] <rsalveti> ChickenCutlass: can you review https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910 ?
[17:26] <rsalveti> I prefer not reviewing since I have no familiarity with the code
[17:28] <tvoss> jibel, top approved
[17:28] <tvoss> rsalveti, ChickenCutlass ^
[17:35] <jibel> tvoss, thanks
[17:35] <Mirv> tvoss: thanks
[17:36] <jibel> trainguards, can you publish 5 now?
[17:39] <Mirv> jibel: I did.
[17:39] <jibel> Mirv, perfect, how do I know it is available in destination and an image can be built?
[17:42] <ev> Laney: if you'd be so kind, I have a question in https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[17:43] <Mirv> jibel: when they have similar status to others at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages instead of the current symbol + arch list
[17:43] <jibel> Mirv, there is no rmadison4ppa ;)
[17:44] <Mirv> jibel: exactly..
[17:49] <jgdx> kenvandine, didn't we agree on targetting wily? :) /cc robru
[17:50] <jgdx> I'm happy to target wily now, reconfigure, then backport for vivid
[17:50] <robru> jgdx: ok will do
[17:51] <jgdx> robru, hey, thanks.
[17:52] <robru> jgdx: you're welcome
[17:52] <ahayzen> Hey, we switched focus of the music-app from lp:music-app/remix to lp:music-app/refactor and I'm now spotting double autolandings eg http://<IP_ADDRESS>:8080/job/music-app-autolanding/686/ and http://<IP_ADDRESS>:8080/job/music-app-refactor-autolanding/42/ ... does something on jenkins need to be changed to respect to change of focus?
[17:52] <robru> jgdx: kenvandine: so you'll need to reupload libqofono for wily, right now only the vivid version is in there
[17:53] <robru> ahayzen: sounds like you need cihelp
[17:53] <jgdx> kenvandine, ^r u able?
[17:53] <jgdx> kenvandine, I'd like not to kill it for at least another week.
[17:53] <ev> ahayzen: I'll have a look after lunch
[17:54] <ahayzen> ev, thanks :-)
[17:54] <ahayzen> ev, i suspect it is because there is a job based on trunk and the one on refactor just needs disabling now or something like that
[17:55] <robru> jgdx: ok silo looks good, I deleted the vivid packages so they don't accidentally get published later. if you want you can use the build job to build the wily version now
[17:55] <robru> jgdx: of system settings i mean
[17:57] <jgdx> robru, okay
[18:02] <jibel> Mirv, you confirm that silo 5 is published to the PPA and an image can be buil?
[18:02] <jibel> +t
[18:02] <kenvandine> jgdx, i already uploaded libqofono to wily
[18:03] <kenvandine> and we have the other silo for settings/apn for wily
[18:03] <kenvandine> jgdx, robru: silo 33 is the wily landing for it
[18:04] <kenvandine> i think we should free silo 36
[18:05] <jibel> ogra_, rsalveti if I trust launchpad location-service is now in the overlay PPA, can you trigger a build of vivid? (rc-proposed/meizu.en)
[18:05] <rsalveti> jibel: sure
[18:06] <jibel> rsalveti, thanks
[18:06] <ogra_> rsalveti, while you're at it, a wily build too
[18:06] <ogra_> (to see the last cdimage changes work ... i didnt get to that yet)
[18:06] <rsalveti> ogra_: sure, maybe a beer too I guess
[18:06] <rsalveti> :-)
[18:07] <ogra_> +1
[18:07] <rsalveti> done
[18:07] <rsalveti> just the beer that is a bit more complicated
[18:10] <ogra_> really ?
[18:10]  * ogra_ would hand you one from the sixpack but my arm is so short
[18:16] <rsalveti> lol
[18:31] <robru> kenvandine: hm, silo 33 doesn't have libqofono configured for it
[18:31] <robru> kenvandine: oh I see, 33 and 36 have the same MP. ok I'll free 36 then.
[18:34] <robru> jgdx: sorry for the confusion, just use silo 33, it's the same MP there.
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150529-8e13c5f.changes
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150529-8e13c5f.tar.xz
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150529-8e13c5f.ods
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-20150529-8e13c5f.changes
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-20150529-8e13c5f.tar.xz
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-testresults-20150512-3912934.ods
[18:35] <john-mcaleely> sil2100, ^ lots of device tarballs for landing early next week
[18:35] <john-mcaleely> :-)
[18:35] <kenvandine> robru, thcx
[18:35] <kenvandine> thx
[19:29] <sil2100> john-mcaleely: oh oh!
[19:29] <sil2100> I just got back, didn't have time to take a look at my IRC session
[19:29] <sil2100> john-mcaleely: how's the situation so far?
[20:25] <ogra_> sigh, so my location that worked wondeful on image 7 (like never before actually) doesnt work at all anymore in image 8
[20:25] <ogra_> (on arale)
[20:26] <ogra_> sil2100, i assume that was not the plan ?
[20:27] <ogra_> hmm, probably because location detection is now completely turned off
[20:27] <ogra_> and i cant enable it
[20:28] <jibel> ogra_, it was definitely not the plan
[20:28] <ogra_> yeah, thought so :)
[20:28] <jibel> ToyKeeper, ^ do you confirm?
[20:28] <ToyKeeper> I'll check.
[20:29] <ogra_> the toggle buttons in the indicator are greyed out
[20:29] <ogra_> so i guess the service doesnt start anymore
[20:29] <ToyKeeper> Sorry, I missed the notice that image 8 had finished.
[20:29] <ogra_> there was none
[20:30] <ogra_> the bot hasnt been ported to the new channel design yet ... and since the new vivid channel has a way lower version now this is quite tricky
[20:31] <jibel> ogra_, confirmed :(
[20:31] <ogra_> what was that silo supposed to fix ? it worked really nice the last image
[20:32] <jibel> ogra_, it was supposed to fix no location on first boot
[20:32] <ogra_> hah
[20:32] <ToyKeeper> Hey, at least every boot is the same now.  :)
[20:33] <ogra_> lol, yeah
[20:33] <jibel> not funny
[20:33] <jibel> ogra_, who can revert the package in the overlay?
[20:34] <jibel> it was location-service
[20:34] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150529.changes
[20:38] <rsalveti> jibel: was silo 5
[20:38] <jibel> rsalveti, yes
[20:38] <rsalveti> same issue we got when we were trying to land it a few days ago
[20:38] <rsalveti> that's why I didn't want to approve the code
[20:38] <rsalveti> of course who did, didn't test
[20:39] <rsalveti> ubuntu-location-provider-here from 0.1+15.04.20141110-0ubuntu1 to 0.1+15.04.20150529-0ubuntu1
[20:39] <jibel> rsalveti, can you revert the package? I think this fix should definitely not go in this release.
[20:39] <rsalveti> that's probably the one
[20:40] <rsalveti> actually, that one was backporting the workaround we had for RTM
[20:40] <rsalveti> so here should be safe
[20:40] <rsalveti> https://code.launchpad.net/~mandel/location-service/simple-trust-store-fix/+merge/260497
[20:40] <rsalveti> this is probably the one that caused it
[20:41] <rsalveti> ogra_: jibel: ToyKeeper: can you try manually reverting that and see if it works again?
[20:44] <rsalveti> /usr/share/upstart/sessions/ubuntu-location-service-trust-stored.conf
[20:45] <rsalveti> brb, walking the dog
[20:45] <jibel> rsalveti, sure, trying now
[20:45] <rsalveti> if it works by manually reverting that I can upload a new package reverting the change
[20:47] <ogra_> that code can never work
[20:47] <ogra_> it doesnt make sure that the session dbus has even started
[20:47] <jibel> I'm wondering how it worked for davmor2_hols when he did the verification
[20:49] <ogra_> sigh, no wifi this boot :(
[20:51] <ToyKeeper> Location works great after 'apt-get install ubuntu-location-provider-here=0.1+15.04.20141110-0ubuntu1'.
[20:52] <jibel> rsalveti, I reverted the change for it is still broken
[20:52] <ToyKeeper> Well, it works anyway...  and it works better than I've seen the arale do for quite a while.
[20:52] <ogra_> image 7 worked awesome already
[20:52] <jibel> rsalveti, lets just revert all of silo 5
[20:52] <jibel> ogra_, agreed
[20:52] <ogra_> yeah, hacking the upstart job definitely doesnt fix it
[20:53] <rsalveti> https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910
[20:53] <rsalveti> this is the other change for here
[20:53] <rsalveti> but that's just for wizard
[20:53] <rsalveti> need to brb, can check this later today
[20:53] <rsalveti> super weird
[20:54] <ogra_> the diff in the silo PPA is aquite a bit bigger
[20:54] <ogra_> *quite
[20:54] <ogra_> (but that might be LP being silly)
[20:57] <ogra_> ok, reverting the above fixes it
[20:59] <ogra_> rsalveti, it is the wizard thing ... (not sure what the purpose of that thing is at all ... it will run every boot after dbus started)
[21:00]  * ogra_ needs to go afk for a while
[21:29] <ToyKeeper> Hopefully the torrential downpour here will stop before I have a new image for location testing...
[21:36]  * rsalveti back
[21:36] <rsalveti> alright, let me investigate what happened
[21:44] <camako> cihelp : migration of qtubuntu{-gles} from proposed to release in wily is blocked by a boottest regression according to 'excuses', seems to be bug #1421009 (timed out waiting for Unity greeter), can these tests be re-run please?
[21:44] <camako> kgunn ^^
[21:45] <rsalveti> in theory the here-wizard thing only runs as part of the wizard
[21:46] <kgunn> camako: that is weird, testbed pkgs is mir12 ?
[21:46] <kgunn> i thot it would be mir13 since silo 30 is stuck in proposed and that's it's contents
[21:46] <camako> kgunn, well perhaps it didn't get to that point
[21:47] <camako> i.e. got stuck at boottest and didn't get to testbed
[21:47] <kgunn> mmm
[21:48] <camako> kgunn, if you look at the scrollback, the same thing happened with  oxide-qt and webbrowser-app...
[21:49] <kgunn> camako: ta
[21:49] <kgunn> i'll stop freaking out :)
[21:50] <camako> :-)
[22:01] <jibel> rsalveti, there are at least 2 problems, 1. this job runs on every boot not only after the wizard. 2. ubuntu-location-provider-here-slpgwd is already running, so start exit with 1, the job stops and location-service is not restarted
[22:01] <rsalveti> right, but afaik we have the same package on rtm
[22:02] <rsalveti> but yeah, it shouldn't be running at every boot
[22:02] <rsalveti> let me just revert this guy then
[22:02] <jibel> a workaround is to change to start ubuntu-location-provider-here-slpgwd || true but why does it run on every boot
[22:02] <Ursinha> camako: I'll have a look
[22:03] <rsalveti> the start syntax "looks" correct
[22:03] <rsalveti> since it's waiting the create event
[22:04] <rsalveti> maybe it's always getting the create event
[22:04] <camako> than Ursinha
[22:04] <Ursinha> camako: just so you know, oxide-qt is a different problem
[22:05] <Ursinha> camako: that we plan to address early next week, along with other handful of boottest annoyances
[22:05] <camako> Ursinha, ack
[22:05] <rsalveti> yeah, that's because it's not an empty commit
[22:05] <rsalveti> like it says
[22:05] <Ursinha> the unity bug is a real bug unfortunately
[22:06] <Ursinha> (in unity and friends, not boottest)
[22:19] <rsalveti> jibel: I just deleted the here package from the overlay
[22:19] <rsalveti> jibel: it was the first version available in there
[22:19] <rsalveti> so next image will get the previous version from vivid
[22:20] <rsalveti> there are so many issues with this upstart job
[22:23] <rsalveti> https://bugs.launchpad.net/ubuntu/+source/ubuntu-location-provider-here/+bug/1460215
[22:23] <rsalveti> mandel: ^^^
[22:24] <jibel> rsalveti, thanks, can you build an image and I'll really go on week end.
[22:24] <rsalveti> yup, just waiting launchpad to really delete the package
[22:26] <rsalveti> so I should be able to trigger a new image in at most 20 minutes
[22:30] <plars> Ursinha: camako: looks like the first one succeeded, I just rekicked the -gles one also
[22:39] <camako> plars, great thanks
[22:40] <rsalveti> jibel: ToyKeeper: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
[22:41] <rsalveti> should be done in ~1:15
[22:41] <ToyKeeper> Thanks.
[22:41] <rsalveti> aaaaaaand I'm out
[22:41]  * rsalveti EOW
[22:46] <plars> camako: and that one passed too
[22:47] <plars> should be reflected in excuses soon
[23:01] <camako> plars, awesome... does that mean they 'll be migrating soon?
[23:02] <plars> camako: well, I don't see them on excuses anymore, so I assume that already happened. But we don't have any control over it at that point
[23:03] <camako> plars, ok.. qtubuntu doesn't show to be in proposed according to rmadison... But it shows the old version in wily :
[23:03] <camako> qtubuntu | 0.60+15.04.20150318-0ubuntu3   | wily/universe                     | source
[23:03] <camako> I'm assuming it's on its way
[23:06] <wgrant> camako: https://launchpad.net/ubuntu/+source/qtubuntu/+publishinghistory
[23:06] <wgrant> That'll show things before they've made it all the way out to rmadison.
[23:07] <camako> wgrant.. Yeap I see it... and mir 0.13.1...
[23:08] <camako> plars, Ursinha, wgrant thank you all for your help..


[00:03] <Nafallo> !lart
[00:03] <Nafallo> ugh
[06:34] <RoAk> anyone with access in #ubuntu?
[06:35] <RoAk> morole | AHMADINEJAD is swearing... and insulting... etc
[06:36] <RoAk> !ops
[08:13] <bokey> is there a reason we don't have our lovely ubotu? :(
[08:15] <bokey> @join #ubuntu-np
[08:15] <bokey> >_<
[10:14] <jpatrick> !ubotu | bokey
[10:14] <bokey> jpatrick: hey
[10:14] <bokey> :)
[10:15] <bokey> jpatrick: ubottu is not sitting in our loco man.. #ubuntu-np ;)
[10:15]  * bokey should ask #ubuntu-locoteams people :/
[10:15] <jpatrick> bokey: you'll have to ask jussio1, who just went out
[10:15] <bokey> :(
[10:16] <jpatrick> I'm sure he'll see to it when he gets back
[10:16] <bokey> jpatrick: aite. no problemo
[10:22] <Myrtti> which locoteam is np?
[10:22] <jpatrick> Nepal
[10:23] <bokey> Myrtti: Nepal
[10:23] <Myrtti> I can make ubottu join the channel, but we'll have to discuss how to spread the strain more evenly between the bots
[10:24] <jussio1> Myrtti: please dont
[10:24] <Myrtti> jussio1: exactly
[10:24] <Myrtti> as I said, I _can_
[10:24] <Myrtti> it doesn't necessarily mean I _will_
[10:24] <bokey> jussio1: Myrttim why what's wrong? i am _confused_
[10:24] <jussio1> Loco's are not supposed to get the bot yet as we have not got a full solution and there is limits to the machine it s on.
[10:24] <Myrtti> yup
[10:25] <bokey> but it was running like couple of days ago dude
[10:25] <Myrtti> bokey: ubottu isn't ubotu
[10:25] <bokey> Myrtti: 'powdered ubotu'
[10:25] <bokey> anyway when can we have it?
[10:25] <Myrtti> bokey: I wish someone knew
[10:25] <bokey> :s
[10:25] <Myrtti> nobody does
[10:26] <bokey> jussio1: Myrtti any official answer?
[10:26] <bokey> why can't loco have it?
[10:26] <bokey> and what's the reason?
[10:26] <jpatrick> bokey: bot not yet ready
[10:26] <Myrtti> bokey: the official reason is that we don't have official bots
[10:27] <bokey> jpatrick: Myrtti okie then.. we'll wait
[10:27] <bokey> :s
[10:27] <Myrtti> until we do, we are using temporary ones on makeshift solutions
[10:27] <bokey> right
[10:28] <Myrtti> the main bot dropped few days ago and we had to find a quick-and-dirty solution for the main channels
[10:28] <bokey> Myrtti: do you know why it was dropped?
[10:28] <Myrtti> yes, but I will not discuss it here or anyplace else for that matter
[10:28] <bokey> hmm
[10:29] <Myrtti> let's just leave it to "It's gone, and probably will not come back ever"
[10:29] <Myrtti> the reasons are pretty irrelevant for the time being
[10:30] <bokey> simply annoying for users
[10:30] <jussio1> bokey: we understand and even at this moment working towards a solution
[10:31] <Myrtti> a solution that will be better than we had before ubotu dying on us
[10:31] <Myrtti> in the meantime we'll just have to play with the card hand dealed to us
[10:32] <bokey> don't tell me someone's writing one from ground up rather
[10:32] <Myrtti> no, the code is safe in a version management system
[10:33] <Myrtti> based on supybot
[10:33] <bokey> yup
[10:33] <Myrtti> but the infrastructure needs some figuring out
[10:33] <bokey> that's better i guess (means less delay for us :D)
[10:33] <bokey> right
[10:34] <Myrtti> who'll run it, with what hardware, who'll continue the development, will there be synchronized bots, if so, where and by whom etc.
[10:34] <bokey> right
[10:34] <bokey> thanks Myrtti jussio1
[10:34] <Myrtti> np
[10:34] <bokey> hey jpatrick catch ya around man
[10:34] <Myrtti> I hope this cleared up a few things
[10:34] <bokey> yup it did


[00:42] <catphish> yay, i managed to append the branch name in my http frontend, all working as it should now
[07:34] <jelmer> maxb: please
[09:43] <nilg`> help!!! I've just done some bzr revert FILE by mistake, how can I de-revert?
[09:44] <nilg`> OK, found the answer http://stackoverflow.com/questions/815933/undo-bzr-revert
[12:15] <taylanub> bzr 2.2.2(-2 on arch) hangs with full CPU usage while creating the log file, if it is a symlink
[12:16] <taylanub> hrmm, arch apparently applies some python2.7 compat patches
[12:20] <taylanub> and it's extremely slow, but that might be the server i'm connecting to at the moment (bitlbee)
[18:11] <Muscovy> I'm having some issues pushing to a new launchpad bzr branch.
[18:11] <Muscovy> I keep getting this error: http://paste.ubuntu.com/556888/
[18:38] <Peng> Muscovy: So, have you moved the target directory out of the way and tried again? :P
[18:41] <Muscovy> That does that mean, Peng? Remaking the branch?
[18:41] <Peng> Well, the specific error message is whining that a .bzr control directory exists at lp:opensearch but nothing's in it.
[18:42] <Peng> And the error message suggests you remove said directory.
[18:43] <Peng> Try using your favorite SFTP client, or hitchhiker, to log into lp:opensearch and remove the .bzr directory or rename it to backup.bzr (Launchpad doesn't allow you to rename it to whatever you want).
[18:47] <Muscovy> Alright.
[18:53] <Muscovy> ...how do I do that?
[18:54] <Muscovy> I tried googling how to use hitchhiker, but it didn't help.
[18:59] <Muscovy> I also tried deleting and remaking the branch, but it has the same error.
[19:05] <Muscovy> I figured out how to sftp in. One of the two problem branches had a .bzr. I removed it, but that branch still gives the same error.
[19:10] <Muscovy> Some repeated attempts made one of the branches work.
[19:11] <Muscovy> The other branch still shows no .bzr and gives the same error.
[19:37] <Muscovy> Oh, all good. :D
[19:37] <Muscovy> Thanks for your help, Peng.
[22:32] <maxb> SubversionException: ('Commit failed (details follow):', 200014)
[22:33] <maxb> Anyone know where the details disappear to, when one of those is thrown in the bzr-svn testsuite?


[11:10] <chrisccoulson> gnomefreak - you might be interested in mozilla bug 579765
[11:10] <ubot2> Mozilla bug 579765 in File Handling "Not using GTK filechooser anymore" [Major,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=579765
[12:26]  * gnomefreak likes the new one :)
[13:33] <jdstrand> chrisccoulson: hi!
[13:33] <chrisccoulson> hi jdstrand
[13:34] <jdstrand> chrisccoulson: so, I missed that more uploads are happening for jaunty
[13:34] <chrisccoulson> jdstrand, are they?
[13:34] <jdstrand> chrisccoulson: I'm sitting with doko now
[13:34] <jdstrand> chrisccoulson: well, yes, cause sparc openjdk-6 failed cause xulrunner-1.9.2 failed
[13:35] <gnomefreak> chrisccoulson: thanks for the bug report. i dont want to lose it :(
[13:35] <chrisccoulson> jdstrand, ah, yes
[13:35] <gnomefreak> hi too :)
[13:35] <chrisccoulson> it seems xulrunner hasn't built successfully on sparc for a long time
[13:35] <jdstrand> chrisccoulson: well, it build on maverick and lucid
[13:35] <jdstrand> built
[13:36] <jdstrand> chrisccoulson: it did build on karmic too
[13:37] <jdstrand> chrisccoulson: it did not on hardy
[13:37] <jdstrand> hey doko
[13:37] <jdstrand> doko: to catch you up:
[13:37] <jdstrand> 07:34 < jdstrand> chrisccoulson: so, I missed that more uploads are happening  for jaunty
[13:38] <jdstrand> 07:34 < chrisccoulson> jdstrand, are they?
[13:38] <jdstrand> 07:34 < jdstrand> chrisccoulson: well, yes, cause sparc openjdk-6 failed cause  xulrunner-1.9.2 failed
[13:38] <jdstrand> 07:34 < jdstrand> chrisccoulson: I'm sitting with doko now
[13:38] <jdstrand> 07:35 < chrisccoulson> jdstrand, ah, yes
[13:38] <jdstrand> 07:35 < chrisccoulson> it seems xulrunner hasn't built successfully on sparc  for a long time
[13:38] <jdstrand> 07:35 < jdstrand> chrisccoulson: well, it build on maverick and lucid
[13:38] <jdstrand> 07:35 < jdstrand> built
[13:38] <jdstrand> 07:36 < jdstrand> chrisccoulson: it did build on karmic too
[13:38] <jdstrand> 07:37 < jdstrand> chrisccoulson: it did not on hardy
[13:39] <jdstrand> chrisccoulson: we need openjdk on jaunty/sparc, so we need to decide to either fix the xul build or disable the plugin
[13:39] <doko> openjdk on jaunty/sparc still needs a real fix, which should be tried.
[13:39] <doko> jdstrand: no, we don't know if the fix is necessary on jaunty/sparc
[13:39] <chrisccoulson> oh, yeah, i still need to upload the fix for that
[13:40] <chrisccoulson> i was thinking about the hardy build failure there
[13:40] <chrisccoulson> i'll upload that now
[13:40] <jdstrand> well, we have openjdk-6 on jaunty/sparc release. I don't want it to go away
[13:40] <jdstrand> chrisccoulson: ah, cool
[13:40] <chrisccoulson> jdstrand, i'll upload the fix now. i committed it to bzr last week, and then didn't upload right away because people were complaining to me about hogging the build daemons
[13:42] <jdstrand> chrisccoulson: heh
[13:42] <doko> chrisccoulson: let people complain, or we'll never get more buildds
[13:43] <chrisccoulson> doko - yeah, i think people understand we need more buildd's now, but i don't want to make myself too unpopular ;)
[13:44] <jdstrand> chrisccoulson: doko and I agree that after you upload that, if it doesn't build, doko will just disable the plugin on sparc so it won't ftbfs
[13:44] <jdstrand> (for openjdk of course)
[13:46] <chrisccoulson> jdstrand / doko - ok, xulrunner is uploaded for jaunty now
[13:56] <jdstrand> chrisccoulson: thanks
[20:12] <BUGabundo> "Mozilla Developer Preview Web Browser"
[20:12] <BUGabundo> damn
[20:12] <BUGabundo> did it *really* need all that long name in the menu!?
[20:12] <BUGabundo> its not even branded
[20:39] <fta> damn, upgraded my netbook to maverick, lots of stuff are crashing/bogus in UNE
[21:05] <BUGabundo> eheh


[13:42] <hads> Ah but it's always morning. Also, I'm in AU so it really was morning.
[18:21] <ibeardslee> morning


[22:15] <ron__> Hello
[22:52] <cryptodan_laptop> hello
[23:58] <ron__> Hello to everyone online
[23:59] <ron__> We will get started in a few minutes