It’s about predictable troubleshooting for a bug, not about whether you can install it. No doubt you can, but now the dev has to figure out what particular feature in your OS is causing the issue.
I had this recently, installed Distrobox, which is just a set of scripts, on Aurora. Could not --clone a container, no how. Blow the OS out and install Fedora 41 which is what Aurora is derived from except it’s rpm-ostree, and not a problem cloning a Distrobox. Closed the bug as there was no point trying to figure out what went on there for some weird edge case of using a specific distro.
Aren’t you at all curious why it failed though? (If not, no harm no foul – I certainly know time diagnosing a bug is always in short supply, from personal experience). What if it’s a symptom of something important that might happen later even in Fedora 41?
Sometimes it just feels like containers are used as justification for devs to blow off bug reports. As a dev I want to understand why a failure occurs.
I’m curious enough, but this seemed like it was going to be hard to track down a way to fix it, and I needed that laptop working for other things, and Aurora was being really flakey in other ways as well so I just nuked it.
I’m happy to burn time debugging an issue for a project, but when I tried to track down a way to bugreport to Aurora, I didn’t find anything easily. And this promised to turn into a fingerpointing issue, so I moved on.
Which app? Because it all depends of how much access and permissions the app needs. Managing volumes or changing devices is usually the problem. So far I’ve only had to layer two apps (on bazzite, though): veracrypt and vorta. To access old backups. Everything else works fine, even desktop integration. Although I prefer to use box buddy to handle distrobox as a UI, which runs as a flatpak without problem. It’s been great so far at resolving that kind of issues: bug, update, now it works.
So I started out with a bugreport to BoxBuddy because that’s where I first found it. Then they said it was just running a distrobox create --cloneyaddayadda so I then went to distrobox issues. Then when I tried it in a dualboot on that same machine of Fedora 41 and it worked, I went searching for the Aurora issues tracker with no luck, and then I got on with my life.
It’s about predictable troubleshooting for a bug, not about whether you can install it. No doubt you can, but now the dev has to figure out what particular feature in your OS is causing the issue.
I had this recently, installed Distrobox, which is just a set of scripts, on Aurora. Could not --clone a container, no how. Blow the OS out and install Fedora 41 which is what Aurora is derived from except it’s rpm-ostree, and not a problem cloning a Distrobox. Closed the bug as there was no point trying to figure out what went on there for some weird edge case of using a specific distro.
Aren’t you at all curious why it failed though? (If not, no harm no foul – I certainly know time diagnosing a bug is always in short supply, from personal experience). What if it’s a symptom of something important that might happen later even in Fedora 41?
Sometimes it just feels like containers are used as justification for devs to blow off bug reports. As a dev I want to understand why a failure occurs.
I’m curious enough, but this seemed like it was going to be hard to track down a way to fix it, and I needed that laptop working for other things, and Aurora was being really flakey in other ways as well so I just nuked it.
I’m happy to burn time debugging an issue for a project, but when I tried to track down a way to bugreport to Aurora, I didn’t find anything easily. And this promised to turn into a fingerpointing issue, so I moved on.
Which app? Because it all depends of how much access and permissions the app needs. Managing volumes or changing devices is usually the problem. So far I’ve only had to layer two apps (on bazzite, though): veracrypt and vorta. To access old backups. Everything else works fine, even desktop integration. Although I prefer to use box buddy to handle distrobox as a UI, which runs as a flatpak without problem. It’s been great so far at resolving that kind of issues: bug, update, now it works.
So I started out with a bugreport to BoxBuddy because that’s where I first found it. Then they said it was just running a
distrobox create --clone yaddayaddaso I then went to distrobox issues. Then when I tried it in a dualboot on that same machine of Fedora 41 and it worked, I went searching for the Aurora issues tracker with no luck, and then I got on with my life.