Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On 02/15/2018 03:21 PM, Adam Williamson wrote: > On Thu, 2018-02-15 at 18:05 -0500, Stephen John Smoogen wrote: >> >> You have been doing it but have you been wanting to do it or just >> doing it because no one else seems to do it when it is needed. Was it >> an 'official' part of your job that no

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

I would also like to thank the release engineering folks at fedora. Thank you! signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

> "LT" == Luya Tshimbalanga writes: LT> When you get a chance, would you also update the spec guideline as LT> well? Which spec guideline did you mean? If you were referring to the packaging guidelines, they have said that BuildRoot: should not be used since 2016:

Re: Self-introduction: Kaushal

Glad to have you here! signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On Thu, 2018-02-15 at 18:15 -0500, Matthew Miller wrote: > > My intention here wasn't, actually, to complain, but to figure out if > we could do something to spread the work around a little bit -- or > maybe to attach some recognition to what's being done, and make a clear > process for where,

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On Thu, 2018-02-15 at 18:05 -0500, Stephen John Smoogen wrote: > > You have been doing it but have you been wanting to do it or just > doing it because no one else seems to do it when it is needed. Was it > an 'official' part of your job that no one documented or the > documentation was lost? And

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On Thu, 2018-02-15 at 16:39 -0600, Rex Dieter wrote: > Matthew Miller wrote: > > > As shown at https://www.happyassassin.net/nightlies.html, we > > haven't > > had a successful compose for almost two weeks. AIUI this is mostly > > worked out now, but it raises the question: who should be keeping

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On Thu, Feb 15, 2018 at 02:39:53PM -0800, Adam Williamson wrote: > > I suspect that right now, the answer is kind of "It's all of us > > together", which unfortunately practically speaking often comes down to > > 0.02% per person and rounds down to 0. > I...kinda disagree. Sorry, that came out

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On 15 February 2018 at 17:39, Adam Williamson wrote: > On Thu, 2018-02-15 at 17:34 -0500, Matthew Miller wrote: >> As shown at https://www.happyassassin.net/nightlies.html, we haven't >> had a successful compose for almost two weeks. AIUI this is mostly >> worked out

Re: Orphaning scram

On Wed, Feb 14, 2018 at 12:00 AM, Vascom wrote: > I can take package and upgrade it. > Thanks Vascom. Olzhas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

Matthew Miller wrote: > As shown at https://www.happyassassin.net/nightlies.html, we haven't > had a successful compose for almost two weeks. AIUI this is mostly > worked out now, but it raises the question: who should be keeping track > of this and coordinating fixes? ... > What do you think?

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

On Thu, 2018-02-15 at 17:34 -0500, Matthew Miller wrote: > As shown at https://www.happyassassin.net/nightlies.html, we haven't > had a successful compose for almost two weeks. AIUI this is mostly > worked out now, but it raises the question: who should be keeping track > of this and coordinating

Should we have a release manager for each release? (or, "who owns rawhide"?)

As shown at https://www.happyassassin.net/nightlies.html, we haven't had a successful compose for almost two weeks. AIUI this is mostly worked out now, but it raises the question: who should be keeping track of this and coordinating fixes? For the releases, the blocker bug process basically

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

On 14/02/18 21:59 +0100, Igor Gnatenko wrote: * Fix up packages and tell package names I should not touch because you did that already. boostdenisarnaud jwakely Done in https://src.fedoraproject.org/rpms/boost/c/4c456d525c8779b5ea8ef8b2031ad4eab6b66c61?branch=master

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

On Thu, Feb 15, 2018 at 08:12:27PM +, Tomasz Kłoczko wrote: >It took me personally more than few years to come to conclusion that rpm >packages scriptlets idea is wrong. That exact sentence makes me wonder, did you watch the videos from Will at flock or DevConf? Because what you're

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

On 15 February 2018 at 15:19, David Shea wrote: [..] > Can we maybe step back and give other developers the benefit of the doubt > instead of immediately attacking an attempt to provide information? This is > really unnecessarily hostile. > What I wrote is not about hostility

Re: Escaping macros in %changelog

On Fri, 2018-02-09 at 11:05 +0100, Vít Ondruch wrote: > Dne 9.2.2018 v 09:21 Kevin Kofler napsal(a): > > Matthew Miller wrote: > > > Second, there's package maintainer changelogs. These are really > > > redundant with the dist-git log. We don't really need this > > > anymore. > > > It's just a

Re: New "tests" namespace to share test code

On Thu, 2018-02-15 at 13:11 +0100, Petr Šplíchal wrote: > > > The question 'who decides which tests block which packages' is > > left a bit up in the air, but in fact no more so than it already > > was for package-specific tests... > > Right. Do we want to change this? Specify this more

Re: Schedule for Friday's FESCo Meeting (2018-02-16)

On 02/14/2018 10:06 PM, Devrim Gündüz wrote: > On Wed, 2018-02-14 at 17:36 -0500, Randy Barlow wrote: >> #topic #1842 Nonresponsive maintainer: devrim >> .fesco 1842 >> https://pagure.io/fesco/issue/1842 > I thought other folks was already taking care of this package -- and to be > honest, I was

Re: RANT: Packaging is changing too fast and is not well documented

On Mon, Feb 12, 2018, at 7:37 PM, Kevin Fenzi wrote: > On 02/12/2018 10:14 AM, Ken Dreyer wrote: > > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw wrote: > >> Not coming from a programming background I found the learning curve pretty > >> steep when I first tried to become

Re: Fedora27: NFS v4 terrible write performance, is async working

On 15/02/18 16:48, J. Bruce Fields wrote: On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote: The transaction system allows the write delegation to send the data to the servers RAM without the overhead of synchronous writes to the disk. As far as I'm concerned this problem is

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following Fedora EPEL 7 Security updates need testing: Age URL 1074 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 837 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 419

Re: Fedora27: NFS v4 terrible write performance, is async working

On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote: > The transaction system allows the write delegation to send the data to the > servers RAM without the overhead of synchronous writes to the disk. As far as I'm concerned this problem is already solved--did you miss the discussion of

Re: Non-responsive maintainer: Lubomir Rintel (lkundrak)

On Wed, 2018-02-14 at 23:49 +0100, Sandro Mani wrote: > Hi > > Does anyone know how to contact Lubomir Rintel (lkundrak)? He is > obviously still active since his last koji build is as recent as > last > Sunday the 11th, but he isn't answering to this ticket [1] and I > also > had no luck

Re: libevent-2.1.8 SONAME change.

On 02/15/2018 07:04 AM, Peter Robinson wrote: > On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson wrote: >> Hello, >> >> Yesterday I updated libevent to the latest upstream release. >> >> I mistakenly did not realized there was a SONAME change >> in this update. So if your

Schedule for Thursday's FPC Meeting (2018-02-15 17:00 UTC)

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

Re: Removal of BuildRoot

On 15/02/18 11:10 -0500, David Cantrell wrote: On 02/15/2018 11:02 AM, Jonathan Wakely wrote: On 15/02/18 08:46 -0500, David Cantrell wrote: First, I actually don't care if this change is made or not.  My personal opinion is that it's a nice-to-have cleanup that will probably not cause

Re: Removal of BuildRoot

On 02/15/2018 11:02 AM, Jonathan Wakely wrote: > On 15/02/18 08:46 -0500, David Cantrell wrote: >> First, I actually don't care if this change is made or not.  My personal >> opinion is that it's a nice-to-have cleanup that will probably not cause >> problems, but you never know with that many

Re: Removal of BuildRoot

On 2018-02-13 02:05 PM, Igor Gnatenko wrote: > Just a small heads up, BuildRoot tag is not needed since RHEL6 (which > is oldest > supported one nowadays, it's been year or so after EL5 retirement). And we > don't support EL5 anymore, so... > > I wanted to send this heads up before I actually did

Re: Removal of BuildRoot

On 15/02/18 08:46 -0500, David Cantrell wrote: First, I actually don't care if this change is made or not. My personal opinion is that it's a nice-to-have cleanup that will probably not cause problems, but you never know with that many packages. So that's why I feel it should be approached

Re: Removal of BuildRoot

On 15/02/18 08:52 -0500, David Cantrell wrote: Does it actually hurt or is it just unnecessary? Removing unnecessary things from spec files is fine with me, but I was not seeing this as actually breaking things at the moment. If BuildRoot lines have been in spec files for 10+ years and we are

[Bug 1543336] please provide missing Fedora 27 Perl modules

https://bugzilla.redhat.com/show_bug.cgi?id=1543336 Petr Pisar changed: What|Removed |Added See Also|

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

Dne 14.2.2018 v 21:59 Igor Gnatenko napsal(a): > msuchy abrt satyr * You should not touch because I done the change in upstream, it will be propagated during next release. Miroslav signature.asc Description: OpenPGP digital signature ___ devel

Self-introduction: Kaushal

Hi all, I've just been accepted into the packagers group, so that I can submit and maintain a few packages. For anyone wondering why though, here's a small introduction about me. I'm Kaushal. I'm a developer who works out of Mysuru, India. I'm one of the maintainers of the GlusterFS project [1],

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

> Determinism level is about level of *variations* of the results on > repeating the same operations starting from exactly the same initial state. > Executing ldconfig after each package libraries installation/upgrade or > executing the same ldconfig only one time after install/upgrade libraries >

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

On mercredi 14 février 2018 21:59:27 CET Igor Gnatenko wrote: > * Tell package names you want to remove ldconfig scriptlets entirely instead > of replacing them with %ldconfig_scriptlets and get fix **for free**. I wish you remove the scriplets entirely for Rawhide only on my packages:

[EPEL-devel] Fedora EPEL 6 updates-testing report

The following Fedora EPEL 6 Security updates need testing: Age URL 946 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 836 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb mcollective-2.8.4-1.el6 808

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

On 14 February 2018 at 23:26, Will Woods wrote: [..] > I don't think this single change will make a huge difference within > the existing ecosystem, but I think it's an important step in a larger > shift toward make package installation & image composition a) > introspectable

Re: Removal of BuildRoot

On 15.2.2018 10:17, Michal Novotny wrote: I feel PRs are better for this sort of stuff. Mainly because people are informed why exactly this change is made, they can read the guidelines and then merge the change when they are sure they understand it. It helps spreading knowledge and keeping

[Bug 1543336] please provide missing Fedora 27 Perl modules

https://bugzilla.redhat.com/show_bug.cgi?id=1543336 --- Comment #18 from Petr Pisar --- It looks like 0.053 can be packaged if I disable ECC support. I will try that and put the package on review. -- You are receiving this mail because: You are on the CC list for the bug.

Re: Removal of BuildRoot

On 02/15/2018 02:11 AM, Vít Ondruch wrote: >> Sadly, commit notifications does NOT work for months >> (works for old packages, not for newly imported one) > > It does not work at all. I did not get any notification about mass > rebuild changes what so ever. No build notifications, no commit >

[Bug 1545652] perl-XML-SAX-1.00 is available

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

Re: Removal of BuildRoot

On 02/15/2018 03:08 AM, Panu Matilainen wrote: > On 02/14/2018 11:27 PM, David Cantrell wrote: >> On 02/14/2018 02:41 PM, Igor Gnatenko wrote: >>> On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: On 02/14/2018 11:44 AM, Remi Collet wrote: > Le 13/02/2018 à 23:05, Igor Gnatenko a

Re: Removal of BuildRoot

On 02/14/2018 04:47 PM, Reindl Harald wrote: > Am 14.02.2018 um 22:27 schrieb David Cantrell: >> I am not disputing the policy.  I feel this change is pointless and is a >> lot of commits for no real benefit.  They are not fixes.  You're just >> scrubbing spec files that are not broken.  Who

[Bug 1543336] please provide missing Fedora 27 Perl modules

https://bugzilla.redhat.com/show_bug.cgi?id=1543336 --- Comment #17 from Petr Pisar --- I don't think this ever happen. CryptX author always develops on his libtomcrypt fork. I'd rather try packaging an older CryptX version that could work with upstream libtomcrypt. I don't

Re: Removal of BuildRoot

Michal Novotny wrote: > I feel PRs are better for this sort of stuff. In theory yes. In practice (in my experience so far), it's still not very practical to go through the process of: * fork * commit * file PR for anything more than a handful of packages. Unless, anyone knows of a way to

[Bug 1545652] New: perl-XML-SAX-1.00 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1545652 Bug ID: 1545652 Summary: perl-XML-SAX-1.00 is available Product: Fedora Version: rawhide Component: perl-XML-SAX Keywords: FutureFeature, Triaged Assignee:

Re: Usefulness of `copr mock-config ` feature?

On 2018-02-13 21:51, Michal Novotny wrote: Hello, On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček > wrote: On 2018-02-13 11:47, Pavel Raiskup wrote: Sorry, I wanted to CC fedora devel before, forwarding. Pavel

Re: GCC 8: camotics fails to build for i686, ARMv7 arches (reading 31 bytes from a region of size 16)

On 15/02/18 07:05 -, Samuel Rakitničan wrote: Hello, Need help figuring this out since I have no idea what this means. It means the package should probably not be using -Werror The cbang code that is included in camotics fails to build with the following messages. It is failing only

Re: New "tests" namespace to share test code

On 14 February 2018 at 18:18, Adam Williamson wrote: > On Wed, 2018-02-14 at 17:28 +0100, Petr Šplíchal wrote: >> Hi! >> >> During the last days there have been concerns raised regarding >> what is an appropriate content for the tests namespace. [1] My >> original idea

Re: libevent-2.1.8 SONAME change.

On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson wrote: > Hello, > > Yesterday I updated libevent to the latest upstream release. > > I mistakenly did not realized there was a SONAME change > in this update. So if your package is dependent on > libevent, you are going to have to

[Bug 1479864] Upgrade perl-Net-SSH-Perl to 2.12

https://bugzilla.redhat.com/show_bug.cgi?id=1479864 Paul Howarth changed: What|Removed |Added See Also|

[Bug 1543336] please provide missing Fedora 27 Perl modules

https://bugzilla.redhat.com/show_bug.cgi?id=1543336 Paul Howarth changed: What|Removed |Added See Also|

libevent-2.1.8 SONAME change.

Hello, Yesterday I updated libevent to the latest upstream release. I mistakenly did not realized there was a SONAME change in this update. So if your package is dependent on libevent, you are going to have to rebuild. My apologies for this oversight... steved.

Re: Removal of BuildRoot

On Thu, Feb 15, 2018 at 10:36 AM, Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Thu, 2018-02-15 at 10:17 +0100, Michal Novotny wrote: > > I feel PRs are better for this sort of stuff. Mainly because people are > > informed why

Re: RFC: BugURL in packages

Dne 15.2.2018 v 12:09 Vít Ondruch napsal(a): > Good you mention it. But probably adding RH bugzilla there does not make > sense, because hopefully everybody knows and it > should be the default. Nope. I think even some power users will have to look hard for the right URL. > But it could be

Re: RFC: BugURL in packages

Good you mention it. But probably adding RH bugzilla there does not make sense, because hopefully everybody knows and it should be the default. But it could be utilized by packages, whose maintainers notoriously ignore RH bugzilla (Gnome components comes to my mind). Vít Dne 15.2.2018 v 11:22

Re: RFC: BugURL in packages

On Feb 15, 2018 11:52, "Pierre-Yves Chibon" wrote: On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > it's been just 9 years since BugURL has been added to RPM, but it has not been > used. > > I

Re: Pull requests for compat-gcc-34

9.02.2018 11:34 Rafal Luzynski wrote: > [...] > Please: > - backport the solution to F26 and F27 as well, this should be much > easier than in F28 (my pull requests may be helpful), > - mark my pull requests as merged/obsolete/whatever is appropriate, > - mark the

Re: RFC: BugURL in packages

On Thu, Feb 15, 2018 at 11:22:27AM +0100, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello, > > it's been just 9 years since BugURL has been added to RPM, but it has not been > used. > > I think it would be helpful for users to have it defined in RPMs, so when

Unannounced soname bump in libevent

It appears that yesterday build of libevent bumped its soname. That means that, at minimum, Memcahed is broken now. BTW it is well possible, that the packager did not noticed the soname bump, since the libraries are included into package by wildcards in files section [1]. I consider this bad

Re: RFC: BugURL in packages

On Thursday, 15 February 2018 at 11:22, Igor Gnatenko wrote: > Hello, > > it's been just 9 years since BugURL has been added to RPM, but it has not been > used. Wow! You're right: $ rpm -q --querytags|grep -i bug BUGURL > I think it would be helpful for users to have it defined in RPMs, so when

RFC: BugURL in packages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, it's been just 9 years since BugURL has been added to RPM, but it has not been used. I think it would be helpful for users to have it defined in RPMs, so when they do `dnf info`, `rpm -qi` they would just click on it and it would select

[Bug 1501159] Segmentation fault in spawn_proc_prog calling apr_palloc

https://bugzilla.redhat.com/show_bug.cgi?id=1501159 --- Comment #1 from Matti Linnanvuori --- I could reproduce this by calling spawn_proc_prog on an old object. -- You are receiving this mail because: You are on the CC list for the bug.

Re: Removal of BuildRoot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-02-15 at 10:17 +0100, Michal Novotny wrote: > I feel PRs are better for this sort of stuff. Mainly because people are > informed why exactly this change is made, > they can read the guidelines and then merge the change when they are

Re: Removal of BuildRoot

On Thu, 15 Feb 2018 08:11:17 +0100 Vít Ondruch wrote: > Dne 15.2.2018 v 07:55 Remi Collet napsal(a): > > Le 15/02/2018 à 07:47, Igor Gnatenko a écrit : > >> On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote: > >>> nicolas.mail...@laposte.net wrote: > Hi, >

Re: Removal of BuildRoot

I feel PRs are better for this sort of stuff. Mainly because people are informed why exactly this change is made, they can read the guidelines and then merge the change when they are sure they understand it. It helps spreading knowledge and keeping community involved. Python team did it very well

[Bug 1545467] perl-IPC-Cmd-1.00 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1545467 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In

Re: Removal of BuildRoot

On 02/15/2018 10:34 AM, Miroslav Suchý wrote: Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a): On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: On 02/14/2018 11:44 AM, Remi Collet wrote: - abuse proven packager privileges +1 +1 Please, read policy[0] once more. Sometimes there are

Re: Removal of BuildRoot

Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a): > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: >> On 02/14/2018 11:44 AM, Remi Collet wrote: >>> - abuse proven packager privileges >> +1 +1 > Please, read policy[0] once more. > >> Sometimes there are situations where it's simply a lot

Re: Removal of BuildRoot

On 02/14/2018 11:27 PM, David Cantrell wrote: On 02/14/2018 02:41 PM, Igor Gnatenko wrote: On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: On 02/14/2018 11:44 AM, Remi Collet wrote: Le 13/02/2018 à 23:05, Igor Gnatenko a écrit : Just a small heads up, ... As I said on IRC -

[Bug 1543336] please provide missing Fedora 27 Perl modules

https://bugzilla.redhat.com/show_bug.cgi?id=1543336 --- Comment #15 from Jitka Plesnikova --- I requested new branch and built these packages for EPEL 7. I am maintainer of them. perl-Convert-ASCII-Armour-1.4-32.el7 perl-Net-SSH-0.09-26.el7