Re: Changes to gdk-pixbuf2 in rawhide and F43

On Thu, 04 Sep 2025 08:51:36 -0500, Michael Catanzaro wrote: > I have checked our gdk-pixbuf2-modules-extra package. I think the > BMP, ICO, PNM, and TGA loaders are now obsolete and can safely be > disabled. The other loaders provided by this package are still > needed, but they cover particularl

Re: Strange rpm conflicts

On Mon, 28 Jul 2025 19:45:15 -0600, Orion Poplawski wrote: > Can someone explain this to me? > > sudo dnf upgrade -y eccodes\* > install of eccodes-data-2.42.0-2.fc43.noarch conflicts with file from > package eccodes-data-2.40.0-1.fc43.noarch >- file /usr/share/eccodes/definitions/bufr/ta

Re: RPM %doc directive

On Sun, 25 May 2025 18:49:26 +0100, Barry Scott wrote: > %doc is not a directive that copies anything, which you seem to be > saying. The so-called "special %doc" copies files from local builddir to %_docdir/%name/ Example: %files %doc README --

Re: RPM %doc directive

On Sun, 25 May 2025 16:16:45 +, Mattia Verga via devel wrote: > So, if I understand correctly, I should use %doc only when I need to > "manually" copy docfiles from builddir to buildroot, instead if a > package already install docfiles in the correct position I just have > to list as "regula

Re: RPM %doc directive

On Sun, 25 May 2025 08:38:14 +, Mattia Verga via devel wrote: > But using > '%doc %{_pkgdocdir}/python_module/README.md' > returns > 'Can't mix special %doc with other forms: > /usr/share/doc/siril/python_module/README.md' > > How can I make %doc use that as absolute patch instead of special

Re: gettext 1.25 & error: possibly undefined macro: AM_GNU_GETTEXT

On Mon, 19 May 2025 16:11:00 +0100, Daniel P. Berrangé wrote: > [...], avoiding the autopoint dance autoreconf is supposed to run autopoint according to the manual page, and not even if running autoreconf -f, it manages to run autopoint automatically. DESCRIPTION Run 'autoconf' and, wh

Re: gettext 1.25 & error: possibly undefined macro: AM_GNU_GETTEXT

On Mon, 19 May 2025 15:22:48 +0100, Richard W.M. Jones wrote: > Seemingly because of gettext 1.25 that was recently added to Fedora > Rawhide, I'm now getting the error below. This also breaks all builds > of libguestfs and related tools in Rawhide. > > $ autoreconf -fiv For the background, se

Re: Unannounced / uncoordinated soname bump: magma

On Sun, 4 May 2025 01:42:24 +0200, Fabio Valentini wrote: > The update to magma 2.9.0 that landed in rawhide a few hours ago > bumped the soname for libmagma.so (from `libmagma.so.2.8.0()(64bit)` > to `libmagma.so.2.9.0()(64bit)`) which was not announced or > coordinated with dependent packages.

Re: F43 packagekitd creates load

> $ rpm -qf /usr/libexec/packagekitd > PackageKit-1.2.8-9.fc42.x86_64 Among lots of error log messages, it spams hundreds of thousands of these while not terminating: $ sudo journalctl -xb|grep -i packagekit|grep "failed to add subkeys"|wc -l 463617 May 01 13:09:51 fedora packagekitd[20889]: fai

F43 packagekitd creates load

It's been like this since I've upgraded F42 to F43 Rawhide. On a freshly booted system, packagekitd keeps running and working on something without stopping. What's going on? Is it like that for anyone else? $ rpm -qf /usr/libexec/packagekitd PackageKit-1.2.8-9.fc42.x86_64 --

Re: BuildRequires: coreutils and %{_fixperms}

On Sat, 5 Apr 2025 19:44:26 -0500, Chris Adams wrote: > reviewing a new package of mine, the reviewer said I should BR > coreutils because of that, which makes sense... Package "coreutils" is part of the build-system core set of packages for many, many years and thus doesn't need to become a BR.

Re: Dependency generation in Fedora/COS10 vs RHEL9/COS9

On Thu, 06 Mar 2025 14:31:17 +0100, Michael J Gruber wrote: > https://copr.fedorainfracloud.org/coprs/mjg/mupdf-git/ Any particular reason why the shared libs are not executable? They ought to be. Missing 'x' permissions has caused issues before. $ rpmls mupdf-libs-1.26.0~dev\^309.gfa7687f1c-1.e

Re: Old Style Dependency Generators

On Mon, 16 Sep 2024 12:49:55 +0200, Vít Ondruch wrote: > I believe that the new dependency generators were introduced by RPM 4.9.0: > > https://rpm.org/wiki/Releases/4.9.0 > > Introduced into guidelines 13 year ago: > > https://pagure.io/packaging-committee/issue/76 > > RHEL 7 shipped with RPM

Re: gdk-pixbuf removing several icon loaders

$ rpm -qR claws-mail|grep pixbuf libgdk_pixbuf-2.0.so.0()(64bit) I've added %if 0%{?fedora} > 40 Requires: gdk-pixbuf2-modules-extra%{?_isa} %endif to fix the missing icons and the intercepted backtrace. For Geeqie I've filed: https://bugzilla.redhat.com/2312404 It's not nice, if an ima

Re: Old Style Dependency Generators

On Fri, 13 Sep 2024 10:35:06 +0200, Vít Ondruch wrote: > $ grep -R filter_setup > audacious-plugins.spec:%filter_setup A false positive, because such a simple grep doesn't handle the %if/%else used in that spec file. -- ___ devel mailing list -- devel

Re: Donate 1 minute of your time to test upgrades from F40 to F41

On Mon, 2 Sep 2024 07:20:46 -0700, Pablo Sebastián Greco wrote: > Error: >  Problem 1: package wxGTK3-3.0.5.1-10.fc38.x86_64 from @System requires > libtiff.so.5()(64bit), but none of the providers can be installed The wxGTK3 package does not exist anymore in Fedora 39 and later. File dead.pac

Re: SPDX Statistics - Montessori Edition

On Sat, 31 Aug 2024 12:42:48 +0200, Miroslav Suchý wrote: > List by package maintainers is here > > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt > Well, both "audacious" and "audacious-plugins" are almost done, except for the BSD variant they u

GNOME Shell automatic printer configuration

Whereas this has worked with some older releases of Fedora, in F40 it is broken again here. Printer model is a Samsung ML-1640 USB, and when turning it on GNOME Shell displays notifications about configuring it automatically. However, printing doesn't work afterwards. It reports success, but does

Re: Strange directory ownership in RPM database

On Wed, 10 Jul 2024 17:54:38 +0200, Christoph Karl via devel wrote: > Hi! > > Thank you for the clarification. > How about two different packages which do not depend on each other > having both files/directories below /xyz/? > I assume in this case co-ownership of /xyz/ should be used? > > Is th

Re: Strange directory ownership in RPM database

On Wed, 10 Jul 2024 08:47:32 -0600, Jerry James wrote: > That's exactly it. > > $ ls /usr/lib/qt6 > plugins qml > $ rpm -qf /usr/lib/qt6 > file /usr/lib/qt6 is not owned by any package > $ rpm -qf /usr/lib/qt6/plugins > file /usr/lib/qt6/plugins is not owned by any package > $ rpm -qf /usr/lib/q

Re: Strange directory ownership in RPM database

On Wed, 10 Jul 2024 09:06:54 +0200, Christoph Karl via devel wrote: > RPM does not know about this directory: > $ rpm -qf /usr/lib/qt6 > file /usr/lib/qt6 is not owned by any package > > And dnf thinks it is i686-only: > $ dnf provides /usr/lib/qt6 > Updating and loading repositories: > Repositor

Re: Automatic detection of unused BuildRequires

On Wed, 3 Jul 2024 18:02:01 +0200, Marián Konček wrote: > To my knowledge there is no such project. Only highly experimental ones have been used many, many years ago. For example, in Fedora land I've caught some unused BuildRequires with a script that checks whether shared libs provided by build

Re: fedorapeople.org updated (including new ssh host key)

On Tue, 2 Jul 2024 11:39:01 -0700, Kevin Fenzi wrote: > Please see https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org Page mentions a file ~/.ssh/known_keys which doesn't ring a bell. I've copied to known_hosts instead as usual. A known_keys files is not documented in the manual. --

Orphaned libguess

I've orphaned libguess. It's last known API user doesn't require it anymore for some time. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://doc

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 inc

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 wi

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 with

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: https://bugzi

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 war

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: 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: 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 '[ ]*#define[

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

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() N

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 Claws

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 creat

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 > https://kojipkgs.fed

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 someone

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

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: > > > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/EC7T7MN

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 d

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

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 on

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 "https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true&critical_path=true&fields=global_component&name=f32&page

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 sad

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 rpmdev-bumpsp

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 bo

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

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? Beca

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 th

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 emai

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

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 devel-ann

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

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 assi

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

Re: Hundreds of aarch64 failures with gcc 10.0.1-0.13

> Seems like a lot of things just started to fail to build on aarch64. I also get the following only for aarch64: /usr/bin/ld: index.lib.o: in function `IndexBase::clear(void (*)(void*, int))': /builddir/build/BUILD/audacious-4.0.3/src/libaudcore/index.cc:48: undefined reference to `__aarch64_ld

Re: Orphaning soundtracker

On Thu, 9 Apr 2020 07:10:48 -0700, Erich Eickmeyer wrote: > soundtracker is FTBFS and is basically gnome 1 software that > necro-limped along like a zombie for a few years (read: decades). As it > FTBFS and is dead upstream, I believe it's suffering bitrot so it's > probably time to let it die. >

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

On Sat, 1 Feb 2020 at 19:58, Stephen John Smoogen wrote: > >> From >> https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_deal_with_reported_bugs_in_a_timely_manner >> : >> >> It is recommended that non-coder packagers should find >> co-maintainers who are fam

Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

On Thu, 30 Jan 2020 at 15:47, Richard Shaw wrote: > > 4. I'm not a C/C++ programmer and certainly not a security expert. If I can > find a link to a fix for another distro, such as debian, I'll apply it but > more often than not there's nothing there when I look. I'll even file an > issue upstr

Re: Fedora pagure confusion wrt EPEL

On Fri, 31 Jan 2020 at 20:45, Robbie Harwood wrote: > > You received a total of between 4 and 8 emails depending on how bugzilla > batched them. My apologies for the extra 3-7. More than eight because of needinfo notifications, "assigned" and "Cc" changes and tracker ticket changes. > >> Andrea

Re: Fedora pagure confusion wrt EPEL

On Fri, 31 Jan 2020 at 18:11, Robbie Harwood wrote: > > I could have also needinfo(Michael) (and in hindsight I probably should > have), but based on their reaction, I don't think they would have been > any happier with that. I would have preferred private email over assigning multiple tickets to

Re: Fedora pagure confusion wrt EPEL

On Fri, 31 Jan 2020 at 00:56, Fabio Valentini wrote: > >> > It seems the "support" in PkgDB was also a "lie", because BugZilla >> > doesn't even support default assignees per-branch. >> >> It just worked, and when somebody opened a ticket about an EPEL package, >> the EPEL-specific maintainer beca

Re: Fedora notifications bug: 404 Not Found

On Fri, 31 Jan 2020 at 02:47, Kevin Fenzi wrote: > Can you provide more info? > Was this an irc or email message? > or was it in the git push? It was an email notification. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: Fedora pagure confusion wrt EPEL

On Thu, 30 Jan 2020 23:57:03 +0100, Fabio Valentini wrote: > Did you at least check if the packages were used by something else? ... No, and that doesn't interest me at all. I am not doing EPEL packaging, and I consider it inacceptable that somebody assigns five years old EPEL tickets to me and e

Re: Fedora pagure confusion wrt EPEL

On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote: > Fabio Valentini wrote: > > Until this functionality is merged into pagure's dist-git plugin, there is > > a way, but it's a bit convoluted. And it's too obscure. Instead, I just retired the two EPEL branches. > And we have to do that for

Fedora notifications bug: 404 Not Found

No idea where to report these: | Notification time stamped 2020-01-30 09:55:53 UTC | | mschwendt pushed 1 commit to rpms/claws-mail (el6) | https://src.fedoraproject.org/rpms/claws-mail/branch/el6 Not Found The requested URL was not found on the server. If you entered the URL manually p

Re: Fedora pagure confusion wrt EPEL

On Thu, 30 Jan 2020 12:23:01 +0300, Vascom wrote: > No way. > You can add comaintainer for EPEL builds of your packages. That can't be right. Who has made me the "owner" of claws-mail in EPEL? And why? https://fedoraproject.org/wiki/EPEL/FAQ#I_maintain_a_package_in_Fedora._Do_I_have_to_maintain

Fedora pagure confusion wrt EPEL

I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages. I don't want to be the new default owner of EPEL bugzilla tickets. Where may I be able to stop this mess? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: peek package

On Sat, 4 Jan 2020 08:36:07 +0100, Vitaly Zaitsev via devel wrote: > > Which is something you can only fix with an RPM Fusion package, > > if you "control" (= build) all depending packages. > > RPM Fusion will need to copy and rebuild all such packages and this is a > huge headache for maintain

Re: peek package

On Fri, 3 Jan 2020 16:30:54 +0100, Vitaly Zaitsev via devel wrote: > On 03.01.2020 11:14, Michael Schwendt wrote: > > What sort of "huge headache" would that be? > > 1. Most of ffmpeg-capable applications use compile-time checks for > available codecs presence. Whi

Re: peek package

On Fri, 3 Jan 2020 12:14:37 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > I suspect there would be interest in having a royalty free version of > > > > FFMPEG > > > > > > No, please, don't do this. It will be a huge headache for RPM Fusion > > > maintainers. > > > > What sort of "h

Re: peek package

On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote: > On 02.01.2020 10:05, Benson Muite wrote: > > I suspect there would be interest in having a royalty free version of > > FFMPEG > > No, please, don't do this. It will be a huge headache for RPM Fusion > maintainers. What sort

Re: peek package

On Thu, 2 Jan 2020 11:24:08 +, Tom Hughes wrote: > Actually I believe PACKAGENAME-maintainers@ (with an s) is now the > preferred form and -owner is regarded as deprecated. Is this documented _anywhere_? The following page still mentions the -owner alias https://fedoraproject.org/wiki/Infr

Re: peek package

On Thu, 02 Jan 2020 10:02:25 +, Mattia Verga via devel wrote: > In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and > I supposed this would have reached you directly. I did not know this > isn't working anymore (I later received an unreachable address in > reply). So I d

Re: What's up with GStreamer 0.10 in F31?

On Tue, 5 Nov 2019 at 15:07, Fabio Valentini wrote: > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages > > Note that these Guidelines explicitly only apply to *renaming* and > *replacing*existing packages, not the plain removal / retireme

Re: What's up with GStreamer 0.10 in F31?

On Tue, 5 Nov 2019 13:52:00 +0100, Miro Hrončok wrote: > gstreamer was retired > https://src.fedoraproject.org/rpms/gstreamer/c/21fd6753e6c7f1fa1dee1045596b25fdb8c71f37?branch=f31 > > the commit was reverted > https://src.fedoraproject.org/rpms/gstreamer/c/1ce6b77242c27c450179e32a2fc7833300aa8759

What's up with GStreamer 0.10 in F31?

On Wed, 25 Sep 2019 10:45:45 +0200, Kalev Lember wrote: > On 9/24/19 14:50, Michael Catanzaro wrote: > > On Thu, Aug 22, 2019 at 9:04 am, Tom Callaway wrote: > >> or know of some reason it shouldn't be brought back > > > > Well this looks like gstreamer 0.10. I'm really surprised we still hav

Re: Orphaned packages to be retired (~400 during this week)

On Mon, 9 Sep 2019 23:49:17 +0200, Miro Hrončok wrote: > Request package ownership via releng issues: > https://pagure.io/releng/issues How? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedora

Re: Undelivered Mail Returned to Sender

On Sun, 24 Feb 2019 11:50:45 +0100, Dridi Boukelmoune wrote: > >The mail system > > > > (expanded from ): > > connect > > to mail1.ATrpms.net[160.45.254.20]:25: Connection refused > > That's unfortunate, I was hoping to discuss this this the apt-rpm > downstream mainta

Re: Problem with portaudio linking

On Fri, 4 Jan 2019 10:41:46 +0100, Michal Ruprich wrote: > Hi, > > has anyone encountered a problem on F28 when building a package that > uses portaudio? I was building newer version of wireshark a month ago > and -lportaudio worked fine. Now the build with the same version fails > with message '

Re: Self Introduction: J."MUFTI" Scheurich

On Mon, 10 Dec 2018 11:25:55 +0100, J. Scheurich wrote: > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself > > | When a new package maintainer joins the Fedora Project, we request > that he/she introduces > | themselves on the Fedora devel >

Re: please help retire libocrdma

On Tue, 6 Nov 2018 21:48:16 +0800, Honggang LI wrote: > hi, > > libocrdma had been merged into rdma-core in upstream, so libocrdma is > obsoleted by rdma-core. > > The package owner Selvin tried to retire this package, but failed > with authentication. > > We need someone who manages/maintains

Re: Unretire recordmydesktop

On Sun, 4 Nov 2018 12:17:00 +, Richard W.M. Jones wrote: > recordmydesktop was retired in F27: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4RCB6MBC4JVGG4SYLIKUDOOT2REGA6N4/ > > It's claimed that it doesn't work and is full of crash bugs, but I was >

Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

On Wed, 26 Sep 2018 09:20:30 -0600, Nathanael D. Noblet wrote: > I get what I think is a similar error with the google 'Online accounts' > > I get a certificate error. The message is: > > "No SNI provided; please fix your client." > > Would this be a related issue? Yes. If Google hands out cer

Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

On Mon, 24 Sep 2018 11:27:49 +0200, Florian Weimer wrote: > Actually, I assume Google simply made a mistake here. But this is > getting off-topic. As I've mentioned in the Fedora bugzilla ticket, pointing at the gnutls API is not a solution. libetpan upstream would appreciate a pull request.

Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

On Sat, 22 Sep 2018 16:32:07 -0500, mcatanzaro gnome org wrote: > You'll need to add a call to gnutls_server_name_set(), see: > > https://www.gnutls.org/manual/gnutls.html#Server-name-indication That an update for SNI may be required is clear, but it doesn't answer the question where a change wi

Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

On Wed, 18 Jul 2018 17:26:06 -0400, Ben Cotton wrote: > This change enables TLS 1.3 (draft28) support on the gnutls crypto library. > == Upgrade/compatibility impact == > That change should have no impact on upgrade or compatibility. The TLS > 1.3 protocol is designed in a way that does not cause

Re: Nonresponsive maintainer: Luke Macken (lmacken)

On Thu, 16 Aug 2018 16:13:07 +0200, Miro Hrončok wrote: > On 16.8.2018 16:11, Dusty Mabe wrote: > > > > > > On 08/16/2018 07:29 AM, Miro Hrončok wrote: > >> Luke Macken (lmacken) is not responsive. > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1610474 > >> > >> Anyone knows how to cont

Re: Compilation issue after gcc removal

On Fri, 20 Jul 2018 01:08:55 +0200, Marcin Zajączkowski wrote: > On 2018-07-20 00:26, Artur Iwicki wrote: > > I looked at libattr and in the changelog, there's this: > >> * Tue Jul 17 2018 Kamil Dudka 2.4.48-3 > >> - temporarily provide attr/xattr.h symlink until users are migrated > >> (#1601

audiofile package to become an orphan

When I picked up the package in 2015, the upstream maintainer(s) apparently had stopped the maintenance already. Meanwhile, there have been a few CVEs and other fixes that have been ignored upstream. Recently, another CVE has been assigned to an issue, and there isn't any upstream interest either.

  1   2   3   4   5   6   7   8   9   10   >