11:43 p.m.
[root@anglides ~]# dnf list kernel
ArgumentError: argument --obsoletes: conflicting option string: --
obsoletes
[root@anglides ~]#
This has been happening for a while now. Given that dnf is so critical
to updating Rawhide I would not have expected this to be the case.
1. The dnf tests are clearly not catching enough cases, this should not
have been released by the dnf development team in the first place.
2. The Rawhide integration tests should not have allowed this obviously
breaking application into the distribution.
3. It should have been fixed as the single most urgent thing because of
the status of dnf as a unique program in Fedora.
Yes I know Rawhide is a dangerous place to be, but there is danger and
there is danger. My feeling is that dnf should be treated more
specially than it appears to be.
Cathartic rant done.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel(a)winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
11:57 p.m.
On Fri Feb 17 2017 22:43:55 GMT-0700 (MST) Russel Winder
<russel(a)winder.org.uk> wrote:
[root@anglides ~]# dnf list kernel ArgumentError: argument
--obsoletes: conflicting option string: -- obsoletes [root@anglides
~]#
This has been happening for a while now. Given that dnf is so critical
to updating Rawhide I would not have expected this to be the case.
Upgrading to latest from Koji fixed it for me:
[root@omiday ~]# dnf list kernel
Last metadata expiration check: 1:34:19 ago on Fri Feb 17 21:21:08 2017 MST.
Installed Packages
kernel.x86_64 4.10.0-0.rc4.git2.1.fc26 @rawhide
kernel.x86_64 4.10.0-0.rc6.git0.1.fc26 @rawhide
kernel.x86_64 4.10.0-0.rc7.git1.1.fc26 @rawhide
Available Packages
kernel.x86_64 4.10.0-0.rc8.git0.1.fc26 rawhide
[root@omiday ~]# rpm -q dnf
dnf-2.1.0-1.fc26.noarch
--
Viorel
7:03 a.m.
To make it clear:
1. Just download dnf-2.1.0-1.fc26.noarch.rpm and
python3-dnf-2.1.0-1.fc26.noarch.rpm from
https://kojipkgs.fedoraproject.org/packages/dnf/2.1.0/1.fc26/noarch/
(these two files only)
2. # dnf install <path/>dnf-2.1.0-1.fc26.noarch.rpm
<path/>python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing
(According dnf-automatic, dnf-conf and dnf-yum will get installed
within!)
All done - happy days are here again! : )
On 2/18/17 6:57 AM, Viorel Tabara wrote:
On Fri Feb 17 2017 22:43:55 GMT-0700 (MST) Russel Winder
<russel(a)winder.org.uk> wrote:
> [root@anglides ~]# dnf list kernel ArgumentError: argument
> --obsoletes: conflicting option string: -- obsoletes [root@anglides
> ~]#
>
> This has been happening for a while now. Given that dnf is so critical
> to updating Rawhide I would not have expected this to be the case.
Upgrading to latest from Koji fixed it for me:
[root@omiday ~]# dnf list kernel
Last metadata expiration check: 1:34:19 ago on Fri Feb 17 21:21:08 2017 MST.
Installed Packages
kernel.x86_64 4.10.0-0.rc4.git2.1.fc26 @rawhide
kernel.x86_64 4.10.0-0.rc6.git0.1.fc26 @rawhide
kernel.x86_64 4.10.0-0.rc7.git1.1.fc26 @rawhide
Available Packages
kernel.x86_64 4.10.0-0.rc8.git0.1.fc26 rawhide
[root@omiday ~]# rpm -q dnf
dnf-2.1.0-1.fc26.noarch
10:50 a.m.
On Sat, 18 Feb 2017 14:03:45 +0100
GERHARD GOETZHABER <shmouftler1(a)gmail.com> wrote:
To make it clear:
1. Just download dnf-2.1.0-1.fc26.noarch.rpm and
python3-dnf-2.1.0-1.fc26.noarch.rpm from
https://kojipkgs.fedoraproject.org/packages/dnf/2.1.0/1.fc26/noarch/
(these two files only)
2. # dnf install <path/>dnf-2.1.0-1.fc26.noarch.rpm
<path/>python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing
(According dnf-automatic, dnf-conf and dnf-yum will get
installed within!)
All done - happy days are here again! : )
Not here. I tried all kinds of variations of the above, and I keep
getting errors. Command 2 above gives these errors:
# dnf
install ./dnf-2.1.0-1.fc26.noarch.rpm ./python3-dnf-2.1.0-1.fc26.noarch.rpm
--allowerasing Last metadata expiration check: 0:46:45 ago on Sun Feb
19 08:23:34 2017 MST. Error: Problem 1: conflicting requests
- nothing provides dnf-conf = 2.1.0-1.fc26 needed by
python3-dnf-2.1.0-1.fc26.noarch Problem 2: package
dnf-2.1.0-1.fc26.noarch requires python3-dnf = 2.1.0-1.fc26, but none
of the providers can be installed
- conflicting requests
- nothing provides dnf-conf = 2.1.0-1.fc26 needed by
python3-dnf-2.1.0-1.fc26.noarch
When I fix that by putting in dnf-conf, it wants to remove 166
packages. That doesn't seem reasonable; shouldn't those packages be
updated to allow them to update also? I'd post the output, but dnf is
seg faulting every time now.
When I try to use rpm to Update dnf and python3-dnf, it errors out
with the following:
# rpm -U ./dnf-2.1.0-1.fc26.noarch.rpm ./python3-dnf-2.1.0-1.fc26.noarch.rpm
./dnf-conf-2.1.0-1.fc26.noarch.rpm
error: Failed dependencies:
dnf = 2.0.0-0.rc2.5.fc26 is needed by (installed)
dnf-yum-2.0.0-0.rc2.5.fc26.noarch
python3-hawkey >= 0.7.1 is needed by python3-dnf-2.1.0-1.fc26.noarch
system-python(abi) = 3.6 is needed by python3-dnf-2.1.0-1.fc26.noarch
dnf-conf = 2.0.0-0.rc2.5.fc26 is needed by (installed)
python2-dnf-2.0.0-0.rc2.5.fc26.noarch
When I search in koji, the latest version of python3-hawkey is
python3-hawkey-0.6.3-6.2.fc25.x86_64.rpm. I can't find a
python3-hawkey for fc26 in koji. How can this update ever succeed if
its dependencies can't be met? And how did this update get built?
So, I forced the install of the new dnf using rpm. And now I get the
following error when I try to run dnf:
# dnf
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
ImportError: No module named 'dnf'
Is BFO working for rawhide again? The last time I tried to use it to
install rawhide, it just ignored the command and returned to the menu.
But that was around the time that f25 was splitting from rawhide.
As the other poster said, dnf is a very special component of fedora, so
it should be handled very carefully.
12:23 p.m.
On Sun, 19 Feb 2017 09:50:24 -0700
stan <stanl-fedorauser(a)vfemail.net> wrote:
On Sat, 18 Feb 2017 14:03:45 +0100
GERHARD GOETZHABER <shmouftler1(a)gmail.com> wrote:
> To make it clear:
>
> 1. Just download dnf-2.1.0-1.fc26.noarch.rpm and
> python3-dnf-2.1.0-1.fc26.noarch.rpm from
> https://kojipkgs.fedoraproject.org/packages/dnf/2.1.0/1.fc26/noarch/
> (these two files only)
>
> 2. # dnf install <path/>dnf-2.1.0-1.fc26.noarch.rpm
> <path/>python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing
> (According dnf-automatic, dnf-conf and dnf-yum will get
> installed within!)
>
> All done - happy days are here again! : )
Not here. I tried all kinds of variations of the above, and I keep
getting errors. Command 2 above gives these errors:
[snip]
So, I forced the install of the new dnf using rpm. And now I get
the
following error when I try to run dnf:
# dnf
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
ImportError: No module named 'dnf'
I downgraded to the last version of dnf that uses the python 3.5 ABI,
and dnf works again, with occasional segfaults. But it won't update
anything because there are too many conflicts with going to python
3.6. How is this not python 4? If the ABI changes so much between 3.5
and 3.6 that they are backward incompatible, then it isn't python3
any more. What are the python developers thinking?
I ran a dnf --best update and there are 317 errors, and dnf skips
everything. :-)
Most of the errors are related to the 3.6 ABI update, and packages that
aren't upgraded yet. They propagate back up the libsolv chain, and
prevent everything else from updating.
I suppose I'll be forced to --allowerasing if I want to do a dnf
update. Or force install the dnf dependencies of the new 3.6 ABI so I
can then run dnf update and have it update everything else.
What a mess. Maybe a new install of rawhide would be easier.
3:14 p.m.
On Sun Feb 19 2017 11:23:24 GMT-0700 (MST) stan
<stanl-fedorauser(a)vfemail.net> wrote:
I ran a dnf --best update and there are 317 errors, and dnf skips
everything. :-)
[...]
I suppose I'll be forced to --allowerasing if I want to do a dnf
update. Or force install the dnf dependencies of the new 3.6 ABI so I
can then run dnf update and have it update everything else.
What a mess. Maybe a new install of rawhide would be easier.
Or use the rpmdb from a backup as a reference to bring the system to
that state.
On a related note, I recall a discussion somewhere on the Fedora mailing
lists, about doing an LVM snapshot of rootfs prior to upgrading as an
easy way to roll back.
--
Viorel
7:18 p.m.
On Sun, 19 Feb 2017 14:14:26 -0700
Viorel Tabara <viorel.tabara(a)infrabit.net> wrote:
Or use the rpmdb from a backup as a reference to bring the system to
that state.
It's back in the original state, I just had to force install a dnf
version that was compatible with python3 3.5 ABI. The problem is that
it won't update to python3 3.6 ABI from there. I'll have to do some
manual manipulations to get there.
On a related note, I recall a discussion somewhere on the Fedora
mailing lists, about doing an LVM snapshot of rootfs prior to
upgrading as an easy way to roll back.
I think I remember reading that. And, I think I've seen dnf taking a
snapshot before updating if the snapshot plugin is installed and
enabled.
3:23 p.m.
On Sun, 19 Feb 2017 11:23:24 -0700
stan <stanl-fedorauser(a)vfemail.net> wrote:
I ran a dnf --best update and there are 317 errors, and dnf skips
everything. :-)
The python3-hawkey package is part of the libdnf src rpm, so it exists,
but is being blocked from install because it requires python3 3.6, and
that is being blocked.
I started to unravel the dependencies, but got disillusioned because
there were so many of them and they were like spaghetti, so I put it on
hold for a while. When I get my enthusiasm back, I'll revisit the
problems.
6:43 p.m.
On Sun, 2017-02-19 at 11:23 -0700, stan wrote:
I downgraded to the last version of dnf that uses the python 3.5 ABI,
and dnf works again, with occasional segfaults. But it won't update
anything because there are too many conflicts with going to python
3.6. How is this not python 4? If the ABI changes so much between 3.5
and 3.6 that they are backward incompatible, then it isn't python3
any more. What are the python developers thinking?
It's nothing new, this is how Python has always worked, all the way
back to 2.x (not sure about 1.x). Minor release versions always bump
the ABI.
I ran a dnf --best update and there are 317 errors, and dnf skips
everything. :-)
Most of the errors are related to the 3.6 ABI update, and packages that
aren't upgraded yet. They propagate back up the libsolv chain, and
prevent everything else from updating.
I suppose I'll be forced to --allowerasing if I want to do a dnf
update. Or force install the dnf dependencies of the new 3.6 ABI so I
can then run dnf update and have it update everything else.
I'd just do a --best --allowerasing and see what it's actually blocked
on. There aren't actually many things left that aren't rebuilt for
Python 3.6 at this point, and most of the ones that are left are pretty
obscure. You can see the list in every 'rawhide compose report' mail,
as it lists all packages whose dependencies cannot be resolved. Most of
the issues in the current Rawhide compose are actually with boost.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:25 p.m.
On Sun, 19 Feb 2017 16:43:39 -0800
Adam Williamson <adamwill(a)fedoraproject.org> wrote:
It's nothing new, this is how Python has always worked, all the
way
back to 2.x (not sure about 1.x). Minor release versions always bump
the ABI.
I've never noticed it before. It seems counter intuitive to me, like
bumping a library so number without raising the version number. I
suppose there must be a reason.
I'd just do a --best --allowerasing and see what it's
actually blocked
on. There aren't actually many things left that aren't rebuilt for
Python 3.6 at this point, and most of the ones that are left are
pretty obscure. You can see the list in every 'rawhide compose
report' mail, as it lists all packages whose dependencies cannot be
resolved. Most of the issues in the current Rawhide compose are
actually with boost.
Thanks, this should be helpful. If I can delete just a few packages,
and get the update to succeed, then I can re-install them when they get
updated.
Yeah, I think I noticed boost in the list of problems dnf produced.
12:39 p.m.
First, I had the same problems as Stan, and the whole secret is calling
DNF for both RPMs strictly together in one single command:
So said you've stored the files in the directory /temp your command will
be "dnf install /temp/dnf-2.1.0-1.fc26.noarch.rpm
/temp/python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing", but best of
all will be first going to /temp (or wherever your RPMs are staying) by
cd and from therein just executing "dnf install
{,python3-}dnf-2.1.0-1.fc26.noarch.rpm --allowerasing"!
On 2/19/17 5:50 PM, stan wrote:
On Sat, 18 Feb 2017 14:03:45 +0100
GERHARD GOETZHABER <shmouftler1(a)gmail.com> wrote:
> To make it clear:
>
> 1. Just download dnf-2.1.0-1.fc26.noarch.rpm and
> python3-dnf-2.1.0-1.fc26.noarch.rpm from
> https://kojipkgs.fedoraproject.org/packages/dnf/2.1.0/1.fc26/noarch/
> (these two files only)
>
> 2. # dnf install <path/>dnf-2.1.0-1.fc26.noarch.rpm
> <path/>python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing
> (According dnf-automatic, dnf-conf and dnf-yum will get
> installed within!)
>
> All done - happy days are here again! : )
Not here. I tried all kinds of variations of the above, and I keep
getting errors. Command 2 above gives these errors:
# dnf
install ./dnf-2.1.0-1.fc26.noarch.rpm ./python3-dnf-2.1.0-1.fc26.noarch.rpm
--allowerasing Last metadata expiration check: 0:46:45 ago on Sun Feb
19 08:23:34 2017 MST. Error: Problem 1: conflicting requests
- nothing provides dnf-conf = 2.1.0-1.fc26 needed by
python3-dnf-2.1.0-1.fc26.noarch Problem 2: package
dnf-2.1.0-1.fc26.noarch requires python3-dnf = 2.1.0-1.fc26, but none
of the providers can be installed
- conflicting requests
- nothing provides dnf-conf = 2.1.0-1.fc26 needed by
python3-dnf-2.1.0-1.fc26.noarch
When I fix that by putting in dnf-conf, it wants to remove 166
packages. That doesn't seem reasonable; shouldn't those packages be
updated to allow them to update also? I'd post the output, but dnf is
seg faulting every time now.
When I try to use rpm to Update dnf and python3-dnf, it errors out
with the following:
# rpm -U ./dnf-2.1.0-1.fc26.noarch.rpm ./python3-dnf-2.1.0-1.fc26.noarch.rpm
./dnf-conf-2.1.0-1.fc26.noarch.rpm
error: Failed dependencies:
dnf = 2.0.0-0.rc2.5.fc26 is needed by (installed)
dnf-yum-2.0.0-0.rc2.5.fc26.noarch
python3-hawkey >= 0.7.1 is needed by python3-dnf-2.1.0-1.fc26.noarch
system-python(abi) = 3.6 is needed by python3-dnf-2.1.0-1.fc26.noarch
dnf-conf = 2.0.0-0.rc2.5.fc26 is needed by (installed)
python2-dnf-2.0.0-0.rc2.5.fc26.noarch
When I search in koji, the latest version of python3-hawkey is
python3-hawkey-0.6.3-6.2.fc25.x86_64.rpm. I can't find a
python3-hawkey for fc26 in koji. How can this update ever succeed if
its dependencies can't be met? And how did this update get built?
So, I forced the install of the new dnf using rpm. And now I get the
following error when I try to run dnf:
# dnf
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
ImportError: No module named 'dnf'
Is BFO working for rawhide again? The last time I tried to use it to
install rawhide, it just ignored the command and returned to the menu.
But that was around the time that f25 was splitting from rawhide.
As the other poster said, dnf is a very special component of fedora, so
it should be handled very carefully.
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
3:07 p.m.
On Sun Feb 19 2017 09:50:24 GMT-0700 (MST) stan
<stanl-fedorauser(a)vfemail.net> wrote:
Not here. I tried all kinds of variations of the above, and I keep
getting errors.
I prefer to keep the Koji URL as a visual clue in dnf history:
[root@omiday ~]# dnf history dnf
Last metadata expiration check: 2:11:01 ago on Sun Feb 19 11:40:53 2017 MST.
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
323 | install https://kojipkgs | 2017-02-17 22:55 | Update | 7 <
322 | upgrade dnf | 2017-02-17 22:50 | Update | 9 >
275 | -y upgrade | 2017-01-01 20:31 | I, O, U | 708 EE
265 | upgrade | 2016-12-19 13:38 | E, I, O, U | 615 EE
227 | --releasever=rawhide sys | 2016-11-24 17:55 | D, E, I, O, U | 1358 EE
200 | -y upgrade | 2016-10-20 10:59 | E, I, U | 146
145 | upgrade | 2016-09-15 20:22 | E, I, O, U | 209 EE
117 | --nogpgcheck upgrade | 2016-08-20 16:33 | E, I, U | 91
100 | --releasever=25 system-u | 2016-08-11 13:56 | D, E, I, O, U | 1492 EE
1 | | 2016-06-14 10:31 | Install | 1364 EE
It does take me a bit longer to build the dependency list but it's not
something that bothers me that much, I rarely rely on Koji RPMs:
[root@omiday ~]# dnf history info 323
Last metadata expiration check: 2:11:12 ago on Sun Feb 19 11:40:53 2017 MST.
Transaction ID : 323
Begin time : Fri Feb 17 22:55:16 2017
Begin rpmdb : 2651:a559e374360c3500f0c5d574f47f2d81aab6a6ab
End time : 22:55:23 2017 (7 seconds)
End rpmdb : 2652:70ab883f3c3b46c029d1650e7d60b5571e6df359
User : <lelu>
Return-Code : Success
Command Line : install
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/dnf-...
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/pyth...
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/dnf-...
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/pyth...
https://kojipkgs.fedoraproject.org//packages/yum/3.4.3/512.fc26/noarch/yu...
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/dnf-...
https://kojipkgs.fedoraproject.org//packages/dnf/2.1.0/1.fc26/noarch/dnf-...
Transaction performed with:
Upgraded dnf-2.0.1-2.fc26.noarch @rawhide
Installed rpm-4.13.0-11.fc26.x86_64 @rawhide
Packages Altered:
Upgraded dnf-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded dnf-automatic-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded dnf-conf-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded dnf-yum-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded python2-dnf-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded python3-dnf-2.0.1-2.fc26.noarch @rawhide
Upgrade 2.1.0-1.fc26.noarch @@commandline
Upgraded yum-3.4.3-511.fc26.noarch @@commandline/rawhide
Upgrade 3.4.3-512.fc26.noarch @@commandline
# dnf install ./dnf-2.1.0-1.fc26.noarch.rpm
./python3-dnf-2.1.0-1.fc26.noarch.rpm --allowerasing
I try to stay away from "allowerasing" -- once I had to go through a
massive rpm-fu work. It was fun but time consuming.
--
Viorel
7:13 p.m.
On Sun, 19 Feb 2017 14:07:28 -0700
Viorel Tabara <viorel.tabara(a)infrabit.net> wrote:
I prefer to keep the Koji URL as a visual clue in dnf history:
[snip]
That was interesting. I learned something new. Thanks.
I try to stay away from "allowerasing" -- once I had to go
through a
massive rpm-fu work. It was fun but time consuming.
Yeah, that's why I'm holding off too.
7:11 p.m.
On Sat, 2017-02-18 at 05:43 +0000, Russel Winder wrote:
2. The Rawhide integration tests should not have allowed this
obviously
breaking application into the distribution.
There are no Rawhide integration tests. This is something that a lot of
people are working on at present.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:13 p.m.
On Sat, 2017-02-18 at 05:43 +0000, Russel Winder wrote:
This has been happening for a while now. Given that dnf is so
critical
to updating Rawhide I would not have expected this to be the case.
It was in fact fixed a while ago (as Viorel explained). But Rawhide
packages only appear in the repository after a successful Rawhide
compose, and Rawhide compose has failed every day since 20170215, so no
packages built since then are in the repo; you have to get them from
kojipkgs until compose works again.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:05 a.m.
On 02/19/2017 02:13 AM, Adam Williamson wrote:
On Sat, 2017-02-18 at 05:43 +0000, Russel Winder wrote:
> This has been happening for a while now. Given that dnf is so critical
> to updating Rawhide I would not have expected this to be the case.
It was in fact fixed a while ago (as Viorel explained). But Rawhide
packages only appear in the repository after a successful Rawhide
compose,
Why?
and Rawhide compose has failed every day since 20170215, so no
packages built since then are in the repo; you have to get them from
kojipkgs until compose works again.
This is not helpful. It disables people/testers from testing, building
and upgrading packages.
Ralf
11:02 a.m.
On Sun, 2017-02-19 at 07:05 +0100, Ralf Corsepius wrote:
On 02/19/2017 02:13 AM, Adam Williamson wrote:
> On Sat, 2017-02-18 at 05:43 +0000, Russel Winder wrote:
> > This has been happening for a while now. Given that dnf is so critical
> > to updating Rawhide I would not have expected this to be the case.
>
> It was in fact fixed a while ago (as Viorel explained). But Rawhide
> packages only appear in the repository after a successful Rawhide
> compose,
Why?
Because that's how the process works. Basically, because signing and
mashing happen as part of the compose; the way Fedora repos work you
can't simply take the output of Koji and stuff it straight into the
repository. Apply to releng for more details.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:07 a.m.
On Sun, 2017-02-19 at 09:02 -0800, Adam Williamson wrote:
On Sun, 2017-02-19 at 07:05 +0100, Ralf Corsepius wrote:
> On 02/19/2017 02:13 AM, Adam Williamson wrote:
> > On Sat, 2017-02-18 at 05:43 +0000, Russel Winder wrote:
> > > This has been happening for a while now. Given that dnf is so critical
> > > to updating Rawhide I would not have expected this to be the case.
> >
> > It was in fact fixed a while ago (as Viorel explained). But Rawhide
> > packages only appear in the repository after a successful Rawhide
> > compose,
>
> Why?
Because that's how the process works. Basically, because signing and
mashing happen as part of the compose; the way Fedora repos work you
can't simply take the output of Koji and stuff it straight into the
repository. Apply to releng for more details.
To provide a bit more detail, the Rawhide repo is:
http://download.fedoraproject.org/pub/fedora/linux/development/rawhide//E...
as you can see in fedora-rawhide.repo (the metalink provides this
same location on a mirror). That's not 'just' a repository. What you
find at:
http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/
is an entire Rawhide compose, with install trees and installer images
and all the other paraphernalia. Whenever there's a successful Rawhide
compose, it gets synced into that location (over whichever compose was
there before). So as there was a successful Rawhide compose today,
what's there now (allowing for mirror sync) has changed since yesterday
and the updated dnf is there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:20 p.m.
On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote:
So as there was a successful Rawhide compose today,
what's there now (allowing for mirror sync) has changed since yesterday
and the updated dnf is there.
Sorry, I was wrong about this, I misread my emails a bit. There's still
not been a successful compose since 20170215. Hopefully we get one
soon.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:38 a.m.
On 02/20/2017 03:20 AM, Adam Williamson wrote:
On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote:
> So as there was a successful Rawhide compose today,
> what's there now (allowing for mirror sync) has changed since yesterday
> and the updated dnf is there.
Sorry, I was wrong about this, I misread my emails a bit. There's still
not been a successful compose since 20170215. Hopefully we get one
soon.
In other words, since Feb 15, due to rawhide not having been updated you
have strangled any local package building and testing rawhide.
To me this qualifies as your "That's how things work" being
fundamentally flawed and broken for no-good, absurd reasons.
Ralf
10:16 a.m.
On Mon, 2017-02-20 at 16:38 +0100, Ralf Corsepius wrote:
On 02/20/2017 03:20 AM, Adam Williamson wrote:
> On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote:
> > So as there was a successful Rawhide compose today,
> > what's there now (allowing for mirror sync) has changed since yesterday
> > and the updated dnf is there.
>
> Sorry, I was wrong about this, I misread my emails a bit. There's still
> not been a successful compose since 20170215. Hopefully we get one
> soon.
In other words, since Feb 15, due to rawhide not having been updated you
have strangled any local package building and testing rawhide.
To me this qualifies as your "That's how things work" being
fundamentally flawed and broken for no-good, absurd reasons.
I don't know why you're talking about 'me', since I've not got
anything
to do with release engineering.
Since I don't work for release engineering I don't know all the details
about why the process works this way, I clearly can't have passed those
reasons on to you, so your assertion that the reasons are 'no-good
[and] absurd' is itself absurd.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:46 a.m.
On 02/20/2017 05:16 PM, Adam Williamson wrote:
On Mon, 2017-02-20 at 16:38 +0100, Ralf Corsepius wrote:
> On 02/20/2017 03:20 AM, Adam Williamson wrote:
>> On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote:
>>> So as there was a successful Rawhide compose today,
>>> what's there now (allowing for mirror sync) has changed since yesterday
>>> and the updated dnf is there.
>>
>> Sorry, I was wrong about this, I misread my emails a bit. There's still
>> not been a successful compose since 20170215. Hopefully we get one
>> soon.
>
> In other words, since Feb 15, due to rawhide not having been updated you
> have strangled any local package building and testing rawhide.
>
> To me this qualifies as your "That's how things work" being
> fundamentally flawed and broken for no-good, absurd reasons.
I don't know why you're talking about 'me', since I've not got
anything
to do with release engineering.
Then extend my sentences to releng. Fact is YOU (who ever feels
addressed) are strangling Fedora and render testing and development into
a joke.
Since I don't work for release engineering I don't know all
the details
about why the process works this way, I clearly can't have passed those
reasons on to you, so your assertion that the reasons are 'no-good
[and] absurd' is itself absurd.
Quite simple: Making "a consistent release" a prerequisite to rawhide is
utter non-sense. Rawhide is not a release. The person, who added this
prerequisite, should leave Fedora, IMNSHO. Rawhide serves testing
purposes and by-definition is permanently broken.
Or more pragmatically put: in current (Feb 15) release:
- The kernel is broken for me (doesn't boot)
- glibc is broken for me (It segfaults).
- dnf is a corrupt and inconsistent train-wreck.
...
Since then, probably several 100s of supposed to-be-bugfixes where
built, but YOU are keeping them behind closed doors.
Ralf
11:16 a.m.
On Mon, 2017-02-20 at 17:46 +0100, Ralf Corsepius wrote:
The person, who added this
prerequisite, should leave Fedora, IMNSHO.
This kind of tone is unacceptable and a clear violation of the Code of
Conduct:
https://getfedora.org/code-of-conduct
"Be respectful. Not all of us will agree all the time, but disagreement
is no excuse for poor behavior and poor manners. We might all
experience some frustration now and then, but we cannot allow that
frustration to turn into a personal attack."
I'm placing you on moderation for this list.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:47 p.m.
On Mon Feb 20 2017 10:16:42 GMT-0700 (MST) Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Mon, 2017-02-20 at 17:46 +0100, Ralf Corsepius wrote:
> The person, who added this prerequisite, should leave Fedora,
> IMNSHO.
This kind of tone is unacceptable and a clear violation of the Code of
Conduct:
https://getfedora.org/code-of-conduct
"Be respectful. Not all of us will agree all the time, but
disagreement is no excuse for poor behavior and poor manners. We might
all experience some frustration now and then, but we cannot allow that
frustration to turn into a personal attack."
I'm placing you on moderation for this list.
+1 and thanks.
On a related note, Rawhide documentation is clear about the risks of
running an non-stable version [1].
--
Viorel
[1]:https://fedoraproject.org/wiki/Releases/Rawhide
2619
days inactive
2622
days old
23 comments
6 participants
participants (6)
-
Adam Williamson -
GERHARD GOETZHABER -
Ralf Corsepius -
Russel Winder -
stan -
Viorel Tabara