Summary/Minutes from today's FESCo Meeting (2024-04-01)

(sorry for the crazy links -- meetbot didn't grab the intended name) Text Log:

Schedule for Monday's FESCo Meeting (2024-04-01)

Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-04-01 19:30 UTC' Links to all issues to be

Re: rpmbuild problem with rust code

On 2/26/24 1:41 PM, Richard W.M. Jones wrote: > It's a bit unfortunate that Rust used the shebang syntax here, > although in practice they couldn't be confused as these files > shouldn't ever be executable. It's _possible_ to play comment tricks for executable rust scripts, because rustc allows

Re: Introduction / unorphaning package request

Welcome! Since name collisions are fun, I want to clarify for everyone else that we are not the same person. I'm jistone, he's jostone, and I'm sure this won't confuse anyone... :) On 2/23/24 6:23 AM, Joshua Stone wrote: > Hello everyone, > > I've been a Linux user since my friends showed me

Re: do we need CONFIG_UPROBES=y in our kernels?

On 2/13/24 7:36 AM, Jerry James wrote: > On Mon, Feb 12, 2024 at 11:16 AM Marius Schwarz > wrote: >> In a german developer blog article was the topic raised, that with >> uprobes enabled, userland apps can i.e. circumvent tls security(and >> other protections), >> by telling the kernel to probe

Summary/Minutes from today's FESCo Meeting (2024-01-22)

= # #meeting:fedoraproject.org: fesco = Meeting started by @jistone:fedora.im at 2024-01-22 19:30:53 Meeting summary --- * TOPIC: #3145 Delay mass rebuild for Fedora 40 until f40-build-side-81394 side-tag is

Schedule for Monday's FESCo Meeting (2024-01-22)

Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-01-22 19:30 UTC' Links to all issues to be

Re: F40 Change Proposal: LLVM 18 (System-Wide)

On 1/5/24 5:18 AM, Stephen Gallagher wrote: > On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney wrote: >> >> Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive

Re: more distinct default bash prompt?

On 5/22/23 10:59 AM, Chris Adams wrote: > Once upon a time, John Reiser said: >> Warning: This is intrusive because reading the status code via "$?" resets >> it to zero: >>$ false >>$ echo $? >>1 >>$ echo $? >>0 > > That is incorrect. The second reading of $? is the exit

Re: Firefox builds broken on F38/39

On 4/30/23 11:51 AM, Demi Marie Obenour wrote: > On 4/30/23 06:41, Fabio Valentini wrote: >> On Sun, Apr 30, 2023 at 8:00 AM Bojan Smojver via devel >> wrote: >>> >>> Thank you for the pointer Kevin! Trying to build with older rust in >>> corp now: >>>

Re: libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x

On 2/3/23 8:04 AM, Pete Walter wrote: > I took over libgit2 from Igor when he gave up all his packages and have > since tried to get it up to date. libgit2 is a bit special because it > bumps soname every once in a while and then other packages often fail to > rebuild against the new version both

Re: HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates

On 11/22/22 11:59 AM, Simo Sorce wrote: > On Tue, 2022-11-22 at 17:13 +0100, Fabio Valentini wrote: >> - rust-curve25519-dalek > > Asymmetric cryptography in pure rust should not be used, there is still > no support in the language for constant time operations, which means > there is a fat chance

Re: HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates

On 11/22/22 8:13 AM, Fabio Valentini wrote: > List of Rust library-only packages, > > - rust-rustfilt This one does have a binary, a Rust equivalent to binutils' c++filt. It's OK though -- c++filt knows Rust mangling these days, whereas rustfilt doesn't know C++, so it wouldn't be much loss to

Re: Silent changes in Packaging Guidelines

On 11/4/22 1:10 AM, Florian Weimer wrote: > Another hard one is rust, which has hashed sonames like > /usr/lib64/libstd-09076360fd960627.so. The hash is only known after > building the package because that fixes the ephemeral ABI. Right... I could glob a little more specifically for the few

Re: Karma for OpenSSL needed

On 11/1/22 3:51 PM, Kevin Fenzi wrote: > On Tue, Nov 01, 2022 at 02:55:34PM -0700, Josh Stone wrote: >> On 11/1/22 11:16 AM, Neal Gompa wrote: >>> That said, the packages *are* signed in Koji, because as soon as it's >>> submitted to Bodhi, the packages

Re: Karma for OpenSSL needed

On 11/1/22 11:16 AM, Neal Gompa wrote: > That said, the packages *are* signed in Koji, because as soon as it's > submitted to Bodhi, the packages are signed in-place in Koji. Is that really in-place? Bodhi says these are signed, but when I download from koji, "rpm -qip" still shows "Signature:

Re: Planning to start unifying native and mingw packages

On 9/2/22 5:07 AM, Fabio Valentini wrote: > On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw wrote: >> >>> If looking at a single package in isolation it may look wasteful, but from >>> the POV of the distro as a whole packages with potential mingw sub-RPMs >>> are a small subset of what goes through

Re: Packaging a cross-compilation environment (wasi-libc)

On 8/22/22 5:35 AM, Florian Weimer wrote: > * Jan Staněk: > >> Hi list, >> in order to be able to compile WASM natively on Fedora, >> I'm trying to package wasi-libc[1] to provide the Web Assembly System >> Interface. >> >> [1]: https://github.com/WebAssembly/wasi-libc >> >> My trouble is that

Re: Rust Stack Spring Cleaning (in Winter)

Thank you for working on this, Fabio! On Mon, Dec 20, 2021 at 6:32 AM Fabio Valentini wrote: > Hello Rust packagers, > > (I'm sending this email to the devel and rust lists, and I've added all > directly > affected package maintainers in Bcc - because adding them all to the "To" > or > "CC"

Re: [Rust] Re: [EPEL-devel] Re: What to do with Rust packaging in EPEL9?

On 11/27/21 6:40 AM, Igor Raits wrote: > On Sat, Nov 27, 2021 at 2:51 PM Neal Gompa wrote: > > The macros and tools that power the rust packaging stuff (aside from > rust-srpm-macros) are not shipped in CentOS/RHEL 9, so we can ship it > in EPEL 9 if we want. > > > Hmm, so why does >

Re: RFC: Reduce number of packages that are built for i686

On 11/18/21 10:15 AM, Neal Gompa wrote: > On Thu, Nov 18, 2021 at 12:27 PM Josh Stone wrote: >> >> On 11/17/21 2:27 PM, Kevin Fenzi wrote: >>> And not 'in fedora', but people always bring up steam when these >>> disccussions happen. I wonder why they are sticki

Re: RFC: Reduce number of packages that are built for i686

On 11/17/21 2:27 PM, Kevin Fenzi wrote: > And not 'in fedora', but people always bring up steam when these > disccussions happen. I wonder why they are sticking with 32bit? Is that just for the steam client, or also for its many legacy games? ISTR it provides its own platform libraries for games,

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

On 11/16/21 7:05 PM, Kevin Kofler via devel wrote: > Realistically, they will just stick to Fedora 36 forever and just stop > updating the devices (or try updating them anyway and get no updates from > the server, obviously). > > Sticking an EOL label on a software release is not going to

Re: RISC-V -- are we ready for more, and what do we need to do it?

On 10/4/21 12:12 PM, Neal Gompa wrote: > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi wrote: >> * How good is emulation support > > The lack of real hardware for RISC-V has made it so almost everyone is > working with emulation. It's not realistic right now to work with real > hardware. > >> *

Re: Mangling shebangs in text files: How to detect them, bug in the current implementation and possible solutions

On 9/23/21 2:11 AM, Miro Hrončok wrote: > On 23. 09. 21 1:40, Josh Stone wrote: >> On 9/22/21 4:21 AM, Miro Hrončok wrote: >>> Hello, >>> >>> for many releases, Fedora has the brp-mangle-sehbangs BuildRoot Policy >>> Script >>> that does

Re: Mangling shebangs in text files: How to detect them, bug in the current implementation and possible solutions

On 9/22/21 4:21 AM, Miro Hrončok wrote: > Hello, > > for many releases, Fedora has the brp-mangle-sehbangs BuildRoot Policy Script > that does the following: > > 1) Gets all executable files in the buildroot > 2) Gets all "text" files from those > 3a) Mangles shebangs that are "wrong" >

Re: f34 - llvm12 update

On 5/14/21 5:55 AM, Fabio Valentini wrote: > Would it be possible to rebuild and include rust as well? It is > already built against LLVM 12 in rawhide, and building it against LLVM > 12 instead of the LLVM 11 compat package fixes a few code generation > issues and crashes that have been hitting

Re: Gnome Fractal and veloren/airshipper needs maintainer

On 5/2/21 10:25 AM, Tomasz Torcz wrote: > Dnia Sun, May 02, 2021 at 02:15:21PM -, Artem Tim napisał(a): >> Veloren and Veloren Airshipper bot using rust-nightly. you can forget about >> packaging it for official repos in Fedora. >> >> Fractal - good luck to package it Fedora. >> >> But both

Re: Help wanted: Multiple packages with different ver-rel from one spec

On 2/4/21 11:19 AM, Fabio Valentini wrote: > I am aware of at least three (?) other "noteworthy" packages that have > to deal with this (or at least, had to do something like this in the > past): > > - ruby (with the gems that are bundled with the interpreter), > - perl (with the modules that are

Re: Proposal to deprecated `fedpkg local`

On 1/27/21 2:04 PM, Otto Urpelainen wrote: > The other option of not using 'git add .' can also be described as > mentally filtering out all the irrelevant unstaged changes to find the > ones that should actually be added. That adds cognitive burden, slows > things down and leads to mistakes

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

On 1/16/21 3:21 PM, Nico Kadel-Garcia wrote: > On Sat, Jan 16, 2021 at 4:54 PM Kevin Kofler via devel > wrote: >> >> Miro Hrončok wrote: >>> See also: >>> https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master >> >> This is a blatant violation of

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 1:14 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Sep 14, 2020 at 12:53:57PM -0700, Josh Stone wrote: >> On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: >>>> On Mon, Sep

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 12:18 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Sep 14, 2020 at 09:15:27PM +0200, Fabio Valentini wrote: >> On Mon, Sep 14, 2020 at 9:02 PM Josh Stone wrote: >>> >>> On 9/14/20 11:40 AM, Fabio Valentini wrote: >>>> I agree. The only thing

Re: F34 Change Proposal: Rust Crate Packages For Release Branches (System-Wide Change)

On 9/14/20 11:40 AM, Fabio Valentini wrote: > On Mon, Sep 14, 2020 at 8:38 PM Neal Gompa wrote: >> >> On Mon, Sep 14, 2020 at 2:34 PM Zbigniew Jędrzejewski-Szmek >> wrote: >>> >>> On Mon, Sep 14, 2020 at 10:10:30AM -0400, Ben Cotton wrote:

License change for rust-crossbeam-channel

rust-crossbeam-channel-0.4.3-1.fc33 has changed its license from a combined "(MIT or ASL 2.0) and BSD" to just "MIT or ASL 2.0". See also: https://github.com/crossbeam-rs/crossbeam/issues/536 ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

On 7/21/20 3:12 PM, Mark Wielaard wrote: >>> Is there a procedure to follow for dropping these sub-packages, or can >>> I simply remove them from the spec file? >> >> Maybe add Obsoletes to the devel subpackages, but not Provides. >> >>

Re: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

On 7/21/20 2:24 PM, Mark Wielaard wrote: > Nothing seems to require these packages, but that might be simply be > because they are static libraries, so there aren't any runtime > requirements. Is there some way to determine if anything would start > failing to build if I simply remove them? Apart

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

On 6/5/20 5:27 AM, Neal Gompa wrote: >> Note that having stuff mix compilers is also a bad idea because LTO is >> compatible across the two compilers. If you want to use LTO, you need >> to use the same compiler across the chain, or stuff will break. >> > Yay thinkos... I mean that LTO is *not*

Re: Fwd: Re: late generation of assemble code

On 5/29/20 4:02 AM, Paul Dufresne via devel wrote: > * more space on the hard disks of the servers, because they contains > repositories only for LLVM IR packages rather than one by supported > architectures LLVM IR is not really arch-independent -- by the time you get to this level, all of the

Re: buildroot problems on rawhide i386, armv7hl ??

On 4/15/20 11:19 AM, Miro Hrončok wrote: > I can help you setup a test that builds the packages with rpmbuild or in > local > mock. However, the CI pipeline only runs on x86_64. Can that x86_64 host still use an i686 mock? ___ devel mailing list --

Re: Cross-arch dependencies for plugins (NSS and others)

On 2/24/20 10:11 AM, Florian Weimer wrote: > If we add this to nss_nis.spec: > > %ifarch x86_64 > Recommends: (nss_nis(x86-32) if glibc(x86-32)) > %endif > > then when the user installs nss_nis after glibc.i686, they will get both > packages, as expected. > > Unfortunately, it does not work if

Re: deduplicating noarch subpackages

On 2/13/20 11:26 AM, Nicolas Mailhot wrote: > Le jeudi 13 février 2020 à 09:59 -0800, Josh Stone a écrit : >> >> It's not so black and white. In theory, the only thing that should >> matter is the target triple, but the metadata also hashes the >> metadata >&

Re: deduplicating noarch subpackages

On 2/12/20 8:29 AM, Adam Jackson wrote: > On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote: > >> Another alternative is to try to remove the host information from the >> metadata hash, which I've already started upstream[3], but I'm not sure >> alleviate thei

Re: deduplicating noarch subpackages

On 2/12/20 12:45 AM, Nicolas Mailhot wrote: > Le 2020-02-12 01:21, Josh Stone a écrit : > >> The problem is that those cross-target libraries built by two different >> host arches will have different metadata hashes in the filenames, >> because the hash includes the

Re: deduplicating noarch subpackages

On 2/13/20 7:26 AM, Kevin Kofler wrote: > Neal Gompa wrote: >> My instinct is that this wouldn't work, but I'm not certain. Have you >> tried this change with a scratch build? Scratch builds run the same >> checks that normal builds do, and would be a good way to verify if >> your theory is true.

deduplicating noarch subpackages

When building a normal arch package with noarch subpackages, would it be acceptable in Fedora if only *one* of the arches actually took responsibility to build those noarch subpackages? Context: the "rust" package normally builds arch-specific packages, like "rust" for rustc, rustdoc, and their

License change for rust-tokio-process

rust-tokio-process-0.2.5-1.fc32 changed from MIT/Apache-2.0 to just MIT. This occurred upstream when it merged into the tokio project: https://github.com/tokio-rs/tokio/pull/1320 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

License change for rust-x11

rust-x11-2.18.2-1.fc32 hash changed its license from CC0-1.0 to MIT. See also: https://github.com/erlepereira/x11-rs/issues/82 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories

On 9/9/19 3:35 PM, vvs vvs wrote: > So, you are insisting that Koji just doesn't work without any assistance? And > that it's impossible to build a separate i686 repository without affecting > all others? We used to build secondary architectures separately, using koji-shadow to chase the

Re: Rust applications & i686

On 7/28/19 8:55 AM, Stephen John Smoogen wrote: > On Sun, 28 Jul 2019 at 11:47, Miro Hrončok wrote: > > > What if I want to BR some of the tools from a regular Fedora build > > in the future? Would I need to exclude i686 as well? > > Would you be able to do so now since Rust is in a module and

Re: RPM strip scripts and executables as shared objects

On 3/29/19 9:17 AM, Robert Marcano wrote: > I have been working on a private RPM for a Rust based program Side note on this -- if you do package Rust shared libraries, not just executables, and you want them to be available for further linking, then rustc needs to have the metadata in the .rustc

License change for rust-lru_time_cache

Upstream changed [1] from GPLv3 to dual licenses, MIT or BSD, which is now released and in rawhide: rust-lru_time_cache-0.8.1-1.fc30 [1]: https://github.com/maidsafe/lru_time_cache/pull/103 ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Upstream tip wanted: CI service for Big Endian acrhes

On 11/12/18 6:57 AM, Dan Horák wrote: > On Mon, 12 Nov 2018 13:32:57 +0100 > Miro Hrončok wrote: > >> Recently I've reported some Big Endian related test failures to an >> upstream project [0]. >> >> I was asked by an upstream project maintainer, whether I know some >> free Continuous

Re: Cannot find -latomic when building for epel7 aarch64

On 10/19/18 6:19 PM, Robert-André Mauchin wrote: > On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote: >> I'm trying to build duperemove[1] for epel7[2], and it's building on >> all the arches except aarch64. >> >> I'm BR'ing libatomic, but the error it gives in build.log[3] for >>

License change for rust-ryu

rust-ryu-0.2.6-1.fc30 has broadened its license from just "ASL 2.0" to "ASL 2.0 or Boost". The upstream change [1] follows the change in the C original [2]. [1] https://github.com/dtolnay/ryu/commit/a8d82216155b547c95d05b7689a6f70d535f2df3 [2]

License change for rust-slab

rust-slab-0.4.1-1.fc29 has changed its license from "MIT or ASL 2.0" to just MIT. The upstream change is here: https://github.com/carllerche/slab/pull/49 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: [HEADS UP] Removal of GCC from the buildroot

On 07/11/2018 10:01 AM, Jan Kratochvil wrote: > On Wed, 11 Jul 2018 18:26:23 +0200, Josh Stone wrote: >> So I hear you like compile-time safety... >> >> No, I don't seriously want to get into a language comparison here, >> except to say that it's reasonable for the

Re: [HEADS UP] Removal of GCC from the buildroot

On 07/11/2018 07:37 AM, Kevin Kofler wrote: > Igor Gnatenko wrote: >> A lot of packages in 2018 are not written in C/C++ > > … and this is the problem that needs fixing. > > It is just a PITA to have packages dragging in more and more interpreters > and/or language runtimes. The slowness and

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On 06/18/2018 07:05 PM, Kevin Kofler wrote: > Jeff Backus wrote: >> Hmm.. Yes, we've had discussions within the SIG re: window managers that >> support i586/i686, and KDE was on the list of WMs that no longer support >> our target system. Do these patches/hacks only apply to KDE or do they >>

License change for rust-adler32

Upstream has updated from just BSD to BSD and zlib, reflecting the origins of the code ported to Rust. More info here: https://github.com/remram44/adler32-rs/issues/7 Built in rust-adler32-1.0.3-1.fc29 ___ devel mailing list --

license change in rust-tokio-{executor,reactor,threadpool}

These three rust crates have changed from a combo "MIT or ASL 2.0" license to just MIT. rust-tokio-executor-0.1.1-1.fc29 rust-tokio-reactor-0.1.1-1.fc29 rust-tokio-threadpool-0.1.1-1.fc29 The same change will be coming to rust-tokio-0.1.4 in this update:

Re: On Ye Olde Foreste of Anciente LLVM Versiones

On 03/08/2018 03:25 PM, Yaakov Selkowitz wrote: > On 2018-03-08 17:05, Adam Williamson wrote: >> On Thu, 2018-03-08 at 14:54 -0800, Adam Williamson wrote: >>> While rebuilding stuff for "GCC 8 ABI change on x86_64", I noticed we >>> have a rather magnificent collection of ancient llvm versions:

rust-structopt and rust-structopt-derive license change

rust-structopt-0.2.5-1.fc29 and rust-structopt-derive-0.2.5-1.fc29 come with a license change from "WTFPL" to "ASL 2.0 or MIT". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What's up with koji?

On 01/26/2018 02:38 PM, Paul Howarth wrote: > I'm trying to update mod_fcgid, which is a loadable module for httpd. > > It was failing this afternoon due to the gcc internal compiler error > affecting i686 builds mentioned elsewhere, and I fixed that locally by > rebuilding httpd (and hence apxs,

Re: Test gating enabled in Bodhi

On 01/23/2018 01:28 AM, Pierre-Yves Chibon wrote: > There are three tests that must pass in order for updates to go to stable: > > 0. dist.depcheck - to make sure the update's dependencies are available. > 1. dist.abicheck - to make sure the update's ABI remains stable in a >given Fedora

Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)

On 10/12/2017 05:34 PM, Adam Williamson wrote: > In this case there's an even worse consequence; if you do attempt to > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the > nss packages (as it notices that they are missing dependencies), but it > *will* install

Re: How to enable multilib packages in updates-testing

On 10/02/2017 08:34 PM, Tom Stellard wrote: > Hi, > > A tester on one of my updates[1] noted that the x86_64 and i686 packages had > different version numbers. When I look at the compose[2] for updates-testing, > I can see that for the package in question, compiler-rt, there are only > x86_64

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

On 08/24/2017 05:18 AM, Jan Kratochvil wrote: > But the symbols take less space there as they are compressed. You can check > how it looks like for Linux ELF binaries by: > rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section > .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz

Re: F28 Self Contained Change: Packaging Rust applications/libraries

On 08/21/2017 07:20 AM, Christian Stadelmann wrote: > I'd like to see this change land in F28! > > Anyway, I think there is a showstopper: > * Fedora Packaging guidelines demand packages bundle no dependencies (e.g. > libraries, or in Rust's case crates). This is a good choice in my opinion. > *

Re: Mass rebuild failures only on ppc64le: glibc problem?

On 07/26/2017 06:23 PM, Josh Stone wrote: > On 07/26/2017 04:21 PM, Jason L Tibbitts III wrote: >> I noticed one of my packages failed to build because the test suite >> failed, but only on ppc64le. >> >> builddir/build/BUILD/cyrus-imapd-3.0.2/cunit/.libs/lt-unit: er

Re: Mass rebuild failures only on ppc64le: glibc problem?

On 07/26/2017 04:21 PM, Jason L Tibbitts III wrote: > I noticed one of my packages failed to build because the test suite > failed, but only on ppc64le. > > builddir/build/BUILD/cyrus-imapd-3.0.2/cunit/.libs/lt-unit: error while > loading shared libraries: >

Re: Rust SIG is happy to provide tools written in Rust

On 06/16/2017 11:31 AM, K. Cong wrote: > What about rustup? I feel it's quite important for anyone working in Rust. I think rustup is great for managing rustc versions, and I do use it myself, but I don't think it's a good fit for system packaging. It wants to be interposed in your PATH with

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

On 06/12/2017 03:38 PM, t...@fedoraproject.org wrote: > lldb airlied, daveisfera, 71 weeks ago >jankratochvil, jvcelak, >siddharths, tstellar Where

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

On 03/15/2017 05:32 PM, Tomasz Kłoczko wrote: > ./r/rust.git/rust.spec:BuildRequires: llvm-static This one is conditional, generally disabled. We use it to break rust's bootstrap dependency when llvm is being rebased to a new soname. ___ devel mailing

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

On 03/15/2017 10:08 AM, Daniel P. Berrange wrote: > On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote: >> On 03/14/2017 05:05 PM, Jonathan Wakely wrote: >>> If glibc-static was removed from Fedora and that change propagated to >>> RHEL I know of companies that

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

On 03/14/2017 05:05 PM, Jonathan Wakely wrote: > If glibc-static was removed from Fedora and that change propagated to > RHEL I know of companies that might stop being customers of Red Hat. Even if Fedora removed it, we could still make the business decision to add it back to RHEL. > Being

LLVM compatibility hazard on F24/F25

re https://bugzilla.redhat.com/show_bug.cgi?id=1422930 This is an indirect consequence of the LLVM update for bug 1376213. In the initial llvm-3.8.1-1 update, ajax enabled the Mips target, but this was never pushed out due to unrelated build issues. Then later I found I needed an LLVM update

Re: F26 Self Contained Change: Anaconda LVM RAID

On 02/07/2017 12:27 PM, Samuel Sieb wrote: > On 01/31/2017 12:02 PM, Chris Murphy wrote: >> On Tue, Jan 31, 2017 at 7:33 AM, Chris Adams wrote: >>> How do LVM RAID volumes get tested? There's a regular cron job for >>> testing MD RAID volumes, but I'm not aware of something

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

On 02/03/2017 08:42 AM, Nathanael D. Noblet wrote: > Also what are the risks of enabling this? It makes it possible for an attacker to distinguish used and unused space on the disk, as they can see zeros instead of encrypted noise. Whether that's a problem depends on your level of paranoia.

Re: failure of f24 to f25 upgrade

On 12/01/2016 12:40 PM, Howard Howell wrote: > -Original Message- > From: Josh Stone <jist...@redhat.com> > To: hlhow...@pacbell.net, Development discussions related to Fedora v...@lists.fedoraproject.org>, Adam Williamson <adamwill@fedoraproject.o > rg> &g

Re: failure of f24 to f25 upgrade

On 12/01/2016 12:26 PM, Howard Howell wrote: > Now it gets really weird... > # rpm -q --provides google-earth > package google-earth is not installed Should be google-earth-stable, no? ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: failure of f24 to f25 upgrade

On 12/01/2016 12:22 PM, Adam Williamson wrote: > On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote: >> -Original Message- >> From: Adam Williamson >> To: hlhow...@pacbell.net, Development discussions related to Fedora > v...@lists.fedoraproject.org> >>

Re: fedpkg local --noclean?

On 10/20/2016 09:50 AM, Christopher wrote: > On Thu, Oct 20, 2016 at 4:46 AM Jan Synacek > wrote: > > On Thu, Oct 20, 2016 at 4:33 AM, Christopher > > wrote: > > Is it

Re: comiing to koji aarch64

On 09/10/2016 07:19 AM, Dennis Gilmore wrote: > Hi All, > > We are in the process of importing aarch64 to the primary koji instance as > part of https://fedoraproject.org/wiki/Architectures/ > RedefiningSecondaryArchitectures The import and enablement of aarch64 is for > rawhide only, we

Re: F25 Self Contained Change: Rust Compiler

On 07/14/2016 05:15 PM, Simo Sorce wrote: > Until the Rust ecosystem becomes more stable, it is better to upgrade > it regularly than have a stale tool nobody can really use. > There are even crates that work only with nightlies for now, so trying > to stay on par is necessary to make it useful.

Re: F25 Self Contained Change: Rust Compiler

On 07/13/2016 07:50 AM, Adam Jackson wrote: > On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote: >> Rust uses LLVM for codegen, so in theory, yes. This excludes any >> potential platform-specific bugs that may affect rustc, which are >> certainly a possibility. > > At the moment llvm has

Re: F25 Self Contained Change: Rust Compiler

On 07/13/2016 09:10 AM, Stefan Nuxoll wrote: > ABI stability is entirely dependent on compiler version, AFAIK. > Within the same version of rustc there should be no issues with > dynamic linking, I suspect that may true in general, but I don't think it's promised, and I don't really trust it. We

Re: F25 Self Contained Change: Rust Compiler

On 07/12/2016 09:18 PM, Jan Kurik wrote: > Rust 1.10.0 was released on July 7 along with Cargo 0.11.0. These will > be the initial targets to package. Rust's next release is scheduled > for August 18 on a 6-week cycle. Backwards compatibility is taken very > seriously, so it should be possible to

Re: F25 Self Contained Change: Rust Compiler

On 07/13/2016 02:24 AM, Dridi Boukelmoune wrote: > Since 1.10 (the target of this change) it has become possible to > create "cdylib" (C dynamic library) crates, basically shared objects > that can be linked to by non-Rust programs. > > It isn't supported by cargo yet, but it's available.. Yes,

Re: F25 Self Contained Change: Rust Compiler

On 07/13/2016 12:29 AM, Stefan Nuxoll wrote: > Rust supports dynamic linking, would it be worth investigating that > route instead of copying the proposed Go guidelines? I'm not against > static linking at all costs, but it would make package maintenance > (especially security updates) a lot more

Re: F25 Self Contained Change: Rust Compiler

On 07/12/2016 11:45 PM, Dan Horák wrote: > How does the new language (and compiler) affect secondary architectures? > Will it just work? Rust has their own tier system of architecture support: https://doc.rust-lang.org/book/getting-started.html#platform-support Only i686 and x86_64 are Tier 1

Re: Heads up: glibmm/gtkmm now requires -std=c++11

On 09/22/2015 05:49 PM, Mamoru TASAKA wrote: > Kalev Lember wrote on 09/23/2015 09:35 AM: >> Hi, >> >> A quick heads up to anybody who might run into cryptic build errors when >> building apps that use glibmm/gtkmm: >> >> Latest glibmm/gtkmm stack in rawhide and F23 now uses C++11 features in >>

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

On 09/11/2015 10:35 AM, Stephen Gallagher wrote: > Actually, the opposite is true. RHEL has fewer limitations in this > space. Red Hat's layered projects ship a fair amount of bundled stuff. > This problem is entirely Fedora's. Fedora has far stricter rules than > RHEL in this regard. It helps

Re: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

On 09/04/2015 07:11 AM, Jakub Jelinek wrote: > On Fri, Sep 04, 2015 at 03:58:12PM +0200, Florian Weimer wrote: >> On 09/04/2015 03:49 PM, Jakub Jelinek wrote: >> >>> Clearly it is used by some programs, so it should be considered part of the >>> public API. If it wasn't meant to be exported, it

Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 this morning, and now I get this stderr output: $ /usr/bin/stap -V /dev/null /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking The message comes from ld.so; that symbol

Re: Rawhide plans

On 08/19/2015 08:18 AM, Kevin Fenzi wrote: * Setup some gating. I think it should work like this: today you build a rawhide build and it tags into f24 tag, which is used by the daily compose. I'd like to change that to build into a f24-candidate tag. At that point taskotron or other

Re: Same comand names in /usr/bin and /usr/sbin

On 08/14/2015 10:24 AM, Lennart Poettering wrote: On Mon, 10.08.15 11:50, Josh Stone (jist...@redhat.com) wrote: On 08/10/2015 11:12 AM, Orion Poplawski wrote: iproute has /usr/sbin/ss stripesnoop has /usr/bin/ss This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328

Re: Is it time to allow Chromium in Fedora?

On 08/11/2015 02:04 PM, Reindl Harald wrote: Am 11.08.2015 um 23:00 schrieb Mustafa Muhammad: On Aug 11, 2015 11:29 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad: If I knew Mozilla's Linux

Re: Is it time to allow Chromium in Fedora?

On 08/11/2015 12:12 PM, Chris Murphy wrote: Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder why that binary doesn't just run unmodified anywhere and I'm waiting for 40.0 to show up in Bodhi? If you don't see the value of distro integration and testing, then by all

Re: Is it time to allow Chromium in Fedora?

On 08/11/2015 12:38 PM, Chris Murphy wrote: On Tue, Aug 11, 2015 at 1:18 PM, Josh Stone jist...@redhat.com wrote: On 08/11/2015 12:12 PM, Chris Murphy wrote: Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder why that binary doesn't just run unmodified anywhere and I'm

  1   2   >