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
php-geos-1.0.0-
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 univers
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 Conduc
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 'older
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 +01
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 packagi
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) wh
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 being
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,
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 mergeabl
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 packag
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 branch-
* 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 v
> "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 wa
3: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 would help on the
neuro-scripts repo and add them if required (FranciscoD, 15:38:44)
* ACTION: MeWjOr file an issue and investi
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 wi
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 Intern
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
>
>
Sinc
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 1
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 are
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, bu
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 how
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 give
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 t
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 paca
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.
I
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.
I
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 nothin
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 3400
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 pleas
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 pleas
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 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
bunc
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 havin
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
> appr
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.
F
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 variab
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 it.
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 Fedo
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 ca
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,
> Vi
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 i
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 mail
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
> sen
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 workfl
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 t
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 welcom
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 mak
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 th
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.
postgresq
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 upda
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 don't
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 wo
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 becomin
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) o
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?
Ho
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 som
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 lib
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,
p
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
72 matches
Mail list logo
