[00:21] <infinity> fred909: No, updates are not moved into the release pocket "after a while", or ever.
[00:21] <infinity> fred909: That's how Debian does point releases, but not Ubuntu.
[00:22] <infinity> fred909: On the other hand, if you want to create deterministic docker images by shipping known security flaws, you might want to re-think your entire endeavour.
[00:36] <xnox> mwhudson:  doko: so pandas still fails 3.8 test suite, right?
[00:36] <xnox> override_dh_auto_test: override_dh_auto_install
[00:36] <xnox>         set -e; \
[00:36] <xnox>         for ver in ${PY3VERS}; do \
[00:36] <xnox>           if [ $$ver = 3.8 ] ; then \
[00:36] <xnox>                 debian/rules python-test$$ver || true; \
[00:36] <xnox>           else \
[00:36] <xnox>                 debian/rules python-test$$ver; \
[00:37] <xnox>           fi; \
[00:37] <xnox>         done
[00:37] <mwhudson> xnox: y
[00:37] <mwhudson> need a new upstream version to get 3.8 compat
[00:37] <mwhudson> there is a debian bug about this
[00:39] <xnox> right
[00:39] <xnox> and there are reverse-deps of pandas that are still failing (ie. dask)
[00:39] <xnox> = 280 failed, 23302 passed, 2666 skipped, 742 deselected, 81 xfailed, 31 xpassed, 9569 warnings in 969.29 seconds =
[00:39] <xnox> X connection to :99 broken (explicit kill or server shutdown).
[00:39] <xnox> make[2]: *** [debian/rules:118: python-test3.8] Error 1
[00:39] <xnox> is not good
[00:39] <xnox> mwhudson:  is it out yet upstream? can we package/upload it?
[00:39] <doko> dask needs an update, probably 2.6
[00:40] <doko> also discussed
[00:40]  * xnox remembers vowing to never touch pandas, but i think it was more than 3 years, so expired
[00:40] <mwhudson> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931557
[00:41] <doko> xnox: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10703361/+listing-archive-extra
[00:41] <xnox> mwhudson:  it's done in experimental
[00:41] <xnox> doko:  nice! but sad that it still fails
[00:41] <doko> but maybe let vorlon fix the statsmodels installation failure first ...
[00:42] <xnox> yeah
[00:42] <xnox> blocked on all fronts
[00:42] <doko> there's only limited time
[00:44] <doko> xnox: it's failing for the deprecation warnings, I didn't figure out yet where these come from
[00:45] <doko> the build will succeed if you reduce the amount of tests, like for all non x86 archs
[00:48] <doko> xnox: no, it's not done. it can't be tested
[00:59] <vorlon> doko: only the -doc package is an install failure, what is that blocking?
[01:02] <doko> vorlon: the much discussed pandas update, see https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10703361/+listing-archive-extra and re-enable the indep b-d's
[01:02] <doko> sorry, ppa's don't have a history
[01:04] <doko> anyway, 2am here, afk
[01:04] <vorlon> doko: I still don't understand what this has to do with python-statsmodels-doc being uninstallable; it has no reverse-dependencies
[01:04] <vorlon> and python3-statsmodels itself shouldn't be uninstallable
[01:04] <vorlon> (but testing that locally now)
[01:06] <vorlon> tested and it installs fine, so....
[01:16] <doko> vorlon: seriously? https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10706889/+listing-archive-extra
[01:17] <doko> please do your homework
[01:18] <vorlon> doko: I ran 'reverse-depends -b', where is that build-dependency coming from?
[01:20] <vorlon> doko: it's not a build-dep of pandas in the archive, so why is the new version /adding/ a doc build-dep?
[01:23] <doko> wrong question
[01:24] <doko> looking at the statsmodels build log (archive build) shows you the conflicting files
[01:24] <vorlon> I understand that, we already talked about it
[02:13] <jbicha> what's fun are the cdbs packages that try to be extra clever, like https://salsa.debian.org/gstreamer-team/gst-plugins-good1.0/blob/master/debian/rules
[02:18] <jbicha> teward: before starting a big email to Debian about cdbs, maybe you could read through the recent-ish discussion https://lists.debian.org/debian-devel/2019/05/msg00178.html
[02:19] <teward> jbicha: i have no plans to send any time soon :P
[02:19] <jbicha> there's probably a summary of that email discussion somewhere 😭
[03:12] <mwhudson> uwsgi is the best/worst cdbs package
[04:04] <Unit193> I just converted 3 packages from cdbs to dh. :3
[09:47] <RikMills> cjwatson: hi. merges.ubuntu.com seems to not be updating? sorry if this is something known and in-hand
[09:58] <cjwatson> RikMills: Known in the sense that I have a bunch of overnight mails about it and hadn't dealt with them yet, yes
[09:58] <cjwatson> Got stuck for some reason.  I've killed the stuck process
[09:58] <RikMills> cjwatson: thank you :)
[11:04] <TJ-> Just noticed on 19.10 (but exists since 17.10 I think) that by default os-prober spams the journal with debug messages - not noticed before due to GRUB_DISABLE_OS_PROBER=true ... os-prober has a OS_PROBER_DISABLE_DEBUG but it isn't exported from grub in /etc/grub.d/30_os-prober - is there some other way to prevent the spamming?
[11:38] <cjwatson> You could put 'export OS_PROBER_DISABLE_DEBUG=1' in /etc/default/grub
[11:38] <cjwatson> I think we probably ought to flip the debug default in os-prober instead of further hacking grub
[11:39] <cjwatson> But maybe coupled with installer changes to turn on debugging in the installer context, since it can be very helpful when looking at logs of installer bugs
[13:06] <gpiccoli> o/ rbasak - I detailed a bit the user visible differences in LP #1847924 , let me know if you think it's enough and your thoughts on the alternatives we have heheh
[13:06] <gpiccoli> Thanks in advance!
[14:03] <TJ-> cjwatson:  just got back to os-prober. Yes, export in the sourced config files works. Agreed, user-tool-debug controllable would be best. Even with it disabled os-prober still uses 'log' to be extremely verbose with what I'd regard as debug messages - certainly not very helpful to users, and what is annoying is I cannot find a journal 'unit' that contains these messages. Typical 'unit' field is e.g.
[14:03] <TJ-> 40grub2[$PID] and $PID varies due to many invocations
[14:05] <ahasenack> any idea why this bug isn't showing up in the php7.3 excuses report? https://bugs.launchpad.net/ubuntu/+source/php7.3/+bug/1850190
[14:05] <ahasenack> I added the update-excuse and update-excuses tag (just in case)
[14:05] <ahasenack> or is it still mispelled?
[14:05] <ahasenack> rbalint: ^
[14:14] <gpiccoli> Folks, if we have "force-badtest makedumpfile/all/s390x" in ubuntu-hints, can we have a report of s390 autopkgtest regression?
[14:14] <gpiccoli> I'd expect that arch to be skipped
[14:14] <gpiccoli> According to this page https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#makedumpfile though, it's listed as failed/regression
[14:14] <xnox> it used to work
[14:15] <xnox> and made sure that it did =/
[14:15] <xnox> although people mostly care about zfcpdump which is not trivially testable in VM
[14:16] <gpiccoli> xnox, I still don't understand - it's marked as badtest, I understand that once it worked..but, if in that file that is shown as force-badtest, should it report?
[14:16] <xnox> all hints are per-series, did you check the disco hints branch?
[14:17] <gpiccoli> I'm asking because I'll soon proposed a MP to force-badtest on ppc64 too, some infrastructure problem we need to debug, I've discussed that with the pkg maintainer, cascardo
[14:18] <gpiccoli> hmm..I'm not sure xnox ! Thanks for the heads-up. I'm checking the file ubuntu-release in the repo lp:~ubuntu-release/britney/hints-ubuntu
[14:18] <gpiccoli> Is this related to which series xnox ?
[14:18] <xnox> devel
[14:19] <xnox> i.e. currently focal
[14:19] <gpiccoli> ohhh
[14:19] <gpiccoli> odd!
[14:19] <xnox> https://code.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-disco is the disco one
[14:19] <gpiccoli> I thought it was to specific release. Do we have a way to force badtest to all releases xnox ? Or should we change all releases' files manually, proposing a MP for every one ?
[14:34] <paride> hey xnox, looking at https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1849563 I remembered that you did the nvidia passthrough at the release sprint
[14:34] <paride> was there any special trick worth mentioning?
[14:36] <xnox> gpiccoli:  propose for each release, yes.
[14:37] <gpiccoli> tnx xnox!
[14:43] <xnox> gpiccoli:  part of this is ACLs because only SRU team can touch stable release hints, vs release team who can touch devel series hints, and upon release the $devel series hints are forked to become the baseline of the stable release for future SRUs.
[14:46] <rbalint> ahasenack, the php7.3 update-excuse shows up after the missing builds
[14:46] <gpiccoli> nice, thanks for the explanation xnox ! I'm reporting a LP bug to investigate such recurrent failures in s390x and ppc64el, and will propose soon a merge request to bionic/disco hints
[14:46] <rbalint> ahasenack, i think this is where block-proposed bugs are listed, too
[15:07] <gpiccoli> xnox, sorry to bother again, just confirming - in the britney disco/bionic repo, the file to change in order to add force-badtest is ubuntu-sru correct?
[15:07] <gpiccoli> _Not_ ubuntu-release
[15:27] <cpaelzer> doko: you were so kind to promote postgresql-12 binaries for the MIR that you opened and we discuessed recently, but I found it hanging in excuses with dependencies
[15:27] <cpaelzer> doko: truns out not all binaries of postgresql-11 were in main and postgresql-12 should follow the same
[15:27] <cpaelzer> doko: could you selectively demote the following binaries of postgresql-12
[15:27] <cpaelzer> postgresql-server-dev-12, postgresql-plperl-12, postgresql-plpython-12, postgresql-plpython3-12, postgresql-pltcl-12
[15:27] <cpaelzer> the former one being the one that triggers the component  mismatches atm
[15:28] <cpaelzer> but following the old style which pkg are main/univese the demotion I requested would resolve that
[15:28] <cpaelzer> doko: also news on asyncpg (as you might follow in the bug) we might need v0.19.0 (or a patch thereof) - I'll continue on that
[15:28] <doko> ok, but seriously, why the explicit dependency on clang?
[15:29] <cpaelzer> doko: I never challenged that to the debian packaging, it is as we get it from there
[15:29] <cpaelzer> let me check history on it for an explanation
[15:31] <cpaelzer> doko: it is only on the -dev package and it is becaue things are built --with-llvm
[15:31] <cpaelzer> as part of enabling that option it was added to the -dev dependencies
[15:32] <doko> hmm, they have a jit, that explains why llvm is used, but not clang
[15:34] <doko> and it's built with gcc, as it should
[15:34] <cpaelzer> On that part Ubuntu never touched it, I'd have to ask Myon for reosons beyong what I found int he git log
[15:35] <doko> that would be nice =)
[15:36] <doko> they build a second time with flto=thin -emit-llvm
[15:38] <xnox> gpiccoli:  any file works. it's just the team that commits things has different files. I'm not ubuntu-sru team, so ask them where they want hints
[15:38] <gpiccoli> xnox, but for example, when autopkgtest is failed, which file is lookied to check if it was a bad test?
[15:39] <gpiccoli> I'm confused which file I need to edit in order to prevent the regression flag
[15:39] <xnox> gpiccoli:  i don't know either, and both ubuntu-release team and ubuntu-sru team refuse to document what they will take.
[15:39] <xnox> gpiccoli:  so ping sil2100 rbasak RAOF vorlon about it
[15:41] <gpiccoli> heheh xnox, okay! I guess your last message works as a ping. So the team above ^, please let me know what do you prefer
[15:41] <xnox> i think i misspelled thair names, or they are not in the channel ;-)
[15:50] <gpiccoli> vorlon merged my last MP from last badtest I needed, let's see hehe
[15:50] <gpiccoli> tnx xnox
[15:52] <sil2100> I am here!
[15:53] <sil2100> Well, usually we don't explicitly require people to submit MPs for hint changes, which probably explains why it's not documented
[15:53] <sil2100> For stable series basically both ubuntu-release and ubuntu-sru files are used (+ the per member ones as well)
[15:54] <sil2100> Whenever I edit hints what I do is: if I need to bump an existing hint, I just leave it in the file it was previously in. But if it's a new badtest/skiptest, I put that in ubuntu-sru
[15:54] <sil2100> (for stable series of course)
[15:55] <xnox> sil2100:  add this to the StableReleaseUpdates wiki page please
[15:56] <sil2100> Will do that I guess, but as said, I don't think there's a requirement for people to edit hints on their own
[15:56] <gpiccoli> sil2100, thanks a lot for the great clarification
[15:56] <xnox> sil2100:  correct, but those who do want at least some guidance.
[15:56] <sil2100> I mean, I never ever required that and currently I'm not looking at hint MPs on LP - only when I'm explicitly pinged with an URL
[15:56] <gpiccoli> So, if I want to add a force-badtest, what should I do sil2100 ?
[15:56] <sil2100> xnox: +1
[15:56] <xnox> "if you try to submit hints, use per series branches & keep bumps where they are, or use ubuntu-sru file for new hints" => i.e. things you said
[15:57] <sil2100> gpiccoli: if there's no existing force-badtest for the given package and version, just put it in ubuntu-sru with a comment explaining why it's needed
[15:57] <xnox> sil2100:  erh..... ubuntu-sru must subscribe to the hints branch changes!
[15:58] <sil2100> I'm probably subscribed, but probably all the mail goes into /dev/null!
[15:58] <gpiccoli> bumps where they are -> can I read that as "if we have a specific version entry in ubuntu-release and user is bumping to all versions, keep in ubuntu-release instead of ubuntu-sru" ?
[15:59] <gpiccoli> this is what I got grepping for the package _after_ my addition sil2100 : https://termbin.com/i0v2
[16:00] <gpiccoli> it's in bionic
[16:02] <sil2100> gpiccoli: if it's like skipping a new architecture, then I'd include the new hint in ubuntu-sru then
[16:07] <gpiccoli> thanks sil2100 ! I'll do the MP and loop you there, ok ?
[16:08] <mdeslaur> Skuggen: hi! any luck with the s390x issue?
[16:09] <sil2100> gpiccoli: ok, just give me the URL once you file it
[16:09] <gpiccoli> awesome, much appreciated sil2100 =)
[16:09] <gpiccoli> thanks
[16:10] <sil2100> yw!
[16:40] <xnox> coreycb:  out of all the things, i care about sad openstack in focal-proposed today! https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-openstack
[16:40] <xnox> coreycb:  how can i help, getting those rolling? i.e. we could skip tests on py3.8 on those, or like try to fix them up? what do you think?
[16:42] <coreycb> xnox: oh no, are they all py38 related?
[16:47] <coreycb> xnox: oh good it looks like python3.8 is in bionic now. i can enable non-voting gate unit test jobs upstream now. unfortunately too late for this cycle to enable voting.
[16:51] <infinity> coreycb: So, WTF happened with Openstack upstream for them to slip their 6-month cadence so hard?
[16:52] <infinity> coreycb: Are there conspiracies afoot?  Was there some obvious oops?  More importantly, if it keeps slipping, do we really want to keep trying to "align" if it means SRUing final 2 months and then 3 months (etc) after release?
[16:54] <infinity> I suppose if there is a conspiracy, it's not one involving Fedora, cause F32 still appears to be aligned with Focal.
[16:55] <infinity> coreycb: Is there anyone who can talk sense into them and point out that being out of cadence with the two major 6mo-releasing distros (Ubuntu and Fedora) is daft?
[17:00] <coreycb> infinity: i'm not sure why the cadence changed. beisner may know better (he's in china now though) or jamespage.
[17:00] <coreycb> infinity: but yes if it gets worse then we will have to consider a new approach
[17:02] <coreycb> infinity: for this cycle I think we can still make it work with the one month post-focal delivery of ussuri, assuming the release team and sru team are ok with it
[17:20] <xnox> there is "Release Cycle Observations" thread but not much details or juice in it, and then just the cycle published.
[17:20] <xnox> coreycb:  i think it needs a public mailing list post as to why it's 4 weeks longer than normal. It's 30 weeks long cycle.
[17:22] <coreycb> xnox: infinity: we might know someone on the foundation board
[17:24] <coreycb> xnox: infinity: let me check with others to see if they have a better understanding of the upstream rationale
[17:39] <infinity> coreycb: The rationale would be interesting, but more interesting would be badgering them to re-align with Ubuntu/Fedora again.
[17:39] <infinity> coreycb: This situation is pretty poop for all involved.
[17:40] <infinity> coreycb: Heck, a short cycle focussed just on bugfixes and stability with an eye to pulling back a couple of months would be even better, so we could see final releases well BEFORE our release.  A man can dream.
[17:41] <coreycb> infinity: agreed I'll discuss with the team a bit
[17:54] <ahasenack> what is "live-installer"? https://launchpad.net/ubuntu/+source/live-installer
[17:54] <ahasenack> ubiquity? d-i installer?
[17:54] <ahasenack> it's not subiquity
[18:02] <ahasenack> Skuggen: hi, what's your lp id please?
[18:02] <ahasenack> Skuggen: I have a couple of mysql8 bugs that I would like your opinion on, upgrade issues where a config option is no longer supported by mysql8 and it fails to start
[18:04] <ahasenack> Skuggen: https://launchpad.net/~lars-tangvald ?
[18:05] <gpiccoli> sil2100, here are the MPs heh: https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/375279
[18:05] <gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-disco/+merge/375280
[18:05] <gpiccoli> Thanks again for your help =)
[18:09] <Skuggen> ahasenack: Hi
[18:09] <Skuggen> Yeah
[18:09] <ahasenack> thx
[18:17] <fred909> infinity: thanks for the clarification. definitely don't want to ship security vulnerabilities, but we had test breakage... so trying to find a middle ground where we can control what goes in. i think the main issue was using a docker image (ubuntu:16.04) that's a moving target. the tagged versions shouldn't change though and security updates shouldn't change functionality... right?
[18:21] <infinity> ahasenack: live-installer is the d-i component that copies the livefs into place on the old-style server ISOs.  It's the replacement for debootstrap in the same install flow.
[18:21] <infinity> (ish)
[18:22] <infinity> fred909: I'd somewhat ignorant about how our docker images are built/published (other than to note that, yes, they're updated regularly with post-release updates), so I'm not sure what you mean by "tagged versions".
[18:24] <infinity> fred909: If you build your own stuff from scratch, excluding updates and security will get you the same versions every time.  Obviously not ideal, but gives a base reference.  Security and SRU (bugfix) updates both happen under a policy of not changing functionality unless necessary (ie: a feature has to be disabled because the whole thing, it turns out, is a security flaw by design)
[18:24] <fred909> infinity: it seems the docker images pull from https://partner-images.canonical.com/core/. tagged versions are listed at https://hub.docker.com/_/ubuntu/?tab=tags.
[18:25] <fred909> infinity: ok, thanks.
[18:26] <infinity> fred909: So yeah, looking at that, the tags by date clearly won't ever change (though no idea how much history is kept), while the tags by version number will end up getting updates throughout the life of the product.
[18:27] <infinity> Weirdly confusing use of the term "tag", which implies "unique and unchanging" to VCS people, but obviously doesn't (have to) mean that here. :/
[18:31] <fred909> infinity: yeah, definitely alarming that they can be changed and it's left up to the maintainer of the particular image.
[18:37] <fred909> infinity: you mentioned "Security and SRU (bugfix) updates", security go to -security... what repo do the SRU's go to? -updates?
[18:38] <fred909> ah they're a subset packages in -updates, that are uplifted to the images?
[21:25] <doko> LocutusOfBorg, or RikMills: is anyone of you looking at the paraview/armhf ftbfs?
[22:35] <LocutusOfBorg> doko, I might have a look in 12h, but I failed so far to find a way to fix it
[22:35] <LocutusOfBorg> it might be related to the embedded vtk version
[22:37] <doko> LocutusOfBorg: I also filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944324