I have an internal repository with packages in the 'Core' and 'Standard' group: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd"> <comps> <group> <id>core</id> <default>true</default> <uservisible>false</uservisible> <name>Core</name> <description>Smallest possible installation</description> <packagelist> <packagereq type="mandatory">intel-fedora-release</packagereq> <packagereq type="mandatory">intel-pki</packagereq> </packagelist> </group> <group> <id>standard</id> <name>Standard</name> <description>Common set of utilities that extend the minimal installation.</description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq type="mandatory">intel-user-setup</packagereq> </packagelist> </group> </comps> When I add this repository in the installer, none of its packages get installed. My first suspicion would be that I'm doing something wrong, but I observe a similar failure with the rpmfusion-free repository too. It also adds its rpmfusion-free-release package to @core, and it doesn't end up getting installed.
Hm, even the *updated* packages from this repository haven't been included (I have a handful of local builds of evolution-ews/glib2/libsoup with bug fixes which haven't made it to F19 updates yet).
There's something really odd going on here. Sometimes it seems to work, and sometimes it doesn't.
Perhaps it only worked when I changed the name from the default 'New Repository'. I see this in the logs: 22:57:40,117 INFO packaging: gathering repo metadata 22:57:40,119 WARN yum.YumBase: Bad id for repo: New Repository, byte = 3 22:57:40,122 DEBUG packaging: getting repo metadata for fedora Could it be that the space (which is in the default name that *ought* to be cosmetic AFAICT) is what's breaking it?
We use the ID in a couple places and likely aren't sanitizing it before passing it off to yum. It might help to get /tmp/packaging.log and /tmp/anaconda.log attached to this bug, too. Thanks.
I'm afraid I don't have them now. I wasn't about my own repository; adding *any* repo in the installer, using the default name that it offers, will trigger this. I could try to do a new install to capture this... but you're probably better set up to do that than I am anyway?
In fact, yum doesn't provide a name attribute - only an ID and it expects that to not have spaces in it. We need to do this translation back and forth in the UI.
This will never be fixed in Fedora 19, presumably. Refiling to Fedora 20.
This is not an anaconda bag. It occurs when anaconda requires the Python yum package for the first time. The .repo file is read during initialization of the yum package. If there is a non alpha-numeric \union {-_.:} character in a section header, then the error message Bad id for repo... will be logged by yum. But, unless it pre-processes the .repo files, anaconda can neither prevent nor detect this behavior.
But anaconda *created* the repo file with the invalid header in it. Surely the Anaconda GUI shouldn't have *let* me type a name for the repository which had a space in it? Or it should have done some sanitisation when it created the corresponding .repo file? Or perhaps it shouldn't have had a default name "New Repository", which if not overridden by the user will *already* result in it creating an invalid .repo file? If this is actually a bug in some component or library which is *used* by anaconda, and you expect the sanitisation to be done when the .repo file is created, then by all means refile against that package with a coherent explanation. But it is *not* 'NOTABUG'. Reopening.
(In reply to David Woodhouse from comment #9) > Or perhaps it shouldn't have had a default name "New Repository", which if > not overridden by the user will *already* result in it creating an invalid > .repo file? s/already/always/ Doh.
Revised Bug Description: Anaconda accepts a malformed repository name on "Installation Source" screen. Also, it defaults to the malformed repository name "New Repository" when the user begins to add additional repositories.
Would be helpful if yum made its id requirements more accessible to client code so filed an RFE at https://bugzilla.redhat.com/show_bug.cgi?id=1018284.
Need also to prevent duplicate repo names as yum requires unique names (which it calls ids).
Need also to prevent additional repo names conflicting with regular old repo names like "updates" and "fedora".
Have a partial fix but would go a little bit more smoothly if there wasn't this apparent bug in PyGobject (https://bugzilla.gnome.org/show_bug.cgi?id=710180). If done-editing signal is not acknowledged then must work with changed signal which fires on every edit. This means that a previous, possibly acceptable name, will be lost while entering the new name, whatever it is. Possible to hack around the problem, but a fix would be better.
Fix pushed to master/f20-branch.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.