Re: Request to review and upload unhide 20210124-4
Hello Samuel, > It looks like you're not importing the new releases with "gbp > import-orig", as the commit adding the new sources to debian/master is > not a merge commit and the description looks different, I suggest > always importing new upstream releases with "gbp import-orig --uscan > --pristine-tar". > The commit in the upstream branch is also not tagged, gbp would tag > that for you (and sign it if properly configured). > I have tagged it myself to avoid the round trip. Thanks for pointing this out. I used 'gbp import-orig' for updating the source code, but things went weird while I was manually tinkering with my local unhide git repository - modifying commits , rebasing commits, etc. I think, as you mentioned, I have to stick to the gbp command rather than modifying commits or creating upstream/pristine-tar tags manually. > So this issue can't be solved by upstream, we will have to keep this > in the packaging for a bit, I'm thinking it should be fine to remove > it after bookworm gets released. > Oh, I didn't get to reply to this part before, sorry, but the as I > mentioned above, the new upstream release doesn't address the > Replaces+Breaks issue, that's on the packaging side. Got it. Now I have a better understanding of the problem. Thanks for helping me make the source package better. Best, Fukui On Fri, 2 Sept 2022 at 22:35, Samuel Henrique wrote: > Hello Fukui, > > > # But if you don't mind, please call me Fukui as you did in the latest > email ;) > > Surely, thanks for letting me know. > > > I have updated the draft source package of unhide. > > Kindly find the source code for this version below. > > https://salsa.debian.org/dfukui/unhide/-/tree/debian/master > > Great. > > > The main changes from the previous draft are: > > * New upstream version 20220611 > > It looks like you're not importing the new releases with "gbp > import-orig", as the commit adding the new sources to debian/master is > not a merge commit and the description looks different, I suggest > always importing new upstream releases with "gbp import-orig --uscan > --pristine-tar". > The commit in the upstream branch is also not tagged, gbp would tag > that for you (and sign it if properly configured). > I have tagged it myself to avoid the round trip. > > > * Drop Replaces+Breaks > > So this issue can't be solved by upstream, we will have to keep this > in the packaging for a bit, I'm thinking it should be fine to remove > it after bookworm gets released. > > >> Okay, now I understand what Replaces+Breaks should be like in this case. > >> In fact, I initially had a plan to address such two issues as #1016613 > and the new upstream step by step. > >> That said, it looks like uploading the new upstream would also address > the Replaces+Breaks issue. > > Oh, I didn't get to reply to this part before, sorry, but the as I > mentioned above, the new upstream release doesn't address the > Replaces+Breaks issue, that's on the packaging side. > > I have sponsored the package and pushed the commits (I have done some > changes to the changelog), thanks for contributing! > > Regards, > > -- > Samuel Henrique >
Re: Request to review and upload unhide 20210124-4
Hello Fukui, > # But if you don't mind, please call me Fukui as you did in the latest email > ;) Surely, thanks for letting me know. > I have updated the draft source package of unhide. > Kindly find the source code for this version below. > https://salsa.debian.org/dfukui/unhide/-/tree/debian/master Great. > The main changes from the previous draft are: > * New upstream version 20220611 It looks like you're not importing the new releases with "gbp import-orig", as the commit adding the new sources to debian/master is not a merge commit and the description looks different, I suggest always importing new upstream releases with "gbp import-orig --uscan --pristine-tar". The commit in the upstream branch is also not tagged, gbp would tag that for you (and sign it if properly configured). I have tagged it myself to avoid the round trip. > * Drop Replaces+Breaks So this issue can't be solved by upstream, we will have to keep this in the packaging for a bit, I'm thinking it should be fine to remove it after bookworm gets released. >> Okay, now I understand what Replaces+Breaks should be like in this case. >> In fact, I initially had a plan to address such two issues as #1016613 and >> the new upstream step by step. >> That said, it looks like uploading the new upstream would also address the >> Replaces+Breaks issue. Oh, I didn't get to reply to this part before, sorry, but the as I mentioned above, the new upstream release doesn't address the Replaces+Breaks issue, that's on the packaging side. I have sponsored the package and pushed the commits (I have done some changes to the changelog), thanks for contributing! Regards, -- Samuel Henrique
Re: Request to review and upload unhide 20210124-4
Hello Samuel I have updated the draft source package of unhide. Kindly find the source code for this version below. https://salsa.debian.org/dfukui/unhide/-/tree/debian/master The main changes from the previous draft are: * New upstream version 20220611 * Drop Replaces+Breaks For more details about the changes, take a look at: https://salsa.debian.org/dfukui/unhide/-/compare/debian%2Fmaster-old-20220901...debian%2Fmaster?from_project_id=69150 I would appreciate it if you review the source package and sponsor it. Note that upstream and pristine-tar branches are also updated accordingly. Best, Fukui On Tue, 30 Aug 2022 at 22:38, Daichi Fukui wrote: > Hello Samuel, > > # I have no preference in which I am called Daichi or Fukui. > # But if you don't mind, please call me Fukui as you did in the latest > email ;) > > Thanks for reviewing my source package draft. > > Okay, now I understand what Replaces+Breaks should be like in this case. > In fact, I initially had a plan to address such two issues as #1016613 and > the new upstream step by step. > That said, it looks like uploading the new upstream would also address the > Replaces+Breaks issue. > Thus, if you could give me some time, I would like to work on the new > release with the new upstream source code. > > Best, > Fukui >
Re: Request to review and upload unhide 20210124-4
Hello Samuel, # I have no preference in which I am called Daichi or Fukui. # But if you don't mind, please call me Fukui as you did in the latest email ;) Thanks for reviewing my source package draft. Okay, now I understand what Replaces+Breaks should be like in this case. In fact, I initially had a plan to address such two issues as #1016613 and the new upstream step by step. That said, it looks like uploading the new upstream would also address the Replaces+Breaks issue. Thus, if you could give me some time, I would like to work on the new release with the new upstream source code. Best, Fukui
Re: Request to review and upload unhide 20210124-4
Hello Fukui (sorry I'm not sure if you prefer to be called Daichi or Fukui, I'm going by your email signature, but please let me know otherwise), All of the changes looks good, but I have a comment about the Break+Replaces change: I see that you followed the suggestion from the bug report [0] to go with: Replaces: unhide (<< 20210124-3) Breaks: unhide (<< 20210124-3) But in this specific case, we know that there's only one specific version which triggers the issue, and that is "20210124-2", as that's the one that shipped unhide-gui in the unhide package. In this situation, I recommend us to use the following Breaks+Replaces: Replaces: unhide (= 20210124-2) Breaks: unhide (= 20210124-2) As it only affects testing, and we can remove the whole entry after a shorter amount of time compared to the usual Breaks+Replaces scenarios (I think right after the first stable release should be fine). There's also a new upstream release, which IIRC has 3 patches from d/patches applied, so we can drop those, would you be interested in packaging the new release as well? We can upload all of the changes at once. But please note that if you don't want to work on the new release, I can upload just a revision with the current changes you have as they're good (I can change the Breaks+Replaces if needed). Thank you for contributing! [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016613 -- Samuel Henrique
