Ok great, thanks, - I was hesitant to put it there as this seems so crowded 
Just to be clear, we have a specific procedure for reporting Qubes issues:
Basically, everything goes into a single issue tracker (qubes-issues).
Of course, it’s perfectly fine for people to use other issue trackers for other things, but that means they won’t be included in our usual issue tracking workflow. (For example, I probably won’t see them or triage them, and other devs might not either.)
In this case, @fepitre, it sounds like you want specific problems with your own signed weekly builds to be reported in your own issue tracker, and you’ll handle all those issue reports all by yourself, completely separate from general Qubes issues (which go in qubes-issues). Is that right? If so, I don’t see a problem with it. That’s entirely your call. My only concern is that some people might not understand the distinction and might start reporting more general Qubes bugs in your tracker (simply because they experienced those bugs while using your weekly builds), in which case you’ll have to redirect them to qubes-issues. I can imagine that getting annoying. 
In that case, it might be simpler just to have people submit their reports to qubes-issues, and we can make a separate label for your weekly builds.
For example, when we ask folks to test release candidates, we ask them to report any bugs they find in qubes-issues. Since these weekly builds are similar (just further out on the testing spectrum), I would think we’d want any bugs discovered in them reported in qubes-issues too. The only sort of report that I can imagine might be more appropriate for Issues · fepitre/updates-status-iso · GitHub would be problems with your weekly build process itself (though, even those could be reported to qubes-issues, if you want).
So, @kaspro, based on what you posted above, it sounds like you should probably just report your bug to qubes-issues.
4 Likes
I think the best here ( to be honest I would not handle all problems on my own) is to link the build issue in the Qubes issue tracker. This is mostly for tagging which build has a problem. Is it a better approach?
2 Likes
Yes, that sounds good.
Ok sound good, thank you @adw ! Seems like by responding to this you magically fixed the dom0 for me again @fepitre 
Hence, I will not open an issue in qubes-issues now, but if it should break again.
1 Like
I suspect the new 4.2 weekly build will have Fedora 38, but where may I see the change-list?
They haven’t been published yet, but you can see the in-progress drafts here:
(Note, however, that release candidates are not the same thing as weekly builds.)
1 Like
@fepitre this is annoying Unable to use WiFi with R4.2.0-rc1 · Issue #8242 · QubesOS/qubes-issues · GitHub
Yes I understand but please understand also that we are already handling lot of issues at the same time…
4 Likes
Hello @fepitre
I see last weekly iso is from 8 of august and we are the 23rd.
I was hoping to see core-agent-linux v4.2.19 (r4.2) · Issue #3940 · QubesOS/updates-status · GitHub fixed but commented at core-agent-linux v4.2.19 (r4.2) · Issue #3940 · QubesOS/updates-status · GitHub fixing Newly populated private volumes don’t get proper SELinux labels · Issue #8242 · QubesOS/qubes-issues · GitHub.
I then opened Qubes-4.2.202308081030-x86_64 doesn't boot from ISO (Heads) · Issue #8443 · QubesOS/qubes-issues · GitHub
Can’t wait to test 4k templates and test for BRTFS/TLVM speed comparisons, fwupd support and wyng-backups (TLVM<->BRTFS) restoration over BRTFS with bees deployed to see deduplication of restored VMs and templates.
Where are Q4.2 testing reports and discussions? I am part of the testing team but I see no activity there. Maybe there is issues with my account? @deeplow ? No 4.2 testing category, just this post About the 4.2 Testing category ?
Unfortunately there hasn’t been too much activity there 
.
To this point, I do find a few more 4.2 discussions in 4.2 Testing category. But the last activity is from July.
I opened a threat for the members of the testing team to ask about their thoughts on how to make it work for them:
1 Like
I am trying to test 4.2 on a librem 14 laptop, but have no access to post in the testing group, so while I want to contribute, I am not really able to. I’m been using qubes for a little over a year and I am a habitual alpha/beta tester so I’d be happy to help.
My first run at 4.2 didn’t last long though, because after install the laptop just gets stuck in an infinite loop immediately following the blue qubes boot screen, so I’m back to 4.1 for now until I figure out what is going on.
Thank you for contributing! Please have a look at the instructions for joining the testing team here:
1 Like
Note: next weekly builds will boot from ISO on next builds.
Last openqa build booted from Heads today, with user having to detach sign manually with his own key and having to validate integrity first manually.
This is why we love detached signatures after all: They do both in one step: validating integrity and authenticity at once.
Created an issue specific to installer related problem that cannot be resooved but by reinstalling Track installer related bugs and needed packages (templates versions including needed packages) · Issue #8449 · QubesOS/qubes-issues · GitHub
The latest weekly build, Qubes-4.2.202308260643-x86_64.iso, doesn’t recognize my AX201 WiFi card. And I don’t have access to a LAN to check a wired connection. fyi
1 Like
Happy testing!