ELPA git repo contains zero-padded file modes and running ~$ make fails

ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

I have this error when git-pulling the elpa repository:

  guerry git/elpa ‹master› » git pull
  remote: Counting objects: 64150, done.
  remote: Compressing objects: 100% (22564/22564), done.
  error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c: zeroPaddedFilemode: contains zero-padded file modes
  fatal: erreur de fsck dans l'objet empaqueté
  fatal: échec de index-pack

I was able to git clone again with:

~$ git clone --depth=1 myusername@git.sv.gnu.org:/srv/git/emacs/elpa.git

but it seems I don't get the full commit history then.

Also, running ~$ make in the cloned repo fails with this error:

  In toplevel form:
  packages/ebdb-gnorb/ebdb-gnorb.el:30:1: Error: Cannot open load file: Aucun fichier ou dossier de ce type, ebdb-format
  make: *** [GNUmakefile:173: packages/ebdb-gnorb/ebdb-gnorb.elc] Error 1

I'm not sure what to do with both these errors, thanks for any hint.

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

Bastien <bzg@gnu.org> writes:

> I was able to git clone again with:
>
> ~$ git clone --depth=1 myusername@git.sv.gnu.org:/srv/git/emacs/elpa.git

FWIW, also this is okay:

~$ git clone --config transfer.fsckobjects=false \
             --config receive.fsckobjects=false \
             --config fetch.fsckobjects=false \
             myusername@git.sv.gnu.org:/srv/git/emacs/elpa.git

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

> I have this error when git-pulling the elpa repository:
>
>   guerry git/elpa ‹master› » git pull
>   remote: Counting objects: 64150, done.
>   remote: Compressing objects: 100% (22564/22564), done.
>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
> zeroPaddedFilemode: contains zero-padded file modes
>   fatal: erreur de fsck dans l'objet empaqueté
>   fatal: échec de index-pack

Known problem: just disable fsck for the initial fetch.

> Also, running ~$ make in the cloned repo fails with this error:
>
>   In toplevel form:
>   packages/ebdb-gnorb/ebdb-gnorb.el:30:1: Error: Cannot open load file:
> Aucun fichier ou dossier de ce type, ebdb-format
>   make: *** [GNUmakefile:173: packages/ebdb-gnorb/ebdb-gnorb.elc] Error 1
>
> I'm not sure what to do with both these errors, thanks for any hint.

Don't know about that one, better ask the author/maintainer of
ebdb-gnorb.


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I have this error when git-pulling the elpa repository:
>>
>>   guerry git/elpa ‹master› » git pull
>>   remote: Counting objects: 64150, done.
>>   remote: Compressing objects: 100% (22564/22564), done.
>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>> zeroPaddedFilemode: contains zero-padded file modes
>>   fatal: erreur de fsck dans l'objet empaqueté
>>   fatal: échec de index-pack
>
> Known problem: just disable fsck for the initial fetch.
>
>> Also, running ~$ make in the cloned repo fails with this error:
>>
>>   In toplevel form:
>>   packages/ebdb-gnorb/ebdb-gnorb.el:30:1: Error: Cannot open load file:
>> Aucun fichier ou dossier de ce type, ebdb-format
>>   make: *** [GNUmakefile:173: packages/ebdb-gnorb/ebdb-gnorb.elc] Error 1
>>
>> I'm not sure what to do with both these errors, thanks for any hint.
>
> Don't know about that one, better ask the author/maintainer of
> ebdb-gnorb.

I'm hoping this was just a knock-on error from the first error. If you
pull the elpa repository cleanly and still get this error, please let me
know. TBH this package probably doesn't need to exist, it's a holdover
from back when I didn't know how to do between-package packages.

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

Hi Stefan and Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I have this error when git-pulling the elpa repository:
>>>
>>>   guerry git/elpa ‹master› » git pull
>>>   remote: Counting objects: 64150, done.
>>>   remote: Compressing objects: 100% (22564/22564), done.
>>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>>> zeroPaddedFilemode: contains zero-padded file modes
>>>   fatal: erreur de fsck dans l'objet empaqueté
>>>   fatal: échec de index-pack
>>
>> Known problem: just disable fsck for the initial fetch.

Thanks.  Is there any way to fix it? 

The problem is not mentioned in those links:

https://www.emacswiki.org/emacs/EmacsFromGit#toc2
https://savannah.gnu.org/git/?group=emacs

I would not be surprised if people cannot find the solution. 
Or maybe not that many people git clone elpa after all.

> I'm hoping this was just a knock-on error from the first error. 

I tried again to clone with fsck completely disabled then running 
make still raises the same error:

In toplevel form:
packages/ebdb-gnorb/ebdb-gnorb.el:30:1: Error: Cannot open load file: Aucun fichier ou dossier de ce type, ebdb-format
make: *** [GNUmakefile:173: packages/ebdb-gnorb/ebdb-gnorb.elc] Error 

Isn't it the case on your side?

> If you pull the elpa repository cleanly and still get this error,
> please let me know. TBH this package probably doesn't need to exist,
> it's a holdover from back when I didn't know how to do
> between-package packages.

Maybe it can simply be removed, then?

Thanks,

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

>>> Known problem: just disable fsck for the initial fetch.
> Thanks.  Is there any way to fix it?

Not without rewriting history.  Git used to sometimes generate these
zero-padded file modes.  It's now more careful, but those old commits
are still with us.

> The problem is not mentioned in those links:
>
> https://www.emacswiki.org/emacs/EmacsFromGit#toc2
> https://savannah.gnu.org/git/?group=emacs
>
> I would not be surprised if people cannot find the solution. 
> Or maybe not that many people git clone elpa after all.
>
>> I'm hoping this was just a knock-on error from the first error. 
>
> I tried again to clone with fsck completely disabled then running 
> make still raises the same error:
>
> In toplevel form:
> packages/ebdb-gnorb/ebdb-gnorb.el:30:1: Error: Cannot open load file: Aucun
> fichier ou dossier de ce type, ebdb-format
> make: *** [GNUmakefile:173: packages/ebdb-gnorb/ebdb-gnorb.elc] Error 

Any chance you haven't done `make externals` beforehand?

`ebdb` is an "external" package (i.e. it's kept in its own branch), and
`ebdb-gnorb` depends on `ebdb`, so if you don't `make externals` it's
normal that `ebdb-gnorb` fails to compile.

>> If you pull the elpa repository cleanly and still get this error,
>> please let me know. TBH this package probably doesn't need to exist,
>> it's a holdover from back when I didn't know how to do
>> between-package packages.
> Maybe it can simply be removed, then?

Or turned into an "external" as well.


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Known problem: just disable fsck for the initial fetch.
>> Thanks.  Is there any way to fix it?

[...]

> Any chance you haven't done `make externals` beforehand?
>
> `ebdb` is an "external" package (i.e. it's kept in its own branch), and
> `ebdb-gnorb` depends on `ebdb`, so if you don't `make externals` it's
> normal that `ebdb-gnorb` fails to compile.
>
>>> If you pull the elpa repository cleanly and still get this error,
>>> please let me know. TBH this package probably doesn't need to exist,
>>> it's a holdover from back when I didn't know how to do
>>> between-package packages.
>> Maybe it can simply be removed, then?
>
> Or turned into an "external" as well.

I'll do one or the other soon, but I'd be curious to know if Bastien
hasn't done `make externals`, and if that fixes the problem for sure.
Just FMI.

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'll do one or the other soon, but I'd be curious to know if Bastien
> hasn't done `make externals`, and if that fixes the problem for sure.

Yes, with ~$ make externals the problem with ebdb is gone. Thanks!

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Eric Abrahamsen]

Bastien <bzg@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'll do one or the other soon, but I'd be curious to know if Bastien
>> hasn't done `make externals`, and if that fixes the problem for sure.
>
> Yes, with ~$ make externals the problem with ebdb is gone. Thanks!

Cool! I'm still going to re-absorb this package into Gnorb, I think.

Thanks,
Eric

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

Hi Stefan,

thanks for answering.

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Known problem: just disable fsck for the initial fetch.
>> Thanks.  Is there any way to fix it?
>
> Not without rewriting history.  Git used to sometimes generate these
> zero-padded file modes.  It's now more careful, but those old commits
> are still with us.

:/

> Any chance you haven't done `make externals` beforehand?

Yes, I didn't do that... how could I know?  The instruction is burried
within a quite beefy README.  

I did ~$ make externals and things went fine.

Then ~$ make produced this:

  In dismal-send-cmd-to-shell:
  packages/dismal/dismal.el:4519:17:Warning: variable reference to nonvariable
      ‘(make-local-variable 'dismal-gnuplot-finish)’
  packages/dismal/dismal.el:4519:17:Error: Wrong type argument: symbolp, (make-local-variable 'dismal-gnuplot-finish)
  make: *** [GNUmakefile:173: packages/dismal/dismal.elc] Error 

I don't really need to compile things in ELPA for now, I was just
going down the rabbit hole after the first zero-padded error.

HTH,

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

> Then ~$ make produced this:
>
>   In dismal-send-cmd-to-shell:
>   packages/dismal/dismal.el:4519:17:Warning: variable reference to nonvariable
>       ‘(make-local-variable 'dismal-gnuplot-finish)’
>   packages/dismal/dismal.el:4519:17:Error: Wrong type argument: symbolp, (make-local-variable 'dismal-gnuplot-finish)
>   make: *** [GNUmakefile:173: packages/dismal/dismal.elc] Error 

[ Sorry&Thanks: I just pushed a fix for this.  ]

Hmm... I've had the `elpa.git` checked out for years, and do `make` in
it regularly, yet this plain error got through.
Obviously my `make` only recompiles the changed files, but still,
I wonder how I managed to have a `dismal.elc` more recent than `dismal.el`
given the obvious error from which it suffered.


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[T.V Raman]

The other thing this points out: how do we catch and prevent bit-rot in
elpa?

Dismal used to be one of my favorite tools but I've abandoned it long
since because it has not seen any updates in a long, long time.
-- 

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ Sorry&Thanks: I just pushed a fix for this.  ]

Thanks!  I was able to git pull, make externals and make fine.

-- 
 Bastien

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Tim Landscheidt]

Bastien <bzg@gnu.org> wrote:

>>>> I have this error when git-pulling the elpa repository:

>>>>   guerry git/elpa ‹master› » git pull
>>>>   remote: Counting objects: 64150, done.
>>>>   remote: Compressing objects: 100% (22564/22564), done.
>>>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>>>> zeroPaddedFilemode: contains zero-padded file modes
>>>>   fatal: erreur de fsck dans l'objet empaqueté
>>>>   fatal: échec de index-pack

>>> Known problem: just disable fsck for the initial fetch.

> Thanks.  Is there any way to fix it?

> The problem is not mentioned in those links:

> https://www.emacswiki.org/emacs/EmacsFromGit#toc2
> https://savannah.gnu.org/git/?group=emacs

> I would not be surprised if people cannot find the solution.
> Or maybe not that many people git clone elpa after all.

> […]

Unfortunately, Bastien's note was never followed up on.
Therefore I'd like to propose to replace the calls to:

| git clone

on https://savannah.gnu.org/projects/emacs (ELPA part) and
in ELPA's README with calls to:

| git -c fetch.fsck.zeroPaddedFilemode=ignore clone

preferably with an explanation that this option is necessary
for the initial clone due to an error in the ELPA repository
that cannot be fixed.

TIA,
Tim

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

[ Hi Omar, adding you to the discussion, see below why.  ]

>>>>> I have this error when git-pulling the elpa repository:
>
>>>>>   guerry git/elpa ‹master› » git pull
>>>>>   remote: Counting objects: 64150, done.
>>>>>   remote: Compressing objects: 100% (22564/22564), done.
>>>>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>>>>> zeroPaddedFilemode: contains zero-padded file modes
>>>>>   fatal: erreur de fsck dans l'objet empaqueté
>>>>>   fatal: échec de index-pack

Hmm... I thought I had fixed that.

I just tested it and I get something yet different from the expected:

    % git -c fetch.fsck.zeroPaddedFilemode=error clone git://git.sv.gnu.org/emacs/elpa
    Clonage dans 'elpa'...
    remote: Counting objects: 555187, done.
    remote: Compressing objects: 100% (165071/165071), done.
    erreur : object b7550f84d72a158e20aa425ea2a8f24b9ee9bac0: badDateOverflow: invalid author/committer line - date causes integer overflow
    fatal : erreur de fsck dans l'objet empaqueté
    fatal : fetch-pack : sortie d'index de pack invalide

[ Pardon my French 🙂 ]

Looking at the offending data:

    % git show b7550f84d72a158e20aa425ea2a8f24b9ee9bac0)
    commit b7550f84d72a158e20aa425ea2a8f24b9ee9bac0
    Author: Omar Antolín Camarena <omar.antolin@gmail.com>
    Date:   Thu Jan 1 00:00:00 1970 +0000
    
        When deciding if a candidate is selected compare original targets

And indeed:

    % git -c fetch.fsck.zeroPaddedFilemode=warn -c fetch.fsck.badDateOverflow=warn clone https://github.com/oantolin/embark
    Clonage dans 'embark'...
    remote: Enumerating objects: 5164, done.
    remote: Counting objects: 100% (830/830), done.
    remote: Compressing objects: 100% (314/314), done.
    avertissement : object b7550f84d72a158e20aa425ea2a8f24b9ee9bac0: badDateOverflow: invalid author/committer line - date causes integer overflow
    avertissement : object b7550f84d72a158e20aa425ea2a8f24b9ee9bac0: badDateOverflow: invalid author/committer line - date causes integer overflow
    avertissement : object 2b2e62af001312a9b97724855855dfec51b5bec6: badDateOverflow: invalid author/committer line - date causes integer overflow
    avertissement : object 2b2e62af001312a9b97724855855dfec51b5bec6: badDateOverflow: invalid author/committer line - date causes integer overflow
    remote: Total 5164 (delta 552), reused 790 (delta 516), pack-reused 4334
    Réception d'objets: 100% (5164/5164), 1.60 Mio | 2.83 Mio/s, fait.
    Résolution des deltas: 100% (3346/3346), fait.

Strangely I don't get this error when I use a different machine, so
maybe it depends if it's a 32bit/64bit build or version of Git or
something, but even on that other machine `git fsck` complains about
those bad dates.

I see that it's a fairly recent commit on embark (contrary to the
previous error quoted above which was about some old commit in
coffee-mode) so it might be easier to fix.

Omar, any chance you could fix these with a rebase.
[ Yes, I hate rebases for public branches and it's going to be a bit of
  a PITA to fix the clones we have on elpa.gnu.org (but the clones of
  those clones I have on various other machines 🙁) which track those
  branches, but it's arguably better in the long term.  ]


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

>>>>>> I have this error when git-pulling the elpa repository:
>>
>>>>>>   guerry git/elpa ‹master› » git pull
>>>>>>   remote: Counting objects: 64150, done.
>>>>>>   remote: Compressing objects: 100% (22564/22564), done.
>>>>>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>>>>>> zeroPaddedFilemode: contains zero-padded file modes
>>>>>>   fatal: erreur de fsck dans l'objet empaqueté
>>>>>>   fatal: échec de index-pack
>
> Hmm... I thought I had fixed that.

Actually, I had fixed that specific error over on `nongnu.git` (the error
is a bad commit in `coffee-mode`).
But indeed, `coffee-mode` used to live in `elpa.git` and there were
left-over references to it so that error was still present on `elpa.git`.
I believe I have fixed it now.

[ The badDateOverflow problem on Embark is still with us, OTOH.  ]


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>>>> I have this error when git-pulling the elpa repository:
>>>
>>>>>>>   guerry git/elpa ‹master› » git pull
>>>>>>>   remote: Counting objects: 64150, done.
>>>>>>>   remote: Compressing objects: 100% (22564/22564), done.
>>>>>>>   error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c:
>>>>>>> zeroPaddedFilemode: contains zero-padded file modes
>>>>>>>   fatal: erreur de fsck dans l'objet empaqueté
>>>>>>>   fatal: échec de index-pack
>>
>> Hmm... I thought I had fixed that.
>
> Actually, I had fixed that specific error over on `nongnu.git` (the error
> is a bad commit in `coffee-mode`).
> But indeed, `coffee-mode` used to live in `elpa.git` and there were
> left-over references to it so that error was still present on `elpa.git`.
> I believe I have fixed it now.
>
> [ The badDateOverflow problem on Embark is still with us, OTOH.  ]

As long as we keep them all in the repository, it's very likely that
we'll end up with bad commits in either GNU ELPA or NonGNU ELPA.

Is there something we could add to our scripts to avoid this from
happening in the future?  I'm thinking of adding a `git fsck` to our
scripts before pushing a branch to Savannah, or something.  Not sure
what's needed.

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

> As long as we keep them all in the repository, it's very likely that
> we'll end up with bad commits in either GNU ELPA or NonGNU ELPA.

Then again, it should only bite when doing a clone of the whole
repositor(y|ies), which corresponds to making a clone of each and every
package and that would suffer the same fate if they were kept in
separate branches.

IOW, the main difference is that it's easier to accidentally clone the
whole repository rather than just the few packages you're after.

> Is there something we could add to our scripts to avoid this from
> happening in the future?  I'm thinking of adding a `git fsck` to our
> scripts before pushing a branch to Savannah, or something.  Not sure
> what's needed.

We already have:

    [transfer]
            fsckObjects = true

in the `.gitconfig` of the thingy doing the mirroring of
upstream branches.  But apparently it didn't catch those badDateOverflow
issues (apparently they're not checked in a systematic fashion?).


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

> Then again, it should only bite when doing a clone of the whole
> repositor(y|ies), which corresponds to making a clone of each and every
> package and that would suffer the same fate if they were kept in
> separate branches.
           ^^^^^^^^
           repositories
<sigh>


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Tim Landscheidt]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> […]

>> Is there something we could add to our scripts to avoid this from
>> happening in the future?  I'm thinking of adding a `git fsck` to our
>> scripts before pushing a branch to Savannah, or something.  Not sure
>> what's needed.

> We already have:

>     [transfer]
>             fsckObjects = true

> in the `.gitconfig` of the thingy doing the mirroring of
> upstream branches.  But apparently it didn't catch those badDateOverflow
> issues (apparently they're not checked in a systematic fashion?).

But this configuration does not apply to the Git "server"
accepting pushes to ELPA branches where the error that
started this thread occurred, does it?

To accomplish this, I assume something in the Savannah-
sphere needs to be changed.  (Though I don't understand why
receive.fsckObjects=true is not the Git default.)

Tim

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

>> We already have:
>
>>     [transfer]
>>             fsckObjects = true
>
>> in the `.gitconfig` of the thingy doing the mirroring of
>> upstream branches.  But apparently it didn't catch those badDateOverflow
>> issues (apparently they're not checked in a systematic fashion?).
>
> But this configuration does not apply to the Git "server"
> accepting pushes to ELPA branches where the error that
> started this thread occurred, does it?

There are very few packages where anyone pushes to `elpa.git` (and
currently none in `nongnu.git`), so it's not a major issue.
[ And indeed the two packages where problems have appeared so far
  (`coffee-mode` and `embark` are pulled by that mirroring thingy).  ]

> To accomplish this, I assume something in the Savannah-
> sphere needs to be changed.  (Though I don't understand why
> receive.fsckObjects=true is not the Git default.)

It's considered too costly.


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

> There are very few packages where anyone pushes to `elpa.git` (and
> currently none in `nongnu.git`), so it's not a major issue.
> [ And indeed the two packages where problems have appeared so far
>   (`coffee-mode` and `embark` are pulled by that mirroring thingy).  ]
                               ↑                                   ↓
                               ╰-----------------------------------╯

- Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Emanuel Berg]

Stefan Monnier wrote:

>> There are very few packages where anyone pushes to `elpa.git` (and
>> currently none in `nongnu.git`), so it's not a major issue.
>> [ And indeed the two packages where problems have appeared so far
>>   (`coffee-mode` and `embark` are pulled by that mirroring thingy).  ]
>                               ↑                                   ↓
>                               ╰-----------------------------------╯

Pretty :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Omar Antolín Camarena]

Hi Stefan!

I'd be very happy to fix the problem with Embark, of course! But as you know, I'm not very knowledgeable about git. I know neither what I did wrong nor how to fix. (I can promise you I did not time travel to 1970 to make a commit.) Was the clock on my laptop just wrong when I pushed that commit? More importantly, how do I fix this?

-- 
Omar

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Daniel Mendler via Emacs development discussions.]

Omar Antolín Camarena <omar.antolin@gmail.com> writes:

> I'd be very happy to fix the problem with Embark, of course! But as you know,
> I'm not very knowledgeable about git. I know neither what I did wrong nor how to
> fix. (I can promise you I did not time travel to 1970 to make a commit.) Was the
> clock on my laptop just wrong when I pushed that commit? More importantly, how
> do I fix this?

If I recall correctly it is not the first time that you traveled in time
to create an Embark commit. For example you will create commit
2b2e62af001312a9b97724855855dfec51b5bec6 on Oct 13, 2065.

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Omar Antolín Camarena]

> For example you will create commit 2b2e62af001312a9b97724855855dfec51b5bec6 on Oct 13, 2065.

Correct. I have no idea how that happened either! And I don't know how to keep from happening again. Maybe I'm more prone to the issue because I commit from WSL on Windows and from a VM or Chroot on ChromeOS: I usually have the "outer" Windows or ChromeOS clock visible, but I usually have no idea what time the "inner" Linux environment thinks it is. But still: 1970, 2065? How did that happen and why does it only happen occasionally? But prevention of further instances is not as important as fixing the current problem:

Stefan Monnier mentioned rebasing but I'm unclear on what I am supposed to rebase on what (and I'm also unclear on how that would help: wouldn't the weird commit still be present?). I'll gladly do whatever is necessary to fix the embark repository now, I just don't understand what exactly Stefan proposes I do.

-- 
Omar

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

Hola Omar,

Omar Antolín Camarena [2024-02-01 17:52:15] wrote:
>> For example you will create commit
>> 2b2e62af001312a9b97724855855dfec51b5bec6 on Oct 13, 2065.

Oh, wow, even better!
The 1970 timestamp is kinda boring, but 2065 seems downright creative.
I wonder how it got there!

> Correct. I have no idea how that happened either! And I don't know how to
> keep from happening again. Maybe I'm more prone to the issue because
> I commit from WSL on Windows and from a VM or Chroot on ChromeOS: I usually
> have the "outer" Windows or ChromeOS clock visible, but I usually have no
> idea what time the "inner" Linux environment thinks it is.

No idea how WSL works, sorry, but for ChromeOS, if it's a chroot or
container then it should use the exact same clock as the host, AFAIK.

> But still: 1970, 2065?  How did that happen and why does it only happen
> occasionally?  But prevention of further instances is not as important
> as fixing the current problem:

Actually, fixing the old ones is not that useful if new ones will appear
shortly again.  So it might be worth trying to see if you can reproduce
the problem somehow.

You might want to open a bug report with Git, actually: whatever wrong
time you machine may have, Git shouldn't generate a commit with date
which it will later label as "badDateOverflow".
[ I assume here that you created those commits with the "official" Git
  client.  AFAIK there are several (re)implementations of (part of) Git out
  there, of varying quality.  ]

> Stefan Monnier mentioned rebasing but I'm unclear on what I am supposed to
> rebase on what (and I'm also unclear on how that would help: wouldn't the
> weird commit still be present?). I'll gladly do whatever is necessary to fix
> the embark repository now, I just don't understand what exactly Stefan
> proposes I do.

By rebasing I mean reconstruct an almost identical history, except that
the offending commits are reconstructed with a "better" date.
This normally result in a whole new set of commits IDs (even though the
commits look eerily like the old ones).  It's quite nasty because any
other branches out there will "lose" their connection/relationship to
your branch (because they don't know those new commits and how those
new commits relate to the old ones), so merges and updates get all
screwed up.

It's not urgent (since apparently Git doesn't always complain about it),
but if nobody else beats me to it, I'll try and create such a "fixed"
history when I find the time.


        Stefan

Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[chad]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

IFF you feel like peeking behind the curtain...

On Thu, Feb 1, 2024 at 2:36 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>
>     erreur : object b7550f84d72a158e20aa425ea2a8f24b9ee9bac0:
> badDateOverflow: invalid author/committer line - date causes integer
> overflow
> [...]
>
>     % git show b7550f84d72a158e20aa425ea2a8f24b9ee9bac0)
>     commit b7550f84d72a158e20aa425ea2a8f24b9ee9bac0
>     Author: Omar Antolín Camarena <omar.antolin@gmail.com>
>     Date:   Thu Jan 1 00:00:00 1970 +0000
>
>         When deciding if a candidate is selected compare original targets
>

These files are actually pretty simple, stored in .git/objects/<commit-ID>,
very close to how it's printed by git show. There should be lines starting
with Author or Committer, followed by the name & email, then a unix
timestamp. Presumably, those unix timestamps are, to use a technical term,
"wack".

I don't know git well enough to know how dangerous it would be to fix up
that file on Savannah, but it might help debug, at least.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1577 bytes --]