Re: goffice-0.10.46 no longer builds on i686
THanks! The side tags are:
f40-build-side-77026
f40-build-side-77028
f38-build-side-77032
f37-build-side-77034
Best regards,
Julian
Am 04.11.23 um 18:10 schrieb Gwyn Ciesla via devel:
I can take care of Abiword. Let me know when to do so.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent from Proton Mail mobile
Original Message
On Nov 4, 2023, 12:01 PM, Richard W.M. Jones < rjo...@redhat.com> wrote:
On Sat, Nov 04, 2023 at 03:38:55PM +0100, Julian Sikorski wrote: >
Hello, > > I tried to update goffice to 0.10.46 and gnumeric to
1.12.46 today. > After pushing the changes, it turned out that it no
longer builds on > i686 [1][2]. Given that the use on i686 should be
minimal, None at all, since we don't ship an i686 kernel. (Well, I
suppose someone might be mad enough to try running gnumeric in an
i686 container or chroot on top of an x86-64 kernel, but why'd you
want to do that ...) > I would > be inclined to just ExcludeArch:
%{ix86} and move on. Definitely! > According to > leafdrop,
gnumeric, abiword and gchemutils are the only downstream > consumers
of goffice. I can take care of gnumeric and gchemutils, > but I do
not have access to abiword so I would need help with that. > The
alternative would be to revert to 0.10.45. What would be your >
preference? > > Best regards, > Julian > > [1]
https://gitlab.gnome.org/GNOME/goffice/-/issues/70 > [2]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846 Rich. -- Richard
Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones Read my programming and
virtualization blog: http://rwmj.wordpress.com virt-p2v converts
physical machines to virtual machines. Boot with a live CD or over
the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___ devel mailing list
-- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: goffice-0.10.46 no longer builds on i686
Correction, I had a mishap when cleaning up tags. The correct ones are:
f40-build-side-77026
f39-build-side-77030
f38-build-side-77032
f37-build-side-77036
Best regards,
Julian
Am 05.11.23 um 10:36 schrieb Julian Sikorski:
THanks! The side tags are:
f40-build-side-77026
f40-build-side-77028
f38-build-side-77032
f37-build-side-77034
Best regards,
Julian
Am 04.11.23 um 18:10 schrieb Gwyn Ciesla via devel:
I can take care of Abiword. Let me know when to do so.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent from Proton Mail mobile
Original Message
On Nov 4, 2023, 12:01 PM, Richard W.M. Jones < rjo...@redhat.com> wrote:
On Sat, Nov 04, 2023 at 03:38:55PM +0100, Julian Sikorski wrote: >
Hello, > > I tried to update goffice to 0.10.46 and gnumeric to
1.12.46 today. > After pushing the changes, it turned out that it no
longer builds on > i686 [1][2]. Given that the use on i686 should be
minimal, None at all, since we don't ship an i686 kernel. (Well, I
suppose someone might be mad enough to try running gnumeric in an
i686 container or chroot on top of an x86-64 kernel, but why'd you
want to do that ...) > I would > be inclined to just ExcludeArch:
%{ix86} and move on. Definitely! > According to > leafdrop,
gnumeric, abiword and gchemutils are the only downstream > consumers
of goffice. I can take care of gnumeric and gchemutils, > but I do
not have access to abiword so I would need help with that. > The
alternative would be to revert to 0.10.45. What would be your >
preference? > > Best regards, > Julian > > [1]
https://gitlab.gnome.org/GNOME/goffice/-/issues/70 > [2]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846 Rich. -- Richard
Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones Read my programming and
virtualization blog: http://rwmj.wordpress.com virt-p2v converts
physical machines to virtual machines. Boot with a live CD or over
the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___ devel mailing list
-- devel@lists.fedoraproject.org To unsubscribe send an email to
devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: goffice-0.10.46 no longer builds on i686
Am 04.11.23 um 18:01 schrieb Richard W.M. Jones:
On Sat, Nov 04, 2023 at 03:38:55PM +0100, Julian Sikorski wrote:
Hello,
I tried to update goffice to 0.10.46 and gnumeric to 1.12.46 today.
After pushing the changes, it turned out that it no longer builds on
i686 [1][2]. Given that the use on i686 should be minimal,
None at all, since we don't ship an i686 kernel. (Well, I suppose
someone might be mad enough to try running gnumeric in an i686
container or chroot on top of an x86-64 kernel, but why'd you want to
do that ...)
I would
be inclined to just ExcludeArch: %{ix86} and move on.
Definitely!
Thanks for the feedback, I have pushed the corresponding changes.
Best regards,
Julian
According to
leafdrop, gnumeric, abiword and gchemutils are the only downstream
consumers of goffice. I can take care of gnumeric and gchemutils,
but I do not have access to abiword so I would need help with that.
The alternative would be to revert to 0.10.45. What would be your
preference?
Best regards,
Julian
[1] https://gitlab.gnome.org/GNOME/goffice/-/issues/70
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846
Rich.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5: Checking signatures of packages installed out of a repository?
On Thu, Nov 02, 2023 at 09:58:10AM -0400, Christopher wrote: > On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote: > > > On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote: > > > > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote: > > > > > > > > > > FWIW, from what I can recall, yum used to check all packages, but this > > > > > resulted in tons of people complaining because they did not want it to > > > > > check their local packages. So, a localpkg_gpgcheck option was added > > > > > and > > > > > set to false. dnf4 still has this option. > > > > > > > > I wasn't aware of that change in behavior. I can't find that option > > > > documented in the man page for dnf or any other readily available docs > > > > about dnf in my installation, or present in my dnf.conf file. I don't > > > > > > Odd. It's in the dnf.conf man page here in rawhide: > > > > > > "localpkg_gpgcheck > > > boolean > > > > > > Whether to perform a GPG signature check on local > > > packages (packages in a > > > file, not in a repository). The default is False. This > > > option is subject to > > > the active RPM security policy (see gpgcheck for more > > > details). > > > " > > > > > > Looks like it was added to yum 13 years ago: > > > https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115 > > > > This is pretty badly documented. I'm pretty sure that most people will > > not guess that any URL qualifies as "in a file". > > > > The approach to security nowadays is much stricter than 13 years ago… > > I think we should revisit this decision. > > > > > > remember anybody ever complaining, certainly not "tons of people". > > > > > > This was 13-14 years ago. > > > > > > > Using local RPMs is a pretty rare thing. I can't imagine too many > > > > people complaining about this. It was never much of a burden, and to > > > > the extent that it was, it was a burden that was a worthwhile tradeoff > > > > for increased security. > > > > > > I'm just relaying the history here... > > > > > > > It's also not clear when this option would take effect. Would it take > > > > effect if I did `dnf install /path/to/local/file` or just when I did > > > > > > no, because that looks up that file in your repos and downloads the repo > > > version of the package. > > > > > > > `dnf localinstall /path/to/local/file`? What if I did `dnf > > > > My vote would be: > > 'dnf install /path/to/file' default to warn-but-allow (*) > > I don't think any "warn-but-allow" option is sufficient. The warning > comes too late if the transaction is allowed to proceed. By the time > the user can react, the installation scripts could have already > corrupted the system due to installing a malicious or corrupted > package, and possibly in a way that prevents them from reacting at all > to the warning. > > > 'dnf install https://some.url/' default to an enforcing check > > > > For files outside of a repo, the current set of keys registered > > with rpm should be used. A valid-signature-with-unknown-key must be > > rejected when the check is enforcing. > > > > If such fine-grained policy is not possible, then I think > > defaulting to requiring explicit --nogpgcheck would be better > > than status quo. > > > > (*) I think that 99% of the time when you're doing a local install > > like that, the package was built by the user and it's convenient > > to skip the check. > > I don't know how common it is for people to create their own RPMs, but > that's necessarily going to be some subset of all Fedora users. I > suspect there are many more users who install RPMs downloaded directly > from others where these checks matter more (GPU drivers, Steam > repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made > from Amazon's DEB using alien, Google Chrome initial installation RPM > that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who > never build their own RPMs. > > However, even for those who build their own RPMs, skipping this check > is only going to be convenient for those who don't sign their own > RPMs... which is a good practice and very easy to do. After all, these > signatures don't just protect by authenticating the source of the > package, but they also verify the package integrity to protect against > file corruption. > > Whatever inconvenience there is for users who build their own RPMs to > add an explicit --nogpgcheck to a command-line, I think that's > negligible compared to the benefit to everybody to verify by default. > Perhaps the minor inconvenience will encourage those holdouts to adopt > a better security posture and start signing the RPMs they build > themselves? I'm convinced by those arguments. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to de
Re: goffice-0.10.46 no longer builds on i686
On Sat, Nov 04, 2023 at 05:01:15PM +, Richard W.M. Jones wrote:
> On Sat, Nov 04, 2023 at 03:38:55PM +0100, Julian Sikorski wrote:
> > Hello,
> >
> > I tried to update goffice to 0.10.46 and gnumeric to 1.12.46 today.
> > After pushing the changes, it turned out that it no longer builds on
> > i686 [1][2]. Given that the use on i686 should be minimal,
>
> None at all, since we don't ship an i686 kernel. (Well, I suppose
> someone might be mad enough to try running gnumeric in an i686
> container or chroot on top of an x86-64 kernel, but why'd you want to
> do that ...)
A completely unnecessary nerdy over-the-top correction:
you don't need a container. Dnf will install a 32-bit variant of
packages when instructed to do so:
$ sudo dnf5 remove goffice.x86_64
$ sudo dnf5 install gnumeric.i686
$ file -L /usr/bin/gnumeric
/usr/bin/gnumeric: ELF 32-bit LSB pie executable, Intel 80386, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=193d0eb6fe9bd71cec29b46a7bdd372687a36d37, for GNU/Linux 3.2.0,
stripped
$ gnumeric
...
I imagine that somebody with a machine with little RAM might use a
32-bit program because it uses less memory… But I think it's not worth
the effort required to keep the 32-bit version alive (including all
dependencies).
> > I would
> > be inclined to just ExcludeArch: %{ix86} and move on.
Yeah.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20231105.n.0 changes
OLD: Fedora-Rawhide-20231104.n.0 NEW: Fedora-Rawhide-20231105.n.0 = SUMMARY = Added images:8 Dropped images: 0 Added packages: 2 Dropped packages:1 Upgraded packages: 41 Downgraded packages: 1 Size of added packages: 210.15 KiB Size of dropped packages:377.91 KiB Size of upgraded packages: 1.51 GiB Size of downgraded packages: 6.34 MiB Size change of upgraded packages: 3.58 MiB Size change of downgraded packages: -16.84 KiB = ADDED IMAGES = Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20231105.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20231105.n.0.iso Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20231105.n.0.aarch64.raw.xz Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231105.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231105.n.0.iso Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20231105.n.0.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20231105.n.0.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231105.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: mucalc-2.1-1.fc40 Summary: Convenient command line calculator RPMs:mucalc Size:157.84 KiB Package: rust-powerfmt-0.2.0-1.fc40 Summary: Utilities for formatting values RPMs:rust-powerfmt+alloc-devel rust-powerfmt+default-devel rust-powerfmt+macros-devel rust-powerfmt+std-devel rust-powerfmt-devel Size:52.31 KiB = DROPPED PACKAGES = Package: golang-github-cli-crypto-0-0.3.20230331git6be313f.fc39 Summary: GitHub's golang-crypto fork required for gh RPMs:golang-github-cli-crypto-devel Size:377.91 KiB = UPGRADED PACKAGES = Package: afflib-3.7.20-1.fc40 Old package: afflib-3.7.19-11.fc39 Summary: Library to support the Advanced Forensic Format RPMs: afflib afflib-devel afftools python3-pyaff Size: 2.10 MiB Size change: 34.16 KiB Changelog: * Sat Nov 04 2023 Michal Ambroz - 3.7.20-1 - bump to version 3.7.20 Package: ampache_browser-1.0.6-1.fc40 Old package: ampache_browser-1.0.4-3.fc39 Summary: C++ and Qt based client library for Ampache access RPMs: ampache_browser ampache_browser-devel Size: 977.67 KiB Size change: 3.91 KiB Changelog: * Sat Nov 04 2023 Michael Schwendt - 1.0.6-1 - Update to 1.0.6 for Qt 6 support but build with USE_QT6=OFF. Package: ascii-3.18-18.fc40 Old package: ascii-3.18-17.fc39 Summary: Interactive ascii name and synonym chart RPMs: ascii Size: 102.07 KiB Size change: 45 B Changelog: * Sat Nov 04 2023 Didier Fabert - 3.18-18 - migrated to SPDX license Package: audacious-plugins-4.3.1-3.fc40 Old package: audacious-plugins-4.3.1-2.fc39 Summary: Plugins for the Audacious audio player RPMs: audacious-plugins audacious-plugins-amidi audacious-plugins-exotic audacious-plugins-ffaudio audacious-plugins-jack Size: 8.03 MiB Size change: 12.82 KiB Changelog: * Mon Aug 28 2023 Yaakov Selkowitz - 4.3.1-3 - Enable mms transport plugin. Package: audit-3.1.2-5.fc40 Old package: audit-3.1.2-4.fc40 Summary: User space tools for kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel python3-audit Size: 2.83 MiB Size change: -7.87 KiB Changelog: * Sat Nov 04 2023 Steve Grubb 3.1.2-5 - Bug fixes pulled from upstrean Package: avogadro2-1.98.1-2.fc40 Old package: avogadro2-1.98.0-1.fc40 Summary: Advanced molecular editor RPMs: avogadro2 avogadro2-langpack-af avogadro2-langpack-ar avogadro2-langpack-bg avogadro2-langpack-bs avogadro2-langpack-ca avogadro2-langpack-ca_VA avogadro2-langpack-cs avogadro2-langpack-da avogadro2-langpack-de avogadro2-langpack-el avogadro2-langpack-en_AU avogadro2-langpack-en_CA avogadro2-langpack-en_GB avogadro2-langpack-eo avogadro2-langpack-es avogadro2-langpack-et avogadro2-langpack-eu avogadro2-langpack-fa avogadro2-langpack-fi avogadro2-langpack-fr avogadro2-langpack-fr_CA avogadro2-langpack-gl avogadro2-langpack-he avogadro2-langpack-hi avogadro2-langpack-hr avogadro2-langpack-hu avogadro2-langpack-id avogadro2-langpack-it avogadro2-langpack-ja avogadro2-langpack-kn avogadro2-langpack-ko avogadro2-langpack-ms avogadro2-langpack-nb avogadro2-langpack-nl avogadro2-langpack-oc avogadro2-langpack-pl avogadro2-langpack-pt avogadro2-langpack-pt_BR avogadro2-langpack-ro avogadro2-langpack-ru avogadro2-langpack-sa avogadro2-langpack-sk avogadro2-langpack-sl avogadro2-langpack-sq avogadro2-langpack-sr avogadro2-langpack-sv avogadro2-langpack-ta avogadro2-langpack-te avog
Heads up: Update SFML from 2.5.1 to 2.6.1 with soname bump coming to rawhide
Hi, SFML will be build in sidetag f40-build-side-77060 . These packages will be rebuild : CSFML attract-mode dolphin-emu extremetuxracer gravity-beams-and-evaporating-stars marsshooter ostrichriders visualboyadvance-m Best regards -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5: Checking signatures of packages installed out of a repository?
On 11/2/23 06:36, Christopher wrote: On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote: On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote: It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did no, because that looks up that file in your repos and downloads the repo version of the package. That's not what I've seen. I've used this to explicitly install the Google Chrome RPM before from a local path... before the Chrome repo was set up, and it did not re-download the RPM from any repo. `dnf install ./google-chrome-stable.rpm`. I remember this because it was surprising to me that I didn't need to specify 'localinstall', that regular 'install' just worked. Ever since, I've assumed that 'localinstall' was just an alias for 'install' and didn't behave any differently. Perhaps that assumption is wrong, but that appeared to be the behavior I observed at the time. This was ambiguous and I think you were both considering different meanings. You can dnf install a local rpm file, but you can also give dnf a path to an actual file (e.g. /usr/bin/bash) that can be installed and dnf will find and install the package that contains it. # dnf install /usr/bin/bash Package bash-5.2.15-3.fc38.x86_64 is already installed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up: Update SFML from 2.5.1 to 2.6.1 with soname bump coming to rawhide (finished)
On Sun, 2023-11-05 at 19:00 +, Sérgio Basto wrote: > Hi, > > SFML will be build in sidetag f40-build-side-77060 . > > These packages will be rebuild : > CSFML > attract-mode > dolphin-emu > extremetuxracer > gravity-beams-and-evaporating-stars > marsshooter > ostrichriders > visualboyadvance-m > All packages rebuilt successfully https://bodhi.fedoraproject.org/updates/FEDORA-2023-1acd529e5c > Best regards > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Swift on aarch64 and 39 and Rawhide...suggestions?
Hey all- I’m still having a difficult time trying to figure out what to do about this issue I’m having. Swift 5.9 was released awhile ago and I’ve been able to build it for x864_64 on all versions of Fedora (Rawhide, 39, 38, 37) just fine. On aarch64 (the only other architecture supported), it fails to build for 39 and Rawhide, where the Swift compiler crashes with an LLVM stacktrace while in the process of building the rest of the toolchain (in other words, it’s not that Swift builds and packages correctly and then doesn’t work when installed, it crashes during one of the compilation phases it uses to build the entire toolchain). I’ve been trying to troubleshoot this problem and have it seems that the issue may lay with ld-linux-aarch.so.1: [root@6ba0f8c47e54 swift-source]# lldb ./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend (lldb) target create "./build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend" Current executable set to '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend' (aarch64). (lldb) ru Process 142 launched: '/root/rpmbuild/BUILD/swift-source/build/buildbot_linux/swift-linux-aarch64/bin/swift-frontend' (aarch64) Process 142 stopped * thread #1, name = 'swift-frontend', stop reason = exec frame #0: 0xf7fd84c0 ld-linux-aarch64.so.1`_start at dl-start.S:22 That’s as far as I’ve gotten. I not sure what the next move should be; troubleshooting core libraries is not something I’ve done before and have no idea where to start. Any help or suggestions would be greatly appreciated. I’ve been extremely busy on non-packaging things and honestly don’t really have the time to dig into this. Thanks! Ron___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5: Checking signatures of packages installed out of a repository?
On Sun, Nov 5, 2023 at 3:54 PM Samuel Sieb wrote: > > On 11/2/23 06:36, Christopher wrote: > > On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote: > >> > >> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote: > >>> It's also not clear when this option would take effect. Would it take > >>> effect if I did `dnf install /path/to/local/file` or just when I did > >> > >> no, because that looks up that file in your repos and downloads the repo > >> version of the package. > > > > That's not what I've seen. I've used this to explicitly install the > > Google Chrome RPM before from a local path... before the Chrome repo > > was set up, and it did not re-download the RPM from any repo. `dnf > > install ./google-chrome-stable.rpm`. I remember this because it was > > surprising to me that I didn't need to specify 'localinstall', that > > regular 'install' just worked. Ever since, I've assumed that > > 'localinstall' was just an alias for 'install' and didn't behave any > > differently. Perhaps that assumption is wrong, but that appeared to be > > the behavior I observed at the time. > > This was ambiguous and I think you were both considering different meanings. > > You can dnf install a local rpm file, but you can also give dnf a path > to an actual file (e.g. /usr/bin/bash) that can be installed and dnf > will find and install the package that contains it. > > # dnf install /usr/bin/bash > Package bash-5.2.15-3.fc38.x86_64 is already installed. I was definitely referring to /path/to/existing/local/package.rpm, but I now understand the other behavior for /path/to/missing/file/to/find/and/install. Thank you for the clarification! That makes sense now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
