Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
State of the Union
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Sat Jul 28, 2018 10:33 am    Post subject: Reply with quote

Getting the gentoo devs to accept it IS the real problem and why I don't even try.

I went looking to see if maybe it had been mentioned in the bug repository and ran across a report where someone was reporting that updating gtk-2 with the latest adwaita icon system pulled in gtk-3 (only for the build, and golly gee, you also get at-spi2 and dbus thrown in for free, what a deal :roll: ).
And the response from one of the devs was that basically people are retarded to just not accept gtk-3 on their system (rephrasing by me, but the intent was clear)
This is a dev, mind you.
ETA: from this bug report https://bugs.gentoo.org/645008
ETA2: perhaps "retarded" is the wrong word, but geez, gentoo is about choice or at least supposed to be.

It's all good and well to say just accept the defaults, but then why the hell am I running gentoo, supposedly based on choice, if I just pull in everything because some devs think I should, I might as well just run redhat in the first place. One can always download source from RH.

Choice is more than about just setting a compile flag or two or deciding which module to build for the kernel.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
njsg
Tux's lil' helper
Tux's lil' helper


Joined: 17 Dec 2005
Posts: 86

PostPosted: Sat Jul 28, 2018 2:31 pm    Post subject: Reply with quote

I'd say it's reasonable to start giving up after seeing bug 645008 comment 4. It is a situation that could have been perhaps avoided. While there are times when decisions must be made, in light of that comment this might appear to be a move biased against those who do not want gtk+3 on their systems.

Adwaita-icon-theme might be a can of worms by itself. I have found this to override the X11 default set of cursors... this appears to be bug 543488. Comment 1 is also not very heartwarming when it ignores the report and instead states that upstream "wants the theme to be available". Furthermore, the bug was marked fixed, but it wasn't fixed, at least the last time I checked.

What appear to be proper solutions are mentioned in comment 20 (option b), perhaps?), but none of this was done or even discussed in this bug report.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12711

PostPosted: Sat Jul 28, 2018 3:39 pm    Post subject: Reply with quote

Naib wrote:
Ahh but then there is the scalability issue ...
Yes, that is a real concern. For the reasons you outlined, it's not always appropriate to add such patches to the main tree. However, I still believe that, wherever the patch is made available, it ought to be done in the way I described above, specifically because it avoids the combinatorial growth problem by defining that all the customization patches have a specific order of application and that, barring changes upstream, they can all be applied in that order. Generally, it's better if upstream does take the patch, both for the benefit of non-Gentoo users and as a way of reducing the patch management burden on the Gentoo maintainers. When that doesn't happen, and the patch isn't critical, it's sometimes necessary for it to live in an overlay.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Sat Jul 28, 2018 3:46 pm    Post subject: Reply with quote

If someone has an existing overlay and they want to add the patches (for gtk+3 without at-spi2*) be my guest.
I make no claim to any of it, it was all found by searching and C&P'ing from old sources.

I find it useful for me, so I keep it in my local portage directory.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12711

PostPosted: Sat Jul 28, 2018 4:33 pm    Post subject: Reply with quote

I never cared quite enough to hack it out, but when I saw how simple the patch was, I added it to my local overlay too. Thanks for digging it out. I expected it would be a substantial amount of work to eliminate that dependency.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5433
Location: Removed by Neddy

PostPosted: Sat Jul 28, 2018 4:48 pm    Post subject: Reply with quote

Hu wrote:
Naib wrote:
Ahh but then there is the scalability issue ...
Yes, that is a real concern. For the reasons you outlined, it's not always appropriate to add such patches to the main tree. However, I still believe that, wherever the patch is made available, it ought to be done in the way I described above, specifically because it avoids the combinatorial growth problem by defining that all the customization patches have a specific order of application and that, barring changes upstream, they can all be applied in that order. Generally, it's better if upstream does take the patch, both for the benefit of non-Gentoo users and as a way of reducing the patch management burden on the Gentoo maintainers. When that doesn't happen, and the patch isn't critical, it's sometimes necessary for it to live in an overlay.
that is true, but in patching you do cut support off.
Patching and the disabling as you advocate does depend on patches being applied in succession... One patch may change enough such that the following patch can't resolve where to apply. Again this is a scalability issue. Both bulk apply or USE apply for many patches have this issue so a bulk patch does make sense as it can be adapted for all applicable patches

Ultimately such things are better dealt with upstream. In this instance, how open are upsteam with regards to such patches, especially as it can from "upstream". This sort from thing should be a configurable anyway, especially for a UI toolkit
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
njsg
Tux's lil' helper
Tux's lil' helper


Joined: 17 Dec 2005
Posts: 86

PostPosted: Sat Jul 28, 2018 5:32 pm    Post subject: Reply with quote

I recall seeing this a long time ago, but I don't remember whether I've actually tried it: setting NO_AT_BRIDGE=1.

Now, if it is not going to be used at all, it is better to just not build it and pull in less dependencies. Especially given that this requires dbus, and will pull dbus on an otherwise dbus-less system.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5164

PostPosted: Sat Jul 28, 2018 11:34 pm    Post subject: Reply with quote

Anon-E-moose wrote:
If someone has an existing overlay and they want to add the patches (for gtk+3 without at-spi2*) be my guest.
I make no claim to any of it, it was all found by searching and C&P'ing from old sources.

I find it useful for me, so I keep it in my local portage directory.

As of now it's (3.22.30-r1) in two overlays, both reachable for everyone via layman/eselect-overlay:
Code:
 ~ $ eix -Re gtk+ | perl -nE 'say $1 if m/^(\[\d\] "\S+")/; if ( /^\s+\(3\)/ ) { print for m/\s\S+\[\d\]/g; say "" }'
 3.22.15^t[3] 3.22.15^t[4] 3.22.16^t[3] 3.22.16^t[4] (~)3.22.17^t[3] (~)3.22.17^t[4] (~)3.22.19^t[3] (~)3.22.19^t[4] [m]3.22.19^t[8] (~)3.22.21^t[3] [m](~)3.22.26^t[8] (~)3.22.28^t[6] (~)3.22.28^t[9] (~)3.22.30-r1^t[1] [m](~)3.22.30-r1^t[2] (~)3.91.2^t[3] **9999[5]
[1] "flussence"
[2] "mv"
[3] "chrisadr"
[4] "elementary"
[5] "gnome"
[6] "gnome-next"
[7] "gsview-overlay"
[8] "mv"
[9] "pg_overlay"
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2225
Location: Bardowick, Germany

PostPosted: Mon Jul 30, 2018 10:20 am    Post subject: Reply with quote

Anon-E-moose wrote:
If someone has an existing overlay and they want to add the patches (for gtk+3 without at-spi2*) be my guest.
I make no claim to any of it, it was all found by searching and C&P'ing from old sources.

I find it useful for me, so I keep it in my local portage directory.
You could just open a bug with your patches and send me the link. I'll add them to my overlay (seden via layman) for wider testing and comment on that bug.

Maybe we'll get some attention. If not, then at least some wider testing.

As for the argument about the patching of the build system to get additional options: That was the only way most upstreams would accept patches from me for their projects to enable elogind support. And yes, it is the cleanest way.
If you patch support into or out from a project, always make it opt-in (or opt-out on removals). The defaults must not be changed, or you have no chance to get your patches further then some bug reports. No upstream in this universe will accept a patch that changes their defaults just because you think you know better then them. I learned that the hard way.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Mon Jul 30, 2018 11:55 am    Post subject: Reply with quote

The ebuild probably needs logic to see that if gnome USE flag is set (globally) then atk-bridge USE flag would be also set to on.
I think it can be done without the ebuild needing a gnome flag itself. (comments on this?)

That might get it to pass the muster by gnome gentoo devs.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6184

PostPosted: Mon Jul 30, 2018 1:04 pm    Post subject: Reply with quote

Anon-E-moose wrote:
The ebuild probably needs logic to see that if gnome USE flag is set (globally) then atk-bridge USE flag would be also set to on.

This makes sense only if one would define atk-bridge support to be the same as gnome support. In the latter case, atk-bridge should be renamed to gnome.
Quote:
I think it can be done without the ebuild needing a gnome flag itself.

No. Accessing a USE-flag not specified in IUSE is an error. At least repoman, but probably also portage would complain.
Quote:
That might get it to pass the muster by gnome gentoo devs.

If I were in the gentoo gnome team, my main objection would be that maintaining an non-upstream patch is always dangerous and possibly involved with a lot of work I might not be interested in: Already in the next gtk-version it might happen that the patch is incompatible, and nobody updates it (maybe it is even hard to update): Then suddenly I would be responsible for the work (or I might be blamed by the people who now relied on the patch).
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Mon Jul 30, 2018 1:19 pm    Post subject: Reply with quote

mv wrote:
Anon-E-moose wrote:
The ebuild probably needs logic to see that if gnome USE flag is set (globally) then atk-bridge USE flag would be also set to on.

This makes sense only if one would define atk-bridge support to be the same as gnome support. In the latter case, atk-bridge should be renamed to gnome.

My thinking is that it might have been removed from upstream gtk+ because they do require it in gnome. (just a guess on my part) and thus the need for gnome to require ati-bridge but not kde or anyone else using gtk3 but not needing accessibility stuff.

Quote:
Quote:
I think it can be done without the ebuild needing a gnome flag itself.

No. Accessing a USE-flag not specified in IUSE is an error. At least repoman, but probably also portage would complain.

Then a warning if see gnome USE flag, that atk-bridge IS required. I've seen that done plenty of times.

Quote:
Quote:
That might get it to pass the muster by gnome gentoo devs.

If I were in the gentoo gnome team, my main objection would be that maintaining an non-upstream patch is always dangerous and possibly involved with a lot of work I might not be interested in: Already in the next gtk-version it might happen that the patch is incompatible, and nobody updates it (maybe it is even hard to update): Then suddenly I would be responsible for the work (or I might be blamed by the people who now relied on the patch).

As I've pointed out it was in gentoo, once upon a time, but I have no idea why it was removed.
I get your point about a patch and updating, but that applies to any patches done by gentoo.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6184

PostPosted: Mon Jul 30, 2018 5:56 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Then a warning if see gnome USE flag, that atk-bridge IS required.

No matter how you access the gnome USE flag - whether with "use gnome" (to check whether to print the warning) or in REQUIRED_USE - this is only admissible if gnome is in IUSE.
Back to top
View user's profile Send private message
njsg
Tux's lil' helper
Tux's lil' helper


Joined: 17 Dec 2005
Posts: 86

PostPosted: Mon Jul 30, 2018 7:56 pm    Post subject: Reply with quote

Yamakuzure wrote:
You could just open a bug with your patches and send me the link. I'll add them to my overlay (seden via layman) for wider testing and comment on that bug.

Maybe we'll get some attention. If not, then at least some wider testing.


I would like to see this happen, it is probably the best way to try to get it included in the main tree.

If you do that, please mention the bug number here.
Back to top
View user's profile Send private message
njsg
Tux's lil' helper
Tux's lil' helper


Joined: 17 Dec 2005
Posts: 86

PostPosted: Mon Jul 30, 2018 8:00 pm    Post subject: Reply with quote

Anon-E-moose wrote:

Quote:
Quote:
I think it can be done without the ebuild needing a gnome flag itself.

No. Accessing a USE-flag not specified in IUSE is an error. At least repoman, but probably also portage would complain.

Then a warning if see gnome USE flag, that atk-bridge IS required. I've seen that done plenty of times.

If a warning message of some sort is required, maybe just write an ewarn message if the USE flag is disabled, stating that gtk+3 is being built without accessibility features?

Should the use flag be accessibility, instead of atk-bridge?

In fact, the description of USE=accessibility does mention at-spi.

A better place for the warning might be in gnome ebuilds that have a problem with this. If it is simply required for gnome, print no message and depend on the USE flag being set in gtk+:3. If it is not required, print a message saying "gtk+ is built with USE=-accessibility, accessibility features X, Y and Z might/will not work".
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Mon Jul 30, 2018 8:17 pm    Post subject: Reply with quote

mv wrote:
Anon-E-moose wrote:
Then a warning if see gnome USE flag, that atk-bridge IS required.

No matter how you access the gnome USE flag - whether with "use gnome" (to check whether to print the warning) or in REQUIRED_USE - this is only admissible if gnome is in IUSE.


This is why I mention things like this, I assumed that the global USE flag would suffice. Live and learn.

Thanks
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3190
Location: Dallas area

PostPosted: Mon Jul 30, 2018 9:10 pm    Post subject: Reply with quote

I was curious as to what the future of gtk+ was, so I googled and ran across a gtk+ BOF talk from earlier this month.
They had originally wanted 3.22 to be the last 3.x release, but with 4 taking it's sweet time, they decided to release up through 3.24.
They had a link to the proposed 3.23 candidate gtk+-3.23.0 and I downloaded and ran the patch against it, just to see if it would work, it did with a slightly larger fuzz factor on configure.ac portion of the patch than when I tried it with 3.22.30, the other two were still perfectly on target.

I notice that the original patches for were split into 3 instead of the way I've combined them into one.
My thoughts when I combined them were that since they were all for the same thing, ie atk-bridge (at-spi2) that they should be together.
Are the devs more or less likely to accept them if all together or separate?
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 4.9.4 & 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6814

PostPosted: Tue Jul 31, 2018 12:08 am    Post subject: Reply with quote

If the purpose of the 3 patches are toward same goal, one patch is ok.
But you had to make sure the 3 patches are done only to reach that goal (removing at-spi2), if any of them do something else (fixing a bug or whatever), they won't like a one patch, because you could have case where patch#1 & #2 are refuse and #3 accept.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5164

PostPosted: Tue Jul 31, 2018 12:18 am    Post subject: Reply with quote

The goal of the patch isn't to remove at-spi2, it's to repair the existing configure option in gtk+3 to remove at-spi2.

While it should be indefensible to argue for keeping buggy build systems buggy, I've seen gtk3 people (inside and outside gentoo) do so before.
Back to top
View user's profile Send private message
TigerJr
Guru
Guru


Joined: 19 Jun 2007
Posts: 447
Location: /dev/x0

PostPosted: Fri Aug 03, 2018 12:28 pm    Post subject: Reply with quote

BlaBla Bla

Let's see, only first page of thread about a real problems, 3 pages about one problem plus offtopic holywar Gentoo Conservatism vs Gentoo Progress, like Gnome herds.

And no body write real solution, let's see, but i will try))


Quote:

Portage would grow infinite!!


Old ebuilds and new ebuilds are needed, especialy for those who wants upgrade or downgrade on the fly, but dependensies and size of portage... thats the problem those portage can't solve

PS

And YES SystemD is rudimentary idea that loose herself on the start of the project and now used by distributors for selfish interests.
_________________

Do not update portage without hotdog!

Xenogentooway?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
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