1. 22 Jul, 2019 3 commits
  2. 21 May, 2019 1 commit
  3. 22 Jul, 2019 1 commit
  4. 17 Jun, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Add new autopkgtest for skeleton packaging · 74b8bceddee7
      Jérémy Bobbio (Lunar) authored
      When running `cubicweb-ctl newcube`, the generated template provides
      debian packaging. So let's add automated tests for that using
      The new test will generated a new cube, build a source tarball,
      build the package, try to install it, see if the Python 3 module is
      available and even run autopkgtest against the newly created packages.
      Along the way it will also print information about the generated
      package: buildinfo, package content, and lintian report.
  5. 21 May, 2019 1 commit
    • Laurent Peuch's avatar
      [cubicweb-ctl] move to accepting only once instance name per command · 84a8a8915512
      Laurent Peuch authored
      The rationals behind this decision are:
      - while in the past managing all instances sytem wide made a lot of sens,
        pratices have evolved today and we've moved to managing one instance by one
      - this makes things easier to debug since commands since using them on several
        instances were making this harder (errors hidden in the middle)
      - also solve the problem of the return code to have, before it was always 0
        which prevented to do things like:
            ipython --pdb $(which cubicweb-ctl) $command $instance
        or shell scripts that used it
      - this simplify the code and is always good to take
  6. 09 Jul, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Run all unit tests in autopkgtest · d464495452aa
      Jérémy Bobbio (Lunar) authored
      We previously forgot to copy `tox.ini` alongside the tests. As this
      file configures pytest pattern matching rules, we were not running
      quite a few tests. This is now fixed.
      The added tests required some adjustments in the Debian dependencies.
      Sadly, not all tests currently pass. It seems there are some ordering
      dependencies between the tests in regards to how data are loaded.
      Fixing this probably would probably be better debugged by ensuring
      the test suite does not fail when using pytest random-order plugin.
  7. 19 Jun, 2019 2 commits
  8. 09 Jul, 2019 2 commits
  9. 26 Jun, 2019 1 commit
  10. 19 Jun, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      [skeleton] Update Debian packaging template · 853e73456d0f
      Jérémy Bobbio (Lunar) authored
      Here are multiple updates to the Debian packaging template provided when
      running `cubicweb-ctl newcube`:
       * Switch to source format 3.0 (quilt).
       * Switch to debhelper 9.
       * Switch to dh-python.
       * Switch to Python 3.
       * Name the binary package `python3-cubicweb-CUBENAME` instead of
         just `cubicweb-CUBENAME` (which is still the source package).
       * Populate Depends using dh_python3 support for Python requirements.
       * Run test suite at build time using pytest.
       * Add autopkgtest to run test suite against the installed package.
       * Bump Standards-Version to 4.3.0.
  11. 26 Jun, 2019 1 commit
  12. 17 Jun, 2019 1 commit
  13. 19 Jun, 2019 4 commits
    • Jérémy Bobbio (Lunar)'s avatar
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Remove transitional packages · 2856182d4628
      Jérémy Bobbio (Lunar) authored
      We can take the opportunity of the switch to Python 3 to get rid
      of old transitional packages. Let's do it. :)
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Use sections from requires.txt to populate Recommends and Suggests · 91178bc271c7
      Jérémy Bobbio (Lunar) authored
      As Denis Laxalde pointed out, dh_python can also generate Recommends and
      Suggests from Python package names. So let's use that instead of
      manually populating these fields in `debian/control`.
      Optional dependencies are currently specified in `setup.py` grouped by
      feature. These dependency groups are turned into sections in
      `requires.txt`. Thankfully `dh_python3` has options to populate
      Recommends or Suggests with all package from a given section.
      `debian/rules` now contains a list of which sections should go
      to Recommends and which section should go to Suggests. Because such
      extra list easily gets out-of-sync, we add a third list for ignored
      sections, and ensure that all sections currently in `requires.txt`
      get a mentioned in `debian/rules`.
      Here are the results compared to the previous version with explicit
      Recommends and Suggests (only listing Python packages):
      | only in previous  |           common          | only in new  |
      |                             Recommends                       |
      |                   | python3-docutils          |              |
      | python3-fyzz      |                           |              |
      | python3-imaging   |                           |              |
      |                   | python3-pycryptodome      |              |
      |                   | python3-pyramid           |              |
      |                   | python3-pyramid-multiauth |              |
      | python3-pysqlite2 |                           |              |
      |                   | python3-rdflib            |              |
      |                   | python3-repoze.lru        |              |
      | python3-simpletal |                           |              |
      |                   | python3-vobject           |              |
      |                   | python3-waitress          |              |
      | python3-werkzeug  |                           |              |
      |                   | python3-wsgicors          |              |
      |                              Suggests                        |
      |                   |                           | python3-pil  |
      We also lose versioned dependencies which should not really be an issue
      for Recommends and Suggests.
    • Jérémy Bobbio (Lunar)'s avatar
      [crypto] Use Cryptodome namespace instead of Crypto · 5b0ce10a7046
      Jérémy Bobbio (Lunar) authored
      PyCryptodome comes in two flavors: “an almost drop-in replacement for the old
      PyCrypto library” and “a library independent of the old PyCrypto”. The former
      uses the Crypto namespace, and is shipped as `pycryptodome` while the latter
      uses Cryptodome instead and lies in the `pycryptodomex` package.
      Given the reason to switch to PyCryptodome is that PyCrypto in unmaintained,
      its probably better to avoid any mistake and mandate the specific usage of
      the Cryptodome namespace by requiring `pycryptodomex` instead of
      A more present reason is that Debian buster will only provide a package
      with the separate namespace flavor. The current Recommends is not working with
      the current code. Although it's important to note that the package name will
      probably have to be changed to `python3-pycryptodomex` once
      https://bugs.debian.org/886291 is solved.
  14. 17 Jun, 2019 3 commits
  15. 10 Jun, 2019 5 commits
  16. 13 Jun, 2019 1 commit
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Tidy substvars usage in control file · ca06ce5eba38
      Jérémy Bobbio (Lunar) authored
      The documentation package was missing a Built-Using field to record
      the provenance of the templates.
      Empty packages or meta packages do not require Depends on a specific
      Python version, so we can remove the relevant substvars.
  17. 10 Jun, 2019 2 commits
  18. 05 Jun, 2019 3 commits
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Run test suite as part of autopkgtest · c0ff60cd4c1f
      Jérémy Bobbio (Lunar) authored
      Add support for autopkgtest. The test “unittest” will run the test
      suite using pytest. As we need PostgreSQL in the test environment
      and open network connection, the test is marked with
      `isolation-container` and requires at least LXC to be run, e.g:
          autopkgtest -s -- lxc -s autopkgtest-sid
    • Jérémy Bobbio (Lunar)'s avatar
      [pkg] Switch to Debian source format 3.0 (quilt) · 5722d8c461eb
      Jérémy Bobbio (Lunar) authored
      This forces us to base the Debian package on the source of the Python
      package (as produced by running `python3 setup.py sdist`). While
      it might seem cumbersome, this greatly reduces likelyhood of mismatch
      between an installation via `pip` and one using the Debian package.
      `dpkg-source` will also document for us what is currently in the
      source repository but not in the Python package. Currently the missing
      file are:
      The current manifest will duplicate several files that are stored as
      symlinks in the Mercurial repository, hence the long list of ignored
      files in `extend-diff-ignore`.
    • Jérémy Bobbio (Lunar)'s avatar
  19. 11 Jun, 2019 1 commit
    • Julien Tayon's avatar
      Fix sorting key for rdefs in schema viewer · de1c0721656e
      Julien Tayon authored
      With changeset 234ca3cbbb46, clicking in the schema of an entity with
      cubicweb in py3 on "vue en boite" will probably result in an infinite
      spinner (which implies cw > 3.26)
      What happened ?
      This "vue en boite" used to work at least until...
      hg diff -c a8c1ea390400 cubicweb/schema.py
          @@ -993,10 +992,6 @@ class CubicWebRelationSchema(PermissionM
                               return False
                   return True
          -    @deprecated('use .rdef(subjtype, objtype).role_cardinality(role)')
          -    def cardinality(self, subjtype, objtype, target):
          -        return self.rdef(subjtype, objtype).role_cardinality(target)
           class CubicWebSchema(Schema):
               """set of entities and relations schema defining the possible data sets
      But, wait ...
      If I open a shell on an instance of cw 3.24 something seems off
      >>> list(schema['CWUniqueTogetherConstraint'].relation_definitions())[0][0].cardinality
      # <bound method CubicWebRelationSchema.wrapped of <constraint_of [CWUniqueTogetherConstraint,CWEType]>>
      We have been sorting on a method the whole time ? Is it possible what
      were the effects ?
      1) We cannot sort function can't we ?
      >>> def adder(i): return lambda x: x+i
      >>> sorted(map(adder,range(10)))
      [<function __main__.<lambda>>,
       <function __main__.<lambda>>,
      Yes we can.
      2) what does it means.
      >>> { adder(1) : 1 }
      Out[19]: {<function __main__.<lambda>>: 1}
      In fact the function object as a __hash__ method (which is practical for making
      memoizers (cache)), and return truly random results (pseudo random).
      My take on this patch is relations have NEVER been sorted by cardinality.
      No one never ever noticed. Hence, I propose to not fix a bug that never was
  20. 04 Jun, 2019 2 commits
  21. 11 Jun, 2019 1 commit
  22. 07 Jun, 2019 2 commits