 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. Big D and big U are the two options. 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. But it's also possible, right, that some packages will have files in them that are weird, nested, crazy shit that we don't know what to do with. 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. If you sponsor packages, somebody just mails you a dot dead. 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 build a fucking tall brother. 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. Look, if you're like, things that are stupid in the compiler. 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. So we need to clean up afterwards because otherwise we fucked the build process. But come on, come on, see an HTML file? This is not going to fuck the build process, right? 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. So like 60% of you are like ooh I can pull that line up. 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.