[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 --- Comment #7 from Fedora Update System --- FEDORA-2020-fb4f473b3f has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fb4f473b3f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fb4f473b3f 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
Re: Re-Launching the Java SIG
On 5/18/20 5:54 PM, Ty Young wrote: I'm not advocating for in-kernel drivers. AMD with their drivers has proven proven what a bad idea that is. I, for the most part, like where I'm at and the way Nvidia does things. If I'm against it, I don't see why I would be the one to do it. This comment doesn't make any sense. NVidia's driver is just as much "in-kernel" as AMD's. It's just supplied separately and has to play catch-up every time some internal kernel interface changes. ___ 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 --- Comment #6 from Fedora Update System --- FEDORA-2020-747f380e37 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-747f380e37` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-747f380e37 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2020-c446a7263b has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c446a7263b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c446a7263b 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
[EPEL-devel] Re: Modules again
On 5/17/20 6:34 AM, Paul Howarth wrote: I'm trying to do a local build of gtkwave for EPEL-8. A koji scratch build somehow works: http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 But a local build does not: $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm ... Error: Problem: conflicting requests - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is excluded Adding a repo with a local build of Judy doesn't help; that gets excluded too. Any clues? Paul. Judy-devel appears to be part of the mariadb-devel module. Locally I can do: dnf module enable mariadb-devel dnf install Judy-devel This was discovered with: dnf module provides Judy-devel on RHEL 8.2, though that does not appear to work on CentOS 8.1. For mock, this seems to work: mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm or add to /etc/mock/templates/centos-8.tpl: config_opts['module_enable'] = ['mariadb-devel'] koji does some magic to essentially auto-enable some modules that I don't believe mock has. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
[Bug 1742913] biber-2.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1742913 --- Comment #12 from Orion Poplawski --- Yeah, that's at least one of the things hopefully fixed in the latest build. We are still seeing very strange things in koji though that we have so far been unable to diagnose. -- 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 07:54:42PM -0500, Ty Young wrote: > Surely it is the responsibility of those who want such a change to > make sure that everything that existed before can continue to exist? I > realize this requires that such arguments are being made in good faith > and consider the perspectives and needs of everyone, which they > aren't. Yes, exactly, it requires arguments being made in good faith, and considering the needs and perspectives of others. ...You would do well to practice what you preach. I might add that even when your needs and perspectives are duly considered, it does not follow that the outcome will be something you are necessarily satisfied with. Engineering is all about balancing tradeoffs, after all. Meanwhile, "everything before" continues to exist and works as well as the day it was released. Nobody here is forcing you to use anything more recent; you're free to adapt that older source code to your needs, or pay someone else to do it for you. - 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
[389-devel] 389 DS nightly 2020-05-19 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/19/report-389-ds-base-1.4.4.2-20200518git3516495.fc32.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
Strange rpm trigger behavior in koji rawhide
We're trying to track down a problem that only appears in koji and
copr, but I can't reproduce locally in mock on my rawhide VM. It's
related to file triggers and we're trying to debug with something this:
%transfiletriggerin -n texlive-kpathsea -- /usr/share/texlive
# %{_bindir}/texhash 2> /dev/null || :
# DEBUG, lets see what it does
/usr/bin/sh -x %{_bindir}/texhash || :
export TEXMF=/usr/share/texlive/texmf-dist
export TEXMFCNF=/usr/share/texlive/texmf-dist/web2c
export TEXMFCACHE=/var/lib/texmf
# %{_bindir}/mtxrun --generate &> /dev/null || :
# %{_bindir}/fmtutil-sys --all &> /dev/null || :
# DEBUG, lets see what it does
%{_bindir}/mtxrun --generate || :
%{_bindir}/fmtutil-sys --all || :
hoping to see the output in the mock root.log, but I get nothing.
One basic question - if texlive-kpathsea is part of the transaction,
does the above trigger still fire at the end of the transaction?
I see that mock locally and in copr has output like:
Running scriptlet: texlive-base-7:20200327-4.fc33~bootstrap.1.x86_6
357/357
But I don't see any "Running triggers" or similar. Are we correct to
expect output from triggers?
This is causing build failures after the recent texlive update. Any
help would be greatly appreciated.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 10:18 PM Ty Young wrote: > > > On 5/18/20 8:24 PM, Michael Catanzaro wrote: > > > > Dude, chill out. We're not going to go back to running X as root. The > > Nvidia overclocking tool is just not important at all (seriously, who > > cares?). If you're upset their proprietary software doesn't work > > anymore, you can ask them nicely to fix it please... or ask for the > > source code, and see how far that gets you. ;) > > > I'm well aware Fedora has no interest in correcting its breakage of > backwards compatibility. If you'd actually read all the messages you'd > realize it was all in the name of explaining why distros can't be > trusted to package software and shouldn't do it, including Java > applications. It went down this path naturally, as discussions tend to > do and have on this very mailing list without my involvement. > For what it's worth, this is not a change unique to Fedora. Arch, Debian, and other distributions run Xorg in a user session when GDM is the display manager. Some distributions may have elected to change GDM's behavior to the legacy behavior, but none I'm aware of today do so aside from Ubuntu (and that's only when the proprietary drivers are installed). That said, if you are using a display manager that does not support rootless Xorg, you'll get the legacy behavior. However, the writing is on the wall for both Xorg as root and Xorg as a whole. Fedora in this regard is a trailblazer and other distributions *will* follow. Several distributions have finally shipped GNOME with Wayland by default and removed their "hold-back" patches that reverted GDM and GNOME to legacy behaviors by default. Other desktop display managers are working on supporting running Xorg in the user session as well, and will likely drop support for running Xorg as root once they do. Your app will break everywhere, I can guarantee it. And to be quite honest, I'm tired of seeing you complain on this list without being even singularly helpful at all. You have provided virtually no constructive feedback and continue to attack the Fedora Project and its members. I do not know why you are even here, given that you seem to hate everything we do. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Re-Launching the Java SIG
On 5/18/20 8:24 PM, Michael Catanzaro wrote: Dude, chill out. We're not going to go back to running X as root. The Nvidia overclocking tool is just not important at all (seriously, who cares?). If you're upset their proprietary software doesn't work anymore, you can ask them nicely to fix it please... or ask for the source code, and see how far that gets you. ;) I'm well aware Fedora has no interest in correcting its breakage of backwards compatibility. If you'd actually read all the messages you'd realize it was all in the name of explaining why distros can't be trusted to package software and shouldn't do it, including Java applications. It went down this path naturally, as discussions tend to do and have on this very mailing list without my involvement. (someone tried changing the subject line, but as I pointed out, I was just trying to explain why, as objectively as possible, it wasn't as perfect of a solution as they claim) Of course, instead of reading everything, you decided to make a snide, unfriendly remark that probably violates the CoC. Given you have a Gnome email address I guess I can't say I'm surprised you take the position that you do. Afterall, Gnome has angered many great, talented, and independent extension developers including, IIRC, the developer of one of those most widely used tray icon extensions at the time who later quit out of frustration because Gnome kept breaking things. Indeed, people in general complain about Gnome not playing nice with others. I'd love to see CoC enforcement on this, but I feel like I'd die of old age before that ever happens. >Ugh, I just noticed the subject of this thread is Java SIG. Amazing how thoroughly this conversation has been derailed Maybe people shouldn't make claims that amount to "packaging software for each distro is the only way to do things" despite plenty of evidence to the contrary. The kernel gets rebased continuously throughout the life of a Fedora release. mesa updates are also possible when required, especially at the beginning of a release's lifetime. If there are bugs, you can work with the package maintainers The issues being talked about aren't specific to Fedora. Fedora does do a better job than average on these sort of things. ___ 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 ___ 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
Re: Re-Launching the Java SIG
On Monday, May 18, 2020 4:03:16 PM MST Ty Young wrote: > On 5/18/20 2:51 PM, Samuel Sieb wrote: > > > On 5/18/20 7:27 AM, Ty Young wrote: > > > >> The application was an Nvidia GPU overclocking utility written in > >> Java. When Fedora decided to disable running X. Org as root, it > >> resulted in the application no longer being able to adjust GPU/Memory > >> clocks, among possible other things. The software worked perfectly > >> fine on the latest versions of Ubuntu and Arch(and still does), but > >> not Fedora simply because of this. > > > > > > > > I figured it had to be something to do with NVidia because that's the > > only thing that would break due to that change. If you insist on > > using proprietary software (NVidia driver), then you take the risk of > > having problems like this. If NVidia would do the right thing and > > open their driver, then this could work. > > > > I completely obliterated this nonsensical argument last time this was > said in the thread Red Hat censored. Allow me to do so again. > > > There are a great many outstanding bugs, some of which have existed for > years, in the kernel, its Open Source drivers and in mesa as well as in > other projects like Gnome. No one has fixed those despite being Open > Source, and in some cases they even have pull requests but the > maintainers won't, for whatever reason, accept them. Linux distros > refuse to ship or backport the latest versions of the kernel or mesa, so > even if it was Open Source and in the kernel it'd take years for > everyone to get the fix, if ever. > > > You are arguing on theoretical nonsense that has no real basis in > reality, fueled by purely ideological hatred. > > > If it was Open Source and we were having this discussion, people like > yourself would just move the goalpost by saying something like "Why > don't you contribute?" like you always do. You don't care about fixing > the problem, you just want the drivers to be Open Source and in the > kernel. The issue itself be damned, you don't care whether it *ACTUALLY* > gets fixed or not. > > > Things like graphics drivers shouldn't be apart of the kernel, because > as Linux distros have proven, they can't be trusted to keep things > up-to-date or not to taint them... and the kernel moves wy too slow > for hardware releases anyway. AMD GPU owners who have the latest and > greatest have to wait many months for AMD to add support, and even then > there tends to be bugs. Nvidia? Every new GPU release support is > impressively rock solid that I've seen. > > > X. Org as root is **STILL** the standard and Fedora broke it. This is > why no one wants to support Linux: you constantly break your own > platform and then cry wolf when people who don't care about your > ideological nonsense refuse to fix their software that was working > perfectly fine before. No one has time to check on every new Linux > distro release to see what you broke and clearly, if the number of > unmaintained Fedora packages is any indicator, no one has time or > interest to package and properly maintain the Open Source software that > is available either. > > > All of this is completely ignoring the fact that an Open Source Nvidia > driver would most likely mean OC support exposed by system files like it > is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU > overclocking utilities have broken GPU support because of this, IIRC. > With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) > I can use and support nearly everything at once. > > > Unless you're going to personally volunteer to making a new, stable, > drop-in replacement C API if they do Open Source their driver or make a > new one and integrate it with the kernel? > > > Willing to bet you or anyone else here won't. What does this rant against Linux and Fedora have to do with the Java SIG? Please take this to another thread, preferably at supp...@nvidia.com. -- John M. Harris, Jr. ___ 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 8:24 pm, Michael Catanzaro wrote: Dude, chill out. We're not going to go back to running X as root. Ugh, I just noticed the subject of this thread is Java SIG. Amazing how thoroughly this conversation has been derailed ___ 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
Re: Re-Launching the Java SIG
Dude, chill out. We're not going to go back to running X as root. The Nvidia overclocking tool is just not important at all (seriously, who cares?). If you're upset their proprietary software doesn't work anymore, you can ask them nicely to fix it please... or ask for the source code, and see how far that gets you. ;) The kernel gets rebased continuously throughout the life of a Fedora release. mesa updates are also possible when required, especially at the beginning of a release's lifetime. If there are bugs, you can work with the package maintainers ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 7:08 PM, Solomon Peachy wrote: On Mon, May 18, 2020 at 06:03:16PM -0500, Ty Young wrote: Willing to bet you or anyone else here won't. FYI, this applies to you as well. You just proved my point: >If it was Open Source and we were having this discussion, people like yourself would just move the goalpost by saying something like "Why don't you contribute?" like you always do. You don't care about fixing the problem, you >just want the drivers to be Open Source and in the kernel. The issue itself be damned, you don't care whether it *ACTUALLY* gets fixed or not. You create these problems by refusing to play nice and then attempt to use it as leverage in order to attack people/organizations that don't bend the knee. In actuality the issue itself is just a stepping stone that isn't really cared about. A Gnome foundation member did this this exact same thing on Reddit recently, where graphical glitches would appear *only* on GTK windows that use the unified headerbar and were maxamized/de-maximized. The headerbar only part wasn't originally mentioned, and since the user bringing up the bug was using Nvidia, Nvidia was the one to get blamed for it. Once the unified headerbar only part was mentioned did the foundation member back track. It's why I don't believe for a second that issues like the Gnome 3 memory leaks while running Nvidia is Nvidia's fault. People point fingers based on who they like and agree with, not on technical facts. Crying wolves if there ever was any. (Yes, I know there are very real situations where Nvidia isn't playing nice themselves, but this isn't the case here) I'm not advocating for in-kernel drivers. AMD with their drivers has proven proven what a bad idea that is. I, for the most part, like where I'm at and the way Nvidia does things. If I'm against it, I don't see why I would be the one to do it. Surely it is the responsibility of those who want such a change to make sure that everything that existed before can continue to exist? I realize this requires that such arguments are being made in good faith and consider the perspectives and needs of everyone, which they aren't. - 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 ___ 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
Re: Re-Launching the Java SIG
On Mon, 18 May 2020 18:03:16 -0500, you wrote: >X. Org as root is **STILL** the standard and Fedora broke it. This is >why no one wants to support Linux: you constantly break your own >platform and then cry wolf when people who don't care about your >ideological nonsense refuse to fix their software that was working >perfectly fine before. X.org running as root likely is a security risk, and as such it is long past the point where somebody should have fixed it. And with time the other distros will probably also change X.org to run as a user instead of root (ie. once all the bugs are worked out). So not a very good arguement. ___ 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 06:03:16PM -0500, Ty Young wrote: > Willing to bet you or anyone else here won't. FYI, this applies to you as well. - 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 9:34 AM Ty Young wrote: > The "toolchain" isn't broken, other than Gradle developers not caring > about backwards compatibility but... It works for them, just as A toolchain with broken links scattered through it is not toolchain. Building up the .jar files as a hierarchy from source is not well supported, and has been vulnerable to many fractions. It's inherent to object oriented approaches where paying any notice outside your own momentgary layer of abstraction is considered a violation of your objectives and an anti-pattern. Many "autobuild as needed tools have had this problem, including CPAN, pip, ant, maven, and gradle. I dealt with a lot of this bundling tools for JPackage years ago, and still deal with it with other tools today, most recently with the rubygems dependencies for R10K. It's a problem. > The only thing I remember Gradle downloading when I built it locally is > a previous beta build in order to build the end final release. Maybe > there were a few other things I'm forgetting, someone else can correct me. Build them in "mock", which cuts off network access to the chroot cage building the software. I suspect you'll be unpleasantly surprised: it tends to show build-time downloads for rubygems, pip, and maven based software builds. > Yeah, no. > > > My software didn't magically break just for Fedora because of some bug > in my software. It broke because Fedora decided they wanted to do > something nearly no Linux distro does... something that has been the > defacto standard for many years. > ...and there are plenty of Open Source projects that don't have packages > yet people contribute to them. This isn't the early 2000 when barely > anyone has internet and sites like Github didn't exist. Sure, a distro > package increases visibility still, but it isn't all that matters. Heck, > the Windows 10 calculator app is sitting at over 1100 contributors right > now on Github. Inability or unwillingneds to follow deployment standards is one of the signs of software that should be avoided. If the authors follow > The point here is not that upstream should be blindly trusted, but > rather that downstream's poo **does*** stink and affect other people, > even those that don't specifically package for your distro. Well, yes. Gradle was highly applauded by some developers of my acquaintance. I'm curious what you find beneficial about it, because I've found it to be destabilizing. ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 2:51 PM, Samuel Sieb wrote: On 5/18/20 7:27 AM, Ty Young wrote: The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this. I figured it had to be something to do with NVidia because that's the only thing that would break due to that change. If you insist on using proprietary software (NVidia driver), then you take the risk of having problems like this. If NVidia would do the right thing and open their driver, then this could work. I completely obliterated this nonsensical argument last time this was said in the thread Red Hat censored. Allow me to do so again. There are a great many outstanding bugs, some of which have existed for years, in the kernel, its Open Source drivers and in mesa as well as in other projects like Gnome. No one has fixed those despite being Open Source, and in some cases they even have pull requests but the maintainers won't, for whatever reason, accept them. Linux distros refuse to ship or backport the latest versions of the kernel or mesa, so even if it was Open Source and in the kernel it'd take years for everyone to get the fix, if ever. You are arguing on theoretical nonsense that has no real basis in reality, fueled by purely ideological hatred. If it was Open Source and we were having this discussion, people like yourself would just move the goalpost by saying something like "Why don't you contribute?" like you always do. You don't care about fixing the problem, you just want the drivers to be Open Source and in the kernel. The issue itself be damned, you don't care whether it *ACTUALLY* gets fixed or not. Things like graphics drivers shouldn't be apart of the kernel, because as Linux distros have proven, they can't be trusted to keep things up-to-date or not to taint them... and the kernel moves wy too slow for hardware releases anyway. AMD GPU owners who have the latest and greatest have to wait many months for AMD to add support, and even then there tends to be bugs. Nvidia? Every new GPU release support is impressively rock solid that I've seen. X. Org as root is **STILL** the standard and Fedora broke it. This is why no one wants to support Linux: you constantly break your own platform and then cry wolf when people who don't care about your ideological nonsense refuse to fix their software that was working perfectly fine before. No one has time to check on every new Linux distro release to see what you broke and clearly, if the number of unmaintained Fedora packages is any indicator, no one has time or interest to package and properly maintain the Open Source software that is available either. All of this is completely ignoring the fact that an Open Source Nvidia driver would most likely mean OC support exposed by system files like it is with AMD instead of a nice C API. *Screw that*. Most of the AMD GPU overclocking utilities have broken GPU support because of this, IIRC. With Nvidia I have a nice stable APIs(Stable APIs in Linux? Impossible.) I can use and support nearly everything at once. Unless you're going to personally volunteer to making a new, stable, drop-in replacement C API if they do Open Source their driver or make a new one and integrate it with the kernel? Willing to bet you or anyone else here won't. ___ 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 ___ 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
Re: how to explicitly disable rawhide while building a spin/remix
On 5/17/20 5:07 PM, Globe Trotter via devel wrote: Thanks! Adding "--releasever=32" to the command addresses that problem. Btw, how do I get around a disk requirement? What causes an error like this? Error Summary - Disk Requirements: At least 137MB more space needed on the / filesystem. In /usr/share/spin-kickstarts/fedora-live-base.ks there's a line setting up the / partition: part / --size 5120 --fstype ext4 I expect you're going over that size. I don't know if you can override that later in your own kickstart file or if you'll have to use the flatten command that was mentioned and then edit it in the new file. ___ 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
Self Introduction: Andrzej Bylicki (Andy Mender)
Hello everyone! Introduction: After reading the Fedora docs on packaging, I decided I would like to join the Fedora project initially as a package maintainer/reviewer and perhaps later as a source code committer. Here's the bug report for the package I'd like to revive/unorphan: https://bugzilla.redhat.com/show_bug.cgi?id=1837107 About me: I'm a seasoned Python developer and Unix aficionado. I would consider myself above intermediate in Python (2 and 3), but also quite advanced in C/C++ and beginner in Go and Java. Currently, I work as a software engineer/devops, though I have plenty of experience in Unix system administration as well. Hope to hear from you all soon :) ~Andy ___ 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
[389-devel] please review: PR 51096 - Check for time skew and clock errors
https://pagure.io/389-ds-base/pull-request/51096 -- 389 Directory Server Development Team ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 7:27 AM, Ty Young wrote: The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this. I figured it had to be something to do with NVidia because that's the only thing that would break due to that change. If you insist on using proprietary software (NVidia driver), then you take the risk of having problems like this. If NVidia would do the right thing and open their driver, then this could work. ___ 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
Fedora 33 System-Wide Change proposal: Aarch64 Pointer Authentication & Branch Target Enablement
https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication == Summary == Arm Pointer Authentication (PAC) is a method of hardening code from Return Oriented Programming (ROP) attacks. It uses a tag in a pointer to sign and verify pointers. Branch Target Identification (BTI) is another code hardening method, where the branch/jump target is identified with a special landing pad instruction. Outside of some system support in glibc+kernel, packages gain the additional hardening by compiling with the -mbranch-protection= flag available in recent versions of GCC. In particular -mbranch-protection=standard enables both BTI and PAC, with backwards compatible to armv8.0 code sequences that activate on v8.3 (PAC) & v8.5 (BTI) enabled Arm machines. == Owner == * Name: [[User:jlinton| Jeremy Linton]] & ARM SIG * Email: jeremy.lin...@arm.com == Benefit to Fedora == PAC & BTI are code hardening features, they should serve to make fedora more resistant to a couple further classes of runtime attacks. By enabling this early, fedora is once again proven to be at the leading edge of security and linux development. If everything works as planned, this change will be invisible to the end user, except in cases where the applications will trap behaviour that appears to be caused by exploit attempts. == Scope == * Proposal owners: Work with individual package maintainers in the case of build failures or runtime exceptions. In the latter case there are two possibilities. First on v8.0 hardware, which is currently the most common, the additional instruction sequences are treated as NOP's and should be completely ignored by the hardware. It may be possible on v8.3/8.5 hardware that PAC or BTI may need additional tweaks for hand written assembly which interacts with PAC/BTI enabled code. * Other developers: Assure their packages continue to compile and pass unit/integration/etc tests on v8.0 hardware. Continue to monitor runtime problems on v8.3+ for bugs, vs exploit attempts. * Release engineering: (pending) * Policies and guidelines: At the moment, nothing needs to be changed as this should propagate as the default set of RPM build flags. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If everything works as planned, this should be transparent to the end user. == How To Test == Testing falls into two categories. Assuring that the packages continue to work on existing arm v8.0 hardware without PAC, and testing on PAC+BTI enabled hardware. For the most part the expectation from the fedora community is that package maintainers assure their packages continue to work on existing systems. PAC+ hardware will be in limited supply during the F33 development cycle, so the expectation is that owners of that hardware will perform more complete systemwide testing and report any defects found against the packages in question along with fixes or hardware access. == User Experience == (not supplied) == Dependencies == There are various gcc and kernel related changes which have already landed, but there continue to be a few cleanup patches trickling into the toolchain/compiler as problems are discovered. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Build affected packages with explicit compiler flags disabling the feature. Worse case the top level rpm macros reversion, and a rebuild of effected packages. Contingency deadline: Beta target. * Blocks release? No, except for major functionality loss due to core package bug. * Blocks product? No == Documentation == Arm pointer authentication is a technology designed to make software more robust by providing hardware assistance for code hardening. It protects pointers by cryptographically signing them and verifying their signatures when used, thereby mitigating certain attack vectors. Core support is provided to applications and libraries transparently via kernel and toolchain changes to generate hardended code. Branch Target identification, similarly provides landing pads, to harden code paths by restricting the processor from jumping into unexpected parts of a function. Further reference: * https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software/return-oriented-programming * https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf * https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf * https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf * https://lwn.net/Articles/789370/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Fedora 33 System-Wide Change proposal: Aarch64 Pointer Authentication & Branch Target Enablement
https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication == Summary == Arm Pointer Authentication (PAC) is a method of hardening code from Return Oriented Programming (ROP) attacks. It uses a tag in a pointer to sign and verify pointers. Branch Target Identification (BTI) is another code hardening method, where the branch/jump target is identified with a special landing pad instruction. Outside of some system support in glibc+kernel, packages gain the additional hardening by compiling with the -mbranch-protection= flag available in recent versions of GCC. In particular -mbranch-protection=standard enables both BTI and PAC, with backwards compatible to armv8.0 code sequences that activate on v8.3 (PAC) & v8.5 (BTI) enabled Arm machines. == Owner == * Name: [[User:jlinton| Jeremy Linton]] & ARM SIG * Email: jeremy.lin...@arm.com == Benefit to Fedora == PAC & BTI are code hardening features, they should serve to make fedora more resistant to a couple further classes of runtime attacks. By enabling this early, fedora is once again proven to be at the leading edge of security and linux development. If everything works as planned, this change will be invisible to the end user, except in cases where the applications will trap behaviour that appears to be caused by exploit attempts. == Scope == * Proposal owners: Work with individual package maintainers in the case of build failures or runtime exceptions. In the latter case there are two possibilities. First on v8.0 hardware, which is currently the most common, the additional instruction sequences are treated as NOP's and should be completely ignored by the hardware. It may be possible on v8.3/8.5 hardware that PAC or BTI may need additional tweaks for hand written assembly which interacts with PAC/BTI enabled code. * Other developers: Assure their packages continue to compile and pass unit/integration/etc tests on v8.0 hardware. Continue to monitor runtime problems on v8.3+ for bugs, vs exploit attempts. * Release engineering: (pending) * Policies and guidelines: At the moment, nothing needs to be changed as this should propagate as the default set of RPM build flags. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == If everything works as planned, this should be transparent to the end user. == How To Test == Testing falls into two categories. Assuring that the packages continue to work on existing arm v8.0 hardware without PAC, and testing on PAC+BTI enabled hardware. For the most part the expectation from the fedora community is that package maintainers assure their packages continue to work on existing systems. PAC+ hardware will be in limited supply during the F33 development cycle, so the expectation is that owners of that hardware will perform more complete systemwide testing and report any defects found against the packages in question along with fixes or hardware access. == User Experience == (not supplied) == Dependencies == There are various gcc and kernel related changes which have already landed, but there continue to be a few cleanup patches trickling into the toolchain/compiler as problems are discovered. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Build affected packages with explicit compiler flags disabling the feature. Worse case the top level rpm macros reversion, and a rebuild of effected packages. Contingency deadline: Beta target. * Blocks release? No, except for major functionality loss due to core package bug. * Blocks product? No == Documentation == Arm pointer authentication is a technology designed to make software more robust by providing hardware assistance for code hardening. It protects pointers by cryptographically signing them and verifying their signatures when used, thereby mitigating certain attack vectors. Core support is provided to applications and libraries transparently via kernel and toolchain changes to generate hardended code. Branch Target identification, similarly provides landing pads, to harden code paths by restricting the processor from jumping into unexpected parts of a function. Further reference: * https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software/return-oriented-programming * https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf * https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf * https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf * https://lwn.net/Articles/789370/ -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream 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:
Re: Working with epel7 on Fedora
On Monday, 18 May 2020 17.38.10 WEST Miro Hrončok wrote: > And I change it to: > > %python3_pkgversion 36 > %python3_other_pkgversion 34 > > When needed. It is tedious I think that we need some kind of rpmenv (mostly in terms of the configuration files but you get the idea). :-) I am only half-joking here. :-) -- José Abílio ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Re: looking for scipy on python 3.8 (RISCV Fedora Release 32)
On Mon, May 18, 2020 at 7:45 PM Arun Sukumaran Latha wrote: > > Yes please, do let me know if we can build thos one. > I will let you know. I found some dependencies misaligned due to some packages failing to build or failing to pass tests. I am slowly rebuilding/checking those, but that will take some time. Cheers, david > Regards, > Arun SL > > On Sun, May 17, 2020, 17:25 David Abdurachmanov > wrote: >> >> On Sun, May 17, 2020 at 1:52 PM Arun Sukumaran Latha >> wrote: >> > >> > Thanks David, >> > >> > That helped a lot. >> > >> > But unfortunately, we have ran into the next issue ie. wrt grpcio. >> > >> > [riscv@fedora-riscv tensorflow_pkg]$ sudo dnf install python3-grpcio >> > Last metadata expiration check: 0:17:52 ago on Sun 17 May 2020 06:20:36 AM >> > EDT. >> > Error: >> > Problem: conflicting requests >> > - nothing provides libpython3.7m.so.1.0()(64bit) needed by >> > python3-grpcio-1.20.1-2.fc31.riscv64 >> > - nothing provides python(abi) = 3.7 needed by >> > python3-grpcio-1.20.1-2.fc31.riscv64 >> > - nothing provides python3.7dist(six) >= 1.5.2 needed by >> > python3-grpcio-1.20.1-2.fc31.riscv64 >> > >> > I tried following >> > http://fedora.riscv.rocks/koji/packageinfo?packageID=23014 >> > but still do not see the same available for Python 3.8 >> > >> > let me know if you can help me here as well. >> >> This particular package failed to build last time (compile time errors). >> I can give a look into it. >> >> Cheers, >> david >> >> > >> > Regards, >> > Arun SL >> > >> > On Sun, May 17, 2020 at 2:02 PM David Abdurachmanov >> > wrote: >> >> >> >> On Sat, May 16, 2020 at 8:26 PM Arun Sukumaran Latha >> >> wrote: >> >> > >> >> > Hello All, >> >> > >> >> > I was working on getting tensorflow compiled within the RISCV Fedora >> >> > environment. >> >> > I am using the latest release 32 build. >> >> > Currently I am unable to install the dependent library, scipy due to >> >> > the same not being available for python 3.8.1 which is currently >> >> > installed. >> >> > >> >> > [riscv@fedora-riscv ~]$ sudo dnf install python3-scipy >> >> > Last metadata expiration check: 0:22:10 ago on Sat 16 May 2020 12:02:37 >> >> > PM EDT. >> >> > Error: >> >> > Problem: conflicting requests >> >> > - nothing provides libpython3.7m.so.1.0()(64bit) needed by >> >> > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64 >> >> > - nothing provides python(abi) = 3.7 needed by >> >> > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64 >> >> > (try to add '--skip-broken' to skip uninstallable packages) >> >> > [riscv@fedora-riscv ~]$ cat /etc/redhat-release >> >> > Fedora release 32 (Rawhide) >> >> > [riscv@fedora-riscv ~]$ python3 --version >> >> > Python 3.8.1 >> >> > >> >> > Can you please let me know if we can have the same soon? >> >> >> >> Hi, >> >> >> >> I have rebuilt scipy to Python 3.8 in Fedora/RISCV during mass rebuild >> >> for GCC 10, but it's not yet available directly from distro >> >> repository. >> >> >> >> You would need to install it directly from Fedora/RISCV Koji instance: >> >> http://fedora.riscv.rocks/koji/buildinfo?buildID=156446 >> >> >> >> Cheers, >> >> david >> >> ___ >> >> 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 >> > >> > ___ >> > 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 >> ___ >> 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 > > ___ > 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Petr Pisar writes: > On Sat, May 16, 2020 at 12:56:06PM +0200, Dominique Martinet wrote: > >> How should I go about with that? Open bz bugs to all the packages I >> listed? strongly suggesting to get things to move to /usr/share (17) >> and flatpak (suggest some kind of cache? not sure they'll be >> interested...) and environment-modules (not sure what to suggest >> there, I only have environment-modules because I need to test >> something with openmpi from time to time and it comes with it...) >> >> It might also make sense to have a packaging guideline suggesting to >> avoid /etc/bash_completion.d in favor of the /usr/share variant, I >> couldn't find anything here[1] but I might not have looked thoroughly >> enough... [1] >> https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > When you are at fixing a packaging of the completion scripts, please > make the dependency on bash-completion optional (Recommends: > bash-completion). It used to be a good habit to weaken the dependency > because not everyone is willing to pay the slow-down tax if he has no > use of the completion: I would suggest that at the point where you're sacrificing shell friendliness in favor of performance, it might be a good time to switch over to dash https://src.fedoraproject.org/rpms/dash Thanks, --Robbie 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
Re: Working with epel7 on Fedora
On Mon, 18 May 2020, Miro Hrončok wrote: On 18. 05. 20 18:23, Scott Talbert wrote: Any good workarounds for working with epel7 Python packages on Fedora? Mainly dealing with the fact that python3_pkgversion differs from Fedora to EPEL7. Ie, when doing 'fedpkg mockbuild' the SRPM will be generated with the wrong python3_pkgversion. I tried this, but it didn't seem to work: fedpkg --release epel7 srpm --define 'python3_pkgversion 36' There is a RFE open for +- this workaround to actually work: https://pagure.io/rpkg/issue/432 This other RFE should make that workaround not needed (and the description contains manual steps to create a valid SRPM to build in mock): https://pagure.io/rpkg/issue/495 Here is a relevant bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1767576 I don't work with epel7 packages daily, but I do have this in my ~/.rpmmacros: #python3_pkgversion 36 #python3_other_pkgversion 34 And I change it to: %python3_pkgversion 36 %python3_other_pkgversion 34 When needed. It is tedious :( Thanks for the tip on ~/.rpmmacros. That will be good enough for now I think. Just have to remember to undo it when I go back to Fedora. Scott___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[Bug 1837021] New: perl-Crypt-ECB-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1837021 Bug ID: 1837021 Summary: perl-Crypt-ECB-2.22 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Crypt-ECB Keywords: FutureFeature, Triaged Assignee: c...@wpi.edu Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: c...@wpi.edu, dd...@cpan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 2.22 Current version/release in rawhide: 2.21-13.fc33 URL: http://search.cpan.org/dist/Crypt-ECB/ 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/10253/ -- 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
[Bug 1837021] perl-Crypt-ECB-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1837021 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/modules/by-module/Crypt/Crypt-ECB-2.22.tar.gz to ./Crypt-ECB-2.22.tar.gz -- 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
Re: looking for scipy on python 3.8 (RISCV Fedora Release 32)
Yes please, do let me know if we can build thos one. Regards, Arun SL On Sun, May 17, 2020, 17:25 David Abdurachmanov < david.abdurachma...@gmail.com> wrote: > On Sun, May 17, 2020 at 1:52 PM Arun Sukumaran Latha > wrote: > > > > Thanks David, > > > > That helped a lot. > > > > But unfortunately, we have ran into the next issue ie. wrt grpcio. > > > > [riscv@fedora-riscv tensorflow_pkg]$ sudo dnf install python3-grpcio > > Last metadata expiration check: 0:17:52 ago on Sun 17 May 2020 06:20:36 > AM EDT. > > Error: > > Problem: conflicting requests > > - nothing provides libpython3.7m.so.1.0()(64bit) needed by > python3-grpcio-1.20.1-2.fc31.riscv64 > > - nothing provides python(abi) = 3.7 needed by > python3-grpcio-1.20.1-2.fc31.riscv64 > > - nothing provides python3.7dist(six) >= 1.5.2 needed by > python3-grpcio-1.20.1-2.fc31.riscv64 > > > > I tried following > http://fedora.riscv.rocks/koji/packageinfo?packageID=23014 > > but still do not see the same available for Python 3.8 > > > > let me know if you can help me here as well. > > This particular package failed to build last time (compile time errors). > I can give a look into it. > > Cheers, > david > > > > > Regards, > > Arun SL > > > > On Sun, May 17, 2020 at 2:02 PM David Abdurachmanov < > david.abdurachma...@gmail.com> wrote: > >> > >> On Sat, May 16, 2020 at 8:26 PM Arun Sukumaran Latha > >> wrote: > >> > > >> > Hello All, > >> > > >> > I was working on getting tensorflow compiled within the RISCV Fedora > environment. > >> > I am using the latest release 32 build. > >> > Currently I am unable to install the dependent library, scipy due to > the same not being available for python 3.8.1 which is currently installed. > >> > > >> > [riscv@fedora-riscv ~]$ sudo dnf install python3-scipy > >> > Last metadata expiration check: 0:22:10 ago on Sat 16 May 2020 > 12:02:37 PM EDT. > >> > Error: > >> > Problem: conflicting requests > >> > - nothing provides libpython3.7m.so.1.0()(64bit) needed by > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64 > >> > - nothing provides python(abi) = 3.7 needed by > python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64 > >> > (try to add '--skip-broken' to skip uninstallable packages) > >> > [riscv@fedora-riscv ~]$ cat /etc/redhat-release > >> > Fedora release 32 (Rawhide) > >> > [riscv@fedora-riscv ~]$ python3 --version > >> > Python 3.8.1 > >> > > >> > Can you please let me know if we can have the same soon? > >> > >> Hi, > >> > >> I have rebuilt scipy to Python 3.8 in Fedora/RISCV during mass rebuild > >> for GCC 10, but it's not yet available directly from distro > >> repository. > >> > >> You would need to install it directly from Fedora/RISCV Koji instance: > >> http://fedora.riscv.rocks/koji/buildinfo?buildID=156446 > >> > >> Cheers, > >> david > >> ___ > >> 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 > > > > ___ > > 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 > ___ > 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 > ___ 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
Re: Working with epel7 on Fedora
On 18. 05. 20 18:23, Scott Talbert wrote: Any good workarounds for working with epel7 Python packages on Fedora? Mainly dealing with the fact that python3_pkgversion differs from Fedora to EPEL7. Ie, when doing 'fedpkg mockbuild' the SRPM will be generated with the wrong python3_pkgversion. I tried this, but it didn't seem to work: fedpkg --release epel7 srpm --define 'python3_pkgversion 36' There is a RFE open for +- this workaround to actually work: https://pagure.io/rpkg/issue/432 This other RFE should make that workaround not needed (and the description contains manual steps to create a valid SRPM to build in mock): https://pagure.io/rpkg/issue/495 Here is a relevant bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1767576 I don't work with epel7 packages daily, but I do have this in my ~/.rpmmacros: #python3_pkgversion 36 #python3_other_pkgversion 34 And I change it to: %python3_pkgversion 36 %python3_other_pkgversion 34 When needed. It is tedious :( -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Working with epel7 on Fedora
Any good workarounds for working with epel7 Python packages on Fedora? Mainly dealing with the fact that python3_pkgversion differs from Fedora to EPEL7. Ie, when doing 'fedpkg mockbuild' the SRPM will be generated with the wrong python3_pkgversion. I tried this, but it didn't seem to work: fedpkg --release epel7 srpm --define 'python3_pkgversion 36' Thanks, Scott ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[EPEL-devel] Re: Incompatible upgrade for oniguruma in EPEL 7
+1 makes sense to me; also side-note, in my testing jq seems to work just fine built against oniguruma 6.9.4 ___ 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
Summary/Minutes from today's FESCo Meeting (2020-05-18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 = #fedora-meeting-1: FESCO (2020-05-18) = Meeting started by sgallagh at 14:59:49 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-18/fesco.2020-05-18-14.59.log.html . Meeting summary - --- * init process (sgallagh, 14:59:49) * #2384 Election Interview Questions — FESCo (Fedora 32) (sgallagh, 15:03:33) * AGREED: "FESCo will go with option 3 from https://pagure.io/fesco/issue/2384 with a minor edit to phrasing of question 3." (sgallagh, 15:23:32) * The edit in question: s/needs are at odds/needs conflict in incompatible ways/ (sgallagh, 15:24:57) * Next week's chair (sgallagh, 15:25:48) * ACTION: zbyszek to chair the 2020-05-25 meeting (sgallagh, 15:26:54) * Open Floor (sgallagh, 15:27:01) * LINK: https://pagure.io/fesco/issue/2114 (dcantrell, 15:28:53) * Datacenter Move Status Update (sgallagh, 15:31:33) Meeting ended at 15:39:44 UTC. Action Items - * zbyszek to chair the 2020-05-25 meeting Action Items, by person - --- * zbyszek * zbyszek to chair the 2020-05-25 meeting * **UNASSIGNED** * (none) People Present (lines said) - --- * sgallagh (46) * dcantrell (23) * zodbot (18) * zbyszek (14) * mhroncok (12) * nirik (11) * bookwar (9) * contyk (4) * mhroncok_cell (4) * ignatenkobrain (3) * decathorpe (3) * bcotton (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl7CrwYACgkQRduFpWgo bRG8Dgv+Nr9kv2K2SGSCL/OkfN3a/MBt8Ok1DWkuXZcBgVbdKoNHXiowPfG99zJu UypkbeLJPmJg1kIUfeypITgrh4esyS2PjL2A1M6itpCBtdyebH1fHbo62wEjhbUJ 3MoKl4QBXUi0bThR47rkzX6MZgqGeWKbqNfjwYT31w6bFmM0BzL30LTgGf51m4ZN Ts0OYY6JIQdmXqMt4cRz/tHAQRHei1wuSavAm3fdl/1eMOgiZPMo4lShwkLiH6Hp OlSlptFWcoFVhAW6Ms7B3MUYgKCRf+zuilIfmaAva5P6YmJYtmx5tyAoOv6rPu4e wf1bnVLuJ6HT3GvNUslIeP8JbQ6u2pT1UQP6ngZRhPcdkzDLQQOn21ZG63Ptfwgt m8uHdCQGDK1gXPbWs0h1q70Ifj99Gmt6yygezreUBRXDVqqrq7t/Pn+P4zDGD7ee SAK6cmR/iLpmkh3Ebq2Ze99jmJxhEVh6ebQ6QMSN5dekFrIpXS6M4vcIT84o9RpB 7N30nimb =+h5z -END 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
Re: Many packages unnecessarily link to libpython
- Original Message - > From: "Charalampos Stratakis" > To: "Development discussions related to Fedora" > > Sent: Friday, May 15, 2020 8:12:00 PM > Subject: Many packages unnecessarily link to libpython > > pyotherside m4rtink I can report this is expected and correct. PyOtherSide provides QML <-> Python bindings by embedding a Python interpreter in a QML Plugin, so that QML code can run Python code as needed. ___ 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
Re: Why we package Rust crates
- Original Message - > From: "Kushal Das" > To: devel@lists.fedoraproject.org > Sent: Friday, May 15, 2020 10:08:34 AM > Subject: Re: Why we package Rust crates > > On 5/15/20 1:05 AM, Igor Raits wrote: > > Hello, > > > > This email attempts to answer some frequently asked questions about > > Rust SIG packaging of crates. For those who don't know what a "crate" > > is: it is the name for a collection of functionality in Rust, similar > > to libraries (C/C++), modules (Python/Perl/PHP), gems (Ruby), etc. > > > Thank you all for the hard work. It is amazing to see so many nice tools > available in Fedora. Thanks a lot as well! :) It really seems the best that can be done with what Rust makes possible at the moment. And IMHO it is really a shame Rust still does not have a stable ABI/propert dynamic linking support. That would indeed make things so much easier, more efficient and more secure... > > Kushal > -- > Public Interest Technologist, Freedom of the Press Foundation > CPython Core Developer > Director, Python Software Foundation > https://kushaldas.in > ___ > 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 > ___ 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
Re: LibRaw 0.20 Beta; soname bump
On Mon, May 18, 2020 at 3:43 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, May 13, 2020 at 02:38:58PM +0200, Kalev Lember wrote: > > On 5/12/20 20:42, Gwyn Ciesla via devel wrote: > > >Everything is now rebuild, except for elementary-photos and shotwell, > which are failing for a reason I don't totally understand yet; they build > on local rawhide and in mock but not koji. Investigating. > > > > I looked into the shotwell build failure and did a PR to fix that: > > https://src.fedoraproject.org/rpms/LibRaw/pull-request/1 > > > > Sadly I managed to push the branch to the rpms/ namespace instead of > > my fork :( Grr. > > We should be able to delete such branches soon. > See https://pagure.io/releng/pull-request/9454 ;) > Ah nice! Thanks for working on this. -- Kalev ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 9:14 AM, Fabio Valentini wrote: On Mon, May 18, 2020 at 3:34 PM Ty Young wrote: On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote: My software didn't magically break just for Fedora because of some bug in my software. It broke because Fedora decided they wanted to do something nearly no Linux distro does... something that has been the defacto standard for many years. those comments are just spreading FUD without adding anything worthwhile to the discussion. Please, either provide those details - so we can do better in the future - or stop. Fair enough. The application was an Nvidia GPU overclocking utility written in Java. When Fedora decided to disable running X. Org as root, it resulted in the application no longer being able to adjust GPU/Memory clocks, among possible other things. The software worked perfectly fine on the latest versions of Ubuntu and Arch(and still does), but not Fedora simply because of this. Thanks, 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 ___ 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
Re: Re-Launching the Java SIG
On Mon, May 18, 2020 at 3:34 PM Ty Young wrote: > On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote: > My software didn't magically break just for Fedora because of some bug > in my software. It broke because Fedora decided they wanted to do > something nearly no Linux distro does... something that has been the > defacto standard for many years. Ty, You continue telling us that "Fedora" (sic!) broke your software, but without actually telling us - which broken program it is that you're talking about, and - which packages / changes in fedora caused the breakage, those comments are just spreading FUD without adding anything worthwhile to the discussion. Please, either provide those details - so we can do better in the future - or stop. Thanks, 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
Fedora-Cloud-31-20200518.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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
RFC: Automatically generated BuildRequires for maven-based Java projects
Good $LOCAL_TIME_OF_DAY, I've been working on experimental support for automatically generating BuildRequires for maven-based Java projects, and it's now available for testing in rawhide (and in fedora 32, for local testing). There's no "macro support" for this yet, because it's still work-in-progress, though when it proves useful support for it might eventually get merged into the Java packaging macros directly. The good new is: it should basically "just work" if your package isn't doing anything weird, but this is Java we're talking about, so there's at least three limitations I can think of right now (the bad news): 1. no built-in blacklist for irrelevant plugins yet (e.g. maven-release-plugin) 2. no support for different profiles yet 3. no support for plugins that add additional dependencies in their configuration There are workarounds for the first two limitations: 1. It's pretty easy to just disable those plugins manually in %prep with "%pom_remove_plugin :maven-foo-plugin". 2. If you know ahead of time which submodules will get activated (e.g. based on a previous package build), just specify those modules on the mvn-genbr command line instead of letting mvn-genbr fail to find them. 3. just continue to specify those non-discoverable dependencies manually Usage in .spec files should be pretty simple, and similar to how other tools handle generated BuildRequires: - replace all java / "mvn(foo:bar)" dependencies with "BuildRequires: mvn-genbr", - but keep "BuildRequires: maven-local" (this is not automatically generated). - keep your "pom.xml" modifications in %prep, as usual (e.g. removing unnecessary maven plugins, changing dependencies, modifying XML with XPath queries) - add the following section to your .spec after %prep: %generate_buildrequires mvn-genbr -t . If you're not running the test suite (%mvn_build -f), then drop the -t / --with-tests flag. If the root directory of the maven project is not the toplevel directory, specify the name of the root directory / directories instead of "." (mvn-genbr accepts multiple arguments for this purpose. use "mvn-genbr --help" for current list of command line options). If you want to check out what automatic dependencies mvn-genbr will generate for your package, you can try it without kicking off a package build by dnf-installing "mvn-genbr" (available fedora 32+), and running it with the same arguments as in your .spec file in the source directory that's generated and processed by "fedpkg prep". Comparisons between the generated dependency lists and those that were curated "manually" would be of interest, especially for bug reports :) Since this is still work-in-progress (though it works for a few simple packages I tried it with), please feel free to report your experiences, and - more importantly - open issues when the tool either crashes (it shouldn't, since the POM parser successfully parsed all non-broken maven project files from all fedora packages), or when it generates too many (not that problematic) or too few (not so good) dependencies. The code for the POM parser and mvn-genbr lives in this project on pagure: https://pagure.io/ironthree/pommes Go forth and break my code! 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
Re: Re-Launching the Java SIG
Le lundi 18 mai 2020 à 08:34 -0500, Ty Young a écrit : > > The "toolchain" isn't broken, other than Gradle developers not > caring about backwards compatibility but... It works for them, just > as constantly breaking internal kernel APIs works for the Linux > kernel The difference, is that you can build a new kernel, while running an old kernel. the kernel is not constantly breaking external kernel APIs like gradle breaks the external gradle APIs a new gradle needs to be built (when building gradle with gradle, the new build is a consumer of external gradle APIS) -- Nicolas Mailhot ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 8:34 AM, Ty Young wrote: ...and there are plenty of Open Source projects that don't have packages yet people contribute to them. This isn't the early 2000 when barely anyone has internet and sites like Github didn't exist. Sure, a distro package increases visibility still, but it isn't all that matters. Heck, the Windows 10 calculator app is sitting at over 1100 contributors right now on Github. I meant VSCode, not the calculator app... although that probably has a fair bit of contributors too. ___ 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
Re: LibRaw 0.20 Beta; soname bump
On Wed, May 13, 2020 at 02:38:58PM +0200, Kalev Lember wrote: > On 5/12/20 20:42, Gwyn Ciesla via devel wrote: > >Everything is now rebuild, except for elementary-photos and shotwell, which > >are failing for a reason I don't totally understand yet; they build on local > >rawhide and in mock but not koji. Investigating. > > I looked into the shotwell build failure and did a PR to fix that: > https://src.fedoraproject.org/rpms/LibRaw/pull-request/1 > > Sadly I managed to push the branch to the rpms/ namespace instead of > my fork :( Grr. We should be able to delete such branches soon. See https://pagure.io/releng/pull-request/9454 ;) Zbyszek ___ 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
Re: LibRaw 0.20 Beta; soname bump
Il 11/05/20 22:33, Gwyn Ciesla via devel ha scritto: > I'm building LibRaw 0.20 Beta 1 for rawhide, along with all direct > consumers, in a multi-stage chain build, today, including the following: > > ... > > FYI Also kstars has BR on LibRaw. I've triggered a rebuild just now. Mattia ___ 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
Re: Re-Launching the Java SIG
On 5/18/20 7:35 AM, Nicolas Mailhot via devel wrote:
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
Hello,
On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
devel@lists.fedoraproject.org> wrote:
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
On Fri, 15 May 2020 08:02:34 +0200
Michal Srb wrote:
An aside, just to clarify for myself. That means that all Java
apps
are
the equivalent of statically linked, right? And are related to
things
like flatpaks and modules?
No, that’s similar to venv everywhere. The language has bytecode-
sharing objects. Java upstreams just got used not to share those
executable objects between projects, not to version them properly,
not
to manage their ABI breaks, and to change things in the local copy
instead of contributing changes to the original project.
Well... Java upstreams share their JARs by uploading them to a public
Maven repository (Maven Central most of the time). And in the vast
majority of cases there are also "source-JARs" (containing source
code) uploaded alongside the bytecode JARs. I am simplifying things
here a bit, but basically when Java open source projects want to ship
their apps, they fetch pre-built dependencies from Maven Central,
compile their apps, and bundle everything (app bytecode + pre-built
deps) in a tarball. And that's what they ship.
If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.
That’s non-free software open source to its extreme. The code is
available for a dev to copy and resell at his next work, but
everything is organised (at the human not technical level) so it’s
not possible to reuse the bytecode directly without paying someone
to copy and fork the original code that this bytecode was generated
from in the next project.
I'd like to know more about this if you don't mind. This is
definitely not how open source Java apps are developed.
Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.
The "toolchain" isn't broken, other than Gradle developers not caring
about backwards compatibility but... It works for them, just as
constantly breaking internal kernel APIs works for the Linux kernel or
running X. Org as user does for Fedora. No-one involved with the Linux
kernel or the distros has a right to complain, y'all do it to other
people all the time.
The only thing I remember Gradle downloading when I built it locally is
a previous beta build in order to build the end final release. Maybe
there were a few other things I'm forgetting, someone else can correct me.
And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).
Yeah, no.
My software didn't magically break just for Fedora because of some bug
in my software. It broke because Fedora decided they wanted to do
something nearly no Linux distro does... something that has been the
defacto standard for many years.
Willing to bet money Gnome has received a great many bug reports because
of extensions Linux distros ship by default as well.
...and there are plenty of Open Source projects that don't have packages
yet people contribute to them. This isn't the early 2000 when barely
anyone has internet and sites like Github didn't exist. Sure, a distro
package increases visibility still, but it isn't all that matters. Heck,
the Windows 10 calculator app is sitting at over 1100 contributors right
now on Github.
The point here is not that upstream should be blindly trusted, but
rather that downstream's poo **does*** stink and affect other people,
even those that don't specifically package for your distro.
As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.
___
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
Re: how to explicitly disable rawhide while building a spin/remix
install the fedora-kickstarts rpm edit the fedora-repo.ks to use fedora-repo-not-rawhide.ks ksflatten your kickstart and it will use the normal fedora repos (when all else fails talk to the Fedora Respin SiG in #fedora-respins) ___ 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
Re: fedpkg fork broken?
Richard Shaw wrote on Mon, May 18, 2020: > > Seems to work for me: > > Don't know what's wrong then... I went back and re-read your first mail, it is possible it doesn't work on one of your own projects? I'm not sure how much sense there is in forking your own repo... > Ok, so this is the opposite workflow where you only clone the main repo and > create a remote for your fork. Would be nice if this was documented but > google didn't turn up anything useful for me. The only documentation I > could find still says to do the opposite. Clone your fork and add the > original as the remote (github style). Well you have to clone *something* so fedpkg would know what to fork. I've just done a "fedpkg clone" of a repo to look at it, then assumed fork would do what hitting fork does on the web ui and this is pretty close. I wouldn't want the command to change what origin is, although I'm not sure how `fedpkg push` works I intended to use plain git commands for that... OTOH something did not work, the remote was setup for ssh://a...@pkgs.fedoraproject.org/... and I had assumed there is a magic account with all ssh public keys that does redirection (like github does, everything happens under user 'git') but that didn't work; I had to change the url to specify my user. I might need to specify --user xyz next time... -- 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
Schedule for Mondays's FESCo Meeting (2020-05-18)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2020-05-18 15:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
Proposal: add an optional Feedback section to Change proposals
https://pagure.io/fesco/issue/2394
DECISION (+7, 0, -0)
Fedora 33 System-Wide Change: Boost 1.73 upgrade
https://pagure.io/fesco/issue/2388
DECISION (+4, 0, -0)
Add preset to enable iscsi.service and {iscsid,iscsiuio}.socket
https://pagure.io/fesco/issue/2386
DECISION (+3, 0, -0)
F33 System-Wide Change: Introduce module Obsoletes and EOL
https://pagure.io/fesco/issue/2364
DECISION (+5, 0, -0)
= Followups =
= New business =
#topic #2384 Election Interview Questions — FESCo (Fedora 32)
https://pagure.io/fesco/issue/2384
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
-BEGIN PGP SIGNATURE-
iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl7CgsoACgkQRduFpWgo
bRFd3gv9F/JgOH+t3iE0EjMYgHv/mwZ1uzau4DEaP29QC4exck7zvrZRWZR+VOeq
wLvL6r64V/huDCP5lb8rfRnmeTfLkFS1uHQeGJscKZXCgbzT82S3Y8WOGeZc+POC
VPV061n3w9dPCcnt6cFsasLtqtpf3iED6QJzoTntdhS/7XUkd7Bebl0ZBGT42GDY
s7gSWLrQj1lp70W6AX0gBUVA5i/0beVXVsjzN26j63LsDq1OYYaLBNGAF7LgSPPy
JRsXAMEd3fy5uOkhiNxQlJHujZHJgnGoyQzMPKsECgV4dBOtHdpDWvjLkx3kMB8f
jE+zODVmeFNm9AjFwbQPyfvTAAVdWtGCUXIBxVaQOUtH/OXZCLORAD0bQkl51J0V
UdKpi0xVizn/d57uP0UoeT/Bp3qk4F2v5/gzY2PAXgvOaNjs1Gy91OjrxX2G2AdU
7/eivm8ltVCJkNFbQ93J2INKbak3S4dJrNL263H+Skx8xW/TP0rEgQoW5k/uZCmU
di3M4a1F
=/ERh
-END 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
Re: fedpkg fork broken?
On Mon, May 18, 2020 at 7:25 AM Dominique Martinet wrote: > Richard Shaw wrote on Mon, May 18, 2020: > > I checked src.fp.o/settings and even though my key was still valid, it > was > > going to expire this month so I went ahead and generated a new api token > > and saved it in the specified location: > > ~/.config/rpkg/fedpkg.conf > > I actually hadn't used it yet, so tried just now. > Seems to work for me: > Don't know what's wrong then... > $ fedpkg fork > Fork of the repository has been created: > https://src.fedoraproject.org/fork/martinetd/kernel-tools > $ git remote -v > martinetd ssh:// > a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (fetch) > martinetd ssh:// > a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (push) > origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (fetch) > origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (push) > > so to answer your question on the other thread, it operates in place and > adds a remote. Exactly what I would have wanted :) > Ok, so this is the opposite workflow where you only clone the main repo and create a remote for your fork. Would be nice if this was documented but google didn't turn up anything useful for me. The only documentation I could find still says to do the opposite. Clone your fork and add the original as the remote (github style). > Regarding your problem, did you add the ACL "Fork a project" on your API > key? > Toggled everything on, went back and verified. Thanks, Richard ___ 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
Re: Re-Launching the Java SIG
Le lundi 18 mai 2020 à 14:12 +0200, Michal Srb a écrit :
> Hello,
>
> On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel <
> devel@lists.fedoraproject.org> wrote:
> > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit :
> > > On Fri, 15 May 2020 08:02:34 +0200
> > > Michal Srb wrote:
> > >
> > > An aside, just to clarify for myself. That means that all Java
> > apps
> > > are
> > > the equivalent of statically linked, right? And are related to
> > > things
> > > like flatpaks and modules?
> >
> > No, that’s similar to venv everywhere. The language has bytecode-
> > sharing objects. Java upstreams just got used not to share those
> > executable objects between projects, not to version them properly,
> > not
> > to manage their ABI breaks, and to change things in the local copy
> > instead of contributing changes to the original project.
>
> Well... Java upstreams share their JARs by uploading them to a public
> Maven repository (Maven Central most of the time). And in the vast
> majority of cases there are also "source-JARs" (containing source
> code) uploaded alongside the bytecode JARs. I am simplifying things
> here a bit, but basically when Java open source projects want to ship
> their apps, they fetch pre-built dependencies from Maven Central,
> compile their apps, and bundle everything (app bytecode + pre-built
> deps) in a tarball. And that's what they ship.
If Java finally left the stone age, there should be no problem building
the same artefacts in rpm, installing them in a central place like
%{_datadir}/java or %{_libdir}/java, and making it a package other java
software can buildrequire. We managed it in Go, and we did not even
have a language versionning infra to build upon.
> > That’s non-free software open source to its extreme. The code is
> > available for a dev to copy and resell at his next work, but
> > everything is organised (at the human not technical level) so it’s
> > not possible to reuse the bytecode directly without paying someone
> > to copy and fork the original code that this bytecode was generated
> > from in the next project.
>
> I'd like to know more about this if you don't mind. This is
> definitely not how open source Java apps are developed.
Free software is end user not dev oriented. Stallman wanted his printer
driver to work. The GPL gives rights to the recipient. As long as the
toolchain is broken enouth even huge downstreams like distros are
unable to rebuild the source easily, you have something that may be
open source, but does not function as effective free software.
And when downstreaming is broken upstreaming is broken too (who will
bother contributing to an upstream when things do not flow the other
way?).
As spot wrote a long time ago, the only useful form of open source for
Fedora (and a lot of other entities) is free software.
--
Nicolas Mailhot
___
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
Re: how to explicitly disable rawhide while building a spin/remix
Thanks! How do I get around this issue? I have setenforce set at 0. Also, why does the issue go away when I reduce the packages to be packed in the remix/spin? On Monday, May 18, 2020, 5:26:35 AM CDT, Petr Pisar wrote: On Mon, May 18, 2020 at 12:07:38AM +, Globe Trotter via devel wrote: > Thanks! Adding "--releasever=32" to the command addresses that problem. > Btw, how do I get around a disk requirement? What causes an error like this? > > Error Summary- > Disk Requirements: > At least 137MB more space needed on the / filesystem. > DNF returns this error when the file system is read-only. -- Petr___ 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 ___ 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
Re: fedpkg fork broken?
Richard Shaw wrote on Mon, May 18, 2020: > I checked src.fp.o/settings and even though my key was still valid, it was > going to expire this month so I went ahead and generated a new api token > and saved it in the specified location: > ~/.config/rpkg/fedpkg.conf I actually hadn't used it yet, so tried just now. Seems to work for me: $ fedpkg fork Fork of the repository has been created: https://src.fedoraproject.org/fork/martinetd/kernel-tools $ git remote -v martinetd ssh://a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (fetch) martinetd ssh://a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (push) origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (fetch) origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (push) so to answer your question on the other thread, it operates in place and adds a remote. Exactly what I would have wanted :) Regarding your problem, did you add the ACL "Fork a project" on your API key? I didn't wait after creating it. > GRIPE: You can't actually see the whole key in the website even though I'm > on a 1080p monitor and have a ton of whitespace on either side. So I copied > and pasted it again. No dice. I agree on this one. Double-clicking worked though, whole key was in selection on firefox. fedora 32 with updates-testing enabled if this matters. Cheers, -- 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
fedpkg fork broken?
I'm trying this for the first time (hadn't even noticed it was there!). I've been using the src.fp.o github style forking from the web. I cloned a random project of mine and then tried: $ fedpkg fork Could not execute do_distgit_fork: The following error occurred while creating a new fork: Invalid or expired token. Please visit https://src.fedoraproject.org/settings#nav-api-tab to get or renew your API token. For invalid or expired token refer to "fedpkg fork -h" to set a token in your user configuration. I checked src.fp.o/settings and even though my key was still valid, it was going to expire this month so I went ahead and generated a new api token and saved it in the specified location: ~/.config/rpkg/fedpkg.conf But I still get the same message 10 minutes later. GRIPE: You can't actually see the whole key in the website even though I'm on a 1080p monitor and have a ton of whitespace on either side. So I copied and pasted it again. No dice. Thanks, Richard ___ 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
Re: Re-Launching the Java SIG
Hello, On Sat, May 16, 2020 at 11:24 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote: > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit : > > On Fri, 15 May 2020 08:02:34 +0200 > > Michal Srb wrote: > > > > An aside, just to clarify for myself. That means that all Java apps > > are > > the equivalent of statically linked, right? And are related to > > things > > like flatpaks and modules? > > No, that’s similar to venv everywhere. The language has bytecode- > sharing objects. Java upstreams just got used not to share those > executable objects between projects, not to version them properly, not > to manage their ABI breaks, and to change things in the local copy > instead of contributing changes to the original project. > Well... Java upstreams share their JARs by uploading them to a public Maven repository (Maven Central most of the time). And in the vast majority of cases there are also "source-JARs" (containing source code) uploaded alongside the bytecode JARs. I am simplifying things here a bit, but basically when Java open source projects want to ship their apps, they fetch pre-built dependencies from Maven Central, compile their apps, and bundle everything (app bytecode + pre-built deps) in a tarball. And that's what they ship. JARs in Maven Central are always versioned, and people who want to use them pick specific versions, so no version ranges... (although technically possible of course) And JARs in Maven Central are immutable, so if you want to use such pre-built JAR, you pick a specific version for your app and it will never change. What you're describing sounds like the 2005-ish way of developing Java applications :) The Java open source world has evolved since then. > That’s non-free software open source to its extreme. The code is > available for a dev to copy and resell at his next work, but everything > is organised (at the human not technical level) so it’s not possible to > reuse the bytecode directly without paying someone to copy and fork the > original code that this bytecode was generated from in the next > project. > I'd like to know more about this if you don't mind. This is definitely not how open source Java apps are developed. Thanks, Michal > > The practical effect is technical stagnation and market capture by deep > pocket companies. > > -- > Nicolas Mailhot > ___ > 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 > ___ 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
On Mon, May 18, 2020 at 6:29 AM Dominique Martinet wrote: > > On the pagure side, I assume the process is something along the lines of: > - fedpkg clone pkg && cd pkg > - modify things > - fedpkg fork > - push in fork > - got create PR in the web interface? > I would think you should fork first, otherwise aren't you making changes to the original repo? Amazingly I've been using the src.fp.o fork option, I wasn't even aware that there was a fork option in fedpkg. I need to play around with it. Does it fork in place or create a new directory? Thanks, Richard ___ 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
[Bug 1836658] perl-DateTime-Format-Natural-1.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836658 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DateTime-Format-Natura ||l-1.09-1.fc33 Resolution|--- |RAWHIDE Last Closed||2020-05-18 11:41:26 -- 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Zbigniew Jędrzejewski-Szmek wrote on Mon, May 18, 2020:
> > > How should I go about with that? Open bz bugs to all the packages I
> > > listed?
> >
> > I would suggest to directly create pull requests on pagure (with a
> > reference to this thread), as that will make it more likely that this
> > change will actually happen.
>
> +1
I feel like I'm being dumped the work wholesale... :)
This unfortunately might not be that simple, I've just checked from the
first I'm most likely to use (perf) and the install path is decided by
the kernel makefiles.
The kernel ships three completion scripts, two have been updated to
install to /usr/share/bash-completion/completions by default (so
bpftool will just be a matter of NOT setting bash_compdir in the
specfile and just a spec update) but perf will need a kernel patch
first. I believe this was not fluke the first project I looked that does
it that way, there really is some work required... I don't mind going
through it one item at a time, including the kernel patch that will
break packaging anyway, but this really isn't as simple as pagure PRs,
it might be possible to just 'mv' the file there after install but
that's not a good solution.
On the pagure side, I assume the process is something along the lines of:
- fedpkg clone pkg && cd pkg
- modify things
- fedpkg fork
- push in fork
- got create PR in the web interface?
I'll work on it as time permits...
> Please also consider submitting a PR for the packaging guidelines.
> I think this is a change we generally agree on, and a PR should make
> the whole process faster.
This file ?
https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages/index.adoc
Should it be something specific about bash-completion, or something more
generic about avoiding files in etc when possible?
To give a few examples:
- /etc/systemd/system -> /usr/lib/systemd/system
- /etc/udev/rules.d -> /usr/lib/udev/rules.d
- /etc/tmpfiles.d -> /usr/lib/tmpfiles.d
- /etc/bash_completion.d -> /usr/share/bash-completion/completions
I'm sure there are more and don't see anything about any of these... Oh
actually tmpfiles.d is mentionned but not about avoiding /etc, and all
the others have a macro (%{_unitdir}, %{_udevrulesdir} and
%{_tmpfilesdir} respectively) so can be considered as 'autodocumented' ?
> Also:
> $ repoquery --whatprovides '/etc/bash_completion.d/*' --qf '%{name}'
Well... I'll start with what I have on my system as the egoist
person I am :)
Thanks for the full list though.
--
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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
On Sat, May 16, 2020 at 01:35:52PM +0200, Dan Čermák wrote:
> Hi Dominique,
>
> Dominique Martinet writes:
>
> > *snip*
> >
> > 341 to 130ms is a good start I guess, the rest of the waiting time
> > probably now outweights bash and will get some looking at at a later
> > point, but might as well start somewhere.
>
> That's quite the improvement! Good job and thanks for looking into that!
>
> >
> > How should I go about with that? Open bz bugs to all the packages I
> > listed?
>
> I would suggest to directly create pull requests on pagure (with a
> reference to this thread), as that will make it more likely that this
> change will actually happen.
+1
> > strongly suggesting to get things to move to /usr/share (17) and
> > flatpak (suggest some kind of cache? not sure they'll be
> > interested...) and environment-modules (not sure what to suggest
> > there, I only have environment-modules because I need to test
> > something with openmpi from time to time and it comes with it...)
> >
> >
> > It might also make sense to have a packaging guideline suggesting to
> > avoid /etc/bash_completion.d in favor of the /usr/share variant, I
> > couldn't find anything here[1] but I might not have looked thoroughly
> > enough...
>
> Afaik we don't have an entry in the packaging guidelines about bash
> completion files. Maybe the packaging committee should look into that?
Please also consider submitting a PR for the packaging guidelines.
I think this is a change we generally agree on, and a PR should make
the whole process faster.
Also:
$ repoquery --whatprovides '/etc/bash_completion.d/*' --qf '%{name}'
Last metadata expiration check: 0:01:09 ago on Mon 18 May 2020 12:42:34 PM CEST.
RBTools
abrt-tui
authselect
bash-completion
beesu
boinc-client
bpftool
bti
cargo
cekit-bash-completion
ceph-common
clusterssh
composer-cli
condor
dahdi-tools
dbus-glib-devel
drbd-bash-completion
drush
epix-bash-completion
fcoe-utils
freeipa-client
fzf
gdal
git-extras
glusterfs-cli
gmic
icedtea-web
iprutils
kdocker
koschei-admin
ledger
lilv
lizardfs-client
lldpad
lnst-ctl
lnst-slave
lttng-tools
lyx-common
monotone
mpc
openscap-scanner
openvswitch
origin
origin-clients
pass-otp
pass-pwned
pdc-client
perf
perl-App-Cme
perl-Config-Model-Itself
perl-Dist-Zilla
phoronix-test-suite
pmempool
publican
python3-argcomplete
python3-catkin_lint
python3-cinderclient
python3-doit
python3-glanceclient
python3-heatclient
python3-manilaclient
python3-mistralclient
python3-novaclient
python3-wstool
quilt
ratools
reptyr
salt
scl-utils
sheepdog
singularity
stgit
tarsnap-bash-completion
tmt
topgit
torsocks
trace-cmd
tracer-common
tuxpaint
udisks
vrms-rpm
xen-runtime
Zbyszek
___
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
Re: how to explicitly disable rawhide while building a spin/remix
On Mon, May 18, 2020 at 12:07:38AM +, Globe Trotter via devel wrote: > Thanks! Adding "--releasever=32" to the command addresses that problem. > Btw, how do I get around a disk requirement? What causes an error like this? > > Error Summary- > Disk Requirements: > At least 137MB more space needed on the / filesystem. > DNF returns this error when the file system is read-only. -- Petr 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
[Bug 1836658] perl-DateTime-Format-Natural-1.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836658 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|iarn...@gmail.com | Doc Type|--- |If docs needed, set a value -- 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
Fedora-Cloud-30-20200518.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- 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
Re: Fedora 32: samba 4.12.2: Problem with access from win10b to win10a via remote desktop
Il giorno dom, 17/05/2020 alle 16.08 +0200, Dario Lesca ha scritto: > Done: https://bugzilla.redhat.com/show_bug.cgi?id=1836630 I must fill a bug also on samba's bugzilla? -- Dario Lesca (inviato dal mio Linux Fedora 32 Workstation) ___ 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
On Sat, May 16, 2020 at 12:56:06PM +0200, Dominique Martinet wrote: > How should I go about with that? Open bz bugs to all the packages I > listed? strongly suggesting to get things to move to /usr/share (17) and > flatpak (suggest some kind of cache? not sure they'll be interested...) > and environment-modules (not sure what to suggest there, I only have > environment-modules because I need to test something with openmpi from > time to time and it comes with it...) > > > It might also make sense to have a packaging guideline suggesting to > avoid /etc/bash_completion.d in favor of the /usr/share variant, I > couldn't find anything here[1] but I might not have looked thoroughly > enough... > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ > When you are at fixing a packaging of the completion scripts, please make the dependency on bash-completion optional (Recommends: bash-completion). It used to be a good habit to weaken the dependency because not everyone is willing to pay the slow-down tax if he has no use of the completion: # dnf repoquery --whatrequires 'bash-completion' | grep -v bash-completion frama-c-0:20.0-3.fc33.x86_64 hashcat-0:5.1.0-7.fc33.i686 hashcat-0:5.1.0-7.fc33.x86_64 kiwi-cli-0:9.20.5-1.fc33.noarch perl-Config-Model-Itself-0:2.020-2.fc32.noarch snapd-0:2.43.3-1.fc33.x86_64 toolbox-experience-0:0.0.18-3.fc33.noarch votca-csg-bash-0:1.6-1.fc33.noarch -- Petr 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
[EPEL-devel] Re: Documentation for EPEL modules?
On Sat, May 16, 2020 at 11:43:00AM +0200, Antonio Trande wrote: > On 15/05/20 14:57, Stephen Gallagher wrote: > > On Fri, May 15, 2020 at 7:57 AM Petr Pisar wrote: > >> > >> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote: > >>> On Fri, May 15, 2020 at 6:15 AM Petr Pisar wrote: > >>> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote: > > Shortly (Martin is in Cc to confirm): > > > > 1) Make a module: > > > > $ fedpkg clone cmake3 > > $ fedpkg request-repo --namespace modules --exception cmake3-latest > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8 > > > This will request for creating "cmake3-latest" module and "cmake3-latest" > repository and "epel8" stream and "epel8" branch. I don't know if you > really > want to create "cmake3-latest:epel8" module stream. > > >>> > >>> Since this is a module, is there any point in using the cmake3 namespace > >>> over just cmake? > >>> > >> I cannot see any point. Maybe if there were cmake-2 or cmake-4 > >> incompatible to > >> cmake-3 but installable in parallel, then it would make sense. (Like > >> Python.) > >> Because you cannot install more streams of the same module at the same > >> time. > >> Otherwise I would also go with plain "cmake" module name. > > > > > > It turns out, cmake already has a presence[1] in the modules namespace > > of dist-git. It is a relic of the Modularity 1.0 effort, but it's > > already there and that will make this easier. > > Petr, can you take care of this module for epel8, too? > I cannot because of a lack of time and interest in CMake. But I can transfer an ownership of the module to whoever wants it. Also please note that at that time CMake bundled various libraries and a second build-only cmake-bootstrap module was needed to build the cmake module properly. I will include it into the gift. -- Petr 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
Re: [EPEL-devel] Re: Documentation for EPEL modules?
On Sat, May 16, 2020 at 11:43:00AM +0200, Antonio Trande wrote: > On 15/05/20 14:57, Stephen Gallagher wrote: > > On Fri, May 15, 2020 at 7:57 AM Petr Pisar wrote: > >> > >> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote: > >>> On Fri, May 15, 2020 at 6:15 AM Petr Pisar wrote: > >>> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote: > > Shortly (Martin is in Cc to confirm): > > > > 1) Make a module: > > > > $ fedpkg clone cmake3 > > $ fedpkg request-repo --namespace modules --exception cmake3-latest > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8 > > > This will request for creating "cmake3-latest" module and "cmake3-latest" > repository and "epel8" stream and "epel8" branch. I don't know if you > really > want to create "cmake3-latest:epel8" module stream. > > >>> > >>> Since this is a module, is there any point in using the cmake3 namespace > >>> over just cmake? > >>> > >> I cannot see any point. Maybe if there were cmake-2 or cmake-4 > >> incompatible to > >> cmake-3 but installable in parallel, then it would make sense. (Like > >> Python.) > >> Because you cannot install more streams of the same module at the same > >> time. > >> Otherwise I would also go with plain "cmake" module name. > > > > > > It turns out, cmake already has a presence[1] in the modules namespace > > of dist-git. It is a relic of the Modularity 1.0 effort, but it's > > already there and that will make this easier. > > Petr, can you take care of this module for epel8, too? > I cannot because of a lack of time and interest in CMake. But I can transfer an ownership of the module to whoever wants it. Also please note that at that time CMake bundled various libraries and a second build-only cmake-bootstrap module was needed to build the cmake module properly. I will include it into the gift. -- Petr 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 --- Comment #3 from Fedora Update System --- FEDORA-2020-fb4f473b3f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fb4f473b3f -- 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 --- Comment #4 from Fedora Update System --- FEDORA-2020-c446a7263b has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c446a7263b -- 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
Re: Orphaning vala - asking for new owner
Hi, I maintain GNOME Boxes (which is part of the default workstation installation) and GNOME Connections. Both written in Vala. Therefore the maintenance of Vala in Fedora is important to me. I can take ownership of it, and I will be happy to collaborate with others that might be also interested. Regards, Felipe Borges. On Sat, May 16, 2020 at 9:53 PM Michel Alexandre Salim wrote: > > Hi all, > > I'm still the primary maintainer for Vala, but de facto have not been > doing much with it -- it mostly gets auto-upgraded together with the > rest of the GNOME stack. > > As such I'm not really the best person to have issues assigned to, and > if anyone else wants to take over the reign, I'll transfer ownership > directly rather than causing a mad scramble by directly orphaning. > > Thanks, > > -- > Michel Alexandre Salim > profile: https://keybase.io/michel_slm > chat via email: https://delta.chat/ > GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 > ___ > 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 ___ 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 --- Comment #2 from Fedora Update System --- FEDORA-2020-747f380e37 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-747f380e37 -- 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-PkgConfig-LibPkgConf-0 ||.11-1.fc33 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- 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
[Bug 1836456] perl-PkgConfig-LibPkgConf-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836456 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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
Re: FTBFS bug not reassigned
Dne 17. 05. 20 v 1:25 Benjamin Lowry napsal(a): > I recently adopted flatbuffers, which was orphaned due to an open FTBFS > in F32 [1]. I've fixed the spec, rebuilt, and made an update in bodhi, > but I'm unable to close the FTBFS bug because it hasn't been reassigned > to me. What should I do? Am I supposed to be able to edit this bug? I'm > in the editbugs group... -ben > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799345 I have assigned the bug to you. I hope it helps and it won't postpone fix of the root cause of this issue. Vít signature.asc 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
Fedora-Cloud-32-20200518.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 600166 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/600166 -- 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
Fedora rawhide compose report: 20200517.n.1 changes
OLD: Fedora-Rawhide-20200516.n.0 NEW: Fedora-Rawhide-20200517.n.1 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 7 Dropped packages:0 Upgraded packages: 113 Downgraded packages: 0 Size of added packages: 2.51 MiB Size of dropped packages:0 B Size of upgraded packages: 980.35 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -58.87 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20200516.n.0.iso Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20200516.n.0.iso = ADDED PACKAGES = Package: rust-diesel_migrations-1.4.0-1.fc33 Summary: Migration management for diesel RPMs:rust-diesel_migrations+default-devel rust-diesel_migrations+mysql-devel rust-diesel_migrations+postgres-devel rust-diesel_migrations+sqlite-devel rust-diesel_migrations-devel Size:38.86 KiB Package: rust-libsqlite3-sys-0.18.0-1.fc33 Summary: Native bindings to the libsqlite3 library RPMs:rust-libsqlite3-sys+bindgen-devel rust-libsqlite3-sys+buildtime_bindgen-devel rust-libsqlite3-sys+cc-devel rust-libsqlite3-sys+default-devel rust-libsqlite3-sys+in_gecko-devel rust-libsqlite3-sys+min_sqlite_version_3_6_23-devel rust-libsqlite3-sys+min_sqlite_version_3_6_8-devel rust-libsqlite3-sys+min_sqlite_version_3_7_16-devel rust-libsqlite3-sys+min_sqlite_version_3_7_7-devel rust-libsqlite3-sys+pkg-config-devel rust-libsqlite3-sys+preupdate_hook-devel rust-libsqlite3-sys+session-devel rust-libsqlite3-sys+sqlcipher-devel rust-libsqlite3-sys+unlock_notify-devel rust-libsqlite3-sys+with-asan-devel rust-libsqlite3-sys-devel Size:124.88 KiB Package: rust-pommes-0.0.1-1.fc33 Summary: Project object model model (and parser using serde) RPMs:pommes rust-pommes+default-devel rust-pommes-devel Size:2.14 MiB Package: rust-r2d2-0.8.8-1.fc33 Summary: Generic connection pool RPMs:rust-r2d2+default-devel rust-r2d2-devel Size:32.38 KiB Package: rust-scheduled-thread-pool-0.2.4-1.fc33 Summary: Scheduled thread pool RPMs:rust-scheduled-thread-pool+default-devel rust-scheduled-thread-pool-devel Size:24.63 KiB Package: rust-tokio-socks-0.2.2-1.fc33 Summary: Asynchronous SOCKS proxy support for Rust RPMs:rust-tokio-socks+default-devel rust-tokio-socks+tor-devel rust-tokio-socks-devel Size:35.08 KiB Package: rust-webkit2gtk-0.9.2-1.fc33 Summary: Rust bindings for webkit-gtk library RPMs:rust-webkit2gtk+default-devel rust-webkit2gtk+v2_10-devel rust-webkit2gtk+v2_12-devel rust-webkit2gtk+v2_14-devel rust-webkit2gtk+v2_16-devel rust-webkit2gtk+v2_2-devel rust-webkit2gtk+v2_4-devel rust-webkit2gtk+v2_6-devel rust-webkit2gtk+v2_8-devel rust-webkit2gtk-devel Size:121.47 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Carla-1:2.2-1.beta1.fc33 Old package: Carla-1:2.2-0.1.20200514gitf100892.fc33 Summary: Audio plugin host RPMs: Carla Carla-devel Carla-vst lv2-carla Size: 51.23 MiB Size change: 2.55 MiB Changelog: * Sat May 16 2020 Martin Gansser - 1:2.2-0.1.20200514gitf100892 - Update to 2.2beta1 Package: CuraEngine-1:4.6.1-1.fc33 Old package: CuraEngine-1:4.6.0-1.fc33 Summary: Engine for processing 3D models into G-code instructions for 3D printers RPMs: CuraEngine Size: 3.68 MiB Size change: -53 B Changelog: * Tue May 05 2020 Gabriel F??ron - 4.6.0-1 - Update to 4.6.1 Package: armadillo-9.880.1-1.fc33 Old package: armadillo-9.860.1-1.fc33 Summary: Fast C++ matrix library with syntax similar to MATLAB and Octave RPMs: armadillo armadillo-devel Size: 10.92 MiB Size change: 9.64 KiB Changelog: * Sat May 16 2020 Jos?? Matos - 9.880.1-1 - update to 9.880.1 Package: calibre-4.16.0-1.fc33 Old package: calibre-4.15.0-1.fc33 Summary: E-book converter and library manager RPMs: calibre Size: 68.59 MiB Size change: -213.08 KiB Changelog: * Sat May 16 2020 Kevin Fenzi - 4.16.0-1 - Update to 4.16.0. Fixes bug #1836053 Package: conmon-2:2.0.17-0.1.dev.git82e9358.fc33 Old package: conmon-2:2.0.16-0.1.dev.gite34c6d6.fc33 Summary: OCI container runtime monitor RPMs: conmon Size: 213.40 KiB Size change: 2.32 KiB Changelog: * Mon May 11 2020 RH Container Bot - 2:2.0.16-0.2.dev.git42cb289 - autobuilt 42cb289 * Tue May 12 2020 RH Container Bot - 2:2.0.16-0.3.dev.git6fa9c2a - autobuilt 6fa9c2a * Tue May 12 2020 RH Container Bot - 2:2.0.16-0.4.dev.gitedd4aaa - autobuilt edd4aaa * Tue May 12 2020 RH Container Bot - 2:2.0.17-0.1.dev.git82e9358 - bump to 2.0.17 - autobuilt 82e9358 Package: coturn-4.5.1.2-1.fc33 Old package: coturn-4.5.1.1-3.fc33 Summary: TURN/STUN & ICE Server RPMs: coturn
Re: SELinux is preventing systemctl from read access on the file SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
On Sun, May 17, 2020 at 9:45 AM Joseph Wagner
wrote:
> I've tried relabeling, and the problem still persists. Should I report
> this as a bug, or this a config problem on my end?
>
Hi Joseph,
This bug has already been reported:
https://bugzilla.redhat.com/show_bug.cgi?id=1827972
It is a similar bug to the one pointed to by Johannes, but requires a
different approach.
> Joseph D. Wagner
>
>
> SELinux is preventing systemctl from read access on the file
> SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
>
> * Plugin catchall (100. confidence) suggests
> **
>
> If you believe that systemctl should be allowed read access on the
> SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'systemctl' --raw | audit2allow -M my-systemctl
> # semodule -X 300 -i my-systemctl.pp
>
> Additional Information:
> Source Context system_u:system_r:logrotate_t:s0
> Target Context system_u:object_r:efivarfs_t:s0
> Target Objects SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c [
> file ]
> Source systemctl
> Source Path systemctl
> Port
> Host localhost.localdomain
> Source RPM Packages
> Target RPM Packages
> SELinux Policy RPM selinux-policy-targeted-3.14.5-38.fc32.noarch
> Local Policy RPM selinux-policy-targeted-3.14.5-38.fc32.noarch
> Selinux Enabled True
> Policy Type targeted
> Enforcing Mode Enforcing
> Host Name localhost.localdomain
> Platform Linux localhost.localdomain 5.6.11-300.fc32.x86_64
> #1 SMP Wed May 6 19:12:19 UTC 2020 x86_64 x86_64
> Alert Count 5
> First Seen 2020-05-15 03:26:10 PDT
> Last Seen 2020-05-17 00:01:02 PDT
> Local ID e5acdc0f-f979-4bb7-9889-1fa1e1a1586b
>
> Raw Audit Messages
> type=AVC msg=audit(1589698862.374:769): avc: denied { read } for
> pid=112829 comm="systemctl"
> name="SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c" dev="efivarfs"
> ino=15503 scontext=system_u:system_r:logrotate_t:s0
> tcontext=system_u:object_r:efivarfs_t:s0 tclass=file permissive=0
>
>
> Hash: systemctl,logrotate_t,efivarfs_t,file,read
> ___
> 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
>
--
Zdenek Pytela
Security controls team
___
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
Re: Many packages unnecessarily link to libpython
On Friday, May 15, 2020 8:12:00 PM CEST Charalampos Stratakis wrote: > [...] > On Fedora Rawhide, there are at this point 144 packages linking to libpython, > many of those possibly without any need for it. > [...] > postgresql hhorak jstanek panovotn pkajaba pkubat praiskup tgl > [...] > praiskup postgresql > [...] The subpackage postgresql-plpython3 implements python interpreter. Pavel ___ 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
