, which might change with time if it
is unmaintained.
So if anyone from RH or outside would like to step-in and take
maintenance / further development of this project, that would be
welcome. I would probably stick around to some extent and provide any
guidance
top-level git directory
(i.e. next to rpkg.conf).
This will become relevant (for SCM rpkg srpm build method) with f35
builders in Copr.
---
Also if anyone is using the rpkg command-line tool locally, replacing
/etc/rpkg.conf with /etc/rpkg.conf.rpmnew will be needed.
Best regards
clime
On Thu, 1
eam sources
through a git submodule.
Best regards
clime
P.S.: the project is hosted here: https://pagure.io/rpkg-util
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
Thank you all for the kind words!
clime
On Thu, 18 Mar 2021 at 14:49, David Duncan wrote:
>
> Great News! Much appreciated!
>
> David Duncan
> http://about.me/davdunc
>
>
> On Wed, Mar 17, 2021 at 9:37 PM Christoph Karl wrote:
> >
> > Am 14.03.21
Hello,
I have just finished port of libravatar.org service to server provided
by Fedora. Big thanks to the Fedora project for sponsoring libravatar.
Avatars in pagure.io, src.fp.o, Bodhi should now load much faster.
Best regards!
clime
___
devel
On Sun, 14 Feb 2021 at 22:16, Kevin Fenzi wrote:
> On Sun, Feb 14, 2021 at 09:39:01PM +0100, Miro Hrončok wrote:
> >
> > That still means a particular change needs to "bump" the release number
> to a
> > specific value and hence it generates conflicts/mismatch when:
> >
> > - two or more PRs
On Thu, 4 Feb 2021 at 21:12, clime wrote:
> On Thu, 4 Feb 2021 at 19:36, Matthew Miller
> wrote:
>
>> On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote:
>> > > I genuinely wonder if this is due to the launch animation. I know that
>>
On Thu, 4 Feb 2021 at 19:36, Matthew Miller
wrote:
> On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote:
> > > I genuinely wonder if this is due to the launch animation. I know that
> > > subjectively for myself using the Impatience to triple the speed makes
> > > my desktop
On Sat, 30 Jan 2021 at 20:03, Vitaly Zaitsev via devel
wrote:
>
> On 30.01.2021 18:50, clime wrote:
> > Hey, what do you mean by this?
>
> https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/
>
> > Why should scriplets usage be incompatible with immutable F
On Sat, 30 Jan 2021 at 19:48, Fabio Valentini wrote:
>
> On Sat, Jan 30, 2021 at 7:24 PM Peter Boy wrote:
> >
> >
> >
> > > Am 30.01.2021 um 17:45 schrieb Vitaly Zaitsev via devel
> > > :
> > >
> > > On 30.01.2021 16:58, Peter Boy wrote:
> > >> But it’s perfectly usable for Fedora Workstation
On Sat, 30 Jan 2021 at 01:28, Kevin Kofler via devel
wrote:
>
> Michael Catanzaro wrote:
> > Alternative: use automated reverts instead of force pushes, and don't
> > worry about maintaining a clean history.
>
> Sure, it is possible to make an implementation with lower quality of
> implementation
On Sat, 30 Jan 2021 at 16:08, Vitaly Zaitsev via devel
wrote:
>
> On 29.01.2021 09:49, Zdenek Dohnal wrote:
> > I'm currently trying to rewrite the current shell aliases for making
> > Vi/View/Vim use the correct compiled binary based on which Vim package
> > is installed.
>
> Alternatives are
.1 and uploaded
the new sources in about the same time (maybe slightly later) you
opened the pull request.
https://src.fedoraproject.org/rpms/doxygen/commits/master
That probably led to the confusion. Lookaside cache is not populated
just by opening a pull request :).
Best Regards
clime
>
/#DEJUEWXMAZND626D7ZOSOIFHGWSYGPAG
- the problem of generating release by using build system vs. using
just cvs/git was discussed there (Colin Walters vs. Jesse Keating). It
would be interesting to know what people discussing the topic in the
thread think about it today.
clime
On Mon, 4 Jan 2021 at 20:43, Dan Čermák wrote:
>
> clime writes:
>
> > ...snip...
> >> >
> >> > $ preproc-rpmspec pkg.spec.rpkg # prints rendered spec to stdout,
> >> > pkg.spec.rpkg is a spec template
> >>
> >> This would b
more manual on your own
(e.g. invoking git archive and sedding your spec file with the
produced sourcename).
Well, I probably didn't help you much
Anyway, best regards
clime
>
> Thanks,
> Richard
>
> ___
> devel mailing list -- devel@l
...snip...
> >
> > $ preproc-rpmspec pkg.spec.rpkg # prints rendered spec to stdout,
> > pkg.spec.rpkg is a spec template
>
> This would be a viable workaround, but a workaround nevertheless. Since
> I am not frequently rebuilding Fedora rpms outside of mock, koji & copr,
> I cannot tell how much
o actually make good
> decisions on. It is also true that many wish
> we did have sufficiently good data in order
> to make good decisions. Rock, meet hard
> place.
I think we can simply parse server-side access logs to count package
downloads, no?
It won't be probably very p
package update
> and this will probably become the new upstream
> for the fedora libmemcached package
>
>
> Comment / idea ?
For me, the biggest issue always is that I don't know if I should pick
php-memcache or php-memcached plugin...is there any recommendation
regarding t
On Fri, 18 Dec 2020 at 17:03, clime wrote:
>
> On Fri, 18 Dec 2020 at 16:23, James Szinger wrote:
> >
> > On Fri, 18 Dec 2020 00:51:49 +0100
> > clime wrote:
> >
> > > Well, the users here are still packagers here no? I thought the "User"
t;>> 'Vi'. So if you run 'vi --version' it always shows 'VIM'.
> >>>>
> >>>>> In the end I find it incorrect to mislead users by default by telling
> >>>>> them 'Vim works' but Vi is run instead - Vi and Vim don't have the
> >>>>> sa
On Sun, 20 Dec 2020 at 11:39, Miro Hrončok wrote:
>
> On 12/20/20 1:38 AM, clime wrote:
> >> I view this proposal as a risk that the spec files will look a bit more
> >> weird, and the spec files maintenance will start diverging too much.
> >> Everything happenin
On Sun, 20 Dec 2020 at 00:23, Pavel Raiskup wrote:
>
> On Thursday, December 17, 2020 8:05:40 PM CET Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> >
On Sat, 19 Dec 2020 at 20:57, clime wrote:
>
> On Sat, 19 Dec 2020 at 20:07, Dan Čermák
> wrote:
> >
> > clime writes:
> >
> > > On Thu, 17 Dec 2020 at 22:04, James Szinger wrote:
> > >>
> > >> On Thu, 17 Dec 2020 14:05:40 -0500
>
On Sat, 19 Dec 2020 at 20:07, Dan Čermák wrote:
>
> clime writes:
>
> > On Thu, 17 Dec 2020 at 22:04, James Szinger wrote:
> >>
> >> On Thu, 17 Dec 2020 14:05:40 -0500
> >> Ben Cotton wrote:
> >>
> >> 1. How does this affect users
On Sat, 19 Dec 2020 at 03:02, Luya Tshimbalanga wrote:
>
>
> On 2020-12-18 11:13 a.m., Robbie Harwood wrote:
> > clime writes:
> >
> >> On Fri, 18 Dec 2020 at 18:20, Robbie Harwood wrote:
> >>> Robert-André Mauchin writes:
> >>>
> >&g
On Fri, 18 Dec 2020 at 18:20, Robbie Harwood wrote:
>
> Robert-André Mauchin writes:
>
> > On 12/18/20 3:52 PM, James Szinger wrote:
> >>
> >> No. One can also download the sources from upstream using spectool or
> >> similar, even wget or curl. My local work flow is typically get or
> >>
On Fri, 18 Dec 2020 at 15:53, James Szinger wrote:
>
> On Fri, 18 Dec 2020 03:04:01 +0100
> clime wrote:
>
> > I wouldn't call it "deprecating rpmbuild". That's certainly not at all
> > my intention.
> >
> > As a side-point, I think the cases where
On Fri, 18 Dec 2020 at 16:23, James Szinger wrote:
>
> On Fri, 18 Dec 2020 00:51:49 +0100
> clime wrote:
>
> > Well, the users here are still packagers here no? I thought the "User"
> > in the title means "end user" who shouldn't be affected by it. May
Dne pá 18. 12. 2020 10:52 dop. uživatel Miro Hrončok
napsal:
> On 12/18/20 1:19 AM, clime wrote:
> >> I'd very much like to understand the impact of this on the following:
> >>
> >>
> >> 1) Provenpackagers doing mass spec changes/updates.
> > I
side, there is an ongoing work to add the preprocessor support
>> into the `rpkg` python library so that a packager can easily work with
>> the spec files containing the preprocessor (rpkg) macros:
>> https://pagure.io/rpkg/pull-request/530
>>
>>
>
On Fri, 18 Dec 2020 at 02:27, Japheth Cleaver wrote:
>
> On 12/17/2020 3:59 PM, Matthew Miller wrote:
>
> On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:
>
> This change proposal does affect users. The User Experience section
> needs to answer the following:
>
On Fri, 18 Dec 2020 at 00:58, Matthew Miller wrote:
>
> On Fri, Dec 18, 2020 at 12:24:10AM +0100, clime wrote:
> > It would be possible to specify the spec template as an rpm Source so
> > it would get included into the resulting srpm as well.
>
> Yeah I was thinking
On Thu, 17 Dec 2020 at 21:23, Miro Hrončok wrote:
>
> On 12/17/20 8:05 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the
On Thu, 17 Dec 2020 at 22:04, James Szinger wrote:
>
> On Thu, 17 Dec 2020 14:05:40 -0500
> Ben Cotton wrote:
>
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> >
On Thu, 17 Dec 2020 at 21:34, James Cassell wrote:
>
>
> On Thu, Dec 17, 2020, at 2:05 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> >
...snip...
>
> I'm generally not excited about this, as it adds a huge layer of
> indirection and a ton of extra magic that makes it harder to decipher
> what is happening.
>
I don't think there is any magic in it. Everything is clearly
documented and every expansion clearly defined and also
opt-in nature on packager side, there should be no
> > compatibility issues.
> >
> > == How To Test ==
> > Once the feature is enabled, one can test it by providing the
> > `rpkg.conf` file with the required content in a package repository and
> > use some rpkg macro in
On Tue, 3 Nov 2020 at 21:22, clime wrote:
>
> On Tue, 3 Nov 2020 at 19:25, Neal Gompa wrote:
> >
> > On Tue, Nov 3, 2020 at 1:08 PM clime wrote:
> > >
> > > On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote:
> > > >
> > > > >>
On Tue, 3 Nov 2020 at 19:25, Neal Gompa wrote:
>
> On Tue, Nov 3, 2020 at 1:08 PM clime wrote:
> >
> > On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote:
> > >
> > > >> Or switch to depend on `%{_bindir}/git`?
> > > >
> > > > If
data, don't they?
Ok, I didn't know that. Do you happen to know if there is
documentation of what ends up in primary metadata and what not?
Thank you!
clime
> Is this about removing them? They are just 36,217 lines out of
> 2,253,333, or something like that. They also should compress well
&g
ckage names only even
though filelists.xml lazy loading is not yet implemented
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7I6HII4Y62BYVU2DEY67VMONJKZENDJC/).
clime
>
>
> Vít
>
>
>
> $ dnf --quiet repoquery --exact --whatrequires git-core |
On Mon, 2 Nov 2020 at 21:38, Daniel Mach wrote:
>
> Lazy file list loading? Yes, that's on DNF's TODO list already, but (to
> be honest) not on top - there's always something more important. It's
> not getting into DNF4, but it may get into DNF5 later on.
Ok, good to know.
Best r
On Mon, 2 Nov 2020 at 18:55, Vít Ondruch wrote:
>
>
> Dne 01. 11. 20 v 11:58 clime napsal(a):
> > Hello!
> >
> > First of all, I don't really know what I am talking about here but I
> > noticed the `dnf update` operation downloads among other things
> >
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https
by default by telling
> >>>> them 'Vim works' but Vi is run instead - Vi and Vim don't have the
> >>>> same
> >>>> set of features, which may lead into bug reports caused by this
> >>>> mistake.
> >>>
> >>> Isn't th
On Mon, 12 Oct 2020 at 07:39, Zdenek Dohnal wrote:
>
> On 10/10/20 2:37 PM, clime wrote:
> > Hello,
> >
> > could Fedora and CentOS containers for docker and podman come with
> > `alias vim=vi` in ~/.bashrc?
> >
> > I would very much welcome it as I am
something on
vanilla containers from the whole range.
Didn't want to write about this first but maybe there are more people
with the same problem.
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
to have this fixed for version 3.
clime
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https:/
On Mon, 28 Sep 2020 at 19:17, Richard Shaw wrote:
>
> On Mon, Sep 28, 2020 at 9:26 AM clime wrote:
>>
>> On Mon, 28 Sep 2020 at 14:44, Richard Shaw wrote:
>> >
>> > I haven't seen anything obvious in the mailing list lately so maybe it's
>> > just
he way,
do you use that command for something actually?
Thank you
clime
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.or
On Fri, 4 Sep 2020 at 12:59, clime wrote:
>
> On Fri, 4 Sep 2020 at 12:48, Aoife Moloney wrote:
> >
> > Good Morning Everyone,
> >
> > I wanted to share with you some information regarding the current
> > state and future of Communishift. The infrastructur
ion around communishift a bit.
>
> Aoife, Kevin & Pingou
> - On behalf of the Fedora Infrastructure team
Hello Aoife,
is it working right now so that I can deploy my community app there or
currently not working at all?
Thank you
clime
>
>
> [1] https://fedoraproject.or
Hello,
I have a package rpm-git-tag-sort for a review. Can I swap it with somebody?
https://bugzilla.redhat.com/show_bug.cgi?id=1858256
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
On Wed, 24 Jun 2020 at 10:35, Petr Pisar wrote:
>
> On Wed, Jun 24, 2020 at 10:22:38AM +0200, clime wrote:
> > On Wed, 24 Jun 2020 at 09:40, Petr Pisar wrote:
> > >
> > > On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek
> > >
On Wed, 24 Jun 2020 at 09:40, Petr Pisar wrote:
>
> On Wed, Jun 24, 2020 at 06:51:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Yes. Putting the "stream identification" into the package name is the
> > most natural solution, and has been floated various times.
>
> This already happens. But
On Tue, 23 Jun 2020 at 20:59, Terry Bowling wrote:
>
> On Tue, Jun 23, 2020 at 2:33 PM clime wrote:
>>
>>
>> So I don't really get even after almost five years where modularity is
>> going or what it wants to achieve. I don't understand its use-case for
>> any
On Mon, 22 Jun 2020 at 08:14, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Jun 22, 2020 at 04:55:10AM +0200, clime wrote:
> > >> > > Hello Josh,
> > >> > >
> > >> > > you can change the artifact type while keeping interface the same a
On Mon, 22 Jun 2020 at 08:14, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Jun 22, 2020 at 04:55:10AM +0200, clime wrote:
> > >> > > Hello Josh,
> > >> > >
> > >> > > you can change the artifact type while keeping interface the same a
On Mon, 22 Jun 2020 at 04:12, Naheem Zaffar wrote:
>
>
>
> On Mon, 22 Jun 2020, 02:57 clime, wrote:
>>
>> On Fri, 19 Jun 2020 at 01:59, Josh Boyer wrote:
>> >
>> > On Thu, Jun 18, 2020 at 5:51 PM clime wrote:
>> > >
On Fri, 19 Jun 2020 at 01:59, Josh Boyer wrote:
>
> On Thu, Jun 18, 2020 at 5:51 PM clime wrote:
> >
> > On Thu, 18 Jun 2020 at 15:25, Josh Boyer wrote:
> > >
> > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
> > > wrote:
> > > >
> &
not help
> > to understand the reasons behind, whether you can't change UX in the
> > RHEL 9, or you think that technology is good enough for your use-cases
> > or any other reasons.
>
> The base requirement is that the UX remain largely the same. As I
> said, from a RHEL
On Sat, 16 May 2020 at 20:33, Paul Howarth wrote:
>
> On Sat, 16 May 2020 20:23:35 +0200
> clime wrote:
> > I am co-maintaining an epel-7 package (dist-git) and I wanted to add
> > it to epel-8 too. But right now, it wouldn't install because one of
> > the depend
depend on such package from an
epel-8 package or at least I will solve it like this by removing the
dependency. Something like this is a bit surprising, however. I didn't
know a repo like that existed.
clime
___
devel mailing list -- devel
e beneficial features for maybe not all packages
but at least some.
I suspect on such scale as Fedora operates, it might be quite hard to
do something which improves things for everybody.
> If what you're proposing was implemented, then I'd have to manually try
> all the tags until I found
On Thu, 14 May 2020 at 01:03, Ken Dreyer wrote:
>
> On Wed, May 13, 2020 at 4:29 PM clime wrote:
> > Probably there are more variants but I see these three right now. I
> > think variants 1 and 2 where the spec file is kept in dist-git but
> > patches can be in source
On Wed, 13 May 2020 at 22:32, Ken Dreyer wrote:
>
> On Tue, May 12, 2020 at 6:20 PM clime wrote:
> > When you do rdopkg new-version and you are asked to force push, is
> > also the current master-patches HEAD tagged with the current package
> > NVR?
>
> It's someth
On Tue, 12 May 2020 at 16:28, Clement Verna wrote:
>
> On Mon, 11 May 2020 at 12:55, Clement Verna wrote:
>>
>>
>>
>> On Mon, 11 May 2020 at 11:03, Fabio Valentini wrote:
>>>
>>> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney wrote:
>>> > ## GitForge Updates
>>> > * We are tracking our
ally check signatures when importing. When import is done,
"sources" file would be updated. In future, it could also import git
tags instead of just tarballs (i.e. it would basically just clone git
repo and reset it to specific tag) and these w
On Tue, 12 May 2020 at 23:06, Ken Dreyer wrote:
>
> On Tue, May 12, 2020 at 1:45 AM clime wrote:
> >
> > Ken, would it be, please, possible to provide links to the patch
> > branches and mentioned dist-git repos. I would like to have a closer
> > look.
>
> Sur
s
> and PatchXXX entries in our .spec file in the corresponding dist-git
> branch.
Ken, would it be, please, possible to provide links to the patch
branches and mentioned dist-git repos. I would like to have a closer
look.
Thanks
clime
>
> At a general level, a typical Fedora p
On Fri, 8 May 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi,
> I'm a bit late to the party, but here's my 2¢.
>
> On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> > In the packit project, we work in source-git repositories. These are
> > pretty much upstream
On Thu, 7 May 2020 at 20:50, Kevin Fenzi wrote:
>
> On Tue, May 05, 2020 at 06:46:48PM +0200, Florian Weimer wrote:
> ...snip...
> >
> > The latest tag for a source package name wins for the Koji-generatged
> > repository. I don't know what happens if different source packages
> > build
On Fri, 8 May 2020 at 16:22, Stephen John Smoogen wrote:
>
> On Fri, 8 May 2020 at 09:59, clime wrote:
> >
> > On Thu, 7 May 2020 at 20:58, Kevin Fenzi wrote:
> > >
> > > On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > > ...s
On Thu, 7 May 2020 at 22:53, clime wrote:
>
>
>
> > In the rare occasion that I need to make downstream-only changes with
> > patches, I usually just explode the upstream tarball, run "git init",
> > then "git add .", "git commit -m import&q
On Thu, 7 May 2020 at 20:58, Kevin Fenzi wrote:
>
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> ...snip... please folks... please trim your posts? :)
>
> > These are some great stats!
> >
> > But I would like to note that exploded repos (or source-gi
> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just one
> commit), or
Dne čt 7. kvě 2020 12:19 uživatel Vít Ondruch napsal:
>
> Dne 06. 05. 20 v 20:39 clime napsal(a):
> > On Wed, 6 May 2020 at 13:21, Fabio Valentini
> wrote:
> >> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch
> wrote:
> >>>
> >>> Dne 05. 05. 20 v
On Wed, 6 May 2020 at 21:00, Pierre-Yves Chibon wrote:
>
> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
> > But I would like to note that exploded repos (or source-git repos)
> > have at least two other advantages.
> >
> > 1) they consume less space
46: 1
> 47: 1
> 48: 3
> 49: 1
> 50: 2
> 51: 1
> 53: 1
> 54: 1
> 66: 1
> 68: 1
> 71: 1
> 75: 1
> 78: 1
> 79: 1
> 85: 1
> 127: 1
> 170: 1
>
> In relative terms:
>
> - 71% of packages have ZERO patches
> - 15% have ONE patch
>
you
> build an unreleased commit, you get a "work-in-progress" N-V-R and
> also changelog won't be populated with the latest changes. This
> workflow needs "pushing a tag" to be a build trigger so that it is
> convenient.
>
> Best regards
> clime
>
> >
git.3.abcdef12. E.g. it won't be a clean N-V-R because
it doesn't come from a tagged commit. If you push a tag and repeat a
build from that same commit (or from that tag, see above), you will
now get a clean N-V-R like foo-1.0-2. This is assuming Release: {{{
git_dir_release }}} is used in the sp
On Tue, 5 May 2020 at 18:46, Florian Weimer wrote:
>
> > Hey Florian,
> >
> > On Mon, 4 May 2020 at 10:03, Florian Weimer wrote:
> >>
> >> > as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags
> >> > pushed by package maintainers) effort, I revisited the sorting
> >> > algorithm
On Tue, 5 May 2020 at 11:35, clime wrote:
>
> Hey Florian,
>
> On Mon, 4 May 2020 at 10:03, Florian Weimer wrote:
> >
> > > as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags
> > > pushed by package maintainers) effort, I revisited the
On Tue, 5 May 2020 at 13:06, Miro Hrončok wrote:
>
> On 05. 05. 20 12:41, Tomas Tomecek wrote:
> > Before I reply, I'd like to stress that we are still in a prototype
> > phase - not everything is solved (clearly) and at this point, we
> > experiment with the workflow mostly.
>
> Experimenting is
lent to dist-git branch name. So, the annotated-tags proposal is such
that it keeps git the source of truth for NVR and changelog but to avoid
conflicts between branches and to allow for making those information
dynamic, it moves that information from spec files out to git metadata.
Thank you
Dne po 4. kvě 2020 8:44 uživatel Clement Verna
napsal:
>
>
> On Sun, 3 May 2020 at 21:42, clime wrote:
>
>> On Sun, 3 May 2020 at 19:42, Aoife Moloney wrote:
>> >
>> > # CPE Weekly: 2020-05-02
>> > ---
>> > title
l be considered the
latest one only if it has the highest N-V-R.
What do you think? What is the best sorting approach here?
Thanks
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproj
f the plan in an
open manner where people can contribute?
I expected a restart of the git forge process because of the first one
not being open and community-inclusive.
Thank you
clime
> * Fedora have also released a blog post
> https://communityblog.fedoraproject.org/fedora-council-
On Thu, 30 Apr 2020 at 20:40, Nicolas Mailhot via devel
wrote:
>
> Le lundi 09 mars 2020 à 00:26 +0100, clime a écrit :
>
> Hi,
>
> > the code would fail because at that point, the
> > git metadata is already missing (they are not included in srpms).
>
> Can’t
On Thu, 30 Apr 2020 at 10:40, Petr Šabata wrote:
>
> On Tue, Apr 28, 2020 at 3:40 AM clime wrote:
> >
> > Few more notes:
> >
> > I think an idea that build system could be simply passing
> > --with/--without options on mock's command-line should be
>
R.I.P Taskotron
On Thu, 30 Apr 2020 at 10:01, Kamil Paral wrote:
>
> As previously announced [1], Taskotron [2] will be shut down today. See the
> announcement and its discussion for more details and some background info.
>
> As a result, certain tests (beginning with “dist.“) will no longer
On Tue, 28 Apr 2020 at 16:08, Matthew Miller wrote:
>
> It’s here! We’re proud to announce the release of Fedora 32.
> Thanks to the hard work of thousands of Fedora community
> members and contributors, we’re celebrating yet another
> on-time release!
>
> Read the official announcement at:
>
> *
in case the solution above is chosen or the set of with options (and
the final values for them) that were used during build if the
buildroot config approach is chosen. I think that would be very useful
for debugging and inspection of rpms.
...that's probably it from me.
clime
On Tue, 28 Apr 2020 at 03
just
start with only buildroot configs?
Best regards!
clime
>
> Cheers,
> P
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Condu
cros should be sufficiently robust after the behavior unification.
clime
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject
, comment in the text follows.
>>
>> On Tue, Apr 14, 2020 at 12:16 PM clime wrote:
>>>
>>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch wrote:
>>> >
>>> >
>>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>>> >
>>>
On Mon, 20 Apr 2020 at 13:54, Ondrej Nosek wrote:
>
>
>
> On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch wrote:
>>
>>
>> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a):
>>
>> Thanks for answers, comment in the text follows.
>>
>> On Tue, Apr 14,
On Mon, 20 Apr 2020 at 01:54, clime wrote:
>
> On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek wrote:
> >
> > Thanks for answers, comment in the text follows.
> >
> > On Tue, Apr 14, 2020 at 12:16 PM clime wrote:
> >>
> >> On Tue, 14 Apr 2020 at 12:05,
On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek wrote:
>
> Thanks for answers, comment in the text follows.
>
> On Tue, Apr 14, 2020 at 12:16 PM clime wrote:
>>
>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch wrote:
>> >
>> >
>> > Dne 14. 04. 20 v 0:
1 - 100 of 176 matches
Mail list logo
