Re: Automatic ABI checks for new package updates in bodhi using taskotron
> Thanks for the quick review. I have addressed review comments and added new > diff at https://phab.qadevel.cloud.fedoraproject.org/D817?id=2081 . Thanks, looks good. I have no further concerns regarding the task code. > I am not > sure if I updated diff in right way but this is what I ended up by following > option "Update diff" available in right side :) Whatever works. Phabricator is not completely suited for reviewing patches from unknown projects, so it can be a bit cumbersome. But I needed a place where I can add comments to any line of the script (I think it's not possible to do on github). If we need to review any further changes, we can use Phab or github, doesn't matter. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: Automatic ABI checks for new package updates in bodhi using taskotron
> Hello Kamil, > > Sorry for replying late. I subscribed to this list, but for a reason the > emails are still not being delivered to me. I clicked on some more buttons > in the interface right now, so we'll see. In the mean time, I am using the > web interface to reply, so please forgive the awkward formatting that might > come out of this. Hello Dodji, welcome. > I think the test systems must have that kind of amount of memory. For most > packages, the memory consumption is reasonable. But for some packages where > the combination of ELF binary size and uncompressed debug info size is big, > then, well, the tool is going to require a lot of memory. For instance, it > takes 13+GB of memory to compare the ABI of two instances of the libjvm.so > library. I've read the backlog of your discussion with tflink, but I'm not sure what the conclusion is. I believe we can't assign 15GB RAM to all our test VMs (and we can't tie a specific task to a specific set of VMs at the moment). So I guess we will increase our test VMs memory to some "reasonable" amount and let the few extremely large packages crash with OOM. (That reminds me we should make sure to disable swap in VMs, otherwise that would kill the host). Do you have any advice what this "reasonable" amount of RAM should be? 4 GB? 6 GB? So that 95% of tasks work OK, and just the extreme ones crash. We can then add those to a blacklist. Speaking of lists, you and Tim were mentioning white/blacklists, also critpath set. So what is the ideal set of packages we should run on initially? All packages? Only critpath packages? Only libraries included in critpath? In case we should run just on libraries, any good recommendation how to recognize that (better than matching "lib*" in package name)? We would need to make the decision without downloading the package, but I guess we could query koji or repo metadata if necessary. We will need to implement white/blacklisting, ideally I'd like you to have the control over it, not us (so e.g. defining that in task.yaml formula). We can probably implement critpath support (recognizing what is in critpath and what is not), I'm sure it will be needed in other tasks in the future as well. Kamil ___ qa-devel mailing list qa-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: Automatic ABI checks for new package updates in bodhi using taskotron
On Thu, Apr 21, 2016 at 8:27 PM, Kamil Paral wrote: >> Hello Kamil, >> >> Sorry for replying late. I subscribed to this list, but for a reason the >> emails are still not being delivered to me. I clicked on some more buttons >> in the interface right now, so we'll see. In the mean time, I am using the >> web interface to reply, so please forgive the awkward formatting that might >> come out of this. > > Hello Dodji, welcome. > >> I think the test systems must have that kind of amount of memory. For most >> packages, the memory consumption is reasonable. But for some packages where >> the combination of ELF binary size and uncompressed debug info size is big, >> then, well, the tool is going to require a lot of memory. For instance, it >> takes 13+GB of memory to compare the ABI of two instances of the libjvm.so >> library. > > I've read the backlog of your discussion with tflink, but I'm not sure what > the conclusion is. I believe we can't assign 15GB RAM to all our test VMs > (and we can't tie a specific task to a specific set of VMs at the moment). So > I guess we will increase our test VMs memory to some "reasonable" amount and > let the few extremely large packages crash with OOM. (That reminds me we > should make sure to disable swap in VMs, otherwise that would kill the host). > Do you have any advice what this "reasonable" amount of RAM should be? 4 GB? > 6 GB? So that 95% of tasks work OK, and just the extreme ones crash. We can > then add those to a blacklist. > > Speaking of lists, you and Tim were mentioning white/blacklists, also > critpath set. So what is the ideal set of packages we should run on > initially? All packages? Only critpath packages? Only libraries included in > critpath? In case we should run just on libraries, any good recommendation > how to recognize that (better than matching "lib*" in package name)? We would > need to make the decision without downloading the package, but I guess we > could query koji or repo metadata if necessary. With latest commit [1] in libabigail taskotron task, ABI comparison will occur only on shared libraries because we call abipkgdiff with --dso-only option. So, if a package doesn't contains any library file, it won't run abi checks on files available in package.There is a related bug[2] which has already been fixed and will be available in next libabigail release. So, there is no need to look specifically for lib* package. Also, packages providing libraries may not start/contain *lib* (e.g. elfutils) in its name. So, let's say we initially start with packages available in critpath[3], then we don't have to worry whether a package provides any shared library or not. Our main concern would be which library in any of the critpath package consumes more memory (usage of memory is greater than available in spawned VM). [1] https://github.com/sinnykumari/task-libabigail/commit/752ace2c74b2ccc5aa37a3b6fcaa10e18d4d7cba#diff-70856293f092405ffacb0091cc57b0acR7 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19961 [3] https://admin.fedoraproject.org/pkgdb/api/critpath ___ qa-devel mailing list qa-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
