1st of all. I would like to quote this from official issue-tracking documentation:
The issue tracker is not a discussion forum
The issue tracker is a tool to help the developers be more productive and efficient in their work. It is not a place for discussion. If you wish to discuss something in the issue tracker, please do so on the forum or mailing lists (see Help, Support, Mailing Lists, and Forum). You can simply link to the relevant issue in your discussion post.
Having said (or shared) that, here is the forum. We can talk and discuss open issues. See which are still valid or could be solved. And act accordingly. I have written a simple tool for myself to get a random list of open issues and review them in my free time.
1. issue #8383: Num lock state not restored after reboot - reported by adw SOLVED/CLOSED
Enabling num lock and setting the option to remember this setting doesn't work. Num lock is off again after rebooting dom0.
I believe this to be a misunderstanding. Setting the Numlock status remembering option in XFCE is valid only in user’s XFCE session. Not in LUKS/dmcrypt unlock screen. Not even in LightDM login screen. Archlinux Wiki has some workarounds to activate Numlock (not remembering status) in early boot-up. So what does the user want in this case? Should we write a tool to replicate XFCE setting for early boot? Should we properly document how to activate Numlock in early boot? Should this issue be closed?
the certificate for the domain that qubes uses to upgrade its distro has had an expired certificate since the 18th, visited the website manually and looked at the certificate and it is expired.
That domain is hosted by fepitre and hosts repositories of unsupported Qubes OS versions. adw has mentioned fepitre in the issue comments but not received a reply. Looking at the domain right now shows proper valid Let’s Encrypt certificate. Most probably with proper auto-renewal using certbot or similar. Looking at Certificate issuing history, shows proper and timely renewals. I believe the issue to be invalid. The only possibility that comes to mind would be if user had been trying to update an ancient version of Qubes OS which did not have ISRG Root X1 root certificate in updatevm but only DST Root CA X3. In that case, user should update via http, hopefully to a newer Qubes OS version.
No, it’s not a misunderstanding. I wasn’t trying to get Num Lock to persist outside of the Xfce session. For example, I would press Num Lock while typing in a text document in an app qube, then reboot Qubes OS, then open the same (or another) text document, and Num Lock would no longer be on. It was not about early boot-up at all.
The fact that we can no longer reproduce it probably means that there was some change between 4.1 and 4.2 or it was otherwise accidentally fixed/unbroken in the meantime.
If an issue should be closed, then a comment to that effect needs to go on the issue itself, otherwise it will probably not get closed. Even if it does (e.g., because we happen to see the comment here on the forum by coincidence), we will just have to link or copy/paste your comment on the issue when we close it, otherwise people will not know why it was closed and get upset.
The same general principle applies for other issues actions (e.g., reopening, label changes). Don’t expect anything to happen unless a clear (and reasonably concise) comment requesting that action is posted to the issue itself.
Yes. Sure. But before commenting on Github, we should assure that we have a proper solution and not a false positive which is agreed by more than just one user. We do not want to clutter the Github commenting area for other devs. That is why I am using Forum this way.
if you want to clean issues, a low hanging fruit is to search for issues tagged for older qubes os version and check if the bug is still relevant, also ask OP if they still encounter the issue on 4.2
I am not personally very picky. I use the --random --limit 7 in my tool and look at 7 Random issues. Whatever shows up. Maybe leave some of the easier low hanging fruits for the others who might be interested.
I think there’s a middle ground here where you can link to a single forum post (keeps the information discoverable directly from the ticket) without cluttering and going against the documentation. If the discussion becomes spread over more than one forum post, you could link the posts to each other rather than adding further comments to the GH issue. Even if you’ve got more than one issue per forum post this could still work.
ETA: the guidance about not cluttering the ticket doesn’t mean it’s not appropriate to ping the ticket owner on the forum - it could be and atm I wouldn’t expect them to find the post. It looks to me like you’ve engaged enough with both tickets here to justify notifying the owners.
That would make sense. I wasn’t sure if you were proposing this as a standard process or experimenting, but either way I think these are quick wins for keeping information together without cluttering.
OK. Let’s focus on something a little bit more complex.
Issue #8512 - Avoid reusing disposable VM names until reboot - Created by DemiMarie in September 2023, self-assigned. Self-assignment removed in March 2024.
Let’s deep dive to the issue. The logic of DispVM ID generation is decided in get_new_unused_dispid function of qubes.app module of qubes-core-admin repo. Which is this:
def get_new_unused_dispid(self):
for _ in range(int(qubes.config.max_dispid ** 0.5)):
dispid = random.SystemRandom().randrange(qubes.config.max_dispid)
if not any(getattr(vm, 'dispid', None) == dispid for vm in self):
return dispid
raise LookupError((
'https://xkcd.com/221/',
'http://dilbert.com/strip/2001-10-25')[
random.randint(0, 1)])
It tries for (square root of max_dispid == 100) times to generate a random number which is not used by other DispVM. Then it fails and returns either of XKCD or Dilbert comic strips (who says programmers do not have sense of humour?). The max_dispid is hard coded to 10000, in case you were wondering. That is the maximum number of concurrent Disposables (Maximum number of qubes is also 10000).
So how to do it? We could generate a list of 1 to qubes.config.max_dispid, shuffle it and add it to a queue at program initialization. It is necessary to assure that the list is unique in session. Then serve from it until queue runs out. Then we do queue regeneration again just in case the machine is going to run over 10000 DispVMs in one session (maybe it is a build machine). I will try this and see if works well. Then I will make a pull request with proper Github comment.
Issue #4842 - Improve UX and documentation of services SOLVED/CLOSED
The above issue was opened on Feb 25, 2019 by adw for Qubes OS R4.0:
Check the services of sys-firewall and see that qubes-firewall is not enabled.
Despite this, sys-firewall still seems to work correctly as a FirewallVM.
Reply by Mark:
Works as intended - service not listed means “use default value”.
This is also included in qvm-service manual you linked:
And the issue was filed as a UX issue.
Few months later at 14 Dec 2019, Marmarta pushed a new commit to qubes-manager. This text was added at the bottom of Services tab of VM Settings GUI:
Unlisted services will follow default settings.
So I believe the issue is fixed. Here is the most recent screenshot of Services Tab (I preferred it to be bold among two others. But it will do):
then update grub via grub2-mkconfig -o /boot/grub2/grub.cfg or something similar for UEFI, the boot entry menu will be changed from
Qubes, with Xen hypervisor
to
Qubes release 4.2.1 (R4.2), with Xen hypervisor
or we can fine-tune sed to get just the R4.2 part or 4.2.1 part.
The /etc/default/grub file is provided by grub2-tools package. So a new one should be packaged and installed with a menu regeneration trigger. I am not good at packaging RPMs or deciding if this change would belong to any of the existing packages. I guess someone else could look into this if interested.
update
User could look into qubes-linux-utils repository. There is a custom grub file shipped via qubes-utils package. It might be possible to add another to resolve the original post request. Or you could look into anaconda documentation on how the /etc/default/grub file is generated during installation.
Issue #9298 - Window title of Qubes Template Switcher reads “Template Manager”, confusingly similar to that of the Qubes Template Manager
This issue is openned just two hours ago. I nickname this the Schrodinger’s issue.
It is easy to change this line from Template Manager to Template Switcher and make the user happy. But this will contradict with the executable filename which is qubes-template-manager which is again confusing as it is acutally the template switcher.
The executable for actual template manager (download/upgrade/remove/…) is called qvm-template-gui. So it will be still more confusing.
Are you doing any filtering of the random selection here? It might be worth delaying further issues around now to see if some of these get picked up, now that there’s a nice range.
Agree with this, though I wonder if discussion and a separate ticket should wait until there’s someone volunteering to own the issue, to avoid the forum getting flooded with unactioned threads. This “context update on multiple random tickets” thread could work well as a starting point for that, or people could use the random selection tool for themselves.
