Re: Devtoolset for epel7 for build in Copr

Miroslav Suchý writes: > You have to run > >   scl enable devtools-3 $COMMAND > > to make this library available. I used to do that, but it's rather easier to source the enable script (conditionally) in %build and perhaps %check or %install. ___ devel

Re: Devtoolset for epel7 for build in Copr

[epel-devel seems a better place for this.] Dmitry Butskoy writes: > Ben Beasley wrote: >> Yes, the devtoolsets work nicely if you supply the appropriate >> incantations. I haven’t tried in COPR specifically > I've just tried and it seems that devtoolset are not available for > epel7 builds in C

Re: hdf5 fortran build failure with gcc 12

Orion Poplawski writes: > On 1/29/22 19:40, Mamoru TASAKA wrote: >> Looks like "minusone" variable looking like constant value defined >> in >> fortran/test/tH5A_1_8.F90 needs PARAMETER attribute. Tried this diff: >> ``` >> diff --git a/hdf5.spec b/hdf5.spec >> index 3b1d27b..2bac44d 100644 >> -

Re: Uninitialized variables and F37

Mark Wielaard writes: > Although I am not against trying to turn nondeterministic bugs into > deterministic ones and getting rid off more undefined code, I am > slightly worried it means those bugs will be harder to find in > production. Also I really hope we do also encourage people to use the >

dummy libraries for proprietary dependencies (especially NVIDIA)

Is there the possibility of building packages with dummy shims for proprietary dynamic libraries that could be substituted at runtime (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths provide the nasty real libthing at runtime)? Obviously there are potential technical and legal is

Re: Testing request: OpenConnect VPN with 2FA on Rawhide

In case it's not clear, note that client openconnect supports multiple VPN types, and they might behave differently (e.g. Global Protect, with a different sort of authentication flow). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: ppc64le copr

Silvie Chlupova writes: > Hi Dave, > at this point, we still don't have working ppc64le workers. Please see this > issue https://pagure.io/fedora-infrastructure/issue/9059. Unfortunately, I > can't give you better information at the moment. OK, thanks. I can sympathize, being in an infrastructu

ppc64le copr

What's the state of ppc64le in copr? Is it coming back and, if so, is there a timescale for that? Sorry I can't find the info about it from a while back, but I thought things were meant to be restored by August. It would definitely be more useful to me than s390x... __

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

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ñ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.

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

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: 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

[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: 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

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? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe s

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?

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?

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: 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

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: gcc -fno-common

Jakub Jelinek writes: > Note, if for whatever reason one wants the common behavior e.g. on a few > selected variables, one can add __attribute__((__common__)) to those > variables to override the default, it doesn't have to be just -fcommon > that changes the behavior of all non-automatic variabl

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

Mamoru TASAKA writes: > Filed: https://bugzilla.redhat.com/show_bug.cgi?id=1798636 For what it's worth, I'd have raised an issue if it has a different cause, and doesn't fixed along with the original regression, lest it looks as if I'm shirking bug reporting responsibilities. ___

Re: gcc -fno-common

Jakub Jelinek writes: > On Wed, Feb 05, 2020 at 05:13:27PM +0000, Dave Love wrote: >> GCC doesn't document the targets for which -fno-common produces better >> code. Can someone say for which of the Fedora ones it makes a >> difference? > > E.g. on any that is c

gcc -fno-common

GCC doesn't document the targets for which -fno-common produces better code. Can someone say for which of the Fedora ones it makes a difference? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fed

Re: Possible gcc/s390x bug (was Re: Mass rebuild status)

I assume this -- currently breaking procenv, as that uses -Werror -- has the same cause, as it shows up under the same circumstances: In function 'strncat', inlined from 'appendn' at string-util.c:111:2, inlined from 'appendn' at string-util.c:80:1, inlined from 'append' at str

hypre soname bump in rawhide

I'll be updating hypre in rawhide with a soname bump. (That is already in epel8, where the dependencies were being built anyhow.) I've mailed the maintainer of the dependencies but haven't heard back. petsc and sundials2 will rebuild, and I assume sundials will when the current rawhide FTBFS is f

Re: aarch64 test systems implementation

"Richard W.M. Jones" writes: > On Thu, Sep 19, 2019 at 11:27:21AM +0100, Dave Love wrote: >> (Is there a way to tell?) > > virt-what ! I guess if I'd read the man page I'd have seen that the "kvm" I saw was

Re: aarch64 test systems implementation

Kevin Fenzi writes: > On 9/19/19 3:27 AM, Dave Love wrote: >> Are the aarch64 test systems running on real or emulated hardware? (Is >> there a way to tell?) > > You mean the ones listed at > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

Re: aarch64 test systems implementation

Stephen John Smoogen writes: > It depends on what level of emulation you mean. Are you meaning "is it > an x86_64 acting like a aarch64?" then the answer is no. Yes, that's what I meant, thanks. > If you are > meaning "is it an aarch64 guest system on an aarch64" then probably > yes... we don't

Re: aarch64 test systems implementation

Jun Aruga writes: > On Thu, Sep 19, 2019 at 12:28 PM Dave Love > wrote: >> >> Are the aarch64 test systems running on real or emulated hardware? (Is >> there a way to tell?) >> >> I ask because I'm seeing bad numerical results from a test and would >

aarch64 test systems implementation

Are the aarch64 test systems running on real or emulated hardware? (Is there a way to tell?) I ask because I'm seeing bad numerical results from a test and would like to know if I can eliminate qemu as a possible cause -- not that I think that's likely. ___

hypre licence change

I'm preparing an update for hypre which has a licence change from LGPLv2 to MIT or ASL 2.0. It is required by petsc and sundials. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: failing push for un-orphaned package

Miro Hrončok writes: > On 11. 09. 19 11:14, Dave Love wrote: >> I'm puzzled why it needs re-reviewing when branches are maintained, > > Because it was only maintained in EPEL, not Fedora. I just don't understand why it would be OK for EPEL but not for Fedora, but no m

Re: failing push for un-orphaned package

Kevin Fenzi writes: > it's still retired on all the Fedora branches. > See: > > https://pagure.io/releng/issue/8723#comment-594936 > > The hook thats blocking it is a check against pdc, which rejects commits > when the package is eol/not currently supported. > > So, you need a re-review and unret

failing push for un-orphaned package

What to I need to do to be able to push to the repo of something I've got un-orphaned? I currently see: $ fedpkg push Counting objects: 10, done. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 877 bytes | 0 bytes/s, done. Total 7 (delta 4), reused 0 (delta 0) remote: Branch r

Re: Capitalized name in bugzilla review request and pagure repo

[I seem not to have sent this before.] Jordan Ogas via devel writes: > Greetings, > > I believe I have an issue. Please direct me to the correct list if the > following is not applicable here. > > My first package was recently approved, however, no one (myself included) > noticed that the bugzil

Re: unable to branch to epel8

Kevin Fenzi writes: > Hum. I see you have a lot of custom rules. Sadly the interface for doing > rules is confusing and over detailed. Would you be willing to do the > reset on them, then slowly re-add the filtering out of ones you don't > want? I think something in your rules is negating each ru

Re: unable to branch to epel8

Kevin Fenzi writes: > Let me step back a bit here... > > pagure.io is a general source forge for open source projects. It's run > by Fedora Infrastructure, but it uses another domain so people don't > think they have to only use it for Fedora related projects. > > src.fedoraproject.org is also ru

Re: unable to branch to epel8

Miro Hrončok writes: >> Remote: Creating a new reference/branch is not allowed in this project. >> To ssh://lovesh...@pkgs.fedoraproject.org/rpms/procenv >> ! [remote rejected] epel8 -> epel8 (pre-receive hook declined) >> error: failed to push some refs to >> 'ssh://lovesh...@pkgs.fedoraprojec

Re: Orphaning cloud-init, python-boto

Igor Gnatenko writes: > python-boto is dead and deprecated. Why do you want to take it? While I don't run it from Fedora, Elasticluster is one current user (see ) for what it's worth. ___ devel ma

Re: unable to branch to epel8

Kevin Fenzi writes: >> Also, I don't get any notifications from pagure (as with various other >> -- most? -- services), despite turning on anything relevant-looking in >> the notifications app. I've asked several times about lack of >> notifications with no luck or suggestions how to debug it.

Re: unable to branch to epel8

Robert-André Mauchin writes: > The PDC is the Product Definition Center: Thanks. > Your package has already a EPEL8 branch in the PDC: > https://pdc.fedoraproject.org/rest_api/v1/component-branches/? > global_component=procenv > > If the branch has not been created in dist-git, you can create i

unable to branch to epel8

I've tried to get a couple of epel8 branches created, and the tickets have been closed (twice in one case after I re-opened it) with "The branch in PDC already exists". (It worked for other packages.) I don't know what PDC is, but the branch definitely isn't in git. An example is

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

Frantisek Zatloukal writes: > On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler > wrote: > >> * the performance increase to be had is marginal, given that we are mostly >> talking about code written in C or C++ without even compiler >> vectorization >> (-ftree-vectorize) turned on, >> > > Are yo

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

I don't agree with the proposal, and am only interested in EPEL, but: Kevin Kofler writes: > I disagree with ANY raised vector instruction requirement, considering that: > * it would make Fedora incompatible with some hardware out there, That's already so for hardware which is at least of simil

Re: portable performance engineering

You wrote: > Dave Love wrote: >> they'd be rather limited by the compiler options we're supposed to use, >> that don't include vectorization, so you don't even get the benefit you >> could from SSE2. (I've been told off in review for turning th

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

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: [Scitech] Re: openmpi 3.1.3?

[Re-sending from a subscribed address, apologies for any duplicates.] Dominik 'Rathann' Mierzejewski writes: > Why not 4.0.0? It was released in September 2018 and it's supposedly ABI > compatible with 3.x: > https://www.mail-archive.com/announce@lists.open-mpi.org/msg00119.html I guess you hav

responding to CVEs

Is there any specific requirement to change packages in response to CVEs, specifically if they appear to be bogus? I can't find anything specifying that. I ask because three CVEs have triggered automated bug reports against libxsmm . I don't

Re: Orphaned packages need new maintainers (will be retired in 1 week)

Miro Hrončok writes: > On 18. 12. 18 11:22, Dave Love wrote: >>> loveshack: makedepf90 >> >> I don't think that's the case now. dl_poly used it, but I've removed >> the dependency and I wonder why it's showing up with a threat (I assume)

Re: Need help with illegal instruction errors in COPR

Orion Poplawski writes: > With the help of the very useful libSegFault I was able to generate a > backtrace in COPR with: > > export LD_PRELOAD=/usr/lib64/libSegFault.so > export SEGFAULT_SIGNALS=ill > > which pointed to the libpsm2 library. I've filed > https://bugzilla.redhat.com/show_bug.cgi?

Re: OpenBLAS: link with which library?

Kevin Kofler writes: > Jerry James wrote: >> If I understand correctly, the default is a library that cannot >> tolerate multiple threads, uses 32-bit integers in the interface, and >> does not use "a symbol name suffix", whatever that means. > > Hmmm, normally, the serial version is not itself p

Re: Orphaned Packages in rawhide (2018-08-27)

I'll take autodocksuite. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.

Re: "TLS reference ... mismatches non-TLS reference"

Vít Ondruch writes: > Dne 1.8.2018 v 13:48 Dave Love napsal(a): >> I've been trying to build a new version of the scorep package with >> %check running make check. A couple of days ago it failed with strange >> link errors concerning symbols not found which are defi

"TLS reference ... mismatches non-TLS reference"

I've been trying to build a new version of the scorep package with %check running make check. A couple of days ago it failed with strange link errors concerning symbols not found which are defined in the libraries it was linking against (apparently in the right order). Now it's failing on rawhide

Re: change in -fpic handling?

Florian Weimer writes: >> I just tried a koji scratch build of libxsmm, where the problem showed >> up; it now builds, but the test failed with a numerical error which I >> haven't seen before and I probably can't debug on any reasonable >> timescale. Is that plausibly due to the binutils change

Re: change in -fpic handling?

Florian Weimer writes: > Can this still cause symbol clashes if two linkonce sections (of > different names) contain functions which receive annobin annotations? > > Anyway, looks like these annobin changes exposed a binutils bug: > > > > (W

Re: change in -fpic handling?

Florian Weimer writes: > On 06/26/2018 02:53 PM, Dave Love wrote: >> What has changed in the last month to affect building shared libraries >> in rawhide? >> >> I tried to rebuild libxsmm in rawhide, after changing the spec to use >> python2 explicitly, and it

Re: change in -fpic handling?

Petr Pisar writes: > On 2018-06-26, Dave Love wrote: >> What has changed in the last month to affect building shared libraries >> in rawhide? >> >> I tried to rebuild libxsmm in rawhide, after changing the spec to use >> python2 explicitly, and it failed w

change in -fpic handling?

What has changed in the last month to affect building shared libraries in rawhide? I tried to rebuild libxsmm in rawhide, after changing the spec to use python2 explicitly, and it failed with /usr/bin/ld: build/intel64/libxsmm_main.o: relocation R_X86_64_PC32 against symbol `libxsmm_crc32_u64'

Re: equivalent of Debian config-package?

Neal Gompa writes: > The reason Ansible is used is because we have no current equivalent > facilities to do delayed script execution or diversion of > configuration files. Both are functions required for Debian-style > configuration packages. Feel free to file an issue with rpm upstream[1] > to f

Re: equivalent of Debian config-package?

devzero2000 writes: > Il gio 31 mag 2018, 13:42 Neal Gompa ha scritto: > >> On Thu, May 31, 2018 at 6:54 AM Dave Love >> wrote: >> > >> > Is there any existing system for rpm like the Debian one >> > <https://debathena.mit.edu/config-package-dev/

Re: equivalent of Debian config-package?

Stephen John Smoogen writes: > 1. Do not strip out who you are replying to. There are hundreds of > people on this list and people come in at different times... and I am > not sure who "You" was. Apologies, it was a mistake due to Gnus configuration and replying through Gmane; I understand mail

Re: equivalent of Debian config-package?

Josh Boyer writes: >> I guess we disagree about what the problem is, but it's unfortunate if >> Fedora/RH isn't interested in the sort of environment for which >> config-package was developed. > > Can you elaborate more on what that environment is? A fairly large university (not as big as MIT) w

Re: equivalent of Debian config-package?

You wrote: > Neal Gompa wrote: >> No such thing currently exists, because an equivalent to `dpkg-divert` >> does not exist in RPM. > > You are probably aware of this, but for the other readers of this thread: I wasn't anyhow, thanks! > File triggers can be (ab)used to do something like that, th

Re: equivalent of Debian config-package?

You wrote: > I think generally the Fedora/RH-ecosystem answer is to use Ansible for > configuration, rather than configuration packages. > > That's not sayin' there can't be another answer, but in general that's > the route *I'd* take to solve this problem on my systems. I guess we disagree abou

Re: equivalent of Debian config-package?

Neal Gompa writes: > No such thing currently exists, because an equivalent to `dpkg-divert` > does not exist in RPM. > > It is technically possible to implement such a mechanism, but it does > not exist right now. Thanks. I assume even if it was feasible to work on it, it wouldn't appear in cur

equivalent of Debian config-package?

Is there any existing system for rpm like the Debian one for building local configuration packages? If not, would it be feasible to implement one? ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Is it possible atlas is linked wrongly by new binutils?

Kevin Kofler writes: > Dave Love wrote: >> You'll find Dominik was correct if you try it. > > If you are talking about the missing RPM AutoProvides: > Provides: libblas.so.3()(64bit) > does wonders. I mean you need to get the soname right and ensure that you have eve

Re: Is it possible atlas is linked wrongly by new binutils?

Kevin Kofler writes: > Dominik 'Rathann' Mierzejewski wrote: >> It also needs some patching, because each library has a different >> SONAME. > > Symlinking > libblas.so.3 → libopenblas.so.0 > liblapack.so.3 → libopenblas.so.0 > is enough to get things linked against BLAS and/or LAPACK to pick up

Re: Is it possible atlas is linked wrongly by new binutils?

Matthew Miller writes: > On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote: >> Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, >> i.e., having symlinks or linker scripts pointing at least libblas.so and >> liblapack.so to libopenblas.so.*, ideally also lib

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

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

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

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

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

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

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

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

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

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

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

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

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: > 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

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

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: 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: 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: > 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: 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: 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

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: 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

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: [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

  1   2   >