Re: [arch-general] wallpaper for 1920x1080 screens.

[gt]

On Wed, May 09, 2012 at 08:06:12PM +0200, Boris Le Ninivin wrote:
> I've uploaded a bunch of variations :
> http://borisln.deviantart.com/gallery/ , feel free to distribute/use
> them :)

Nice, a color for everyone. Maybe, they should indeed be bundled into
the archlinux-wallpaper package.

> I've licensed them under a CC BY SA license, so you can even sell
> them if you want :D (But I doubt it could earn you much money :P)

Who would be cheap enough to make money off your effort, though there
are many sick people out there.

Re: [arch-general] drop slim in favor of lightdm

[Guus Snijders]

Op 9 mei 2012 15:59 schreef "Christian Hesse"  het volgende:
>
> Christian Hesse  on Tue, 2012/05/08 10:35:
> > Any thoughts on that?
>
> Ok, some notes from myself...
>
> There were two reasons why I did not use lxdm:
[...]

Just being curious, but wasn't it lxdm that caused a bit of a security stir
in Ubuntu and others?

I haven't checked the Arch package, but i understood that it creates a
guest user by default. From what i understand, it's bit even a system user,
but a built-in account in lxdm.

Then again; i could be wrong and mixing dm's here...

mvg, Guus

Re: [arch-general] wallpaper for 1920x1080 screens.

[Boris Le Ninivin]

I've uploaded a bunch of variations : 
http://borisln.deviantart.com/gallery/ , feel free to distribute/use them :)


I've licensed them under a CC BY SA license, so you can even sell them 
if you want :D (But I doubt it could earn you much money :P)


- Boris.

Re: [arch-general] [arch-projects] netcfg status?

[Thomas Bächler]

Am 09.05.2012 16:38, schrieb Jouke Witteveen:
> The latest version is in testing for no more than five days now. I
> sent a mail regarding the move to core:
> http://mailman.archlinux.org/pipermail/arch-projects/2012-April/002765.html
> Not much has happened since and I am quite confident in the state of
> the code. Some things are a bit hacky still, but it shouldn't be worse
> than it has always been. The main issue at the moment is the wiki. I
> am not against moving to core by the end of the week.

Alright, the end of the week it is then (unless major bugs occur).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] procps dependency

[gt]

On Wed, May 09, 2012 at 05:59:04PM +0200, Arno Gaboury wrote:
> I am trying to build and burn the archboot iso file on my x86_64 Arch.
> 
> *|[gabx@magnolia Desktop]$ sudo pacman -S archboot
> Password:
> resolving dependencies...
> warning: cannot resolve "procps>=3.2.8-4", a dependency of "archboot"
> :: The following package cannot be upgraded due to unresolvable dependencies:
>   archboot
> 
> Do you want to skip the above package for this upgrade? [y/N] n|*
> 
> procps-ng 3.3.2-2 is installed on my box.
> 
> ** From what I read and understand, Arch went recently from procps
> to procps-ng, so it is normal that my system doesn't have anymore
> the procps package listed as installed and I can safely ignore.
> 
> Please can someone confirm?

You should be fine. Though you should open a bug report against
archboot, as it shouldn't depend on procps, but procps-ng instead.

Re: [arch-general] wallpaper for 1920x1080 screens.

[Ralf Mardorf]

On Wed, 2012-05-09 at 23:42 +0800, Yuan wrote:
> i want a green one, if i can :)

Complementary color of red, so you only need to invert the original ;).
I'm kidding :p.

 - Ralf

Re: [arch-general] wallpaper for 1920x1080 screens.

[Boris Le Ninivin]

On 05/09/2012 05:42 PM, Yuan wrote:

i want a green one, if i can :)
>_>
Best regards
-
Yuan blog  github
Does the one I've added to the deviant art page fits ? Or do you want 
some other one ? (Darker, lighter, etc.)


- Boris

[arch-general] procps dependency

[Arno Gaboury]

I am trying to build and burn the archboot iso file on my x86_64 Arch.

*|[gabx@magnolia Desktop]$ sudo pacman -S archboot
Password:
resolving dependencies...
warning: cannot resolve "procps>=3.2.8-4", a dependency of "archboot"
:: The following package cannot be upgraded due to unresolvable dependencies:
  archboot

Do you want to skip the above package for this upgrade? [y/N] n|*

procps-ng 3.3.2-2 is installed on my box.

** From what I read and understand, Arch went recently from procps to 
procps-ng, so it is normal that my system doesn't have anymore the 
procps package listed as installed and I can safely ignore.


Please can someone confirm?

Re: [arch-general] wallpaper for 1920x1080 screens.

[Yuan]

i want a green one, if i can :)
>_>
Best regards
-
Yuan blog  github 






On Wed, May 9, 2012 at 11:05 PM, Boris Le Ninivin  wrote:

> On 05/09/2012 04:44 PM, Denis A. Altoé Falqueto wrote:
>
>> On Wed, May 9, 2012 at 12:12 AM, Boris Le Ninivin
>>   wrote:
>>
>>> Hi everyone.
>>>
>>> I've made this wallpaper
>>> http://borisln.deviantart.com/**art/Archlinux-Wallpaper-1-**300929958since
>>>  I
>>> didn't find any red wallpaper which pleased me, big enough for my screen
>>> in
>>> the official package, nor on Google images.
>>>
>>> It's licensed under creative commons BY-SA, so if one wants to put it in
>>> the
>>> official archlinux-wallpaper package, feel free to do so :)
>>>
>>> Also, if anyone has any remarks or anything to say about it, I'm all
>>> ears.
>>>
>> I liked it a lot! Thanks for sharing!
>>
> Thank you very much for your answer! :)
>
> Well, if you want, I've made several different colors of it... Since the
> wallpaper is made with a background color and a "filter" color, I can make
> some wallpapers with different colors, which produces different results.
> I'll update the deviantart account with some of these. If one wants
> different colors (or even specific ones), lemme know, I'll try them asap
> (and I can send wallpapers by email if it's for a specific request).
>
> - Boris.
>

Re: [arch-general] wallpaper for 1920x1080 screens.

[Boris Le Ninivin]

On 05/09/2012 04:44 PM, Denis A. Altoé Falqueto wrote:

On Wed, May 9, 2012 at 12:12 AM, Boris Le Ninivin
  wrote:

Hi everyone.

I've made this wallpaper
http://borisln.deviantart.com/art/Archlinux-Wallpaper-1-300929958 since I
didn't find any red wallpaper which pleased me, big enough for my screen in
the official package, nor on Google images.

It's licensed under creative commons BY-SA, so if one wants to put it in the
official archlinux-wallpaper package, feel free to do so :)

Also, if anyone has any remarks or anything to say about it, I'm all ears.

I liked it a lot! Thanks for sharing!

Thank you very much for your answer! :)

Well, if you want, I've made several different colors of it... Since the 
wallpaper is made with a background color and a "filter" color, I can 
make some wallpapers with different colors, which produces different 
results. I'll update the deviantart account with some of these. If one 
wants different colors (or even specific ones), lemme know, I'll try 
them asap (and I can send wallpapers by email if it's for a specific 
request).


- Boris.

Re: [arch-general] wallpaper for 1920x1080 screens.

[Denis A . Altoé Falqueto]

On Wed, May 9, 2012 at 12:12 AM, Boris Le Ninivin
 wrote:
> Hi everyone.
>
> I've made this wallpaper
> http://borisln.deviantart.com/art/Archlinux-Wallpaper-1-300929958 since I
> didn't find any red wallpaper which pleased me, big enough for my screen in
> the official package, nor on Google images.
>
> It's licensed under creative commons BY-SA, so if one wants to put it in the
> official archlinux-wallpaper package, feel free to do so :)
>
> Also, if anyone has any remarks or anything to say about it, I'm all ears.

I liked it a lot! Thanks for sharing!

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
For more information, please read: http://idallen.com/topposting.html

---
Denis A. Altoe Falqueto
Linux user #524555
---

Re: [arch-general] drop slim in favor of lightdm

[Christian Hesse]

Christian Hesse  on Tue, 2012/05/08 10:35:
> Any thoughts on that?

Ok, some notes from myself...

There were two reasons why I did not use lxdm:

* I thought it did not work with challenge response authentication via pam.
  Obviously this is not true: You can enter the password only only, but it is
  tested for every pam prompt. So I can enter unix password or oath token -
  both work.
  The only "problem" is that it does not show the pam message ("One-time
  password (OATH) for ..." - but I can live with that.

* I had trouble interactively selecting a session from lxdm. It took me some
  time to find the cause: The greeter did not give session type to lxdm when
  no language selection dropdown was shown.
  I fixed that (see https://bugs.archlinux.org/task/29814), now everything
  works fine.

Additionally it seems to fix a problem with mouse cursor...

So for now I will stick with lxdm I think. Thus I am fine with not having
lightdm in the official repos.
-- 
main(a,b){char*/*Schoene Gruesse */c="B?IJj;M"
"EHCX:;";for(a/*Chris   get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/*   gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}

Re: [arch-general] [Bulk] Re: [Bulk] Re:RFC: OpenRC as init system for Arch

[Kevin Chadwick]

On Wed, 9 May 2012 13:57:14 +0200
Nicolas Sebrecht wrote:

> The way used to handle conditions is wrong. And I admit that for /this/
> particular case, this is not much relevant.
> 

I actually prefer the first case with multiple ifs. It helps newbie
techs dive in and read the code. So what if they break it they will
learn fixing it.

> > There's another point, shell is easily editable and understandable  and
> > that's a good thing and not a bad one and also one of arches values I
> > believe, hence pacman uses so much shell!  
> 
> I don't find pacman much editable, sorry. I've given examples of nice
> features not easy to implement, here in the past. ,-p

There are a lot of functions and files to get a handle on
aren't there. Is that the reason? I don't think that detracts from the
point though?

Re: [arch-general] [Bulk] Re:RFC: OpenRC as init system for Arch

[Kevin Chadwick]

On Wed, 09 May 2012 19:45:51 +0800
Patrick Lauer wrote:

> > On occasions I have had to resort to editing shell init scripts because
> > I don't agree with the distro or devs. People shouldn't be forced to
> > Gentoo and damaging the environment.  
> Wat :)
> I presume you got distracted and meant to write something else,
> otherwise I have to claim that you are a donkey ;) Thanks for the most
> surreal quote of the day (so far

Was it cryptic. I didn't get your humour either?

With init and shell rc. You are guaranteed control and adaptability and
easier understanding of all executions. With systemd you may have to
work within the expected configurations.

Basically, the premise is that a minimal Linux system should be X times
bigger.

This means you may have to recompile like the Gentoo distro to get the
system you want. Like you currently have to do if you want a smaller
kernel.

Re: [arch-general] netcfg status?

[Thomas Bächler]

Am 09.05.2012 13:16, schrieb Geert Hendrickx:
> Hi,
> 
> What is the status of netcfg 2.8.x?  When will it hit [core] ?
> 
> I have been using it succesfully on my workstation and on two VPS
> (static IPv4 + IPv6 profiles).
> 
> 
>   Geert

Jouke, should we move it? In general, if you want the package to move to
core, you need to notify a developer, as you can't move it yourself.




signature.asc
Description: OpenPGP digital signature

[arch-general] Re: [Bulk] Re:RFC: OpenRC as init system for Arch

[Nicolas Sebrecht]

The 09/05/12, Kevin Chadwick wrote:
> On Wed, 9 May 2012 12:30:34 +0200
> Nicolas Sebrecht wrote:
> 
> > You should turn them all in things like:
> > 
> >   mkdir /sys 2> /dev/null 2>&1
> >   cd /sys || {
> > ewarn ""
> > return 1
> >   }
> 
> That's just a little less racy and certainly not
> atomic, /usr/bin/install would be atomic. As you have said
> your race point doesn't actually matter. You call it plain wrong and
> admit there is nothing wrong at the same time?

The way used to handle conditions is wrong. And I admit that for /this/
particular case, this is not much relevant.

> There's another point, shell is easily editable and understandable  and
> that's a good thing and not a bad one and also one of arches values I
> believe, hence pacman uses so much shell!

I don't find pacman much editable, sorry. I've given examples of nice
features not easy to implement, here in the past. ,-p

-- 
Nicolas Sebrecht

Re: [arch-general] [Bulk] Re:RFC: OpenRC as init system for Arch

[Patrick Lauer]

On 05/09/12 19:35, Kevin Chadwick wrote:
> On Wed, 9 May 2012 12:30:34 +0200
> Nicolas Sebrecht wrote:
>
>> You should turn them all in things like:
>>
>>   mkdir /sys 2> /dev/null 2>&1
>>   cd /sys || {
>> ewarn ""
>> return 1
>>   }
> That's just a little less racy and certainly not
> atomic, /usr/bin/install would be atomic. As you have said
> your race point doesn't actually matter. You call it plain wrong and
> admit there is nothing wrong at the same time?
Well, the problem here is -
that script will be the only one running, and the only one manipulating
sysfs, and it's fail-safe - if anyone else creates the directory we
still end up in a state where it exists (modulo permissions)

So yes, it's technically racy and could fail, but all failure modes are
benign (directory already there, directory really already there) or
really confusing (we can't create a dir - is / mounted readonly? Why are
we being run then?!), so either it's good or something really bad you
can't catch anyway.

>
> There's another point, shell is easily editable and understandable  and
> that's a good thing and not a bad one and also one of arches values I
> believe, hence pacman uses so much shell!
And it's on-the-fly editable. If you just need to disable that check for
a minute because ... err ... long story, but you have to do it ...
trivial. And sh -x gives you an instant "debugger" that makes finding
silly mistakes a lot easier.
>
> On occasions I have had to resort to editing shell init scripts because
> I don't agree with the distro or devs. People shouldn't be forced to
> Gentoo and damaging the environment.
Wat :)
I presume you got distracted and meant to write something else,
otherwise I have to claim that you are a donkey ;) Thanks for the most
surreal quote of the day (so far)

Take care,

Patrick

Re: [arch-general] [Bulk] Re:RFC: OpenRC as init system for Arch

[Kevin Chadwick]

On Wed, 9 May 2012 12:30:34 +0200
Nicolas Sebrecht wrote:

> You should turn them all in things like:
> 
>   mkdir /sys 2> /dev/null 2>&1
>   cd /sys || {
> ewarn ""
> return 1
>   }

That's just a little less racy and certainly not
atomic, /usr/bin/install would be atomic. As you have said
your race point doesn't actually matter. You call it plain wrong and
admit there is nothing wrong at the same time?

There's another point, shell is easily editable and understandable  and
that's a good thing and not a bad one and also one of arches values I
believe, hence pacman uses so much shell!

On occasions I have had to resort to editing shell init scripts because
I don't agree with the distro or devs. People shouldn't be forced to
Gentoo and damaging the environment.

[arch-general] netcfg status?

[Geert Hendrickx]

Hi,

What is the status of netcfg 2.8.x?  When will it hit [core] ?

I have been using it succesfully on my workstation and on two VPS
(static IPv4 + IPv6 profiles).


Geert


-- 
geert.hendrickx.be :: ge...@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

[arch-general] Re: [Bulk] Re:RFC: OpenRC as init system for Arch

[Nicolas Sebrecht]

The 07/05/12, Patrick Lauer wrote:

> So anyway. If you complain about bad shell, fix it, or throw some
> examples at me so I can rewrite them cleanly.

"Patch it yourself" is exactly the opposite of what I would expect. This
is not peace of mind to add patches to already too much stressed code in
pieces of core tools. I'm not talking about you especially and vanilla
OpenRC scripts but those written and tuned by maintainers.

>   Don't think rewriting in
> Modula-3 will make it any better, the same people you condemned for not
> writing good shell won't write good INTERCAL either. Educate them, fix
> any bug you find, enjoy.

Traking down what maintainers do with stderr and how error code is
handled in init shell scripts is most of the time a good example of how
educated people can write poor shell code.

As you're asking for it, here is a random example of shell code in sysfs
(a very core script) taken from official repository(1):

  if [ ! -d /sys ]; then
if ! mkdir -m 0755 /sys; then
  ewarn "Could not create /sys!"
  return 1
fi
  fi

This code is exposed to race conditions as the directory creation could
happen in a slice between the first condition check and the next mkdir
call. Of course, in this particular case we can sanely expect the
creation of /sys beeing not concurrency at all, but this way of
"checking for conditions and then handle the missing condition after the
facts" is almost everywhere in the code.  This is RACY and plain WRONG.

You should turn them all in things like:

  mkdir /sys 2> /dev/null 2>&1
  cd /sys || {
ewarn ""
return 1
  }

If this kind of problem was only for creating directories, I wouldn't
even mention it. But in real life these shell code scripts make
debugging and maintaining init a nightmare. Writing good shell code is
MUCH harder than it looks at a first glance, including for educated
people.

(1) 
http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob_plain;f=init.d/sysfs.in;hb=HEAD

-- 
Nicolas Sebrecht

Re: [arch-general] RFC: OpenRC as init system for Arch

[Kevin Chadwick]

On Wed, 9 May 2012 10:58:01 +0200
Nicolas Sebrecht wrote:

> And dbus will be part of the kernel, soon.
> 
> So, what you call "silly dependencies" *are the core* of a Linux system.


So is that sentiment, we'll force it upon you. How lovely.

You have read all the security papers about dbus, right?

Unless your willing to give up lots of your own or machine time
compiling of course.

I wouldn't run the as admitted by and somewhat out of Linus's control
bloated linux kernel on servers, adding dbus would just re-affirm that
even if it wasn't used.

I wonder and am not suggesting whether the unix/posix world is going to
divulge completely due to linux only tech.


I wonder when/if a new linux kernel will gather steam. Perhaps called
something like genux. Or if techs will eventually flock even more to the
BSDs.


They're retorical by the way.

Re: [arch-general] qt applications gone black

[Paul Gideon Dann]

On Wednesday 09 May 2012 11:31:08 CodeVision wrote:
> QGtkStyle was unable to detect the current GTK+ theme.
> 
> I reckon its the same problem. As far as I know, there's no real
> solution for it, just a few workarounds. I solved it by installing
> 'gconf' [1] which has a lot less dependencies than libgnomeui. If you
> are not running gnome, you might also have to run:
> 
> gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme
> your_theme_name

Strange; I wouldn't have thought the problem was the GTK theme.  If it is, 
though, I've had gtk-chtheme hanging around, which depends only on gtk2.

Paul

Re: [arch-general] qt applications gone black

[gt]

On Wed, May 09, 2012 at 11:31:08AM +0200, CodeVision wrote:
> On Wed, 9 May 2012 14:34:27 +0530
> gt  wrote:
> 
> > I had removed libgnomeui a year back, and everything was working fine
> > in the meantime.
> > 
> > Unfortunately libgnomeui fetches a lot of unnecessary gnome stuff,
> > gvfs, udisks2 etc. Isn't there some other solution?
> 
> From your picture and description, the problem you have seems similar to
> the problem I had a while ago. If the error message you get when you run
> e.g. VLC from the command line is: 
> 
> QGtkStyle was unable to detect the current GTK+ theme.
> 
> I reckon its the same problem. As far as I know, there's no real
> solution for it, just a few workarounds. I solved it by installing
> 'gconf' [1] which has a lot less dependencies than libgnomeui. If you
> are not running gnome, you might also have to run:
> 
> gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme
> your_theme_name
> 
> For more information you can look in this forum thread [2], where I
> also got this solution from.
> 
> Hope it helps.
> 
> 
> [1] http://www.archlinux.org/packages/extra/x86_64/gconf/  or
>   http://www.archlinux.org/packages/extra/i686/gconf/
> [2] https://bbs.archlinux.org/viewtopic.php?pid=775685

Nope my problem was different. Thanks for your help, but i finally found
a solution on the forums itself.

https://bbs.archlinux.org/viewtopic.php?id=93325

The last post by ecmel solves the problem for me. I had recently
borrowed .Xresources colours from someone on the forums, which were like

*.background:
*.foreground:
...

Changing them to urxvt.background, i.e., removing the wildcard solved
the problem. Who would have thought that .Xresources would be accessed
by qt, but apparently it is.

Thanks to all for the help.

Re: [arch-general] qt applications gone black

[gt]

On Wed, May 09, 2012 at 10:20:13AM +0100, Paul Gideon Dann wrote:
> On Wednesday 09 May 2012 14:34:27 gt wrote:
> > Unfortunately libgnomeui fetches a lot of unnecessary gnome stuff, gvfs,
> > udisks2 etc. Isn't there some other solution?
> 
> Qt comes with qtconfig.  Have you tried that already?

Yes, tried it, as mentioned by Diep Pham Van. But, it didn't matter
whatever style i tried.

I also tried downgrading to qt 4.8.0-6, but that too didn't make a
difference.

Re: [arch-general] qt applications gone black

[CodeVision]

On Wed, 9 May 2012 14:34:27 +0530
gt  wrote:

> I had removed libgnomeui a year back, and everything was working fine
> in the meantime.
> 
> Unfortunately libgnomeui fetches a lot of unnecessary gnome stuff,
> gvfs, udisks2 etc. Isn't there some other solution?

From your picture and description, the problem you have seems similar to
the problem I had a while ago. If the error message you get when you run
e.g. VLC from the command line is: 

QGtkStyle was unable to detect the current GTK+ theme.

I reckon its the same problem. As far as I know, there's no real
solution for it, just a few workarounds. I solved it by installing
'gconf' [1] which has a lot less dependencies than libgnomeui. If you
are not running gnome, you might also have to run:

gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme
your_theme_name

For more information you can look in this forum thread [2], where I
also got this solution from.

Hope it helps.


[1] http://www.archlinux.org/packages/extra/x86_64/gconf/  or
http://www.archlinux.org/packages/extra/i686/gconf/
[2] https://bbs.archlinux.org/viewtopic.php?pid=775685

Re: [arch-general] qt applications gone black

[Paul Gideon Dann]

On Wednesday 09 May 2012 14:34:27 gt wrote:
> Unfortunately libgnomeui fetches a lot of unnecessary gnome stuff, gvfs,
> udisks2 etc. Isn't there some other solution?

Qt comes with qtconfig.  Have you tried that already?

Paul

Re: [arch-general] qt applications gone black

[gt]

On Wed, May 09, 2012 at 03:28:42PM +0700, Diep Pham Van wrote:
> I have same problem before, you must install libgnomeui and change GUI
> style in qtconfig.

I had removed libgnomeui a year back, and everything was working fine in
the meantime.

Unfortunately libgnomeui fetches a lot of unnecessary gnome stuff, gvfs,
udisks2 etc. Isn't there some other solution?

[arch-general] Re: RFC: OpenRC as init system for Arch

[Nicolas Sebrecht]

The 07/05/12, Patrick Lauer wrote:

> Nyet. Future very certain. Most of us will stick with OpenRC, and do
> whatever is needed to keep it working.

I don't think so, like developers from inside the Gentoo community
itself...

> Now that systemd upstream has assimilated udev (which confuses nicely,
> but their decision in the end) there's even work to get rid of that
> silly udev, err, systemd-udev, err, systemd dependency. The harder some
> people try to force their ideas on others the faster we get replacements
> to route around the damage.

...because udev is merged into systemd (which makes perfect sense to get
an event-driven boot system).

And dbus will be part of the kernel, soon.

So, what you call "silly dependencies" *are the core* of a Linux system.

These are needed changes to really have expected features in the
beginning of this century. Of course, you could support the old way of
maintaining services and handling init. But the price is to add more
complexity/workload in the middle/long term and become esoteric to
upcoming killer features which will just (or almost, at least) work out
of the box with an event driven init system.


-- 
Nicolas Sebrecht

Re: [arch-general] qt applications gone black

[Diep Pham Van]

I have same problem before, you must install libgnomeui and change GUI
style in qtconfig.

On Wed, May 09, 2012 at 12:49:48PM +0530, gt wrote:
> Hey guys
> 
> I am facing a strange issue. All qt applications have become black,
> making them impossible to use.
> 
> Here's an example showing vlc and avidemux-qt
> 
> https://imgur.com/a/PR5vH
> 
> Anyone else facing this issue? The closest i found someone with a
> similar problem is:
> 
> https://www.linuxquestions.org/questions/slackware-14/next-kde-4-8-2-regression-firefox-thunderbird-joined-the-all-blacks-942693/
> 
> But the guy is using kde, and i am using dwm + xf86-video-intel

-- 
PHẠM Văn Điệp

h  : http://favadi.com
e  : i...@favadi.com
m  : +84 984 339 841
   _
ASCII ribbon campaign ( )
 - against HTML email  X
 & vCards / \

[arch-general] qt applications gone black

[gt]

Hey guys

I am facing a strange issue. All qt applications have become black,
making them impossible to use.

Here's an example showing vlc and avidemux-qt

https://imgur.com/a/PR5vH

Anyone else facing this issue? The closest i found someone with a
similar problem is:

https://www.linuxquestions.org/questions/slackware-14/next-kde-4-8-2-regression-firefox-thunderbird-joined-the-all-blacks-942693/

But the guy is using kde, and i am using dwm + xf86-video-intel