Am Freitag, dem 25.03.2022 um 14:13 -0700 schrieb Vagrant Cascadian:
> On 2022-03-25, Felix Zielcke wrote:
> > Am Mittwoch, dem 23.02.2022 um 09:36 +0100 schrieb Thomas Schmitt:
> > I totally forgot about this. Sorry!
> >
> > I just tried to test it with TZ set.
> > But I always get the same
Hi,
Felix Zielcke wrote:
> > I just tried to test it with TZ set.
> > But I always get the same binaries. No matter to what I change TZ or
> > /etc/timezone between the builds.
Vagrant Cascadian wrote:
> I can reproduce the issue in a debian sid chroot with pcmemtest 1.5-3
> from debian
I don't
On 2022-03-25, Felix Zielcke wrote:
> Am Mittwoch, dem 23.02.2022 um 09:36 +0100 schrieb Thomas Schmitt:
> I totally forgot about this. Sorry!
>
> I just tried to test it with TZ set.
> But I always get the same binaries. No matter to what I change TZ or
> /etc/timezone between the builds.
>
> So
Hi,
Chris Lamb wrote:
> More generally, I can't think of a scenario where the value of
> SOURCE_DATE_EPOCH request a timezone implication,
Alain Knaff mentioned mcopy option -m
"Preserve the file modification time."
which he wants to fulfill the user's expectation that the Y/M/D/h/m/s
Hi Thomas,
> i wrote to info-mtools about the problem that time zone influences the
> result of mcopy even if SOURCE_TIME_EPOCH is set.
> Alain Knaff then proposed to set the TZ variable to UTF when pcmemtest
> gets built.
> https://lists.gnu.org/archive/html/info-mtools/2022-02/msg2.html
>
Hi,
i wrote to info-mtools about the problem that time zone influences the
result of mcopy even if SOURCE_TIME_EPOCH is set.
Alain Knaff then proposed to set the TZ variable to UTF when pcmemtest
gets built.
https://lists.gnu.org/archive/html/info-mtools/2022-02/msg2.html
Would that be
Hi,
my favorite suspect in mtools is to see in function mk_entry():
https://sources.debian.org/src/mtools/4.0.33-1+really4.0.32-1/directory.c/?hl=98#L107
now = localtime();
(I see no debian/patches directory for mtools. So this is probably
really in effect with Debian's package.)
I
Hi,
Vagrant Cascadian wrote:
> I haven't looked into it too deeply, but got the basically the same
> results as currently showing on:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
Looks again like the FAT directory entries. The byte
On 2022-02-15, Thomas Schmitt wrote:
> Vagrant Cascadian wrote:
>> I noticed 1.5-3 is still affected by timezone differences,
>
> Can you already say whether the differences are in the range of
> partition 1 or in the range of partition 2 of the .iso (as told by
> fdisk -l) ?
I haven't looked
Hi,
Vagrant Cascadian wrote:
> I noticed 1.5-3 is still affected by timezone differences,
Can you already say whether the differences are in the range of
partition 1 or in the range of partition 2 of the .iso (as told by
fdisk -l) ?
> If I come up with an updated patch, I'll maybe submit a new
On 2022-02-12, Felix Zielcke wrote:
> Am Freitag, dem 11.02.2022 um 22:46 +0100 schrieb Thomas Schmitt:
>> Chris Lamb wrote:
>> > Did you try the --invariant flag?
>>
>> Well, i step aside and let this question reach Felix. :))
>>
>>
Control: tags -1 pending
Am Freitag, dem 11.02.2022 um 22:46 +0100 schrieb Thomas Schmitt:
> Hi,
>
> Chris Lamb wrote:
> > Did you try the --invariant flag?
>
> Well, i step aside and let this question reach Felix. :))
>
> https://manpages.debian.org/unstable/dosfstools/mkdosfs.8.en.html
>
Hi,
Chris Lamb wrote:
> Did you try the --invariant flag?
Well, i step aside and let this question reach Felix. :))
https://manpages.debian.org/unstable/dosfstools/mkdosfs.8.en.html
says that this is what we need if my theory about the second difference
is correct:
--invariant
Use
[merging two replies]
Hi Thomas,
> I wonder whether the "file list" in "data.tar.xz" of
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
> is made from the files in the ISO or from the input files on hard disk.
That can safely be ignored for
Hi,
First an observation from digging in pcmemtest/1.5-2/build64/Makefile:
What about target grub-memtest.iso ?
It has its own xorriso run and EFI System Partition image.
I guess they need treatment for reproducibility, too.
Felix Zielcke wrote:
> Here's the output for the 64bit ISO:
> [...]
>
Am Freitag, dem 11.02.2022 um 11:41 +0100 schrieb Thomas Schmitt:
> Hi,
>
> Felix Zielcke wrote:
> > I modifed the patch now to use --set_all_file_dates.
>
> I wonder whether the "file list" in "data.tar.xz" of
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffosc
>
Hi,
Felix Zielcke wrote:
> I modifed the patch now to use --set_all_file_dates.
I wonder whether the "file list" in "data.tar.xz" of
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffosc
ope-results/pcmemtest.html
is made from the files in the ISO or from the input files
Am Donnerstag, dem 10.02.2022 um 16:24 -0800 schrieb Chris Lamb:
> Hi Thomas,
>
> > > Have you had a look at the diffoscope output after this patch is
> > > applied?
> >
> > Where can a curious bystander get that look ?
>
> I was referring to a hypothetical diff that you might generate
>
Hi Thomas,
>> Have you had a look at the diffoscope output after this patch is
>> applied?
>
> Where can a curious bystander get that look ?
I was referring to a hypothetical diff that you might generate
locally; updating the result on tests.reproducible-builds.org would
require a new upload. :)
Hi,
Chris Lamb wrote:
> Have you had a look at the diffoscope output after this
> patch is applied?
Where can a curious bystander get that look ?
I only found a diff from february 8:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pcmemtest.html
where i
Hi Felix,
> thanks for your patch. Just committed it.
> Do you or anyone else have a hint how to make the ISOs fully
> reproducible? How to do this is totally new to me.
Good question. Have you had a look at the diffoscope output after this
patch is applied? From memory, it looked like some kind
Am Dienstag, dem 08.02.2022 um 12:06 -0800 schrieb Chris Lamb:
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> pcmemtest could not be built reproducibly.
>
> This is because the generated ISOs inherit the uid/gid of the build
> process, as well as the
Source: pcmemtest
Version: 1.5-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
pcmemtest could not be built
23 matches
Mail list logo
