Message ID | CACbE=3pkfRrx7QT4nTNqDtNMif+p2Bpoj1NcqUKvX7MFJhTqMQ@mail.gmail.com |
---|---|
State | Superseded, archived |
Headers | show |
Series | [pacman-dev] Fix srcinfo sometimes printing double newline at the end | expand |
Hi Marti, On Fri, Jun 26, 2020 at 01:09:54AM +0200, Martin Rys wrote: > Hi, > this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually > generates a file with two newlines at the end. I agree with you, this bugs me a lot too. [...] > Which seems to always print out a newline, so I believe the > srcinfo_close_section function is not needed there and simply > removing it and the two lines that call it would solve this issue, as > per the patchfile in the attachment. I proposed a similar patch recently[0] but it was rejected as the newline separators are apparently part of the spec so they should be retained[1]. I sent out another patch after that only removes the final newline but it wasn't reviewed so I thought that the pacman devs thought it was a non-issue. Since you seem to agree with me, though, I'll resend that patch and hopefully it'll be reviewed this time around. Thanks, Denton [0]: https://lists.archlinux.org/pipermail/pacman-dev/2020-June/024399.html [1]: https://lists.archlinux.org/pipermail/pacman-dev/2020-June/024405.html
On 26/6/20 9:27 am, Denton Liu wrote: > Hi Marti, > > On Fri, Jun 26, 2020 at 01:09:54AM +0200, Martin Rys wrote: >> Hi, >> this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually >> generates a file with two newlines at the end. > > I agree with you, this bugs me a lot too. > > [...] > >> Which seems to always print out a newline, so I believe the >> srcinfo_close_section function is not needed there and simply >> removing it and the two lines that call it would solve this issue, as >> per the patchfile in the attachment. > > I proposed a similar patch recently[0] but it was rejected as the > newline separators are apparently part of the spec so they should be > retained[1]. I sent out another patch after that only removes the final > newline but it wasn't reviewed so I thought that the pacman devs thought > it was a non-issue. Since you seem to agree with me, though, I'll resend > that patch and hopefully it'll be reviewed this time around. > Please do not resend patches. We have a patch tracking system, which means patches are never lost. I have given this patch a very low priority. That means with limited time available to me, I will likely review other patches first. But it will get considered at some stage. Allan
Hi Allan, On Fri, Jun 26, 2020 at 09:43:39AM +1000, Allan McRae wrote: > Please do not resend patches. We have a patch tracking system, which > means patches are never lost. Sorry about that, coming from other mailing list projects, I didn't realise that patches here are automatically tracked. Do you have a link to the patch tracker? (Also, if possible, the v2 that I just sent should be used over the old v2 as it contains an updated commit message without the typo and with a sign-off.) > I have given this patch a very low priority. That means with limited > time available to me, I will likely review other patches first. But it > will get considered at some stage. Thanks! -Denton
On 6/25/20 7:51 PM, Denton Liu wrote: > Hi Allan, > > On Fri, Jun 26, 2020 at 09:43:39AM +1000, Allan McRae wrote: >> Please do not resend patches. We have a patch tracking system, which >> means patches are never lost. > > Sorry about that, coming from other mailing list projects, I didn't > realise that patches here are automatically tracked. Do you have a link > to the patch tracker? https://patchwork.archlinux.org/project/pacman/list/ > (Also, if possible, the v2 that I just sent should be used over the old > v2 as it contains an updated commit message without the typo and with a > sign-off.) I've marked your v2 patch as superseded. Today's v3 (mislabeled "v2" :p) is now the current iteration. >> I have given this patch a very low priority. That means with limited >> time available to me, I will likely review other patches first. But it >> will get considered at some stage. > > Thanks! > > -Denton At first glance it seems fine to me.
--- srcinfo.sh.in.edit 2020-06-26 01:02:38.662489244 +0200 +++ srcinfo.sh.in 2020-06-26 01:02:58.086464001 +0200 @@ -30,9 +30,6 @@ printf '%s = %s\n' "$1" "$2" } -srcinfo_close_section() { - echo -} srcinfo_write_attr() { # $1: attr name @@ -94,7 +91,6 @@ srcinfo_open_section 'pkgbase' "${pkgbase:-$pkgname}" srcinfo_write_section_details '' - srcinfo_close_section } srcinfo_write_package() { @@ -104,7 +100,6 @@ srcinfo_open_section 'pkgname' "$1" srcinfo_write_section_details "$1" - srcinfo_close_section } write_srcinfo_header() {