| * mwhudson rubs eyes | 00:53 | |
| mwhudson | i think the python2 pytest in proposed is totally broken | 00:54 |
|---|---|---|
| Unit193 | Hopefully not with sand. | 00:54 |
| mwhudson | Unit193: this python3.8 transition has been a bit like that | 00:54 |
| Unit193 | Yeah, all paths changing is...Not ideal. | 00:54 |
| mwhudson | ok not completely completely broken | 00:55 |
| sarnold | just "python version update" broken | 00:57 |
| mwhudson | doko: a bunch of the pytest autopkgtests failed because of a strange pkg_resources problem that doesn't seem to happen any more so i've retried those | 01:55 |
| mwhudson | does anyone want to remove the python2 autopkgtest from python-qtpy? | 10:09 |
| * mwhudson falls asleep | 10:09 | |
| cpaelzer | ahasenack: there are new versions of patroni and pgrouting which are part of the open pg12 issues | 11:03 |
| cpaelzer | ahasenack: I have triggered tests using the new pg-common and pg-12 | 11:03 |
| cpaelzer | maybe that resolves those two | 11:03 |
| cpaelzer | there also is a new pglogical-ticker, I guess that will be my next merge ... | 11:03 |
| cpaelzer | nice, the only delta we had was by me, is accepted upstream and in the new debian version | 11:07 |
| cpaelzer | so it is in fact a sync now | 11:07 |
| cpaelzer | syncing and triggering tests later, maybe doing a test build and test before ... | 11:07 |
| matttbe | Hello! I am using Ubuntu Focal and I am surprised to see that Git is 4 versions behind the latest one. The version in 20.04 repo is 2.20.1-2ubuntu1 since Disco while the latest (2.24) is available in Debian testing. I didn't find any reason, "excuse" tag, nor build failures explaining why v2.24 is not available in Ubuntu repos. May you guide me where I can find explanations to know why some popular softwares are not updated? | 11:12 |
| matttbe | In fact, I would like to validate that some scripts I have using Git can still work with the latest version of Git. | 11:13 |
| matttbe | I understand that many tools are depending on Git and updating it can be difficult. Maybe it cannot be upgraded because some build systems rely on it and are not compatible with more recent versions? :) | 11:14 |
| rbalint | doko i suggest dropping python-motor from release to get python3-defaults in, i've fixed part of the regression, but waiting for upstream on this one: https://jira.mongodb.org/browse/MOTOR-460 | 11:15 |
| rbalint | doko python-taskflow is done | 11:20 |
| cjwatson | matttbe: In general anything with Ubuntu modifications doesn't get automatically updated until a developer goes and looks at the Ubuntu-specific modifications to decide whether they need to be forward-ported or can just be dropped. | 11:27 |
| cjwatson | matttbe: That is probably the case here. | 11:28 |
| cjwatson | jbicha: ^- the delta to git is yours and I think it probably needs a merge - is this on your list? | 11:29 |
| matttbe | cjwatson: thank you for your reply. I will then check with the Ubuntu maintainers :) | 11:29 |
| cjwatson | matttbe: I've just checked above with the person who made the change in question | 11:29 |
| matttbe | cjwatson, thank you for that! | 11:29 |
| jbicha | cjwatson: git's not on my list. See also Debian bug 911997 😢 | 11:32 |
| ubottu | Debian bug 911997 in src:git "git: Apply diff from Ubuntu" [Normal,Open] http://bugs.debian.org/911997 | 11:32 |
| cjwatson | jbicha: merges.u.c thinks it should be on your list :) | 11:33 |
| jbicha | cjwatson: hire me for the Foundations team and then I'll make sure it's on my list :) | 11:33 |
| cjwatson | jbicha: I haven't been on Foundations in some years ;-) | 11:34 |
| cjwatson | jbicha: Should I take this as it being OK for me to do the merge? | 11:34 |
| jbicha | please go ahead :) | 11:34 |
| cjwatson | OK | 11:35 |
| matttbe | cjwatson: thank you for your help :-) | 11:36 |
| cpaelzer | ahasenack: pglogical-ticker delta is in upstream and builds fine, it won't resolve the PG12 test issue but making it a sync will help to pick it up automatically once it gets a PG12 upload in Debian | 11:46 |
| cpaelzer | I also pinged Myon for those that are left open | 11:47 |
| cpaelzer | maybe he already ahs a lead on some of them | 11:47 |
| doko | rbalint: \o/ | 12:05 |
| Skuggen | matttbe: If you want to test, you could use something like https://launchpad.net/~git-core/+archive/ubuntu/ppa for now, maybe? | 12:19 |
| mdeslaur | Skuggen: the mysql on s390x hang turned out to be an openssl issue | 12:24 |
| mdeslaur | Skuggen: https://git.openssl.org/?p=openssl.git;a=commit;h=e1cce612a6520555805c25be2539f231c22696d9 | 12:26 |
| Skuggen | mdeslaur: Oh! | 12:26 |
| Skuggen | Good (sort of) :) | 12:26 |
| mdeslaur | yeah, unfortunate combo of openssl bug and the way mysql initializes it | 12:27 |
| Skuggen | If the bug title "incorrect call to openssl_malloc_init() can lead..." is accurate, maybe MySQL is doing something wrong with the call? | 12:28 |
| doko | mwhudson: done by ginggs | 12:30 |
| Skuggen | Maybe we still need to call it to support older platforms (8.0 doesn't seem to use it, but we dropped some older platforms for that) with lots of fiddly conditionals | 12:32 |
| mdeslaur | Skuggen: yeah, it got dropped in 8.0...I'm note sure what the impact of removing it is...upstream bug seems to hint that it's unnecessary | 12:33 |
| mdeslaur | Skuggen: in any case, I'm fixing bionic's openssl, so it shouldn't happen anymore | 12:33 |
| cjwatson | matttbe_: on its way into focal now | 12:33 |
| cjwatson | (modulo builds, tests, regression tests against other packages ...) | 12:34 |
| Skuggen | mdeslaur: Seems it got dropped for 8.0 because we had the same issue there on Windows, but on 5.7 (where we only use static linking for openssl) we went straight from 1.0.2 to the 1.1.1 with this issue fixed | 12:43 |
| matttbe_ | Skuggen: thank you for the suggestion! I was going to use the PPA but I was also wondering why it was not in the main repos (did we lost track of it or did the new versions introduce severe regressions, even if it would have been strange :) ) | 12:44 |
| mdeslaur | Skuggen: cool | 12:44 |
| matttbe_ | cjwatson: excellent, thank you for the very quick update :-) | 12:45 |
| ahasenack | Skuggen: hi, did you see those bugs where a config parameter that worked in 5.7 no longer works in 8.0, which fails to start after the upgrade? | 12:48 |
| ahasenack | I was wondering if it was expected that the 8 package remove those config options, or replace them | 12:48 |
| ahasenack | so far I've seen two such config options | 12:49 |
| ahasenack | https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1850998 and https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1850895 | 12:49 |
| ubottu | Launchpad bug 1850998 in mysql-8.0 (Ubuntu) "NO_AUTO_CREATE_USER removed in mysql-8, broke upgrade" [Undecided,Confirmed] | 12:49 |
| ubottu | Launchpad bug 1850895 in mysql-8.0 (Ubuntu) "query_cache_limit removed in mysql-8, upgrade broke" [Undecided,Incomplete] | 12:49 |
| Skuggen | ahasenack: Ah, sorry, I looked for it shortly after you mentioned it before, but didn't see it and then it slipped my mind. Will take a look now | 13:12 |
| ahasenack | Skuggen: thanks! I renamed the bug title a bit to indicate what each one is about | 13:13 |
| Skuggen | NO_AUTO_CREATE_USER has been removed because the ability to use GRANT to create users has been removed (so it has no use): https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html | 13:14 |
| Skuggen | Query cache has also been removed | 13:15 |
| Skuggen | Was the query cache setting in the default config file? We have some logic in the packaging to comment out some query_cache settings since they were in the default 5.7 config (we did something similar for the 5.5->5.7 transition) | 13:16 |
| Skuggen | https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/ (it's also mentioned briefly on the nutshell page) | 13:16 |
| ahasenack | Skuggen: there is nothing about query_cache_limit in debian/** | 13:18 |
| Skuggen | https://salsa.debian.org/mariadb-team/mysql/blob/mysql-5.7/debian/master/debian/additions/mysql.conf.d/mysqld.cnf#L60 | 13:19 |
| Skuggen | That might be a packaging bug | 13:19 |
| Skuggen | https://salsa.debian.org/mariadb-team/mysql/blob/mysql-8.0/ubuntu/devel/debian/mysql-server-8.0.postinst#L116 is a hack to deal with it (for focal I'd like to strip away|comment as much of the default config as possible, to avoid problems like this in the future) | 13:21 |
| Skuggen | Oh! It looks like your config is in /etc/mysql/my.cnf instead of /etc/mysql/mysql.conf.d/mysqld.cnf as we expect? | 13:22 |
| ahasenack | Skuggen: I think there are commented lines suggesting the user could use my.cnf | 13:22 |
| ahasenack | Skuggen: all those config files for mysql are very confusing, there are several | 13:22 |
| Skuggen | The server by default uses /etc/mysql/my.cnf | 13:23 |
| Skuggen | Yeah, it's an ancient mess which I think was just put in place because MariaDB and MySQL use the same files | 13:23 |
| ahasenack | so postinst handles it if it was in a particular config file? | 13:23 |
| Skuggen | Yeah | 13:23 |
| ahasenack | is that the case for other deprecated config options as well? Not just for the 5.7->8 upgrade path | 13:24 |
| Skuggen | It just comments it out with an extra line with something like "this option was automatically commented out because it is no longer valid" | 13:24 |
| Skuggen | Just the ones that are in the default Ubuntu 5.7 config file | 13:24 |
| ahasenack | I mean, from other major upgrades, was postinst always only concerned with one particular config file? | 13:24 |
| Skuggen | Yeah, the 5.7 postinst handled it the same way | 13:25 |
| Skuggen | There's a mechanism to help support users, but I see now we haven't properly updated it for 8.0: | 13:26 |
| ahasenack | is it worth it to look at other config files? Or too messy and error prone, since users can include stuff from anywhere? | 13:26 |
| Skuggen | Yeah, the MySQL config system is too tangled. You can ask MySQL which settings it's using, but not where they're coming from | 13:26 |
| Skuggen | But we run mysqld --verbose --help as a "trial" startup to detect bad config. However that only works for 5.7. 8.0 now has a proper --validate-config flag | 13:27 |
| ahasenack | that wouldn't make the upgrade work in the end, though | 13:28 |
| Skuggen | No | 13:29 |
| ahasenack | so option is "sorry, it's a valid bug, but we only try to upgrade config file X"? | 13:30 |
| ahasenack | or should we look at least at /etc/mysql/my.cnf as well? Is that historically the main config file? | 13:30 |
| ahasenack | or is it shared with mariadb? | 13:30 |
| Skuggen | /etc/mysql/my.cnf is shared with maria, yes | 13:31 |
| Skuggen | So by default all it does is include the variant-specific locations | 13:31 |
| ahasenack | but this guy had his actual config in it? | 13:31 |
| Skuggen | It looks a bit like he's been upgrading since at least 5.5 (Ubuntu 14 or older) | 13:33 |
| Skuggen | His config file contains the lines the 5.7 postinst would add to the settings removed between 5.5 and 5.7 | 13:33 |
| Skuggen | For the 5.7 transition I think we had a catch-all bug for issues with invalid configuration, which just instructed users in fixing it | 13:36 |
| ahasenack | cpaelzer: where are the mysql standard/template bugs again? The list? | 13:37 |
| Skuggen | https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1571865 | 13:37 |
| ubottu | Launchpad bug 1571865 in mysql-5.7 (Ubuntu Xenial) "mysql fails to start after upgrade if previous defaults were customised" [High,Fix released] | 13:37 |
| ahasenack | shouldn't dupe to a fix released bug | 13:38 |
| === ricab is now known as ricab|lunch | ||
| ahasenack | we can say opinion or wontfix if we think it's not worth fixing | 13:39 |
| Skuggen | Yeah, don't think we should revive that issue, but it has a discussion on many of the same things | 13:39 |
| ahasenack | can you add a comment then saying we do handle the upgrade if the config file is X, but that we can't chase down all possible config files? Something like that? What do you think? | 13:40 |
| Skuggen | Yeah, I'll do that | 13:43 |
| ahasenack | ok, and the other bug about NO_AUTO_CREATE_USER ? Is there handling for that? | 13:44 |
| Skuggen | Just remove the option from sql_mode | 13:44 |
| Skuggen | That is not part of any default config | 13:44 |
| ahasenack | ah, we only take care of the default config, makes sense | 13:44 |
| Skuggen | Yeah. MySQL has something like 400 flags that can be set :D | 13:45 |
| cpaelzer | ahasenack: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bugs?&field.tag=triage | 13:47 |
| ahasenack | cpaelzer: thanks | 13:48 |
| Skuggen | Ah, 1612517 | 13:48 |
| ahasenack | Skuggen: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1612517 | 13:48 |
| ubottu | Launchpad bug 1612517 in mysql-5.7 (Ubuntu) "Server fails to start after upgrade because of customized config and obsolete/renamed directives" [Medium,Confirmed] | 13:48 |
| ahasenack | yep, just saw it | 13:48 |
| ahasenack | but postinst is better now, it handles some cases | 13:49 |
| Skuggen | https://dev.mysql.com/doc/refman/8.0/en/server-option-variable-reference.html would be the correct link to use instead of the 5.7 one listed there, I think | 13:50 |
| ahasenack | by "custom configs", you actually mean two possibilities there: a) different config file; b) non-default config option | 13:50 |
| Skuggen | Right | 13:50 |
| Skuggen | If /etc/mysql/mysql.conf.d/mysqld.cnf from a 5.7 installation hasn't been altered by the user it'll just be replaced | 13:51 |
| Skuggen | But if they edit it or add a new one (any .cnf files in that directory will be used) they can get this issue | 13:51 |
| ahasenack | ok | 13:52 |
| ahasenack | Skuggen: ok, I think we can dupe #1850895 to #1612517, wdyt? | 13:53 |
| Skuggen | Yeah. Should be updated to affect 8.0, I guess? | 13:55 |
| ahasenack | I updated the description a bit | 13:55 |
| ahasenack | but yeah, let's add a myusql-8 task to it | 13:55 |
| Skuggen | It probably isn't relevant for 5.7 any more unless there are still people upgrading from trusty | 13:55 |
| ahasenack | but if we aren't planning on fixing it, maybe it should be a wontfix or opinion bug? | 13:55 |
| ahasenack | I'm not sure | 13:55 |
| ahasenack | there are | 13:56 |
| ahasenack | (people upgrading from trusty) | 13:56 |
| ahasenack | ok, done (dupes) | 13:57 |
| Skuggen | Yeah, right now it's working as intended (until we can think of a robust way to do more) | 13:57 |
| ahasenack | thanks Skuggen | 13:57 |
| Skuggen | np :) | 13:57 |
| === M_hc[m] is now known as _hc | ||
| kanashiro | doko, I am working on libpam-radius-auth merge and the only delta we have now is the addition of the build flag -fno-strict-aliasing added by you. If it's possible I'd like to know if this flag is still needed and why? | 14:31 |
| vorlon | didrocks: LP: #1852256 is definitely filed in the wrong place, I wonder if Desktop wants to triage it a bit (not enough info to say if this is a desktop or kernel issue) | 14:55 |
| ubottu | Launchpad bug 1852256 in Ubuntu CD Images "Ubuntu ne s'ouvre plus après update" [Undecided,New] https://launchpad.net/bugs/1852256 | 14:55 |
| didrocks | vorlon: I doubt we can do anything about that bug, really vague and "I didn't do anything special". The user says that he is deleting it and reinstalling | 15:01 |
| didrocks | (posting once launchpad stops timeouting) | 15:05 |
| === ricab|lunch is now known as ricab | ||
| vorlon | didrocks: indeed. I just didn't know if there was a good generic place to reassign such bugs, since ubuntu-cdimage is wrong | 18:24 |
| === hyperair is now known as Guest84234 | ||
| doko | kanashiro: are you asking me about an upload from 2008? ;p | 19:03 |
| doko | seriously, check for warnings in the build logs | 19:03 |
| kanashiro | doko, no need to use a time machine :) I checked the logs and there is no warning related to this, I'll request a sync from Debian. Thanks | 19:09 |
| mwhudson | ginggs: thanks :) | 20:09 |
| ginggs | mwhudson: yw! i did python-qtawesome too | 20:56 |
| mwhudson | ginggs: thanks | 20:56 |
| mwhudson | pytest autopkgtest results looking a bunch happier now | 20:56 |
| === alan_g_ is now known as alan_g | ||
| Laney | cpaelzer: hey, can you re-check https://bugs.launchpad.net/ubuntu/+source/tpm2-tss/+bug/1841595 please? superm1 says all the issues should be resolved & it's now blocking fwupd from migrating | 23:16 |
| ubottu | Launchpad bug 1841595 in tpm2-tss (Ubuntu) "[MIR] tpm2-tss" [Undecided,Confirmed] | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!