KDE CI: Plasma » plasma-mobile » kf5-qt5 SUSEQt5.15 - Build # 10 - Still Failing!
BUILD FAILURE Build URL https://build.kde.org/job/Plasma/job/plasma-mobile/job/kf5-qt5%20SUSEQt5.15/10/ Project: kf5-qt5 SUSEQt5.15 Date of build: Fri, 11 Feb 2022 05:22:41 + Build duration: 42 sec and counting CONSOLE OUTPUT [...truncated 230 lines...][2022-02-11T05:23:21.477Z] EXECUTOR_NUMBER = '0'[2022-02-11T05:23:21.477Z] CVS_RSH = 'ssh'[2022-02-11T05:23:21.477Z] DEBUGINFOD_URLS = 'https://debuginfod.opensuse.org/ '[2022-02-11T05:23:21.477Z] STAGE_NAME= 'Configuring Build'[2022-02-11T05:23:21.477Z] NODE_LABELS = 'Docker Swarm-699720fcff19 SUSEQt5.15'[2022-02-11T05:23:21.477Z] WORKSPACE_TMP = '/home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15@tmp'[2022-02-11T05:23:21.477Z] XDG_DATA_DIRS = '/home/jenkins/install-prefix/share:/usr/share:/usr/local/share:/usr/share'[2022-02-11T05:23:21.477Z] CONFIG_SITE = '/usr/share/site/x86_64-unknown-linux-gnu'[2022-02-11T05:23:21.477Z] PATH = '/home/jenkins/install-prefix/bin:/home/jenkins//bin:/usr/local/bin:/usr/bin:/bin'[2022-02-11T05:23:21.477Z] RUN_ARTIFACTS_DISPLAY_URL = 'https://build.kde.org/job/Plasma/job/plasma-mobile/job/kf5-qt5%20SUSEQt5.15/10/display/redirect?page=artifacts'[2022-02-11T05:23:21.477Z] PROFILEREAD = 'true'[2022-02-11T05:23:21.477Z] MAIL = '/var/spool/mail/jenkins'[2022-02-11T05:23:21.477Z] HOSTTYPE = 'x86_64'[2022-02-11T05:23:21.477Z] BUILD_ID = '10'[2022-02-11T05:23:21.477Z] LESSKEY = '/usr/etc/lesskey.bin'[2022-02-11T05:23:21.477Z] OLDPWD= '/home/jenkins'[2022-02-11T05:23:21.477Z] LC_CTYPE = 'C.UTF-8'[2022-02-11T05:23:21.477Z] CMAKE_PREFIX_PATH = '/home/jenkins/install-prefix:/usr/:/usr/local/'[2022-02-11T05:23:21.477Z] LD_LIBRARY_PATH = '/home/jenkins/install-prefix/lib:/home/jenkins/install-prefix/lib64'[2022-02-11T05:23:21.477Z] PKG_CONFIG_PATH = '/home/jenkins/install-prefix/lib64/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig'[2022-02-11T05:23:21.477Z] QT_PLUGIN_PATH= '/home/jenkins/install-prefix/lib64/plugins'[2022-02-11T05:23:21.478Z] QML2_IMPORT_PATH = '/home/jenkins/install-prefix/lib64/qml'[2022-02-11T05:23:21.478Z] QT_SELECT = 'qt5'[2022-02-11T05:23:21.478Z] LANG = 'en_US.UTF-8'[2022-02-11T05:23:21.478Z] XDG_CURRENT_DESKTOP = 'KDE'[2022-02-11T05:23:21.478Z] ASAN_OPTIONS = 'detect_leaks=0:new_delete_type_mismatch=0:detect_odr_violation=0:stack-use-after-scope=0:alloc_dealloc_mismatch=0'[2022-02-11T05:23:21.478Z] [2022-02-11T05:23:21.478Z] [2022-02-11T05:23:21.478Z] == Commencing Configuration:[2022-02-11T05:23:21.478Z] cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON -DCMAKE_INSTALL_PREFIX="/home/jenkins//install-prefix/" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DBUILD_COVERAGE=ON -DECM_ENABLE_SANITIZERS='address' "/home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15"[2022-02-11T05:23:22.045Z] -- The C compiler identification is GNU 11.2.1[2022-02-11T05:23:22.304Z] -- The CXX compiler identification is GNU 11.2.1[2022-02-11T05:23:22.304Z] -- Detecting C compiler ABI info[2022-02-11T05:23:22.304Z] -- Detecting C compiler ABI info - done[2022-02-11T05:23:22.304Z] -- Check for working C compiler: /usr/bin/cc - skipped[2022-02-11T05:23:22.304Z] -- Detecting C compile features[2022-02-11T05:23:22.304Z] -- Detecting C compile features - done[2022-02-11T05:23:22.304Z] -- Detecting CXX compiler ABI info[2022-02-11T05:23:22.562Z] -- Detecting CXX compiler ABI info - done[2022-02-11T05:23:22.562Z] -- Check for working CXX compiler: /usr/bin/c++ - skipped[2022-02-11T05:23:22.562Z] -- Detecting CXX compile features[2022-02-11T05:23:22.562Z] -- Detecting CXX compile features - done[2022-02-11T05:23:22.562Z] Installing in /home/jenkins/install-prefix. Run /home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15/build/prefix.sh to set the environment for plasma-mobile.[2022-02-11T05:23:22.562Z] fatal: HEAD does not point to a branch[2022-02-11T05:23:22.562Z] -- Looking for __GLIBC__[2022-02-11T05:23:22.821Z] -- Looking for __GLIBC__ - found[2022-02-11T05:23:22.821Z] -- Performing Test _OFFT_IS_64BIT[2022-02-11T05:23:22.821Z] -- Performing Test _OFFT_IS_64BIT - Success[2022-02-11T05:23:22.821Z] -- Performing Test HAVE_DATE_TIME[2022-02-11T05:23:23.080Z] -- Performing Test HAVE_DATE_TIME - Success[2022-02-11T05:23:23.080Z] -- Found Gettext: /usr/bin/msgmerge (found version "0.21") [2022-02-11T05:23:23.080Z] -- Found KF5I18n: /home/jenkins/install-prefix/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found version "5.91.0") [2022-02-11T05:23:23.080Z] -- Found X11: /usr/include [2022-02-11T05:23:23.080Z] -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so[2022-02-11T05:23:23.338Z] -- Looking for
KDE CI: Plasma » plasma-mobile » kf5-qt5 SUSEQt5.15 - Build # 9 - Failure!
BUILD FAILURE Build URL https://build.kde.org/job/Plasma/job/plasma-mobile/job/kf5-qt5%20SUSEQt5.15/9/ Project: kf5-qt5 SUSEQt5.15 Date of build: Fri, 11 Feb 2022 05:21:06 + Build duration: 36 sec and counting CONSOLE OUTPUT [...truncated 230 lines...][2022-02-11T05:21:40.637Z] EXECUTOR_NUMBER = '0'[2022-02-11T05:21:40.637Z] CVS_RSH = 'ssh'[2022-02-11T05:21:40.637Z] DEBUGINFOD_URLS = 'https://debuginfod.opensuse.org/ '[2022-02-11T05:21:40.637Z] STAGE_NAME= 'Configuring Build'[2022-02-11T05:21:40.637Z] NODE_LABELS = 'Docker Swarm-e395d17c6071 SUSEQt5.15'[2022-02-11T05:21:40.637Z] WORKSPACE_TMP = '/home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15@tmp'[2022-02-11T05:21:40.637Z] XDG_DATA_DIRS = '/home/jenkins/install-prefix/share:/usr/share:/usr/local/share:/usr/share'[2022-02-11T05:21:40.637Z] CONFIG_SITE = '/usr/share/site/x86_64-unknown-linux-gnu'[2022-02-11T05:21:40.637Z] PATH = '/home/jenkins/install-prefix/bin:/home/jenkins//bin:/usr/local/bin:/usr/bin:/bin'[2022-02-11T05:21:40.637Z] RUN_ARTIFACTS_DISPLAY_URL = 'https://build.kde.org/job/Plasma/job/plasma-mobile/job/kf5-qt5%20SUSEQt5.15/9/display/redirect?page=artifacts'[2022-02-11T05:21:40.637Z] PROFILEREAD = 'true'[2022-02-11T05:21:40.637Z] MAIL = '/var/spool/mail/jenkins'[2022-02-11T05:21:40.637Z] HOSTTYPE = 'x86_64'[2022-02-11T05:21:40.637Z] BUILD_ID = '9'[2022-02-11T05:21:40.637Z] LESSKEY = '/usr/etc/lesskey.bin'[2022-02-11T05:21:40.637Z] OLDPWD= '/home/jenkins'[2022-02-11T05:21:40.637Z] LC_CTYPE = 'C.UTF-8'[2022-02-11T05:21:40.637Z] CMAKE_PREFIX_PATH = '/home/jenkins/install-prefix:/usr/:/usr/local/'[2022-02-11T05:21:40.637Z] LD_LIBRARY_PATH = '/home/jenkins/install-prefix/lib:/home/jenkins/install-prefix/lib64'[2022-02-11T05:21:40.637Z] PKG_CONFIG_PATH = '/home/jenkins/install-prefix/lib64/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig'[2022-02-11T05:21:40.637Z] QT_PLUGIN_PATH= '/home/jenkins/install-prefix/lib64/plugins'[2022-02-11T05:21:40.637Z] QML2_IMPORT_PATH = '/home/jenkins/install-prefix/lib64/qml'[2022-02-11T05:21:40.637Z] QT_SELECT = 'qt5'[2022-02-11T05:21:40.637Z] LANG = 'en_US.UTF-8'[2022-02-11T05:21:40.637Z] XDG_CURRENT_DESKTOP = 'KDE'[2022-02-11T05:21:40.637Z] ASAN_OPTIONS = 'detect_leaks=0:new_delete_type_mismatch=0:detect_odr_violation=0:stack-use-after-scope=0:alloc_dealloc_mismatch=0'[2022-02-11T05:21:40.637Z] [2022-02-11T05:21:40.637Z] [2022-02-11T05:21:40.637Z] == Commencing Configuration:[2022-02-11T05:21:40.637Z] cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON -DCMAKE_INSTALL_PREFIX="/home/jenkins//install-prefix/" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DBUILD_COVERAGE=ON -DECM_ENABLE_SANITIZERS='address' "/home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15"[2022-02-11T05:21:40.896Z] -- The C compiler identification is GNU 11.2.1[2022-02-11T05:21:40.896Z] -- The CXX compiler identification is GNU 11.2.1[2022-02-11T05:21:40.896Z] -- Detecting C compiler ABI info[2022-02-11T05:21:40.896Z] -- Detecting C compiler ABI info - done[2022-02-11T05:21:40.896Z] -- Check for working C compiler: /usr/bin/cc - skipped[2022-02-11T05:21:40.896Z] -- Detecting C compile features[2022-02-11T05:21:40.896Z] -- Detecting C compile features - done[2022-02-11T05:21:41.154Z] -- Detecting CXX compiler ABI info[2022-02-11T05:21:41.154Z] -- Detecting CXX compiler ABI info - done[2022-02-11T05:21:41.154Z] -- Check for working CXX compiler: /usr/bin/c++ - skipped[2022-02-11T05:21:41.154Z] -- Detecting CXX compile features[2022-02-11T05:21:41.154Z] -- Detecting CXX compile features - done[2022-02-11T05:21:41.154Z] Installing in /home/jenkins/install-prefix. Run /home/jenkins/workspace/Plasma/plasma-mobile/kf5-qt5 SUSEQt5.15/build/prefix.sh to set the environment for plasma-mobile.[2022-02-11T05:21:41.154Z] fatal: HEAD does not point to a branch[2022-02-11T05:21:41.154Z] -- Looking for __GLIBC__[2022-02-11T05:21:41.154Z] -- Looking for __GLIBC__ - found[2022-02-11T05:21:41.154Z] -- Performing Test _OFFT_IS_64BIT[2022-02-11T05:21:41.411Z] -- Performing Test _OFFT_IS_64BIT - Success[2022-02-11T05:21:41.411Z] -- Performing Test HAVE_DATE_TIME[2022-02-11T05:21:41.411Z] -- Performing Test HAVE_DATE_TIME - Success[2022-02-11T05:21:41.411Z] -- Found Gettext: /usr/bin/msgmerge (found version "0.21") [2022-02-11T05:21:41.411Z] -- Found KF5I18n: /home/jenkins/install-prefix/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found version "5.91.0") [2022-02-11T05:21:41.669Z] -- Found X11: /usr/include [2022-02-11T05:21:41.669Z] -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so[2022-02-11T05:21:41.669Z] -- Looking for
Re: Plasma sprint doodle
We should wrap this as the dates are getting near. Should we do March 5th and 6th? On Mon, Jan 31, 2022 at 11:18 AM Marco Martin wrote: > > Hi all, > Here is a doodle with a bunch of dates to plan the sprint > https://doodle.com/poll/nvdyzp979y8dvfyd?utm_source=poll_medium=link > -- > Marco Martin > >
Re: plasma 5.24 tars ready for packaging
On 2/10/22 11:07, Ben Cooksley wrote: Hence the feeling of impending doom (imagine if you were getting a flood of bug reports about a single issue and knew that it was only going to get bigger before it got smaller) JFYI there is no need to imagine; that's literally the everyday reality for people doing bug triage. You get a flood of bug reports, you triage them and alert the developers, the developers try their best to fix the issue and eventually do so, you alert packagers to backport the fix as needed; this is how it works. Nate
Re: plasma 5.24 tars ready for packaging
On Fri, Feb 11, 2022 at 1:23 AM Aleix Pol wrote: > On Wed, Feb 9, 2022 at 11:05 AM Ben Cooksley wrote: > > > > On Wed, Feb 9, 2022 at 4:30 AM Nate Graham wrote: > >> > >> Much work is currently in progress to actually fix these issues. I see > >> multiple merge requests across multiple repos being reviewed and merged. > >> I think it makes sense to let that process happen. I see no indication > >> of the issue not being taken seriously, even considering the hyperbolic > >> and threatening way in which it was communicated mere days before a > >> major software release that is already occupying everyone's time. Let's > >> tone down the rhetoric and let developers do their jobs, now that > >> they've been made aware of this critical issue. > > > > > > Please note that it is extremely important that backports and the making > of releases containing those backports is a critical part of the process of > rectifying this issue. > > It cannot be left to just resolve itself via the organic process of > users updating their systems to major versions - because that won't happen > for months or longer and it is likely that the issue will continue to > intensify before it gets any better. > > > > Based on data we have we know that a big proportion of the traffic is > coming from KF 5.86 based systems so these patches need backporting as > distributions will not ship major version updates to these users. > > Patch releases however have a chance (especially if we prod packagers) > of making their way to those users within a matter of days. > > > > To date all mentions I have made of backports being essential have been > ignored. > > I don't know why you are saying you have been ignored. Distributions > were notified yesterday and I know at least a portion of them are > working on it. > Please note the timing of the email - it predates the backport request emails being sent. Now that the backports process is underway things are looking much better. > > This problem has been ongoing for several weeks now. Mitigations are > in place, let's give ourselves the time to react. > > I don't think that this general feeling of impending doom is making it > easier for anyone to address the problem. > Prior to the backport process getting underway we were facing the possibility of the issue dragging on for many months, with the issue potentially intensifying during that period. Hence the feeling of impending doom (imagine if you were getting a flood of bug reports about a single issue and knew that it was only going to get bigger before it got smaller) > > Thank you for caring. > Aleix > Thanks, Ben
Re: plasma 5.24 tars ready for packaging
On Wed, Feb 9, 2022 at 11:05 AM Ben Cooksley wrote: > > On Wed, Feb 9, 2022 at 4:30 AM Nate Graham wrote: >> >> Much work is currently in progress to actually fix these issues. I see >> multiple merge requests across multiple repos being reviewed and merged. >> I think it makes sense to let that process happen. I see no indication >> of the issue not being taken seriously, even considering the hyperbolic >> and threatening way in which it was communicated mere days before a >> major software release that is already occupying everyone's time. Let's >> tone down the rhetoric and let developers do their jobs, now that >> they've been made aware of this critical issue. > > > Please note that it is extremely important that backports and the making of > releases containing those backports is a critical part of the process of > rectifying this issue. > It cannot be left to just resolve itself via the organic process of users > updating their systems to major versions - because that won't happen for > months or longer and it is likely that the issue will continue to intensify > before it gets any better. > > Based on data we have we know that a big proportion of the traffic is coming > from KF 5.86 based systems so these patches need backporting as distributions > will not ship major version updates to these users. > Patch releases however have a chance (especially if we prod packagers) of > making their way to those users within a matter of days. > > To date all mentions I have made of backports being essential have been > ignored. I don't know why you are saying you have been ignored. Distributions were notified yesterday and I know at least a portion of them are working on it. This problem has been ongoing for several weeks now. Mitigations are in place, let's give ourselves the time to react. I don't think that this general feeling of impending doom is making it easier for anyone to address the problem. Thank you for caring. Aleix
Re: Critical Denial of Service bugs in Discover
On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley wrote: > > > > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol wrote: >> >> [Snip] >> >> We still haven't discussed here is how to prevent this problem from >> happening again. >> >> If we don't have information about what is happening, we cannot fix problems. > > > Part of the issue here is that the problem only came to Sysadmin attention > very recently, when the system ran out of disk space as a result of growing > log files. > It was at that point we realised we had a serious problem. > > Prior to that the system load hadn't climbed to dangerous levels (> number of > CPU cores) and Apache was keeping up with the traffic, so none of our other > monitoring was tripped. > > If you have any thoughts on what sort of information you are thinking of that > would be helpful. We could have plots of the amount of queries we get with a KNewStuff/* user-agent over time and their distribution. > It would definitely be helpful though to know when new software is going to > be released that will be interacting with the servers as we will then be able > to monitor for abnormalities. We make big announcements of every Plasma release... (?) >> Is there anything that could be done in this front? The issue here >> could have been addressed months ago, we just never knew it was >> happening. > > > One possibility that did occur to me today would be for us to integrate some > kind of killswitch that our applications would check on first initialisation > of functionality that talks to KDE.org servers. > This would allow us to disable the functionality in question on user systems. > > The check would only be done on first initialization to keep load low, while > still ensuring all users eventually are affected by the killswitch (as they > will eventually need to logout/reboot for some reason or another). > > The killswitch would probably work best if it had some kind of version check > in it so we could specify which versions are disabled. > That would allow for subsequent updates - once delivered by distributions - > to restore the functionality (while leaving it disabled for those who haven't > updated). The file we are serving here effectively is the kill switch to all of KNewStuff. Aleix
Re: Critical Denial of Service bugs in Discover
On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol wrote: > [Snip] > > We still haven't discussed here is how to prevent this problem from > happening again. > > If we don't have information about what is happening, we cannot fix > problems. > Part of the issue here is that the problem only came to Sysadmin attention very recently, when the system ran out of disk space as a result of growing log files. It was at that point we realised we had a serious problem. Prior to that the system load hadn't climbed to dangerous levels (> number of CPU cores) and Apache was keeping up with the traffic, so none of our other monitoring was tripped. If you have any thoughts on what sort of information you are thinking of that would be helpful. It would definitely be helpful though to know when new software is going to be released that will be interacting with the servers as we will then be able to monitor for abnormalities. (This would have allowed us to advise on the User-Agent stuff prior to September, as well as point out potential issues with caching > Is there anything that could be done in this front? The issue here > could have been addressed months ago, we just never knew it was > happening. One possibility that did occur to me today would be for us to integrate some kind of killswitch that our applications would check on first initialisation of functionality that talks to KDE.org servers. This would allow us to disable the functionality in question on user systems. The check would only be done on first initialization to keep load low, while still ensuring all users eventually are affected by the killswitch (as they will eventually need to logout/reboot for some reason or another). The killswitch would probably work best if it had some kind of version check in it so we could specify which versions are disabled. That would allow for subsequent updates - once delivered by distributions - to restore the functionality (while leaving it disabled for those who haven't updated). > > Aleix > Thanks, Ben
