[gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

A user asked for optional gtk3 support in www-client/chromium:


However, reading e.g.

says this:

> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
> forbidden

> package is an application with support for multiple gtk+, maintainer
> is free to select whatever slot he desires to support. It is strongly
> advised to use gtk+-3 if functionality is equivalent. This is to
> reduce workload of bugs being triggered with one slot but not the
> other.

What are your recommendations for the best course of action?

For stability and maintainability, I'd prefer www-client/chromium to use
the upstream defaults (gtk+-2 AFAIK) since it's most common, tested, and
supported configuration. If/when upstream moves to gtk+-3, we'd just follow.

I also understand we have users who are eager to run various
configurations, and expect Gentoo to be flexible and allow that. Would
masking a gtk3 USE flag for www-client/chromium be acceptable? Are there
any other solutions that might work?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Andrew Savchenko]

On Wed, 9 Sep 2015 00:24:55 -0700 Daniel Campbell wrote:
> > For stability and maintainability, I'd prefer www-client/chromium
> > to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> > tested, and supported configuration. If/when upstream moves to
> > gtk+-3, we'd just follow.
> > 
> > I also understand we have users who are eager to run various 
> > configurations, and expect Gentoo to be flexible and allow that.
> > Would masking a gtk3 USE flag for www-client/chromium be
> > acceptable? Are there any other solutions that might work?
> > 
> > Paweł
> > 
> x11-misc/spacefm supports multiple toolkits as well. I stay in line
> with GNOME suggestions by making gtk3 the default, but gtk2
> configurable via USE. Versioned USE flags are generally frowned upon,
> but I see no better way to support both a GTK3 default *and* allow for
> the GTK2 support. Part of the reason I came to Gentoo (and became a
> dev) is to support user choice, and personally as a maintainer that
> matters more than suggestions.
> 
> If the GNOME team has a solid recommendation for supporting both GTK2
> and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
> the user to set gtk2 is the best of both worlds imo.

The chromium upstream recommends gtk2, so it should be the default,
even if the GNOME team recommends gtk3.

Best regards,
Andrew Savchenko


pgpQkR30y3SMr.pgp
Description: PGP signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 12:20 AM, Paweł Hajdan, Jr. wrote:
> A user asked for optional gtk3 support in www-client/chromium: 
> 
> 
> However, reading e.g. 
> 
>
> 
says this:
> 
>> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is 
>> forbidden
> 
>> package is an application with support for multiple gtk+,
>> maintainer is free to select whatever slot he desires to support.
>> It is strongly advised to use gtk+-3 if functionality is
>> equivalent. This is to reduce workload of bugs being triggered
>> with one slot but not the other.
> 
> What are your recommendations for the best course of action?
> 
> For stability and maintainability, I'd prefer www-client/chromium
> to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> tested, and supported configuration. If/when upstream moves to
> gtk+-3, we'd just follow.
> 
> I also understand we have users who are eager to run various 
> configurations, and expect Gentoo to be flexible and allow that.
> Would masking a gtk3 USE flag for www-client/chromium be
> acceptable? Are there any other solutions that might work?
> 
> Paweł
> 
x11-misc/spacefm supports multiple toolkits as well. I stay in line
with GNOME suggestions by making gtk3 the default, but gtk2
configurable via USE. Versioned USE flags are generally frowned upon,
but I see no better way to support both a GTK3 default *and* allow for
the GTK2 support. Part of the reason I came to Gentoo (and became a
dev) is to support user choice, and personally as a maintainer that
matters more than suggestions.

If the GNOME team has a solid recommendation for supporting both GTK2
and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
the user to set gtk2 is the best of both worlds imo.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV797CAAoJEAEkDpRQOeFwcl4P+wUAQwjoVCdvEjELYxSpgHZS
I6xd+YOikyRuio68+UB1pBeJpFkZkblQ7DS6loK8eIQFSM+C3RQ1bM2Qa/iQ7he4
4X5NNDVMI8UgT568TsH0d6k/AuUxGuRlH6lrMKOdXZfrCen/pl0QLTtWkI+sOzh4
hAxDKoXf3CntmIrwCp2bsTDyU79uX+X2mQHnjz49U7FXYWc+WDPMaFK1dQzp59wD
vLnMFNoh27gVSWNwsYiy6yo7hL73vIF2ZQaiYnQDKR3nxOLvWLTsCY6JSfebSJiX
bv/dyUldcjK4vaEaES0+PYHVww7A3f13QbC3b3/8oTxAHfMZpYCWnskUN1hCx337
I+/LBR2KrSsoyLPNNfMuVk0t4h2TEQw2SHED4+ObQ2qQ4tc1SmdWPn3g//2e8cFU
Zl2fLxfrXiQxCUB5dByUXSzD1lPCo7BvespewoJ3g+YkeZpxfQ4iyt91otG8sooW
VNJF/+gqgBSGnJPZQBjx1n6bjx08B++pCoybvZGn2NUHvLpYe/rgA3oZyg0clZND
dEbkgXbbn3dJMbiaTzT7ou2Icv0T0F7+xHxq4IFvZ7NgthrNhmTFllWsgC0rpM3/
RLwjFfaekap1utGew5W3+77xyKIxDIeBFGQm0pP7KgQDHn+M6Cs5+r64vljDXsWp
0MYg19z2jBdxbCpaMxET
=Q16B
-END PGP SIGNATURE-

[gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation? (was: www-client/chromium gtk3 support)

[Duncan]

Paweł Hajdan, Jr. posted on Wed, 09 Sep 2015 09:20:13 +0200 as excerpted:

> A user asked for optional gtk3 support in www-client/chromium:
> 

Talking about browsers and gtk3, I read that binary distros are starting 
to ship firefox built against gtk3, now.

And with that happened, they'll likely be eager to deprecate gtk2, as I 
think firefox was the big hold-out making that impractical.

Which means gentoo will likely eventually follow, since gtk2 viability 
will be dropping at that point.

So what's the gentoo gtk3 firefox status, and when it does go gtk3, how 
long can users expect their other gtk2 apps to continue to be supported, 
if upstream doesn't update to gtk3, due to inactivity or whatever reason?

While I'm at it, what about claws-mail, which I use but which is still 
gtk2 based?

And what about pan (nntp client), which I've been long-term involved with 
upstream on the mailing lists as a "guru user" and kept the list lights 
on when there was effectively no upstream dev, so I happen to know its 
gtk3 status fairly well -- the gtk3 port has long been done and some 
distros even ship it, but we continue to recommend gtk2 because we 
continue to get reports of various gtk3-based pan bugs that "magically" 
disappear when people rebuild with gtk2, that have never been traced much 
further than that, because the recommendation continues to be gtk2 (yes, 
circular reasoning, but...).

And for as long as I've been running pan, nearing a decade and a half 
now, development has always been sporadic, as I said even lacking an 
upstream dev at all, for a few years.  A couple years ago Heinrich 
Mueller adopted it and did a lot of work, adding some features that had 
been on the request list for years, but while he (and Petr Kovar, the 
Gnome rep and website maintainer, but a l10n guy not a dev) still do 
patches, he hasn't done much more than that for a couple years.  So 
realistically, upstream isn't going to be very active in getting those 
gtk3 bugs traced and patched, tho patches will probably be applied if 
distro maintainers develop and submit them.

For the desktop I tend to be more a kde guy (tho I'm not sure I will 
still be with the frameworks5/plasma5 upgrade...), but on these apps, and 
particularly on pan, since I /am/ involved with upstream there, I'm 
concerned about gtk, but am not close enough to the gentoo/gtk team to 
know the status there, thus the questions.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 09:24 AM, Daniel Campbell wrote:
> 
> x11-misc/spacefm supports multiple toolkits as well. 

It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
removed to be consistent with the rest of the tree.

[gentoo-dev] news item: libvirt-1.2.19 init script upgrades

[Doug Goldstein]

The following is the proposed news item to inform OpenRC users of a
change to the init script setup for libvirt 1.2.19 and newer.

-- 
Doug Goldstein
Title: libvirt-1.2.19 init script changes
Author: Doug Goldstein 
Content-Type: text/plain
Posted: 2015-09-09
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: 

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Brian Dolbec]

On Wed, 9 Sep 2015 12:37:49 +0200
hasufell  wrote:

> On 09/09/2015 09:24 AM, Daniel Campbell wrote:
> > 
> > x11-misc/spacefm supports multiple toolkits as well. 
> 
> It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
> removed to be consistent with the rest of the tree.
> 

to hell with stable, IMHO gtk3 is just crap and nearly destroys all
usability,  I have mostly gtk2, with some gtk3, and I'd love to nuke
the rest of the gtk3 ones...  So, if chromium goes gtk3, I'll be
looking for a new browser.  and if gentoo drops gtk2, I'll be looking
for a new DE...

-- 
Brian Dolbec 

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 09:20 +0200, Paweł Hajdan, Jr. wrote:

In chromium's case (a new gtk3-based ui that needs wider testing), a
local gtk3 USE flag does make sense.

But in general, the gnome team recommends avoiding the gtk3 flag
whenever possible. We definitely don't want it to become a global flag.
We are trying to avoid the following scenario:

(1) Dozens of ebuilds add gtk3 USE flag, and the semantics of the gtk3
flag differ wildly in those ebuilds:
  (a) build an optional gui that happens to be based on gtk3 (instead
  of no gui at all);
  (b) build experimental gtk3-based gui (instead of stable gtk2 gui as
  recommended by upstream);
  (c) build recommended gtk3-based gui (instead of legacy gtk2-based
  gui which is not supported by upstream any more);
  (d) build widget library and utilities for gtk3 (possibly in parallel
  with gtk2 widgets and utilities);
  (e) build widget library and utilities for gtk3 (and disable gtk2
  widgets and utilities - without making any effort to allow both
  gtk2 and gtk3 support in parallel by splitting the package or
  renaming a few files).
(3) Since the flag is used all over the place, some users try to
globally enable or disable it, depending on their personal feelings
about Adwaita's tab shapes.
(4) Since the flag sometimes means "build a gui (instead of no gui at
all)" at some point it gets globally enabled in some profile.
(5) Users are forced to maintain giant lists of package.use entries to
get a usable desktop environment. Unhappiness reigns.

In other words, to avoid the scenario that happened during gtk1/gtk2
transition, and which is now starting with qt4/qt5 [1].

[1] 
https://archives.gentoo.org/gentoo-dev/message/11e3d077e0d9c953597c3d17f327c6b3



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Lars Wendler]

On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:

>On 9/1/15 3:24 PM, Lars Wendler wrote:
>> * samba upstream is extremely uncooperative. Best example is that we
>>   still have some automagic dependencies [5] in samba's build system
>> and upstream is not very keen on fixing these.
>> 
>> [...]
>>
>> [5] https://bugs.gentoo.org/489748
>> https://bugs.gentoo.org/489770
>
>I don't see any references to upstream bug reports, and so no evidence
>of upstream being uncooperative.
>
>Are there any public links that you could share?

Sorry, I forgot about the mails I sent to samba upstream [1]

Regards
Lars

>Paweł
>
>

[1]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpWBWYgd1bxc.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 03:17 PM, Brian Dolbec wrote:
> On Wed, 9 Sep 2015 12:37:49 +0200
> hasufell  wrote:
> 
>> On 09/09/2015 09:24 AM, Daniel Campbell wrote:
>>>
>>> x11-misc/spacefm supports multiple toolkits as well. 
>>
>> It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
>> removed to be consistent with the rest of the tree.
>>
> 
> to hell with stable, IMHO gtk3 is just crap and nearly destroys all
> usability,  I have mostly gtk2, with some gtk3, and I'd love to nuke
> the rest of the gtk3 ones...  So, if chromium goes gtk3, I'll be
> looking for a new browser.  and if gentoo drops gtk2, I'll be looking
> for a new DE...
> 


I haven't encountered a gtk app (I develop some myself) that has dropped
significant features in the process of migration to gtk3, but I
obviously don't use all of them.

IMO, there's pretty much no difference for the user, except that the
codepaths are better maintained.

You can have the exact same usability with gtk3 as with gtk2. That's
developer choice, not toolkit related. When upstream developers drop
features or even toolkit support, you don't want to ship legacy code to
the user.

So this is just a transition period anyway and we shouldn't confuse our
users with temporary USE flags that break consistency, unless that's
absolutely necessary.

Again: usability is not predefined in the toolkit. This is not about gnome3.

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Lars Wendler]

Hey all,

seems like I need to correct one of my previous said statements.
Please see below:

On Tue, 1 Sep 2015 15:24:05 +0200 Lars Wendler wrote:

>Hey community,
>
>for a way too long time Gentoo's samba packages lack the attention they
>would require to keep them top notch and as useful as possible for our
>users.
>
>The reason I started to take minimum care of our samba packages was
>because my former employer used Gentoo on his Linux server (guess
>why? :D) and as there were also samba servers among them I had slight
>interest in Gentoo's samba packages to be at least up to date on
>a security point of view.
>After I started work for my new employer this interest lowered even
>more and all I am doing right now is simple version bumps on all samba
>(and related) packages nobody else seems to take care of.
>The situation in Gentoo became even worse when upstream discontinued
>the 3.6.x series which still is the only samba version in Gentoo that
>is multilib capable.
>Given this fact I decided to unmask samba-4.0 and samba-4.1 series
>although both still suffering from two major problems:
>
>* Until now all samba-4 packages are not multilib ready [1]
>
>* samba-4 packages require heimdal, a kerberos implementation that
>  unfortunately cannot be installed in parallel with mit-krb5 package
>  [2]

This seems to be no longer true. I've added samba-4.2.4-r1 with
"system-mitkrb5" USE flag to portage today.

>So here comes a really seriously meant call for help:
>Gyus, if you _are_ interested in samba then please try to invest time
>and knowledge so we can make Gentoo's samba packages better.
>
>To be honest there are some trip wires that make solutions to the two
>above mentioned problems (and possibly others) a bit difficult:
>
>* samba upstream is extremely uncooperative. Best example is that we
>  still have some automagic dependencies [5] in samba's build system
> and upstream is not very keen on fixing these.

And the upstream reference [6]

>* samba (and related) packages are using waf as build system. One of
>  the most ugliest build systems I ever had the bad luck to be involved
>  with.
>
>* To make samba-4 (and related) packages multilib ready, we might need
>  to make python multilib ready first. I'm not sure this requirement is
>  still necessary - we should ask mgorny about this :)
>
>* We should really get heimdal and mit-krb5 packages in a shape where
>  we can install them in parallel [2]. Using the bundled heimdal from
>  samba is no valid option [3]

See above. Should no longer be a pressing requirement. Of course it
would still be nice to have.

>* Stabilization of samba-4 still needs to go a long road [4]
>
>
>Once again, we need your help so please help. If you are willing to do
>so and have no commit access, well... I have and as long as the
>contributions from any volunteer meet the Gentoo standards I am more
>than happy to commit any improvements as proxy maintainer. If they
>don't meet the standards, I'm quite sure we can work those issues out
>together.
>
>
>Kind regards
>Lars
>
>
>[1] https://bugs.gentoo.org/534432
>[2] https://bugs.gentoo.org/490872
>https://bugs.gentoo.org/542462
>[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
>[4] https://bugs.gentoo.org/489762
>[5] https://bugs.gentoo.org/489748
>https://bugs.gentoo.org/489770
>
[6]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpbCrqntlReJ.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] www-client/chromium gtk3 support

[Mike Gilbert]

On Wed, Sep 9, 2015 at 3:20 AM, Paweł Hajdan, Jr.  wrote:
> A user asked for optional gtk3 support in www-client/chromium:
> 
>
> However, reading e.g.
> 
> says this:
>
>> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
>> forbidden
>
>> package is an application with support for multiple gtk+, maintainer
>> is free to select whatever slot he desires to support. It is strongly
>> advised to use gtk+-3 if functionality is equivalent. This is to
>> reduce workload of bugs being triggered with one slot but not the
>> other.
>
> What are your recommendations for the best course of action?
>
> For stability and maintainability, I'd prefer www-client/chromium to use
> the upstream defaults (gtk+-2 AFAIK) since it's most common, tested, and
> supported configuration. If/when upstream moves to gtk+-3, we'd just follow.
>
> I also understand we have users who are eager to run various
> configurations, and expect Gentoo to be flexible and allow that. Would
> masking a gtk3 USE flag for www-client/chromium be acceptable? Are there
> any other solutions that might work?

I would really like a way to toggle gtk3 for testing. If you don't
want to expose it as a 'supported' option for users, then masking it
sounds fine to me.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
> I would really like a way to toggle gtk3 for testing. If you don't
> want to expose it as a 'supported' option for users, then masking it
> sounds fine to me.

Then add the flag, document it in metadata.xml.

But in general, try to avoid using this flag in your ebuilds if
possible, the gnome team *really* doesn't want to turn gtk3 into a
global USE flag with uncertain semantics.

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Warner]

On Wed, Sep 9, 2015 at 8:10 AM, Alexandre Rostovtsev 
wrote:

> On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
> > I would really like a way to toggle gtk3 for testing. If you don't
> > want to expose it as a 'supported' option for users, then masking it
> > sounds fine to me.
>
> Then add the flag, document it in metadata.xml.
>
> But in general, try to avoid using this flag in your ebuilds if
> possible, the gnome team *really* doesn't want to turn gtk3 into a
> global USE flag with uncertain semantics.


The best way to avoid this IMHO is to not name the flag the same thing.

if you named the chromium flag "experimental-gtk3-ui' or similar, then
users would be unable to turn it on by just setting 'gtk3'

-A

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
> 
> app-editors/emacs
> app-editors/emacs-vcs
> app-editors/mousepad
> app-i18n/fcitx
> app-i18n/fcitx-configtool
> app-i18n/ibus
> app-i18n/ibus-unikey
> app-i18n/imsettings
> app-i18n/scim
> app-i18n/scim-anthy
> app-i18n/uim
> app-misc/emelfm2
> dev-libs/libdbusmenu
> dev-python/matplotlib
> dev-util/geany
> kde-plasma/plasma-desktop
> lxde-base/lxdm
> mail-client/claws-mail
> media-gfx/geeqie
> media-libs/libcanberra
> media-plugins/audacious-plugins
> media-sound/audacious
> media-sound/easytag
> media-sound/mp3splt-gtk
> net-analyzer/pinger
> net-dns/avahi
> net-libs/gtk-vnc
> net-misc/dhcpcd-ui
> net-misc/electrum
> net-misc/spice-gtk
> www-client/dwb
> www-client/uget
> www-client/uzbl
> www-client/vimb
> www-plugins/freshplayerplugin
> x11-drivers/nvidia-drivers
> x11-misc/light-locker
> x11-misc/spacefm
> x11-themes/light-themes
> xfce-base/libxfce4ui
> xfce-extra/xfce4-taskmanager
> 
> 

There was a tracker on bugzilla about it at some point, but people
didn't care enough, so I stopped filing bugs. Neither the gnome team nor
QA had a strong enough opinion to enforce consistency here over the
whole tree.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:48 AM, hasufell wrote:
> On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
>> 
>> [ Snip list ]
>> 
> 
> There was a tracker on bugzilla about it at some point, but
> people didn't care enough, so I stopped filing bugs. Neither the
> gnome team nor QA had a strong enough opinion to enforce
> consistency here over the whole tree.
> 


Right... So, back to the issue at hand.  If a package -always-
depends on a gtk (usually gtk2), but can optionally be configured to
depend on gtk3 instead (and it should be optional because support
isn't clearly stable yet), what's the solution here?

IUSE="gtk" isn't appropriate because that's meant for enabling
optional gtk support, not choosing -which- gtk to support when there
always needs to be one.  IUSE="gtk3" to me fits well in this case
but it's also reportedly forbidden...
IUSE="experimental-gtk3-support" seems less than optimal but if we
(chromium, mozilla teams) have to go that route I guess we will..

The wiki seems to say that we as rdep maintainers should choose one
and stick with it, but as a mozilla package maintainer, I don't want
to force the entire user base to using one or the other (at least
not yet), given firefox -just- got (that is, will get in two version
bumps) gtk3 support that's considered stable enough for use outside
of development.

I don't suppose we as a community can revisit the decision to ban
IUSE="gtk3" as a flag to toggle between gtk2 and gtk3 support, when
one or the other is -required- by a package?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwWuYACgkQAJxUfCtlWe25WwD/b8ozgV4zHLyNrIzYI+Cu79+l
gBORP+1q6EMUWyuyVewBAIE3nNFow+XeN67pH4pT6gqQqBJ27VH+bAt9nTprs0pi
=HWeR
-END PGP SIGNATURE-

[gentoo-dev] Last rites: app-portage/lightweight-cvs-toolkit

[Michał Górny]

# Michał Górny  (09 Sep 2015)
# Package to be used with gentoo-x86 CVS, so pretty much defunct now.
# Removal in 30 days. Bug #560056.
app-portage/lightweight-cvs-toolkit


-- 
Best regards,
Michał Górny



pgpRb9h_oiR7s.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 06:06 AM, Duncan wrote:
> Paweł Hajdan, Jr. posted on Wed, 09 Sep 2015 09:20:13 +0200 as
> excerpted:
> 
>> A user asked for optional gtk3 support in www-client/chromium: 
>> 
> 
> Talking about browsers and gtk3, I read that binary distros are
> starting to ship firefox built against gtk3, now.
> 
> And with that happened, they'll likely be eager to deprecate
> gtk2, as I think firefox was the big hold-out making that
> impractical.


Firefox's use of gtk3 actually still requires gtk2, so gtk2 won't be
deprecated (at least not any time soon).

Also, FYI, since gtk2 will (for the forseeable future) always be
required by the firefox core, we are going to add a gtk3 flag to
provide end-user control of building the frontend against gtk3 or not.

I don't think deprecation of gtk2 is anything we are going to need
to worry about any time soon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwUQcACgkQAJxUfCtlWe1r4QEAwJ4VQLTQhHe9Mx6DocDtkk0k
TXYlocHSXPqrb907jx8BANABAaCToAOPnKchenrMLJxQFh0euC1Ku0ki8H9TwJtu
=p0Fr
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:16 AM, Alec Warner wrote:
> 
> 
> On Wed, Sep 9, 2015 at 8:10 AM, Alexandre Rostovtsev 
> > wrote:
> 
> On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
>> I would really like a way to toggle gtk3 for testing. If you
>> don't want to expose it as a 'supported' option for users, then
>> masking it sounds fine to me.
> 
> Then add the flag, document it in metadata.xml.
> 
> But in general, try to avoid using this flag in your ebuilds if 
> possible, the gnome team *really* doesn't want to turn gtk3 into
> a global USE flag with uncertain semantics.
> 
> 
> The best way to avoid this IMHO is to not name the flag the same
> thing.
> 
> if you named the chromium flag "experimental-gtk3-ui' or similar,
> then users would be unable to turn it on by just setting 'gtk3'
> 

Is it worth noting that there are dozens of packages in the tree
right now that have a gtk3 flag in IUSE?  Many have 'gtk gtk3'
combinations, and many others have 'gtk3' entirely on their own:

app-editors/emacs
app-editors/emacs-vcs
app-editors/mousepad
app-i18n/fcitx
app-i18n/fcitx-configtool
app-i18n/ibus
app-i18n/ibus-unikey
app-i18n/imsettings
app-i18n/scim
app-i18n/scim-anthy
app-i18n/uim
app-misc/emelfm2
dev-libs/libdbusmenu
dev-python/matplotlib
dev-util/geany
kde-plasma/plasma-desktop
lxde-base/lxdm
mail-client/claws-mail
media-gfx/geeqie
media-libs/libcanberra
media-plugins/audacious-plugins
media-sound/audacious
media-sound/easytag
media-sound/mp3splt-gtk
net-analyzer/pinger
net-dns/avahi
net-libs/gtk-vnc
net-misc/dhcpcd-ui
net-misc/electrum
net-misc/spice-gtk
www-client/dwb
www-client/uget
www-client/uzbl
www-client/vimb
www-plugins/freshplayerplugin
x11-drivers/nvidia-drivers
x11-misc/light-locker
x11-misc/spacefm
x11-themes/light-themes
xfce-base/libxfce4ui
xfce-extra/xfce4-taskmanager

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwUvcACgkQAJxUfCtlWe3oBgEAvr7nBfDygUPG4MGiK23ya3Xn
RRWLOkprA6SuFjbef84BAJehMtEtt+ZqC3HzGJ5yroM+yCqQE855uQz7+2mpGeyC
=LOpM
-END PGP SIGNATURE-

[gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation? (was: www-client/chromium gtk3 support)

[»Q«]

On Wed, 9 Sep 2015 10:06:30 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> So what's the gentoo gtk3 firefox status, 

Ian or someone can probably give more info, but there are builds in the
mozilla overlay which use gtk3.

> While I'm at it, what about claws-mail, which I use but which is
> still gtk2 based?

I haven't seen any interest from Claws devs to transition to gtk3, but
someone's just cited your post in the bug for it,
.

[gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation?

[Duncan]

Ian Stakenvicius posted on Wed, 09 Sep 2015 11:32:23 -0400 as excerpted:

> Firefox's use of gtk3 actually still requires gtk2, so gtk2 won't be
> deprecated (at least not any time soon).

I was entirely unaware of that.  Thanks.  It changes the picture 
dramatically.

> Also, FYI, since gtk2 will (for the forseeable future) always be
> required by the firefox core, we are going to add a gtk3 flag to provide
> end-user control of building the frontend against gtk3 or not.
> 
> I don't think deprecation of gtk2 is anything we are going to need to
> worry about any time soon.

Thanks.  As I said, firefox-core still requiring gtk2 changes the picture 
dramatically, both for gentoo, and as part of pan upstream, for it as 
well.

FWIW, there's still some of us that remember the gtk1 based xmms with 
fondness for its clean just-what-we-need interface and lack of extraneous 
deps, while at the same time providing fancy visualization, etc.  
Similarly, there's still those trying to use the kde-sunset overlay for a 
kde3 app or two.  Personally, I try to be on the (moderately) leading 
edge rather than the trailing and was well off of both of these before 
they disappeared from the tree, but that's why I'm asking these sorts of 
questions (and why I follow this list, as well), giving me as long as 
possible to prepare and try to find suitable replacements before I'm 
under the gun.

As for pan upstream, I'm on record on the pan lists as saying that until 
firefox switches to gtk3, there's not a lot to worry about regarding gtk2, 
since firefox really is the big gtk2 elephant in the room and practically 
speaking, gtk2 isn't going anywhere until firefox does, either by 
switching to something else, or by becoming irrelevant.

With mentions of gtk3 based firefox now in distros and that being my 
trigger of record, I was starting to worry about pan on gtk3.  But if 
firefox still requires gtk2 at its core, the trigger doesn't look to have 
actually been pulled, after all.  That really /does/ change the picture, 
so...

Thanks again! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [warning] the bug queue has 83 bugs

[Matt Turner]

On Wed, Sep 9, 2015 at 2:00 PM, Alex Alexander  wrote:
> Our bug queue has 83 bugs!
>
> If you have some spare time, please help assign/sort a few bugs.
>
> To view the bug queue, click here: http://bit.ly/m8PQS5

I suspect you used bit.ly to shorten a long bugzilla link, but it
doesn't need to be super long:

https://bugs.gentoo.org/buglist.cgi?email1=bug-wranglers%40gentoo.org_to1=1=---

[gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation? (was: www-client/chromium gtk3 support)

[Duncan]

»Q« posted on Wed, 09 Sep 2015 10:12:50 -0500 as excerpted:

> I haven't seen any interest from Claws devs to transition to gtk3, but
> someone's just cited your post in the bug for it,
> .

Thanks.  I've always thought I might at least register with claws' 
bugzilla, to CC and track things like this, but never have.

(It'd be nice, sometimes, if every bugzilla instance, let alone other bug 
trackers, wasn't a kingdom unto itself, requiring separate registration.  
Tho of course centralized has its own problems, including tracking and 
privacy implications.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Paweł Hajdan , Jr .]

On 9/9/15 4:00 PM, Lars Wendler wrote:
> On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:
>> I don't see any references to upstream bug reports, and so no evidence
>> of upstream being uncooperative.
>>
>> Are there any public links that you could share?
> 
> Sorry, I forgot about the mails I sent to samba upstream [1]
> 
> [1]
> http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

I see. I'm not sure if I'm interpreting this correctly without more
context. These are my reactions to above thread:

1. All people who replied are listed on
 . To me this means it's indeed
"official" upstream response.

2. Upstream is indeed initially confused.

3. After reading the reference to
,
they point to "--with{out,}-pam, --with{out,}-aio-support and
--with{out,}-attr" flags. Notably, dmapi is not mentioned.

4. At that point I'd expect a reply from you Lars, that since they have
flags for other libraries but not dmapi (or the dmapi ones don't work -
and provide steps to repro), why wouldn't they take the patch.

5. In fact,  from your
original post links to upstream
 with a slightly
different patch that apparently has been landed.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [warning] the bug queue has 83 bugs

[Alex Alexander]

Our bug queue has 83 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 06:14 PM, Ian Stakenvicius wrote:
> 
> 
> Right... So, back to the issue at hand.  If a package -always-
> depends on a gtk (usually gtk2), but can optionally be configured to
> depend on gtk3 instead (and it should be optional because support
> isn't clearly stable yet), what's the solution here?
> 

Provide the gtk3 version in an overlay (without gtk3 USE flag), because
that's where experimental stuff belongs. If people want to test it, they
can do it an we don't have to use ugly stuff like package.use.stable.mask.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

On 9/9/15 5:48 PM, hasufell wrote:
> There was a tracker on bugzilla about it at some point, but people 
> didn't care enough, so I stopped filing bugs. Neither the gnome team
> nor QA had a strong enough opinion to enforce consistency here over
> the whole tree.

Looks like that was  .

I'm not sure whether the underlying issue was enforcement, or just
handling various use cases.

Similar situation with qt/qt4/qt5 seems to confirm to me that it's not
whims that make people not follow the policy, but real needs and use cases.

Quotes from above bug:

> You really have not addressed all the situations here.

> Yes I know there may be situations where the proposed solutions are
> not sufficient.

Also, most blocking bugs seem to be resolved as WONTFIX/WORKSFORME/INVALID.

FWIW I do care. For now responses on this thread seem to recommend (or
be at least OK with) adding gtk3 USE flag to www-client/chromium . If
there's an alternative solution endorsed by GNOME or QA team that would
make progress on 
possible, I'd just switch to that solution.

Paweł



signature.asc
Description: OpenPGP digital signature