| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
 Posted: Wed Jul 25, 2018 6:31 pm Post subject: |
 |
|
| Tony0945 wrote: | | Anon-E-moose wrote: | | And even at that, I found a bsd based patch for gtk+3 so that at-spi2-* wouldn't be pulled in, which would have required me to run dbus. |
Could you pastebin that patch, please? |
https://paste.pound-python.org/show/HZhCk5ROfBn5ahEanLXF/
2 files, the patch itself and the patch for the ebuild.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Jul 25, 2018 7:13 pm Post subject: |
|
|
| Anon-E-moose wrote: | https://paste.pound-python.org/show/HZhCk5ROfBn5ahEanLXF/
2 files, the patch itself and the patch for the ebuild. |
Can confirm it built successfully and with the desired effect:
| Code: | ~ $ diff -u <(ldd /usr/lib/libgtk-3.so | sed 's/(0x.*)//') <(ldd /var/tmp/portage/x11-libs/gtk+-3.22.30/image/usr/lib64/libgtk-3.so | sed 's/(0x.*)//')
--- /dev/fd/63 2018-07-25 20:02:26.797256561 +0100
+++ /dev/fd/62 2018-07-25 20:02:26.797256561 +0100
@@ -15,7 +15,6 @@
libcairo.so.2 => /usr/lib64/libcairo.so.2
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0
- libatk-bridge-2.0.so.0 => /usr/lib64/libatk-bridge-2.0.so.0
libepoxy.so.0 => /usr/lib64/libepoxy.so.0
libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0
@@ -39,8 +38,6 @@
libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0
libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0
libz.so.1 => /lib64/libz.so.1
- libatspi.so.0 => /usr/lib64/libatspi.so.0
- libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3
libexpat.so.1 => /usr/lib64/libexpat.so.1
libuuid.so.1 => /lib64/libuuid.so.1
libbz2.so.1 => /lib64/libbz2.so.1 |
Can also confirm gtk3 stuff (Firefox etc) no longer spawns persistent junk at-spi-bus-launcher processes with this patch applied, thanks for sharing it. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Wed Jul 25, 2018 8:04 pm Post subject: |
|
|
| Tony0945 wrote: | | Code: | # eix --only-names --exact --installed-with-use --substring python2 --and --not --substring --use python3
app-misc/resolve-march-native
app-office/gnumeric
app-text/asciidoc
app-text/gnome-doc-utils
dev-lang/yasm
dev-libs/libgamin
dev-libs/libmateweather
dev-libs/libnatspec
dev-libs/libxslt
dev-python/enum34
dev-python/gconf-python
dev-python/graphy
dev-python/ipaddress
dev-python/pygtk
dev-python/pygtkglext
dev-util/gtk-doc
dev-util/itstool
dev-vcs/git
dev-vcs/mercurial
gnome-base/gconf
gnome-base/libglade
mate-base/mate-applets
mate-base/mate-desktop
mate-base/mate-menus
media-gfx/eom
media-gfx/graphviz
net-analyzer/namebench
net-analyzer/net-snmp
net-analyzer/nmap
net-fs/samba
net-libs/libproxy
net-print/cups
sys-libs/ldb
sys-libs/talloc
sys-libs/tdb
sys-libs/tevent
x11-libs/vte
x11-misc/mozo
x11-wm/openbox
|
That's a lot of packages requiring python 2.
I really don't give a damn about python 2 vs 3. I don't program with python and it's only on my systems because other packages like portage need it. I AM annoyed that the devs can't seem to keep this stuff straight in the portage tree. I had some subversion of python 3 then it was reverted and then the revsion was reverted. I get that python 3 has syntactical differences from python 2. So do various versions of C and C++, but the devs seem to do a good job patching and warning when they don't patch. But can you say that the above list is some sort of weird old fashioned Gentoo that I'm clinging too? samba? cups? gconf? (required by mate).
Maybe those packages could be migrated to python 3? or the flavor of the month of python 3?
Am I really asking to much to ask that portage make this transparent in the official tree? |
| Code: | eix --only-names --exact --installed-with-use --substring python2 --and --not --substri
app-text/asciidoc
app-text/cherrytree
app-text/gnome-doc-utils
dev-lang/yasm
dev-libs/keybinder
dev-libs/libgamin
dev-libs/libnatspec
dev-libs/libxslt
dev-python/enum34
dev-python/futures
dev-python/ipaddress
dev-python/pygtk
dev-python/pygtksourceview
dev-python/wxpython
dev-util/boost-build
dev-util/itstool
dev-vcs/git
gnome-base/gconf
media-gfx/gimp
media-gfx/graphviz
media-gfx/inkscape
media-gfx/uniconvertor
net-analyzer/nmap
net-fs/samba
net-libs/libproxy
net-libs/nodejs
net-mail/mailutils
net-print/cups
sci-electronics/kicad
sys-libs/ldb
sys-libs/talloc
sys-libs/tdb
sys-libs/tevent
x11-wm/openbox |
Samba appear to almost be there ( https://bugzilla.samba.org/show_bug.cgi?id=10028 )
Inkscape,Gimp, graphviz ... these all depend on gtk2 and GTK2 only has python2 bindings... inkscape and gimp are progressing through to gtk3 conversion so at some point this or next year they can be dropped.
The two REALLY odd ones on my list are: git and kicad... kicad uses QT and git is ???? surprised that didn't py3.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Jul 25, 2018 11:26 pm Post subject: |
|
|
| Anon-E-moose wrote: |
2 files, the patch itself and the patch for the ebuild. |
Thanks! Found I had to add the atk-bridge useflag to metadata.xml also.
So what does it mean? And why is it default. Changed the default in my local repo.
Will check later if this works on later versions.
Thanks again![/code] |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Jul 25, 2018 11:42 pm Post subject: |
|
|
| Tony0945 wrote: | | Anon-E-moose wrote: |
2 files, the patch itself and the patch for the ebuild. |
Thanks! Found I had to add the atk-bridge useflag to metadata.xml also.
So what does it mean? And why is it default. Changed the default in my local repo.
Will check later if this works on later versions.
Thanks again! |
Not sure what all it does, but by default gtk+3 pulls in at-spi2-[atk/core] libs/code, this disables pulling in those dependencies.
from ati-spi2-atk -> DESCRIPTION="Gtk module for bridging AT-SPI to Atk"
from ati-spi2-core -> DESCRIPTION="D-Bus accessibility specifications and registration daemon"
It's part of the stupid accessibility stuff that gnome wants everyone to use whether they want it or not and unfortunately it pulls in dbus to talk to atk.
It should work on later versions, but probably not an exact line number match, I think the patching uses a fuzz factor.
Looks like Ant P used it on gtk+-3.22.30
Edit to add: it sure is difficult to find out exactly what it does but ran across this from Linux from scratch about it
The At-Spi2 Core package is a part of the GNOME Accessibility Project. It provides a Service Provider Interface for the Assistive Technologies available on the GNOME platform and a library against which applications can be linked.
Edit to add 2: It seems it's derived from CORBA garbage.
From the wiki:
Assistive Technology Service Provider Interface (AT-SPI) is a platform-neutral framework for providing bi-directional communication between assistive technologies (AT) and applications.[3] It is the de facto standard for providing accessibility to free and open desktops, like GNU/Linux or OpenBSD, led by the GNOME Project.
One common nomenclature to explain an accessibility framework is a usual client-server architecture. In that way, Assistive Technologies (ATs) like screen readers, would be the clients of that framework, and computer applications would be the server. In this architecture, client and server need to communicate with each other, usually using the IPC technology of the platform. Ideally the accessibility framework exposes this to the client and server in a transparent way.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Jul 25, 2018 11:50 pm Post subject: |
|
|
Right! I'm not handicapped, so why do I need it? Might be a good default for public computers.
I've been irked about Mate requiring this. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Jul 25, 2018 11:52 pm Post subject: |
|
|
The patch I found was originally from the gnome people, then they changed their mind the next point release and reversed the commit.
And everyone has been stuck with it ever since. ~le sigh~
Edit to add: even under windoze I can turn off the accessibility stuff if don't want/need it.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Jul 26, 2018 3:07 am Post subject: |
|
|
| Not just Windows; newer versions of Firefox add a "Block Accessibility APIs" checkbox right in the user-facing options page, and you know how much they've dumbed it down to avoid scaring the user recently… (it turns out this dead weight's an easy backdoor for malware) |
|
| Back to top |
|
|
njsg
Tux's lil' helper
Joined: 17 Dec 2005
Posts: 88
|
| Posted: Fri Jul 27, 2018 9:58 am Post subject: |
|
|
| So, while it is true one can patch the ebuild and add the other patch, any chance we can get this in the main portage tree? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jul 27, 2018 10:03 am Post subject: |
|
|
| njsg wrote: | | So, while it is true one can patch the ebuild and add the other patch, any chance we can get this in the main portage tree? |
Well... As a USE flag patch possibly.
One thing I like about Gentoo is they will follow upstream and only patch what's needed to function via portage .
A USE flag should be viable method but when packages that really need gtk3 stop functioning where does support go? It can't go upstream, what can Gentoo devs do?
This is the real question that needs to be considered for such a patch to be accepted... Where will the support queries go WHEN a problem occurs. Burning bugwrangers time on bugs.gentoo.org isn't the right thing
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Jul 27, 2018 10:51 am Post subject: |
|
|
| njsg wrote: | | So, while it is true one can patch the ebuild and add the other patch, any chance we can get this in the main portage tree? |
Highly unlikely it will go into the main portage tree.
It was offered originally only because upstream supplied it.
But that's why the overlays exist, for things that upstream doesn't supply, want, need, old versions, etc.
The more pertinent question is why doesn't upstream allow it.
Why must everyone pull in accessibility even when only a minority may need or want it?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Jul 27, 2018 11:31 am Post subject: |
|
|
| Anon-E-moose wrote: | The more pertinent question is why doesn't upstream allow it.
Why must everyone pull in accessibility even when only a minority may need or want it? |
Because you mistake who is the minority.
For you the minority is users with disability.
For upstream minority is non binary distro users.
A binary distro will have no choice to have it even it's not use, at best, if well made, users may have choice to disable it (but a disable functionality is not the same as a missing functionality).
And for upstream, they care only about binary distro, because it's one behind them.
It could even be a strategic choice ; if your weakness is your unability to use something only when it have a use, maybe you could impose this to anyone, making your weakness disapears as everyone must use it.
You're not bloated if everyone is bloated  |
|
| Back to top |
|
|
njsg
Tux's lil' helper
Joined: 17 Dec 2005
Posts: 88
|
| Posted: Fri Jul 27, 2018 11:32 am Post subject: |
|
|
| Naib wrote: | | njsg wrote: | | So, while it is true one can patch the ebuild and add the other patch, any chance we can get this in the main portage tree? |
Well... As a USE flag patch possibly. |
It is a USE flag patch.
| Naib wrote: |
One thing I like about Gentoo is they will follow upstream and only patch what's needed to function via portage .
A USE flag should be viable method but when packages that really need gtk3 stop functioning where does support go? It can't go upstream, what can Gentoo devs do?
This is the real question that needs to be considered for such a patch to be accepted... Where will the support queries go WHEN a problem occurs. Burning bugwrangers time on bugs.gentoo.org isn't the right thing |
If something breaks because of this patch, that will be because some dependency was not clearly specified, or because something was not tested appropriately. Support does go to bugs.gentoo.org as it would and should go for any other broken ebuild, build failure, etc. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jul 27, 2018 12:43 pm Post subject: |
|
|
| njsg wrote: | | Naib wrote: | | njsg wrote: | | So, while it is true one can patch the ebuild and add the other patch, any chance we can get this in the main portage tree? |
Well... As a USE flag patch possibly. |
It is a USE flag patch.
|
No it isn't....
There is no USE flag that patches the source on gtk+ to remove the need for at-spi2-*
| Code: | # emerge gtk+ -va
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-libs/gtk+-3.22.30:3::gentoo USE="X cups introspection (-aqua) -broadway -cloudprint -colord -examples {-test} -vim-syntax -wayland -xinerama" ABI_X86="32 (64) (-x32)" 18,503 KiB
# ll /usr/portage/x11-libs/gtk+/files/
total 32
-rw-r--r-- 1 root root 1487 Jul 1 13:37 gtk+-2.24.24-out-of-source.patch
-rw-r--r-- 1 root root 1331 Jul 1 13:37 gtk+-2.24.31-fix-gtkentry-beep.patch
-rw-r--r-- 1 root root 2504 Jul 1 13:37 gtk+-2.24.31-update-icon-cache.patch
-rw-r--r-- 1 root root 1904 Jul 1 13:37 gtk+-3.22.20-libcloudproviders-automagic.patch
-rw-r--r-- 1 root root 5474 Jul 1 13:37 gtk+-3.22.2-update-icon-cache.patch
-rw-r--r-- 1 root root 627 Jul 1 13:37 gtkrc
-rw-r--r-- 1 root root 96 Jul 1 13:37 settings.ini
|
no patch to remove at-spi2-*, no USE flag to enable such patch.
It could be BUT it isn't. There is a world of difference between a technical possibility (this is), planned to be implemented (it isn't) and "it is".
You stated "it is" There is no USE flag... it could but it isn't
Does GEntoo offer patches to packages? sure they do and I have mentioned this. A recent wave was due to GCC-7.x being stricter on typecasting and alot of upstream packages would not build, but they have accepted patches for the next release and as a result gentoo took said patches into the tree.
They also patches controlled via USE flags. gentoo-sources to add gentoo-specific tweaks (around openrc) and they have offered a kdbus USE flag to pull in the kdbus patch if the user wanted. This is the exception not the norm due to the permutations
| njsg wrote: |
| Naib wrote: |
One thing I like about Gentoo is they will follow upstream and only patch what's needed to function via portage .
A USE flag should be viable method but when packages that really need gtk3 stop functioning where does support go? It can't go upstream, what can Gentoo devs do?
This is the real question that needs to be considered for such a patch to be accepted... Where will the support queries go WHEN a problem occurs. Burning bugwrangers time on bugs.gentoo.org isn't the right thing |
If something breaks because of this patch, that will be because some dependency was not clearly specified, or because something was not tested appropriately. Support does go to bugs.gentoo.org as it would and should go for any other broken ebuild, build failure, etc. |
um ... no... For gentoo to support this patch via a USE flag they must take ownership of the resultant bugs that would occur with a ridiculous number of permutation. Gentoo would then have to take responsibility to fix these other packages with bespoke gentoo patchset to support another patchset ... this very quickly becomes a rats nest of permutations managed via patchsets to cope with other patchsets. Dealing with vanilla upstream source means upstream can be approach to fix their code. Gentoo does not have the resources to contemplate forking every package and equally every package with every combination of patchsets across the dependency tree. This is unreasonable to expect from gentoo when they offer a framework.
So no, this patchset isn't a USE flag, it could be offered as a USE flag but it isn't and it shouldn't be offered by default by Gentoo due to the resultant loading on bugreports. Gentoo provides a framework where users can EASILY apply their own patches via /etc/portage/patches
--edit--
Looking at the patch to the ebuild and the source, the patch is applied no matter what. USE flags then set whether at-sp2 is pulled in. This diverges teh codebase irrespective of the users choice.
The patch should be applied *IF* a USE flag is set and this is before considering whether such patches would be accepted and there are very good reasons why not and I have stated them
_________________
| Quote: | | Removed by Chiitoo |
Last edited by Naib on Fri Jul 27, 2018 2:16 pm; edited 2 times in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Jul 27, 2018 1:12 pm Post subject: |
|
|
I could have modified the ebuild to use the atk-bridge flag (that I added) to apply the patch, but didn't think about it.
Because ... gosh darned it, I was basically doing it for me. 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jul 27, 2018 1:43 pm Post subject: |
|
|
| Anon-E-moose wrote: | I could have modified the ebuild to use the atk-bridge flag (that I added) to apply the patch, but didn't think about it.
Because ... gosh darned it, I was basically doing it for me. |
exactly but that isn't my point. njsg is picking up bad habits from others posting here (here being the forum) . Asserting their view as the only view to be considered and via twisting what is stated to align with their dismissal.
Factorially incorrect like every other instance
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
njsg
Tux's lil' helper
Joined: 17 Dec 2005
Posts: 88
|
| Posted: Fri Jul 27, 2018 2:02 pm Post subject: |
|
|
I may be mistaken, but doesn't the following toggle the atk-bridge based on the USE flag?
| Code: |
+ $(use_with atk-bridge) \
|
And also
| Code: |
- >=app-accessibility/at-spi2-atk-2.5.3[${MULTILIB_USEDEP}]
+ atk-bridge? ( >=app-accessibility/at-spi2-atk-2.5.3[${MULTILIB_USEDEP}] )
|
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jul 27, 2018 2:07 pm Post subject: |
|
|
no and yes. Yes there is a USE flag to depend on at-spi2 BUT the patch is applied irrespective of choice ERGO this isn't a USE flag patch, a USE flag that applies a patch
re-read EXACTLY the flow because I am serious, you are picking up some really disgusting habits.
1) ask if it can go in the main portage
2) as a USE flag patch possibly
3) it is a USE flag patch
now maybe you read what I wrote as "someone needs to provide a patch that ads a USE flag" which the patch does. What I wrote (which you conviniently cherry picked... AGAIN disgusting bad behaviour) and then the following post explained Gentoo follows upstream, this would break upstream. Something like this would be exposed as a USE patch (ie a USE flag to apply a patch). This does not mean it would be added, as I explained, equally the patch ACTUALLY is applied irrespective of the USE flags...
The USE flag just pulls in at-spi2-atk BUT the patch is still applied, ergo the USE flag doesn't apply the patch... this breaks alignment with upstream for those that do want at-spi2
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Jul 27, 2018 3:40 pm Post subject: |
|
|
| Naib wrote: | | this breaks alignment with upstream for those that do want at-spi2 |
No, it doesn't. The purpose of the patch is to bring the option to the build system. If you happen to not pass --without-use-atk-bridge, you get the original build.
This is the cleanest way to patch a package, because it is distribution-agnostic and does not rely on a way that the distribution can automatically apply patches depending on user choices.
Unfortunately, patches are often not written in this clean way out of lazyness: It is of course less work to set up only a quick hack which then only works for gentoo.
BTW, the ebuild with the mentioned patch is available in the mv overlay since ages... |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Jul 27, 2018 3:45 pm Post subject: |
|
|
| mv wrote: | | Naib wrote: | | this breaks alignment with upstream for those that do want at-spi2 |
No, it doesn't. The purpose of the patch is to bring the option to the build system. If you happen to not pass --without-use-atk-bridge, you get the original build.
This is the cleanest way to patch a package, because it is distribution-agnostic and does not rely on a way that the distribution can automatically apply patches depending on user choices.
Unfortunately, patches are often not written in this clean way out of lazyness: It is of course less work to set up only a quick hack which then only works for gentoo.
BTW, the ebuild with the mentioned patch is available in the mv overlay since ages... |
you haven't dealt with anything following DO178 have you otherwise you would not be making such a statement.
By all means have it in a custom overlay but for Gentoo to make this (and by extension other such patches) can result in a massive support issue
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Jul 27, 2018 4:05 pm Post subject: |
|
|
Naib is correct in that the way I added the patch itself will be applied regardless,
It should have been bracketed with atk-bridge as in
| Code: | diff -u /usr/portage/x11-libs/gtk+/gtk+-3.22.19.ebuild .
--- /usr/portage/x11-libs/gtk+/gtk+-3.22.19.ebuild 2018-05-21 20:39:19.000000000 -0500
+++ ./gtk+-3.22.19.ebuild 2018-07-27 11:03:47.432210728 -0500
@@ -11,7 +11,7 @@
LICENSE="LGPL-2+"
SLOT="3"
-IUSE="aqua broadway cloudprint colord cups examples +introspection test vim-syntax wayland +X xinerama"
+IUSE="aqua atk-bridge broadway cloudprint colord cups examples +introspection test vim-syntax wayland +X xinerama"
REQUIRED_USE="
|| ( aqua wayland X )
xinerama? ( X )
@@ -48,7 +48,7 @@
>=x11-libs/libxkbcommon-0.2[${MULTILIB_USEDEP}]
)
X? (
- >=app-accessibility/at-spi2-atk-2.5.3[${MULTILIB_USEDEP}]
+ atk-bridge? ( >=app-accessibility/at-spi2-atk-2.5.3[${MULTILIB_USEDEP}] )
x11-libs/libX11[${MULTILIB_USEDEP}]
>=x11-libs/libXi-1.3[${MULTILIB_USEDEP}]
x11-libs/libXext[${MULTILIB_USEDEP}]
@@ -120,6 +120,11 @@
# gtk-update-icon-cache is installed by dev-util/gtk-update-icon-cache
eapply "${FILESDIR}"/${PN}-3.22.2-update-icon-cache.patch
+ # get rid of gtk3-atk-bridge crap
+ if ! use atk-bridge; then
+ eapply "${FILESDIR}"/${PN}-3.22.19.atk-bridge.patch
+ fi
+
eautoreconf
gnome2_src_prepare
}
@@ -143,6 +148,7 @@
$(use_enable X xkb) \
$(use_enable X xrandr) \
$(use_enable xinerama) \
+ $(use_with atk-bridge) \
--disable-papi \
--disable-mir-backend \
--enable-man \ |
I believe the if ! use is correct.
Now lets move on to other things because neither gentoo devs nor upstream will allow this other than in an overlay. 
Edit to add: I would love to see it added ... but ... I don't believe in trying to fight hopeless battles
Why do I say hopeless ... from metadata.xml
<maintainer type="project">
<email>gnome@gentoo.org</email>
<name>Gentoo GNOME Desktop</name>
</maintainer>
It's gnome ... nuff said
Now I know it was originally Gimp Tool Kit but since somewhere about the mid gtk+2 into gtk+3 it might as well be known as Gnome Tool Kit
SO just put it in your local portage and go from there.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Jul 27, 2018 5:09 pm Post subject: |
|
|
| Naib wrote: | | you haven't dealt with anything following DO178 have you |
Obviously running out of sane arguments you start personal attacks with unrelated things. If that standard would indeed forbid applying patches to a build system which obviously do nothing unless activated but accepts building a safety critical system with dbus, then something is very wrong with that standard.
Anyway, I am not interested in discussing an OT standard, so for me it is here EOD. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Jul 27, 2018 11:56 pm Post subject: |
|
|
In my opinion, unconditionally applying the patch and then conditionally enabling its functionality is the more maintainable choice. If the patch is conditionally applied, then users who elect not to use it will never notice if it one day ceases to apply due to upstream changes. This allows bitrot to go unnoticed. It is better for the community if the first person to test the new version is immediately notified that the patch no longer applies to the text of the new version. The patch may not get updated in a timely manner, but at least the maintainers will know about it quickly and know to either fix or disable it.
If the patch is conditionally applied, then any other patches that touch the same area become much more trouble to use because their applicability (at a text level, not a logical level) may depend on this patch. By always applying this patch, then conditionally enabling it, later patches can always assume it is present and therefore be simpler to implement. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sat Jul 28, 2018 12:30 am Post subject: |
|
|
| Hu wrote: | | In my opinion, unconditionally applying the patch and then conditionally enabling its functionality is the more maintainable choice. |
You're correct on that. With the patch applied then turning it on and off would be like the test or examples flag
Well thought out response, Hu. kudos
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Jul 28, 2018 8:30 am Post subject: |
|
|
| Hu wrote: | In my opinion, unconditionally applying the patch and then conditionally enabling its functionality is the more maintainable choice. If the patch is conditionally applied, then users who elect not to use it will never notice if it one day ceases to apply due to upstream changes. This allows bitrot to go unnoticed. It is better for the community if the first person to test the new version is immediately notified that the patch no longer applies to the text of the new version. The patch may not get updated in a timely manner, but at least the maintainers will know about it quickly and know to either fix or disable it.
If the patch is conditionally applied, then any other patches that touch the same area become much more trouble to use because their applicability (at a text level, not a logical level) may depend on this patch. By always applying this patch, then conditionally enabling it, later patches can always assume it is present and therefore be simpler to implement. |
Ahh but then there is the scalability issue and that is why this generic concept being accepted by Gentoo (see the original request) would cause problems.
It's one thing to apply a patch to fix some build issue, especially when upstream has it, its another to accept end-user choice type patches. Group foo want X disabled,group bar want to add y, group bar wants optional z. And none of them are accepted by upstream
How can this be managed at distribution level. Upstream would not accept bugs as it is modified from their perspective (they would ask to reproduce with issued code or HEAD) Gentoo bugwrangers would reject due to the shear combinations (they already do that with GCC flags) so if upstream and Gentoo cannot support it, how can it being the tree?
If someone want to make their own overlay great, if someone wants to offer the patches great BUT the support then lies in the community
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
