Hi Martin,
I was quite busy lately so did not have time to reply.
(Most of the time I'll speak for Rust ecosystem below)
On Fri, Feb 21, 2020 at 4:06 PM Martin Sehnoutka wrote:
>
> Hi,
>
> before I write the proposal itself I just want to stress the fact that
> it isn’t my intention to change t
Le 2020-02-26 09:50, Martin Sehnoutka a écrit :
Hi,
Hi,
Go package management:
I know that Go has a package management now, but the question is if
upstream communities are going to adopt it.
Upstream communities won’t have any choice if they want their software
to be trusted by third partie
Hi,
thank you all for your input! I have few notes:
Review process:
I don't think that the review process is a problem. It is independent of
the file format we use. I mean we can have regular review process and
store the package in a tarball as well as we do it with RPM.
Go package managemen
On Tue, Feb 25, 2020 22:26:24 -0500, Randy Barlow wrote:
> On 2/25/20 3:12 PM, Ankur Sinha wrote:
> > Basically, packages do not pass review merely because they use good
> > licenses.
>
> Note that I just said that I thought it was the primary purpose, not
> the only purpose.
Sure, but I'm arguin
On 2/25/20 3:12 PM, Ankur Sinha wrote:
Basically, packages do not pass review merely because they use good
licenses.
Note that I just said that I thought it was the primary purpose, not the
only purpose.
___
devel mailing list -- devel@lists.fedorap
On Tue, Feb 25, 2020 14:41:34 -0500, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > > One thing that comes to my mind with this proposal is that we still need
> > > some way to vet licenses. Today, this is done via the package review
> > > process, and in m
On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > One thing that comes to my mind with this proposal is that we still need
> > some way to vet licenses. Today, this is done via the package review
> > process, and in my mind is the primary purpose of package review. If we
> > started
On Mon, Feb 24, 2020 at 02:46:02PM +0100, Vitaly Zaitsev via devel wrote:
> On 24.02.2020 13:41, Miroslav Suchý wrote:
> > Yes. But it is only rpm-build what cannot access network. Mock itself can
> > access network.
>
> Mock is using Internet connection only for downloading metadata and
> packag
On 24.02.2020 13:41, Miroslav Suchý wrote:
> Yes. But it is only rpm-build what cannot access network. Mock itself can
> access network.
Mock is using Internet connection only for downloading metadata and
packages from repositories. Then it use systemd-nspawn to create a
protected isolated contai
- Original Message -
> From: "Fabio Valentini"
> To: "Development discussions related to Fedora"
>
> Sent: Friday, February 21, 2020 4:46:52 PM
> Subject: Re: Include non-RPM content in buildroot
>
> On Fri, Feb 21, 2020 at 3:58 PM Martin Sehn
Dne 24. 02. 20 v 11:17 Vitaly Zaitsev via devel napsal(a):
> All packages must be build with disabled network access to ensure, that
> it use packaged dependencies and not downloaded from outside.
Yes. But it is only rpm-build what cannot access network. Mock itself can
access network.
In other
On Fri, Feb 21, 2020 10:11:47 -0500, Randy Barlow wrote:
> On 2/21/20 9:57 AM, Martin Sehnoutka wrote:
> > Every time there is a new release it would automatically synchronize our
> > own Fedora-specific registry, which would in turn be accessible in
> > buildroot.
>
> One thing that comes to my m
On 24.02.2020 10:55, Miroslav Suchý wrote:
> Additionally, even when the build in Koji (or Mock in general) is offline,
> the dependencies are installed with internet
> enabled. If you teach Mock how to call native crate/rubygem/.. before the
> actual build start, you will have most of the
> work
Dne 21. 02. 20 v 15:57 Martin Sehnoutka napsal(a):
> This process is unfortunately not fully automated and therefore requires a
> certain amount of human effort.
This is an important sentence. Let's save it for later as [1]
> The proposal itself is fairly simple: Let’s stop packaging all Go and
On Fri, Feb 21, 2020 at 3:58 PM Martin Sehnoutka wrote:
>
> Hi,
Hi!
I think several of your assumptions are not necessarily correct, which
might lead to wrong conclusions.
My responses are inline below.
> before I write the proposal itself I just want to stress the fact that
> it isn’t my inten
On Fri, 21 Feb 2020 at 09:58, Martin Sehnoutka wrote:
>
> Hi,
>
> before I write the proposal itself I just want to stress the fact that
> it isn’t my intention to change the current packaging workflow and
> definitely not the user experience. Also if you have C or Python
> packages it would not a
Le vendredi 21 février 2020 à 15:57 +0100, Martin Sehnoutka a écrit :
> Hi,
Hi,
> Go went even further in this case and it is
> common
> to bundle all the dependencies as a source code directly in the
> upstream
> repository. See this repo as an example:
> https://github.com/containers/libpod/
On 2/21/20 9:57 AM, Martin Sehnoutka wrote:
Every time there is a new release it would automatically synchronize our
own Fedora-specific registry, which would in turn be accessible in
buildroot.
One thing that comes to my mind with this proposal is that we still need
some way to vet licenses.
Hi,
before I write the proposal itself I just want to stress the fact that
it isn’t my intention to change the current packaging workflow and
definitely not the user experience. Also if you have C or Python
packages it would not affect your work at all (I’m not familiar with all
interpreted l
19 matches
Mail list logo
