Re: Self Introduction: Dan Shoemaker

> > Hi, my name is Dan Shoemaker. I have been using Fedora since Fedora Core > 6 for both personal and professional use. About five years ago I started > developing bash scripts in order to start automating tasks I was doing > while maintaining Linux servers for various clients. Last year I star

Re: Non-responsive maintainer: pocock

On 2/26/20 6:59 PM, Daniel Pocock wrote: On 26/02/2020 22:56, Dakota Williams wrote: On 2/24/20 5:57 PM, Daniel Pocock wrote: On 24/02/2020 20:47, Dakota Williams wrote: Does anyone know how to contact maintainer pocock? https://bugzilla.redhat.com/show_bug.cgi?id=1806708 https://bugzilla

Re: Want to claim vault

Yes is there someone with more knowledge on this who could say what the right procedure is for this case? If I do need to use a different name package name, would I at least be able to have 'Provides: vault' in it? I don't think there's a precedent yet for this package in other Linux distros so I

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 16:13, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > > For the changelog, we believe we have a potential good solution: > > - The changelog will be automatically generated using an external > > `changelo

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

On Thu, Feb 27, 2020 at 07:50:05PM +0100, Clement Verna wrote: > On Thu, 27 Feb 2020 at 14:14, Richard W.M. Jones wrote: > > > Despite earlier concerns, this does in fact appear to all be working fine. > > > > Yes requesting and building in the side tag should work just fine. > > > > > > There

Re: taskotron going down for emergency maintenance

Taskotron is back up but we're still having some issues with delays to the incoming jobs. We're still investigating but data should be flowing again, even if it is a bit delayed. Thanks, Tim On Thu, 27 Feb 2020 10:09:33 -0700 Tim Flink wrote: > The subject says it all, really. > > Taskotron

Revamping the Release Readiness meeting

(Posting to many mailing lists for visibility. I apologize if you see this more times than you'd like.) You may have already seen my Community Blog post[1] about changing the Release Readiness meeting process. The meeting has questionable value in the current state, so I want to make it more usef

Re: Ideas and proposal for removing changelog and release fields from spec file

Le jeudi 27 février 2020 à 17:38 +0100, clime a écrit : > On Thu, 27 Feb 2020 at 16:26, Nicolas Mailhot via devel > wrote: > > Le 2020-02-27 12:59, clime a écrit : > > Hi, > > > > > can you, please, show an example of such package? I was searching > > > through some > > > golang packages because

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

On Thu, 27 Feb 2020 at 14:14, Richard W.M. Jones wrote: > Despite earlier concerns, this does in fact appear to all be working fine. > Yes requesting and building in the side tag should work just fine. > > There are now F32 builds going through for all OCaml packages in a > side tag, and when

Re: Can not build new package: not in list for tag f33-updates-candidate

It works, thanks a lot! El jue., 27 feb. 2020 18:02, Mohan Boddu escribió: > This should be fixed now, can you give it a try? > > On Thu, Feb 27, 2020 at 10:54 AM Alejandro Álvarez Ayllón > wrote: > > > > Hello all, > > > > I am trying to build sourcextractor++, which was accepted yesterday, an

taskotron going down for emergency maintenance

The subject says it all, really. Taskotron is having some problems with an internal component, it can't wait for a better time and we need some downtime to fix it. If all goes well, it should be back up shortly. I'll send another email to update once we're done. Tim pgp4sFi8EO6c7.pgp Descripti

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 17:29, Nils Philippsen wrote: > > On Thu, 2020-02-27 at 15:10 +0100, clime wrote: > > Another thing to consider is whether we want a transparent build > > system where all the description of what will happen when a spec file > > is sent to it is included in the specfile itse

Re: Ideas and proposal for removing changelog and release fields from spec file

On Tue, Feb 25, 2020 at 05:42:11PM +0100, Miro Hrončok wrote: > On 25. 02. 20 9:50, Pierre-Yves Chibon wrote: > >Upgrade path may be problematic if you update Fn to a version in less commit > >than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update > >F31 > >to 1.0 in 2 commits,

Re: Can not build new package: not in list for tag f33-updates-candidate

This should be fixed now, can you give it a try? On Thu, Feb 27, 2020 at 10:54 AM Alejandro Álvarez Ayllón wrote: > > Hello all, > > I am trying to build sourcextractor++, which was accepted yesterday, and > every time I try I get the following error: > > BuildError: package sourcextractor++ not

Fedora rawhide compose report: 20200227.n.0 changes

OLD: Fedora-Rawhide-20200226.n.0 NEW: Fedora-Rawhide-20200227.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 9 Dropped packages:1 Upgraded packages: 96 Downgraded packages: 0 Size of added packages: 91.55 MiB Size of dropped packages

Re: OCaml 4.10.0 build in Fedora 32 and 33

On Thu, Feb 27, 2020 at 12:04:42PM +0100, Fabio Valentini wrote: > > Yeah, because the updates-testing activation happened, which means > that just submitting builds is not enough anymore. > If you did things "normally", you'd need to create buildroot overrides > for each build, wait, submit the n

Re: OCaml 4.10.0 build in Fedora 32 and 33

On Thu, Feb 27, 2020 at 10:46:27AM +, Richard W.M. Jones wrote: > > This is where I might need help. I have a few questions: > > - There was something go on with Bodhi a few days ago which meant >that you didn't want me to start this. Can I start now? We were enabling it on tuesday an

Fedora-32-20200227.n.0 compose check report

No missing expected images. Failed openQA tests: 25/160 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200226.n.0): ID: 528837 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/528837 ID: 528871 Test: x86_64 universal

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 16:26, Nicolas Mailhot via devel wrote: > > Le 2020-02-27 12:59, clime a écrit : > Hi, > > > > > can you, please, show an example of such package? I was searching > > through some > > golang packages because I was curious how it works but couldn't find > > an example > > A G

Re: Ideas and proposal for removing changelog and release fields from spec file

On Wed, 2020-02-26 at 23:07 -0500, Neal Gompa wrote: > On Wed, Feb 26, 2020 at 8:05 PM Robert-André Mauchin < > zebo...@gmail.com> wrote: > > On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote: > > > However, for the release field, we are struggling a little bit > > > more, two > > >

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 2020-02-27 at 15:10 +0100, clime wrote: > Another thing to consider is whether we want a transparent build > system where all the description of what will happen when a spec file > is sent to it is included in the specfile itself or whether we want But we don't have that today: think of ma

rpminspect Copr repository moving

If you are using rpminspect and rpminspect-data-fedora from my Copr repository, please note that it is moving. The move is tied to my username change that happened internally at Red Hat and then I mirrored in Fedora. The short story is that I can now have "dcantrell" as my username and discontin

Can not build new package: not in list for tag f33-updates-candidate

Hello all, I am trying to build sourcextractor++, which was accepted yesterday, and every time I try I get the following error: BuildError: package sourcextractor++ not in list for tag f33-updates-candidate https://koji.fedoraproject.org/koji/taskinfo?taskID=41969086 I have seen some packages t

Fedora 32 compose report: 20200227.n.0 changes

OLD: Fedora-32-20200226.n.0 NEW: Fedora-32-20200227.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:59.90 KiB Size of

Re: Ideas and proposal for removing changelog and release fields from spec file

Le 2020-02-27 12:59, clime a écrit : Hi, can you, please, show an example of such package? I was searching through some golang packages because I was curious how it works but couldn't find an example A Go example: https://src.fedoraproject.org/rpms/golang-x-build A non-Go example: https://

Re: Ideas and proposal for removing changelog and release fields from spec file

Hi, On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > For the changelog, we believe we have a potential good solution: > - The changelog will be automatically generated using an external `changelog` > file as well as the commit history ... > If you wanted to edit the changelo

Fedora-Rawhide-20200227.n.0 compose check report

No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 24/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200226.

Re: State of FMN (FedMSG Notifications) and Replacement

On Wed, 2020-02-26 at 13:03 -0800, Kevin Fenzi wrote: > On Wed, Feb 26, 2020 at 02:45:24PM +, Jeremy Cline wrote: > > FYI before I left the team I started hacking up a replacement[0]. > > My > > design focused on how to get as rich a feature set as I could using > > only AMQPs currently availab

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 13:23, clime wrote: > > On Thu, 27 Feb 2020 at 12:42, David Kaufmann wrote: > > > > On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > > > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote: > > >> Another idea would be generating a changelog-entry from git history w

Schedule for Thursday's FPC Meeting (2020-02-27 17:00 UTC)

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-02-27 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2020-02-27 09:00 PST US/Pacific 2020-02-27

Re: Cross-arch dependencies for plugins (NSS and others)

I submitted a patch for redhat-rpm-config: Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

Despite earlier concerns, this does in fact appear to all be working fine. There are now F32 builds going through for all OCaml packages in a side tag, and when that's done I'll try to create a Bodhi update. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones

Fedora-IoT-33-20200227.0 compose check report

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 2/8 (x86_64) Old failures (same test failed in Fedora-IoT-33-20200226.0): ID: 528771 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/528771 ID: 528772 Test:

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 12:42, David Kaufmann wrote: > > On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote: > >> Another idea would be generating a changelog-entry from git history when > >> creating an update in bodhi, and there is no pr

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 10:47, Nicolas Mailhot via devel wrote: > > Le 2020-02-27 09:52, Miro Hrončok a écrit : > > On 27. 02. 20 9:20, Pierre-Yves Chibon wrote: > >>> How would that work with "complex" releases? For example release > >>> containing > >>> prerelease info like 0.1.beta.2 or 0.1.2012

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

Adding a dist tag does indeed fix this problem. I'll try continuing with my original plan of using a self-service side tag. Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedo

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

On Thu, Feb 27, 2020 at 12:47:00PM +0100, Lubomír Sedlář wrote: > Richard W.M. Jones píše v Čt 27. 02. 2020 v 11:03 +: > > I built ocaml-4.10.0-1.fc33 yesterday. > > > > Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but > > builds fail with: > > > > $ fedpkg request-side-tag

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

Richard W.M. Jones píše v Čt 27. 02. 2020 v 11:03 +: > I built ocaml-4.10.0-1.fc33 yesterday. > > Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but > builds fail with: > > $ fedpkg request-side-tag --base-tag f32-build > Side tag 'f32-build-side-19863' (id 19863) created. > U

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, Feb 27, 2020 at 12:21:48PM +0100, clime wrote: > On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote: >> Another idea would be generating a changelog-entry from git history when >> creating an update in bodhi, and there is no pre-existing >> changelog-entry for the current version. > > But

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 10:00, David Kaufmann wrote: > > On Thu, Feb 27, 2020 at 08:08:49AM +0100, Dan Čermák wrote: > > For the changelog: yes please, generate it from the commit log! They are > > more or less the same for all my packages and I'm getting tired of copy > > pasting the same text int

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

On Thu, Feb 27, 2020 at 11:03:33AM +, Richard W.M. Jones wrote: > > I built ocaml-4.10.0-1.fc33 yesterday. > > Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but > builds fail with: > > $ fedpkg request-side-tag --base-tag f32-build > Side tag 'f32-build-side-19863' (id 19863

Re: Build into < Rawhide side tag fails with "Package ... has already been built"

On Thu, Feb 27, 2020 at 12:04 PM Richard W.M. Jones wrote: > > > I built ocaml-4.10.0-1.fc33 yesterday. > > Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but > builds fail with: > > $ fedpkg request-side-tag --base-tag f32-build > Side tag 'f32-build-side-19863' (id 19863) created

Re: Ideas and proposal for removing changelog and release fields from spec file

On 27. 02. 20 11:57, clime wrote: If i understand correctly, this would rely on the locally undefined %{baserelease} macro, which is later provided auto-magically by the build system. Should this macro be populated also locally if not defined? Yes, by fedpkg. Now should the specs be buildable s

Re: OCaml 4.10.0 build in Fedora 32 and 33

On Thu, Feb 27, 2020 at 11:47 AM Richard W.M. Jones wrote: > > On Mon, Feb 24, 2020 at 08:56:04AM +, Richard W.M. Jones wrote: > > OCaml 4.10.0 was released over the weekend. > > > > We currently have OCaml 4.10.0 beta 1 in Rawhide. It's not that far > > away from 4.10.0. Unfortunately since

Build into < Rawhide side tag fails with "Package ... has already been built"

I built ocaml-4.10.0-1.fc33 yesterday. Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but builds fail with: $ fedpkg request-side-tag --base-tag f32-build Side tag 'f32-build-side-19863' (id 19863) created. Use 'fedpkg build --target=f32-build-side-19863' to use it. Use 'koji wai

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, 27 Feb 2020 at 09:53, Miro Hrončok wrote: > > On 27. 02. 20 9:20, Pierre-Yves Chibon wrote: > >> How would that work with "complex" releases? For example release containing > >> prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package > >> have no version, so depend heavi

Re: OCaml 4.10.0 build in Fedora 32 and 33

On Mon, Feb 24, 2020 at 08:56:04AM +, Richard W.M. Jones wrote: > OCaml 4.10.0 was released over the weekend. > > We currently have OCaml 4.10.0 beta 1 in Rawhide. It's not that far > away from 4.10.0. Unfortunately since building beta 1, Fedora 32 was > forked from Rawhide so we now have th

Re: Ideas and proposal for removing changelog and release fields from spec file

Le 2020-02-27 09:52, Miro Hrončok a écrit : On 27. 02. 20 9:20, Pierre-Yves Chibon wrote: How would that work with "complex" releases? For example release containing prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package have no version, so depend heavily on the Release tag

Re: Ideas and proposal for removing changelog and release fields from spec file

Le 2020-02-27 08:35, Nicolas Mailhot via devel a écrit : Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit : You don't use Release for upstream versioning, even for snapshots. For your examples: * 0-0.1.beta.2 -> 0~beta.2-1 * 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a- Sor

Re: sssd: Could you please respond in Fedora Bugzilla?

On 27. 02. 20 10:00, Michal Židek wrote: Hello Michal, Could you please respond in here: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=sssd&product=Fedora Regarding this, do you know how to change the default assignee for the component? I will go throu

Re: sssd: Could you please respond in Fedora Bugzilla?

On 27. 02. 20 9:49, Michal Židek wrote: On 2/27/20 9:42 AM, Miro Hrončok wrote: Hello Michal, Could you please respond in here: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=sssd&product=Fedora Especially in here https://bugzilla.redhat.com/show_bug.c

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, Feb 27, 2020 at 08:08:49AM +0100, Dan Čermák wrote: > For the changelog: yes please, generate it from the commit log! They are > more or less the same for all my packages and I'm getting tired of copy > pasting the same text into %changelog and git commit. Another idea would be generating

Fedora-Cloud-31-20200227.0 compose check report

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedorap

Re: Ideas and proposal for removing changelog and release fields from spec file

On 27. 02. 20 9:20, Pierre-Yves Chibon wrote: How would that work with "complex" releases? For example release containing prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package have no version, so depend heavily on the Release tag to signal what is the snapshot date and git co

sssd: Could you please respond in Fedora Bugzilla?

Hello Michal, Could you please respond in here: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=sssd&product=Fedora Especially in here https://bugzilla.redhat.com/show_bug.cgi?id=1800567 ? I see you have just committed 14 commits to src.fedoraproject.org/rp

Re: Ideas and proposal for removing changelog and release fields from spec file

On Thu, Feb 27, 2020 at 02:04:41AM +0100, Robert-André Mauchin wrote: > On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote: > > However, for the release field, we are struggling a little bit more, two > > options are more appealing to us: > > > > A) The release field is automaticall