Re: [gentoo-dev] Last-rites: app-admin/lastpass-cli
> > # Göktürk Yüksek (2021-03-14) > > # Dead upstream. No revdeps. > > # Removal in 60 days to allow people extra time > > # for transitioning out. Bug #776262. > > app-admin/lastpass-cli > > > > > > > Due to recent changes to Lastpass, I switched to Bitwarden. It may be > worth mentioning somewhere that you can export from Lastpass and import > to Bitwarden and not lose any passwords. My switching took about 5 > minutes, some of which is downloading the sources and add-ons. I actually use lastpass-cli, because my company use LastPass. Is there an alternative, or can we keep this somehow? All the best, -- Thomas
Re: [gentoo-dev] Packages up for grabs
On Montag, 15. März 2021 11:03:17 CET Martin Dummer wrote: > I can take > > > [Bv] net-misc/teamviewer Please make nagging upstream about https://bugs.gentoo.org/750899 a top priority. TIA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: GTK2 based LXDE packages
# Andreas Sturmlechner (2021-03-15) # Unmaintained for >1 year, blocking cleanup of deprecated libraries. # Succeeded by LXQt many years ago (see also: lxqt-base/lxqt-meta). # Removal on 2021-04-14 or replacement by GTK3-based versions available # in ~arch. No more stabilisation is going to happen without the packages # getting a new maintainer. Bugs #708188, #751076, #769524 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository
Hi all, This is an RFC copied from a bug (https://bugs.gentoo.org/776007), and I have added a new section because I realized maven local would not be a good destination for system-wide packages. - 0. Motivation Java packaging has become more difficult on Gentoo because maven/Gradle, the two main build systems for java, is unsupported. When java packages migrated from their ant builds to maven/Gradle, most of the packages have not been updated since. I know that in Java overlay, the packaging practices in general is to patch the pom.xml files to work with local jars, but it does not work with Gradle and can be difficult when working with large projects. 1. Challenges - maven modules/artifacts do not work well with java-config. They generally have a group, which resolves name collisions, but java-config currently does not have a group variable. - it will be hard to reinvent the wheel. If the solution was to rewrite pom.xml/build.gradle files, it would have to resolve the dependencies correctly with all the version constraints instead of relying on the build system. Currently, for java-config packages can only depend on a specific slot of a library, but some might work with newer versions of their dependencies. - plugins are also hard to create in Gradle. Custom resolution of dependencies or specifying a custom repository is not easy because it involves "internal" API without much documentation. Fedora's XMvn project can be used as a starting point but at the time of writing, XMvn is outdated and missing some implementations for newly added interface methods in Gradle's API. 2. Proposed idea Maven/Gradle both have an offline mode which restricts them from fetching online files. For java libraries, they will be published to the local maven repository, which makes it available for other java programs using maven/gradle that depends on the library. Packages that still use java-pkg-simple.eclass can be kept because they are generally not available in maven, so it is rare for other packages to depend on them. The eclass and java-config should be updated for some packages that depend on other packages that get published to mavenLocal, but this seems like a rare case. Those packages can also just get converted to a maven/project using patches. For applications, the launcher scripts should also be changed to parse local artifacts with POM files. If this were to be implemented, newer (revisions/subslots? Or old slots with -new at the end?) packages would be incompatible with older versions of packages. 3. ERRATA The local maven repository would not be a good fit since it is on a per-user basis (~/.m2). The correct way would be to define a path for installing (such as /usr/share/.m2), and pass that to build tools as a URL (file:///usr/share/.m2). Feel free to reply if you have any questions or improvements. Kaibo Ma
Re: [gentoo-dev] Packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum
On 05/03/2021 19:37, Sam James wrote: Following the retirement of a proxy maintainer, as their request, we have the following packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum I'll take them. -- Marecki
Re: [gentoo-dev] Packages up for grabs
Hi, I can take > [Bv] net-misc/teamviewer //madmartin
[gentoo-dev] proxied="" attribute added to metadata.xml
Hi, everyone. TL;DR: the Council has approved adding the optional proxied="yes|no|proxy" (defaults to 'no') attribute to metadata.xml yesterday. Please wait a few more hours before using it. If you're not dealing with proxy maintenance at all, you can safely ignore this message. What's added? = The elements (used for Gentoo maintainers, not these in ) now accepts an additional proxied="" attribute, that can be either: - proxied="yes" -- indicating that the person in question is a proxied maintainer (i.e. does not have direct push access) - proxied="no" (the default, so don't specify it) -- indicating that the person in question is a maintainer with push access - proxied="proxy" -- indicating that the developer in question only proxies (i.e. pushes commits) for somebody else and does not maintain the package itself What's needed to support it? The updates to DTD and XML Schema were pushed yesterday (EU) evening, and I've just pushed pkgcore revbumps. I'm still waiting for rsync to catch up to upgrade pkgcore on Infra. So rough ETA, you can start using it in ~6 hours. If you see pkgcheck complaining about failing schema validation, upgrade it. How to use it? == For regular dev-maintainers (with @gentoo.org), don't do anything. For proxied maintainers (including Gentoo devs without push access), use proxied="yes". For their respective proxies, use proxied="proxy". For example: fn...@example.com proxy-ma...@gentoo.org What's the gain? This will primarily power pkgcheck checks for stale proxy records. Currently they assume that everyone @gentoo.org has push access (which isn't correct) and only treats proxy-ma...@gentoo.org as proxy. With this data, the checks will be enhanced to explicitly recognize devs without push access and devs acting as proxies, and therefore report: a. whenever metadata.xml specifies only proxies, i.e. nobody in there has push access, b. whenever a proxy is left over when all proxied maintainers are removed. Questions? == -- Best regards, Michał Górny
