Re: [gentoo-dev] Current portage will now truncate your repo's git history to 1
On Sat, Dec 17, 2022 at 05:42:43AM +, Sam James wrote: > > > > On 15 Dec 2022, at 19:22, Florian Schmaus wrote: > > > > This is a public service announcement that the recently stabilized portage > > version will truncate you repo's git history to 1. > > I wish you'd shown us in #gentoo-portage before sending this, as it's a bit > misleading / alarmist. We were actively all speaking > at the time. > > Not only to reconsider the phrasing and include some important details, but > also to mention the rationale, which I describe > below. > > If you felt the Portage team should've written a news item for it, you were > (and still are) free to say so, and we'd > do it. > > > > > While this is a good thing for the majority of Gentoo users, it affects > > developers that develop in a git known to portage (like me). If I > > understand the portage maintainers vision correctly, then future portage > > will assume full control over its configured repositories and potentially > > perform destructive operations on them, for example "git clean" [1]. > > > ... only for repositories of sync-type=git & auto-sync=yes. > > The rationale for this is that most people who use sync-type=git are doing so > because they want > a quicker sync (to complete), a more reliable one (no Manifest race condition > issues), and to > get changes from Gentoo faster. > > Whenever Portage is syncing something, our view was that we should prioritise > successful > completion of syncs, especially given it may be performed unattended. > > If git is pulling from a CDN, Portage may on one sync receive state X, but > on a subsequent sync receive state X-1. This can cause an odd state > where git wants to resolve conflicts and manual intervention is required. > > This situation was often worse with sync-depth=1 and would lead > to orphaned files, hence the 'git clean' PR referenced. > > The motivation behind the sync depth part was because of > disk space growing unbounded otherwise. Just to make this more abundantly explicit: it repeatedly happened to me (but others, too) that on a system using git to sync a shallow ::gentoo clone, during unattended syncs, the repository attempted a merge with the upstream, yielding a repo in a merging state, with a huge list of dirtied files in the working tree, plus untracked files. > > I personally would prefer portage simply adjusting its behavior based on > > the owner of the repository. That is, if it's the 'portage' user then > > assume full control, and if it is a different user, then fall back to a > > preserving, conservative mode of operation. Unfortunately, for me, this > > idea was received skeptically at best in a recent discussion in > > #gentoo-portage. > > This wouldn't work for Prefix and also FEATURES="-usersync". > > -- > > Now, looking forward in a constructive manner, I think we can > make both camps happy here with an option to indicate > If Portage can assume the repository will be touched by something > other than Portage. > > I propose a configuration option called 'volatile' (thanks > Arsen for the name suggestion) which indicates that the > repository may be changed outside of Portage by any time, > and hence no destructive operations should be carried out. > > If the option is on, it also prohibits some optimisations > which require assuming the integrity of the repository. > > I have a draft of these changes at https://github.com/gentoo/portage/pull/961. > > (https://github.com/gentoo/portage/pull/961.patch if want to view as a raw > patch series.0 > > I am undecided on whether volatile should be default on or not. In the PR > as it is, it defaults to off, which would require a news item. I may just > turn it > on given the tone of this thread, as none of it has been very encouraging > for further work on Portage. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Current portage will now truncate your repo's git history to 1
On Fri, Dec 16, 2022 at 11:01:13PM -0500, Brian Evans wrote: > On 12/15/22 20:08, Duncan wrote: > > Florian Schmaus posted on Thu, 15 Dec 2022 21:40:19 +0100 as excerpted: > > > >> On 15/12/2022 21.10, Toralf Förster wrote: > >>> On 12/15/22 20:22, Florian Schmaus wrote: > o use PORTDIR_OVERLAY and multiple repositories on their system: a > system-wide, managed by portage, and a dev repository (in your HOME), > scoped in via PORTDIR_OVERLAY. > >>> > >>> Isn't this covered by /etc/portage/repos.conf/* > >> > >> Absolutely, but this requires a manual intervention from the user. And, > >> of course, you can totally opt-out from portage managing (syncing) the > >> repository, but then you have to take care of syncing yourself. > >> > >> The point is that with the new portage release, portage's behavior > >> changes. And I would argue that portage should not, in its effort to > >> become more user friendly, disregard ebuild-developer friendliness. > >> Assuming it is achievable with a reasonable amount of additional code > >> complexity. > > > > This bit me too, and making things worse, the truncate killed the git > > history that presumably had the answer I needed to fix it up. > > =:^( Fortunately I had a bit of a clue due to preemptively following the > > portage changelog where I had seen a hint, so I was able to dig it up > > again without the git log help that's definitely now my first instinct. > > > > Thankfully, if anyone does accidentally gets shallowed, just executing > 'git fetch --unshallow' will revert the default '--depth 1' > > I really don't care for that 'git clean' patch. If that makes it in > without a way to opt-out, it will be patched out for me personally. > > Brian By "that 'git clean'" patch, do you mean [1]? Why are you speaking as if you're talking about a 3rd party and not people that are also on the gentoo-dev mailing list? It seems like the more productive thing to do would be to at least offer substantive criticism about a specific PR, maybe even in the PR itself. While I'm at it: you used to be reachable on IRC, but you never migrated away from Freenode. Why? It seems like every few days someone is looking for you only to be surprised that you're not in Gentoo's IRC community anymore. [1] https://github.com/gentoo/portage/pull/939 signature.asc Description: PGP signature
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Also, according to commit history, dynamic exception usage was removed
in
https://github.com/vlabella/GLE/commit/14753e9aba9eb6490358caaeb60f6e36ba314acc,
so you can try to apply this patch.
сб, 17 дек. 2022 г. в 16:05, Azamat Hackimov :
>
> Hello.
>
> You need to add
>
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> into CMakeLists.txt after project() declaration via patching. Since
> this is an upstream issue, you need to notify upstream about C++17
> incompatibility.
>
> сб, 17 дек. 2022 г. в 14:35, Andrey Grozin :
> >
> > Hello *,
> >
> > I'm trying to package a new version of sci-visualization/gle which now
> > uses cmake. After some patching CMakeLists.txt, it configures
> > successfully. But at build time it spits zillion errors
> >
> > error: ISO C++17 does not allow dynamic exception specifications
> >
> > The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
> >
> > src_compile() {
> > CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> > }
> >
> > but this makes no difference, c++17 is still used. How to convince
> > cmake_src_compile to use -std=c++14?
> >
> > Thanks in advance,
> > Andrey
> >
>
>
> --
> From Siberia with Love!
--
>From Siberia with Love!
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
On Sat, 17 Dec 2022, Arsen Arsenović wrote: audacity-2.4.2-r3.ebuild has something for this already: ``append-cxxflags -std=gnu++14'' Thanks, this works. Andrey
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hello.
You need to add
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
into CMakeLists.txt after project() declaration via patching. Since
this is an upstream issue, you need to notify upstream about C++17
incompatibility.
сб, 17 дек. 2022 г. в 14:35, Andrey Grozin :
>
> Hello *,
>
> I'm trying to package a new version of sci-visualization/gle which now
> uses cmake. After some patching CMakeLists.txt, it configures
> successfully. But at build time it spits zillion errors
>
> error: ISO C++17 does not allow dynamic exception specifications
>
> The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
>
> src_compile() {
> CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> }
>
> but this makes no difference, c++17 is still used. How to convince
> cmake_src_compile to use -std=c++14?
>
> Thanks in advance,
> Andrey
>
--
>From Siberia with Love!
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hi, > but this makes no difference, c++17 is still used. How to convince > cmake_src_compile to use -std=c++14? Cmake sets those flags during src_configure (when the build dir is configured) and therefore ignores CXXFLAGS entirely during src_compile. You should set those in src_configure before cmake_src_configure gets called. And Arsen Arsenovićs reply applies here on how to use flag-o-matic function append-cxxflags to do it. -- Alfred Wingate
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hi,
Andrey Grozin writes:
> Hello *,
>
> I'm trying to package a new version of sci-visualization/gle which now uses
> cmake. After some patching CMakeLists.txt, it configures successfully. But at
> build time it spits zillion errors
>
> error: ISO C++17 does not allow dynamic exception specifications
>
> The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
>
> src_compile() {
> CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
> }
>
> but this makes no difference, c++17 is still used. How to convince
> cmake_src_compile to use -std=c++14?
>
> Thanks in advance,
> Andrey
audacity-2.4.2-r3.ebuild has something for this already:
``append-cxxflags -std=gnu++14''
Check out flag-o-matic.eclass. Note that the build system could still
be overriding it, so if that fails, I'd check the compilation commands
for -std=... parameters, as well as CXX_STANDARD_LEVEL, or whatever
cmake calls it.
Hope that helps, have a great day.
--
Arsen Arsenović
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-python/test_server
# Michał Górny (2022-12-17) # The new version requires `multipart` that conflicts # with dev-python/python-multipart used by dev-python/starlette. # No reverse dependencies. # Removal on 2023-01-16. Bug #886475. dev-python/test_server -- Best regards, Michał Górny
[gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hello *,
I'm trying to package a new version of sci-visualization/gle which now
uses cmake. After some patching CMakeLists.txt, it configures
successfully. But at build time it spits zillion errors
error: ISO C++17 does not allow dynamic exception specifications
The natural thing to try is to add -std=c++14 to CXXFLAGS. So I tried
src_compile() {
CXXFLAGS="${CXXFLAGS} -std=c++14" cmake_src_compile
}
but this makes no difference, c++17 is still used. How to convince
cmake_src_compile to use -std=c++14?
Thanks in advance,
Andrey
[gentoo-dev] Last rites: dev-perl/perl-mozldap
# Michał Górny (2022-12-17) # Discontinued upstream. Fails to build for some users. No reverse # dependencies. # Removal on 2023-01-16. Bug #650346. dev-perl/perl-mozldap -- Best regards, Michał Górny
[gentoo-dev] Last rites: media-gfx/iscan-plugin-network-nt
# Michał Górny (2022-12-17) # No longer downloadable. Pending version bump with no reply from # the maintainer. # Removal on 2023-01-16. Bug #786912. media-gfx/iscan-plugin-network-nt -- Best regards, Michał Górny
