pytestmark = pytest.mark.tier1
I saw this in a test and curious as to it's function? I'm sure it has one :)
--
Sincerely,
William
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
Le 02/10/2019 à 08:37, Remi Collet a écrit :
> Hi,
>
> See: https://fedoraproject.org/wiki/Changes/php74
>
Mass rebuild done
php-7.4.0~RC3-1.fc32
graphviz-2.42.2-2.fc32
php-ast-1.0.3-2.fc32
php-facedetect-1.2.0-0.9.20180306gitc717941.fc32
https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/04/report-389-ds-base-1.4.2.2-20191003gite049236.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
No missing expected images.
Failed openQA tests: 5/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191001.n.0):
ID: 462758 Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/462758
ID: 462828 Test: x86_64
OLD: Fedora-31-20191001.n.0
NEW: Fedora-31-20191003.n.1
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 35
Dropped packages:2
Upgraded packages: 98
Downgraded packages: 0
Size of added packages: 59.73 MiB
Size of dropped packages:327.71 KiB
Anyone have any ideas? I tried re-submitting them but they were obsoleted
by bodhi again.
Thanks,
Richard
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
On Thu, Oct 03, 2019 at 04:32:04PM -0600, Jerry James wrote:
> On Wed, Oct 2, 2019 at 11:45 AM Kevin Fenzi wrote:
> > So, this is my 'fault' I guess.
> >
> > There were some builds stuck in the signing tag in rawhide, so I
> > retagged them to get them signed and in. In this case it made an
On Thu, Oct 03, 2019 at 08:42:36PM +0200, Clement Verna wrote:
> On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote:
>
> > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> > > wrote:
> > >
> > > > On Wed, Oct 02, 2019 at 05:31:56PM
Hi,
On Tuesday, 24 September 2019 at 06:56, Thomas Stephen Lee wrote:
> On Tue, Sep 24, 2019 at 12:17 AM Troy Dawson
> wrote:
> > On Mon, Sep 23, 2019 at 10:53 AM Stephen John Smoogen
> > wrote:
> > > On Mon, 23 Sep 2019 at 12:31, Thomas Stephen Lee
> > > wrote:
[...]
> > > > Ran the command
Announcing the creation of a new nightly release validation test event
for Fedora 31 Branched 20191003.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
On Wed, Oct 2, 2019 at 11:45 AM Kevin Fenzi wrote:
> So, this is my 'fault' I guess.
>
> There were some builds stuck in the signing tag in rawhide, so I
> retagged them to get them signed and in. In this case it made an 'older'
> build show up. ;(
>
> I'll check f32 for older builds and fix them
On 03. 10. 19 23:34, alcir...@gmail.com wrote:
I'm trying to build an RPM of a python package.
The LICENSE file of the python package states that it is released under
MIT license.
But there is a file, _version.py, where you can read:
Parts of `extract_components` are taken from the pypa
I'm trying to build an RPM of a python package.
The LICENSE file of the python package states that it is released under
MIT license.
But there is a file, _version.py, where you can read:
Parts of `extract_components` are taken from the pypa packaging project
(https://github.com/pypa/packaging)
https://fedoraproject.org/wiki/Changes/BINUTILS233
== Summary ==
Rebase the binutils package from version 2.32 to version 2.33.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com
== Detailed Description ==
Switch the binutils package from
https://fedoraproject.org/wiki/Changes/BINUTILS233
== Summary ==
Rebase the binutils package from version 2.32 to version 2.33.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com
== Detailed Description ==
Switch the binutils package from
On Thu, Oct 3, 2019 at 9:11 PM Dinesh Prasanth Moluguwan
Krishnamoorthy wrote:
>
> Hello everyone!
>
> We, the Dogtag PKI team, would like to revive the jboss-logging-tools
> which was retired as part of the Fedora orphaning process.
>
> This package is a direct dependency for dogtag-pki project,
Thanks Adam! Much appreciated.
On Thu, Oct 3, 2019 at 2:57 PM Adam Williamson wrote:
> On Thu, 2019-10-03 at 10:43 -0500, Steve Siirila wrote:
> > Troy,
> >
> > Thanks for the reply, much appreciated! I look forward to seeing the
> > patches getting integrated into RHEL 7.
> >
> > On Thu, Oct
On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote:
> On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote:
> > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto
> > wrote:
> > > Hi,
> > > epel 8 brings a new file called package.cfg, I strongly prefer to
> > > keep
> > > branches
https://bugzilla.redhat.com/show_bug.cgi?id=1753548
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #2 from
Hello everyone!
We, the Dogtag PKI team, would like to revive the jboss-logging-tools
which was retired as part of the Fedora orphaning process.
This package is a direct dependency for dogtag-pki project, which in
turn is a dependency for FreeIPA.
I'd honored if someone can review [1] our
https://bugzilla.redhat.com/show_bug.cgi?id=1753726
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #1 from
https://bugzilla.redhat.com/show_bug.cgi?id=1753550
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #1 from
https://bugzilla.redhat.com/show_bug.cgi?id=1753728
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #2 from
On Thu, Oct 03, 2019 at 11:42:02AM -0400, Randy Barlow wrote:
> On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> > I even go as far as reverting branch-only commits and then doing the
> > bidirectional merge trick to restore fast forwardability. That of
> > course
> > clobbers the
* Daniel P. Berrangé [03/10/2019 14:47] :
>
> FWIW, my approach is to purge all changelog entries older than 2 years
> the first time I touch a package in January each year. Is there any value
> in having guidelines to encourage some policy in this area, so maintainer
> approach it in a consistent
On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote:
> On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> > On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> > wrote:
> >
> > > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > > > ○ Every changes to dist-git is done
https://bugzilla.redhat.com/show_bug.cgi?id=1752411
--- Comment #10 from Fedora Update System ---
FEDORA-EPEL-2019-67e1c8c8d8 has been submitted as an update to Fedora EPEL 6.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-67e1c8c8d8
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1752411
--- Comment #9 from Fedora Update System ---
FEDORA-EPEL-2019-2e402bcb54 has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2e402bcb54
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1752411
--- Comment #8 from Fedora Update System ---
FEDORA-EPEL-2019-7c65527082 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7c65527082
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1752411
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |MODIFIED
--- Comment #7 from
https://bugzilla.redhat.com/show_bug.cgi?id=1757538
--- Comment #1 from Fedora Update System ---
FEDORA-2019-93fb0f420c has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-93fb0f420c
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=1757538
Paul Howarth changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1758280
Bug ID: 1758280
Summary: Please build perl-Spreadsheet-ParseExcel for EPEL 8
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
> "MM" == Matthew Miller writes:
MM> Whether or not it's documented policy (and I can't remember or find
MM> anything either), many packages have the practice of trimming very
MM> old entries.
You can't always do this. I tried to purge changelog entries from a
package older than 2010 and
https://bugzilla.redhat.com/show_bug.cgi?id=1757538
Paul Howarth changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1758050
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #1 from
euroFedora/issue/250 (bt0, 15:23:11)
* LINK: https://fedorapeople.org/groups/neuro-sig/ (FranciscoD,
15:33:05)
* LINK:
https://fedorapeople.org/groups/neuro-sig/Fedora-31-Comp-Neuro-20191003-1.iso
(FranciscoD, 15:33:11)
* ACTION: MeWjOr think about whether tags
On Thu, Oct 03, 2019 at 11:13:32AM -0500, Michael Cronenworth wrote:
> >Remote changelog URLs might become inaccessible over time, making tracking
> >down
> >behavior changes & tricky bugs problematic.
> Yes, there are systems that do not have Internet access.
> Examples:
> - Classified systems
On 10/3/19 9:45 AM, Martin Kolman wrote:
Also, the current changelogs are self contained & do not require internet
access.
Remote changelog URLs might become inaccessible over time, making tracking down
behavior changes & tricky bugs problematic.
Yes, there are systems that do not have
On Wed, Oct 2, 2019 at 9:20 PM Neal Gompa wrote:
>
> Unfortunately, it doesn't scale for the large number of packages we
> have. Pull requests would work if we had mergify[1] working on
> Dist-Git, otherwise I can't see how it'd work.
>
> [1]: https://github.com/Mergifyio/mergify-engine
>
>
On Thu, Oct 03, 2019 at 10:19:40AM -0500, Chris Adams wrote:
> The other thing that makes source code changelogs less useful in some
> cases is that they are often very verbose, with info that isn't clear to
> end users. They show changes that are often not relevant (like maybe
> between release
On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote:
> On Wed, 2 Oct 2019 at 19:34, Matthew Miller
> wrote:
>
> > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
> > > > ○ Every changes to dist-git is done via pull-requests
> > > Erm, no thank you. Pull requests
Troy,
Thanks for the reply, much appreciated! I look forward to seeing the
patches getting integrated into RHEL 7.
On Thu, Oct 3, 2019 at 10:26 AM Troy Dawson wrote:
> On Thu, Oct 3, 2019 at 7:54 AM Steve Siirila wrote:
> >
> > When will opendmarc fixes made nearly two years ago make it into
On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> I even go as far as reverting branch-only commits and then doing the
> bidirectional merge trick to restore fast forwardability. That of
> course
> clobbers the branch-only changelog section and replaces it with the
> one from
> master,
On Thu, 3 Oct 2019 at 11:20, Vít Ondruch wrote:
>
>
> Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a):
> > On 03. 10. 19 15:23, Vít Ondruch wrote:
> >>
> >> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
> >>> Miro Hrončok wrote:
> On 03. 10. 19 1:32, Kevin Fenzi wrote:
> > I'm not sure
On Thu, Oct 3, 2019 at 7:54 AM Steve Siirila wrote:
>
> When will opendmarc fixes made nearly two years ago make it into EPEL for
> RHEL 7? We pretty much have had to hold off running it as it crashes
> whenever we receive email from a site with a malformed DMARC TXT record. A
> patch has
Once upon a time, Daniel P. Berrangé said:
> I think having a record of upstream SCM would be useful regardless. Many
> times when submitting patches to Fedora packages, I've been told to send
> my patch to upstream insteadwhich means trying to figure out where
> that upstream is for this
Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a):
> On 03. 10. 19 15:23, Vít Ondruch wrote:
>>
>> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
>>> Miro Hrončok wrote:
On 03. 10. 19 1:32, Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different
> spec
On Thu, Oct 03, 2019 at 09:37:31AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé said:
> > Or just add some RPM metadata tags to record the upstream SCM type + URL +
> > branch / release tag, etc. The user can thus easily find the upstream
> > full commit logs corresponding to
When will opendmarc fixes made nearly two years ago make it into EPEL for
RHEL 7? We pretty much have had to hold off running it as it crashes
whenever we receive email from a site with a malformed DMARC TXT record. A
patch has been available for nearly two years now.
On Thu, Oct 03, 2019 at 07:37:09AM -0700, Troy Dawson wrote:
> In my opnion, bad idea. We should be using koschei [1] for that.
> Two reasons it's a bad idea.
> 1 - Since Stream is be definition, changing, you will not easily know
> what an EPEL package is built against.
Well, it's changing, but
On Thu, 2019-10-03 at 09:37 -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé said:
> > Or just add some RPM metadata tags to record the upstream SCM type + URL +
> > branch / release tag, etc. The user can thus easily find the upstream
> > full commit logs corresponding to the
On Thu, Oct 03, 2019 at 09:16:15AM -0500, Chris Adams wrote:
> > I think rather than this, we should bite the bullet and remove changelogs
> > entirely from spec files.
> I find "rpm -q --changelog" useful (at least when maintainers put useful
> info there, which isn't always), so please don't.
Ben,
I'm in Colorado, but absolutely willing to travel to Ohio to help staff the
booth... I don't know if there is budget for travel, but if there is, and
there is no one closer who wants to help, let me know! :)
Geoff Marr
IRC: coremodule
On Wed, Oct 2, 2019 at 1:48 PM Ben Cotton wrote:
> I
On 10/3/19 10:29 AM, Daniel P. Berrangé wrote:
On Thu, Oct 03, 2019 at 10:21:37AM -0400, David Cantrell wrote:
On 10/3/19 10:16 AM, Chris Adams wrote:
Once upon a time, Matthew Miller said:
I think rather than this, we should bite the bullet and remove changelogs
entirely from spec files.
Once upon a time, Daniel P. Berrangé said:
> Or just add some RPM metadata tags to record the upstream SCM type + URL +
> branch / release tag, etc. The user can thus easily find the upstream
> full commit logs corresponding to the pacakge.
IMHO that is only good when the Fedora package is
On Thu, Oct 3, 2019 at 7:05 AM Matthew Miller wrote:
>
> On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
> > After the announcement today of centos-stream, I wonder if it would make
> > sense to move epel8-playground to build against that instead of the
> > latest rhel8 release?
>
>
On Thu, Oct 03, 2019 at 10:21:37AM -0400, David Cantrell wrote:
> On 10/3/19 10:16 AM, Chris Adams wrote:
> > Once upon a time, Matthew Miller said:
> > > I think rather than this, we should bite the bullet and remove changelogs
> > > entirely from spec files.
> >
> > I find "rpm -q --changelog"
On Thu, 3 Oct 2019 at 05:50, Kevin Kofler wrote:
>
> Stephen John Smoogen wrote:
> > OK at the moment it looks like we seem to average 311,000 ip addresses
> > per day doing a daily checkin for Fedora. Out of those ~13,400 are
> > x86_32. The majority of the x86_32 are pre-F28 with only about
On 03. 10. 19 16:16, Chris Adams wrote:
Once upon a time, Matthew Miller said:
I think rather than this, we should bite the bullet and remove changelogs
entirely from spec files.
I find "rpm -q --changelog" useful (at least when maintainers put useful
info there, which isn't always), so
On 10/3/19 10:16 AM, Chris Adams wrote:
Once upon a time, Matthew Miller said:
I think rather than this, we should bite the bullet and remove changelogs
entirely from spec files.
I find "rpm -q --changelog" useful (at least when maintainers put useful
info there, which isn't always), so
Once upon a time, Matthew Miller said:
> I think rather than this, we should bite the bullet and remove changelogs
> entirely from spec files.
I find "rpm -q --changelog" useful (at least when maintainers put useful
info there, which isn't always), so please don't.
--
Chris Adams
On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
> After the announcement today of centos-stream, I wonder if it would make
> sense to move epel8-playground to build against that instead of the
> latest rhel8 release?
This is something we're talking about at the CentOS Stream kickoff
On 03. 10. 19 15:23, Vít Ondruch wrote:
Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
Miro Hrončok wrote:
On 03. 10. 19 1:32, Kevin Fenzi wrote:
I'm not sure how to handle the dychomoty between having different spec
files for each release and wanting to maintain just one spec that has a
On Thu, Oct 03, 2019 at 09:51:01AM -0400, Matthew Miller wrote:
> On Thu, Oct 03, 2019 at 02:47:27PM +0100, Daniel P. Berrangé wrote:
> > FWIW, my approach is to purge all changelog entries older than 2 years
> > the first time I touch a package in January each year. Is there any value
> > in
On Thu, Oct 03, 2019 at 02:47:27PM +0100, Daniel P. Berrangé wrote:
> FWIW, my approach is to purge all changelog entries older than 2 years
> the first time I touch a package in January each year. Is there any value
> in having guidelines to encourage some policy in this area, so maintainer
>
On Thu, Oct 03, 2019 at 09:23:16AM -0400, Josh Boyer wrote:
> On Thu, Oct 3, 2019 at 9:21 AM Vitaly Zaitsev via devel
> wrote:
> >
> > Hello all.
> >
> > Is it possible to remove old %changelog entries from SPECs? I can't find
> > information about this in Fedora packaging guidelines.
>
> Yes.
On Thu, Oct 03, 2019 at 03:40:43PM +0200, Miroslav Suchý wrote:
> Rpmbuild actually removes all entries older than %_changelog_trimtime
> In Fedora this macro is defined as
> -13: _changelog_trimtime%{lua:print(os.time() - 2 * 365 * 86400)}
> I.e. everything older than 2 years is discarded
On Thu, Oct 03, 2019 at 02:45:20PM +0200, Vitaly Zaitsev via devel wrote:
> Hello all.
>
> Is it possible to remove old %changelog entries from SPECs? I can't find
> information about this in Fedora packaging guidelines.
>
> All history still can be found in git log.
We already set an rpm
Dne 03. 10. 19 v 14:45 Vitaly Zaitsev via devel napsal(a):
Hello all.
Is it possible to remove old %changelog entries from SPECs? I can't find
information about this in Fedora packaging guidelines.
All history still can be found in git log.
Rpmbuild actually removes all entries older than
Dne 03. 10. 19 v 14:35 Matthew Miller napsal(a):
> On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote:
>> I'm not sure how to handle the dychomoty between having different spec
>> files for each release and wanting to maintain just one spec that has a
>> bunch of crazy conditionals in
Dne 03. 10. 19 v 12:18 Miro Hrončok napsal(a):
Then obviously, people start inventing %if spaghetti.
Nope,
%if spaghetti
comes from people who are upstream author of some project (usually layered application) and have to support the packages
(usually cli tools for their project) for all
On Thu, Oct 03, 2019 at 02:45:20PM +0200, Vitaly Zaitsev via devel wrote:
> Is it possible to remove old %changelog entries from SPECs? I can't find
> information about this in Fedora packaging guidelines.
> All history still can be found in git log.
Whether or not it's documented policy (and I
On Thu, Oct 3, 2019 at 9:21 AM Vitaly Zaitsev via devel
wrote:
>
> Hello all.
>
> Is it possible to remove old %changelog entries from SPECs? I can't find
> information about this in Fedora packaging guidelines.
Yes.
josh
>
> All history still can be found in git log.
>
> --
> Sincerely,
>
Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a):
> Miro Hrončok wrote:
>> On 03. 10. 19 1:32, Kevin Fenzi wrote:
>>> I'm not sure how to handle the dychomoty between having different spec
>>> files for each release and wanting to maintain just one spec that has a
>>> bunch of crazy conditionals in
Hello all.
Is it possible to remove old %changelog entries from SPECs? I can't find
information about this in Fedora packaging guidelines.
All history still can be found in git log.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On Thu, Oct 03, 2019 at 11:52:32AM +0200, Kevin Kofler wrote:
> Have you seen my reply elsewhere in this thread?
I did, thanks. And I can see that as a fine model too. Looking for more
ideas from Richard as well.
> What is clear is that submitting pull requests to myself does not make any
>
On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different spec
> files for each release and wanting to maintain just one spec that has a
> bunch of crazy conditionals in it. Even thought I do this too, I think
> we need a
On Wed, 2019-10-02 at 14:44 -0400, Colin Walters wrote:
>
> On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote:
>
> > As others in the thread have pointed out, mandatory pull requests just
> > make no sense for most single-maintainer projects, which most packages
> > probably are.
>
> Well,
-- Forwarded message -
From: Kenneth Topp
Date: Thu, Oct 3, 2019 at 2:31 AM
Subject: [rpms/future] PR #5: re-enable future for python2
To:
toppk opened a new pull-request against the project: `future` that you are
following:
``
re-enable future for python2
``
To reply, visit
This is the Minimization Objective [0] update.
Status: Discovery phase
== Next phase definition ==
I'm putting together a proposal for the next phase approval. I've made a
Logic Model [1] so far, more is coming soon. See the issue [2] to get more
updates and to give feedback which is very
Hello mostly Bcced maintainers of packages impacted by this.
I maintain python-unittest2, a backport of the standard library unittest module
from Python 3 to Python 2 (mostly) [1].
We are removing python2-unittest2 soon, as nothing depends on it any more [2].
I'd retire the package, as it
On 03. 10. 19 11:58, Kevin Kofler wrote:
I don't understand the people actually maintaining different changelogs for
the releases. I just merge master into the release branches when I push an
update, and if that includes some changelog entries for Rawhide-only mass
rebuilds, so be it. Removing
Reposting message to initscripts-devel:
Hi,
A slight modification to the postgresql startup script:
postgresql.log.1 is the output from systemctl status postgresql before
applying the drop-in.
postgresql.log.2 is the output from systemctl status postgresql after
applying the drop-in.
On Thu, Oct 3, 2019 at 5:51 AM Kevin Kofler wrote:
> How about we just reverse-engineer what those blobs do and reimplement
> them
> as Free Software?
>
If I'm reading the comments right in the bugzilla report linked above, it
sounds like Lenovo is going to do the right thing and put out an
Kevin Fenzi wrote:
> I'm not sure how to handle the dychomoty between having different spec
> files for each release and wanting to maintain just one spec that has a
> bunch of crazy conditionals in it. Even thought I do this too, I think
> we need a workflow that discourages this somehow.
I
Miro Hrončok wrote:
> On 03. 10. 19 1:32, Kevin Fenzi wrote:
>> I'm not sure how to handle the dychomoty between having different spec
>> files for each release and wanting to maintain just one spec that has a
>> bunch of crazy conditionals in it. Even thought I do this too, I think
>> we need a
Matthew Miller wrote:
> Do you have an alternative proposal?
Have you seen my reply elsewhere in this thread?
I wrote there:
> You need a different CI approach. Maybe:
> * a push hook that just locks the repository and does the tests before
> validating the push, though I can see that
Stephen John Smoogen wrote:
> OK at the moment it looks like we seem to average 311,000 ip addresses
> per day doing a daily checkin for Fedora. Out of those ~13,400 are
> x86_32. The majority of the x86_32 are pre-F28 with only about 3400
> (about 14% of total x86_32 and ~1% of all Fedora users)
Stephen Gallagher wrote:
> So, looking at the license of that tool, it seems to be fine to
> redistribute it unmodified... so what if we wrote a tool that would
> run the `acpidump` and `acpixtract` locally, submit it to a very
> simple web service and get back the config file for their system?
On 03. 10. 19 1:32, Kevin Fenzi wrote:
I'm not sure how to handle the dychomoty between having different spec
files for each release and wanting to maintain just one spec that has a
bunch of crazy conditionals in it. Even thought I do this too, I think
we need a workflow that discourages this
On 02. 10. 19 16:16, laurent.rineau__fed...@normalesup.org wrote:
On Wednesday, October 2, 2019 3:19:09 PM CEST Miro Hrončok wrote:
On 01. 10. 19 18:47, laurent.rineau__fed...@normalesup.org wrote:
With CGAL-5.0, CGAL is becoming a header-only C++ library of templates.
That means that CGAL
On 10/2/19 8:33 PM, Matthew Miller wrote:
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
It's definitely the winning workflow in the open source world today,
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
> > I'm going to ask again what was in my original email: What is your ideal
> > workflow? How do you think things should work?
> > Is what we have today the ideal state of things?
> > If so, great!
> > If not, what can we improve and are
On 2019-10-02 16:45, Fabio Valentini wrote:
On Wed, Oct 2, 2019 at 3:07 AM Brian (bex) Exelbierd
wrote:
On Tue, Oct 1, 2019 at 10:05 AM Pavel Valena wrote:
- Original Message -
From: "Jun Aruga"
To: "Development discussions related to Fedora"
Cc: "Fedora Infrastructure"
Sent:
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-10-03 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2019-10-03 09:00 PDT US/Pacific
2019-10-03
https://bugzilla.redhat.com/show_bug.cgi?id=1758050
Bug ID: 1758050
Summary: Upgrade perl-Test-TCP to 2.21
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Test-TCP
Assignee: rc040...@freenet.de
On Wed, Oct 2, 2019 at 11:21 PM Jared K. Smith wrote:
>
> On Wed, Oct 2, 2019 at 9:32 AM Jared K. Smith
> wrote:
>>
>> I blindly assumed it had been eight weeks already, so I requested a
>> re-review at RHBZ#1755147. Obviously I'll just close that review request if
>> we can get this
98 matches
Mail list logo
