time for 5.0.9

[Dirk Hohndel]

Hi Steve,   (Linus - there's a question for you near the bottom)

> On Jun 12, 2022, at 6:10 PM, Steve  wrote:
> 
> I can test this today.

COOL!

> I didn't even notice that that build was from the 12th of May as I have not used the https://subsurface-divelog.org/downloads/daily <https://subsurface-divelog.org/downloads/daily> builds for a very long time (since I have build my own as needed) and got it on the 12 June so the dates matched in my brain as I had sorted by last modified and it was at the top :)

I hate to point this out... but when you click on that header once then the OLDEST file is on top...
And to prevent running out of disk space I have a script that cleans up this folder and keeps the last 30 days (or so - would have to check the script... I wrote that a long time ago)...
Click that header TWICE and you'll have the newest on top :)

> On that note, I also have noticed the last time I found an issue I gave almost no real details as I was headed out on a liveaboard and was just about to lose all internet access for the week.
> I will  check and dig up the last email to this list and add some more detail. A screen-shot or 2 should make it a lot clearer.

Cool. I'm sorry if I ignored a report.

I KNOW that I do that occasionally when I run out of time. And I KNOW that I try to go back and check. And sadly often still stuff falls through the cracks. Which is why I always encourage people to ping me if no one responds...

(admittedly, there are certain bugs where I simply rely on a couple of the other developers to step in as it's obviously their code where the bug is... and then it's even more common that I forget to follow up)

> I had tried renaming the directories and attempting a new build as the first thing that I did when it failed the first time as I have come across some random build issues in the past after previous upgrades to the os.
> I just deleted them altogether now and tried again just to be 100% sure, full cli output below:
> 
> 
> [steve at t490 <mailto:steve at t490> src]$ 
> [steve at t490 <mailto:steve at t490> src]$ 
> [steve at t490 <mailto:steve at t490> src]$ ls -l
> total 40
> -rw-rw-r-- 1 steve steve 22583 Jun 12 10:19 build.log
> drwxrwxr-x 5 steve steve 4096 Jun 9 16:57 googlemaps
> drwxrwxr-x 5 steve steve 4096 Jun 9 16:57 install-root
> drwxrwxr-x 15 steve steve 4096 Jan 4 2021 libgit2
> drwxrwxr-x 33 steve steve 4096 Jun 12 18:32 subsurface
> [steve at t490 <mailto:steve at t490> src]$
> [steve at t490 <mailto:steve at t490> src]$
> [steve at t490 <mailto:steve at t490> src]$ rm -f build.log 
> [steve at t490 <mailto:steve at t490> src]$ rm -rf googlemaps/
> [steve at t490 <mailto:steve at t490> src]$ rm -rf install-root/
> [steve at t490 <mailto:steve at t490> src]$ rm -rf libgit2/
> [steve at t490 <mailto:steve at t490> src]$ rm -rf subsurface/

That's... thorough...
maybe we should provide a little cleanup script that isn't quite so... brutal :)

> g++ -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld -Wl,--enable-new-dtags -shared -o libqtgeoservices_googlemaps.so .obj/qgeoserviceproviderplugingooglemaps.o .obj/qgeocodingmanagerenginegooglemaps.o .obj/qgeocodereplygooglemaps.o .obj/qgeoroutingmanagerenginegooglemaps.o .obj/qgeoroutereplygooglemaps.o .obj/qplacemanagerenginegooglemaps.o .obj/qplacesearchreplygooglemaps.o .obj/qplacecategoriesreplygooglemaps.o .obj/qgeomapreplygooglemaps.o .obj/qgeotiledmapgooglemaps.o .obj/qgeotiledmappingmanagerenginegooglemaps.o .obj/qgeotilefetchergooglemaps.o .obj/qplacesearchsuggestionreplyimpl.o .obj/qgeoerror_messages.o .obj/moc_qgeoserviceproviderplugingooglemaps.o .obj/moc_qgeocodingmanagerenginegooglemaps.o .obj/moc_qgeocodereplygooglemaps.o .obj/moc_qgeoroutingmanagerenginegooglemaps.o .obj/moc_qgeoroutereplygooglemaps.o .obj/moc_qplacemanagerenginegooglemaps.o .obj/moc_qplacesearchreplygooglemaps.o .obj/moc_qplacecategoriesreplygooglemaps.o .obj/moc_qgeomapreplygooglemaps.o .obj/moc_qgeotiledmapgooglemaps.o .obj/moc_qgeotiledmappingmanagerenginegooglemaps.o .obj/moc_qgeotilefetchergooglemaps.o .obj/moc_qplacesearchsuggestionreplyimpl.o /usr/lib64/libQt5Location.so /usr/lib64/libQt5PositioningQuick.so /usr/lib64/libQt5Quick.so /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Positioning.so /usr/lib64/libQt5QmlModels.so /usr/lib64/libQt5Qml.so /usr/lib64/libQt5Network.so /usr/lib64/libQt5Core.so -lGL -lpthread 
> /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld: No such file or directory

I am so sorry. I didn't pay enough attention when I responded the first time and could have saved you some time.
There's a very odd new feature in Fedora36 that I stumbled over and hacked around and then COMPLETELY forgot about.

Hey Linus - is this something that you see, too?

The hack around this that I found and then forgot is hidden in packaging/copr/subsurface.spec:

( cd googlemaps ; mkdir -p build ; cd build ; \
        qmake-qt5 ../googlemaps.pro ; \
        # on Fedora 36 and newer we get the package_notes that break the build - let's rip them out
        sed -i 's/-Wl[^ ]*package_note[^ ]* //g' Makefile
        make -j4 ; \
        make install_target INSTALL_ROOT=%{_builddir}/install-root )

After you run qmake against googlemaps.pro, you need to remove the that package_note warnings flag from the Makefile.

I'm sure that is NOT the right way to do it - but it's what I use for the COPR builds anyway...

Sorry about sending you the wrong way...

/D


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20220612/5ed2c8fc/attachment-0001.htm>