[23:57] <doctormo> BiosElement: Huh, looked at my ToDo board and it looks like I forgot to review your structure, can you pass me the link to it again/


[08:28] <mup> Bug #1844975 opened: Published 1.25.x streams for Bionic are buggy <juju-core:New> <https://launchpad.net/bugs/1844975>
[08:31] <mup> Bug #1844975 changed: Published 1.25.x streams for Bionic are buggy <juju-core:New> <https://launchpad.net/bugs/1844975>
[08:34] <mup> Bug #1844975 opened: Published 1.25.x streams for Bionic are buggy <juju-core:New> <https://launchpad.net/bugs/1844975>


[23:32] <Svenstaro> Is it possible to use a classroom server with a single generic student account for the thin clients?
[23:42] <alkisg> No - but you may use one for each pc


[01:16] -queuebot:#ubuntu-release- New sync: r-cran-redland (cosmic-proposed/primary) [1.0.17-10-1]
[07:34] -queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.3 => 2.20.9-0ubuntu7.4] (core)
[07:46] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.5 => 1:2.11+dfsg-1ubuntu7.6] (ubuntu-server, virt)
[07:48] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.34.2 => 2.35.2] (desktop-core, ubuntu-server)
[07:57] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.35.1~14.04]
[07:57] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.35.1]
[07:58] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.35~14.04]
[07:58] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.35]
[07:58] <apw> ^ clearing the decks for a 2.35.2 across the board
[07:59] -queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.35.1+18.04 => 2.35.2+18.04] (desktop-core, ubuntu-server)
[08:01] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.34.2~14.04 => 2.35.2~14.04] (no packageset)
[08:09] <LocutusOfBorg> slangasek, thanks!
[08:09] <LocutusOfBorg> I usually unpublish the binaries when I'm only interested in the build logs :)
[08:19]  * apw will handle the snapd's ^
[08:56] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-136.162] (core, kernel)
[09:03] <xnox> slangasek, is something odd happening with the iso production? on s390x it looks like an out of date d-i is being used, as if mirror is stale?
[09:03] <xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/cosmic/daily-20180912.log -> Using MD5 sums from d-i: /srv/cdimage.ubuntu.com/ftp/dists/cosmic/main/installer-amd64/20101020ubuntu551/images/MD5SUMS
[09:03] <xnox> however current d-i is 20101020ubuntu552
[09:04] <xnox> thus e.g. initrd has v4.17 modules, not v4.18 and things fail
[09:41] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.0-0ubuntu1~18.04.1 => 2:10.3.0-0ubuntu1~18.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[09:59] -queuebot:#ubuntu-release- New binary: ganeti [amd64] (cosmic-proposed/universe) [2.16.0~rc2-6ubuntu1] (no packageset)
[10:48] -queuebot:#ubuntu-release- New: accepted ganeti [amd64] (cosmic-proposed) [2.16.0~rc2-6ubuntu1]
[10:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [sync] (cosmic-proposed) [1.0.17-10-1]
[10:48] -queuebot:#ubuntu-release- New: accepted ufolib2 [sync] (cosmic-proposed) [0.1.3-1]
[10:48] -queuebot:#ubuntu-release- New: accepted r-cran-mitools [amd64] (cosmic-proposed) [2.3-1]
[10:48] -queuebot:#ubuntu-release- New: rejected r-cran-redland [sync] (cosmic-proposed) [1.0.17-9-1]
[10:51] -queuebot:#ubuntu-release- New binary: r-cran-redland [s390x] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[10:51] -queuebot:#ubuntu-release- New binary: r-cran-redland [ppc64el] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[10:52] -queuebot:#ubuntu-release- New binary: ufolib2 [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
[10:54] -queuebot:#ubuntu-release- New binary: r-cran-redland [i386] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[10:55] -queuebot:#ubuntu-release- New binary: r-cran-redland [amd64] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[10:57] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-136.162]
[11:00] -queuebot:#ubuntu-release- New binary: r-cran-redland [arm64] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[11:01] -queuebot:#ubuntu-release- New binary: r-cran-redland [armhf] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
[11:35] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.107-0ubuntu<IP_ADDRESS>]
[11:47] -queuebot:#ubuntu-release- New binary: r-cran-kmi [amd64] (cosmic-proposed/universe) [0.5.4-1] (no packageset)
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [amd64] (cosmic-proposed) [1.0.17-10-1]
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [armhf] (cosmic-proposed) [1.0.17-10-1]
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [ppc64el] (cosmic-proposed) [1.0.17-10-1]
[11:48] -queuebot:#ubuntu-release- New: accepted ufolib2 [amd64] (cosmic-proposed) [0.1.3-1]
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [arm64] (cosmic-proposed) [1.0.17-10-1]
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [s390x] (cosmic-proposed) [1.0.17-10-1]
[11:48] -queuebot:#ubuntu-release- New: accepted r-cran-redland [i386] (cosmic-proposed) [1.0.17-10-1]
[11:49] -queuebot:#ubuntu-release- New: accepted r-cran-kmi [amd64] (cosmic-proposed) [0.5.4-1]
[12:06] -queuebot:#ubuntu-release- New binary: r-cran-rdflib [amd64] (cosmic-proposed/universe) [0.1.0+dfsg-1] (no packageset)
[12:11] -queuebot:#ubuntu-release- New: accepted r-cran-rdflib [amd64] (cosmic-proposed) [0.1.0+dfsg-1]
[12:41] -queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [<IP_ADDRESS>-0ubuntu24 => <IP_ADDRESS>-0ubuntu25] (no packageset)
[12:56] <LocutusOfBorg> slangasek, do you mind commenting on https://github.com/lvc/abi-compliance-checker/pull/80#issuecomment-420523736 ?
[12:56] <gitbot> lvc issue (Pull request) 80 in abi-compliance-checker "Run packing commands in a subprocess" [Open]
[13:02] -queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (xenial-proposed) [2.5.5-0ubuntu<IP_ADDRESS>]
[13:09] -queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (xenial-proposed) [2.26.1-1ubuntu1~16.04.7]
[13:57] <acheronuk> sil2100: could I please get a packageset update for Kubuntu?
[15:37] <slangasek> xnox: yes, it appears the cdimage mirror on nusakan is 9 days out of date
[15:37] <slangasek> xnox: no, 3 days
[15:37] <slangasek> from the 9th ;)
[15:38] <slangasek> I'm running an anonftpsync by hand now to see what's up
[15:39] <xnox> slangasek, kill stale locks maybe?
[15:39] <xnox> happened before
[15:39] <slangasek> xnox: no, rsync is now running
[15:45] <slangasek> there's a design bug where if image builds on nusakan take too long and overlap, the sync never happens in order to not destabilize an in-progress image build
[15:45] <slangasek> so that could be it
[15:45] <slangasek> but I'm waiting to see what happens with rsync
[15:47] <slangasek> xnox: an rsync succeeded and the mirror is now up to date; I would have to crawl logs of the previous builds to see why this didn't happen on its own before now
[15:47] -queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-20ubuntu2~18.04 => 2.30-21ubuntu1~18.04] (core)
[15:48] -queuebot:#ubuntu-release- Unapproved: accepted ipxe [source] (bionic-proposed) [1.0.0+git-20180124.fbe8c52d-0ubuntu2.1]
[15:52] <xnox> slangasek, ok.
[15:54] <slangasek> xnox: yeah I looked at the logs and they all have the telltale 'parallel build; waiting for mirror to sync' line.  It would be nice if we could have this fixed someday, perhaps we need to make local hardlink farm copies of the mirror under a lock :P
[15:54] <slangasek> because currently the lock is held for the duration of any image build and there are a lot of those and they take real time
[16:09] <xnox> slangasek, given by hash mirrors, they need not hold a lock, if they resolve and use by hash mirrors, no?
[16:09] <xnox> or is that not synced?
[16:09] <slangasek> interesting point
[16:10] <slangasek> that's probably the better path forward
[16:10] <slangasek> ftp/dists/cosmic/by-hash/SHA256/ is there
[16:11] <slangasek> I haven't looked details of how to consume by-hash though, and this is all in the debian-cd codebase
[16:11] <slangasek> so probably not the quickest thing to retrofit
[16:12] <slangasek> xnox: do you have a pointer handy for details on consuming by-hash?
[16:15] <xnox> slangasek, i do this -> grab http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease, take sha256sum of it, from then on, i know that i can get _that_ version of it from http://archive.ubuntu.com/ubuntu/dists/cosmic/by-hash/SHA256/a2efba58cb8b5fc07bb2e4afb29a26593741780d8f285b0e6421174e07d8246b
[16:15] <xnox> where a2ef... is the sha256sum of it.
[16:15] <xnox> slangasek, but i have no idea what the apt-archive url / env variable spec is to point and lock onto that.
[16:15] <xnox> only walk it....
[16:15] <slangasek> right
[16:15] <xnox> juliank, ^
[16:16] <slangasek> and also I don't know if debian-cd is using apt or walking things directly :)
[16:16] <xnox> juliank, is there a url spec for by-hash fetching things?
[16:16] <xnox> or maybe cjwatson given there was some planning/work to have this in launchpad
[16:18] <slangasek> good news, we are using apt
[16:19] <xnox> slangasek, as far as i understand, there is no need to do anything then, just drop the locks.
[16:20] <xnox> slangasek, you are free to update the mirror, whilst builds are in progress, and as long as InRelease is updated atomically everything should be able to fetch things without any hashsum missmatches
[16:20] <xnox> slangasek, if the apt you are using is new enough....
[16:20] <xnox> slangasek, nousakan is on bionic, right?! =)
[16:21] <slangasek> xenial
[16:21] <xnox> http://manpages.ubuntu.com/manpages/xenial/man5/sources.list.5.html -> seems to have By-Hash option, so yeah, should be fine.
[16:21] <cjwatson> xnox: It's covered by https://wiki.debian.org/DebianRepository/Format
[16:21] <xnox> nice!
[16:22] <slangasek> so it's not just a no-op, you have to specify Acquire-By-Hash
[16:22] <cjwatson> you do need to make sure that mirror sync passes are done correctly
[16:22] <slangasek> oh, or perhaps Acquire-By-Hash is set in the archive
[16:23] <xnox> slangasek, http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease has Acquire-By-Hash set
[16:23] <slangasek> right
[16:23] <cjwatson> I *think* cdimage.build.anonftpsync gets it right though
[16:23] <slangasek> but then we also do things like FILES=`find -L $MIRROR/dists/$SUITE/ -name Sources.gz` in tools/grab_md5
[16:24] <cjwatson> Yeah, its two-stage stuff looks right
[16:24] <cjwatson> It would not remotely surprise me to find that there was ancient stuff in debian-cd that needs to be cleaned up
[16:24] <xnox> slangasek, urgh
[16:36] -queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu25]
[16:53] <slangasek> xnox: anyway, turning this into a card now and depending on how the image build times look over the next few days maybe it becomes a sprint topic
[17:11] -queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [<IP_ADDRESS>-0ubuntu24 => <IP_ADDRESS>-0ubuntu25] (no packageset)
[17:13] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.3 => 0.7.5-1ubuntu16.4] (core)
[17:24] <bdmurray> slangasek: Do you see anything strange with the zfs-linux upload for xenial-proposed?
[17:26] -queuebot:#ubuntu-release- New binary: glyphslib [amd64] (cosmic-proposed/universe) [3.0.2-3] (no packageset)
[17:27] -queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8-20180414-1ubuntu2 => 8.2.0-1ubuntu2~18.04] (core) (sync)
[17:27] -queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.3.0-16ubuntu3 => 7.3.0-27ubuntu1~18.04] (core) (sync)
[17:29] <slangasek> bdmurray: deleting the header of debian/patches/2203-Allow-mounting-datasets-more-than-once.patch is a bit odd, but non-functional. is that what you mean?
[17:30] <bdmurray> slangasek: Yeah, so by "non-functional" you mean the patch isn't getting dropped?
[17:30] <slangasek> bdmurray: yes; it's only dropping the header from the patch, not the code changes
[17:31] <slangasek> still doesn't really belong in an SRU, but it's not going to regress the package
[17:37] <cking> slangasek, bdmurray - it was my fault, I somehow messed up the header to that commit
[17:38] -queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu25]
[17:38] -queuebot:#ubuntu-release- New binary: libreoffice-dictionaries [amd64] (cosmic-proposed/main) [1:6.1.0~rc2-3] (personal-gunnarhj, ubuntu-desktop)
[17:38] -queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [<IP_ADDRESS>-0ubuntu24 => <IP_ADDRESS>-0ubuntu25] (no packageset)
[17:39] -queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [<IP_ADDRESS>-0ubuntu24 => <IP_ADDRESS>-0ubuntu25] (no packageset)
[18:15] -queuebot:#ubuntu-release- New: accepted glyphslib [amd64] (cosmic-proposed) [3.0.2-3]
[18:15] -queuebot:#ubuntu-release- New: accepted libreoffice-dictionaries [amd64] (cosmic-proposed) [1:6.1.0~rc2-3]
[18:29] -queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.5-3 => 3.6.6-1~18.04] (core)
[18:33] -queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.0~b3-1 => 3.7.0-1~18.04] (no packageset)
[18:36] -queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu25]
[21:23] -queuebot:#ubuntu-release- Unapproved: rejected syslinux [source] (bionic-proposed) [3:6.03+dfsg1-2ubuntu<IP_ADDRESS>]
[21:29] -queuebot:#ubuntu-release- Unapproved: syslinux (bionic-proposed/main) [3:6.03+dfsg1-2 => 3:6.03+dfsg1-2ubuntu<IP_ADDRESS>] (core)


[02:13] <Erige> I have a weird issue, My wifi connects to saved networks but it doesnt show any new networks of even the one im connected on the applet
[05:07] <akis> hi all. update-notifier [3.168 (xenial)] doesn;'t work under xubuntu 16.04 (clean installation) althouthg it is enabled at 'application autostart'. I read some similar reports but no solution. Any idea or help?
[05:07] <flocculant> 346a9392
[05:40] <soreau> I can't seem to figure out how to make lightdm autologin a user on 16.04
[05:40] <soreau> I tried editing lightdm.conf and the user is set to login without password, so I can press enter at login screen and it logs in
[05:41] <soreau> but it does not autologin without pressing enter
[05:42] <soreau> [SeatDefaults]\nautologin-user=user doesn't help
[05:50] <soreau> it was pam
[05:52] <akis> hi all. update-notifier [3.168 (xenial)] doesn;'t work under xubuntu 16.04 (clean installation) althouthg it is enabled at 'application autostart'. I read some similar reports but no solution. Any idea or help?
[14:08] <xubuntu04w> Hi! I upgraded from xubuntu 14.04 LTS 16.04 LTS and now my laptop won't boot up. After the bios loading the screen is black.
[14:13] <xubuntu04w> Its a http://www.ebay.de/itm/Medion-Akoya-E5010-MD97020-/300985834712
[14:24] <eggggs> rv identify ggghhh
[14:24] <eggggs> lol  ooops
[17:56] <Algyz> forgot how to get sound from hp usdt desktop internal speaker :(
[20:28] <PsynoKhi0> hi, if I attempt to dualboot ubuntu and xubuntu in uefi mode on the same GPT formatted hard drive, provided I mount the same partition as /boot/efi on both, are they going to take turns handling GRUB after updates?
[21:48] <Erige> I cant find any straight answer, I would like to use unity on my 2-1 one when I use touch screen, and XFCE when I am in desktop mode. I currently have Xubuntu installed, would I run into any problems installing ubuntu-desktop,
[22:41] <ronin-> any idea if this kind of init scripts still work in the latest (x)ubuntu? https://gist.github.com/naholyr/4275302#file-service-sh
[22:43] <xubuntu87w> I am just trying to report and issue with Xubuntu, and I might be the issue
[22:45] <xubuntu87w> I have a Lenovo Y510P and when I am logged into Xubuntu my speakers do not work, but when I switch to Ubuntu, they do, so it is not a hardware issue.  The speakers show like they are working with the decibel bar (incorrect terminology) showing volume and it being at 100% Youtube is not on mute.  I tried several settings in Audio to no avail
[22:45] <xubuntu87w> Any suggestions or help to troubleshoot would be good


[15:59] <x58> How can I debug why a juju run is not completing?
[16:08] <petevg> kwmonroe: here's the traceback I get when trying to deploy a xenial version of the zookeeper charm: http://paste.ubuntu.com/21019611/
[16:08] <petevg> It looks like it is a failure in the openjdk layer; it's looking for /etc/default/bigtop-utils, but that doesn't exist ...
[16:10] <kwmonroe> petevg: that ain't nary an openjdk layer failure.. openjdk doesn't need bigtop-utils.  it's gotta be a failure of zookeeper or the bigtop base layer.
[16:11] <petevg> Hmmm ... Zookeeper doesn't attempt to edit anything in place, though.
[16:11] <petevg> ... I think.
[16:11] <kwmonroe> yeah, it's coming from lib/charms/layer/apache_
[16:11] <kwmonroe> bigtop_base.py", line 239, in trigger_puppet
[16:12] <lazypower> x58 - you can juju debug-hooks application/#    which will put you in an interactive shell (just a plain ol root shell by default)
[16:12] <lazypower> it should trap that run stanza and give you an opportunity to debug
[16:13] <kwmonroe> petevg: i might have spoken too soon -- there is some java stuff that it's looking for during that re_edit_in_place.. i'll kick it around in just a few minutes.
[16:13] <petevg> kwmonroe: here's my branch, for reference: https://github.com/juju-solutions/bigtop/tree/zookeeper-bind-address
[16:13] <kwmonroe> cool, thx petevg
[16:13] <petevg> Did I specify the series correctly in metadata.yaml?
[16:14] <kwmonroe> yeah petevg -- that looks legit
[16:14] <x58> lazypower: Thans.
[16:14] <petevg> kwmonroe:  you're right about where it's coming from. Here's the line from the base layer:
[16:15] <petevg> http://paste.ubuntu.com/21020508/
[16:15] <petevg> kwmonroe: do we have any big data charms that we've actually deployed/tested on xenial?
[16:15] <kwmonroe> ah, right petevg.. so the question is now why isn't /etc/default/bigtop-utils present?  is zk trying to trigger_puppet before bigtop-base is available?
[16:18] <petevg> kwmonroe: Hmmm. Bigtop looks like it installed -- there's a bigtop.release directory in the ubuntu user's home dir.
[16:18] <petevg> etc/default/bigtop-utils isn't there, though.
[16:20] <kwmonroe> petevg: could it be the zookeeper deb in bigtop's repo doesn't correctly specify bigtop-utils as a prereq?  said differently, how does bigtop-utils get installed with a trusty deployment?  i don't see us specifically calling that out in the bigtop base layer.
[16:20] <petevg> kwmonroe: That sounds plausible (I don't see it explicitly installing it, either.)
[16:22] <petevg> kwmonroe: Yeah. If I apt install "bigtop-utils" and then run "juju resolved zookeeper/0", everything looks happier.
[16:22] <petevg> I think that I'm going to go ahead and cheat and just explicitly call "apt install bigtop-utils" in the charm for now, to get this done. I'll file a ticket w/ bigtop to get the package fixed.
[16:24] <kwmonroe> roger that petevg.. perhaps we can also work around with an explicit bigtop-utils entry in the base layer: https://github.com/juju-solutions/layer-apache-bigtop-base/blob/master/layer.yaml#L7
[17:25] <suchvenu> Hi
[17:26] <suchvenu> I am getting the following error when I deploy the charm http://pastebin.ubuntu.com/21028721/
[17:26] <suchvenu> and the juju status shows as "message: agent is lost, sorry! See 'juju status-history websphere-liberty/0'"
[17:27] <suchvenu> Can anyone help me with this ?
[17:28] <suchvenu> juju status history shows this : http://pastebin.ubuntu.com/21028908/
[17:39] <kwmonroe> suchvenu: it seems anastasia suggested trying juju-1.25.6 in bug 1465307, but i do not see that as released yet.
[17:39] <mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <canonical-bootstack> <landscape> <regression> <juju-core:New> <https://launchpad.net/bugs/1465307>
[17:39] <kwmonroe> anyone know when 1.25.6 is due?
[17:40] <lazypower> kwmonroe - its in proposed
[17:40] <lazypower> add-apt-repository ppa:juju/proposed
[17:42] <kwmonroe> ah, ack lazypower.. suchvenu if you want to try the proposed 1.25.6, do:
[17:42] <kwmonroe> sudo add-apt-repository ppa:juju/proposed && sudo apt update && sudo apt upgrade juju
[17:43] <suchvenu> ok kwmonroe
[18:07] <narindergupta> anyone knows how to connect juju to openstack (deployed through juju) i tried this URL https://blog.felipe-alfaro.com/2014/04/29/bootstraping-juju-on-top-of-an-openstack-private-cloud/
[18:07] <narindergupta>  but facing issues
[18:11] <lazypower> narindergupta - what issues are you encountering?
[18:12] <lazypower> narindergupta - we use juju driving a juju deployed openstack all the time internally with OIL and other efforts
[18:12] <narindergupta> lazypower, juju.cmd supercommand.go:429 failed to bootstrap environment: index file has no data for cloud {RegionOne http://<IP_ADDRESS>:35357/v2.0} not found
[18:12] <lazypower> ahh i  have seen this before but i dont recall the fix... one sec while I see if i can get someone to lend a hand.
[18:13] <narindergupta> lazypower, sure will be helpful. Also if you have the clear method explaining or script will be helpful?
[18:13] <lazypower> narindergupta - i think you have to build simplestreams, but i'm verifying that
[18:14] <narindergupta> lazypower, how to do that?
[18:14] <lazypower> i very well could be wrong, adn we have a lot of high profile folks out at the mid cycle sprint, so i may redirect you to the juju mailing list allowing them a chance to chime in
[18:15] <narindergupta> lazypower, zahra already posted this to mailing list. everyone says juju can not connect to cloud but manually i can do everything to cloud
[18:15] <narindergupta> lazypower, but any information will be helpful
[18:15] <lazypower> you bet, i'll do what i can to help. i've got your contact details, i'll e-mail you any information i can surface today
[18:16] <narindergupta> lazypower, sounds good to me thanks
[18:32] <magicaltrout> make it work lazypower !
[18:33] <lazypower> magicaltrout - working on it, its hard to do when there's no response from the SME's ;)
[18:33] <magicaltrout> hehe
[18:35] <petevg> kwmonroe: Hmmm ... looks like bigdata-utils being missing might be just the tip of the iceberg for Zookeeper on xenial. It looks like the Zookeeper xenial deb installs it in /usr/share/zookeeper rather than /usr/lib/zookeeper, and that screws up the puppet scripts :-/
[18:38] <kwmonroe> petevg: how are you specifying the xenial deb in your zk layer?
[18:39] <petevg> kwmonroe: I'm not. I'm just running puppet and letting it do its thing.
[18:39] <kwmonroe> petevg: did you alter the bigtop_repo_x86 layer opt?  or manually apt-add-repo?
[18:39] <petevg> Currently digging through puppet stuff to see if I can override the path ... I see a lot of instances of that zookeeper path being a defaul or hardcoded, though.
[18:39] <petevg> kwmonroe: again. Not doing anything manually. Just telling bigtop to do its thing.
[18:40] <kwmonroe> petevg: i bet i know what's happening.. i bet there's a zookeeper package in the xenial archives.  on the borked system, what does "dpkg -l | grep zoo" say?
[18:42] <petevg> kwmonroe: http://paste.ubuntu.com/21038468/
[18:42] <kwmonroe> petevg: how about "sudo apt-cache madison zookeeper"
[18:43] <petevg> kwmonroe: http://paste.ubuntu.com/21038664/
[18:43] <kwmonroe> thar she be petevg
[18:43] <petevg> So there is a package in universe.
[18:44] <petevg> Yeah. And it's newer, so that's why it's being grabbed, right?
[18:44] <kwmonroe> i'm not sure how the precedent is set
[18:44] <kwmonroe> but your thought seems reasonable.. bigger version wins
[18:45] <kwmonroe> so now petevg.. we need to figure out how to force the bigtop repo to win.  maybe a priority option we can set?
[18:45] <petevg> kwmonroe: Probably. Do you know where puppet calls apt/dpkg?
[18:46] <petevg> We either need to do some magic before that runs, or override it.
[18:48] <petevg> I think that I want to pin the package. I'm not sure that it's going to be easy to do so before bigtop installs zookeeper, but after it adds its repo. Digging into it now ...
[19:37] <kwmonroe> ok petevg, let's compare notes.. http://paste.ubuntu.com/21045756/
[19:38] <kwmonroe> petevg: one solution is to create an /etc/apt/preferences.d/file to force bigtop repos to take priority (as seen in above paste)
[19:39] <petevg> kwmonroe: Yep. That's pretty much what I found. Need to test it and make sure that it works before the repo is actually setup.
[19:45] <petevg> kwmonroe: thx for suggesting the wildcard -- covering the same case elsewhere makes sense.
[19:46] <kwmonroe> petevg: the pro is that presumably all zk deps would get prioritized too (or rather, all bigtop repo bits would).  the con is that there may be some old crusty deb in the bigtop repo that we really didn't want to take prescendent over the main archive.
[19:47] <petevg> True. I think that the pro outweighs the con, though.
[19:47] <kwmonroe> yeah, me too.  lest you're stuck managing deps in a preferences file till you simply die.
[19:47] <petevg> I'm sticking the file in a resource, reading it into Python, then writing it out, so we can do some parsing if it every becomes a big problem.
[19:48] <kwmonroe> word petevg.  perhaps think about using the bigtop_repo layer option (from bigtop base layer) as the url to use in the origin matcher.  it may not always be "bigtop-repos.s3.amazonaws.com".
[19:49] <petevg> kwmonroe: Good idea. Will do.
[19:50] <kwmonroe> in fact, it probably should never be that hard coded string, but whatever the hostname for the repo url may be.  surely there's some pythony thing to strip 'http://' and '/blah/foo' from a url and just leave the fqdn.
[19:56] <petevg> kwmonroe: bigtop_repo[7:].split("/")[0] should do it. Not pretty, but it works. :-)
[19:57] <magicaltrout> its okay
[19:57] <magicaltrout> kwmonroe hasn't written a pretty line of code in his life
[19:57] <kwmonroe> petevg: it's gonna get uglier too.. the layer option is "bigtop_repo-$(arch)"
[19:57] <petevg> Yep. I'm in the middle of writing that section of code right now :-)
[19:58] <kwmonroe> and petevg, what if somebody uses https or ftp?  that'll dork the 7th char.
[19:58] <kwmonroe> magicaltrout: all my code is handsome
[19:58] <petevg> This is why a lib is always nice :-)
[19:58] <magicaltrout> hehe
[19:59] <kwmonroe> dont we use urlparse in these bt charms?  surely that would do a fine parsing job
[19:59] <magicaltrout> urlparse
[20:00] <petevg> Here's an ugly function for you: http://paste.ubuntu.com/21048613/ (Going to test to verify that the approach works, and worry about making things prettier later.)
[20:00] <kwmonroe> magicaltrout: if you can't keep up, at least keep quiet
[20:00] <magicaltrout> *sob*
[20:00]  * magicaltrout finds more wine
[20:00] <kwmonroe> ;)
[20:01] <petevg> magicaltrout: thank you. urlparse is a good idea, to catch other stuff I haven't thought of.
[20:01] <kwmonroe> petevg: i like everything about that function except line 8
[20:02] <kwmonroe> that's like 92% approval from me
[20:02] <kwmonroe> which is pretty incredible
[20:02] <petevg> Excellent. I'll fix up line 8 with urlparse before review :-p
[20:02] <kwmonroe> :)  +1
[20:17] <petevg> kwmonroe: yay. Tests passed! Cleaning up code. PRs coming your way soon ...
[20:33] <x58> juju run --service myserver hangs forever and never seems to complete.
[20:36] <petevg> kwmonroe: PRs for you: https://github.com/juju-solutions/bigtop/pull/30  lazyPower had volunteered to review them, so feel free to sling it over to him if you run short on time :-)
[20:36] <petevg> (That PR links to the other two.)
[20:59] <kwmonroe> roger petevg, taking a gander ahora
[21:36] <zeestrat> Hey guys, what would you do if you'd need to deploy some none juju services on blank Ubuntu machines if you have an MAAS managed infra with some juju deployments already? Just commission machines in MAAS, use the ubuntu charm so you can manage it some what with juju and get some flexibility with lxd containers, or some other approach?
[21:37] <zeestrat> I see that the ubuntu charm is intended for testing and development, but is there anything inherently missing that I should look out for?
[21:42] <kwmonroe> petevg: "This breaks many things"  lol.  zk and bigtop-base PRs merged.  we'll let upstream marinate on their PR.
[21:45] <petevg> kwmonroe: Cool. Thank you :-)
[21:48] <kwmonroe> zeestrat: deploying 'ubuntu' seems a fine way to do what you want.  i don't know of anything missing that would make you say "oh, this is why it's test/dev only".  it's just a cloud-init ubuntu installation.
[21:49] <kwmonroe> zeestrat: and you do get the benefit of connecting stuff up to it.. anything that uses the juju-info relation can be attached to your 'ubuntu' charm units... stuff like ganglia for monitoring, etc
[22:42] <kwmonroe> petevg: fwiw, https://jujucharms.com/u/bigdata-dev/zookeeper/xenial/1 is your new hotness
[22:43] <petevg> kwmonroe: sweet! Thank you :-)
[22:44] <kwmonroe> not so fast petevg.. the bigtop_apt change in the zookeeper push now conflicts with your unit test PR :/  https://github.com/juju-solutions/layer-apache-bigtop-base/pull/28
[22:45] <kwmonroe> not a big deal, just wanted to knock you down a peg this fine tuesday afternoon ;)
[22:45] <petevg> kwmonroe: of course it does. Will fix it in the morning :-)
[22:45] <kwmonroe> cool - thanks, and have a good night!


[16:51] <acheron-a> hello
[16:53] <acheron-a> has anyone noticed or reported about the nautilus file manager hanging and time-out after you insert an USB drive and click on it to browse the files?  seemed to have started after the eject update
[16:55] <acheron-a> also when you do a clean install and enter the computer name - host name in the installer, nautilus never picks that up, it just shows "Computer" but if you change the host name in
[16:56] <acheron-a> [System Settings], [All Settings], System =>
[16:56] <acheron-a> [Details], [Overview] Device name
[16:56] <acheron-a> and change it, then the computer name shows up in nautilus
[19:31] <acheron-a> pretty quiet here
[19:36] <flocculant> acheron-a: yea - has been quiet since balloons went off to do other things http://i.imgur.com/Hs4aS75.png
[19:36] <balloons> flocculant, lol
[19:37] <flocculant> screenshot makes it look like you only just left :D
[19:37] <flocculant> prior to the 22ns gQuigs said something on the 21st :p
[19:38] <acheron-a> i see
[19:38] <acheron-a> i mentioned a couple of things here and no one said a word
[19:38] <flocculant> acheron-a: u+1 might get more talk
[19:39] <acheron-a> what is u+1?
[19:39] <flocculant> #ubuntu+1 the dev supporty type channel
[19:41] <acheron-a> thanks
[19:41] <balloons> or just plan #ubuntu
[19:41] <balloons> well then
[19:42] <flocculant> balloons: are they not likely to say 'that's for +1 not here' ?
[19:42] <flocculant> anyway - back to just idling in this channel :p


[15:01]  * slangasek waves
[15:01] <juliank> o/
[15:01] <fginther> o/
[15:01] <aleks_bogdanov> o/
[15:02] <sil2100> o/
[15:02] <slangasek> #startmeeting
[15:02] <meetingology> Meeting started Thu Sep 13 15:02:06 2018 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:02] <slangasek> [TOPIC] Lightning round
[15:02] <slangasek> $ echo $(shuf -e slangasek bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson rcj philroche Odd_Bloke fginther juliank cshep aleks_bogdanov tobikoch)
[15:02] <slangasek> fginther aleks_bogdanov tdaitx cshep bdmurray xnox philroche infinity cyphermox doko mwhudson sil2100 Odd_Bloke slangasek juliank rbalint rcj tobikoch
[15:02] <slangasek> fginther: hello!
[15:02] <fginther> * Out for three days on holiday
[15:02] <fginther> * Created a new test image for a partner
[15:02] <fginther> * Cloud image build system vanguarding
[15:02] <fginther> * done
[15:03] <rbalint> o/
[15:03] <aleks_bogdanov> * working on simple streams exporters
[15:03] <aleks_bogdanov> * getting to learn all the systems and processes
[15:03] <aleks_bogdanov> * done
[15:03] <tdaitx> Short week: last Friday, working 6h/day this week
[15:03] <tdaitx> * fixed openjdk atk bridge error (LP: #1788250) a while ago
[15:03] <tdaitx>   - provided package to the security team, released on Bionic yesterday
[15:03] <tdaitx> * updated openjdk-lts sru exception, created ffe bug report (LP: #1791716)
[15:03] <tdaitx> * provided debdiff for new openjdk-11/openjdk-lts to doko
[15:03] <tdaitx> * fixed orphanedold-dkms files, tested on Xenial, Bionic, and Cosmic, SRU for Xenial/Bionic and patch for Cosmic (LP: #1791959)
[15:04] <tdaitx> * so far unable to cause sync to hang in order to reproduce LP: #1667512
[15:04] <tdaitx> (done)
[15:04] <slangasek> cshep:
[15:05] <cshep> working on updating image classes
[15:05] <cshep> that's pretty much it. done
[15:05] <bdmurray> committed a fix for an OOPS encounted when submitting crashes to daisy
[15:05] <bdmurray>   https://oops.canonical.com/oops/?oopsid=OOPS-fed140a72ccf553f7f43898fbc0a8f4c
[15:05] <bdmurray> submitted RT re daisy and apport code updates for the production Error Tracker
[15:05] <bdmurray> modified upgrade-charm hooks in Error Tracker charms to use proper directories
[15:05] <bdmurray> fixed cheetah issue w/ logrotation jobs for daisy and errors app servers
[15:05] <bdmurray> sorted out issues with staging version of the Error Tracker
[15:05] <bdmurray> submitted RT regarding staging errors frontends access to prod cassandra
[15:05] <bdmurray> updated Error Tracker main page filtering to show only deb crashes and add a
[15:05] <bdmurray> figured out how to and imported a snap crash into the staging version of the Error Tracker
[15:05] <bdmurray>  selection for 'all other binary packages'
[15:05] <bdmurray> updated Bionic release notes to include info re dropping of powerpc arch
[15:05] <bdmurray> investigation into apport SRU regressions
[15:06] <bdmurray> overrode increased rate of crashes for open-vm-tools after discussion w/ cpaelzar
[15:06] <bdmurray> SRU verification of libc6 upgrade change (LP: #1787649)
[15:06] <bdmurray> review of didier's apport MP which fixes LP: #1791324
[15:06] <bdmurray> irc discussion with tdaitx re LP: #1791959 and old-dkms files
[15:06] <bdmurray> ordered a dragonboard and parts
[15:06] <bdmurray> ✔  done
[15:06] <bdmurray> xnox:
[15:06] <xnox> * smc-tools new upstream release LP: #1689782
[15:06] <xnox> * PATH is broken, fixing everywhere:
[15:06] <xnox>   LP: #1792004 LP: #1614080
[15:06] <xnox>   https://github.com/systemd/systemd/pull/10073
[15:06] <xnox> * openssh-server socket activation patches
[15:06] <xnox>   - done, reviewed with debian maintainers & foundations
[15:06] <xnox>   - will clean-up more and post to systemd-devel review
[15:06] <xnox>   - also will post for review to openssh-portable
[15:06] <xnox> * debugging finarld incomplete shutdown initrd generations
[15:07] <xnox> done
[15:07] <philroche> * Cloud image modification for partner clouds
[15:07] <philroche> * Helping onboard new team members
[15:07] <philroche> * Preparing for team sprint next week
[15:07] <philroche> (done)
[15:07] <philroche> cyphermox:
[15:08] <cyphermox> - MIR: gpsd
[15:08] <cyphermox> - SRU verifications for gnu-efi, shim 13 in trusty, shim 15 in bionic
[15:08] <cyphermox> - fixing netplan autopkgtests prior to upload
[15:09] <cyphermox> - optional-addresses upstream systemd work
[15:09] <cyphermox> - merged mwhudson's optional-addresses code for netplan
[15:09] <cyphermox> - plymouth fix for tty deactivation (LP: #1767918) and SRU to bionic
[15:09] <cyphermox> - fwupdate: drop uefi artefacts
[15:09] <cyphermox> - investigating missing MokSBStateRT in efivars
[15:09] <cyphermox> - SRU syslinux with patch for gnu-efi 3.0.8 support in bionic
[15:09] <cyphermox> - proposed-migration: looked into python-pkginfo
[15:09] <cyphermox> (done)
[15:09] <doko> - at the GNU Cauldron in Manchester from Thu to Mon
[15:09] <doko> - working on toolchain SRUs with sil2001
[15:09] <doko> - review all open MIRs
[15:09] <doko> - archive work, toolchain updates
[15:09] <doko> (done)
[15:09] <doko> ohh, and started a cosmic test rebuild
[15:10] <doko> http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180911-cosmic.html
[15:10] <juliank> +1
[15:11] <slangasek> xnox: do you suppose we could get a central writeup afterwards of how you expect PATH to work, so we a) know what would be a regression, and b) can make sure there are no holes in it?
[15:11] <bdmurray> sil2100:
[15:11] <sil2100> - Candidate reviews
[15:11] <sil2100> - Kernel SRU reviews
[15:11] <sil2100> - Regular SRU reviews and releases
[15:11] <sil2100> - FFe reviews
[15:11] <sil2100> - raspi3 u-i classic:
[15:11] <sil2100>   * Adding some tweaks to ubuntu-image for easier kernel/initrd preparation
[15:11] <sil2100>   * Figuring out the correct uboot.env for raspi3
[15:11] <Odd_Bloke> slangasek: You want to understand the PATH forward?
[15:11] <sil2100>   * Add some more changes to the gadget tree and livecd-rootfs to get proper boot contents
[15:11] <sil2100>   * Multiple test image builds - final local image finally booting into the system on the rootfs
[15:11] <sil2100> - Tweaks to the work-in-progress britney branch for SRU ADT regression handling, test suite additions
[15:11] <xnox> Odd_Bloke, ahahhahahhaha
[15:11] <sil2100> - Travel preparations
[15:11] <xnox> slangasek, possibly.
[15:11] <sil2100> (done)
[15:11] <Odd_Bloke> * Visiting a partner last week, so playing catch-up this week
[15:11] <Odd_Bloke> * Double-checked that microcode is correctly installed in bare metal images we provide to partners
[15:11] <Odd_Bloke> * Met with our new folks for the first time!
[15:11] <Odd_Bloke> * Continued work on streamlining the delivery of our images to GKE
[15:11] <xnox> slangasek, but i would argue we should drop /usr/local and then people will stop listening
[15:11] <Odd_Bloke> (done)
[15:12] <Odd_Bloke> slangasek:
[15:12] <xnox> slangasek, because e.g. unattended-upgrades.service should not have /usr/local in PATH
[15:13] <doko> tdaitx: fyi: the above test rebuild is done using openjdk-11 as the default
[15:13] <tdaitx> doko: ack, thanks for that!
[15:14] <rbalint> xnox, why shouldn't u-u have /usr/local/bin ?
[15:14] <tdaitx> doko: just for curiosity sake, does the rebuild respect the build dependebcy order at all?
[15:14] <slangasek>  * SRU processing, there are some good shims and grubs running around
[15:14] <slangasek>  * Support for nvidia modules in GKE
[15:14] <slangasek>  * Preparing for keyring cabal activities during the sprint
[15:14] <slangasek>  * proposed-migration wrangling
[15:14] <slangasek>  * upcoming:
[15:14] <slangasek>   * swapping tomorrow for sprint travel
[15:14] <slangasek>   * travelling to sprint
[15:14] <slangasek> (done)
[15:14] <juliank> * submitted systemd-networkd state documentation PR (https://github.com/systemd/systemd/pull/10033)
[15:14] <juliank> * debugged packagekit -crashing- restarting when upgrading itself (bug 1790613) - hello, maintainer scripts!
[15:15] <juliank> * fixed ipxe FTBFS
[15:15] <juliank> * fixed ipxe booting grub via shim in qemu (bug 1789319)
[15:15] <juliank> * some apt upstream discussions
[15:15] <juliank> * reviewed an update-manager merge proposal from rbalint (https://code.launchpad.net/~rbalint/update-manager/retry-after-failed-transaction/+merge/354648)
[15:15] <juliank> * submitted PR for networkd-dispatcher /etc overrides (https://gitlab.com/craftyguy/networkd-dispatcher/merge_requests/40)
[15:15] <juliank> * merged newt for automake 1.16 (after a friendly request from LocutusOfBorg, who merged automake); reported some bugs in debian
[15:15] <juliank> (done)
[15:15] <rbalint> (short week)
[15:15] <slangasek> rbalint:
[15:15] <rbalint> * triaging unattended-upgrades regressions
[15:15] <rbalint> * gardening update-manager bugs
[15:15] <rbalint> * fixing LP: #1317164 and LP: #1791931 which have > 100 duplicates and lot of reported crashes
[15:15] <rbalint> * renaming WSL apps to proudly include LTS in the name
[15:15] <rbalint> (done)
[15:15] <doko> tdaitx: no. why would it be necessary?
[15:16] <slangasek> xnox: I'm asking you for documentation, not a polemic
[15:16] <slangasek> rcj:
[15:17] <tdaitx> doko: hmm, I don't see maven, ant, or gradle there, is that expected?
[15:17] <rcj> * Debugging and reported a missing dependency in linux-firmware (bug #1792189)
[15:17] <doko> tdaitx: still running ... blame the libreoffice/chromium/firefox test builds for the delay ...
[15:17] <rcj> * cloud image development and fixes
[15:17] <rcj> (done)
[15:17] <tobikoch> * Learning about image building.
[15:17] <tobikoch> * Debugging small problems related to that.
[15:17] <tobikoch> (happy end)
[15:18] <slangasek> tdaitx: it rebuilds using the main archive for build-dependencies, so in principle everything there should be buildable against itself now without bootstrapping
[15:18] <slangasek> and anything that isn't is a failure
[15:18] <xnox> rbalint, because /usr/local/bin/python3 breaks distro upgrades.
[15:18] <slangasek> xnox: just create a systemd unit that watches for /usr/local/bin/python3 with inotify and deletes it
[15:18] <tdaitx> slangasek: ack, thanks
[15:18] <xnox> slangasek, excellent idea!
[15:19] <rbalint> xnox, u-u does not really run during distro upgrades
[15:19] <xnox> rbalint, /any/ package upgrade can fail... we have bugs...
[15:19] <slangasek> any other questions on status?
[15:22] <slangasek> [TOPIC] Bugs
[15:23] <slangasek> bdmurray: hello
[15:23] <bdmurray> bug 1754777
[15:24] <slangasek> bdmurray: I don't think casper nfs support is a priority for us
[15:25] <cyphermox> people still use nfs?
[15:25] <cyphermox> :D
[15:26] <slangasek> doko: btw is that rebuild test going to show up at http://qa.ubuntuwire.org/ftbfs/rebuilds/ soon?
[15:26] <bdmurray> Could somebody comment on the bug since it has a lot of people affected?
[15:26] <slangasek> who are these lots of people that are affected?
[15:27] <slangasek> if you're doing casper+nfs, you're doing something custom
[15:27] <cyphermox> oh, actually
[15:27] <cyphermox> could it be some kind of edubuntu thing maybe?
[15:27] <slangasek> there's no edubuntu in 18.04
[15:27] <cyphermox> no, but people do upgrade
[15:27] <cyphermox> I wonder if it's casper used outside of for install purposes.
[15:28] <doko> slangasek: no, using my modified ftbfs-report. and you wanted to review my changes and propose a package where to file these changes ...
[15:28] <cyphermox> (not that it particularly changes whether we support nfs+casper really)
[15:28] <doko> and only sending the annonucement once main has finished to build
[15:28] <gaughen> I have a bug I wanted to ask about before we move on, slangasek
[15:30] <slangasek> doko: afaik you still need to push changes to lp:~wgrant/lp-ftbfs-report/production
[15:30] <rcj> suspenseful
[15:30] <gaughen> https://bugs.launchpad.net/vaultlocker/+bug/1780332
[15:31] <slangasek> doko: so you need wgrant to review rather than me
[15:32] <doko> slangasek: we should add these scripts to some distro repo
[15:33] <slangasek> doko: it should have its own repo, but you still need to negotiate that with wgrant to change which branch he's deploying from
[15:33] <doko> well, next week. he got the same emails that you got
[15:36] <doko> sil2100: sru ping?
[15:36] <xnox> i'll comment on the bug
[15:36] <slangasek> xnox: ta :)
[15:36] <slangasek> bdmurray: other bugs?
[15:37] <bdmurray> How about a crash? https://errors.ubuntu.com/problem/ef53414acdfe092569388629a5c446880d0bcba1
[15:37] <slangasek> are crashes bugs?
[15:37] <rbalint> slangasek, they can become ones :-)
[15:38] <slangasek> systemd-journald crashing
[15:38] <slangasek> in fsync()
[15:39] <slangasek> am I blind that I can't find here what signal it's crashing with?
[15:39] <bdmurray> 6
[15:39] <sil2100> doko: I just need the SRU verification steps mentioned on the tracking bugs and then it should be good to go
[15:39] <cyphermox> slangasek: top of the screen, in the breadcrumbs thing
[15:40] <cyphermox> ah, bdmurray already answered
[15:40] <slangasek> oh, that's the 6? ok
[15:40] <slangasek> so it's a SIGABRT
[15:40] <juliank> similar to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1773148?
[15:41] <juliank> both crash in fsync.c:27 with SIGABORT
[15:41] <slangasek> rbalint, xnox: ^^ so should we be concerned about this, or does systemd-journald recover gracefully and this is a non-event?
[15:41] <slangasek> since SIGABRT likely means journald itself thought there was a problem
[15:41] <juliank> Probably systemd is aborting the syscall in fsync because the fsync hangs or something?
[15:42] <juliank> same bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1750855 it seems
[15:43] <bdmurray> juliank: yeah, that was my thought
[15:44] <slangasek> right, so I'm not sure that's user-affecting
[15:44] <slangasek> or fixable in systemd
[15:45] <juliank> Does systemd send SIGABRT to unresponsive services or something?
[15:45] <slangasek> it will, yes
[15:45] <slangasek> there's a keepalive on journald and I think logind
[15:45] <slangasek> so a hanging fsync() could just be tripping the watchdog
[15:46] <xnox> slangasek, juliank - systemd sends SIGABRT when internal timer times-out.
[15:46] <slangasek> right
[15:46] <xnox> because Watchdog= thing is set
[15:46] <xnox> actually
[15:46] <slangasek> we did change watchdog on some of the processes, didn't we?
[15:46] <juliank> ok
[15:46] <xnox> i thought we agreed to drop watchdog stanza on journald
[15:46] <xnox> slangasek, yeah, that's what i thought.
[15:46] <slangasek> well, I'm sure I opined that we should drop it
[15:46] <xnox> maybe we only talked about it in portland
[15:46] <slangasek> I don't know if it was agreed :)
[15:47] <slangasek> xnox: so should we take this into the backlog?
[15:47] <xnox> yeah
[15:47] <slangasek> ok, doing
[15:47] <bdmurray> that's it for me then
[15:48] <xnox> i wonder if we can have a graceful watchdog, which instead of killing things, would log that "i would have killed it"
[15:48] <slangasek> I'll take via bug #1750855
[15:48] <slangasek> [TOPIC] AOB
[15:48] <slangasek> anything else?
[15:48] <bdmurray> then should we mark the ET created bug as a dupe of the private crash?
[15:48] <slangasek> probably
[15:49] <bdmurray> doing so
[15:49] <slangasek> going once (AOB)
[15:49] <gaughen> sold!
[15:50] <slangasek> ok
[15:50] <slangasek> #endmeeting
[15:50] <meetingology> Meeting ended Thu Sep 13 15:50:05 2018 UTC.
[15:50] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2018/ubuntu-meeting.2018-09-13-15.02.moin.txt
[15:50] <slangasek> thanks, all :)


[00:02] <Riddell> hum, well server is built but is failing to appear at http://cdimage.ubuntu.com/ubuntu-server/daily/20100928.2/
[00:02] <Riddell> I wonder if that's the mirrors full up
[00:05] <Riddell> ooh there it is
[00:05] <Riddell> mathiaz: images up http://cdimage.ubuntu.com/ubuntu-server/daily/20100928.2/
[00:05] <mathiaz> Riddell: \o/ - thank ya!
[00:35]  * stgraber just noticed this morning's -meta change including the ubuntu font ...
[00:36] <stgraber> I'll be pushing a new edubuntu-meta change refreshing our dependencies to include it
[00:36] <Riddell> is it really that important?  it's not set as default or anything
[00:37] <stgraber> well, currently it means that our DVD has it in the live environment as we derive from Ubuntu but installing from a minimal system won't because edubuntu-meta is out of sync
[00:37] <stgraber> so I don't really care having it or not, I care about inconsistent installations
[00:38] <ScottK> stgraber: Is gcompris on your ISO?
[00:38] <stgraber> ScottK: yes
[00:38] <ScottK> stgraber: You might see about getting it moved from the ubuntu-desktop packageset to yours (since it's in Universe).
[00:39] <Riddell> stgraber: ok as you wish
[00:42] <stgraber> ScottK: that's weird, it was in our packageset for karmic then was apparently moved to ubuntu-desktop with lucid.
[00:47] <stgraber> cjwatson: ^ any chance you can fix that when you have a minute ?
[00:48] <stgraber> Riddell: I just checked and we won't need a meta package update as edubuntu-desktop simply depends on ubuntu-desktop solving all of our issues ;) For some reason I didn't remember that part of the magic.
[00:48] <Riddell> phew
[01:03] <NCommander> Riddell: what happened to my dove image?
[01:10] <Riddell> NCommander: still going
[01:13] <mathiaz> Riddell: hm - seems that -server isos have disappered
[01:13] <mathiaz> Riddell: 20100928.2 is no longer available from http://cdimage.ubuntu.com/ubuntu-server/daily/
[01:13] <Riddell> umm
[01:13] <Riddell> spooky
[01:14] <Riddell> mathiaz: they're still there on antimony but maybe they're not on one of the mirrors
[01:14] <Riddell> elmo did say they were getting full
[01:15] <mathiaz> Riddell: ok
[01:15]  * mathiaz hopes they'll show up eventually
[01:17] <NCommander> Riddell: very slow :-/
[01:17] <Riddell> NCommander: yes, and I need to go to bed now
[01:18] <Riddell> mathiaz: I'm copying the images over to http://jasmine.19inch.net/~jr/tmp/ubuntu-server/ incase you need them now
[01:18] <mathiaz> Riddell: I won't need them now
[01:18] <mathiaz> Riddell: it would be great if they can show up in a couple of hours
[01:19] <Riddell> NCommander: going to sleep now, feel free to kill the process if it doesn't get done soonish
[01:39] <NCommander> Riddell: k
[01:40] <maxb> Hi, Bazaar in maverick is 2.2.0. 2.2.1 is released, with some fairly important bugfixes. Can you advise if we should aim for a SRU or a (very) late-breaking release pocket upload? (pitti suggested the latter in bug 636930, but that was some days ago, so may no longer be valid)
[01:40] <ubot4> Launchpad bug 636930 in bzr (Ubuntu Maverick) (and 4 other projects) "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affects: 5) (dups: 4) (heat: 288)" [Undecided,Triaged] https://launchpad.net/bugs/636930
[02:02] <ScottK> maxb: Since it's eligible for post-release micro-version update, I don't see a strong reason to wait.  If all the same testing is done as for a post-release update, I think it would be reasonable to drop it in between RC and final.
[02:11] <maxb> Right, that makes sense
[03:50] <mathiaz> ScottK: IIUC accepting bzr would require an ISO respin
[04:31] <ScottK> mathiaz: That's why I said after RC.
[07:15] <ara> good morning!
[08:31] <ara> Riddell, morning
[08:31] <ara> Riddell, rekonq is crashing for me in kvm, is that known?
[09:14] <ara> seb128, as RAOF has confirmed that it is a mesa issue, I think we should add it to the release notes for RC
[09:34] <Riddell> ara: not known to me
[09:34] <ara> Riddell, OK, thanks, I will file a bug
[09:42] <ara> Riddell, bug 650934
[09:42] <ubot4> Launchpad bug 650934 in rekonq (Ubuntu) "Rekonq crashes in a KVM with 800MB ram (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/650934
[10:03] <cjwatson> stgraber: hm, this is odd, can't immediately figure out why it went to desktop ...
[10:03] <cjwatson> ubuntu-desktop I mean
[10:05] <cjwatson> germinate shows it in edubuntu/desktop-gnome, edubuntu/desktop-kde, edubuntu/ubuntu-edu-preschool, and edubuntu/ubuntu-edu-primary
[10:06] <Daviey> Hey!  What are the chances of a respin happening before RC?  We don't need one, but wondered if foundation are likely to call one.
[10:07]  * cjwatson hasn't heard of a reason right now
[10:07] <cjwatson> not globally anyway, edubuntu might need one
[10:10] <Daviey> ok great, the current situation with the server seems to be pretty sound.  The only edge case of concern is people using the on cd archive to upgrade UEC, will get a silent failure.  There is a work around for this, if we had a respin it would close this edge case - but not worth making a new ISO for that IMO.
[10:11] <Daviey> (new installs are unaffected)
[10:12] <cjwatson> what package is the workaround in?
[10:14] <Daviey> eucalyptus-java-common, has been fixed to stop euca' before attempting to upgrade the database.  The work around, would be a copy and paste # stop eucalyptus ; do-upgrade() ; start eucalyptus, after reboot
[10:15] <Daviey> (database schema upgrade is handled in packaging)
[10:17] <cjwatson> did we not respin after that fix last night?
[10:17] <cjwatson> maverick-server-amd64.list:/pool/main/e/eucalyptus/eucalyptus-java-common_2.0+bzr1241-0ubuntu4_amd64.deb
[10:17] <cjwatson> maverick-server-i386.list:/pool/main/e/eucalyptus/eucalyptus-java-common_2.0+bzr1241-0ubuntu4_i386.deb
[10:18] <cjwatson> eucalyptus-java-common | 2.0+bzr1241-0ubuntu4 |      maverick | amd64, armel, i386, powerpc
[10:18] <cjwatson> all in sync
[10:20] <Daviey> ahh, sorry - i was mistaken
[10:20] <Daviey> i didn't realise there was a new spin last night
[10:21] <cjwatson> there was some difficulty pushing to cdimage mirrors I think
[10:21] <cjwatson> let me see if that's resolved
[10:22] <cjwatson> looks ok, you want 20100928.2
[10:22] <Daviey> cjwatson: so, the server team should be considering 20100928.1 as the RC candidate?
[10:22] <cjwatson> .2
[10:22] <cjwatson> surely?
[10:22] <Daviey> that isn't on cdimages.*
[10:22] <cjwatson> it is on some of them
[10:22] <cjwatson> I just checkd
[10:22] <cjwatson> +e
[10:23] <Daviey> ahh
[10:23] <cjwatson> (p.s. official name is cdimage.ubuntu.com not cdimages)
[10:23] <cjwatson> it's also on the ISO tracker
[10:23] <cjwatson> ok, so I just deleted a pile of older builds; let's see if that helps cdimage pick it up
[10:23] <cjwatson> try it again in a few minutes?
[10:23] <Daviey> cjwatson: rockin' thanks.
[10:24] <Daviey> So, when .2 shows up - we will spend today doing some pre-RC testing.
[10:56] <cjwatson> stgraber: wow, that was more complicated than I expected it to be, but fixed now
[10:56] <cjwatson> stgraber: you gained edubuntu-live as well in the same process
[10:57] <cjwatson> and ubuntu-desktop lost those two and language-pack-kde-*, which is obviously correct anyway
[10:57]  * ogra would appreciate an armel rebuild ... i assume the archive should be setteled by now
[12:02] <Riddell> NCommander, GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100929/
[12:03] <NCommander> Riddell: yup, saw, thanks. Already did a successful test install :-)
[12:20] <cjwatson> robbiew: we're due an EOL announcement for jaunty soon, aren't we?  https://wiki.ubuntu.com/EndOfLifeProcess
[12:21] <cjwatson> ah, heh, I see you edited https://wiki.ubuntu.com/EndOfLifeAnnouncement recently so I guess you know ...
[12:21] <ScottK> IIRC it went out a few days ago.
[12:35] <ogra> Riddell, thanks a lot
[12:37] <Riddell> ogra: you're welcome.  what did I do?
[12:37] <ogra> roll ne images :)
[12:37] <ogra> *new
[12:37]  * ogra was waiting to test the new bootloader on omap3
[13:19] <smoser> cjwatson, or slangasek could you populate iso tracker from http://uec-images.ubuntu.com/server/maverick/20100928.4/published-ec2-daily.txt
[13:19] <smoser> and also list 20100928.4 as the uec images to be tested.
[13:38] <cjwatson> smoser: done and done
[13:38] <ScottK> cjwatson: Does x-loader belong in some package set (I find it unusual to see packages in Main that don't)?
[13:38] <smoser> gracias.
[13:40] <cjwatson> ScottK: how odd.  it *ought* to be in core
[13:47] <cjwatson> oh, eek
[13:47] <cjwatson> ScottK: thanks, nasty bug - it was using the i386 Packages file regardless of architecture, I think
[13:47] <ScottK> cjwatson: You're welcome.
[13:48] <ScottK> Convenient of wgrant to put the package sets on the package acceptance page so the lack would be there staring at me.
[13:55] <doko_> ok to sync http://packages.debian.org/changelogs/pool/main/libd/libdbd-sqlite3-perl/current/changelog ? fixes ftbfs
[13:56] <ScottK> doko_: Did your ucf update get resolved?  I just went looking for the FFe bug and couldn't find it.
[13:56] <doko_> ScottK: it was ufc
[13:56] <doko_> anyway, not needed
[13:57] <ScottK> That would explain why I couldn't find it.  OK.
[13:57] <ScottK> doko_: It's in Main, so it needs to wait until after RC.
[13:57] <ScottK> (after that, it looks good)
[14:06] <cjwatson> ScottK: how exciting.  http://paste.ubuntu.com/502618/
[14:06] <cjwatson> I'm going to apply that as it looks basically correct - TBH if the Ubuntu Studio guys want to fix ia32-libs they're welcome to it :-)
[14:07] <ScottK> Absolutely.
[14:08] <persia> Quite possibly the fix there will lead to work to drop that from Ubuntu Studio again.
[14:17] <ScottK> cjwatson: The correction to the package set already shows up on the LP package accept page.  Very nice.
[14:19] <cjwatson> ScottK: yep, seems to be immediate, which is good
[14:25]  * Riddell out for a bit
[14:55] <ScottK> There's a reasonable stack of Universe syncs in the queue if anyone has time to look ...
[18:13] <ScottK> Is it known/on purpose we have a newer mountall in the archive than is on the Kubuntu live CD (i386)
[18:15] <ScottK> Riddell: ^^^?
[18:26] <doko> skaet: what is wrong with keeping bug #635891 open for natty?
[18:26] <ubot4> Launchpad bug 635891 in lprof (Ubuntu Maverick) (and 3 other projects) "libvigraimpex (main) build-depends on hfd5 (universe) (affects: 1) (heat: 188)" [High,Fix released] https://launchpad.net/bugs/635891
[18:27] <skaet> doko,  was just assigning it.
[18:29] <skaet> making sure it was on someone's monitoring list,   for writing release notes,  if its not going to be fixed.
[18:30] <persia> skaet, Isn't it better to do that with a release-notes task?
[18:30] <persia> That way it shows up in https://bugs.launchpad.net/ubuntu-release-notes
[18:30] <persia> (and we can track when it gets release-noted separately from when it gets fixed)
[18:31] <skaet> persia,  will be doing that too.
[18:32] <skaet> just changed the assigned to field to be the desktop team, from unassigned.
[19:47] <doko> need somebody to approve for bug #642344 tiles (unapproved) and mvel2 (new), new upstream version just taken and renamed from debian
[19:47] <ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 3 other projects) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/642344
[19:48] <ScottK> doko: I just approved tiles.
[19:49] <doko> ScottK: then you have to approve mvel2 too =)
[19:50] <ScottK> OK
[19:53] <stgraber> cjwatson: thanks (for the packageset change)
[19:56] <ScottK> doko: I'll have to look at New tonight or tomorrow, but seems fine.
[19:57] <doko> ScottK, cjwatson: would be nice to have it built tomorrow morning/noon my time. still doing the manual bootstrap with #is
[19:57] <ScottK> OK. Will try.  If some else gets to it first, I won't mind.
[20:00] <doko> hmm, why doesn't my grace upload show up?
[20:01] <ScottK> doko: It's in the queue, but it's in the Xubuntu packageset, so not accepting until after RC.
[20:01] <doko> ahh, ok
[20:03] <doko> ScottK: what about drizzle, will it be removed? just asking for NBS ...
[20:03] <ScottK> Yes.
[20:03] <ScottK> Upstream decided they'd rather ship nothing at this point and I think we aren't going to disagree.
[20:04] <ScottK> There's a removal bug pending.
[20:16] <CardinalFang> I have a question about our current release state.  The "unapproved" queue has close to 40 items in it.  Is "approved" frozen while we make RC images or something like that?
[20:19] <persia> CardinalFang, For anything that lands on an image undergoing validation, yes (unless the image fails validation and the release team for that image needs a specific package for a respin)
[20:28] <CardinalFang> persia, okay.  I (=Online Services) care about two packages in the "unapproved" queue.  I don't know what I should be doing now.  Waiting, perhaps?
[20:28] <persia> Which packages?
[20:29] <ScottK> CardinalFang: Unless it rises to the level of "We should not release the RC unless we fix this", waiting is appropriate.
[20:30] <CardinalFang> persia, ubuntuone-client, desktopcouch .
[20:30] <persia> Yeah, those need waiting.
[20:30] <CardinalFang> ScottK, I don't think we should stop RC, no.
[20:30] <persia> CardinalFang, If it was some package that wasn't used on any image, and you had a really good reason, you could beg, but those appear on images.
[20:33] <ScottK> Stuff that's not in Main or seeded on an image, I'm pushing through, so those wouldn't be waiting.
[20:35] <persia> Ah, with that information, yes no need for package names to reach a conclusion :)
[20:42] <CardinalFang> persia, okay, I guess my only question is, wait for what?  What happens next for me?
[20:42] <CardinalFang> I guess I fear being asleep when someone asks a question about them.
[20:43] <persia> Wait for RC to be released.
[20:44] <CardinalFang> persia, okay.  Sorry for sounding neurotic.
[22:53] <ScottK> doko: mvel2 source accepted.
[23:10] <doko> ScottK: thanks
[23:48] <Riddell> ScottK: hmm, no I didn't see that it had the old mountall
[23:49] <Riddell> cjwatson: just how serious is that mountall bug?


[00:10] -queuebot:#ubuntu-release- New binary: tinymembench [riscv64] (noble-proposed/universe) [0.4+git20231218+ds-1] (no packageset)
[00:21] -queuebot:#ubuntu-release- New binary: vulkan-utility-libraries [riscv64] (noble-proposed/universe) [1.3.268.0-1] (no packageset)
[00:23] -queuebot:#ubuntu-release- New binary: nihstro [riscv64] (noble-proposed/universe) [0.0~git20211107.e924e21-1] (no packageset)
[00:28] -queuebot:#ubuntu-release- New binary: opustags [riscv64] (noble-proposed/universe) [1.9.0-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-cenkalti-rpc2 [amd64] (noble-proposed/universe) [1.0.0-3] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: golang-github-harenber-ptc-go [amd64] (noble-proposed/universe) [2.2.3-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: golang-github-golang-jwt-jwt-v5 [amd64] (noble-proposed/universe) [5.2.0-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: papi [amd64] (noble-proposed/universe) [7.1.0-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: golang-github-openfga-go-sdk [amd64] (noble-proposed/universe) [0.3.3-2] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: papi [armhf] (noble-proposed/universe) [7.1.0-2] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: papi [arm64] (noble-proposed/universe) [7.1.0-2] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: papi [ppc64el] (noble-proposed/universe) [7.1.0-2] (no packageset)
[07:00] -queuebot:#ubuntu-release- New: accepted fortunes-it [amd64] (noble-proposed) [2.2-2]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-golang-jwt-jwt-v5 [amd64] (noble-proposed) [5.2.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-harenber-ptc-go [amd64] (noble-proposed) [2.2.3-1]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-openfga-go-sdk [amd64] (noble-proposed) [0.3.3-1]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [amd64] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [armhf] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [riscv64] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [amd64] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [armhf] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [riscv64] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-cenkalti-rpc2 [amd64] (noble-proposed) [1.0.0-3]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-harenber-ptc-go [amd64] (noble-proposed) [2.2.3-2]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [arm64] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [s390x] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [ppc64el] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted python-opem [amd64] (noble-proposed) [1.3+dfsg-1]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [arm64] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [ppc64el] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [s390x] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [arm64] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-golang-jwt-jwt-v5 [amd64] (noble-proposed) [5.2.0-2]
[07:00] -queuebot:#ubuntu-release- New: accepted nihstro [ppc64el] (noble-proposed) [0.0~git20211107.e924e21-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [s390x] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [armhf] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [amd64] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [ppc64el] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [s390x] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted golang-github-openfga-go-sdk [amd64] (noble-proposed) [0.3.3-2]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [amd64] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [armhf] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted opustags [arm64] (noble-proposed) [1.9.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted vulkan-utility-libraries [riscv64] (noble-proposed) [1.3.268.0-1]
[07:00] -queuebot:#ubuntu-release- New: accepted tinymembench [riscv64] (noble-proposed) [0.4+git20231218+ds-1]
[07:00] -queuebot:#ubuntu-release- New: accepted papi [arm64] (noble-proposed) [7.1.0-2]
[07:00] -queuebot:#ubuntu-release- New: accepted papi [ppc64el] (noble-proposed) [7.1.0-2]
[07:00] -queuebot:#ubuntu-release- New: accepted papi [amd64] (noble-proposed) [7.1.0-2]
[07:00] -queuebot:#ubuntu-release- New: accepted papi [armhf] (noble-proposed) [7.1.0-2]
[11:14] -queuebot:#ubuntu-release- New binary: python-pyproject-parser [amd64] (noble-proposed/none) [0.9.1-2] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: lib25519 [amd64] (noble-proposed/none) [0~20230630-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: sail [amd64] (noble-proposed/none) [0.9.0+repack-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: zuo [amd64] (noble-proposed/none) [1.9-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: vibes [amd64] (noble-proposed/none) [0.2.3+dfsg-1] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: lib25519 [armhf] (noble-proposed/none) [0~20230630-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: vibes [arm64] (noble-proposed/none) [0.2.3+dfsg-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: lib25519 [s390x] (noble-proposed/none) [0~20230630-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: sail [armhf] (noble-proposed/none) [0.9.0+repack-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: zuo [armhf] (noble-proposed/none) [1.9-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: sail [arm64] (noble-proposed/none) [0.9.0+repack-1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: vibes [armhf] (noble-proposed/none) [0.2.3+dfsg-1] (no packageset)
[17:38] -queuebot:#ubuntu-release- New binary: sail [s390x] (noble-proposed/none) [0.9.0+repack-1] (no packageset)
[17:38] -queuebot:#ubuntu-release- New binary: vibes [s390x] (noble-proposed/none) [0.2.3+dfsg-1] (no packageset)
[17:41] -queuebot:#ubuntu-release- New binary: zuo [s390x] (noble-proposed/universe) [1.9-1] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: lib25519 [ppc64el] (noble-proposed/universe) [0~20230630-1] (no packageset)
[17:43] -queuebot:#ubuntu-release- New binary: sail [ppc64el] (noble-proposed/universe) [0.9.0+repack-1] (no packageset)
[17:44] -queuebot:#ubuntu-release- New binary: vibes [ppc64el] (noble-proposed/universe) [0.2.3+dfsg-1] (no packageset)
[17:47] -queuebot:#ubuntu-release- New binary: zuo [ppc64el] (noble-proposed/universe) [1.9-1] (no packageset)
[17:53] -queuebot:#ubuntu-release- New binary: lib25519 [riscv64] (noble-proposed/universe) [0~20230630-1] (no packageset)
[18:00] -queuebot:#ubuntu-release- New binary: zuo [riscv64] (noble-proposed/universe) [1.9-1] (no packageset)
[18:03] -queuebot:#ubuntu-release- New binary: sail [riscv64] (noble-proposed/universe) [0.9.0+repack-1] (no packageset)
[18:06] -queuebot:#ubuntu-release- New binary: vibes [riscv64] (noble-proposed/universe) [0.2.3+dfsg-1] (no packageset)
[18:21] -queuebot:#ubuntu-release- New binary: zuo [arm64] (noble-proposed/universe) [1.9-1] (no packageset)
[19:31] -queuebot:#ubuntu-release- New: accepted lib25519 [amd64] (noble-proposed) [0~20230630-1]
[19:31] -queuebot:#ubuntu-release- New: accepted lib25519 [ppc64el] (noble-proposed) [0~20230630-1]
[19:31] -queuebot:#ubuntu-release- New: accepted lib25519 [s390x] (noble-proposed) [0~20230630-1]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [amd64] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [armhf] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [riscv64] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [amd64] (noble-proposed) [0.2.3+dfsg-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [armhf] (noble-proposed) [0.2.3+dfsg-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [riscv64] (noble-proposed) [0.2.3+dfsg-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [amd64] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted lib25519 [armhf] (noble-proposed) [0~20230630-1]
[19:31] -queuebot:#ubuntu-release- New: accepted python-pyproject-parser [amd64] (noble-proposed) [0.9.1-2]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [ppc64el] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [arm64] (noble-proposed) [0.2.3+dfsg-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [s390x] (noble-proposed) [0.2.3+dfsg-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [armhf] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [riscv64] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted lib25519 [riscv64] (noble-proposed) [0~20230630-1]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [s390x] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [arm64] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [s390x] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted sail [arm64] (noble-proposed) [0.9.0+repack-1]
[19:31] -queuebot:#ubuntu-release- New: accepted zuo [ppc64el] (noble-proposed) [1.9-1]
[19:31] -queuebot:#ubuntu-release- New: accepted vibes [ppc64el] (noble-proposed) [0.2.3+dfsg-1]
[22:10] -queuebot:#ubuntu-release- New binary: slepc4py [amd64] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[22:10] -queuebot:#ubuntu-release- New binary: slepc4py [armhf] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[22:12] -queuebot:#ubuntu-release- New binary: slepc4py [ppc64el] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[22:12] -queuebot:#ubuntu-release- New binary: slepc4py [s390x] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[22:24] -queuebot:#ubuntu-release- New binary: slepc4py [arm64] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[22:59] -queuebot:#ubuntu-release- New binary: python-lib25519 [amd64] (noble-proposed/universe) [0~20230630.1-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: python-lib25519 [amd64] (noble-proposed/universe) [0~20230630.1-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: c-blosc2 [amd64] (noble-proposed/universe) [2.12.0+ds-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: slepc4py [riscv64] (noble-proposed/universe) [3.19.2-1ubuntu3] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: c-blosc2 [ppc64el] (noble-proposed/universe) [2.12.0+ds-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: c-blosc2 [arm64] (noble-proposed/universe) [2.12.0+ds-1] (no packageset)
[23:46] -queuebot:#ubuntu-release- New: accepted c-blosc2 [amd64] (noble-proposed) [2.12.0+ds-1]
[23:46] -queuebot:#ubuntu-release- New: accepted c-blosc2 [ppc64el] (noble-proposed) [2.12.0+ds-1]
[23:46] -queuebot:#ubuntu-release- New: accepted python-lib25519 [amd64] (noble-proposed) [0~20230630.1-2]
[23:46] -queuebot:#ubuntu-release- New: accepted c-blosc2 [arm64] (noble-proposed) [2.12.0+ds-1]
[23:46] -queuebot:#ubuntu-release- New: accepted python-lib25519 [amd64] (noble-proposed) [0~20230630.1-1]
[23:51] -queuebot:#ubuntu-release- New binary: c-blosc2 [riscv64] (noble-proposed/universe) [2.12.0+ds-1] (no packageset)