sysmo-bts
/
meta-sysmocom-bsp
9
1
Fork 0
Code Issues Pull Requests Releases Activity

gpsd: upgrade to 3.24 #9

Merged
osmith merged 3 commits from osmith/nightly into laforge/nightly 2022-12-15 09:44:43 +00:00
Conversation 5 Commits 3 Files Changed 14 +318 -392
osmith commented 2022-12-14 13:23:00 +00:00
Member
Copy Link
gpsd: upgrade to 3.24

Change the version by renaming the .bb file. Reset the version of the
recipe (PR) back to "r0" again, as it is common practice after changing
the package version. The previous value "r3.20" looked a bit like a
package version, but it's not that.

Rebase patches:
* 0001-gps2udp-Add-a-label-timestamp-and-mac-address-to-eac.patch
* 0002-gps2udp-leave-argv-untouched.patch (leave-argv-untouched.patch)
* 0003-tsip-configure-and-enable-1PPS.patch (gpsd-tsip-pps.patch)

Add build fixes:
* 0004-SConscript-force-use-of-pthread.patch

Drop patches:
* 0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch:
  unused in previous version
* 0001-SConstruct-disable-html-and-man-docs-building-becaus.patch:
  doesn't apply, instead disable docs building via manbuild='no'
* 0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch:
  not needed anymore (no splintopts line in 3.24)
* gpsd-3.3-ldflags.patch:
  fixed upstream
* no-rpath-please.patch:
  doesn't apply, not needed anymore (see 5df2de36 in gpsd.git)

Related: https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-PR
Related: SYS#6222
Change-Id: I2debe481c5f1cc4ee8290ad0dc883d6a4ea73741

Marked as WIP as it depends on sysmocom/gpsdate#1 and contains a debug commit to build gpsdate from my branch currently. But it can be reviewed and tested already.

``` gpsd: upgrade to 3.24 Change the version by renaming the .bb file. Reset the version of the recipe (PR) back to "r0" again, as it is common practice after changing the package version. The previous value "r3.20" looked a bit like a package version, but it's not that. Rebase patches: * 0001-gps2udp-Add-a-label-timestamp-and-mac-address-to-eac.patch * 0002-gps2udp-leave-argv-untouched.patch (leave-argv-untouched.patch) * 0003-tsip-configure-and-enable-1PPS.patch (gpsd-tsip-pps.patch) Add build fixes: * 0004-SConscript-force-use-of-pthread.patch Drop patches: * 0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch: unused in previous version * 0001-SConstruct-disable-html-and-man-docs-building-becaus.patch: doesn't apply, instead disable docs building via manbuild='no' * 0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch: not needed anymore (no splintopts line in 3.24) * gpsd-3.3-ldflags.patch: fixed upstream * no-rpath-please.patch: doesn't apply, not needed anymore (see 5df2de36 in gpsd.git) Related: https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-PR Related: SYS#6222 Change-Id: I2debe481c5f1cc4ee8290ad0dc883d6a4ea73741 ``` Marked as WIP as it depends on https://gitea.sysmocom.de/sysmocom/gpsdate/pulls/1 and contains a debug commit to build gpsdate from my branch currently. But it can be reviewed and tested already.
osmith added 1 commit 2022-12-14 13:23:01 +00:00
46dd65ce74 gpsd: cosmetic fixes in SRC_URI, EXTRA_OESCONS 
Change-Id: Ic5af4db7bbce6ba0bf55387265fdfc95a1761230
pespin commented 2022-12-14 16:22:59 +00:00
Member
Copy Link

In the "gpsd: upgrade to 3.24" patch I fail to see where did you import the new recipe from.
Because usually that recipe may exist in some poky or meta-* layer and we simply copy it over here. Did you look at that? That's usually the way, since it means upstream poky already took care of applying new needed patch fixes, etc.

In the "gpsd: upgrade to 3.24" patch I fail to see where did you import the new recipe from. Because usually that recipe may exist in some poky or meta-* layer and we simply copy it over here. Did you look at that? That's usually the way, since it means upstream poky already took care of applying new needed patch fixes, etc.
osmith commented 2022-12-14 16:37:54 +00:00
Author
Member
Copy Link

In the "gpsd: upgrade to 3.24" patch I fail to see where did you import the new recipe from.
Because usually that recipe may exist in some poky or meta-* layer and we simply copy it over here. Did you look at that? That's usually the way, since it means upstream poky already took care of applying new needed patch fixes, etc.

I've compared the upstream packaging with ours:
https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd

There are several differences. First we have the following patches. The 0002 patch can probably be safely dropped, and maybe also 0001, but 0003 looked pretty important. So I forward ported all of them to ensure the functionallity stays the same.

  • 0001-gps2udp-Add-a-label-timestamp-and-mac-address-to-eac.patch
  • 0002-gps2udp-leave-argv-untouched.patch (leave-argv-untouched.patch)
  • 0003-tsip-configure-and-enable-1PPS.patch (gpsd-tsip-pps.patch)

Then we have a pretty old toolchain with old gcc, old python etc. I had to add the following fix to make it build:

  • 0004-SConscript-force-use-of-pthread.patch

We also have other customizations in our package that we probably can't just throw away, like the udev rules or specific gpsd-default files per product.

├── gpsd
│   ├── 60-gpsd.rules
│   ├── gpsd
│   ├── gpsd-default
│   ├── gpsd.service
│   ├── oc2g
│   │   ├── gpsd-default
│   │   └── gpsd.service
│   ├── sysmobts2100
│   │   └── gpsd-default
│   ├── sysmobts-v2
│   │   └── gpsd-default
│   └── sysmocom-idu
│       └── gpsd-default

So it was not possible to just use the upstream package.

> In the "gpsd: upgrade to 3.24" patch I fail to see where did you import the new recipe from. > Because usually that recipe may exist in some poky or meta-* layer and we simply copy it over here. Did you look at that? That's usually the way, since it means upstream poky already took care of applying new needed patch fixes, etc. I've compared the upstream packaging with ours: https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd There are several differences. First we have the following patches. The 0002 patch can probably be safely dropped, and maybe also 0001, but 0003 looked pretty important. So I forward ported all of them to ensure the functionallity stays the same. * 0001-gps2udp-Add-a-label-timestamp-and-mac-address-to-eac.patch * 0002-gps2udp-leave-argv-untouched.patch (leave-argv-untouched.patch) * 0003-tsip-configure-and-enable-1PPS.patch (gpsd-tsip-pps.patch) Then we have a pretty old toolchain with old gcc, old python etc. I had to add the following fix to make it build: * 0004-SConscript-force-use-of-pthread.patch We also have other customizations in our package that we probably can't just throw away, like the udev rules or specific gpsd-default files per product. ``` ├── gpsd │   ├── 60-gpsd.rules │   ├── gpsd │   ├── gpsd-default │   ├── gpsd.service │   ├── oc2g │   │   ├── gpsd-default │   │   └── gpsd.service │   ├── sysmobts2100 │   │   └── gpsd-default │   ├── sysmobts-v2 │   │   └── gpsd-default │   └── sysmocom-idu │   └── gpsd-default ``` So it was not possible to just use the upstream package.
osmith requested review from pespin 2022-12-14 16:38:21 +00:00
pespin commented 2022-12-14 16:40:40 +00:00
Member
Copy Link

My point is precisely that the submitted commits should be made from the point of view of:
1- importing a given well-known upstream recipe from poky/meta-* and providing info about the repo and hash it was imported from in the commit decription.
2- Make whatever change are needed in top of it to have it work for us

So ideally you should be submitting 2 patches, each doing one of the points above, even if "1" alone doesnt compiler and both need to be merged.
This allows in the future finding out what did we change on our side.

My point is precisely that the submitted commits should be made from the point of view of: 1- importing a given well-known upstream recipe from poky/meta-* and providing info about the repo and hash it was imported from in the commit decription. 2- Make whatever change are needed in top of it to have it work for us So ideally you should be submitting 2 patches, each doing one of the points above, even if "1" alone doesnt compiler and both need to be merged. This allows in the future finding out what did we change on our side.
osmith force-pushed osmith/nightly from 8a6ea0bc45 to 6ad5bab56a 2022-12-14 16:52:23 +00:00 Compare
osmith commented 2022-12-14 16:55:57 +00:00
Author
Member
Copy Link

as discussed in chat, improved the commit message

as discussed in chat, improved the commit message
pespin approved these changes 2022-12-14 17:14:58 +00:00
osmith force-pushed osmith/nightly from 6ad5bab56a to 5bd261b12a 2022-12-15 09:36:50 +00:00 Compare
osmith changed title from WIP: gpsd: upgrade to 3.24 to gpsd: upgrade to 3.24 2022-12-15 09:41:40 +00:00
osmith commented 2022-12-15 09:43:37 +00:00
Author
Member
Copy Link

Now that sysmocom/gpsdate#1 is merged, I've changed the last patch to properly use the latest commit from gpsdate master. I've verified again that it builds. The change is trivial, I don't think it needs another review round. Merging to laforge/nightly as discussed.

Now that https://gitea.sysmocom.de/sysmocom/gpsdate/pulls/1 is merged, I've changed the last patch to properly use the latest commit from gpsdate master. I've verified again that it builds. The change is trivial, I don't think it needs another review round. Merging to laforge/nightly as discussed.
osmith merged commit 5bd261b12a into laforge/nightly 2022-12-15 09:44:43 +00:00
osmith deleted branch osmith/nightly 2022-12-15 09:44:44 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
pespin
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sysmo-bts/meta-sysmocom-bsp#9
No description provided.
Delete Branch "osmith/nightly"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?