Fix localMidnight

In some cases localMidnight(longitude:) returns wrong value.
let jd = JulianDay(year: 2016, month: 12, day: 20, hour: 3, minute: 5, second: 3.5)

let longitude4 = 90.0.degrees
print(jd.localMidnight(longitude: longitude4).date)
// Prints 2016-12-20 06:00:00 +0000

If we're on longitude W 90, and current time is December 20th, 03:05 UTC, then the date is not actually December 20th for us yet. December 20th will come when time is December 20th, 06:00 UTC.

So what is December 20th, 03:05 UTC on longitude W 90?

It's evening of December 19th. I.e. by local time it would be December 19th, 21:05.

So which date is it?

December 19th.

So what's the UTC time of local midnight?

December 19th, 06:00 UTC.

Hello Andris. Thanks for questioning this. It is really a tricky question, and we may need to actually change the method signature instead.
This method is intended to not refer to any date object, as it is a complex concept. The idea is to have a simple mean to have a geographic/longitudinal shift from midnight UTC. In that sense, it is not the midnight in the usual human sense. Move left or right in longitude by some kilometers, and the the value will change.
In that sense, the method provides this convenient shift. Mut maybe we should find some better naming?

I see. I have say I had a suspicion that it could be that this is the intended way. So it's only about naming then.
Perhaps we could have it like this:

public func localMidnight(for longitude: Degree) -> JulianDay
public func midnight(for timeZone: TimeZone) -> JulianDay

Or perhaps the new one could be
public func midnightOfCurrentDate(for timeZone: TimeZone) -> JulianDay

I was just thinking. Is localMidnight really doing what you want it to do?
Look at this use case:
func twilights(forSunAltitude sunAltitude: Degree, coordinates: GeographicCoordinates) -> (rise: JulianDay?, transit: JulianDay?, set: JulianDay?, error: CelestialBodyTransitError?) {

        var error: CelestialBodyTransitError? = nil

        let jd_midnight = self.julianDay.localMidnight(longitude: coordinates.longitude)
        let sun_midnight = Sun(julianDay: jd_midnight)
        if sun_midnight.makeHorizontalCoordinates(with: coordinates).altitude > sunAltitude {
            error = .alwaysAboveAltitude
        }

Given Sun instance on a particular JulianDay, you convert the JulianDay to local midnight to check whether Sun actually goes below requested altitude (the rationale being that at midnight it might be approximately at the lowest point).
OK, let's think about it. Say we:

created a Date 2016-12-31 20:00:00 +0000 (JD 2457754.33)
converted it to a JulianDay
created Sun with that JulianDay

The date that we created corresponds to 2017-01-01 07:00:00 +11h (Sydney time)
So what will localMidnight do?

return self.midnight + longitude.inHours.inJulianDays

self.midnight is calculated as JulianDay((value - 0.5).rounded(.down) + 0.5)

i.e. floor(JD 2457754.33 - 0.5) + 0.5 = JD 2457753.5 or more simply - drop all the hours past 00:00 UTC. Result will be 2017-12-31 00:00:00 +0000

longitude of Sydney is -151.2, i.e. -10.08 hours or -0.42 JulianDay
final result = JD 2457753.5 - 0.42 = JD 2457753.08 or 2016-12-30 13:55:12 +0000 which by Sydney time is 2016-12-31 01:55:12.

So when calculating twilights for date that corresponds to local time 2017-01-01 07:00:00 we will check whether sun was below altitude at midnight for previous day i.e. 2016-12-31 01:55:12. I think this will give us incorrect results as we should have calculated local midnight to be 2017-01-01  01:55:12

There is another, perhaps simpler perspective.

midnight drops all the hours past 00:00 UTC
localMidnight(longitude:) does this:

calculate midnight, i.e. drop all hours (potentially change up to -0.9999 JD)
adds longitude hours which for eastern longitudes means reducing value even more (potentially up to -0.5 JD)

So the final result may differ from the original date by almost -1.5 JD. That will not be the nearest local midnight.

Hm, that's a thorough check of this problematic midnight. I am not the original author of this function. If I read the associated documentation, it reads

Returns the Julian Day corresponding to the Greenwhich midnight before the actual value

But the first -0.5 operation is there probably to ensure somehow to round correctly towards a date before the actual value. As see it today, this comes with an additional .rounded(.down). This makes no sense to have both.
I think that this method could simply be written return value.rounded(.down) and it would satisfy the definition, and fix the problems you describe here above, isn't it?

I think midnight is correct.
public var midnight: JulianDay { return JulianDay((value - 0.5).rounded(.down) + 0.5) }

Both 0.5 values are there because Julian Days are counted from noon time instead of midnight.
Since Julian Days are counted from noon, midnight in UTC will always have 0.5 at the end. That's why if we want to round down hours after the midnight, we remove 0.5, round and then add 0.5 back.
Having return value.rounded(.down) would return noon time in UTC before the actual value.

You're right. I am trying to play with it now, I see I'm mistaken.
So what is wrong is to consider that, to compute midnight in somewhere else than Greenwich, one needs to compute it first for Greenwich and then shift it by longitude, no?
So we keep midnight as it is (maybe renaming it as midnightUTC or something else), and work on making localMidnight(for longitude|timeZone) correct.

While playing with the code, I think the handling of errors in the function     func twilights(forSunAltitude sunAltitude: Degree, coordinates: GeographicCoordinates) -> (rise: JulianDay?, transit: JulianDay?, set: JulianDay?, error: CelestialBodyTransitError?) is wrong too.
I mean, I use computations outside the RiseTransitSetTimes function to infer values .alwaysAbove|BelowAltitude. That's risky. I'll work to better infer meaningful errors from basic error flags returned by RiseTransitSetTimes.

So what is wrong is to consider that, to compute midnight in somewhere else than Greenwich, one needs to compute it first for Greenwich and then shift it by longitude, no?

Yes.

So we keep midnight as it is (maybe renaming it as midnightUTC or something else), and work on making localMidnight(for longitude|timeZone) correct.

Well, localMidnight(for timeZone:) is already correct. At least as far as I know (timezones are tricky :))
public func midnight(for timeZone: TimeZone) -> JulianDay {
    let offsetFromGMT = JulianDay(Double(timeZone.secondsFromGMT(for: self.date)) / (60*60*24))
    return (self + offsetFromGMT).midnight - offsetFromGMT
}

midnight is calculated for offset value, and then the offset is removed.

I've juste committed a new implementation of localMidnigt(for longitude) method, covered by additional tests. I think, I got it right now. Can you have a look, and possibly close the issue? Thanks!

I will take a look. But I wonder why didn't you use the one-liner I introduced in #55? :)
public func localMidnight(longitude: Degree) -> JulianDay {
    return (self - longitude.inHours.inJulianDays).midnight + longitude.inHours.inJulianDays
}

Does the new implementation returns different results? Also please note that we'd still need localMidnight for time zone because of #56

Interestingly, there is one single test that fails with your one-liner. I couldn't investigate more, but here is a screenshot. Interesting.

Ah, interesting. I will check this.

Oh, take a look at this:
public struct Degree: NumericType, CustomStringConvertible {
      ...
      public var inHours: Hour { return Hour(value / 15.0) }
      ...
}

let longitude8 = -360.0.degrees
print(longitude8.inHours)
// prints: -24h0m00.000s
// is this correct?

Well, yes this is technically correct, since there is no automatic "reduction" to a range like, say, [-180,180[ for instance. But where does it lead us?
Note that I've worked quite a bit on the rise transit and set functions. This is because I wanted to reproduce the values produced by the C++ tests. Unfortunately, these tests only print values out and dont really test anything. When trying to reproduce the rise and set times of Mercury in March 1st, 2038 (as in the C++ tests), I fixed quite a few details. But I also broke some other ones. And if you look at the code today, some tests do not pass anymore.

But I am unsure of where does this question lead us somewhere?

I asked because I used inHours in my one-liner for localMidnight and thought that it provides reduced hours for a given longitude.
Let's throw out my implementation and use yours 👍🏻

Note that I've worked quite a bit on the rise transit and set functions. This is because I wanted to reproduce the values produced by the C++ tests.

Looks like you don't use localMidnight anymore for RiseTransitSet. I'm OK with that, I will pre-calculate midnights for time zone myself. That actually means that we don't need midnight(for: TimeZone) anymore.

When trying to reproduce the rise and set times of Mercury in March 1st, 2038 (as in the C++ tests), I fixed quite a few details. But I also broke some other ones. And if you look at the code today, some tests do not pass anymore.

I see, can't comment much regarding those tests. I'm mostly checking Sun and Moon data against USNO.

A quick note. I have not checked more rise transit and set stuff for Sun and Moon, but I managed to get solar system objects times right. I'm not using localMidnight, as AA book is very precisely stating that coordinates must be computed for 0h Dynamical Time (which is basically midnight UT, not the local midnight). I'll thus close this issue.


interrupt when import by arangoimp

Hi, when I import data by arangoimp, it will be interrupt and show
ERROR error message:    Expecting type Array (exception location: /home/abuild/rpmbuild/BUILD/arangodb-3.0.8/arangod/HttpServer/HttpHandler.cpp:157). Please report this error to arangodb.com
My arangodb cluster:
system: centos7
arangodb version: 3.0.8
cluster: 3 agency, 2 dbserver, 1 coordinator(<IP_ADDRESS>:8531)
cluster was setup by the method of arangodb manual Chapter "Deployment -- Cluster: Processes"
My import command(run this command on one dbserver):
arangoimp --collection my_coll --batch-size 67108864 --on-duplicate "update" --progress true --file "my_file" --type "csv" --separator "," --log.level "debug" --log.use-local-time true --server.authentication false --server.database my_db --server.endpoint "http+tcp://<IP_ADDRESS>:8531"
context of my imported datafile("my_file"), There are about 6 million lines in the file:
"_key","t1","t2","t3","t4"
"11111111","aaa2","bbb2","ccc2",ddd2"
"22222222","aaa2","bbb2","ccc2",ddd2"

Error was occurred when the progress 51% and 69%, I tried twice
First try:
Starting CSV import...
2016-09-27T15:41:07 [11673] INFO processed 10387456 bytes (3%) of input file
2016-09-27T15:41:07 [11673] INFO processed 20742144 bytes (6%) of input file
2016-09-27T15:41:07 [11673] INFO processed 31096832 bytes (9%) of input file
2016-09-27T15:41:07 [11673] INFO processed 41484288 bytes (12%) of input file
2016-09-27T15:41:07 [11673] INFO processed 51838976 bytes (15%) of input file
2016-09-27T15:41:31 [11673] INFO processed 62193664 bytes (18%) of input file
2016-09-27T15:41:32 [11673] INFO processed 72548352 bytes (21%) of input file
2016-09-27T15:41:32 [11673] INFO processed 82935808 bytes (24%) of input file
2016-09-27T15:41:32 [11673] INFO processed 93290496 bytes (27%) of input file
2016-09-27T15:41:32 [11673] INFO processed 103645184 bytes (30%) of input file
2016-09-27T15:41:32 [11673] INFO processed 113999872 bytes (33%) of input file
2016-09-27T15:42:21 [11673] INFO processed 124387328 bytes (36%) of input file
2016-09-27T15:42:22 [11673] INFO processed 134742016 bytes (39%) of input file
2016-09-27T15:42:22 [11673] INFO processed 145096704 bytes (42%) of input file
2016-09-27T15:42:22 [11673] INFO processed 155451392 bytes (45%) of input file
2016-09-27T15:42:22 [11673] INFO processed 165838848 bytes (48%) of input file
2016-09-27T15:42:22 [11673] INFO processed 176193536 bytes (51%) of input file
2016-09-27T15:43:34 [11673] INFO processed 186548224 bytes (54%) of input file
2016-09-27T15:43:35 [11673] INFO processed 196902912 bytes (57%) of input file
2016-09-27T15:43:35 [11673] INFO processed 207290368 bytes (60%) of input file
2016-09-27T15:43:35 [11673] INFO processed 217645056 bytes (63%) of input file
2016-09-27T15:43:35 [11673] INFO processed 227999744 bytes (66%) of input file
2016-09-27T15:43:35 [11673] INFO processed 238354432 bytes (69%) of input file

2016-09-27T15:44:53 [11673] ERROR error message:    Expecting type Array (exception location: /home/abuild/rpmbuild/BUILD/arangodb-3.0.8/arangod/HttpServer/HttpHandler.cpp:157). Please report this error to arangodb.com

second try:
Starting CSV import...
2016-09-27T16:00:27 [12118] INFO processed 10387456 bytes (3%) of input file
2016-09-27T16:00:27 [12118] INFO processed 20742144 bytes (6%) of input file
2016-09-27T16:00:27 [12118] INFO processed 31096832 bytes (9%) of input file
2016-09-27T16:00:27 [12118] INFO processed 41484288 bytes (12%) of input file
2016-09-27T16:00:27 [12118] INFO processed 51838976 bytes (15%) of input file
2016-09-27T16:01:02 [12118] INFO processed 62193664 bytes (18%) of input file
2016-09-27T16:01:02 [12118] INFO processed 72548352 bytes (21%) of input file
2016-09-27T16:01:02 [12118] INFO processed 82935808 bytes (24%) of input file
2016-09-27T16:01:02 [12118] INFO processed 93290496 bytes (27%) of input file
2016-09-27T16:01:02 [12118] INFO processed 103645184 bytes (30%) of input file
2016-09-27T16:01:02 [12118] INFO processed 113999872 bytes (33%) of input file
2016-09-27T16:01:31 [12118] INFO processed 124387328 bytes (36%) of input file
2016-09-27T16:01:31 [12118] INFO processed 134742016 bytes (39%) of input file
2016-09-27T16:01:31 [12118] INFO processed 145096704 bytes (42%) of input file
2016-09-27T16:01:31 [12118] INFO processed 155451392 bytes (45%) of input file
2016-09-27T16:01:31 [12118] INFO processed 165838848 bytes (48%) of input file
2016-09-27T16:01:31 [12118] INFO processed 176193536 bytes (51%) of input file

2016-09-27T16:02:43 [12118] ERROR error message:    Expecting type Array (exception location: /home/abuild/rpmbuild/BUILD/arangodb-3.0.8/arangod/HttpServer/HttpHandler.cpp:157). Please report this error to arangodb.com

Maybe the command line statements which you have used are not correct absolutely.

Could you point out what's wrong with statements?
I also get this error when use http request '_api/import'.
The error is not arise at the beginning, it seems that more data in arangodb, more chance the error arised.

Please note that the batch size is pretty big. If documents composed exceed the maximum server post data size, errors like this may occur. This stackoverflow question could be related?

Hi, I'm afraid is not caused by batch size.
I do some test again:
This time I use the http request '_api/import' with small batch each request, and when error(the same error I described above) occured, I waited for 30 seconds and reimport the data which caused that error, and it successed.
So I continue import by this manner. But when data in arangodb growth bigger, it can't success import anymore. I have halt the import programme for a whole night, and I retry start import on the morning, it failed.
My cluster setup:

I use the two-master mode, 3 agencies, 2 master, 2 coordinators
arangodb verison 3.0.10
Three agency run on three virtual machines respectively
There are two physical machines, one db-server and one coordinator run on each machine respectively. And these two physical machines only used for arango, no other programmes run on them.

collection setup:

2 document collections, 2 edge collections
4 shardings for each collection
2 replica factors for each collection
all collections's waitForSync=true, and the import option is also set waitForSync=true
after create the collections, I stop the master_2 process for a few minutes until all the collection leaders transfer to master_1, and then restart master2 process
when start to import by http request '_api/import', I use the address of coord_1's(on the same machine of master_1)

There are some phenomena I observed:

When the number of documents close to 70 million and number of edges close to 200 million, it will be can't import anymore. I try the whole test twice, it almost the same
After I halt the import programme, the two db servers still have massive network I/O and disk I/O(yes, until now, halt for more than 12 hours)
When it can't import anymore, the UI of coord_1 also can't open, and UI of coord_2 can open but can't show node infomation etc
The size of data file on master_1 is 33G, but the size of data file on master_2 is only 3.1G
The free memory and free disk space is still plenty

Some question:

Is it because of there are a lot of data cached in memory other than direct write in disk?
Because I set waitForSync=true, the data should be writen to all master nodes before return the http request. So why the size of data file is different on two master nodes?

@name-yy : a few questions back that may help us a bit in diagnosing what is happening:

are you importing all data into the document collections first and into the edge collections only after that? Or are you doing an interleaved import that imports fractions into both the document collections and the edge collections?
does the import process stop at a specific point, e.g. always when importing into a specific collection, or is this more or less random?
regarding the different datasizes on the servers: by what attributes are the data sharded (i.e. which shardKeys value do you use for the collections)? And how do the values for the shard keys look like? Could you provide some examples?

I imports fractions into both the document collections and the edge collections
the import process stop randomly at the beginning, but the final stop(I mean after this import error, I can't to import anymore) it seems stopped on importing the edge collection(the biggest collection, about 0.2 billion items)
the shard key is "_key" in every collection

the data in document collection is {"_key":"11111111111", "attr_1":"11111111111", "attr_2": "xx", "attr_3": 0}
the data in edge collection is {"_key": "1111111111122222222222", "_from": "11111111111", "_to": "22222222222", "attr_1": 23, "attr_2": 1.43, "attr_3":<PHONE_NUMBER>}
in each import, I make a http request to imoprt a batch of 2000~3000 items of documents, and after the request return, I make another http request to import a batch of 3000~4000 items of edges.

Closing this as duplicate of #2158.


Contact us page functionality

The input section of contact us page is not getting cleared after submission of one detail. addittionaly we must pop out an alert on submission to let user know that his/her details has been submitted. @tushargupta1504  @Natasha2342  please assign this to me under  gssoc and hactober fest accepted and with appropriate levels.

it is resolved already


iso: only include the host's dependencies

fixes #194
I've only tested that the iso build evaluates. I still have to test that it builds. And this change could break the current iso build, so it definitely has to be tested thoroughly.
I came up with a pretty simple solution though, so I thought I may as well share it. Instead of importing all modules, I just added the hosts toplevel into the iso's storeContents.
cc @blaggacao

This looks great!
I was wanting to devise a way to actually test the iso as part of CI, but building the actual iso image itself is quite expensive both in space and time. Not sure if there would be any other way to reliably test it on each change though without having to build and squash the image.
If we can come up with something, perhaps we can include it in this PR.

This is really elegant, but at least we would need the (basic) user profiles so that remote access still works. Maybe re-importing the base suite suffices. Basically replicate how it is done here. That would solve this problem and not break the docs (though complementing them is necessary).

I was wanting to devise a way to actually test the iso as part of CI, but building the actual iso image itself is quite expensive both in space and time. Not sure if there would be any other way to reliably test it on each change though without having to build and squash the image.

I would like to see that too. But it does take a while to build the iso. Perhaps if we could just import the iso modules into the test node and inspect different parts of the machine once started up.

Maybe re-importing the base suite suffices. Basically replicate how it is done here. That would solve this problem and not break the docs (though complementing them is necessary).

I didn't even think of that! Yeah I knew this would break things, thanks for figuring what exactly it broke :)
So I tried adding the base suite, but then that runs into the problem of home-manager missing. I think getting that to work will require a rework of hosts/default.nix and devosSystem. We might want to consider not passing ALL the modules as one list and instead seperating them. Or passing them as an attrset, so different parts of devosSystem can pick apart the necessary modules. And then a final attrValues of the attrset could be used in the final host.

With #198, I can selectively import the base suite and flakeModules - which contains home-manager. Since those are the only two that declare new options(I think!), I think that should get any user's base suite to evaluate.

I think core is valuable too for the unified "sysadmin experience".

Yeah I'm actually thinking now of just including everything but local and lib.

That is a good idea, the environments should be probably as close as possible in every aspect, just not starting more systemd services than declared in suites.base and profiles/core.
I have a hard time following up on the home-mamager problwm you reported. What is it about?

That is a good idea, the environments should be probably as close as possible in every aspect, just not starting more systemd services than declared in suites.base and profiles/core.

I add a change to forward environment.systemPackages. But either way every other dependency is in the store, they just have to be installed to the profile.

I have a hard time following up on the home-mamager problwm you reported. What is it about?

So the base suite imports the users which set the home-manager options. But without importing extern, those options don't exist, so the evaluation fails. And it indicates a general problem with trying to import parts of the host's config without the necessary modules. If a user had declared options in a custom module, then importing the base suite would then fail.

Ok, I understand. So we need to make sure to actually import all modules but only core, nixos-user and root-user profiles. Right?

For a live installer we actually only need core + root. We can drop nixos. We should actually drop nixos, since deploy-rs does require passwordless sudo and it's quite easy to set a password for nixos during install (you are prompted).

Filtering out users is a good idea, but does the root user have ssh access to the iso by default? So if I understand right, the user adds an ssh public key to the root user module which is imported to the iso build. And then you can now ssh into the system as the root user.  But we don't want to include the other users as that would be unnecessary and will likely have a password.
So instead of importing the base suite, I'm now just importing suites.allUsers.root.

I have occasion to test this out as it looks like I fudged my zfs ashift settings and need to recreate my pool. I'll report back how it goes.

Updated to include core, global, flakeModules, and modOverrides. The last two aren't really necessary, but they will prevent an evaluation failure in the rare case someone uses home-manager or sets some other option expecting an overridden module

but does the root user have ssh access to the iso by default?

No, but it is documented how to do that. Wording might be in need of alight tweaking after this discussion.

Updated to include core, global, flakeModules, and modOverrides.

I think this is actually necesarry (and all other modules, too) in order to be robust.
 Actually a positive one is not correct here.

@blaggacao I'm not entirely sure what you mean? Isn't the goal here to only import the necessary things as to prevent unecessary system startup while still copying the closure. And with that in mind I would think a positive selector is better. So in the future if more modules get added, we have to go through and evaluate if they should be in the isoConfig.
Could you perhaps share a nix expression as to what should be imported. I think might clear up confusion.

If we really wanted to go deep. We could pass args to each module manually, and then, if the module happens to define a systemd service, we can filter it out of it's config session before including it. Might be more complex than it sounds though.

The goal can be reached in two ways, indeed.
Per #194 we want ro avoid systemd to start up. If I recall the docs correctly, those type of things are only defined in profiles. That might be user profiles (in theory: user systemd serbices) or regular profiles.
No systemd serbice is ever avtivated by a module (maybe specified, etc. But not switched on).
But modules define options that a profile (which we need here) might use. We just don't know if and which one.
Hence, we need to include all modules, but no profile, except the ones we clearly document,so that users will know, that if they put a systemd service in one of those profiles, it will start as part of the live installer.
I suggest, we only document core and root. (And if there is no root, nothing bad happens, you just can't ssh into the live installer, where the only user you really need is root).

So the logic would be: +-
modulesList - suites.allProfiles - suites.allUsers + core + root

If beeing able to ssh into root is unwanted, we can also choose nixos insstead. I think that might be a concern, indeed. We just would need to make sure that for deploy-rs this user has passwordless sudo. But maybe that can actually be considered an issue in upstream deploy-rs.
So let's rather use nixos and file an issue in deploy-rs.

Okay I think I clearly follow what your saying and I agree. I just pushed a commit that I believe accomplishes it. Its all modules except local and lib. Which is essentially modulesList - allProfiles. And as I said earlier, I'm just importing the entire base suite. I don't know how to filter out users, and also I don't see a point in doing so. User services are usually really light if any are even defined. And it could be nice to login to your user and get an environment your comfortable with.

Agreed! I'll file an issue in deploy-rs then.

I think there is an issue in deploy-rs for password based sudo. Unless I misunderstand and your talking about something else.

This is starting to look pretty clean. i can test tomorrow on my setup end to emd manually for a final round pf feedback / approval. 👍

I'm in an excellent position to try this out since I'm deploying a cage kiosk service, and before this PR I would have to manually build with cage switched to opening a terminal instead of a browser.

After testing tomorrow, if you could compile what you learn about bootstrapping and write a nixos integration test for the iso config, that would be amazing. I especially want to test the link local stuff to ensure it's actually working as we move forward.

Just force pushed with a cleanup of the git history. Its just three commits now.
bors try

It looks like this is now taking forever. I'll try with zstd, but I suspect we rather need to generate an overlay fs (if possible) and store those additional closures (not necessary at boot) just plainly on the files system, without compression and without inclusion into the squashfs.

bors try-

I think we should revert to strictly solve #194 and leave the other stuff for another PR. It is too hard to isolate and understand cause-effects relationship with mixed concerns if every end-to-end test takes more than 2 hours.

I think we should revert to strictly solve #194 and leave the other stuff for another PR.

Isn't that the entire point of all the changes in this PR? I'm confused as to what you would like to revert to. Either we import all modules or figure out a way to include the closure and import necessary modules. This PR is trying to do the latter.

It is too hard to isolate and understand cause-effects relationship with mixed concerns if every end-to-end test takes more than 2 hours.

I think its ok if we take some time to figure out this PR. Also another way to test could be to build the isoConfig's toplevel and inspect the files in there.

I'm gonging to test now alternative implementation https://github.com/divnix/devos/pull/202 which tries not to introduce side effects. It still includes https://github.com/divnix/devos/pull/202/commits/2bd331429d7a89f0f94aeaf36fff6195f25cd240 as we already started to go down that road with https://github.com/divnix/devos/pull/198 although its not strictly necessary for solving #194

Borrowed @blaggacao's idea of using disabledModules here. And I think this should avoid potential side effects.

I get a segfault on its current state, maybe the lib.remove doesn't work as intended?  #202 builds now an I could start into the live installer, going to rebase my cage project on #202 to finally verify #194.
/nix/store/vf2f1xph3v6afy0bx0cf46bp82qincpy-devshell-dir/bin/flk: line 28: 308429 Segmentation fault      (core dumped) nix build "$DEVSHELL_ROOT#nixosConfigurations.$2.config.system.build.iso" "${@:3}

nix build .#nixosConfigurations.NixOS.config.system.build.iso works for me Not sure where the segfault comes from. But that seems like a nix issue.

Can you also merge https://github.com/Pacman99/devos/pull/3? So I can try again off of this branch here?

@Pacman99 For various reasons, this has taken me a whole day already, and I still wasn't able to test this fully. Are you ok, if we turn over the page and continue on #202 ? It's just too hard for me to keep track of all those things while not being able to commit here... (sry)

I'll leave this PR open as a draft. But yeah this was mainly meant to demonstrate an idea and I don't think that the idea is viable. I think we'll have to experiment more to get a better overall solution. But I'm not sure #202 is much better since its basically the same as this PR but with a few tweaks.

Perfectly fine with continuing there though since you're the one doing most of the testing anyways itll be easier for you to update.

I think the CI runner is still trying to evaluate this PR, but I don't think the CI runner is even available right now.

Included in #202


Added CI workflow to publish CVAT images

Motivation and context
resolve #7
How has this been tested?
Manually
Checklist

[x] I submit my changes into the develop branch
[x] I have added description of my changes into CHANGELOG file
[x] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
[x] I have linked related issues (read github docs)
- [ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2021 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage decreased (-0.004%) to 69.968% when pulling 2eb62abfad6a91879368640ba2559b8df5de4912 on az/public_images into e0fc323a4d649c34bcfee47f67b7efd9a54683a8 on develop.

@azhavoro , don't forget to add news into CHANGELOG.md

@azhavoro , also need to fix codacy issues.

@azhavoro , any updates?

@azhavoro , could you please notify all stakeholders about the achievement (gitter, Intel teams)? Need to clear emphasize why it is important (speed of the build, easy to deploy, alternative channel to distribute CVAT, etc).

@azhavoro , could you please notify all stakeholders about the achievement (gitter, Intel teams)? Need to clear emphasize why it is important (speed of the build, easy to deploy, alternative channel to distribute CVAT, etc).

Sure


Automatically Add a Message to Discussions in the mo Repository

We need an automation feature for our GitHub organization. The goal is to automatically post a message in any new discussions created in the mo repository.
Requirements:

Whenever a new discussion is started in the mo repository, an automatic message should be posted in the discussion thread.
The message should mention all three teams: @octoposprime/mo , @octoposprime/mo-tl , @octoposprime/mo-jr , to ensure they receive a notification about the new discussion.
This automation will help in promptly notifying all relevant teams about new discussions, ensuring that no important conversation is missed.

Please add the correct labels.


remove deprecated MPI-1.0 constructs

Removed deprecated MPI-1.0 constructs, to ensure compatibility with Open MPI 4.x
https://www.open-mpi.org/faq/?category=mpi-removed
Signed-off-by: Kilian Cavalotti<EMAIL_ADDRESS>

Thank you, @kcgthb !