[Bug 2057683] Re: [MIR] platformdirs
Override component to main platformdirs 4.2.0-1 in noble: universe/misc -> main python3-platformdirs 4.2.0-1 in noble amd64: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble arm64: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble armhf: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble i386: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble ppc64el: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble riscv64: universe/python/optional/100% -> main python3-platformdirs 4.2.0-1 in noble s390x: universe/python/optional/100% -> main 8 publications overridden. ** Changed in: platformdirs (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2057683] Re: [MIR] platformdirs
Thanks for the prompt review @paelzer! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2057683] Re: [MIR] platformdirs
James did all the uploads AFAIK, once they are all in proposed or migrated things can be pro-/dem-moted. Changing states accordingly to reflect that this is ready. ** Changed in: platformdirs (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => (unassigned) ** Changed in: platformdirs (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2057683] Re: [MIR] platformdirs
Working on the handful of migrations in main under the openstack package set. os-client-config does not actually depend on appdirs - fix uploaded openstacksdk migrated already - dependency dropped, fix uploaded ironicclient - review submitted upstream - patched version uploaded. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2057683] Re: [MIR] platformdirs
Review for Source Package: platformdirs
This goes a bit of an unusual way ...
[Rationale, Duplication and Ownership]
First of all, what does platformdirs do, according to its description
and interfaces:
Depending on your system (Linux, Mac OS X, or Windows), you have to use
different directories for storing user data. platformdirs will help you choose
an appropriate:
.
* user data directory (user_data_dir function)
* user config directory (user_config_dir function)
* user cache directory (user_cache_dir function)
* site data directory (site_data_dir function)
* site config directory (site_config_dir function)
* user log directory (user_log_dir function)
According to my, surely incomplete, research I quickly identified two
alternatives that seem to be the most common use cases for this.
1. There is python3-xdg which is a bit more Desktop centric, but implements
https://specifications.freedesktop.org/basedir-spec/latest/
And yes - it is in main already :-/
In doing so it provides ability to load the following paths
xdg_data_home, xdg_data_dirs, xdg_config_home, xdg_config_dirs,
xdg_cache_home, xdg_state_home and therefore provides almost the same.
Although it seems not to be a in-place alternative and using it
might be quite some effort depending on how it is used from openstack code.
2. Even more interesting seems python3-appdirs
It is more popular by usage counts, by project forks and all that
and yes - it is also in main already :-/
But it is suspiciously close in what it does
appdirs will help you choose an appropriate:
* user data dir (user_data_dir)
* user config dir (user_config_dir)
* user cache dir (user_cache_dir)
* site data dir (site_data_dir)
* site config dir (site_config_dir)
* user log dir (user_log_dir)
And with that being too close to be an accident I found this:
Note: This project has been officially deprecated. You may want to
check out https://pypi.org/project/platformdirs/ which is a more active
fork of appdirs. Thanks to everyone who has used appdirs.
And on the platformdirs side I found:
This repository is a friendly fork of the wonderful work started by
ActiveState who created appdirs, this package's ancestor.
Maintaining an open source project is no easy task, particularly from
within an organization, and the Python community is indebted to appdirs
(and to Trent Mick and Jeff Rouse in particular) for creating an incredibly
useful simple module, as evidenced by the wide number of users it has
attracted over the years.
Nonetheless, given the number of long-standing open issues and pull
requests, and no clear path towards ensuring that maintenance of the
package would continue or grow, this fork was created.
So in regard to our usual check, yes there is other software in main providing
the same functionality - python3-appdirs.
But the python3-platformdirs that you suggested is the better alternative.
It is the same code but evolving.
On one hand, that means that this MIR is much easier.
I can skip the rest of the review here ...
It is essentially a continuation of bug 1464165 which brought appdirs in.
Hey James and Openstack again :-)
I think changing to platformdirs is a clear win.
I'm not even concerned on tests (as we otherwise so often are), it used the
automatic testing at build and autopkgtest.
So can we just promote platformdirs and go on then? Well ... no.
This is like any other "same source new name" in which we want the usage
of the old inferior to go away.
I appreciate that time is scarce, but this is a better drop in replacement.
OTOH The list is huge and not exclusively by openstack and also in many
packages that do not yet have any delta.
Reverse-Depends
===
* crossgrader
* git-phab
* nuitka
* nvchecker
* ofxstatement
* ofxstatement-plugins
* openlp
* plover
* ptpython
* pydoctor
* python3-cobra [amd64 arm64 armhf ppc64el]
* python3-datacache
* python3-datalad
* python3-easydev
* python3-etesync
* python3-fissix
* python3-fs
* python3-intake [amd64 arm64 armhf ppc64el s390x]
* python3-ironicclient
* python3-libpysal
* python3-mbed-ls
* python3-miio
* python3-napari
* python3-npe2
* python3-openstacksdk
* python3-os-client-config
* python3-os-faults
* python3-pako
* python3-pycuda [amd64 arm64]
* python3-pyopencl [amd64 arm64 armhf ppc64el s390x]
* python3-pyspectral
* python3-pytools
* python3-requests-cache
* python3-rply
* python3-satpy
* python3-subliminal
* python3-ulmo
* snakemake
* sqlfluff
* telegram-send
* urlwatch
I was tempted to say, given the time in the noble release, I'd approve that
this is promoted to main but would like to have strong committment to work
out before the end of 24.10.
But then I saw this:
root@n:~# apt-cache policy $(reverse-depends --release=noble python3-appdirs |
awk '/^*/ {print $2}' | xargs) | grep -B 6 main | grep '^[a-z].*:'
python3-ironicclient:
python3-openstacksdk:
[Bug 2057683] Re: [MIR] platformdirs
** Changed in: platformdirs (Ubuntu) Assignee: (unassigned) => Christian Ehrhardt (paelzer) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2057683] Re: [MIR] platformdirs
** Description changed: [Availability] The package platformdirs is already in Ubuntu universe. The package platformdirs build for the architectures it is designed to work on (any). It currently builds and works for architectures: OK Link to package https://launchpad.net/ubuntu/+source/platformdirs [Rationale] The package platformdirs is a new runtime dependency of package python-openstacksdk that we already support The package platformdirs is required in Ubuntu main no later than Final Freeze as its required for the 24.04 LTS release. [Security] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=platformdirs site:www.openwall.com/lists/oss-security https://ubuntu.com/security/cves?package=platformdirs https://security-tracker.debian.org/tracker/source-package/platformdirs - No CVEs/security issues in this software in the past - no `suid` or `sgid` binaries - no executables in `/sbin` and `/usr/sbin` - Package does not install services, timers or recurring jobs - Packages does not open privileged ports (ports < 1024). - Package does not expose any external endpoints - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=platformdirs - Upstream's bug tracker https://github.com/platformdirs/platformdirs/issues [Quality assurance - testing] - RULE: - The package must include a non-trivial test suite - RULE: - it should run at package build and fail the build if broken - TODO-A: - The package runs a test suite on build time, if it fails - TODO-A: it makes the build fail, link to build log TBD - TODO-B: - The package does not run a test at build time because TBD - - RULE: - The package should, but is not required to, also contain - RULE: non-trivial autopkgtest(s). - TODO-A: - The package runs an autopkgtest, and is currently passing on - TODO-A: this TBD list of architectures, link to test logs TBD - TODO-B: - The package does not run an autopkgtest because TBD - - RULE: - existing but failing tests that shall be handled as "ok to fail" - RULE: need to be explained along the test logs below - TODO-A: - The package does have not failing autopkgtests right now - TODO-B: - The package does have failing autopkgtests tests right now, but since - TODO-B: they always failed they are handled as "ignored failure", this is - TODO-B: ok because TBD - - RULE: - If no build tests nor autopkgtests are included, and/or if the package - RULE: requires specific hardware to perform testing, the subscribed team - RULE: must provide a written test plan in a comment to the MIR bug, and - RULE: commit to running that test either at each upload of the package or - RULE: at least once each release cycle. In the comment to the MIR bug, - RULE: please link to the codebase of these tests (scripts or doc of manual - RULE: steps) and attach a full log of these test runs. This is meant to - RULE: assess their validity (e.g. not just superficial). - RULE: If possible such things should stay in universe. Sometimes that is - RULE: impossible due to the way how features/plugins/dependencies work - RULE: but if you are going to ask for promotion of something untestable - RULE: please outline why it couldn't provide its value (e.g. by splitting - RULE: binaries) to users from universe. - RULE: This is a balance that is hard to strike well, the request is that all - RULE: options have been exploited before giving up. Look for more details - RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30 - RULE: Just like in the SRU process it is worth to understand what the - RULE: consequences a regression (due to a test miss) would be. Therefore - RULE: if being untestable we ask to outline what consequences this would - RULE: have for the given package. And let us be honest, even if you can - RULE: test you are never sure you will be able to catch all potential - RULE: regressions. So this is mostly to force self-awareness of the owning - RULE: team than to make a decision on. - TODO: - The package can not be well tested at build or autopkgtest time - TODO: because TBD. To make up for that: - TODO-A: - We have access to such hardware in the team - TODO-B: - We have allocated budget to get this hardware, but it is not here - TODO-B: yet - TODO-C: - We have checked with solutions-qa and will use their hardware - TODO-C: through testflinger - TODO-D: - We have checked with other team TBD and will use their hardware - TODO-D: through TBD (eg. MAAS) -
[Bug 2057683] Re: [MIR] platformdirs
** Description changed: [Availability] The package platformdirs is already in Ubuntu universe. The package platformdirs build for the architectures it is designed to work on (any). It currently builds and works for architectures: OK Link to package https://launchpad.net/ubuntu/+source/platformdirs [Rationale] - RULE: There must be a certain level of demand for the package - TODO: - The package TBDSRC is required in Ubuntu main for TBD - TODO-A: - The package TBDSRC will generally be useful for a large part of - TODO-A: our user base - TODO-B: - The package TBDSRC will not generally be useful for a large part of - TODO-B: our user base, but is important/helpful still because TBD - TODO: - Additional reasons TBD - TODO: - Additionally new use-cases enabled by this are TBD - TODO: - Package TBDSRC covers the same use case as TBD, but is better - TODO: because TBD, thereby we want to replace it. - TODO: - The package TBDSRC is a new runtime dependency of package TBD that - TODO: we already support - RULE: Sometimes there are other/better ways, often are achieved by using a - RULE: library with similar functionality that is more commonly used and - RULE: thereby already in main or a better candidate to promote. - RULE: Reducing the set of supported software in Ubuntu helps to focus on the - RULE: right things, otherwise Ubuntu developers will be consumed by updating - RULE: many variations of the same - wasting valuable time that could be better - RULE: spent elsewhere. - RULE: If there are other packages in the archive that are close, but unable to - RULE: address the problem you might spend some time explaining what exists and - RULE: why it isn't a sufficient alternative. - TODO: - There is no other/better way to solve this that is already in main or - TODO: should go universe->main instead of this. - - RULE: Reviews will take some time. Also the potential extra work out of review - RULE: feedback from either MIR-team and/or security-team will take time. - RULE: For better prioritization it is quite helpful to clearly state the - RULE: target release and set a milestone to the bug task. - RULE: When doing so do not describe what you "wish" or "would like to have". - RULE: Only milestones that are sufficiently well-founded and related to - RULE: major releases will be considered - TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD - TODO-A: due to TBD - TODO-B: - It would be great and useful to community/processes to have the - TODO-B: package TBD in Ubuntu main, but there is no definitive deadline. + The package platformdirs is a new runtime dependency of package python-openstacksdk that we already support + + The package platformdirs is required in Ubuntu main no later than Final + Freeze as its required for the 24.04 LTS release. [Security] - RULE: The security history and the current state of security issues in the - RULE: package must allow us to support the package for at least 9 months (120 - RULE: for LTS+ESM support) without exposing its users to an inappropriate level - RULE: of security risks. This requires checking of several things: - RULE: - Search in the National Vulnerability Database using the PKG as keyword - RULE: https://cve.mitre.org/cve/search_cve_list.html - RULE: - check OSS security mailing list (feed into search engine - RULE: 'site:www.openwall.com/lists/oss-security ') - RULE: - Ubuntu CVE Tracker - RULE: https://ubuntu.com/security/cve?package= - RULE: - Debian Security Tracker - RULE: https://security-tracker.debian.org/tracker/source-package/ - TODO-A: - Had #TBD security issues in the past - TODO-A: - TBD links to such security issues in trackers - TODO-A: - TBD to any context that shows how these issues got handled in - TODO-A: the past - TODO-B: - No CVEs/security issues in this software in the past - - RULE: - Check for security relevant binaries, services and behavior. - RULE: If any are present, this requires a more in-depth security review. - RULE: Demonstrating that common isolation/risk-mitigation patterns are used - RULE: will help to raise confidence. For example a service running as root - RULE: open to the network will need to be considered very carefully. The same - RULE: service dropping the root permissions after initial initialization, - RULE: using various systemd isolation features and having a default active - RULE: apparmor profile is much less concerning and can speed up acceptance. - RULE: This helps Ubuntu, but you are encouraged to consider working with - RULE: Debian and upstream to get those security features used at wide scale. - RULE: - It might be impossible for the submitting team to check this perfectly - RULE: (the security team will), but you should be aware that deprecated - RULE: security algorithms like 3DES or TLS/SSL 1.1 are not acceptable. - RULE: If you think a package might do that it would be great to provide a -
[Bug 2057683] Re: [MIR] platformdirs
** Description changed: - New dependency for python-openstacksdk + [Availability] + TODO: The package TBDSRC is already in Ubuntu universe. + TODO: The package TBDSRC build for the architectures it is designed to work on. + TODO: It currently builds and works for architectures: TBD + TODO: Link to package https://launchpad.net/ubuntu/+source/TBDSRC + + [Rationale] + RULE: There must be a certain level of demand for the package + TODO: - The package TBDSRC is required in Ubuntu main for TBD + TODO-A: - The package TBDSRC will generally be useful for a large part of + TODO-A: our user base + TODO-B: - The package TBDSRC will not generally be useful for a large part of + TODO-B: our user base, but is important/helpful still because TBD + TODO: - Additional reasons TBD + TODO: - Additionally new use-cases enabled by this are TBD + TODO: - Package TBDSRC covers the same use case as TBD, but is better + TODO: because TBD, thereby we want to replace it. + TODO: - The package TBDSRC is a new runtime dependency of package TBD that + TODO: we already support + RULE: Sometimes there are other/better ways, often are achieved by using a + RULE: library with similar functionality that is more commonly used and + RULE: thereby already in main or a better candidate to promote. + RULE: Reducing the set of supported software in Ubuntu helps to focus on the + RULE: right things, otherwise Ubuntu developers will be consumed by updating + RULE: many variations of the same - wasting valuable time that could be better + RULE: spent elsewhere. + RULE: If there are other packages in the archive that are close, but unable to + RULE: address the problem you might spend some time explaining what exists and + RULE: why it isn't a sufficient alternative. + TODO: - There is no other/better way to solve this that is already in main or + TODO: should go universe->main instead of this. + + RULE: Reviews will take some time. Also the potential extra work out of review + RULE: feedback from either MIR-team and/or security-team will take time. + RULE: For better prioritization it is quite helpful to clearly state the + RULE: target release and set a milestone to the bug task. + RULE: When doing so do not describe what you "wish" or "would like to have". + RULE: Only milestones that are sufficiently well-founded and related to + RULE: major releases will be considered + TODO-A: - The package TBDSRC is required in Ubuntu main no later than TBD + TODO-A: due to TBD + TODO-B: - It would be great and useful to community/processes to have the + TODO-B: package TBD in Ubuntu main, but there is no definitive deadline. + + [Security] + RULE: The security history and the current state of security issues in the + RULE: package must allow us to support the package for at least 9 months (120 + RULE: for LTS+ESM support) without exposing its users to an inappropriate level + RULE: of security risks. This requires checking of several things: + RULE: - Search in the National Vulnerability Database using the PKG as keyword + RULE: https://cve.mitre.org/cve/search_cve_list.html + RULE: - check OSS security mailing list (feed into search engine + RULE: 'site:www.openwall.com/lists/oss-security ') + RULE: - Ubuntu CVE Tracker + RULE: https://ubuntu.com/security/cve?package= + RULE: - Debian Security Tracker + RULE: https://security-tracker.debian.org/tracker/source-package/ + TODO-A: - Had #TBD security issues in the past + TODO-A: - TBD links to such security issues in trackers + TODO-A: - TBD to any context that shows how these issues got handled in + TODO-A: the past + TODO-B: - No CVEs/security issues in this software in the past + + RULE: - Check for security relevant binaries, services and behavior. + RULE: If any are present, this requires a more in-depth security review. + RULE: Demonstrating that common isolation/risk-mitigation patterns are used + RULE: will help to raise confidence. For example a service running as root + RULE: open to the network will need to be considered very carefully. The same + RULE: service dropping the root permissions after initial initialization, + RULE: using various systemd isolation features and having a default active + RULE: apparmor profile is much less concerning and can speed up acceptance. + RULE: This helps Ubuntu, but you are encouraged to consider working with + RULE: Debian and upstream to get those security features used at wide scale. + RULE: - It might be impossible for the submitting team to check this perfectly + RULE: (the security team will), but you should be aware that deprecated + RULE: security algorithms like 3DES or TLS/SSL 1.1 are not acceptable. + RULE: If you think a package might do that it would be great to provide a + RULE: hint for the security team like "Package may use deprecated crypto" + RULE: and provide the details you have about that. + TODO: - no `suid` or `sgid` binaries + TODO-A: - no executables in
[Bug 2057683] Re: [MIR] platformdirs
** Description changed: - TBC + New dependency for python-openstacksdk ** Changed in: platformdirs (Ubuntu) Assignee: (unassigned) => James Page (james-page) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2057683 Title: [MIR] platformdirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
