home  bbs  files  messages ]

      ZZLI4422             linux.debian.devel             1179 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  Msg # 246 of 1179 on ZZLI4422, Saturday 10-03-25, 1:16  
  From: VINCENT DANJEAN  
  To: ALL  
  Subj: Re: Cleaning salsa build cache before a   
 From: vdanjean.ml@free.fr 
  
 Le 02/10/2025 €€ 05:51, Otto Kek€€l€€inen a €€crit€€: 
 >>> I will try to send you a MR with these fixed later in the week if I have 
 time. 
 > 
 > I sent these now in 
 > https://salsa.debian.org/debian/taktuk/-/merge_requests/3 and 
 > https://salsa.debian.org/debian/taktuk/-/merge_requests/4 but really 
 > the repository should also be renamed to use DEP-14 branch names to 
 > not conflict with upstream, and the rename can't be done as a MR. 
 > Would you like me to fix the repository branches and settings for you? 
  
 Not now, thanks. I've several scripts to change on my side 
 when I will rename the branches. And then, I will do it for all my repos 
 at once. 
  
 >> I found my problem: after fixing my initial mistake, I force-push all 
 branches. 
 >> But I forgot to force-push tags. And upstream/3.7.8 was pointing to the 
 previous (wrong) state. 
 > 
 > Again, if you have debian/gbp.conf correctly and do all imports with 
 > `gbp import-orig --uscan`, all the branches and tags will 
 > automatically be correct and there is no need for manually fiddling 
 > with them as you described in your email. 
  
 Thanks, you help pointing to debian/gbp.conf. This is what explain 
 the different behavior on salsa CI and locally: I have a $HOME/.gbp.conf 
 with "pristine-tar = True". When I remove it, "gbp export-orig" 
 also use the tag locally. 
    I will quickly push a debian/gbp.conf in all my packages (and, at 
 this point, I will probably also make the DEP-14 branch rename). 
  
    However, I said before, I've always used `gbp import-orig --uscan` to 
 import a new upstream version. The $HOME/.gbp.conf makes it be possible. 
 My initial mistake comes from the fact that `gbp import-orig --uscan` 
 does *not* re-download the tarball if one is already present. 
    I did a `gbp import-orig --uscan` with the old watch file. I see 
 many changes in upstream sources, most of them were due to autogenerated 
 autoconf files being updated. So I change debian/watch to point 
 to upstream gitlab tags[1], but I forgot to remove the local (previously 
 downloaded) tarball. So, after locally resetting all branches, my 
 second `gbp import-orig --uscan` correctly look at upstream git tags 
 but import in my local git the state of the previous tarball. 
    I did not see that initially and push it to salsa. 
    When I saw that, I locally, again, reset all branches and remove tags. 
 I also removed the (local) tarball. And I did a third 
 `gbp import-orig --uscan`. 
    The local state was good, then. I force-pushed to salsa but I 
 forgot to remove and repush salsa tags. And, as I did not add a 
 debian/gpb.conf, salsa CI used the (wrong) salsa upstream/3.7.8 tag 
 to create the tarball. 
  
    Regards, 
      Vincent 
  
 [1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor shows us that 
 autogenerated autoconf files can be used to hide attacks. That is 
 why I would prefer to base upstream tarball on upstream git tags 
 instead of upstream (hand-made with "make dist") tarballs. 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2) 

[ list messages | list forums | previous | next | reply ]

search for:

328,124 visits
(c) 1994,  bbs@darkrealms.ca