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@t490 <mailto:steve@t490> src]$ > [steve@t490 <mailto:steve@t490> src]$ > [steve@t490 <mailto:steve@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@t490 <mailto:steve@t490> src]$ > [steve@t490 <mailto:steve@t490> src]$ > [steve@t490 <mailto:steve@t490> src]$ rm -f build.log > [steve@t490 <mailto:steve@t490> src]$ rm -rf googlemaps/ > [steve@t490 <mailto:steve@t490> src]$ rm -rf install-root/ > [steve@t490 <mailto:steve@t490> src]$ rm -rf libgit2/ > [steve@t490 <mailto:steve@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
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
