View Issue Details

IDProjectCategoryView StatusLast Update
0004218unrealinstallingpublic2015-08-08 17:08
Reporterj883376Assigned Tosyzop 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version12.04 LTS
Product Version3.2.10.1 
Target VersionFixed in Version3.4-beta1 
Summary0004218: Config parameter -quick does not bypass SSL certificate generation
DescriptionWhen running ./Config with the option -quick, all initial questions before it runs ./configure are ignored as expected, however after it finishes running ./configure it asks whether you want to generate an SSL certificate. This causes issues for doing scripted, unattended installations.

I've attached a patch to solve the problem.
TagsNo tags attached.
3rd party modules

Activities

j883376

2013-05-27 07:48

reporter  

config.patch (127 bytes)

katsklaw

2013-05-29 14:00

reporter   ~0017694

Last edited: 2013-05-29 14:02

View 2 revisions

I'm unable to duplicate this bug on Unreal3.2.10.1 release on Debian 7 64bit.

Are you sure you tested from a clean install? or has Unreal been compiled before?

Even a make cleandir doesn't truly clean all residue. I do have a patch for 3.2.9 I think that added a standard make distclean but I don't think it was added.

j883376

2013-05-29 14:17

reporter   ~0017695

I'm able to reproduce it every time from a clean install. It seems that I missed a step in my explanation of the issue.

From a fresh directory manually create a config.settings file with CRYPTOIRCD="1" and GENCERTIFICATE="0". When you run ./Config -quick after having created the file, you will be prompted whether you'd like to generate an SSL certificate.

katsklaw

2013-05-29 14:38

reporter   ~0017697

Last edited: 2013-05-29 14:40

View 2 revisions

My problem here is that manually creating config related files is not part of the normal or documented installation process.

I understand that you may have specific needs, in that case your patch would likely be invaluable but for those that follow the already established installation process, there is no need to patch anything at all since the "bug" only appears after you perform steps outside the norm. By making my own custom edits, I can create "bugs" all day long, because again, it's not part of the "normal" process.

syzop

2015-08-08 17:07

administrator   ~0018634

oh, didn't know there was a bug report for this. I fixed this a few months ago in 3.4.x.

Issue History

Date Modified Username Field Change
2013-05-27 07:48 j883376 New Issue
2013-05-27 07:48 j883376 File Added: config.patch
2013-05-29 14:00 katsklaw Note Added: 0017694
2013-05-29 14:02 katsklaw Note Edited: 0017694 View Revisions
2013-05-29 14:17 j883376 Note Added: 0017695
2013-05-29 14:38 katsklaw Note Added: 0017697
2013-05-29 14:40 katsklaw Note Edited: 0017697 View Revisions
2014-03-14 01:14 peterkingalexander Issue cloned: 0004302
2015-08-08 17:07 syzop Note Added: 0018634
2015-08-08 17:07 syzop Status new => resolved
2015-08-08 17:07 syzop Fixed in Version => 3.4-beta1
2015-08-08 17:07 syzop Resolution open => fixed
2015-08-08 17:07 syzop Assigned To => syzop