[00:22] -queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset)
[00:29] -queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-sourcemap.v1 [source] (disco-proposed) [1.0.5-1ubuntu1]
[00:31] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+7-1ubuntu1]
[00:31] -queuebot:#ubuntu-release- Unapproved: accepted linux-ftpd-ssl [source] (disco-proposed) [0.17.36+0.3-2.1ubuntu1]
[00:32] -queuebot:#ubuntu-release- New binary: golang-gopkg-sourcemap.v1 [amd64] (disco-proposed/universe) [1.0.5-1ubuntu1] (no packageset)
[00:36] -queuebot:#ubuntu-release- New: accepted golang-gopkg-sourcemap.v1 [amd64] (disco-proposed) [1.0.5-1ubuntu1]
[02:01] -queuebot:#ubuntu-release- New binary: golang-github-robertkrimen-otto [amd64] (disco-proposed/universe) [0.0~git20180617.15f95af-2] (no packageset)
[02:41] -queuebot:#ubuntu-release- New: accepted golang-github-robertkrimen-otto [amd64] (disco-proposed) [0.0~git20180617.15f95af-2]
[02:55] <tsimonq2> xnox (cc vorlon): ack on the CSS changes.
[03:09] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+7-1ubuntu1 => 11.0.3+7-2ubuntu1] (core)
[04:02] -queuebot:#ubuntu-release- New binary: golang-github-flynn-json5 [amd64] (disco-proposed/universe) [0.0~git20160717.7620272-1] (no packageset)
[04:46] -queuebot:#ubuntu-release- Unapproved: openjdk-13 (disco-proposed/universe) [13~13-0ubunt1 => 13~17-1] (no packageset)
[04:47] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [source] (disco-proposed) [13~17-1]
[04:47] -queuebot:#ubuntu-release- New: accepted golang-github-flynn-json5 [amd64] (disco-proposed) [0.0~git20160717.7620272-1]
[05:07] <vorlon> tjaalton: intel-compute-runtime, note that this license should be labelled 'BSD-3-clause' in debian/copyright, not just 'BSD'
[05:19] -queuebot:#ubuntu-release- New: accepted intel-compute-runtime [source] (disco-proposed) [19.13.12717-0ubuntu1]
[05:20] <infinity> bdmurray: That's actually meant to be a redirect through ubuntu.com, which appears to have broken some time in the past.  I'll talk to the web team about it this morning.
[05:24] -queuebot:#ubuntu-release- Unapproved: resolvconf (disco-proposed/universe) [1.79ubuntu12 => 1.79ubuntu13] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: intel-compute-runtime [amd64] (disco-proposed/universe) [19.13.12717-0ubuntu1] (no packageset)
[05:35] <tjaalton> vorlon: yes, fixed in git
[05:35] <tjaalton> thanks!
[05:38] -queuebot:#ubuntu-release- Unapproved: dde-qt-dbus-factory (disco-proposed/universe) [1.1.0-2 => 1.1.0-2ubuntu1] (no packageset)
[05:41] -queuebot:#ubuntu-release- New: accepted intel-compute-runtime [amd64] (disco-proposed) [19.13.12717-0ubuntu1]
[05:42] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (disco-proposed) [1.79ubuntu13]
[07:16] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Final] has been marked as ready
[07:18] <acheronuk> morning. any issues cropped up demanding respins, or are we looking good over all?
[07:18] <acheronuk> I'm assuming the later, as infin1ty just did block-all source
[07:19] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Final] has been marked as ready
[07:47] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Final] has been marked as ready
[07:55] <acheronuk> infinity or anyone else who may know.. flavours such as Kubuntu supported 16.04 for 3 year, so do we get a EOL email sent out from Ubuntu, or does each flavour so their own. Plus where do we set the date? Exactly at the 3 year date? (e.g. 17th April for 16.04)
[07:55] <acheronuk> April 21st I mean!
[07:57] <acheronuk> also, there is some confusion about trusty eol date. 5 years would be 17th, but some sources (including a now removed statement on a Ubuntu blog) say 30th April
[08:02] <infinity> acheronuk: https://lists.ubuntu.com/archives/ubuntu-announce/2019-March/000241.html <-- The official EOLish date
[08:03] <infinity> acheronuk: As for the flavour 3y EOLs, no, I don't send notices for those.
[08:03] <infinity> acheronuk: If you have flavour mailing lists and blogs, I'd suggest maybe mentioning it there, but I also expect flavour users to follow LTS to LTS, since that's what the 3y overlap is meant to facilitate.
[08:04] <acheronuk> infinity: thanks. did not see that email
[08:05] <acheronuk> on the overlap, yes, of course. some users are hard to shift onwards though ;)
[08:13] <jibel> willcooke, infinity just finished netboot, unless you have something pending on your side, Ubuntu Desktop and netboot are good to ship for me.
[08:13] <willcooke> jibel, woot. thanks!
[08:13] <infinity> jibel: \o/
[08:15] <sil2100> pi's look good as well
[08:17] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Final] has been marked as ready
[08:17] <willcooke> \o/ \o/ \o/
[08:59] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Final] has been marked as ready
[09:01] <bluesabre> high fives all around (and back to bed)
[09:31] <sil2100> bluesabre: thanks o/
[09:32] <luna> Ubuntu 19.04 Release party at TG LAN in Norway later tonight
[10:28] -queuebot:#ubuntu-release- Unapproved: lighttpd (disco-proposed/universe) [1.4.53-3ubuntu1 => 1.4.53-4ubuntu1] (no packageset)
[10:28] <LocutusOfBorg> CVE fixes ^^
[10:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Final] has been marked as ready
[10:36] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Final] has been marked as ready
[10:36] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Final] has been marked as ready
[10:36] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Final] has been marked as ready
[10:36] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Final] has been marked as ready
[10:36] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Final] has been marked as ready
[10:49] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Final] has been marked as ready
[11:38] <Laney> tsimonq2: might want to fix that lubuntu link in the release notes?
[11:41] <tsimonq2> Laney: I assumed sil2100  would have done it. :P
[11:41] <tsimonq2> I'll look.
[11:42] <sil2100> No no no, I was only whipping about doing that
[11:43] <tsimonq2> heh
[11:46] <infinity> tsimonq2: Mark yourself ready too. :P
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Final] has been marked as ready
[11:47] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Final] has been marked as ready
[11:52] -queuebot:#ubuntu-release- Unapproved: accepted gedit [source] (disco-proposed) [3.32.0-3]
[12:13] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Final] has been marked as ready
[12:17] <tsimonq2> infinity: .
[12:17] <tsimonq2> I'll play with the wiki when I'm *not* on my phone. :P
[12:31] <tsimonq2> Oh, nice. The wiki doesn't like me today.
[12:32] <tsimonq2> The link is literally s/cosmic/disco/ with nothing else changed. Can someone please JFDI?
[12:32] <tsimonq2> Laney, sil2100: ^
[12:36] <Wimpress> tsimonq2: Are your RM for Lubuntu this release?
[12:38] <acheronuk> tsimonq2: the wiki hates everyone today
[12:40] <Laney> tsimonq2: ok, someone will need to make it not 404 then
[12:42] <tsimonq2> Wimpress: I am by default, wxl had to fill in last cycle because I was deathly ill.
[12:42] <tsimonq2> Laney: It'll stop 404ing when the ISOs come out. :P
[12:42] <tsimonq2> Wimpress: (If I'm not around, wxl is my backup, and then it falls back to the Lubuntu Council.)
[12:44] <tsimonq2> acheronuk: s/today/always/ :P
[12:45] <tsimonq2> Oh, I actually see ISOs.
[13:13] <acheronuk> tsimonq2: https://www.ubuntu.com/ says 19.04 is out. going to wait for the email still?
[13:14] <acheronuk> and instantly I sees infinity's email :)
[13:17] <cjwatson> Well done
[13:18] <ginggs> happy 19.04 everyone!
[13:18] <tsimonq2> \o/
[13:18] <tsimonq2> /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\
[13:18] <tsimonq2> Congrats everyone!
[13:18] <rbalint> \o/
[13:21] <handsome_feng> \\\\0///
[13:24] <gaughen> congrats all!
[13:40] <mdeslaur> congrats!
[13:40] <Eickmeyer> Congrats all!
[13:46] <Ukikie> infinity: Congrats.
[13:48] <sil2100> tsimonq2: I'm either on some unreliable network or the link to https://lubuntu.me/disco-released doesn't work ;)
[13:49] <sil2100> tsimonq2: the announcement is out, I guess it's *time*
[13:49] <LocutusOfBorg> do we have a codename for EE???
[13:49]  * LocutusOfBorg is joking, just to be clear
[13:49] <LocutusOfBorg> congrats everybody!
[13:49] <cyphermox> LocutusOfBorg: Edgy Eft :)
[13:50] <LocutusOfBorg> LOL
[13:50] <LocutusOfBorg> for some seconds I took it seriously
[13:50] <cyphermox> dead serious, only 13 years ago
[13:53] <mdeslaur> Edgy Eft II
[13:54] <LocutusOfBorg> http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
[13:54] <LocutusOfBorg> for the first time, non canonical contributions are at the first place?
[13:55] <Ukikie> LocutusOfBorg: One might notice https://lists.ubuntu.com/mailman/listinfo/Eoan-changes and https://launchpad.net/ubuntu/eoan
[13:55] <infinity> Looks like that's been a trend for a couple of years.  I blame people who take over the job of autosync after we freeze and stop syncing. :P
[13:56] <infinity> But also, Canonical contribution has obviously dropped off a bit since we dropped Unity.
[13:56] <LocutusOfBorg> infinity, actually if you see the number of packages, haskell is probably to blame ;)
[13:56] -queuebot:#ubuntu-release- Unapproved: kpatch (bionic-proposed/universe) [0.5.0-0ubuntu1 => 0.5.0-0ubuntu1.1] (no packageset)
[13:56] -queuebot:#ubuntu-release- Unapproved: xtables-addons (bionic-proposed/universe) [3.0-0.1ubuntu1 => 3.0-0.1ubuntu2] (no packageset)
[13:56] <Odd_Bloke> Edgy Eft II: Electric Eoogaloo
[13:57] <luna> http://releases.ubuntu.com/19.04/ubuntu-19.04-desktop-amd64.iso.torrent 0 day Ubuntu Linux warez
[13:57] <LocutusOfBorg> but I think half of my effort is "syncing packages after pushing the delta to debian" and hopefully with gcc9 we will loose all our "wl-asneeded"
[13:58] <LocutusOfBorg> is the archive open yet for eoan? :p
[13:58]  * LocutusOfBorg wants to be the first to ask
[13:58] <LocutusOfBorg> seriously, good job release team! its time to celebrate and party!
[14:10]  * juliank moved up from 16th to 15th place
[14:11] <juliank> this ubuntu-activity thing is fun
[14:12] <juliank> but like a lot of the apt stuff I do is just synced
[14:12] <juliank> :)
[14:14] <infinity> juliank: Yeah, it doesn't record autosyncs, but if you beat the bot and sync yourself, it'll pick that up. :P
[14:15] <infinity> At the end of the day, though, it's really just a way to see who does the most transitions.
[14:15] <juliank> I mostly upload things so they are synced when I wake up the next day
[14:15] <juliank> :)
[14:15] <infinity> (And the Canonical/Community split is always an interesting non-metric)
[14:15] <tsimonq2> sil2100: I would do it if I didn't have school to attend to. I'll publish during my lunch in a little more than two hours.
[14:16] <LocutusOfBorg> infinity, I think we should remove the "buildN" uploads, we would have better results
[14:16]  * infinity shrugs.
[14:16] <LocutusOfBorg> (even if no change rebuilds with delta have "ubuntu" suffix)
[14:17] <infinity> I don't think accuracy of results are really a goal.  Plus, "accuracy" changes depending on what you think it's meant to be measuring.
[14:22] <tsimonq2> What is Eoan? Is it a misspelling of Eon?
[14:23] <infinity> https://www.merriam-webster.com/dictionary/eoan
[14:24] <LocutusOfBorg> what would happen if I propose to do only one release each year? do you have statistics of installation of LTS VS non-LTS releases?
[14:24] <LocutusOfBorg> I think it might be time to relax a bit :D
[14:25] <infinity> LocutusOfBorg: Releasing less often means longer freezes and bug-hunting periods.
[14:25] <infinity> LocutusOfBorg: Releasing more often (or continuously, as some want) means never getting new features, because there's no time to fix bugs.
[14:25] <infinity> LocutusOfBorg: 6mo feels like a sweet spot for a large OS-sized project.
[14:26] <tsimonq2> infinity: Weird, a physical Merrium-Webster dictionary didn't have itm
[14:26] <tsimonq2> *it.
[14:26] <infinity> tsimonq2: Maybe Merriam would have, but your cheap knock-off Merrium didn't?
[14:27] <tsimonq2> I don't know, it was a very large dictionary.
[14:27] <tsimonq2> ¯\_(ツ)_/¯
[14:27] <LocutusOfBorg> infinity, OTOH, who cares about installing something that will be thrown away in less than 9mo?
[14:27] <infinity> LocutusOfBorg: Lots of people.
[14:27] <tsimonq2> Anyway, as usual, once we have the noun, dibs on the wiki.
[14:27] <LocutusOfBorg> ok, that was my request, do you have statistics?
[14:28] <infinity> Not handy.
[14:28] <LocutusOfBorg> ok :)
[14:28] <infinity> Popularity definitely skews more toward LTS these days, but that's mostly due to cloud.
[14:28] <LocutusOfBorg> it would be nice to compare LTS and non-LTS, to see how many are following the 6months releases
[14:28] <LocutusOfBorg> infinity, that is my point, almost every people I know, are using LTS because of 5 years support
[14:29] <tsimonq2> LocutusOfBorg: I heard LTS:non-LTS was 10:1. Don't quote me on that.
[14:29] <LocutusOfBorg> with hwe LTS gained also new features
[14:29] <infinity> tsimonq2: Stats like that count each cloud instance as an install, though, which is likely not a fair metric.
[14:29] <tsimonq2> Fairn
[14:29] <tsimonq2> *Fair.
[14:29] <tsimonq2> (Typing on mobile.)
[14:30] <tsimonq2> I do agree with infinity though.
[14:30] <LocutusOfBorg> but do you agree that the sum of "new features" each release decreased in the last 10 years?
[14:30] <LocutusOfBorg> I mean, ok I was probably a younger student 10 years ago, and students have lots of time to format the laptop
[14:31] <infinity> I'm not sure I agree with that, no.
[14:31] <infinity> We get a ton of churn.
[14:31] <LocutusOfBorg> but meh, "updated kernel updated glib, updated gnome updated foobar", but nothing really heartbreaking
[14:31] <infinity> And it's more each year.
[14:31] <LocutusOfBorg> I don't think I got what you said
[14:32] <Eickmeyer> Ubutnu Studio's update was huge. Our 25th release, and it was pretty feature-full.
[14:32] <LocutusOfBorg> what is "churn?" :) -ENONATIVESPEAKER
[14:32] <infinity> If by "new feature" you mean "holy crap, it suspends and resumes without crashing", sure, we get less of that, but that's because once you solve a problem like that, it's done.
[14:32] <infinity> So, we're a bit more "boring" by virtue of the fact that we suck less.
[14:32] <LocutusOfBorg> that is a fair point, but I mean like "hey we switched from gnome2 to gnome3" or something similar
[14:33] <ginggs> was that a feature?
[14:33] <LocutusOfBorg> :D
[14:33] <infinity> LocutusOfBorg: "churn", constant movement of stuff.  Lots of changes.  More thousands of lines of code change per year now than 4 years ago or 8.
[14:33] <LocutusOfBorg> infinity, of course code changes are big! but is end user experiencing something different at the end?
[14:33] <tsimonq2> Instead of changing the release cycle, I would argue in 2019 you don't need 3 mo ths to upgrade if you're on the non-LTS anyway.
[14:33] <tsimonq2> *months
[14:34] <LocutusOfBorg> I mean, my bionic is stable, I never had to think wrt moving to cosmic or disco
[14:34] <infinity> LocutusOfBorg: End user experience doesn't define our workload.
[14:34] <LocutusOfBorg> maybe end user installation might define it a little bit, if we discover nobody is installing non-LTS because of $reasons...
[14:34] <infinity> LocutusOfBorg: The bottom line is that lots of changed code means lots of work keeping it integrated.  The longer you allow unfettered churn, the longer you have to stop to fix it all.
[14:35] <LocutusOfBorg> but less releases means also less SRUs
[14:35] <infinity> LocutusOfBorg: Our freezes are much less painful than Debian's, and it's not because we're somehow more awesom, it's because we're dealing with smaller chunks of destabilisation.
[14:35] <LocutusOfBorg> actually just to point my little experience, I discovered today I fixed a java11 issue in virtualbox in bionic, and I completely forgot about cosmic
[14:36] <LocutusOfBorg> because 1) I wasn't aware of java11 going in cosmic 2) nobody pointed it out, so I forgot about it
[14:38] <LocutusOfBorg> my guess is that I'm not the only one who in terms of fixing stable bugs has a tendency to consider only LTS and LTS-1 instead of everything else
[14:38] <cjwatson> You're not, but I think that's OK - we don't have to fix everything
[14:38] -queuebot:#ubuntu-release- Packageset: 6787 entries have been added or removed
[14:38] <LocutusOfBorg> (not something I do on purpose!)
[14:41] -queuebot:#ubuntu-release- Unapproved: gedit (disco-updates/main) [3.32.0-3 => 3.32.0-3] (ubuntu-desktop) (sync)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted gedit [sync] (disco-updates) [3.32.0-3]
[14:47] -queuebot:#ubuntu-release- Unapproved: distro-info-data (eoan-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
[14:48] <LocutusOfBorg> oh.... so you are already ready for eoan? surprising
[14:49] <infinity> LocutusOfBorg: No.
[14:49] -queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (eoan-proposed) [0.39ubuntu2]
[14:49] <LocutusOfBorg> of course you aren't yet, but the work started quickly on that cicle
[14:50] <LocutusOfBorg> *cycle
[14:50] <Laney> It can start once we get the name, which happened in time this cycle.
[14:55] -queuebot:#ubuntu-release- Unapproved: distro-info-data (eoan-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
[15:11] <teward> *hands the Release Team beers*
[15:12]  * Eickmeyer sends teward a quad-shot venti latte
[15:12]  * teward absorbs through osmosis
[15:19] -queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.11 => 0.18ubuntu0.12] (core)
[15:20] -queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.37ubuntu0.3 => 0.37ubuntu0.4] (core)
[15:20] -queuebot:#ubuntu-release- Unapproved: distro-info-data (disco-proposed/main) [0.39ubuntu1 => 0.39ubuntu2] (core)
[15:20] -queuebot:#ubuntu-release- Unapproved: distro-info-data (cosmic-proposed/main) [0.38ubuntu0.2 => 0.38ubuntu0.3] (core)
[15:20] -queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.10 => 0.28ubuntu0.11] (core)
[15:24] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (disco-proposed) [0.39ubuntu2]
[15:24] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (cosmic-proposed) [0.38ubuntu0.3]
[15:25] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (bionic-proposed) [0.37ubuntu0.4]
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.11]
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.12]
[15:28] <tsimonq2> Nice, Eanimals are cool. Is that Australian? :P
[15:29] <sil2100> I don't know, I'm not very knowledgable in animals! Especially e-animals
[15:30] <sil2100> Electronic-animals
[15:30] <sil2100> hm
[15:30] <sil2100> Bionic animals?
[15:30] <tsimonq2> XD
[15:42] <vorlon> congrats, all!
[15:50] -queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (eoan-proposed) [0.39ubuntu2]
[16:42] <acheronuk> infinity: perhaps an impossible things to estimate, but do you have an ETA on updating the metadata to turn do-release-upgrades on?
[16:43] <acheronuk> if not, then fine :)
[16:55] <infinity> bdmurray: ^
[16:55] <bdmurray> infinity: Do you want me to give an estimage? ;-)
[16:55] <infinity> bdmurray: Sure. :)
[16:56] <infinity> bdmurray: Or if you're not aware of any upgrade showstoppers, do the thing.
[16:56]  * infinity needs to lie down for a bit to let these drugs clear his sinuses.
[16:56] <bdmurray> infinity: I'm not aware of any because either nobody tests or its perfect
[17:02] <bdmurray> acheronuk: real soon now maybe an hour at most
[17:02] <acheronuk> bdmurray: I know in recent times it has been a few days. if we look like going sooner, I won't complain
[17:03] <acheronuk> bdmurray: people have been asking, and all I have been able to do is cite past examples
[17:05] <bdmurray> acheronuk: what release did we wait days? I'm not remembering one immediately
[17:13] <acheronuk> bdmurray: I don't recall. the memory is insistent on the fact, but could be mistaken I guess
[17:13] <acheronuk> something like release on Thurs but meta not updated until Monday
[17:14] <acheronuk> honesly, I don't care if that memory or normal procedure is wrong. :)
[17:14] <bdmurray> well if you are repeating it and its wrong...
[17:15] <acheronuk> I did say it could be hrs to a few days, depending...
[17:18] <acheronuk> point being that as said, only done if it seems no showstoppers. which I can only hedge bets on
[17:18] <bdmurray> okay for bionic we did wait a couple of days
[17:19] <bdmurray> https://bazaar.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu/revision/208#meta-release
[17:19] <acheronuk> fair enough
[17:31] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu<IP_ADDRESS> => 10ubuntu<IP_ADDRESS>] (no packageset)
[19:03] -queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (bionic-proposed) [7.5.0+18.04.20190304-0ubuntu1]
[19:11] -queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (xenial-proposed) [7.4.5+16.04.20190312-0ubuntu1]
[19:25] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-advantage-tools [source] (trusty-proposed) [10ubuntu<IP_ADDRESS>]
[20:03] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu<IP_ADDRESS> => 10ubuntu<IP_ADDRESS>] (no packageset)
[20:03] <ahasenack> vorlon: ^
[20:13] <valorie> Thank you release team!
[20:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (trusty-proposed) [10ubuntu<IP_ADDRESS>]
[20:15] <tsimonq2> infinity, vorlon: Can I please get your AA hat opinion? https://github.com/lxqt/libfm-qt/issues/370#issuecomment-484671222
[20:15] <gitbot> lxqt issue 370 in libfm-qt "Licensing question" [Closed]
[20:17] <vorlon> tsimonq2: can you phrase that in the form of a question rather than a link to a nondescript comment in a github issue? :)
[20:18] <tsimonq2> vorlon: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927380 two files were released with the wrong license.
[20:18] <ubot5`> Debian bug 927380 in release.debian.org "unblock: libfm-qt/0.14.1-5" [Normal,Open]
[20:18] <vorlon> that's still not a question
[20:18] <tsimonq2> What is the appropriate action here?
[20:19] <vorlon> merge the new version when Ergonomic opens?
[20:19] <tsimonq2> Patch the source, or call it good since upstream explicitly patched it?
[20:19] <tsimonq2> For Disco.
[20:19] <vorlon> there are plenty of upstream license statements in source tarballs that are incorrect
[20:20] <tsimonq2> That's the answer then, thanks!
[20:20] <vorlon> we don't need to do extra work to make the upstream license statements match reality :)
[20:20] <tsimonq2> Makes sense, just confirming :)
[20:21] <vorlon> and AIUI the upstream fix was to correct the license statement to LGPL, in which case debian/copyright happened to already be accuarte
[20:47] -queuebot:#ubuntu-release- Unapproved: dde-qt-dbus-factory (eoan-proposed/universe) [1.1.0-2 => 1.1.0-2ubuntu1] (no packageset)
[20:48] -queuebot:#ubuntu-release- Unapproved: rejected dde-qt-dbus-factory [source] (disco-proposed) [1.1.0-2ubuntu1]
[20:48] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2]
[21:10] <tsimonq2> Ahh, got it


[21:50] <Harrier_II> whats the latest version
[21:57] <moylan> what's the latest version of what?
[23:23] <jacekowski> mornign people


[00:44] -queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.11 => 1:17.10.12] (core)
[03:10] <valorie> slangasek: I have one more question about the re-released ISOs - I see nothing for ubuntustudio
[03:11] <valorie> is that deliberate?
[03:13] <slangasek> valorie: there were no test results reported for ubuntustudio
[03:14] <valorie> ok
[03:14] <valorie> not a good sign for the health of that team
[03:14] <krytarik> Nope, it isn't.
[03:46] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-29.32~16.04.1] (kernel)
[06:59] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-29.32~16.04.1]
[07:11] -queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [17.2.4-0ubuntu1~16.04.3 => 17.2.4-0ubuntu1~16.04.4] (core, xorg)
[08:32] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (xenial-proposed) [17.2.4-0ubuntu1~16.04.4]
[09:02] -queuebot:#ubuntu-release- Unapproved: amd64-microcode (trusty-security/main) [2.20131007.1+really20130710.1 => 2.20131007.1+really20130710.1] (no packageset) (sync)
[09:02] -queuebot:#ubuntu-release- Unapproved: amd64-microcode (zesty-security/main) [3.20160316.3 => 3.20160316.3] (no packageset) (sync)
[09:02] -queuebot:#ubuntu-release- Unapproved: amd64-microcode (xenial-security/main) [2.20160316.1 => 2.20160316.1] (no packageset) (sync)
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [sync] (trusty-security) [2.20131007.1+really20130710.1]
[09:02] -queuebot:#ubuntu-release- Unapproved: amd64-microcode (artful-security/main) [3.20160316.3 => 3.20160316.3] (no packageset) (sync)
[09:03] -queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [sync] (artful-security) [3.20160316.3]
[09:03] -queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [sync] (zesty-security) [3.20160316.3]
[09:03] -queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [sync] (xenial-security) [2.20160316.1]
[09:48] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-110.133] (core, kernel)
[09:49] -queuebot:#ubuntu-release- New: accepted cloud-initramfs-tools [amd64] (xenial-proposed) [0.27ubuntu1.5]
[09:49] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-110.133]
[11:17] -queuebot:#ubuntu-release- New binary: r-cran-git2r [amd64] (bionic-proposed/universe) [0.21.0-1] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: spectre-meltdown-checker [i386] (bionic-proposed/universe) [0.27-1] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: python-pygerrit2 [amd64] (bionic-proposed/universe) [2.0.4-1] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: wireguard [amd64] (bionic-proposed/universe) [0.0.20171221-4] (no packageset)
[11:20] -queuebot:#ubuntu-release- New binary: r-cran-git2r [i386] (bionic-proposed/universe) [0.21.0-1] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: spectre-meltdown-checker [amd64] (bionic-proposed/universe) [0.27-1] (no packageset)
[17:12] -queuebot:#ubuntu-release- New binary: spectre-meltdown-checker [amd64] (bionic-proposed/universe) [0.28-1] (no packageset)
[18:45] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-110.133~14.04.2] (kernel)
[18:51] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-110.133~14.04.2]
[23:16] -queuebot:#ubuntu-release- New binary: wireguard [amd64] (bionic-proposed/universe) [0.0.20171221-5] (no packageset)


[14:19] <immu> where is willcook?
[18:30] <jbicha> fossfreedom: gnome-shell is no longer on the Ubuntu Budgie iso's (fixed by dropping the gnome-session dep from mutter and metacity)
[20:19] <fossfreedom> jbicha, brilliant news - and thanks ever so much for helping on this.  much appreciated.
[22:49] <Laney> pitti: I think you might have broken autopkgtest-build-lxd with fc10ae67e0f1cb1cb51350288c63d60a65b126ba (https://paste.ubuntu.com/25099812/)
[22:49] <Laney> pitti: I guess it's the removal of grep -v $ALIAS


[04:31] <SpamapS> negronjl: you ready for tomorrow?
[10:51] <antono> hi all. testing juju with local provider
[10:52] <antono> for some reason no success. it cannot start all lxc containers for very long time
[10:53] <antono> so basically machine     state: not-started during 10 minutes
[10:53] <antono>
[10:53] <antono> yesterday i got it running somehow... but i was away for a long time
[14:31] <yolanda> hi, good afternoon
[14:31] <yolanda> i'm trying to create an openstack instance from juju, but the instance gives me error
[14:31] <yolanda> anyone can guide me on how correctly setup the environments.yaml for openstack? i should be missing something
[15:14] <james_w> how's the charm store coming along?
[15:20] <bbcmicrocomputer> hi, a quick Q.. when writing Charms, is it by design that Juju executes hooks with a umask of 0077?
[16:34] <jcastro> bbcmicrocomputer, out of curiosity, what are you looking to charm?
[16:36] <jamespage> jcastro, I hoping to persuade him to charm hive :-)
[16:36] <jcastro> heh
[16:39] <jamespage> jcastro, are you helping with the charm school today?
[16:39] <jcastro> no, that's Clint and Juan
[16:39] <jcastro> it's a meatspace one
[16:43] <bbcmicrocomputer> jcastro: yeah, I'd like to do a Hive charm
[16:43] <jcastro> oh nice
[16:44] <bbcmicrocomputer> jcastro: atm, I'm just playing with jamespage's existing Hadoop ones
[16:46] <bbcmicrocomputer> jcastro, jamespage: would love to also create a Solr charm, so we could have a search server coupled to a MySQL or PostgreSQL instance
[16:47] <bbcmicrocomputer> jcastro, jamespage: be quite cool if you could just have indexing automatically set-up via the relations
[16:47] <jcastro> https://bugs.launchpad.net/charms/+bug/828367
[16:47] <_mup_> Bug #828367: Charm Needed: SolrCloud <Juju Charms Collection:New> < https://launchpad.net/bugs/828367 >
[16:48] <jcastro> and https://bugs.launchpad.net/charms/+bug/808255
[16:48] <_mup_> Bug #808255: Charm Needed: Solandra <Juju Charms Collection:New> < https://launchpad.net/bugs/808255 >
[16:48] <jcastro> those would be quite cool to see
[16:49] <bbcmicrocomputer> jcastro: ah cool, well would love to have a go at tackling them, schedule permitting
[16:49] <jcastro> awesome
[16:50] <bbcmicrocomputer> jcastro: any answer to the previous Q about why juju executes hooks with a umask of 0077?  Is it just to be *safe*?
[16:52] <jcastro> not sure
[16:52] <bbcmicrocomputer> jcastro: ah ok
[16:53] <jcastro> I can however ping bcsaller, fwereade_, hazmat, and niemeyer for you. :)
[16:53] <bbcmicrocomputer> jcastro: sure, thanks
[16:57] <fwereade_> bbcmicrocomputer, I think that comes from twistd defaults; I don;t know that we made an explicit decision ourselves
[16:57] <fwereade_> bbcmicrocomputer, but perhaps someone who joined before me will be able to contradict that
[16:58] <bbcmicrocomputer> fwereade_: ok, thanks
[17:12] <andrewsmedina> hi
[17:13] <andrewsmedina> there's a way to define a custom image in a deploy?
[17:14] <jcastro> like an AMI?
[17:16] <andrewsmedina> jcastro: yes
[17:16] <jcastro> http://askubuntu.com/questions/84333/how-do-i-use-a-specific-ami-for-juju-instances
[17:16] <jcastro> you want default-image-id
[17:16] <fwereade_> andrewsmedina, I *think* that you can still change default-image-id in environments.yaml before you deploy; but I recommend you don't come to depend on that because it'll be going away soon
[17:17] <fwereade_> andrewsmedina, what's your use case?
[17:18] <andrewsmedina> fwereade_: I want in some cases to define a custom ami in a deploy
[17:18] <andrewsmedina> jcastro: I want define at a deploy time
[17:18] <fwereade_> andrewsmedina, what are the important characteristics of the different ami?
[17:20] <jcastro> i've always wanted to do that too
[17:20] <andrewsmedina> fwereade_: I want to use juju with golden images
[17:23] <andrewsmedina> This would be possible with "--contraints"
[17:23] <andrewsmedina> like
[17:23] <andrewsmedina> juju deploy local:mysql --constraints 'image-id: ami-0000002d'
[17:24] <fwereade_> andrewsmedina, as I recall it was agreed that allowing specific images with constraints was a bad idea
[17:24] <andrewsmedina> fwereade_: why?
[17:24] <fwereade_> andrewsmedina, in particular it's an end-run around our attempts to match the ubuntu series tothe charm that's being deployed
[17:27] <andrewsmedina> fwereade_: but with this juju only works on ubuntu
[17:27] <fwereade_> andrewsmedina, but that is clearly a sensible thing to want to do; can I suggest starting a discussion on the lists? I suspect it'll be the best way to get properly considered discussion
[17:28] <fwereade_> andrewsmedina, that is a restriction that I think we're... er... somewhere between "resigned to" and "comfortable with" for now
[17:28] <andrewsmedina> fwereade_: you can do it
[17:30] <andrewsmedina> fwereade_: use golden image is a very common amazon workflow
[17:30] <fwereade_> andrewsmedina, I think there's a general assumption in the codebase that we'll be deploying to ubuntu -- charms, in particular, are intended to be targeted to a particular ubuntu series -- and we'd need to think carefully about how to relax that
[17:31] <andrewsmedina> fwereade_: and with this is not need install the same thing every time
[17:31] <andrewsmedina> fwereade_: humm
[17:31] <fwereade_> andrewsmedina, indeed -- I can definitely see the utility of what you ask for
[17:31] <fwereade_> andrewsmedina, but as I say it involves a bit more complexity than one might hope for
[17:32] <andrewsmedina> fwereade_: I know
[17:37] <fwereade_> andrewsmedina, is it ramp-up time you're mainly worried about?
[17:38] <andrewsmedina> fwereade_: yes
[17:39] <fwereade_> andrewsmedina, hmm, I'm just thinking that I actually don't know what the usual distribution of time-spent-ramping-up actually is
[17:40] <andrewsmedina> fwereade_: in every deploy, juju install juju, zookeeper agent...
[17:41] <andrewsmedina> fwereade_: update and upgrade the ubuntu
[17:43] <fwereade_> andrewsmedina, quite -- there's a fair amount to be done -- but I'm wondering how to get a decent idea of where we can save the most time in the general case
[17:44] <niemeyer> bbcmicrocomputer: Are you getting such a umask? (/cc jcastro)
[17:45] <niemeyer> bbcmicrocomputer: What's the 0077 reflecting, more precisely?
[17:45] <andrewsmedina> fwereade_: I think skipping this installation every time
[17:49] <bbcmicrocomputer> niemeyer: I noticed a lot of the configuration files being copied as part of a charm install hook was ending up as private to root, which caused problems when running daemon processes as other users.  So I altered one of the hooks to output the umask to a temporary file and found that when juju called it, it was 0077.
[17:50] <niemeyer> bbcmicrocomputer: That certainly sounds bogus
[17:50] <niemeyer> hazmat: Does that ring any bells?
[17:50] <fwereade_> bbcmicrocomputer, btw, what version of juju are you using?
[17:51] <niemeyer> bbcmicrocomputer: I can't find anything about such a umask in the code base, FWIW
[17:51] <bbcmicrocomputer> niemeyer: 0.5+bzr457-0ubuntu1
[17:51] <bbcmicrocomputer> niemeyer: me neither :)
[17:52] <niemeyer> bbcmicrocomputer: Ah, found the source
[17:52] <bbcmicrocomputer> niemeyer: it's an EC2 deployment and the system umask is def not set to 0077, so have assumed it was juju
[17:52] <niemeyer> bbcmicrocomputer:        --umask <mask>
[17:52] <niemeyer>               The (octal) file creation mask to apply. (default: 0077 for daemons, no change otherwise).
[17:52] <niemeyer> bbcmicrocomputer: From twistd
[17:52] <niemeyer> bbcmicrocomputer: Would you mind to file a bug? We'll certainly fix that
[17:53] <bbcmicrocomputer> niemeyer: ah ok, so we def shouldn't be altering charms to switch umasks?
[17:53] <niemeyer> bbcmicrocomputer: No, juju should not execute charms with such a umask
[17:53] <fwereade_> niemeyer, I *think* it's already fixed accidentally, because the upstart agents run with --nodaemon
[17:53] <bbcmicrocomputer> niemeyer: ok, will file a bug
[17:53] <niemeyer> fwereade_: Oh, was that recent?
[17:53] <fwereade_> niemeyer, thatstarts at r460 :)
[17:53] <niemeyer> hah, ok :-)
[17:54] <m_3> bbcmicrocomputer: we usually either use explicit chmods (preferred) or set the umask as needed in hooks
[17:54] <niemeyer> bbcmicrocomputer: Thanks for filing the bug. It'll be good to have that tracked no matter what
[17:54] <bbcmicrocomputer> m_3: makes sense
[17:54] <m_3> bbcmicrocomputer: lots of charm helper fns have a mode arg... ch_template_file <owner> <mode> <source> <target>
[17:55] <fwereade_> niemeyer, I haven't verified, so yeah, we definitely want that bug ;)
[17:56] <m_3> bbcmicrocomputer: 600 isn't an unreasonable starting point... better for the charm author to screw up in a more secure way than not IMO
[17:57] <bbcmicrocomputer> m_3: yeah, it wouldn't surprise me if it was by design for this very reason
[17:57] <bbcmicrocomputer> m_3: at least then the author is thinking about it
[17:57] <m_3> bbcmicrocomputer: right
[18:25] <_mup_> Bug #953258 was filed: juju executing hooks with umask of 0077 <juju:New> < https://launchpad.net/bugs/953258 >
[19:45] <_mup_> Bug #953339 was filed: juju remove-relation usage/help typo <juju:New> < https://launchpad.net/bugs/953339 >
[21:25] <robbiew> jcastro: SpamapS: http://www.zazzle.com/run_lxc_tshirt-235168775723259384
[21:25] <robbiew> we should make hallyn wear it
[21:35] <jcastro> robbiew, can we put "but don't forget to remove the stuff in /var/lib every once in a while." on the back?
[21:36] <jcastro> that is pretty awesome though
[21:37] <arosales> jcastro, m_3: If you have a spare minute could you add http://charmschoolsv.eventbrite.com/ to juju.ubuntu.com/Events?
[21:37] <robbiew> lol
[21:37] <arosales> more for our tracking where and what we have done.
[21:38] <arosales> also what do you think about putting webinars/virtual sessions you have done there to?
[21:38] <arosales> for http://charmschoolsv.eventbrite.com/ Clint and Juan are running that one.
[21:48] <m_3> arosales: done
[21:48] <arosales> m_3: Thank you
[21:50] <m_3> np
[23:10] <marcoceppi> Hey everyone o/ So I've started back up on the Steam charm and I don't think it's being done properly
[23:11] <m_3> marcoceppi: cool man... don't be shy about making changes
[23:11] <marcoceppi> Right, This one is kind of drastic though. I'm thinking that each "steam game" should be a subordinate(sp?) charm of a main Steam charm. To be deployed with the "Constraints" flag
[23:11] <marcoceppi> Opinions?
[23:12] <marcoceppi> Basically "I want to do this thing even more weirder"
[23:12] <m_3> ha!
[23:12] <marcoceppi> Because more weirder is the only way to describe it
[23:12] <m_3> I kind of seems like a config option to me
[23:12] <m_3> but there's no reason not to do it that way
[23:12] <m_3> well... except those features haven't really landed yet
[23:13] <m_3> I'd say heck yeah... experiment
[23:13] <marcoceppi> That's what I've been hammering on; however, I've run into "How do I deploy custom maps", "How do I add plugins", "How do I manage config options that don't exist between games"
[23:13] <m_3> ah right
[23:13] <marcoceppi> There are maybe a handful of shared config options, the rest are just hog wild different
[23:13] <m_3> well perhaps they're all separate charms?  that have a steam plugin of sorts
[23:14] <m_3> which is exactly what you were saying ;)
[23:14] <marcoceppi> For maps I figured there could be a "maps" folder that users can extract maps to and that would be moved in to place for that game, but if you switch game types the maps won't be compatible
[23:14] <marcoceppi> m_3: Yeah ;)
[23:14] <marcoceppi> It's a weird use case
[23:14] <marcoceppi> I really don't _want_ to make 35 different charms for each different Steam game server
[23:15] <marcoceppi> but I'm running out of sane options for consolidating them in to one
[23:15] <m_3> marcoceppi: until the steam charm can be deployed separately, then I'd recommend just using a helper sort of library for those parts... then you can turn it into a separate charm once we can do subordinates
[23:16] <m_3> marcoceppi: wow.. that _is_ a lot
[23:16] <marcoceppi> yeah :\
[23:16] <m_3> perhaps it's just more complex configuration then
[23:16] <marcoceppi> Well, I currently do this for configuration. juju steam --set config_key="mp_timelimit" config_value="12"
[23:17] <marcoceppi> so you have wild card config keys
[23:17] <m_3> right
[23:17] <m_3> note you can pass entire json or yaml files as config options...
[23:18] <marcoceppi> Also, what's the policy on something like "map_url" as a config option that would fetch a remote ZIP file and extract it (not over HTTPS and most likely using any Cryptographic checking) but wouldn't be part of the actual charm setup, user invoked
[23:20] <m_3> marcoceppi: do you have example configuration files for deploying steam?
[23:20] <m_3> a couple of different games
[23:20] <marcoceppi> m_3: I've been doing that for each game
[23:20] <marcoceppi> so you could just point to a configuration file and it would use "sane" defaults for that game
[23:21] <m_3> marcoceppi: links?
[23:21] <m_3> marcoceppi: you still working from lp:~marcoceppi/charms/oneiric/steam/trunk?
[23:22] <marcoceppi> Yeah, there might not be all the updates there but not much work has been done since then
[23:22] <marcoceppi> http://bazaar.launchpad.net/~marcoceppi/charms/oneiric/steam/trunk/view/head:/opt/tf2.cfg
[23:22] <marcoceppi> So that's what a game config looks like
[23:23] <m_3> marcoceppi: awesome... I'll take a look
[23:25] <m_3> marcoceppi: perhaps some config options can be grouped into dedicated config files... then we can pass the entire config files in as charm config params
[23:26] <m_3> yaml can take a yaml file as a field
[23:26] <marcoceppi> Interesting
[23:27] <m_3> http://paste.ubuntu.com/881172/
[23:27] <m_3> that's a snippet from a config yaml file I'm passing in to a charm
[23:27] <m_3> the | and the indentation make the magic happen
[23:27] <m_3> I think that could be really useful here
[23:29] <m_3> marcoceppi: we'd have to watch _re_configuration... treat that more as a full upgrade... but it should work
[23:30] <marcoceppi> Right, this looks promising, I'm going to give it a shot
[23:31] <m_3> seems like it'd make it easier to have separate sets of config options for different games... this way you can pass in a whole config file for each game
[23:31] <m_3> common stuff you can keep in the main config.yaml
[23:31] <m_3> but then there's an option for... game_config:
[23:31] <m_3> that you write out and point the game to during spinup