Why doesn't inotify detect my file deletions on travis-ci? - travis-ci

My tests are failing on travis-ci because inotify is not delivering IN_DELETE or IN_DELETE_SELF events. On other Linux boxes, the code works correctly.
Here is a sample program that creates a file, watches it, deletes it, and then looks for an inotify event. This reports "inotify seems OK" on my Linux boxes, but that inotify is busted on travis-ci. No errors are reported - the file descriptor simply never becomes readable.
The kernel version on the travis-ci build is "2.6.32-042stab079.5", while inotify was merged in 2.6.13, so I expect inotify to work.
Is inotify supported on travis-ci? If so, why is my code not working? If not, how can I detect at build time or runtime whether inotify is supported, so I can use another code path?
Thanks for any help!

Related

Regarding scikit_learn installation

Hello and thank you for looking at this. I have been using docker to create various multi-arch builds. I have noticed some interesting behavior. When trying to run buildx for image creation, scikit_learn 0.21.3 takes a very long time to download/install (about 2.5 hours). However, when using the regular build command through docker on a single arch, it only takes about 10 minutes or so. The reason I am having to use this specific version of scikit_learn is due to an error I receive from my application where it is unable to find the sklearn.utils.linear_assignment module.
I receive this \nModuleNotFoundError: No module named 'sklearn.utils.linear_assignment_'
The only version I have been able to run is 0.21.3 up to this point. Having said that, I have found more recent versions do install much faster, but again they do not have the linear assigmment module, which is a dependency for my application. Any help or guidance would be greatly appreciated.

'daprd' is not recognized as an internal or external command, operable program or batch file

I am trying to debug a huge project using VS Code, the project is supposed to run on dapr using docker. I have installed dapr, docker, both seem to work fine. I also have VS Code, and I managed to get dapr extension for VS Code.
I build the project using dotnet build, no errors, so I am assuming that works fine, but when I try to debug it (run it) I get that error. I have read that it can be caused by having to set up environmental variables, but I don't know which environmental variables, as they seem to be present in the path (c:\users\myself.dapr\bin) is present.
So I have a few questions: what should I do now? and what is the reason behind it? Basically, I want to fix this, but knowing and understanding how, thanks.
As simple as restarting the laptop fix it, I guess that I did all of the installations without restarting and it needed a restart.
It was nothing to do with the environment variables in the end.

node webpack hangs. How to debug?

I am trying to build ORO Platform js assets, using a non-docker environment, it works like a charm, but in Docker (either during Docker Build, or container execution) the building process stop and hangs with 100% CPU.
67% [0] building 1416/1470 modules 54 active ... ndles/orotask/sidebar_widgets/assigned_tasks/css/styles.scss
The building process does not necessarily hang on the exact same file. And also, the build seems to succeed on some occasion.
I've try to reduce to a minimum the process by removing Happy, tested with --max-old-space-size=4096, but no luck.
Sources : https://github.com/oroinc/platform/tree/master/build
How would you recommend debugging this ?
Thanks
There is a known issue when a NodeJs process hangs while you run it from the root user. As I know, there is no workaround for now. Consider using another user to build the assets.
If it's not the case, please review the Troubleshooting section in OroAssetBundle, that might help.

Air application not packaging for iOS (air sdk 17)

I am posting this question because I stumbled upon the solution, despite not being able to find anything online which helped my specific problem. I am posting the accidental fix as an answer.
Problem: I am using adt.jar via cmd and an ANT script to package the air tablet application. Everything works fine on my workstation, but ipa builds fail on the build machine. The build machine is just a re-purposed workstation with more memory, larger hdd, and runs tomcat/hudson. Both environments are Win7 SP1. By 'everything' I mean apk builds in various configurations, and ipa builds with testing and production provisions files.
Error messages varied a little bit, but here are the common two messages:
Compilation failed while executing : compile-abc
Error #1042: Not an ABC file.
The stack dump was just a bunch of parameters passed into adt -- application specific.
Things I tried based on many internet searches:
Update to latest air 17 beta (17.115) Did not work. I did not expect this to fix my problem, because the PC which successfully builds the ipa does not have this version of the sdk
Hunted down empty case blocks in the code. There were a couple, but again this did not fix the problem. Still works on my machine and not the build machine. I actually made sure the empty blocks existed on the functional environment to disprove this attempt. I am not using "-useLegacyAOT no", so this should not have helped.
Compared all relevant environment vars between the two systems, and matched the ones that were different. This did not fix the issue.
Checked the version of jdk pointed to by JAVA_HOME. Both were already "64-Bit Server VM (build 20.45-b01, mixed mode)" aka: jdk-6u45-windows-x64.exe
Out of desperation, I ran Windows Update on the environment which failed to produce ipa files. There was a recommended update to the .NET framework which something in my tool chain must depend on. This fixed the problem.
Microsoft .NET Framework 4.5.2 for Windows 7 x64-based Systems (KB2901983)
My personal workstation is always up to date, and I restart often. This was not the case for the build workstation.
EDIT: A second update was also installed at the same time. This could be what fixed things, but I'm not going to question it.
Update for Windows 7 for x64-based Systems (KB3021917)

Wireshark Disscetor Error on Windows Platform

I am trying to build a dissector for Wireshark on Windows platform. But, I am getting an error.
I followed this link to install Wireshark from the source on windows, and I was able to build and run the software successfully.
Then using the README.plugins, I added a plugin, and did all the changes, mentioned in the file.
With the plugin, it built successfully, but whenever I tried running it, a dialog box appears stating The plugin 'ABC.dll' has neither a register routine, a register_tap_listener or a register_wtap_module or a register_codec_module routine.. Though wireshark is running fine, but my plugin is not included in it.
Linux Environment: I tried compiling and running on linux platform, and it worked fine, with the plugin included.Can anybody tell me, where I might be going wrong on the windows platform. Thanks.
There's a bit of magic which happens when building plugins on Windows so that certain symbols in the DLL are declared as exported so they can be found in the DLL at run-time. (I haven't recently dug into all the details, but the mechanism is different on *nix and so the results on each platform might be different).
What version of Wireshark are you building ? (How are you getting the Wireshark sources ?).
The specific error message you re getting suggests you might be building a version of WWireshark 1.10. (The message has changed in the Wireshark development version (1.11)).
In any case, something is not quite right (obviously) as to how the DLL is being built on Windows.
My suggestion as a starting point:
You might be able get an idea as to what's wrong by
comparing the plugin.c file (which is generated at build time) in your plugin directory on Windows with a plugin.c from one of the other Wireshark Windows plugin directories.
The magic occurs in that file.
Things like:
WS_DLL_PUBLIC_NOEXTERN void
plugin_reg_handoff(void)
{
{extern void proto_reg_handoff_unistim (void); proto_reg_handoff_unistim ();}
}

Resources