Thank you for your feedback.
After some thinking, I've decided to not start the Fedora Change process,
nor to merge these changes.
These changes are not suited for Fedora use cases.
Once again, I appreciate the discussion
On Tue, Dec 19, 2023 at 7:14 PM Tomáš Mráz wrote:
> In my opinion none
I would personally go with the 2 and get closer to the upstream. I agree
with the npm analogy that was made in the conversation.
Furthermore, I don't think that most users, working on Go projects on
Fedora, would even know that we provide different Go envars
to the upstream ones. IMO, they would
I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
As this was the only disputed change in these PRs so far, I plan on merging
both of them into rawhide at the end of this week.
However, if you see any issue with merging this "middle ground" change,
feel free to discuss.
On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé
wrote:
> On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> > provided by cronie and crontabs and swap de
On Wed, Dec 6, 2023 at 1:02 PM Daniel P. Berrangé
wrote:
> On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> > On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> >
> > > The only difference is that if you have populated the cron.deny list,
> >
On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini
wrote:
> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky
> wrote:
> >
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and s
On Wed, Dec 6, 2023 at 12:32 PM Michael J Gruber
wrote:
>
> Thanks, that sounds like the typical things to expect during an upgrade.
> We typically don't even have release notes mentioning this, but it would be
> nice, since it's even a "plus" for F40 (compliance, hardening).
>
> Does that mean
On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber
wrote:
> Hi there,
>
> what is the impact of these changes:
> - Do default installs work the same way as before?
> - Do existing setups (crontabs) keep working?
>
> If yes then I'd consider the permission changes to be fixes, or at least
>
Hi everyone,
For F40 I would like to change file permissions of few files that are
provided by cronie and crontabs and swap deny list for allow list. I'm not
really sure if I should make a change proposal. I figured I'll send an
email first and see the feedback.
The driving force of this change
It is sad to see you go, but I see your point why you are doing this.
Thank you for all your work on git package, it was great collaborating with
you.
All the best,
On Tue, Oct 3, 2023 at 4:25 PM Todd Zullinger wrote:
> Hi,
>
> I'm orphaning all my packages (which I effectively did
> months
I'm not really sure why upstream did this.
I'll take a look and submit a patch to upstream. Thanks for pointing it out.
On Wed, Nov 2, 2022 at 9:31 PM Fabio Valentini wrote:
> On Wed, Nov 2, 2022 at 12:42 PM Ondrej Pohorelsky
> wrote:
> >
> > The missing dependency is pkg-ve
-proc-macro-hack
On Wed, Nov 2, 2022 at 11:24 AM Fabio Valentini
wrote:
> On Wed, Nov 2, 2022 at 11:11 AM Miro Hrončok wrote:
> >
> > On 02. 11. 22 10:48, Ondrej Pohorelsky wrote:
> > > Thanks, that did the trick!
>
> I concur.
> With setuptools_rust, you're pret
:
> On 01. 11. 22 14:01, Ondrej Pohorelsky wrote:
> > Hi,
> >
> > I'm a package maintainer of Breezy [0] in Fedora.
> >
> > Recently in the newest version (3.3.0), which I'm trying to update to,
> upstream
> > started requiring python-setuptools-rust as a B
Hi,
I'm a package maintainer of Breezy [0] in Fedora.
Recently in the newest version (3.3.0), which I'm trying to update to,
upstream started requiring python-setuptools-rust as a BuildRequire,
because they are shipping rio-py package [1]. This is a simple rust input
output library, which
As stated before in Fedora we definitely are against this way of packaging
Go, Rust or pretty much anything else. This however doesn't apply to EPEL,
CentOS or RHEL, where introducing and maintaining huge amount of
dependencies because of one particular package doesn't make sense.
Especially if
Hi,
In the latest git release (2.33.0), upstream stopped shipping
git-multimail. We are currently shipping it in Fedora with git-2.32.0,
but not as a standalone package.
The reason for removing git-multimail from contrib/ is that it might
attract more attention as a standalone project and to
. 20 18:31, Miro Hrončok wrote:
> >> On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
> >>> We are working on dropping Python 2 version of Mercurial in Fedora[0]
> >>> entirely.
> >>>
> >>> Currently there is a working version of Mercurial 5.
note_148341
>
> On Wed, Nov 25, 2020 at 12:07 PM Miro Hrončok wrote:
>>
>> On 11/25/20 5:56 PM, Miro Hrončok wrote:
>> > On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
>> >> We are working on dropping Python 2 version of Mercurial in Fedora[0]
>> &
We are working on dropping Python 2 version of Mercurial in Fedora[0] entirely.
Currently there is a working version of Mercurial 5.6 in COPR[1] that
needs further testing. If anyone who uses Mercurial would be able to
test it and give me some feedback, I would be glad!
Also there is a question
19 matches
Mail list logo
