Hi Maxime, I am confused by your replies in the thread. Maybe, I miss the topic of the comment by Ludo.
Well, from my understanding, the question is: should a perfectly working and fine submission be delayed because unrelated-to-Guix issues are in upstream code? Ludo said these unrelated-to-Guix issues are not blocker, from my understandings. And I agree. Do you disagree? Reading you, I am missing what you are suggesting. You are commenting on “standard” which somehow asks about explicit criteria. And, you are implicitly commenting on blocking while issues from upstream are not fixed. Instead of trying to deduce myself (and probably the wrong way), could you please explicitly write down your arguments? Do you think that patch#55541 should be delayed while upstream is not supported by cross-compilation? I agree that fixing as much as possible and earlier is the best. However, there is a tension between being perfect and doing with the resources at hand. For sure, it would be better if submitter also report (or fix) upstream some issues, but I am not convinced the Guix project should make this as mandatory requirements for inclusion of submitted packages in Guix. Do you think that patch#55541 should be delayed while submitter has not open an upstream issue? Last, I miss these comments about old bugs and what you are implicitly suggesting with them. Are you suggesting that old unsolved bugs are closed without valid motivation? >> Old unsolved bugs are still open > > Sometimes they aren't: > * https://issues.guix.gnu.org/45828 Closed because: This can happen if guix-daemon was restarted but ‘guix publish’ wasn’t: ‘guix publish’ opens only one connection to the store at startup time, and then never tries to re-open it. There was an old bug on this topic: https://issues.guix.gnu.org/26705 Back then I marked it as ‘wontfix’ because: 1. Losing a connection to the daemon Does Not Happen™ in normal conditions. Namely, upon ‘herd restart guix-daemon’, ‘guix publish’ is automatically restarted. One situation where ‘guix publish’ is not restarted is if one does “killall guix-daemon” or similar. (Perhaps that’s something to fix in the Shepherd?) > * https://issues.guix.gnu.org/26705 Closed because: For now I’m closing this bug as “wontfix” because I’ve never seen any occurrence of #2, and because #1 cannot happen on GuixSD (if ‘guix-daemon’ is restarted, the shepherd will also restart ‘guix-publish’. > * https://issues.guix.gnu.org/25719 (exception handling hasn't been cleaned > up before closing) Closed because: I haven't seen this particular exception in a long time. I cannot tell whether the actual usability has been fixed, though--it could be that only the servers are more reliable and this code path is thus not currently being entered. > * https://issues.guix.gnu.org/44199 (it's a WIP, not completed yet, but still > closed!) This history is: Maxime Devos wrote on 24 Oct 2020 21:47 zimoun wrote on 27 Oct 2020 14:39 Maxime Devos wrote on 27 Oct 2020 19:50 Maxime Devos wrote on 1 Nov 2020 01:05 Ludovic Courtès wrote on 15 Nov 2020 22:13 > This patch defines a `gnunet-fetch' method, allowing for downloading > files from GNUnet by their GNUnet chk-URI. While I think this is a laudable goal, I’m reluctant to including GNUnet support just yet because, as stated in recent release announcements, GNUnet is still in flux and not considered “production ready”. So I think we should keep it around and revisit this issue when GNUnet is considered “stable”. WDYT? zimoun wrote on 16 Nov 2020 01:35 Maxime Devos wrote on 18 Nov 2020 20:14 > So I think we should keep it around and revisit this issue when > GNUnet > is considered “stable”. WDYT? Sounds reasonable to me. There are also a lot of missing parts: a service definition for Guix System, findings substitutes, finding sources by hash (the one Guix uses, not the GNUnet hash) ..., so it isn't like my rudimentary patch was usable on large scale anyway. Ludovic Courtès wrote on 18 Nov 2020 23:12 tags 44199 wontfix close 44199 quit Therefore, if you have more details for one of these reports, feel free to comment, provide more info or fix; for sure it will help. Cheers, simon