It would be nice if there were also big places where it would be reasonable for someone to have the source correctly, to have the source package while developing. That's why my proposal was USSRCE-dvm-hello-2.9 because when you go to CDE, USSRCE-dvm has to get source hello and you get that list of all the versions you know that might be. Well, that's not quite a big source content, but we might want that. This is why that was my suggestion, but actually it's true that if we want the debugging tool to be useful regarding these sources, it's better to have the dvm package revision because patches and binary and amuse. Well, they have the same source. They should, yes. Some packages are sorry. Just to say one thing, this could get us on par with Fedora. Yeah, because I thought Fedora RPM build has predictable build paths. They use debugging in all sort of things, but it's USSRCE-dvm-hello-2.9. Can we do that? Yeah. I just wanted to say that this also has other things about the useful look, which we kind of made for things that depend currently on dash source binary packages. Where do dash source binary packages, do we have a canonical answer for that right now? Where they put their stuff? I think it's use of source. I'd have to check that. GCC source install a terrible. Yeah, and GCC source install a terrible. I think the utils is unpacked. Maybe it's terrible these days again. So anyway, it sounds like there's a range of things that are happening right now. It also installs the RT patch, a single patch for that. And it still installs all the graphics. So the canonical build part would standardize these dash source packages in the label. I don't think it would be a mistake for us to try to get into that. Yeah. If we say this is what those are going to see, fine. And then if people ever want to use that, fine. That would be useful to say. We're disgusted at that pump and all agree. It would be useful, but there's always going to be differences, right? I mean... Should they build a patch and then get rid of it? What does it do? What does it do? I don't remember. Well, typically RPMs, they have the vendor suffix and the version numbers. But if the version number is full, it will have something for Fedora and then R-H-E-L for Red Hat and blah, blah, blah. It does occur to me that... Is it going to be okay to put Tildes in there? We'll find Barbox, but that's fine. Coldings? Yeah. Spaces. We're not going to have spaces. We're not going to forget the lab. Okay. Let's say we include the revision, the package revision number. So what's the content of that? Is that the unpacked thing or the DSC video news? Well, under hello 3.12-1, after that, I believe there is slash davian slash rules, which is executed to do the build. So it's unpacked. Look it. Yeah, if you point davian rules, it's unbegared. So the latest patch I have against DPKG build package will actually... So it has a test and it veils out. It shall not go to that directory. Or if you have period install, it will fire a period automatically and run the build in an environment that overlays that you went back to the directory. So this is something that... This is an edge that we can push into a DPKG build package. And it'll just take advantage of it. Yeah. Or like a conflict option to enable it. And enable it by default. That sounds good to me. I wouldn't support that. I mean, if we find out that it breaks some... If we find out that it breaks some build... I mean, eventually we'll have to get it into build.dds build, right? So I have a patch... I have an insisted patch against sbuild. So we'll make sbuild use that directory, I guess. Not look at people doing it. But be able to say it is not necessary. I mean, if it's like a package-to-package level, that does not need special care in sgroup. Because it just runs... Well, it depends on... What did you say? It depends on... The period. You want to... So just one thing. The period is very immediate because it uses Ptrace. And Ptrace cannot handle a lot of architectures. And it travels the... I'm sorry, it will fail to build if it's under Ptrace. And also it will like really slow down... I mean, not really, but it will slow down the build. It interests like... Come on. So the solution which is... Is it okay if I eat a wall dollar? Join the circle. Don't make it too much noise. You really have to share. The patch is a hundred words. Okay. So that's all you can generate. Is there a patch in the bts2? No, just follow... No. So the patches are not to push any package... Any patches to DPKG for a while. Because I wanted to have, you know, a lot of... Trend before going to Gilem with all my little... Folder and being called No. Because that's... I mean, for the way that I understood Gilem work for DPKG, it made it feel like you send me the patch and that's the which is. And you rewrite your patch and then it gets into DPKG if it's interested in the idea. That's how I've seen things work. So I'd rather, I wanted to have, you know, huge number to present to say, okay, this is not a dream. This is something that can happen. But we need to modify it to DPKG. So here's the batch. Well, you know, what I find with DPKG, you're modifying it. That film, which is that type of stuff. But that's a social spectrum. It is under Gilem's... So it seems to me like we should get those bug reports submitted to the VCS just so the discussion is out in the open. And if he's going to... If he ends up being obstinate about it, then we say, hey, please, you know... We write it for us. Yeah, and probably say it would be good if it was not just Lunar following up on the patches. If we make it clear that there are several people who want this and the patches are not acceptable for some reason then we should figure out some patches that are applicable. But I'd say we should get the bugs submitted in the summits so that it's a public discussion. So the other patch against DPKG that has not been submitted is... So that's one that is, like, completely... It usually can be applied. It's the one that sorts the file in the that depth archive. That one is, I believe, not contentious at all. I mean, we started to sort in the five sums so that they did better. Yes, some kind of... Yeah. And those are another patch which are sort of tough as a minus-minus end time option which we all have... So all members of the archive they will have the same end time. Mm-hmm. So how it works right now with the experiment we've done is that at the beginning of the... of the build it gets the time. Mm-hmm. And then use the same end time everywhere. But if the build timestamp environment viable is set then it will reuse the same timestamp. It will get timestamp into the time and time option. Why do we not want this to be always done? Like, first on the side of that chain work. Yeah. So we would always use the time... the timestamp of the chain block of the last chain block on the chain? Yes, of the 12-step of the source package. Yeah. Which has a bit of a design. Is it... Or shall we... the time of the signature of the DSC? No, that's too late. Too late? Yeah. You only saw that after it's built. Oh, you mean signing the Damian Doctard of GC as well? No. It's too late because it's not signed during the build. Well, you build the source package first and then... So we need to improve the situation. We want to have a minus duplication build package. I'm not going to build the source package. Oh, right, yeah. I would think it's the entry of the chain block. So this is a patch to a deep package or a patch to the source? A duplication dash source. A duplication dash... No. We want something in duplication, but it surely goes to the patch that I already have. Build the... Yes. The package... Build the... I don't know. It's already half written. It's only like... So right now I'm using like time to get the initial timestamp so it would be just passing the event chain block and... But... I'd rather not do that in C, though. Or maybe there's already something wrong. I think the deep package... Yeah, I thought it was probably... No, not all of it. Deep package build package is the thing that builds the actual .debt is not. Maybe... I think I can stand. But... I'm waiting to follow up on that patch and change what I've already written because I know it right now. And... But you plan to pass that changeable value through as an environment very little? Look, it would be the last entry of the chain block. It wouldn't need to be present during the... Like, this is for source mail, right? This is not for my... But it doesn't need to be present during the actual build process. I don't understand why you're talking about... It does because you're building a .debt. So what happens is that you build a .debt. You need to fetch the version. Where do you find the versions? That's in GBN slash chain block. What you're saying is that's where you're going to take the timestamp in version... I don't know if the .debt doesn't depend on... from the particular directory. You can try to pack up this directory into a... pack up this directory of... a .debt. and there's no assumption that you're in the... the top level of source for a .debt. But we can have... because of your package, that as an environment variable, is that reasonable? Because that's close to what I already have. Do you want to... Do you want to put the environment variables to devian rules also? Do you need it? It would be. Is it okay for devian rules to have that environment variable? You're cool. Cool. Okay. So... the timestamp stuff... This is one place where the timestamps show up. And all of the... Yeah, there are many other places. Yeah. Yeah. We want to focus this discussion on the framework first. Because if the .debt files themselves are not reproducible, then what's inside is less meaningful. I remember the conversation years ago about the timestamp in the archive on the outside. Did that get resolved? So... So that's... So that's one of the things that was during the experiment we built in Azure. We've minus, minus enabled deterministic archives, which actually make the option that you've just chosen the default one. So... But with that... But we could also just be passing that to R. That's been changing a lot of places. No, it's... No, it's... That's L, D, U, Z, I, R. L, D, C, U, Z, I, R. Yeah. So we... So you're saying switch the default option in the details. So we could just switch the option in the details. Can anybody think about anything that would break? I don't understand why there's a default. What's the difference between the two nodes? What's non-deterministic about it? When adding file in the archive index, use 0 for R. We'll use 0 for UIG, GIG timestamps, and use consistent file nodes for old files. Oh. So if you do that, and people are doing backups, they're going to be pissed. Right. So if you're using... No. Doesn't it make control doing make supports having dependencies on our members and they are archived so that would mean that it's a... So that will depend on the timestamps there being what... what it is. So you think we can't turn that on? No, it won't break. It'll break. I mean, it's a whole... it's a whole thing that hasn't been used up much anymore because it doesn't work with the... Can we use Hari's promise a little bit? I was trying to make it so I could read it. Yeah. It's the... The environment variable we could... That's not a good use if we... We can't... What about the environment variable that should help? Oh, that would mean I see I'm going to solve it. Yeah. We can do that. But then you... have the same problem that we're building but we're running presumably in... It's the intent for deterministic builds to be applied applicable to all packages and devs because in the first case then we have some of these packages I don't think you'd be using in a public health system that really makes the support for updating all packages and the dev files. So... So you can always use the awkward options it's available. You can pass you or pass D to... My... No, okay.  Okay. So can we change what it calls R to R to D? But it sounds like we're talking about R here. One is in building the Debian binary package where it sounds like... And one is in building actual libraries where it is possible that the main file time string cracking feature isn't used in the build process of these actual libraries and so we can't change it there. But I believe... But so the other question is can we write an R processor that strips... Right. Yeah. Yeah, right. True. So I mean it's all about unpacking one R and giving the all like the other... options you can make. Yeah. So stripping R and GZ. Right, because there was this other thing about can we strip the... the... Yeah. I've heard a lot about that. I spent a little bit of time last night working on... working with Drew Fisher, I think his name, on Drop-a-Doc comments. Oh yeah. I spent a moment yesterday working on Drop-a-Doc comments and trying to thread the man for Drop-a-Doc that was able to store the timestamps through the Maven so long change to Drop-a-Doc. And it clearly got into enormous pain. And I concluded that it's not worth talking about it. Should we have a DH strip non-deterministic thing and we can get everything there? Yeah. That's great. Strip non-determinism? Non-DR. It removes non-DR. DH to terminize. Yeah. That would result in a... a result sooner. Yeah. Now I totally agree with that. Sure. I haven't spent the time already to try to create it. But it would be cool to also get all of those things. Yeah, but you know what? This would also be a place to collect all of those things. The source code for this would be a place to collect a to-do list. And you could say, oh, this is a Drop-a-Doc file. Let's go fix Drop-a-Doc. Is it better for them to go in one task like this or in the respective like DH Java? They already have like... The other ones, DH Python. They already have DH... I think it's separate. I think it should be global because for instance, Java uses JAR, which is just and except for everyone who uses it, that would benefit from making that non-DR instead of making it Java-specific. I agree with that one. But like, to construct the arguments that produce the JAR itself is something that is only known to the JAR and that you do a second pass on the JAR to clean it up.  So this command, this DH-shipped-out-of-Germanism probably needs to look in the Debian directory and say, oh, this file is processed differently with this different... Well, these package... Fringe packages can do fringe things. That's the flexibility of the Debian rules. But we need to... If we have solution for 95% on 99% Yeah, I'll bring it as a mechanism for package build systems to say I want to handle this particular thing differently. So we could make non-deterministic a phase that, you know, DH Python or whatever it is, it does have it. That's good. Great. I also have AR and ZIP and... Good. So that was inside to get back outside. That's okay. One question that is not solved yet is where do we recall the build environment? Michael is inside the dot changes. For example, I... I had a couple of email changes with the author of the package called DH Build Info which basically does the job we want. If we recall the build environment, all the packages and the version. But currently it's solved in that but you're also told me like yeah, I would like to have this actually to be done at the difficulty level but he was arguing that the file he was producing should be a separate file. Like next to the changes? Next to the changes. What's the trade off? Yeah, that's when I... Will the archive track the files next to the changes model? Where do they go? I just tried to do that. Yeah. The projections. Yeah. Detonement isn't that easy inside of that. That's not crazy. That tar.gz player. Well, so the AR top level has data.tar.gz and control.tar.gz No, because you do have the amount of multiple binaries from the same source. So it's making information. Yeah, it's a source package thing. The good thing we're using above changes? No, it's a binary. It's a build thing. But it's going to associate with each architecture that it builds on, right? Yeah. I think it follows better in the binary package than elsewhere, although it's not very... One of the good things about... I think it's separate to the change model. Because it's changes. Because the changes file should be... One of the good things about the changes file is that we can... we have free to add x- things. So we can experiment without asking many more people, which is... we need to change that. That was one good thing. Kind of currently get at the changes by the particular address. But we need... That needs to be fixed. In that case, we need to change that to get the changes file kept. My tech would be all these four packages in the binary. That's the easiest way. I believe... No, I believe DH coding is smarter. It's all depends and depends. Maybe. Because you know we have built... We have built these the most important things that where some code from that other package gets copied in and that's it. I don't want to get the source of the package. My understanding is that we don't want to use that. It was meant to get packages in the archive. It would blow up the side of the archive. I feel like you would want the most every package because you might have something that's essential or build essential, like the compiler that changes the app. If maintainers are not building the package in the shoes then that's a privacy issue. They should send it to them. Well, hold on. I mean, this is going to be in the changes file, right? If you just build the source file it won't show up anyway. But maintainers build binary packages on their personal machine. Sure, but they should not be uploadable. So do we have to move to source only packages before we can do that? No, it's not a before thing. If you don't want to leak information out of your machine, quit uploading packages that you've built on your local machine. Just upload the source. You need to build the source file. Build the source file. We're going to do the whole verification stuff. The development is to upload the changes file with the hashes of the demo. So, I'm getting back to maybe not everybody some people are not at this whole grade. So one of the end idea was that you would have the .dev in the changes file but you would not upload the .dev because after the upload ability will pick the changes start the rebuilding process and if the result change .dev matches what's in the changes file then it can get accepted in the upright. So we have the expectation that not both have been compromised and that the package can be actually built. So if we want to do that then we need to we need to be right in what we capture as the build depends that we're actually used. Could we use recursive dependencies of build essential and build systems? That would be less. We can try that. We can try that. I think we're good. We're not going to have problems with hashes. That means doing weird downgrades on the building. With my level fail the versions are different. We should probably reject that. Why would you want that in the upright? The build is to not update the build essential on a process which is for example use something and build essential breaks horribly and if the build this would automatically update the package and this breaks you can't build anything anymore. So you kind of not necessarily want to have the build like it's a specific script we're looking at. It's a thing that would take the packages like the list of packages and versions and install them from Snapchat to introduce the build environment. So I think we're jumping ahead of ourselves. We think we're going to change the way that the archive itself is going to operate to not allow an upload to go through a message reproducible. I think the first thing is get the upload to be reproducible. And okay, fine. The build these may not have the same thing and they may produce something different. But get the upload, get the build to be reproducible and don't worry about setting it up as a as a dating factor for the archive. So I think that suggests that it just it's a list that ships either in the .changes file or it's a separate file or it's in the .dev. So you mentioned Snapchat. One thing that would reduce the size of the list is to start with a timestamp if we know that the build environment is up-to-date and do by reference to Snapchat. Do you know what the date is? No, what up-to-date means we're starting to get archive. No. The different things are in for different architectures at different times and... Let's worry about optimizations So I'm trying to think what are the advantages of having a separate file and it's hard for me to follow in. I mean, if you want to be this to be working, you also need to have buildd when they first pick the build for another architecture as the db upload architecture. They also need to recall the build environment for that architecture. You know? So it feels to me that in the archive it's always about change as well. So that's, I don't know, that feels like the most easiest way to me because the other way is you do a source-only upload and then you have changes file that would not have any informations. It would be a difficult name to change as well because it's an obvious source. Yeah. Yeah. Ah. Yes. Ah. In that case, you might have multiple versions of different packages right here. Okay, so we need to separate files. That's the reason. Relatedly, what about stuff? Okay, it depends. They need to know what architecture they work on. Who's the author? Who's the author? If you're building an archive, your changes file is still underscore. Okay. That's also interesting because if you're doing what should you be able to build the same thing across different files? I have seen I'm aware of things where it makes a binary format which is fine, but the binary format is specified in a little idea or a big idea and you detected it when you load the file which one came in? I don't remember my thinking. Do we consider that a bug from the point of view or reproducibly? Yeah. All packages should be reproducible across architectures. There's some weird stuff like M-Test or something where it has all packages that has binaries in it. It looks a bit a lot of just I just want to see what the output of running this on the whole tree is for our tall things and see if they're not deterministic and which ways they fail. I would like to be slightly all the world of acts and say if it's not reproducible on different architectures but the thing in the archives if it falls on in the future it shouldn't be considered preventing us from getting to the goal of reproducible builds. If we can get that 64% from this that would be awesome. Can we agree that it should be a separate file that is referenced in the changes that is kept in the archive and that contains the architecture in the final name of all old packages that separate file in the site. It's referenced in the changes the changes file inside. Why not? I know DKG is sitting out to get help from ourselves and talk about the buildies but the buildies only build packages for their particular architecture and how to fire independent packages that want to take their buildies that doesn't need to do something or just the project. Our two independent ones are built by the developer. This is one of the issues about Chinese stores. I haven't followed the whole conversation with that. I wonder why that file isn't simply in the .dev because it's because when I have DKG and DKG that will be deprecated. But the change log is already deprecated and the copyright is already deprecated. That's more than enough to do. Is it useful to have it in a delivered package on the systems? There's a problem. No, it's useful if you were packaging the source code. It's not useful if you've got it on the system. It should ship with the source code if you're going to ship it. The reason why you should not be in the .dev is because there's no reason that you told me to catch the .dev while I'm trying to actually produce it. Yeah. Because it saves me dollars and bandwidth. That can only be bad. Conversely, you're changing the .dev by putting some help. Yeah. Yeah, because they're about to... Okay. We'll get to the separate part. Basically, I believe the plan for that would be to take TH build info. Check it. So it's going to be build info. And move it to duplicate as a batch to duplicate it and create the file. So it's going to be Hello underscore 2.9 2.9 3.12 or .buildinfo Or not. And is that signed by the developer who initially uploaded it? Probably. It's here that referenced it. It will check some. It changes the file. It will check some of that. Probably you have multiple builders and security in the building. They will have different burdens of JCC or... but it's still reproducible. That's fine. Yeah, that's fine. No, I can one file and you produce the environment of that file. The archive gets one copy. Yeah. Some buildin. I'll tell you it gets one copy from the developer initially. And then each buildin gives the archive one. So we're building a different ability to match what the developer did. The developer might have used the developer. I'm not even talking about matching the developer. I'm talking about the buildin that the developer didn't have. So if you want to reproduce, you need to be able to say, does this match the power out with built-in powerful city? And that needs to be available so that you can pull that and reinstall the same package. Just to make sure I understand, this is per binary package? Yeah. You could have I think it's technically possible to have the ME-6264 build the first two or dependent packages and then separate the second two and don't actually do that. Okay, so like, it's a source package that builds four binaries. Yeah. And Alice builds binary one and two and Bob builds binary three and four and the archive wants to mix those two. Okay. I think there's nothing in the machinery that stops another level. Well, we shouldn't do that. I'm fine with that answer. Is it possible this package? Sure it's possible. There's an arch all binary package with an arch something else in the same source. Well, arch all, of course. Ah, I'll show you. Right. Yeah, okay, so you kind of know I do build the arch independent, only the I will outload only the arch independent binaries from the four binaries. Ah, and so what would it do? Do we have to do that? So maybe we need to have a dash underscore in depth and underscore up. What? I don't know. This doesn't reference the this refers to where it was built. Not the fact that it's an ANSI scorecard. There'll be two, there'll be two, but there'll be one. There'll be one. There'll be four of the independent. Right. There'll be two, but there'll be one. There'll be two, but there'll be one. There'll be one. There'll be three. The reason is, my changes are always called multi-upchangers. And even if it's not good, we have to know what changes are. You can upload the set up and then change it as well. We want to keep the changes as far as we're ever going. We're not doing that right now. And so we have changes as far as our collider names that we're already from. If you have a separate file, there's no reason to keep the changes as far as we can. signature maybe, but you don't need that for binary packages right now, so why would we not be able to build it for them? So, okay, so potentially, if you're doing a build of, if you're doing a build that includes the other 10 packages that you're building, tell him, I just want to know, don't build it without using that. I said, if you're building both 10 and 10, you get two dozen of them fast. So they need to have different names to grant it to build. Can we just put a text down here? I thought I wanted to get rid of that. No, it would be not all. So here's, so this is the idea that I think I'm hearing, and maybe I'm not gonna make it, but when you do a build, you are producing some architecture independent packages, and then some architecture dependent packages, and say I just do a build locally, and I build both of those, then these two files will be identical, right? And then the archive is going to take the architecture independent packages from one or the other of the builds that come through, and they will take that underscore all dot build info and ship it over there. Yeah, you said from the buildee or from the developer? I don't care which one they choose. They're going to choose, and then the architecture independent packages. So then they won't be present in the stuff uploaded by the buildee. I'm saying this, I'm saying this. And if there will be one buildee, we'll be able to do that. You can have the same category of problem with the developer. I think it's true, you can have the same category of problem with the developer, just removes one out of the two, let's say, binary packages from the developer. Don't do that. Seriously, like we don't need to worry about that case. I really think we just, the developers shouldn't be doing that. I wouldn't choose the name to be an underscore. Well, that's really confusing. Any everywhere else means every dependent architecture. If you want to call it in-depth, I think we just make it a star. Yeah, but the problem is that we're calling it, the problem is that we're having a cross compilation. Cross compilation. No, that's okay, that's the destination. It's not trying to do cross compilation. The content of this file should include the build, the host architecture, as well as the target architecture. Well, it should be the architecture of each package that is recorded. Yeah, it actually does right now. I think the golden footer, the yes-golden-footer, we called it. I shouldn't say. Okay. What is possible on the thing of this topic and then the other topic, which is, the reason I suggested this, I think it's actually cleaner if there's one golden-footer file per object. That's really my point. For dem? For binary dem, yeah. Why? But the thing is, for dem, it's per build. It's per target build. I guess I'm just saying that there are real promises about relation between builds and devs, and I'm also fine with control D. But it doesn't, how would you interpret multiple golden-footers? One for dev, I don't understand. Well, I want it to be the same building, but for all of the devs that are built at one time. The question is whether you're trying to reproduce builds or whether you're trying to reproduce devs. Well, I'm assuming that if you reproduce builds, you reproduce devs. So, I have a plausible, I think, interpretation of where you're pointing with this, which is we're getting build files from somewhere. We need to be able to download them. They need to be tracked by the archive. We need to be re-signed by the archive, because we're not relying on changes files for this. So, we need some sort of system like the packages file for build info files. So, you might have a build info style file that has each dev, and then has, like, it stands up for each dev, and then the name of the associated build info for it. But, given a dem, you know what its source code is. You know, hello tools comes from the hello source file, and so you figure out what the source file is, and that's the build info that you sent. And it just has the information about what was used to deploy the build. That's it. When I am a client of this, so I'm not a client, and I want to reproduce the build on my desktop for my own assurance that the build are going to do something, and I download the build info file. How do I do that? You need to download the source NUS. Or you're going to the, like, the source downside in your users. And so that fetches the DSC, the original product piece, and the build info. Which also is why it's so easy. Is there all source specific? Oh, it's given the DSC. No, no. So, what is the mechanism whereby? Tech. Okay. No. Magic tech. Magic tech. That's the... So, wait, wait, wait. I'm not hearing your question. If I run the app get source. How does app get source know where to literally download? Like, what do you need to be URL to download the build info file from? Because it doesn't know which dot that is what I'm trying to produce. Right. It actually really has to download. It doesn't even, it almost doesn't even know what architecture I'm looking for. It knows the architecture that you're on. So, it's going to guess that. Okay. Just like app get download fetches the version for the architecture that you're on. And then, if the package has some architecture, it will also fetch the underscore all. Is it verifying any signatures for cryptographic ashes when it downloads the build info? Via the app.archive.chin. Right. There's a tree in the app. So, is it the source? No, no, no. In the source as well. No, for certain reasons. It's also for the sources. But that's new. You're talking about wearing. But it's not going to store it. It's neither a dev nor a DSC. Is there some file that... Yeah. The app.archive contains a bunch of this information. Okay. And if it doesn't contain it for what we want, we'll make sure that it gets into it. So, maybe... Well, okay. So, maybe my initial idea, which was make the dot changes the private thing that actually you get and, you know, call the people that should produce things on. Maybe it needs to be this build info. Maybe we need to make sure that all the information is in this build info. And maybe we need to make this build info sign. In that case. Because what I was thinking, but when I said, huh, we take the dot changes file, is that dot changes were already signed. But this is referenced by the changes file. Well, I as a client can't get to the changes file. Right, no. Oh, I see what you're saying. But if we are going to change that to add the recorded file, I didn't knew that actually you could upload changes file with multiple times the same name. And that's a kind of form that I actually had rather not open because that's breaking things. So, let's make something new. Maybe that's better. So, we could stick signature in the build info. But it seems to me like if there is a dot changes file associated with every built package in the archive, then those dot changes files should be... Well, it's great. Also, one other reason is sponsoring. I hadn't followed that before, but now it's sponsoring. When you sponsor a package, what you sign is the dot changes file. But I want to verify the signature of the actual developer and not the sponsor. You verify the signature of the archive. So that's why I was saying one answer is the archive signs some metadata for all of the built info. You don't know which developer sign. That's why I say we include either as the batch signature or inline signature in the building program. The signature that is of the developer that actually builds the thing. But if the dot changes files are being shipped? The dot changes file might be signed by a sponsor and not by the developer. But in that case, then the builder came from the sponsor. That's what I'm saying. Wait.  No, you can reproduce something. But if I'm sponsoring a package, I look at the source code and I upload the thing that I built. We're not going to take an arbitrary signature. Somebody's just re-looking at your source code. I want to make sure that... Yeah, well, we don't know if it is. I would tell you. Did we rebuild it? Yeah. I don't want the build info to be signed by the person whose binaries are not being uploaded. But if it's reproducible, then you're up. This isn't the big one. Well, we're not... It's still upload yours and not theirs. It's going to fit as a reference. Right, exactly. If it's exactly the same build info, you can just replace the signature. Yeah. If it's the same dead, it doesn't matter. If it's not the same dead, you want the one that goes in the archive. Therefore, you should be using the build info from the person who did the final upload, not from the original. Is that logical? That's logical, but it assumes that the best practice is to rebuild what you sponsor. One of the great... One of the amazing... One of the amazing things that I've seen with the tall brother being reproducible is that we take a machine that we have no trust on it.  We take 80s to build. It generates a gigabyte of archives for all architectures. It's super long to upload to the actual server. But then it doesn't matter because I can take my own laptop, which is on broadband, no cell phone on a train because I only have to upload one file to the server to make it true, which is a signature of the SHAP-25675. It's the only file I have to upload. So I'm actually arguing that I shouldn't have to, as a sponsor, maybe I shouldn't have to have to upload the .dev file at all. We are going forward. We're trying to get to binary less uploads. So yeah, I see it. I don't see why that changes. The point is that you don't need to rebuild the .dev. You always do it. You do it because you need to make sure you're sponsoring a package that builds in a clean environment because the person you're sponsoring the package for may not have built it in a clean environment. But I believe the signature on the building code from the person that actually made the first build. But maybe it's a new intuition out here. I don't know. I think you guys are identical. Does it matter? Well, that's one thing. Right now it's super hard to know. We don't have that information right now in the archive. Who built the package? So here's a plausible scenario I might be thinking of which is if the archive is better at minimizing the build info or getting more sane, more reproducible build info. So the thing is that the build info might vary while the dev doesn't. And there's some build info that might be more reproducible because it's cleanly front snapshot as opposed to some packages upgraded, some packages not. And maybe the resulting devs for both of these are identical. I would watch her for the one that is more standardized because that's easier for a third party to reproduce. Again, this is once the rest of the archive is already being processed. Let's move on. Let's get to the 65%. I have a question about DH. Clean this stuff up to remove the data. Can we address that later? Let's try to get the environments settled. I don't think we need the build info to be signed. I still have not heard an argument for why the build info on its own needs to be signed given that the dot changes files are going to be broken. I'm saying let's not make the dot changes spread and let's keep exactly that walking as it is in the right now. And so we are missing a piece of information and that's... But that is not going to redistribute these dot files without a change either, right? No, but the fact that right now there is no... without a change file there's no name scheme that is mandatory. I think it's a painful thing to handle. Oh, because of the multi. So you won't necessarily know which dot change is to yet because it could be under square root of 64 dot changes or it could be under square multi dot changes. Or you could reuse the same changes file name and you can't have both of those changes files in the archive because they have the same name. There's no way to make an after archive that takes two files with exactly the same name. No, but the dot changes file has the arch on it. No, but I could reuse the entire name because I could do the same upload for the arch twice. Same upload, same arch twice. And the archive... The archive is only taking happiness from one of the uppelines so it's only going to produce one. But the changes file for the arch in your panel packages also has the build arch on them but it actually is happening that you have two changes files with exactly the same name. One that contains the arch independent packages and one that contains the arch dependent packages. Okay. So the names are thrown away at the moment, I think. So we have to reuse the name and then reuse the stuff. Why? Because it's done with changes files anyway. So if we're talking about what that means to reproduce, then the stuff that comes from the buildings that built the arch dependent packages regularize names, yes? And the stuff that comes from the original uploader will have whatever whacking in the original uploader wanted to put on it. And that's where the arch independent packages are going to come from. But I believe it's just clear to you to view the dot changes file as a transactional thing. It's a transaction recovery and it should stay that way. Transact with the arch arch. Yes, I'm going to change use transactional. And the buildings are something that stays until the package gets removed. I agree with you in principle that that such a system would be nicer but I think that given that there are other groups who want to do certain things with changes files it's going to be harder to build a stable reproducible build system on the assumption that changes file follows certain rules and therefore we should prefer the user option if there are no clear downsides. I think that's what we are going to do. I find that. Thanks. So, signature on the build. We have all the trust that came in. I have a hilarious joke that you don't really get a good bullet and then the fact on the work or not and that's your thing. So we normally need to ask that to not throw away the dot changes file, right? That's a separate answer. We don't need that. That needs to distribute. I love you people. I feel we're making progress. You will to avoid changing semantics. And so I mean the build info becomes part of the list of topics in the dot changes file. Okay. Whoever does the build. What's that? We know how we're producing the environment. You have this fact from the text we had so far. One thing I worry is that we might discover something else that is part of the environment that we don't know now needs to be recorded as part of the environment. It needs to be an extensive program. That's what I'm getting at. It needs to be a format so that you can extend things and packages that don't care about the extension without the extension, you don't break the tools. Could you want us to look at the build info? Yeah, build info producing right now? Yeah. I'm sure you have some file on your document. I have a file on my document. Sorry. What? Probably not. What are you looking for? Build info. They are in USR. I call this build info or something. They are architectures. All Haskell packages have that. I believe that's central. That's not super machine. It doesn't contain heavy-denture. Is there any machine? I don't think so. What's that? Changes file. That's the data. Packages. Central packages closure. Build the central package for closure. Declare arch-in-depth build dependencies. Build dependencies. Arch-dependent build dependencies. It's missing the architecture of the... No, you can't have... I can do my build with a free access and a... It's missing the architecture of the build environment. Yeah. It's just a column dash. It's the data. Yeah. Let me know. Why? So we're looking for, what, a colon? So what is that specific reason we need? Build info needs to record. Is that right? The architecture of multi-arched packages. The post architecture of the tool chain. Well, every package is mentioned as well. Yeah. We can't recall the canal version. Who owns? I, some people believe that they had buying VA here. I'm not sure. I mean, because you've got to, you know, some of the configure ships will try to detect their gate bills as they're running the other side of wages. I'm saying this is a bug. Yes, it is a bug. But if the package, you know, captures that, but I believe it can help the bug in the gate, we know. So what, so canal version? If the format is extended. We won't attempt to reproduce the kernel version. But it will be. But this is probably the information here. The kernel version? Yeah. Is kernel major, minor enough? Like just 313 or just 311? Is that enough? You also need, you know, There could be patches in its smaller version that are bug-fixed patches. I'm not saying it's the worst patch. I feel like you are likely to leave the kernel the other way. Let's, let's, let's just go back in and argue about running the error. Okay. So I know what gets captured, but maybe we don't want to catch it. I mean there is a username that captures. Several, several of these will be in the results. That's the problem. And they should be in the result. They should not be. The user, what I'm saying, should not be in the result. Yeah. So we, so we don't need that in the build-in. Right. Same as what we call. Well during, during debugging, when we're trying to figure this out, it may actually be useful to have these. I thought we were enumerating all the things and then decided. Yeah, I know. Let me make one more point, which is that this is an extensive format. Listing something here now and including it in build-in folks now does not commit us to including it in build-in folks forever. If we get to the point where the kernel version or the username no longer matters, we can stop including in build-in folks. We can also have it be a default that is not included, but people who are okay with including it can start including. My username is my email address, which is on the package. I don't care. Right. But I don't care. So, we should favor specifying the things we think are important and then come back and decide that. You should only do what you're building. As T little or what? Yeah. As you know, whatever. As you know, it uses the same username. That is my fault. It's not using my username. Okay. What else? So, you make some mind calls. The time of the build. Yeah. Maybe. Where do you see? Where do you see? The environments. Yeah. The environments. Oh, I've been there. Like, C-C seems relevant. But what about, like, that's the alternative choice? Oh, sure. Oh, sure. No, are you serious? Yeah, you're absolutely right. Yeah. You want to know what answer is? The actual shot, 252 of all the binaries involved. The number of your kids present. Snapshot. Slap. We're enumerating here. We can, we can go. We're running process. I'm going to talk to you. I'm going to talk to you. You had ports wasn't it? Last five emails. The number is to be used. Oh. Yeah. Yeah. Where are all the things that can be your answer? Or that matter. Like proxy view info basically. Oh, so actually CPU flags are going to affect the way, there's some like. I love this. So. Wait. So how do you deal with? CPU flags should be something that packages to take it off to. But it shows. It shows. But it might also influence how the compiler chooses top of my state. Yeah, that's all. It means.  It's going to be possible. Again, that's about it. Yeah. It's built into the compiler. Is it? Yeah. But all the bills. The package. It's a configure script. Yeah. Yeah. It depends. Yeah. There are definitely conditions. There are periods, all periods going to have access. Yeah. Maybe play. I'm not. It's going to get to the data. Then it won't include it. Yeah. This is not a requirement. This is not a list of things to require. Okay. You don't know if the PCC in the building can get this few flags then. So, really, what I would love here is we actually start with the PCC script. Let's just start with the. How do we put it? We start with the packages and the host. Yeah. Can I get the host host? Yeah. And if we need to add things, we bring up the data. That's fine. Yep. Still. I think about the privacy thing. No. We can see you guys. We're still looking for 60% or something. Exactly. Yeah. Well, the diagnosis that you did to break down the ones that weren't reproducible, some of those will suggest new things to add to the DH building once we get into the whole archive. If we can get to the point where we've got 60% actually building reproducibly and then we do some categorization and say, hey, this is a common feature. All right. There is some more data in the building. I was like, well, I don't know. Everything through it. I want to tell you something exciting. Maybe 20 minutes. OK. Maybe 20 minutes. So, yeah, maybe we should go to an end because we're not familiar with the structure or something. We want to remediate tasks. That was my final thing. I have one possibility for that. I wanted to get a sense of what the implementation quality of scripts, et cetera, that are part of DH's that are not reproducible needs to have. And I have some thoughts about it as a topic. What the quality of the work? So what the property is? You're asking, should it work? No. Like, so to be very concrete, these Java doc files have actually no comment that has a timestamp. It seems to me that the best way for me to handle this would be to have a, like, Debian slash reproducible cleanings file that says Java doc colon, and then a glob expression that refers to rich files to process with the DH cleaning Java doc helper. And then the DH cleaning Java doc helper can be a relatively naive world script that knows it on line five. There should only be this comment. That's right. There really is a comment. OK, cool. We can outsource that job to a more packaging helper, and we don't need to specify that yet. And if your DH, you know, DH clean-up reproducibility dash dash with Java decides that it wants to specify this file, it's welcome to do if it doesn't need to. So we need to basically implement these on a plug-in basis for each one of the possible... Right. I would still draw it like to draw a line. With this thing of the clean-up afterwards idea, it's that for the AR, one of the issue we had is that, OK, scripts might rely on time stamp during the build process.  But come on, come on, see an HTML file?  Yeah, but it's a... So we need to... I think we should try to favor the fact that we do not get timestamp read-in after a while. Preferred determinism over... I think I spent two hours on that yesterday, and I'm rather really disturbed. I actually think that we should write... If there's an obvious said script to clean up a file, write this script and throw it into stripped non-determinism. Right. And then let it run. Yeah, and not this... stripped non-determinism has a list of the things that we need to go past our upstream about, hey, we really like to not list you in the wall of shame of all the things that, you know, non-deterministic builds. So fix it, and we'll drop you. So the preference is always going to be fix the problem, or at least fix the problem in Devin. But if it needs to be temporarily fixed, we can do so via the script, and maybe there's something that can be permanently fixed like the AR thing. That's okay. Given equivalent efforts, prefer the thing which produces deterministic behavior rather than cleaning up after it. Given limited time, do the thing which works, and then coordinate with upstreams to get the preferable outcome. Very good way to trade it. Awesome. So... Go... ...tasks. So should we go back and read through what some of the tasks are? So... Joey is the talk. Sorry? Was Joey has the talk? So, you know, it seems like you might be furthest along on these patches that need to be submitted. Well, I can take care of the interventions. So... Is that okay? Yeah. Did we make a decision about... Okay, we can't do that universally. Yeah. Okay. So... That's just the decision point. We don't need to do anything else. So, who wants to start DH Strip Non-Determinism? I want to. I could do it. Wow. So who's going to pull... There's four volunteers. Who's PM? Yeah. Exactly. Put something there. So, repository-wise, we have a reproducible IOC project. And we can do the DPKD and the presentations and the MISC. Is that okay? It's a possible produce, just to... So, we can... Yeah. We can do a developer and then a branch. So... Oh. Thanks, guys. Yeah, my thoughts. So... So, who wants to work with DH Build... Who's upstream for DH Build Enjoy? So, he's a French. He's Oyan. Okay, is he averse to changes? Well... We're going to... Actually, we're not going to change his software. We're going to change DPKD. We're going to take the work he's done and put it in DPKD. And eventually, we would make it. We probably want to coordinate with this person and take over their work and stuff. They're absolutely... Yeah, we can. But, I mean, he... So, I actually... I stated he was on discussion. Okay. He told me he wanted to get it in DPKD. Awesome. Okay, so then... Yeah, but it sounds like it's hard to get things in DPKD. Well, we can get it in DPKD. We can get our... I mean, we can stop using a private branch. Yeah. And we can... Well, can we start by just updating THBuildInfo? No, because you need... If it's going to be a separate file, that is, alone without them, then it needs to be done by... THBuildInfo runs in the middle of the demo process. And so, it's not going to capture it. It's not going to get on the right list. It doesn't take much time. Right. I mean, why is where you run in the build process determine, like, what your CPU flags are? No. What your user ID is and what your user ID is and the packages you have installed. Because the file needs to be written outside of the build process. But you run the package demo for David Rawls. It also puts it outside... On the same page. ...the directory. Is the package changes when run with David Rawls? Yes. Yes. A lot of these times, the package is built in. Oh, yeah. Oh, yeah. Yeah. And the other thing is the shell script that DHBuildInfo runs can always be run at any time. It doesn't have to be called from David Rawls. So, it seems to me like we have ample experience with the House of Trent D package maintainers. We have a busy, but happy to work... We're happy to, like, collaborate DHBuildInfo maintainers. It sounds to me like the easiest thing to get to where we want to go is to get what the changes we want into DHBuildInfo. And then use a package that everybody can use in the main archive. We can't stop them because we're building by file, even if we generate it from the edge, we're building by deep package changes. We still have to package. Deep package. Well, sure. There's a deep package changes that need to be done to stuff the DHBuildInfo into the changes, right? That is a minimal set of changes compared to actually making it produce all of this information in DHBuildInfo. Yeah. I'm thinking that since we already packaged in package, hold on. Okay. My impression was that every single patch is pulling teeth. And if it's a patch that says if this DHBuildInfo file is present included in the DHBuildInfo changes, that sounds like one tooth pull. If it's with the package, then do all of this other... Shit. It sounds like a whole mouthful. I have a question also. Is it not possible for these changes files to be generated by some process that's not deep package? Rar. Woohoo. Sorry, we're trying to finish. So is it not possible for these to be generated by some... Well, yeah. That's it. Well, then... Okay. I would agree. I would agree. I would agree. I would agree. I would agree. It's not possible for... I mean, so it's not possible because I am going to tackle right now. So I hope it's going to be outside. Who wants to take on talking to the DAC folks about it? Right. We don't know if we're going to work on building. So... However, you will do it. Cool. We'll work on building. It'll be inside the... Building file or... There's two things, right? One thing is... Yeah. Figuring out the generation of the DartBuildInfo. I'm making sure that works. I'm defining a file format in some way that makes sense. And the other thing is, including those things, in the dot changes file. But that's trivial, not to worry. Someone voluntary to write the building? Or write the building and add it to our data? Define a format and write a script that extends, either extends or replaces the hdl.info to gather all of this data, or some of this data. Can you quickly look up what's the language? Oh, I'm assuming that was I, S, I, C, F, T, and so on. Perl. Build essential. Perl. I mean, start to put it right there. That's why you put it in a great form. There's more people for the other one. Can we take this off now? It's because you know Perl. Shit. You don't have to take that. That was a bit. Maybe you can, like the first step would be to mail, and you're good at that. Mail your hand to say, hey, the maintainer of the hdl.info. Hey, do you want, we have the following new requirements. You want to work on the code to do that. No, I can't say the word. Ah. So it's a bit able to relate it to the hdl. So, rather than saying that you're going to mention something else there, but isn't it just the first two? Yeah. Well, the maintainer of the hdl. Make it nationally redevolved, and it's not right there. Yeah. She redevolved acceptable. All right. So, mail the hdl.info. Yeah, I don't generally do the mail here. Thanks. You are. What? You asked for someone to volunteer to mail your request. Oh, no. He won't. I'm sorry. I'll try to reveal that. What do you want to reveal that? No. How did you do that? Do what? Just a place to work. Yeah. It's pretty useful. All right. I don't have that in my one yet. So, this is awesome. One other thing, so once we have the hdl.info, there is this old script that, you know... What's the other script? Yeah. If I would be interested in doing that for sbill, I don't know if that's the tool that people want to use here. So, when did I do that? I believe that's the... That's what the build means, right? Thanks. Is it the right script? Sure. That's awesome. All right. I'm sorry. What's your objective? To keep? What about that? To keep? Okay. Is it the right script? Thank you. That was true. It will take on a list of package and version and query snapshot, and you can do the right snapshot to your own. Okay. It's just going to do it for sbill. For sbill? For sbill. I don't know if people want it for other tools. I don't know. Whatever tools make you happy to make it happen. Yes. You can do that if people want you to do other things. Do we have a way of measuring our progress with all these things once each person has done these individual pieces, measuring what fraction of the tree is in a good shape now? I think... We need a can turn. I'm asking, have we... I know when to rebuild the whole archive. So I actually kind of think that this framework is the framework that we need in order to get to the point where we can do the results. But I could be wrong. So if we're producing the viewed info and this changes to us, we'll take that and build it and just say it matches and it didn't or it didn't. And then we're like, okay, now we're going to step closer than when you can do that for one package. And then, okay, it matches. Good for all of them. Folks like Lucas do archive wide rebuilds. And if we can say, here's a set of tools and if you do the archive wide rebuild with these tools, we'd love to see what you come up with. But maybe it is actually the one doing that. So I think this is what we need to get back. I still probably, I don't know, maybe, do you think it would be useful? So we kind of stopped, because I told David, okay, let's hope we can now, so we don't have time. Do you think it would still be useful to cut out to do a rebuild with the build path fixed? Yeah, I think. I think that... Wait, how are we going to get the build path fixed? It's, I have a patch wise build, but that's the thing. Yeah, we can just like take what's in there and build the text what's in there. Do we need to be submitting that patch somewhere? No. Is that another to do? Well, it would be part of... No, it would be part of... Well, yeah, maybe, but not... Just add it to BTS. Of course. It's... Where do we start for this thing? Like the... We start by documenting. The kind of people... Yeah, the kind of people path. So if it's a wishlist bug for S-Build and say... Then just put it in, put it... So that when people are looking at the S-Build BTS, they see that this feature is available if we want to do it. So I'm going to put that down as another one. Sorry, you wanted somebody to focus on what are you doing? Yeah, sure. I'm sending the platform. But I need to test it before. Yeah, yeah. I'll give it to Jeff to test it. Yeah, I'm fine with Jeff to test it. Awesome. It's a five line project. Cool. Submit it to me. Can I start submitting to Jeff to you? I think I'm going to test it. Well, no, it's BTS. Wow. It needs to be published someplace. And if it's bad, we'll get a new version. We'll publish it in the same place. It's fine. Attach the dash, don't tag a dash. Awesome. Great. Thanks a lot. And when we have done the initial rebuild, I believe we can also start having some continuous integration. Yeah. And we have something in Tracker. Well, frankly, we can say that 60% of Dabian builds deterministic builds. And we can say, here is deterministic Dabian. It doesn't have any restitution. I won't have a candle. You'll notice that we have a kernel. Yeah. There was probably more changes to my idea. I think there is a couple of timestamps that are captured by the build process. I have my cons. There might be a lot of them. And the one that was in... What I know is that some people started something called Membo. And I really tried to talk to them for ages, explaining how Dian worked or what they liked to do when they were. And they hadn't heard from them. But they never said, what does it look like? This is the way we change it. I wouldn't know if it'd be here. There's our stuff. Do you want to figure it out? But they use defect time. They defect it all over the place. I don't have much of an idea to get a clue to Dabian and all of that. Because of the GRSEC thing. Whatever. That's not a good idea. What I'm saying is that the kernel, they kind of made some work or it's probably going to happen to me. But the K3G engineer made some work on making the K3G. I was told that the one I uploaded today should be reproducible. I don't know. I have a question about time frame. Do you have time that you want to check in on each other? Is everyone who is submitting this subscribed? I think it's out of... But it's on the very top of the Wishing page which you also should subscribe to. So I will mail the list in a week or sometime after I'm done through my email back log post. Actually before too long I'll post these notes some days. I mean there will be a little bit of an update. I will probably update the Wishing page. The one we see today. On the Wishing page there are two rule lists. So we can also update them. Now the rest of the Wishing page should probably be changed to reflect what we decided people feel like this could be reproducible. That would be great. The more we can see about how fast we're moving as we go the better we can give momentum and help us get faster. We can't see that.  Just patch two more percent. I mean the DH DivePython deterministic right over the deep end I believe is like 80% of all Python packages. A bonus. Is there anything left to do except to leave and go drink or play? That's it. Yeah thanks a lot. Thank you for calling me. I'm sorry I was late. The sushi restaurant was like half an hour slow. Can we try to bring back this? No, I maintain. There are a couple. What are two packages I maintain for work? I maintain for work.


Did you know that there are over 2,200 known religions in the world? We are all born into one belief, religion, or faith, which influences how we see the world and everything and everyone in it, including ourselves. Do our beliefs divide and separate us, or do they bring us together in greater harmony? When you look up with awe on a star-filled night, do you ask who or what created all of this? Have you ever had a profound or deeply challenging experience in your life that changed your beliefs at the core of your being? Enlightened Pathways takes us on a journey of discovery to understand just how spiritual transformational experiences impact our lives and the world around us. Join us now as we deeply explore all that nourishes, heals, and inspires us. Welcome to Enlightened Pathways. Welcome. My name is Robert Rebecca, and I am your host today for Enlightened Pathways. With me today is my guest, Nikki Lamarbe. And I met Nikki all about four years ago as I started a little journey around the country, and I met her at a festival in Quincy, Quincy, Kinsey, Massachusetts, Quincy, Massachusetts, yes. I always hear it pronounced very differently. So Quincy, Massachusetts. And I was wandering through the festival, and I was kind of quite down and out, because I was experiencing some significant shortfalls in my life at that moment. And so I was walking through the festival, and I passed by this little booth that was selling this beautiful jewelry, and it just stopped me in my tracks. And I stopped, and I looked, and Nikki and I started having a conversation. And we quickly realized that we were quite kindred spirits. I've learned a lot about Nikki since then, and I've followed her journey across the country. She is a crystal healer. She works a lot with selenite in her healing methodologies. She traveled around the country to some selenite digs, and dug up a lot of selenite over the past couple of years, created this beautiful mobile van that she's traveled around in. And so I'm very grateful that you showed up here this weekend. And we had our own little tours here in Maine as well. So as I've learned about Nikki and her journey, one of the things that I've really appreciated is her depth of being. And I've really resonated with that in my own spiritual growth. And her own creations have helped to ground me in my own spiritual path. So with that, I'd like to introduce you to Nikki. Thank you for having me. Very welcome. I was so happy to get the email and invitation to come and talk about my favorite subject of all time. Your favorite subject? It totally is. Excellent. Why don't you tell me about that for a minute? Like, 26 minutes is not enough. Yeah. So my life is about my spiritual journey, and my work is about it, and my consciousness is about it, and just focusing on where I'm at, being aware at what I'm feeling, what I'm thinking, or attempting to every moment of the day. So yeah, it's a beautiful thing. That is. Then did you start to recognize your spiritual connection early in life? Yeah. So for me, it was early. I was raised Catholic. I'm the youngest of seven children, and we grew up in the country in the tiny town of Menden, Massachusetts, and I was let out in the morning with my dogs, and I would play until I heard the cow bell to come in for lunch. And so there was a lot of beautiful quiet time in nature, and I would have these moments of bliss. I would be perhaps in a tree, climbing a tree, and just having this moment of stillness where I could hear the wind blowing through the pine needles, and all of a sudden I would have this overwhelming euphoria flow through me, and it would last only a few seconds, but each time that happened, I would want to capture it, and I would think, oh, what made me feel that way, or what was I thinking, what was I doing, and it wasn't like getting a gift and feeling joy about the gift. It was something different, and yeah, so those were the first moments, and then my father was French Catholic, and my mother was Irish Catholic, and they grew up in Malboro. Usually the two did not mix, so he would speak often at the dinner table, Sunday dinners, about the hypocrisy within the Catholic religion, and how the French and the Irish, and they couldn't even get along, and they're all Catholic, and how can that be, and then he would bring my attention to, or bring everybody's attention, to the fact that we'd go to church, listen to a beautiful sermon, be touched, moved, and inspired, and then get into the car, and people are trying to cut each other off to get out of the parking lot. So that really made me start thinking, and that was at, like, seven, and I remember thinking to myself at that age, how are we ever going to end war, poverty, injustice in this world if we can't get out of the parking lot? That's a great question. So that really set me off, then two of my brothers became Jehovah's Witnesses, which started a whole new dialogue in our family of religious introspection and just observing in my own family the lack of inquiry as to why my brothers became Jehovah's Witnesses. So after college I ended up studying with them for, I lasted about six months, and if you've ever studied with the Jehovah's Witnesses they have a book, and you read, they have you read, and they tell you things, and they bring it back to scripture, and then you have to answer these questions at the bottom of the page, well, they, obviously people who just are led easily would read the question, answer based on what they had read in the book. Well, no, I kept going back to Genesis. It was like, okay, this doesn't make any sense to me because in Genesis it says blah, blah, blah, and how can you, how do you equate that, and yeah, we, we didn't do very well. And it wasn't antagonistic on my part. It was really trying to understand, if Genesis says this, how did we get here? And what was it that started you to question that, that even inspired you? Because I loved my brothers, and I felt all of this tension in our family Mother's Day was a contentious day. My father would be very upset at my brothers who are witnesses because they don't celebrate holidays. How could you do that to your mother? And so just trying to understand, you know, always going back to how can we love each other more? And that's what Christ's teachings were about to me. It seems very simple. Do unto others as you would have done unto yourself. And I think, yeah, people just stop and take a minute to think instead of being led by the dialogue, especially nowadays, it's been a challenge. But one of the funniest things that happened to me was I was 14 and I walked into the kitchen and it was after school and there are my, my older brother Ed was the first to become a witness. And then my, the next in line for me was my brother Richard, he's four years older than I. And they were talking about, they got really quiet when I walked into the kitchen. I was like, Hey, what's going on? What are you, what are you talking about? I could feel the energy shift. And they said, Oh, you know, we're talking about the Bible. But and, and we, I was like, Oh, okay. And so you could see the gleam in Ed's eye like he wanted to tell me. He's like, but you can't tell mom because you're at that impressionable age. Right. I'm like, Oh, I won't say anything. So they start, he starts telling me about Armageddon and revelations, which is some heavy duty stuff. So here I am listening to all of this. My eyes are getting wider and wider. Like, Oh my goodness. This is the, you know, the good angels are going to come down to have it from heaven and help the bat or get rid of the bad angels. And there's going to be this big battle. And all I could think of was I want to help the good angels. Like that's all I, I became like obsessed. Like, how can I help instead of being fearful that I'm going to be destroyed because I'm not a Jehovah's Witness? Do you know, I was just like, Oh, no, I want to help. I want to help. But so it's just interesting that. And then as I grew older from there, so I was about 14 then. I just didn't, I was like, if you believe in a, if it's a vengeful God. Yeah, I'll take death over that. It was just like, I don't want to do. And it was just so counter against my nature. It didn't make any sense to me. You either believe in love or you believe in fear. The two don't, they're polar opposites in my brain and way of understanding. So most people think it's love and hate, but it's love and fear. It really is fear. I mean, yeah, to me, my understanding of it is that fear begets hate. Yeah. So it really is that fear response. And so much of the dialogue today is based on that fear, is using people's fear to lead them in a certain direction. And I just have gone the opposite way, like trying to stay in a love vibration every day. It's a much better place to be, isn't it?  It does feel good. And I know that for someone like me, it has taken many years to navigate a history of challenges, to keep it simple, to understand where my source of power, my real authentic source of power was coming from and what it was really connected to. And being brave enough, I don't know if brave is the right word, but finding the courage enough to be willing to explore it. Because I, too, grew up in a religious household mostly, and Catholic school, and Sunday school, and what have you. I was told what to believe, but not explained. I was taken away by choices. And when I started to discover I could make my own choices, for me it was a lot of guilt and shame about making it as, oh, wait, if I don't believe in the God that I was brought up to believe in, I am going to have this. Right. Yeah, and that's not everybody's experience with growing up in those churches, but it was my experience. And I was the one who had to live through it and grow through it and find a way on the other side of it, where I could start questioning carefully. Yes. And asking difficult questions until now, I feel an immense freedom to explore my consciousness and awareness and that source of power that I experience within myself, that I experience with other people. Yeah, that connection. I love, is it the Christian scientist? No. What's the other one that says that the only sin is believing in the separation? Like that we're not connected to each other, that we're not one consciousness streaming through into these bodies, these separate bodies? I don't know which one it is, but I resonate with that a lot. Yeah. Separation is where, because if it's me against you, who am I really going to choose? I mean, the human psyche is built around self-protection and self-preservation. And so if there is that separation, I'm going to go for survival. Right. Instead of looking at it as me and you and understanding the different lenses, sometimes I look at it as like one of those beautiful stained glass windows and the light of source energy or God or the oneness shines through, the scientists would call it the quantum field, shines through that beautiful stained glass through all the different colors and shapes and lines and expressions of that one light. I find that the concept of being connected, being one, the unseparation of not just between me and other people, but everything, tends to create a life that I feel I am in flow with. Yes. Yes. And the deeper I go into that flow, the easier and more fun life becomes. Like just this morning, I was visiting with some friends and I could hear their thoughts before they would say their thoughts. And so and then they were like, I was just thinking that. I said, I know I heard you. And it just becomes, yeah, so much more fun and easier to communicate with other people and to really hear their fear and feel in their energy where what's going on? Yeah, absolutely. It's wonderful. What do you think has been helpful for you over the past few years? We've been through COVID, we've been through and we've been through some interesting things on this planet over the past few years and that I have found challenging to reconcile with my own concept of unity and wholeness and unconditional love and acceptance and participation. And I find myself many times in a place of contention as opposed to, again, wholeness, cooperation or something like that and having to re-explore and repurpose my connection so that I can still find a way to fit in and be part of. So in your own experience over the past few years, what has that been like for you to navigate? It's been a challenge and I feel like sometimes the greatest gift that we can give somebody else is a good old slap in the face. And not in a mean way, but in a wake up way. So I use social media for my work and my life, so I'm very present there. And I have given myself permission to unfollow, block, delete people that are very stuck in the mud about this is the way I'm going to look at the world and I'm not listening to anybody else or anything else and I'm being rude and demeaning and cruel. And so how do you deal with that in a balanced way? I'm not going to enable those people by continuing to keep them on my social media and some people are like, oh, that's so mean. But in a way, it's taking a stand and it's saying, no, there's a better way. There's a better way to communicate and I am open 24-7 to have any conversation with any person always. But forgiveness comes with asking and apology. There's a two way and you can't just, I won't ruin my own vibration, energy, sense of peace and centeredness by having discussions and conflicts with. And I feel like that's OK, that it kind of, when we walk away, a good friend of mine told me the other day, he said, I realized that a certain friend had unfriended me. And he said, I asked her, have I been too much on the deep end? And she was like, yeah, like you kind of have. And so that was that proverbial slap in the face. It got his attention to really stop and say, huh, I may want to rethink this. Like, what's more important to you, loving human beings or being right? And I feel like love is the answer. If we could just go back to that and be committed to peace and conversation, I think we'd get back to a better place. But it's been devastating. And I feel like so many of my friends in the spiritual community have bypassed spirituality 101, kindness, compassion, respect, understanding, integrity, authenticity. That's what spirituality is to me. And I feel like when we lose sight of that over being right, we're an ego. And it does get difficult at times for me to hear people who profess to have embraced a certain belief system, you know, a certain popular religion or have you. That is supposed to be quite loving and accepting in an unconditional way. And yet their behavior is everything but. Exactly. And so it's like, well, wait a minute. How do I put this and this together? You know, how do I make sense of this?  It's again, yeah, the hypocrisy. It's hypocrisy, yeah. And if you could just live the beatitudes for one day.   And I'm like, if you all could just follow Christ's teachings and live the beatitudes for one day, then come and talk to me about, you know, how you're going to be saved. And I'm not like, and if a God is going to be like that, then sign me off. Like I don't want to participate in that. Like it just feels so counter. Like it doesn't make any sense to me. Well, you know, it's interesting because, you know, you and I have a similar concept in the construct of how, you know, our human psyche works and how we engage in reality where we hold a belief. And that belief is designed to inspire us to act in a certain way. Exactly. However, if I say that I'm unconditionally loving, but my actions are not, where is that disconnect? And what is it that's going on inside me or a person that's able to justify that disconnect? Because I am of the belief that there's a positive intention for everything. Totally. So even if I'm lying, there's a positive intention. If I'm deluding myself, there's a positive intention behind it, you know, in some way, even though I'm not aware of it. But what is it that makes that happen? So I'm always curious how to unravel that so that I find myself able to what sort of want to use this, that I find myself able to distinguish whether or not I'm actually walking my talk. I told a good friend once, I said, Frank, I will always love you. I may not like you, but I will always love you. Yeah, it's OK. So in that unconditional love, I completely have love, compassion, and understanding. I may not choose to be in the presence of the other. We've got just a few minutes left. The time flew by, right? Told you. I know. And so I have to ask, it's like, what is one of the most important things that you value within your belief structure that you think might be beneficial to our audience that they might be able to latch on to? It's just I feel like making peace a priority, like just making inner peace a priority, taking that deep breath, giving yourself a couple of seconds. Mm-hmm. I love that. I love that. Thank you so much. Thank you for having me. Yeah, thank you, everybody. And unfortunately, that is all the time that we have today to spend with Nikki. And I am so grateful that you made time to come up here and be with us in person. It's such a huge thrill. Love to be in here. Thank you. Thank you. If you'd like to get more information about Nikki and about her crystal healing practices and about the beautiful everything she makes, just spectacular, you can visit her website at crystalandstonesstudio.com. Thank you. And I'll put that up here on our website so you can find it there. And it'll also be in the credits as well. And just a few closing remarks and a shout out to today's executive producer and sponsor, Bridge to Heaven Healing and Lipin Lizards, which is the premier source for healing crystals and readings with four locations, including 1, 2, 3, Main Street, Freeport, Maine. You can visit www.lipinlizards.biz for more information. Also, a big thanks to our co-executive producer, Dr. Anna Kabeca, the creator of Mighty Maka Plus, the daily nourishing supplement that improves metabolism and reinvigorates the body. Visit Dr.AnnaKabeca.com for more information. Also, if you would like to get more information about this show to reach out to us or to sponsor us, please visit www.deepbeing.org. We would love to hear from you. And a quick shout out to the crew, Director Packard and Carton, Audio and Sound, Dale Ashby and Cameras, Travis Nadeau, as well as to the Portland Media Center and their team, Tom, Dino and Warren. We wouldn't be here without them. Thank you for watching Enlightened Pathway is in spending your valuable time with us today. Until next time, play, have fun, be happy.


Hello, love bugs and welcome back to my youtube channel. If you're new here I'm Sarah and I help teach people how to find inner happiness through fitness and spirituality and today We're gonna talk about the secrets of the divine Masculine I've been doing Heavy research into the divine feminine the divine masculine energies Polarity how they work with each other how they can work against each other, and I'll tell you guys what I Am totally consumed with this information And I just finished reading the way of the superior man by David Dita Which is pretty much where my inspiration came from to film this video right here Now you might think it's a little odd that I'm doing a video on the divine masculine as I am in fact a Woman, but the thing is is that we all every single human being Has a divine feminine and a divine masculine the thing is is that the majority of people? I think it's somewhere around 90 or 95 percent have a much heavier Core that is aligned with either the feminine or the masculine and this isn't necessarily gender specific It doesn't mean that that every female's core is a divine feminine Every male's core is a divine masculine Although that tends to be the majority of people and a lot of times we can tend to pretty much flow flow Back and forth between the two now I want to play a little game real quick before we get into the video And I want you to think do you think you fall closer to the divine masculine at your core or to divine feminine Let me know in the comments below We're just gonna say feminine masculine Okay, that's just how we're gonna do this video because we're probably gonna say it a lot So the feminine's main priority is the flow and the love and relationships While the masculine energy's Priority is their mission in life that leads to ultimate freedom. Now. It's no secret that men and women are Biologically different. However with the feminist movement and the way that women have Come into the workforce stepped up own businesses own companies Take charge of the finances and their relationships. I mean shit women even run countries But because of that The majority of women have really gotten away from their core feminine and have very much stepped into their masculine energies And I would say that that has happened to me over most of my life as well And so right now I'm learning on kind of how to Step back and fall back into my feminine core energy, which is 100% certainly where I fall And what happens is if you're a core masculine living in your feminine or you're a core feminine living in your masculine You tend to be very misaligned with your fulfillment in life What makes you happy and it can cause a lot of just unhappiness in life now the divine feminine and divine masculine Share the ultimate goal. However, it's an extremely different journey on how they get to that ultimate goal of love and of freedom the masculine mission is always going to be more of a priority to the masculine than Relationships love their woman and that's just nature now That being said that doesn't mean they don't want love and relationships and a Female or a feminine companion to go through their life with just as if you know The woman doesn't it's not like we don't have Missions and we don't have a purpose to fulfill in life, but at our core it's just not the number one priority as much as love and relationships and Relaxing into our flow is and in reality as David explains in this book the masculine's mission actually serves both people in the relationship think of it kind of as Filling one's cup up before they're able to flow and fill other people's cups up or another example would be think about how when you're on an airplane and they're going through before you take off all of the Safety procedures and precautions and things like that and they always say hey if we go down put on your own mask Before you put on others because in that way you're able to help more people Then if you're worrying about putting a mask on other people and you're running out of oxygen on top of that if a masculine isn't Concentrating on fulfilling their mission and their ultimate happiness, then they're not actually showing up as their most authentic selves in the rest of their lives in their relationships in their families even in their friendships the masculine must live their Purpose to be able to be fulfilled so that they can live their ultimate truth and be able to show My freaking camera died even though she said she was full, but she would lie in so Anyway Where were we out so the truly interesting thing about this book that? really caught my attention and really aligns with what my biggest like truest inner beliefs is is that our missions and things that fulfill us change as we go through life like What you wanted when you were five most likely not what you want when you're 25 Not the same thing you want when you're 55 like we change we evolve hopefully and Those things change too So I also had a lunch break when Mike When my battery was charging if I seem a little more energized I am It's also hot as hell out here. It's been so freaking humid the past two weeks. I digress as a masculine and also as a feminine We go through cycles or layers of fulfillment as we go through our lives once something fulfilled you back in the day Probably doesn't anymore. There's a good chance that something you did a while ago You loved and you really enjoyed and then like over time you kind of Didn't really enjoy anymore or things change or priorities change an example for that for me would be I was a competitive gymnast and like pretty bad-ass one too and I loved it. I spent Three hours four days a week at practice. I spent the weekends at competitions plus obviously going to school and Then one time I got injured. I think I was in seventh grade and I'd been doing it You know since I was like five and I was like I don't want to do gymnastics anymore I loved it like my love for the sport didn't change But I didn't have a life and I was getting to the age I was what 12 13 like I wanted to have a life. I want to hang out with friends I went into like do things and so I quit and I think that a lot of people and I talked about this in my last video Think that once they choose to do something like that's it. You're not allowed to change mine screw that So basically as you go through these different layers of purposes and fulfillment You kind of like check it off and then you go to the next one and then you check it off This is not a check check it off and then you go to the next one because you completed that layer I don't know why he's saying it that way layer of purpose You know even with my career path I believe I went over this in another video, but you know, I went to school for journalism I didn't do journalism and then I was acting for a while And then I sold cars and then I was the general manager of a gym and now I'm in real estate and guess what now I'm circling back to acting because I didn't fulfill that layer Because I it's not complete. It's not complete. So More on that to come in the future, but they're excited. So the biggest thing that I really took away From this book that you know as a woman was a bit hard to swallow Was the fact that the man's priority the masculine's priority Is their journey is their mission? That's what's going to give them fulfillment Not me not that chick Can we add to it? Oh, yeah And it goes kind of on the flip side too, which what David spoke about in the video is that you know Sometimes you'll hear from you know that the masculine in the relationship saying to the feminine Well, you know, why do you care so much about this? You care way more than me You know stop focusing all your attention on the relationship and blah blah blah when in reality That's the feminine biology. That's who the feminine is at her core So as I'm studying this stuff, it's realizing that Not only do we need to understand who we are at our core whether we are Feminine or a masculine, but we also need to understand our counterpart and how they operate because it's that polarity That will bring us the most satisfaction and fulfillment in our friendships and our relationships in in anything and any type of human frickin interaction now I will say and I feel obligated to bring this up because While I very much enjoyed this book. It was very much Geared towards the masculine the man Whatever there were two things in the book that Kind of offended me So And it might not offend everyone Offensive now. I understand the guy's book. It was geared towards guys There are plenty of women that read it. This book's been around for over 20 years But I feel like if I don't talk about these two things real quick I won't be filming an authentic video and book review So the first thing is that David says the feminine does not speak What she means that essentially her words mean nothing because the feminine is controlled by her emotions while I agree in the sense that yes, the feminine is very very suede and controlled by emotions myself included I go through 20 moods a day every day. It's very exhausting. I think to Say that women don't know how to communicate clearly and speak Out for what they want It's kind of bullshit I feel that the feminine or a woman that can't communicate effectively is underdeveloped and immature now the second thing I felt was Very offensive this one More was how casually he spoke about How it's just normal for the masculine or the man To have mistresses and I'm not talking about, you know, dating around when you're single whatever I'm talking about a coupled up man in a relationship Committed to a woman in a marriage and they have a mistress He spoke about that in addition to pornography strip clubs all that kind of stuff as being just so normal and so accepted and I just don't agree with that. He even talked about Lusting after the man's 18 year old babysitter Look men by nature are more visual creatures and back in the day when humans were like, you know new on earth Their job was to procreate and so biologically it makes sense that Back in the caveman days Yeah, they'd want to impregnate as many women as possible because the whole point was to procreate on earth that being said I feel that men in modern culture today that are controlled so deeply by Women or the feminine energy and their desire for women are unrefined Unhealed and also immature while I believe it's completely normal and natural for the masculine to be Attracted to other women other feminine energies. It is also very barbaric and immature so it consistently lust after them to the point of being Emotionally disloyal so overall really enjoyed the book definitely geared towards men or the masculine Whoever the masculine is in the relationship There's always going to be a feminine and masculine in any relationship whether it is heterosexual Homosexual all shades in between there's always going to be one in the other and the more Polarity they have the more masculine and the more feminine the more it's Going to have longevity and and work out as long as those two people do communicate and are educated on this kind of information I think this is so important and I'm going to continue Sharing information about the divine feminine and the divine masculine on this channel because I find it so fascinating I would absolutely Love to hear your thoughts on this video. So please let me know in the comments below and also Were you right? Did you know are you a feminine core? Are you a masculine core? Are you not sure and if you're not sure ask me a question in the comments below and I'll do my best to Into your question. I love you guys so much And I can't wait to share this journey with you as I evolve and fall back and get back into the groove Of my feminine core energy. Thanks for spending time with me today and don't forget be limitlessly yourself


A new study suggests that early ACL reconstruction surgery delays secondary injury to the knee meniscus compared with delayed surgery or non-surgical treatment. The findings are published in the American Journal of Sports Medicine. The anterior cruciate ligament, or ACL, is an important stabilizing structure in the knee. Injury to the ACL places additional stress on neighboring knee structures, such as the meniscus, increasing the risk of secondary injury. However, it's unclear whether the type and timing of ACL reconstruction affect the risk of subsequent meniscal injury. To find out, researchers recently used machine learning to compare the risk and timing of secondary meniscal injury among patients whose ACL injuries were treated non-surgically with early reconstruction surgery or with delayed reconstruction surgery. There was no significant difference in the overall occurrence of secondary meniscal injury in the patients who were treated with versus without surgery. However, the patients who underwent early ACL surgery went longer without developing meniscal injury than those who underwent delayed surgery or no surgery at all. Random survival forest models outperformed the traditional Kaplan-Meyer method in predicting the risk of secondary meniscal tear and the duration without meniscal injury. Risk factors for secondary meniscal injury were also identified. In the surgical cohort, an increased time to surgery, a faster return to sport, a younger age at the time of injury, and participation in sports involving high impact or rotational landings were significant risk factors. In contrast, in the non-surgical cohort, the significant factors were a faster return to sport, greater pain at the time of injury, hypermobility, and participation in non-contact sports. Notably, this study was retrospective and there were some differences in baseline characteristics between groups. For example, the surgical cohort had a greater incidence of simultaneous meniscal injury at the time of ACL injury than the non-surgical group. In addition, the non-surgical cohort had a greater proportion of partial ACL tears. Therefore, the initial injuries may have been more severe in the surgical cohort. Furthermore, there were differences in sports involvement and follow-up times among the groups. And surgical techniques for ACL reconstruction changed considerably during the study period. Overall, the findings show that performing ACL reconstruction surgery soon after injury may help delay a secondary meniscal injury. They also identify machine learning models with good performance that might be useful for clinical decision making regarding the treatment of ACL injuries.