Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
Björn Persson wrote on Thu, Apr 22, 2021 at 04:26:22PM +0200: > It is however a good illustration of how a network problem can destroy > the user experience. Five minutes is a long wait. I'm glad that we now > have this information. This is an old post but I just used debuginfod for the first time (on debian actually (debuginfod 0.183-1, gdb 10.1-1.7) in case things have changed - forgive me and please correct me if anything I've said is significantly better on current version on rawhide), so figured I'd share... - My usecase admitedly wasn't a very nice one (graphical application, info dll says I have 265 linked libraries...), but it felt very slow. Looking at iftop the server was reliably sending me things at 1mbps which isn't great but with the amount of data involved being slow can't be helped, I guess. What makes it really bad is that such applications link extra libraries at runtime, so when I thought it was finally done and it got into the breakpoints I had set, continuing a bit just ran into another wall of downloads, but this also isn't debuginfod's wrongdoings. Most of these libraries are nothing I care about. I understand gdb tries to find debug infos for libraries it encounters when these are loaded into the program's address space, but could it be possible to not download anything at this point and only download debuginfos when they are really used (the first time an address in such libraries appear in a backtrace to get line number / local variables / etc) ? I realize this isn't obvious, but it'd make my usage much more appreciable -- downloading 4 or maybe 5 libraries for the area I'm debugging in that monster instead of the full 265 of them. - None of ^C, ^\, ^Z work, when I grew tired of waiting I had to switch to another terminal and kill the gdb process. It'd be great if e.g. ^C could skip the current download (or future downloads too?) and continue debugging, or enter the (gdb) prompt like it normally does -- iirc it went into that prompt after the download? or batch of downloads I'm not sure, I just remember it took too long. - unsetting DEBUGINFOD_URLS completely disables the debuginfod client, it would have been nice to use the data available in the client cache anyway. Ultimately I set it to localhost so debuginfod would give up immediately on new requests but still use previously downloaded data. Perhaps there could be an "offline mode" of sorts? I also agree with the security concerns given, debuginfos are usually seen as trusted data and I wouldn't be surprised new bugs get found in their parsing which could compromise developers since the server can send whatever it wants to send. I'm not going to be very helpful on that respect though as I don't have any bright idea (distributing just checksums of all debug files in the main package, so when debuginfod downloads something it can compare with the checksum that was installed and verified locally by signed rpm? Didn't reread the whole thread but I think something similar was suggested), but that topic didn't get much discussion and it sounds important to me. All in all I think it's a very valuable tool, but it would be really great if we could minimize the amount of data actually downloaded, and establish some chain of trust. Thanks, -- Dominique ___ 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
Question related to systemd-oomd
Hi, One question about this wiki entry: "Note that the following memory pressure example requires the changes listed in “Scope” to work as expected, as systemd-oomd shipped with systemd v247 does not support changing the time window for memory pressure." (It refers to this example: systemctl edit user@.service [Service] ManagedOOMMemoryPressure=kill ManagedOOMMemoryPressureLimit=10% # save and exit systemd-run --user tail /dev/zero # will lead to a lot of reclaim and then OOM if not killed) What does exactly mean "requires the changes listed in "Scope"? Could you clarify and to elaborate more a bit? Thanks in advance! -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ 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: When is pappl going to be good enough to replace cups?
On Tue, May 25, 2021 at 04:01:13AM +0200, Martin Kolman wrote: > > (And incidently, I do have a duplexing printer, a decade-plus-old > > Brother HL-5340D. Along with 31 others, though only 26 are plugged > > in > > at the moment. Isn't driver development/regression testing fun?) > Wow! :D In any case, just let me say thanks for all your work so far, > that's quite some determination! (Not to mention space, paper and power > budget. :) ) As a former colleague of mine put it, engineering is a highly productive behavioral disorder. (To be fair, 12 of those 32 were sent to me by other folks) Also, only four of those 32 printers are theoretically supported [1] by one of those newfangled printer application thingeys [2]. The rest depend on Gutenprint. ...Suffice it to say I have a vested interest in the legacy cups driver flow continuing to function until the as-of-yet-theoretical Gutenprint Printer Application is usable. [1] I haven't actually _tested_ them this way yet. [2] two by lprint, one by ipp-usb, and one by ps-printer-app. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: >> I do not see how that is the common use case. Why would I want to print >> from my telephone? I do not even normally print from my notebook! > > I don't think it's controversial to say that one needs to print from > whatever computing devices one uses. If I am sitting next to my printer, I have a desktop computer in front of me from which I can issue the print job, so why would I want to do it from a notebook or smartphone? > X11 forwarding through SSH while running Wayland seems to work just fine > for me. *shrug* You're actually using a mix of X11 and Wayland then (with all the forwarded windows being X11/XWayland windows) though. >> More often than not, the "PDF-based print flow" just means that something >> client-side converts the PostScript to PDF before sending it to the shiny >> new "PDF-based print flow", only to have something in the driver filters >> convert the PDF back to PostScript before doing anything else. > > This hasn't been the case since Fedora 19 (Spring 2013), which, as part > of CUPS 1.6, switched to a PDF-native flow. Postscript is only used on > the edges, ie if the printer requires it or the application supplies it. But that is exactly my point: if the printer requires PostScript and the application supplies PostScript, but the queue expects PDF documents, this results in converting back and forth from PostScript to PDF and back to PostScript. Kevin Kofler ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 08:52:13PM -0400, PGNet Dev wrote: > Endless theoretical discussions ... Interesting, but _is_ there > real-world, end-user doc available for installing and using papp-et-al > on Fedora, today? A "do this now" for end users? TBH, I'm unclear > (and no, I haven't gone digging ...) The short answer -- no, there isn't anything like thet yet. For PAPPL specifically, there won't ever be, because it is essentially a library/framework to be used by printer-specific stuff. > Admittedly, PS drivers are buggy-to-useless, and NONE of the "toner > level" reporting seems attached to reality in any way. For these old Postscript-capable HPs, there's the new 'ps-printer-app' (not yet packaged in Fedora) which will allow you to supply the PPD and everything should JustWork(tm). For native PCL, there's currently the 'hp-printer-app', but IIUC it's meant more as a demonstration of PAPPL than anything comprehensive. When Gutenprint is finally mashed together with PAPPL, it'll bring along comprehensive PCL4/5/5c support. There are probably plans afoot to do the same with hplip, which will also result in comprehensive PCL support. > If any of that^^ ceases to function, then that'll be a problem. Absolutely! I don't believe anyone is seriously advocating for retiring the status-quo "Legacy CUPS" driver model until (at minimum) the major printer driver families have been PAPPLized. > OTOH, If papp-future _at_the_very_least_ maintains that^^ > functionality through legacy wrappers, then I have zero concerns. I believe this exact scenario is planned as the final catch-all option. Just to be clear, when this Printer Application-only vision was first announced I was probably the most vocal skeptic in the room. Since then, the Openprinting folks have made consistent progress, addressing concerns, and filling in the missing pieces. They're working very, very hard to ensure printing continues to work... at least as well as it ever did, heh. (I've beeen around long enough to remember similar arguments being made about a new shiny upstart called CUPS over lpr[ng] and printcap. And look where we are today...) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: When is pappl going to be good enough to replace cups?
On Mon, 2021-05-24 at 11:46 -0400, Solomon Peachy wrote: > On Mon, May 24, 2021 at 04:58:18PM +0200, Kevin Kofler via devel > wrote: > > Looks like you do not have a duplex printer. (Hint: Printing duplex > > is not > > always what you want. But never printing duplex makes even less > > sense. > > There's also short side duplex that makes sense in some cases for > > landscape > > printing.) > > Eh, duplexing is another basic document property, like paper size and > orientation. Granted, it's relatively likely to be overridden at > the time of printing... > > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, > and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint shines, > even > in comparison to official manufacturer drivers on $ProprietaryOS. > > (And incidently, I do have a duplexing printer, a decade-plus-old > Brother HL-5340D. Along with 31 others, though only 26 are plugged > in > at the moment. Isn't driver development/regression testing fun?) Wow! :D In any case, just let me say thanks for all your work so far, that's quite some determination! (Not to mention space, paper and power budget. :) ) > > - Solomon > ___ > 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 ___ 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
[Bug 1950383] please build perl-Archive-Extract for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1950383 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2021-e9b863f5ec has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e9b863f5ec See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Endless theoretical discussions ... Interesting, but _is_ there real-world, end-user doc available for installing and using papp-et-al on Fedora, today? A "do this now" for end users? TBH, I'm unclear (and no, I haven't gone digging ...) Here, I've got hundreds of networked printers. _Many_ of them old warhorses. E.g., ~ 50 HP LaserJet 4050n. Slow, but incredibly reliable. Unlike the modern 'options' from HP, made cheaply overseas, prone to breakage, and locked down with print-cartridge DRM, these 4050s have outlasted virtually every desktop & server we have, and quite a number of staff as well, and 3rd party parts & cartridges abound. CUPS 2.3.3op2 runs on virtually every Fedora desktop here, in addition to quite a few of the servers. For the 4050s, the drivers are all 'HP LaserJet 4050 Series pcl3, hpcups 3.19.6 (color, 2-sided printing)', and the connections are "socket://static.i.p.address". The PPDs are older than dirt, *PPD-Adobe: "4.3" * PPD file for HP LaserJet 4050 Series with CUPS. * Created by the CUPS PPD Compiler CUPS v1.5.0. *% (c) 2008 Copyright HP Development Company, LP *FormatVersion: "4.3" *FileVersion: "3.19.6" ... and work flawlessly. Admittedly, PS drivers are buggy-to-useless, and NONE of the "toner level" reporting seems attached to reality in any way. Neither, for me, has been a concern. Same holds generally true for all other networked printers, with the exception of some of high-volume/color machines that bundle their own raster/spool/networking/etc. If any of that^^ ceases to function, then that'll be a problem. Personally, I'm not the slightest bit interesting in wasting time/money replacing what work s well *AND* losing capbility for the sake of the next bringh-n-shiny OTOH, If papp-future _at_the_very_least_ maintains that^^ functionality through legacy wrappers, then I have zero concerns. Additional features/functionality are welcome gravy. ___ 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: When is pappl going to be good enough to replace cups?
On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: > All this is of no use if the printer does not actually implement that > though. Of course. That's where this whole "printer application" thingey comes in. > I do not see how that is the common use case. Why would I want to print from > my telephone? I do not even normally print from my notebook! I don't think it's controversial to say that one needs to print from whatever computing devices one uses. > Well, if I want to configure the printer, I need to know what to point my > browser at. But sure, if a dialog gives me a link, that is a way. Though it > means yet another layer of indirection (bringing up the dialog first, only > to get redirected to a web interface). Running 'ippfind' will show you the list of all IPP-capable printers that are advertising themselves through mDNS, and the URI they can be reached at. > My desktop and my notebook, i.e., the devices I actually SSH to at times > (from each other, usually), do have hardcoded IPs, yes. (And I also use X11 > forwarding when I SSH, so Wayland is a non-starter.) X11 forwarding through SSH while running Wayland seems to work just fine for me. *shrug* > More often than not, the "PDF-based print flow" just means that something > client-side converts the PostScript to PDF before sending it to the shiny > new "PDF-based print flow", only to have something in the driver filters > convert the PDF back to PostScript before doing anything else. This hasn't been the case since Fedora 19 (Spring 2013), which, as part of CUPS 1.6, switched to a PDF-native flow. Postscript is only used on the edges, ie if the printer requires it or the application supplies it. pdftopdf transforms proved to be a lot more robust than pstops due to PDF's semantics being far better defined. (Incidently, Fedora 19 is also when the switch to using mDNS for printer discovery happened..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:41:07PM +0200, Kevin Kofler via devel wrote: >> I have never connected directly to a remote printer. > > It works quite well in Fedora these days. Well, the printers I had when I had a use for remote printing did not support it, sharing them through a computer was the only way. My current printer does support "wireless printing", but AFAIK there is no way to get it to connect to a secure WPA2-protected WLAN, it can only act as its own insecure hotspot. And I basically only ever print to it from one single computer (a non-moving desktop tower – yes, I still own such a thing), so I do not have a need to use it remotely to begin with. USB is the simplest solution. > Stop thinking about this in terms of AirPrint -- that's a very cut-down > proprietary variation of IPP. What we're talking about here is vastly > more capable. > > There's no reason why the printer can't represent its configuration > settings via IPP attributes. There's no reason why standard OS print > dialogs can't represent them to the user. All this is of no use if the printer does not actually implement that though. > You're correct, just not for the reasons you think. These days, > "User-friendly" means a printer-manufacturer-supplied standalone > printing app on their smartphone. I do not see how that is the common use case. Why would I want to print from my telephone? I do not even normally print from my notebook! That said, the smartphone hype has completely missed me so far. I still use a dumb cellphone. I recently got a PinePhone, and I'm only slowly getting used to it. (It does not even have a SIM card inserted yet because I have not picked a suitable contract for a smartphone yet.) Android and iOS are proprietary platforms that I just do not want. (I know AOSP is FOSS, but Android is more than just AOSP in practice.) >> So what is the port number then, or if it is dynamic, how do I find it >> out? > > Who cares what port (or even IP address) it's using? If the print > dialog knows the printer is there, it knows how to talk to it, including > its web interface. It's just another network printer, after all. Well, if I want to configure the printer, I need to know what to point my browser at. But sure, if a dialog gives me a link, that is a way. Though it means yet another layer of indirection (bringing up the dialog first, only to get redirected to a web interface). > (There's no inherent reason why wou wouldn't be able to assign fixed > ports, though that might get messy when more than one printer is > involved. Do you also hardcode IP addresses for every system on your > LAN?) My desktop and my notebook, i.e., the devices I actually SSH to at times (from each other, usually), do have hardcoded IPs, yes. (And I also use X11 forwarding when I SSH, so Wayland is a non-starter.) > We have a native PDF-based print flow, enabling far more consistent > rendering behavior than pure postscript, as well as a much richer set of > capabilities. More often than not, the "PDF-based print flow" just means that something client-side converts the PostScript to PDF before sending it to the shiny new "PDF-based print flow", only to have something in the driver filters convert the PDF back to PostScript before doing anything else. In the worst case, those conversions are done using ps2pdf and/or pdf2ps without any options, a process which ends up doing things such as lossy image recompression. (Those tools do not have roundtrip-safe defaults.) Kevin Kofler ___ 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
[Bug 1964181] New: perl-Convert-ASN1-0.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1964181 Bug ID: 1964181 Summary: perl-Convert-ASN1-0.29 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Convert-ASN1 Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.29 Current version/release in rawhide: 0.27-22.fc34 URL: http://search.cpan.org/dist/Convert-ASN1/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2722/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 10:41:07PM +0200, Kevin Kofler via devel wrote: > Except if the non-local printer was actually shared through another computer > on which it was attached, in which case you needed a printer driver either > on the computer sharing the printer (sharing it as a PostScript or PDF > printer) or on the computer actually doing the printing (if it was shared as > a raw queue), or even on both. All non-local printing I have ever done was > done like that. Sure, the system with the printer physically attached needs a "driver" of some sort. > I have never connected directly to a remote printer. It works quite well in Fedora these days. > And most of my printing has always been directly connected over parallel > port or USB. My current printer is connected over USB. I have a headless server with all of my printers attached (via USB). > Well, if the printer requires a printer application because it does not > support AirPrint, then how would the printer supply such a configuration > interface? The printer application will have to provide it! As opposed to "the printer driver has to provide it" or "the operating system has to provide it"? (Or "the individual application provides it" as is the case for Libreoffice, modern Firefox, and others?) Stop thinking about this in terms of AirPrint -- that's a very cut-down proprietary variation of IPP. What we're talking about here is vastly more capable. There's no reason why the printer can't represent its configuration settings via IPP attributes. There's no reason why standard OS print dialogs can't represent them to the user. Incidently, it's not just about the needs of containerization. IPP is vastly more expressive than PPDs, and is baked around the notion of bi-directional communication with the printer. Restricting selectable options based on loaded media or printer state? No problem! Reporting consumables? No problem! Performing maintainence tasks? No problem! (Note what while this is possible with CUPS, in practice very few CUPS drivers have actually implemented any of it, and I have yet to see a UI that properly reports/prevents illegal option combinations, a PPD feature that has been around since 1989) > And I have already explained why a web interface is not a user-friendly > configuration interface. You're correct, just not for the reasons you think. These days, "User-friendly" means a printer-manufacturer-supplied standalone printing app on their smartphone. > So what is the port number then, or if it is dynamic, how do I find it out? Who cares what port (or even IP address) it's using? If the print dialog knows the printer is there, it knows how to talk to it, including its web interface. It's just another network printer, after all. (There's no inherent reason why wou wouldn't be able to assign fixed ports, though that might get messy when more than one printer is involved. Do you also hardcode IP addresses for every system on your LAN?) > Dropping support for older hardware is always an unfriendly move. E.g., I am > also doing all I can to prevent requirements on newer SSE (or even AVX) > versions from creeping in. Unfriendly, sure. But indefinitely maintaining support for old stuff isn't viable either, and it's also "unfriendly" to have new features remain inaccessable because older devices don't support it. Note I say this as someone who maintains drivers for a couple of specialist printers for which new media has been unobtanium for at least five years, and whose power supplies have a tendency to spotaneously explode. > > Meanwhile. The ultimate goal has not yet been realized, but with each > > incremental milestone along the way, it's getting closer. Ironically, > > the existing Legacy CUPS + cups-filters + drivers printing flow has been > > the largest beneficiary of these improvements; I wouldn't consider that > > a failure. > > How has it benefitted? All I see is it getting labeled deprecated and > constantly threatened of removal. Modern (>2010) networked printers JustWork(tm), without need for local drivers. CUPS-shared printers JustWork(tm), also without local drivers. Folks with smartphones can print to most CUPS-attached printers, again, no drivers. We have a standard _lossless_ raster image format that all printers must accept. We have a native PDF-based print flow, enabling far more consistent rendering behavior than pure postscript, as well as a much richer set of capabilities. We have end-to-end colorspace awareness, with automatic colorspace conversion if the appropriate profiles are installed. We have sane auto-scaling/cropping modes that generally do the right thing in the face of aspect ratio mismatches. We're closer than ever to a universal printing system that is not tied to any specific OS or client, and that behaves identically no matter where or how the printer is attached. Underpinning all of this are formally
F34: AVCs on dbus socket from GNOME
Since upgrading from a fairly clean F33 (installed from scratch a few months
ago) to F34 I get regular (upon each desktop login, I believe) SELinux denials
on what appears to be a dbus socket from gnome-shell and other components:
type=AVC msg=audit(1621790705.033:963): avc: denied { write } for
pid=136319 comm="gnome-shell" name="dbus-QyPy1X95QF" dev="tmpfs" ino=368
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file permissive=0
Similar denials occur immediately following for gsd-keyboard, gsd-power,
gsd-media-keys, gsd-color and gsd-wacom, always in that order as far as I can
tell.
Is this a bug in the upgrade process? A known bug? Something misconfigured by
me? (I didn't readily find anything in Bugzilla or by searching)
I can obviously trivially fix it for myself (audit2allow says "allow xdm_t
tmp_t:sock_file write;") but if it's an SELinux policy or upgrade bug then it
should presumably be fixed.
Tim
___
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: fkinit
On Mon, 2021-05-24 at 16:36 -0400, Stephen Gallagher wrote: > On Mon, May 24, 2021 at 3:05 PM Miroslav Suchý wrote: > > > > I want to share with wider audience that with fedora-packager-0.6.0.6 > > (already in Fedora stable) you can run > > > > fkinit > > > > or > > > > fkinit -u USERNAME > > > > to obtain Fedora Kerberos ticket. > > > > > > Kudos to Stephen Gallagher and Tomas Hrcka for making this. > > > > For a little more information: The benefit of using `fkinit` over > regular `kinit` is that it will handle OTP use-cases better (without > having to follow the complicated steps at > https://fedoraproject.org/wiki/Infrastructure/Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure > > Instead, you'll be prompted to enter your password and OTP > concatenated and it will take care of the rest for you. Update https://docs.fedoraproject.org/en-US/fedora-accounts/user/#pkinit ? Any chance on getting gnome-online-accounts to handle this? -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc. ___ 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: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > The legacy CUPS *direct-attached* model simply doesn't work with > containerized/sandboxed applications that are all the vogue these days. So this is yet another functionality regression coming from that containerization nonsense! Why do we all have to pay the price for containerization even if we do not use it? > But if your printer was already non-local vs the system doing the > printing (ie on "the network" somewhere) then this whole conversation is > moot, because you haven't had to install a native driver locally for > many years. Except if the non-local printer was actually shared through another computer on which it was attached, in which case you needed a printer driver either on the computer sharing the printer (sharing it as a PostScript or PDF printer) or on the computer actually doing the printing (if it was shared as a raw queue), or even on both. All non-local printing I have ever done was done like that. I have never connected directly to a remote printer. And most of my printing has always been directly connected over parallel port or USB. My current printer is connected over USB. >> > Except for Gutenprint, I'm not aware of any printer driver provider >> > which plans to provide more specific options with a printer >> > application. >> >> Which implies that, from a user perspective, there will be a noticeable >> loss of functionality. > > How so? I mean, whether you supply the printing options from the lp > command line, the printer's web UI (this includes CUPS' webserver) or > the system printing dialog the functionality will still be there. Well, if the printer requires a printer application because it does not support AirPrint, then how would the printer supply such a configuration interface? The printer application will have to provide it! And I have already explained why a web interface is not a user-friendly configuration interface. >> A web interface requires bringing up a web browser, manually pointing it >> to http://localhost: where is a port number that has to be >> manually looked up from some manual, > > No, it's a standard property, and I'd presume a "generic IPP print > dialog" would have a big fat button that, when mashed, takes you to the > appropriate configuration interface. So what is the port number then, or if it is dynamic, how do I find it out? > Honestly? The simplest approach is to copy what every other platform out > there already does, and simply drop support for sufficiently old > hardware. Fedora routinely does this, why should printers be any > different? Dropping support for older hardware is always an unfriendly move. E.g., I am also doing all I can to prevent requirements on newer SSE (or even AVX) versions from creeping in. > Meanwhile. The ultimate goal has not yet been realized, but with each > incremental milestone along the way, it's getting closer. Ironically, > the existing Legacy CUPS + cups-filters + drivers printing flow has been > the largest beneficiary of these improvements; I wouldn't consider that > a failure. How has it benefitted? All I see is it getting labeled deprecated and constantly threatened of removal. Kevin Kofler ___ 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: fkinit
On Mon, May 24, 2021 at 3:05 PM Miroslav Suchý wrote: > > I want to share with wider audience that with fedora-packager-0.6.0.6 > (already in Fedora stable) you can run > > fkinit > > or > > fkinit -u USERNAME > > to obtain Fedora Kerberos ticket. > > > Kudos to Stephen Gallagher and Tomas Hrcka for making this. > For a little more information: The benefit of using `fkinit` over regular `kinit` is that it will handle OTP use-cases better (without having to follow the complicated steps at https://fedoraproject.org/wiki/Infrastructure/Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure Instead, you'll be prompted to enter your password and OTP concatenated and it will take care of the rest for you. ___ 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: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > CUPS discovery is designed to run on secure, private LAN, so it is > expected that you have a protection against somebody connecting to your > WIFI. That is (still) a reasonable assumption for a home WiFi WLAN on which a home printer is likely to be located. That is what WPA is for. Sure, you can connect a notebook or smartphone to untrusted public WiFi networks, but you normally do not print in such a network. Kevin Kofler ___ 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: Is really systemd-oomd enforced?
El dom, 23 may 2021 a las 13:59, Sergio Belkin ()
escribió:
> El dom, 23 may 2021 a las 13:10, Sergio Belkin ()
> escribió:
>
>>
>>
>> El dom, 23 may 2021 a las 12:58, Neal Gompa ()
>> escribió:
>>
>>> On Sun, May 23, 2021 at 11:54 AM Sergio Belkin wrote:
>>> >
>>> > Hi,
>>> > I was reading the systemd-oomd documentation and it says:
>>> > «More precisely, only cgroups with memory.oom.group set to 1 and leaf
>>> cgroup nodes are eligible candidates.»
>>> > (https://www.freedesktop.org/software/systemd/man/systemd-oomd.html)
>>> >
>>> > However I haven't found any "memory.oom.group" file set to 1:
>>> >
>>> > sudo find /sys -name "memory.oom.group" -exec grep -v '^0$' '{}' \; |
>>> wc -l
>>> > 0
>>> >
>>> > So, Should I set memory.oom.group to 1?
>>> >
>>>
>>> Do you have systemd-oomd-defaults installed? That's where the oomd
>>> configuration is stored.
>>>
>>>
>>>
>>> --
>>>
>>> Hi Neal
>>
>> rpm -qil systemd-oomd-defaults
>> Name: systemd-oomd-defaults
>> Version : 248.3
>> Release : 1.fc34
>> Architecture: x86_64
>> Install Date: jue 20 may 2021 06:06:11
>> Group : Unspecified
>> Size: 145
>> License : LGPLv2+
>> Signature : RSA/SHA256, sáb 15 may 2021 17:50:23, Key ID
>> 1161ae6945719a39
>> Source RPM : systemd-248.3-1.fc34.src.rpm
>> Build Date : sáb 15 may 2021 14:10:24
>> Build Host : buildvm-x86-09.iad2.fedoraproject.org
>> Packager: Fedora Project
>> Vendor : Fedora Project
>> URL : https://www.freedesktop.org/wiki/Software/systemd
>> Bug URL : https://bugz.fedoraproject.org/systemd
>> Summary : Configuration files for systemd-oomd
>> Description :
>> A set of drop-in files for systemd units to enable action from
>> systemd-oomd,
>> a userspace out-of-memory (OOM) killer.
>> /usr/lib/systemd/oomd.conf.d
>> /usr/lib/systemd/oomd.conf.d/10-oomd-defaults.conf
>> /usr/lib/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf
>> /usr/lib/systemd/system/user@
>> .service.d/10-oomd-user-service-defaults.conf
>>
>> And:
>>
>> cat /usr/lib/systemd/oomd.conf.d/10-oomd-defaults.conf
>> /usr/lib/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf
>> /usr/lib/systemd/system/user@
>> .service.d/10-oomd-user-service-defaults.conf
>> [OOM]
>> DefaultMemoryPressureDurationSec=20s
>> [Slice]
>> ManagedOOMSwap=kill
>> [Service]
>> ManagedOOMMemoryPressure=kill
>> ManagedOOMMemoryPressureLimit=50%
>>
>> Just in case:
>> systemd-analyze cat-config /etc/systemd/oomd.conf | egrep -v '^$|#'
>> [OOM]
>> [OOM]
>> DefaultMemoryPressureDurationSec=20s
>>
>
>> Still it's not clear for me if systemd-oomd is really enforced :)
>>
>> --
>> --
>> Sergio Belkin
>> LPIC-2 Certified - http://www.lpi.org
>>
>
> I was looking at https://testdays.fedoraproject.org/events/105
>
> Swap Based Killing worked for but "Memory Pressure Based Killing" didn't
> (stress-ng is not killed by systemd-oomd as is in
> https://fedoraproject.org/wiki/QA:Testcase_Memory_Pressure_Based_Killing#How_to_test
> ):
>
> may 23 13:46:34 munster.belkin.home kernel: Timer invoked oom-killer:
> gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
>
> This is oomctl output:
> Dry Run: no
> Swap Used Limit: 90.00%
> Default Memory Pressure Limit: 60.00%
> Default Memory Pressure Duration: 20s
> System Context:
> Swap: Used: 6.0G Total: 7.9G
> Swap Monitored CGroups:
> Memory Pressure Monitored CGroups:
> Path: /user.slice/user-1000.slice/user@1000.service
> Memory Pressure Limit: 50.00%
> Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 1.83 Total: 51s
> Current Memory Usage: 5.9G
> Memory Min: 0B
>
> Any ideas?
>
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
>
Well I've reported the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1964153
HTH
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
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: Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
On Fri, May 21, 2021 at 8:49 PM Reon Beon via devel wrote: > > Any update? As others have said, it takes a reasonable amount of work. Currently kmod in Rawhide and F34 support zstd, but not F33. Even if this support was everywhere, it requires a number of changes, and testing to verify that the changes a) work, and b) actually improve things in a meaningful way. You are not going to see this roll out this month, or even with the 5.13 rebase. But it is being considered. ___ 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
MLT-7 in with soname bump
Hi,
MLT-7 change to cmake IIRC , and move all files to a different
directory , we are trying keep all in same place [1] since, I think we
don't need two versions of MLT (6 and 7)
We need to rebuild synfig and synfigstudio [2].
[1]
https://src.fedoraproject.org/rpms/mlt/pull-request/3#
[2]
dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
"libmlt*" --qf "%{repoid} %{sourcerpm}" -q
rawhide synfig-1.4.0-1.fc35.src.rpm
rawhide synfigstudio-1.4.0-1.fc35.src.rpm
rawhide webvfx-1.2.0-4.fc34.src.rpm
--
Sérgio M. B.
___
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
fkinit
I want to share with wider audience that with fedora-packager-0.6.0.6 (already in Fedora stable) you can run fkinit or fkinit -u USERNAME to obtain Fedora Kerberos ticket. Kudos to Stephen Gallagher and Tomas Hrcka for making this. Miroslav ___ 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
[EPEL-devel] Re: intent to retire roundcubemail in epel7
On 24/05/2021 19:36, Sérgio Basto wrote: On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote: On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote: On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < smo...@gmail.com> wrote: ...snip... Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;( https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451 why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ ? If Roundcube 1.4 doesn't work, 1.3 will. I am wondering if we need a different way to announce reasons for this: [ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ... Or maybe instead of saying it's retiring, do Fedora's Orphaning format. Announce they are orphaning the package, and if a package is orphaned for a certain amount of time, and has all the orphan annoucements, it get's removed. But I do like your checkbox way for announcing the reasons for retiring/orphaning. Well, thats what goes in the dead.package file when the package is retired. :) I was just wanting to stop shipping a known vulnerable package and get it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't actually going to work, but happy for someone to prove me wrong. I don't really have the time to investigate further myself. So, I will orphan it now, if no one takes it in a while, I will retire it then? kevin ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: intent to retire roundcubemail in epel7
On Mon, 24 May 2021 at 14:36, Sérgio Basto wrote: > On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote: > > On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote: > > > On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < > > > smo...@gmail.com> > > > wrote: > > > > ...snip... > > > > Here's a scratch build of 1.4.11, but I bet it won't work as many of > > the > > php-pear packages are too old. ;( > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451 > > > > why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ > ? > > > EPEL packages may rely on Red Hat SCL's for build dependencies but not run-time dependencies. In this case this would be a run-time dependency requirement. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: intent to retire roundcubemail in epel7
On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote: > On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote: > > On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < > > smo...@gmail.com> > > wrote: > > ...snip... > > Here's a scratch build of 1.4.11, but I bet it won't work as many of > the > php-pear packages are too old. ;( > > https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451 > why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ ? > > > I am wondering if we need a different way to announce reasons for > > > this: > > > > > > [ ] I no longer use RHEL-7 so can not test > > > [ ] I found that there are too many package updates needed that I > > > do not > > > have time for. > > > [ ] The following RHEL packages are too old for this package to be > > > updated > > > [ ] The upstream is dead and I can not fix > > > ... > > > > Or maybe instead of saying it's retiring, do Fedora's Orphaning > > format. > > Announce they are orphaning the package, and if a package is orphaned > > for a > > certain amount of time, and has all the orphan annoucements, it get's > > removed. > > But I do like your checkbox way for announcing the reasons for > > retiring/orphaning. > > Well, thats what goes in the dead.package file when the package is > retired. :) > > I was just wanting to stop shipping a known vulnerable package and get > it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't > actually going to work, but happy for someone to prove me wrong. I > don't > really have the time to investigate further myself. > > So, I will orphan it now, if no one takes it in a while, I will retire > it then? > > kevin > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to > epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Chris Murphy wrote: > Consumer printers have trended toward having an RGB only interface, > making it impossible to directly control them per channel. In effect, > the print driver is becoming part of the printer's firmware. My Canon PIXMA MG3650 is definitely a consumer printer (and a recent one), and it supports CMY-only printing via the Gutenprint driver. It speaks a proprietary protocol, offloading most of the work to the driver, as is common for cheap printers. Why would the printer do the RGB to CMYK (or CMY) conversion when the computer can do it? (That said, it appears to support AirPrint, at least the USB endpoint for it is advertised. But I have no idea how flexible the AirPrint mode is, if it works at all. But definitely not as much as Gutenprint, I am pretty sure.) Kevin Kofler ___ 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: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint shines, even > in comparison to official manufacturer drivers on $ProprietaryOS. Well, choosing whether you want a printout with less ink consumption or one that looks more "perfect" is an important choice, and it's only found in the advanced, driver-specific settings. Kevin Kofler ___ 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
[EPEL-devel] Re: fedpkg Kerberos failing for me on el7
On Mon, May 24, 2021 at 03:30:58PM +, Dave Dykstra wrote: > Is anybody else having trouble with using kerberos with fedpkg on el7? > It is working for me on el8, and it used to work for me on el7, but now > on my el7 machine any time I try to do an upload I get > Could not execute upload: Request is unauthorized. > and with fedpkg build I get > Kerberos authentication fails: unable to obtain a session > Could not execute build: Could not login to > https://koji.fedoraproject.org/kojihub > > This is with fedpkg-1.40-6.el7 installed from epel and after successfully > doing kinit d...@fedoraproject.org. Can you make a ticket at https://pagure.io/fedora-infrastructure and include the output of the failing commands with: "KRB5_TRACE=/dev/stdout" prepended (that will give debugging output). Thanks, kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, 24 May 2021 at 12:29, Solomon Peachy wrote: > On Mon, May 24, 2021 at 05:14:41PM +0200, Kevin Kofler via devel wrote: > > The real issue here is the "once CUPS removes printer driver support" > > premise that makes a "transition technology" necessary in the first > place. > > The change removes functionality that has been just working for decades. > > The legacy CUPS *direct-attached* model simply doesn't work with > containerized/sandboxed applications that are all the vogue these days. > > But if your printer was already non-local vs the system doing the > printing (ie on "the network" somewhere) then this whole conversation is > moot, because you haven't had to install a native driver locally for > many years. > > > > Except for Gutenprint, I'm not aware of any printer driver provider > > > which plans to provide more specific options with a printer > application. > > > > Which implies that, from a user perspective, there will be a noticeable > loss > > of functionality. > > How so? I mean, whether you supply the printing options from the lp > command line, the printer's web UI (this includes CUPS' webserver) or > the system printing dialog the functionality will still be there. > > > > They seem to be okay with AirPrint. > > > > So, how, if at all, can you configure an AirPrint printer? > > The same way you configure any other printer; ie via its designated > configuration interface. This can be the printer control panel, an > embedded web server, or arbitrary print-time options; whatever the > printer and application/platform supports. > > > A web interface is not a complete replacement for "what CUPS provides > right > > now", which is a driver-independent key-value property interface that is > > used both by desktop environments and/or distributions to provide > > configuration interfaces in their native toolkit (e.g., > > system-config-printer, kde-print-manager, etc.) and by applications to > allow > > changing printer settings for individual printouts from within the > > application. > > IPP already supports arbitrary key-value properties. That isn't the > problem; instead it's getting generic driver/device-independent > configuration tools/interfaces to present them properly. > > These interfaces represent their own level of hell, and they are _all_ > broken in some way or another, even with the mature PPD-based CUPS flow. > > (And I say that as a Gutenprint developer who has to deal with the > support headaches..) > > > A web interface requires bringing up a web browser, manually pointing it > to > > http://localhost: where is a port number that has to be > manually > > looked up from some manual, > > No, it's a standard property, and I'd presume a "generic IPP print > dialog" would have a big fat button that, when mashed, takes you to the > appropriate configuration interface. > > > And yet, that design is just not (and still not) a fully functional > > replacement for the functionality you are trying to remove and has > achieved > > little to no adoption. That is the point where it is simply time to > admit > > failure. > > Honestly? The simplest approach is to copy what every other platform out > there already does, and simply drop support for sufficiently old > hardware. Fedora routinely does this, why should printers be any > different? > > Mainly because printers tend to either live incredibly short lives or horribly long ones (like my old neighbours HP Laserjet 4 which they got from their Dad. The printer is at least 4 years older than the student.) I would say it was a lone example, but I have seen 4 students in the last year with some older printer because the new one didn't work with Windows or their Mac but their parents' 10+ year old one was running fine so they got it. Going from the various University email lists, these older things end up being the ones which departments keep going for decades also. Printers tend to be seen as major cost products for a lot of businesses and university/government departments mainly from when they were. Mainly because too many departments bought cheap ones in the past which ended up costing too much in service calls (which is what the printing company wanted.. razor blade model). Instead you end up having to fill out giant amounts of paperwork to justify a 50 dollar off the shelf printer but you can get a 40,000 dollar one approved quicker. You then end up keeping that 40,000 one going for as long as you can.. because it may be 20 years before you get another one. [The printer company pretty much makes as much money with either purchase.. it is either on the front end or the back end.] > Meanwhile. The ultimate goal has not yet been realized, but with each > incremental milestone along the way, it's getting closer. Ironically, > the existing Legacy CUPS + cups-filters + drivers printing flow has been > the largest beneficiary of these improvements; I wouldn't consider that > a failure. > > - Solomon > -- > Solomon
Re: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > CUPS discovery is designed to run on secure, private LAN, so it is > expected that you have a protection against somebody connecting to your > WIFI. That was a reasonable assumption in the 1980s. It's 2021 now, and every program that communicates must cope with a hostile environment. Here in the third millennium we have laptops moving between networks. There are public hotspots and mobile Internet, plenty of connections that aren't private LANs. Home routers are typically crap and never get any security updates, and the Insecurity of Things ensures that there are easily cracked devices in every home and office. As for wifi, it has a long history of flawed security protocols. A recent study found three protocol design flaws in the standards, including the latest WPA3 specification, and nine implementation defects that can be used to attack devices that trust the wifi network to protect them. Assuming that all the nodes on the local link are friendly is criminally naïve. Björn Persson pgpLHHjA7RfBz.pgp Description: OpenPGP digital signatur ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 05:14:41PM +0200, Kevin Kofler via devel wrote: > The real issue here is the "once CUPS removes printer driver support" > premise that makes a "transition technology" necessary in the first place. > The change removes functionality that has been just working for decades. The legacy CUPS *direct-attached* model simply doesn't work with containerized/sandboxed applications that are all the vogue these days. But if your printer was already non-local vs the system doing the printing (ie on "the network" somewhere) then this whole conversation is moot, because you haven't had to install a native driver locally for many years. > > Except for Gutenprint, I'm not aware of any printer driver provider > > which plans to provide more specific options with a printer application. > > Which implies that, from a user perspective, there will be a noticeable loss > of functionality. How so? I mean, whether you supply the printing options from the lp command line, the printer's web UI (this includes CUPS' webserver) or the system printing dialog the functionality will still be there. > > They seem to be okay with AirPrint. > > So, how, if at all, can you configure an AirPrint printer? The same way you configure any other printer; ie via its designated configuration interface. This can be the printer control panel, an embedded web server, or arbitrary print-time options; whatever the printer and application/platform supports. > A web interface is not a complete replacement for "what CUPS provides right > now", which is a driver-independent key-value property interface that is > used both by desktop environments and/or distributions to provide > configuration interfaces in their native toolkit (e.g., > system-config-printer, kde-print-manager, etc.) and by applications to allow > changing printer settings for individual printouts from within the > application. IPP already supports arbitrary key-value properties. That isn't the problem; instead it's getting generic driver/device-independent configuration tools/interfaces to present them properly. These interfaces represent their own level of hell, and they are _all_ broken in some way or another, even with the mature PPD-based CUPS flow. (And I say that as a Gutenprint developer who has to deal with the support headaches..) > A web interface requires bringing up a web browser, manually pointing it to > http://localhost: where is a port number that has to be manually > looked up from some manual, No, it's a standard property, and I'd presume a "generic IPP print dialog" would have a big fat button that, when mashed, takes you to the appropriate configuration interface. > And yet, that design is just not (and still not) a fully functional > replacement for the functionality you are trying to remove and has achieved > little to no adoption. That is the point where it is simply time to admit > failure. Honestly? The simplest approach is to copy what every other platform out there already does, and simply drop support for sufficiently old hardware. Fedora routinely does this, why should printers be any different? Meanwhile. The ultimate goal has not yet been realized, but with each incremental milestone along the way, it's getting closer. Ironically, the existing Legacy CUPS + cups-filters + drivers printing flow has been the largest beneficiary of these improvements; I wouldn't consider that a failure. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
[Bug 1964067] New: perl-XML-Feed-0.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1964067 Bug ID: 1964067 Summary: perl-XML-Feed-0.62 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XML-Feed Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.62 Current version/release in rawhide: 0.61-1.fc34 URL: http://search.cpan.org/dist/XML-Feed Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8396/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The Program Management Team is here to help!
If you didn't see my post on the Community Blog[1] last week, I wanted to let you know that the newly-formed Program Management Team is now ready to help other teams in Fedora. Some of the duties that the team can perform include: * Coordination with other Fedora teams (e.g. Websites, design) * Consulting on team process development and improvement * Tracking development plans against the Fedora schedule * Issue triage and management * Shepherding Change proposals and similar requests If this is something your team (SIG, Working Group, etc, etc) is interested in, please file an issue[2]. Since this is a new team, we're still figuring out how things work. Working with other teams will help us figure that out faster. [1] https://communityblog.fedoraproject.org/need-help-the-program-management-team-is-here/ [2] https://pagure.io/fedora-pgm/pgm_team/new_issue?template=support_request -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 04:58:18PM +0200, Kevin Kofler via devel wrote: > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > always what you want. But never printing duplex makes even less sense. > There's also short side duplex that makes sense in some cases for landscape > printing.) Eh, duplexing is another basic document property, like paper size and orientation. Granted, it's relatively likely to be overridden at the time of printing... But by "settings" I was referring to things like ink density/droplet size, weave patterns, dither modes, individual color channel curves, and other minutae that matter for specialized photo/art printing on near-arbitrary media. This tunability is where Gutenprint shines, even in comparison to official manufacturer drivers on $ProprietaryOS. (And incidently, I do have a duplexing printer, a decade-plus-old Brother HL-5340D. Along with 31 others, though only 26 are plugged in at the moment. Isn't driver development/regression testing fun?) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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-Rawhide-20210524.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 21/194 (x86_64), 21/133 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210523.n.0): ID: 893112 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/893112 ID: 893219 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/893219 ID: 893220 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/893220 ID: 893223 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/893223 ID: 893224 Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi URL: https://openqa.fedoraproject.org/tests/893224 ID: 893227 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/893227 ID: 893230 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/893230 ID: 893325 Test: aarch64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/893325 ID: 893637 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/893637 Old failures (same test failed in Fedora-Rawhide-20210523.n.0): ID: 893050 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/893050 ID: 893053 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/893053 ID: 893059 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/893059 ID: 893084 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/893084 ID: 893090 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/893090 ID: 893091 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/893091 ID: 893102 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/893102 ID: 893105 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/893105 ID: 893118 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/893118 ID: 893127 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/893127 ID: 893129 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/893129 ID: 893248 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/893248 ID: 893262 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/893262 ID: 893266 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/893266 ID: 893280 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/893280 ID: 893285 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/893285 ID: 893289 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/893289 ID: 893301 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/893301 ID: 893303 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/893303 ID: 893304 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/893304 ID: 893323 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/893323 ID: 893324 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/893324 ID: 893330 Test: aarch64 universal install_repository_http_graphical@uefi URL: https://openqa.fedoraproject.org/tests/893330 ID: 893335 Test: aarch64 universal install_repository_http_variation@uefi URL: https://openqa.fedoraproject.org/tests/893335 ID: 893339 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/893339 ID: 893349 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/893349 ID: 893355 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/893355 ID: 893541 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/893541 ID: 893552 Test: aarch64 Server-dvd-iso
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 9:26 AM Kevin Kofler via devel wrote: > > Kevin Kofler via devel wrote: > > Solomon Peachy wrote: > >> On the other hand, the average person wanting to "just print something" > >> can do just that without ever adjusting any settings. > > > > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > > always what you want. But never printing duplex makes even less sense. > > There's also short side duplex that makes sense in some cases for > > landscape printing.) > > Another example: What do you do when you run out of black ink at a time > where no stores are open (night, weekend, hard lockdown, etc.)? With > Gutenprint, it is very easy to change from CMYK mode to CMY mode with > composite black. Consumer printers have trended toward having an RGB only interface, making it impossible to directly control them per channel. In effect, the print driver is becoming part of the printer's firmware. -- 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
[EPEL-devel] fedpkg Kerberos failing for me on el7
Is anybody else having trouble with using kerberos with fedpkg on el7? It is working for me on el8, and it used to work for me on el7, but now on my el7 machine any time I try to do an upload I get Could not execute upload: Request is unauthorized. and with fedpkg build I get Kerberos authentication fails: unable to obtain a session Could not execute build: Could not login to https://koji.fedoraproject.org/kojihub This is with fedpkg-1.40-6.el7 installed from epel and after successfully doing kinit d...@fedoraproject.org. Dave ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Kevin Kofler via devel wrote: > Solomon Peachy wrote: >> On the other hand, the average person wanting to "just print something" >> can do just that without ever adjusting any settings. > > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > always what you want. But never printing duplex makes even less sense. > There's also short side duplex that makes sense in some cases for > landscape printing.) Another example: What do you do when you run out of black ink at a time where no stores are open (night, weekend, hard lockdown, etc.)? With Gutenprint, it is very easy to change from CMYK mode to CMY mode with composite black. Kevin Kofler ___ 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: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > Printer applications started as a transition technology - a way how to > support older printers once CUPS removes printer driver support - so for > now they are here for backward compatibility. The real issue here is the "once CUPS removes printer driver support" premise that makes a "transition technology" necessary in the first place. The change removes functionality that has been just working for decades. > Except for Gutenprint, I'm not aware of any printer driver provider > which plans to provide more specific options with a printer application. Which implies that, from a user perspective, there will be a noticeable loss of functionality. > They seem to be okay with AirPrint. So, how, if at all, can you configure an AirPrint printer? > AFAIK PAPPL (and even the old lprint which I packaged into Fedora last > year, but his web interface is going to substituted by PAPPL web ui in > the next release) provides a default web interface which you can use for > configuring printer options. >> >> From the end user perspective, the new approach brings only >> disadvantages. > Since PAPPL provides web ui and CLI, which you can use for configuring > your device, IMHO it is not much different from what CUPS provides right > now. A web interface is not a complete replacement for "what CUPS provides right now", which is a driver-independent key-value property interface that is used both by desktop environments and/or distributions to provide configuration interfaces in their native toolkit (e.g., system-config-printer, kde-print-manager, etc.) and by applications to allow changing printer settings for individual printouts from within the application. A web interface requires bringing up a web browser, manually pointing it to http://localhost: where is a port number that has to be manually looked up from some manual, and then using a web form (rather than a native dialog) to change any settings. And changing the settings for just one printout requires bringing up the web interface as previously described, then making the printout through the application, and then going back to the web interface to change the settings back, meaning you now have to deal with two applications (the browser and the actual application) instead of one. I never use http://localhost:631 to configure CUPS, it is just not practical (even though I happen to know the port number by heart, which is also not the case for the new PAPPL port). > CUPS developers (PWG+Openprinting) decided to remove deprecated > functionality (which has big issues regarding security and distribution) > in the future in favor of standardized, less hardware dependent > solution, which is supported by 98% of printers released since 2010. The > functionality has been deprecated for 11 years and still be only > deprecated (not removed) until there is a coverage for older devices by > printer applications and have some tools for installing older printers > via printer applications. If you try and fail to remove something for 11 years, that should be clear evidence that that something is actually needed and simply cannot be removed. > CUPS developers came up with printer application design for older device > users, so they don't have to buy a new device, created first three > printer applications - ippeveprinter (shipped in CUPS itself, under > cups-printerapp subpackage in Fedora), lprint (support for label > printers) and ps-printer-app (which covers postscript printers) -, plans > to implement printer applications for other widely packaged printer > drivers and publicly provides a documentation how to create printer > applications for corner use cases. And yet, that design is just not (and still not) a fully functional replacement for the functionality you are trying to remove and has achieved little to no adoption. That is the point where it is simply time to admit failure. Kevin Kofler ___ 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: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On the other hand, the average person wanting to "just print something" > can do just that without ever adjusting any settings. Looks like you do not have a duplex printer. (Hint: Printing duplex is not always what you want. But never printing duplex makes even less sense. There's also short side duplex that makes sense in some cases for landscape printing.) Kevin Kofler ___ 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: hamcrest update to 2.2 in Fedora rawhide
On Mon, May 24, 2021 at 4:02 PM Mikolaj Izdebski wrote: > > On Fri, May 21, 2021 at 1:55 AM Fabio Valentini wrote: > > > > On Fri, May 21, 2021 at 1:10 AM Mikolaj Izdebski > > wrote: > > > > > > Hello, > > > > > > Next week I'm going to update package hamcrest in Fedora rawhide from > > > version 1.3 to version 2.2. > > > > > > The proposed update contains an API change that can affect packages > > > depending on hamcrest. You may need to rebuild your packages to keep > > > working with updated hamcrest. > > > > > > The update has already been checked into dist-git and a Koji build has > > > already been done, but Bodhi update has not been submitted yet. Bodhi > > > update is expected after a week, to comply with Updates Policy that > > > mandates a notification one week in advance before submitting an API > > > changing update. > > > > > > Current NVR in rawhide: hamcrest-1.3-31.fc34 > > > Updated NVR: hamcrest-2.2-3.fc35 > > > Build link: > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364 > > > > Note that hamcrest versions 2.x have already been available for over a year: > > https://src.fedoraproject.org/rpms/hamcrest2 > > hamcrest2 package is orphaned and it will be retired soon, unless > someone adopts it. As maintainer of hamcrest I would like to keep it > at the latest upstream version. Older versions can of course be > packaged as compat packages with version suffix in the name, if anyone > wishes to maintain them. > > > We packaged them separately because, IIRC, maven artifact coordinates > > and java package import paths are completely separate between version > > 1.x and 2.x so packages can't just be updated, but actually need to be > > ported to the new 2.x APIs. > > That is the API break I was speaking of. Hence I gave maintainers of > dependent packages a week to respond and prepare their packages to > work with updated hamcrest, by porting to hamcrest 2.2 or by packaging > version 1.x as hamcrest1 compat package and switching packages to use > it instead of hamcrest. So you're going to knowingly break other people's packages, with only one week's notice, for no good reason (since both versions of hamcrest were already available in parallel for over a year)? Do you think that is acceptable? Fabio ___ 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: Storing package metadata in ELF objects
On Wed, 2021-05-19 at 16:58 +0200, Mark Wielaard wrote: > Hi Guillem, > > On Wed, 2021-05-19 at 02:19 +0200, Guillem Jover wrote: > > So this is where I guess I'm missing something. To be able to make > > sense of the coredumps there are two things that might end up being > > relevant, backtraces and source code. systemd-coredump might already > > emit a backtrace, and depending on the information provided it might > > be more or less useful. If one needs the actual debug symbols there's > > already some external querying/fetching required, and if distribution > > specific source code is required because many distributions patch > > upstream source, then even more querying/fetching will be required. > > > > Which is why I'm not seeing why this standalone and isolated metadata > > would be of much help by itself. As in, the way I see it, either the > > information from systemd (w/o the extra metadata) is sufficient to > > track down bugs, or that querying/fetching would be needed anyway, at > > which point the metadata can be inferred too then? > > Because without that metadata you cannot easily figure out where/how to > get the files needed to properly track down the bugs. But using that > metadata you can figure out where the debuginfod server is that can > provide all that information for the binaries/core files (or a distro > specific method if the distributor doesn't have a debuginfod server > yet). Yes, that is a good use case. Another use case is that the person (or bot) who first looks at the journal with the crash notification and the metadata might not necessarily be the one that does the full in-depth debugging. First level support will look at things and go "oh this is from package X at version Y, therefore team Z needs to chime in". Or it can see that it's version A.B.C, which is listed as known buggy, and ignore the issue. Or a myriad of other combinations. Then there are automated systems, parsing logs and creating tickets. Having the structured metadata available in the journal in the crash message means much more complex and useful querying and ticket creation systems can be set up. You _cannot_ just go and query random remote internet servers from these systems, they need to be network-isolated, as logs can have confidential data from customers. The main point is, there are many many things that happen between a crash and the team owning the component looking up debugging symbols and loading core files. This feature is very very useful for a whole lot of those things. > > Oh, I was thinking about those mixed environments, full chroots or > > stripped down containers, from different vendors, but affecting Debian > > installations. What I'm also probably missing here is how does the > > metadata help for a third-party that is not expected to track/keep/upload > > debug symbols nor source packages into some repository, because otherwise > > I'm not seeing how they'd make use of the cores (if they are insufficient > > by themselves) to debug issues? I guess my question back would be what > > would they do with the metadata if they do not have the debug symbols > > nor the sources readily available? Also assuming of course they exercise > > good practices such as never reusing the same package-version-arch tuple > > for different builds, and similar. :) > > Different builds will have different build-ids, so they can be kept > apart. But even if without the distributor having added debuginfod > meta-data and providing a server to fetch the extra symbols, debuginfo, > sources, the extra meta-data is useful to administrators. Just seeing > that crashes are associated with specific distro/version/packages helps > narrow down instabilities. Precisely - again this is a very much real use case. In my case, the engineers doing support and looking at the logs (and only at the logs - no access to the running systems is permitted) _want_ this, because it helps them. Being able to know at a glance to the journal exactly what is borken, with version info, is extremely valuable to them. Yes the version info might not be precise for a minority of use cases that override the binary version with something different than the source version, but that's fine as it's far and few, mostly affects metapackages, and even then it can be documented clearly that the reference is to the source version, not the binary one. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part ___ 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:
Re: hamcrest update to 2.2 in Fedora rawhide
On Fri, May 21, 2021 at 1:55 AM Fabio Valentini wrote: > > On Fri, May 21, 2021 at 1:10 AM Mikolaj Izdebski wrote: > > > > Hello, > > > > Next week I'm going to update package hamcrest in Fedora rawhide from > > version 1.3 to version 2.2. > > > > The proposed update contains an API change that can affect packages > > depending on hamcrest. You may need to rebuild your packages to keep > > working with updated hamcrest. > > > > The update has already been checked into dist-git and a Koji build has > > already been done, but Bodhi update has not been submitted yet. Bodhi > > update is expected after a week, to comply with Updates Policy that > > mandates a notification one week in advance before submitting an API > > changing update. > > > > Current NVR in rawhide: hamcrest-1.3-31.fc34 > > Updated NVR: hamcrest-2.2-3.fc35 > > Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364 > > Note that hamcrest versions 2.x have already been available for over a year: > https://src.fedoraproject.org/rpms/hamcrest2 hamcrest2 package is orphaned and it will be retired soon, unless someone adopts it. As maintainer of hamcrest I would like to keep it at the latest upstream version. Older versions can of course be packaged as compat packages with version suffix in the name, if anyone wishes to maintain them. > We packaged them separately because, IIRC, maven artifact coordinates > and java package import paths are completely separate between version > 1.x and 2.x so packages can't just be updated, but actually need to be > ported to the new 2.x APIs. That is the API break I was speaking of. Hence I gave maintainers of dependent packages a week to respond and prepare their packages to work with updated hamcrest, by porting to hamcrest 2.2 or by packaging version 1.x as hamcrest1 compat package and switching packages to use it instead of hamcrest. -- Mikolaj Izdebski > > Fabio > ___ > 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 ___ 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 rawhide compose report: 20210524.n.0 changes
OLD: Fedora-Rawhide-20210523.n.0 NEW: Fedora-Rawhide-20210524.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 36 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 198.32 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.11 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: corsix-th-0.64-8.fc35 Old package: corsix-th-0.64-7.fc35 Summary: Open source clone of Theme Hospital RPMs: corsix-th corsix-th-data Size: 2.71 MiB Size change: 602 B Changelog: * Sun May 23 2021 Artem Polishchuk - 0.64-8 - fix: Broken music | rh#1963368 Package: darktable-3.4.1-3.fc35 Old package: darktable-3.4.1-2.fc35 Summary: Utility to organize and develop raw images RPMs: darktable darktable-tools-noise Size: 10.77 MiB Size change: -129.86 KiB Changelog: * Sun May 23 2021 Robert-Andr?? Mauchin - 3.4.1-3 - Rebuild for libavif soname bump Package: dav1d-0.9.0-1.fc35 Old package: dav1d-0.8.2-1.fc35 Summary: AV1 cross-platform Decoder RPMs: dav1d libdav1d libdav1d-devel Size: 3.17 MiB Size change: 31.17 KiB Changelog: * Sun May 23 2021 Robert-Andr?? Mauchin - 0.9.0-1 - Update to 0.9.0 - Close: rhbz#1960939 Package: dummy-test-package-gloster-0-3813.fc35 Old package: dummy-test-package-gloster-0-3803.fc35 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 236.05 KiB Size change: 608 B Changelog: * Sat May 22 2021 packagerbot - 0-3804 - rebuilt * Sun May 23 2021 packagerbot - 0-3805 - rebuilt * Sun May 23 2021 packagerbot - 0-3806 - rebuilt * Sun May 23 2021 packagerbot - 0-3807 - rebuilt * Sun May 23 2021 packagerbot - 0-3808 - rebuilt * Sun May 23 2021 packagerbot - 0-3809 - rebuilt * Sun May 23 2021 packagerbot - 0-3810 - rebuilt * Sun May 23 2021 packagerbot - 0-3811 - rebuilt * Mon May 24 2021 packagerbot - 0-3812 - rebuilt * Mon May 24 2021 packagerbot - 0-3813 - rebuilt Package: elementary-calculator-1.6.1-1.fc35 Old package: elementary-calculator-1.6.0-3.20210216git64f8f0a.fc35 Summary: Calculator app designed for elementary RPMs: elementary-calculator Size: 527.44 KiB Size change: -5.13 KiB Changelog: * Sun May 23 2021 Fabio Valentini - 1.6.1-1 - Update to version 1.6.1. Package: elementary-notifications-0-0.12.20210515.gitd5ff186.fc35 Old package: elementary-notifications-0-0.11.20210311.giteec89e6.fc35 Summary: GTK Notifications Server RPMs: elementary-notifications elementary-notifications-demo Size: 344.43 KiB Size change: -2.39 KiB Changelog: * Sun May 23 2021 Fabio Valentini - 0-0.12.20210515.gitd5ff186 - Bump to commit d5ff186. Package: eterm-0.9.6-26.fc35 Old package: eterm-0.9.6-25.fc34 Summary: Enlightened terminal emulator RPMs: eterm Size: 10.93 MiB Size change: -27.24 KiB Changelog: * Sun May 23 2021 Terje Rosten - 0.9.6-26 - Add patch from rxvt-unicode to fix rhbz#1961798 Package: fzf-0.27.1-1.fc35 Old package: fzf-0.27.0-2.fc35 Summary: A command-line fuzzy finder written in Go RPMs: fzf Size: 4.95 MiB Size change: -28.37 KiB Changelog: * Sun May 23 2021 Elliott Sales de Andrade - 0.27.1-1 - Update to latest version (#1963312) Package: gd-2.3.2-5.fc35 Old package: gd-2.3.2-4.fc35 Summary: A graphics library for quick creation of PNG or JPEG images RPMs: gd gd-devel gd-progs Size: 1.20 MiB Size change: -23.17 KiB Changelog: * Sun May 23 2021 Robert-Andr?? Mauchin - 2.3.2-5 - Rebuild for libavif soname bump Package: git-2.32.0-0.1.rc1.fc35 Old package: git-2.31.1-3.fc35 Summary: Fast Version Control System RPMs: git git-all git-core git-core-doc git-credential-libsecret git-cvs git-daemon git-email git-gui git-instaweb git-p4 git-subtree git-svn gitk gitweb perl-Git perl-Git-SVN Added RPMs: git-p4 Size: 24.10 MiB Size change: 338.18 KiB Changelog: * Sun May 16 2021 Todd Zullinger - clean up various dist conditionals * Mon May 17 2021 Todd Zullinger - 2.32.0-0.0.rc0 - update to 2.32.0-rc0 * Fri May 21 2021 Jitka Plesnikova - 2.31.1-3.1 - Perl 5.34 rebuild * Sat May 22 2021 Todd Zullinger - 2.32.0-0.1.rc1 - update to 2.32.0-rc1 - rearrange python2/python3 conditionals - re-enable git-p4 with python3 - add coreutils BuildRequires - remove unneeded NEEDS_CRYPTO_WITH_SSL Package: golang-filippo-edwards25519-1.0.0~beta.3-1.fc35 Old package: golang-filippo-edwards25519-1.0.0~beta.2-2.fc34 Summary: Implementation
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 3:29 AM, Zdenek Dohnal wrote: Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Greetings, Is there any plan to support these IPP printer applications over Unix domain sockets? I manage a virtual printer that uses CUPS filters and backends to capture documents to an application database. We have been using CUPS authentication features to control who can use the printer, and not to have to reimplement authentication on the filter and backends. With network bound IPP applications, anyone on the same multiuser machine would be able to bypass CUPS and send documents directly unless I duplicate CUPS authentication functionality. Unix sockets would help with that, ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 01:48:08PM +0200, Vitaly Zaitsev via devel wrote: > Breaking what has worked well for years is the worst idea, IMO. It worked well for years in the same sense that sysvinit worked well; with a great deal of bailing wire, angst, and the occasional blood sacrifice to the elder gods. > Introducing a new API -> implementing new apps for all available printers -> > deprecating the old API -> removing the old API. > > ^ this strategy should be used. Fortunately, it is! - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 12:33:45PM +0200, Vitaly Zaitsev via devel wrote: > On 24.05.2021 12:30, Solomon Peachy wrote: > > Not only is it possible, it's been done. > > For all existing printers in the world? I don't believe. For all printers? Of course not. But that wasn't what Zdenek wrote. At least two printer families have working Printer Applications _today_. There is a reasonable plan in place to port several more, and once complete that will encompass the vast majority of the printers still in use. Meanwhile, stuff that never had a native Linux/CUPS driver still won't work. And stuff that was only ever made available with a proprietary binary driver can be wrapped with legacy CUPS, which itself is a "printer application". Printing has always been an awful, awful mess, and the fact it works as well as it does is a testatment to the thankless efforts of the OpenPrinting folks (and their predecessors). Indeed, these days, it's a rare (new-ish) printer that doesn't JusWork(tm). The Printer Application model is attempting to bring the older/niche models into the same "driverless" paradigm. This is a VeryGoodThing(tm), as it means printing will automagically JustWork(tm) for just about everyone -- Linux, Android, iOS, MacOS, and even Windows! We're even going to (finally!) be getting sane color profile management out of the box! - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: [Test-Announce] 2021-05-24 @ 15:00 UTC - Fedora QA Meeting
Will attend this meeting today On Sat, May 22, 2021 at 2:01 AM Adam Williamson wrote: > # Fedora Quality Assurance Meeting > # Date: 2021-05-24 > # Time: 15:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: #fedora-meeting on irc.freenode.net > > Greetings testers! > > We didn't meet last week, so let's get together and check in. I don't > have anything much specific for the agenda, so it may be a short > meeting. > > If anyone has any other items for the agenda, please reply to this > email and suggest them! Thanks. > > == Proposed Agenda Topics == > > 1. Previous meeting follow-up > 2. Fedora 35 status > 3. Test Day / community event status > 4. Open floor > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > > ___ > 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 > ___ 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: When is pappl going to be good enough to replace cups?
On 24.05.2021 13:23, Zdenek Dohnal wrote: I would have a counter question - do you think that all existing printers in the world which have a printer driver work correctly on Linux? I don't believe.:) Breaking what has worked well for years is the worst idea, IMO. OpenPrinting community plans to create printer applications for widely known printer drivers, plus those applications can use your own PPD file once you upload it to the application and the same is planned to do with plugins/firmware (you will be able to use 3rd party plugins and firmware with printer applications). Good, but only when this task is fully completed, the deprecated CUPS features can be removed. Introducing a new API -> implementing new apps for all available printers -> deprecating the old API -> removing the old API. ^ this strategy should be used. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: When is pappl going to be good enough to replace cups?
On Mon, 24 May 2021 at 03:30, Zdenek Dohnal wrote: > Hi Stephen, > On 5/22/21 1:37 AM, Stephen John Smoogen wrote: > > > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. > > CUPS is supported and developed by Openprinting+PWG community, which > contains Mike Sweet and distro maintainers (like me). > My apologies. > > I don’t know what any other alternatives there are as more and more > printers seem to be wanting you to send your prints to some central web > server they own and then will talk with your printer and print the task. Or > they say they support the IPP but really its an app on your machine which > just takes it and makes it something proprietary and trying to talk ipp to > the printer fails. > > You don't need any central web server or special app to be able to print > via the current printer standards, which are driverless (IPP > Everywhere/Airprint/Google Cloud Print). In case your device is on your LAN > or USB, you don't even install the device permanently - CUPS is able to > pick up Avahi messages about a device being in LAN or on localhost (in case > of USB printers after you install ipp-usb) and set up a temp queue for you > when you are about to print - the queue is removed after successful > printing. > I have had very bad luck in setting up new network printers over the last 4 years. I can get all of them to print from Windows and Mac, but every one of them from HP, Brother, and some other brands could not print anything from Linux. They were all 'Linux ready' but were doing it via either Google Print or a set of proprietary software blobs to be put on the computer. [They even came with ipp filters but they called the blobs]. I have a Brother MFC-27100W in my office which I print to via my wife's Mac because of this. > Printers outside of your LAN need to be installed permanently right now > via printer configuration tools (CUPS web ui, gnome-control-center, > lpadmin) or via cups-browsed. We plan to support such devices by printer > profiles, so the queues won't installed permanently either. > > Devices which currently depend on a deprecated functionality - printer > drivers and raw queues - will need a printer application once the > deprecated functionality is removed from CUPS. This application will > advertise the device on localhost via MDNS protocol and will communicate > with CUPS via IPP, both public well-known protocols. The only place where > the data can turn into proprietary is filtering, but it's the same with > printer drivers. > > -- > Zdenek Dohnal > Software Engineer > Red Hat Czech - Brno TPB-C > > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 08:51:11AM +0200, Zdenek Dohnal wrote: > Except for Gutenprint, I'm not aware of any printer driver provider > which plans to provide more specific options with a printer application. > They seem to be okay with AirPrint. So printer application will be > needed only for older (<2010) printer models in most cases. Yeah, Gutenprint is a special case. Or perhaps it's more accurate to say it represents several special cases, because its intended use cases require the ability to carefully tune the output. On the other hand, the average person wanting to "just print something" can do just that without ever adjusting any settings. Disclaimer; I wrote most of the dye-sublimation code in Gutenprint. That family of printers is one of the "verticals" that has completely ignored IPP, due in part to product lifecycles that routinely exceed a decade. Instead, dyesub makers have opted to sell little appliances to provide network connectivity, including SMB for "hot folder" support. Of the devices I'm aware of, all but one is running Linux + CUPS + Gutenprint. (The exception still running CUPS, only with their own driver) Anyway. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:33 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 12:30, Solomon Peachy wrote: >> Not only is it possible, it's been done. > > For all existing printers in the world? I don't believe. I would have a counter question - do you think that all existing printers in the world which have a printer driver work correctly on Linux? I don't believe. :) OpenPrinting community plans to create printer applications for widely known printer drivers, plus those applications can use your own PPD file once you upload it to the application and the same is planned to do with plugins/firmware (you will be able to use 3rd party plugins and firmware with printer applications). -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital 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
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:30 PM, Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:18:17AM +0200, Vitaly Zaitsev via devel wrote: >> On 24.05.2021 08:51, Zdenek Dohnal wrote: >>> OpenPrinting plans >>> to implement printer applications for widely known printer driver >>> packages during GSoC [1] and provides a documentation for driver >>> developers who wants to implement their printer application faster[2][3]. >> I don't think this is even possible in theory. > Not only is it possible, it's been done. > > - Solomon Thanks, Solomon :) > > ___ > 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 -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital 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
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:37 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 10:33, Zdenek Dohnal wrote: >> The future removal isn't due lacking manpower, but due moving to >> standardized and less hardware dependent solutions - driverless >> standards such as IPP Everywhere. And those standards are supported >> by 98% devices released after 2010. > > HP LaserJet P1102w and many others (also called as "win-printers"). It > will be discovered through IPP Everywhere / Avahi, but will not print > anything until the proprietary "plugin" is installed. > I answered you in your original thread, no point of spamming the same message under every related email in the conversation tree. I told you there is a plan for printer application for foo2zjs and you can join the community to implement it, you disagreed, I beg to differ. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital 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
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 10:33, Zdenek Dohnal wrote: The future removal isn't due lacking manpower, but due moving to standardized and less hardware dependent solutions - driverless standards such as IPP Everywhere. And those standards are supported by 98% devices released after 2010. HP LaserJet P1102w and many others (also called as "win-printers"). It will be discovered through IPP Everywhere / Avahi, but will not print anything until the proprietary "plugin" is installed. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: When is pappl going to be good enough to replace cups?
On 24.05.2021 12:30, Solomon Peachy wrote: Not only is it possible, it's been done. For all existing printers in the world? I don't believe. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 10:18:17AM +0200, Vitaly Zaitsev via devel wrote: > On 24.05.2021 08:51, Zdenek Dohnal wrote: > > OpenPrinting plans > > to implement printer applications for widely known printer driver > > packages during GSoC [1] and provides a documentation for driver > > developers who wants to implement their printer application faster[2][3]. > > I don't think this is even possible in theory. Not only is it possible, it's been done. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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-32-20210524.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-32-20210523.0): ID: 892910 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/892910 ID: 892917 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/892917 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
Fedora-Cloud-34-20210524.0 compose check report
No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210523.0): ID: 892886 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/892886 ID: 892887 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/892887 ID: 892888 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation URL: https://openqa.fedoraproject.org/tests/892888 ID: 892889 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging URL: https://openqa.fedoraproject.org/tests/892889 ID: 892890 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux URL: https://openqa.fedoraproject.org/tests/892890 ID: 892891 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/892891 ID: 892892 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/892892 ID: 892893 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/892893 Soft failed openQA tests: 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210523.0): ID: 892899 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/892899 Passed openQA tests: 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: When is pappl going to be good enough to replace cups?
On 5/22/21 9:58 PM, Björn Persson wrote: > > So what I'm hearing is that Fedora will soon stop working with my > printer, There isn't a specific date for removing the functionality, now we work on implementing printer applications for widely known and open sourced printer drivers. > because if there isn't enough manpower to even keep existing > printer drivers in place, The future removal isn't due lacking manpower, but due moving to standardized and less hardware dependent solutions - driverless standards such as IPP Everywhere. And those standards are supported by 98% devices released after 2010. > then who is going to write a bunch of pappls > for not-quite-brand-new printers? Openprinting community plans to write printer applications for some widely known printer drivers during Google Summer of Code in the future[1]. For others - we expect other communities which want those devices to work once drivers are removed from CUPS will step up and implement the missing parts. Openprinting created a printer application library [2] and documentation for them [3][4]. > > And if the bright and shiny future is that USB printers look just like > network printers, and network printers just show up without any > installation, then I'm starting to wonder how I will know whether I'm > sending my sensitive document to my USB printer or to some impostor on > a wifi network. CUPS discovery is designed to run on secure, private LAN, so it is expected that you have a protection against somebody connecting to your WIFI. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects#converting_classic_cups_printer_drivers_into_printer_applications_multiple_students [2] https://github.com/michaelrsweet/pappl/ [3] https://openprinting.github.io/documentation/01-printer-application/ [4] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > ___ > 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 -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital 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
Re: opam (was: Re: Orphaned packages looking for new maintainers)
On Wed, May 19, 2021 at 4:29 AM Richard W.M. Jones wrote: > > (I've added a few opam devs to CC) > > On Tue, May 18, 2021 at 10:14:41PM +0200, Miro Hrončok wrote: > > opam orphan 1 weeks > > ago > > I didn't notice that opam had been orphaned. This package is the tool > used for source packaging of OCaml packages under $HOME > (https://opam.ocaml.org/). > > I don't especially like language-specific tools for managing packages, > because of the usual problems that have been widely discussed > elsewhere and it's not profitable to rehash them again. This is my > personal view. > > The question is if we want to keep this in Fedora or not? ie. As an > official Fedora package versus something that opam maintainers would > provide themselves as a download. I would like to take opam for Fedora. People who need this package would be easier to install it. Just like pip for Python and cpanm for Perl, which are available in Fedora. People just use the package as it is. They don't urge a full integration with Fedora-shipped Ocaml packages. And there is a use case in the XAPI community and the Citrix company that a huge opam repo is packaged in a single RPM[1]. They don't ship individual RPM per Ocaml package. They also package opam as an RPM[2]. So, It won't be hard to also maintain the opam RPM in Fedora. [1] https://github.com/xcp-ng-rpms/xs-opam-repo [2] https://github.com/xcp-ng-rpms/opam - robin > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > 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 ___ 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
jplesnik pushed to perl-Type-Tie (rawhide). "Perl 5.34 re-rebuild of bootstrapped packages"
Notification time stamped 2021-05-24 08:19:04 UTC
From 30d7a39eac065943c8996080bee0785d26069b7a Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 24 2021 08:18:58 +
Subject: Perl 5.34 re-rebuild of bootstrapped packages
---
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 44292d9..6784fcd 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
Name: perl-Type-Tie
Version:0.015
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Tie a variable to a type constraint
# cf. README
License:GPL+ or Artistic
@@ -79,6 +79,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
%{_mandir}/man3/*
%changelog
+* Mon May 24 2021 Jitka Plesnikova - 0.015-4
+- Perl 5.34 re-rebuild of bootstrapped packages
+
* Sun May 23 2021 Jitka Plesnikova - 0.015-3
- Perl 5.34 rebuild
https://src.fedoraproject.org/rpms/perl-Type-Tie/c/30d7a39eac065943c8996080bee0785d26069b7a?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 08:51, Zdenek Dohnal wrote: OpenPrinting plans to implement printer applications for widely known printer driver packages during GSoC [1] and provides a documentation for driver developers who wants to implement their printer application faster[2][3]. I don't think this is even possible in theory. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
jplesnik pushed to perl-Specio (rawhide). "Perl 5.34 re-rebuild of bootstrapped packages"
Notification time stamped 2021-05-24 08:16:28 UTC
From 80f71336ee5c37111ff5b5f2c369da0baa6b0ad2 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 24 2021 08:16:21 +
Subject: Perl 5.34 re-rebuild of bootstrapped packages
---
diff --git a/perl-Specio.spec b/perl-Specio.spec
index cbe708f..7b097a1 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -7,7 +7,7 @@
Name: perl-Specio
Version: 0.47
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Type constraints and coercions for Perl
# lib/Specio/PartialDump.pm: GPL+ or Artistic
#
@@ -162,6 +162,9 @@ make test
%{_mandir}/man3/Test::Specio.3*
%changelog
+* Mon May 24 2021 Jitka Plesnikova - 0.47-3
+- Perl 5.34 re-rebuild of bootstrapped packages
+
* Fri May 21 2021 Jitka Plesnikova - 0.47-2
- Perl 5.34 rebuild
https://src.fedoraproject.org/rpms/perl-Specio/c/80f71336ee5c37111ff5b5f2c369da0baa6b0ad2?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 09:29, Zdenek Dohnal wrote: You don't need any central web server or special app to be able to print via the current printer standards, which are driverless (IPP Everywhere/Airprint/Google Cloud Print). HP JaserJet P1102(w) and many other HP printers will not print without installing a proprietary "plugin" (or a special OSS converter foo2zjs) for both Wi-Fi and USB. Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. I think that the current version of CUPS should not be replaced by a new one with features removed. Move it, for example, to the cups-legacy package. Nobody is going to write application-based drivers for all existing legacy hardware. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
jplesnik pushed to perl-Params-ValidationCompiler (rawhide). "Perl 5.34 re-rebuild of bootstrapped packages"
Notification time stamped 2021-05-24 08:14:53 UTC
From b3a72ff85b89539934196fd8db5735a586a46880 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 24 2021 08:14:47 +
Subject: Perl 5.34 re-rebuild of bootstrapped packages
---
diff --git a/perl-Params-ValidationCompiler.spec
b/perl-Params-ValidationCompiler.spec
index 0bf709a..3b9f097 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -7,7 +7,7 @@
Name: perl-Params-ValidationCompiler
Version: 0.30
-Release: 11%{?dist}
+Release: 12%{?dist}
Summary: Build an optimized subroutine parameter validator once, use it
forever
License: Artistic 2.0
URL: https://metacpan.org/release/Params-ValidationCompiler
@@ -87,6 +87,9 @@ make test
%{_mandir}/man3/Params::ValidationCompiler::Exceptions.3*
%changelog
+* Mon May 24 2021 Jitka Plesnikova - 0.30-12
+- Perl 5.34 re-rebuild of bootstrapped packages
+
* Sat May 22 2021 Jitka Plesnikova - 0.30-11
- Perl 5.34 rebuild
https://src.fedoraproject.org/rpms/perl-Params-ValidationCompiler/c/b3a72ff85b89539934196fd8db5735a586a46880?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
jplesnik pushed to perl-Mail-Message (rawhide). "Perl 5.34 re-rebuild of bootstrapped packages"
Notification time stamped 2021-05-24 08:13:34 UTC
From 8b279126b1d5abce8f46284d22ced6db90fdb018 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova
Date: May 24 2021 08:13:28 +
Subject: Perl 5.34 re-rebuild of bootstrapped packages
---
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index 32536c5..e8018b0 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,6 +1,6 @@
Name: perl-Mail-Message
Version: 3.010
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: MIME message handling
License: GPL+ or Artistic
URL: https://metacpan.org/release/Mail-Message
@@ -126,6 +126,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon May 24 2021 Jitka Plesnikova - 3.010-4
+- Perl 5.34 re-rebuild of bootstrapped packages
+
* Sun May 23 2021 Jitka Plesnikova - 3.010-3
- Perl 5.34 rebuild
https://src.fedoraproject.org/rpms/perl-Mail-Message/c/8b279126b1d5abce8f46284d22ced6db90fdb018?branch=rawhide
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 24th May (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 24th May (today!) at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.freenode.net/?channels=#fedora-neuro or Matrix/Element: https://matrix.to/#/!xgwUsLNGIoOAXMxGMQ:matrix.org?via=matrix.org=t2bot.io The channel is also bridged to Telegram, so you can also join us there on the @NeuroFedora group: https://t.me/NeuroFedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210524T13=%3A=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-05-10-13.02.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F35: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- 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-33-20210524.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-33-20210523.0): ID: 892820 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/892820 ID: 892827 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/892827 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: When is pappl going to be good enough to replace cups?
Hi Stephen, On 5/22/21 1:37 AM, Stephen John Smoogen wrote: > > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. CUPS is supported and developed by Openprinting+PWG community, which contains Mike Sweet and distro maintainers (like me). > > I don’t know what any other alternatives there are as more and more > printers seem to be wanting you to send your prints to some central > web server they own and then will talk with your printer and print the > task. Or they say they support the IPP but really its an app on your > machine which just takes it and makes it something proprietary and > trying to talk ipp to the printer fails. You don't need any central web server or special app to be able to print via the current printer standards, which are driverless (IPP Everywhere/Airprint/Google Cloud Print). In case your device is on your LAN or USB, you don't even install the device permanently - CUPS is able to pick up Avahi messages about a device being in LAN or on localhost (in case of USB printers after you install ipp-usb) and set up a temp queue for you when you are about to print - the queue is removed after successful printing. Printers outside of your LAN need to be installed permanently right now via printer configuration tools (CUPS web ui, gnome-control-center, lpadmin) or via cups-browsed. We plan to support such devices by printer profiles, so the queues won't installed permanently either. Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital 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
[Bug 1950383] please build perl-Archive-Extract for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1950383 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2021-e9b863f5ec has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e9b863f5ec -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/22/21 12:17 AM, Kevin Kofler via devel wrote: > Zdenek Dohnal wrote: >> It is a library for printer applications [1], not a substitute for CUPS. >> CUPS is still present and is going to be. >> >> There will be more printer applications coming into Fedora >> (ps-printer-app f.e.) and one already is (lprint). >> >> >> The purpose of the library is have a way how to implement a support for >> devices which don't support IPP Everywhere [2] or its derivations >> (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can >> be seen by CUPS once we remove printer driver support. Hi Kevin, > I really don't see how the switch from drivers to printer applications is an > improvement. Printer applications started as a transition technology - a way how to support older printers once CUPS removes printer driver support - so for now they are here for backward compatibility. Except for Gutenprint, I'm not aware of any printer driver provider which plans to provide more specific options with a printer application. They seem to be okay with AirPrint. So printer application will be needed only for older (<2010) printer models in most cases. > All the existing drivers have to be ported to the new interface > to essentially emulate the IPP protocol. And now, instead of being able to > configure printer options through the existing graphical CUPS frontends (or > just set them temporarily in the individual application, which most > applications support nowadays), you end up with a CLI as in the old lpr > days, e.g.: > https://www.msweet.org/lprint/lprint.html#printing-options > https://www.msweet.org/lprint/lprint.html#setting-default-options > or at best, a GUI provided by the printer application in some arbitrary > toolkit, which will likely be GTK for Gutenprint (forcing KDE Plasma users > to use a GTK application to configure their printer) and Qt for HPLIP > (forcing GNOME users to use a Qt application to configure their printer). > Instead of a standardized interface to configure printer options, every > printer application now has to reinvent its own one. AFAIK PAPPL (and even the old lprint which I packaged into Fedora last year, but his web interface is going to substituted by PAPPL web ui in the next release) provides a default web interface which you can use for configuring printer options. > > From the end user perspective, the new approach brings only disadvantages. Since PAPPL provides web ui and CLI, which you can use for configuring your device, IMHO it is not much different from what CUPS provides right now. > From the driver developer perspective, it means a lot of porting work. It depends on which devices he creates drivers for - if the device supports Airprint, he can choose to let Airprint to support the printer and no printer application is needed. >From my daily work, I see people often use drivers because they are used to using it and don't know they don't need to use it. For older devices, yes, there needs to be a printer application to be able to use the device with CUPS in the future, but OpenPrinting plans to implement printer applications for widely known printer driver packages during GSoC [1] and provides a documentation for driver developers who wants to implement their printer application faster[2][3]. > The > only ones who will benefit are the CUPS developers, who will have > successfully outsourced their work to other projects that now have to do > their work for them. CUPS developers (PWG+Openprinting) decided to remove deprecated functionality (which has big issues regarding security and distribution) in the future in favor of standardized, less hardware dependent solution, which is supported by 98% of printers released since 2010. The functionality has been deprecated for 11 years and still be only deprecated (not removed) until there is a coverage for older devices by printer applications and have some tools for installing older printers via printer applications. CUPS developers came up with printer application design for older device users, so they don't have to buy a new device, created first three printer applications - ippeveprinter (shipped in CUPS itself, under cups-printerapp subpackage in Fedora), lprint (support for label printers) and ps-printer-app (which covers postscript printers) -, plans to implement printer applications for other widely packaged printer drivers and publicly provides a documentation how to create printer applications for corner use cases. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects [2] https://openprinting.github.io/documentation/01-printer-application/ [3] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: >
[389-devel] 389 DS nightly 2021-05-24 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/05/24/report-389-ds-base-2.0.4-20210524git58a1591b9.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
