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 year is really short period for doing so much work in Debian. Imho we are already too late to make it, but let's try it. :) I think requesting the removal of packages that you are **not** > maintaining is - to be polite - a bit unconventional (at least). > This remains at the discretion of the maintainer as far as I remember. > as other sad, RoQA. But maintainer can always stop this. Py2keep tag, fix package, even anyone else can NMU it. Removing is last and least preferred option. This is happening mostly for unmaintained/dead upstream packages, low popcons, MIA maintainers, QA packages, etc. > All dependency fields in debian/control and debian/tests/control must > > also be updated to stop using the unversioned python > > Are all you "must" statements "policy decisions"? Or your personal wish > list items? > Python policy update is underway. Thank you. -- Best regards Ondřej Nový
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 9D1E 064B
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 > > contributor is at a minimum impolite. > > I disagree when it comes to the debian namespace, and the documentation > agrees with me[1]. > +1. If someone wants private repo, he/she can use private/user namespace for it. We created "debian" (original collab-maint) group with RW permissions for DD with intention. So we have place where any DD can commit and collaborate together on one project. > ... I don't think it is > reasonable to ask for coordination for this type of changes, and I would > agree that even notifying is too much effort if this was done salsa-wide. > any owner of repository can enable email notifications for changes inside own repo. But sending emails "hey i commited something, please git pull" is just crazy. Maybe we should don't use git at all just use email for sending patches, right? :) BTW, thanks Ondřej Nový for those "editorial" fixes! > yw :) -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 particular version of systemd on your > system. If that's the case, then you should Depend on the correct > version of systemd. If you also support other init systems, you can add > an alternate dependency on those other systems; or you can use > Recommends: rather than Depends: if you don't want it to be absolute. > but I want my package to work without init systems, for example inside Docker. But if systemd is installed, I need >= version. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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) > according to this, I can use "Breaks" in situation, where my package is broken with older version of other package and I can "Breaks" older version of that not compatible (interacts badly) package. Am I reading it correctly? Because that means "Breaks" works both way. If A breaks B: A doesn't work correctly with B or B doesn't work correctly with A. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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? > Does the service fail to start or does it have a proper fallback? > Tried. It starts (it ignores new unit directive) and if /var/cache/swift directory exists from past, it works fine. If it doesn't exists, some of swift components doesn't work correctly. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 systemd.postinst has run before > your postinst. > this is not issue for me, because when I'm upgrading swift package, /var/cache/swift directory already exists from the past (created by older version of swift with "old" method). Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 46A5 6090 3573 1255 9D1E 064B
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 correct solution is: Depends: systemd (>= 235~) | sysv-init | openrc I don't currently depend on systemd, or any other init system. I think my solution is correct, because Swift works with any init system and I want to only say "it doesn't work with older systemd". I don't think it's correct to list all possible init systems in Depends. Can you help us? Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 > release where the third party elements of the Django ecosystem almost all > support Python 3, so transition is possible to make ready for an all > Python 3 > future. (AIUI anyway, I'm not a Django maintainer) > which is perfect for seamless migration. +1 -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 (build time). I never seen build failure when Py3 tests was fine and Py2 wasn't. Because OpenStack upstream officially support Py2. > > - no chance to have any Python 2 packages installed, so we're sure > we're > > on a full Python 3 stack (in my current setup, unfortunately some > Python > > 2 packages are still pulled). This may go on for another 3 years if > we > > don't remove Python 2 now, with the added issue that it will pull > > *older* version of clients if selecting Python 2 and if we still have > > them in Buster (ie: case of OpenStack backports on top of Stable). > > > > so let's fix packages to not pull Py2 if it's not needed. > > More work... > we need to fix it in both cases. So it's same work. > - packaging and decrufting will take a long time, so we'd better start > > early. Especially if we want to do it the proper way, without > breaking > > any reverse (build-)dependency that are outside of OpenStack. > > > > more than one release cycle? I'm sure we can do it during Bullseye. And > > we will do it for non-OS Python packages too. Better is to do removing > > in earlier phase of development cycle. > > And even more work... > huh? Doing now or doing later. Same work. > There's btw a bunch of RC bugs in the BTS that I would love to get > fixed. Anyone up for contributing that? > problem is that nobody want's to cooperate with you, that's all. All other arguments are useless. I already explained to you many times what is problem. > This was part of a non-formal discussion with Ubuntu people, I'm not > sure it would be right to say with who, but I'm sure you can guess. We > can discuss with that person again and see what he says now, as maybe > things have changed since that last conversation. So no, I don't have > any formal announcement/links to support that it will happen in Ubuntu > for Rocky. > so it's just your opinion. Now, what needs to be accounted, is how many people use Py2 clients (and > of course, by that, I mean the Python modules, not the cli). To answer > that question, we have unfortunately no data except your own case. > we have data: https://qa.debian.org/popcon.php?package=python-openstackclient Not ideal I know. But better than nothing. But is the whole set made of just one? Or more? Impossible to say... > Which is why I asked you how much time it would take for fixing the > situation in your own company, as it could be a good example. How many > months do you need? 6 months? A year? It'd be super nice if you could > explain your use case in more details, and tell what your code base is > about. Though maybe you can't do it publicly? Or even, maybe you can't > tell me? I would understand in both cases. But if you can explain, it > would help understanding at least your use case, which may be similar to > others. > we need Buster stable period for Py2->Py3 migration. We are going to be ready for Py3-only for Bullseye. Thousands of servers, millions lines of code. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 sure we're > on a full Python 3 stack (in my current setup, unfortunately some Python > 2 packages are still pulled). This may go on for another 3 years if we > don't remove Python 2 now, with the added issue that it will pull > *older* version of clients if selecting Python 2 and if we still have > them in Buster (ie: case of OpenStack backports on top of Stable). > so let's fix packages to not pull Py2 if it's not needed. > - packaging and decrufting will take a long time, so we'd better start > early. Especially if we want to do it the proper way, without breaking > any reverse (build-)dependency that are outside of OpenStack. > more than one release cycle? I'm sure we can do it during Bullseye. And we will do it for non-OS Python packages too. Better is to do removing in earlier phase of development cycle. - at some point, even upstream will move to Python 3, and Python 2 will > be the legacy old thing. Do we really want to be the only distribution > that will hit these Python 2 bugs? In such case, we'll be alone writing > these Python 2 bugfix patches. :/ > that point is after Rocky, so it's doesn't matter for Buster. - Other distros (RHEL and Ubuntu) will move to Python 3 only in the next > OpenStack development cycle, meaning we'll be alone with Python 2 > support at some point. > any links where Ubuntu said they will not support Py2 for Rocky? I'm sure we will not be alone. The other thing is, it's ready! I was able to do functional testing on > top of the Python 3 release of OpenStack Debian packages. So why should > we hold any longer? > What is ready? Py3 support, or Py2 dropping? If foremost, let's do it. Let's have good Py3-only services, let's have default Py3 clients, but support Py2 clients. It cost us nothing, it's already done this way. > The only benefit we get with keeping Python 2 support is for thirdparty > software that is still using Python 2. We don't have this in Debian at > the moment. What's the status in your company? Do you still need Python > 2 for your internal use? What's the ETA for switching to Python 3? > yep, that's important benefit. Because our priority is our users. "My" company is not important, important is our users and my company is just one of them. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 for Py2 now 2. upstreams official supports Py2 now (and probably will support in OS release targeted for Buster) 3. Python 2 will be in Buster I didn't see any real benefits dropping them before Buster release. Let's drop them just after Buster release. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 > missing the flag. Since I have the data at hand, I figured it would be > easy to generate a dd-list of packages named after their module that > lack the tag. You find that list attached. > I think it's good idea to mass commit this (adding Testsuite: autopkgtest-pkg-python) into Git repos. We should probably merge this list with Debian CI whitelist one. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 all (e.g. capitalization). > > This could be fixed in autodep8. > File a bug maybe? > I tried to do my best :) https://sources.debian.org/src/autodep8/0.11.1/support/python/generate/ Feel free to add more "magic" for module name detection. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: MBF proposal: python modules that fail to import
Hi, 2018-04-16 11:56 GMT+02:00 Ondrej Novy : > 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-python even if there is d/tests, but you should rename d/tests/control to d/tests/control.autodep8 -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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ý Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 the documentation. which i consider correct. > We'd like to know that with transitions for library soname bump, is > "Conflicts:" relationship needed / not needed in all circumstances and what > problem might users / developers encounter if it is added / not added. > If there are no file collision (and both packages can be co-installed), I don't see any reason why add Conflicts/Replaces. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 python3-sphinx-intl is better. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 why do SQL schema update during package upgrade? init script / solo script is better place imho. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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. -- S pozdravem/Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 the OpenStack dev cycle, normally it should have been > fully uploaded *AND* tested against tempest. > yep, because there are no branches for it. And because I don't know how to create them (in infra which I hate for deb packaging) i can't continue my work on Ocata. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 be a full time job. > as second most active openstack-pkg team contributor ( http://blends.debian.net/liststats/uploaders_pkg-openstack.png) I think this not needs to be full time job, but we need more maintainers. > If things continue this way, I probably will ask for the removal > of all OpenStack packages from Debian Sid after Stretch gets released > (unless I know that someone will do the work). > please don't ask anyone to remove __team maintained__ packages. > As a consequence, the following projects wont get packages even in > Ubuntu (as they were "community maintained", which means done by me and > later sync into Ubuntu...): > done by team, not (only) you. I know you done most of packaging work, but please don't say: I'm only one who did OS packaging. That's not fair to other contributors. Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 contrary to git+ssh URLs, and account on Alioth is not > required to checkout. > ack, this is what i'm using too. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 same system for running builds (Jenkins?). -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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 carefull, because there are some packages which FTBFS in debci (example: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html ) and it's bug in debci. Build works fine in buildd and in my local sbuild. Maybe we should fix this first? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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. Imho bug in manpage. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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. right: https://buildd.debian.org/status/package.php?p=python-tornado&suite=jessie-backports https://anonscm.debian.org/cgit/python-modules/packages/python-tornado.git/tree/debian/control#n24 python-tornado build-depends on missing: - python3:arm64 (>= 3.5) So jessie-backports buildd have this "bug" too. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
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: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844366 https://github.com/openssl/openssl/issues/1903 https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e Really nice. Please revert this transition and try again with buster, thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
