61–70 of 72 posts
Earlier quoted context omitted.
A moderator edited the URL from a page that says "NO" which links to this.
I'm aware of that. I was asking why that change was made.
Please submit the original source. If a post reports on something found on another site, submit the latter.
Earlier quoted context omitted.
Indeed, which is a completely different "view" on things...
A moderator edited the URL from a page that says "NO" which links to this.
Mods, how come my post was completely edited? :)
If we can find a more substantive page to link to on the same topic, we'll sometimes change the URL. Usually we post a comment explaining that we did so, but it depends who's on duty at the time.
I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com [2] https://buckaroo.pm
Is there any known problems / pitfalls regarding cmake and reproducible builds? Just curious to know.
This is a big problem if you want reproducible builds with varying build directory.
https://lists.alioth.debian.org/pipermail/reproducible-build...
Mods, how come my post was completely edited? :)
The is-foo-bar-yet.com -> NO/YES trope has been off topic on HN for years, mainly because such pages are unsubstantive but also because it's long been a cliché. If we can find a more substantive page to link to on the same topic, we'll sometimes change the URL. Usually we post a comment explaining that we did so, but it depends who's on duty at the time.
disorderfs is nice for ferreting out readdir()-ordering effects.
I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com [2] https://buckaroo.pm
Well, this is Debian - they generally don't maintain the software, they just package it. Small changes can be pushed upstream, but "Here's a brand new build system that we promise is super cool" is generally not a patch that people like taking :)
They definitely maintain software. There is a whole pile of packages that aren't maintained upstream any more that are still maintained in Debian, they write things like manual pages for commands that don't have then, they bash the build scripts into something that works on a whole pile of architectures the author never considers, they manage what is probably the worlds biggest issue track system, and then there is the security team producing patches for versions upstream no longer supports.
But probably it's just your wording. While they do maintain software, they are mostly concerned with packaging existing software, not writing new stuff.
Earlier quoted context omitted.
Well, this is Debian - they generally don't maintain the software, they just package it. Small changes can be pushed upstream, but "Here's a brand new build system that we promise is super cool" is generally not a patch that people like taking :)
> Well, this is Debian - they generally don't maintain the software They definitely maintain software. There is a whole pile of packages that aren't maintained upstream any more that are still maintained in Debian, they write things like manual pages for commands that don't have then, they bash the build scripts into something that works on a whole pile of architectures the author never considers, they manage what is…
(One of the packages I maintain in Debian is apparently dead upstream as of the last year or so, but even so I'm not very interested in becoming the new upstream and adopting big changes like a new build system.)
Earlier quoted context omitted.
Often, package is built using a certain library version (from a different package), that library is then updated - and the new package cannot build using the new library. Or... deeper parts of the compiler toolchain change, and the application doesn't re-build without changes.
That has nothing to do with reproducible builds - the issue being solved by reproducible builds is that even in exactly the same environment, running the same build script twice can result in differences in the output.