Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 985103 - Spaces in default additional repository ID/name cause silent failure to use it
Summary: Spaces in default additional repository ID/name cause silent failure to use it
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: mulhern
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1020991
TreeView+ depends on / blocked
Reported: 2013-07-16 19:23 UTC by David Woodhouse
Modified: 2015-06-22 20:24 UTC (History)
8 users (show)

Fixed In Version: anaconda-21.3-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1020991 (view as bug list)
Last Closed: 2015-06-22 20:24:38 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1018284 None None None Never

Internal Links: 1018284

Description David Woodhouse 2013-07-16 19:23:48 UTC
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">
   <description>Smallest possible installation</description>
      <packagereq type="mandatory">intel-fedora-release</packagereq>
      <packagereq type="mandatory">intel-pki</packagereq>
    <description>Common set of utilities that extend the minimal installation.</description>
      <packagereq type="mandatory">intel-user-setup</packagereq>

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.

Comment 1 David Woodhouse 2013-07-16 19:42:11 UTC
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).

Comment 2 David Woodhouse 2013-07-16 23:02:25 UTC
There's something really odd going on here. Sometimes it seems to work, and sometimes it doesn't.

Comment 3 David Woodhouse 2013-07-16 23:14:01 UTC
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?

Comment 4 Chris Lumens 2013-08-21 19:09:28 UTC
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.

Comment 5 David Woodhouse 2013-08-21 19:54:12 UTC
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?

Comment 6 Chris Lumens 2013-08-21 20:31:19 UTC
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.

Comment 7 David Woodhouse 2013-09-05 15:42:02 UTC
This will never be fixed in Fedora 19, presumably. Refiling to Fedora 20.

Comment 8 mulhern 2013-10-10 19:48:59 UTC
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.

Comment 9 David Woodhouse 2013-10-10 20:05:39 UTC
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.

Comment 10 David Woodhouse 2013-10-10 20:16:54 UTC
(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?



Comment 11 mulhern 2013-10-11 12:28:33 UTC
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.

Comment 12 mulhern 2013-10-11 15:42:19 UTC
Would be helpful if yum made its id requirements more accessible to client code so filed an RFE at

Comment 13 mulhern 2013-10-14 12:59:45 UTC
Need also to prevent duplicate repo names as yum requires unique names (which it calls ids).

Comment 14 mulhern 2013-10-14 13:58:11 UTC
Need also to prevent additional repo names conflicting with regular old repo names like "updates" and "fedora".

Comment 15 mulhern 2013-10-15 12:08:00 UTC
Have a partial fix but would go a little bit more smoothly if there wasn't this apparent bug in PyGobject (

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.

Comment 16 mulhern 2013-10-24 14:23:05 UTC
Fix pushed to master/f20-branch.

Comment 17 Fedora End Of Life 2015-05-29 09:11:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.