Orphaning: makedepf90
by Dominik 'Rathann' Mierzejewski
Dear All,
I'm orphaning the package makedepf90. I originally packaged it only
to be able to unbundle it from cp2k, where it was used during the
build process, but it hasn't been used since release 2.6.0, when
upstream switched to their own dependency generation script written
in python. If anyone wants to take it, feel free to do so. Nothing
depends on it as far as I know. Upstream website seems to be gone
since January 2017:
https://web.archive.org/web/20170116121627/http://personal.inet.fi/privat...
Last release was in June 2006.
I'll orphan the package as soon as pagure-over-dist-git is functional,
because PkgDB is read-only already.
Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
6 years, 7 months
Orphaning procedure for libpwiz
by Antonio Trande
Hi all.
I'm going to abandon 'libpwiz' package on f27.
Feel free to claim ownership if you need it.
Regards.
--
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
6 years, 7 months
Why Atomic Host should be built using Modularity
by Colin Walters
There was a discussion today in the Atomic WG about using Modules.
Meeting log: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-A...
Agenda discussion: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-A...
(Side note; this doc was originally stored at <https://gist.github.com/cgwalters/c69bf2091eab7c1af316d0d7dd41f530>)
This post is the "why" that I'd written earlier. Some of the rationale
here crosscuts with other active discussions; for example, keeping
Python 2 in Atomic Host, as well as Bodhi and update cadences.
There’s an effort in Fedora called
[“Modularity”](https://docs.pagure.org/modularity/) that effectively gives
multiple lifecycles for different components.
Today (and since the start), Fedora Atomic Host *is* Fedora - we have just added
another build process at the end of the "Everything" build process (and the same
is true of the `registry.fedoraproject.org/fedora` container). There's a lot of
benefits to that; any security fixes to e.g. `glibc` or `openssl` automatically
propagate.
Content streams
---------------
But on the other hand, Fedora Atomic Host is locked into the current Fedora
cycles; the freezes, then the "open the floodgates" model of Bodhi.
The "at most once a day updates" that Bodhi implements is quite suboptimal
for the server case. We go to quite a bit of effort to implement a "two
week" cadence for the ostree updates, distinct from whatever happens in Bodhi
day to day.
Further, we really have no idea what might land in Bodhi day to day. There
are a lot of updates that are basically non-critical, and should ideally
be batched together. Things like `rsync`.
Another issue is that we currently don't have any ability to do *overrides* when we need
to. If a package gets karma or the maintainer decides to ship it anyways, that's
basically it. Yes, ideally we don't have overrides, but the reality is we need
the ability, we just want to avoid using it in any long term capacity.
Moving towards a single stream
------------------------------
One of the major benefits of the rpm-ostree technology is that there's
no special distinction between minor and major upgrades, as we've ended
up with between `yum upgrade` and `dnf system-upgrade`. The underlying
ostree side is "image like" - we could easily do changes on the scale of
[UsrMove](https://fedoraproject.org/wiki/Features/UsrMove) without requiring
any special work or downtime, in the same way we can do small incremental updates
atomically. For example, imagine that we decided to switch to
the [Debian Multiarch](https://wiki.debian.org/Multiarch) layout. That'd
just be another atomic upgrade (with rollback, etc.)
See [this issue](https://pagure.io/atomic-wg/issue/228) for more background
discussion on this topic.
We'd like "Fedora Atomic Host" to simply be a single stream for most users.
This implies more than just having a unified update mechanism; we also
need to ensure that any Changes that land in "Fedora" are minimally
disruptive for the server case.
Good examples here are:
- https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
We'd probably take this change, but delay it quite a while. It makes
sense for desktops, and as an opt-in for server admins who want it.
- Dropping /usr/bin/python: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
This badly affects Ansible (which is quite important for Atomic Host)
Now, a lot of how this works comes down to how quickly Modularity
takes over Fedora and the changes in general. We're not going to get
out of being able to make changes like the above; but I think
we want more control over when they land - for example, allow
Workstation to actually do something earlier.
Basically, we want to create a minimal server OS focused
on container hosting which you can install to e.g. a
bare metal machine, and upgrade seamlessly in place
without any special work for years.
How many years? This proposal doesn't address that,
but it certainly seems to me like we could easily handle
2-3 years without major breaking changes.
Obviously again, a lot of this relies on containerization to be
truly successful. (And containerization in turn really requires
Modularity too!)
One important aspect of this the "system containers" effort to
move even things like Kubernetes into containers that are decoupled from
the host lifecycle. We'd likely have Kubernetes containers as modules,
with likely at least 2 major versions available.
Development benefits for AH
---------------------------
We want to minimize the number of versions of our critical path
components that we maintain; think `docker`, `ostree` etc. Now,
perhaps in a Modularity world we would end up offering multiple
`docker` RPMs (and containers), but I don't see a reason to maintain
multiple `ostree/rpm-ostree` for example. Another good example is
`cloud-init`. Further, the more we can move away from the generic
"rawhide" model to one where we have only transient branches for
e.g. `anaconda`, the better.
Or to phrase this another way - it's better if our "current stable" is the development stream target.
The at-most-once-a-day updates model is too slow for development (we want to test smaller incremental changes as they come in). The once-a-day model is also too fast for most end users (see above). It's also easier to link automated testing policy to modules rather than karma. And if something goes wrong in testing (say we encounter a kernel crasher), we want the ability to roll back versions - which `rpm-ostree` supports very well; `rpm-ostree upgrade` behaves like `yum distro-sync` always.
Development benefits for Fedora in general
------------------------------------------
By staying in sync with the base runtime etc., we unify development
and help push Modularity forwards.
Benefits to users
-----------------
Not much *directly*. However, for any users who want to e.g. file bugs, we can
make it more clear that e.g. if they have a problem with `coreutils`, that comes
from the base runtime, and ideally Bugzilla allows them to file bugs there.
If things like the Changes end up being written in terms of modules, we'll be able
to automatically pick those up.
What next
-------------
We're going to experiment with this!
6 years, 7 months
Fedora 25 GRUB security issue
by Chris Murphy
security@ and security-team@ have no meaningful activity in at least
the last 6 months so I'm posting this here.
grub2 incorrectly initialises the boot_params from the kernel image
https://bugzilla.redhat.com/show_bug.cgi?id=1418360
The gist is that the bug means the kernel can't determine UEFI secure
boot state, considers it not enabled, resulting in the kernel not
enabling certain checks it otherwise does when it knows secure boot is
enabled. Ergo, users who have secure boot enabled are not getting the
full benefit of secure boot, and this fallback is pretty much silent
(you'd have to be looking at kernel messages to know you're not
protected).
Fedora 26 has grub2-2.02-0.40.fc26.x86_64 which contains the fix. It
was proposed as a blocker bug, bug was rejected because it doesn't
have a formal security evaluation.
However, Fedora 24 didn't get the fix before going EOL. And Fedora 25
and Rawhide both still have this problem. And I think it needs
attention.
Thanks,
--
Chris Murphy
6 years, 7 months
Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/Schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
even.
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
release.
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
press push).
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 7 months
Build failures on alternative ("secondary") arches
by Peter Lemenkov
Hello All!
I've got two nasty packages. One fails to pass the tests on BigEndian
arches (s390x, ppc64), another one fails to pass the tests on POWER
(ppc64 and ppc64le).
So I have several questions.
* Can I have a shell access to the ppc64 machine (which covers both
cases) where I can install packages and can run gdb / git / gcc?
* How maintainers are supposed to handle it?
* (A provocative one) - is it better to me just to set ExclusiveArch
and open a bugzilla ticket with build log of the failed build?
Sometimes it's hard to do anything even on supported architecture, so
asking me to support a package for the rarely used architecture (which
I don't even have access to) is, well, slightly overoptimistic, no?
--
With best regards, Peter Lemenkov.
6 years, 7 months
FAILED: BuildError: package ... not in list for tag f27-pending
by Jos de Kloe
Hi,
I'm trying to do a build for the python-metar package (first time since
I adapted it after it was orphaned), but I constantly get this error
when I try to do a fedpkg build:
FAILED: BuildError: package metar not in list for tag f27-pending
does anyone know what is wrong, and how to solve it?
Could it be related to the fact that I renamed the spec file from
python-metar.py to metar.py in git?
(I did that since rpmlint gave me the error "E: invalid-spec-name")
Jos
6 years, 8 months