[20:28] -queuebot:#ubuntu-release- Unapproved: openvswitch (mantic-proposed/main) [3.2.0-1 => 3.2.1-0ubuntu<IP_ADDRESS>] (core)
[20:29] -queuebot:#ubuntu-release- Unapproved: openvswitch (lunar-proposed/main) [3.1.2-0ubuntu<IP_ADDRESS> => 3.1.3-0ubuntu<IP_ADDRESS>] (core)
[20:30] -queuebot:#ubuntu-release- Unapproved: openvswitch (jammy-proposed/main) [2.17.7-0ubuntu<IP_ADDRESS> => 2.17.8-0ubuntu<IP_ADDRESS>] (core)
[20:46] -queuebot:#ubuntu-release- Unapproved: mcomix (mantic-proposed/universe) [2.1.0-2 => 2.1.0-2ubuntu1] (no packageset)
[23:30] <tsimonq2> xnox: ack thanks
[23:31] -queuebot:#ubuntu-release- Unapproved: lubuntu-update-notifier (jammy-proposed/universe) [0.5.1~22.04.3 => 0.5.1~22.04.6] (lubuntu)
[23:31] -queuebot:#ubuntu-release- Unapproved: lubuntu-update-notifier (lunar-proposed/universe) [0.5.4 => 0.6.0~23.04.3] (lubuntu)
[23:31] -queuebot:#ubuntu-release- Unapproved: lubuntu-update-notifier (mantic-proposed/universe) [0.5.4 => 0.6.2~23.10.1] (lubuntu)
[23:34] <tsimonq2> vorlon cc bdmurray: And your updated SRUs, no longer doing that output scraping garbage. :) ^^^
[23:34]  * tsimonq2 has his finger hovering over the dput button for noble... ;)


[21:32] <thumper> veebers: is there something wrong with the merge bot?
[21:32] <veebers> thumper: not that I'm aware of, whats the issue/
[21:32] <veebers> thumper: (which merge job?)
[21:33] <thumper> I was just looking at one of jam's branches
[21:33] <thumper> saw the merge request but no bot response
[21:33] <thumper> https://github.com/juju/juju/pull/8557
[21:33] <veebers> thumper: it's possible it's the issue where the hook gets dropped or ignored by jenkins.
[21:33] <thumper> do the checks on a PR get cleared on new pushes?
[21:34] <veebers> thumper: checks get re-run on pushes. (you can see ticks/crosses beside the commit sha in the list)
[21:35] <thumper> I know that the merge jobs just show up as checks now...
[21:35] <thumper> perhaps it was just that
[21:35] <thumper> never mind me
[21:35] <veebers> thumper: If the merge bot had run it would have been merged, unless there was an issue then it would show as a failure
[21:36] <thumper> but we don't add a comment on failure, do we?
[21:36] <veebers> thumper: if you click "show all checks" you'll see that only the check-merge job has run
[21:36] <veebers> thumper: it would show up in the checks list
[21:37] <thumper> ah, found it
[21:38] <veebers> thumper: argh, so the merge job did run (before your current one) and went unstable, no idea why it didn't update the PR. :-\ Having a quick look now
[21:38] <thumper> ok, thanks
[21:51] <veebers> thumper: I'm a little confused :-\ jams merge command worked, it ran and failed and marked that commit broken (red cross) but it wasn't mentioned in the checks section. Jam then pushed up some  . ..  ah
[21:51] <veebers> thumper: It seems that pushing up a commit and getting a run on it clears any previous runs (incl. failures) so the updated push removed the check comment for the failed merge (it was still marked as error by the red cross though)
[21:52]  * veebers is no longer confused
[21:52]  * thumper nods
[21:57] <thumper> morning wallyworld
[21:57] <wallyworld> hey
[21:57] <thumper> veebers: do you use spacemacs with vim editing or emacs?
[22:08] <veebers> thumper: emacs
[22:08] <veebers> wallyworld: hey o/
[22:08] <wallyworld> hiya
[22:09] <anastasiamac> o/


[00:36] <jbicha> meway: did you visit edubuntu.org? Edubuntu is Ubuntu with a lot of educational software pre-installed
[00:37] <meway> yes I did
[00:37] <meway> oh I see :)


[14:29] <jrwren>  oh linux community, keep being linux community. https://github.com/libsdl-org/SDL/pull/9345
[14:45] <Scary_Guy> The only thing I don't like about Wayland is it currently breaks Synergy/BarrierKVM functionality.


[05:17] <mborzecki> morning
[05:44] <zyga> Good morning
[05:47] <mborzecki> zyga: hey
[05:53] <zyga> mborzecki: how are you today?
[05:56] <zyga> mborzecki: we are moving again but this time relatively very little
[05:58] <mborzecki> zyga: changing places?
[05:58] <mborzecki> zyga: it's damn hot today again
[06:00] <zyga> mborzecki: yeah, we didn't rent a single place for the whole duration of our stay
[06:00] <zyga> (which is uncertain anyway)
[06:00] <zyga> mborzecki: here we have finally some clouds
[06:01] <zyga> mborzecki: it is just 23C and very very pleasant
[06:01] <zyga> I'll check my PRs, some are close to landing
[06:04] <zyga> mborzecki: do you think this will pass?
[06:04] <zyga> https://www.irccloud.com/pastebin/bVNC8zuG/
[06:05] <mborzecki> zyga: mhm, looks good to me
[06:06] <zyga> I've replicated the case for generic ubuntu that matches apparmor, starting spread
[06:06] <zyga> let's see
[06:06] <zyga> I just noticed the grass is still wet, wow it is really cold and cloudy today
[06:07] <mborzecki> zyga: isn't that /usr/bin/sh vs /bin/sh ?
[06:07] <zyga> mborzecki: yeah, I am pretty sure that is is
[06:07] <mborzecki> zyga: at laest on fedora/centos/amzn
[06:07] <zyga> mborzecki: we have a magic thing in our spec that disables the rewrite that normally happens
[06:07] <zyga> mborzecki: which makes me think that:
[06:07] <mborzecki> zyga: oh, right
[06:07] <zyga> 1) it was always broken for hotplug
[06:07] <zyga> 2) device cgroup was not tested on those systems effectively
[06:08] <zyga> 3) after fixing this we will kill two birds with one stone
[06:08] <zyga> mborzecki: I'll check that shortly
[06:08] <zyga> but it sounds plausible to me
[06:20] <mborzecki> mvo: morning, not taking a day off?
[06:22] <zyga> mvo: hello
[06:24] <mvo> hey zyga and mborzecki !
[06:25] <zyga> how are you doing?
[06:25] <zyga> good to be home?
[06:25] <mvo> mborzecki, zyga I will be here today, want to be part of the standup, talk about the sprint and also welcome ian today
[06:25] <mborzecki> mvo: yay, ijohnson is starting today?
[06:25] <mvo> zyga: yes, very good to be home, we had a network outage over the weekend, no phone or internet, so even a forced holiday from all digital things :)
[06:25] <mvo> mborzecki: yes
[06:26] <mvo> mborzecki: I think so at least, will double check for any last minute changes :)
[06:26] <mborzecki> mvo: great to have the team grow in size :)
[06:26] <mvo> mborzecki: yeah, I'm excited too
[06:27] <mvo> mborzecki, zyga how are you ? what did I miss? sorry for not joining the standup once, it was very busy
[06:27] <zyga> mvo: relatively quiet week; some excessive iteration on the lxd fix
[06:27] <zyga> mvo: but it now has two approvals and just a few comments to tweak
[06:28] <mvo> zyga: \o/ thanks for jumping on this one
[06:28] <mvo> zyga: and you made the trip and are "settled" now?
[06:28] <zyga> mvo: haha
[06:28] <zyga> mvo: we are moving today
[06:28] <zyga> but not far
[06:28] <zyga> so ...
[06:28] <mborzecki> mvo: landed some gadget updates bits, more on reviews still, but we're closing in
[06:28] <zyga> it's not the most stable work environment ;)
[06:29] <mvo> mborzecki: yay, thanks for this
[06:30] <zyga> mvo: I have some feedback from manjaro, one small fix to a shell script to send
[06:33] <mvo> zyga: cool!
[06:40] <zyga> mborzecki: I know why that trivial udev change didn't work, fixed, let's see if it passes now
[06:47] <mborzecki> got an errand to run, bbiab
[06:56] <ackk> hi, I'm having an issue building a python C extension in a snap (actually a dependency of what I'm snapping). I have a reproducer with a minimal snap that just builds the library: http://paste.ubuntu.com/p/qmxp7rBh6Z/. the error is http://paste.ubuntu.com/p/kgwcB673qf/ am I missing something in the build configuration?
[06:58] <zyga> mborzecki: it passed, pushed now
[06:59] <zyga> ackk: looks like lack of header
[07:00] <ackk> zyga, those headers are in the library itself
[07:01] <ackk> zyga, -Iast27/Include
[07:02] <ackk> zyga, needless to say that if I create a virtualenv and pip install typed-ast --no-binary=typed-ast it works
[07:05] <zyga> ackk: but is that path OK when in snapcraft?
[07:05] <zyga> it is a relative path, not sure if that is good here
[07:05] <ackk> mhm
[07:06] <ackk> zyga right but I think it's assumed to build from the base of the package
[07:06] <zyga> I don't know, just guessing based on what the errors said
[07:06] <ackk> not sure if snapcraft does something different, but it should just call pip ?
[07:10] <zyga> mvo: https://github.com/snapcore/snapd/pull/7048 needs a 2nd review and is super simple
[07:14] <zyga> mborzecki: final remark on https://github.com/snapcore/snapd/pull/7026 -- I would like not to enforce \n on the final line. I think it is too pedantic and doesn't win us anything while actively closing the utility of the parser down the line.
[07:14] <zyga> mborzecki: I pushed remaining tweaks and intend to merge when green
[07:14] <zyga> mborzecki: if you feel strongly about the newline please indicate so
[07:14] <zyga> mborzecki: since you are on an errand now I'll wait until you return
[07:15] <mvo> zyga: thanks, checking now
[07:16] <pstolowski> mornings!
[07:16] <pstolowski> welcome back mvo!
[07:16] <mvo> pstolowski: good morning! and thank you :)
[07:16] <mvo> pstolowski: feels good to be back :)
[07:20] <zyga> mvo: thank you :)
[07:20] <zyga> hello Pawel!
[07:29] <ackk> zyga, I wonder if it has to do with the fact that snapcraft calls "pip wheel" not "pip install", or because of environ
[07:29] <zyga> I really don't know, it would be good to see if you can reproduce the failure without snapcraft involved
[07:32]  * zyga jumps at https://github.com/snapcore/snapd/pull/6891 again
[07:42] <zyga> mvo: 1-2-1 in 15 minutes, right?
[07:47] <mvo> zyga: yes
[07:47] <diddledan> ackk: seemingly works when you remove `--no-binary=typed-ast` <-- I've never seen parameters passed this way and have no idea if that is even likely to work
[07:48] <ackk> diddledan, yes, because on amd64/i386 that library is available as binary. on other arches it fails because it tries to build it. to test it I'm passing --no-binary to reproduce the issue on amd64
[07:48] <ackk> diddledan, the original issue is that if you have no binary package for that library, it fails to build. I've seen similar issues with other libraries
[08:27] <mborzecki> re
[08:33] <mborzecki> zyga: for the sake of landing this fast and since we agreed on it on friday, let's maybe stick to \n for now
[08:44] <mborzecki> zyga: interestingly the PR with udev helper still fails on opensuse https://github.com/snapcore/snapd/pull/7049#issuecomment-507173763
[08:44] <zyga> I didn't change opensuse yet
[08:46] <mborzecki> zyga: take a look at the log, it's like a lib is missing
[08:52] <pedronis> mborzecki: hi, after the fact comment,  gadget.Partition probably merits a doc comment
[08:52] <mborzecki> pedronis: ok, will add
[08:54] <pedronis> thx
[09:00] <zyga> hello pedronis
[09:00] <zyga> welcome back!
[09:06] <pstolowski> oh well, snap config stuff is fun
[09:07] <Chipaca> pstolowski: orly
[09:09] <diddledan> ackk: it looks like the failure is induced by setting `CFLAGS="-I/usr/include/python3.6"`
[09:10] <ackk> diddledan, which is set by snapcraft?
[09:11] <diddledan> yes
[09:21] <mborzecki> microk8s uses a vm to start the node?
[09:22] <diddledan> no, it runs directly
[09:30]  * zyga could use a coffee
[09:30] <pedronis> mvo: hi, we still need to publish 2.39.3 to snapd, right?
[09:34] <mvo> pedronis: checking
[09:34] <pedronis> mvo: is not even in beta afaict
[09:34] <mvo> pedronis: it only affects devices so I think we don't need to SRU it, we should make it available on GH but no need for packaging updates either
[09:34] <mvo> pedronis: let me check that
[09:36] <mvo> pedronis: oh, the snapd snap - yes, need to check with sergio but yes, that needs to go out
[09:36]  * mvo prepares beta
[09:36] <pedronis> yes, the snapd snap
[09:36] <pedronis> sorry
[09:43]  * Chipaca takes a break
[09:56] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049
[09:58] <mborzecki> zyga: heh, so AA blocked that
[09:58] <zyga> yeah, I'm so happy we have that distro
[10:00] <zyga> brb, taking out the garbage
[10:15] <abeato> pedronis, hey, did you see latest comment from Jamie in https://github.com/snapcore/snapd/pull/5915 ? is that a thumbs up for implementing 'snapctl netplan-apply'?
[10:21] <zyga> re
[10:30] <Chipaca> mvo, pedronis, re some of the less serious things we talked about last week I finally heard back from my archiver :-p   http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/presentacion/
[10:30] <Chipaca> check out those super high resolution photos taken with an actual digital camera omgz
[10:34] <Chipaca> hmmmm
[10:34] <Chipaca> pstolowski: for automatic snapshots I suspect having 'expires=YYYY-mm-dd' instead of 'auto' might be more useful
[10:34] <Chipaca> pedronis: WDYT?
[10:36] <mvo> Chipaca: woah, when were these pics taken?
[10:36] <pstolowski> Chipaca: oh wow, who is this guy on 3rd photo? :)
[10:36] <Chipaca> mvo: '00 iirc
[10:36] <mvo> Chipaca: amazing :)
[10:37] <Chipaca> mvo: we were very proud of our server at the time: http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/machines/pv-1/
[10:37] <Chipaca> proud mostly in that we were able to afford it, and it actually booted and ran fine as long as you held down a certain capacitor on the main hdd during boot
[10:37] <Chipaca> :-)
[10:40] <Chipaca> (also that rickety shelf was actually a controlled atmosphere because it was in the atmo lab at the uni)
[10:42]  * Chipaca still puzzled about 'snap install --verbose'
[10:43] <ogra> you should make it read the output through speakers very loudly when --verbose is set ;)
[10:43] <pedronis> Chipaca: what's the question?
[10:43] <Chipaca> https://forum.snapcraft.io/t/how-to-run-a-snap-install-verbose-in-terminal/12100?u=chipaca
[10:44] <Chipaca> ogra: xsublim, but for pulseaudio
[10:45] <pedronis> abeato: we discussed that a bit more last week, I think there is some idea to do that but let "netplan apply" call it if inside a snap
[10:46] <ogra> Chipaca, lol
[10:47] <abeato> pedronis, you mean change netplan to call the snapd API to re-start daemons if it detects it is being run inside a snap?
[10:47] <pedronis> abeato: no, to call an api that does the full apply
[10:47] <pedronis> not just restart daemons
[10:47] <pedronis> well really call snapctl, not an api
[10:47] <pedronis> as low-tech as possible, basically
[10:48] <abeato> pedronis, ah, I thought that was what 'snapctl netpla-apply' was going to do
[10:48] <abeato> so no changes there
[10:48] <pedronis> abeato: yes, but saying the snap will just call netplan
[10:49] <abeato> pedronis, so the snap will call netplan and netplan will run snapctl netplan-apply?
[10:52] <pstolowski> Chipaca: expiration instead of auto sounds fine, it would reduce the need to read expiration time again on execution of the task. a side-effect of such change is obviously the effective expiration (calculated when the task is created vs when it's executed)
[10:52] <ogra> the snap will call snapctl and netplan itself will work aotomonously is what i understand from jamies comments
[10:52] <ogra> *autonomously
[10:52] <pstolowski> Chipaca: i'm not sure if it's an issue or not, probably is fine
[10:54] <pedronis> abeato: yes, something like that
[10:55] <abeato> ok, I guess that can work too
[10:56] <abeato> ogra, the wording is slightly confusing tbh, I think he wants to make all this transparent to the netplan caller
[10:57] <ogra> yeah, true
[10:57]  * pstolowski lunch
[10:58] <Chipaca> debian 9 is buster, yes?
[11:00] <Chipaca> hm, 9 is stretch
[11:00] <zyga> Chipaca: stretch
[11:00] <Chipaca> debian has re-exec?
[11:00] <zyga> https://en.wikipedia.org/wiki/Debian#Code_names
[11:00] <zyga> Chipaca: yes it does
[11:00] <mvo> pedronis: snapd 2.39.3 is now in beta, now sergio and cert need to jump on it :)
[11:00] <ogra> streched re-exec
[11:03] <pedronis> mvo: ok
[11:05] <Chipaca> zyga, degville: fwiw https://forum.snapcraft.io/t/cannot-install-snap-store-on-debian-9/12077?u=chipaca
[11:07] <degville> Chipaca: thanks for the heads-up, looking now.
[11:07] <mvo> pedronis: also did some investigation about a higher errors.u.c failure rate with the 2.39.3 release for sil2100  but it looks mostly under control (one unknown)
[11:12] <zyga> Chipaca: aha
[11:12] <Chipaca> zyga: oho
[11:12] <Chipaca> zyga: a … gruffalo?
[11:13] <zyga> whaat? :)
[11:13] <zyga> mborzecki: pushed to https://github.com/snapcore/snapd/pull/7026
[11:14] <zyga> I think it's 100% what all the reviewers wanted now
[11:14] <Chipaca> zyga: "Aha! Oho! A trail on the snow! // Whose is this trail and where does it go?"
[11:14] <Chipaca> note you need to pronounce 'snow' to rhyme with 'oho!' or you failed
[11:14] <Chipaca> (also with 'go!' :) )
[11:15] <Chipaca> zyga: https://en.calameo.com/read/000612803e258cbf5d447
[11:19] <sil2100> mvo: phew, thanks for the investigation!
[11:22] <zyga> mvo: replied on that shell script question
[11:29] <Chipaca> man the snapd package in debian 9 is old and bad and nasty :-(
[11:29] <mvo> zyga: thx
[11:29] <Chipaca> doesn't debian have SRUs?
[11:30] <cjwatson> it's certainly possible to update packages in stable releases.  I have no idea whether it would be possible to convince the stable RMs to take a wholesale update here
[11:31] <cjwatson> like Ubuntu, somebody would have to make the case for it.  unlike Ubuntu, you wouldn't have management leverage to apply :P
[11:31] <zyga> cjwatson: FYI, flatpack updates go to backports regularly
[11:31] <zyga> I think we could consider the same path
[11:32] <cjwatson> no harm in trying though
[11:32] <zyga> though our dependency chain may be problematic
[11:33] <mvo> backports is pretty open in general for updates (iirc)
[11:34] <Chipaca> almost had a heart attack because debian's snapd doesn't include the fix for the ucrednet vuln
[11:34] <Chipaca> … then realised it's so old, it doesn't even have the vulnerability
[11:35] <cjwatson> for backports it generally just needs to be in testing
[11:35] <cjwatson> and obviously be buildable etc.
[11:41] <Chipaca> aw man, we have management leverage to apply? somebody should've told us
[11:42] <Chipaca> maybe we were missing management fulcrum
[11:42] <mvo> cachio: hey, good morning. snapd 2.39.3 snap is in beta now, please give it a go :)
[11:55] <mvo> Chipaca: did you see the comment in 7025? should be an easy win and then this one can go in
[11:59]  * Chipaca looks
[11:59] <Chipaca> mvo: that i should add a spread test?
[12:05]  * zyga is hungry, brb
[12:05] <mvo> Chipaca: yeah, we can do it in a followup as well
[12:05] <mvo> Chipaca: its actually so simple its probably quicker if I do it instead of writing it here :/ but oh well :)
[12:06] <Chipaca> mvo: doing it now
[12:06] <mvo> Chipaca: \o/
[12:06] <Chipaca> hoping to get feedback from sergio also
[12:06]  * Chipaca has poked
[12:25] <Chipaca> zyga: how's your things-i-need-to-review plate? #6695 has a half review and i was wondering if you'd be able to finish it or if i should do it
[12:26] <zyga> Chipaca: go for it!
[12:26] <zyga> I'm debugging mount propagation
[12:26] <zyga> and feeling hungry while the folks go for lunch
[12:28]  * Chipaca is having lunch
[12:30] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049 is green!
[12:30] <zyga> mvo: ^ this will allow to have bash snaps that don't ship /bin/sh anymore
[12:30] <zyga> base snaps, not bash snaps
[12:31] <zyga> mvo: consider it for 2.40 if you want to
[12:34]  * Chipaca implements type:bash snaps
[12:37] <ogra> Chipaca, nooo ... make it type:POSIX !!!
[12:37] <Chipaca> ogra: name:posix, type:msdos
[12:37] <ogra> lol
[12:37]  * zyga waits for amiga people to chime in
[12:38] <zyga> and for spread to spawn
[12:38] <Chipaca> ships two apps
[12:38] <Chipaca> vms
[12:38] <Chipaca> and pcm
[12:38] <Chipaca> as in pc/m, not as in /dev/pcm
[12:41] <Chipaca> pedronis: 'cp'?
[12:42] <Chipaca> > cp, ln use --target-directory in full
[12:42] <Chipaca> ah
[12:42] <Chipaca> d'oh
[12:42] <Chipaca> pedronis: until I pasted it here I thought that said In, not ln
[12:42] <pedronis> Chipaca: I'm asking whether cutting it down to just dir is good style or not
[12:42] <Chipaca> pedronis: probably not
[12:42] <pedronis> not sure myself
[12:42] <Chipaca> target-directory all over coreutils
[12:43] <pedronis> to be fair, they let you use just '-t'
[12:43] <pedronis> otoh this thing will probably be used mostly by scripts/snapcraft
[12:43] <Chipaca> yeap
[12:44] <pedronis> so not sure it needs to be short vs clean
[12:44] <Chipaca> bah
[12:44] <Chipaca> --basename, for sure
[12:44] <Chipaca> --target-dir[ectory] was just free :-)
[12:45] <Chipaca> (and neatly avoids the awkwardness of having something called 'basename' including a directory)
[12:46] <pedronis> Chipaca: otoh ubuntu-image has -w DIRECTORY, --workdir DIRECTORY
[12:46] <cachio> mvo, hey, just arrived
[12:46] <cachio> I'll start with it
[12:46] <pedronis> and -O DIRECTORY, --output-dir DIRECTORY
[12:47] <sergiusens> pedronis: Chipaca I would argue that the descriptive long option is better in scripts/code as much as using descriptive non one letter variable names :-)
[12:47] <Chipaca> --directory-dir=ectory
[12:47] <Chipaca> sergiusens: agreed
[12:48] <Chipaca> sergiusens: I don't think you're arguing against the thing :-)
[12:48] <Chipaca> --target-directory is happening
[12:48] <sergiusens> coming in late, I guess the discussion is about the best long-option to use?
[12:50] <Chipaca> sergiusens: yeah, target-dir vs target-directory mostly
[12:52] <sergiusens> Chipaca: if it helps, the positional argument you have for `pack` is `[<target-dir>]`, so if you are looking for consistency, there is your answer
[12:52] <Chipaca> dammit :-)
[12:52] <pedronis> Chipaca: our helps tend to do <*-dir>
[12:52]  * Chipaca defenestrates a rabbit
[12:53] <pedronis> those are not option names, they are placeholders really
[12:53] <pedronis> though
[12:55] <Chipaca> pedronis: I think --target-directory is the right call
[12:56] <Chipaca> pedronis: it does jump out in the options though, it's very long, but that might be ok
[12:56] <pedronis> Chipaca: we do have --ignore-validation
[12:56] <Chipaca> pedronis: <target-dir> is probably fine as a placeholder but I wouldn't mind if we went full ectory there as well
[12:57] <pedronis> as far as I can tell the only option that abbreviates (not counting --devmode which is called like that everywhere) is --abs-time
[12:57] <Chipaca> psh, the longest options are --unicode=[auto|never|always] :)
[12:58] <Chipaca> download doesn't have that one yet though
[12:58] <Chipaca> (but i expect to make --unicode and --color global at _some_ point)
[13:00]  * Chipaca stands up
[14:07] <Chipaca> pedronis: i'm about to merge the 'snap download' pr, shout if i should hold off
[15:03]  * cachio lunch
[15:41] <Chipaca> this chipaca will spontaneously EOD in T-19 minutes
[16:28] <ackk> is it ok to start services in a post-refresh hook?
[17:28] <zyga> re
[17:28]  * zyga resumes PRs
[18:02] <Chipaca> ackk: yes
[18:15] <ardaguclu> hello, what is the usage purpose of snapctl?. It is an executable and as I understand some other executable starts it. Am I right?, or I miss something.
[18:28] <ackk> Chipaca, great, thanks. it did seem to work fine, but wanted to be sure it's really intended to be used
[18:29] <ackk> ardaguclu, snapctl is used inside snap hooks to interact with the snap system (like, get configs, manage services, ...) for the snap itself
[18:32] <ardaguclu> thanks.


[00:01] <Eickmeyer> bdmurray: HA! I was just adding that bug to the release notes. Thanks! Didn't realize it was only a NCR otherwise I'd have done it.
[00:01] <bdmurray> ;-)
[00:46] -queuebot:#ubuntu-release- Unapproved: ironic (jammy-proposed/universe) [1:20.0.0+git2022030313.4e6a3d52e-0ubuntu1 => 1:20.1.0-0ubuntu1] (openstack)
[00:53] -queuebot:#ubuntu-release- Unapproved: ironic-inspector (jammy-proposed/universe) [1:10.10.0+git2022030313.3ebfdf0-0ubuntu1 => 1:10.11.0-0ubuntu1] (openstack)
[00:59] -queuebot:#ubuntu-release- Unapproved: horizon (jammy-proposed/main) [4:21.0.0+git2022030313.dd9e4c82b-0ubuntu2 => 4:22.1.0-0ubuntu1] (openstack)
[01:06] -queuebot:#ubuntu-release- Unapproved: magnum (jammy-proposed/universe) [13.0.0+git2022030313.4c4bba13-0ubuntu2 => 14.0.0-0ubuntu1] (openstack)
[01:07] -queuebot:#ubuntu-release- Unapproved: keystone (jammy-proposed/main) [2:20.0.0+git2022030313.a3fc9e7c3-0ubuntu1 => 2:21.0.0-0ubuntu1] (openstack)
[01:07] -queuebot:#ubuntu-release- Unapproved: masakari (jammy-proposed/main) [12.0.0+git2022030313.1a67234-0ubuntu1 => 13.0.0-0ubuntu1] (openstack)
[01:08] -queuebot:#ubuntu-release- Unapproved: manila (jammy-proposed/universe) [1:13.0.2+git2022030313.3ce3854ae-0ubuntu1 => 1:14.0.0-0ubuntu1] (openstack)
[01:22] -queuebot:#ubuntu-release- Unapproved: masakari-monitors (jammy-proposed/main) [12.0.0+git2022030313.a89511e-0ubuntu2 => 13.0.0-0ubuntu1] (openstack)
[01:23] -queuebot:#ubuntu-release- Unapproved: mistral (jammy-proposed/universe) [13.0.0+git2022030313.55bb2564-0ubuntu1 => 14.0.0-0ubuntu1] (openstack)
[01:26] -queuebot:#ubuntu-release- Unapproved: murano-agent (jammy-proposed/universe) [1:8.0.0+git2022011308.b873684-0ubuntu1 => 1:9.0.0-0ubuntu1] (openstack)
[01:31] -queuebot:#ubuntu-release- Unapproved: networking-bagpipe (jammy-proposed/universe) [15.0.0+git2021120816.8a8279a-0ubuntu1 => 16.0.0-0ubuntu1] (openstack)
[01:34] -queuebot:#ubuntu-release- Unapproved: networking-bgpvpn (jammy-proposed/universe) [15.0.0+git2022030313.1d09555-0ubuntu1 => 16.0.0-0ubuntu1] (openstack)
[01:34] -queuebot:#ubuntu-release- Unapproved: networking-hyperv (jammy-proposed/universe) [1:11.0.0+git2022011308.7619f8c-0ubuntu1 => 1:12.0.0-0ubuntu1] (openstack)
[01:35] -queuebot:#ubuntu-release- Unapproved: networking-odl (jammy-proposed/universe) [1:19.0.0+git2022030314.b57cfa8b4-0ubuntu1 => 1:20.0.0-0ubuntu1] (openstack)
[02:23] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy Beta] has been marked as ready
[02:45] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Jammy Beta] has been marked as ready
[03:04] -queuebot:#ubuntu-release- Unapproved: ukui-session-manager (jammy-proposed/universe) [3.0.5-1 => 3.0.5-1ubuntu1] (ubuntukylin)
[05:15] -queuebot:#ubuntu-release- Unapproved: wine-development (jammy-proposed/universe) [6.7~repack-1ubuntu1 => 6.17~repack-1] (i386-whitelist) (sync)
[05:16] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [sync] (jammy-proposed) [6.17~repack-1]
[05:20] <LocutusOfBorg> vorlon, hello, looks like jxrlib is needed by wine-development on i386
[07:02] <paride> bdmurray, the live-server beta images look good! I submitted some more results to the ISO tracker
[07:27] -queuebot:#ubuntu-release- Unapproved: cctbx (jammy-proposed/universe) [2021.12+ds1-4 => 2021.12+ds1-4ubuntu1] (no packageset)
[07:27] -queuebot:#ubuntu-release- Unapproved: accepted cctbx [source] (jammy-proposed) [2021.12+ds1-4ubuntu1]
[07:36] <handsome_feng> Hi, could anyone in release team approve ukui-session-manager 3.0.5-1ubuntu1 which fixed a critical bug?
[07:50] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Jammy Beta] has been marked as ready
[08:06] <cpaelzer> doko: sil2100: I think https://bugs.launchpad.net/ubuntu/+source/python-xmlschema/+bug/1953363/comments/14 would be ready to be promoted.
[08:06] <jamespage> bdmurray: hey - apologies for the changelog snafu on that ceph upload for focal - I've amended the changelog to reflect the reality of the contents of the package and re-uploaded
[08:07] <cpaelzer> doko: sil2100: I can't see a problem and would promote it, but I wanted to ask if e.g. the beta freeze adds some special handling I'm not yet aware of?
[08:07] <sil2100> cpaelzer: I think it should be safe to promote. I mean, we won't be respinning and we'll probably be lifting Beta freeze a bit later today anyway
[08:08] <cpaelzer> thanks sil2100, I'll handle it then
[08:10] <cpaelzer> And jamespage do not be concerned, nowdays snafu is just IT support https://www.snafu.de/ :-P
[08:10] <jamespage> lol
[08:12] -queuebot:#ubuntu-release- Unapproved: accepted ukui-session-manager [source] (jammy-proposed) [3.0.5-1ubuntu1]
[08:18] -queuebot:#ubuntu-release- Unapproved: mate-hud (jammy-proposed/universe) [22.04.1-0ubunt1 => 22.04.2-0ubuntu1] (ubuntu-mate)
[08:19] <Wimpy> sil2100: Morning. Please accept and unblock mate-hud 22.04.2-0ubuntu1
[08:54] <sil2100> Wimpy: will do o/
[08:54] <Wimpy> <3
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Canary) amd64 [Jammy Beta] (20220329.1) has been added
[08:59] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Jammy Beta] has been marked as ready
[09:06] -queuebot:#ubuntu-release- Unapproved: accepted mate-hud [source] (jammy-proposed) [22.04.2-0ubuntu1]
[09:22] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Jammy Beta] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (jammy-proposed/universe) [0.17.10 => 0.17.11] (personal-fossfreedom, ubuntu-budgie)
[10:03] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Canary) amd64 [Jammy Beta] has been updated (20220331)
[10:24] -queuebot:#ubuntu-release- New sync: gnome-shell-extension-manager (jammy-proposed/primary) [0.2.3-2]
[10:40] <sil2100> Hello hello, anyone feeling like giving the new canary beta images a spin? ^
[10:47] <Wimpy> sil2100: I can. Quickemu make is easy :-)
[11:34] <Wimpy> sil2100: Canary install tested. It "works". Resulting install boots and functions correctly. Tracker updated.
[11:36] -queuebot:#ubuntu-release- Unapproved: m2crypto (jammy-proposed/universe) [0.38.0-1ubuntu4 => 0.38.0-1ubuntu5] (no packageset)
[11:37] -queuebot:#ubuntu-release- Unapproved: accepted m2crypto [source] (jammy-proposed) [0.38.0-1ubuntu5]
[11:59] -queuebot:#ubuntu-release- Unapproved: networking-sfc (jammy-proposed/universe) [13.0.0+git2022030314.26274d2-0ubuntu1 => 14.0.0-0ubuntu1] (openstack)
[12:06] <seb128> Wimpy, thanks for helping with the desktop testing!
[12:09] <sil2100> WOohoo!
[12:11] -queuebot:#ubuntu-release- Unapproved: neutron-dynamic-routing (jammy-proposed/universe) [2:19.0.0+git2021120910.8a0ddf6-0ubuntu1 => 2:20.0.0-0ubuntu1] (openstack)
[12:14] -queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (jammy-proposed/main) [2:19.0.0+git2021120910.883f4f261-0ubuntu1 => 2:20.0.0-0ubuntu1] (openstack)
[12:17] -queuebot:#ubuntu-release- Unapproved: placement (jammy-proposed/main) [1:6.0.0+git2022030314.ff0f2dda-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack)
[12:19] -queuebot:#ubuntu-release- Unapproved: ovn-octavia-provider (jammy-proposed/main) [1.1.1+git2022030314.ec5b1d5-0ubuntu1 => 2.0.0-0ubuntu1] (openstack)
[12:20] -queuebot:#ubuntu-release- Unapproved: sahara-plugin-spark (jammy-proposed/universe) [6.0.0+git2021120910.4999d4c-0ubuntu1 => 7.0.0-0ubuntu1] (openstack)
[12:20] -queuebot:#ubuntu-release- Unapproved: sahara (jammy-proposed/universe) [2:15.0.0+git2022030314.f6a4a6e0-0ubuntu1 => 2:16.0.0-0ubuntu1] (openstack)
[12:20] -queuebot:#ubuntu-release- Unapproved: sahara-plugin-vanilla (jammy-proposed/universe) [6.0.0+git2021120910.03e4216-0ubuntu1 => 7.0.0-0ubuntu1] (openstack)
[12:23] -queuebot:#ubuntu-release- Unapproved: accepted gramps [source] (focal-backports) [5.1.5-1~bpo20.04.1]
[12:23] -queuebot:#ubuntu-release- Unapproved: accepted gramps [source] (impish-backports) [5.1.5-1~bpo21.10.1]
[12:30] -queuebot:#ubuntu-release- Unapproved: senlin (jammy-proposed/universe) [1:12.0.0+git2022030314.608e80b9-0ubuntu1 => 1:13.0.0-0ubuntu1] (openstack)
[12:35] -queuebot:#ubuntu-release- Unapproved: vitrage (jammy-proposed/universe) [7.5.0+git2022011309.43091cd4-0ubuntu2 => 8.0.1-0ubuntu1] (openstack)
[12:36] <LocutusOfBorg> seb128, jxrlib please on i386?
[12:37] -queuebot:#ubuntu-release- Unapproved: rclone (jammy-proposed/universe) [1.53.3-4 => 1.53.3-4ubuntu1] (no packageset)
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted rclone [source] (jammy-proposed) [1.53.3-4ubuntu1]
[12:38] -queuebot:#ubuntu-release- Unapproved: zaqar (jammy-proposed/universe) [13.0.0+git2022011310.1726ac41-0ubuntu1 => 14.0.0-0ubuntu1] (openstack)
[12:39] -queuebot:#ubuntu-release- Unapproved: swift (jammy-proposed/main) [2.29.0+git2022030314.3ff3076ce-0ubuntu2 => 2.29.1-0ubuntu1] (openstack)
[12:39] -queuebot:#ubuntu-release- Unapproved: watcher (jammy-proposed/universe) [2:7.0.0+git2022011310.01d74d0a-0ubuntu1 => 2:8.0.0-0ubuntu1] (openstack)
[12:40] -queuebot:#ubuntu-release- Unapproved: rclone (impish-proposed/universe) [1.53.3-1 => 1.53.3-1ubuntu0.1] (no packageset)
[12:42] -queuebot:#ubuntu-release- Unapproved: rclone (focal-proposed/universe) [1.50.2-2 => 1.50.2-2ubuntu0.1] (no packageset)
[12:44] -queuebot:#ubuntu-release- Unapproved: rclone (bionic-proposed/universe) [1.36-3 => 1.36-3ubuntu0.1] (no packageset)
[12:45] -queuebot:#ubuntu-release- Unapproved: zaqar-ui (jammy-proposed/universe) [11.0.0+git2021120913.bae3359-0ubuntu2 => 12.0.0-0ubuntu1] (openstack)
[12:46] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy Beta] has been marked as ready
[12:50] -queuebot:#ubuntu-release- Unapproved: watcher-dashboard (jammy-proposed/universe) [6.0.0+git2021120912.146e547-0ubuntu2 => 7.0.0-0ubuntu1] (openstack)
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (jammy-proposed) [1:14.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (jammy-proposed) [1:14.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (jammy-proposed) [1:18.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (jammy-proposed) [3:25.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (jammy-proposed) [2:14.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (jammy-proposed) [2:20.0.0-0ubuntu1]
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (jammy-proposed) [2:24.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (jammy-proposed) [4:22.1.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (jammy-proposed) [1:20.1.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (jammy-proposed) [14.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (jammy-proposed) [13.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (jammy-proposed) [14.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted networking-bagpipe [source] (jammy-proposed) [16.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (jammy-proposed) [1:12.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [source] (jammy-proposed) [1:10.11.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted manila [source] (jammy-proposed) [1:14.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted murano-agent [source] (jammy-proposed) [1:9.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted networking-odl [source] (jammy-proposed) [1:20.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (jammy-proposed) [2:21.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted networking-bgpvpn [source] (jammy-proposed) [16.0.0-0ubuntu1]
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (jammy-proposed) [13.0.0-0ubuntu1]
[13:10] -queuebot:#ubuntu-release- Unapproved: pymupdf (jammy-proposed/universe) [1.19.2+ds1-1build1 => 1.19.2+ds1-1ubuntu1] (no packageset)
[13:11] -queuebot:#ubuntu-release- Unapproved: accepted pymupdf [source] (jammy-proposed) [1.19.2+ds1-1ubuntu1]
[13:15] -queuebot:#ubuntu-release- Unapproved: python-pyaudio (jammy-proposed/universe) [0.2.11-1.3build3 => 0.2.11-1.3ubuntu1] (no packageset)
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted networking-sfc [source] (jammy-proposed) [14.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (jammy-proposed) [2:20.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted placement [source] (jammy-proposed) [1:7.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted sahara-plugin-spark [source] (jammy-proposed) [7.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (jammy-proposed) [2:16.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted swift [source] (jammy-proposed) [2.29.1-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted watcher-dashboard [source] (jammy-proposed) [7.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted zaqar-ui [source] (jammy-proposed) [12.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [source] (jammy-proposed) [2:20.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted python-pyaudio [source] (jammy-proposed) [0.2.11-1.3ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (jammy-proposed) [1:13.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted watcher [source] (jammy-proposed) [2:8.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted ovn-octavia-provider [source] (jammy-proposed) [2.0.0-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted vitrage [source] (jammy-proposed) [8.0.1-0ubuntu1]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted sahara-plugin-vanilla [source] (jammy-proposed) [7.0.0-0ubuntu1]
[13:17] -queuebot:#ubuntu-release- Unapproved: accepted zaqar [source] (jammy-proposed) [14.0.0-0ubuntu1]
[13:33] <sil2100> paride: hello hello! How're the subiquity images looking from your POV for Beta?
[13:44] -queuebot:#ubuntu-release- Unapproved: murano-dashboard (jammy-proposed/universe) [1:12.0.0+git2022030313.ad3ddf6c-0ubuntu1 => 1:13.0.0-0ubuntu1] (openstack)
[13:44] -queuebot:#ubuntu-release- Unapproved: sahara-dashboard (jammy-proposed/universe) [15.0.0+git2022011309.da7235b-0ubuntu2 => 16.0.0-0ubuntu1] (openstack)
[13:45] -queuebot:#ubuntu-release- Unapproved: octavia-dashboard (jammy-proposed/main) [8.0.0+git2022030314.d8b97e6-0ubuntu1 => 9.0.0-0ubuntu1] (openstack)
[13:47] <sil2100> waveform: hey hey! Were you able to test the serial console on our 22.04 beta raspi images?
[13:51] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (jammy-proposed/universe) [13.0.0+git2022011215.cddfd05-0ubuntu1 => 14.0.0-0ubuntu1] (openstack)
[13:53] -queuebot:#ubuntu-release- Unapproved: llvm-defaults (jammy-proposed/universe) [0.54ubuntu1 => 0.55~exp1] (i386-whitelist) (sync)
[13:53] -queuebot:#ubuntu-release- Unapproved: accepted llvm-defaults [sync] (jammy-proposed) [0.55~exp1]
[13:53] -queuebot:#ubuntu-release- Unapproved: ironic-ui (jammy-proposed/universe) [5.0.0+git2022011217.07e5607-0ubuntu2 => 5.1.0-0ubuntu1] (openstack)
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (jammy-proposed) [14.0.0-0ubuntu1]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (jammy-proposed) [1:13.0.0-0ubuntu1]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (jammy-proposed) [16.0.0-0ubuntu1]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted ironic-ui [source] (jammy-proposed) [5.1.0-0ubuntu1]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted octavia-dashboard [source] (jammy-proposed) [9.0.0-0ubuntu1]
[14:06] -queuebot:#ubuntu-release- Unapproved: python-oslo.context (jammy-proposed/main) [1:3.4.0-0ubuntu1 => 1:4.1.0-0ubuntu1] (openstack)
[14:10] -queuebot:#ubuntu-release- Unapproved: heat-dashboard (jammy-proposed/main) [6.0.0+git2022030311.7729b75-0ubuntu1 => 7.0.0-0ubuntu1] (openstack)
[14:10] -queuebot:#ubuntu-release- Unapproved: manila-ui (jammy-proposed/universe) [1:6.0.0+git2022030313.97ca7f0-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack)
[14:11] -queuebot:#ubuntu-release- Unapproved: magnum-ui (jammy-proposed/universe) [9.0.0+git2021120911.fede1be-0ubuntu2 => 10.0.0-0ubuntu1] (openstack)
[14:26] -queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.22 => 2.20.11-0ubuntu27.23] (core, i386-whitelist)
[14:30] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.23]
[14:32] <sil2100> ...ok, I'm marking preinstalled images as green
[14:32] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Jammy Beta] has been marked as ready
[14:32] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Jammy Beta] has been marked as ready
[14:32] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Jammy Beta] has been marked as ready
[14:34] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.23]
[14:35] <waveform> sil2100, sorry -- didn't have a chance to get to the serial test yet -- will try this afternoon but I did check the config/kernel-cmdline do include everything necessary for the serial console
[14:38] <sil2100> Ok, thanks! I'll prep the release now
[14:38] <sil2100> o/
[14:39] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Jammy Beta] has been marked as ready
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Jammy Beta] has been marked as ready
[14:42] -queuebot:#ubuntu-release- Unapproved: jxrlib (jammy-release/universe) [1.2~git20170615.f752187-5 => 1.2~git20170615.f752187-5] (i386-whitelist, kubuntu) (sync)
[14:44] -queuebot:#ubuntu-release- Unapproved: jxrlib (jammy-release/universe) [1.2~git20170615.f752187-5 => 1.2~git20170615.f752187-5] (i386-whitelist, kubuntu) (sync)
[14:58] -queuebot:#ubuntu-release- Unapproved: octavia (jammy-proposed/universe) [1:9.0.1+git2022030314.328ffbab-0ubuntu1 => 1:10.0.0-0ubuntu1] (openstack)
[14:59] -queuebot:#ubuntu-release- Unapproved: openstack-trove (jammy-proposed/universe) [2:16.0.0+git2022030314.39322f5a-0ubuntu1 => 2:17.0.0-0ubuntu1] (openstack)
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted heat-dashboard [source] (jammy-proposed) [7.0.0-0ubuntu1]
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (jammy-proposed) [1:7.0.0-0ubuntu1]
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (jammy-proposed) [2:17.0.0-0ubuntu1]
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted magnum-ui [source] (jammy-proposed) [10.0.0-0ubuntu1]
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted python-oslo.context [source] (jammy-proposed) [1:4.1.0-0ubuntu1]
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (jammy-proposed) [1:10.0.0-0ubuntu1]
[15:16] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (jammy-proposed/universe) [22.04.24 => 22.04.25] (ubuntustudio)
[15:18] -queuebot:#ubuntu-release- Unapproved: studio-controls (jammy-proposed/universe) [2.3.0-0ubuntu1 => 2.3.1-0ubuntu1] (ubuntustudio)
[15:46] -queuebot:#ubuntu-release- Unapproved: heat-dashboard (jammy-proposed/main) [7.0.0-0ubuntu1 => 7.0.0-0ubuntu2] (openstack)
[15:52] -queuebot:#ubuntu-release- Unapproved: magnum-ui (jammy-proposed/universe) [10.0.0-0ubuntu1 => 10.0.0-0ubuntu2] (openstack)
[16:12] <juliank> arm64 testing capacity is at 50%, ticket with IS raised
[16:27] <LocutusOfBorg> juliank, also some builds failed with "unknown"
[16:27] <LocutusOfBorg> is it possible to retry them?
[16:27] <juliank> LocutusOfBorg: you mean tests?
[16:28] <LocutusOfBorg> yep
[16:28] <juliank> We shouldn't do blanket retries atm
[16:28] <LocutusOfBorg> only 27 now
[16:30] <juliank> do it
[16:30] <juliank> tell me what to do
[16:30] <juliank> whatever
[16:30] <juliank> I noticed one of them was my fault
[16:30] <LocutusOfBorg> done
[16:31] <juliank> jawn-smith: bdmurray so any test with "http://us.ports.ubuntu.com/ubuntu-ports/dists/jammy-proposed/InRelease  403  Forbidden [IP: <IP_ADDRESS> 3128]" is a result from me running mojo run which overrode the worker-bos01-*.conf config changes I made to enable ports
[16:31] <juliank> those can be retried
[16:31] <juliank> some of them / all of them might be retried by LocutusOfBorg above already, I can't say
[16:32] <LocutusOfBorg> only the 27 shown with "/unknown" version in updates_excuses
[16:32] <juliank> yes
[16:32] <juliank> LocutusOfBorg: I checked one of them and that was the reason
[16:32] <juliank> LocutusOfBorg: I don't know if there are others, basically
[16:32] <bdmurray> Well but if we use retry-autopkgtest-regressions it'll know if they are already queued.
[16:32] <juliank> yes when it works
[16:33]  * bdmurray doesn't need any more doubt
[16:33] <juliank> queue content reporting isn't always correct
[16:33] <juliank> sometimes you might get empty queues or partial queue contents only
[16:33] <juliank> when queues are this long
[16:34] <bdmurray> sadness
[16:34] <juliank> we should write our own message queue and use that instead of rabbitmq
[16:34] <juliank> rewrite autopkgtest cloud as a set of Erlang processes
[16:35] <juliank> rabbitmq is the wrong message queue for our use case basically
[16:35] <juliank> maybe for any use case :D
[16:37] <juliank> bdmurray: maybe run ps aux | grep -Ff <(find /tmp/autopkgtest-work.*/out/log -mmin +60 | sed s#/out/log##)  | tee /dev/stderr | awk '{print $2}' | xargs kill a couple of times over your working day on autopkgtest-lxd-worker/0 to cleanup stuck armhf jobs earlier
[16:37] <juliank> this removes everything not outputting for 60mins which I think is reasonable at the current time
[16:38] <juliank> bdmurray: I feel like we should work on jammy-based autopkgtest-cloud now before we migrate to PS5 in May such that we then end up with an up-to-date cloud directly
[16:39] <juliank> that's what we did with the last re-setup when it went directly to 20.04 in 2020
[16:41] <juliank> we don't want to redeploy twice, and rabbitmq in 22.04 might be nicer
[16:41] <bdmurray> When did you last cleanup stuck armhf jobs?
[16:41] <juliank> like 10 mins ago
[16:41]  * bdmurray sets a timer
[16:44] <juliank> world is set
[16:44] <juliank> ugh
[16:44] <juliank> world is sad
[17:10] <sil2100> Beta should be released o/
[17:10] <sil2100> Checking torrents
[17:17] <RikMills> sil2100: \o/
[17:18] <RikMills> and thank you
[17:20] <juliank> phew
[17:20] <juliank> sil2100: sorry for disturbing earlier with SRU stuff, I thought the betas already were finished
[17:20] <sil2100> juliank: haha, no worries, I'll get to that in a bit!
[17:21] <juliank> I mixed it up with the beta call for testing :D
[17:30] -queuebot:#ubuntu-release- Unapproved: trove-dashboard (jammy-proposed/universe) [17.0.0+git2021120912.1602afb-0ubuntu2 => 18.0.0-0ubuntu1] (openstack)
[17:40] -queuebot:#ubuntu-release- Unapproved: aisleriot (jammy-proposed/main) [1:3.22.21-1 => 1:3.22.22-1] (ubuntu-desktop) (sync)
[17:40] -queuebot:#ubuntu-release- Unapproved: gucharmap (jammy-proposed/universe) [1:14.0.2-1 => 1:14.0.3-1] (ubuntu-desktop) (sync)
[17:41] -queuebot:#ubuntu-release- Unapproved: five-or-more (jammy-proposed/universe) [1:3.32.2-2 => 1:3.32.3-1] (desktop-extra) (sync)
[17:41] -queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (jammy-proposed/main) [1.14.1-2 => 1.14.2-1] (desktop-core) (sync)
[17:49] -queuebot:#ubuntu-release- Unapproved: scipy (jammy-proposed/universe) [1.8.0-1exp2build1 => 1.8.0-1exp2ubuntu1] (kubuntu)
[17:50] -queuebot:#ubuntu-release- Unapproved: neutron-fwaas (jammy-proposed/universe) [1:16.0.0+git2022030710.a9f26b81e-0ubuntu1 => 1:16.0.0+git2022033113.de8a4d4cf-0ubuntu1] (openstack)
[17:53] -queuebot:#ubuntu-release- Unapproved: networking-baremetal (jammy-proposed/universe) [5.1.0+git2022030210.33aa103-0ubuntu1 => 5.1.0+git2022033113.f30f96c-0ubuntu1] (openstack)
[17:53] <RikMills> I guess the britney beta block is to be dropped soon?
[17:57] -queuebot:#ubuntu-release- Unapproved: gnocchi (jammy-proposed/universe) [4.4.1+git2022031411.81026625-0ubuntu1 => 4.4.1+git2022033113.2339b9e9-0ubuntu1] (openstack)
[18:08] -queuebot:#ubuntu-release- Unapproved: ceilometer (jammy-proposed/main) [2:17.0.1+git2022030310.bac34383-0ubuntu1 => 2:18.0.0-0ubuntu1] (openstack)
[18:08] -queuebot:#ubuntu-release- Unapproved: murano (jammy-proposed/universe) [1:12.0.0+git2022030313.f0258fc8-0ubuntu1 => 1:13.0.0-0ubuntu1] (openstack)
[18:11] -queuebot:#ubuntu-release- Unapproved: cinder (jammy-proposed/main) [2:19.0.0+git2022030310.b49fb59a6-0ubuntu2 => 2:20.0.0-0ubuntu1] (openstack)
[19:59] -queuebot:#ubuntu-release- Unapproved: calamares (jammy-proposed/universe) [<IP_ADDRESS>-0ubuntu3 => <IP_ADDRESS>-0ubuntu4] (lubuntu, ubuntustudio)
[21:14] -queuebot:#ubuntu-release- Unapproved: exim4 (jammy-proposed/main) [4.95-4ubuntu1 => 4.95-4ubuntu2] (ubuntu-server)
[21:37] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (jammy-proposed/main) [1:22.04.7 => 1:22.04.8] (core)
[22:10] -queuebot:#ubuntu-release- Unapproved: rejected jxrlib [sync] (jammy-release) [1.2~git20170615.f752187-5]
[23:12] -queuebot:#ubuntu-release- Unapproved: gnome-bluetooth3 (jammy-proposed/universe) [42.0-1 => 42.0-3] (no packageset) (sync)
[23:13] -queuebot:#ubuntu-release- Unapproved: accepted gnome-bluetooth3 [sync] (jammy-proposed) [42.0-3]
[23:14] -queuebot:#ubuntu-release- Unapproved: gnome-sushi (jammy-proposed/universe) [41.0-3 => 41.0-4] (desktop-extra) (sync)


[16:54] <kklimonda> hey, what's the status of 0.10? It were mentioned on the last uds but since then there were no new info about it.
[16:56] <Stevee> oh, new information about the next rel. would be great
[16:58] <ion> Keybuk said it won’t be ready in time for Ubuntu 10.10. He’s still working on it.
[17:01] <kklimonda> ion: Is He doing it behind closed doors? there are no commits in lp:upstart
[17:02] <ion> Alas, yeah.
[17:05] <ashb> fail. is this opensoruce or what?
[17:09] <marcc> what's the strategy if I want to log the output of a job?
[17:11] <Stevee> i don't know, but i also think, that a more transparend development process would be good


[04:32] <kilonux> hello any specialists for newbies around?
[05:08] <ewanm89_laptop> kilonux: We are all, as we all were all newbies at one time.
[05:09] <kilonux> ahh nice to hear!
[05:14] <kilonux_> ewanm89_laptop: this is not a support #,  but my feisty is freezin anyway, and the new laptop works beatifully under windows
[05:22] <ewanm89_laptop> kilonux: Any pattern to this freezing?
[11:20] <kilonux> ikke le, for noe gjr faktisk det
[11:21] <kilonux> men jeg blir stadig kobla ut  og automisk inn igjen
[11:27] <simira> og s havnet du p feil kanal? ;)


[05:17] <student> hello to who do i need to speak  to get my ubuntu cloak?
[05:18] <m4v> !member
[05:18] <student> m4v, i am =)
[05:18] <student> i just want to get my cloak
[05:18] <student> they told me that i need to come here
[05:19] <nhandler> student: Do you have a link to your LP profile?
[05:19] <student> Lp?
[05:20] <nhandler> student: LP=Launchpad (http://launchpad.net)
[05:20] <student> https://launchpad.net/~harddark
[05:21] <nhandler> student: It does not appear that you are a part of the ~ubuntumembers team, which is used to keep track of Ubuntu Members
[05:26] <m4v> i don't understand him, he already applied once to be a member in the ubuntu council, he should know the process by now...
[14:00] <erUSUL> niko: ping
[14:00] <niko> yes
[14:00] <erUSUL> niko: ubotu-fr deleted all bans in #ubuntu-es
[14:00] <m4v> nonononon
[14:00] <m4v> it wasn't ubot2
[14:00] <niko> o_o ?
[14:00] <m4v> uBOTu-fr*
[14:00] <m4v> it was timido
[14:01] <erUSUL> sorry not ubotu someone named student
[14:01] <niko> :)
[14:01] <m4v> student (n=deb@irssi/user/TiMiDo) has left #ubuntu-irc ("Leaving")
[14:02] <m4v> I don't understand that guy (i'm saying it again) but he either don't know how to use chanserv or likes to mess things up
[14:02] <m4v> doesn+t*
[14:03] <m4v> gah
[14:03] <niko> or perhaps, he should ask before do something, until he wasn't aware of bans reason
[14:07] <m4v> yes, he should have asked, well, the ban list needed a cleanup anyway...
[22:06] <erUSUL> he spammed my channel and users within spmmed #ubuntu he is insulting me. what else needs to do to get a ban?
[22:07] <erUSUL> ikonia: ^^
[22:07] <ikonia> he's gone
[22:07] <erUSUL> ty
[22:07] <ikonia> I wasn't aware of the first part and couldn't read the spanish
[22:08] <erUSUL> no problem; thanks for dealing with it
[22:08] <m4v> erUSUL: what happened?
[22:09] <niko> erUSUL: the bot do the job ?
[22:09] <niko> or he bypass it
[22:09] <erUSUL> m4v: he continued in #ubuntu and in private his crusade against me ;P
[22:09] <m4v> niko: uses /query
[22:09] <erUSUL> niko: it was private spam
[22:09] <niko> ah ok
[22:09] <niko> like one week ago
[22:09] <niko> one or two
[22:10] <m4v> erUSUL: ah, I don't follow #ubuntu as closely as u-es :p
[22:10] <erUSUL> m4v: well he was highlighting me... hard to not notice
[22:11] <ikonia> he's insulting me randomly now
[22:11] <erUSUL> wellcome to my world
[22:11] <niko> ikonia: welcome
[22:12] <m4v> yeah, jebus is hard to deal, he'll insult you for anything
[22:13] <m4v> that sad part is that he was right, he just can't said it with proper manners
[22:13] <m4v>  s/that/the/
[22:14] <ikonia> not hard at all
[22:14] <ikonia> he's banned, problem solved
[22:15] <m4v> ah yes, but I can't do the same in u-es :P
[22:15] <ikonia> erUSUL: can/has
[22:15] <m4v> I'm only op in ku-es
[22:15] <niko> ( in pm with jebus )
[22:16] <ikonia> don't feed him
[22:16] <niko> i spot him to -ops and -es-ops
[22:21] <m4v> niko: really don't lose much time with hum, he deserved the ban.


[19:36] <alkisg> stgraber: hi, about dnsmasq again... so, is it correct if I say that the dnsmasq package is broken on Ubuntu, since when one installs it, it doesn't work if he doesn't go and manually change the network-manager configuration?
[19:36] <alkisg> Maybe that change should go to dnsmasq.postinst then?
[19:38] <alkisg> Or, maybe network-manager should check if dnsmasq or bind9 are installed, and not do the local resolver thing if they are?
[20:16] <stgraber> yeah, network manager checking would make more sense, we mentioned it a few times for people using bind


[14:17] <neops> salut la communauté
[14:18] <neops> je n'arrive pas a installer centos sur un hdd externe
[14:18] <neops> - test avec lili linux = ecran noir
[19:24] <akernedo> hi people, sorry to distrub you, i have a general question and I'm not sure where to post it, it's not that important but I can remain with my question for the rest of my life^^
[19:25] <akernedo> but there need to be somebody here before asking anything xD
[19:29] <Noskcaj> !ask
[19:37] <akernedo> sorry, so my question : why is there no graphical consistency between the different flavours of Ubuntu, especially between Gnome and Unity's version, which are the closest (using Gnome technologies and GTK)?
[19:39] <jbooms> apples n oranges are meant to be apples n oranges
[19:42] <akernedo> yes but what is the relation with my question?
[19:45] <Noskcaj> akernedo, differet flavours want differet themes
[19:45] <Noskcaj> and different desktop environments
[19:47] <akernedo> yes, I guet that, I'm not saying they must be exactly the same, but, for instance, it would be possible to keep gnome desktop with ambiance theme, I think. Just to keep in mind that's still Ubuntu. It' just curiosity, not a troll!
[19:47] <akernedo> get*
[19:54] <Noskcaj> akernedo, yeah, you could do that. I'm not sure how well the theme works though
[19:55] <akernedo> ok so for my question : if all the ubuntu flavours do not adopt the same theme, it's because they want to show their differences first, not what they have in common, finally?
[19:56] <Noskcaj> yes
[22:28] <darkxst> roasted, you had printer issues right? https://bugs.launchpad.net/ubuntu-gnome/+bug/1242658/comments/9
[23:26] <roasted> darkxst: once upon a time I did, yes
[23:27] <darkxst> is it working now?
[23:27] <roasted> I do not have an ubuntu gnome install at the moment but I'd be happy to spin up a VM
[23:27] <roasted> last I tried it wasn't, but that was early in the 13.10 release


[08:20] <Gargoyle> hi
[22:53] <MikeRL> Hmm. Is thia channel still used? Not nearly as active as it once was some time back.
[23:18] <MikeRL> What happened to all the packages on the security ppa? They're all except one marked as superseded or deleted.


[00:00] <bac> hi rick_h_.  otp, but what's up?
[00:01] <rick_h_> fyi, I talked to arosales about quickstart and it's not going anywhere for this cycle
[00:01] <bac> six month cycle?
[00:01] <rick_h_> bac: we'll work on introducing it to the guys on eco some, arosales would like to setup a meet sometime to run them through the basics
[00:01] <rick_h_> bac: but we won't hand anything off until Oct
[00:01] <rick_h_> bac: rgr
[00:01] <bac> rt
[00:01] <rick_h_> 14.10 cycle kind of thing
[00:02] <rick_h_> so we want to get the idea on the table, but not actually move for now. So just a heads up that we can continue our current plans as they are
[00:24] <arosales> rick_h_, bac, I am going to talk to a few guys on my team to check interest in transitioning. I'll get back to you guys once I have done so, and perhaps we an do some knowledge transfer
[00:26] <arosales> bac, rick_h_ apologies we won't be able to dedicate time to dev on it this cycle. Perhaps some items will move faster than we think (I guess that happens sometimes right :-)
[06:14] <kadams54> huwshimi: you around?
[06:15] <huwshimi> kadams54: Hey!
[06:16] <kadams54> I ran into a potential bug earlier today and Jeff said you might be working on a fix…
[06:17] <kadams54> Here's how to reproduce on comingsoon.jujucharms.com:
[06:18] <kadams54>  1) Deploy the Mediawiki bundle, then drag-n-drop a second mysql charm. It also gets the name "mysql" which means it will fail when you try to deploy it.
[06:18] <kadams54> But if you try to rename it, there isn't a button anymore to save the changes to the ghosted charm's config.
[06:19] <kadams54> If there's a fix in progress for that, great. If not, I'll create a bug report.
[06:19] <huwshimi> kadams54: Oh yeah, I'm not working on a fix, but we discussed in a call this morning and Rick said that the inspector needs be updated to auto-save those config changes.
[06:20] <huwshimi> kadams54: There are some broader changes on the ghost inspector, maybe it'll be done as part of that.
[06:20] <kadams54> Ah, excellent.
[06:20] <huwshimi> kadams54: I guess a bug report at this stage would be prudent.
[06:20] <kadams54> Yeah, will do.
[06:20] <kadams54> Don't want to lose visibility
[06:21] <huwshimi> kadams54: Just so we don't release mv without fixing it.
[06:21] <huwshimi> yeah
[06:21] <huwshimi> Thanks
[06:21] <huwshimi> kadams54: But yes, that is my fault :)
[06:22] <kadams54> Meh, we all knew the button in the inspector was going away.
[06:26] <kadams54> Alright, with that, I'm off to bed :-)
[06:27] <kadams54> Have a good rest of the day!
[07:17] <rogpeppe> mornin' all
[07:21] <huwshimi> Morning
[08:21] <frankban> morning rogpeppe: I'll start migrating filetesting to github.com/juju/testing/filetesting
[08:21] <rogpeppe> frankban: cool.
[08:21] <rogpeppe> frankban: i could work concurrently on other related stuff if you feel it would speed things up
[08:25] <frankban> rogpeppe: sure, I guess the next thing is handling juju/osenv, e.g. decoupling utils from juju/osenv
[08:26] <frankban> rogpeppe: the goal is to have a github.com/juju/utils project
[08:26] <rogpeppe> frankban: a lot of osenv looks quite core-specific
[08:27] <rogpeppe> frankban: the only thing that isn't is the proxy stuff, i think
[08:29] <frankban> rogpeppe: ok, so I guess it makes sense to have utils/zip and utils/set outside juju-core
[08:31] <frankban> rogpeppe: charm depends on both, and also on utils itself, but AFAICT only for stuff like ReadSHA256, ReadFileSHA256 and ReplaceFile. Perhaps a good path is to move juju-core unrelated stuff to github and change charm to only depend on the github project
[08:31] <rogpeppe> frankban: i think there are (at least) two splits that should happen
[08:32] <rogpeppe> frankban: utils/osenv should split out the juju home stuff
[08:32] <rogpeppe> frankban: (or perhaps split out the proxy stuff)
[08:33] <rogpeppe> frankban: and utils itself should be split into coherent packages containing related functionality, rather than being a grab-bag of stuff
[08:34] <rogpeppe> frankban: i'll try and come up with a coherent scheme for that
[08:35] <frankban> rogpeppe: great, thanks
[08:55] <frankban> rogpeppe: uhm, it seems juju is not using the latest revision of github.com/juju/testing. this is the missing change: https://github.com/juju/testing/commit/83bf0cdc931b7556c93e8d496978b3f010d50ab5 . Do you think it's safe to include that?
[08:56] <rogpeppe> frankban: yeah, i do
[08:56] <frankban> cool
[08:57] <rogpeppe> frankban: i'd propose a CL with a single change to the dependencies.tsv file to update that
[08:57] <frankban> rogpeppe: yeah, that's what I was thinking
[08:58] <frankban> rogpeppe: ah, feel free to create a kanban card in Project A for what you are working on
[09:36] <frankban> rogpeppe: I need a review for https://codereview.appspot.com/100740044 (trivial)
[09:37] <rogpeppe> frankban: LGTM
[09:37] <frankban> thanks
[09:54] <frankban> rogpeppe: have you ever seen this? fatal: reference is not a tree: a99ca0f5b8d5b7ad608fd7214e8ba3d7b6279f63.
[09:54] <rogpeppe> frankban: i think i might have - was that printed by git?
[09:55] <frankban> I think so, godeps in tarmac reports this error from git I guess
[09:55] <frankban> rogpeppe: do we need to pull from github/juju/testing in tarmac?
[09:56] <rogpeppe> frankban: i *thought* it pulled automatically
[09:58] <rogpeppe> frankban: am asking in juju-core - someone might know
[09:58] <frankban> thanks
[10:06] <frankban> rogpeppe: unrelated: in the process of updating testing, I'd like to go get my fork in a separate GOPATH, and run the tests/verify dependencies. Is it possible to go get a github named branch? I guess no. So maybe this can be done with 1) export GOPATH=... 2) go get github.com/frankban/testing 3) checkout the branch with the updates and 4) go get -u ./...
[10:06] <frankban> correct>
[10:06] <frankban> ?
[10:46] <frankban> rogpeppe: at this point I'd be inclined not to start the filetesting migration, and tackle that on Monday. I can start working on breaking utils/set, what do you think?
[10:47] <rogpeppe> frankban: seems ok to me. i'm currently factoring out apt from utils.
[10:48] <frankban> rogpeppe: so juju-core/utils/set -> juju-core/set, how does it sound?
[10:48] <rogpeppe> frankban: that seems a bit odd to me
[10:48] <rogpeppe> frankban: why move it?
[10:49] <rogpeppe> frankban: i thought it should probably go to github.com/utils/set
[10:49] <rogpeppe> frankban: oops
[10:49] <rogpeppe> frankban: i mean github.com/juju/utils/set
[10:51] <frankban> rogpeppe: IC, right, so 1) we move the juju-core related stuff from utils to their own packages and 2) we migrate utils to github, correct?
[10:51] <rogpeppe> frankban: yeah
[10:51] <rogpeppe> frankban: i don't think we have to migrate all of utils to github - i think juju-core can probably still keep its own utils dir
[10:53] <frankban> rogpeppe: yeah that's reasonable
[11:06] <frankban> rogpeppe: so, after you split apt, the remaining osenv stuff in utils is file (osenv.Home, osenv.SetHome). Those functions in osenv/vars_* seem to be generic. We can either 1) move vars_* into utils (or perhaps utils/os), or 2) break the file stuff in into a separate pkg
[11:06] <rogpeppe> pwd
[11:10] <rogpeppe> frankban: i think all the proxy-related stuff should move out of osenv and into utils/proxy (httpproxy?)
[11:10] <rogpeppe> frankban: i think osenv.Home() should move out of osenv too
[11:10] <rogpeppe> frankban: and SetHome too
[11:10] <rogpeppe> frankban: which would leave osenv with just juju-related stuff
[11:12] <frankban> rogpeppe: yeah, ok so I'll start with osenv home stuff. What do you thing about osenv.(Set)Home --> utils/os.(Set)Home?
[11:13] <rogpeppe> frankban: tbh they're trivial enough that perhaps they could go into utils itself
[11:13] <rogpeppe> frankban: utils already depends on os and has os-specific files
[11:15] <frankban> rogpeppe: ok so just osenv.(Set)Home --> utils.(Set)Home, correct? and later osenv.Proxy* -> utils/proxy.Proxy*, correct?
[11:15] <rogpeppe> frankban: sgtm
[11:16] <frankban> rogpeppe: cool, thanks, I'll start with the first one
[11:20] <rick_h_> morning all
[11:27] <rick_h_> morning rogpeppe can you add a card to the board for the apt refactoring you mentioned please? We've got a card in the ready to code lane for "migrate juju utils package" but sounds like we're doing parts of that so maybe just a new card?
[11:28] <rogpeppe> rick_h_: will do. that occurred to me earlier but didn't make it as far as motor action :-)
[11:28] <rick_h_> rogpeppe: hah, TGIF
[11:30] <rick_h_> redir: when you get settled this morning can we catch up on where we're at for the demo prep stuff?
[11:54] <frankban> rogpeppe: moving Home to "utils" causes an import loop, it seems I am blocked on your apt change, unless I use a submodule e.g. utils/env
[11:55] <rogpeppe> frankban: i've proposed my apt change: https://codereview.appspot.com/100730044
[11:58] <frankban> rogpeppe: cool I'll take a look after lunch
[11:58] <rogpeppe> frankban: it's just been LGTM'd
[11:58] <frankban> rogpeppe: even better
[11:58] <rogpeppe> frankban: i'm about to approve it - it should hopefully have landed by the time you've finished lunch
[11:59] <frankban> rogpeppe: sounds good
[11:59]  * frankban lunches
[12:20] <rogpeppe> frankban: it's now merged
[12:32] <bac> thanks for the review frankban.  good suggestions.
[12:34] <bac> frankban: as an aside, i notice the quickstart tests have a failure if JUJU_HOME is set.
[12:41] <frankban> bac: yw
[12:41] <frankban> bac: confirmed, the expected error in test_no_admin_secret_found should use settings.JUJU_HOME
[12:42] <bac> frankban: ah, that's a simple way to fix it.  you want me to roll it into my branch?
[12:42] <frankban> bac: yes please
[12:42] <frankban> thanks
[12:42] <bac> gladly
[12:43] <bac> really freaked me out last night when lbox failed b/c i'd inadvertantly run it in another terminal...
[12:54]  * rogpeppe goes for lunch
[13:01] <redir> rick_h_: sure
[13:01] <redir> settled
[13:01] <rick_h_> redir: cool, how goes? It looked like you had mongodb conflict between the state server and mongodb for charmworld yesterday?
[13:01] <redir> and rick_h_ I don't know that it is a conflict
[13:02] <rick_h_> ok, but we suspect?
[13:02] <redir> I can't start it with service but can by calling the command from the service config as the correct user
[13:02] <redir> so I don't know what is preventing it.
[13:02] <rick_h_> redir: I was going to suggest can we test it out on two machine then? put the gui on the bootstrap node, but all of charmworld on a second
[13:02] <rick_h_> redir: to clarify if the dual mongos is the issue?
[13:03] <redir> so quickstart and then deploy CW to a separate instance?
[13:03] <redir> this makes using AMIs more difficult
[13:03] <redir> but not impossible
[13:03] <redir> and I would like to know why it isn't starting
[13:04] <redir> bac did you have a chance to look?
[13:04] <bac> redir: i did not
[13:04] <rick_h_> redir: well, let's get the process and the ami thing might not work out
[13:05] <bac> frankban: i did a 'make clean' in quickstart and now unrelated websocket tests fail, even in trunk.  have you seen that before?
[13:05] <bac> redir: i'm about to wrap up this task and then can help
[13:06] <frankban> bac: no, trying
[13:06] <bac> frankban: http://paste.ubuntu.com/7505527/
[13:06] <frankban> bac: confirmed and weird
[13:07] <bac> frankban: so some package shifted beneath us?
[13:08] <frankban> bac: we specify the version for each requirement, looking at the test
[13:10] <frankban> bac: but not for the websocket client, which is a dependency of python-jujuclient
[13:13] <bac> frankban: websocket's connect is never called in that test.  self.sock remains None.
[13:14] <frankban> bac: jujuclient 0.17.5 has install_requires=["websocket-client"], without the version :-/
[13:15] <frankban> bac: and a new version of the websocket client has been released recently
[13:15] <bac> ah
[13:15] <frankban> bac: newer versions of jujuclient fix it, but we must depend on  0.17.5 which is the trusty release
[13:16] <bac> uh-oh
[13:16] <bac> frankban: they 'fix it' by specifying the websocket version or a code work-around?
[13:17] <frankban> bac: install_requires=["websocket-client==0.12.0"],
[13:17] <frankban> bac: which is correct, 0.12.0 is the trusty release
[13:17] <bac> frankban: can we add that to quickstart?
[13:18] <frankban> bac: so, the easy fix is to add websocket-client as a dependency in requirements.pip, even if it's not a direct dependency
[13:19] <frankban> bac: setup.py automatically adds the requirements listed in requirements.pip
[13:20] <bac> frankban: verified that works
[13:20] <frankban> bac: cool
[13:20] <bac> frankban: i'll XXX to remove it when we go to a newer version of jujuclient
[13:21] <frankban> bac: sounds good thanks
[13:27] <rick_h_> frankban getting some <3 in the comments http://hackingdistributed.com/2014/05/22/hyperdex-on-aws/
[13:28] <bac> frankban: created new module quickstart/platform_support.py .  it is a little unwieldy but i could not shadow the stdlib platform module.
[13:28] <frankban> rick_h_, jcastro: cool!
[13:29] <redir> there's no juju noop command is there?
[13:29] <redir> one that prints what it would do but doesn't actually do it?
[13:32] <frankban> bac: platform_support sounds ok, I suggested platforms but I agree is too similar to the stdlib one. from PEP8: "Underscores can be used in the module name if it improves readability.". I think this is the case
[13:32] <frankban> redir: I am not aware of any dry run mode
[13:43] <redir> frankban: tx
[13:44] <bac> frankban: requested changes made and ready for review at https://codereview.appspot.com/99410054/
[13:45] <frankban> bac: looking
[13:46] <redir> frankban: tx
[13:46] <redir> echo
[13:46] <frankban> redir: yw yw
[13:50] <bac> rick_h_: standup shouldn't go long today, should it?
[13:50] <rick_h_> bac: nope
[13:50] <rick_h_> bac: just normal run through and we've got two weekly review
[13:50] <bac> good.  going to tour CG cutter at 11:45
[13:50] <rick_h_> gotcha
[13:51] <rick_h_> bac: will try to move fast today
[13:55] <redir> I'd like to find a way to fail faster:/
[13:57] <frankban> bac: done
[14:02] <redir> what does: An error occurred while deploying the bundle: error() takes exactly 2 arguments (4 given) mean
[14:03] <redir> in jujugui
[14:03] <rick_h_> redir: it means something didn't go according to plan. I bet the deployer doesn't like some error handling code
[14:04] <rick_h_> redir: want to hangout and see what's up?
[14:04] <hazmat> hmm
[14:05] <redir> just started different bundle... but I htink I can reproduce
[14:05] <bac> redir: i'm available now to help.
[14:05] <redir> I prolly have something wrong in some bundle
[14:05] <redir> I am here
[14:05] <rick_h_> redir: yea, but we probably have something wrong is surfacing that error to the user behind the gui
[14:06] <redir> ok gimme about 10 minutes to see if this deploy succeeds
[14:06] <rick_h_> k
[14:06] <hazmat> redir, found it
[14:07] <hazmat> redir, the bundle had an invalid placement  fwiw
[14:08] <hazmat> redir, can you pastebin the bundle
[14:11] <redir> hazmat: sure
[14:15] <redir> hazmat:
[14:16] <redir> http://paste.ubuntu.com/7505780/
[14:16] <hazmat> redir, so for placement onto another service.. you have to specify for each unit the remote service unit.
[14:17] <hazmat> hmm
[14:17] <hazmat> your syntax looks sane though
[14:18] <hazmat> redir, try with to: [mongodb]
[14:18] <redir> hazmat: I have modified it about 100 times
[14:18] <hazmat> redir, you mean you've already tried that suggestion?
[14:18] <redir> so rerunning to verify
[14:18] <redir> hazmat: I believe so
[14:18] <hazmat> redir, like 10 and 19
[14:19] <redir> http://paste.ubuntu.com/7505793/
[14:19] <hazmat> redir, that works
[14:19] <redir> hazmat: that one works to put all services on one machine "0" if previously bootstrapped
[14:20] <redir> but mongo doesn't start
[14:20] <hazmat> redir, and the log says?
[14:20] <hazmat> for mongo that is
[14:20] <redir> so I am now trying to deploy the 3 services in the bundle to 1 other machine
[14:20] <redir> mongo the log says nothing no log created in /v/l/m/m.log
[14:20] <hazmat> redir, also check /var/log/upstart/mongodb.log
[14:21] <redir> doesn't start using service ... start either
[14:21] <redir> hazmat: doh, forgot about that other log location:/
[14:23] <hazmat> the whole charm world deploy and ingest world to support the gui is kinda of bogus
[14:23] <redir> hazmat sadly that time the bundle didn't get the error
[14:23] <hazmat> redir, why so glum chum ;-)
[14:23] <hazmat> sledgehammer to cut cheese..  style
[14:24] <redir> you've pointed me at that upstart log dir before and I forgot about it
[14:25] <redir> An error occurred while deploying the bundle: read tcp <IP_ADDRESS>:37017: i/o timeout
[14:25] <redir> doesn't look ideal
[14:26] <frankban> rogpeppe: are you available for reviewing https://codereview.appspot.com/98510043 ?
[14:26] <rogpeppe> frankban: looking
[14:26] <frankban> rogpeppe: thanks
[14:34] <hazmat> redir, its juju state server on the fritz, it comes back. but the deploy needs to be reattempted
[14:34] <hazmat> redir, your running two mongodbs, juju state server, charmworld trying to ingest the universe.. its quite a heavy workload for a single machine
[14:35] <hazmat> oh.. and java elasticsearch
[14:35] <redir> hazmat: on that deploy there are two machines
[14:35] <hazmat> redir, to=0 ?
[14:36] <redir> the one with the 37017 i/o fail is on m0 and es/cw/mongo are on m1
[14:36] <redir> but es failed to show up on that one
[14:36] <redir> hazmat: bac I'd be glad for eyes on these two envs I have running
[14:36] <hazmat> redir, are you using canonistack?
[14:37] <redir> hazmat: uh probably not
[14:37] <redir> ec2
[14:37] <hazmat> redir, cool
[14:38] <redir> hazmat: bac invites sent if you are free
[14:38] <redir> https://plus.google.com/hangouts/_/gyagopwm6fdrxuvnl6oaqdjhoya?authuser=3&hl=en
[14:50] <rick_h_> jujugui call in 10
[14:50] <hazmat> redir, sorry stepped away.. no one was there
[14:58] <rick_h_> jujugui call in 2 kanban and such please
[15:01] <rick_h_> frankban: rogpeppe Makyo ^
[15:06] <Makyo> jujugui Review/QA: https://github.com/juju/juju-gui/pull/340
[15:10] <bac> redir: i'm running an experiment on ec2 to see if i can manually deploy mongo to machine 0
[15:21] <hatch> another week almost down....man these weeks fly by
[15:22] <rick_h_> yea, no kidding
[15:23] <frankban> hatch: its seems Y.merge is shallow and clone is deep copy: http://yuilibrary.com/yui/docs/api/classes/YUI.html#method_clone
[15:24] <hatch> doh!
[15:24] <hatch> sorry everyone!
[15:24]  * hatch sulks away
[15:24] <hatch> ^ jujugui
[15:25] <frankban> hatch: :-) np, I was just wondering why my Y.clone fix worked two weeks ago
[15:27] <rick_h_> :)
[15:28] <bac> rogpeppe, redir: http://paste.ubuntu.com/7506019/
[15:32] <hatch> ok....what's it going to cost me to get someone to write these tests.....?
[15:32] <hatch> :P
[15:34] <hatch> rick_h_ btw - maybe I like the token widget now
[15:34] <hatch> MAYBE
[15:35] <hatch> :-)
[15:40] <rick_h_> hatch: hah, just a matter of time :P
[15:41]  * rick_h_ is going to get a t-shirt made up "Jeff says 'maybe..mabye rick was right" :P
[15:42] <hatch> lol
[15:52] <hatch> rick_h_ I can now reproduce Makyo's bug - We need to ignore the inflight response because the 'store' abstraction doesn't return the actual XHR pointer
[15:53] <rick_h_> hatch: right, I think we chased that before
[15:54] <hatch> the 'proper' fix would be to fix the store abstraction I think - but we can do a workaround for now, I'll do it in a follow-up
[15:54] <rick_h_> hatch: cool, yea I think a sanity check to just have the response come back and note the container is gone, halt, would beok
[15:55] <rick_h_> hatch: it's almost same effect as inflight ignoring because it's not like the server stops
[15:55]  * redir orders some lunch then wants to chat with rick_h_ to work out plan for this and handoff/knowledge transfer
[15:55] <rick_h_> redir: ok, are we chatting before lunch or after it?
[15:55] <hatch> right right - it would be nice though from the destructor to be able to call something like 'inflight.cancel()' though
[15:56] <rick_h_> hatch: right, but then it needs access to the store internals
[15:56] <redir> your choice rick_h_
[15:56] <rick_h_> hatch: it's a bit dirty
[15:56] <hatch> rick_h_ well no, the store calls could return a reference to the call
[15:56] <hatch> just like the env does
[15:56] <rick_h_> hatch: k
[15:56] <rick_h_> redir: let's do before then while it's fresh in our heads
[15:56] <hatch> this might be one of those 'just' things which turns into a big job hah
[15:56]  * rick_h_ is going to be shutting down after lunch friday ugh
[15:56] <hatch> so workaround first
[15:57] <rick_h_> hatch: I have a feeling like I chased that down before and hit that wall
[15:57] <redir> OK
[15:57] <hatch> tis possible
[15:57] <redir> let me make a biobreak and I am ready
[15:57] <rick_h_> hatch: this has the smell of promises causing doom to it
[15:58] <rick_h_> hatch: I think that's what I hit, some of the store calls are wrapped with promises that have specific return values already
[15:58] <hatch> haha I thought we got rid of promises, or are they still in there?
[15:58] <rick_h_> and getting at a reference to the ajax call isn't easily done
[15:58] <rick_h_> we stopped creating more, we never cleaned out the old ones
[15:58] <hatch> oh I thought we did
[15:59] <rick_h_> https://github.com/juju/juju-gui/blob/develop/app/store/charmworld.js#L280
[15:59] <rick_h_> and more
[16:01] <hatch> ohh boy
[16:01] <hatch> promises - the gift that keeps on giving
[16:01] <redir> rick_h_: ready and in daily HO
[16:01] <rick_h_> hatch: ok otp
[16:05] <redir> rick_h_: http://paste.ubuntu.com/7506167/
[16:11]  * rick_h_ goes to get food
[16:12] <hatch> rebase is nice when you want to re-order commits
[16:19] <rick_h_> yep yep
[16:37] <rick_h_> redir: woot, that bundle came up for me
[17:15] <hatch> ugh edge case
[17:15] <hatch> for the amount of pixels this takes up on a screen there are sure a lot of cases
[17:15] <rick_h_> :)
[17:16] <redir> rick_h_: with ~cs:charmworld?
[17:16] <redir> or with bac's branch?
[17:16] <rick_h_> redir: both
[17:16] <rick_h_> redir: I used your bundle first as it was
[17:16] <redir> rick_h_: failed for me with bac's branch
[17:16] <rick_h_> and I've just finished a second pass with the source set to lp:charmworld
[17:16] <redir> I must have the spelling wrong
[17:17] <rick_h_> redir: I downlaoded it and then just passed it to juju-quickstart
[17:17] <rick_h_> redir: so not sure
[17:17] <rick_h_> you pasted it right :)
[17:17] <rick_h_> redir: have some basics for the local charm docs? I'll try it out on my env I've got here
[17:18] <redir> rick_h_: actually I need some local charms:)
[17:18] <rick_h_> charm get XXX
[17:18] <rick_h_> using charmtools
[17:18] <redir> oh
[17:18] <rick_h_> will fetch them down and such
[17:18] <rick_h_> brb
[17:18] <redir> rick_h_: how can I be sure it would deploy my charm rather than one ingested?
[17:20] <rick_h_> redir: you're not tryuing to deploy it
[17:21] <rick_h_> this is all eye candy, to get a charm into charmworld and then the gui will show it in the top left of the sidebar
[17:22] <redir> oh
[17:23] <bac> redir: how goes the battle?
[17:24] <rick_h_> hey bac side note, do you still have hte apache log info on the mjc traffic? IS asked me to get an RT filed to investigate the traffic and get it corrected and I want to make sure to fill in the fact right
[17:25] <bac> rick_h_: i have anonymized apache logs from the other day. thedac just got it for me with no RT.  is that what you want?
[17:25] <rick_h_> bac: yes, I just want to get the facts together. Knowing thedac helped look is good info.
[17:26] <bac> rick_h_: i can paste some representative entries or give you the whole 22M compressed file
[17:26] <rick_h_> bac: a couple reference points will be good. Mainly I want to make sure we are positive where the traffic was from before filing the RT and how we figured out what was up
[17:27] <rick_h_> bac: or I was going to rope you into sumitting the RT and copying me on it if you don't mind/have time
[17:27] <rick_h_> bac: but on the bundle front I've had two good deploys from quickstart the colocated bundle redir put together and we're getting ready to test the local charm ingestion part
[17:30] <bac> rick_h_: it was positively identified by the user-agent being gsa-crawler.  thedac then looked at the non-anon IP address and saw it was internal.
[17:30] <rick_h_> bac: ok
[17:33] <bac> rick_h_: http://paste.ubuntu.com/7506455/
[17:33] <rick_h_> bac: thanks, appreciate the details
[17:34] <bac> rick_h_: but IS already took some action to scale back the load caused by the crawler.  would be worth a check to see if it has helped.
[17:41] <bac> rick_h_: do you want me to file an RT?  if so, what are we requesting?  that they look at the log files to see if they are causing excessive load or that they not index the sites at all?
[17:41] <rick_h_> bac otp, I'll file in a bit
[17:41] <rick_h_> bac: they want to see why it's crawling at all
[17:41] <bac> rt
[17:41] <bac> ah, best plan
[17:42]  * rogpeppe is done for the day
[17:42] <rogpeppe> see y'all tuesday
[17:42] <rick_h_> have a good weekend rog
[17:43] <rogpeppe> rick_h_: and you. and happy weekends to everyone else too!
[17:48] <redir> later rogpeppe
[17:53] <redir> rick_h_: otp?
[17:55] <rick_h_> redir: yea on the phone
[18:02] <redir> bac got a sec?
[18:02] <bac> i do
[18:02] <redir> regualar channel or should I start one?
[18:02] <bac> hatch: thanks for the tip about iterm2.  urwid works fine on it.
[18:02] <bac> redir: regular
[18:02] <hatch> awesome
[18:02] <hatch> yeah it's by far the most popular terminal client on osx
[18:42] <rick_h_> redir: how we doing? I've got a 15min break here
[18:45] <redir> good
[18:45] <redir> wanna follow up after your call or have a look?
[18:46] <rick_h_> redir: sounds good
[18:47] <redir> which?
[18:48] <rick_h_> oh, follow up after hte interview 4pm ish (hopefully a bit earlier)
[18:48] <redir> OK
[18:48] <redir> perfect
[18:48] <rick_h_> sorry, read that as "after your call have a look"
[18:48] <rick_h_> come on friday!
[18:50] <redir> np
[18:50] <redir> I  shouldhn't ask compound questions
[18:59] <hatch> I wish YUI had a deep comparitor
[19:07] <hatch> edge case.....SMASHED
[19:07] <hatch> boo yeah
[19:11] <hatch> oh that just broke everything outside of il
[19:11] <hatch> head....desk
[19:17] <hatch> apparently this render editorial and sidebar business is ingrained into the browser deeper than I had thought
[19:26] <redir> rick_h_: I have to run two errands before things close. I should be back by 4
[19:26] <rick_h_> rgr
[19:27] <hatch> The Witcher 2 is only $4 and avail on Linux
[19:27] <hatch> http://store.steampowered.com/app/20920/
[19:28] <rick_h_> hatch: cool or need to chat?
[19:29] <rick_h_> redir: cool, I'm free when you get back
[19:29] <hatch> rick_h_ all good - I just need to add a bunch of code back in which is causing cascading test failures
[19:29] <hatch> and tackle them in a follow-up
[19:29] <rick_h_> gotcha
[19:29] <rick_h_> yea, smaller is better in this process
[19:32] <hatch> rick_h_ I can also just put a patch in and break non il
[19:35] <hatch> actually I can just fudge these tests
[19:43] <hatch> rick_h_ no wonder this didn't work out going whole hog on it heh
[19:43] <hatch> it's all so intertwined in ways that aren't immediaately apparent until you break it :)
[19:43] <rick_h_> yea, I make bad decisiosn so you don't have to
[19:43] <rick_h_> :)
[19:43] <hatch> lol
[19:43] <rick_h_> decisions that is
[19:48] <hatch> excellent, back to where I was 2h ago
[19:48] <rick_h_> heh, baby steps
[19:49] <hatch> heh it's funny when tests pass but the code their testing doesn't exist
[19:49] <hatch> too much stubbing
[19:49] <hatch> lol
[19:49] <rick_h_> yea, I'm nervous with the level of stubbing we're getting to
[19:50] <hatch> once we go to a folder based, test hierarchy it will be a lot easier to see where our tests are and how they integrate
[20:02] <redir> rick_h_: I am back
[20:02] <rick_h_> redir: cool
[20:02] <rick_h_> redir: https://plus.google.com/hangouts/_/gqvoo43tsgwyvpgcdtinfcjdema?authuser=1&hl=en
[20:40] <redir> rick_h_: https://dl.dropboxusercontent.com/u/7386012/cw-2instance-demo.tar.bz2
[20:41] <redir> rick_h_: lemme know when you grab it
[20:41] <rick_h_> redir: rgr
[20:41] <redir> I'll remove after
[20:41] <rick_h_> redir: got it, extracted and can read the readme
[20:42] <rick_h_> redir: thanks again for working on that and getting your juju crash course in :)
[20:46] <hatch> passing tests.....victory
[20:47] <hatch> now to see if it still works
[20:47] <hatch> lol
[20:47] <rick_h_> hah I was going to ask if it'll pass review and qa
[20:48] <redir> rick_h_: want me to leave that stuff running in aws?
[20:49] <rick_h_> hatch: I will say let's see next week if this is still a problem if we can start a parallel path vs refactor
[20:49] <rick_h_> redir: nope, you're good thanks
[20:49] <redir> OK rick_h_ then I am going to destroy that environment.
[20:50] <rick_h_> redir: sounds good
[20:50] <hatch> rick_h_ which problem?
[20:50] <hatch> rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1322744 maybe we want to make luca aware of this bug
[20:51] <_mup_> Bug #1322744: Entering a text search query after selecting category restricts search to that category silently <juju-gui:New> <https://launchpad.net/bugs/1322744>
[20:51] <rick_h_> hatch: this refactor, if we can't get the stuff to work with flags on and off we build a diff code path
[20:51] <rick_h_> hatch: we've talked about it. It'll go away soon
[20:51] <hatch> the filters?
[20:51] <rick_h_> that's an existing bug actually, /me looks for it
[20:52] <hatch> ohh ok
[20:52] <rick_h_> hmm, no luck. Well yes it's a know ux failure that will go away but we live with for now
[20:52] <hatch> rick_h_ ok so doing the QA after I have it working properly under il the charmbrowser now no longer works without il
[20:52] <redir> rick_h_: also leaving that card in the code column if you are working on it still
[20:53] <rick_h_> redir: ok thanks I am
[20:53] <rick_h_> hatch: https://plus.google.com/hangouts/_/canonical.com/mark-rick?authuser=1
[20:55] <bac> redir: how goes the battle?
[20:56] <redir> thanks bac, rogpeppe, and hazmat for all your assists navigating the juju/quickstart/deployer/bundle jungle
[20:56] <redir> bac done I think
[20:56] <redir> bac rick_h_, is adding a couple more things to it
[20:57] <redir> bac I updated your doc a little to. To reflect using juju scp -- -r ...
[20:57] <redir> and also to use local-charms directories with valid series names
[20:57] <bac> redir: thanks.  that knowledge came afterwards and i forgot to update
[20:57] <redir> np
[20:57] <bac> redir: i think we need to file a juju-core bug about mongodb on node 0
[20:58] <redir> bac and one about controlmaster:)
[21:00] <hatch> rick_h_ in case you were interested here is the branch with all the new tests and whatnot https://github.com/juju/juju-gui/pull/342
[21:01] <rick_h_> hatch: k, I'll probably not peek until monday to be honest
[21:01] <rick_h_> brain fry setting in
[21:02] <hatch> yeah np, it's almost a 1000 line diff but a big chunk of that was the removal of the original search results list test suite
[21:02] <bac> redir, rogpeppe: bug filed -- https://bugs.launchpad.net/juju-core/+bug/1322747
[21:02] <_mup_> Bug #1322747: Deploying mongodb to machine 0 fails <juju-core:New> <https://launchpad.net/bugs/1322747>
[21:04] <hatch> rick_h_ oh ok I know why it doesn't render now - just looking into how much work it'll be to fix it
[21:05]  * rick_h_ runs off to get the boy from day care. Have a good weekend all if I don't see you alter
[21:05] <rick_h_> later
[21:05] <hatch> enjoy!
[21:09] <hatch> nice....fixed it
[21:26] <hatch> jujugui looking for two reviews and qa's on https://github.com/juju/juju-gui/pull/342 plz and thanks
[21:48] <hatch> anyone still in?
[21:49] <rick_h_> Makyo: email on the way
[21:49] <rick_h_> hatch: don't think so, TGIF
[21:49] <hatch> haha, well my branch is finished and up for any takers if they want over the weekend
[21:49] <hatch> I'm going to continue on it for the next card
[21:49] <hatch> on a new branch from it that is
[21:49] <rick_h_> dude, go enjoy the weekend :P
[21:50] <hatch> I still have an hour!
[21:50] <rick_h_> we'll catch up on monday and I'll help review/qa it
[21:50] <hatch> and it's +30C, way to hot!
[21:50] <rick_h_> lol
[21:50] <rick_h_> then go slack or play with go or the python stuff
[21:50] <rick_h_> or take a nap
[21:50] <rick_h_> those are good when it's hot :P
[21:50] <hatch> go put on some SPF 110 and head outside
[21:50] <hatch> lol
[21:50] <rick_h_> there you go
[21:50] <rick_h_> mow the lawn!
[21:51] <hatch> yeah it does need some mowing
[21:51] <hatch> ok gong to mow the lawn
[21:52] <hatch> you convinced me
[21:52] <rick_h_> and with that, the invites out, ty Makyo for the assist, and I'm going to run away as well
[21:52] <rick_h_> lol
[21:52] <rick_h_> glad my feedback works on lawns
[21:52] <rick_h_> (that I can't see)
[21:52] <hatch> haha - enjoy your weekend
[22:16]  * redir heads to pack. This time tomorrow I'll be sitting on a beach with a margarita or something... see you all in a week.
[22:16] <redir> or so