%include /usr/share/spin-kickstarts/fedora-live-minimization.ks
But I have noticed that it wants to go into the rawhide repo. That is because
/usr/share/spin-kickstarts/fedora-live-base.ks has fedora-repo-rawhide.ks as
the repo by default. Now, I know that I can comment it out but I dont want to
do
Hi,
Ny kickstart file has the following:
%include /usr/share/spin-kickstarts/fedora-live-base.ks
%include /usr/share/spin-kickstarts/fedora-live-minimization.ks
But I have noticed that it wants to go into the rawhide repo. That is because
/usr/share/spin-kickstarts/fedora-live-base.ks has
Dne 09. 12. 20 v 0:34 Kevin Kofler via devel napsal(a):
That said, will "dnf downgrade" offer you cached versions that are no longer
in the repos? Last I checked, it only offered me whatever was still in the
repos, and I had to dig up the cached RPMs manually.
Yes, right, that is why there w
Marius Schwarz wrote:
> it will eat disk space. If you have 0ad laying around in 3 different
> version, that's 1 GB each.
Sure, but that is usually not the scarce resource. And if you need the disk
space, you can always clear the cache manually. Deleting data should not be
the default action.
>
Am 09.12.20 um 00:34 schrieb Kevin Kofler via devel:
Vít Ondruch wrote:
As a workaround, if you use `keepcache=True` in dnf.conf, you'd have
copies of everything you previously installed on your system.
I still don't understand why this is not the default. Even for stable
releases, because with
On Tue, Dec 8, 2020, at 6:34 PM, Kevin Kofler via devel wrote:
> Vít Ondruch wrote:
> > As a workaround, if you use `keepcache=True` in dnf.conf, you'd have
> > copies of everything you previously installed on your system.
>
> I still don't understand why this is not the default. Even for stable
Vít Ondruch wrote:
> As a workaround, if you use `keepcache=True` in dnf.conf, you'd have
> copies of everything you previously installed on your system.
I still don't understand why this is not the default. Even for stable
releases, because without it, you can easily obtain only the ancient GA
On Mon, Dec 7, 2020, at 11:45 AM, Fabio Valentini wrote:
>
> I'm wondering, wouldn't this scenario be a prime application of an
> OSTree based system like Silverblue?
...
On Mon, Dec 7, 2020, at 12:28 PM, Martin Kolman wrote:
> With OSTree one could easily have multiple update states availabl
Am 07.12.20 um 18:28 schrieb Martin Kolman:
Nice, very good progress! :)
I really need to try the latest Fedora image on my Pinephone when I
have some time. :)
Read the issue tracker on github before you update... you will be
surprised ;)
Best regards,
Marius Schwarz
> way to handle it would be, if the os compenents came from stable
> repos, so that these problems do not happen. But as i said, bleeding
> edge is needed atm.
>
>
>
> Is it possible to keep at least the last version of a package around
> in rawh
ks, direct http links
> > work ofcourse ), and later downgraded with
> > dnf, which is so to speak, a pain in the ass. Of course, the best way to
> > handle it would be, if the os compenents
> > came from stable repos, so that these problems do not happen. But as i
> > sa
o that
> these problems do not happen. But as i said, bleeding edge is needed atm.
>
> Is it possible to keep at least the last version of a package around in
> rawhide repo, to make dnf downgrade work? That would ease a lot of this pain.
>
> I know that there is a native koji to
links work ofcourse ), and later downgraded
> with
> dnf, which is so to speak, a pain in the ass. Of course, the best way to
> handle it would be, if the os compenents came from stable repos, so that
> these problems do not happen. But as i said, bleeding edge is needed atm.
>
>
Am 04.12.20 um 17:34 schrieb Adam Williamson:
I don't think there's an easy way to do this, because of how we build
stuff. The Rawhide and Branched trees are rsynced over top of the
previous content from the most recent successful compose, with metadata
pre-built at the compose level. The old thi
Am 04.12.20 um 16:37 schrieb Vít Ondruch:
As a workaround, if you use `keepcache=True` in dnf.conf, you'd have
copies of everything you previously installed on your system.
Thats even better :) thx, didn't know this.
best regards,
Marius
___
devel mai
os compenents came from stable repos, so that
> these problems do not happen. But as i said, bleeding edge is needed atm.
>
> Is it possible to keep at least the last version of a package around in
> rawhide repo, to make dnf downgrade work? That would ease a lot of this
> pain.
>
Is it possible to keep at least the last version of a package around
in rawhide repo, to make dnf downgrade work? That would ease a lot of
this pain.
I know that there is a native koji tool to handle rawhide, but i must
say, that won't work in most cases. Let me explain:
Pine has announce
ch is so to speak, a pain in the ass. Of course, the best way to
handle it would be, if the os compenents came from stable repos, so that
these problems do not happen. But as i said, bleeding edge is needed atm.
Is it possible to keep at least the last version of a package around in
rawhi
On 02/12/2018 11:00 AM, Alfredo Moralejo Alonso wrote:
> Hi,
>
> A new build for python-jsonpatch was done some days ago in
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1024370 but it has
> not appeared in rawhide repo yet.
>
> Any idea about what may be happe
Hi,
A new build for python-jsonpatch was done some days ago in
https://koji.fedoraproject.org/koji/buildinfo?buildID=1024370 but it has
not appeared in rawhide repo yet.
Any idea about what may be happening?
Regards,
Alfredo
___
devel mailing list
Dear rawhide users,
if you have enabled a COPR repo in the last three months (since the
beginning of December last year till yesterday), then it points to
fedora-$releasever-$basearch. You can reenable it by using `dnf copr enable
` to get .repo file pointing to actual fedora-rawhide chroot in
the
Hello,
Mock fails with this error:
DEBUG: Error: Package: gdcm-2.0.17-3.fc16.i686 (fedora)
DEBUG:Requires: libpoppler.so.13
I recall a poppler update recently, is a rebuild required or something?
--
Thanks,
Regards,
Ankur: "FranciscoD"
http://fedoraproject.org/wiki/User:Ankursinh
On Mon, Mar 29, 2010 at 5:57 AM, Peter Robinson wrote:
> On Mon, Mar 29, 2010 at 12:03 AM, Paul wrote:
>> Hi,
>>
>> I've been away from my pc for the last couple of days and have come back
>> to find a problem.
>>
>> When I try to do an update from yum, I'm getting the following error
>>
>> Error
On Mon, Mar 29, 2010 at 12:03 AM, Paul wrote:
> Hi,
>
> I've been away from my pc for the last couple of days and have come back
> to find a problem.
>
> When I try to do an update from yum, I'm getting the following error
>
> Error: Cannot retrieve metalink for repository: rawhide. Please verify
On Mon, 2010-03-29 at 07:23 +0100, Paul wrote:
> Oddly, Matt's solution of
>
> wget -O - \
> 'https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i686'
>
> does work, but it looks like the problem is a crypto one...
It's also a yum bug that it doesn't give you a sane error message, an
Hi,
> > Error: Cannot retrieve metalink for repository: rawhide. Please verify
> > its path and try again
>
> To get more info use: URLGRABBER_DEBUG=1 yum check-update
This gives me
2010-03-29 07:18:52,993 attempt 1/10:
https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i686
INFO:url
On Mon, 2010-03-29 at 00:03 +0100, Paul wrote:
> Hi,
>
> I've been away from my pc for the last couple of days and have come back
> to find a problem.
>
> When I try to do an update from yum, I'm getting the following error
>
> Error: Cannot retrieve metalink for repository: rawhide. Please veri
On Mon, Mar 29, 2010 at 12:03:05AM +0100, Paul wrote:
> Hi,
>
> I've been away from my pc for the last couple of days and have come back
> to find a problem.
>
> When I try to do an update from yum, I'm getting the following error
>
> Error: Cannot retrieve metalink for repository: rawhide. Plea
Hi,
I've been away from my pc for the last couple of days and have come back
to find a problem.
When I try to do an update from yum, I'm getting the following error
Error: Cannot retrieve metalink for repository: rawhide. Please verify
its path and try again
Looking at the fedora-rawhide.repo f
repos.d is fedora
> > and fedora-testing. What's happened to the fedora-rawhide.repo files?
> >
> > I know things were forked a few days back, but didn't realise the
> > rawhide.repo config would vanish.
>
> It got separated to fedora-release-rawhide packa
On Sat, Feb 20, 2010 at 08:17:28PM +, Paul wrote:
> Hi,
>
> Just checked why I've not been able to grab the updates from rawhide and
> it looks like the only fedora.repo files in /etc/yum.repos.d is fedora
> and fedora-testing. What's happened to the fedora-rawhide.repo files?
>
> I know thin
Hi,
Just checked why I've not been able to grab the updates from rawhide and
it looks like the only fedora.repo files in /etc/yum.repos.d is fedora
and fedora-testing. What's happened to the fedora-rawhide.repo files?
I know things were forked a few days back, but didn't realise the
rawhide.repo
32 matches
Mail list logo
