| 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() {
Hi, this is a bit of an OCD thing, but `makepkg --printsrcinfo` usually generates a file with two newlines at the end. This logic happens in pacman/scripts/libmakepkg/srcinfo.sh.in (/usr/share/makepkg/srcinfo.sh) The relevant functions: srcinfo_close_section() { echo } srcinfo_write_global() { ... srcinfo_open_section 'pkgbase' "${pkgbase:-$pkgname}" srcinfo_write_section_details '' srcinfo_close_section } srcinfo_write_package() { ... srcinfo_open_section 'pkgname' "$1" srcinfo_write_section_details "$1" srcinfo_close_section } As you can see, the functions process section details, and then print out a newline no matter if details printed something or not. The write_section_details eventually leads to: srcinfo_write_attr() { ... printf "\t$attrname = %s\n" "${attrvalues[@]}" } 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. Thanks for taking a look at this, Marti