qBittorrent fails to build on OS X 10.10.5

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Hello :)

Let me start out by saying that I think that simply put, Yosemite (or Xcode 7.2.1) isn't supported anymore, and that the response is a "Sorry, can't fix that," but perhaps it's still worth reporting here, if nothing else, perhaps then qbittorrent should just refuse to install on macOSes as old as mine is.

I've tried previously to get a recent qBittorrent installed on another machine with El Cap, first using official binaries (which require, IIRC, Mojave now), then Homebrew, then manually from source, and I failed to do so, eventually settling on using Wine and a Windows version of qBittorrent — though not entirely without issues.

So, as I — just an hour or so ago — decided to try Macports instead of continuing my constant battle with Homebrew on this old Air with Yosemite on it, and being absolutely stunned at how much better Macports is, I spotted qBittorrent in the list of available ports and decided to give it a try.

As expected, though, it did fail to build, with errors about missing nomers in the std namespace, such as is_same_v and optional. A bit of Googling seems to suggest that this might be due to a dependency on Xcode > 11, but even if so, I believe that might just be abstracting a deeper dependency on a newer gcc? I mean, qBittorrent isn't a Mac app at birth, so the dependency on Xcode might not be by necessity.

I also note that Macports informs me that the version of qt I'm offering to the build process isn't the newest, but that it might be the newest one compatible with my OS. Sounds about right :)

I hope it's comme-il-faut to create this ticket — if not, apologies. I did read the rules, and also found one interesting previous ticket (​https://trac.macports.org/ticket/59980), which seems to suggest that until very recently, qBittorrent via Macports did indeed still build on OS X 10.10, but in the meantime it seems that the version offered has also received quite a bump, so this could explain the current incompatibility.

I'll attach the logs, and conclude by thanking you for Macports and your input.

Cheers, Daniel

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Main.log install/build log

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Shell output

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Forgot to say that my Xcode is 7.2.1, and pkgutil --pkg-info=com.apple.pkg.CLTools_Executables puts out:

package-id: com.apple.pkg.CLTools_Executables

version: 7.2.0.0.1.1447826929

volume: /

location: /

install-time: 1615233228

groups: com.apple.FindSystemFiles.pkg-group com.apple.DevToolsBoth.pkg-group com.apple.DevToolsNonRelocatableShared.pkg-group

[i0ntempest]

qBittorrent could be built on Yosemite before because 4.3.3 requires C++17 and 4.3.2 only needs C++14 features. This is probably similar to this: ​https://trac.macports.org/ticket/62421 where the system's libc++ doesn't have the required feature to build the software. If you don't mind though, I can add some logic to lock you at 4.3.2, until the macports devs potentially find a way to use new C++ features on old OSes.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Hello i0ntempest, thank you for your kind response :)

Being able to install 4.3.2 would be absolutely fantastic. Anything from 4.2.2 and up fits my requirements, since that's the version that added PERFORMANCE: Move multiple torrents one by one (glassez) which finally avoided a disk-fragmentation-inducing "unfortunateness" in the up-till-then design of the code.

I read your bit about soe logic to lock me at 4.3.2 and went googling, found this: ​https://trac.macports.org/wiki/howto/InstallingOlderPort . I cloned https://github.com/macports/macports-ports.git, git logged the Portfile for qBittorrent, saw that fa286ad50976db0b978940bda10c9b2a3570eaf9 was the commit for v4.3.2, checked that out, did what the guide told me to, and holy cow. I now have qBittorrent 4.3.2 running on Yosemite :D

I friggin' love you, and Macports, too :D Why oh why have I wasted soooo many hours with Homebrew :D

AFAIU, there's no "pinning" of ports in Macports, correct? So, until 4.3.3 builds here — if you really think that that will ever happen — still can't get over the joy of finding someone who actually gives a crap about older macOSes — the hacker in me is thinking perhaps I could perhaps "just" rename qBittorrent to something like qBittorrent@432 and install that?

Thank you so much for helping out :)

[kencu (Ken)]

If you're curious, see #62426 where I'm tracking how we might use a newer libc++ on older systems.

[i0ntempest]

There is port “pinning” but that’ll need me adding stuff to the portfile and push it to the repo (what I meant by add some logic), and isn’t changeable by the user. After that future updates will not be downloaded for you (and everyone on Yosemite).

[kencu (Ken)]

Homebrew, Ubuntu,and many other package managers have a command for the user to "pin" the port themselves to stop upgrades.

(I use that myself on Ubuntu to stop kernel updates on a certain 2006 MacBookPro that is a bit touchy with kernels).

On MP, we have to manually do it, in the portfile, which suits our purposes (or use a Local Repository, which many of us do use).

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Yes, I too use pinning with apt (and previously with brew). It's nice to have :) But of course, it makes a lot of sense to have that option also on the maintainer-side with something like Macports, where you maintain so many previous versions of macOS.

The reference to mkvtoolnix earlier got me remembering that I needed that installed too, and I noticed that the latest version offered to my system is v41, which I myself had noted was the last one I could download from fosshub and run on Yosemite. For old grumpy farts like me who think that macOS has, in key areas, gotten worse with every installment since Mavericks (not to say that it hasn't improved in others), hunting for compatible versions is an annoyance, but also a bit of a curiosity, as it doesn't always make sense.

For instance, I get that the dependency on Qt in mkvtoolnix-gui can cause mkvtoolnix itself to lose support when it is built against newer versions of Qt that have their own new dependencies. But then something like qBittorrent 4.3.2 actually being available for Yosemite here, in Macports, indicates that this is most likely just laziness or sloppiness on the behalf of the developers. Also, in the case of mkvtoolnix, a) The GUI has looked exactly the same for as long as I remember, so why not stick with the more compatible version of Qt?, and b) Why are the CLI also incompatible with older versions? There's no reason I can think of that these tools shouldn't be compatible with pretty much any system out there, just link statically. Or maybe that's just bad practice. But I do enjoy my decades-old CLI binaries that were built with static linking, that still work everywhere, all the time.

Well, sorry, I know this isn't a chat room, I should use my inside-voice for my rants :D I'm very curious about your link, Ken. It's been about 15 years since I last did any C/++ programming, so I'm rusty with compiling and linking and whatnot, but in general terms I get what you're trying to do over there, and I really like it. It reminds me of compiling on Windows, where — if I'm not misremembering — libraries are loaded a bit like the shell uses its $PATH, so that you can override linked libraries with custom versions by placing them further up in the path, e.g. right next to the executable. But that's been about 20 years, so I may remember incorrectly, or the may have changed it since :D Either way, I applaud any work that's done to keep the golden years (in my view) of OS X alive for as long as possible ;)

i0ntempest, If you're going to do the server-side pinning of qbt version 4.3.2 for Yosemite, I'd love to know, so I can remove the mental note to avoid upgrading :D

Thank you guys!

[i0ntempest]

Pinning is done in ​https://github.com/macports/macports-ports/commit/700dbb1a. Please try this portfile or wait for updated portindex and report back, so I can close this.

[i0ntempest]

Cleared 10.11 buildbot: ​https://build.macports.org/builders/ports-10.11_x86_64-watcher/builds/43000 Should be ok now, please reopen if it's not

[kencu (Ken)]

The newest libc++ library and headers are now installed with the macports-libcxx port. All functionality is enabled.

It works to enable the latest mkvtoolnix to work all the way back to at least 10.11. I haven't tried this port yet.

I caution that in addition to confirming building, some attempts to confirm functionality of ports built against the newer libc++.dylib should be undertaken. Issues are possible. Early days as yet.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Hey guys :) Sorry for my slow responding — dealing with some stress-related after effects that trip me up and cause me to drop out from time to time.

i0ntempest, if I'm understanding you correctly, then I believe I can confirm — upgrading ports leaves qbt at 4.3.2 now.

Ken, are you saying that you may have a fix ready that would allow qbittorrent 4.3.3 to compile on Yosemite now? If so, is there any way (that I might understand) for me to test it out?

Cheers guys

[i0ntempest]

upgrading ports leaves qbt at 4.3.2 now

Yes

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

i0ntempest, I've also debugged a problem with qBittorrent discarding torrents on exit, if they're added as magnet links and the metadata hasn't yet been retrieved. I've corresponded on github, and was informed that it might've been an issue with libtorrent-rasterber@1.2.10, which is used here in the ports version. I hacked the Portfile to get libtorrent-rasterbar 1.2.11 instead to see if it fixed the issue, and it did. It compiled just fine here on my Yosemite install without needing any other changes but modifying my hosts file to serve libtorrent-rasterbar-1.2.11.tar.gz and updating the hash and filesize so that it would try to compile. Which it did correctly. Clearly, this isn't the correct way to do things like this, and I'm not sure if I've broken anything in my ports installation by doing so, but do you think you could bump the version in the offical ports file as well? And in a way so that my "pinned" 4.3.2 version of qbt also pulls this version, should I reinstall in the future and have forgotten how to hack it in?

Thanks :)

PS: I see there's also a libtorrent-rasterbar 1.2.12 version available. Should I try to build that the same way and see if it succeeds on a Yosemite machine?

[kencu (Ken)]

Replying to DanielSmedegaardBuus:

Ken, are you saying that you may have a fix ready that would allow qbittorrent 4.3.3 to compile on Yosemite now? If so, is there any way (that I might understand) for me to test it out?

The instructions are in the notes for the macports-libcx port.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Replying to kencu:

Replying to DanielSmedegaardBuus:

Ken, are you saying that you may have a fix ready that would allow qbittorrent 4.3.3 to compile on Yosemite now? If so, is there any way (that I might understand) for me to test it out?

The instructions are in the notes for the macports-libcx port.

I'm not ashamed to say I have no idea where to go from that :D I tried googling it, but nothing recent. Also googling "macports-libcx" (with the quotes to ask for verbatim results) yields zero results :/ But maybe that just means it's above my paygrade :D

[kencu (Ken)]

sorry, macports-libcxx. missed an x on this ipad.

It's a port; you can just install it, and it will show you it's notes.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Thanks, Ken :) I tried it out. Installed fine, and I tried adding those flags to the Portfile, but I'm out of my normal braining area here :D Think this is something for i0ntempest to try out. My change didn't "bite" :)

[i0ntempest]

qBittorrent discarding torrents on exit, if they're added as magnet links and the metadata hasn't yet been retrieved

I actually experienced this just today with my qbittorrent web server.
Updating libtorrent-rasterbar to 1.2.11 is trivial (and will be pushed soon), you just change the version and the hashes; but 1.2.12 is giving me problems as it needs b2 executable which does not seem to be included in macports boost. I'll leave this to the maintainer, we can open a ticket to request an update.

[i0ntempest]

Btw since macports-libcxx is now up I might make qbittorrent use that on older systems some time later, after all the major issues are worked out. Would be great if you'd like to test.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Sounds great! Thank you :) I'll be very happy to test.

EDIT: About the metadata thing. This seems to be a long-standing WONTFIX bug, that seems to be in rasterbar. At least I'm assuming that's what they (qbt team) mean when they're saying, "won't fix, this is upstream." With a proxy enabled, this is super frustrating. You literally have to restart qbittorrent to get it to actually download metadata for magnet links and start downloading. Oh well, that's another issue :)

[kencu (Ken)]

success. screen shot attached. patch shortly.

[kencu (Ken)]

qbittorrent 4.3.3 on 10.10.5 Yosemite

[kencu (Ken)]

OK Daniel, I would much appreciate you kicking the heck out of the tires on this <​https://github.com/macports/macports-ports/pull/10382> to see if there are any warts we don't currently know about.

If we push this, it will be port 1 with this approach. Still not claiming all will be 100% wonderful, but it's worth a good look at least, I think.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Damn, that's nice! :D Great work! And this with the official qBittorrent team only supporting Mojave and up XD I'll test away, thank you!

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Okay, I'm running 4.3.3 from your PR on my server now. So far, so good, just pulled in five new torrents that are humming along ATM. FTR, though, I do still run it with the libtorrent-rasterbar 1.2.11 version that I hacked in earlier, and not the 1.2.10 version in the official MacPorts repo since it's buggy — but I'm assuming that's not an issue, as i0ntempest will probably update that, too, before merging your PR?

This is really cool, you guys :D This is the best place ever :D Loving MacPorts and the MacPorts peeps! Wheeeeee XD

[i0ntempest]

libtorrent-rasterbar 1.2.11 is already up, if what u did to hack it was changing the version and the hash, you're good to go cuz that's exactly what I did. Can't do the same for 1.2.12 though.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Awesome — that's what I did, too :)

[i0ntempest]

Reopening for the better solution, PR 10382 will close this.

[i0ntempest]

They just released 4.3.4.1 and it requires libtorrent 1.2.12 (also qt 5.12). Now we have to open a ticket to request an update.

[kencu (Ken)]

well I was kind of expecting that qt change, although came sooner than I thought... makes the libcxx fix kinda moot :)

we might as well stay with the current hold-back then....and we may see this pattern play out in other ports as well.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Well, on the positive side, I've now been running with the libcxx qBittorrent thing for more than a day now without any issues - apart from the well-known unrelated proxy bugs, but it runs just as well as the non-libcxx version did :)

Ken, btw, does this libcxx do anything for getting a more recent version of mkvtoolnix running on older OS Xes like mine? Or is the incompatibility over there unrelated? (I did try using just the CLI binaries from a more recent mkvtoolnix on my Yosemite install, but no dice).

Oh, speaking of "just binaries," i0ntempest, is there a reason the -gui, i.e. "nox" variant of the qbittorrent port still pulls in Qt? I tried the nox version of qbittorrent on a headless Armbian server recently, and thought it great that it didn't pull in any extra stuff, like Qt. Especially these days, where the WebUI in qBittorrent has gotten as good as it has :)

[i0ntempest]

Because it uses qmake to build, which is the build system from Qt. You *might* be able to use a lower qt version to build the nox version but I've never tried.\ \ Also quick question for Ken, what's the oldest OS that can get Qt 5.12?

[kencu (Ken)]

I modified mkvtoolnix to use macports-libcxx here <​https://github.com/macports/macports-ports/pull/10238> but didn't commit it.

Works great on the systems I tried. Let me know if you get stuck.

qt5.12 is 10.13+. Sometimes a motivated person can maintain a port to use an older qt5 version, for a while at least. New features come in gradually in most cases. If someone wants to do that, the libcxx fix might still prove useful, up to you.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Roger that, thanks for the info :) I've been thinking lately that maybe I should get back into C programming, so that I could possibly figure out how to keep some of this new software alive for my old Yosemite. In a perfect world run by me, there would be a fork of OS X Yosemite as the basis for a new and better OS :D Right now, my brain overheats from an hour in a terminal window, though, so outlook to C programming is probably long XD

I'll have a go at the mkvtoolnix-libcxx version! Thanks for that :D

[kencu (Ken)]

Replying to DanielSmedegaardBuus:

there would be a fork of OS X Yosemite as the basis for a new and better OS

The way we are approaching this is to leave the core OS as it is, and add newer features and functions in an add-on library called 'legacysupport'. See: <​https://github.com/macports/macports-legacy-support>

I've been working on this for several years, and in time it was taken up and accepted by MacPorts and has been steadily enhanced and updated as needed.

[i0ntempest]

Closing, we've decided to stay with the current fallback because of the new Qt requirement.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Wondering if something changed afterall, since I'm now unable to update my ports without qbittorrent trying to upgrade, and breaking in the process?

It all starts with the error "moc_mainwindow.cpp:432:22: error: no member named 'toggleVisibility' in 'MainWindow'" ... Perhaps the qBittorrent got "thawed" again on Yosemite, or is this unrelated? Should I attach the log to the original message's log files, or open a new ticket?

Cheers :)

[i0ntempest]

What's the version you currently have right now? On Yosemite you should have 4.3.2 and it shouldn't attempt to update to a later version, and I thought you have gotten that version to build on your system?
Also if you want macports to ignore qbit build error and upgrade other stuff, give -p flag to it so it ignores all build errors, but only use this as a last resort.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

I uninstalled it again to get upgrade outdated to work again (thanks for the -p flag tip), but it was 4.3.2. I just tried installing it again, and it fails the same way.

You're right that it worked fine before, and my confusion is exactly why it wants to update, since I thought it had been frozen. Perhaps a dependency has been updated that triggered the need for a rebuild?

I'll attach the log to the OP — let me know if I should open a new report instead.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Build failure June 2021

[i0ntempest]

The only change between your last successful build and now (for your old OS and 4.3.2 anyway) *should* be the use of the new boost portgroup and change of the boost version used. I'll make a few tweaks and let you know when I'm done.

[i0ntempest]

I have made changes so that qbit now builds using boost 1.71 on your OS, can you do a selfupdate and try building again?

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Build failure June 30 2021

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Thank you, i0ntempest, and sorry for my slowness in communication.

I do remember something about libboost being part of the failed upgrade I tried to do initially, so that might be related. I still get an error when I try to install qBittorrent after a selfupdate, though. It feels like it's a little different, though... Here's the shell output — I'll attach the log to the OP:

# sudo port install qbittorrent
Portfile changed since last build; discarding previous state.
--->  Computing dependencies for qBittorrent
--->  Fetching archive for qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://cph.dk.packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://nue.de.packages.macports.org/qBittorrent
--->  Fetching distfiles for qBittorrent
--->  Verifying checksums for qBittorrent
--->  Extracting qBittorrent
Warning: reinplace s|QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.14|QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.10|g didn't change anything in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent/qBittorrent/work/qBittorrent-4.3.2/macxconf.pri
--->  Configuring qBittorrent
Warning: Qt dependency is not the latest version but may be the latest supported on your OS
--->  Building qBittorrent
Error: Failed to build qBittorrent: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent/qBittorrent/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port qbittorrent failed

Perhaps I should try to remove boost and see if that makes any difference? Currently, I have:

# port installed boost
The following ports are currently installed:
  boost @1.71.0_3+no_single+no_static+python38
  boost @1.71.0_4+no_single+no_static+python38 (active)

I'll give it a shot and report back.

EDIT: A little odd. I removed boost, libtorrent-rasterbar, and mkvtoolnix (the latter two as removing boost would break them anyway). Trying to install then, it fails because:

# sudo port install qbittorrent
--->  Computing dependencies for qBittorrent
The following dependencies will be installed:  libtorrent-rasterbar
Continue? [Y/n]:
--->  Fetching archive for libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-2.0.4_0+python39.darwin_14.x86_64.tbz2 from https://packages.macports.org/libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-2.0.4_0+python39.darwin_14.x86_64.tbz2.rmd160 from https://packages.macports.org/libtorrent-rasterbar
--->  Installing libtorrent-rasterbar @2.0.4_0+python39
Warning: boost176 must be installed with +python39.
--->  Activating libtorrent-rasterbar @2.0.4_0+python39
--->  Cleaning libtorrent-rasterbar
--->  Fetching archive for qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://cph.dk.packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://nue.de.packages.macports.org/qBittorrent
--->  Building qBittorrent
Error: Failed to build qBittorrent: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent/qBittorrent/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port qbittorrent failed

I immediately noticed the warning about boost, but now I think it's not the culprit for this particular failure, since it does say that it installed it, and indeed if I try to install it afterwards, it asks me if I want to rebuild it. Also, the qbittorent build log fails the same way as always, with the "mainWindow" references.

This time, however, it failed *very* quickly compared to before, so I'm not sure if there's some kind of caching going on here? I'm starting to feel like I'm messing up my installation completely XD

[i0ntempest]

qbit now depends on boost176 via the new boost portgroup, I've tried with boost171 in the last commit which is essentially the same as the boost port but that didn't make a difference. Your error is more likely Qt related (and also occurs on 10.12) and I've asked on qbit GitHub discussions for help. Can you post the full log of that last failed build?

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Build failure June 30 2021, #2

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Ah, okay, so perhaps Qt needs to be frozen as well as qbittorrent for it (and friends, I assume) to build on <=10.12?

Attached the latest log — I assume that's the one you asked for?

[i0ntempest]

Ok so the error didn’t change, it appeared very quickly prolly because you didn’t clean before running the build again. Qt is already frozen on old systems, so since you did have it successfully built before it still should now. I have no idea what change I made now makes it fail.
For the sake of isolating the problem, can you pull the portfile when you successfully built 4.3.2 and try that? Basically do what you did here again: ​https://trac.macports.org/ticket/62441#comment:4 , and attach the log if it fails.
I’ll get some sleep and wait for you result, it’s nearly 5am here.

[kencu (Ken)]

qt5 is frozen on 10.10 to the last version that will build on 10.10.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Roger that! And sorry for keeping you up :) I'll go to sleep as well in a bit, so sleep tight ;)

For the sake of completeness, I did a port uninstall, then port clean on libtorrent-rasterbar, boost, and qbittorrent. Had no idea there was a clean argument available. It didn't actually uninstall all of that, as it wasn't all installed at this point, but either way, a subsequent reattempt failed the same as before - this time after actually building stuff.

I then uninstalled and cleaned again, re-did the old workaround with the git checkout, and now I'm looking at some boost/libtorrent-related oddness again, as interestingly, it did fail once more:

cd ~/Projects/macports-ports/net/qBittorrent
 daniel@air  ~/Projects/macports-ports/net/qBittorrent   master  git checkout fa286ad50976db0b978940bda10c9b2a3570eaf9
Updating files: 100% (2827/2827), done.
Note: switching to 'fa286ad50976db0b978940bda10c9b2a3570eaf9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at fa286ad5097 qBittorrent: update to 4.3.2
 daniel@air  ~/Projects/macports-ports  ➦ fa286ad5097  sudo port uninstall libtorrent-rasterbar boost qbittorrent
 daniel@air  ~/Projects/macports-ports  ➦ fa286ad5097  sudo port clean libtorrent-rasterbar boost qbittorrent
--->  Cleaning libtorrent-rasterbar
--->  Cleaning boost
--->  Cleaning qBittorrent
 daniel@air  ~/Projects/macports-ports  ➦ fa286ad5097  sudo port installed libtorrent-rasterbar boost qbittorrent
None of the specified ports are installed.
 ✘  daniel@air  ~/Projects/macports-ports  ➦ fa286ad5097  cd net/qBittorrent
 daniel@air  ~/Projects/macports-ports/net/qBittorrent  ➦ fa286ad5097  sudo port install
--->  Computing dependencies for qBittorrent
The following dependencies will be installed:
 boost
 libtorrent-rasterbar
Continue? [Y/n]:
--->  Fetching archive for boost
--->  Attempting to fetch boost-1.76_0.darwin_14.x86_64.tbz2 from https://packages.macports.org/boost
--->  Attempting to fetch boost-1.76_0.darwin_14.x86_64.tbz2 from https://cph.dk.packages.macports.org/boost
--->  Attempting to fetch boost-1.76_0.darwin_14.x86_64.tbz2 from https://nue.de.packages.macports.org/boost
--->  Fetching distfiles for boost
--->  Verifying checksums for boost
--->  Extracting boost
--->  Configuring boost
--->  Building boost
--->  Staging boost into destroot
--->  Installing boost @1.76_0
--->  Activating boost @1.76_0
--->  Cleaning boost
--->  Fetching archive for libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-2.0.4_0+python39.darwin_14.x86_64.tbz2 from https://packages.macports.org/libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-2.0.4_0+python39.darwin_14.x86_64.tbz2.rmd160 from https://packages.macports.org/libtorrent-rasterbar
--->  Installing libtorrent-rasterbar @2.0.4_0+python39
Warning: boost176 must be installed with +python39.
--->  Activating libtorrent-rasterbar @2.0.4_0+python39
--->  Cleaning libtorrent-rasterbar
--->  Fetching archive for qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_0+gui.darwin_14.x86_64.tbz2 from https://packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_0+gui.darwin_14.x86_64.tbz2 from https://cph.dk.packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_0+gui.darwin_14.x86_64.tbz2 from https://lil.fr.packages.macports.org/qBittorrent
--->  Fetching distfiles for qBittorrent
--->  Verifying checksums for qBittorrent
--->  Extracting qBittorrent
--->  Configuring qBittorrent
Warning: Qt dependency is not the latest version but may be the latest supported on your OS
--->  Building qBittorrent
--->  Staging qBittorrent into destroot
--->  Installing qBittorrent @4.3.2_0+gui
--->  Activating qBittorrent @4.3.2_0+gui
--->  Cleaning qBittorrent
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: libtorrent-rasterbar @2.0.4+python39
Continue? [Y/n]:
--->  Computing dependencies for libtorrent-rasterbar
--->  Cleaning libtorrent-rasterbar
--->  Scanning binaries for linking errors
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     libtorrent-rasterbar @2.0.4_0+python39
--->  Computing dependencies for libtorrent-rasterbar
--->  Fetching distfiles for libtorrent-rasterbar
--->  Verifying checksums for libtorrent-rasterbar
--->  Extracting libtorrent-rasterbar
--->  Applying patches to libtorrent-rasterbar
--->  Configuring libtorrent-rasterbar
Error: Failed to configure libtorrent-rasterbar: boost176 must be installed with +python39.
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/main.log for details.
Error: rev-upgrade failed: Error rebuilding libtorrent-rasterbar
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

So, it actually installs everything, though with this boost warning, then it does a post-build check and decides it should rebuild libtorrent-rasterbar, this time turning the warning related to boost into an actual error, and fails there. The qBittorrent v.4.3.2 that it just installed, for the record, now runs. Its about screen mentions both boost 1.7.6 and libtorrent 2.0.4.0 in the Software Used section...

Okay, so first of all, I'm certain that this error didn't occur when I used this git checkout work-around before. Second of all, I can't say for absolute certain that that previous successful build of qbt 4.3.2 didn't include libtorrent @ 2.0.4.0, but seriously... I mean, my comment #14 is clearly talking about 1.2.x versions, and I think I remember being confused when looking for changelogs etc., and seeing 2.x versions on github... But my braining isn't exactly up to snuff these days. It just feels really weird to me, this.

Am I missing something really obvious, because I feel like a big question mark when I see myself at this same old checkout in the git repo, yet I'm seeing what I believe is the most recent libtorrent-rasterbar version being pulled in?

My brainy hurty :D Sorry if I'm just being daft here. Gonna go sleepface and then see if you have any ideas after hopefully having slept for a bunch of hours :)

[i0ntempest]

That rev-upgrade thing is most likely caused by mismatched dependency library (boost and boost176), but the key here is it builds... I'm confused as hell, the current portfile with fallbacks should give you mostly (if not exactly) the same configuration. Can you post your main.log for the successful build?

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

I know, right? Very strange. I'm attaching the libtorrent-rasterbar log — I assume that's the interesting one, since it's the one that fails, right?

I notice in this log it says:

:debug:configure boost176 is installed with the following variants: +no_single+no_static+python38
:debug:configure   required: python39, forbidden:
:debug:configure   rejected, because required variant python39 is missing
:error:configure Failed to configure libtorrent-rasterbar: boost176 must be installed with +python39.
:debug:configure Error code: NONE
:debug:configure Backtrace: boost176 must be installed with +python39.

That's pretty clear, though. Should've read that last night, but yeah, I'm not too good at the braining ATM :D

I'm gonna try and see if I can rebuild boost176 against/for python39 as it indicates it wants. Still confused about how libtorrent 2.x gets pulled in even when building from this older commit, but really, I've never uninstalled and cleaned boost176, just boost, so it kinda makes sense that I can't get rid of this issue, assuming that that's the culprit. Questions though, would be what triggered the boost176 (re)build with that configuration to make the qbt build sad, and if it should really have that requirement for boost176 in the first place (that is, being built for python39), seeing as how it apparently works fine with one built for python38.

About libtorrent 2.x being pulled in even when at this older commit, is there someplace outside of the macports-ports repo that gets to co-decide which dependency versions get pulled in? Pretty curious about that one :)

Anyway, I'll attach the log, try to rebuild boost176 for python39 and see what happens.

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

libtorrent build log July 1

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

Well, that took care of the boost176 error, but it brought back the original error:

daniel@air  ~/Projects/macports-ports/net/qBittorrent  ➦ fa286ad5097  sudo port install boost176 +python39
Password:
--->  Computing dependencies for boost176
--->  Fetching archive for boost176
--->  Attempting to fetch boost176-1.76.0_2+no_single+no_static+python39.darwin_14.x86_64.tbz2 from https://packages.macports.org/boost176
--->  Attempting to fetch boost176-1.76.0_2+no_single+no_static+python39.darwin_14.x86_64.tbz2.rmd160 from https://packages.macports.org/boost176
--->  Installing boost176 @1.76.0_2+no_single+no_static+python39
--->  Deactivating boost176 @1.76.0_2+no_single+no_static+python38
--->  Cleaning boost176
--->  Activating boost176 @1.76.0_2+no_single+no_static+python39
--->  Cleaning boost176
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
 daniel@air  ~/Projects/macports-ports/net/qBittorrent  ➦ fa286ad5097  sudo port install qbittorrent
--->  Computing dependencies for qBittorrent
--->  Fetching archive for qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://cph.dk.packages.macports.org/qBittorrent
--->  Attempting to fetch qBittorrent-4.3.2_2+gui.darwin_14.x86_64.tbz2 from https://nue.de.packages.macports.org/qBittorrent
--->  Fetching distfiles for qBittorrent
--->  Verifying checksums for qBittorrent
--->  Extracting qBittorrent
Warning: reinplace s|QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.14|QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.10|g didn't change anything in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent/qBittorrent/work/qBittorrent-4.3.2/macxconf.pri
--->  Configuring qBittorrent
Warning: Qt dependency is not the latest version but may be the latest supported on your OS
--->  Building qBittorrent
Error: Failed to build qBittorrent: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_qBittorrent/qBittorrent/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port qbittorrent failed

Attaching this log again. This really looks like that qt issue you mentioned that also affects 10.12. I'll try to uninstall qt and reinstall it from the older commit and see what happens.

EDIT: Not sure, actually, how to reinstall those qt-* ports that I have installed. I see qt59 in aqua/qt59, but I don't know how to install those "subports," like qt59-qtbase and so on... :/

[DanielSmedegaardBuus (Daniel Smedegaard Buus)]

qbittorrent build log July 1

[kencu (Ken)]

your error is

:info:build compiling moc_previewlistdelegate.cpp
2534	:info:build moc_mainwindow.cpp:432:22: error: no member named 'toggleVisibility' in 'MainWindow'
2535	:info:build         case 70: _t->toggleVisibility((*reinterpret_cast< const QSystemTrayIcon::ActivationReason(*)>(_a[1]))); break;
2536	:info:build                  ~~  ^

and more like that.

This likely means the qt you are building against is too old, so don't try to install an even older one...

You may be able to work around this with some effort. I have done this many times. But it may not be a small enough effort to be worthwhile.

[i0ntempest]

Actually my goal is exactly to use new dependencies (libtorrent 2.x, boost 1.76) to build the old 4.3.2 portfile so I can know if it's the "environment" that's causing the error or the changes in the portfile itself. Now it succeeded meaning the culprit is the changes in the portfile, tho I don't know which exactly. Well it's going to be a painfully long troubleshooting process...