With kernel > 3.19 sysdig driver does not compile dues to 'struct file' change and others changes in kernel headers i tested it with 3.19.x and 4.1.8 kernels sysdig 0.2.0 compiles from sources.
Assignee: bugsquad => doktor5000Source RPM: (none) => sysdigSeverity: normal => major
I suppose it affects cauldron too.
Whiteboard: (none) => MGA5TOOVersion: 5 => Cauldron
Sorry, totally forgotten about this, will take a look.
CC: (none) => doktor5000Status: NEW => ASSIGNED
For mga5 the problem is, we would need to either update jsoncpp so sysdig can build with it (we use an RC version of jsoncpp - 0.6.0-0.rc2.4.mga5) or switch sysdig to use a bundled copy of jsoncpp. I'd prefer the former for obvious reasons. jsoncpp is currently being maintained by dmorgan ... any opinions? Other affected packages seem to be apt, minetest, kopete and paraview. Should be fixed for cauldron with http://svnweb.mageia.org/packages?view=revision&revision=886634 and sysdig-0.2.0-1.mga6
CC: (none) => luigiwalser, rverschelde, stormi
(In reply to Florian Hubold from comment #3) > For mga5 the problem is, we would need to either update jsoncpp so sysdig > can build with it (we use an RC version of jsoncpp - 0.6.0-0.rc2.4.mga5) or > switch sysdig to use a bundled copy of jsoncpp. I'd prefer the former for > obvious reasons. Yeah, if it can be built against the system one in Cauldron, it can be in Mageia 5. > jsoncpp is currently being maintained by dmorgan ... any > opinions? He hasn't been maintaining anything for a while. dlucio recently updated jsoncpp it to 1.6.5 in Cauldron. It didn't change the libmajor, so it might work fine in Mageia 5 if it needs to be updated. > Other affected packages seem to be apt, minetest, kopete and > paraview. Affected how and by what?
(In reply to Florian Hubold from comment #3) > Other affected packages seem to be apt, minetest, kopete and paraview. Not minetest actually, I built it against the bundled jsoncpp because upstream uses an old patched version (grmbl...) and if built against the system jsoncpp, the game crashes when retrieving the list of game servers... (see http://svnweb.mageia.org/packages/updates/5/minetest/current/SPECS/minetest.spec?view=markup)
urpmq shows only kodi, apt, paraview, and sysdig using the jsconcpp library.
(In reply to David Walser from comment #6) > urpmq shows only kodi, apt, paraview, and sysdig using the jsconcpp library. I did a grep in older cauldron spec collection. What was your exact query? Something like "urpmf --requires -l libjsoncpp.so|cut -d':' -f1|sort -u" ? FWIW, jsoncpp has some interesting release scheme, check https://github.com/open-source-parsers/jsoncpp/releases Earlier we were on old 0.x branch with 0.6 rc, and in cauldron we're at 1.6.5 We would need to upgrade in mga at least to one of the 0.10.x branch releases to have some supported version. Release scheme is partly described in https://github.com/open-source-parsers/jsoncpp/releases/tag/0.8.0 I've built 1.6.5 on mga5, can try a rebuild of kodi, apt and paraview.
(In reply to Florian Hubold from comment #7) > (In reply to David Walser from comment #6) > > urpmq shows only kodi, apt, paraview, and sysdig using the jsconcpp library. > > I did a grep in older cauldron spec collection. What was your exact query? > Something like "urpmf --requires -l libjsoncpp.so|cut -d':' -f1|sort -u" ? Yikes! urpmq --whatrequires libjsoncpp0
OK, with newer jsoncpp, kodi seems to need an explicit include added on iostream in pvr-addons/addons/pvr.filmon/src/FilmonAPI.cpp (fix queued locally) and then it builds fine. Not sure why the build works in cauldron where we also have newer jsoncpp. apt and paraview rebuild just fine with newer jsoncpp without changes. So any objections on pushing jsoncpp 1.6.5 to mga5 together with sysdig 0.2.0 ? Shall I open a seperate bug for jsoncpp update?
Whiteboard: MGA5TOO => (none)Hardware: x86_64 => AllVersion: Cauldron => 5
No objections. If they go together, go ahead and do it in the same bug.
Seems somehow I forgot about this report :/ Already committed the updates for sysdig and jsoncpp, luckily committed the fixed kodi build already earlier. Once they're all submitted will assign to QA with an advisory.
sysdig-0.2.0-1.mga5 and jsoncpp-1.6.5-1.mga5 have already been uploaded to core/updates_testing, but kodi cannot be rebuilt, as it seems some libsmbclient packages (maybe only -devel) seem missing. Wrote mail to our friendly sysadmins, and will write advisory for sysdig tomorrow.
I have uploaded a patched/updated package for Mageia 5. You can test this by installing sysdig (will automatically install dkms-sysdig) and try to load the sysdig-probe module via modprobe, and try to use sysdig e.g. by using the ncurses frontend csysdig. Some more documentation and examples for sysdig are shown at http://www.sysdig.org/wiki/sysdig-examples/ As noted previously, to allow the newer sysdig version to build, jsoncpp had to be updated. Our old jsoncpp version was outdated, 0.6 was released 2011 and was not updated since. For the newer jsoncpp package, kodi needed a small fix to allow it to build again, I also pushed a new build to updates_testing but that does not need to be validated IMHO. I don't have a testcase for jsoncpp. Suggested advisory: ======================== With kernel >= 3.19 the sysdig-probe kernel module could not be build, this update fixes this by updating sysdig to 0.2.0. References: https://bugs.mageia.org/show_bug.cgi?id=16911 ======================== Updated packages in core/updates_testing: ======================== i586 sysdig-0.2.0-1.mga5.i586 x86_64 sysdig-0.2.0-1.mga5.x86_64 Source RPMs: sysdig-0.2.0-1.mga5.src.rpm ======================== Updated packages in core/updates_testing for jsoncpp ======================== i586 libjsoncpp-devel-1.6.5-1.mga5.i586 libjsoncpp0-1.6.5-1.mga5.i586 x86_64 lib64jsoncpp-devel-1.6.5-1.mga5.x86_64 lib64jsoncpp0-1.6.5-1.mga5.x86_64 Source RPMs: jsoncpp-1.6.5-1.mga5.src.rpm
Assignee: doktor5000 => qa-bugs
I would say that the Kodi fix should probably be released as well to make sure that we still have good SRPMS on the mirrors. For that, you'd probably want to let the Kodi maintainer have a look to see if they want to do any other changes to it and handle it in another bug report. IIRC, Kodi bundles ffmpeg, so it probably needs to be updated for security issues at the very least anyway.
(In reply to David Walser from comment #14) > For that, you'd probably want to let the Kodi maintainer have a look Already did last week, waiting for a reply ...
Testing complete mga5 64 Before ------ Preparing... ########## 1/4: luajit-common ########## 2/4: lib64luajit5.1_2 ########## 3/4: sysdig ########## 4/4: dkms-sysdig ########## Creating symlink /var/lib/dkms/sysdig/0.1.89-3.mga5/source -> /usr/src/sysdig-0.1.89-3.mga5 DKMS: add Completed. Preparing kernel 4.1.13-desktop-2.mga5 for module build: (This is not compiling a kernel, just preparing kernel symbols) Storing current .config to be restored when complete Running Generic preparation routine make mrproper...... using /proc/config.gz make oldconfig..... make prepare.... Building module: cleaning build area.... make KERNELRELEASE=4.1.13-desktop-2.mga5 -C /lib/modules/4.1.13-desktop-2.mga5/build M=/var/lib/dkms/sysdig/0.1.89-3.mga5/build....(bad exit status: 2) Error! Bad return status for module build on kernel: 4.1.13-desktop-2.mga5 (x86_64) Consult the make.log in the build directory /var/lib/dkms/sysdig/0.1.89-3.mga5/build/ for more information. modprobe: FATAL: Module sysdig-probe not found. warning: %post(dkms-sysdig-0.1.89-3.mga5.noarch) scriptlet failed, exit status 1 ERROR: 'script' failed for dkms-sysdig-0.1.89-3.mga5 After ----- Not mentioned in advisory but dkms-sysdig rpm is also part of this update. # urpmi sysdig To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates Testing") dkms-sysdig 0.2.0 1.mga5 noarch (recommended) sysdig 0.2.0 1.mga5 x86_64 3MB of additional disk space will be used. 509KB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) y installing dkms-sysdig-0.2.0-1.mga5.noarch.rpm sysdig-0.2.0-1.mga5.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ########## 1/2: sysdig ########## 2/2: dkms-sysdig ########## Creating symlink /var/lib/dkms/sysdig/0.2.0-1.mga5/source -> /usr/src/sysdig-0.2.0-1.mga5 DKMS: add Completed. Preparing kernel 4.1.13-desktop-2.mga5 for module build: (This is not compiling a kernel, just preparing kernel symbols) Storing current .config to be restored when complete Running Generic preparation routine make mrproper..... using /proc/config.gz make oldconfig..... make prepare.... Building module: cleaning build area.... make KERNELRELEASE=4.1.13-desktop-2.mga5 -C /lib/modules/4.1.13-desktop-2.mga5/build M=/var/lib/dkms/sysdig/0.2.0-1.mga5/build...... cleaning build area.... cleaning kernel tree (make mrproper)..... DKMS: build Completed. sysdig-probe.ko.xz: - Installation - Installing to /lib/modules/4.1.13-desktop-2.mga5/dkms/extra/ depmod...... DKMS: install Completed. Also noted it fails without the newer lib64jsoncpp0 installed, so it's a runtime requirement too. # sysdig sysdig: symbol lookup error: sysdig: undefined symbol: _ZN4Json5Value7nullRefE With the new lib installed, tried a few examples from the man page.. eg. # sysdig -c spy_ip <IP of your adapter> # sysdig "evt.type in ( 'select', 'poll' )" Stumbled around in csysdig ncurses gui too which is a bit like htop. All appears to be working OK.
Whiteboard: (none) => has_procedure mga5-64-ok
Not clear from the above. Should jsoncpp-1.6.5-1.mga5.src.rpm be included in the advisory?
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #17) > Not clear from the above. Should jsoncpp-1.6.5-1.mga5.src.rpm be included in > the advisory? Yes, it was needed to build this update.
Whiteboard: has_procedure mga5-64-ok => has_procedure mga5-64-ok advisoryKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0195.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
The updated kodi package is still lingering in updates_testing. Should we just push it?