Re: Who moved my journald.conf?

On Thu, 9 May 2024 15:12:57 -0400, Tom Horsley wrote: > I mean, what if [Journal] means > "Forget everything, we're starting journal options now"? The last > thing you'd want to do is put in a [Journal] line in that case and > forget all the previous settings :-). That's an odd thought in my

Re: Who moved my journald.conf?

On Wed, 08 May 2024 10:49:12 +0100, Patrick O'Callaghan wrote: > As stated earlier, it hasn't been modified by me. > > > What is in your /etc/systemd/journald.conf file compared with the > > default in /usr/lib/systemd/journald.conf? > > They are identical except for comments: That proves my

Re: Who moved my journald.conf?

On Tue, 07 May 2024 23:22:53 +0100, Patrick O'Callaghan wrote: > In that case I assume it was put there under F39. Seems very odd that > the upgrade just kept it in addition to the one in /usr/lib/systemd. Depends. You cannot rely on just "rpm -qf ..." since that only queries the package file

Re: Who moved my journald.conf?

On Tue, 07 May 2024 21:38:47 +0100, Patrick O'Callaghan wrote: > It's there on my system, updated from F39: > > # rpm -qf /etc/systemd/journald.conf > systemd-255.4-1.fc40.x86_64 No, it's not: $ rpm -qcv systemd|grep conf$ -rw-r--r--1 root root0 Mar 1 01:00

Re: F40 and breaking file command change

On Fri, 3 May 2024 05:30:21 -0400, Jeffrey Walton wrote: > I thought the same thing about the file program. The change should have > caused a regression when running its self tests. The authors should have > known there was a problem with what they did. It's more likely that the file program's

Re: F40 and breaking file command change

On Wed, 1 May 2024 23:10:18 -0400, Jeffrey Walton wrote: > I was amazed the file project broke the command. The projects I contribute > to will move mountains to avoid breaking established behavior. We don't > want to screw our users like that. In such a case, your script ought to apply some

Re: Files missing in RPM database

On Wed, 1 May 2024 12:49:32 -0500, W. Michael Petullo wrote: > This clean up process has been going on since Fedora 1. FWIW, my mass-filings of "unowned directory" bugzilla tickets has had poor responses by packagers eventually and therefore has been discontinued. Instead, a section has been

Re: Switching XZ for ZSTD?

On Thu, 04 Apr 2024 13:51:59 +, Arnie T via devel wrote: > The 'basic issue' I see is the "one or two" developers, some that nobody > knows in person, vis-à-vis "many" developers on a big project. > The same sort of a secret agent's infiltration attack on a project would also be possible

Re: Where is the source code for a Koji build?

On Thu, 22 Feb 2024 04:13:18 -0500, Jeffrey Walton wrote: > I'm new to working with Fedora's Release Engineering. I ran across a > package that Failed To Build From Source (FTBS) for Fedora 40 at > . I have C and > C++ experience, and I believe

Re: emacs is hopeless

On Sun, 12 Nov 2023 20:50:04 -0500, Jeffrey Walton wrote: > I have not encountered any problems (yet?). Fedora 39 Workstation installation (so Wayland based), launching Emacs from GNOME Shell as well as terminals. No problems yet. I apply some font face customizations in ~/.emacs though.

Re: Sound synthesizer for Linux

On Sun, 22 Oct 2023 19:59:56 -0400, Fulko Hew wrote: > About 15 years or so ago, I was using a sound synthesizer on Fedora > that was GUI drag-n-drop sound modules, and draw wires between them > There were VCOs, filters, ADSR, mixers, etc. > > It looks like I never wrote down what I installed

Re: NTFS corruption with Fedora 37 and 38

On Mon, 31 Jul 2023 18:50:30 +0100, Richard W.M. Jones wrote: > Did you get to the bottom of what's really happening here? As in the message that opened this topic, it is suspected that there has been a change to mount with kernel ntfs3 instead of ntfs-3g. I remember I've not had corruption

Re: NTFS corruption with Fedora 37 and 38

On Tue, 25 Jul 2023 16:29:20 +0200, Ralf Corsépius wrote: > [1] I've only sporadically used NTFS, before, but for a couple of weeks, > I had to use it more frequently. I would also call my usage "sporadic" (accessing NTFS USB sticks and camera SD cards), but the worst symptoms I've had ever had

NTFS corruption with Fedora 37 and 38

Trying to figure out what has changed in Fedora land that causes NTFS corruption for some time. This is with default workstation with GNOME Shell auto-mounting external storage media when plugging them in. A ticket in bugzilla suggests there has been a changed from ntfs-3g to ntfs3:

Re: systemd-oomd insanely aggressive with non-DE logins

On Sun, 12 Mar 2023 13:37:46 -, Andre Robatino wrote: > I have 3 machines with clean F37 installs. Dunno yet whether it's also F37 or just F38, but here on F38 even gnome-terminal is getting killed when running a simple tar command in it that works on creating a ~20 GB archive.

Re: directories in /usr

On Tue, 27 Dec 2022 14:31:16 -0800, Samuel Sieb wrote: > If they are installed by the package manager, you shouldn't be deleting > them. > Do you mean "x86_64-w64-mingw32" and "i686-w64-mingw32"? > Did you install wine? Those files and directories are related to mingw not wine. And there are

Re: mass rebuild status - 2022-01-25

On Thu, 27 Jan 2022 15:06:31 +0100, František Šumšal wrote: > I've indeed noticed the other warnings. However, given this mass rebuild was > done with a new snapshot of gcc-12, the error is probably related to that, > that's why I pointed out the most severe issue (since it's an error, not > a

Re: mass rebuild status - 2022-01-25

On Thu, 27 Jan 2022 14:01:40 +0100, František Šumšal wrote: > Looks like the culprit is: You may have noticed that there are many more compiler errors in the build.log, but it seems you've missed that the src.rpm builds fine for all other archs. What gives?

Re: mass rebuild status - 2022-01-25

On Tue, 25 Jan 2022 10:04:32 -0800, Kevin Fenzi wrote: > After that we will be done and it will be on maintainers to sort out > FTBFS issues. What's up with the armv7hl arch being _the only one_ (!) that failed? https://koji.fedoraproject.org/koji/taskinfo?taskID=81787304

Re: mp4 to dvd

On Fri, 24 Dec 2021 14:17:57 -0600 (CST), Michael Hennebry wrote: > Any suggestions for converting mp4 files to VOB? > Even an example with mencoder might be useful. > Long long ago, I used mencoder for making DVD video files. > Lost track of the script I used. > I tried it again recently, > but

Re: Non-responsive maintainer check for bpepple

On Fri, 17 Dec 2021 11:50:42 -0500 (EST), Scott Talbert wrote: > Does anyone know how to contact them? Direct email and bug reports have > had no response. His twitter profile points at a few contact options as a last resort. https://twitter.com/bpepple

Re: F34 pipewire no audio after updates

On Thu, 19 Aug 2021 12:30:36 -0700, Jack Craig wrote: > i too have this problem after f34 install. (fresh, not updated).given > michael's status, what is the > next thing to try? Between GDM screen and logging in, something falls flat on its nose and sends errors to the logs, but the three

Re: F34 pipewire no audio after updates

On Wed, 28 Jul 2021 13:14:03 +0200, Michael Schwendt wrote: > Am I the only one where audio is missing after recent updates to F34? > The three pipewire processes are running, but no sound. No volume control > in GNOME Shell either. It's been a week or so without such problems, but t

F34 pipewire no audio after updates

Am I the only one where audio is missing after recent updates to F34? The three pipewire processes are running, but no sound. No volume control in GNOME Shell either. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to

Re: Fedora rawhide compose report: 20210727.n.0 changes

On Tue, 27 Jul 2021 15:26:31 +0200, Petr Pisar wrote: > It's a locale in sed: > > $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' > /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=C.UTF-8 sed > 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!' > 48 /* 3.8-devel */ > $ grep '[

Re: Fedora rawhide compose report: 20210727.n.0 changes

Something in grep/sed/rpm is broken since today or yesterday. On July 24th, a %global definition in a spec file still worked. It still works with a local Mock build for Rawhide/F35. It fails in koji Rawhide: https://kojipkgs.fedoraproject.org//work/tasks/3604/72743604/build.log

Re: Troubles with the claws-mail

On Sun, 6 Jun 2021 12:00:11 +0200, Bob Marcan wrote: > Fedora 33 up to date (Sun Jun 6 11:47:43 CEST 2021) > claws-mail-3.17.8-1.fc33.x86_64) > > In claws-mail keyboard key "k" is ignored. > Same key is working in all other applications. > So it is not a keyboard problem. :-) > Does anybody

Re: How to replace the rpm-build package with my own in a mock container

On Sun, 16 May 2021 13:11:09 -, Mikhail Gavrilov wrote: > I am already added my local repository to > `/etc/mock/templates/fedora-rawhide.tpl` with locally builded rpm-build > package. Did you include that template file from within the mock .cfg file? What does the root.log file contain?

Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)

On Mon, 3 May 2021 10:23:02 +0200, Miro Hrončok wrote: > Full report available at: > https://churchyard.fedorapeople.org/orphans-2021-05-03.txt > grep it for your FAS username and follow the dependency chain. Some more detail would be helpful in this case: Too many dependencies for dpdk,

Re: Self-introduction: TheEvilSkeleton

On Sat, 27 Mar 2021 12:15:13 -0400, TheEvilSkeleton wrote: > My alias is TheEvilSkeleton, but you can also call me Tesk, > TheEvilSkely, Skelly, Proprietary Chrome-chan or anything close to it. May I ask for your real name? Where does this come from that people introduce themselves with

Re: GNOME Shell startup app issue with /tmp

On Sat, 16 Jan 2021 08:44:54 -0600, Michael Catanzaro wrote: > > Most likely you want to use $XDG_RUNTIME_DIR instead, which is private > > to your user, and not shared with other users. Use glib's > > g_get_user_runtime_dir() as a wrapper for accessing that variable. > > Or g_dir_make_tmp()

Re: GNOME Shell startup app issue with /tmp

On Sat, 16 Jan 2021 15:34:44 +0100, Lennart Poettering wrote: > Regardless of the actual issue ran into: taking a predictable name > like that in /tmp/ is a DoS vulnerability. /tmp/ is a shared > namespace, any local program can take any name in there, and hence > block you out from starting

GNOME Shell startup app issue with /tmp

Noticed that when setting Claws Mail to become a startup app in F33 GNOME Shell, it doesn't create its /tmp/claws-mail-$UID directory. Claws Mail relies on g_get_tmp_dir() for retrieval of the path, so it seems when the program is launched, either /tmp doesn't exist yet or there are problems

Re: How did this file end up in the lookaside cache?

On Tue, 12 Jan 2021 00:13:21 +, Cristian Morales Vega wrote: > Not sure exactly when, but it looks like me creating > https://src.fedoraproject.org/rpms/doxygen/pull-request/9 has > triggered a process uploading the tarball to the lookaside cache. > > The tarball inside >

Re: can't install package pipewire-jack-audio-connection-kit

On Fri, 01 Jan 2021 15:28:48 -, Leigh Scott wrote: > > On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt > wrote: > > > > PipeWire replaces libjack and the JACK daemon, so the Conflicts are > > correct. > > How? > > $ rpm -q --requires libavdevice |

Re: can't install package pipewire-jack-audio-connection-kit

On Fri, 1 Jan 2021 10:26:13 -0500, Nico Kadel-Garcia wrote: > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > > > Conflicts in distribution packages are bad, bad, bad and typically a dead > > end when

Re: can't install package pipewire-jack-audio-connection-kit

On Fri, 1 Jan 2021 06:58:43 -0500, Neal Gompa wrote: > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > > > Conflicts in distribution packages are bad, bad, bad and typically a dead > > end when

Re: can't install package pipewire-jack-audio-connection-kit

On Thu, 31 Dec 2020 16:26:15 +0100, Matthias Runge wrote: > On 31/12/2020 16:10, Martin Gansser wrote: > > this means that jack-audio-connection-kit has been replaced by > > pipewire-jack-audio-connection-kit ? > > >- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 > >

Re: dnf exclude option not working

On Tue, 29 Dec 2020 19:00:30 +0200, Kostas Sfakiotakis wrote: > [root@Orion ~]# dnf repoquery --whatrequires libcpuid > > Last metadata expiration check: 0:52:55 ago on Tue 29 Dec 2020 06:01:13 > PM EET. > cpu-x-0:4.0.1-5.fc33.x86_64 > i-nex-0:7.6.1-4.fc33.x86_64 > i-nex-0:7.6.1-6.fc33.x86_64 >

Re: dnf exclude option not working

On Tue, 29 Dec 2020 18:46:05 +0200, Kostas Sfakiotakis wrote: > root@Orion ~]# dnf repoquery --whatrequires cpu-x > > Last metadata expiration check: 0:07:22 ago on Tue 29 Dec 2020 06:01:13 > PM EET. > cpu-x-data-0:4.0.1-5.fc33.noarch That query isn't helpful, because it doesn't show what you

Re: dnf exclude option not working

Kostas Sfakiotakis schrieb am Mo., 28. Dez. 2020, 23:25: > > Στις 28/12/20 8:15 μ.μ., ο/η Michael Schwendt έγραψε: > > On Mon, 28 Dec 2020 19:57:05 +0200, Kostas Sfakiotakis wrote: > > > >> Error: > >>Problem: problem with installed package cpu-x-4.0.1-5.f

Re: dnf exclude option not working

On Mon, 28 Dec 2020 19:57:05 +0200, Kostas Sfakiotakis wrote: > Error: >  Problem: problem with installed package cpu-x-4.0.1-5.fc33.x86_64 >   - cannot install the best update candidate for package > cpu-x-4.0.1-5.fc33.x86_64 >   - package cpu-x-4.0.1-5.fc33.x86_64 requires

Re: dnf exclude option not working

On Mon, 28 Dec 2020 14:07:19 +0200, Kostas Sfakiotakis wrote: > Στις 28/12/20 2:36 π.μ., ο/η Ed Greshko έγραψε: > > On 28/12/2020 08:05, Kostas Sfakiotakis wrote: > >> Can someone please tell me the correct syntax of the exclude option ( > >> the -x option will not work as well ) ?? > >> > >>

Re: smartd log alert

On Sun, 27 Dec 2020 17:56:56 +0100, François Patte wrote: > What is a "fairly low rate"? And beyond which rate do I have to be scared? Usually, you would want the displayed value to be high, since the underlying "rate" is mapped. If the shown value drops much, that would be reason to be

Re: smartd log alert

On Sun, 27 Dec 2020 14:36:54 +0100, François Patte wrote: > I have this alert in my watchlog report: Have you used the smartctl tool from the smartmontools package yet as to examine SMART data and perhaps run self-tests? ___ users mailing list --

Re: Fedora GNOME Shell rendering problem

On Wed, 23 Dec 2020 12:11:53 +0100, Olivier Fourdan wrote: > > The last time I had asked about Nvidia+Fedora was in 2018 when booting > > an installation would end up with a terribly slow GNOME Shell: > > > >

Re: Fedora GNOME Shell rendering problem

On Tue, 22 Dec 2020 17:15:32 +0100, Olivier Fourdan wrote: > Can you check and look for GL_OUT_OF_MEMORY messages in the journalctl logs > for gnome-shell? (Xwayland being spawned by gnome-shell, the messages from > Xwayland will be marked as gnome-shell in the logs) > > Xwayland uses glamor by

Re: Fedora GNOME Shell rendering problem

On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote: > Most likely the GPU driver. This is a symptom of a corrupted Xft glyph > cache inside the Xwayland X server. > > (It's not impossible that the glyph was corrupted before upload by > some other component, but that's much less likely -

Fedora GNOME Shell rendering problem

In the attached screenshot excerpt it's the bold "a" character that is missing everywhere within the entire main window of Claws Mail. In other cases, it's a different character. Sometimes it is not missing but visually corrupted, looking like random "garbage" data. Fedora 33 x86_64 GNOME Shell

Re: The (bad) state of Qt on GNOME / Wayland

Thread is old, but makes me wonder, is there any current status on Qt with Wayland? In F33 with GNOME Workstation, several Qt applications don't work correctly with Wayland, but do work if switching to Xorg. avidemux-qt, for example, displays a video preview area that doesn't update. Audacious

Re: test Digest, Vol 200, Issue 122

On Fri, 30 Oct 2020 00:03:36 + (UTC), George R Goffe via test wrote: > Traffic means what you might expect it to mean. Typically this kind of server > communicates about bugs and "special events" like outages. > > Since I am not communicating to bugzilla.redhat.com I am waiting for traffic

Re: F33 WS ISO checksum

On Wed, 28 Oct 2020 11:21:07 -0400, pmkel...@frontier.com wrote: > Are you saying that the warning message about the 19 lines is a don't > care or is their a problem with the way the checksum file is made? Does > this mean that the OK message that comes first is in error? Just display the

Firefox Clear History not clickable / F33

This is with default Fedora 33 Workstation x86_64. Firefox > History > Clear Recent History > Time range to clear The combobox can be clicked to show the drop-down list, but none of the shown items can be selected with a mouse-click. Using cursor keys is the workaround. Can anyone reproduce

Re: Is anyone else having trouble with bugzilla.redhat.com?

On Tue, 27 Oct 2020 18:09:27 + (UTC), George R Goffe via test wrote: > I have had no traffic from the RedHat bugzilla site since 7 Oct. ^^ What does that mean? > Is the site broken? No. > Have I missed something or am I doing something wrong? Start with a detailed

Re: installing wine on F33 wants to downgrade packages

On Fri, 23 Oct 2020 15:08:57 -0500, Anil Felipe Duggirala wrote: > 2. Why is it downgrading my packages? A likely cause is that you have come from an x86_64-only installation that has had access to more recent package repositories than what you using currently. Possibly because you've been

Re: testing update

On Tue, 20 Oct 2020 11:02:23 -0700, Samuel Sieb wrote: > > Do I need to dnf remove rpmfusion-free-release-32-1.noarch > > rpmfusion doesn't even have a testing repo. You need to provide more > details. Of course they still offer a testing repo for updates, and its .repo file is included

Strange gpg-agent processes with Fedora 32

Has anyone seen the following before and possibly has found out what is going on? Fedora 32 shows a gpg-agent process for each repo but with a non-existant ".tmp" homedir. Examples: root2512 0.0 0.0 161028 900 ?Ss 11:20 0:00 gpg-agent --homedir

Bodhi failed to get a resource from PDC ...

Bodhi fails with this error message. Any suggestion on how to continue? Builds : Unable to create update. Bodhi failed to get a resource from PDC at the following URL

Re: Unannounced soname bump: libreport

On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote: > > As a side note, the update now has arch specific BuildRequires, so the SRPM > > cannot be rebuilt on anything but . > > > > https://koschei.fedoraproject.org/package/libreport?collection=f33 > > Aaaw ... stuff like this makes me

Re: A few questions about rpmdev-bumpspec tool

On Thu, 13 Aug 2020 18:41:23 +0800, Qiyu Yan wrote: > In the latest version of rpmdevtools, rpmdev-bumpspec has changed to > use time+date in the changelog it generates[1], while the packaging > guidelines have not been updated accordingly[2], should the guideline > be updated to the

Re: Duplicate package was reviewed

On Fri, 31 Jul 2020 12:48:44 +0200, Tomasz Torcz wrote: > What about bringing old, possibly unmaintained library into Fedora? > It may contain unfixed security bugs. Not that I know of any, but it's > a possibility. 1) First it would need to pass the review process. Submitter _and_ reviewer

Re: Duplicate package was reviewed

libqmatrixclient vs libquotient Absolutely no conflict whatsoever. Different SONAME, different file/folder names, different package names, different project name. Even if they came from the same project, the old compat- naming scheme would not have applied.

Re: rkhunter --update fails.

On Thu, 30 Jul 2020 16:55:53 -, home user wrote: > [10:44:44] Checking file mirrors.dat [ Update failed ] > [10:44:44] Info: Executing download command '/usr/bin/wget -q -O > "/var/lib/rkhunter/rkhunter.upd.rJwBkFr06W" >

Re: Steam erroneously marked as "Installed" in Gnome Software

On Wed, 1 Jul 2020 01:44:32 +0530, Sreyan Chakravarty wrote: > Hi, > > I have NEVER installed Steam via Gnome Software on my notebook, in fact > I never installed it ever, but on Gnome Software it is marked as > "Installed". > > Any way I can remove it from there ? That is mark it as "not

Re: Every second GDM login fails

On Sun, 28 Jun 2020 19:25:48 +0800, Ed Greshko wrote: > Next time you do it, count the dots just to make sure all keystrokes are > being registered. > I've done that before and have also clicked the "eye" icon to unhide the entered passphrase, and it is shown correctly but will be rejected.

Every second GDM login fails

Has anyone also had this before with GNOME Shell in Fedora 32? It is new behavior compared with older releases of Fedora. When I return to a locked screen, my usual habit is to press Return and then to enter the passphrase. That fails even if unhiding the passphrase and verifying that it has been

Re: Errors compiling

On Tue, 23 Jun 2020 21:56:40 -0400, Frank wrote: > I am trying to compile/install IceWm for my Fedora 32 installation. Ran > into some problems I have resolved, but > I am stumped by these: > > checking for strlcat... no > checking for C++11 by default... yes > checking for CORE... no >

Re: what was that on f30 ??

On Tue, 23 Jun 2020 05:21:46 -0700, Jack Craig wrote: > yesterday, something came on screen asking for a repo update & authorised > access. > > seems to have broken repo access, any insights?? Rule of thumb in such a scenario would be to ask _before_ proceeding, and to be precise about what

Re: issue upde fc32 (sagemath)

On Sat, 6 Jun 2020 20:33:30 +0200, Patrick Dupre wrote: > Hello, > > I get the following error message: > dnf update > Last metadata expiration check: 0:07:57 ago on Sat 06 Jun 2020 08:23:49 PM > CEST. > Dependencies resolved. > > Problem 1: package polymake-singular-4.0.1-2.fc32.x86_64

Re: Orphaning a bunch of my packages (part 1 of X)

On Sat, 6 Jun 2020 12:06:28 +0200, Andy Mender wrote: > I'm a heavy LXQt user. Does that mean that if those packages get orphaned > for good, they will be dropped from the repositories? It is explained here: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

Re: perl-Math-GSL

On Wed, 3 Jun 2020 11:21:43 +0200, Patrick Dupre wrote: > I could not compile perl-Math-GSL-0.40 because this package does not deal > with gsl 2.6 > Thus, I installed gsl 2.5 independently of gsl 2.6 (gsl-2.6-2.fc32.x86_64) > and I was able to build the rpm package which requires libgsl.so.23 >

Re: build package

On Tue, 2 Jun 2020 20:08:16 +0200, Patrick Dupre wrote: > Can I simulatenously install GSL 2.5 and 2.6? > > or remove GSL 2.6 and intall GSL 2.5? > The library SONAME has changed from libgsl.so.23 to libgsl.so.25, but libgslcblas.so.0 hasn't changed, and the Fedora packages would conflict

Re: Unretiring abcMIDI

On Tue, 02 Jun 2020 10:46:45 -0400, Stuart D. Gathman wrote: > 2. The GPLv2 license is buried in readme.txt. I added a LICENSE file > to my git mirror. Should I include that as a patch? https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text > 4. The

Re: build package

On Tue, 2 Jun 2020 12:36:03 +0200, Patrick Dupre wrote: > Hello, > > I am rebuilding the perl packages that I need. > perl-Math-GSL-0.40.tar.gz > > > rpmbuild -bb perl-Math-GSL.spec > > gives an error: > Checking for GSL using gsl-config > Found GSL 2.6 (via gsl-config) installed in /usr >

Re: Bodhi: "how to install" is supposed to work?

On Tue, 02 Jun 2020 09:32:27 +0200, Alessio wrote: > In Bodhi there is a dnf command in the "How to install" section, in > order to install the package to test. Something like: > > sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020- > 81a3b3df7d > > Is it supposed to work?

Re: upgrade 30 to 32

On Tue, 02 Jun 2020 19:29:51 +0930, Tim via users wrote: > Patrick Dupre wrote: > >> This has been solved by > >> > >> rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 > > Michael Schwendt: > > The good old "rpm -e perl-PDL-LAPACK" wou

Re: upgrade 30 to 32

On Tue, 2 Jun 2020 00:25:59 -0700, Samuel Sieb wrote: > >> rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 > > > > The good old "rpm -e perl-PDL-LAPACK" would have been enough for the > > most common use case. > > Maybe you missed the original message where he tried the equivalent of > that

Re: upgrade 30 to 32

On Mon, 1 Jun 2020 23:12:06 +0200, Patrick Dupre wrote: > This has been solved by > > rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 The good old "rpm -e perl-PDL-LAPACK" would have been enough for the most common use case. ___ users mailing list --

Re: Fedora 30 EOL

On Mon, 1 Jun 2020 12:09:36 -0500, Roger Heflin wrote: > When the policy is not being followed and/or not enforced it means > nothing. Only someone who is in love with > the policy would say otherwise and actively defend it. You're still not getting it. > I am going to guess you helped write

Re: Looking for a .so

On Sun, 31 May 2020 09:02:51 -0700, Geoffrey Leach wrote: > On Sun, 31 May 2020 16:29:54 +0200 > Andras Simon wrote: > > > 2020-05-31 16:08 UTC+02:00, Geoffrey Leach: > > > I have a build that references '-lz'. This fails, because gcc > > > expects to find libz.so in the library search path.

Re: F30 security update submitted for stable "marked obsolete" instead of being pushed

On Fri, 29 May 2020 16:55:37 +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > AFAIK this was never the case, but I'm not sure. I remember in the past > > the updates just kinda stuck in limbo (being pushed to stable for > > eternity). At least now they are marked as obsolete. > > I think

Re: Fedora 30 EOL

On Sat, 30 May 2020 16:42:10 -0500, Roger Heflin wrote: > The policy means nothing when Only an "outsider" would say that. That policy has been refined multiple times since the fedora.us era with its strict QA policies. That policy is also reason why potential "maintainers" shy away from the

Re: Fedora 30 EOL

On Sat, 30 May 2020 11:14:22 -0500, Roger Heflin wrote: > You really need to understand the devs actual motivations. And your > are attributing things to Fedora devels that are being funded outside > of the Fedora community. Please, think outside the box. It isn't helpful to the discussion, if

Re: Fedora 30 EOL

On Sat, 30 May 2020 07:33:04 -0500, Roger Heflin wrote: > My background is I have been used Fedora since Core 1, and prior to > that started with Redhat 5/6/7/8/9 and managed (or was technical lead > for a team) with >1000 installed running combinations of RHEL, Centos, > non-enterprise

Re: What's pulling in a bunch of texlive packages?

On Sat, 30 May 2020 16:11:16 +0100, José Abílio Matos wrote: > Most probably something that provides documentation, e.g. on pdf. docbook-utils-pdf is a likely candidate. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: Cannot upgrade gnutls with dnf (transaction problems)

On Sat, 30 May 2020 09:33:11 +0200, Joachim Backes wrote: > Error: Transaction test error: >   file /usr/share/doc/manual/gnutls.html conflicts between attempted > installs of gnutls-devel-3.6.13-4.fc32.i686 and > gnutls-devel-3.6.13-4.fc32.x86_64 >   file /usr/share/info/gnutls.info-3.gz

Re: Fedora 30 EOL

On Fri, 29 May 2020 21:08:10 -0500, Roger Heflin wrote: > The maintainers are for the most part about "packaging" kernels. > They rarely seem to ever work on kernel bugs, nor have the time to do > such investigate even if they have the time. If that were true, something would be even more wrong

Re: Fedora 30 EOL

On Fri, 29 May 2020 13:56:34 -0500, Roger Heflin wrote: > I don't believe the kernel.org developers work out of the fedora > bugzilla (or any distro's bugzilla), so no one who knows anything is > likely to find and/or see the bug. > > To get a kernel developer you would need to at least post a

Re: python3-pyparsing: conflicting error

On Fri, 29 May 2020 15:09:34 +0200, Jun Aruga wrote: > I opened the issue ticket for systemtap. > https://bugzilla.redhat.com/show_bug.cgi?id=1841558 Why would you do that? It's "python3" (3.8) -> "python3.9" dependency breakage. ___ devel mailing list

Re: Fedora 30 EOL

On Thu, 28 May 2020 21:19:34 -0700, John M. Harris Jr wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1742960 > > > > > > Lately all my bug reports tend to go like this. > > > > > > Why don't you try to reproduce issues with Fedora 31, 32 or Rawhide > > and then reassign the tickets

Re: Fedora 30 EOL

On Thu, 28 May 2020 18:08:48 +0930, Tim via users wrote: > Perhaps there should be an automated culling of participants. If you > step up the plate to say you'll maintain a package, but don't, *you* > get dumped from bugzilla. Please let's not create a thread of doom. You can't seriously

Re: Fedora 30 EOL

On Thu, 28 May 2020 07:50:16 +, Suvayu Ali wrote: > It took so long, that the bug report became irrelevant. I have since > moved to a different country, with a different job, and don't have > access to the original machine. In fact, as mentioned in the bug, I > could reproduce a similar

Re: Fedora 30 EOL

On Wed, 27 May 2020 15:42:39 -0400, Ben Cotton wrote: > On Wed, May 27, 2020 at 3:23 PM Michael Schwendt wrote: > > > > The fundamental problem here is that it has taken a very long time for > > somebody to respond to the bug reporter. There has been no guidance and >

Re: Fedora 30 EOL

On Wed, 27 May 2020 12:07:35 -0400, Ben Cotton wrote: > On Wed, May 27, 2020 at 4:30 AM Suvayu Ali wrote: > > > > Lately all my bug reports tend to go like this. Are others having the > > same experience? > > I understand the frustration. My bugs get closed EOL, too. For what > it's worth,

Re: Fedora 30 EOL

On Wed, 27 May 2020 08:18:48 +, Suvayu Ali wrote: > > As of the 26th of May 2020, Fedora 30 has reached its end of life for > > https://bugzilla.redhat.com/show_bug.cgi?id=1742960 > > Lately all my bug reports tend to go like this. Why don't you try to reproduce issues with Fedora 31, 32

Re: Retired packages with maintainers

On Tue, 12 May 2020 at 14:13, Fabio Valentini wrote: > > > - Do we have a documented way to mark modules as orphaned or retired? > > I think we do. I seem to remember seeing "dead.module" files in some > module repositories I looked at ... Well, the "dead.package" file in dist git has been the

Re: Fedora pagure confusion wrt EPEL

On Tue, 5 May 2020 at 10:33, Pierre-Yves Chibon wrote: > > The scripts syncing information from dist-git to bugzilla have been broken > for a > long time (less than 5 years though) and we've picked them up, fixed and clean > them so they work again. > This has been announced here and on

Re: Fedora pagure confusion wrt EPEL

On Mon, 04 May 2020 20:12:58 -0400, James Cassell wrote: > > Can this stop, please? > > > > Again somebody has used a script to assign bugzilla EPEL tickets to me > > again, although I am not responsible for the EPEL packages and have never > > been responsible for them. > > > > I feel

Re: Fedora pagure confusion wrt EPEL

> This incident turns into a growingly unpleasant experience for me. > I've asked you to clean up the mess in bugzilla and reassign the EPEL > packages properly, because I am not responsible for those packages. > You've not done that. I've had to do it myself. Team work doesn't mean > that you

Re: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

On Sat, 2 May 2020 12:36:29 +0200, Sandro Mani wrote: > Hi > > I'm stuck on the following build failure of the aarch64 build here [1] > > /usr/bin/ld: .libs/geod: hidden symbol `__aarch64_ldadd4_acq_rel' in > /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced > by DSO >

  1   2   3   4   5   6   7   8   9   10   >