RFI/RFC: Fedora Linux graphical recovery environment
Hey all, Earlier this week, the Fedora Workstation WG discussed a ticket brought to us asking for a GUI-based rescue/recovery environment[1]. While we all agreed in principle that such a thing would be a very good thing to have, we don't really know how to achieve such a thing. Additionally, we're not really sure what the scope of things should be provided in said recovery environment and what kind of things people would expect to be able to fix in there. So I come to y'all to ask about this and give us some feedback on the idea, how to do it, and what kinds of things you expect people to need a recovery environment for. [1]: https://pagure.io/fedora-workstation/issue/288 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 - Errors/Warnings with `dnf update`
Ankur Sinha kirjoitti 31.3.2022 klo 12.51: On Thu, Mar 31, 2022 12:16:43 +0300, Otto Urpelainen wrote: Otto Urpelainen kirjoitti 31.3.2022 klo 11.22: Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26: Hello, Just wondering if this is a bug and what to report against. I upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update` and saw some odd output. Not sure if its a bug with dnf or selinux or the packages being installed. Let me know if its a known issue or if I need to file a bug and where. There is a Bugzilla entry for this [1]. If you are like me and try to recover by doing selinux relabeling, you can end up in a situation where login is not possible anymore [2]. This seems to be affecting multiple users, so perhaps this is worth reporting as a Common Bug [3]. I will do so a bit later, unless somebody beats me to it. Ok, I tried, but ask.fedoraproject.org gives me a permission error when I click Create Topic. (In Finnish, even though I changed the UI language to English so that I could paste the error here.) After running into multiple issues with discussion.fedoraproject.org, I am weary of Discourse. That's odd. Can you please try in a clean private or incognito window where you're not using any browser extensions/add-ons that may be blocking various bits? I found out what the problem was. Discussion can continue at Ask Fedora Site Feedback [1]. [1]: https://ask.fedoraproject.org/t/trouble-trying-to-propose-a-common-bug/20985 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
On Thu, Mar 31, 2022 at 9:10 AM Michael Catanzaro wrote: > With ipp-usb, my printer has six options: color, grayscale, deep gray, > device gray, device RGB, and deep color. I have no idea what the last > four of these mean. I also don't know whether the grayscale setting > corresponds to high-quality grayscale or black-only grayscale. Not sure > how to avoid using color ink when I only need black. My guess is to think of them this way 1. Internally uses some form of color management (could be ICC or proprietary or combination). The "deep" version means "more of". So that'd be more contrast and more color saturation. color, deep color grayscale, deep gray 2. These "pass through" the values in the printed file and do not compensate for the device's behavior at all, so it should be fairly "raw" output suitable for making ICC profiles. As the device doesn't really have RGB inks, there's still some (likely proprietary) internal RGB to CMYK conversion, or however many inks there are, e.g. CcMmYKk (for dark and light variations of those inks). device gray, device RGB I expect "device gray" will get you black ink only output. It's a toss up whether grayscale and/or deep gray actually use some color inks in order to produce smoother results, in particular using a balance of the light inks would produce better gradation. > So technically this is *more* printing options, but it sure feels like > less, since I don't see the black-only option there anymore. Yeah. Jargon. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review requests: mingw-qt6-qtwebchannel, mingw-qt6-qttranslations
Hi I've got two more mingw-qt6-* packages which are up for review, both are straight forward mingw/c++ packages. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2009269 - mingw-qt6-qtwebchannel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2070708 - mingw-qt6-qttranslations Happy to review in exchange Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
Hi Kamil, On 3/31/22 14:19, Kamil Paral wrote: I very much like how Chris summarized the problem in a more user-friendly language in test list [1]: The very rudimentary summary is: 1. When upgrading (does not apply to clean installs); 2. with a printer that supports ipp-usb (a.k.a. driverless printing); 3. using the native driver (which can be a cups filter, free or nonfree) Printing breaks. I believe this is something that was missing from your announcement. I hoped the paragraph called _'This breakage happens if both conditions below are met:' _would have done the trick. __ I tried to create a Common Issues entry for our users here: https://ask.fedoraproject.org/t/common-issues/20975 Please help me finish it by directly editing or suggesting additions and fixes in comments. That text should be readable and actionable by an average Joe, deep technical details can be linked. This is all just printer-related, scanners didn't fit into my brain for the moment, they'll get a separate treatment. I've added more details in the bug where you added the link https://bugzilla.redhat.com/show_bug.cgi?id=2066528 - please let me know which stuff I can specify further. This looks like a major change, I wonder why it wasn't included in F36 ChangeSet [2]. I think we should consider adding it there, even though it's way past the deadline. It would make the change more visible/searchable and also make the description and workarounds more accessible. This is completely my fault, I'm deeply sorry for that - I took ipp-usb being in Fedora for some time, its existence was advertised several times in reports from printing groups here, other distros have it installed by default and the breakage is documented (for long time on wiki, now even on Fedora Quick Docs), so I thought the impact would be that wide for a Change. If it helps you and others from problems, I will remove the recommendation and start the full process in F37 or F38. Now, I have a load of questions: There are quick docs pages, which were migrated by Brandon Nielsen (kudos!) and I keep them updated as SME - https://docs.fedoraproject.org/en-US/quick-docs/, tab Printing and scanning - it has terminology, known issues, useful tricks - it can help you as well. 1. Is Chris' summary above correct? Almost - the difference is the problem can happen even if you install the driverless USB device with classic driver on clean Fedora. 2. Does this affect only USB printers, and no network printers? Only USB printers which are capable of using IPP-over-USB. See the quick docs how to find out. 3. Can you estimate what portion of our user base (who own printers) is going to be affected by this? How common are printers supporting IPP over USB? I'm sorry, idk - but usually every new USB printer/scanner/multifunction device made around 2014 and newer has this support. 4. If the printer doesn't support IPP over USB, what will happen? Will the printer continue to work as usual, and the ipp-usb package will not interfere? ipp-usb ignores devices which don't have IPP-over-USB USB interface 7/1/4. Printer and its print queue should work as usual. 5. How can an average Joe tell whether he's using a classic driver (which is incompatible with ipp-usb)? Device URI (from f.e. 'lpstat -v') doesn't start with 'ipp://' and driver name doesn't contain 'driverless' or 'IPP Everywhere'. Unfortunately system settings show only 'localhost' for local connections... but CUPS Web UI shows both info at the printer detail. 6. When you talk about 'removing the old print queue', is it the same as removing the printer from system settings (e.g. gnome-control-center)? Yes - the printer in system settings is actually a print queue in CUPS or entry from mDNS. Print queue can be removed. 7. If Joe removes the printer from system settings, what will happen then? Is a reboot necessary? Will the printer magically appear there by some autodiscovery? Or is it necessary to manually add the printer, but no driver selection is needed? Alternatively, is it possible that the printer will only appear in print dialogs (from different apps), but it will not be listed in system settings? Reboot is not necessary, dialogs capable of using temporary queues (GTK and Libreoffice) will pick up the queue when you open a print dialog - system settings will show an entry based on mDNS communication, which is a ghost printer now to tell users there is actually a printer you don't need to install one - I have reported a bug to gnome-control-center for better handling this, but seems stale https://bugzilla.redhat.com/show_bug.cgi?id=1765328 . Manual print queue/printer installation shouldn't be needed, but in case it is there is a manual in the original email. 8. Is it necessary that Joe also removes the real driver from the system (like hplip), or will the action described above be sufficient? Driver removal is not needed - remov
Re: Dropping wine from ARM
On 3/31/22 04:56, Michael Cronenworth wrote: On 3/30/22 11:04 PM, Tom Stellard wrote: $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed This path is the Fedora MinGW path: /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v Try using -target x86_64-w64-mingw32 to match gcc. Doesn't help. You need to have the mingw64-gcc package installed. With that installed, I get: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/x86_64-w64-mingw32/sys-root/mingw/include /usr/include -Tom $ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list. The "/usr/include" path is a terrible choice. Time to open a bug report? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Retiring python-typer-cli due to lack of upstream support
This is just a heads-up that I am retiring python-typer-cli in F37/Rawhide due to an ongoing lack of upstream support. It is a leaf package. Important functionality has been patched out downstream[1] for about six months due to incompatibility with click version 8.x and typer version 0.4.0 (the latter by the same author as typer-cli). The required fix is nontrivial, and there is no sign of progress[2]. This has been the case through the entire F35 lifecycle, and I wouldn’t expect the package to be adequately maintained even if upstream does comes through with a patch at some point. Still, I will maintain the packages in F34–F36 until those releases’ end-of-life dates, and I’ll also keep maintaining the related python-typer package, which has seen a much more adequate amount of upstream attention in the past year. – Ben [1] https://bugzilla.redhat.com/show_bug.cgi?id=121 [2] https://github.com/tiangolo/typer-cli/issues/50 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
On Thu, Mar 31 2022 at 02:19:35 PM +0200, Kamil Paral wrote: 10. Can it happen that the IPP-over-USB approach offers less printing options than its real driver counterpart? E.g. paper types, color adjustments, etc. With hplip my printer had three color mode options: color, high-quality grayscale (using color), or black-only grayscale (what I normally used). With ipp-usb, my printer has six options: color, grayscale, deep gray, device gray, device RGB, and deep color. I have no idea what the last four of these mean. I also don't know whether the grayscale setting corresponds to high-quality grayscale or black-only grayscale. Not sure how to avoid using color ink when I only need black. So technically this is *more* printing options, but it sure feels like less, since I don't see the black-only option there anymore. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Poco FTBFS fix and soname bump
Poco upstream finally committed OpenSSL 3 in the next release branch. And Carl George helped to finish rawhide/f36 builds with a snapshot source. There is also a soname bump. Poco bumps soname at every release. After all, nothing else in Fedora depends on Poco. -robin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Dropping wine from ARM
On 3/31/22 7:43 AM, Mamoru TASAKA wrote: Actually it seems --target=foo, not -target foo Both argument types work. I had just ignored the "ignoring..." text. I'll have to use the bundled libs on only ARM arches. We don't have MinGW for ARM in Fedora. I think this will get us a working build for x86 and ARM arches. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
Hi,
On Wed, 2022-03-30 at 15:55 +0200, Zdenek Dohnal wrote:
> On 3/30/22 03:26, Michael Catanzaro wrote:
> > (removing us...@lists.fedoraproject.org)...
> >
> > On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal
> > wrote:
> > > Unfortunately there is no clean upgrade path to solve the migration
> > > automatically because of unrealistic requirements such as:
> > >
> > > - the USB device would have needed to be plugged in and turned on
> > > during the update
> > > - %post scriptlets don't work the same way on immutable Fedoras as
> > > on Fedora Linux, and other upgrade possibilities such as Leapp don't
> > > support Fedora upgrades AFAIK,
> > > the fix has to be done manually.
> > >
> > Hi Zdenek,
> >
> > First, thanks for your work on preparing Fedora for CUPS 3.0 and
> > driverless printing, and for helping me with the printer and scanner
> > bug reports I reported after I discovered this broke my printer after
> > upgrading to F36:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2066528
> > https://bugzilla.redhat.com/show_bug.cgi?id=2069277
> >
> > Hopefully my experience after removing my old print queue and
> > switching to the CUPS temporary queue is an anomaly. I know we don't
> > *expect* users to have this much trouble. That said, even if
> > everything goes as expected, requiring users to remove the original
> > broken print queue is unfortunate. Leaving a broken scanner device
> > around is too.
> >
> > I understand it is difficult to seamlessly upgrade users from F35 ->
> > F36 due to the intrusive nature of these changes. That said, I think
> > it's worth discussing whether a smoother upgrade is possible, because
> > otherwise I expect a large number of complaints from users. An
> > installed one-shot systemd service would avoid the need for any %post
> > scriplets, for example.
>
> That could help us on immutable systems - but I'm not sure when the
> service should run - I would expect it would run once a certain CUPS
> version is on the system, but I'm not sure how to make it run only once
> when it is installed without any %post/%triggerin in RPM. And what
> should trigger the run of the service?
>
> Maybe an idea? The service will be brought up by udev rule - if action
> 'ADD' happens during restart as well, the daemon should be loaded during
> machine restart and when the printer is turned on - it will be run only
> for IPP-over-USB device, construct the URI for the device and then try
> to find the URI among local permanent queues. WDYT?
Sounds reasonable, it probably isn't too bad to do a little bit more
work here and run a migration script every time a printer supported by
ipp-usb is plugged in.
Not sure, maybe one could do that from inside ipp-usb. Or, possibly by
adding a new (template) service that is launched by systemd to the udev
rule, e.g.
ENV{SYSTEMD_WANTS}+="ipp-usb-migrate@.service"
to the udev rule.
That way a script can be executed that receives the sysfs path of the
printer (%I argument). If that information is enough to delete the
queue from cups, then this might be a solution to the issue.
And, one can still touch a file to skip running the script the next
time the printer is discovered.
Benjamin
>
> > Alternatively, could we find a way to disable the classic drivers if
> > the printer supports ipp-usb?
>
> Hmm... what I can think of we could come up with deny lists for classic
> driver projects (hplip, gutenprint, sane-backends), so users could
> define idVendor and idProduct and reject the device in the classic
> driver. However this would fit better the scanning stack, since there is
> automatic device discovery for classic drivers.
>
> For printers permanent queue installation with a classic driver always
> requires user intervention - IMO we should not block users which
> explicitly want to install print queue with classic driver.
>
> >
> > > - the USB device would have needed to be plugged in and turned on
> > during the update
> >
> > I understand the problem is you don't know whether the printer
> > supports ipp-usb unless it's on, right? Therefore, a one-time upgrade
> > script has no way to know whether the print queue should be deleted or
> > not?
> Exactly.
> >
> > Perhaps it would be possible to delete the print queue that uses the
> > traditional driver whenever support for ipp-usb is detected?
> Yes, that could be possible, but it will work only if the device is
> turned on when the service is started.
> > I don't know enough about printing to say whether that is a reasonable
> > suggestion or a ridiculous one. Just brainstorming.
>
> No problem, it helps me to think about the problem from another angle.
>
> >
> > Michael
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/
Re: Dropping wine from ARM
Michael Cronenworth wrote on 2022/03/31 20:56: On 3/30/22 11:04 PM, Tom Stellard wrote: $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed This path is the Fedora MinGW path: /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v Try using -target x86_64-w64-mingw32 to match gcc. Doesn't help. $ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list. The "/usr/include" path is a terrible choice. Time to open a bug report? Actually it seems --target=foo, not -target foo $ echo | clang --sysroot=/usr --target=x86_64-w64-mingw32 -v -E - clang version 13.0.1 (Fedora 13.0.1-1.fc36) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /bin (in-process) clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-redhat-linux-gnu ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/mingw/include" ignoring nonexistent directory "/usr/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/include End of search list. # 1 "" # 1 "" 1 # 1 "" 3 # 361 "" 3 # 1 "" 1 # 1 "" 2 # 1 "" 2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed
Hi Zdenek, a QA person here. This sounds like it's going to be a major headache for us (and our users), I hope I'm wrong. I initially skipped your message, because it was too technical (seemed targeted at system admins, not regular users) and I don't know half of the printer-related abbreviations and terms. I guess my blissful ignorance ends :-) I very much like how Chris summarized the problem in a more user-friendly language in test list [1]: > The very rudimentary summary is: > 1. When upgrading (does not apply to clean installs); > 2. with a printer that supports ipp-usb (a.k.a. driverless printing); > 3. using the native driver (which can be a cups filter, free or nonfree) > Printing breaks. > I believe this is something that was missing from your announcement. I tried to create a Common Issues entry for our users here: https://ask.fedoraproject.org/t/common-issues/20975 Please help me finish it by directly editing or suggesting additions and fixes in comments. That text should be readable and actionable by an average Joe, deep technical details can be linked. This is all just printer-related, scanners didn't fit into my brain for the moment, they'll get a separate treatment. This looks like a major change, I wonder why it wasn't included in F36 ChangeSet [2]. I think we should consider adding it there, even though it's way past the deadline. It would make the change more visible/searchable and also make the description and workarounds more accessible. Now, I have a load of questions: 1. Is Chris' summary above correct? 2. Does this affect only USB printers, and no network printers? 3. Can you estimate what portion of our user base (who own printers) is going to be affected by this? How common are printers supporting IPP over USB? 4. If the printer doesn't support IPP over USB, what will happen? Will the printer continue to work as usual, and the ipp-usb package will not interfere? 5. How can an average Joe tell whether he's using a classic driver (which is incompatible with ipp-usb)? 6. When you talk about 'removing the old print queue', is it the same as removing the printer from system settings (e.g. gnome-control-center)? 7. If Joe removes the printer from system settings, what will happen then? Is a reboot necessary? Will the printer magically appear there by some autodiscovery? Or is it necessary to manually add the printer, but no driver selection is needed? Alternatively, is it possible that the printer will only appear in print dialogs (from different apps), but it will not be listed in system settings? 8. Is it necessary that Joe also removes the real driver from the system (like hplip), or will the action described above be sufficient? 9. I read that Firefox might not work with the new setup [3][4]. I'm *very* concerned about that. Can you elaborate? When exactly will printing from Firefox not work? For all IPP over USB printers handled through ipp-usb? 10. Can it happen that the IPP-over-USB approach offers less printing options than its real driver counterpart? E.g. paper types, color adjustments, etc. What if the user wants to use the real driver instead, for these reasons, what is the recommended approach? (Ideally for an average Joe, if possible, i.e. no lpadmin commands). 11. What can we do better during the upgrade? I read we can't fix this perfectly. But even if the package removed all "print queues" during installation, it would go from "My printer doesn't print and I have idea why, I'm so angry" situation into "My printer disappeared, I had to add it again, I'm so angry" situation (in case it wasn't IPP over USB, in which case it would be autodetected and immediately re-appear). That seems like an obvious lesser evil. In the first case, you have no idea what to do, except for magically stumbling on our documentation. In the second case, it's obvious that you need to add the printer again, if it is not there, and so it allows users to fix the situation themselves pretty naturally. I understand this won't work on rpm-ostree based systems, but it's still a huge leap forward. Am I misunderstanding something? 12. This can still be reverted, right? It's enough to stop recommending ipp-usb in F36, correct? Or is there a technical reason why that mustn't be changed? I simply wonder whether we still have a way out if this is deemed too catastrophic without some automatic workarounds like the one proposed above. Thanks! Kamil [1] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/YL3XCMM7O27MEG6B2K54L2YSP2OJ7ZJ4/ [2] https://fedoraproject.org/wiki/Releases/36/ChangeSet [3] https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c4 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1983403 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: ht
Re: Dropping wine from ARM
On 3/30/22 11:04 PM, Tom Stellard wrote: $ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed This path is the Fedora MinGW path: /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. Clang apparently has no idea where MinGW files in Fedora live. :( $ clang -c test.c -target x86_64-windows -v Try using -target x86_64-w64-mingw32 to match gcc. Doesn't help. $ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list. The "/usr/include" path is a terrible choice. Time to open a bug report? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Koji down?
I submitted some builds yesterday and didn’t get any emails, and at least as of 6:18 CDT every link I click on the main webpage replies with “server is offline”. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 - Errors/Warnings with `dnf update`
On 3/31/22 02:35, Carmelo Sarta wrote: Hello there! I've never seen this error before `error: Plugin selinux: hook fsm_file_prepare failed` but I would try `dnf reinstall container-selinux` and maybe `dnf reinstall podman` There seems to be an error appening when people are installing container-selinux, that I have not pinned down. It does not happen on my system. Hope this helps On Thu, Mar 31, 2022 at 4:27 AM Nathanael D. Noblet wrote: Hello, Just wondering if this is a bug and what to report against. I upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update` and saw some odd output. Not sure if its a bug with dnf or selinux or the packages being installed. Let me know if its a known issue or if I need to file a bug and where. Running transaction Preparing : 1/1 Upgrading : crun-1.4.4-1.fc36.x86_64 1/16 error: lsetfilecon: (/usr/bin/crun;62451078, system_u:object_r:container_runtime_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package crun-1.4.4-1.fc36.x86_64 Upgrading : containers-common-4:1-53.fc36.noarch 2/16 error: unpacking of archive failed on file /usr/bin/crun;62451078: cpio: (error 0x2) error: crun-1.4.4-1.fc36.x86_64: install failed error: lsetfilecon: (/var/lib/containers/sigstore, system_u:object_r:container_var_lib_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package containers-common-4:1-53.fc36.noarch Upgrading : conmon-2:2.1.0-2.fc36.x86_64 3/16 error: unpacking of archive failed on file /var/lib/containers/sigstore: cpio: (error 0x2) error: containers-common-4:1-53.fc36.noarch: install failed error: lsetfilecon: (/usr/bin/conmon;62451078, system_u:object_r:conmon_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package conmon-2:2.1.0-2.fc36.x86_64 Upgrading : podman-3:4.0.2-1.fc36.x86_64 4/16 error: unpacking of archive failed on file /usr/bin/conmon;62451078: cpio: (error 0x2) error: conmon-2:2.1.0-2.fc36.x86_64: install failed error: lsetfilecon: (/usr/bin/podman;62451078, system_u:object_r:container_runtime_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package podman-3:4.0.2-1.fc36.x86_64 Upgrading : runc-2:1.1.1-1.fc36.x86_64 5/16 error: unpacking of archive failed on file /usr/bin/podman;62451078: cpio: (error 0x2) error: podman-3:4.0.2-1.fc36.x86_64: install failed error: lsetfilecon: (/usr/bin/runc;62451078, system_u:object_r:container_runtime_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package runc-2:1.1.1-1.fc36.x86_64 Upgrading : swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64 6/16 error: unpacking of archive failed on file /usr/bin/runc;62451078: cpio: (error 0x2) error: runc-2:1.1.1-1.fc36.x86_64: install failed error: lsetfilecon: (/usr/bin/swtpm;62451078, system_u:object_r:swtpm_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package swtpm-0.7.2- 1.20220307git21c90c1.fc36.x86_64 Upgrading : snapd-2.54.4-1.fc36.x86_64 7/16 error: unpacking of archive failed on file /usr/bin/swtpm;62451078: cpio: (error 0x2) error: swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64: install failed error: lsetfilecon: (/etc/sysconfig/snapd;62451078, system_u:object_r:snappy_config_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package snapd-2.54.4-1.fc36.x86_64 Running scriptlet: flatpak-1.12.7-1.fc36.x86_64 8/16 error: unpacking of archive failed on file /etc/sysconfig/snapd;62451078: cpio: (error 0x2) error: snapd-2.54.4-1.fc36.x86_64: install failed Upgrading : flatpak-1.12.7-1.fc36.x86_64 8/16 error: lsetfilecon: (/usr/libexec/flatpak-system-helper;62451078, system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument error: Plugin selinux: hook fsm_file_prepare failed Error unpacking rpm package flatpak-1.12.7-1.fc36.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- and thanks for all the fish, Carmel
Re: F36 - Errors/Warnings with `dnf update`
On Thu, Mar 31, 2022 12:16:43 +0300, Otto Urpelainen wrote: > Otto Urpelainen kirjoitti 31.3.2022 klo 11.22: > > Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26: > > > Hello, > > > > > > Just wondering if this is a bug and what to report against. I > > > upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update` > > > and saw some odd output. Not sure if its a bug with dnf or selinux or > > > the packages being installed. Let me know if its a known issue or if I > > > need to file a bug and where. > > > > There is a Bugzilla entry for this [1]. > > If you are like me and try to recover by doing selinux relabeling, > > you can end up in a situation where login is not possible anymore [2]. > > > > This seems to be affecting multiple users, > > so perhaps this is worth reporting as a Common Bug [3]. > > I will do so a bit later, unless somebody beats me to it. > > Ok, I tried, but ask.fedoraproject.org gives me a permission error > when I click Create Topic. > (In Finnish, even though I changed the UI language to English > so that I could paste the error here.) > After running into multiple issues with discussion.fedoraproject.org, > I am weary of Discourse. That's odd. Can you please try in a clean private or incognito window where you're not using any browser extensions/add-ons that may be blocking various bits? -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220331.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220330.0): ID: 1204329 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1204329 ID: 1204338 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1204338 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 - Errors/Warnings with `dnf update`
Otto Urpelainen kirjoitti 31.3.2022 klo 11.22: Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26: Hello, Just wondering if this is a bug and what to report against. I upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update` and saw some odd output. Not sure if its a bug with dnf or selinux or the packages being installed. Let me know if its a known issue or if I need to file a bug and where. There is a Bugzilla entry for this [1]. If you are like me and try to recover by doing selinux relabeling, you can end up in a situation where login is not possible anymore [2]. This seems to be affecting multiple users, so perhaps this is worth reporting as a Common Bug [3]. I will do so a bit later, unless somebody beats me to it. Ok, I tried, but ask.fedoraproject.org gives me a permission error when I click Create Topic. (In Finnish, even though I changed the UI language to English so that I could paste the error here.) After running into multiple issues with discussion.fedoraproject.org, I am weary of Discourse. So I will not propose a common bug about this. Hopefully somebody else does. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220331.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220330.0): ID: 1204312 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1204312 ID: 1204321 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1204321 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] [Test Day] Fedora Wallpaper Test Day is TODAY!
Hey All, The Fedora Design team is hosting a test day today. We will be testing the Light/Dark theme and Wallpaper for Fedora Linux 36. If you have some cycles, these resources[0] will give you some context of how to test and submit results[1] For a little bit of history about the test day can be found here [2] [0] http://fedoraproject.org/wiki/Test_Day:2022_03_31_F36_Wallpapers [1] https://testdays.fedoraproject.org/events/130 [2] https://discussion.fedoraproject.org/t/help-us-test-fedora-linux-36-beta-wallpaper/37890 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 - Errors/Warnings with `dnf update`
Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26: Hello, Just wondering if this is a bug and what to report against. I upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update` and saw some odd output. Not sure if its a bug with dnf or selinux or the packages being installed. Let me know if its a known issue or if I need to file a bug and where. There is a Bugzilla entry for this [1]. If you are like me and try to recover by doing selinux relabeling, you can end up in a situation where login is not possible anymore [2]. This seems to be affecting multiple users, so perhaps this is worth reporting as a Common Bug [3]. I will do so a bit later, unless somebody beats me to it. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2056303 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2069102 [3]: https://ask.fedoraproject.org/tags/c/common-issues/141/all/f36 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
