openmpi/python-related problems in epel7 ppc buildroot

I'm trying to build a new package. It's failing on epel-7-ppc64le (only) with two sorts of errors in %check which appear to be problems with the build root, e.g. . One is from openmpi of a sort I don't recognize but which looks like an

Re: openmpi/python-related problems in epel7 ppc buildroot

Orion Poplawski writes: > On 08/18/2015 09:21 AM, Dave Love wrote: >> I'm trying to build a new package. It's failing on epel-7-ppc64le >> (only) with two sorts of errors in %check which appear to be problems >> with the build root, e.g. >> <https://koj

Re: F23 Self Contained Change: RPM MPI Requires Provides

Sandro Mani writes: >> Where are we with this? I see some F23 builds but no updates yet. >> >> >> Formally, this Change has been removed from the scope of F23 as it >> was not ready for Alpha, which is a requirement to have a Change in >> a release. >> However Zbyszek told me yesterday that

Re: openmpi/python-related problems in epel7 ppc buildroot

Orion Poplawski writes: > On 08/19/2015 06:20 AM, Dave Love wrote: >> Orion Poplawski writes: >> >>> On 08/18/2015 09:21 AM, Dave Love wrote: >>>> I'm trying to build a new package. It's failing on epel-7-ppc64le >>>> (only) with

Re: openmpi/python-related problems in epel7 ppc buildroot

Orion Poplawski writes: > openmpi is clearly not completely broken on epel7-ppc64. Many packages have > been built for it and appear to run fine. Do they not run tests, or is this a recent thing? Presumably it should be documented somewhere, anyhow. >>> I'm happy to help out as well, but >>>

Re: openmpi/python-related problems in epel7 ppc buildroot

I wrote: > I was about to post about that. I probably mis-read the koji output, > but then it was fine in epel7 in mock and copr. Actually, it would fail in copr epel7; the test was disabled there. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listi

working way to push updates currently?

Is there a currently-working way to push an update? fedpkg update (running on rhel6, but with the latest available versions of bodhi and python-fedora as far as I can tell) crashes. When I remember the non-obvious way to do it on the bodhi web site and try, I get a pop-up saying just "Required",

Re: Resources for upstream testing?

Dave Johansen writes: >> We do have docker images that can be used [0] - but we currently don't >> have a user friendly way to find them. You currently have to look >> through koji to find them [1]. >> >> Hope this helps! >> >> [0] >> >> https://kojipkgs.fedoraproject.org//work/tasks/7896/1092789

Re: working way to push updates currently?

Kevin Fenzi writes: > On Thu, 03 Sep 2015 17:33:44 +0100 > Dave Love wrote: > >> Is there a currently-working way to push an update? >> >> fedpkg update (running on rhel6, but with the latest available >> versions of bodhi and python-fedora as far as I can

Re: working way to push updates currently?

Jeff Backus writes: > On Thu, Sep 3, 2015 at 1:39 PM, Kevin Fenzi wrote: > >> > When I remember the non-obvious way to do it on the bodhi web site >> > and try, I get a pop-up saying just "Required", though I managed to >> > operate it previously. >> >> That's also pretty weird. Can you file an

Re: working way to push updates currently?

Kevin Fenzi writes: > On Fri, 04 Sep 2015 11:10:40 +0100 > Dave Love wrote: > >> I already filed an issue in bugzilla, per instructions for EPEL >> packages, since the client crashes. (It may well actually be a >> problem with python-fedora.) Was that a waste of t

Re: Can't push update to stable

Jerry James writes: > I tried this morning and tonight to push this update to stable: > > https://bodhi.fedoraproject.org/updates/FEDORA-2015-14375 > > Both times, bodhi told me that this update has not yet met the minimum > testing requirements defined in the Package Update Acceptance Criteria.

Re: Resources for upstream testing?

Dave Johansen writes: >> For what it's worth, you can use vagrant with the >> kaorimatz/fedora-rawhide-x86_64 box. A search on the hashicorp atlas >> finds it. >> > > Are there any instructions on how to use this for testing? I don't understand. It provides a system in which you can do what yo

Re: Proposal to reduce anti-bundling requirements

Michael Stahl writes: >> Symbol interposition is used a lot for very useful features, blocking >> interposition would break a lot of stuff. > > really? i've always thought that it was only useful for libc symbols, > but maybe that's because i don't work on base OS stuff. I'd guess most uses are

Re: rpmbuild - empty RPMS directory

arnaud gaboury writes: > I have been working on my first rpmbuild since quite a few days now. > > The rpm is intendeed to install R[0] built with Intel MKL libraries > and Intel compiler. As a base for the spec file, I used the one from > Fedora R package[1]. Why? I ask as someone who supports

Re: openmpi 1.10.0 coming to rawhide soon

Orion Poplawski writes: > I'll be building openmpi 1.10.0 for rawhide soon. This has soname bumps so > I'll be rebuilding dependent packages as well: Has the ABI actually changed? What I've seen about it suggested not, and NEWS doesn't say -- just "based on the v1.8.x series, but with a few ne

Re: Resources for upstream testing?

Dave Johansen writes: > I've never used docker/vagrant, so I was wondering if there was any > information on how to get the docker image setup so it can be used. Also, > is there anything special that needs to be done once it's running? Or do > the typical commands like "dnf install" and such "ju

Re: rpmbuild - empty RPMS directory

arnaud gaboury writes: >> Why? I ask as someone who supports R rpms on HPC systems and knows a >> bit about relevant libraries and compilers. > > Please visit this blog[0] or many other talking about R-benchmark.R. I don't think this is the place for a lecture on all that's wrong with that; it'

Re: Proposal to reduce anti-bundling requirements

Florian Weimer writes: > I think it is important to keep the LD_PRELOAD case separate from > implicit interposition between the main program (if linked with -E) and > DSOs or between different DSOs. LD_PRELOAD is quite explicit in what it > wants to do. OK. (I probably don't understand properl

RHEL 6.6 MPI mess

The undocumented openmpi and mpich updates in RHEL6.6 have broken binary compatibility and seem to be provoking general rebuilds of things in EPEL. While that may be OK for things that are packaged in EPEL, it at best doesn't help with our HPC users' locally-built programs or local/copr-published

Re: RHEL 6.6 MPI mess

Doug Ledford writes: > There was a changeover in maintainership for this package internally, so > I'm coming into this issue cold. Thanks for responding. (I assume that means the Red Hat openmpi package.) I wasn't expecting to get it sorted out in RHEL, and wanted to avoid what looks like bein

Re: RHEL 6.6 MPI mess

Orion Poplawski writes: > Just a quick note - this discussion belongs on the EPEL mailing list. Apologies. I don't remember seeing that when I read the instructions to try to get packages into EPEL. I'll check whether it's there/obvious when I have a chance. -- devel mailing list devel@lists.

Re: mpich 3.1.4 in rawhide - soname changes

Sandro Mani writes: >> openmpi seems to be using >> >> /usr/lib64/openmpi/bin/ >> /usr/lib64/openmpi/lib/ >> >> so perhaps the "mpich" option is better than a generic "mpi"? >> > Yes, and this is the way it was before. I'd say this is just an > oversight in mpich-modules.patch [1], @MPILIBNAME@ c

Re: mpich 3.1.4 in rawhide - soname changes

Orion Poplawski writes: >> Do we know if the actual ABI is incompatible, rather than library >> names/contents? If not, a compatibility libmpich might be useful, >> partly to avoid breaking existing binaries and partly because I suspect >> some things will look for a library of that name, at lea

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

[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 will set OpenBLAS as system-wide default backend, and > at the

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

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 think it produces? Obviously GPLv3 is incompatible with GPLv2, for instance, and typically with other strong copyleft

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

Dominik 'Rathann' Mierzejewski writes: > What exact alternative are you proposing, then? Carrying downstream > patches to all BLAS/LAPACK implementations like Debian? I don't think > that's sustainable. You don't need patches to be able to substitute an ABI-compatible version (with the soname co

Re: How do Fedora developers get access to devtoolset for testing.

Jonathan Wakely writes: > On 20/07/20 16:01 -0500, Steven Munroe wrote: >>Jonathan Wakely wrote: >>> Why are you asking fedpkg to build for f33 if you are trying to >>> package something for el7 and el8? >> >>I am trying to get better turn around for myself as I have local >>access to a POWER8 ma

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

Iñaki Ucar writes: > So here you are exclusively talking about BLIS, because other > libraries implement BLAS + some parts of LAPACK. I may agree that > doing the latter is a bad idea given that the reference implementation > offers two distinct libraries. But that's the landscape we have > unfor

Re: How do Fedora developers get access to devtoolset for testing.

Steven Munroe writes: > I come from a different culture and experience. I am not as conversant > in Fedorian as I should be. So I tend to misunderstand what is plain > to you all. Really, it's nothing specific to Fedora. The same would apply to any GNU/Linux distro (or other OS with a typical p

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

I meant to say that wrapping symbols may cause some confusion with debugging and profiling, though I don't think that's critical where its necessary. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists

Self introduction: Dave Love

I've just submitted my first package, the procenv tool for showing the process environment: I have more to offer which are relevant to HPC or other research computing. There's a collection of specs for packages I've installed at

Re: Proposal to reduce anti-bundling requirements

Björn Persson writes: > Florian Weimer wrote: >> I would really like to see DT_NEEDED-based use cases for >> symbol interposition. > > Well, there is the thread wrapper I wrote for the Ada Milter API to > prevent Libgnat from leaking memory when Libmilter's threads terminate. > I think what it do

Re: Proposal to reduce anti-bundling requirements

Tom Hughes writes: > Recently I even saw a case of a header only C++ library bundling > another C++ head library which raises slightly metaphysical questions > since dependants of a header only library need to be rebuilt when it > changes anyway if they are to pickup security fixes. Strictly spea

Re: Self Introduction: Dominique Martinet

Dominique Martinet writes: > Hi, > > I'm a developper/sysadmin at CEA, a French research institute, mainly > working on HPC clusters - both maintenance and designing new ones. That's good to see for some of us. In case you don't know, it's worth looking under http://copr.fedoraproject.org/, as

Re: Proposal to reduce anti-bundling requirements

Stephen John Smoogen writes: > Because in this networked world > everything becomes security sensitive because a hacker doesn't need to > be root to do a lot of things. My opinion is partly informed by my world being networked, with experience of compromises on and from research systems, for aro

Re: Packaging question on MPI requires

Sandro Mani writes: > On 22.10.2015 16:54, Sandro Mani wrote: > So the package is installing pynestkernel.so in > /usr/lib64/python2.7/site-packages/nest/pynestkernel.so. However, the > dependency generator expects MPI-enabled binaries to be in one of > several known MPI directories, which are >

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: >> What are you supposed to do with MPI packaging for another language such >> as R? By the sound of it >> >> and friends will fail now. > As a short-term solution, it is always possible

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: >> Surely this isn't scalable. What would happen with a common API for N >> different Scheme implementations, for instance? I'm also interested in >> Haskell; others might want the bindings to Common Lisp, ruby, Tcl... >> Currently CLASSPATH isn't set for the

Re: Packaging question on MPI requires

Zbigniew Jędrzejewski-Szmek writes: > I think this thread is getting too speculative: after all, we're > talking mostly about agreeing on a few directories. > Is there something broken that we should fix? > > Zbyszek I think that depends on whether you want to enable anything other than C(++), P

Using external repos in copr for yum and dnf targets

I have a copr that requires external repos for devtoolset and autotools to build EPEL packages. I added the external repos, and it used to work fine, even though there had to be separate repos for EPEL5 and EPEL6. (It's a collection of many things with all the targets in the same copr -- maybe tha

Re: Packaging question on MPI requires

Sandro Mani writes: >> I think that depends on whether you want to enable anything other than >> C(++), Python, and Fortran MPI packages (generally, not specifically in >> relation to the dependency stuff). I know I should have raised this >> before and probably somewhere else... > I suppose one

conditionalizing %license

What's the correct way to write a spec file that obeys the %license* stipulation but also works for epel6? Some time ago I was told to follow https://fedorahosted.org/fpc/ticket/411 and write %{!?_licensedir:%global license %%doc} and that now also appears in https://fedoraproject.org/wiki/EPE

Re: conditionalizing %license

Richard Shaw writes: > On Tue, Dec 1, 2015 at 10:44 AM, Dave Love wrote: > >> What's the correct way to write a spec file that obeys the %license* >> stipulation but also works for epel6? >> >> Some time ago I was told to follow >> https://

Re: conditionalizing %license

Sérgio Basto writes: > On Ter, 2015-12-01 at 16:44 +0000, Dave Love wrote: >> What's the correct way to write a spec file that obeys the %license* >> stipulation but also works for epel6? >> >> Some time ago I was told to follow >> https://fed

building software collections in copr

It's obviously possible to build software collections in copr since some exist, but I don't understand how. What's the secret? At least in the el6 root, I don't see a way to pick up scl-utils-build which seems to be needed in the root if you follow the documentation for producing SC packages. --

Re: New scitech FAS and COPR group

Orion Poplawski writes: >> Why COPR instead of EPEL? >> >> EPEL is part of Fedora package git tree, all extra stuff from Fedora is >> available in one place... >> >> For me COPR is good solution for tests before package lands in Fedora (or >> EPEL). > > Oh yeah, I already maintain quite a lot

Re: building software collections in copr

Remi Collet writes: > Le 07/01/2016 12:28, Dave Love a écrit : >> It's obviously possible to build software collections in copr since some >> exist, but I don't understand how. What's the secret? >> >> At least in the el6 root, I don't see a way

Re: ZFS on linux

Zach Villers writes: > I understand. My thought was, that there seems to be a push to add support > in Debian and Ubuntu. Would it now be possible/make sense to create maybe a > nodebug kernel package based on a stable kernel supported by ZFS and > zfs/spl packages maybe even as a copr repo? Wha

Re: ZFS on linux

Reindl Harald writes: >>> who is "Lawrence Livermore"? >> >> Lawrence Livermore National Laboratory is an organization founded by >> the University of California to do research and development for >> academic and government purposes. The US Department of Energy >> commissioned them to port ZFS to

Re: ZFS on linux

Stephen John Smoogen writes: > Lawrence Livermore National Laboratory is a US Government/Department > of Energy laboratory that UC Berkeley has a hand in managing. It was > not founded by the University of California but came out of the post > Manhatten project to build the hydrogen bomb. The US

Re: Fedora development of Snap packages

Przemek Klosowski writes: > It would be nice if there was a 'container snapshot' facility that > would convert between a native application package from Fedora or > Debian and a portable container---possibly both ways. Obviously, > native->container is desirable for portability; the opposite > co

LBNL BSD licence

I've realized that the licence for a package I've recently had reviewed is actually "LBNL BSD" , not BSD3 with a DoE disclaimer, as I thought. (Mea culpa, but licensecheck didn't spot it.) Anyway, I've fixed that, but I can't find any discussion a

Re: LBNL BSD licence

Haïkel writes: > Do not change shipped license file from upstream. Of course (though Fedora doesn't seem to regard modifying a licence document as much of a legal issue as I do ). I should have said that COPYING is just a pointer to LBNL's st

Re: Too fast karma on Bodhi updates

Adam Williamson writes: > "Install the package and see if the system breaks" is an appropriate > form of testing for some packages, but not all, many are not at all > related to typical desktop system functionality. Folks do need to make > sure they understand what a package is for and have actua

Re: Too fast karma on Bodhi updates

"Gerald B. Cox" writes: > It's very simple to control whether something is pushed automatically, and > it's also easy > to control the amount of karma required for the automatic push. Yes, I edited it. > Not only > is it documented, it is in the file you > modify when submitting the update. Yo

[Koji] Re: [Koji] #333: no login button in web interface

Forwarding in case others are confused by this. I can't figure out how to use the cli for everything. For instance, how do I get a list of recent scratch builds? --- Begin Message --- #333: no login button in web interface + Reporter: loveshack |

Re: [Koji] Re: [Koji] #333: no login button in web interface

Charalampos Stratakis writes: > Hi. > > Doesn't 'koji list-tasks --mine' work for scratch builds? I couldn't find a way to show either scratch build tasks or finished tasks of any sort with the cli. There doesn't seem to be any separate documentation. -- devel mailing list devel@lists.fedorapro

Re: [Koji] Re: [Koji] #333: no login button in web interface

Kevin Fenzi writes: > You can have FMN ( https://apps.fedoraproject.org/notifications/ ) mail > or irc query you for all your scratch builds. Yes, but that takes hours (I'd say normally about half a day) and I keep losing notifications somehow. > You can also find all scratch builds of yours t

Re: [Scitech] Fedora scientific packaging

Sandro Mani writes: > That said, there is now a github repo which contains the > work-in-progress stuff for packaging Salome (and some initial OpenFOAM > work) here [2]. People interested in joining these efforts or sharing > initial work on other scientific packages are very welcome to join the

MPI packaging change?

I've been mostly out of action for a while but am trying to sort out an MPI package which is now uninstallable in rawhide and I don't know what's changed in the packaging procedure. It's just an MPI-based library which is failing on the libsuperlu_dist.so.1()(64bit) requirement as follows: $ rp

"Unexpected dependencies" from ppc64le build

I get this causing a failed build on fedora-22-ppc64le but the package builds OK on x86. Can anyone suggest why and what to do about it? If it's due to the build procedure, it's buried in cmake, which is pretty much beyond my ken... cd /builddir/build/BUILD/libomp_oss/src && /usr/bin/perl /bu

Re: "Unexpected dependencies" from ppc64le build

Orion Poplawski writes: > check-depends.pl appears to be part of libiomp, so I think it's an issue about > what it thinks is an okay dependency. ld64.so.2 may be a ppc64/le specific > library that the libiomp developers haven't encountered before. Thanks. I'm not awake, saw it as an rpm check

Re: Reviews swap

Antonio Trande writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi all, > > I have three pending reviews: > > - - parmetis https://bugzilla.redhat.com/show_bug.cgi?id=1323227 I'm not getting through to that at present, but as far as I can tell, parmetis is (still) non-free

changing project homepage in apps and pkgdb

How do you change the homepage listed in a project's apps page and "upstream" in pkgdb (e.g. in https://apps.fedoraproject.org/packages/powerman and the different one in https://admin.fedoraproject.org/pkgdb/package/rpms/powerman/)? -- devel mailing list devel@lists.fedoraproject.org http://lists.f

packaging suid files

I have a package to submit that has an suid binary. The packaging guidelines say in that case you must %global _hardened_build 1 and it turns on PIE/PIC. However, it doesn't do so on el6, at least. Should flags be added by hand and, if so, exactly which? Also, does an suid binary require somet

Re: packaging suid files

Orion Poplawski writes: > This may help: > > https://fedoraproject.org/wiki/Changes/Harden_All_Packages Maybe... > I've done this for EL6: > > # _hardened_build not working for EL6, at least define > __global_ldflags for now > %{!?__global_ldflags: %global __global_ldflags -Wl,-z,relro -Wl,-z,n

Re: RFH: Annotating ELF binaries

Nick Clifton writes: > Hello Everyone, > > We (the tools team at Red Hat) are working on a project to add > annotations to ELF binaries, so that we can answer various questions > about them. We have set up a wiki page about the project here: > > https://fedoraproject.org/wiki/Toolchain/Wat

Re: upcoming build and release developer flag day December 12 2016

Is this going to work for those of us who use RHEL, not Fedora (and are only actually interested in EPEL)? Also, will it work with Heimdal clients? (The Fedora packager stuff is rather hit and miss under EPEL at the best of times.) ___ devel mailing lis

clarification of package naming guidelines

Could someone clarify the rules on package naming ? Background: I've packaged something its author calls SuperLU_DIST using the rpm name superlu_dist. I interpreted that as cons

Re: clarification of package naming guidelines

Thanks for the comments. "Gerald B. Cox" writes: > On Thu, Dec 1, 2016 at 8:39 AM, Mattia Verga > wrote: > >> >> So, in my opinion, you did it right naming your package "superlu_dist". >> For sure, you MUST not use uppercase letters. > > > I believe there is a bit of leeway for the packager her

Re: installing RPMs on NFS filesystems

den...@ausil.us writes: > Without filesystem capabilities, many things will not work. Ping as a > user for instance. Lots of setuid binaries switched to using > filesystem capabilities rather than setuid and require it to work. RPM > failing is the right thing to do. I haven't actually noticed pr

Re: qr_mumps rename

Antonio Trande writes: > Hi all. > > I wish to rename 'qr_mumps' to 'qrmumps', Why? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clarification of package naming guidelines

"Gerald B. Cox" writes: > On Mon, Dec 5, 2016 at 3:30 AM, Dave Love wrote: > >> >> Why are most people going to use superlu-dist when that's not the proper >> name of the software? I'm not familiar with a SuperLU user community, >> but I

Re: qr_mumps rename

Antonio Trande writes: > On 12/05/2016 12:45 PM, Dave Love wrote: >> Antonio Trande writes: >> >>> Hi all. >>> >>> I wish to rename 'qr_mumps' to 'qrmumps', >> >> Why? >>

Re: Packagers - Flag day 2016 Important changes

Dennis Gilmore writes: > Greetings.  > > As previously announced, releng has made a number of changes as part of > it's 2016 "flag day".  > > All package maintainers will want to make sure they have updated to > the  > following package versions (some may be in testing as of this email): > >

Re: Packagers - Flag day 2016 Important changes

Dennis Gilmore writes: > See the general kerberos information at:  > https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication > for more details. I was going to try to authenticate, even if the tools won't work, but that's missing the fundamental information about how to configure t

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: > This is included in the fedora-packager-0.6.0 update. > > Make sure your /etc/krb5.conf has the include to include them > from /etc/krb5.conf.d/ though That will break Heimdal, for people who use that. ___ devel mailing list -- d

Re: Packagers - Flag day 2016 Important changes

Christopher writes: > Better yet, save your password in gnome-keyring: > keyring set login fedora > And retrieve it for kinit: > keyring get login fedora | kinit usern...@fedoraproject.org None of this is any good if you're not using a desktop system, is it? I'm probably not the only one who doe

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: > Ah, the actual package produced is python2-cccolutils (from the > python-cccolutils package). > > python2-cccolutils.x86_64 1.4-1.el6 epel-testing Isn't that wrong for EPEL? ___ devel mailing list -- devel@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: > fedora-packager-0.6.0 includes: > > /etc/krb5.conf.d/fedoraproject_org > and > /etc/krb5.conf.d/stg_fedoraproject_org > > which contain: > > [realms] > FEDORAPROJECT.ORG = { > kdc = https://id.fedoraproject.org/KdcProxy > } > [domain_realm] > .fedoraproject.org =

Re: Packagers - Flag day 2016 Important changes

Petr Mensik writes: > Sure, I am really missing this information written on the wiki page. The > secret is, they are in the DNS record. If you try > $ host -t URI _kerberos.fedoraproject.org Thanks. I forget about DNS records because I've been not trusting them forever. However, I only know

Re: Packagers - Flag day 2016 Important changes

Simo Sorce writes: > On Tue, 2016-12-13 at 10:54 +0000, Dave Love wrote: >> Kevin Fenzi writes: >> >> > This is included in the fedora-packager-0.6.0 update. >> > >> > Make sure your /etc/krb5.conf has the include to include them >> > f

Re: Packagers - Flag day 2016 Important changes

Simo Sorce writes: > If you really need to automate it because typing a password is too hard: > cat ~/.mykrbpassword | kinit myusername It needs to be automated principally because the password is not memorable. I assume infrastructure people would rather we don't use the least secure credentia

Re: Packagers - Flag day 2016 Important changes

Stephen Gallagher writes: >> There is actually a Kerberos mechanism for storing credentials even if >> it somewhat defeats the object, particularly on a shared system. It >> would be better if you could forward the GSS identities over ssh, but I

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: > On Tue, 13 Dec 2016 14:36:06 + > Dave Love wrote: > >> Simo Sorce writes: >> >> > If you really need to automate it because typing a password is too >> > hard: cat ~/.mykrbpassword | kinit myusername >> >> It nee

Re: Packagers - Flag day 2016 Important changes

Simo Sorce writes: > But I am not sure why you would need to forward your user credentials to > servers normally. Did you copy your certs everywhere before ? I would > think the normal case is that people have 1 development machine where > they handle packaging. Some people use "Enterprise Linux

Re: Packagers - Flag day 2016 Important changes

Simo Sorce writes: > The krb5.conf is interchangeable if you use a subset of directives > common to both, this directive is not common to both, therefore it is > incompatible with Heimdal. Obviously; sorry I pointed it out. > Samba has been ported to MIT Kerberos for Fedora uses, and the abilit

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: > If you are using the default kerberos cache (the linux kernel keyring), For what it's worth, not on RHEL6, and some of the (unsatisfactory) methods for dealing with Kerberos in batch systems currently rely on the traditional ccache, whether or not they could copy credential

Re: Packagers - Flag day 2016 Important changes

Kevin Fenzi writes: >> Some people use "Enterprise Linux" (ugh) server systems in >> "enterprises" which have Kerberized services -- like networked home >> filestores, where the old certificate is. (I did copy the >> credentials with Firefox sync.) OK, Red Hat people think we shouldn't >> work t

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

David Schwörer writes: > On 4/14/20 11:06 AM, Miro Hrončok wrote: >> orangefs  orphan   1 >> weeks ago > > I took orangefs and rebuild it. > However I am not able to close or take the FTBFS bug [1] > The documentation only says I should take the bug

Re: OrangeFS

David Schwörer writes: > Upstream said in Februar they where working on a 3.0 release [1]. Not > sure where they are working though, because there are no new commits > [2]. Omnibond as in omnibond.com? Not sure that helps with orangefs, > there link to orangefs is broken, and they only refer to t

Re: What CPU extensions can we assume are available by arch?

Richard Shaw writes: >> tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support >> at least AVX2" and it met with a lot of backlash. Yes, that's the wrong approach to performance engineering. > Now that you mention it that does tickle some brain cells... > > So it seems what's

Re: What CPU extensions can we assume are available by arch?

Kevin Kofler writes: > Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of > the vector code? It should be faster than scalar (especially considering > that the "scalar" floating-point code (under the default -mfpmath=sse) > actually loads everything into SSE2 register

Re: What CPU extensions can we assume are available by arch?

Jun Aruga writes: > You do not need to care about the availability by arch or compiler > when using this library. As far as I can tell, it doesn't do dynamic dispatch. Experimentally, if you build with -mavx2 and run on ivybridge (or for skx and run on haswell), the test code generates illegal

Re: What CPU extensions can we assume are available by arch?

Jun Aruga writes: > For the better user experience, we are promoting the system library > for both RPM and Debian based Linux distributions. What system library, for what purpose? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe s

Re: What CPU extensions can we assume are available by arch?

Kevin Kofler writes: > Florian Weimer wrote: >> In general, that is not true. You can use the target function attribute >> and function multiversioning instead in many cases. > > This may (or may not) have been recently fixed, but last I checked, > intrinsics for a vector instruction set XYZ2 w

Re: What CPU extensions can we assume are available by arch?

Jun Aruga writes: >> > For the better user experience, we are promoting the system library >> > for both RPM and Debian based Linux distributions. >> >> What system library, for what purpose? > > Hi Dave, > The simde system library is > > * simde-devel in Fedora and EPEL [1] > * libsimde-dev in D

portable performance engineering (was: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update)

I'm afraid this turned into a bit of and essay on more useful things Fedora could do for portable performance engineering, should anyone care. I actually have no interest in Fedora except as a requirement to work on packaging for research software around EPEL, specifically for HPC and so performan

Re: portable performance engineering

Benson Muite writes: > Tradeoffs to satisfy a wide variety of users - a base system with most > common software easy to try which can then be re-installed for > performance. Flatpacks should help with easy but not performance > optimal installation of many packages. Spack (https://spack.io/) may

  1   2   >