Re: Python 2 removal in sid/bullseye: Progress and next steps

Hi, po 11. 11. 2019 v 16:27 odesílatel Norbert Preining napsal: > thanks for your work on the Python2 removal. > It's team work, I "only" sent that email :). It looks like others already replied, but Could you please give a time line of how you are planning to proceed? > time line=now. 1.5

Re: Conflicting lintian warnings when using debian/tests/control.autodep8 or debian/tests/control

Hi, po 7. 1. 2019 v 11:37 odesílatel Andreas Tille napsal: > Any idea what to do (except overriding one of the lintian > warnings)? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918621 -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255

Re: salsa.debian.org: merge requests and such

Hi, út 6. 11. 2018 v 16:46 odesílatel Felipe Sateler napsal: > > That seems completely reasonable. Making the repository accessible to > > others is a courtesy that should not be abused. Pushing directly to the > > master branch of a package for which one is not an active maintainer or > >

Re: Package not compatible with old systemd

Hi, st 19. 9. 2018 v 10:07 odesílatel Wouter Verhelst napsal: > > Conflicts is just more strict Breaks, > > Eh, no. > ehm, yes: 7.4: Conflicts ... This is a stronger restriction than Breaks You're claiming that the systemd support of your package won't work > correctly unless you have a

Re: Package not compatible with old systemd

Hi, st 19. 9. 2018 v 13:21 odesílatel Ansgar Burchardt napsal: > Policy specifically says to use Breaks in this case: "Breaks should be > used [...] when the breaking package exposes a bug in or interacts > badly with particular versions of the broken package." (same section as > above) >

Re: Package not compatible with old systemd

Hi, út 18. 9. 2018 v 12:27 odesílatel Michael Biebl napsal: > Fwiw, we had a similar issue in udev, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903224 > for the gory details. > thanks. > Have you tried running your swift service with an older (say v232 from > stable) systemd? >

Re: Package not compatible with old systemd

Hi, út 18. 9. 2018 v 12:18 odesílatel Michael Biebl napsal: > assume you (re)start your service in postinst? In this case you need a > running systemd >= 235 at that point. > yes. > We do re-exec systemd in postinst, but a versioned Breaks or Conflicts > does not give you the guarantee that

Re: Package not compatible with old systemd

Hi, út 18. 9. 2018 v 10:30 odesílatel Lars Wirzenius napsal: > Would Conflicts work here? > Conflicts is just more strict Breaks, for example when files are overwritten. This is not case and Breaks "is enough". -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C

Package not compatible with old systemd

Hi, my package src:swift is not compatible with old systemd, because I'm using CacheDirectory in unit file. CacheDirectory is supported from systemd 235. I think correct solution is to add to binary package this relation: Breaks: systemd (<< 235~) Thomas Goirand (zigo) said it's wrong and

Re: Please do not drop Python 2 modules

Hi, 2018-04-26 20:04 GMT+02:00 Adrian Bunk : > Triaging would imply a valid technical reason like problems with the > Python 2 module, not blind dropping out of a desire to kill Python 2. > I completely agree with you Adrian, thanks! -- Best regards Ondřej Nový Email:

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

Hi, 2018-04-26 13:27 GMT+02:00 Scott Kitterman : > I know very little about the details of OpenStack, but in case a somewhat > parallel example is useful, that's approximately what Django will do. > Bullseye will be Django 2.0, which is Python 3 only. Buster is the pivot >

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

Hi, 2018-04-26 0:49 GMT+02:00 Thomas Goirand : > > - faster build time (no need to test with Python 2, so less chances > of > > build failure). > > > > build is done once, customer happiness is for years (buster lifetime). > > More work ... > more work for machines

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

Hi, 2018-04-25 11:11 GMT+02:00 Thomas Goirand : > > - faster build time (no need to test with Python 2, so less chances of > build failure). > build is done once, customer happiness is for years (buster lifetime). - no chance to have any Python 2 packages installed, so we're

Re: Please do not drop Python 2 modules

Hi, 2018-04-25 9:06 GMT+02:00 Thomas Goirand : > > I would like to start dropping Python 2 as early as possible though. The > only question that remains is: how many people still have Python 2 only > code using clients. > /me And because: 1. OS clients are already packaged

Re: MBF proposal: python modules that fail to import

Hi, 2018-04-15 21:27 GMT+02:00 Helmut Grohne : > Note that autopkgtest-pkg-python is only applicable when the module name > matches the package name. That's true for the majority of packages, but > not for all (e.g. capitalization). Nevertheless, a lot of packages are >

Re: MBF proposal: python modules that fail to import

Hi, 2018-04-15 21:32 GMT+02:00 Mattia Rizzolo : > On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote: > > Note that autopkgtest-pkg-python is only applicable when the module name > > matches the package name. That's true for the majority of packages, but > > not for

Re: MBF proposal: python modules that fail to import

Hi, 2018-04-16 11:56 GMT+02:00 Ondrej Novy <n...@ondrej.org>: > already done in git. > sry. I only removed useless Testsuite: autopkgtest-pkg in git. Checking if d/tests already exists before adding autopkgtest-pkg-python is really important. You can add autopkgtest-pkg

Re: MBF proposal: python modules that fail to import

Hi, 2018-04-16 11:47 GMT+02:00 Andreas Tille : > > W: python-csb source: unnecessary-testsuite-autopkgtest-field > ... > So before doing a MBF "Missing Testsuite: autopkgtest-pkg-python" > this should be checked as well. > already done in git. -- Best regards Ondřej Nový

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

Hi, 2018-03-29 4:35 GMT+02:00 Boyuan Yang <073p...@gmail.com>: > * My mentor suggests that the new library package (libdframeworkdbus2) > should > add the relationship "Conflicts: libdframeworkdbus1" > what is mentor's argument about adding this? > > ...and such necessity is not reflected in

Re: s/python3-sphinx-intl/sphinx-intl

Hi, 2017-09-13 13:18 GMT+02:00 Hideki Yamane : > Then, source package as sphinx-intl and binary package python3-sphinx-intl > is fine? > if sphinx-intl is primary application (cli tool, etc.), than binary pkg sphinx-intl is better. If it's library/module, than

Re: Adding postgresql as pre-depends for gitlab

Hi, 2017-04-16 15:08 GMT+02:00 Peter Palfrader : > > Having the DBMS on a different host should be a supported way of setup. > You should not depend on a postgres server on the same machine running > gitlab, and therefore neither should you pre-depend on postgres. > yep and

Re: The end of OpenStack packages in Debian?

Hi, 2017-02-18 8:11 GMT+01:00 Clint Byrum : > > I'd be willing to help transition these into DPMT and co-maintain them > going forward: > i would like to co-maintain this packages too (and I'm co-maintaining some of them already). But outside infra, inside DPMT as you said.

Re: The end of OpenStack packages in Debian?

Hi, 2017-02-16 0:45 GMT+01:00 Thomas Goirand : > > Yes, you've done some work, and many thanks for it, it has been very > useful. However the reality is: since I stopped after the Newton > release, absolutely no work has been done to package Ocata in Debian. At > this point in

Re: The end of OpenStack packages in Debian?

Hi, 2017-02-15 13:42 GMT+01:00 Thomas Goirand : > > Over the last few months, I hoped for having enough strengths to > continue my packaging work anyway, and get Ocata packages done. But > that's not what happened. The biggest reason for this is that I know > that this needs to

Re: What is exactly the "canonical URI" for Vcs-{Git,Browser}?

Hi, 2017-01-20 12:45 GMT+01:00 Sebastiaan Couwenberg : > > Vcs-Browser: https://anonscm.debian.org/cgit/pkg-foo/bar.git > > Vcs-Git: https://anonscm.debian.org/git/pkg-foo/bar.git > > These are the ones you should use, because both use encryption for the > connection and

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

Hi, 2017-01-13 17:47 GMT+01:00 Antonio Terceiro : > I think you are a little confused. That links to reproducible builds, > which has nothing to do with debci. > yep, sorry for confusion. I assumed that FTBS migration check will use data from reproducible builds OR will use

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

Hi, 2017-01-13 8:46 GMT+01:00 Pirate Praveen : > Similar to piuparts auto rejects, I think we should add auto reject when > autopkgtest of a reverse dependency or build dependency fails (which was > not failing earlier) or cause FTBFS to reverse dependencies. > just be

Re: depending on libssl1.0-dev, buildd fails to find it

Hi, 2016-12-18 14:14 GMT+01:00 James McCoy : > Well, sbuild's man page documents that the aptitude resolver will check > alternatives. If it doesn't in practice, that sounds like a bug. > you need to run sbuild with "--resolve-alternatives" or add same option in sbuildrc.

Re: depending on libssl1.0-dev, buildd fails to find it

Hi, 2016-12-18 11:38 GMT+01:00 Mattia Rizzolo : > afaik sbuild strips the alternatives while parsing the .dsc (or > d/control or whatever), before passing the information to the resolvers, > so even if you use another resolver for -bpo you still get the same > behaviour.

Re: OpenSSL 1.1.0

Hi, 2016-11-19 21:06 GMT+01:00 Kurt Roeckx : > Chacha20 would be a new feature. Following the policy that can't > be added in a 1.0.2 version, only bugs get fixed in it. > yep, they don't add new feature, but break API between 1.1.0b->c release: