On 02. 07. 24 23:25, Michel Lind wrote:
Hi all,
I'm currently shepherding getting catch v3 into EPEL 9 (bringing along
the catch2 compatibility package, so the impact is minimal) - and to
make sure no dependent package is left in a state where they can't be
rebuilt, I'm coordinating the work in
Hi all,
I'm currently shepherding getting catch v3 into EPEL 9 (bringing along
the catch2 compatibility package, so the impact is minimal) - and to
make sure no dependent package is left in a state where they can't be
rebuilt, I'm coordinating the work in a side tag.
See for example https://src.f
FF 107.0 shipped in all current Fedora releases a while ago. You can
find all that in bodhi. If you mean 107.0.1, that will depend on the FF
maintainers. Maybe they see no reason to respin, because the bugs fixed
in that release are not something that is important in Fedora - not
sure.
--
Bojan
_
On 12/3/22 22:41, Bojan Smojver via devel wrote:
> 107.0.1 build for
> F37/x86_64: https://copr.fedorainfracloud.org/coprs/bojan/FF/
>
> If you want/need or are obsessive about version numbers, like yours
> truly. ;-)
When will FF107 actually ship in Fedora?
--
Sincerely,
Demi Marie Obenour (she
107.0.1 build for
F37/x86_64: https://copr.fedorainfracloud.org/coprs/bojan/FF/
If you want/need or are obsessive about version numbers, like yours
truly. ;-)
--
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
Dne 22. 11. 22 v 20:41 Adam Williamson napsal(a):
On Tue, 2022-11-22 at 12:48 +0100, Vít Ondruch wrote:
Would it be possible to develop a way to better manage updates of some
interconnected packages? FF + NSS would be one case, but when we are
doing Ruby on Rails update, it always involve more
On Tue, 2022-11-22 at 12:48 +0100, Vít Ondruch wrote:
>
> Would it be possible to develop a way to better manage updates of some
> interconnected packages? FF + NSS would be one case, but when we are
> doing Ruby on Rails update, it always involve more packages. Or probably
> gcc + annobin are
On Tue, Nov 22, 2022 at 6:48 AM Vít Ondruch wrote:
>
>
> Dne 21. 11. 22 v 18:56 Adam Williamson napsal(a):
> > On Mon, 2022-11-21 at 12:43 -0500, Demi Marie Obenour wrote:
> >> On 11/21/22 09:23, Simo Sorce wrote:
> >>> On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
> On 11/20/2
Dne 21. 11. 22 v 18:56 Adam Williamson napsal(a):
On Mon, 2022-11-21 at 12:43 -0500, Demi Marie Obenour wrote:
On 11/21/22 09:23, Simo Sorce wrote:
On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
On 11/20/22 17:40, Simo Sorce wrote:
On Sun, 2022-11-20 at 17:22 -0500, Demi Marie
On Mon, 2022-11-21 at 12:43 -0500, Demi Marie Obenour wrote:
> On 11/21/22 09:23, Simo Sorce wrote:
> > On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
> > > On 11/20/22 17:40, Simo Sorce wrote:
> > > > On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
> > > > > On 11/20/22
On Mon, Nov 21, 2022 at 12:45 PM Demi Marie Obenour
wrote:
>
> On 11/21/22 09:23, Simo Sorce wrote:
> > On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
> >> On 11/20/22 17:40, Simo Sorce wrote:
> >>> On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
> On 11/20/22 07:24
On 11/21/22 09:23, Simo Sorce wrote:
> On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
>> On 11/20/22 17:40, Simo Sorce wrote:
>>> On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
On 11/20/22 07:24, Bojan Smojver via devel wrote:
> Now that nss 3.85 has been built,
On Sun, 2022-11-20 at 19:24 -0500, Demi Marie Obenour wrote:
> On 11/20/22 17:40, Simo Sorce wrote:
> > On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
> > > On 11/20/22 07:24, Bojan Smojver via devel wrote:
> > > > Now that nss 3.85 has been built, I thought I'd have a go at building
Dne 20. 11. 22 v 13:24 Bojan Smojver via devel napsal(a):
PS. I am not the FF maintainer (obviously), so this is just for kicks.
Feel free to use Copr for such experiments
https://copr.fedorainfracloud.org/
Miroslav
___
devel mailing list -- devel
Of course, relevant build overrides had to be provided, because
required version of nss was not in stable at the time I started these
scratch builds. Thought I'd mention it for completeness.
--
Bojan
___
devel mailing list --
On 20/11/2022 23:22, Demi Marie Obenour wrote:
Has switching to bundled NSS been considered? For browsers anything
that holds up an update is very,*very* bad.
No. Bundling cryptographic libraries is a very, very bad idea.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On 11/20/22 17:40, Simo Sorce wrote:
> On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
>> On 11/20/22 07:24, Bojan Smojver via devel wrote:
>>> Now that nss 3.85 has been built, I thought I'd have a go at building
>>> FF 107.0, given that's been out for a few days and original builds
>
On Sun, 2022-11-20 at 17:22 -0500, Demi Marie Obenour wrote:
> On 11/20/22 07:24, Bojan Smojver via devel wrote:
> > Now that nss 3.85 has been built, I thought I'd have a go at building
> > FF 107.0, given that's been out for a few days and original builds
> > failed in koji, because nss was too o
On Sun, Nov 20, 2022 at 5:23 PM Demi Marie Obenour
wrote:
>
> On 11/20/22 07:24, Bojan Smojver via devel wrote:
> > Now that nss 3.85 has been built, I thought I'd have a go at building
> > FF 107.0, given that's been out for a few days and original builds
> > failed in koji, because nss was too o
On 11/20/22 07:24, Bojan Smojver via devel wrote:
> Now that nss 3.85 has been built, I thought I'd have a go at building
> FF 107.0, given that's been out for a few days and original builds
> failed in koji, because nss was too old at the time.
Has switching to bundled NSS been considered? For b
Everything except F38 completed fine.
--
Bojan
___
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-cond
Now that nss 3.85 has been built, I thought I'd have a go at building
FF 107.0, given that's been out for a few days and original builds
failed in koji, because nss was too old at the time.
No idea how this is going to end up, but the tasks for F3{8,7,6,5} are
here, if anyone is interested:
https
On Thu, Dec 02, 2021 at 03:00:54PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> > Basically I'd like to try a build in koji with each of the glibc
> > versions in:
> > https://kojipkgs.fedoraproject.org/packages/glibc/2.34.9000/
> > to see if any one of those was the trigger.
>
> An
On Thu, Dec 02, 2021 at 02:58:52PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
>
> >
> > The same srpm builds fine in F35 build roots, but fails in F36 build
> > roots with bizarre make errors. make appears to "loose" a bunch of
> > the rules in the makefile, despite them still actually
* Daniel P. Berrangé:
> Basically I'd like to try a build in koji with each of the glibc
> versions in:
> https://kojipkgs.fedoraproject.org/packages/glibc/2.34.9000/
> to see if any one of those was the trigger.
And to answer your question: “fedpkg request-side-tag”, and then “koji
tag” the ol
* Daniel P. Berrangé:
> Basically I'd like to try a build in koji with each of the glibc
> versions in:
> https://kojipkgs.fedoraproject.org/packages/glibc/2.34.9000/
> to see if any one of those was the trigger.
And to answer your question: “fedpkg request-side-tag”, and then “koji
tag” the ol
* Daniel P. Berrangé:
>
> The same srpm builds fine in F35 build roots, but fails in F36 build
> roots with bizarre make errors. make appears to "loose" a bunch of
> the rules in the makefile, despite them still actually existing when
> I dump a copy of the makefile contents immediately before ru
vCPU builders.
Based on package differences betweeen F35 and F36 build roots, my
money is currently on something changing in gcc or glibc, with a
lean towards glic, but I struggle to see an obvious changelog entry
that jumps out as a likely trigger.
I was hoping to try doing scratch builds wi
* Fabio Valentini:
> On Wed, Apr 14, 2021 at 9:48 AM Honza Horak wrote:
>>
>> Hi folks,
>>
>> I found this thing and thought it might be useful for testing depended
>> packages before committing, something similar to the chain scratch
>> builds in koji,
On Wed, Apr 14, 2021 at 9:48 AM Honza Horak wrote:
>
> Hi folks,
>
> I found this thing and thought it might be useful for testing depended
> packages before committing, something similar to the chain scratch
> builds in koji, that are not available (to my knowledge).
>
>
Hi folks,
I found this thing and thought it might be useful for testing depended
packages before committing, something similar to the chain scratch
builds in koji, that are not available (to my knowledge).
I didn't realize before we can use module builds for any package set,
that doe
Ah. Scratch builds aren't considered real builds, so they don't show up in the
builds list and I was peeking around there. Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email t
re: is there any way to
> retrieve a list of scratch builds I've submitted to koji?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduc
I looked through the help / --help for the command and tried searching the wiki
and didn't find an answer, so I'm asking here: is there any way to retrieve a
list of scratch builds I've submitted to koji?
___
devel mailin
On Tue, Jun 10, 2014 at 12:28:22PM -0500, Dennis Gilmore wrote:
> What version of koji do you have installed?
koji-1.9.0-1.fc20.noarch
However .. it just started to work again, so it must have been some
temporary weirdness.
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 10 Jun 2014 17:43:37 +0100
"Richard W.M. Jones" wrote:
>
> I'm not sure if this is a local problem, but currently I'm unable
> to upload the SRPM to do a scratch build:
>
> $ fedpkg srpm
> Wrote:
> /home/rjones/d/fedora/libguestfs/master/l
I'm not sure if this is a local problem, but currently I'm unable
to upload the SRPM to do a scratch build:
$ fedpkg srpm
Wrote: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
$ koji build --scratch rawhide
/home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.f
-1.1
> sent as a scratch build, can't I?
Right, scratch builds don't count. But, I encourage you to increment release
number anyway. There are plenty of numbers, so you won't run out, and it's
easy to get confused about versions and changes -- just always increment,
and that
> foo-1.1 sent as a scratch build, can't I?
Right, scratch builds are exactly what they sound like -- they're done
on the Koji infrastructure but the build is basically ignored.
-Chris
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi folks,
Just in case, let's say we have the package foo-1.0 if I make a scratch
build of package foo-1.1, that doesn't count at all, isn't it?
I mean can I send an update foo-.1.1 completely different of the foo-1.1
sent as a scratch build, can't I?
Thanks in advance
--
--
Sergio Belkin ht
On Fri, Nov 25, 2011 at 06:49:13PM +0100, Nils Philippsen wrote:
> On Thu, 2011-11-24 at 17:26 +0100, Jim Meyering wrote:
> > config.h:
> > rm -f $@ $@-t;
> > \
>
> I'd rather not remove the target right at the beginning...
Why not? Y
On Thu, 2011-11-24 at 17:26 +0100, Jim Meyering wrote:
> config.h:
> rm -f $@ $@-t;
> \
I'd rather not remove the target right at the beginning...
> { \
> ec
Richard W.M. Jones wrote:
> On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
>> http://marc.info/?l=pptpclient-devel&m=132102054518031
>
> This is indeed rather unexpected behaviour of make!
Actually it should not be unexpected.
Whenever you update a target non-atomically that can hap
Kaleb S. KEITHLEY wrote:
...
>>> Perhaps there's some extra fedpkg flag I should be using for epel builds?
>>
>> Perhaps try without parallel make?
>
> Yes, that makes it work.
>
> Thanks for the tip.
When running make from the command line, I always use -j$N, for 1 < N.
But of course, I rarely ty
Richard W.M. Jones wrote:
> On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
>> http://marc.info/?l=pptpclient-devel&m=132102054518031
>
> This is indeed rather unexpected behaviour of make!
>
> BTW I think your patch is incomplete, since it will create an
> incomplete config.h if the
On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
> http://marc.info/?l=pptpclient-devel&m=132102054518031
This is indeed rather unexpected behaviour of make!
BTW I think your patch is incomplete, since it will create an
incomplete config.h if the disk runs out of space. I think this
On 11/24/2011 01:54 PM, Richard W.M. Jones wrote:
> On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote:
>> On 11/23/2011 10:08 AM, Orion Poplawski wrote:
>>> On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:
I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86
On Wed, Nov 23, 2011 at 10:20:50AM -0500, Kaleb S. KEITHLEY wrote:
> On 11/23/2011 10:08 AM, Orion Poplawski wrote:
> > On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:
> >>
> >> I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
> >> and i686 with `rpmbuild -bb ...` and `rpmbui
On 11/23/2011 10:08 AM, Orion Poplawski wrote:
> On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:
>>
>> I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
>> and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`
>> respectively.
>>
>> I can also build using mock,
On 11/23/2011 07:57 AM, Kaleb S. KEITHLEY wrote:
>
> I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
> and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`
> respectively.
>
> I can also build using mock, both x86_64 and i386, with `mock -r
> epel-6-x86_64 --
I can build glusterfs fine on real RHEL6.1 using rpmbuild, both x86_64
and i686 with `rpmbuild -bb ...` and `rpmbuild -bb --target=i686 ...`
respectively.
I can also build using mock, both x86_64 and i386, with `mock -r
epel-6-x86_64 --rebuild ...` and mock -r epel-6-i386 --rebuild ...`
respe
Paul Howarth wrote:
> You need to "BuildRequire: systemd-units", which is where the
> %{_unitdir} macro is defined.
Shouldn't this [systemd-units] be added to the main build root?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Nov 02, 2011 at 03:05:19PM -0400, Kaleb S. KEITHLEY wrote:
> I looked at other spec files with systemd .system files. The relevant
> part of my spec file is:
> ...
> %{_unitdir}/glusterd.service
> %{_unitdir}/glusterfsd.service
> ...
>
> and the koji build is failing with:
> ...
> Process
On Wed, 02 Nov 2011 15:05:19 -0400
"Kaleb S. KEITHLEY" wrote:
> I looked at other spec files with systemd .system files. The relevant
> part of my spec file is:
>
> ...
> %files server
> ...
> %if 0%{?fedora} < 17
> # Legacy init
> %{_sysconfdir}/init.d/glusterd
> %{_sysconfdir}/init.d/glusterf
I looked at other spec files with systemd .system files. The relevant
part of my spec file is:
...
%files server
...
%if 0%{?fedora} < 17
# Legacy init
%{_sysconfdir}/init.d/glusterd
%{_sysconfdir}/init.d/glusterfsd
%else
%{_unitdir}/glusterd.service
%{_unitdir}/glusterfsd.service
%endif
...
and
On Wed, 2010-08-04 at 18:29 +0100, Paul Howarth wrote:
> > That's a neat trick, since 1.1.1 didn't even have configs for Fedora
> > 14.
>
> I roll all of my own mock configs, with different names from the bundled
> ones so they don't disappear when a new mock version comes around.
>
> > They wer
On Wed, 04 Aug 2010 09:47:43 -0700
Adam Williamson wrote:
> On Wed, 2010-08-04 at 17:31 +0100, Paul Howarth wrote:
> > On 04/08/10 17:28, Adam Williamson wrote:
> > > On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
> > >> I have a modified package locally and want to install and test
>
On Wed, 2010-08-04 at 17:31 +0100, Paul Howarth wrote:
> On 04/08/10 17:28, Adam Williamson wrote:
> > On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
> >> I have a modified package locally and want to install and test it. Since
> >> it's a biarch package, I need to build the i686 version
On 04/08/10 17:28, Adam Williamson wrote:
> On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
>> I have a modified package locally and want to install and test it. Since
>> it's a biarch package, I need to build the i686 version too. How?
>
> Is there a reason not to use mock locally?
I mi
On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
> I have a modified package locally and want to install and test it. Since
> it's a biarch package, I need to build the i686 version too. How?
Is there a reason not to use mock locally? That's how I'd do it - just
'fedpkg srpm' then 'mock -
On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
> $ i386 fedpkg local --arch=i686
> ...
> + ./configure --build=x86_64-unknown-linux-gnu
> --host=x86_64-unknown-linux-gnu --program-prefix=
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
> --bindir=/usr/bin --sbindir=/us
h committed and tagged
files in CVS. Unpushed changes could be tested using "make
srpm-scratch-build" but fedpkg doesn't have an srpm-scratch-build yet
(hint, hint).
For the moment I've been doing "fedpkg srpm" and running koji scratch
builds manually with the resulting SRPM.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I have a modified package locally and want to install and test it. Since
it's a biarch package, I need to build the i686 version too. How?
A local build no longer seems to work for anything but the primary arch,
because it still configures for x86_64:
$ i386 fedpkg local --arch=i686
...
+ ./conf
On Tue, Mar 16, 2010 at 02:58:24PM -0400, David Malcolm wrote:
> I recently discovered this script for downloading scratch builds from
> Koji:
> http://people.redhat.com/mikeb/scripts/download-scratch.py
>
> Is this the "official" way of doing this? If so, is this packag
I recently discovered this script for downloading scratch builds from
Koji:
http://people.redhat.com/mikeb/scripts/download-scratch.py
Is this the "official" way of doing this? If so, is this packaged
somewhere? (e.g. in a more recent build of "koji" or "rpmdevtools&
65 matches
Mail list logo
