Fedora 11: yum hangs on 'Setting up Package Sacks'

NOTE: this post was originally written after seeing this problem in rawhide. The problem persisted into Fedora 11, but all the notes below are for a rawhide configuration. The fix below works for the fedora.repo also.

---

If you are trying Fedora 11 and yum hangs showing the following output:

# yum -v update
Config time: 0.045
Yum Version: 3.2.22
Setting up Package Sacks
_

Do not fear. There are (at least) two reasons why you can see this issue. First, the problem may just be an intersection between your proxy's configuration and the default yum configuration. If you are behind a proxy, just edit the file /etc/yum.repos.d/fedora-rawhide.repo and change the default "mirrorlist" entry to use http instead of https as follows:

mirrorlist=http://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i386
enabled=1

Of course, you will need to leave the "arch" as x86_64 if you are installing on a 64bit machine. The default https that fedora has chosen will not work with many "transparent" proxy setups, so just change it to http, and you should be fine.

Note, all this assumes that you set up your proxy as follows:

# export http_proxy=http://my-semi-xparent-proxy.com:8080

And when you do run a yum update, run it like this:

yum -v --enablerepo=rawhide update

Alternatively you can edit the /etc/yum.conf file and add a line like this

proxy=http://my_proxy.com:port/

Which brings us to the second easy way to get yourself stuck staring at 'Setting up Package Sacks'. This came up when folks were updating Fedora 11 - preview ... that is, do not run it simply as "yum update" like I did, because it will look as though it does the update just fine, but it will break yum. Doing a simple "yum update" without enabling rawhide will enable the base fedora.repo and the fedora-updates.repo, which will also cause yum to hang at 'Setting up Package Sacks' again with the new "https" in the newly updated "fedora.repo".

Then again, you may enjoy having some extra time while you stare at yum hanging at 'Setting up Package Sacks' until it times out, I sure did ... it gave me enough time to write the following rant.

Remember ... this was the Fedora 11 preview, so you do not want to enable the normal repositories. This is a "feature bug" in my opinion. Doing an update should not change my enabled repositories without prompting me first. I say this is a bug because I have used Debian (sid) for years, and I have been using Redhat/Fedora for just as long, but I have never had this problem with Debian. Flame away.

Hope that helps.

UPDATE: Although this blog entry was for "Fedora 11 - preview" the solutions suggested here, as the anonymous comment below suggests, may also apply to Fedora 11 which has now been released.

Mother's day

Flowers from the kids
Asleep in the hammock
Mom with mom

All I Need Is God

Looks like my blue skies fade to gray
Looks like my pasture's gone away, but
I still don't need your golden cherubim

All I need is God
All I need is God
In the beginning
All I need is God
To survive
All I need is God
To help me all I need

By Kara

Error: 'CREATE VIEW' must be the first statement in a query batch

Have you ever gotten this error?

Error: 'CREATE VIEW' must be the first statement in a query batch.
SQLState: S0001
ErrorCode: 111

or maybe

Error: 'CREATE TRIGGER' must be the first statement in a query batch.

Well, do not worry. Here is how you can solve this issue: Just wrap your query with exec(''). For example, lets say your view is defined as

CREATE VIEW theView AS
   SELECT  tableA.id + '_' tableA.name AS ID_NAME,
      tableB.* FROM tableA a
   INNER JOIN tableB b ON a.a_id = b.b_Id

Well then just change your call as follows:

exec('CREATE VIEW theView AS
   SELECT  tableA.id + ''_'' tableA.name AS ID_NAME,
      tableB.* FROM tableA a
   INNER JOIN tableB b ON a.a_id = b.b_Id')

Notice that single quotes origninally in my CREATE statement are escaped as two consecutive single quotes after it is wrapped in the call to exec('').

You will get the error above, as I did, when executing the CREATE from within SQuirreL SQL, so apparently SQuirreL is attempting to do some 'innocent' things before the CREATE statement. Wrapping the CREATE in an exec forces SQuirreL to put the CREATE statement first in a separate execution plan.

Hope that helps you.

Fall Leaves

See those fall leaves falling from those fall trees? See the leaves falling? They are yellow, green, purple, and brown. Don't frown. Turn your frown upside down. Don't be a clown, 'cuz if your singing, you'll be slinging your love. See the fall leaves falling? Are you stalling? I think not, 'cuz it's getting alot better than I thought. Good night!

by Kara Singleton