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

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 appro

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 (aarch64

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 https://bodhi.fedora

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 lea

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 rp

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 > > https://koji.fedoraproject.org/koji/taskinfo?

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 Wed

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

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 eve

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 Ciesl

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 b

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 be

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 faste

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 lo

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) Creatin

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 f

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 i

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` c

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

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.

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

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 cause

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

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 (e

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 `m

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 c

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 t

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 u

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 i

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

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

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, s

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 Leade

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 thin

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 o

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 cer

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; devel@lists.fedoraproject.o

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 m

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

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

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: https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Pos

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 doesn't

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

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 o

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 live

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 http://kojipkgs.fedoraproject.org//packag

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

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 [1]

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 +pr

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 wit

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 a

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 importan

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

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

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 i

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 ver

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 befo

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 mu

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

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

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. On Mon, 25 Jan 2021 at 20:53, Peter Boy wrote: > With Fedora 33 network configuration is by default persisted in > /etc/NetworkManager/system-con

Re: Fedora 34 Change: GNOME 40 (Self-Contained Change)

On 1/26/21 09:02, Vít Ondruch wrote: I have some issues with screen locking/screen saver [1]. Is needinfo in BZ the right approach? Thx Hi Vít, That definitely works. I'll take a look at the ticket, thanks for letting me know! -- Kalev ___ devel ma

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 th

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

On 26. 01. 21 13:24, Kamil Paral 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 have the logic self-contained, why don't we add something like "Provides: multilib(x86_64, i686)"

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

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 have the logic self-contained, why don't we add something like > > "Provide

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

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: * Try and change the storage format of the signatures to not take up tons of room. I

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

On Tue, Jan 26, 2021 at 09:52:59AM -0500, Alexander Scheel wrote: > > Well, I understand your sentiment against mass spec changes, but there are > > cases, where it currently cannot be avoided (e.-g. when a targeted mass > > rebuild > > is needed for a soname bump). W.g. when we update Python from