/srv/irclogs.ubuntu.com/2019/11/07/#ubuntu-devel.txt

infinityfred909: No, updates are not moved into the release pocket "after a while", or ever.00:21
infinityfred909: That's how Debian does point releases, but not Ubuntu.00:21
infinityfred909: 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:22
xnoxmwhudson:  doko: so pandas still fails 3.8 test suite, right?00:36
xnoxoverride_dh_auto_test: override_dh_auto_install00: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:36
xnox          fi; \00:37
xnox        done00:37
mwhudsonxnox: y00:37
mwhudsonneed a new upstream version to get 3.8 compat00:37
mwhudsonthere is a debian bug about this00:37
xnoxright00:39
xnoxand 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
xnoxX connection to :99 broken (explicit kill or server shutdown).00:39
xnoxmake[2]: *** [debian/rules:118: python-test3.8] Error 100:39
xnoxis not good00:39
xnoxmwhudson:  is it out yet upstream? can we package/upload it?00:39
dokodask needs an update, probably 2.600:39
dokoalso discussed00:40
* xnox remembers vowing to never touch pandas, but i think it was more than 3 years, so expired00:40
mwhudsonxnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93155700:40
ubottuDebian bug 931557 in src:pandas "transition: pandas 0.23 -> 0.25" [Wishlist,Open]00:40
dokoxnox: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10703361/+listing-archive-extra00:41
xnoxmwhudson:  it's done in experimental00:41
xnoxdoko:  nice! but sad that it still fails00:41
dokobut maybe let vorlon fix the statsmodels installation failure first ...00:41
xnoxyeah00:42
xnoxblocked on all fronts00:42
dokothere's only limited time00:42
dokoxnox: it's failing for the deprecation warnings, I didn't figure out yet where these come from00:44
dokothe build will succeed if you reduce the amount of tests, like for all non x86 archs00:45
dokoxnox: no, it's not done. it can't be tested00:48
vorlondoko: only the -doc package is an install failure, what is that blocking?00:59
dokovorlon: 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's01:02
dokosorry, ppa's don't have a history01:02
dokoanyway, 2am here, afk01:04
vorlondoko: I still don't understand what this has to do with python-statsmodels-doc being uninstallable; it has no reverse-dependencies01:04
vorlonand python3-statsmodels itself shouldn't be uninstallable01:04
vorlon(but testing that locally now)01:04
vorlontested and it installs fine, so....01:06
dokovorlon: seriously? https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10706889/+listing-archive-extra01:16
dokoplease do your homework01:17
vorlondoko: I ran 'reverse-depends -b', where is that build-dependency coming from?01:18
vorlondoko: it's not a build-dep of pandas in the archive, so why is the new version /adding/ a doc build-dep?01:20
dokowrong question01:23
dokolooking at the statsmodels build log (archive build) shows you the conflicting files01:24
vorlonI understand that, we already talked about it01:24
jbichawhat'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/rules02:13
jbichateward: 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.html02:18
tewardjbicha: i have no plans to send any time soon :P02:19
jbichathere's probably a summary of that email discussion somewhere 😭02:19
mwhudsonuwsgi is the best/worst cdbs package03:12
Unit193I just converted 3 packages from cdbs to dh. :304:04
RikMillscjwatson: hi. merges.ubuntu.com seems to not be updating? sorry if this is something known and in-hand09:47
cjwatsonRikMills: Known in the sense that I have a bunch of overnight mails about it and hadn't dealt with them yet, yes09:58
cjwatsonGot stuck for some reason.  I've killed the stuck process09:58
RikMillscjwatson: thank you :)09:58
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:04
cjwatsonYou could put 'export OS_PROBER_DISABLE_DEBUG=1' in /etc/default/grub11:38
cjwatsonI think we probably ought to flip the debug default in os-prober instead of further hacking grub11:38
cjwatsonBut 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 bugs11:39
gpiccolio/ 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 heheh13:06
ubottuLaunchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/184792413:06
gpiccoliThanks in advance!13:06
=== ricab is now known as ricab|lunch
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 invocations14:03
ahasenackany idea why this bug isn't showing up in the php7.3 excuses report? https://bugs.launchpad.net/ubuntu/+source/php7.3/+bug/185019014:05
ubottuLaunchpad bug 1850190 in php7.3 (Ubuntu) "FTBFS with mysql 8.0" [Undecided,In progress]14:05
ahasenackI added the update-excuse and update-excuses tag (just in case)14:05
ahasenackor is it still mispelled?14:05
ahasenackrbalint: ^14:05
gpiccoliFolks, if we have "force-badtest makedumpfile/all/s390x" in ubuntu-hints, can we have a report of s390 autopkgtest regression?14:14
gpiccoliI'd expect that arch to be skipped14:14
gpiccoliAccording to this page https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#makedumpfile though, it's listed as failed/regression14:14
xnoxit used to work14:14
xnoxand made sure that it did =/14:15
xnoxalthough people mostly care about zfcpdump which is not trivially testable in VM14:15
gpiccolixnox, 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
xnoxall hints are per-series, did you check the disco hints branch?14:16
gpiccoliI'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, cascardo14:17
gpiccolihmm..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-ubuntu14:18
gpiccoliIs this related to which series xnox ?14:18
xnoxdevel14:18
xnoxi.e. currently focal14:19
gpiccoliohhh14:19
gpiccoliodd!14:19
xnoxhttps://code.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-disco is the disco one14:19
gpiccoliI 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:19
=== ricab|lunch is now known as ricab
paridehey xnox, looking at https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1849563 I remembered that you did the nvidia passthrough at the release sprint14:34
ubottuLaunchpad bug 1849563 in edk2 (Ubuntu Focal) "Unable to passthrough GPUs to guest" [Undecided,New]14:34
paridewas there any special trick worth mentioning?14:34
xnoxgpiccoli:  propose for each release, yes.14:36
gpiccolitnx xnox!14:37
xnoxgpiccoli:  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:43
rbalintahasenack, the php7.3 update-excuse shows up after the missing builds14:46
gpiccolinice, 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 hints14:46
rbalintahasenack, i think this is where block-proposed bugs are listed, too14:46
gpiccolixnox, 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-release15:07
=== cpaelzer_ is now known as cpaelzer
cpaelzerdoko: 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 dependencies15:27
cpaelzerdoko: truns out not all binaries of postgresql-11 were in main and postgresql-12 should follow the same15:27
cpaelzerdoko: could you selectively demote the following binaries of postgresql-1215:27
cpaelzerpostgresql-server-dev-12, postgresql-plperl-12, postgresql-plpython-12, postgresql-plpython3-12, postgresql-pltcl-1215:27
cpaelzerthe former one being the one that triggers the component  mismatches atm15:27
cpaelzerbut following the old style which pkg are main/univese the demotion I requested would resolve that15:28
cpaelzerdoko: 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 that15:28
dokook, but seriously, why the explicit dependency on clang?15:28
cpaelzerdoko: I never challenged that to the debian packaging, it is as we get it from there15:29
cpaelzerlet me check history on it for an explanation15:29
cpaelzerdoko: it is only on the -dev package and it is becaue things are built --with-llvm15:31
cpaelzeras part of enabling that option it was added to the -dev dependencies15:31
dokohmm, they have a jit, that explains why llvm is used, but not clang15:32
dokoand it's built with gcc, as it should15:34
cpaelzerOn that part Ubuntu never touched it, I'd have to ask Myon for reosons beyong what I found int he git log15:34
dokothat would be nice =)15:35
dokothey build a second time with flto=thin -emit-llvm15:36
xnoxgpiccoli:  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 hints15:38
gpiccolixnox, but for example, when autopkgtest is failed, which file is lookied to check if it was a bad test?15:38
gpiccoliI'm confused which file I need to edit in order to prevent the regression flag15:39
xnoxgpiccoli:  i don't know either, and both ubuntu-release team and ubuntu-sru team refuse to document what they will take.15:39
xnoxgpiccoli:  so ping sil2100 rbasak RAOF vorlon about it15:39
gpiccoliheheh xnox, okay! I guess your last message works as a ping. So the team above ^, please let me know what do you prefer15:41
xnoxi think i misspelled thair names, or they are not in the channel ;-)15:41
gpiccolivorlon merged my last MP from last badtest I needed, let's see hehe15:50
gpiccolitnx xnox15:50
sil2100I am here!15:52
sil2100Well, usually we don't explicitly require people to submit MPs for hint changes, which probably explains why it's not documented15:53
sil2100For stable series basically both ubuntu-release and ubuntu-sru files are used (+ the per member ones as well)15:53
sil2100Whenever 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-sru15:54
sil2100(for stable series of course)15:54
xnoxsil2100:  add this to the StableReleaseUpdates wiki page please15:55
sil2100Will do that I guess, but as said, I don't think there's a requirement for people to edit hints on their own15:56
gpiccolisil2100, thanks a lot for the great clarification15:56
xnoxsil2100:  correct, but those who do want at least some guidance.15:56
sil2100I 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 URL15:56
gpiccoliSo, if I want to add a force-badtest, what should I do sil2100 ?15:56
sil2100xnox: +115: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 said15:56
sil2100gpiccoli: 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 needed15:57
xnoxsil2100:  erh..... ubuntu-sru must subscribe to the hints branch changes!15:57
sil2100I'm probably subscribed, but probably all the mail goes into /dev/null!15:58
gpiccolibumps 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:58
gpiccolithis is what I got grepping for the package _after_ my addition sil2100 : https://termbin.com/i0v215:59
gpiccoliit's in bionic16:00
sil2100gpiccoli: if it's like skipping a new architecture, then I'd include the new hint in ubuntu-sru then16:02
gpiccolithanks sil2100 ! I'll do the MP and loop you there, ok ?16:07
mdeslaurSkuggen: hi! any luck with the s390x issue?16:08
sil2100gpiccoli: ok, just give me the URL once you file it16:09
gpiccoliawesome, much appreciated sil2100 =)16:09
gpiccolithanks16:09
sil2100yw!16:10
xnoxcoreycb:  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-openstack16:40
xnoxcoreycb:  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:40
coreycbxnox: oh no, are they all py38 related?16:42
coreycbxnox: 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:47
infinitycoreycb: So, WTF happened with Openstack upstream for them to slip their 6-month cadence so hard?16:51
infinitycoreycb: 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:52
infinityI suppose if there is a conspiracy, it's not one involving Fedora, cause F32 still appears to be aligned with Focal.16:54
infinitycoreycb: 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?16:55
coreycbinfinity: i'm not sure why the cadence changed. beisner may know better (he's in china now though) or jamespage.17:00
coreycbinfinity: but yes if it gets worse then we will have to consider a new approach17:00
coreycbinfinity: 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 it17:02
xnoxthere is "Release Cycle Observations" thread but not much details or juice in it, and then just the cycle published.17:20
xnoxcoreycb:  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:20
coreycbxnox: infinity: we might know someone on the foundation board17:22
coreycbxnox: infinity: let me check with others to see if they have a better understanding of the upstream rationale17:24
infinitycoreycb: The rationale would be interesting, but more interesting would be badgering them to re-align with Ubuntu/Fedora again.17:39
infinitycoreycb: This situation is pretty poop for all involved.17:39
infinitycoreycb: 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:40
coreycbinfinity: agreed I'll discuss with the team a bit17:41
ahasenackwhat is "live-installer"? https://launchpad.net/ubuntu/+source/live-installer17:54
ahasenackubiquity? d-i installer?17:54
ahasenackit's not subiquity17:54
ahasenackSkuggen: hi, what's your lp id please?18:02
ahasenackSkuggen: 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 start18:02
ahasenackSkuggen: https://launchpad.net/~lars-tangvald ?18:04
gpiccolisil2100, here are the MPs heh: https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/37527918:05
gpiccolihttps://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-disco/+merge/37528018:05
gpiccoliThanks again for your help =)18:05
Skuggenahasenack: Hi18:09
SkuggenYeah18:09
ahasenackthx18:09
fred909infinity: 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:17
infinityahasenack: 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:21
infinityfred909: 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:22
infinityfred909: 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
fred909infinity: 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:24
fred909infinity: ok, thanks.18:25
infinityfred909: 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:26
infinityWeirdly confusing use of the term "tag", which implies "unique and unchanging" to VCS people, but obviously doesn't (have to) mean that here. :/18:27
fred909infinity: yeah, definitely alarming that they can be changed and it's left up to the maintainer of the particular image.18:31
fred909infinity: you mentioned "Security and SRU (bugfix) updates", security go to -security... what repo do the SRU's go to? -updates?18:37
fred909ah they're a subset packages in -updates, that are uplifted to the images?18:38
dokoLocutusOfBorg, or RikMills: is anyone of you looking at the paraview/armhf ftbfs?21:25
LocutusOfBorgdoko, I might have a look in 12h, but I failed so far to find a way to fix it22:35
LocutusOfBorgit might be related to the embedded vtk version22:35
dokoLocutusOfBorg: I also filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=94432422:37
ubottuDebian bug 944324 in src:paraview "python-paraview has to be renamed to python3-paraview" [Serious,Open]22:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!