Bug 209515 - ports-mgmt/portupgrade: portsdb fails bacause of uninitialized constant
Summary: ports-mgmt/portupgrade: portsdb fails bacause of uninitialized constant
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Bryan Drewery
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-15 07:44 UTC by tschweikle
Modified: 2019-04-28 18:10 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (bdrewery)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tschweikle 2016-05-15 07:44:05 UTC
+ portsdb -u
portsdb: uninitialized constant PkgDBTools::DBError
++ exit 1
++ exit 1
Comment 1 tschweikle 2016-05-29 10:13:09 UTC
Fixed as of newer portupgrade and tools portupgrade depends on.
Comment 2 Chris Collins 2017-12-11 22:04:00 UTC
not fixed, getting myself on a 11.1 system.

Portupgrade crashed 80% through a rebuild all ports task, didnt show what was done so I got no idea what progress was made, and now generates this when rerunning it, even with just -h argument.

/usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgdbtools.rb:104:in `rescue in db_driver=': uninitialized constant PkgDBTools::DBError (NameError)
        from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgdbtools.rb:63:in `db_driver='
        from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/portsdb.rb:168:in `setup'
        from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgtools.rb:242:in `init_pkgtools_global'
        from /usr/local/sbin/portupgrade:531:in `block in main'
        from /usr/local/lib/ruby/2.4/optparse.rb:1062:in `initialize'
        from /usr/local/sbin/portupgrade:238:in `new'
        from /usr/local/sbin/portupgrade:238:in `main'
        from /usr/local/sbin/portupgrade:2380:in `<main>'

Sadly portupgrade seems to be problematic with its db unresolved issues for years, with the main dev not active responding to issue reports, but portmaster is poor feature wise.  So I keep using it.

Any idea how to fix this one?

I already recompiled ruby, ruby-dbd and portupgrade.
Comment 3 Bryan Drewery freebsd_committer 2018-01-24 18:22:21 UTC
I'll take another look sometime.
Comment 4 Chris Collins 2018-10-23 09:45:55 UTC
Still broken, on 26 servers currently.

But working on another 42 servers, I dont know what triggers it as all the servers are configured equally, just different hardware, some of the servers it originally worked but then breaks after a portupgrade crash.

Doesnt matter what ruby version is used or if portupgrade vs portupgrade-devel port.

Only flag set in make.conf is cputype.
Comment 5 Mikhail Teterin freebsd_committer 2019-04-25 13:39:02 UTC
I'm having this now as well -- the problem started appearing in the middle of a portupgrade run. Using portupgrade-devel-20180309 thus:

         portupgrade -v -a -rR --config

I tie this to the upgrade of ruby24-bdb to ruby25-bdb, which portugprade itself has executed:

[...]
Apr 24 21:05:52 kachka pkg-static: ruby-2.5.5_1,1 installed
Apr 24 21:08:21 kachka pkg: ruby24-bdb-0.6.6_5 deinstalled
Apr 24 21:08:23 kachka pkg-static: ruby25-bdb-0.6.6_6 installed

After reinstalling portupgrade -- which switched the Ruby scripts from $PREFIX/bin/ruby to $PREFIX/bin/ruby25 -- things began to work again...

I'd say, portupgrade should implement special handling for when it upgrades itself OR any of the components it uses (ruby, ruby-bdb, etc.)
Comment 6 Chris Collins 2019-04-28 18:10:24 UTC
I finally did resolve it but since there was no interest shown developer side  I didnt post the followup.

In my case it was caused by something ruby side not liking hardening compile flags so ssp-buffer-size=4 and stack protector.

I had to remove from both ruby and ruby-bdb then it works as expected.

Really there needs to be some kind of built in diagnosis which would indicate the problem.  Nothing was actually visibly crashing so all seemed fine, but clearly something internally must have failed as it silently fell back to the other database type.

As to the flags I used I know they non default, but I would expect these days the vast majority of software to handle them, as is standard on many OS to use those flags now, FreeBSD is one of the few remaining hold outs.

I do feel I remember testing this on a empty make.conf, or at least with only cputype set, but I guess I am wrong given what I found to be the solution or maybe when I tested it, it was never with both ruby and ruby-bdb at the same time because they are both required to not have those flags not just one or the other.