No default repositories in Qt Maintenance Tool - qt

I recently installed Qt 5.5 and its MaintenanceTool (MaintenanceTool.exe). The default repositories were working, but after one day, my MaintenanceTool suddenly reported that no repositories were set.
I can temporarily enter individual repositories in the MaintenanceTool, but I would like to get the default repos set.
Why are they gone?
How can I set the default repositories again?
Thanks in advance

The Maintenance Tool is doing crazy things since the recent updates made by Qt team.
The only solution I know is:
Add the next temporary repository in "Settings":
Windows: http://download.qt.io/online/qt5/windows/x86/online_repository/
Mac: http://download.qt.io/online/qt5/mac/x64/online_repository/
Now, you can update the Qt components and you should see a new update for the Maintenance Tool.
If everything goes well, the Maintenance Tool will be fixed.

Note: The download speed of the default repo by Qt is quite slow (usually limited to 2mbps).
So you might want to use official mirrors to get much higher download speeds.
Here is some magic to quickly get those repo addresses:
Open the following url (which contains online repo components of Qt:
http://download.qt.io/online/qt5/windows/x86/online_repository/qt/
You'll see some files in that directory
Click on "Details" on the right side of any of those files.
This will show mirror links of the file such as:
http://ftp2.nluug.nl/languages/qt/online/qt5/windows/x86/online_repository/qt/1.0.0meta.7z
Cut the right side of any of those urls to make it end with online_repository.
It should be something like this afterward:
http://ftp2.nluug.nl/languages/qt/online/qt5/windows/x86/online_repository
And here we go! Now you can use that url as a repository which has higher download speeds.

As of today (2017 oct. 30) the Mac repo url http://download.qt-project.org/online/qtsdkrepository/mac_x64/root/qt worked for me
Manually added the repository as a custom repo.
Updated (only the maintenance tool was updated at that time it seems).
Relaunched the maintenance tool.
Deleted the custom repo because many repos were present in the default repositories list, then quit the maintenance tool.
Relaunched the maintenance tool and updated normally.
BTW: I used the offline installer for the first install on my Mac.

26th January 2022 : If you are using an old maintenance tool, you need to update the maintenance tool first by adding the repo 'http://download.qt-project.org/online/qtsdkrepository/windows_x86/desktop/tools_maintenance' under user defined repository following the above described steps and selecting "update components". Now you can add/remove the components such as QtCharts, Qt3D etc.

Related

Qt Installer Framework - Update control script

The problem
I have a Qt IFW installer with an online repository, from which users fetch data to install and update the software.
My installer has a "root script" defined in config.xml:
<Installer>
<!-- ... -->
<ControlScript>controllerscript.qs</ControlScript>
</Installer>
Now I want to change the content of controllerscript.qs and deploy it on the online repository.
when a new user installs the software for the first time, it works as expected
when a user updates its software from a previous version using MaintenanceTool.exe, it does not get the update
Possible solution
I realized that when you create the installer, it generates a file named MaintenanceTool.dat which seems to contain controllerscript.qs (+ other things). I managed to manually copy that file and push it to the online repository (inside a package). That way, the maintenance tool is able to see the package update, and correctly gets the new MaintenanceTool.dat. After that, the maintenance tool is indeed using the new code from controllerscript.qs.
Question
Is there another (cleaner) way to achieve that?
If not, is it really safe to provide a manual update to MaintenanceTool.dat? That file contains many other things, so is there a risk to interfere with the rest?
Thanks,

Is there a easy way to protect, or revert Qt source code?

I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.

Products.Carousel uninstall seems to be leaving leftover contents

I'm testing Products.Carousel before to install it on a web site in production.
While uninstalling the product via the quick_installer went smoothly, the banners are still present in their folder (while only being reachable via the "Contents" tab of the parent folder or through the ZMI).
Is is safe to delete this folder manually? Should this be considered a bug in Products.Carousel - i.e. should I file a bug report?
Tia
The uninstall implementation should never touch your content (This is a scary imagination imho). It should uninstall the configuration aka GenericSetup steps.
If you uninstall a certain package, which has it's own content types you should remove them (created objs) manually before uninstall the package.
So, no bug report necessary.

Symfony Own Private Vendor

I have a private bundle that I import in the vendor.
Now, I'm working in my project and want to edit some code in the vendor bundle.
Now I've done that and want to commit to code, so I go the dir of that bundle and say: "git commit -a" so I give a message, save and now I have a commit. Oke, "git push" and give the response "Everything is up-to-date"... So I can't push that but I can commit??
Is this not a way to commit? Should I just clone the repo and work there?
You should never edit the vendor code directly - this is the whole point of dependency management.
Composer basically works by looking at your composer.json file, and fetching the repositories and versions you specify. If you need to make changes to one of your dependencies, you should make the change in the original repository, push the changes up to GitHub (or wherever you're hosting the code) and run composer update.
When Composer installs a vendor, it checks out a particular commit, so you are not on a branch. You need to checkout the master branch — or whichever you're using — and commit to it and push it.
Its a long time ago that I asked this question. Mean while I got the answer but never updated my stackoverflow question, sorry for that!
The answer on my own question is to get the dependency with composer --prefer-source.
https://getcomposer.org/doc/03-cli.md#install
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.

Updating MiniProfiler.MVC3 NuGet package after editing MiniProfiler.cs in App_Start

In the MiniProfiler.MVC3 NuGet package, it creates a file in App_Start that is used to control MiniProfiler settings (the SqlFormatter to use, modifications to the ViewEngines, when to start MiniProfiler, etc.).
There are a lot of TODO comments in this file talking about how to change the code to perform how you want. This is great, but when the NuGet package is updated, it will see that I've changed the file and not pull down the updated version. The problem here is that I lose any updates to that file, and depending on what else updated in the package, making it unusable (for example, when upgrading MiniProfiler.MVC3 from version 1.9 to version 2.0.1 after modifying MiniProfiler.cs in App_Start, the project will no longer build because of needed changes to that file in the 2.0.1 version).
What is the best way to handle this? Should I create my own file in App_Start and not modify the one in the NuGet package, ensuring that I will always get the full update when upgrading to the latest version of the NuGet package?
You could backup the file in App_Start, update it, then merge the files manually, or using a merge tool. You'd probably end up doing this anyways if you're using source control.
Quick-and-dirty: create the file you want. Then copy over/merge every time you upgrade with nugget. Or with every compile. The added build time is negligible.
Slightly better: use the precompile event in visual studio and compare the files. If they differ - either copy over or tell the user. I can't figure out a way to show a message box, or similar, on the top of my head but one could always create a new file with a compilation error and some text nearby "discrepancy in the xxx file".
try using mercurial queues. You can get your code to the point you want (excluding the file you refer to), and then commit. Make changes to your file, and push it to a queue. Make sure to exclude it from any future updates (manually), and then when you want to update your package, pop it off your code base. This will make it look like it used to, and run the nuget update. Then you can push the queue back to the code, and your changes will re-applied. It might take a bit of fiddling, but worth a look.
For reference:
https://www.mercurial-scm.org/wiki/MqExtension
https://www.mercurial-scm.org/wiki/MqTutorial
https://developer.mozilla.org/en/Mercurial_Queues

Resources