[07:17] <enyc> valorie: but, I don't see why this change-of-version mention notification is appearing at all
[07:17] <enyc> This case, could do with somebody from ubuntu to maintain...
[07:26] <enyc> would make a lot of sense to move 5.2.x version up, without the jump to 6.0.x   ,  needed for newer kernel nad a pile of other bugfixes
[07:42] <LocutusOfBorg> enyc, do you want to test virtualbox?
[07:42] <LocutusOfBorg> https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages
[07:42] <LocutusOfBorg> here you are
[07:42] <LocutusOfBorg> enyc, you can talk with me wrt virtualbox, but please move to #-devel
[07:43] <LocutusOfBorg> anyway, I uploaded yesterday the new 5.2.32 in the archive, but needs to be approved by an archive admin. You can test it and help with you testing on bug: #1835576 if you want it to eventually reach the archive
[07:44] <enyc> LocutusOfBorg: aha well i don't know where i'm going you see... nor do i know _WHY_ these messages appear in -release channel if nobody in ubuntu maintaining apparently
[07:44] <LocutusOfBorg> enyc, why should myself being considered "nobody"?
[07:44] <LocutusOfBorg> :)
[07:45] <enyc> LocutusOfBorg: ys read your second message ;p
[07:45] <enyc> LocutusOfBorg: but thats contrary to somebody elses comment which is why confused
[07:45] <LocutusOfBorg> no enyc "enyc: that means that no flavor of ubuntu maintains that package"
[07:45] <LocutusOfBorg> no packageset means: "it is not included on any ubuntu flavour ISO"
[07:46] <LocutusOfBorg> so if you donwload the iso of whichever ubuntu-* you won't have it installed, but it is maintained in the archive, for people who manually install it
[07:47] <enyc> aah, undestand packageset now
[07:48] <LocutusOfBorg> if you want to help maintaining it, please move on #ubuntu-devel, but for now, since the work is already done, testing is needed and appreciated a lot
[07:49] <Ukikie> There's some packagesets unrelated to being shipped on the ISO.
[07:58] <enyc> LocutusOfBorg: I've idefintied with nitckeserv, but not sure if you can see me writing in #ubuntu-devel
[08:21] <tkamppeter> sil21000, it is about the Bionic SRU for network-manager, bug 1754671, due to regressions the SRU was withdrawn from -updates, but the reporters of the regressions do not provide the info which I have asked them for and so I got stuck with them. As there are not many regression reports (3, no duplicates) I asked bdmurray on Tuesday whether one could roll out the SRU anyway and he told not to do so and asked me to ask for hel
[08:21] <tkamppeter> p on mailing lists (ubuntu-quality and canonical-tech) and I got no answer there so far.
[08:23] <tkamppeter> sil2100, there is also now a comment of the original poster of bug 1754671 that he is eagerly waiting for the SRU as it is fixing his problem.
[08:24] <infinity> tkamppeter: So you're hoping another member of the team will give you a different answer because you didn't like the first one?
[08:29] <tkamppeter> infinity, not really, probably I am simply out of ideas because I get no feedback from bug reporters and also no answers on mailing lists.
[08:37] <infinity> tkamppeter: I'm not sure what feedback you're hoping to get that wil resolve this.  On LP: #1829566, it ends with asking them to use a different config.  On other bugs, the claim is that things work, *if* they set a few new config options.  Neither of those is acceptable for an SRU, IMO.
[08:37] <infinity> Making people change their configs to avoid regression *is* a regression.
[08:38] <infinity> Even the guy asking for the SRU to be released is someone who had to change his configs to accomodate the SRU.
[08:38] <infinity> He just now seems to be stuck in a weird spot where he can't seem to use the old package anymore (likely due to automating the new configs eveywhere).
[08:40] <RikMills> sil2100: thank you for plasma SRU :)
[09:22] -queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (bionic-proposed) [19.0.8-0ubuntu0~18.04.1]
[09:26] <tkamppeter> seb128, WDYT about perhaps replace the NM SRU for Bionic by the original NM with selected patches?
[09:27] <seb128> tkamppeter, -1 from we, the new version includes security fixes and improvements customers asked for, we need to sort out the regressions and move forward
[09:44] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.8 => 20101020ubuntu543.9] (core)
[09:49] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.9]
[09:53] <sil2100> tkamppeter: hey! I would have to read up and get more context on this, but so far I must say that I do agree with infinity here - of course it all depends on how big of an impact the changes have, but for a big package like this it feels bad
[09:53] <sil2100> RikMills: yw!
[10:10] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1.1~18.04.1 => 19.0.8-0ubuntu0~18.04.1] (core, xorg)
[11:03] -queuebot:#ubuntu-release- Unapproved: python-libmaas (disco-proposed/universe) [0.6.0-0ubuntu1 => 0.6.0-0ubuntu2] (no packageset)
[11:37] -queuebot:#ubuntu-release- New binary: python-geneimpacts [amd64] (eoan-proposed/universe) [0.3.7-2] (no packageset)
[11:38] -queuebot:#ubuntu-release- New binary: python-os-faults [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-armon-go-proxyproto [amd64] (eoan-proposed/universe) [0.0~git20190211.68259f7-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-huandu-xstrings [amd64] (eoan-proposed/universe) [1.2.0-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-knqyf263-go-dep-parser [amd64] (eoan-proposed/universe) [0.0~git20190521.1ef8521-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-ryanuber-go-glob [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-sap-go-hdb [amd64] (eoan-proposed/universe) [0.14.1-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: python-xstatic-angular-ui-router [amd64] (eoan-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-badgerodon-collections [amd64] (eoan-proposed/universe) [0.0~git20130729.604e922-2] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-knqyf263-nested [amd64] (eoan-proposed/universe) [0.0.1-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-x86kernel-htmlcolor [amd64] (eoan-proposed/universe) [0.0~git20190529.c589f58-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-jesseduffield-go-getter [amd64] (eoan-proposed/universe) [0.0~git20180822.906e156-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [amd64] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: golang-github-ryszard-goskiplist [amd64] (eoan-proposed/universe) [0.0~git20150312.2dfbae5-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [amd64] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: r-cran-nozzle.r1 [amd64] (eoan-proposed/universe) [1.1-1+dfsg-1] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [i386] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: golang-github-schollz-closestmatch [amd64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-party [i386] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [i386] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-timereg [i386] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: rust-ascii [amd64] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-party [amd64] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-timereg [amd64] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [amd64] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[11:49] -queuebot:#ubuntu-release- New binary: r-cran-zeallot [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[11:50] -queuebot:#ubuntu-release- New binary: r-cran-clubsandwich [amd64] (eoan-proposed/universe) [0.3.5-1] (no packageset)
[11:50] -queuebot:#ubuntu-release- New binary: hepmc3 [amd64] (eoan-proposed/universe) [3.1.1-1] (no packageset)
[11:50] -queuebot:#ubuntu-release- New binary: r-cran-insight [amd64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[11:54] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [i386] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[11:54] -queuebot:#ubuntu-release- New binary: rust-ascii [i386] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[11:58] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [s390x] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[11:58] -queuebot:#ubuntu-release- New binary: r-cran-party [s390x] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[11:58] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [s390x] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[11:59] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [s390x] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[11:59] -queuebot:#ubuntu-release- New binary: rust-ascii [s390x] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[11:59] -queuebot:#ubuntu-release- New binary: r-cran-timereg [s390x] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[12:02] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [armhf] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[12:02] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [arm64] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[12:02] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [arm64] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[12:02] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [armhf] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-party [arm64] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [arm64] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: rust-ascii [arm64] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-party [armhf] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: rust-ascii [armhf] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [armhf] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-timereg [arm64] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[12:03] -queuebot:#ubuntu-release- New binary: r-cran-timereg [armhf] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[12:46] -queuebot:#ubuntu-release- New binary: r-cran-deoptim [ppc64el] (eoan-proposed/universe) [2.2-4-1] (no packageset)
[12:48] -queuebot:#ubuntu-release- New binary: r-cran-gbrd [ppc64el] (eoan-proposed/universe) [0.4-11-1] (no packageset)
[12:55] -queuebot:#ubuntu-release- New binary: r-cran-party [ppc64el] (eoan-proposed/universe) [1.3-3-1] (no packageset)
[12:57] -queuebot:#ubuntu-release- New binary: r-cran-spatialreg [ppc64el] (eoan-proposed/universe) [1.1-3+dfsg-1] (no packageset)
[12:59] -queuebot:#ubuntu-release- New binary: r-cran-timereg [ppc64el] (eoan-proposed/universe) [1.9.3-1] (no packageset)
[13:00] -queuebot:#ubuntu-release- New binary: rust-ascii [ppc64el] (eoan-proposed/universe) [0.9.2-1] (no packageset)
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-armon-go-proxyproto [amd64] (eoan-proposed) [0.0~git20190211.68259f7-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-huandu-xstrings [amd64] (eoan-proposed) [1.2.0-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-knqyf263-go-dep-parser [amd64] (eoan-proposed) [0.0~git20190521.1ef8521-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-ryanuber-go-glob [amd64] (eoan-proposed) [1.0.0-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-sap-go-hdb [amd64] (eoan-proposed) [0.14.1-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-x86kernel-htmlcolor [amd64] (eoan-proposed) [0.0~git20190529.c589f58-1]
[13:10] -queuebot:#ubuntu-release- New: accepted python-os-faults [amd64] (eoan-proposed) [0.2.1-1]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-clubsandwich [amd64] (eoan-proposed) [0.3.5-1]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [arm64] (eoan-proposed) [2.2-4-1]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [i386] (eoan-proposed) [2.2-4-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-badgerodon-collections [amd64] (eoan-proposed) [0.0~git20130729.604e922-2]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-knqyf263-nested [amd64] (eoan-proposed) [0.0.1-1]
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-schollz-closestmatch [amd64] (eoan-proposed) [2.1.0-1]
[13:10] -queuebot:#ubuntu-release- New: accepted python-xstatic-angular-ui-router [amd64] (eoan-proposed) [<IP_ADDRESS>-2]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [armhf] (eoan-proposed) [2.2-4-1]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [s390x] (eoan-proposed) [2.2-4-1]
[13:10] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-156.183] (core, kernel)
[13:10] -queuebot:#ubuntu-release- New: accepted golang-github-jesseduffield-go-getter [amd64] (eoan-proposed) [0.0~git20180822.906e156-1]
[13:10] -queuebot:#ubuntu-release- New: accepted python-geneimpacts [amd64] (eoan-proposed) [0.3.7-2]
[13:10] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [ppc64el] (eoan-proposed) [2.2-4-1]
[13:11] -queuebot:#ubuntu-release- New: accepted golang-github-ryszard-goskiplist [amd64] (eoan-proposed) [0.0~git20150312.2dfbae5-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [ppc64el] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-deoptim [amd64] (eoan-proposed) [2.2-4-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [amd64] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [armhf] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [s390x] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-nozzle.r1 [amd64] (eoan-proposed) [1.1-1+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [arm64] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [i386] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [s390x] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [arm64] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [i386] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [s390x] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [arm64] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-insight [amd64] (eoan-proposed) [0.4.0-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [armhf] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [amd64] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [ppc64el] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [arm64] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [i386] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [s390x] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-s3 [amd64] (eoan-proposed) [1.43.0-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [arm64] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-gbrd [i386] (eoan-proposed) [0.4-11-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [ppc64el] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [amd64] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [ppc64el] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [amd64] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [i386] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [s390x] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-party [amd64] (eoan-proposed) [1.3-3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-timereg [armhf] (eoan-proposed) [1.9.3-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [armhf] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-spatialreg [armhf] (eoan-proposed) [1.1-3+dfsg-1]
[13:11] -queuebot:#ubuntu-release- New: accepted rust-ascii [ppc64el] (eoan-proposed) [0.9.2-1]
[13:11] -queuebot:#ubuntu-release- New: accepted r-cran-zeallot [amd64] (eoan-proposed) [0.1.0-1]
[13:14] -queuebot:#ubuntu-release- Unapproved: chrony (disco-proposed/main) [3.4-1ubuntu1 => 3.4-1ubuntu1.1] (core)
[14:13] <seb128> tjaalton, bug #1836721 , I'm not sure it's the best plan of action to handle a SRU-in-update regression that let users wtihout a working graphical session with a new version update
[14:13] <seb128> imho we should fast track the regression fix through (and maybe delete the current version from bionic-updates meanwhile)
[14:13] <seb128> ^ SRU team, opinions?
[14:14] <tjaalton> 19.0.8 fixes at least two other regressions
[14:15] <tjaalton> and it sat on the queue for two weeks
[14:15] <seb128> k, then should we delete the current SRU meanwhile at least? sounds like it has a least 3 regressions so it would probably be best off updates?
[14:15] <seb128> what that on the queue?
[14:15] <tjaalton> 19.0.8
[14:16] <seb128> when we knew it was fixing regressions that happened in a LTS update?
[14:17] <tjaalton> no, these were new
[14:17] <tjaalton> I uploaded it when 19.0.2 was moved to updates
[14:17] <seb128> you should directly ping SRU-reviewer-of-duty when you have a priority upload
[14:17] <seb128> k
[14:17] <seb128> well anyway it sounds like we have an annoying -updates regression if some users are left without a session
[14:17] <seb128> so we should do something about it now
[14:18] <tjaalton> and I have uploaded 19.0.8 plus that revert for bionic, dropped the old upload
[14:18] <seb128> k
[14:18] <tjaalton> no-one complained that meson build dropped symbols from libosmesa, until it hit the lts
[14:18] <seb128> well let's see when some other SRU team members are around to discuss the best thing to do
[14:19] <tjaalton> I pinged RAOF but it was past his EOD already
[14:19] <seb128> yeah, non LTS don't have as many users...
[14:19] <tjaalton> I was off the last week
[14:19] <seb128> right
[14:20] <tjaalton> anyway, my wish was to push the last point release of the series (19.0.8) to proposed first before moving anything to updates, but I lost ;)
[14:20] <tjaalton> that wouldn't have caught the 32bit regression though
[14:22] <seb128> well, you could have verification-failed the previous SRU to block it
[14:22] <seb128> that's a wish easy to get :)
[14:22] <tjaalton> withouth knowing it had any regressions?
[14:22] <tjaalton> -h
[14:22] <tjaalton> there were none filed while it was in proposed for six weeks
[14:22] <seb128> "my wish was to push the last point release of the series (19.0.8) to proposed first before moving anything to updates"
[14:22] <seb128> maybe I misread that
[14:22] <tjaalton> yes, and I was overruled
[14:23] <seb128> ah ok
[14:23] <seb128> oh well
[14:23] <seb128> We are not going to change the past now, let's focus on what we do next
[14:24] <seb128> bdmurray, apw, vorlon, ^ any opinion on what to do there?
[14:24] <tjaalton> I can upload a fix with just the revert too, and fast-track that asap
[14:24] <seb128> let's wait if any of the pinged people is around and want to comment
[14:24] <tjaalton> and then let the new upstream fix virgl, libosmesa etc
[14:28] <tjaalton> I'll check back later, now afk for a bit
[14:29]  * apw tries to understand the question ..
[14:30] <apw> do we have fixes for the reported regressions?  if so if we coudl get an upload with just those on top; that would seems like a quick to test/release combo ?
[14:34] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-156.183]
[14:37] <seb128> apw, from what I understood the 32bits regression has an understood "restore a patch that got dropped too early" fix but what is the queue is also a stable version update fixing some other regressions
[14:38] <seb128> apw, also do you think we should remove/block the current version from -updates meanwhile?
[14:38] <apw> seb128, potentially, it is rather drastic to rip it out
[14:39] <apw> seb128, i assume we would have to put the older one back in the short term
[14:39] <apw> knowing that would not help people already affected
[14:39] <seb128> right, best way out is to land a fixed version asap
[14:39] <apw> tjaalton, of the three regressions is hte revert one the only one which causes headless-ness ?
[14:40] <apw> if so we should rip the current one out of propsoed, and throw the revert only in there
[14:43] <apw> test it and get it out asap
[15:02] -queuebot:#ubuntu-release- New binary: r-cran-bayestestr [amd64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
[15:02] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [amd64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:02] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [s390x] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:02] -queuebot:#ubuntu-release- New binary: r-cran-rdpack [amd64] (eoan-proposed/universe) [0.11-0-1] (no packageset)
[15:02] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [ppc64el] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [arm64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [i386] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:04] -queuebot:#ubuntu-release- New binary: r-cran-vctrs [armhf] (eoan-proposed/universe) [0.2.0-1] (no packageset)
[15:37] <tjaalton> apw: yes
[15:38] <tjaalton> there's no version in proposed atm
[15:38] <tjaalton> but on the queue for disco/bionic
[15:40] <apw> tjaalton, is that one useful for this, or something more significant
[15:41] <tjaalton> apw: it's a new point-release as well
[15:41] <tjaalton> bionic has 19.0.2 plus a patch from 19.0.4
[15:44] <tjaalton> I can upload 19.0.2-1ubuntu1.1~18.04.2 with just the revert
[15:45] <tjaalton> but would like to land 19.0.8 with better ice lake support soon
[15:45] <tjaalton> (icl support as a patch of several cherry-picks from upstream)
[15:50] <LocutusOfBorg> apw, hello, can you please hint ddcci-driver-linux/all/s390x? LP: #1837073
[15:52] <tjaalton> apw, seb128: I've uploaded mesa_19.0.2-1ubuntu1.1~18.04.2 to the queue
[15:52] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1.1~18.04.1 => 19.0.2-1ubuntu1.1~18.04.2] (core, xorg)
[15:53] <tjaalton> whichever is chosen, the other one should be dropped
[16:11]  * RAOF is just finishing two weeks of holiday, so pinging someone else will get a quicker response.
[16:19] <apw> tjaalton, i assume the safest is to take the newer one, then the moral equivalent of the previous one
[16:36] <tjaalton> RAOF: sorry, had no idea :)
[16:38] <tjaalton> apw: safest yes, it's a oneliner which was there for five months in the previous version
[16:48] -queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.4-0ubuntu18.04.1 => 3.28.4-0ubuntu18.04.2] (desktop-extra, ubuntu-desktop)
[16:53] <Laney> that is replacing something already in the queue
[17:16] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [amd64] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [s390x] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [i386] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: fonts-smc-gayathri [amd64] (eoan-proposed/none) [1.000-1] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [arm64] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:35] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [armhf] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:44] -queuebot:#ubuntu-release- New binary: rust-backtrace-sys [ppc64el] (eoan-proposed/universe) [0.1.30-1] (no packageset)
[17:48] <RikMills> Hi, could baloo please be removed fron Eoan. LP: #1837093
[17:53] <RikMills> oh, and remove kate4 as well LP: #1837096
[17:57] -queuebot:#ubuntu-release- Unapproved: spice-html5 (disco-proposed/universe) [0.1.7-3 => 0.1.7-3ubuntu<IP_ADDRESS>] (no packageset)
[17:58] -queuebot:#ubuntu-release- Unapproved: spice-html5 (bionic-proposed/universe) [0.1.7-2 => 0.1.7-2ubuntu1] (no packageset)
[18:34] -queuebot:#ubuntu-release- Unapproved: modemmanager (disco-proposed/main) [1.10.0-1 => 1.10.0-1ubuntu<IP_ADDRESS>] (desktop-core)
[18:34] -queuebot:#ubuntu-release- Unapproved: modemmanager (disco-proposed/main) [1.10.0-1 => 1.10.0-1ubuntu<IP_ADDRESS>] (desktop-core)
[18:57] <vorlon> teward: I'm not thrilled with the 'N/A' test case on LP: #1836366.  It's true that regressions might've been introduced the next time nginx was rebuild in bionic for some other reason, but that doesn't mean we shouldn't have tests to verify that nginx actually works with openssl following the rebuild
[19:22] <vorlon> RikMills: kate4 should be removed from Debian first (at least from unstable), currently there's only a wishlist bug (874932) and if I remove it now from eoan, a newer version will just be synced
[19:24] <ahasenack> teward: vorlon: maybe a "nmap -Pn --script ssl-enum-ciphers -p <port> <host>" run before and after and compare the results?
[19:24] <ahasenack> (for nginx)
[19:24] <vorlon> that would be a very shallow unit test
[19:24] <vorlon> maybe we're confident that the autopkgtests exercise nginx ssl enough to not need anything else
[19:24] <vorlon> but in that case the bug should say that
[19:25] <teward> vorlon: To do that I'd have to ship a dummy cert with the test
[19:25] <teward> the autopkgtest envs don't have enough entropy go generate the ssl-cert certs it seems
[19:25] <teward> AND it'd have to ship a custom configuration to do that
[19:25] <teward> this said
[19:25] <teward> we already KNOW TLS 1.3 works with the package
[19:25] <vorlon> and also that doesn't account for why the nginx autopkgtests pass fine but LP: #1833476 is reported
[19:25] <teward> this is simply to let us *control* it
[19:26] <vorlon> teward: ah right
[19:26] <teward> vorlon: I tried replicating those tests even on Eoan
[19:26] <vorlon> don't have enough entropy> where/when was that determination made? we have plenty of packages that are using entropy at autopkgtest time
[19:26] <teward> and an upstream from-source build
[19:26] <teward> it still failed
[19:26] <teward> vorlon: well the second consideration is
[19:26] <teward> we don't *ship* SSL enabled, we could write a test to do an SSL test but an nmap or a cipher enumeration wouldn't help
[19:27] <teward> TLS1.3 *works* it's the nonenabled tests that're the tricky part
[19:27] <teward> which according to upstream to let us control 1.3 and let it be 'disabled' or set ciphers it needs to build against 1.3
[19:27] <vorlon> I hope you can appreciate that none of this is giving me any more warm fuzzies than I already had
[19:27] <ahasenack> :)
[19:27] <teward> vorlon: i haven't had any warm fuzzies about this eiter
[19:27] <teward> either*
[19:27] <teward> especially when I learned that -securtiy doesn't ship 1.1.1 even
[19:28] <teward> which means that Bionic is 'diverged' in SSL support
[19:28] <teward> i know WHY security doesn't ship it
[19:28] <teward> but until it's shipped in -security we're in a diverged repository state
[19:28] <vorlon> it basically tells me that if there are any ssl-related regressions introduced as a result of a rebuild, we are confident that the autopkgtests /won't/ catch them because none of the autopkgtests test ssl
[19:28] <teward> vorlon: let me propose an alternative consideration:
[19:28] <teward> if TLS1.3 is "always on" currently
[19:28] <teward> as it is
[19:29] <teward> wouldn't the SSL 'regressions' have already been caught with 1.3 support?
[19:29] <teward> because CURRENTLY the case is 1.3 is already by-default enabled the way OpenSSL is in-built configured
[19:29] <teward> the tests we NEED to run are to make sure of the following:
[19:29] <teward> (1) that if we don't specify TLS1.3 in the ssl_protocols line that it doesn't enable TLS1.3
[19:30] <teward> (2) that if we do specify TLS1.3 in the ssl_protocols line but selectively choose TLS 1.3 ciphers in ssl_ciphers it honors the cipherstring we provide
[19:30] <teward> neither option tests for TLS1.3 *regressions* already introduced by OpenSSL which has been in the repos AND had TLS1.3 for nginx, etc. enabled out of the box already
[19:30] <teward> because CURRENTLY TLS1.3 is already enabled
[19:30] <teward> so testing to make sure TLS1.3 "works" is a moot point
[19:31] <teward> the moment anyone pulls a libssl update in it enables TLS1.3
[19:31] <ahasenack> we have had regressions in tls 1.2 in other packages due to openssl 1.1.1, fwiw
[19:31] <teward> postfix, nginx, apache2, etc.
[19:31] <teward> ahasenack: then I think we need to be clear on *what* exactly we're testing in terms of regressions
[19:31] <teward> ahasenack: vorlon: the nginx test suites I don't think were written against OpenSSL 1.1.1
[19:31] <teward> any failures there can be considered an openssl related one based on the SSL bits that've failed
[19:32] <teward> if I pull from *upstream* sources I get the same problem on an 18.04 env.
[19:32] <vorlon> teward: all of this assumes that the only changes in openssl 1.1.1 headers that nginx is sensitive to are the bits needed for controlling tls1.3 protocol / cipher negotiation.  Is there an informed basis for assuming that?
[19:33] <teward> vorlon: this is based on the trac bug I linked
[19:33] <teward> whereby it can't control TLS1.3 without relying on the relevant constants
[19:33] <teward> which it needs to build against to know the constants
[19:33] <vorlon> no
[19:33] <teward> vorlon: i have no other basis for the rest
[19:33] <teward> but i have a question
[19:34] <teward> which releases have had TLS1.3 by default in the development branches?
[19:34] <vorlon> that answers why it /does/ change behavior on a rebuild; it does not confirm that there are no /other/ behavior changes we need to pay attention to
[19:34] <teward> vorlon: then NACK this
[19:34] <teward> but consider we're going to have this problem when:
[19:35] <teward> (1) -security gets 1.1.1.
[19:35] <teward> (2) -security ends up pushing any changes that patch and rebuild against 1.1.1
[19:35] <vorlon> I am not arguing that this SRU should be thrown out
[19:35] <vorlon> I am arguing that the SRU needs to be more rigorous
[19:36] <teward> vorlon: not disagreeing, but also not in a place at the moment where I can dig for additional TLS1.3 headaches.
[19:36] <vorlon> and I would never accept an SRU that had "N/A" as the test case
[19:36]  * teward is currently busy dealing with dependency hell on an 16.04 box
[19:36] <vorlon> ok, understood
[19:36] <teward> vorlon: i think we ALSO need to be careful here going forward then
[19:36] <teward> and with respect to -security
[19:36] <teward> and though security has its own processes
[19:36] <teward> if this was a concern NOW
[19:36] <teward> this should have been an earlier concern during the OpenSSL SRU
[19:37] <teward> and the moment -security gets 1.1.1 pushed out via it
[19:37] <teward> you're going to be basically ahving these SRUs *anyways* but done by Security next time they push a patch for nginx
[19:37] <teward> so i think there's a broader problem and discussion that needs to happen
[19:37] <teward> related to this
[19:37] <teward> not just because of the SRU
[19:37] <teward> but because of OpenSSL being the evil it is regardless
[19:38] <teward> ... not to mention we're already 'SSL libraries diverged' wrt Security and Updates
[19:38] <teward> ... qhixh arill ro rhia sY IEEIRRwa mw
[19:38] <teward> which still to this day irritates me*
[19:38] <teward> *kicks keyboard out into the river*
[19:41] <vorlon> I don't understand why you're concerned about updates vs security being "diverged"
[19:41] <vorlon> every package introduced in an updates pocket needs to take care of its own versioned dependencies to make sure that it pulls in any other deps it needs
[19:41] <vorlon> SRUs must not break as a result of partial upgrades
[19:46] <RikMills> vorlon: fair enough on kate4. I thought I saw somewhere that manually removed things would not autosync again unless synced deliberately again. I must misremember or have misunderstood.
[19:47] <vorlon> RikMills: that may have been a bug that I fixed in recent memory ;)
[19:47] <RikMills> aha. that makes sense!
[20:19] <ddstreet> vorlon if you have a sec, me and kenvandine collided on our uploads of modemmanager to disco...they are identical, so if you could just reject one of them, it shouldn't matter which
[20:20] -queuebot:#ubuntu-release- New binary: swift [amd64] (eoan-proposed/universe) [2.22.0~b1~git2019071110.e62f07d98-0ubuntu3] (openstack)
[20:22] <ddstreet> wow, looking at the backscroll, the upload msgs from queuebot are 1 second apart, that's some crazy coincidence in timing on our uploads
[20:25] <vorlon> ddstreet: there is some batching involved in the messages :)
[20:25] <vorlon> anyway, rejected the second of the uploads, whoever's that was
[20:25] -queuebot:#ubuntu-release- Unapproved: rejected modemmanager [source] (disco-proposed) [1.10.0-1ubuntu<IP_ADDRESS>]
[20:30] <ddstreet> vorlon awesome thanks!
[20:33] <kenvandine> vorlon: thanks
[21:12] <doko> dpkg-deb: error: failed to read archive 'zfs-dkms_*.deb': No such file or directory
[21:12] <doko> make: *** [debian/rules.d/2-binary-arch.mk:220: install-generic] Error 2
[21:13] <doko> sforshee, apw: ^^^ linux autopkg test regression
[21:14] <sforshee> doko: probably means a new zfs landed, though I thought apw had made that so it would download them from the librarian if removed from the archive
[21:15] <sforshee> hmm, no that does not seem to be the case
[21:15] <vorlon> zfs-dkms 0.8.1-1ubuntu5 is stale, current version is 0.8.1-1ubuntu7
[21:15] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1015.16] (no packageset)
[21:16] <apw> sforshee, hmmm, no we expected to avoid that by by copying the old versions into the PPA for builds; but adt is a wrinkle
[21:16] <apw> sforshee, as they are not in the PPA, sigh.
[21:17] <vorlon> what does the ppa have to do with it?  this failure is visible on http://autopkgtest.ubuntu.com/packages/l/linux/eoan/amd64 and shows downloads from ftpmaster.internal
[21:19] <sforshee> I think that was wrt our builds, and the problem of autopkgtest build tests was missed
[21:29] <vorlon> ah
[21:30] <apw> i suspect a rebuild should not build the dkms packages ... in dt
[21:30] <apw> adt
[21:50] -queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (bionic-proposed) [3.28.4-0ubuntu18.04.2]
[22:26] -queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.178.3 => 1.178.4] (core, kernel)
[22:28] -queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.9 => 1.173.10] (core, kernel)
[23:15] -queuebot:#ubuntu-release- New binary: rust-assert-cli [amd64] (eoan-proposed/universe) [0.6.3-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-bumpalo [amd64] (eoan-proposed/universe) [2.5.0-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-core-arch [i386] (eoan-proposed/universe) [0.1.5-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-assert-cli [i386] (eoan-proposed/universe) [0.6.3-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-data-encoding-macro-internal [amd64] (eoan-proposed/universe) [0.1.7-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-caps [amd64] (eoan-proposed/universe) [0.3.2-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: baloo [amd64] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-caps [i386] (eoan-proposed/universe) [0.3.2-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-darling-macro [i386] (eoan-proposed/universe) [0.9.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-dirs-sys [amd64] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-doc-comment [amd64] (eoan-proposed/universe) [0.3.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-getrandom [amd64] (eoan-proposed/universe) [0.1.6-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-gettext-rs [amd64] (eoan-proposed/universe) [0.4.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-http-body [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-ipnetwork [amd64] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-bumpalo [i386] (eoan-proposed/universe) [2.5.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-data-encoding-macro-internal [i386] (eoan-proposed/universe) [0.1.7-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-doc-comment [i386] (eoan-proposed/universe) [0.3.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-gettext-rs [i386] (eoan-proposed/universe) [0.4.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [amd64] (eoan-proposed/universe) [0.2.5-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-darling-macro [amd64] (eoan-proposed/universe) [0.9.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-getrandom [i386] (eoan-proposed/universe) [0.1.6-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-dirs-sys [i386] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-ipconfig [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-diesel [amd64] (eoan-proposed/universe) [1.4.2-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-ipconfig [i386] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-nom-4 [i386] (eoan-proposed/universe) [4.2.3-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-http-body [i386] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-stackvector [amd64] (eoan-proposed/universe) [1.0.6-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-md5-asm [amd64] (eoan-proposed/universe) [0.4.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: baloo [i386] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-md5-asm [i386] (eoan-proposed/universe) [0.4.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-quick-xml [amd64] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-rand-core-0.3 [i386] (eoan-proposed/universe) [0.3.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-core-arch [amd64] (eoan-proposed/universe) [0.1.5-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-rand-core-0.3 [amd64] (eoan-proposed/universe) [0.3.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [i386] (eoan-proposed/universe) [0.2.5-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-static-assertions [amd64] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-assert-cli [s390x] (eoan-proposed/universe) [0.6.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-ipnetwork [i386] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-quick-xml [i386] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-static-assertions [i386] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-caps [s390x] (eoan-proposed/universe) [0.3.2-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-stackvector [i386] (eoan-proposed/universe) [1.0.6-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-nom-4 [amd64] (eoan-proposed/universe) [4.2.3-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: baloo [s390x] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-bumpalo [s390x] (eoan-proposed/universe) [2.5.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-darling-macro [s390x] (eoan-proposed/universe) [0.9.0-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-core-arch [s390x] (eoan-proposed/universe) [0.1.5-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: rust-diesel [i386] (eoan-proposed/universe) [1.4.2-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: rust-data-encoding-macro-internal [s390x] (eoan-proposed/universe) [0.1.7-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-dirs-sys [s390x] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-diesel [s390x] (eoan-proposed/universe) [1.4.2-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-getrandom [s390x] (eoan-proposed/universe) [0.1.6-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-http-body [s390x] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-doc-comment [s390x] (eoan-proposed/universe) [0.3.1-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-gettext-rs [s390x] (eoan-proposed/universe) [0.4.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-ipconfig [s390x] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-ipnetwork [s390x] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-nom-4 [s390x] (eoan-proposed/universe) [4.2.3-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-stackvector [s390x] (eoan-proposed/universe) [1.0.6-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [s390x] (eoan-proposed/universe) [0.2.5-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-quick-xml [s390x] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-static-assertions [s390x] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: rust-rand-core-0.3 [s390x] (eoan-proposed/universe) [0.3.0-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: chicken [amd64] (eoan-proposed/universe) [5.1.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: chicken [i386] (eoan-proposed/universe) [5.1.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-assert-cli [arm64] (eoan-proposed/universe) [0.6.3-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-bumpalo [arm64] (eoan-proposed/universe) [2.5.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-caps [armhf] (eoan-proposed/universe) [0.3.2-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-assert-cli [armhf] (eoan-proposed/universe) [0.6.3-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: rust-caps [arm64] (eoan-proposed/universe) [0.3.2-1] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: rust-bumpalo [armhf] (eoan-proposed/universe) [2.5.0-1] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: rust-core-arch [armhf] (eoan-proposed/universe) [0.1.5-1] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: rust-core-arch [arm64] (eoan-proposed/universe) [0.1.5-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-darling-macro [arm64] (eoan-proposed/universe) [0.9.0-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-data-encoding-macro-internal [arm64] (eoan-proposed/universe) [0.1.7-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-dirs-sys [arm64] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-doc-comment [arm64] (eoan-proposed/universe) [0.3.1-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-darling-macro [armhf] (eoan-proposed/universe) [0.9.0-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-dirs-sys [armhf] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: rust-data-encoding-macro-internal [armhf] (eoan-proposed/universe) [0.1.7-1] (no packageset)
[23:45] -queuebot:#ubuntu-release- New binary: rust-doc-comment [armhf] (eoan-proposed/universe) [0.3.1-1] (no packageset)
[23:45] -queuebot:#ubuntu-release- New binary: rust-getrandom [arm64] (eoan-proposed/universe) [0.1.6-1] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: baloo [arm64] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: chicken [s390x] (eoan-proposed/universe) [5.1.0-1] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: baloo [armhf] (eoan-proposed/universe) [4:4.14.3-3] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: rust-getrandom [armhf] (eoan-proposed/universe) [0.1.6-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-gettext-rs [arm64] (eoan-proposed/universe) [0.4.1-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-http-body [arm64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-ipconfig [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-ipnetwork [arm64] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-gettext-rs [armhf] (eoan-proposed/universe) [0.4.1-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-ipconfig [armhf] (eoan-proposed/universe) [0.2.1-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-http-body [armhf] (eoan-proposed/universe) [0.1.0-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- New binary: rust-ipnetwork [armhf] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:50] -queuebot:#ubuntu-release- New binary: rust-diesel [armhf] (eoan-proposed/universe) [1.4.2-1] (no packageset)
[23:50] -queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [arm64] (eoan-proposed/universe) [0.2.5-1] (no packageset)
[23:50] -queuebot:#ubuntu-release- New binary: rust-nom-4 [armhf] (eoan-proposed/universe) [4.2.3-1] (no packageset)
[23:50] -queuebot:#ubuntu-release- New binary: rust-ppv-lite86 [armhf] (eoan-proposed/universe) [0.2.5-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: rust-diesel [arm64] (eoan-proposed/universe) [1.4.2-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: rust-nom-4 [arm64] (eoan-proposed/universe) [4.2.3-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: rust-rand-core-0.3 [arm64] (eoan-proposed/universe) [0.3.0-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: rust-stackvector [arm64] (eoan-proposed/universe) [1.0.6-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: rust-static-assertions [arm64] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: rust-rand-core-0.3 [armhf] (eoan-proposed/universe) [0.3.0-1] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: rust-stackvector [armhf] (eoan-proposed/universe) [1.0.6-1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: rust-quick-xml [arm64] (eoan-proposed/universe) [0.14.0-1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: rust-static-assertions [armhf] (eoan-proposed/universe) [0.3.3-1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: rust-quick-xml [armhf] (eoan-proposed/universe) [0.14.0-1] (no packageset)


[14:44] <czajkowski> mhall119: ping :)
[14:44] <mhall119> pong
[14:45] <thecolonyroom> czajkowski: Hullo.
[14:45] <czajkowski> thecolonyroom: ahh didnt recognise the nick
[14:45] <steveedwards> czajkowski: Hullo.
[14:45] <czajkowski> ta da
[14:45] <steveedwards> czajkowski: Sorry. My alter ego.
[14:45] <mhall119> cjohnston, meet steveedwards
[14:45] <cjohnston> o/
[14:45] <czajkowski> so basiccally just trying to work out why we have 2 projects with the same name and wondering can they not be under one project
[14:45] <steveedwards> cjohnston: Don't hate me.
[14:45] <czajkowski> or is there something I'm missing here
[14:46] <cjohnston> theres alot that we are missing
[14:46] <cjohnston> but i agree
[14:46] <mhall119> so cjohnston has already given maintainership of uds-project to ~uds-organizers, and I've already pushed steveedwards's code there
[14:46] <cjohnston> i dont care which it is, just pick one and point the other to it if possible
[14:47] <mhall119> we also already have bugs files against uds-project, though they're probably not relevant after the theme change
[14:47] <cjohnston> mhall119: ive gone through them
[14:47] <cjohnston> 2.5 still are
[14:47] <mhall119> ok
[14:47] <czajkowski> at prsent steveedwards project that was registed is inactive so just wondering can he use the project that currenly cjohnston ownes for the summit work
[14:48] <mhall119> sorry, but just to clarify, this is for uds.u.c work, not summit.u.c work
[14:48] <cjohnston> steveedwards: if possible, whatever we choose, can we put a link in the footer as to where to file a bug for the site so that people dont file against ubuntu-website
[14:48] <cjohnston> summit work need to go under the summit project
[14:48] <steveedwards> cjohnston: Will do. I can add that.
[14:48] <mhall119> summit *code* work anyway, we still have some content on there that is UDS-specific (but we're working on removing that)
[14:49] <cjohnston> theme work needs to go against https://launchpad.net/ubuntu-community-webthemes
[14:49] <mhall119> cjohnston: not for uds.u.c
[14:49] <cjohnston> for summit
[14:49] <mhall119> the django one, yes
[14:50] <cjohnston> if everything wasnt hard coded into uds.u.c branch, the branch could be pushed there and all sites could be updated to the new guidelines
[14:50] <cjohnston> but oh well
[14:51] <mhall119> so is everybody okay with using uds-project?
[14:51] <cjohnston> +0 just pick one
[14:51] <mhall119> I'm +1, simply because it's all there already
[14:51] <steveedwards> mhall119: Sounds good.
[14:52] <mhall119> steveedwards: we can add you to ~uds-organizers if you think we need to, so you can push to the branch on that project
[14:52] <steveedwards> mhall119: That would be great. Thanks.
[14:52] <mhall119> otherwise you can just push under your name and make a merge proposal to that branch
[14:54] <czajkowski> great we're sorted so
[14:54] <czajkowski> https://launchpad.net/uds-project  is the one to live right ?
[14:54] <mhall119> right
[14:54] <cjohnston> yes
[14:56] <mhall119> thanks czajkowski, steveedwards, cjohnston
[14:56] <czajkowski> lovely jubbly
[14:56] <czajkowski> sorted so
[14:56]  * czajkowski goes back to reviewing more projects
[14:56] <czajkowski> toodles
[14:56] <steveedwards> mhall119: Cheers.
[14:57] <cjohnston> steveedwards so what are the thoughts from the design team on making the user experience a decent one going between uds.u.c and summit.u.c
[14:57] <cjohnston> it was ok at best in prior to the update
[15:02] <niceguyjames> cjohnston: the issue with the previous uds.u.com and summit.u.com was primarily that the sites tried to mirror each other to make it less obvious you were jumping between different websites, but because they were out of sync that didn't really work.
[15:02] <cjohnston> right..
[15:02] <niceguyjames> cjohnston: so during the UX, the top-level navigation links to summit were reimagined as call-to-actions to go off-site.
[15:03] <niceguyjames> cjohnston: hence them being removed from the top-level navigation which should be reserved for navigation in the current site.
[15:03] <cjohnston> it doesnt make sense to me that there is only 1 link that i find to the schedule
[15:04] <niceguyjames> cjohnston: equally it doesn't make sense that an empty page is promoted before it's populated
[15:04] <cjohnston> I've been against having two seperate sites from day one.. the work should be done to make it one site IMO
[15:04] <niceguyjames> cjohnston: so it may be that it gets dropped into the nav when it does?
[15:04] <niceguyjames> cjohnston: +1
[15:04] <steveedwards> cjohnston: We'd love to help with that.
[15:04] <steveedwards> cjohnston: If we can find the time.
[15:04] <cjohnston> bzr branch lp:summit
[15:04] <cjohnston> ;-)
[15:04] <niceguyjames> cjohnston: the above is just so you know where the UX decision came from.
[15:04] <steveedwards> cjohnston: :)
[15:04] <cjohnston> ty niceguyjames
[15:05] <cjohnston> hardcoding would have been just as easy with both
[15:05] <cjohnston> If we are going to hardcode, I could easily add it all to summit, then just point uds.u.c to summit
[15:06] <cjohnston> ill be back in 5 minutes
[15:15] <cjohnston> im back
[15:25] <cjohnston> svwilliams: ping
[15:26] <svwilliams> Hey cjohnston
[15:26] <cjohnston> have you had a change to work on your branches anymore?
[15:28] <svwilliams> I worked on them more sunday, but not yesterday
[15:28] <cjohnston> ok
[15:28] <svwilliams> I'll have time tonight to straighten out the position: relative issue
[15:29] <cjohnston> cool.. ty
[15:29] <svwilliams> thats the only thing left, removing the % and specifying the px fixed the ltp issue
[15:29] <svwilliams> :-)
[15:30] <cjohnston> sweet
[15:30] <cjohnston> do you know what the problem is with the position relative issue?
[15:30] <cjohnston> or do you need to mess around with it
[15:42] <svwilliams> I need to mess around with it
[15:42] <svwilliams> cjohnston, (sorry for the delays in responses)
[15:42] <cjohnston> np
[15:43] <svwilliams> I think I can put them inside a block that is position relative, but it seems like if they themselves are position relative it ignores that when resizing the page
[15:43] <svwilliams> due to the display:inline-block
[15:43] <svwilliams> though now that I'm typing it
[15:44] <svwilliams> I'm wondering if my margins are throwing it off
[15:44] <svwilliams> I have plenty of time to play with it tonight
[15:44] <svwilliams> I'll let you know
[15:44] <cjohnston> ok
[16:41] <cjohnston> svwilliams: this is really odd.. I'm seeing doubles and dont know why.. I've stared adding links in your side bar.. but i have two side bars
[16:42] <cjohnston> and the side-bar needs to wrap text
[16:45] <cjohnston> svwilliams: mhall119 http://ubuntuone.com/5sgMhDL72yeJDnjBXaPVXv
[16:46] <mhall119> Could not locate object
[16:48] <cjohnston> mhall119: svwilliams http://ubuntuone.com/6sEitrdTgdTwyTYXlSHTWz
[18:05] <daker> mhall119, can you help with a small question ?
[18:05] <mhall119> daker: sure
[18:06] <daker> mhall119, i want to select all the events that are in still happening
[18:07] <mhall119> daker: from within Django, or from the JSON API?
[18:07] <daker> django
[18:07] <daker> ORM
[18:07] <daker> FYI: each events has a start/end date
[18:07] <daker> event*
[18:09] <daker> imagine you have two events happening today and i need to get them just by passing the date
[18:10] <daker> mhall119, ^
[18:12] <mhall119> daker: we have that in the object managers already I think
[18:14] <daker> mhall119, no i think you didn't understand
[18:14] <daker> imagine you have event 1 from 10-03-2012 to 13-03-2012
[18:15] <daker> and event 2 from 12-03-2012 to 13-03-2012
[18:15] <daker> and i want just by passing the 12-03-2012 to the query to get the list of the two events
[18:17] <svwilliams> cjohnston, that's odd ... it looks like the block that you are building links into exists in more than one place ... did I leave a trailing one in from all of our testing
[18:17] <svwilliams> last friday
[18:20] <mhall119> daker: ah, I think I understand
[18:21] <mhall119> daker: something like TeamEvent.objects.filter(date_end__gte=your_date_variable)
[18:21] <mhall119> that will give you any date that *end* after the given variable date
[18:22] <mhall119> daker: look at next_events in TeamEventsManager
[18:22] <mhall119> /events/models.py line 105
[18:24] <daker> ok
[18:25] <cjohnston> svwilliams: i dont think so
[18:35] <cprofitt> hey cjohnston
[18:35] <cjohnston> hey
[18:36] <cprofitt> bobweaver is his irc nick
[18:36] <cjohnston> ok
[18:37] <cprofitt> he is not on now.
[18:37] <cjohnston> ok
[18:37] <cprofitt> but if you see him... you know who he is
[18:38] <cjohnston> ok.. cool
[18:38] <cjohnston> ty
[18:39] <cprofitt> I will likely have to work on bzr with him...
[18:39] <cjohnston> ok
[18:40] <cjohnston> thats easy enough
[18:40] <cjohnston> groundcontrol may be something to look at too
[18:40] <cprofitt> yeah... that is
[18:41] <cprofitt> I will try to ensure that he gets in contact with you.
[18:41] <cjohnston> awesome.. ty
[18:44] <cprofitt> mhall119: I just saw cjohnston in the other channel and mentioned it to him
[18:44] <cprofitt> but yes, we need to get bob in here
[21:59] <cjohnston> daker: https://code.launchpad.net/~chrisjohnston/loco-team-portal/bzr-req-update


[05:15] <darkxst> octoquad, please use recommends for the seed changes i.e. * (package) format
[06:44] <octoquad> darkxst, done.
[06:45] <octoquad> darkxst, could you let me know what the difference is? I couldn't find any documentation around the difference between package-name and (package-name)
[06:45] <darkxst> octoquad, recommends can be removed without breaking ubuntu-gnome-desktop
[06:46] <darkxst> so only use non-bracketed ones for hard-deps
[06:47] <octoquad> thanks
[06:48] <darkxst> did you test that eog becomes default image viewer (by context menus)?
[06:49] <darkxst> octoquad, and there maybe some gsettings overrides that add shotwell to the shell panel?
[06:51] <darkxst> also feel free to update the meta package ;) just grab ubuntu-gnome-meta, run the update script and post a debdiff somewhere
[06:56] <darkxst> (after I merge it, of course)
[06:58] <darkxst> octoquad, done
[07:20] <darkxst> octoquad, and I didnt check eog etc, but we have a week to things like that
[07:24] <darkxst> s/fix/things/ I'm a bit scattered after not having a cigarettes all week ;(
[13:08] <LinDol> hi all :)
[13:08] <LinDol> good evening
[13:39] <LinDol> When I install 15.04, How can I check gnome version which i have on my laptop in terminal?
[13:41] <LinDol> $ gnome-shell --version?
[13:44] <mgedmin> IIRC 15.04 contains a bit of a mish-mash of versions; but most of the components are 3.14
[13:47] <LinDol> mgedmin, thank you :)
[13:50] <mgedmin> (in fact the only ones I can see that aren't at 3.14 are baobab, gedit, gnome-contacts, vino, yelp)
[13:50] <mgedmin> (ok, those are the ones that have their corresponding versions at 3.14 in the ppa for vivid)
[14:07] <LinDol> oh did you use PPA?


[06:21] <Bashing-om> Gdoc: Caught up - A few comments remain outstanding.
[22:27] -SwissBot:#ubuntu-news- ::Planet:: Alan Pope: Chromium on Linux @ https://popey.com/blog/2021/02/chromium-on-linux/
[22:27] <Bashing-om> UWN: Issue 669 up for review and final edits: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue669 :D
[22:29] <guiverc> !!??what??!!   I didn't realize it was monday already ; maybe I need to switch from tea to coffee...
[22:32] <guiverc> ack anyway, will look when I'm a little more aware/alert maybe
[22:32] <guiverc> & thanks Bashing-om
[22:39] <Bashing-om> guiverc: Lots of interruptions - loss of focus -  in the process; pay attention to the proof reading :P
[22:41] <guiverc> ack


[03:49] <Cheri703> AlanBell: that would be great. I think having perhaps a sub-category for career days. like the normal ones are "about folks' careers" and then have a "what companies are looking for" category
[03:57] <Cheri703> or perhaps "how to prepare/hunt for a new job"
[18:43] <AlanBell> something like that, yes. Maybe "how recruitment works" Cheri703


 Just in case any of you haven't already seen this or claimed it (There's only 3 hours left) https://www.humblebundle.com/store/company-of-heroes-2?hmb_source=companyofheroes2_freegame&hmb_medium=banner
 Dollar store product.


[01:21] <dmbQs> Need some help reconfiguring Grub after restoring to a new VM. Can anyone help me with the instructions here: I restored a Tar backup to a new VM. Now I need to reconfigure Grub. Need some help with the commands found here: https://help.ubuntu.com/community/BackupYourSystem/TAR. Would anyone mind helping??
[02:47] <delinquentme> sshfs is supposed to create the mount dir on execution right?
[02:47] <delinquentme> im getting a complaint from bash: fuse: bad mount point `/home/thrive/www': No such file or directory
[02:48] <sarnold> delinquentme: no, a directory needs to exist somewhere before you can mount a filesystem on it
[02:51] <delinquentme> sarnold, much apreesh
[04:35] <babak_>  question mod_security comes on 12.04 as 2.6.3 and the current version is 2.7.5 is it ok to stay with 2.6.3 ? I though we where supposed to use LTS for things like this.
[07:49] <rbasak> Daviey: I'm looking at http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html. It looked truncated; then I realised that it's being updated as I read it. What do you think about changing the cronjob to write to a temporary file and then renaming in, so we get an atomic update? Not worth it for the one time I hit the problem? :)
[08:30] <Daviey> rbasak: Yeah, i can do that.
[08:31] <Daviey> rbasak: if you saw this crontab... you'd be wishing we had wrappers :)
[08:31] <Daviey> (busy)
[08:31] <rbasak> :)
[08:36] <Daviey> rbasak: should be good now
[08:36] <rbasak> Daviey: thanks!
[09:01] <Daviey> zul: hey, can you check if kombu can be sync'd? kombu 2.5.12-0ubuntu2 -> 2.5.12-1
[09:02] <Daviey> jamespage: looks like gdisk can be sync'd?
[09:12] <jamespage> Daviey, probably
[11:37] <yolanda> zul, trying to build ceilometer for the tests, but having a lot of RuntimeError: No 'ceilometer.storage' driver found, looking for ''
[11:43] <zul> yolanda:  yeah ill have a look at it today
[11:43] <yolanda> i was trying to build ceilometer to run the tests, do you prefer that i wait for it?
[11:47] <zul> yolanda:  yeah
[11:47] <yolanda> ok
[11:47] <yolanda> zul, please let me know when it's fixed so i can add my tests
[11:52] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/python-novaclient/babel/+merge/182367
[12:04] <wsk233> hello i need to setup a ftp server for some internal use the only thing i need to be able to configure is chroot which is the most easy ftp server to set this up
[12:05] <greppy> wsk233: I've always liked proftpd if I *really* had to setup a plain ftp server, I much prefer using sftp.
[12:05] <wsk233> ofcrouse i understand
[12:08] <zul> jamespage: https://code.launchpad.net/~zulcss/python-neutronclient/deps-refresh/+merge/182372
[12:16] <zul> Daviey:  should be ok to sync
[12:40] <crass> I'd like to run the server iso from an iso on a filesystem on a usb stick. Is this possible?
[12:41] <crass> this can be done using the loopback.cfg with the desktop iso, but server's loopback.cfg just has an entry for testing the iso, not actually running it
[12:57] <Monotoko> what should I be allowing through the firewall to stop a DNS lookup failure when doing a proxypass?
[12:58] <Monotoko> outgoing is allowed... I don't see the problem
[14:25] <hallyn_> zul: if/when my laptop(s) overheat can you step in for a few mins in the virt stack talk (in 1.5 hrs)
[14:26] <zul> hallyn_:  sure
[14:26] <hallyn_> thx
[14:28] <zul> hallyn_:  if my network connection doesnt crap out on me :)
[14:28] <hallyn_> sbux?
[14:28] <zul> hallyn_:  rural internet
[14:46] <disposable> i have a vlan interface on top of bond(active-backup) interface on top of 2 physical interfaces. I recently upgraded from 10.04 to 12.04 and suddenly I see a lot of dropped packets on my bond0 and the inactive underlying eth interface. same problem on 3.2, 3.5, 3.8, 3.9 kernels. it seems about a 1/5 of received packets are dropped. my cards use igb module (intel 82576). has anybody come across this?
[14:47] <disposable> i've tried juniper and procurve switches
[14:54] <zul> roaksoax: mind +1ing https://code.launchpad.net/~zulcss/python-novaclient/babel/+merge/182367 and https://code.launchpad.net/~zulcss/python-neutronclient/deps-refresh/+merge/182372 please
[14:54] <zul> yolanda:  ceilometer should be fine now
[14:54] <roaksoax> zul: done
[14:55] <yolanda> zul, thx
[14:55] <zul> thanks
[14:55] <patdk-wk> disposable, works great for me
[15:03] <disposable> patdk-wk: if you type ifconfig bond0, do you not see any dropped packets?
[15:08] <patdk-wk> oh, that, your suppost to see that
[15:08] <patdk-wk> every single multicast/broadcast packet it sends out one nic, will be dropped when it's received on the other nic
[15:10] <disposable> patdk-wk: i'd understand seeing dropped packets on the ethX device that isn't the current slave, but not on bond0
[15:11] <disposable> patdk-wk: on your bond0 interface is the number of dropped packets also around 1/5 of all received?
[15:20] <patdk-wk> 1/230th
[15:20] <disposable> patdk-wk: thanks.
[15:20] <patdk-wk> it exactly matchs the received and dropped count of my backup nic
[15:21] <disposable> patdk-wk: yes, same here.
[15:21] <patdk-wk> so that easily explains it
[15:21] <patdk-wk> it's a backup, anything received isn't suppost to be, and is a dup
[15:21] <patdk-wk> and is dropped
[15:21] <patdk-wk> as I said
[15:21] <disposable> patdk-wk: weird thing is that every couple of reboots i get 0 dropped packets.
[15:21] <disposable> by couple i mean >20
[15:28] <Shadowandlight> anyone have ideas on how to deploy a cloned copy of Ubuntu faster?  I need to change passwords (mysql and linux) and settings faster then doing everything by hand... if possible http://askubuntu.com/questions/337503/easiest-solution-to-modifying-linux-mysql-passwords-and-other-settings-after-c
[15:30] <disposable> Shadowandlight: i'd suggest chef/puppet/cfengine but that may be too much overhead if you're just changing a few things. in your case i'd simply start clusterssh, log into all machines at once and just click into individual windows to enter different passwords.
[15:34] <Shadowandlight> do the config tools run locally or do they need to be web based like webmind / cloudmin?
[15:52] <thebwt> are there any reccomendations for a php ppa? I'm trying to get newer version stuff for a 12.04 server
[15:55] <arosales> jamespage, smoser is there goingto be a Server IRC meeting today since there is 1308 vUDS?
[15:56] <jamespage> arosales, nope
[15:56] <jamespage> can't do sessions and irc meeting at the same time
[15:57] <arosales> jamespage, ok
[15:57] <arosales> jamespage, I thought so just wanted to confirm
[16:00] <smoser> arosales, i say no
[16:01] <arosales> smoser, ack thanks. I'll put a reminder in ubuntu-meeting since we didn't get a mail out to the list
[16:01] <arosales> or I may have missed it if it did go out :-)
[16:23] <disposable> Shadowandlight: unfortunately, chef/puppet require installation of ruby and lots of additional software. cfengine is smaller and faster but with the steepest learning curve. for clusterssh, you just need ssh.
[16:33] <rbasak> disposable: is there a real world problem with pulling in all this "overhead"? apt-get does it automatically for you, and it doesn't use a significant amount of space on an installed server node. I also don't like the ruby dependency, but I don't think it'd affect my recommendiation to look into chef/puppet over anything else.
[16:54] <wedgwood> Is there a good way to set environment variables when calling lxc-attach? I need something like --clear-env plus a few extra values.
[16:58] <wedgwood> hallyn_: If I might trouble you, any ideas? ^
[16:58] <rbasak> wedgwood: I call env after lxc-attach. lxc-attach --clear-env ... -- env foo=bar my_command
[16:59] <wedgwood> rbasak: ah, I'll give that a shot. there are ~a dozen things to set in some cases, but I still think that could be manageable
[17:25] <smoser> ok. i have a stupid question.
[17:26] <smoser> i wnat to make 'cloud-utils' package basically only depend on another package now.
[17:26] <smoser> transitional if you will.
[17:28] <hallyn_> wedgwood: had to look back at the changelog;  right now rbasak's is the best option.  There is code for 'extra_keep_env', but it's not yet hooked up to the cli
[17:29] <hallyn_> smoser: what is your q?  (does it belong in -devel? :)
[17:29] <smoser> i think its never mind.
[17:30] <hallyn_> ok :)
[17:30] <roaksoax> smoser: yeah that would work
[17:30] <roaksoax> smoser: cloud-utils would become a transitional package indeed
[17:31] <roaksoax> smoser: or you could make it a meta-package
[17:31] <smoser> whats a meta-package specifically ? a task?
[17:31] <roaksoax> smoser: no, a metapackage are packages that simply depend on others and do not install anything
[17:31] <smoser> example?
[17:32] <roaksoax> smoser: for example, 'maas' is a metapackage that installs 'maas-region-controller', 'maas-cluster-controller'
[17:32] <smoser> perfect. thank you.
[17:33] <roaksoax> smoser: now, transitional packages are usually needed for upgrades
[18:11] <gartral> hey all, I've been looking into Landscape to help manage a private server and I was wondering if I install the landscape-client package, and decide later that I don't want it, will it break the server if I remove it?
[18:12] <sarnold> gartral: I had no trouble on my machine removing the landscape client after playing with it for a few weeks
[18:13] <gartral> sarnold: and exactly how much IS the Landscape service, I'm quite dismayed and put off by Cononical's secrecy on that subject
[18:14] <sarnold> gartral: heh, I'm sorry I can't actually fix that :) I had a free account on account of being an employee...
[18:17] <sarnold> gartral: hey! this looks like it. :) http://www.canonical.com/enterprise-services/ubuntu-advantage/server
[18:18] <gartral> sarnold: 320 USD *PER SERVER*?! holey crap! never mind that!
[18:19] <sarnold> gartral: yes that seems a bit steep if landscape is the only part of the plan you want
[18:21] <gartral> sarnold: yea.. I was thinking it would be like $10-20 US/year for a single server.. $320 is far, far *far* too rich for my blood
[18:23] <sarnold> gartral: yes, it looks like it was priced to be competitive against rhel and sles: https://www.redhat.com/apps/store/server/ https://www.suse.com/products/server/how-to-buy/
[18:25] <gartral> sarnold: yea.. I'd rather just run my single server through an SSH console..
[18:25] <sarnold> gartral: and perhaps the "unattented-upgrades" package would provide a lot of what you'd want from landscape anyway
[18:38] <mgw> Is btrfs recommended for general use on server machines? I'm interested to use in conjunction with lxc. As I understand it, this will help reduce disk usage from duplicated container file systems.
[18:41] <RoyK> mgw: btrfs is not recommended for production systems
[18:41] <mgw> RoyK, thanks
[18:41] <xnox> mgw: you can equally use overlayfs or lvm snapshots for that.
[18:41] <RoyK> mgw: afaik btrfs doesn't have any dedup stuff yet
[18:42] <xnox> mgw: which are more stable than btrfs.
[18:42] <RoyK> xnox: 'cept lvm snapshots are dead slow :P
[18:42] <mgw> xnox: thanks, looking at overlayfs
[18:42] <xnox> RoyK: well dedup is being packaged by me, soon ;-)
[18:42] <RoyK> mgw: try zfs
[18:42] <xnox> RoyK: not in my testing.
[18:42] <sarnold> RoyK: is the zfs support entirely via fuse?
[18:42] <RoyK> mgw: zfs has a decent dedup implementation if you have *lots* of memory
[18:43] <RoyK> sarnold: there's zfsonlinux - separate ppa
[18:43]  * xnox wouldn't recommend zfs on linux to anyone. Solaris or Freebsd maybe.
[18:43] <RoyK> sarnold: works well
[18:43] <xnox> sarnold: zfsonlinux is not legally clean.
[18:43] <sarnold> RoyK: hrm. how is that legal?
[18:43] <sarnold> aha :) hehe
[18:43] <RoyK> xnox: heh - I've worked with zfs on rather large systems, as in quater of a petabyte, works well
[18:43] <sarnold> RoyK: linux?
[18:43] <RoyK> sarnold: it's legal, it's legal to download and install non-gpl software on your own
[18:44] <RoyK> sarnold: zfsonlinux does just that
[18:44] <mgw> ubuntu-zfs is zfsonlinux?
[18:44] <RoyK> sarnold: it's like graphics drives that compile on install
[18:44] <RoyK> mgw: no, ubuntu-zfs is fuse-based, dead slow
[18:47] <mgw> RoyK: ok… so I'll need to download the package from http://zfsonlinux.org/
[18:47] <RoyK> mhm
[18:48] <sarnold> RoyK: neat. thanks :D
[18:48] <RoyK> mgw: keep in mind that zfs doesn't support things like expanding a VDEV (that is, a RAIDz1 or RAIDz2 aka RAID-5 or RAID-6)
[18:49] <mgw> RoyK: I *think* that would be ok for us.
[18:49] <keithzg> xonx: It's only not legally clean to distribute the code compiled into the kernel; but for example a binary module for the kernel is just fine, same as the proprietary NVIDIA blobs are.
[18:50] <RoyK> mgw: takes a wee bit more of planning
[18:50] <keithzg> ^xnox, I mean.
[18:51] <sarnold> I think the zfs modules work in part because the code clearly originated elsewhere, rather than works only on linux.
[18:51] <sarnold> it's hard to claim it's a derived work when the primary platform was something else entirely :)
[18:52] <mgw> RoyK, xnox, sarnold: thanks for the assistance
[18:52] <sarnold> mgw: thanks for asking the question at the right time :) I'd not seen zfsonlinux before. it looks cool. :)
[18:54] <mgw> RoyK: is it stable?
[18:54] <RoyK> mgw: works for me (tm)
[18:54] <RoyK> mgw: and it's used by some large storage providers
[18:54] <mgw> ok, great
[19:04] <RoyK> mgw: what sort of storage are you planning?
[19:07] <mgw> RoyK: you mean the use case, or the type of hardware?
[19:22] <RoyK> mgw: both
[19:34] <RoyK> mgw: ping?
[19:34] <mgw> RoyK: most of my machines have 2x1TB with HW RAID
[19:34] <mgw> SATA
[19:34] <RoyK> ok
[19:35] <RoyK> for that, zfs should work well, that is, for even larger stuff like multihundred terabytes, zfs should work well, if properly planned
[19:36] <mgw> I'm wanting to back lxc containers in such a way as to not have to replicate the 500MB ubuntu files for every container…. does zfs have a versioning system that would allow that?
[19:36] <lifeless> mgw: have a look at lxc-start-ephemeral
[19:36] <lifeless> mgw: which does exactly that
[19:36] <RoyK> mgw: somehow, yes, you can clone a filesystem which will make it dedup what's there, but not the new stuff
[19:37] <RoyK> mgw: you can turn on dedup on the dataset, but it'll require large amounts of RAM to run efficiently
[19:37] <mgw> lifeless: lxc-start-ephemeral… so the / filesystem would be read only/shared?
[19:38] <lifeless> mgw: have a look at the script; it should answer your questions :)
[19:38] <mgw> (looking at man now)
[20:23] <stuxlof> I'm running ubuntu 11.10 x86_64 with a dell h700 raid controller containing megaraid sas firmware. I'm not sure if I either need to install megasasctl or megacli. I've got megacli64 running but it only gives me an 'Exit Code: 0x00'. Now megasasctl needs some 32 bit libraries (https://github.com/gnif/ARMT/tree/master/utils/megactl) to function, and this is where I'm stuck at atm
[20:26] <stuxlof> the megaraid_sas driver is loaded in the kernel
[20:27] <mgw> lifeless: do I understand that lxc-start-ephemeral still needs overlayfs?
[20:28] <lifeless> or aufs yeah
[20:28] <lifeless> you could do a similar script though
[20:29] <lifeless> or manually setup your lxc mount tables
[20:29] <lifeless> so that you have a readonly fs and a /var/state/myproject that is readwrite
[20:29] <mgw> yeah, i'm thinking i'd need to use that script as a ref
[20:29] <mgw> but create my own
[20:45] <delinquentme> I've got a file I've used for sshfs mounting remote files
[20:45] <delinquentme> I want to delete the local version of this file
[20:45] <delinquentme> sudo rm -rf localFile/
[20:46] <delinquentme> will do that without removing the content of the remote dir
[20:46] <delinquentme> correct?
[20:48] <sarnold> delinquentme: does the output of mount show the mount currently active?
[20:51] <delinquentme> mount: can't find dopamine_live/ in /etc/fstab or /etc/mtab  << looks like im good
[22:17] <Darkstar1> I can't seem login via ssh. I'm on 12.04
[22:22] <RoyK> Darkstar1: what error message?
[22:23] <Darkstar1> None. I think the server was hacked
[22:23] <Darkstar1> just looking through the  bash history
[22:23] <RoyK> lots of nice stuff? ;)
[22:24] <Darkstar1> it seems someone got in yesterday and unpacked something called portuser.
[22:24] <Darkstar1> Just trying to get ssh back
[22:25] <Darkstar1> ssh logs to system normally right?
[22:25] <RoyK> Darkstar1: try rkhunter and chkrootkit
[22:26] <Darkstar1> RoyK: It's a remote vm
[22:26] <Darkstar1> but I'll look at those toools
[22:26] <RoyK> they attempt to do the same job, but may overlap a bit
[22:26] <RoyK> Darkstar1: yiu can run those on a remote machine
[22:30] <Darkstar1> Think I need to boot into single user mode
[22:32] <sarnold> Darkstar1: best would be taking the machine entirely offline and inspecting the filesystem from a known-good system. preferably a known-good system you can throw away when you're done.
[22:35] <Darkstar1> sarnold: thing is I don't know what to look for tbh. I looked at the history of bash and managed to find the one thing that was installed. What that thing did I do not know, but I removed the compromised user and inspecting the bash history has allowed me to remove the unpacked stuff
[22:36] <sarnold> Darkstar1: check especially for unexpected dot files in all directories, debsums mismatches, unexpected kernel modules, etc.
[22:36] <Darkstar1> debsums?
[22:37] <sarnold> Darkstar1: debsums checks the sizes / hashes of dpkg-managed files, it's a useful way to get a quick overview of what might have changed if an installed rootkit is pretty amateurish
[22:39] <Darkstar1> ok.
[23:52] <crass> something has changed wrt to how ubuntu handles inactive lvm vgs within the last few releases
[23:52] <crass> any one have ideas on how to really release all resources using a vg so that I can luksClose the underlying device?


[00:06] <bryce> I've fleshed out https://wiki.ubuntu.com/X/Bugs/IntelDriver a bit more
[00:21] <tseliot> I've added another I830WaitLpRing() bug to the wiki
[00:39] <bryce> it'd be nice to update that LpRing table to remove the fixed bugs
[00:42]  * bryce reorders by chip id
[00:44] <cwillu> 22741 is a dupe of 28326
[00:44] <cwillu> which is odd, seeing as it's not the same chip?
[00:45] <cwillu> oh, nvm, just notice the other line
[00:46] <bryce> let's try sorting by symptom...
[00:48] <bryce> there we go
[00:49] <bryce> hmm
[00:50] <bryce> well maybe that'll give some ideas on further triaging...  bugs with similar symptoms should test each other's workarounds and steps to reproduce
[07:33] <bryce> hah, I've reproduced the freeze on i965
[08:34] <bryce> heya RAOF
[08:34] <RAOF> Howdie bryce.
[08:34] <RAOF> What's up?
[08:35] <bryce> ah, well I was finally able to reproduce that i965 freeze bug that's been going around
[08:35] <bryce> I'm poking around collecting any data that looks interesting
[08:35] <bryce> not finding strong clues, but am finding some "interesting evidence"
[08:36] <RAOF> I think I'll rebuild a kernel with the MMIO tracer enabled, and provide someone with a log of the suspend/resume cycle with the nvidia driver.
[20:25] <andresmujica> ping bryce
[22:36] <bryce> andresmujica: just ask
[22:37] <bryce> tjaalton: mesa 7.4 brought a freeze regression.  Downgraded to 7.3 and it seems to have gone away.
[22:38] <superm1> bryce, it also brought a regression in myth causing segfaults
[22:39] <superm1> i've been bisecting all day to find the commit
[22:39] <superm1> (bug 355242)
[22:39] <bryce> superm1: aha, yeah I wondered if that could be the case, I saw that bug too
[22:40] <bryce> superm1: in looking through the mesa 7.4 changelog, it seems the majority of the changes for -intel were for DRI2 issues, we probably don't care so much about
[22:40] <superm1> bryce, i dont know what drivers are affected, but i'm able to reproduce it with vesa, so virtualbox has been my friend
[22:45] <bryce> hmm
[22:45] <bryce> yeah I can't tell from the bug report whether it's driver-specific or in the genera mesa code
[22:45] <superm1> well i'm down to like 2 commits left, so i should know soon enough
[22:45] <andresmujica> hi bryce, i just was going to ask about the freeze
[22:45] <superm1> just annoying that it takes like 25min to do mesa builds
[22:46] <andresmujica> it's only related to x?  mesa and dri?
[22:46] <andresmujica> or is kernel involved too?
[22:46] <bryce> hrm, seems this mesa 7.4 upgrade is kind of poor quality, if we've already found two serious regressions with it
[22:47] <bryce> superm1: I also looked in the mailing list for recent discussions of regressions but didn't see anything obvious, maybe the problems are some weird conflict with this mesa and ubuntu-specific kernel/xserver junk
[22:47] <bryce> hopefully timo can weigh in
[22:47] <bryce> andresmujica: heya, thanks for looking at the freeze bugs :-)
[22:48] <andresmujica> hehe
[22:48] <bryce> andresmujica: from what I suspect, there is definitely one freeze bug, which I believe started with the mesa 7.4 upgrade on 4/3, which only affects i965
[22:49] <andresmujica> yeap, i'm reading about them..
[22:49] <andresmujica> ok.
[22:49] <bryce> andresmujica: however there are also plenty of other freeze bugs that still exist
[22:49] <andresmujica> gonna test it here downgrading
[22:49] <andresmujica> yeap
[22:49] <andresmujica> that's what i've noticed..
[22:49] <bryce> andresmujica: so we have to distinguish between them
[22:49] <andresmujica> which factor are u using to distinguish them?
[22:49] <bryce> they're really, really hard to debug though - no error messages, and all have identical symptoms, and a lot seem to come on randomly
[22:50] <bryce> so far, the most useful thing is if you can pin it to a particular date when it started happening, and from that discern which package changed at that time, that brought the freeze into existence
[22:51] <bryce> unfortunately, when people first noticed after upgrading from intrepid -> jaunty, the number of changes is too great to sort through, so that's kind of a shame
[22:52] <bryce> anyway, what you've been posting to the bugs is exactly the right info and questions to present to reporters, so keep it up, hopefully that can get us better knowledge for what to do with the bugs.
[22:52] <andresmujica> ok. perfect then!
[22:53] <bryce> if you get answers that show that they're freezes in -intel that still exist in jaunty, please add them to that table so we can keep track of them for later
[22:53] <andresmujica> ok
[22:58] <bryce> ok, wife is kicking me out in the shop to get some house projects done... bbiaw
[23:00] <superm1> well git bisect claims fe5328bfad063f2ccbcafa2cebe6971d7e8e1db7 is first bad commit
[23:01] <superm1> i'll do a test build with just that commit reverted to check tho
[23:52] <superm1> well that would have been wishful thinking i guess.  there must be some more (possibly related) commits that are also a factor


[03:49] <CIA-4> ubiquity: superm1 * r3635 ubiquity/ (debian/changelog scripts/mythbuntu/mythbuntu_install.py):
[03:49] <CIA-4> ubiquity: Mythbuntu: Reconfigure mythbuntu-default-settings to ensure that the
[03:49] <CIA-4> ubiquity: DefaultSession is set.
[09:30] <CIA-4> ubiquity: evand * r3636 trunk/ (4 files in 3 dirs):
[09:30] <CIA-4> ubiquity: Copy any network configuration set up by the user of the live CD to
[09:30] <CIA-4> ubiquity: the installed system.
[11:18] <CIA-4> casper: evand * r729 casper/ (debian/changelog scripts/casper-bottom/15autologin):
[11:18] <CIA-4> casper: Revert the previous change to 15autologin and instead just make sure
[11:18] <CIA-4> casper: custom.conf does not exist.
[11:26] <CIA-4> casper: evand * r730 casper/debian/changelog: releasing version 1.209
[14:39] <ev> cjwatson: you mentioned at UDS that there had been some effort to translate the console-setup templates.  But Debian uses console-data, not console-setup (kbdnames-maker) for its input, with no string overlap between the two.  What approach did you have in mind?
[14:40] <cjwatson> console-setup comes from Debian
[14:40] <cjwatson> we didn't invent it :)
[14:40] <cjwatson> it's just that Debian hasn't finished switching over to it yet
[14:40] <cjwatson> I haven't paid lots of attention to what's in console-setup upstream, but I know translation was being worked on
[14:41] <cjwatson> and I'm *pretty* sure it landed
[14:41] <ev> apologies for the odd phrasing, I've been looking at both console-setup in Debian and Ubuntu, so I didn't mean to imply that it didn't exist.
[14:41] <ev> the package, that is
[14:42] <ev> hrm, I haven't uncovered it, but it's my first day back, so lets assume that I'm looking right at it without noticing :).  I'll keep digging.
[14:43] <cjwatson> what I mean is that I didn't have any particular approach in mind myself because I thought it was done
[14:43] <ev> ah, gotcha
[14:43] <cjwatson> console-setup (1.35) unstable; urgency=low
[14:43] <cjwatson>   [ Samuel Thibault ]
[14:43] <cjwatson>   * Fetch keyboard names translations from xkeyboard-config.
[14:43] <cjwatson> that stuff
[14:44] <ev> thanks
[15:58] <CIA-4> grub-installer: cjwatson * r829 ubuntu/ (5 files in 3 dirs): merge from Debian 1.49
[17:02] <CIA-4> grub-installer: cjwatson * r830 ubuntu/debian/changelog: releasing version 1.49ubuntu1
[17:36] <xivulon> hi ev, cjwatson, happy new year!
[17:37] <xivulon> please have a look at bug #477104
[17:37] <xivulon> the upstream patch seems to do the trick, no side effect I can notice


[00:57] <cjwatson> kamal: That powerpc build is just finishing now.
[00:57] <kamal> cjwatson, nice, thanks again for the help with that
[09:14] <Laney> elfy: well done, thanks for your help
[09:17] <sil2100> Hello release team! We have an FFe for the Qt 5.4 QML-cache feature in vivid: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1418060
[09:17] <sil2100> The packages are ready to be published, we just need a final ACK
[09:19] <Laney> sil2100: done
[09:19] <sil2100> Laney: thanks!
[09:19] <sil2100> Mirv: ^ \o/
[09:31] <Mirv> Laney: thanks!
[16:15] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/fix-max-pup/+merge/251282
[17:50] <teward> if someone wants something looked at for consideration for addition to vivid prior to release (but post-feature-freeze) where to we direct that request to?  (It arrived in #ubuntu-bugs asking for Bug Control to look at it for inclusion)
[18:07] <slangasek> bdmurray: merged
[18:10] <slangasek> teward: is this a new feature?
[18:14] <teward> slangasek: not my bug, but i'd be glad to point you to it
[18:14] <teward> slangasek: not sure where to direct the person / bug for attention
[18:14] <teward> slangasek: second consideration: pkg the bug is against is Universe
[18:14] <teward> slangasek: however ScottK suggested the freeze wouldn't affect the bugfix as it's not new features being added - https://bugs.launchpad.net/ubuntu/+source/gramps/+bug/1426144
[18:14] <teward> (first comment is ScottK's)
[18:14] <teward> in other news, LP is timing out for me again :/
[18:16] <teward> slangasek: however, it's still not bug control's choice what gets in / doesn't get in - hence asking where i should send the user.  i'm happy to proxy the reqs to here but i'm lazyish too
[18:19] <slangasek> teward: correct, bugfixes are not affected by feature freeze.  normally I would say #ubuntu-motu or #ubuntu-devel for this, but as this just requires a sync of a new Debian package version I'll JFDI
[18:19] <teward> slangasek: i'm not fluent in acronyms - expand JFDI for me please
[18:19]  * teward is also extremely tired o.o
[18:19] <slangasek> just friggin' do it :)
[18:19] <teward> ah okay
[18:19] <teward> yeah i'm tired, and i think i need more espresso :/
[18:20] <teward> slangasek: i'll advise the user to poke -devel or -motu next time about it, since Bug Control doesn't have any true release control
[18:20] <teward> and let them know you're looking at it right now
[18:39] <tyhicks> Some i386 autopkg tests failed while my dbus upload was migrating from -proposed
[18:39] <tyhicks> they look to be unrelated to my changes
[18:39] <tyhicks> could someone here trigger the tests to run again?