plugwash: > package: dh-cargo > > Recently a substantial number of upstream cargo packages started using > timestamps the ftpmasters > consider reject-worthy, I believe this was done in the name of > reproducibility. >
On what basis are you forming your belief? Because I worked on reproducibility for a couple of years (and was advising the rustc guys about it), and this method is not suitable for that purpose. >From what I gather during previous discussions, some overzealous FTP person >ages ago decided to add this over-reaching check, to reject other bad-quality >packages, without thinking about the long-term consequences of it. Now we must >all suffer the consequences. The correct fix is to undo this injustice, not to leech volunteers' time with this sort of bullshit. Covid has killed several million people in the past couple years due to government incompetence and inaction, I don't want to care about fucking timestamps, ESPECIALLY when it has nothing to do with reproducibility. > After it became clear that this was a larger-scale issue and we got sick of > working around this in individual packages, sylvestre implemented a > workaround in dh_cargo. Unfortunately this fix does not seem to be complete. > > Specifically it seems that when an upstream changelog is installed by > dh_installchangelogs to /usr/share/doc it doesn't get the timestamp fixing > treatment. Presumablly because dh_installchangelogs pulls it from the source > tree while the dh_cargo timestamp fixing happens on the output tree. > > I've worked around it for now in crossbeam-deque, but I don't know how many > other packages are > potentially effected (e.g. have changelogs with dodgy timestamps in their > upstream packaging) and whether this is something we need to deal with > centrally. > -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
