[Bug 1921396] perl-MooseX-Getopt-0.74-6.el8 cant be installed on RHEL8

https://bugzilla.redhat.com/show_bug.cgi?id=1921396 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value ---

Re: Proposal to deprecated `fedpkg local`

Hello, On 27.01.21 17:17, Vít Ondruch wrote: I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? For me even a step further: I

[389-devel] 389 DS nightly 2021-01-28 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/28/report-389-ds-base-2.0.2-20210128git827773829.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[Bug 1921533] New: perl-JSON-Path-0.430 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1921533 Bug ID: 1921533 Summary: perl-JSON-Path-0.430 is available Product: Fedora Version: rawhide Status: NEW Component: perl-JSON-Path Keywords: FutureFeature, Triaged

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On 27. 01. 21 19:30, Kevin Fenzi wrote: On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote: On 1/26/21 8:44 PM, Kevin Fenzi wrote: So, the thread here kind of fell quiet with everything else going on. It seems clear there's issues to address here before this change might get

Fedora-Rawhide-20210127.n.1 compose check report

Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 30/181 (x86_64), 28/123

[Bug 1920399] perl-Log-Report-1.32 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1920399 --- Comment #6 from Fedora Update System --- FEDORA-2021-2cbaca83c9 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing

[Bug 1920399] perl-Log-Report-1.32 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1920399 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from

Testing lua-filesystem 1.8.0

Hi all, lua-filesystem has not been properly updated since 2015; we missed the 1.7.0 release in 2017 and the 1.8.0 release in April last year. The changelogs seem to indicate this should be backward-compatible, but if your package depends on the `lfs` module please test: F32

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On Wed, 2021-01-27 at 10:25 -0800, Kevin Fenzi wrote: > On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim > wrote: > > On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote: > > > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote: > > > > But that would involve at

Orphaning my ocaml packages

Hi all, I've not been using Ocaml recently, and have not been able to give these packages the attention they deserve. I'll be orphaning them; in all cases there's only exactly one comaintainer (Ding-Yi Chen) so they'll be the primary maintainer going forward. rpms/ocaml-biniou rpms/ocaml-cppo

[Bug 1921396] New: perl-MooseX-Getopt-0.74-6.el8 cant be installed on RHEL8

https://bugzilla.redhat.com/show_bug.cgi?id=1921396 Bug ID: 1921396 Summary: perl-MooseX-Getopt-0.74-6.el8 cant be installed on RHEL8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-MooseX-Getopt

Re: Mass rebuild failures on s390

On Wed, Jan 27, 2021 at 10:15:20PM +, Richard W.M. Jones wrote: > Here are a couple of my packages which failed mass rebuild > because of apparent problems with the s390 builder: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709 > >

Re: COMMERCIAL - Bosch - Architect

George Bastin writes: Sorry Marius, it is not a violation of any law. Right. By the way, banning everyone from an organization from using a mailing list: that's not a violation of any law, either. It would also not be a violation of any law to notify administrators of other mailing lists

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 4:17 PM, Richard W.M. Jones wrote: > On

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated > the `fedpkg local` command. I don't think it should be used. Mock > should be the preferred way. Would there be anybody really missing > this functionality?

Mass rebuild failures on s390

Here are a couple of my packages which failed mass rebuild because of apparent problems with the s390 builder: https://koji.fedoraproject.org/koji/taskinfo?taskID=60560709 https://koji.fedoraproject.org/koji/taskinfo?taskID=60560418 Could we automatically look for builds which fail this way and

Re: Proposal to deprecated `fedpkg local`

On 1/27/21 2:04 PM, Otto Urpelainen wrote: > The other option of not using 'git add .' can also be described as > mentally filtering out all the irrelevant unstaged changes to find the > ones that should actually be added. That adds cognitive burden, slows > things down and leads to mistakes

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 4:04 PM, Otto Urpelainen wrote: > Gwyn

Re: Proposal to deprecated `fedpkg local`

On Wed, 2021-01-27 at 17:17 +0100, Vít Ondruch wrote: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? Sorry I

Re: Proposal to deprecated `fedpkg local`

Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40: ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch wrote: Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a): Question; What problem would be solved by removing fedpkg local that isn't addressed

Re: Proposal to deprecated `fedpkg local`

+1 to everything that Gwyn said. 'fedpkg local' is just so immensely useful for initial package developement. I also use it a lot for systemd & friends: I *want* to build packages against the local environment and install them locally without pulling in any other package updates, and I want to

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 9:17 AM Vít Ondruch wrote: > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? Seems like this is a

Re: Proposal to deprecated `fedpkg local`

Vít Ondruch writes: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should > be the preferred way. Would there be anybody really missing this > functionality? I would miss it. It's nontrivially

Re: Proposal to deprecated `fedpkg local`

Vít Ondruch wrote: > I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg > local` command. I don't think it should be used. Mock should be the preferred > way. Would there be anybody really missing this functionality? Mock is waaay overkill a lot of the time. It's a

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote: > On 1/26/21 8:44 PM, Kevin Fenzi wrote: > > So, the thread here kind of fell quiet with everything else going on. > > > > It seems clear there's issues to address here before this change might > > get approved. Here's my list: > >

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim wrote: > On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote: > > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote: > > > But that would involve at least six new steps that would've to be > > > automated: 1)

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On Wed, Jan 27, 2021 at 01:26:17PM +0100, Petr Menšík wrote: > What about ability to opt-in into %prep checking on push? > Could we add some new rules to gating.yaml for example, allowing few > checks on push? If it's something that runs locally before accepting the commit, I think that would be

Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories

On Wed, Jan 27, 2021 at 10:47:07AM +0100, Kamil Paral wrote: > On Tue, Jan 26, 2021 at 7:06 PM Kevin Fenzi wrote: > > > > Adding normal packages are requirements for a devel package just to make > > it > > > multilib feels... unclean? Perhaps I'm misunderstanding something. In > > order > > > to

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should > be the preferred way. Would there be anybody really missing this > functionality? For what

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a): Hi, This would describe my usual workflow as well. fedpkg local is great for checking soname did not change, patches apply, to debugging why my test suites fail and how they behave. mock usual does not have even vim You have vim on your host with

Intention to orphan brutalchess and stockfish packages

Hi, unfortunately there's not enough available time for me to actively maintain gaming packages. As I'm more and more loosing interest in gaming especially with Linux (preferences clearly go into mobile gaming) I decided to orphan two of my long standing packages. . brutalchess - chess game -

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 10:18 AM Vít Ondruch wrote: > > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? > I would

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:00:42PM +0100, Vít Ondruch wrote: > > Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a): > > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: > > > Hi, > > > > > > I wonder, what would be the sentiment if I proposed to deprecated the > > > `fedpkg local`

Re: Proposal to deprecated `fedpkg local`

Hi, This would describe my usual workflow as well. fedpkg local is great for checking soname did not change, patches apply, to debugging why my test suites fail and how they behave. mock usual does not have even vim, let alone gdb or something better. In other words, i use fedpkg local a lot and

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 04:43:35PM +, Daniel P. Berrangé wrote: > On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote: > > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel > > wrote: > > > > > > It's needed for testing builds against versions of packages not yet in > > >

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:33:30PM +0100, Vít Ondruch wrote: > > Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a): > > > > Question; What problem would be solved by removing fedpkg local that isn't > > addressed by documentation? > > > > It would ensure, that people are using stable and

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch wrote: > Dne 27. 01.

[Bug 1921203] perl-Graph-0.9717 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1921203 --- Comment #1 from Upstream Release Monitoring --- Skipping the scratch build because an SRPM could not be built: ['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-jvm43ph4/perl-Graph.spec'] returned 1: b'error:

[Bug 1921203] New: perl-Graph-0.9717 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1921203 Bug ID: 1921203 Summary: perl-Graph-0.9717 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Graph Keywords: FutureFeature, Triaged

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a): Question; What problem would be solved by removing fedpkg local that isn't addressed by documentation? It would ensure, that people are using stable and predictable environment for Fedora development, keeping their system intact.

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:26 AM, Vít Ondruch wrote: > Dne 27. 01.

dropping selinux-policy strict version requirement

Hi folks, Many applications ship their own "-selinux" sub-package. These subpackages usually set a minimal dependency on the exact selinux-policy version in the buildroot. In Ceph's case, we have: Requires(post): selinux-policy-base >= %{_selinux_policy_version} This version requirement

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:10 AM, Fabio Valentini wrote: > On Wed,

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 17:57 Gwyn Ciesla via devel napsal(a): -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:16 AM, Vít Ondruch wrote: > Dne 27. 01.

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 18:03 Gwyn Ciesla via devel napsal(a): -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 17:59 Colin Walters napsal(a): On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch wrote: You can do this in mock without messing with your system. You can use `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command you want to use`. You can use `mock your.srpm

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 6:04 PM Gwyn Ciesla via devel wrote: > Great! And you can keep doing that! That's a good thing to have. fedpkg local > also works without network access, like on a train, if you have all your > BuildRequires in place. If that's all you want, why not use plain rpmbuild

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 11:00 AM, Vít Ondruch wrote: > Dne 27. 01.

Re: Proposal to deprecated `fedpkg local`

Actually, I forgot `mock --enablerepo=local some.srpm` which download the freshest packages for the build root directly from Koji. Vít Dne 27. 01. 21 v 17:50 Vít Ondruch napsal(a): You can do this in mock without messing with your system. You can use `mock -i some.rpm`, you can even use

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a): On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch wrote: > You can do this in mock without messing with your system. You can use > `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf > command you want to use`. You can use `mock your.srpm > --short-circuit=install` and similar. You

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch wrote: > You can do

Re: Proposal to deprecated `fedpkg local`

On Wed, 27 Jan 2021 16:43:35 + Daniel P. Berrangé wrote: > On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote: > > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel > > wrote: > > > > > > It's needed for testing builds against versions of packages not yet in > > > mock. I

Re: Proposal to deprecated `fedpkg local`

You can do this in mock without messing with your system. You can use `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command you want to use`. You can use `mock your.srpm --short-circuit=install` and similar. You can use `mock shell --unpriv` if you want to tinker more. Mock

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote: > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel > wrote: > > > > It's needed for testing builds against versions of packages not yet in > > mock. I use it almost every day. Losing it would make things like testing > >

[Bug 1921174] New: perl-Mojolicious-8.72 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1921174 Bug ID: 1921174 Summary: perl-Mojolicious-8.72 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote: > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be the > preferred way. Would there be anybody really missing this functionality?

Re: Proposal to deprecated `fedpkg local`

"fedpkg local lets me cycle through build failures faster in the early stages" Totally agree. On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel < devel@lists.fedoraproject.org> wrote: > > > > -- > Gwyn Ciesla > she/her/hers > > in your fear,

Re: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote: > https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List I have updated https://fedoraproject.org/wiki/Mailing_list_guidelines#Commercial_messages to be more clear. -- Matthew Miller Fedora Project

Re: Proposal to deprecated `fedpkg local`

--  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 27, 2021 10:27 AM, Fabio Valentini wrote: > On Wed,

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel wrote: > > It's needed for testing builds against versions of packages not yet in mock. > I use it almost every day. Losing it would make things like testing solib > bumps harder. I've done local test builds for soname bumps and similar

Re: Proposal to deprecated `fedpkg local`

It's needed for testing builds against versions of packages not yet in mock. I use it almost every day. Losing it would make things like testing solib bumps harder. --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 5:17 PM Vít Ondruch wrote: > > Hi, > > I wonder, what would be the sentiment if I proposed to deprecated the > `fedpkg local` command. I don't think it should be used. Mock should be > the preferred way. Would there be anybody really missing this functionality? I would

Proposal to deprecated `fedpkg local`

Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Vít OpenPGP_signature Description: OpenPGP digital signature

RE: COMMERCIAL - Bosch - Architect

Sorry Marius, it is not a violation of any law. You address is on a public mailing list, which anyone in the world can contact. I apologise if any offence was caused. -Original Message- From: PGNet Dev Sent: 27 January 2021 16:06 To: fedora...@cloud-foo.de;

Re: COMMERCIAL - Bosch - Architect

And you're spamming MY 'private mailbox' now? Who made you the consumer police? Now, get lost, troll. On 1/27/21 11:01 AM, Marius Schwarz wrote: Am 27.01.21 um 16:53 schrieb PGNet Dev: And that somehow justifies 'notifying the legal department' as a 1st response? Yeap, because he spammed

[Bug 1915252] perl-Tie-Cycle-1.226 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1915252 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC|

Summary/Minutes from today's FESCo Meeting (2021-01-27)

= #fedora-meeting-2: FESCO (2021-01-27) = Meeting started by King_InuYasha at 15:01:56 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-27/fesco.2021-01-27-15.01.log.html .

Re: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 10:53:52AM -0500, PGNet Dev wrote: > And that somehow justifies 'notifying the legal department' as a 1st response? No. I agree that that's an overreaction. -- Matthew Miller Fedora Project Leader ___ devel mailing list --

[EPEL-devel] Re: RHEL contacting EPEL maintainers when package goes into RHEL

On 20. 01. 21 15:27, Troy Dawson wrote: This last week in the EPEL Steering Committee meeting, we talked about what happens when an EPEL package gets pulled in and released in RHEL. There were a couple of people who said that had happened to them and they were totally un-aware that it was going

Re: COMMERCIAL - Bosch - Architect

On 1/27/21 10:44 AM, Matthew Miller wrote: On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote: I thought it was a public mailing list, I noted the subject was Commercial in the Header as stated on the Fedora Guidelines:

Re: COMMERCIAL - Bosch - Architect

On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote: > I thought it was a public mailing list, I noted the subject was Commercial > in the Header as stated on the Fedora Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List That paragraph

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On Wed, Jan 27, 2021 at 2:14 AM Pavel Raiskup wrote: > > On Tuesday, January 26, 2021 9:46:49 PM CET Neal Gompa wrote: > > Yes. This is breaking *everything*. Regardless of whether the plugin > > is installed, RPM now thinks the generated packages are invalid and > > cannot do anything with them.

Solved: new koji problem: 404 errors on downloadlinks

Am 27.01.21 um 16:29 schrieb Marius Schwarz: https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm which just retruns a 404: $ curl -I http://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

On Wed, Jan 27, 2021 at 10:48:46AM +0200, Panu Matilainen wrote: > And this would be on EVERYBODY's database whether you use the > feature or not, also slowing down every single rpm query somewhat as > a whole lot more data has to be pulled from disk, and there's no way > to get rid of the weight

RE: COMMERCIAL - Bosch - Architect

Apologies Marius I thought it was a public mailing list, I noted the subject was Commercial in the Header as stated on the Fedora Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List However, going out of your way to try to sabotage another person’s

new koji problem: 404 errors on downloadlinks

The new firefox build 85.0.4 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1680475 offers this link: https://kojipkgs.fedoraproject.org//packages/firefox/85.0/4.fc32/x86_64/firefox-85.0-4.fc32.x86_64.rpm which just retruns a 404: $ curl -I

Re: COMMERCIAL - Bosch - Architect

Am 27.01.21 um 15:37 schrieb Stephen John Smoogen: The following is an official statement. This list is NOT meant for these sorts of emails. Please do not post either CV or requests for hiring on this list. We will be deleting all further posts in this vein The legal departement of Bosch

[Bug 1921135] New: Upgrade perl-Test-Inline to 2.214

https://bugzilla.redhat.com/show_bug.cgi?id=1921135 Bug ID: 1921135 Summary: Upgrade perl-Test-Inline to 2.214 Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Inline Assignee: rc040...@freenet.de

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 1/27/21 2:22 PM, Miro Hrončok wrote: > On 27. 01. 21 13:45, Petr Menšík wrote: >> I think one reason against maintainer's pull requests is poor tooling to >> work with them. Filled fedpkg proposal to include ability to fork and >> add personal fork to current repository or add when cloning

Schedule for Wednesday's FESCo Meeting (2021-01-27)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-01-27 15:00 UTC' Links to all issues to

Re: COMMERCIAL - Bosch - Architect

The following is an official statement. On Wed, 27 Jan 2021 at 09:10, George Bastin wrote: > Dear colleagues at Fedora, > > > > I am hoping to discuss a *Senior Security and Systems > Architect/Engineering* opportunity I am working on directly with *Robert > Bosch Car Multimedia GmbH* with you!

Python Classroom Lab help needed: proj-data is suddenly 569M

Hello, when debugging an unexpected significant file size grow of the Python Classroom Lab [1], I've realized the following package changes since Fedora 33: proj -proj-datumgrid +proj-data-at +proj-data-au +proj-data-be +proj-data-br +proj-data-ca +proj-data-ch +proj-data-de +proj-data-dk

Python Classroom Lab help needed: proj-data is suddenly 569M

Hello, when debugging an unexpected significant file size grow of the Python Classroom Lab [1], I've realized the following package changes since Fedora 33: proj -proj-datumgrid +proj-data-at +proj-data-au +proj-data-be +proj-data-br +proj-data-ca +proj-data-ch +proj-data-de +proj-data-dk

Re: COMMERCIAL - Bosch - Architect

Hello May you consider my cv https://www.hdfilm.kz/cv.pdf Отправлено с iPhone > 27 янв. 2021 г., в 20:09, George Bastin > написал(а): > >  > Dear colleagues at Fedora, > > I am hoping to discuss a Senior Security and Systems Architect/Engineering > opportunity I am working on directly

COMMERCIAL - Bosch - Architect

Dear colleagues at Fedora, I am hoping to discuss a Senior Security and Systems Architect/Engineering opportunity I am working on directly with Robert Bosch Car Multimedia GmbH with you! The position has a strong focus on Open Source Technologies, and Bosch need someone who is highly skilled

Container Plumbing Days call for speakers.

Announcing Free Open Source Micro Virtual Conference `Container Plumbing Days` sponsored byRed Hat. March 9-10, 2021. Looking for speakers. Low level talks, from the container engine down to the OS. Not orchestrators. http://containerplumbing.org/

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 27. 01. 21 13:45, Petr Menšík wrote: I think one reason against maintainer's pull requests is poor tooling to work with them. Filled fedpkg proposal to include ability to fork and add personal fork to current repository or add when cloning [1]. I think current way discourages its use, because

Re: unrecognized DWARF version in .debug_info at 6

If apitrace has its own old bundled copy of libbacktrace, better it should update it to the latest version, which is https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libbacktrace;h=7c4b8fb2fed26a7412bbed1f23976a0f568d0111;hb=HEAD Incomplete DWARF5 support was added to it in December 2019 and

List of long term FTBFS packages to be retired in a week

Dear maintainers. Based on the current fail to build from source policy, the following packages will be retired from Fedora 34 approximately one week before branching (= 1 week from now). Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Note

Re: unrecognized DWARF version in .debug_info at 6

On Wed, Jan 27, 2021 at 05:54:48AM -0700, Jeff Law wrote: > On 1/27/21 5:48 AM, Sandro Mani wrote: > > Apitrace is currently failing to build, with [1] > > > > Test project > > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu > > Start 1:

Re: unrecognized DWARF version in .debug_info at 6

On Wed, Jan 27, 2021 at 01:48:55PM +0100, Sandro Mani wrote: > Hi > > Apitrace is currently failing to build, with [1] > > Test project > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu > Start 1: libbacktrace_btest > 1/6 Test #1:

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

On 1/25/21 5:53 AM, Peter Boy wrote: With Fedora 33 network configuration is by default persisted in /etc/NetworkManager/system-connections/*.nmconnection files. The old /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being processed for the time being, but obviously

Re: unrecognized DWARF version in .debug_info at 6

On 1/27/21 5:48 AM, Sandro Mani wrote: > > Hi > > Apitrace is currently failing to build, with [1] > > Test project > /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu > Start 1: libbacktrace_btest > 1/6 Test #1: libbacktrace_btest

unrecognized DWARF version in .debug_info at 6

Hi Apitrace is currently failing to build, with [1] Test project /builddir/build/BUILD/apitrace-37c36e66b8cfa534797ca565c22e8c30923f35d4/x86_64-redhat-linux-gnu Start 1: libbacktrace_btest 1/6 Test #1: libbacktrace_btest ...***Exception: SegFault 0.11 sec unrecognized DWARF

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

I think one reason against maintainer's pull requests is poor tooling to work with them. Filled fedpkg proposal to include ability to fork and add personal fork to current repository or add when cloning [1]. I think current way discourages its use, because too many manual steps have to be done

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

What about ability to opt-in into %prep checking on push? Could we add some new rules to gating.yaml for example, allowing few checks on push? Most of package I manage are tiny or small, prep check should not take longer than 10s on most of them. I made mistake of omitting patch our source file

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

On Wednesday, 27 January 2021 at 13:11, Arthur G wrote: > Too bad NetworkManager persists with the old MS-DOS "INI" file format for > it's configuration files. At least network-scripts was bash script friendly. You can use crudini to manage .ini files. Works quite well. There's also nmcli...

  1   2   >