Bug 985103 - Spaces in default additional repository ID/name cause silent failure to use it
Spaces in default additional repository ID/name cause silent failure to use it
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: mulhern
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 1020991
  Show dependency treegraph
Reported: 2013-07-16 15:23 EDT by David Woodhouse
Modified: 2015-06-22 16:24 EDT (History)
8 users (show)

See Also:
Fixed In Version: anaconda-21.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1020991 (view as bug list)
Last Closed: 2015-06-22 16:24:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2013-07-16 15:23:48 EDT
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 15:42:11 EDT
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 19:02:25 EDT
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 19:14:01 EDT
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 15:09:28 EDT
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 15:54:12 EDT
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 16:31:19 EDT
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 11:42:02 EDT
This will never be fixed in Fedora 19, presumably. Refiling to Fedora 20.
Comment 8 mulhern 2013-10-10 15:48:59 EDT
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 16:05:39 EDT
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 16:16:54 EDT
(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 08:28:33 EDT
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 11:42:19 EDT
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.
Comment 13 mulhern 2013-10-14 08:59:45 EDT
Need also to prevent duplicate repo names as yum requires unique names (which it calls ids).
Comment 14 mulhern 2013-10-14 09:58:11 EDT
Need also to prevent additional repo names conflicting with regular old repo names like "updates" and "fedora".
Comment 15 mulhern 2013-10-15 08:08:00 EDT
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.
Comment 16 mulhern 2013-10-24 10:23:05 EDT
Fix pushed to master/f20-branch.
Comment 17 Fedora End Of Life 2015-05-29 05:11:07 EDT
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.