On Thursday, September 26, 2019 6:26:33 AM CEST Pavel Raiskup wrote:
> On Thursday, September 26, 2019 12:32:58 AM CEST Stephen John Smoogen wrote:
> > On Wed, 25 Sep 2019 at 17:32, Omair Majid wrote:
> > > But I know lttng-ust-devel exists in RHEL 8. It was also built by CentOS
> > > 8 here: http
Hello,
On Thu, Sep 26, 2019, at 13:28, Jiri Hladky wrote:
> I'm trying to contact Hannes Frederic Sowa, maintainer of datamash package:
>
> https://src.fedoraproject.org/user/stressinduktion
> https://src.fedoraproject.org/rpms/datamash
>
> I have started the nonresponsive maintainer process due
I second this notion. As I recall, the only thing in the way of the
MPFR 4 update was a circular dependency on the libmpc package I
maintain, and allowing the userbase to catch up to the API change.
It's been a while now, and it would be nice to get this change rolling.
--
James Paul Turner
Dep
Hi all,
I'm working on (learning modularity) and developing a module for my package
and created a not-so-great (super long) branch name in the dist-git rpm and
module repo before I realized that it would be the stream's name too. Also,
it seems that the incomplete module was picked up and included
Christopher writes:
> I just don't see this proposed workflow as solving the biggest
> problems that packagers face. For me, I think the biggest problem that
> packagers (particularly newer packagers) face is discovery of all the
> services involved in the packaging workflow, and the need to visi
* Pierre-Yves Chibon [26/09/2019 16:07] :
>
> When we work on upstream projects, I think it's pretty standard now to always
> go
> via PRs, even for your own branch.
FWIW, this workflow makes sense for one that has a community but it sounds very
strange to do this on a project on which you are th
Randy Barlow writes:
> This suggestion gives a nice clean place to write the bodhi update
> description, right in git. The commit messages can remain the way they
> are today: authored for the audience of spec file contributors.
>
> We could also support special syntax in the tag message to allow
On Thu, 26 Sep 2019 at 16:46, Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > Allow packagers to have a clone of the upstraem git repo
>
> - What about the upstream projects that still only publish a tarball at
> release?
What about upstream
Daniel P. Berrangé writes:
> On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
>
> For packages I maintain, my preference is to touch dist-git as little
> as possible. Ideally I would never touch dist-git at all & rather wish
> it didn't exist at all in its current form of spec+
On 26. 09. 19 22:06, Jason L Tibbitts III wrote:
"C" == Christopher writes:
C> With version-controlled package sources, changelogs in SPEC seem so
C> obsolete to me. They are already problematic today when they conflict
C> due to changes in multiple branches.
It's important to note that the
On 26. 09. 19 11:36, Pierre-Yves Chibon wrote:
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
If we go this way, there must be a way to disable this or to dictate what side
tag this needs to be built in.
I remember that during the Python 3.8 rebuilds in the side ta
On 26. 09. 19 21:47, Randy Barlow wrote:
On Thu, 2019-09-26 at 19:05 +, Jeremy Cline wrote:
The tag also provides a nice place to write release notes for the
update. I suppose you could also add support for some sort of text
tag
inside commits (like when you mark a commit as fixing an issue
On 26. 09. 19 22:37, Tristan Cacqueray wrote:
Note that git-pull-requests now support pagure. The tool takes care of
creating the fork, pushing the local changes and opening the PR:
https://github.com/Mergifyio/git-pull-request
Will definitively test this soon, thanks!
If it works, we shoul
Hello all,
I've been working with RHEL and CentOS packages since about 2011, but mostly in
the domain of private Yum repositories. I've done some work in the past with the
SUSE Build Service also. I'm familiar with Redhat/Fedora packaging guidelines
but not with Fedora-specific development tooling.
On Thu, Sep 26, 2019 at 15:49 Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 03:40:49PM +0200, Miroslav Suchý wrote:
>> Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
>> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écr
On Thu, 2019-09-26 at 20:55 +0200, Hans de Goede wrote:
> Hi Tom,
>
> On 26-09-2019 20:47, Tom Stellard wrote:
> > On 09/26/2019 11:24 AM, Adam Williamson wrote:
> > > On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
> > > > On 09/26/2019 11:03 AM, Adam Williamson wrote:
> > > > > We are cur
On Thu, 2019-09-26 at 20:51 +0200, Hans de Goede wrote:
>
> OTOH we also want F31 to work with current hardware when it ships;
> and llvm is kinda special in this regard, its main use in Fedora
> is inside the graphics stack and mesa needs llvm9 to support the
> AMD Radeon 5700 series cards which
> "C" == Christopher writes:
C> With version-controlled package sources, changelogs in SPEC seem so
C> obsolete to me. They are already problematic today when they conflict
C> due to changes in multiple branches.
It's important to note that the RPM changelog is rather a different
thing from
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> > ○ Every commit to dist-git (ie: PR merged) is automatically built
> > in koji
> > ○ Every build in koji results automatically in an update in bodhi
>
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don'
On Thu, 2019-09-26 at 19:05 +, Jeremy Cline wrote:
> The tag also provides a nice place to write release notes for the
> update. I suppose you could also add support for some sort of text
> tag
> inside commits (like when you mark a commit as fixing an issue in
> Git{Lab,Hub} and look at the co
On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:
> On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> > The combination of these two makes no sense to me. I do plenty of
> > work
> > where I don't want to build it (specfile cleanup, patches,
> > configuration
> > changes, etc.).
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don't want to build it (specfile cleanup, patches,
> configuration
> changes, etc.). I want a build that goes to users be explicit.
>
> A better model, in my
Hi Tom,
On 26-09-2019 20:47, Tom Stellard wrote:
On 09/26/2019 11:24 AM, Adam Williamson wrote:
On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
On 09/26/2019 11:03 AM, Adam Williamson wrote:
We are currently in the "Beta to Pre Release" phase of the release
cycle. The updates policy fo
Hi,
On 26-09-2019 20:24, Adam Williamson wrote:
On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
On 09/26/2019 11:03 AM, Adam Williamson wrote:
We are currently in the "Beta to Pre Release" phase of the release
cycle. The updates policy for this phase -
https://fedoraproject.org/wiki/Upd
On Thu, 2019-09-26 at 08:58 -0700, Brian C. Lane wrote:
> I'm also not clear on where the .spec files and tests would live if
> you
> are using a fork of the upstream. We still need dist-git to store
> those,
> even if everything that touches them is a tool other than vim. Or
> maybe
> I missed som
Thanks!
On Thu, Sep 26, 2019 at 10:31 AM Adrian Reber wrote:
> On Thu, Sep 26, 2019 at 09:34:11AM -0500, Steven Munroe wrote:
> > Wed, 25 Sep 2019 11:38:45 -0700 Kevin Fenzi wrote
> >
> > >> Can you now try:
> > >>
> > >> curl -v
> > '
> https://download-ib01.fedoraproject.org/pub/fedora-second
https://bugzilla.redhat.com/show_bug.cgi?id=1756098
Emmanuel Seyman changed:
What|Removed |Added
Blocks||1744709
Referenced Bugs:
https://
On 09/26/2019 11:24 AM, Adam Williamson wrote:
> On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
>> On 09/26/2019 11:03 AM, Adam Williamson wrote:
>>> We are currently in the "Beta to Pre Release" phase of the release
>>> cycle. The updates policy for this phase -
>>> https://fedoraproject.
On Thu, Sep 26, 2019 at 09:08:16AM -0700, Adam Williamson wrote:
> On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:
> >
> > Ah right, that makes a lot of sense.
> >
> > I can imagine automatically detecting the new upstream release, building
> > that, and presenting the packager with a easy
On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote:
>
> Pierre-Yves Chibon writes:
>
> > Here is what the vision we came to and that we would like to discuss:
> >
> > ○ Every changes to dist-git is done via pull-requests
> > ○ Pull-requests are automatically tested
> > ○ Every commit to dist-g
On Thu, Sep 26, 2019 at 01:22:03PM -0400, Robert Marcano via devel wrote:
> On 9/26/19 12:57 PM, Ken Dreyer wrote:
> > On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > > Le 26/09/2019 à 11:36, Pierre-Yves
On Thu, 2019-09-26 at 11:20 -0700, Tom Stellard wrote:
> On 09/26/2019 11:03 AM, Adam Williamson wrote:
> > We are currently in the "Beta to Pre Release" phase of the release
> > cycle. The updates policy for this phase -
> > https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
> >
On Thu, 2019-09-26 at 20:13 +0200, Igor Gnatenko wrote:
> Well, we have updated LLVM to next major version even before
> mid-cycle.
I didn't check exactly when this happened before, but note there is a
significant difference between different parts of the cycle. There are
different rules for the p
On 09/26/2019 11:03 AM, Adam Williamson wrote:
> We are currently in the "Beta to Pre Release" phase of the release
> cycle. The updates policy for this phase -
> https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
> says:
>
> "From this point onwards maintainers MUST[1]:
>
>
Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>> > Here is what the vision we came to and that we would like to discuss:
>> >
>> > ○ Every changes to dist-git is done via pull-requests
>>
>> IMHO Hav
Well, we have updated LLVM to next major version even before
mid-cycle. Since it is important for graphics stack. Compatibility
package was always created. On the other hand, it requires proper
coordination with other package maintainers.
tl;dr I think it is fine to do rebase before F31 Final, but
We are currently in the "Beta to Pre Release" phase of the release
cycle. The updates policy for this phase -
https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -
says:
"From this point onwards maintainers MUST[1]:
Avoid Major version updates, ABI breakage or API changes if at
On Thu, Sep 26, 2019 at 8:33 AM Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora but the
Pierre-Yves Chibon writes:
> Here is what the vision we came to and that we would like to discuss:
>
> ○ Every changes to dist-git is done via pull-requests
> ○ Pull-requests are automatically tested
> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
> ○ Every build in ko
On 9/26/19 12:57 PM, Ken Dreyer wrote:
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
Here is what the vision we came to and that we would like to discuss:
○ Every cha
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is
* Unclear work-
On 9/26/19 7:07 AM, Pierre-Yves Chibon wrote:
When we work on upstream projects, I think it's pretty standard now to always go
via PRs, even for your own branch.
So that tests are run, so that other member of the community can see, comment,
review the change.
What is so differen
On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> > wrote:
> > > There is a clear initial rejection of a PR-only contribution model. I
> > > hear that
> > > and that
On 9/26/19 9:07 AM, Pierre-Yves Chibon wrote:
What is so different in Fedora that we cannot move to this model?
Is it a tooling issue?
Is it something else?
As others have already stated that may work in projects with tens, hundreds, or
thousands of contributors, but most of Fedora packages ar
On 9/26/19 10:28 AM, Pierre-Yves Chibon wrote:
Would this change if the PR was automatically tested for you without you having
to do anything?
I always run local mock builds prior to commits. Maybe not everyone likes to do this
and wants Koji to do it for them, but I prefer local mock builds.
Hello everyone!
The logs for the NeuroFedora team meeting on 26th September are linked below:
- HTML Logs:
https://meetbot.fedoraproject.org/fedora-neuro/2019-09-26/neurofedora.2019-09-26-15.01.log.html
- HTML Minutes:
https://meetbot.fedoraproject.org/fedora-neuro/2019-09-26/neurofedora.2
On Thu, 2019-09-26 at 15:46 +, Jeremy Cline wrote:
>
> Ah right, that makes a lot of sense.
>
> I can imagine automatically detecting the new upstream release, building
> that, and presenting the packager with a easy-to-review PR that you just
> click "merge" on instead of pointing the specfi
On 9/26/19 11:14 AM, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
>>
>> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
>>> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
>>> wrote:
On Thu, Sep 26, 2019 at 02:57:45PM +0100, D
On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
[snip]
> Allow packagers to have a clone of the upstraem git repo, and use the
> pull-requests and run Fedora CI testing against the Fedora branch of
> the upstream repo instead of against dist-git.
>
> In this way, maintaining
On Thu, Sep 26, 2019 at 05:14:59PM +0200, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
> >
> > On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> > > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > >
> > > > On Thu, Se
On Thu, Sep 26, 2019 at 09:34:11AM -0500, Steven Munroe wrote:
> Wed, 25 Sep 2019 11:38:45 -0700 Kevin Fenzi wrote
>
> >> Can you now try:
> >>
> >> curl -v
> 'https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/'
>
> Attached file curlv.homer54.txt
On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> wrote:
> > There is a clear initial rejection of a PR-only contribution model. I hear
> > that
> > and that may mean that we never go this way. I'm honestly fine with that :)
> > I
On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkone...@redhat.com wrote:
> On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote:
> > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote:
[snip]
> > With an updates.img solution like you are describing here is there
> > anything
> > to
On Thu, Sep 26, 2019 at 4:57 PM Jeremy Cline wrote:
>
> On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> > On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > > Instead I pre
On 26.09.2019 15:10, Pierre-Yves Chibon wrote:
> What makes it a headache? What can we do to not have this be a terrible
> headache? Can we fix/improve the tooling?
I'm not going to log in into web, create a new pr, then merge it. This
is a terrible idea. Do not change current workflow.
--
Since
On 26.09.2019 11:36, Pierre-Yves Chibon wrote:
> ○ Every changes to dist-git is done via pull-requests
No way! This is a terrible idea.
> ○ Every build in koji results automatically in an update in bodhi
Not good too.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
_
On Thu, Sep 26, 2019 at 4:50 PM Fabio Valentini wrote:
>
> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > branch wi
On Thu, Sep 26, 2019 at 04:16:46PM +0200, Fabio Valentini wrote:
> > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
>
> I don't think this is wise. On the one hand, it will create even more
> workload in koji, and on the other hand, running "fedpkg build" for
> things I
On Thu, Sep 26, 2019 at 04:49:31PM +0200, Fabio Valentini wrote:
> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > br
On 26. 09. 19 11:36, Pierre-Yves Chibon wrote:
○ Every changes to dist-git is done via pull-requests
I like this idea, however as other has pointed out, it needs to be much smoother
experience than now.
See for example this RFE:
number 3)
https://lists.fedoraproject.org/archives/list/devel
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > Instead I prefer a clone of the master upstream git repo and maintain a
> > branch with patches cherry-picked into it. This is used to auto-generate
> > pa
On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon wrote:
> There is a clear initial rejection of a PR-only contribution model. I hear
> that
> and that may mean that we never go this way. I'm honestly fine with that :)
> I do want to see why that is a show-stopper and if we can find ways to not
On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> Instead I prefer a clone of the master upstream git repo and maintain a
> branch with patches cherry-picked into it. This is used to auto-generate
> patches for the Fedora RPM, at the same time updating the patch file list
> in t
On Thu, Sep 26, 2019 at 04:07:59PM +0200, Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 08:47:24AM -0500, Michael Cronenworth wrote:
> > On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
> > > Again, I'd like to reinforce that the idea is not to enforce any part of
> > > this
> > > workflow tomo
Wed, 25 Sep 2019 11:38:45 -0700 Kevin Fenzi wrote
>> Can you now try:
>>
>> curl -v
'https://download-ib01.fedoraproject.org/pub/fedora-secondary/development/31/Everything/ppc64le/os/'
Attached file curlv.homer54.txt
>> (Note that that mirror has a ipv6 address, so if you have a routable
>> ipv
On Thu, Sep 26, 2019 at 04:24:29PM +0200, Pierre-Yves Chibon wrote:
> On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > >
> > > At Flock, a few of us met to discuss a future v
On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> >
> > At Flock, a few of us met to discuss a future vision of the packager
> > workflow.
> > This discussion was triggered by the
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
On Thu, Sep 26, 2019 at 2:32 PM Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
Alright. I don't often reply to discussion threads like this, but here we go.
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization t
On Thu, Sep 26, 2019 at 6:56 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote:
> > On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon
> > wrote:
> > >
> > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > > Le 26/09/2019 à 11:36, Pie
On Thu, Sep 26, 2019 at 08:47:24AM -0500, Michael Cronenworth wrote:
> On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
> > Again, I'd like to reinforce that the idea is not to enforce any part of
> > this
> > workflow tomorrow, it'll be a smooth, slow and long transition. My question
> > is
> > whe
On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
> At Flock, a few of us met to discuss a future vision of the packager workflow.
> This discussion was triggered by the realization that a number of initiatives
> are happening around packaging in Fedora
Le 26/09/2019 à 15:10, Pierre-Yves Chibon a écrit :
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
>> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>>> Here is what the vision we came to and that we would like to discuss:
>>>
>>> ○ Every changes to dist-git is done via pull-re
On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote:
> On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon
> wrote:
> >
> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > > Here is what the vision we came to and
Dne 26. 09. 19 v 11:36 Pierre-Yves Chibon napsal(a):
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
+1
Thou, I would love to have general solution. Not just Fedora-centric. Something which will respect use-case of
On Thu, Sep 26, 2019 at 03:40:49PM +0200, Miroslav Suchý wrote:
> Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
> > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > > Here is what the vision we came to and that we wo
On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote:
Again, I'd like to reinforce that the idea is not to enforce any part of this
workflow tomorrow, it'll be a smooth, slow and long transition. My question is
whether this is a place where we want to go or can we come up with a
different/better one?:)
On Thu, Sep 26, 2019 at 09:14:38AM -0400, Stephen John Smoogen wrote:
> On Thu, 26 Sep 2019 at 09:02, Remi Collet wrote:
> >
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git i
On Thu, Sep 26, 2019 at 01:15:03PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every change
Dne 26. 09. 19 v 15:10 Pierre-Yves Chibon napsal(a):
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
Here is what the vision we came to and that we would like to discuss:
○ Every changes to dist-git is done via pull-requests
IMH
On Thursday, 26 September 2019 15:01:25 CEST Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
>
> > Here is what the vision we came to and that we would like to discuss:
> >
> > ○ Every changes to dist-git is done via pull-requests
>
>
> IMHO Have to stay optional, makin
On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > Here is what the vision we came to and that we would like to discuss:
> >
> > ○ Every changes to dist-git is done via pull-requests
>
> IMHO Have to stay optional, making this ma
On Thu, 26 Sep 2019 at 09:02, Remi Collet wrote:
>
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > Here is what the vision we came to and that we would like to discuss:
> >
> > ○ Every changes to dist-git is done via pull-requests
>
> IMHO Have to stay optional, making this mandatory bei
On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > Here is what the vision we came to and that we would like to discuss:
> >
> > ○ Every changes to dist-git is done via pull-requests
>
> IMHO Have to stay optional, making this ma
No missing expected images.
Failed openQA tests: 5/152 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20190925.n.0):
ID: 458642 Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/458642
ID: 458654 Test: x86_64 universal i
OLD: Fedora-31-20190925.n.0
NEW: Fedora-31-20190926.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 13
Dropped packages:1
Upgraded packages: 35
Downgraded packages: 0
Size of added packages: 83.57 MiB
Size of dropped packages:7.95 MiB
Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> Here is what the vision we came to and that we would like to discuss:
>
> ○ Every changes to dist-git is done via pull-requests
IMHO Have to stay optional, making this mandatory being a terrible headache.
RFemi
___
Good Morning Everyone,
At Flock, a few of us met to discuss a future vision of the packager workflow.
This discussion was triggered by the realization that a number of initiatives
are happening around packaging in Fedora but there is no real shared vision on
what we want the packager UX/workflow t
On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote:
> On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote:
> > Hello everyone,
> >
> > We (the Anaconda installer team) want to solve multiple problems by
> > one
> > solution and we want
> >
> > *YOUR FEEDBACK!*
> >
> >
> > I
On Thu, Sep 26, 2019 at 06:59:37AM -0500, Richard Shaw wrote:
> On Thu, Sep 26, 2019 at 6:35 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
> >
> > The process is streamlined to require fewer steps from the reporter
> > and to provide quicker access to the package.
> > FESCo takes
On Thu, Sep 26, 2019 at 6:35 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
>
> The process is streamlined to require fewer steps from the reporter
> and to provide quicker access to the package.
> FESCo takes care of the weekly reminders through the bug on its tracker.
> It is possibl
A new non-responsive maintainer policy has been approved [1].
This announcement is a bit late because it took a while to update the
documentation and add all the necessary templates in bugzilla.
The new policy is at [2] (diff [3]).
tl;dr:
When a maintainer is not responding to bug reports,
to sta
Hi Fedora,
I'm trying to contact Hannes Frederic Sowa, maintainer of datamash package:
https://src.fedoraproject.org/user/stressinduktion
https://src.fedoraproject.org/rpms/datamash
I have started the nonresponsive maintainer process due to lack of contact
through bugzilla
mail:
https://bugzilla
On 26. 09. 19 12:59, Vít Ondruch wrote:
Dne 26. 09. 19 v 12:19 Miro Hrončok napsal(a):
On 26. 09. 19 12:05, Vít Ondruch wrote:
Arguably, you should s/--whatrequires/--whatdepends/
Why?
Because weak dependencies are depednecies as well?
Right, when trying to figure out if a new version b
Dne 26. 09. 19 v 12:19 Miro Hrončok napsal(a):
> On 26. 09. 19 12:05, Vít Ondruch wrote:
>> Arguably, you should s/--whatrequires/--whatdepends/
>
> Why?
>
Because weak dependencies are depednecies as well?
Vít
___
devel mailing list -- devel@lists.fe
On 26. 09. 19 12:05, Vít Ondruch wrote:
Arguably, you should s/--whatrequires/--whatdepends/
Why?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le..
Dne 25. 09. 19 v 17:21 Miro Hrončok napsal(a):
> On 25. 09. 19 17:10, Todd Zullinger wrote:
>> dnf repoquery -q --qf '%{name}' --archlist=src --releasever=rawhide \
>> --disablerepo='*' --enablerepo=rawhide-source \
>> --whatrequires asciidoctor --whatrequires rubygem-asciidoctor
>
> Whe
I have found thermald unreliable on my Thinkpad X1 Yoga G4 (same mainboard as
the X1 Carbon 7) with an i7-8665U. The laptop is unable to cTDP up to 25W and
throttles at 80 degrees rather than 95 degrees as it does in Windows, even
after extracting the ACPI tables with dptfxtract as per the instr
100 matches
Mail list logo
