Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

Dne 04. 12. 20 v 12:36 Marius Schwarz napsal(a): Am 03.12.20 um 21:06 schrieb Ben Cotton: ...changes in default behavior, when 1. technically reasonable and 2. not explicitly overridden by the user, should generally be made on upgrade. Distributions are supposed to be opinionated, and in cases

Re: External (non-rpm) BuidRequires - was New Mock release v2.7

Dne 04. 12. 20 v 0:55 Miro Hrončok napsal(a): On 12/3/20 9:52 AM, Vít Ondruch wrote: Dne 02. 12. 20 v 22:49 Miroslav Suchý napsal(a): Dne 02. 12. 20 v 17:19 Vít Ondruch napsal(a): Why these requires does not follow some standard naming convention possibly with some prefix? What do you mean

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

Dne 03. 12. 20 v 23:26 Petr Šabata napsal(a): Also a couple of notes on modularity here: # By default, module stream name is derived from the branch name If we have any "master" modules, those will get unexpectedly renamed as soon as they get rebuilt. This might impact tagging or updates and ca

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

Dne 04. 12. 20 v 0:43 Miro Hrončok napsal(a): On 12/3/20 7:50 PM, Matthew Miller wrote: As an alternate proposal, what is currently "master" could be moved to "rawhide" and a_new_  "main" branch created explicity to hold just a readme about that package's packaging details (like which branche

Re: External (non-rpm) BuidRequires - was New Mock release v2.7

Dne 02. 12. 20 v 22:49 Miroslav Suchý napsal(a): Dne 02. 12. 20 v 17:19 Vít Ondruch napsal(a): Why these requires does not follow some standard naming convention possibly with some prefix? What do you mean? Like external:python3-foo? Yes, that was the idea. I can imagine, that the reason

Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

Dne 02. 12. 20 v 14:18 Neal Gompa napsal(a): On Wed, Dec 2, 2020 at 8:14 AM Olivier Fourdan wrote: Hi Dominik, On Wed, Dec 2, 2020 at 2:02 PM Dominik 'Rathann' Mierzejewski wrote: Provides: xorg-x11-server-Xwayland = %{version}-%{release} Obsoletes: xorg-x11-server-Xwayland < first-versio

Re: External (non-rpm) BuidRequires - was New Mock release v2.7

Dne 02. 12. 20 v 8:00 Miroslav Suchý napsal(a): Dne 01. 12. 20 v 13:07 Pavel Raiskup napsal(a): I'm pleased to announce that there's a new Mock release. Except for several bugfixes, this release introduces a new "External Build Requires" feature (by Miroslav Suchý) I want to ask you for feedb

Re: Mass spec file change: Adding BuildRequires: make

Dne 01. 12. 20 v 19:35 Tom Stellard napsal(a): On 12/1/20 8:33 AM, Vít Ondruch wrote: Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a): On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote: Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a): False positive because they use gcc

Re: Mass spec file change: Adding BuildRequires: make

Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a): On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote: Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a): False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages

Re: Mass spec file change: Adding BuildRequires: make

Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a): False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ? Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should

Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

Have you considered to keep using the "xorg-x11-server-Xwayland" package name? Vít Dne 30. 11. 20 v 20:05 Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/XwaylandStandalone == Summary == Move Xwayland to a standalone package built from current code upstream rather than the stab

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

Dne 26. 11. 20 v 14:38 Neal Gompa napsal(a): On Thu, Nov 26, 2020 at 8:35 AM Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote: On ke, 25 marras 2020, Tomáš Popela wrote: On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy wrote: Screencast

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

Running Rawhide, I don't think there is a need to postpone this, if the PipeWire and PA are easily swap-able and that should be possible next week as far as I understand your plan. That means everybody will be able to switch back to PA if there are issues. That should be good for Rawhide as wel

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

Dne 24. 11. 20 v 15:22 Vitaly Zaitsev via devel napsal(a): On 24.11.2020 15:15, Vít Ondruch wrote: I think it would be simple enough if there was not the explicit conflict with pulse audio [1]. The instruction could be "Disable PA service and install PW". Absolutely imposs

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a): Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a): Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020: On 22.11.2020 12:36, Dominique Martinet wrote: That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a): Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020: On 22.11.2020 12:36, Dominique Martinet wrote: That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide? Some packages directly depends on the

rubygem-ronn being replaced by rubygem-ronn-ng

Hi, I'd like to announce, that rubygem-ronn, which have not seen release in ages, was retired in Fedora and it is replaced by rubygem-ronn-ng. If you are using Ronn (maintainers of affected packages in BCC), please check your package if it is not FTBFS by a chance. Sorry for not announcing i

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

Dne 16. 11. 20 v 10:22 Zbigniew Jędrzejewski-Szmek napsal(a): On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote: On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý wrote: Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a): If you're going to have this kind of "upstream" spec f

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

Dne 13. 11. 20 v 14:51 Ken Dreyer napsal(a): On Thu, Nov 12, 2020, 4:15 PM Matthew Miller > wrote: On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote: > I still believe that this concept is inherently incompatible with the

Fwd: [Bug 1114146] Review Request: rubygem-ffi-yajl - Ruby FFI wrapper around YAJL 2.x

I wonder what is going to happen next with this review? Will the process continue with the "Submitter_not_responding" policy part [1]? If yes, then when? I actually don't know why the policy was not targeted on both parties at once, because I was certainly the last commenting in the review. BT

Re: What to do with - in release tag?

Maybe follow this guideline? https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde Although it it not clear to me if this is pre-release or post release or what it actually is. Vít Dne 11. 11. 20 v 16:09 Bruno Wolff III napsal(a): I looked

Re: patch applied without package maintainers' approve

Dne 09. 11. 20 v 15:50 Honggang LI napsal(a): On Mon, Nov 09, 2020 at 02:39:22PM +0100, Dominik 'Rathann' Mierzejewski wrote: On Monday, 09 November 2020 at 14:23, Honggang LI wrote: On Mon, Nov 09, 2020 at 08:03:59AM -0500, Neal Gompa wrote: On Mon, Nov 9, 2020 at 8:03 AM Honggang LI wrote:

Orphaned rubygem-json_pure

Hello, I have removed dependencies on rubygem-json_pure from rubygem-morph-cli and rubygem-multi_json, therefore nothing else depended on rubygem-json_pure. There is no real need for rubzgem-json_pure in Fedora, since jruby is long gone and ruby can use the binary rubygem-json, which is more

Re: Packaging rules for build from source vs BPF byte code ?

Dne 05. 11. 20 v 13:03 Daniel P. Berrangé napsal(a): On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote: On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé wrote: In QEMU there's a desire to make use of BPF programs for implementing some networking features. The current patches a

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 19:07 clime napsal(a): On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: Or switch to depend on `%{_bindir}/git`? If we do it like this, we will never be able drop repo download times for Fedora users. Files in %{_bindir} already end up in the primary metadata, don't they?

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 17:55 Miro Hrončok napsal(a): On 11/3/20 5:10 PM, clime wrote: On Tue, 3 Nov 2020 at 15:40, Vít Ondruch wrote: Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: git (amahdal, besser82, chrisw, pcahyna, pstodulk

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) git.src requires cvs git-cvs.noarch requires cvs ( ) req

Re: EOL and Obsoletes in Modularity

Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a): On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: Daniel Mach writes: The API is clear: DNF expects additional 'modulemd-obsoletes' YAML documents in modules.yaml. The new document format is getting into libmodulemd and there's going to b

Re: making download of filelists.xml(.zck) trigger on demand

Dne 01. 11. 20 v 11:58 clime napsal(a): Hello! First of all, I don't really know what I am talking about here but I noticed the `dnf update` operation downloads among other things `filelists.xml` (optionally compressed by zchunk, thanks Jonathan Dieter!!!) and I remember there was a thread on d

Re: GVim issues

"work" machines. Possibly a misbehaving plugin? Could be. I have received new LP today, maybe I should start from scratch and try without plugins. Vít On 10/29/20 11:29 AM, Vít Ondruch wrote: Does anybody experience issues with GVim? It happens quite often, that it stops updating t

GVim issues

Does anybody experience issues with GVim? It happens quite often, that it stops updating the UI. It seems it does something in background (e.g. the mouse cursor is changing and window title updating), but the UI is completely stuck. I am not really sure how to analyze this issue and where to re

Re: Has glibc just removed some symbols?

Dne 26. 10. 20 v 22:36 Adam Williamson napsal(a): On Tue, 2020-10-20 at 08:05 -0600, Jerry James wrote: See https://koschei.fedoraproject.org/package/ocaml-dune?collection=f34 OCaml package builds are suddenly failing because the symbols __xstat64, __fxstat64, and __lxstat64 cannot be found, m

Re: Self Introduction: Davide Cavalca

Dne 29. 10. 20 v 2:32 Michel Alexandre Salim napsal(a): Hi Davide! Welcome on board the packagers group! On Wed, 2020-10-28 at 17:07 -0700, Davide Cavalca via devel wrote: [snip] Myself, Filipe and Michel are kicking off an effort within Facebook to try and get more of our OSS software packa

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

Dne 22. 10. 20 v 18:33 Aleksandra Fedorova napsal(a): On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok wrote: On 10/22/20 2:51 PM, Aleksandra Fedorova wrote: Hi, Vit. On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch wrote: I was asking for ELN branch for ages and it was always denied and there you

Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

I was asking for ELN branch for ages and it was always denied and there you have it [1]. So what is the current stance on this topic? Vít [1] https://src.fedoraproject.org/rpms/gcc/commits/eln Dne 22. 10. 20 v 14:27 Aleksandra Fedorova napsal(a): Hi, all, this is the informational message

Re: glibc troubles in rawhide?

Dne 21. 10. 20 v 9:36 Florian Weimer napsal(a): * Fabio Valentini: I'm pretty sure this is the result of *not* updating glibc. Did you attempt a partial upgrade of rawhide, restricting the package set during an update? I cannot reproduce this: In the current compose and buildroot,

Re: intending to retire thunderbird-enigmail in F34+

As a Rawhide use, who is effectively F34 user already, I'd appreciate if you retired the thunderbird-enigmail in F35+ or mabybe just wait a bit longer. This is good candidate for inclusion in fedora-obsolete-packages BTW. OTOH I'll soon update also my other computer and won't care anymore ;) Vít

Re: Where did my keys go in Thunderbird?

@Zdeněk, thx for the tip. And if you wonder like my why you cannot see the menu item, them the reason might be you are using thunderbird-enigmail installed from Fedora, which is 2.1.x version. But you need to install Engimail 2.2.x from Mozilla addons to have this functionality available, unless t

Re: Fwd: Orphaned packages of skisela

Dne 03. 10. 20 v 17:41 Andy Mender napsal(a): > On Fri, 2 Oct 2020 at 11:53, Vít Ondruch <mailto:vondr...@redhat.com>> wrote: > > Hi, > > I was in contact with Sebastian, who used to work for RH and > maintained several Fedora packages. However, due to ch

Fwd: Fwd: Orphaned packages of skisela

práva Předmět:Fwd: Orphaned packages of skisela Datum: Fri, 2 Oct 2020 11:48:32 +0200 Od: Sebastián Kisela Komu: Vít Ondruch -- Forwarded message - From: mailto:devel-ow...@lists.fedoraproject.org>> Date: Fri 2. Oct 2020 at 11:32 Subject: Orphaned packages of

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

Dne 01. 10. 20 v 0:10 Michael Catanzaro napsal(a): > On Wed, Sep 30, 2020 at 11:49 pm, Björn Persson > wrote: >> So there's no need to revert any changes to /etc/nsswitch.conf? I've >> seen some discussion about that file in relation to systemd-resolved. >> It seemed far from easy to understand h

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

es, simple workaround via symlink is available until the >>> problems will be solved, so I see no reason for ignoring this problem. >>> >>> On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: >>> >>>> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): &g

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

Dne 28. 09. 20 v 18:03 Michael Catanzaro napsal(a): > On Mon, Sep 28, 2020 at 10:51 am, Ian Pilcher > wrote: >> I anticipated this question.  I don't have a good proposal for you ... >> but I believe that it's up to the people advocating/implementing this >> change to come up with that.  If it is

Re: Self Introduction: Ruki Wang

Hello and welcome! All information necessary to become Fedora packager should be available on this page: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers There is also Fedora Join SIG, which can help you with onboarding: https://docs.fedoraproject.org/en-US/fedora-join/ind

Re: Orphaned packages looking for new maintainers

Dne 22. 09. 20 v 10:47 Miro Hrončok napsal(a): > On 22. 09. 20 10:29, Michael J Gruber wrote: >>> Dne 21. 09. 20 v 18:37 Michael J Gruber napsal(a): >>> >>> >>> No, please not! It is just build dependency. I have orphaned the >>> package >>> to have it removed from Fedora. May be I should have ret

Re: Orphaned packages looking for new maintainers

Dne 21. 09. 20 v 18:37 Michael J Gruber napsal(a): >> The following packages are orphaned and will be retired when they >> are orphaned for six weeks, unless someone adopts them. If you know for sure >> that the package should be retired, please do so now with a proper reason: >> https://fedorapro

Re: Orphaned packages looking for new maintainers

Dne 21. 09. 20 v 14:39 Miro Hrončok napsal(a): > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know > for sure > that the package should be retired, please do so now with a proper > reason: > https://fedoraproject

Re: Shouldn't we have process for removing zombie packages?

Dne 18. 09. 20 v 12:37 Petr Pisar napsal(a): > On Fri, Sep 18, 2020 at 10:42:00AM +0200, Vít Ondruch wrote: >> This is not about nagging maintainer for the purpose of nagging them. >> > Filing the requests en mass is exactly nagging for nagging. This might be misunderstanding

Re: Shouldn't we have process for removing zombie packages?

Dne 18. 09. 20 v 10:24 Petr Pisar napsal(a): > On Thu, Sep 17, 2020 at 09:09:51PM +0200, Vít Ondruch wrote: >> Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a): >>> Well, many maintainers don't touch packages that keep working and don't >>> need updates or bugf

Re: Shouldn't we have process for removing old packages?

Dne 17. 09. 20 v 18:29 Kevin Fenzi napsal(a): > On Thu, Sep 17, 2020 at 12:39:28PM +0200, Vít Ondruch wrote: >> Looking at rubygem-sinatra-rabbit [1], I wonder if we should not have >> process for removing "zombie" packages. >> >> The issue with this package i

Shouldn't we have process for removing old packages?

Looking at rubygem-sinatra-rabbit [1], I wonder if we should not have process for removing "zombie" packages. The issue with this package is that while it keeps building, it is very likely not working. The `%check` suite is disable for ages already. Upstream is dead. I know I could open BZ questio

Orphaning rubygem-erubis

Hi, I have orphaned rubygem-erubis. It is dead upstream for almost 10 years and it is FTBFS with every major version of Ruby. There is available rubygem-erubi, which is properly maintained and most of the projects already switched. The only remaining dependency in Fedora is rubygem-asciidoctor, wh

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 15:01 Vít Ondruch napsal(a): > Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a): >> On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote: >>> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): >>>> On Mon, Sep 14, 2020 at 09:50

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 12:03 Pierre-Yves Chibon napsal(a): > On Mon, Sep 14, 2020 at 10:35:18AM +0200, Vít Ondruch wrote: >> Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): >>> On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: >>>> Reading th

Re: Proposing an EPEL packaging SIG

Dne 14. 09. 20 v 10:11 Zbigniew Jędrzejewski-Szmek napsal(a): > On Mon, Sep 14, 2020 at 09:50:45AM +0200, Vít Ondruch wrote: >> Reading this proposal and with the EPEL8 experience, where there was not >> even wiki page, where I could state that I don't care about EPEL and I

Re: Proposing an EPEL packaging SIG

Reading this proposal and with the EPEL8 experience, where there was not even wiki page, where I could state that I don't care about EPEL and I had to reply into every BZ independently, wouldn't it make sense to move EPEL into its own dist-git namespace? I guess that in the CVS days, having EPEL b

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): > * Tom Hughes via devel: > >> On 11/09/2020 07:13, Ondrej Dubaj wrote: >> >>> There seemed to be no big reason for moving the libraries to the >>> main package in the past, so I consider f34 as a good candidate for >>> such a change. It would be gre

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

Dne 10. 09. 20 v 17:32 Michael Catanzaro napsal(a): > > On Thu, Sep 10, 2020 at 9:24 am, Vít Ondruch wrote: >> Hi Michael, >> >> Could you please provide more details? This is content of my >> nsswitch.conf: >> >> >> ~~~ >> >> $ gr

Re: The Future of the Java Stack (also regarding ELN and RHEL)

Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a): > > > On 9/11/20 10:16 AM, Mikolaj Izdebski wrote: > >> Another, more concrete example: core Ant doesn't have any dependencies >> beyond JDK. It is easy to build and maintain, yet very functional. On >> the other hand, full Ant with all the optional

Re: The Future of the Java Stack (also regarding ELN and RHEL)

Dne 11. 09. 20 v 8:43 Petr Pisar napsal(a): > On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote: >> For Maven packaging the appeal of Modularity is clearly the privatization of >> the dependency tree, which obviously undercuts the ecosystem of packages. >> > You are right

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

Hi Michael, Could you please provide more details? This is content of my nsswitch.conf: ~~~ $ grep mdns4_minimal /etc/authselect/user-nsswitch.conf hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname ~~~ How that happened? From what version of what package it happened? Why should

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

Generally, I would appreciate if the proposal was more readable to casual Fedora user/developer. I don't think there is clearly described the current state and what is going to be changed. Also, there is a lot of unclear terminology, e.g. I don't have idea what are "LSM hooks". "Migrate users to us

Re: Non-responsive maintainer: domcleal

Dne 02. 09. 20 v 17:19 Robbie Harwood napsal(a): > Vít Ondruch writes: > >> Hi Robbie, >> >> I wonder if you had some intentions with the packages, > If you're asking if I plan to take them, I do not. Thx for clarification. Since the first ticket was rubygem- it

Re: Non-responsive maintainer: domcleal

ll maintainers might be interested to take over your rubygem-terminal-table, because this is the dependency chain: rubygem-unicode-display_width <= rubygem-terminal-table <= rubygem-jekyll Vít > > --Greg > > On Wed, Sep 2, 2020 at 3:38 AM Vít Ondruch <mailto:vondr...@redh

Re: Fedora 33 blocker status

Dne 01. 09. 20 v 19:54 Tom Hughes via devel napsal(a): > On 01/09/2020 18:29, kevin wrote: > >> Just to make sure folks know, the retrace server being down is not this >> teams fault, it's ours (infrastructure). We planned to just have it down >> for a week or less when moving it to RDU, but it tu

Re: Non-responsive maintainer: domcleal

Hi Robbie, I wonder if you had some intentions with the packages, be cause at lest the 3 down bellow looks to be required by other packages and they are now in danger of being removed from Fedora. Adding on CC Pavel, Dan and Greg who might be interested in some of them. Vít Dne 01. 09. 20 v 2

Re: [HOWTO] Keep using Rawhide after branching

Dne 28. 08. 20 v 19:09 Adam Williamson napsal(a): > On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote: >> Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a): >>> No, unfortunately the key is there, but the package is incomplete. >>> >>> If you have enabled gpg si

Re: [HOWTO] Keep using Rawhide after branching

; 1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76 > 2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77 > > > On 8/25/20 12:16 PM, Vít Ondruch wrote: >> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a): >>> Hi Vít, >>> >>> Unfortun

Re: Does ELN SIG have some issue tracker?

Dne 25. 08. 20 v 19:09 Aleksandra Fedorova napsal(a): > Hi, Vit, > > On Tue, Aug 25, 2020 at 11:21 AM Vít Ondruch wrote: >> Looking at the ELN SIG page [1], there is no contact information, no ML, >> no issue tracker. I would like to discuss bootstrapping issues such as &g

Re: [HOWTO] Keep using Rawhide after branching

ould work, followed by normal upgrade. > > Filled bug #1872248 for it. It should finally work without user even > fiddling with gpg keys manually. Is there some pressure to keep users > from using rawhide? > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248 > > On 8

Does ELN SIG have some issue tracker?

Looking at the ELN SIG page [1], there is no contact information, no ML, no issue tracker. I would like to discuss bootstrapping issues such as [2], but there is no place to provide any feedback. Is this group working under cover? (Using the minimization tracker [3], where a lot of ELN stuff appea

Re: Proposed Modular Policy for Fedora ELN

Dne 20. 08. 20 v 20:17 Stephen Gallagher napsal(a): > > However, ELN has a mission to be a bridge to future RHEL and that > distribution has committed to default streams as a business necessity > for multiple reasons (among them support lifecycle which is much > harder to address via non-modular c

Orphaned rubygem-dealayed_job{,_active_record}

Hi, I don't have any use for rubygem-dealayed_job and rubygem-dealayed_job_active_record, therefore I orphaned them. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora

Re: Very strange compiler/linker related build failures in rawhide

Hi Jeff, Dne 27. 07. 20 v 14:28 Vít Ondruch napsal(a): > Dne 27. 07. 20 v 12:25 Vít Ondruch napsal(a): >> Dne 24. 07. 20 v 21:01 Jeff Law napsal(a): >>> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote: >>>> The LTO break Ruby on various p

Orphaned rubygem-{rubypants,org-ruby}

Hi, I have orphaned rubygem-rubypants and rubygem-org-ruby, because I have not any use for these. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: h

[HOWTO] Keep using Rawhide after branching

Just as a reminder to all Rawhide users, this is the easiest way to keep using Rawhide after branching: ~~~ $ sudo dnf update fedora-gpg-keys $ sudo dnf update fedora-repos --release 34 ~~~ Unfortunately, there has been no progress on [1] during past months. Vít  [1] https://pagure.io/

Re: failed to do fedpkg import

Dne 16. 08. 20 v 15:53 Fabio Valentini napsal(a): > > Also I'm not sure why you're running import again, when the package > already exists. `import` is the best way how to upload sources + add/remove patches from dist-git. I would suggest everybody to `import` instead of `new-sources`/`upload`.

Re: A few questions about rpmdev-bumpspec tool

Dne 13. 08. 20 v 12:41 Qiyu Yan napsal(a): > Hello all, > > I have some problem with rpmdev-bumpspec recently. > > 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 according

Re: LTO and the F33 mass rebuild

Dne 11. 08. 20 v 18:43 Kevin Fenzi napsal(a): > On Sun, Aug 09, 2020 at 10:06:49PM -0600, Jeff Law wrote: >> On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote: >>> On Sun, Aug 9, 2020 at 12:03 AM Jeff Law wrote: So I've done two passes over the F33 build failures here: https

Orphaned rubygem-wikicloth

Hi everybody, I don't have any use for rubygem-wikicloth, therefore I orphaned the package. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https:/

Re: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

Dne 06. 08. 20 v 11:26 Aleksandra Fedorova napsal(a): > Hi, > > On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski wrote: >> So, I'm getting one of these messages every couple of hours and I'd >> really rather not. Who do I need to talk to about it? > You can talk about it with the ELN SIG [1] or Fe

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

Dne 04. 08. 20 v 21:38 Michael Catanzaro napsal(a): > On Tue, Aug 4, 2020 at 10:31 am, Chris Murphy > wrote: >> Should we go back to the old workaround for F33? Madness for one more >> release? And then drop the madness once there's a dnf solution? > > We could, but we have installed so many othe

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

Dne 04. 08. 20 v 20:58 Vitaly Zaitsev via devel napsal(a): > On 04.08.2020 16:45, Vít Ondruch wrote: >> I think the "don't use autoremove" is better suggestion ATM, because I >> don't really want to keep earlyoom on the system in case there is >> systemd

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

Dne 04. 08. 20 v 16:05 Vitaly Zaitsev via devel napsal(a): > On 04.08.2020 15:48, Michael Catanzaro wrote: >> In the meantime, if you want to keep earlyoom, don't use autoremove. > sudo dnf mark install earlyoom > I think the "don't use autoremove" is better suggestion ATM, because I don't really

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

Yesterday, I have updated my Rawhide and wondered why `dnf autoremove` would want to remove earlyoom just to discover that soft dependency in earlyoom was dropped [1] and hence nothing requires earlyoom and DNF is free to remove this package (and it is possibly not installed anymore on upgraded sys

Re: Fedora 33 Mass Rebuild

Mohan, Could you please check the script filling out the FTBFS tickets is doing the right thing? There was reported this ticket against Ruby: https://bugzilla.redhat.com/show_bug.cgi?id=1865667 But I have rebuild Ruby already on Friday 31st: https://koji.fedoraproject.org/koji/buildinfo?buildI

Re: module build: BuildrootError: could not init mock buildroot

Dne 02. 08. 20 v 0:21 Kevin Fenzi napsal(a): > On Fri, Jul 31, 2020 at 04:05:20PM +0200, Jun Aruga wrote: >> Hi, >> Sometimes once per a few times, I faced the following weird build >> error when building Ruby modules. >> Did you see it? Known issue? >> >> https://koji.fedoraproject.org/koji/task

Re: Minimal Mock's buildroot

Quite some stuff from the list are "soft" dependencies of rpmbuild, e.g. the compression algorithms. May be we should have discussion if we should have BR on the decompression library, or if the BR could be autogenerated. Vít Dne 02. 08. 20 v 22:06 Miroslav Suchý napsal(a): > As part of > ht

Orphaned rubygem-fast_gettext

Hi, I have orphaned rubygem-fast_gettext, because I have no use for it, neither anything else depends on it. VĂ­t ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of

Orphaning ruby-ldap

I don't have any use for ruby-ldap package. It is not in the best condition. While it probably works, it does not follow the best practices and it would deserve to be replaced by rubygem-ldap if somebody considering to keep it in Fedora. Anyway, I have orphaned it. VĂ­t _

Re: Very strange compiler/linker related build failures in rawhide

Dne 27. 07. 20 v 12:25 Vít Ondruch napsal(a): > Dne 24. 07. 20 v 21:01 Jeff Law napsal(a): >> On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote: >>> The LTO break Ruby on various platforms. >>> >>> >>> https://koji.fedoraproject.org/koji/task

Re: List of long term FTBFS packages to be retired in August

Dne 26. 07. 20 v 13:44 Miro Hrončok napsal(a): > On 29. 06. 20 17:49, Vít Ondruch wrote: >> Dne 29. 06. 20 v 17:21 Miro Hrončok napsal(a): >>> js-jquery1 nodejs-sig, patches, vondruch   Fedora 30 >>> js-jquery2 vondruch

Re: Very strange compiler/linker related build failures in rawhide

Dne 24. 07. 20 v 21:01 Jeff Law napsal(a): > On Fri, 2020-07-24 at 20:52 +0200, Vít Ondruch wrote: >> The LTO break Ruby on various platforms. >> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573 >> >> vs >> >> https://k

Re: Very strange compiler/linker related build failures in rawhide

The LTO break Ruby on various platforms. https://koji.fedoraproject.org/koji/taskinfo?taskID=47582573 vs https://koji.fedoraproject.org/koji/taskinfo?taskID=47621733 (Note these are my experimental builds testing single test case). The only difference is redhat-rpm-config 162-1.fc33 => 163-1

Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

Just FTR, I don't think I am going to reveal too much saying that for RHEL9, the sentiment is (at least in the context of Ruby, Node.js and Python) that we are very likely not going to use default streams. Plain old RPMs do mostly the same job. In this context, I'd be more than happy if the docume

Re: Modularity Improvements Objective

Dne 24. 07. 20 v 14:25 Petr Pisar napsal(a): > On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote: >> There's a Modularity Improvements Objective draft available[1]. >> >> The Objective summarizes the work that is in progress already as well as >> highlights our plans for Fedora 34. >> >>

Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

Dne 22. 07. 20 v 14:55 Stephen Gallagher napsal(a): > On Mon, Jul 13, 2020 at 1:06 PM Vít Ondruch wrote: >> Is this just about the specific URL or also about the "Naming Policy"? > The Naming Policy is not currently under discussion in this proposal. > Only the U

Re: Fedora in 6th gear

Thx to everybody who submitted the change proposal. It is nice that people follow the process instead of just pushing something into Fedora without sharing with wider audience. Vít Dne 16. 07. 20 v 19:52 Zbigniew Jędrzejewski-Szmek napsal(a): > In the FESCo meeting summary email sent out today

Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

Is this just about the specific URL or also about the "Naming Policy"? I am asking, because I already had a lot of arguments about the branching on this list and various different places but this guideline still insist that "using upstream major versions as branches is recommended". This is not ac

Re: List of long term FTBFS packages to be retired in August

r for node packaging. Sorry. Vít Dne 02. 07. 20 v 13:42 Alexandre de Farias napsal(a): > In fact, I am not at this time. > > On Wed, 2020-07-01 at 15:38 +0200, Vít Ondruch wrote: >> Hi Alexandre, >> >> Thank you for your offer. I just wonder, are you sponsored in

<    2   3   4   5   6   7   8   9   10   11   >