Re: Single-threaded OpenBLAS is not thread-safe

On Thu, 28 May 2020 at 10:04, Susi Lehtola wrote: > > The correct case is to use the OpenMP flavor of OpenBLAS to avoid these > issues. If you use the OpenMP library in a sequential program, the BLAS > runs in parallel, and if you use the OpenMP library in an OpenMP > parallel program the BLAS run

Re: Supporting hibernation in Workstation ed., draft 1

On Sat, 30 May 2020 at 11:32, Vitaly Zaitsev via devel wrote: > > On 30.05.2020 00:58, Chris Murphy wrote: > > We will support an install time means of enabling hibernation retained > > via Custom partitioning. If the user chooses to create a swap > > partition, the installer will include a resume

Re: Supporting hibernation in Workstation ed., draft 1

On Sat, 30 May 2020 at 12:57, Dominique Martinet wrote: > > Vitaly Zaitsev via devel wrote on Sat, May 30, 2020: > > On 30.05.2020 11:51, Iñaki Ucar wrote: > > > What are the issues? I have full-disk encryption and > > > suspend-then-hibernate enabled (with s

Re: Update on Rough Draft Implementation of KangarooTwelve

On Tue, 2 Jun 2020 at 08:07, tsalim--- via devel wrote: > > At this point, I am working on adding support for numbers as large as 2^255 > as required by the length_encode function detailed on page 9 of the RFC. > > The C Programming Language does not support large numbers greater than 2^63-1 > a

Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

On Tue, 2 Jun 2020 at 17:37, Jonathan Wakely wrote: > > All packages from the f33-boost side tag have now been signed and > should be in rawhide But not in Bodhi. Does this require manual intervention? -- Iñaki Úcar ___ devel mailing list -- devel@lis

Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

On Wed, 3 Jun 2020 at 01:07, Jonathan Wakely wrote: > > On 02/06/20 16:24 +0100, Jonathan Wakely wrote: > >### Boost.Bind > > > >Several packages failed to build because the Boost.Bind placeholders > >_1, _2, _3 etc. are no longer in the global namespace. See the message > >in : > > > >BOOST_PRAGM

Re: [Retired] boost-nowide

Thanks for all the work. :) On Thu, 4 Jun 2020 at 12:22, Jonathan Wakely wrote: > > As previously discussed (by me ... nobody else responded) I have > retired the boost-nowide package in rawhide. > > The boost-1.73.0 package now in rawhide provides boost-nowide as a > subpackage, because the proj

Re: Is there an official Fedora for WSL?

On Sun, 7 Jun 2020 at 04:22, Gordon Messmer wrote: > > On 6/2/20 4:52 AM, Code Zombie wrote: > > Is there an official branch of Fedora for WSL or a plan to create one? > > > The good news is that it's reasonably straightforward to install an > unpackaged distribution, you just need a tarball of th

Re: Is there an official Fedora for WSL?

On Mon, 8 Jun 2020 at 07:12, Gordon Messmer wrote: > > > - I found that [1] does a pretty good job replacing /usr/bin/systemctl > > [1] https://github.com/gdraheim/docker-systemctl-replacement > > I only use WSL for an interactive shell, so I haven't needed to do much > of anything with systemd.

Re: Is there an official Fedora for WSL?

On Mon, 8 Jun 2020 at 10:37, Florian Weimer wrote: > > * Iñaki Ucar: > > > On Mon, 8 Jun 2020 at 07:12, Gordon Messmer > > wrote: > >> > >> > - I found that [1] does a pretty good job replacing /usr/bin/systemctl > >> > [1] https://github

Re: Fedora Jam switch to GNOME

On Wed, 10 Jun 2020 at 18:46, Neal Gompa wrote: > > I would personally be very sad if Fedora Jam switched from KDE to > GNOME. To me, KDE has always been the home for creatives, and it shows > with the excellent Qt/KDE based software for auditory and visual > creativity. From my perspective, KDE i

Re: Highlights from the latest Copr release 2020-06-10

On Wed, 10 Jun 2020 at 21:42, Pavel Raiskup wrote: > > - Copr project "runtime" dependencies were implemented. Great! > - Copr-cli supports batch build delete feature: > > $ copr-cli delete build_id [build_id ...] Hooray! Just delete or delete-build? -- Iñaki Úcar

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

On Tue, 16 Jun 2020 at 12:14, Jiri Vanek wrote: > > On 6/16/20 9:18 AM, Kamil Paral wrote: > > On Mon, Jun 15, 2020 at 10:12 PM Ben Cotton > > wrote: > > > > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground > > > > == Summary == > > Fedora Wo

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

On Tue, 16 Jun 2020 at 03:09, Neal Gompa wrote: > > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler wrote: > > > > How does this affect the many packages that already build in a separate > > build folder manually? There are even several specfile templates that > > contain the boilerplate for that. >

SELinux question

Hi, I need some help from a SELinux guru. TL;DR, I've developed a small service. An app talks to this service, the service does some stuff and, in the meanwhile, it reports the progress to the app user by writing some messages into the stderr (/proc//fd/2) of that app. So far so good. Now, I keep

Re: Fedora Packager Dashboard available for testing

Congrats for the great work! One question. I don't have many packages, but I only see one of them. Why? Iñaki On Tue, 23 Jun 2020 at 18:35, Josef Skladanka wrote: > > Hi, > > We'd like to announce public testing of the Packager Dashboard - a new > service for Fedora package maintainers aiming t

Re: Fedora Packager Dashboard available for testing

On Wed, 24 Jun 2020 at 11:20, Josef Skladanka wrote: > > Iñaki, > > looking at your dashboard overview, my guess would be that only one of > the packages has any bugs/updates/prs/... since we "know" you have six > packages (shown in the header), but only one is shown in the > dashboard. So accordi

Re: SELinux question

On Wed, 24 Jun 2020 at 11:05, Qiyu Yan wrote: > > Run your program in permissive mode and use audit2why [1], to see what's > wrong. > If you have to allow that, you can use audit2allow [2] to produce a > policy package to allow that behavior in package. > I don't know how to make this into a pack

Re: SELinux question

On Wed, 24 Jun 2020 at 20:45, Nathanael D. Noblet wrote: > > On Wed, 2020-06-24 at 12:12 +0200, Iñaki Ucar wrote: > > Thanks, I got [1] and [2] more or less covered thanks to the output > > of > > the SELinux troubleshooter. The missing parts were how to get > >

Re: SELinux question

El mié., 24 jun. 2020 21:15, Jared K. Smith escribió: > On Wed, Jun 24, 2020 at 4:55 AM Iñaki Ucar > wrote: > >> I need some help from a SELinux guru. TL;DR, I've developed a small >> service. An app talks to this service, the service does some stuff >> and,

Re: Fedora Packager Dashboard available for testing

s > just don't need any attention. > > If the data is incomplete, please report a bug showing what's missing > so we can investigate. > Thank you, > > josef > > On Wed, Jun 24, 2020 at 11:06 AM Iñaki Ucar wrote: > > > > Congrats for the gre

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Fri, 26 Jun 2020 at 03:40, Sergio Belkin wrote: > > Well, I strongy disagree whit this move. > In fact on of the things that I hate of Debian/Ubuntu is the choice of nano > and the poor version that they offer by default of vi. > More friendly for end-users? Really? > Please thinking so, the e

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Fri, 26 Jun 2020 at 09:50, Jan Kratochvil wrote: > > On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote: > > But regardless, that's something to fix in the dnf bash completion scripts, > > not a reason to completely disable completion as the earlier poster said. > > TL;DR it regresses the or

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Fri, 26 Jun 2020 at 10:20, Leigh Scott wrote: > > Please don't make this universal for all the spins, it should be optional. > TBH I don't give a damn if you do it to the workstation spin, please keep > your grubby hands off the cinnamon spin :-) That escalated quickly. :) -- Iñaki Úcar ___

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Fri, 26 Jun 2020 at 19:06, Neil Horman wrote: > > Right, and I acutally think thats great. You had a problem, you asked the > questions you needed answers to, and solved your problem. I personally think > the process of identifying whats bothering you, figuring out a solution (by > asking que

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Tue, 30 Jun 2020 at 21:24, Robert-André Mauchin wrote: > > May I suggest another option? > I provide a package for Micro, an editor written in Go with a discoverable > interface. https://micro-editor.github.io/ > > It is compiled as a static binary of 4.6 MB with no dependency. Probably > bigge

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 17:53, Jerry James wrote: > > On Wed, Jul 1, 2020 at 8:25 AM Ben Cotton wrote: > > > > Mechanisms such as update-alternatives and modules have been discussed > > in the past, but were considered improper (the former) or faced > > technical issues (the former). > > I think th

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On Wed, 1 Jul 2020 at 18:54, Miro Hrončok wrote: > > On 01. 07. 20 18:33, Michael Catanzaro wrote: > > On Wed, Jul 1, 2020 at 11:28 am, Michael Catanzaro > > wrote: > >> I have not much opinion on whether we should use this vs. nano. > > > > Actually, playing with it for an extra three minutes..

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 19:03, Jerry James wrote: > > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar wrote: > > BTW, I would also like to discuss here, as part of this proposal, > > which backend should be the system-wide default. I believe we all > > would agree that OpenB

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > On 01. 07. 20 16:24, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > == Summary == > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > library, which will set OpenBLAS

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 20:13, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 10:54:16 -0600 > Jerry James wrote: > > > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar > > wrote: > > > BTW, I would also like to discuss here, as part of this proposal, > > > which

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 20:24, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 19:28:53 +0200 > Iñaki Ucar wrote: > > I'm no expert, but the FAQ says: > > > > "You have a GPLed program that I'd like to link with my code to build > > a proprietary prog

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 21:00, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 20:24, Susi Lehtola > wrote: > > > > On Wed, 1 Jul 2020 19:28:53 +0200 > > Iñaki Ucar wrote: > > > I'm no expert, but the FAQ says: > > > > > > "You have a G

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > On 01. 07. 20 16:24, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > == Summary == > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > library, which will set OpenBLAS

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 3 Jul 2020 at 13:02, Susi Lehtola wrote: > > On Wed, 1 Jul 2020 20:16:36 +0200 > Iñaki Ucar wrote: > > > No, this is exactly the wrong way around. You should use the serial > > > library for code that you want to be running in serial (this way you > > &

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 3 Jul 2020 at 15:23, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > == User Experience == > > Users will have a new CLI tool, called flexiblas, which will allow > > them to properly switch the BLAS/LAPACK backend without administrativ

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 3 Jul 2020 at 15:29, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jul 03, 2020 at 01:15:29PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > > == User Experience == > > > Users will have a new CLI tool, called flexiblas, which

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 3 Jul 2020 at 15:43, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 01, 2020 at 10:24:27AM -0400, Ben Cotton wrote: > > == Documentation == > > See the > > [https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release/-/blob/master/README.md > > README] of the upstream project and t

Re: [Fedora-legal-list] Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 3 Jul 2020 at 16:15, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 02, 2020 at 09:50:47AM +0200, Iñaki Ucar wrote: > > On Wed, 1 Jul 2020 at 18:39, Miro Hrončok wrote: > > > > > > On 01. 07. 20 16:24, Ben Cotton wrote: > > > > https://fedora

Re: [Fedora-legal-list] Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Sat, 4 Jul 2020 at 16:20, Zbigniew Jędrzejewski-Szmek wrote: > > > > Would the maintainer consider switching the whole thing to LGPLv3? > > > This would preserve the freeness of his code and be much less hassle > > > for everyone involved, with no interpretation of new legal texts required. > >

Re: [Fedora-legal-list] Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Wed, 15 Jul 2020 at 12:35, Kevin Kofler wrote: > > Iñaki Ucar wrote: > > LGPL has other implications towards proprietary software, and that's > > what the authors specifically want to protect, so that's a hard line. > > > > Wouldn't the Clas

Re: Orphaning repsnapper, gtkglextmm

On Wed, 15 Jul 2020 at 11:39, Miro Hrončok wrote: > > On 02. 06. 20 22:36, Miro Hrončok wrote: > > I've just orphaned repsnapper and gtkglextmm. repsnapper depends on > > gtkglextmm > > which depends on pangox-compat, which is already orphaned for 4 weeks. > > > > I haven't touched the packages i

Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed

Could someone with superpowers cancel the following task for me? Thanks. https://koji.fedoraproject.org/koji/taskinfo?taskID=47330918 On Fri, 17 Jul 2020 at 09:44, Fabio Valentini wrote: > > On Wed, Jul 15, 2020 at 5:55 PM Mat Booth wrote: > > Any update? Any thoughts on when you want to merge

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 17 Jul 2020 at 10:34, Dave Love wrote: > > [I found I hadn't sent this earlier, as I should have.] > > > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > > > == Summary == > > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > > library, which

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Fri, 17 Jul 2020 at 11:19, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 17 July 2020 at 10:25, Dave Love wrote: > > There will be hoops to jump through to get packages to configure when > > they don't know about the library. > > From what I understand from the proposal, FlexiBLAS looks

Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed

On Fri, 17 Jul 2020 at 11:19, Dan Horák wrote: > > On Fri, 17 Jul 2020 10:42:45 +0200 > Iñaki Ucar wrote: > > > Could someone with superpowers cancel the following task for me? > > Thanks. > > done, it has already failed on i686 Yeah, that's why I wanted

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Tue, 21 Jul 2020 at 19:59, Dave Love wrote: > > Iñaki Ucar writes: > > >> The licence seems to me to > >> rule it out a priori. > > > > The authors are going to add an exception, so the license won't be a > > problem. What problems do you thin

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

On Tue, 28 Jul 2020 at 18:02, Dave Love wrote: > > I'm offering the experience of doing all this work from various > different points of view. I don't off-hand remember instances where > particular problems have occurred, because I've done quite a of this. > Isn't engineering experience valuable?

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

On Wed, 25 Mar 2020 at 01:14, Gavin Simpson wrote: > > Dear list > > On Fedora 31 the pango library has recently updated to version >= 1.44 > and in doing so has switched to using the HarfBuzz library (from > FreeType) and dropped Adobe Type 1 font support. This causes problems > with plotmath as

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

ce/package to fix this. Should I CC the fonts lists? Iñaki On Wed, 25 Mar 2020 at 11:28, Iñaki Ucar wrote: > > On Wed, 25 Mar 2020 at 01:14, Gavin Simpson wrote: > > > > Dear list > > > > On Fedora 31 the pango library has recently updated to version >= 1.44 &g

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza wrote: > > 20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen: > > > > On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote: > >> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney wrote: > >>> > >>> ### Other Updates > >>> > >>> GitForge Deci

Re: CPE Git Forge Decision

Hi Leigh, On Mon, 30 Mar 2020 at 11:30, Leigh Griffin wrote: > > Hi everyone, > > Thank you for your patience while the CPE Team worked through an incredible > number of requirements from multiple stakeholder sources. On Friday evening > we announced on the Community Blog our decision to adopt

Re: CPE Git Forge Decision

On Mon, 30 Mar 2020 at 12:15, Leigh Griffin wrote: > > On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar wrote: >> >> Hi Leigh, >> >> On Mon, 30 Mar 2020 at 11:30, Leigh Griffin wrote: >> > >> > Hi everyone, >> > >> > Thank you for y

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

On Mon, 30 Mar 2020 at 13:10, Leigh Griffin wrote: > > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar wrote: >> >> So I was also waiting for those open discussions about the >> requirements gathered. > > We had several threads on them from the Fedora perspective on b

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

On Mon, 30 Mar 2020 at 13:20, Neal Gompa wrote: > > On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin wrote: > > > >> > >> I was really looking forward to reading what > >> Neal (as he's doing now) and others had to say about the requirements > >> *before* any decision was taken, and how each tool co

Re: CPE Git Forge Decision

On Tue, 31 Mar 2020 at 19:15, Matthew Miller wrote: > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote: > > Some failure of process or communication must have occurred > > somewhere along the lines, because open source should have been the > > first and most important requiremen

Re: CPE Git Forge Decision

On Thu, 2 Apr 2020 at 12:20, Neil Thompson wrote: > > Yeah, it's really starting to smell as though this whole process was a > "consultation" done in bad faith with a predetermined outcome. Not what one > expects from Fedora/Red Hat. I am convinced that the consultation was done in good faith,

Re: v4l2loopback kernel module in Fedora?

On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > Aren't external kernel modules banned by fedora packaging rules? Yes, they are: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_no_external_kernel_modules -- Iñaki Úcar

Re: v4l2loopback kernel module in Fedora?

On Sun, 5 Apr 2020 at 22:23, Christopher wrote: > > On Sun, Apr 5, 2020 at 3:20 PM Iñaki Ucar wrote: > > > > On Sun, 5 Apr 2020 at 11:08, Leigh Scott wrote: > > > > > > Aren't external kernel modules banned by fedora packaging rules? > > > >

Re: v4l2loopback kernel module in Fedora?

On Mon, 6 Apr 2020 at 03:53, Christopher wrote: > > The previous packaging was on COPR, but it appears abandoned, probably > because it's kind of worthless if it's not signed. And, it's a lot of > manual work to self-sign and register the key with mokutil, and even > more effort to figure out how

Re: PSA: please do not BuildRequires: qt5-devel

On Mon, 6 Apr 2020 at 18:08, Rex Dieter wrote: > > The qt5, qt5-devel metapackages were introduced a few releases ago as merely > a convenience for end-users, not intended to be used in official fedora > packages, but seems these have seen some non-trivial adoption anyway. > > Personally, I object

Re: v4l2loopback kernel module in Fedora?

On Tue, 7 Apr 2020 at 05:58, Christopher wrote: > > If I get the motivation, I'll file a bug against the RPMFusion package. Here's the bug tracker: https://bugzilla.rpmfusion.org/ > As for the original issue regarding packaging: there is a ticket being > tracked to get it upstream into the kerne

Re: CPE Git Forge Decision

On Tue, 7 Apr 2020 at 03:08, Randy Barlow wrote: > > On 4/6/20 6:37 AM, Leigh Griffin wrote: > > I'm sorry if you took my mail up as implying a lack of value from how > > the team historically worked. As a team we are being tasked more and > > more with adding what I call real value which is at a

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

On Wed, 15 Apr 2020 at 11:13, Jun Aruga wrote: > > > jaruga: nodejs-source-map-support, jruby > > I am okay to let nodejs-source-map-support orphan. > I have no idea why nodejs-source-map-support affects me. Follow the trail: uglify-js requires nodejs-acorn, which requires nodejs-rollup, which re

simple-koji-ci fails with new patch

Hi, I forked a package, changed the spec, added a patch and submitted a PR. Then simple-koji-ci fails because the patch wasn't included in the SRPM apparently [1]. Any idea why? Did I miss something? [1] https://src.fedoraproject.org/rpms/R/pull-request/3 Regards, -- Iñaki Úcar

Re: simple-koji-ci fails with new patch

On Fri, 1 May 2020 at 13:39, Dan Horák wrote: > > On Fri, 1 May 2020 13:21:10 +0200 > Iñaki Ucar wrote: > > > Hi, > > > > I forked a package, changed the spec, added a patch and submitted a > > PR. Then simple-koji-ci fails because the patch wasn't inc

Re: F33 system wide change, java-11-openjdk as system jdk

Hi, thanks for your assistance, comments inline: On Mon, 4 May 2020 at 10:48, Jiri Vanek wrote: > > Generally, no program can say, that do not support jdk11, because any > javac/java application can be > *hacked* to work with java11 - see > https://jvanek.fedorapeople.org/devconf/2017/portingjav

Re: F33 system wide change, java-11-openjdk as system jdk

On Mon, 4 May 2020 at 11:22, Jiri Vanek wrote: > > > Thanks, but as I said above, the RStudio rpms don't pull the JVM, > > because it's not required at runtime. So I suppose that, beyond fixing > > the java-devel version in BuildRequires, I don't need to do anything > > more, right? > > Hopefully:

Re: CPE Weekly: 2020-04-26

On Tue, 5 May 2020 at 20:44, Stephen John Smoogen wrote: > > On Tue, 5 May 2020 at 13:59, Fabio Valentini wrote: > > > > On Tue, May 5, 2020 at 4:08 PM Leigh Griffin wrote: > > > > > > We have performed technical analysis at all stages, this is a deeper dive > > > from two perspectives. The fir

Single-threaded OpenBLAS is not thread-safe

Hi, I wanted to bring some attention to this in devel, not only to openblas' maintainer (in CC), because there have been some discussions around BLAS/LAPACK in the past here. As Dave Love pointed out in a previous discussion, generally, parallelization is made at the top level and then you simply

Default BLAS/LAPACK implementation + runtime exchangeable backends

Hi, I didn't find this proposal in the archives, so let me add something to this discussion. Does anyone know about FlexiBLAS [1]? It seems like the perfect solution to this problem, and AFAIK, only Arch packages it. Here's a presentation [2] about it (not up-to-date with the current feature-set,

Re: Building eBPF programs

Did you check the following? https://patchwork.ozlabs.org/patch/870656/ https://code.forksand.com/oisf/suricata/commit/7906c521cdde5b1d0eb3ce379b8e343c3055653f Iñaki On Fri, 18 Oct 2019 at 15:22, Steve Grubb wrote: > > On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote: > > * Steve

Official font

Hi all, I incidentally discovered today that, since quite recently, there's a Red Hat font [1]. And this led me to think about the popularity of the Ubuntu font, you know, and how nice would be to have a nice catchy official Fedora font integrated into the distro... I'm just thinking aloud, becaus

Re: Official font

On Wed, 30 Oct 2019 at 17:42, Jakub Jelen wrote: > > On Wed, 2019-10-30 at 16:58 +0100, Iñaki Ucar wrote: > > Hi all, > > > > I incidentally discovered today that, since quite recently, there's a > > Red Hat font [1]. And this led me to think about the popular

Re: Official font

Great, thanks! That template looks wonderful! Iñaki El jue., 31 oct. 2019 0:48, Luya Tshimbalanga escribió: > > On 2019-10-30 9:54 a.m., Iñaki Ucar wrote: > > On Wed, 30 Oct 2019 at 17:42, Jakub Jelen wrote: > >> On Wed, 2019-10-30 at 16:58 +0100, Iñaki Ucar wrote: > &

Re: Use immutable CRAN URLs

Hi, I had every intention of pushing this forward, but I never found the time. Sorry for that. It would still be great to have these. Iñaki On Wed, 6 Nov 2019 at 10:11, Elliott Sales de Andrade wrote: > > Hello, > > On Thu, 1 Nov 2018 at 20:45, Jason L Tibbitts III wrote: > > > > Since I actu

Re: How do I remove GLIBCXX_ASSERTIONS?

Steve, as you said in that thread, actually those assertions have helped uncover a bug (tagged as "critical")! I don't see any way in which they could "add additional crashes" if upstream does their homework. So I don't think it's a good idea to remove them. Iñaki On Fri, 2 Aug 2019 at 17:47, Ste

Dropping -devel subpackage

Hi, Quick question not found in the docs. There's a package with a -devel subpackage. No package depends on this -devel and upstream removes the development files in the new release, so I just dropped the -devel subpackage. Now, it's improbable, but if the old -devel subpackage was installed, the

Re: Dropping -devel subpackage

On Sun, 4 Aug 2019 at 01:21, Miro Hrončok wrote: > > > So the question is: should I add "Obsoletes: pkg-devel < $new_version" > > to pkg's SPEC? Is this a proper use of "Obsoletes"? > > Yes. Exactly a right thing to do. Thanks, Miro. Then, I suggest to add this particular case to the documentatio

Re: How do I remove GLIBCXX_ASSERTIONS?

On Sun, 4 Aug 2019 at 16:21, Sam Varshavchik wrote: > > I'm well aware of the alternatives. That's not the point. > > The point is that there's nothing wrong with this specific form of existing > code that now throws exceptions when the hardened build gets turned on. > There is no buffer overruns,

Re: Dropping -devel subpackage

On Sun, 4 Aug 2019 at 15:01, Rex Dieter wrote: > > Iñaki Ucar wrote: > > > On Sun, 4 Aug 2019 at 01:21, Miro Hrončok wrote: > >> > >> > So the question is: should I add "Obsoletes: pkg-devel < $new_version" > >> > to pkg's SPEC? I

Re: How do I remove GLIBCXX_ASSERTIONS?

On Mon, 5 Aug 2019 at 18:23, Andrew Lutomirski wrote: > > On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik wrote: > > > > Georg Sauthoff writes: > > > > > > I ended up tweaking my code to avoid the assertions, rather than > > > > disabling > > > > them. For this particular situation, my original c

Re: Cannot build with mock for rawhide on Fedora 30

The same happens in Copr. Iñaki El sáb., 17 ago. 2019 12:53, Till Hofmann escribió: > Hi all, > > I'm facing an issue with the package signatures on Fedora when trying to > build in rawhide chroot: > $ mock -r fedora-rawhide-x86_64 --shell > [...] > Public key for zstd-1.4.2-1.fc31.x86_64.rpm i

Re: Cannot build with mock for rawhide on Fedora 30

On Mon, 19 Aug 2019 at 13:03, Pavel Raiskup wrote: > > On Saturday, August 17, 2019 1:07:04 PM CEST Iñaki Ucar wrote: > > The same happens in Copr. > > Copr is fixed now, builders have installed mock-core-configs and > distribution-gpg-keys from updates-testing: > https:/

R-core does not provide librt anymore in rawhide

Hi, I noticed this. For the same R version, fc31 and fc32 R-core packages do not provide librt.so anymore. As a consequence, R packages using real time extensions (notably, those using shared memory) cannot be loaded due to missing symbols (because they don't have an explicit -lrt). Is there a goo

Re: Fedora Workstation and disabled by default firewall

On Mon, 26 Aug 2019 at 15:25, Robert Marcano wrote: > > On 8/26/19 9:07 AM, mcatanz...@gnome.org wrote: > > > > Well the thing is, blocknig ports tends to break applications that want > > to use those ports. We're not going to do that, period. It also doesn't > > really accomplish anything: either

Re: Fedora Workstation and disabled by default firewall

On Tue, 27 Aug 2019 at 09:40, wrote: > > If there is a separate team of firewall developers that would be interested > in writing a new style of firewall, then I'm sure the WG would be happy to > reopen discussion of the issue, including a discussion of requirements, etc. > But I highly doubt a

Re: Fedora Workstation and disabled by default firewall

On Tue, 27 Aug 2019 at 14:25, wrote: > > On Tue, Aug 27, 2019 at 2:37 PM, Iñaki Ucar wrote: > > There's no need to write "a new style of firewall". It would be as easy as > asking the user once whether a new connection is trusted or not. That's it. > >

Re: Fedora Workstation and disabled by default firewall

On Tue, 27 Aug 2019 at 14:20, wrote: > > The main competitor of Fedora Workstation is Ubuntu. Ubuntu ships without a > firewall enabled and nobody considers this a critical vulnerability. Now: why > is that...? 1. Ubuntu Server ships without a firewall enabled. Do you think that's a good policy

Re: Fedora Workstation and disabled by default firewall

On Tue, 27 Aug 2019 at 15:17, Iñaki Ucar wrote: > > Windows shows a pop-up. To be fair, I've just checked and Windows 10 doesn't show a pop-up; better than that: when you (enter the password and) hit "connect", it asks there whether it's a private network and you

Re: Fedora Workstation and disabled by default firewall

Responding to the first message because I'm not interested in further discussion. It's clear to me that there will be no agreement in this matter unless there are reasonable potential alternatives. Therefore, this message is just to let you all know that I'm at least trying to push for better alter

Re: Error with fedpkg update

On Thu, 29 Aug 2019 at 17:36, Gerald B. Cox wrote: > > If I do that, I believe I get into a situation where the other builds f29, > f30 and F32 are behind, which if I remember correctly causes other issues - > and shouldn't we understand what is wrong with the system rather than just > trying t

Re: Error with fedpkg update

On Thu, 29 Aug 2019 at 18:06, Gerald B. Cox wrote: > > Thanks all for the replies... I was under the impression from the previous > response I needed to submit to bodhi, but I believe I misinterpreted and that > was intended for future changes going forward. Looking at bodhi now it's a > littl

Re: Defining the future of the packager workflow in Fedora

On Thu, 26 Sep 2019 at 16:46, Pierre-Yves Chibon wrote: > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote: > > Allow packagers to have a clone of the upstraem git repo > > - What about the upstream projects that still only publish a tarball at > release? What about upstream

Re: Let's talk about Fedora in the '20s!

On Tue, 7 Jan 2020 at 10:28, Miroslav Suchý wrote: > > Dne 06. 01. 20 v 18:19 Matthew Miller napsal(a): > > We're not adding meaningful end-user value by manually repackaging these in > > our own format. We _do_ add value by vetting licenses and insuring > > availability and consistency, but I thi

Re: Let's talk about Fedora in the '20s!

On Tue, 7 Jan 2020 at 13:28, Neal Gompa wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: > > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > >

Re: Let's talk about Fedora in the '20s!

On Tue, 7 Jan 2020 at 13:58, Miro Hrončok wrote: > > [...] > > For me, an ultimate success would be if upstream projects would actually use > Fedora-family distros in their CI testing. And I don't mean that they would > use > Copr or packit to package RPM packages, or that they deploy their own J

Re: Let's talk about Fedora in the '20s!

On Mon, 6 Jan 2020 at 18:28, Matthew Miller wrote: > > Hi everyone! Since it's a new year and a new decade [*], it seems like a > good time to look forward and talk about what we want the Fedora Project to > be in the next five and even ten years. How do we take the awesome > foundation we have no

Re: Let's talk about Fedora in the '20s!

On Tue, 7 Jan 2020 at 16:38, Matthew Miller wrote: > > On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote: > > For me, the main challenge Fedora faces is **positioning**. > > > > Let me explain: (I don't have numbers but) in my (limited) experience, > &

Re: Let's talk about Fedora in the '20s!

On Tue, 7 Jan 2020 at 19:03, Matthew Miller wrote: > > Red Hat has also always invested its marketing dollars in _product_; the > sponsorship of Fedora is _mostly_ from an engineering side. I'd *like* to > get more for these wider efforts, but in a very real way that Red Hat > investment is like t

  1   2   3   >