lib32-libxft-lcd should be included in multilib

TemplarGR · 2010-09-27 10:37:46

Since libxft, libxft-lcd, and lib32-libxft are already included in official repos, i believe this:

http://aur.archlinux.org/packages.php?ID=22091

should be included as well.

.:B:. · 2010-09-27 11:07:29

The one-stop shop is located at:

http://bugs.archlinux.org

Edit: my bad, seems like [multilib] doesn't work that way!

Allan · 2010-09-27 11:11:25

Yeah... a bug is not going to get it there either. The people in charge of the repos put what they feel like there. If you want that package in a repo, apply to be a TU and put it there.

wonder · 2010-09-27 11:11:40

i vote for dropping libxft-lcd

litemotiv · 2010-09-27 12:03:14

wonder wrote:

i vote for dropping libxft-lcd

Why's that?

wonder · 2010-09-27 12:37:25

because that kind of patching is against our philosophy

TemplarGR · 2010-09-27 14:25:16

Allan wrote:

Yeah... a bug is not going to get it there either. The people in charge of the repos put what they feel like there. If you want that package in a repo, apply to be a TU and put it there.

Well... i had the feeling that to become a TU is a complicated and time consuming procedure, and time is not what i have in abundance. All i wanted was to suggest that since libxft-lcd AND lib32-libxft are provided, it should be really easy for the same maintener(s) to provide one more, which is already available in AUR anyway...

And your reply was "hey beg us to become a TU to put it there...". This is really dissapointing.

If you do not want to bother with this request then this is fine, most of us use the AUR package anyway, i just made a suggestion.

TemplarGR · 2010-09-27 14:35:34

wonder wrote:

because that kind of patching is against our philosophy

I do not get this, what is your philosophy? And before you copy here the known link, just explain why this specific package violates that philosophy...

Cairo-lcd (also in AUR) provided a similar patch to be used together with libxft-lcd, and since cairo 1.10 this patch is included upstream. Why not dropping cairo altogether now since it "violates your philosophy"?

Libxft-lcd is a really useful package, and it doesn't violate the "only vanilla" or the "simple" philosophy at all.

It is 2010 and i do not understand why a modern linux distro wouldn't properly support LCD font rendering in its official repos. Most if not all Arch users would want this...

In my opinion, since cairo 1.10 includes the lcd patch, and libxft-lcd(except the lib32-libxft-lcd) is also included in your repos, you should bring fontconfig-lcd from AUR too and provide smooth font rendering on LCD screens without the need of external packages.

wonder · 2010-09-27 14:50:19

@TemplarGR you are now officially trolling

1)our philosophy is to not patch packages to add _extra_ functionality like this -lcd patches do.
2)cairo has that feature because UPSTREAM decided to include it and therefor doesn't violate 1)
3) in 2010 if you really care about this, you can bug upstream instead of us. then you will find out that there is a good reason they are not including it.

litemotiv · 2010-09-27 15:48:01

wonder wrote:

you will find out that there is a good reason they are not including it.

You mean the avoidance of possible Cleartype patent infringements, or something else? Please provide links to background information if you have any, i have been looking but it seems very scattered.

TemplarGR · 2010-09-28 06:12:43

wonder wrote:

@TemplarGR you are now officially trolling
1)our philosophy is to not patch packages to add _extra_ functionality like this -lcd patches do.
2)cairo has that feature because UPSTREAM decided to include it and therefor doesn't violate 1)
3) in 2010 if you really care about this, you can bug upstream instead of us. then you will find out that there is a good reason they are not including it.

I am not "trolling" just because i happen to have a different opinion on the matter. Grow up a little please...

1) In the case of libxft-lcd, you are not patching using distro-specific patches, you are simply applying an upstream patch on an upstream package, that's all... Please do a search of packages using "patch", just to find a few other patched packages in your repos(strangely libxft-lcd doesn't show up on that search)...
2) i know that, what i wanted to say is that cairo now includes functionality you had previously declared "unworthy" of being included officially...
3) I know about licencing reasons, but here is the thing: libxft-lcd is ALREADY in your repos, for quite some time a might add... So either remove libxft-lcd, or add lib32-libxft-lcd. Providing one and not the other is stupid really...

litemotiv · 2010-09-28 08:35:05

TemplarGR, while i personally would also like to see libxft-lcd in [extra], the only working approach will be to exactly find out the status of the patches upstream. The main issue here is Arch's philosophy to keep packages as vanilla as possible, so if upstream doesn't compile it in by default, Arch won't either unless there is a pressing reason to do so - that's why libxft-lcd is in [community] instead of [extra].

Make sure the lcd-patch for libxft is considered 'official' upstream, state your case with objective arguments and references on the bugtracker to include it, and ask people to vote for inclusion. This will not necessarily make it happen, but it will definitely increase the chances. Once it is in [extra], getting it in multilib will be a trivial step.

TemplarGR · 2010-09-30 08:33:45

I know about Arch's philosophy, that is one of the reasons i am using it and advocating its use to others.

But it is not like if including libxft-lcd and lib32-libxft-lcd(and potentially fontconfig-lcd too) officially would make Arch less vanilla. I am not advocating installing it by default with xorg, but providing the option to use these packages in an official way for almost all of us with lcd monitors.

It is like offering two distinct flavours of a software, like for example you are already doing with openoffice and go-openoffice.

It is not that we can not use AUR. I have been using it for these packages since my beginning with Arch. It is a matter of principle mostly, providing officially Arch users with LCD font support.

Anyway i want to thank all of you for your responses.

TryA · 2010-09-30 13:47:41

Is libxft-lcd still useful now ? After some tests, I think we just need the additional config file (10-lcd-filter.conf) from fontconfig-lcd to enable LCD filtering, it works with libxft from [extra]. So, either we keep fontconfig-lcd in AUR (or even [community]), or we integrate the LCD filter config file into fontconfig.

EDIT: My bad, libxft-lcd is necessary if you want filtering with apps using libxft for font drawing.

Last edited by TryA (2010-10-02 16:24:29)

Arch Linux

#1 2010-09-27 10:37:46

lib32-libxft-lcd should be included in multilib

#2 2010-09-27 11:07:29

Re: lib32-libxft-lcd should be included in multilib

#3 2010-09-27 11:11:25

Re: lib32-libxft-lcd should be included in multilib

#4 2010-09-27 11:11:40

Re: lib32-libxft-lcd should be included in multilib

#5 2010-09-27 12:03:14

Re: lib32-libxft-lcd should be included in multilib

#6 2010-09-27 12:37:25

Re: lib32-libxft-lcd should be included in multilib

#7 2010-09-27 14:25:16

Re: lib32-libxft-lcd should be included in multilib

#8 2010-09-27 14:35:34

Re: lib32-libxft-lcd should be included in multilib

#9 2010-09-27 14:50:19

Re: lib32-libxft-lcd should be included in multilib

#10 2010-09-27 15:48:01

Re: lib32-libxft-lcd should be included in multilib

#11 2010-09-28 06:12:43

Re: lib32-libxft-lcd should be included in multilib

#12 2010-09-28 08:35:05

Re: lib32-libxft-lcd should be included in multilib

#13 2010-09-30 08:33:45

Re: lib32-libxft-lcd should be included in multilib

#14 2010-09-30 13:47:41

Re: lib32-libxft-lcd should be included in multilib

Board footer