[gentoo-dev] Last-rites: www-plugins/freshplayerplugin
# Andreas Sturmlechner (2020-09-04) # No maintainer, defunct with modern browsers, bug #694024. # Masked for removal in 30 days. www-plugins/freshplayerplugin signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: app-text/cutemarked
# Andreas Sturmlechner (2020-09-04) # Depends on deprecated dev-qt/qtwebkit, maintainer unresponsive for 1.5 yr.; # Upstream dead, fork available, bug #684678. Masked for removal in 30 days. app-text/cutemarked signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: kde-apps/libkgeomap
# Andreas Sturmlechner (2020-09-04) # Depends on deprecated dev-qt/qtwebkit, no more revdeps; bug #737928 # Masked for removal in 30 days. kde-apps/libkgeomap signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-python/flask-appconfig
# Louis Sautier (2020-09-04) # Masked for removal in 30 days, no revdeps. Dependency of # previously removed dev-python/flask-bootstrap dev-python/flask-appconfig signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Please port your packages to Python 3.8
Michael Orlitzky wrote:
>
> Who generates the metadata when I `git pull`?
For the gentoo repository, it is in general some gentoo server
which then pushes the calculated metadata to the repository which
you pull as a user.
It is *possible* to use the "plain" repository, but you have to
set up quite a bit for that (updating metadata is only one of
several steps which you have to do manually in that case).
A collection of scripts which do the missing steps is
https://github.com/vaeth/portage-postsyncd-mv
though I do not know whether they still work. Indeed (as
probably most users) I am using since years one of the
repositories with generated metadata already.
> Or in overlays?
There are overlays which provide metadata, and there are overlays
where you have to do it on your own with egencache. Overlays which
use eclasses from the gentoo repository usually do the latter,
since otherwise the metadata is soon out-of-date.
However, for most overlays, egencache takes far less than a minute,
so for overlays, this is not really an issue. For the gentoo repository,
the time of a full metadata generation is considerable. As mentioned,
checksums and timestamps are used to minimize the amount, though this
does not work for eclass changes (see below).
> but if you record that wasted time in a different "metadata generation"
> ledger, then it looks like I've saved a bunch of time because the "bash
> sourcing" ledger reads zero.
No. You need correct metadata after every syncing of the repository.
Either the gentoo server or your machine has to do it.
This is independent of whether the PM "prefers" the installed or
the repositories' metadata. Excluding installed packages from metadata
updating would not be sane and would not safe much time (since the vast
majority of ebuilds are not installed, anyway).
> Even if I believe in a metadata angel and if we pretend that the PMS
> requires the metadata to be there, then rebuilding whenever metadata
> changes is still not 100% correct (as you point out), because it often
> rebuilds pointlessly. But that's getting into a harder problem.
Yes, usually the metadata rebuilds due to eclass changes are pointless
(except in the few cases where the eclass change is related with the
metadata).
I remember when I used to sync from the "plain" repository and rebuilt
the metadata on my system, that the syncing (i.e. metadata regeneration)
costed 10-30 minutes whenever one of the basic eclasses (which are
sourced by almost every ebuild) had a trivial change. Probably,
meanwhile machines are slightly faster and there are less such "basic"
eclasses needed in newer EAPIs, but it will still need a considerable
time.
> The recompilation isn't always pointless. In the present scenario, the
> rebuild is what installs the python-3.8 copy of the program.
No. If users use the defaults for PYTHON_{,SINGLE}_TARGET, the
rebuild has absolutely no effect except for changing some metadata
in /var/db/pkg (and some file timestamps).
> I'm not arguing that this is the best way to do things, but that it's
> the only way to do them given what's in the PMS today.
Of course. That was the decision made some years ago.
> maybe it should pay a few people to sit around and think about
> this for a week.
There was such a debate some years ago, before the decision mentioned
above was made.
It was a hefty discussion, but there were strong proponents of pointless
recompilation vs. improvement of the dependency handling (for both
sides, there are much more arguments which I will not repeat now).
The discussion might have turned if I would have found the time to
implement the necessary change in portage, but neither then nor now
I have the time to do so. (To be honest: Maybe I had the time, but I
dislike python too much.) Nevertheless, I do not think that it was a
good decision.
I am not posting this to re-roll the above discussion again.
But your posting shows that apparently not everybody knows the reasons
why things are the way they are now.
Re: [gentoo-dev] Please port your packages to Python 3.8
On 2020-09-04 09:22, Rich Freeman wrote: > > Current Gentoo policy: > > ...if the changes are likely to cause problems for end users." If you're willing to ignore the user reports of problems, and ignore the mailing list threads telling you that it will cause problems, and avoid running any tests, then it becomes possible to construct a fortress of flawed reasoning to defend the claim that "this won't cause problems for end users."
Re: [gentoo-dev] Please port your packages to Python 3.8
On Fri, Sep 4, 2020 at 9:06 AM Michael Orlitzky wrote: > > It's easy to say "well this is not an issue because it can be solved by > ..." > > If it's easy, get it added to the PMS and I'll agree with you. > Current Gentoo policy: "Maintainers must not assume that dynamic dependencies will be applied by the package manager. When changing runtime dependencies the maintainer should revision the ebuild if the changes are likely to cause problems for end users." [1] Certainly having a discussion about whether this could change down the road is reasonable, but keep in mind this would require package managers to actually be changed, which requires code. Out of the box portage has issues with dynamic deps[2] so it isn't a solved problem on any package manager, let alone all of them. In the interim, devs MUST revbump in these situations. The Council left some room for discretion, and as a result I end up having portage rebuild everything on changed deps because frankly I don't trust people to get it right, since if people can't see for themselves the reason for a rule it seems to be a reason to ignore it. The rule is also documented in the devmanual[3]. 1 - https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt 2 - https://wiki.gentoo.org/wiki/Project:Portage/Changed_Deps#Ebuild_Revision_Bumps 3 - https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html -- Rich
Re: [gentoo-dev] Please port your packages to Python 3.8
On Fri, 4 Sep 2020 09:06:46 -0400 Michael Orlitzky wrote: > On 2020-09-04 08:54, Alexis Ballier wrote: > > > > py37 will (*) still be installed as it cannot be depcleaned because > > of 1. emerge won't fail since deps are satisfied. > > > > > > (*) or rather should, but I think the only case that matters is a > > valid system state where noone forced uninstall of a needed package > > or manually rm'ed some random files > > > > There's no need to speculate; use pkgcore for a month and come back > and tell me how much comfort these hypotheticals were. there's no speculation in assuming a consistent set of installed packages (consistent as specified in... PMS ;) ); there is, however, speculation in the hypothetical error messages when the installed set of packages is inconsistent > >> or.. > >> > >> 3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support. > >> 4b. A user tries to install that revdep, but the PM sees that > >> the latest version of foo is already installed, and it (the > >> installed version) doesn't support python-3.8. Mysterious > >> error messages and manual intervention ensue. > > > > > > precisely the case I wrote above: unsatisfied dep -> pull ebuild. > > non-issue too. > > It's easy to say "well this is not an issue because it can be solved > by ..." are you kidding ? are you seriously suggesting adding to PMS that PM needs to pull ebuilds to install packages ? good luck with that ;)
Re: [gentoo-dev] Please port your packages to Python 3.8
On 2020-09-04 08:54, Alexis Ballier wrote: > > py37 will (*) still be installed as it cannot be depcleaned because of > 1. emerge won't fail since deps are satisfied. > > > (*) or rather should, but I think the only case that matters is a valid > system state where noone forced uninstall of a needed package or > manually rm'ed some random files > There's no need to speculate; use pkgcore for a month and come back and tell me how much comfort these hypotheticals were. >> or.. >> >> 3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support. >> 4b. A user tries to install that revdep, but the PM sees that >> the latest version of foo is already installed, and it (the >> installed version) doesn't support python-3.8. Mysterious >> error messages and manual intervention ensue. > > > precisely the case I wrote above: unsatisfied dep -> pull ebuild. > non-issue too. It's easy to say "well this is not an issue because it can be solved by ..." If it's easy, get it added to the PMS and I'll agree with you.
Re: [gentoo-dev] Please port your packages to Python 3.8
On Thu, 3 Sep 2020 14:17:06 -0400 Michael Orlitzky wrote: > On 2020-09-03 12:38, Alexis Ballier wrote: > > > > if some upgrade wants a package with unmatched deps (e.g. not > > installed at all or py38 usedep not satisfied), $PM will surely try > > to satisfy it by installing an ebuild. I don't think PMS specifies > > this, nor should it. > > > > It's not an upgrade per se. The situation is roughly this: > > 1. User installs foo-1.2.3.ebuild, which supports python-3.7. > 2. Developer ninja-edits the ebuild to support python-3.8. > 3a. (crickets) > 4a. Developer removes python-3.7 support from foo-1.2.3.ebuild. > 5a. The next time something pulls foo-1.2.3 into the depgraph, > the PM will see that the installed version of foo-1.2.3 depends > on python-3.7, but that there is no python-3.7 in the tree or that > it's masked. Now emerge always fails. py37 will (*) still be installed as it cannot be depcleaned because of 1. emerge won't fail since deps are satisfied. (*) or rather should, but I think the only case that matters is a valid system state where noone forced uninstall of a needed package or manually rm'ed some random files > > or.. > > 3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support. > 4b. A user tries to install that revdep, but the PM sees that > the latest version of foo is already installed, and it (the > installed version) doesn't support python-3.8. Mysterious > error messages and manual intervention ensue. precisely the case I wrote above: unsatisfied dep -> pull ebuild. non-issue too. > What's happening is that the PM is using the metadata from the > installed version of the package, rather than the ninja-edited > metadata in the repo (how would it know which ebuilds were edited > meaningfully?). That's completely legal according to the PMS, and > also the smart thing to do: sourcing a few thousand lines of bash > *just in case* there was an important change in some ebuild is a huge > waste of users' time. you seem to be confusing dynamic deps and unsatisfied deps here. A package installed with py38 disabled (e.g. after a revbump) or no py38 support at all (e.g. without revbump) will not satisfy a [py38] usedep in any case so will work just the same > Developers have an easy way to signal that there was an important > change: to bump the "r" number at the end of the ebuild. This forces > any upgrade involving e.g. foo-1.2.3 to pull in foo-1.2.3-r1, and the > fact that an upgrade is available is evident from `ls`, rather than > from sourcing a mountain of bash. One developer makes a change, and > it saves thousands of users each a lot of time. That's what we're all > here for. fixing non-issues does not seem so important to me :/ [...]
Re: [gentoo-dev] Re: Please port your packages to Python 3.8
On 2020-09-04 04:39, Martin Vaeth wrote: > >> That's completely legal according to the PMS, and also the >> smart thing to do: > > s/smart/dumb/, but necessary for a dumb PM Word games notwithstanding, these are the package managers described by the PMS. >> sourcing a few thousand lines of bash *just in case* there was an >> important change in some ebuild is a huge waste of users' time. > > That's wrong: The metadata has to be (re)generated anyway, > independent of whether this is a revision bump or just a modification. > For most syncing methods the bash sourcing does not happen on the > user's machine, and on those machines where the metadata is actually > calculated, there are checksums and timestamps used to minimize the > effort. From this perspective there is no difference between a > modification or a revision bump. This is Hollywood accounting =) Who generates the metadata when I `git pull`? Or in overlays? It's me, but if you record that wasted time in a different "metadata generation" ledger, then it looks like I've saved a bunch of time because the "bash sourcing" ledger reads zero. Even if I believe in a metadata angel and if we pretend that the PMS requires the metadata to be there, then rebuilding whenever metadata changes is still not 100% correct (as you point out), because it often rebuilds pointlessly. But that's getting into a harder problem. > ... costs thousands of users a lot of compilation time, although > the recompilation is completely pointless for each of them, but > done only to keep the PM simpler. The recompilation isn't always pointless. In the present scenario, the rebuild is what installs the python-3.8 copy of the program. I'm not arguing that this is the best way to do things, but that it's the only way to do them given what's in the PMS today. The foundation is always looking for ways to spend money; maybe it should pay a few people to sit around and think about this for a week. In any case, until a better solution finds its way into the PMS, we should make the revisions.
[gentoo-dev] Packages up for grabs: aqbanking and friends (German HBCI onlinebanking)
Hi, I'm listed as the maintainer of aqbanking and a bunch of packages that are basically just its dependencies (though libchipcard and ktoblzcheck may be used separately for some functionality). This is a library for accessing german online banking systems (which goes under the names HBCI or FinTS) and can be used e.g. with gnucash. I'm practically not using these any more as I've completely switched to using the web interface of my bank. I also haven't been very active in maintaining them and probably should've removed myself a while ago as the maintainer. If you care about these please add yourself as a maintainer. I will remove myself in a few days and assign them to maintainer-needed status if noone steps up. The packages include: net-libs/aqbanking app-misc/ktoblzcheck sys-libs/gwenhywfar sys-libs/libchipcard sys-libs/libhx -- Hanno Böck https://hboeck.de/
[gentoo-dev] news item: riscv multilib profile is going away
[** Note 1: This only affects one specific profile. **] [** Note 2: I am still testing the migration process proposed here. **] Title: riscv multilib profile is going away Author: Andreas K. Hüttel Posted: 2020-09-06 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/riscv/17.0/rv64gc The Gentoo RISC-V team is discontinuing the riscv64 multilib stages and profile. The main reason for this is that with the upcoming introduction of riscv32 a multilib stage would contain both 32bit and 64bit binaries, and so far no hardware exists that is able to run both and thus update the stage or installation (unless you use qemu). Please switch to the rv64gc/lp64d profile. This is done by * selecting default/linux/riscv/17.0/rv64gc/lp64d with eselect profile * rebuilding gcc emerge -1 sys-devel/gcc * and then rebuilding your system emerge -ev @world The default/linux/riscv/17.0/rv64gc profile will stop functioning soon. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Please port your packages to Python 3.8
Michael Orlitzky wrote: > What's happening is that the PM is using the metadata from the installed > version of the package, rather than the ninja-edited metadata in the > repo (how would it know which ebuilds were edited meaningfully?). The question is easy to answer: It is reasonable to assume that the repository metadata is correct and more up-to-date than the metadata of the installed version. But the PM would need to be smart enough to interpret subslot-deps correctly and merge that from the data of installed packages in a clever way. > That's completely legal according to the PMS, and also the > smart thing to do: s/smart/dumb/, but necessary for a dumb PM. > sourcing a few thousand lines of bash *just in case* there was an > important change in some ebuild is a huge waste of users' time. That's wrong: The metadata has to be (re)generated anyway, independent of whether this is a revision bump or just a modification. For most syncing methods the bash sourcing does not happen on the user's machine, and on those machines where the metadata is actually calculated, there are checksums and timestamps used to minimize the effort. From this perspective there is no difference between a modification or a revision bump. > Developers have an easy way to signal that there was an important > change: to bump the "r" number at the end of the ebuild. That's why it was decided to do it this way instead of requiring a smarter PM. Instead of putting some smart logic into the PM (which in case of portage was not fully implemented and in case of other package managers not at all), the decision was to force recompilations for every user and every tiny dependency change. > One developer makes a change, and it saves > thousands of users each a lot of time. ... costs thousands of users a lot of compilation time, although the recompilation is completely pointless for each of them, but done only to keep the PM simpler.
Re: [gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass
On 2020-09-03 15:37, Marek Szuba wrote:
For the record, some mostly-cosmetic issues that have already been
identified. Will include them in the next revision:
> +if [[ ! ${_LUA_R0} ]]; then
> +
> +inherit multibuild toolchain-funcs
> +
> +BDEPEND="virtual/pkgconfig"
There should be no BDEPEND in the eclass any more, it's a leftover from
an earlier iteration which retrieved module directories in less
conditional fashion.
> +# Please note that you can also use bash brace expansion if you like:
> +# @CODE
> +# LUA_COMPAT=( lua5_{1..3} )
s/_/-/
> + eerror "No Lua implementation selected for the build. Please add one"
> + eerror "of the following values to your LUA_TARGETS (in make.conf):"
Will add "or package.use" here.
> +# @FUNCTION: _lua_wrapper_setup
> +# @USAGE: [ []]
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Create proper 'lua' executable and pkg-config wrappers
Should be "proper Lua executables" - for dev-lang/lua we have got both
'lua' and 'luac', and for dev-lang/luajit we'll probably have 'luajit'
(have yet to see if invoking 'luajit' as 'lua' works).
> +# Check LUA_COMPAT for well-formedness and validity, then set
> +# two global variables:
> +#
> +# - _LUA_SUPPORTED_IMPLS containing valid implementations supported
> +# by the ebuild (LUA_COMPAT - dead implementations),
Just say "minus" here, as it stands it is a bit confusing (at least to
me) because my first reaction is to read the - as a dash, not as an
arithmetic minus.
--
MS
signature.asc
Description: OpenPGP digital signature
