8:13 a.m.
I have just tagged v6.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
11:38 a.m.
On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
I have just tagged v6.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Can we please stop generating and publishing the source RPMs? They're
of little use considering that you can easily run
$ rpmbuild -ta libvirt-x.y.z.tar.xz
to obtain RPMs from a release archive, so all they really do is
clutter the directory listing.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Yes, please do that everybody :)
--
Andrea Bolognani / Red Hat / Virtualization
1:58 p.m.
On Thu, Sep 24, 2020 at 18:38:18 +0200, Andrea Bolognani wrote:
On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
> I have just tagged v6.8.0-rc1 in the repository and pushed signed
> tarballs and source RPMs to https://libvirt.org/sources/
Can we please stop generating and publishing the source RPMs? They're
of little use considering that you can easily run
$ rpmbuild -ta libvirt-x.y.z.tar.xz
to obtain RPMs from a release archive, so all they really do is
clutter the directory listing.
The nice thing about the source RPMs is that they are internally signed
(in contrast to an external signature in *.asc for tarballs). Personally
I don't find them useful either, but some people may think otherwise and
I'm not sure they will raise their voice here. We could just stop
creating source RPMs and wait if anyone complains. Or we could be a
little bit more conservative and just move them to a subdirectory
perhaps. I don't mind either way.
Jirka
2:39 p.m.
On Thu, Sep 24, 2020 at 3:00 PM Jiri Denemark <jdenemar(a)redhat.com> wrote:
On Thu, Sep 24, 2020 at 18:38:18 +0200, Andrea Bolognani wrote:
> On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
> > I have just tagged v6.8.0-rc1 in the repository and pushed signed
> > tarballs and source RPMs to https://libvirt.org/sources/
>
> Can we please stop generating and publishing the source RPMs? They're
> of little use considering that you can easily run
>
> $ rpmbuild -ta libvirt-x.y.z.tar.xz
>
> to obtain RPMs from a release archive, so all they really do is
> clutter the directory listing.
The nice thing about the source RPMs is that they are internally signed
(in contrast to an external signature in *.asc for tarballs). Personally
I don't find them useful either, but some people may think otherwise and
I'm not sure they will raise their voice here. We could just stop
creating source RPMs and wait if anyone complains. Or we could be a
little bit more conservative and just move them to a subdirectory
perhaps. I don't mind either way.
I like that Source RPMs are produced, because I can trivially use them
in my import->build->test pipeline, since my build system accepts
SRPMs as input and not random tarballs. :)
So at least here's one voice for keeping them. :)
--
真実はいつも一つ！/ Always, there's only one truth!
3:35 a.m.
On Thu, Sep 24, 2020 at 03:39:03PM -0400, Neal Gompa wrote:
On Thu, Sep 24, 2020 at 3:00 PM Jiri Denemark
<jdenemar(a)redhat.com> wrote:
>
> On Thu, Sep 24, 2020 at 18:38:18 +0200, Andrea Bolognani wrote:
> > On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
> > > I have just tagged v6.8.0-rc1 in the repository and pushed signed
> > > tarballs and source RPMs to https://libvirt.org/sources/
> >
> > Can we please stop generating and publishing the source RPMs? They're
> > of little use considering that you can easily run
> >
> > $ rpmbuild -ta libvirt-x.y.z.tar.xz
> >
> > to obtain RPMs from a release archive, so all they really do is
> > clutter the directory listing.
>
> The nice thing about the source RPMs is that they are internally signed
> (in contrast to an external signature in *.asc for tarballs). Personally
> I don't find them useful either, but some people may think otherwise and
> I'm not sure they will raise their voice here. We could just stop
> creating source RPMs and wait if anyone complains. Or we could be a
> little bit more conservative and just move them to a subdirectory
> perhaps. I don't mind either way.
>
I like that Source RPMs are produced, because I can trivially use them
in my import->build->test pipeline, since my build system accepts
SRPMs as input and not random tarballs. :)
If you have the tarball you can trivially generate the source RPM if
you need it because the tarball still contains the .spec file. IOW
just run
$ rpmbuild -ts libvirt-6.7.0.tar.xz
Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:09 a.m.
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Thu, Sep 24, 2020 at 03:39:03PM -0400, Neal Gompa wrote:
> On Thu, Sep 24, 2020 at 3:00 PM Jiri Denemark <jdenemar(a)redhat.com> wrote:
> >
> > On Thu, Sep 24, 2020 at 18:38:18 +0200, Andrea Bolognani wrote:
> > > On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
> > > > I have just tagged v6.8.0-rc1 in the repository and pushed signed
> > > > tarballs and source RPMs to https://libvirt.org/sources/
> > >
> > > Can we please stop generating and publishing the source RPMs? They're
> > > of little use considering that you can easily run
> > >
> > > $ rpmbuild -ta libvirt-x.y.z.tar.xz
> > >
> > > to obtain RPMs from a release archive, so all they really do is
> > > clutter the directory listing.
> >
> > The nice thing about the source RPMs is that they are internally signed
> > (in contrast to an external signature in *.asc for tarballs). Personally
> > I don't find them useful either, but some people may think otherwise and
> > I'm not sure they will raise their voice here. We could just stop
> > creating source RPMs and wait if anyone complains. Or we could be a
> > little bit more conservative and just move them to a subdirectory
> > perhaps. I don't mind either way.
> >
>
> I like that Source RPMs are produced, because I can trivially use them
> in my import->build->test pipeline, since my build system accepts
> SRPMs as input and not random tarballs. :)
If you have the tarball you can trivially generate the source RPM if
you need it because the tarball still contains the .spec file. IOW
just run
$ rpmbuild -ts libvirt-6.7.0.tar.xz
Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
That assumes I have the ability to add such a mechanism that can do
that automatically. :)
--
真実はいつも一つ！/ Always, there's only one truth!
11:49 a.m.
On Fri, 2020-09-25 at 05:09 -0400, Neal Gompa wrote:
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
> On Thu, Sep 24, 2020 at 03:39:03PM -0400, Neal Gompa wrote:
> > I like that Source RPMs are produced, because I can trivially use them
> > in my import->build->test pipeline, since my build system accepts
> > SRPMs as input and not random tarballs. :)
>
> If you have the tarball you can trivially generate the source RPM if
> you need it because the tarball still contains the .spec file. IOW
> just run
>
> $ rpmbuild -ts libvirt-6.7.0.tar.xz
> Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
That assumes I have the ability to add such a mechanism that can do
that automatically. :)
A testing pipeline that can only work with SRPMs seems quite
limiting, and will not be able to deal with many subprojects such as
for example Go and Rust language bindings... We actually only produce
SRPMs for the main C library IIRC.
Anyway, while I personally think that we should not be generating
SRPMs, I can't deny they seem to offer some value to you, and so I
will begrudgingly retire my motion to stop publishing them :)
--
Andrea Bolognani / Red Hat / Virtualization
1:30 p.m.
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
If you have the tarball you can trivially generate the source RPM if
you need it because the tarball still contains the .spec file. IOW
just run
$ rpmbuild -ts libvirt-6.7.0.tar.xz
Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
I've never tried this before... what does it do if the .spec file is
non-trivial and includes things expanded by autoconf, or if there are
multiple different .spec files?
Personally, I have found the libvirt provided spec file limiting - and use
a distro one like Fedora as a starting point instead. And, I meant to try
and figure out why this was and provide feedback about it. But, for other
projects such as openvswitch - I find that the one they build and maintain
upstream, to be very useful. In this case, you do run autoconf and
configure, and "make rpm-fedora" generates both RPM and SRPM. From that
respect, the need to distribute a .src.rpm separately is not as important,
but the ability to build an SRPM using an easy mechanism is the real
requirement and I'm mostly wondering if "rpmbuild -ts" is sophisticated
enough to support many real-world use cases, or if it is only useful for
the most trivial and eventually limiting use cases.
--
Mark Mielke <mark.mielke(a)gmail.com>
10:33 p.m.
On 9/25/20 2:30 PM, Mark Mielke wrote:
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé
<berrange(a)redhat.com <mailto:berrange@redhat.com>> wrote:
If you have the tarball you can trivially generate the source RPM if
you need it because the tarball still contains the .spec file. IOW
just run
$ rpmbuild -ts libvirt-6.7.0.tar.xz
Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
I've never tried this before... what does it do if the .spec file is
non-trivial and includes things expanded by autoconf, or if there are
multiple different .spec files?
That's not relevant in the case of libvirt, because we no longer use
autoconf/configure/make, but use meson instead, and the source tarfile
only has a single .spec file.
Even when libvirt did use autoconf, that step was done on the file
libvirt.spec.in as a part of make dist, and so the source tar has always
contained a libvirt.spec that is ready to be used directly by rpmbuild.
Personally, I have found the libvirt provided spec file limiting - and
use a distro one like Fedora as a starting point instead.
I'm not sure what difference you're seeing here. The libvirt.spec in
Fedora git is just directly imported from the upstream libvirt source
tar every time the package is rebased. There is no difference. (well,
except that the Fedora libvirt.spec file maintains the incomplete and
thus totally pointless %changelog section).
And, I meant to try and figure out why this was and provide feedback
about it.
If there's something you think is missing in libvirt's spec file,
definitely send a patch for it.
But, for other projects such as openvswitch - I find that the one
they
build and maintain upstream, to be very useful. In this case, you do
run autoconf and configure, and "make rpm-fedora" generates both RPM
and SRPM. From that respect, the need to distribute a .src.rpm
separately is not as important, but the ability to build an SRPM using
an easy mechanism is the real requirement and I'm mostly wondering if
"rpmbuild -ts" is sophisticated enough to support many real-world use
cases, or if it is only useful for the most trivial and eventually
limiting use cases.
Hmm. Maybe you're asking the question "in general" for any arbitrary
package, while I am (and Dan was) answering only relative to libvirt? In
that case I should stop and let someone who knows what they're talking
about take over :-)
3:38 a.m.
On Fri, Sep 25, 2020 at 02:30:32PM -0400, Mark Mielke wrote:
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé
<berrange(a)redhat.com>
wrote:
> If you have the tarball you can trivially generate the source RPM if
> you need it because the tarball still contains the .spec file. IOW
> just run
>
> $ rpmbuild -ts libvirt-6.7.0.tar.xz
> Wrote: /home/berrange/rpmbuild/SRPMS/libvirt-6.7.0-1.fc32.src.rpm
>
I've never tried this before... what does it do if the .spec file is
non-trivial and includes things expanded by autoconf, or if there are
multiple different .spec files?
It only works when there is a single .spec file, which is the case with
libvirt tarballs. Expansion of macros is largely irrelevant until you
get the build stage.
Personally, I have found the libvirt provided spec file limiting -
and use
a distro one like Fedora as a starting point instead.
Errm, the libvirt.spec inside the tarball *IS* the Fedora distro spec.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:09 a.m.
New subject: libvirt-6.8.0 release candidate 2
I have just tagged v6.8.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
1514
days inactive
1519
days old
10 comments
6 participants
participants (6)
-
Andrea Bolognani -
Daniel P. Berrangé -
Jiri Denemark -
Laine Stump -
Mark Mielke -
Neal Gompa