Yeah The last year ago when we did their own table it like made this possible all the work we've been doing in the last year and I hope it's going to happen again because it was really magic just to say true stuff So Hogger made some slides so that's where we want to go What are we now We're in the present we want to go to the future No, we are here That's the end of the year So the other grant was a lie and so I thought we'd make a bigger life make it even look more fancy That's where we want to go maybe not that fast So if you have a tradition Yeah, that's right So basically we wanted to make a list of what we had to discuss but we failed because we wanted to make a good talk the past hour and I think we did it but we could not do everything Yeah But we can just put the bobbins as the box we had Just put them on the other presentation again Yeah, I can tell you from that The real blockers anything we could do is to get these fixes in the deep package that help build on the build piece having to read on the how such the users can use have that in S build and have the FTP archive support build in profiles These are the topics So we start this deep package Deep package One of the issues with deep packages that I've mentioned from the list for me the biggest blocker because currently the times times in the R container is the only thing that qualifies in a way a build environment for me losing that information right now where there's no replacement is a short stopper So as long as we don't have the build information or whatever it's containing in the archive I'd rather not make the R container or lose that data But if you would have this build in profiles you would be fine Yes, because then that information is somewhere else So I don't want that information because right now it's just a really fast approximation but it's the best we've got now So if you want to know when a package was built you can check the timestamp on the binary and you could infer I mean of course it's really fast but you could infer from a snapshot what was the environment for that day the build information is the kind of the critical path for like everything else because the tar reproducibility stuff and the other remaining things are things that affect only the binary package So if one of them is not reproducibly the rest are unimportant So it's either all of them or not It doesn't make sense to or it doesn't matter if they are in an issue I know that for Helmut it was a problem to not have the file ordering patch because he can filter the timestamp issues but the file ordering is much more complex to analyze It's a bit different The timestamp still is different Okay, there's two lines in the diff but since I have to cut down and diff at like one-to-one lines the top of the diff is polluted with all the ordering issues and then I don't see the interesting bits so getting the ordering right would make the diffs immediately much more useful In that sense I've actually talked with Chris and Holger that I've got the patch locally that I've not tested properly or sensibly and I'd like to test it before I deploy it because if it's not localized to the rotors of the stuff it affects the whole archive and I'd rather not break Debian So we can test that patch Probably the poll issue is missing and I can send it to you guys and if you could do a run over all the guys at least that part I might find I don't have an issue with that part Three bucks there's two non-diversities ordering and the file permissions also I guess for normalized file permissions when creating control Yeah, I've not actually looked at the patch it felt there was something not completely right but I have to check it out but also coming back to the M time stuff you mentioned on the poll and now we have to discuss it at least I think discussions but if upstream is not amenable to have tar except a clamping value for them times something I want to do meet long-term is to have an internal tar implementation for creating In-defect, yes because that will also allow us to have other features so for me that's on the origin and that would mean that we don't have to if tar upstream supports or not clamping this clamping could be done already on the package itself and then it also means that we don't have to modify any package to do these fine things on the file system Out of interest what are the features we think are related to that will allow us to get packages without being rude so you can have a manifest and then you can specify the permissions and owners so I think you should definitely capture that you feel that the ARM time issue blocks on build info we should capture that you think that the AR issue requires the build info to be available yeah that's done because that's a dependency between issues yes the M time thing is we can work around it in other places but for me the blocking is the things that are the build info are the rest are not in just because you don't have a fully reproducible package just like this I'm just not sure so it sounds like this build info stuff is going to take a while to actually hit the archives would you accept the patch in the meantime to basically standardize the ARM time based on source state input let's discuss the build info before arriving to that conclusion yeah so at least for build info I have several concerns for boys one is that the path embedding the build path which for me is a privacy issue because it leaks information from your your governing system and I don't really like that but there are always leaked information sure but one of the points of reproducibility we want to standardize to make things like neutral and not expose like time zone and all that stuff that we currently have this problem doesn't mean that we have to make it worse and if you are building binary packages on your system and you get a build info file where it leaks your home path with all the build I would like to separate the path from the build info file because the path we also would need to discuss the ability to maintain as where they build and talking about we will have build info files with some path in there I would like to discuss that first and then come back to this privacy leak my solution would be just a white listed file we agree on slash paths and then you could only get the build info file if it's written in slash paths and so that you if you build slash build then you put it in there because if you have a privacy leak information slash build it's your own fault but if you build in Bohn Holger my secret project you probably don't want to leak it so and regarding the build info files I should like to explain this build before I leave first that was one of my questions what exactly is in a build because all I've worked on up to date sounds like it's something that could go into the packages files as it's copied what does need on files for that the build info file at the moment has the build files which we will discuss it has the checked sums of the source packages view it has the checked sums of all binaries created and it has a list of the packages installed in the package so that sounds pretty much like just the packages files that makes the handling much easier a source file a source file no the information is for a source file this is binaries it's written in binaries but you would repeat then that information needs to be written per source file per architecture so it's actually not so specific it's for the it's build specific you have been in a new year on the same source and you don't have the same can you maybe go for an example yes I'm trying to find one open it on another just a file make it a bit smaller so we can can you open just a file but we call it a frame or that's really good does that make standard for changes files I mean something I've been pondering for a while is that for me I'm switching from if this really makes sense to put into a different file or not changes files yeah but the changes files are not exposed on any interface I mean of course we have to have changes agglomeration of the things exposed in the repository but what we thought about these files what we thought about these files and in 200,000 files to the FTP server is a bad idea because as many files as there are now for sit and scratch so I try to just cut them all together and that reduce the size so that made it one file and made it 140 megabyte but I assume the file will even be smaller because half the packages are arch-all or whatever percentage and compare this 140 megabyte to a 14 megabyte is that all files together or per architecture? that's per architecture but we will need these files per architecture and I would also want these big files to be on the Mural Network for the users while these individual files I would be finding I think it would be enough if there would be an FTP master a major snapshot so that we can build a service for the Mural Network users can download these files users will need to download these files to reuse it or they download them and what about some things to do you cannot put them in the depth file because then you change them right well, the same thing you get every component with the file not the depth file it will also bloat the packages file you get all the the dependencies it's pretty big I think the packages file now that's huge that keeps every user so you have the data in the same format as all the local for the description files but that's what I would put one thing specific that thing maybe whether we put this information in the build info file an extra file or put it in the ARF changes I think changes makes because most of the stuff is just the same so that's all yeah my initial idea was that changes and then I researched and in the end I thought it was my idea for several points that changes file do not have a normalized name you can upload anything that changes with some reference and it will just go in you can upload source only packages and accept it so in the context of reproducible build they don't have any binaries so they don't make sense and also for me that changes they represent the transaction to the archive we are building for information that we want to keep forever associated with the actual binaries and the source and the last point was that the last point I don't care what? the last point I don't care which one? the transaction versus snapshot of the well maybe you don't care but for me it was easier to be done that way anyway in the last thing was that I want multiple people to be able to sign that file and the changes right now they have an inline signature and you can't have multiple signatures with inside signatures it's actually not such a crazy idea to put the build input back inside the depth because if the build environment changes then we would expect the rest of the depth to change anyway you cannot create half a head look you cannot have the depth like but you don't need to put the hash of the depth in the build input file you put the build input file without any reference to the depth itself inside the depth and then anything that's about the depth you can just get where do you collect the hash of the depth you don't need the hash of the depth I did just hash the depth but if you have it in the changes file and the rest in the build input file you need two files where you need one before yeah so that makes things more complicated if you put the instead in the input file you put the hash of the data.tar .exe then your depth will be the same file you have the same hash and you have the build input file inside if you have the same build input one tension for me is what kind of tool will you use at the end of the rebuild process to assess that you got the same information and I believe that Shassan is easy enough anything more complicated that means that you have to prove that more tools are actually correct and that's you would have the same just the very easy I think I can check the light on this just thinking one different way I think at the moment Luna is trying to reproduce the build input file while other people just want to think about reproducing the depth files so maybe that connection should be split I believe in build input files there's at least three problems that's uploading the information storing the information and signing the information and at least my feeling would be that for uploading the information in that case just the list of dependencies would be the changes files which is just a transport container for uploading the stuff then you need to think about how to store it and then how to sign it is yet another question but my feeling has always been that this build input file doesn't really fit into the way Debian is working at the moment so maybe use the changes file as an upload container and then store the information in the packages like file these build info for me they will be listed in the dot changes and uploaded to the archive I have referenced in the dot changes and also for the signature part it is the same problem because if I want to do a rebuild I don't want to have to download the actual dot then from the archive just the build info file you can even accept that you can upload new changes file signed and then you can extract the signature and store it somewhere else you don't need to keep the changes file I don't want to keep the changes file the point is that if we end up agglomerating all the contents in a big same way that we have packages we have changes or whatever then you can store the signatures somewhere else I mean I kind of agree with what he is saying that one thing is a container and this changes file is just from base information and then we store it in the database whatever way we want and then it can be exposed in a single file as someone who did the initial build I want to give to the world a proof in a session that this is what I got so this is the build info signed to be multiple people like first byte developer so I don't have to trust the archive that the key from the archive is not compromised and I can check initial keys one by one and the keys I want even like I can trust some only a subset of GBN if I do it this is why the use case is ahead in mind and so I don't want the signatures to be merged to be munched like hidden by the archive thingy so I don't have to trust the archive key as my own like my trust but that doesn't really work so the only thing you are trusting in the future will be the build keys which are completely automated because we are moving to having everything rebuilt by build keys not by people yes but I want the mention to be able to also say this is what I got on top of the build keys this is the thing we can do you make a source on your upload and have your build and profile into the good luck to be able to upload doesn't that require the build to rebuild using exactly the second versions of packages that were missed by the main technology maybe two thousand solo keys so let me give another reason for not including the build input into the Debian binary package so if you think of reproducible builds more as a QA measure then it would be interesting to know whether the package rebuilds to the exact same binary with slightly different build depends or thinking further if you swap out the build architecture and for being able to do such a thing one needs to have rebuild info not be in the Debian package so that's a useful thing for future and it would be cool if we wouldn't block that future right now so for that if the case of putting the control data and the other hashers of those inside the build that would still be able to admit your use case in general you wouldn't expect if you change the build environment for the output to be the same just sort of like philosophically speaking the dev is the end result and it's good for the end result to point to all of the context that was used to create it so I don't see for the signature space instead of signing the build-in profile you could just sign the hash of the dev and then the dev itself would contain the build-in profile so you're signing the same amount of information yeah but why not sign the build-ins for directly because then you have two files so you put the build-ins inside the dev you just need to sign the hash of the dev yeah but I mean I have to download that dot dem to get the data I need to reproduce it which I think is although what we just said that is upload the source and the build-in for and have it reproduced by the build-ins and see if it matches I don't agree that this is a big solution to put the build-in for in the dev precisely for Helmholtz reasons but if we wanted that that could extract this information on install time because that's what it's being done for the control information anyway so I mean I don't think that's a valid reason not to do that I think that there are other reasons not to do that but can we I'd like to use this session to not be only about the build-in for maybe you also should one minor question about the build-in profile perhaps a small note you see from T-Shirt so I can tell you a bit from OpenSousa perhaps you have the OpenCleanService it means everything automatically if a build-in had changes and for example there are cases where let's say you fix a typo in an error message in the library so that won't change the packages that into the library so for a version I'd not put the build-in before in the package because you can have different versions of the library and still get the same application that leads to it all for this kind of other topics also other topics but the only other relevant topic I see is the build-in class and the rest the step-by-step stuff is easy so I think it's I'm going to go to Rala but for the build-in for things I would like to hear yours then how do we proceed with this process just one minor comment can you show the build-in profile again can you please not in 2015 deploy things that mentioned in the private part one I'm using just a difficult library output and it does that I can remove it it's easy they don't hurt that is not true they hurt the brain which of these things clients actually very fond you should verify all of them no why should you not verify all of them because they know it that's another discussion there was one thing that I wasn't sure about what you just said is that at some point I was wondering if instead of having version here it would not be best to have just ash cryptographic ash of the package it makes it easier to find it on Snapchat and also it means that we don't have to rebuild the package later if it's only a change of version but right now we can't we can't do that because we don't have the information stored in apps in a database status library so maybe this is something that we should discuss but I like it it makes sense to replace the version with a package whatever of the defyers which version what you would have there is aduser and then the Shah 256 or 512 of aduser so you need to store it when you're folding it I would like to compliment the version by the hash so the Q&A person and me would like to keep the version even if we are not using it it is here to reason also yes I also have a concern when it comes to the either enforcement or what should we consider the container or the smallest unit of reproducibility and I mentioned this in the list I'm not entirely sure that I mean using the binary packages the smallest unit makes sense because it makes life easier for everyone but my concern is that it might disallow us or might paint us into a corner that we can get out of so if we want to include unproducible things by design into dead packages like signatures it disallows it so we have this if the bin is reproducible and it has the binary you can detach the second signature it has to be later with unproducible builds the signature will match yeah true signatures embedded into the binary I guess is what you mean but he's saying that you could have them outside and black so we started to discuss this also lately because of Grubb and Lenox signatures which in a few years in the Middle East but true this is if we want to have signatures for the dark dev as a whole dark thing my thing was like adding a field to the build info so we set signature and we just like at the end of the rebuild process could be pasted and see if the final hash match and I think that would work does it make sense well I guess it shifts what's more difficult from one side to the other so how do we move on with this third info by ready with this question so I personally find it hard to discuss just to give you a feeling is that I've been like trying to feel with this thing for a couple like 6 or 7 months and so everybody has to make the wall process thought and this is a bit frustrating to me so I'm totally up to discuss more but maybe with more crowd maybe 5 or 6 people and we try to get to the bottom of the proposal do you have all of the points right now on the page somewhere most of it is on the history page on the wiki and the rest is on my head I guess and the history page on the wiki there's quite some points and the rest might be in my head I mean I was like that's not so many notes I think that's not much in the history of what we know history page today is awesome maybe we can dedicate one hour tomorrow of this session we have to leave question I mean if we can leave that with having a concrete proposal then it's for everybody that would be also for this R but in the package we need an fdp master or two we need someone from the package we need what edge nothing nothing there three teams and yeah cool and the other question is the build pass we have 15 minutes left where to build the packages so as an introduction for that if we can get rid of the fixed build path requirement I would be up for it but we have no tool right now that is able to mingle like as a past processing step Dwarf and Elf files to get rid of the path to the dot c or dot whatever file that is getting compiled and right now the best tool that exists is called debug edit and sadly since Dwarf files contain now hash table for the string then you can use debug edit to replace the path that is in the hash table to other paths but then the other is not correct from mobile to the next because hash table ordering will be different anyway sorry too much details but yeah I mean we need someone to write Elf code like code to mingle Elf or Dwarf and this is not a problem anymore but this way is way beyond my skills and time but you know this is the way we got anybody squared who worked on this so far actually we start building debugging packages automatically on the not on the Montana machines and in a way this kind of disappears because most of the styles coming from debugging well they get embedded what we do for dvn is we pass minus g and then we strip yeah yeah but what I mean is that this gets recorded in the dependency moves and they are built somewhere else and it's not that privacy anymore for the container for the build yeah I mean we can we can agree that to have a fixed location for everybody that's also a way to solve it but it's just to say that this is not the it's a walk around already and it's not the final solution so as far as I know the build it's not build in slash build which one? it's just build so if we the package would only put the build in the build pass in the build info file if the pass is slash build I think the privacy concerns will be in the rest the point is that if we are going I mean if the helper starts like a meeting it builds them itself automatically so yeah that's a fix so this privacy was perfect but what I still dislike about this solution is that slash build is not it's not part of the file hierarchy standard and we want users to be able to rebuild the binaries so that way we would force every user to violate against the file hierarchy standard slash build which I think is kind of ugly so would we have a better path I would use whatever TMP, build, build whatever so far the build we maintain as we are rather like now we don't want to change this well the point so the build decided before were mounting partitions there now we have the work put including the build partitions and the same TMPFS so I guess we can we don't have any problem at least for all buildings that have been upgraded to GC and just tell us what it should be basically yeah I don't know what it should be I mean the point is that it defies my endpoint currently as long as we do a change last week I guess we can pick that for the buildis and any path is fine and the problem looks the same but you have to pay attention to build the name of the package and the version and it has been changed for security issues not for the buildis but for people using sbuild so that the path is unpredictable so probably you don't want to change what security means what not predicted as far as temperatures yeah if you are using different users if different users may use sbuild and the part the build partitions as long as we have a common fix I can key on that if it is srb buildi or other the idea is to have the same on the buildis and on what user can use sbuild should use a separate language so like let's say that for buildis I don't think we you are fine with any path as long as it looks the same but if it is same I don't see a new package but this is to get the change in sbuild and then deploy that on the buildis but it has to be always the same otherwise we are not pretty sure yeah that's why I think the buildis are not the same it's probably finding a same path that can be used by a new user do we need fixed paths for buildi with symbols anyway so that we can find the source again can't we just fix the problem at the same time and I think the user source Debbie and I saw on the build info file on the web browser looked just looked just right yeah yeah we have to use something like that because it would just allow me to up get source the stuff to that location and then GDP would just work I why? because the second source Debbie yeah but it's below the user here I don't know any other better proposal the only problem is that as a user it makes your life easier it's not difficult isn't user source at the moment special anyway we need to do right there right but we can guess yeah of course but any other location will have the same problem yeah of course TMP is not the right place to put it I think that's probably better because you really can have user read on your model then you don't need to go and use a local one expect something to be local no local bar source or bar build whatever but in one 10 more minutes so what's the difference between doing this and having it writeable for every user and slash TMP TMP is bad because the temp is as small and it smells but this should be writeable and you still have 5 writes it's about to create the path so this is writeable by every user and we don't have to discuss security issues because any location will have the same problems if you just need to decide on a location then you fix the problems separately before there was no security issue because the path was automatically generated and by using a fixed path you create a security issue with the user's research you can still append some randomness no you can't you can not because you want to reduce the path if you just need to have for locally reproducing I can do that yes but I think maybe we have to let an emergency system not multiple users can reproduce binary yes let's not spoil this by in the salt by mountain spaces that's right you can just mount your own stuff over there and build there directly on the user but last good for our users or tools would be to do lots of complicated things also what's one about mkdir and checking the owner does mkdir for us always no it's not the right thing I can't build it same time if it's a little bit busy we just let it go good point sorry you can't fix everything at once this is almost the same amount of work it's just fixing the toolchain so does this sound right can we go for it it still feels wrong because there is an actual problem that should be fixed but funding it because it's too far maybe for this path the point of this I don't think I don't think why my current proposal was fix whatever the sbuild or build has like used tmp build have this build path is the build info right now and one day someone will come from heaven and give us a post processing tool and then we can get rid of that if I trust you some problem because you have plenty of build systems that end up compiling from actually pass and then those pass get we can fix those most of them when I did like the test one year and a half ago I could fix the only one that could not fix was the often walk maybe I should not appear in the first time and the problem is that you want to post process the file and maybe it's more complicated but we need it you can always specify the source path gdb for example it's a convenience I don't think it's a requirement yes but you need it to be fixed they have to no I don't think it needs to be embedded I don't think I think it's convenient I mean if we can pass gcc all the better maybe I don't know it's just as for now I couldn't find it I don't know if it's easier or not maybe it's some way to I'm quite sure often Susan has a field check that complains if you have your field pool somewhere if you understand it at the end so it should be possible so I'd say maybe you should talk to the open source you're using debug edit to get to a canonical path good question I'm sure of that I'm dead deep in the pink service I'll tell you who can answer the question but I can't answer it myself so I've looked at it at least for Fedora and Appliances they use debug edit and then the compare script we'll just ignore this thing isn't it only from RPM itself so that's why it's fixed because RPM takes care of this by itself I mean we could use that I would get the same thing or we could pass GCC to not have this path information at once but I know it's going to be soft sound developers because they like it in the end it's the same problem if you use a user download the sources on your phone the path will match anyway people have had this problem if I'm developing my own software I do want GCC to just work yeah but you've made one pretty fast I mean I mean that's the idea solution if there's no path then there's no problem at all I shouldn't even have to care about I don't understand that so that's my ideal goal I would love to work on this and we agree on just like have a fixed path for build DMS build have the build path in the build info thing and then we try to get rid of it in the near future does that sound reasonable yes I really want to get rid of it but I do want people to move forward before having to get fixes in GCC there were some developers is it alright to have strict non-determinism as a build dependencies for I don't know 18,000 packages included in that handle I'd rather not because some other distributions might be interested in improving it make it a dependency have to depend on that I don't want to fix my package but it should be reusable I'm asking because this is what we have in the test repository right now how many how many packages does it add for stripping very few, it's already in a pearl it depends on a few pearl modules for the raw and architecture all depends on pearl itself and we both have sit pearl that's ok and then unless that puts in sit and anra and what not nice can you really be very careful about dependencies so I guess we are out of time for this round table first thing thank you for being here, great progress already and there's a couple issues but I'm pretty confident we'll get to the bottom before the end of that


The time is close. It's almost here. It's time for ghouls and ghost and fear as Jack-o-lanterns catch the eye. They match the moonlight in the sky Which is cackle wizards call spirits past right through the wall Coffins creak and crack then break as mummy zombies vampires wake Somewhere wolves howl to the moon which silhouettes a witch and broom with bats and cats the darkness shade and Skeletons all on parade where spiders crawl and monsters creep and in this night No one shall sleep they roam the streets for sweets to eat each home They laugh out trick or treat it's time where fearful sights are seen all black Purple orange and green these freaky creepy things all scream happy frightening Halloween


We hope that students between the age of 14 and 18 all around the world who think science is fun will submit smart ideas on how to explain nuclear technology and nuclear science to other young people or submit projects on how to make them more aware of the benefits of nuclear science and technology.