Public bug reported:

Hi,
I tried to fulfil to the promise that dpb made and tried to help with som 
eolder proposed migrations.
After a while I found something I can actually help, so I looked at asyncpg.
Building version 0.13.0-1 was failing on armhf [1]

Error (all 198 of them):
E   ValueError: invalid literal for int() with base 10: '1 (Ubuntu 10'

That seems to do a int conversion with something that gets an "1 (Ubuntu 10" as 
text.
That is in function split_server_version_string
The failing variable is the argument "version_string"

That could be related to postgres 10 now being to digits.
But why only on armhf then?

It triggers the code on setup when checking for the postgres version.
Function _get_pg_version in asyncpg/cluster.py.

To get it it calls effectively:
/usr/lib/postgresql/10/bin/postgres --version

This is now the string:
"postgres (PostgreSQL) 10.1 (Ubuntu 10.1-3)"

Then it drops the prefix:
"10.1 (Ubuntu 10.1-3)"

Well all that happens on x86 as well.
If I modify the source to be a callable program and iterate a bit I see that:
$ ./test-serverversion.py "10.1 (Ubuntu 10.1-3)"
Initial 10.1 (Ubuntu 10.1-3)
parts ['10', '1 (Ubuntu 10', '1']
Traceback (most recent call last):
  File "./test-serverversion.py", line 44, in <module>
    main(sys.argv[1])
  File "./test-serverversion.py", line 33, in main
    versions = [int(p) for p in parts][:3]
ValueError: invalid literal for int() with base 10: '1 (Ubuntu 10'

I think it was broken by "build time".
On x86 I see:
postgresql-client-10_10.0-1_amd64.deb
On armhf I see:
postgresql-client-10_10.1-3_armhf.deb

The old version format was "postgres (PostgreSQL) 9.6.6"

A fix would be:
   if " (" in version_string:                                                   
       version_string = version_string[0:version_string.find(" (")]

With all that known I found [2] and [3].

I pinged [3] with the info on [2] and given an upload happens this will
resolve and by that unblock part of the proposed-migration.

Further on I found, debugged, fixed and reported [4] which makes it build and 
work correctly again.
There might be more things that need to be addressed by upstream to follow this 
pg change, but for now things seem better than before.

I prepared an ubuntu1 upload to get this finally migrating in bionic.
And we can make it a sync once upstream & Debian picked things up.

[1]: https://launchpad.net/ubuntu/+source/asyncpg/0.13.0-1/+build/13670362
[2]: https://github.com/MagicStack/asyncpg/issues/250
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882017
[4]: https://github.com/MagicStack/asyncpg/issues/256

** Affects: asyncpg (Ubuntu)
     Importance: Medium
         Status: Triaged

** Affects: asyncpg (Debian)
     Importance: Unknown
         Status: Unknown

** Bug watch added: Debian Bug tracker #882017
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882017

** Also affects: asyncpg (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882017
   Importance: Unknown
       Status: Unknown

** Changed in: asyncpg (Ubuntu)
       Status: New => Triaged

** Changed in: asyncpg (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1747589

Title:
  asyncpg fails to build against postgresql 10.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/asyncpg/+bug/1747589/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to