Core: Project version texts causing rpm builds fail with 'Unknown tag: x.x.x.x' (x are version numbers)

[ahmedowsky]

I am facing this issue since our first rpm package i've built.

I am building a .NET Core project on my Windows machine, and then copying the built project onto the CentOS machine and then wrapping it up in an RPM.

I have a spec file which kind'a automates rpm builds. To specify rpm's version info, this spec file reads my dll's version (file version). I set this version information using "project properties -> package -> Assembly version & Assembly file version & Package version" inputs over visual studio (2017-windows).

Sometimes, not always but quite frequently, those version numbers are causing rpm builds fail with 'Unknown tag: x.x.x.x' message (x-es are version numbers). I found a turnaround for that which is ridiculous but works great.

I am opening a web browser, searching for the version number i want to use. Once the search is complete, i copy the text from one of search results and paste that text into "assembly version", "assembly file version" and "package version" inputs.

For example: current version is '1.1.1.1' and i want to change it as '1.1.1.2'. Then i google '2', copy another '2' from one of the search results and paste it into the last inputs of "assembly version", "assembly file version" and "package version".

And this solution never fails. The text i copy from a google search result works, buy my keyboard's input doesn't...

I don't even know where this issue belongs but it doesn't make one's life easy.

[karelz]

I don't quite understand what is the problem - it seems that you cannot edit fields in package properties inside Visual Studio. Is that correct?
Does it happen on more than 1 machine?
Did you try latest VS build?

[ahmedowsky]

@karelz i know you don't like reading, it's hard or whatever but, can you at least read the title?
Your question is really so irrelevant, so absurd.
Details (including examples) are below the title.
Those properties, are making, my rpm builds, to fail, if i use my keybord, to write, those version numbers.

Does it happen on more than 1 machine, yes
Did i try latest VS build, yes
Did i try older VS builds, yes
Change? None

[karelz]

@ahmedowsky no need to get angry here ... I am just trying to help you here. Personal attacks won't speed things up.

The fact is I never heard about rpm builds. The title may be self-explanatory for you, but sadly it is not clear to me. And while I read all your text, it was not clear to me either. Otherwise I would not ask the questions above.

For example, it is still not clear to me if you are unable to type anything in the text boxes (from keyboard), or if the values are just not being respected when typed from keyboard.
BTW: That's why clear step-by-step repro steps (starting with new project) help clarify things. If you don't know where the issue is (which component), it is GREAT help and usually makes routing to the right place much faster.

[ahmedowsky]

I'm sorry, i really am. I didn't mean to upset you. I was assuming that someone commenting under this issue would know about rpm builds.

I can edit package inputs over VS no problem there. I can build the project, no problem there. Published dll's are also has the right version information on them. All cool on windows / VS part.

Here's a step-by-step example

1. open a dotnet core console app / web api (doesn't matter)
2. build it & publish it & copy them inside a centos7 machine
3. create a spec file (this file is something like a rpm build instruction)
4. modify that spec file so it would be able to read rpm package's version information directly from the published dll (by doing so you won't have to edit spec file for every new version)
5. build rpm package for that published output inside the centos7 machine
   

   6. build passes, rpm package is ready (all cool)

BAD CASE

1. open project properties -> package
2. change "assembly version", "assembly file version" and "package version" as you wish, using numbers on your keyboard (lets say 1.1.1.1)
3. build it & publish it & copy them inside a centos7 machine
4. build rpm package for that published output inside the centos7 machine
   

   5. build fails (usually)

GOOD CASE

1. open project properties -> package
2. change "assembly version", "assembly file version" and "package version" as you wish, by copy-paste-ing numbers from a google search result (lets say 1.1.1.1)
3. build it & publish it & copy them inside a centos7 machine
4. build rpm package for that published output inside the centos7 machine
5. build always succeeds

[karelz]

Thanks for the steps! That will (hopefully) help me help you! ;)

build fails (usually)

Why did you say "usually"? Is it intermittent? (as in repeating builds sometime fail) Or is it just random if the problem will be hit or not and once it is, then it is persistent? How often does it happen? (in either case)
Is the error the one from title? "Unknown tag: x.x.x.x' (x are version numbers)" ... so in this case it would be "... 1.1.1.1"?

This is overall very weird (and interesting ;)). It sounds like VS in the "bad case" does not save some files. Can you please compare the project and its output between the "good case" and the "bad case" (ideally both changing to the same version number from the same original number) to observe if there is any difference.
Once we track down which file is different (i.e. it was not saved), maybe we can figure out which component is to blame (and to be routed to).

[karelz]

BTW: I updated your steps to add numbers and bad/good case titles for easier references during further discussion - I hope you don't mind.

[ahmedowsky]

Why did you say "usually"? Is it intermittent? (as in repeating builds sometime fail) Or is it just random if the problem will be hit or not and once it is, then it is persistent?

Random, if it's a fail, it always fails, doesn't matter how many times i repeat rpm build process after that

How often does it happen?

Quite often, i just prefer copy-paste-ing approach all the time

Is the error the one from title? "Unknown tag: x.x.x.x' (x are version numbers)" ... so in this case it would be "... 1.1.1.1"?

Yes, rpm build error will be "Unknown tag: 1.1.1.1" in this case

This is overall very weird (and interesting ;))

Watching your teammates faces right after explaining this situation is also funny

It sounds like VS in the "bad case" does not save some files

I'm not sure about that. All i do is reading the dll's version information. And spec file actually can read that, even in the 'bad case'.
On Spec file i have those two lines below.
%define assemblyFileVersion %(strings /bla/bla/app.dll | egrep '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$')
Version: %{assemblyFileVersion}

[omajid]

An error of the type Unknown tag: Foo generally means rpmbuild thinks the file contains this line:

Foo: Bar

As a test, I did:

%define assemblyFileVersion %(echo -e '1.\\n2.3\n4')
Version: %{assemblyFileVersion}

And the rpmbuild error is:

error: line 6: Unknown tag: 2.3n4

So, I can't help but wonder what assemblyFileVersion actually evaluates to. Can you print it out in hex form? I suspect newlines are somehow sneaking in.

Set Version to a hardcoded value in the spec file and put this in %prep:

xxd<<EOF                                                                                                          
%assemblyFileVersion                                                                                              
EOF   

(You might have to install vim-common package which provides xxd)

For my example, the rpmbuild log shows:

+ xxd                                                    
00000000: 312e 0a32 2e33 6e34 0a                   1..2.3n4.

[karelz]

@ahmedowsky it seems that @omajid is waiting on your response here - or did I miss something?

[karelz]

No response, closing. Feel free to reopen when there's more info. Thanks!