devel October 2021

devel@lists.fedoraproject.org

190 participants
422 discussions

F35 Change: Debuginfod By Default (Self-Contained Change proposal)
by Ben Cotton 05 Jun '24

05 Jun '24

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault == Summary == Fedora users / developers who need to debug/trace distro binaries can make use of the recently activated elfutils-debuginfod servers to automatically fetch debugging data and source code, instead of having to use `# sudo dnf` commands. == Owner == * Name: [[User:fche| Frank Ch. Eigler]] * Email: fche(a)redhat.com == Detailed Description == Numerous fedora debugging-type tools have built-in capabilities to use the [https://sourceware.org/elfutils/Debuginfod.html debuginfod] protocol to fetch debuginfo/source code automatically. We would like to activate a setting so that Fedora's debuginfod servers are automatically used, rather than requiring hand-editing individual users' dot files. == Feedback == There has existed [https://www.spinics.net/lists/fedora-devel/msg279002.html broad interest] in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature. Some of the distros configure their installations by default to talk to those servers, some do not. Turning on this by default has some limited privacy implications. Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging. The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo. Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy. We anticipate discussing this topic on the mailing list, and noting it in the release notes either way. == Benefit to Fedora == This will improve developers' experience. It may reduce download server burden, as only individual ELF/DWARF/source files are downloaded rather than entire `-debuginfo` and `-debugsource` RPMs. It would help Fedora catch up to other distros who put up `debuginfod` servers already. :-) == Scope == * Proposal owners: The work could consist one extra parameter in the `elfutils.spec` `%configure`. Its effect is to arrange for the `elfutils-debuginfod-client` RPM to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS` environment variable automatically to `https://debuginfod.fedoraproject.org/`. (At the time of this writing, the _staging_ server is getting ready for testing: `https://debuginfod.stg.fedoraproject.org/`.) * Other developers: None - relevant code has been previously upstreamed! * Release engineering: None - our team is operating the `debuginfod[.stg].fedoraproject.org` VMs. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == None. Note that these servers index all active Fedora releases (32-), all architectures, so users of those versions can already set `DEBUGINFOD_URLS` manually to take advantage. == How To Test == * Install `elfutils-debuginfod-client` * Open arbitrary fedora binary via gdb. ** Admire the immediate downloading of debuginfo and source code. * Run `eu-stack -v -p $pid` for an arbitrary process. ** Admire the immediate downloading of debuginfo to give precise file:line data. == User Experience == Primarily: users running debuggers, profilers, tracing tools on internet-capable machines can work immediately, without switching to privileged users and fragile manual `dnf` commands to install this data. == Dependencies == The `debuginfod` servers at `fedora-infra` need to be up. == Contingency Plan == * Contingency mechanism: change the elfutils-debuginfod-client subrpm to not set the default `DEBUGINFOD_URLS` environment variable for all users. In the case of a server outage, the debugger tools revert to debuginfo-less operation, prior to this feature. * Contingency deadline: shortly before freeze * Blocks release? No == Documentation == There is upstream documentation in the debugging tools as well as associated with the client code / cli tooling. What our Release Notes would focus on however is the _automatic activation_ of this facility via the environment variable. == Release Notes == TBD. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

16 43

some man pages have bugs, can't be grep'd
by Chris Murphy 27 Mar '24

27 Mar '24

I've been seeing this since clean installing Fedora 30. I don't recall ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded system (is now the clean installed system). [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity <standard input>:176: warning [p 3, 0.8i]: cannot adjust line [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr [chris@flap mantest]$ ll -rw-rw-r--. 1 chris chris 62 Jul 16 14:24 rpm.stderr -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout Is this a bug that should be reported against rpm or something else? I'm certain I've seen it in other man pages, but offhand I can't find another example. -- Chris Murphy

4 6

Unretire ulogd (or another NFLOG logger?)
by Chris Adams 21 Feb '24

21 Feb '24

I'd like to use NFLOG to log firewall drops (so that the kernel message log isn't spammed by them), but it doesn't appear there's anything currently in Fedora that can read that other than "tcpdump -i nflog". It looks like ulogd was retired a while back because it only had a SysV init script and nobody stepped up to convert it to systemd (which should be really simple, since the old init script is pretty much a textbook template of a SysV init script). Am I missing anything? Is that all it needs? Is there another NFLOG logger daemon? -- Chris Adams <linux(a)cmadams.net>

2 1

Outage Notification - 2009-07-01 01:00 UTC
by Mike McGrath 24 Aug '23

24 Aug '23

There will be an outage starting at 2009-07-01 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-01 01:00 UTC' Affected Services: Buildsystem CVS / Source Control Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1496 Reason for Outage: Final migration step for new cvs server. It will hopefully be offline for only 30-45 minutes. The additional time is for some further tuning if needed and some verification steps. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce

2 1

RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller 12 Jun '23

12 Jun '23

Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? * see http://fedora.riscv.rocks/koji/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

20 40

Conflicting build-ids in nekovm and haxe
by Andy Li 07 May '23

07 May '23

Hi list, Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901 Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c". The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib". Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode). I'm not sure how to resolve it. Please advice. Best regards, Andy

5 6

can't install package pipewire-jack-audio-connection-kit
by Martin Gansser 12 Mar '23

12 Mar '23

Hi, when trying to install pipewire-jack-audio-connection-kit i get this error message: # dnf -y install pipewire-jack-audio-connection-kit Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020. Error: Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - conflicting requests - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) How can i fix this ? Regards Martin

11 17

x86_64-v2 in Fedora
by Neal Gompa 02 Feb '23

02 Feb '23

Hey all, Earlier this week, I was helping with processing features for openSUSE Leap 15.4[1] and I discovered that they're planning on introducing x86_64-v2 to openSUSE soon. The reference for this change was that RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions have been considering bumping up to v2 or v3[3][4]. Some cursory examination of the new x86_64 sublevels seem to indicate that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the first couple of generations of x86_64 CPUs from Intel and AMD. I personally don't have any computers that don't have support for x86_64-v2 anymore. Does anyone know if anyone is planning to propose this for Fedora anytime soon, either as an addon architecture (like what Arch is doing) or an upgrade of our x86_64 baseline like RHEL is doing? [1]: https://en.opensuse.org/Feature_Planning_15.4 [2]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-l… [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html [4]: https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-Po… -- 真実はいつも一つ！/ Always, there's only one truth!

32 61

[apt-cacher-ng] Resurrect dead package
by Frédéric Pierret 24 Dec '22

24 Dec '22

Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb2… with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?r… still available for such case? Thank you. Best regards, Frédéric Pierret

3 3

fedpkg clone fails with Permission denied (publickey).
by Richard Shaw 26 Nov '22

26 Nov '22

Long story short I lost my home directory where I do all of my packager activities (separate from my main user) so I'm setting things up from scratch. I created new ssh keys and uploaded the public key to admin.fedoraproject.org and pasted into pagure.io. It's been over an hour and I'm still getting: $ fedpkg clone hamlib Cloning into 'hamlib'... hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. I've also updated my API tokens, which is STILL not well documented. I pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't real intuitive. Thanks, Richard

5 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2021