[arch-general] Xorg Segfault on Console Switch

[Yaro Kasear]

I seem to be having an odd issue with Xorg since updating to 1.20.9.

I tend to be logged onto Xorg across more than one user based on what
kind of task I need, and switch between them via CTRL+ALT+F1/F2/F3.

Since the update this morning it seems to have started causing segfaults
on Xorg the longer I'm switched away from the console containing the
Xorg instance that crashes.

I am not even sure how to begin troubleshooting this problem. I can
usually figure this out on my own.

Process 8780 (Xorg) of user 1003 dumped core.

  Stack trace of thread 8780:
  #0  0x7ff15b192615
raise (libc.so.6 + 0x3d615)
  #1  0x7ff15b17b862
abort (libc.so.6 + 0x26862)
  #2  0x5617387ee35a
OsAbort (Xorg + 0x14a35a)
  #3  0x5617387efe21
FatalError (Xorg + 0x14be21)
  #4  0x5617387f5a79 n/a
(Xorg + 0x151a79)
  #5  0x7ff15b1926a0
__restore_rt (libc.so.6 + 0x3d6a0)
  #6  0x561738722f03 n/a
(Xorg + 0x7ef03)
  #7  0x5617387a8ed5 n/a
(Xorg + 0x104ed5)
  #8  0x5617387d67fc n/a
(Xorg + 0x1327fc)
  #9  0x5617386edbb3
mieqProcessDeviceEvent (Xorg + 0x49bb3)
  #10 0x5617386edcfc
mieqProcessInputEvents (Xorg + 0x49cfc)
  #11 0x5617388045b9
ProcessInputEvents (Xorg + 0x1605b9)
  #12 0x5617386dd8c8 n/a
(Xorg + 0x398c8)
  #13 0x7ff15b17d152
__libc_start_main (libc.so.6 + 0x28152)
  #14 0x5617386de5ae
_start (Xorg + 0x3a5ae)

Yaro



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 3:41 PM, Morten Linderud via arch-general wrote:
> https://www.archlinux.org/pacman/pacman.8.html#_handling_config_files_a_id_hcf_a
>
> Can you please read this section a few times before writing more emails?
>
I see. I was sure pacman made no comparisons at all to previous config
versions, just what is on the filesystem now and what's new.

Sorry about that, I was wrong.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear  wrote:

> On Wed, Aug 19, 2020 at 3:17 PM Archange  wrote:
>
>>
>> Le 20/08/2020 à 00:04, Yaro Kasear a écrit :
>> > On 8/19/20 2:56 PM, Yaro Kasear wrote:
>> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
>> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>> >>>> I've always questioned the wisdom of dropping a .pacnew just when the
>> >>>> file is different from the default. There's really no reason for it
>> >>>> considering any changes you made were deliberate and presumably
>> thought
>> >>>> out. The end result is pacman cluttering /etc with a default
>> >>>> configuration file whose only reason for existing is to, if it's
>> used,
>> >>>> clear settings. Why?
>> >>>>
>> >>> The .pacnew is there to indicate that something new exists, or that
>> >>> you changed
>> >>> something. Most of the time you can remove .pacnew files, but not
>> >>> always. Also,
>> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle
>> them.
>> >>>
>> >>>> What pacman SHOULD do is compare /etc files between package versions
>> and
>> >>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>> >>>> reason to need a new default config file for the user to examine
>> because
>> >>>> then there's an actual indicator some meaningful change in default
>> >>>> configuration or how the package handles configs happened.
>> >>>>
>> >>> That's way beyond the scope of a package manager, and also, there's no
>> >>> way
>> >>> to tell what "DEFAULTS" (why caps?) should be.
>> >> Caps for emphasis is all.
>> >>>> All most pacnew files wind up doing is sitting there for thirty
>> seconds
>> >>>> before being deleted without anyone even opening them because they're
>> >>>> literally just what the file was before the user ALREADY changed it
>> >>>> before... because it's utterly useless to get a default config file
>> when
>> >>>> you've intentionally changed it and there's nothing in the new
>> version
>> >>>> of the package that calls for an examination of the defaults.
>> >>>>
>> >>> I don't know why you said that .pacnew sits for thirty seconds before
>> >>> being
>> >>> deleted. Are you using a hook that does this? Because nothing handles
>> >>> them
>> >>> automatically, that's the user's job. There are tools to aid in doing
>> >>> that,
>> >>> but in the end the user should know what to apply, and what to
>> discard.
>> >> I wasn't being literal about thirty seconds. Exaggerating.
>> >>> Regards,
>> >>> Giancarlo Razzolini
>> >> Yaro
>> >>
>> >>
>> > Oh, also:
>> >
>> > "That's way beyond the scope of a package manager, and also, there's no
>> > way to tell what "DEFAULTS" (why caps?) should be."
>> >
>> > Yes there is. The defaults are literally what's in the config file in
>> > the archive and not on the filesystem. How would that not be a way to
>> > determine default settings?
>> >
>> > I'm not suggesting the package manager would have to understand the
>> > settings, but it would be able to tell if the contents of that file are
>> > different from another version. (Which it obviously does already,
>> > otherwise it wouldn't know to make a pacnew file.)
>> >
>> > I can't imagine it'd be that difficult for pacman to compare checksums
>> > between files in /etc or /boot between versions of a package (If a
>> > previous version is available.) and what's on /etc and determine if it
>> > really needs to bother putting a pacnew file on the filesystem that
>> > doesn't need to be there. It's already doing some sort of check between
>> > what's in the package and what's on the filesystem already.
>> >
>> > Yaro
>>
>> pacman does this: if the *packaged file* changed between the installed
>> version and the new one, and the *installed file* is different from the
>> *packaged file*, then drop a .pacnew.
>>
>> I’m not sure what you want more…
>>
>> Bruno/Archange
>>
>

Re: [arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:17 PM Archange  wrote:

>
> Le 20/08/2020 à 00:04, Yaro Kasear a écrit :
> > On 8/19/20 2:56 PM, Yaro Kasear wrote:
> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
> >>>> I've always questioned the wisdom of dropping a .pacnew just when the
> >>>> file is different from the default. There's really no reason for it
> >>>> considering any changes you made were deliberate and presumably
> thought
> >>>> out. The end result is pacman cluttering /etc with a default
> >>>> configuration file whose only reason for existing is to, if it's used,
> >>>> clear settings. Why?
> >>>>
> >>> The .pacnew is there to indicate that something new exists, or that
> >>> you changed
> >>> something. Most of the time you can remove .pacnew files, but not
> >>> always. Also,
> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
> >>>
> >>>> What pacman SHOULD do is compare /etc files between package versions
> and
> >>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
> >>>> reason to need a new default config file for the user to examine
> because
> >>>> then there's an actual indicator some meaningful change in default
> >>>> configuration or how the package handles configs happened.
> >>>>
> >>> That's way beyond the scope of a package manager, and also, there's no
> >>> way
> >>> to tell what "DEFAULTS" (why caps?) should be.
> >> Caps for emphasis is all.
> >>>> All most pacnew files wind up doing is sitting there for thirty
> seconds
> >>>> before being deleted without anyone even opening them because they're
> >>>> literally just what the file was before the user ALREADY changed it
> >>>> before... because it's utterly useless to get a default config file
> when
> >>>> you've intentionally changed it and there's nothing in the new version
> >>>> of the package that calls for an examination of the defaults.
> >>>>
> >>> I don't know why you said that .pacnew sits for thirty seconds before
> >>> being
> >>> deleted. Are you using a hook that does this? Because nothing handles
> >>> them
> >>> automatically, that's the user's job. There are tools to aid in doing
> >>> that,
> >>> but in the end the user should know what to apply, and what to discard.
> >> I wasn't being literal about thirty seconds. Exaggerating.
> >>> Regards,
> >>> Giancarlo Razzolini
> >> Yaro
> >>
> >>
> > Oh, also:
> >
> > "That's way beyond the scope of a package manager, and also, there's no
> > way to tell what "DEFAULTS" (why caps?) should be."
> >
> > Yes there is. The defaults are literally what's in the config file in
> > the archive and not on the filesystem. How would that not be a way to
> > determine default settings?
> >
> > I'm not suggesting the package manager would have to understand the
> > settings, but it would be able to tell if the contents of that file are
> > different from another version. (Which it obviously does already,
> > otherwise it wouldn't know to make a pacnew file.)
> >
> > I can't imagine it'd be that difficult for pacman to compare checksums
> > between files in /etc or /boot between versions of a package (If a
> > previous version is available.) and what's on /etc and determine if it
> > really needs to bother putting a pacnew file on the filesystem that
> > doesn't need to be there. It's already doing some sort of check between
> > what's in the package and what's on the filesystem already.
> >
> > Yaro
>
> pacman does this: if the *packaged file* changed between the installed
> version and the new one, and the *installed file* is different from the
> *packaged file*, then drop a .pacnew.
>
> I’m not sure what you want more…
>
> Bruno/Archange
>

But that is not what I am talking about.

I'm discussing what is essentially three configuration files here:

- The config in old-package.
- The config in new-package.
- The config on the filesystem.

I already know pacman compares new-package and filesystem config. It does
NOT do any check between old-package and new-package.

What I'm saying is a pacnew seems unnecessary if the file between
old-package and new-package are the same, be

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:56 PM, Yaro Kasear wrote:
> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>>> I've always questioned the wisdom of dropping a .pacnew just when the
>>> file is different from the default. There's really no reason for it
>>> considering any changes you made were deliberate and presumably thought
>>> out. The end result is pacman cluttering /etc with a default
>>> configuration file whose only reason for existing is to, if it's used,
>>> clear settings. Why?
>>>
>> The .pacnew is there to indicate that something new exists, or that
>> you changed
>> something. Most of the time you can remove .pacnew files, but not
>> always. Also,
>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
>>
>>> What pacman SHOULD do is compare /etc files between package versions and
>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>>> reason to need a new default config file for the user to examine because
>>> then there's an actual indicator some meaningful change in default
>>> configuration or how the package handles configs happened.
>>>
>> That's way beyond the scope of a package manager, and also, there's no
>> way
>> to tell what "DEFAULTS" (why caps?) should be.
> Caps for emphasis is all.
>>> All most pacnew files wind up doing is sitting there for thirty seconds
>>> before being deleted without anyone even opening them because they're
>>> literally just what the file was before the user ALREADY changed it
>>> before... because it's utterly useless to get a default config file when
>>> you've intentionally changed it and there's nothing in the new version
>>> of the package that calls for an examination of the defaults.
>>>
>> I don't know why you said that .pacnew sits for thirty seconds before
>> being
>> deleted. Are you using a hook that does this? Because nothing handles
>> them
>> automatically, that's the user's job. There are tools to aid in doing
>> that,
>> but in the end the user should know what to apply, and what to discard.
> I wasn't being literal about thirty seconds. Exaggerating.
>> Regards,
>> Giancarlo Razzolini
> Yaro
>
>
Oh, also:

"That's way beyond the scope of a package manager, and also, there's no
way to tell what "DEFAULTS" (why caps?) should be."

Yes there is. The defaults are literally what's in the config file in
the archive and not on the filesystem. How would that not be a way to
determine default settings?

I'm not suggesting the package manager would have to understand the
settings, but it would be able to tell if the contents of that file are
different from another version. (Which it obviously does already,
otherwise it wouldn't know to make a pacnew file.)

I can't imagine it'd be that difficult for pacman to compare checksums
between files in /etc or /boot between versions of a package (If a
previous version is available.) and what's on /etc and determine if it
really needs to bother putting a pacnew file on the filesystem that
doesn't need to be there. It's already doing some sort of check between
what's in the package and what's on the filesystem already.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
>>
>> I've always questioned the wisdom of dropping a .pacnew just when the
>> file is different from the default. There's really no reason for it
>> considering any changes you made were deliberate and presumably thought
>> out. The end result is pacman cluttering /etc with a default
>> configuration file whose only reason for existing is to, if it's used,
>> clear settings. Why?
>>
>
> The .pacnew is there to indicate that something new exists, or that
> you changed
> something. Most of the time you can remove .pacnew files, but not
> always. Also,
> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
>
>> What pacman SHOULD do is compare /etc files between package versions and
>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
>> reason to need a new default config file for the user to examine because
>> then there's an actual indicator some meaningful change in default
>> configuration or how the package handles configs happened.
>>
>
> That's way beyond the scope of a package manager, and also, there's no
> way
> to tell what "DEFAULTS" (why caps?) should be.
Caps for emphasis is all.
>
>> All most pacnew files wind up doing is sitting there for thirty seconds
>> before being deleted without anyone even opening them because they're
>> literally just what the file was before the user ALREADY changed it
>> before... because it's utterly useless to get a default config file when
>> you've intentionally changed it and there's nothing in the new version
>> of the package that calls for an examination of the defaults.
>>
>
> I don't know why you said that .pacnew sits for thirty seconds before
> being
> deleted. Are you using a hook that does this? Because nothing handles
> them
> automatically, that's the user's job. There are tools to aid in doing
> that,
> but in the end the user should know what to apply, and what to discard.
I wasn't being literal about thirty seconds. Exaggerating.
>
> Regards,
> Giancarlo Razzolini

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] No login after update

[Yaro Kasear]

On 8/19/20 2:13 PM, Giancarlo Razzolini via arch-general wrote:
> Em agosto 19, 2020 16:02 Manuel Reimer escreveu:
>> Hello,
>>
>> Some minutes ago I did a regular system update and after that decided
>> to reboot. After reboot I was unable to log into my system. After
>> fiddling a bit I rebooted to an Arch boot stick to find the following
>> message in pacman.log:
>>
>> [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login
>> installed as
>> /etc/pam.d/system-login.pacnew
>>
>
> The .pacnew should've been handled *before* rebooting.
>
>> As this seemed to be a candidate that may cause login problems, I
>> deleted "system-login" and moved the ".pacnew" into place.
>>
>> After reboot I'm now able to log in again...
>>
>> IMHO something like this should not happen...
>>
>> Maybe it's worth a note on the Arch homepage that it is important to
>> move this pacnew into place before reboot?
>>
>
> This only affected you and whomever else changed system-login. It's
> not news
> material. Also, if you're messing with PAM, you should be responsible
> for applying
> the new stuff, otherwise it'll break, like it did for you.
>
> Regards,
> Giancarlo Razzolini

I've always questioned the wisdom of dropping a .pacnew just when the
file is different from the default. There's really no reason for it
considering any changes you made were deliberate and presumably thought
out. The end result is pacman cluttering /etc with a default
configuration file whose only reason for existing is to, if it's used,
clear settings. Why?

What pacman SHOULD do is compare /etc files between package versions and
see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
reason to need a new default config file for the user to examine because
then there's an actual indicator some meaningful change in default
configuration or how the package handles configs happened.

All most pacnew files wind up doing is sitting there for thirty seconds
before being deleted without anyone even opening them because they're
literally just what the file was before the user ALREADY changed it
before... because it's utterly useless to get a default config file when
you've intentionally changed it and there's nothing in the new version
of the package that calls for an examination of the defaults.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 1:09 PM, Kusoneko wrote:
> On June 2, 2020 5:58:51 PM UTC, Hanipaganda via arch-general 
>  wrote:
>>
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, June 2, 2020 9:10 AM, Yaro Kasear  wrote:
>>
>>> On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
>>>
>>>> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>>>>
>>>>> https://thenationalpulse.com/
>>>>> Isn't this a right-wing propaganda media? IIUC you are so far
>>>>> the only one making a political issue out of a sincere exchange
>>>>> of thoughts, regarding an off-topic thread.
>>>> FWIW the logo has got only a single colour of the rainbow,
>>>> https://www.archlinux.org/ , is this already too much rainbow
>> colour?
>>>> Is it planned to change the colour of the logo? Can you provide a
>> link
>>>> to a fact-check prove source?
>>> The fact this user used the term "globalist" should really tell you
>> all
>>> you need to know about them. That's a conservative dog-whistle term
>> for
>>> "Jew" and is usually spewed by people who listen to garbage like Alex
>>> Jones unironically.
>>>
>>> Yaro
>> The country is burning with the fires of revolution as the proletariat
>> make their stand against a capitalist bourgeoisie power structure that
>> has systemically oppressed them for years and you are concerned about a
>> logo change? I frankly cannot imagine the privilege one must have to
>> not only believe this but also feel the confidence to express this in
>> front of others during worldwide unrest.
>
> I cannot imagine the privilege one must have to imply that a single country's 
> civil unrest somehow translates to worldwide unrest and should prevent people 
> from being concerned about their own personal issues.

Thing is, I *am* in the United States, and somehow I'm able to be both
worried about the state of things on here AND comment on something
minor. Some people seem to think you can only worry about one issue at a
time. I know it wasn't you who said it, just commenting in line with
your thinking, and that comment of theirs was just not terribly
constructive and probably a red herring.

I'm going to drop off this thread now, though.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 12:58 PM, Hanipaganda via arch-general wrote:
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, June 2, 2020 9:10 AM, Yaro Kasear  wrote:
>
>> On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
>>
>>> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>>>
>>>> https://thenationalpulse.com/
>>>> Isn't this a right-wing propaganda media? IIUC you are so far
>>>> the only one making a political issue out of a sincere exchange
>>>> of thoughts, regarding an off-topic thread.
>>> FWIW the logo has got only a single colour of the rainbow,
>>> https://www.archlinux.org/ , is this already too much rainbow colour?
>>> Is it planned to change the colour of the logo? Can you provide a link
>>> to a fact-check prove source?
>> The fact this user used the term "globalist" should really tell you all
>> you need to know about them. That's a conservative dog-whistle term for
>> "Jew" and is usually spewed by people who listen to garbage like Alex
>> Jones unironically.
>>
>> Yaro
> The country is burning with the fires of revolution as the proletariat make 
> their stand against a capitalist bourgeoisie power structure that has 
> systemically oppressed them for years and you are concerned about a logo 
> change? I frankly cannot imagine the privilege one must have to not only 
> believe this but also feel the confidence to express this in front of others 
> during worldwide unrest.

I'm not concerned about the logo change. I'm in favor of it. And the
situation in the United States (Not everyone on this list is in the US.)
is not really relevant to this discussion.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/2/20 3:49 AM, Ralf Mardorf via arch-general wrote:
> On Tue, 02 Jun 2020 00:53:02 -0400, Olivier Langlois wrote:
>> https://thenationalpulse.com/
> Isn't this a right-wing propaganda media? IIUC you are so far
> the only one making a political issue out of a sincere exchange
> of thoughts, regarding an off-topic thread.
>
> FWIW the logo has got only a single colour of the rainbow,
> https://www.archlinux.org/ , is this already too much rainbow colour?
>
> Is it planned to change the colour of the logo? Can you provide a link
> to a fact-check prove source?
>
The fact this user used the term "globalist" should really tell you all
you need to know about them. That's a conservative dog-whistle term for
"Jew" and is usually spewed by people who listen to garbage like Alex
Jones unironically.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Arch should be apolitical

[Yaro Kasear]

On 6/1/20 6:43 PM, Ricardo Band wrote:
> On June 1, 2020 11:18:50 PM UTC, Amir Fletcher via arch-general 
>  wrote:
>> Recently, the Arch reddit logo was changed to a rainbow. This is for "pride 
>> month". It is forcing a political view on all of the users who did not ask 
>> for this. 
> I'm sorry but why do you care about the damn logo? And since when has the 
> sexual identity anything to do with politics?
> It's a rainbow, not a swastika.

Agreed.

It's not like people are forced to use the logo to use Arch Linux. If
you don't like it, then just don't sit around staring at it.

Also, in the sort of places that would cause serious harm for someone to
support LGBT+ rights Arch already has a number of packages that they
would already not want people to use. Just saying.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 11:21 PM, Eli Schwartz via arch-general wrote:
> On 3/7/20 11:53 PM, Yaro Kasear wrote:
>>> Thanks for your reply. If I put this in a bash script, will it reset once
>>> the script is done running?
>>>
>> I suspect it will if you drop the 'export' directive and just set PATH
>> without it.
>>
>> I'd strongly recommend testing it until it works for you.
> But the "PATH" environment variable already has the export attribute on
> it, so it is exported either way.
>
> Furthermore, I'm bewildered w.r.t. what is the question/goal here? If
> you set some variable in a script, it will never modify the environment
> of the *parent process*, only the script itself, and child processes
> started by the script.
>
> Have I completely misunderstood the question?
>
If they are having trouble invoking Reflector, a simple two-line script
to change PATH just for the script and an instance of Reflector is all
they would need. I won't comment as to the unconventional setup they
have for their system, though. I personally wouldn't change my PATH like
that, but this isn't about what *I* am doing.

Yaro




signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 10:51 PM, karx via arch-general wrote:
> On Sat, Mar 7, 2020, 9:59 PM Yaro Kasear  wrote:
>
>> On 3/7/20 9:53 PM, karx via arch-general wrote:
>>> On Sat, Mar 7, 2020, 9:50 PM Neven Sajko  wrote:
>>>
>>>> I have not fully understood your situation, but can you not just
>>>> change the PATH environment variable?
>>>>
>>> No. I need python for other projects, and would much rather use a version
>>> management system rather than risk messing up the system python.
>> Basically,
>>> what I am asking is, can I get reflector to work with pyenv?
>>>
>> You could just change PATH for the one terminal with an 'export
>> PATH=/usr/bin:$PATH'
>>
>> That wouldn't affect PATH for any other sessions...
>>
>> Yaro
>>
> Thanks for your reply. If I put this in a bash script, will it reset once
> the script is done running?
>
I suspect it will if you drop the 'export' directive and just set PATH
without it.

I'd strongly recommend testing it until it works for you.

Yaro

Re: [arch-general] Problem with reflector

[Yaro Kasear]

On 3/7/20 9:53 PM, karx via arch-general wrote:
> On Sat, Mar 7, 2020, 9:50 PM Neven Sajko  wrote:
>
>> I have not fully understood your situation, but can you not just
>> change the PATH environment variable?
>>
> No. I need python for other projects, and would much rather use a version
> management system rather than risk messing up the system python. Basically,
> what I am asking is, can I get reflector to work with pyenv?
>
You could just change PATH for the one terminal with an 'export
PATH=/usr/bin:$PATH'

That wouldn't affect PATH for any other sessions...

Yaro

Re: [arch-general] Package guidelines 

[Yaro Kasear]

On 10/14/19 3:59 PM, Alberto Salvia Novella via arch-general wrote:
> Video-reply 

For someone who "can handle disagreement" like you claim in your video,
you sure are protesting quite a bit over it.

I also have a hard time someone is really extending a hand in good faith
with respectful, mutual discourse and productive discussion when they:

- Immediately block anyone who disagrees with them like you did three
times now at least.

- Hide like/dislike count on your videos.

- Disable comments on your videos.

It tells me you're not interested in people actually responding to your
thoughts in an intellectually honest way. I can handle disagreement too,
but I don't have time for people whose approach to criticism,
constructive or no, is intellectual dishonesty.

You're not asking for respect, you're asking for people to just accept
what you say. That's not the same thing. Respect means you can take
disagreement without blocking them or posting a Youtube video that's one
half boring and one half petulant whining about your treatment.

Yaro

Re: [arch-general] Package guidelines 

[Yaro Kasear]

On 10/14/19 10:41 AM, Alberto Salvia Novella via arch-general wrote:
> As said, blocked the latest three.
>
> We can either have a constructive conversation or it's over, that
> simple. Make your choice.
>
Blocking people who respond negatively to your proposal is a great way
to get people to universally hate your ideas. Especially when one of the
people you block is a TU who explains why your ideas won't be followed.

If you can't handle that, you're in the wrong place. Though as other
users have already pointed out, it looks like your proposal was a thread
going nowhere from the start.

Your proposal has little rationale given to justify your ideas, at least
one of your ideas already conflicts with existing guidelines, and one of
your ideas is startlingly bad security practice nobody should follow.

Yaro

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Yaro Kasear]

On 10/9/19 9:39 AM, Ralf Mardorf via arch-general wrote:
> On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote:
>> On 10/9/19 10:11 AM, Tinu Weber wrote:
>>> https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/
>>>   
>> Perfect - thank you!
> IMO 'reiserfsprogs' is a good pointer for what reason to change 'base'
> makes sense ;). It's a package good for backwards compatibility, but
> probably not useful for a base install ;).
>
Heck, jfsutils. Does anyone actually use JFS outside of backwards
compatibility

support for older IBM systems? It bewilders me that it was in the
original base group,

honestly.

Yaro

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Yaro Kasear]

On 10/8/19 1:45 PM, David C. Rankin wrote:
> On 10/08/2019 01:33 PM, Eli Schwartz via arch-general wrote:
>> Because this is not about containers. There are tons of things in the
>> old base group which I don't want installed on my heavyweight X11
>> desktop which is used for media consumption.
>>
>> I don't need netct (because networkmanager is love), s-nail (unuseful in
>> practice) or vi (symlink to vim) as a baseline fact.
>>
>> I don't need cryptsetup or device-mapper if I'm not opting into an
>> encrypted filesystem, but this does not matter as I cannot get rid of
>> either one due to systemd performing shared library links to
>> libcryptsetup.so and therefore also having a depends+=('cryptsetup')
>>
>> I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do
>> you think my system is unusable without it? Note: in practice, both are
>> required by libblockdev, which means if you use udisks2 you have both
>> installed anyway.
> As long at it passes the Allan test, then so be it. I do use mdadm, netctl,
> s-nail (mailx) but agree with vim as baseline. The point being no kernel? So
> now a 'base' install does not result in a running system? It seems like
> forcing the install of `base` + (a list of other packages) just to result in a
> bootable system will create more problems then it solves. At least a meta of
> 'base-legacy' would provide the same install capability. As for the argument
> advances that this was due to those looking for a container install, why not
> create a 'base-container' or 'base-minimal' and leave the traditional 'base'
> alone?
>
There are multiple kernels officially supported. Vanilla, lts, zen, hardened, 
etc.
So it probably was left out of base because they didn't want to force people to 
take the extra step of changing kernels. 

Yaro

Re: [arch-general] Bios Raid (Fake Raid) and Virtual Raid (Software Raid)

[Yaro Kasear]

On 9/3/19 7:26 PM, David C. Rankin wrote:
> On 09/02/2019 08:07 AM, Kelly Rogers via arch-general wrote:
>> Hi,
>> Can you tell me what is capable to do Arch Linux: Bios Raid (Fake Raid) and
>> Virtual Raid (Software Raid)?
>> Thank you!
> Forget fake-raid -- dmraid (though I have used it for years), just use Linux
> software RAID (mdadm). Far more flexible and a guaranteed migration path
> forward. The overhead for software raid was negligible on on single-core 486
> machines, it isn't even in the noise anymore.
>
You can do either in Linux, I believe both work with mdadm. BIOS RAID is
only worth using if you plan to share the array with another OS, though,
like Windows.

Yaro

Re: [arch-general] RAID10 + dmcrypt/LUKS + ext4: expanding?

[Yaro Kasear]

On 10/24/2017 08:53 PM, L. Rose wrote:
> Hi everyone,
>
> I want to setup a couple of drives using RAID10 with mdadm. On top of
> /dev/md0, I want to setup one large dmcrypt/LUKS encrypted ext4 volume.
> As Arch wiki reads, this seems to be possible. But what about expanding
> that volume later on? RAID#Format_the_RAID_Filesystem recommends
> calculating the stripe_width value for ext4 based on the number of data
> disks[0]. When adding a new disk, the number of data disks would
> increase by one, and expanding both the dmcrypt/LUKS and the ext4 layer
> should be possible - but what about the stripe width_value? Does it need
> to be updated? Should it be updated? Is it possible to update the
> stripe_width value afterwards?
>
> Encryption is a must for me, and having the space accessible in one big
> chunk instead of individual disks would allow more efficient usage and
> is therefore important for me. So it would be really nice to get some
> information on this. Thanks in advance!
>
> Regards,
>
> L. Rose
>
> [0]: https://wiki.archlinux.org/index.php/RAID#Example_3._RAID10.2Cfar2
As far as I can tell, the stripe size doesn't have a noticeable impact
on performance. I'd go with a sensible starting stripe size and not fuss
over the stripe size after that. I don't know if you can modify stripe
size after the fact.

Adding onto RAID 10 should be pretty simple as long as you remember you
can only add drives in multiples of 2, since you're mirroring and
striping. Depending on how your RAID 10 is set up you can use mdadm to
add the drives or, if you're using something like Intel Rapid Storage
you could use your UEFI to expand the array with perhaps a little less
confusion.

LUKS should handle the expansion just fine, though I'd recommend putting
LVM in the encrypted mapping so that you can more easily manage volumes
once the LUKS container is unlocked. This way you can have multiple
volumes under one key. LVM also readily expands and shrinks as you need,
which makes things less of a headache.

You could even do a RAID 10-like setup with LVM if I'm not mistaken. I'd
probably do it that way just to avoid the hassle of dealing with
differing RAID formats, plus mdadm isn't as friendly as LVM. I only use
RAID 10 myself because I wanted one big shared volume between Arch Linux
and Windows 10.

Conrad



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Dual boot issue, windows doesn't show up on grub

[Yaro Kasear]

I have found it sometimes helps to mount the "Microsoft Reserved" or
"Microsoft System" partition before running grub-mkconfig. The os-prober
package can be really dimwitted sometimes when it comes to doing scans on
its own like that.



On Tue, Jul 25, 2017 at 2:07 PM, Junayeed Ahnaf via arch-general <
arch-general@archlinux.org> wrote:

> Oh yes, I have that too. Forgot to add that, issued sudo os-prober
> before sudo update-grub but no luck .
>
>
> On 07/26/2017 01:06 AM, Bjoern Franke wrote:
> > Am 25.07.2017 um 21:03 schrieb Junayeed Ahnaf via arch-general:
> >> Hello ,
> >>
> >> I installed arch on my laptop which has 2 hard drives , one is ssd
> (linux is installed there, also grub), one is HDD(with windows). So, at
> boot time , I can select either hard disk or ssd and can get either windows
> or arch. Is there a way for grub to see both Linux and Windows? I tried
> sudo update-grub and  sudo grub-mkconfig -o /boot/grub/grub.cfg but they
> don't recognize windows. My windows is not uefi if that's any issue.
> >>
> >> My linux is on /dev/sdb2 and windows on /dev/sda2 if that's any concern.
> > Did you install os-prober?
> >
> > regards
> > Bjoern
>
>

Re: [arch-general] Weird reaction to pull request over at Arch Linux ARM

[Yaro Kasear]

On Fri, Jan 27, 2017 at 12:27 PM, Christopher Reimer 
wrote:

> Hello list,
>
> I'd like to get some feedback on this pull request discussion over at Arch
> Linux ARM: https://github.com/archlinuxarm/PKGBUILDs/pull/1444 (Backup:
> http://pastebin.com/x8H0mNiE)
>
> Short summary: I wanted to contribute a simple patch to enable support for
> Banana Pi hardware. I tried that a few years back and got besides some
> other concerns the answer that it cannot be added, because at this time
> there were no upstream support and I accepted that.
>
> This is no longer the case, so I thought it must be possible to add
> support now.
>
> I also noticed a few other pull request trying exactly that, which were
> instantly closed by Kevin Mihelich without any reasonable explanation.
> That's why I expected some resistance and prepared myself to
> counterargument a few of his concerns.
>
> And I think I did quite good. Good enough to make him ignore me.
>
> Why am I writing this to the Arch Linux mailing list? Well, for quite some
> time I thought Arch Linux ARM is Arch Linux. And I think there are a lot
> more out there who think so.
> Therefore I think behavior like this could hurt the overall reputation of
> Arch Linux. Especially if a future goal of Arch Linux might be ARM support
> and Kevin Mihelich somehow joins the team.
>
> Did I miss something? Do I expect too much? I don't know.
>
> Thanks
>
> Christopher Reimer
>

This really has nothing to do with the Arch community.

Arch ARM is its own project. Now, I'm not a TU or a developer, but in my
view trying to complain to an upstream project when downstream doesn't do
what a contributor wants reflects more badly on Arch's reputation.

Even if people on Arch cared, what could they even do about it? Are you
expecting the Arch developers to somehow pull some imaginary authority over
the Archlinux ARM project? That'd be even worse to Arch's reputation if
they though they could just boss around forks of Arch.

The maintainer of a project has zero obligation to take on pull requests.
Complaining to Archlinux users about it won't change it, especially when
his response to your whining on his GitHub page was reasonable.

If you don't like it, feel free to fork Archlinux ARM. Nothing's stopping
you. But stopping filling this list with nonsense and your personal
problems with the developers of projects Arch has nothing to do with.

Yaro

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 08:18 PM, Merlin Büge wrote:

Where is /boot physically located? Can grub2 boot from LV these days?

/boot is physically located on my only storage drive in the laptop.
It's not a seperate partition, just on the Btrfs filesystem.



Can grub2 boot from LV these days?

I don't know (nor do I need).


Just to answer: Yes, grub2 can boot from LVM and LUKS. UEFI typically 
requires an open boot partition, but that could just be used to launch 
grub2 which could in turn read things from an encrypted logical volume.


My current computer is a legacy BIOS system (Ugh, I prefer UEFI.) so I 
can put the whole thing in LVM/LUKS no issues, since BIOS doesn't use a 
system partition. Arch's wiki should provide adequate instructions, I 
believe.




Regards

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 08:09 PM, Merlin Büge wrote:

Hi Yaro,


thanks for your answer!



I'd set up two partitions: Your EFI system partition and the LUKS
container. Then inside LUKS, format the whole thing as LVM and then set
up from there, rather than make the LUKS container another GPT "disk."
Then you just use the crypt and lvm2 hooks.

I have no EFI system partition because I don't need one.



My mistake. I assumed you had a typical UEFI setup, which would require one.


You should only really use partition tables on a physical disk, in my
opinion, not a LUKS container.

The reason for this is that LVM works with a lot more flexibility and is
more readily automated than trying to get the system to re-read
partition tables.

Hm. I can see your points. But I don't need the flexibility LVM provides,
I have enough flexibility through Btrfs.
And yeah, it's readily automated, and that's indeed practical for many
people. Personally, I'd rather modify the start-up process a tiny bit
so that GPT inside LUKS gets parsed. I just try to strip off unnecessary
'overhead' / layers of my system.

Okay, then.

Here's my opinion on this approach.

If you have 8 GiB or more and not hibernating, don't bother with swap, 
it'd be a waste of disk space. In that case you could just put a btrfs 
volume straight on the LUKS container without the GPT. Problem solved as 
you don't need any more volume management than opening LUKS containers.


Otherwise WITH swap: Unfortunately btrfs (still) doesn't support swap 
files properly, otherwise I'd suggest using them. You can write a custom 
hook. Unless you plan to share it, I'd make it a dead simple shell 
script that simply reruns the command to scan for added GPT partitions 
for your specific setup. Make sure you have a setup hook that gets the 
dependencies in there.


Personally, I still think you should just use LVM, for the simple reason 
you're having trouble with GPT, which is not meant for being used like 
this, since it can work as a more flexible "partition table" inside the 
LUKS container and is better supported all around. btrfs really doesn't 
act as a good replacement for logical volumes, in my experience. Having 
something with more features than you need is better than trying to 
coerce something into working ways it's not really intended.





If you were on a system where you could add disks [...]

Since it's on my laptop, I don't need that functionality :)


Best Regards,

Merlin

Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way

[Yaro Kasear]

On 11/27/2016 09:48 AM, Merlin Büge wrote:

Hey everybody!


I'm currently installing Arch on my laptop (Thinkpad T400), and have decided
for a rather unusual partition scheme: A single LUKS container directly on
the disk (SSD) with a GPT partition table and two partitions inside it: one for
SWAP, the other one for the system and everyting else, formatted with Btrfs.

The laptop runs libreboot, so I have GRUB2 as a payload inside the flash chip
which I use to decrypt the LUKS container and load a GRUB configfile
located at /boot/grub/grub.cfg (generated by grub-mkconfig). This works fine.


While experimenting with GPT inside LUKS before the installation I've noticed
two issues, with at least one of them being present also after installation:

First, after unlocking the LUKS containter the two GPT partitions don't become
visible to the kernel automatically. I have to manually do
   partprobe /dev/mapper/
to inform the kernel about the two new partitions. partprobe is part of parted.
My idea was to create a custom hook just after the 'encrypt' hook, which would
simply run the above command. I tested this and it seems to work.

Question:
Is there an even simpler solution to that problem? For example an alternative
to partprobe which is already in 'base'?


The second issue was that I could not (after unmounting the Btrfs partition and
deactivating the swap partition of course) directly close the LUKS mapping via
   cryptsetup luksClose 
It gave me:
   device-mapper: remove ioctl on  failed: Device or resource busy
   [...]
   device-mapper: remove ioctl on  failed: Device or resource busy
   Device  is still in use.

Instead, I had to remove the partition mappings first via
   dmsetup remove 1 2
This was getting me rid of the aforementioned error messages.

As expected, I get these error messages also during system shutdown -- but only
whith the shutdown hook in initramfs. Without it, I presume the system does not
even try to close the LUKS container (which would make sense, since there is no
initramfs created by default for shutdown afaik), therefore also resulting in
no error messages being shown.

What could I do about this?
I'd like to have my system closing the LUKS container correctly -- therefore I
need to remove the partition mappings before that.


I've read a lot in the last days and weeks about Btrfs, SSDs, coreboot, etc. to
make sure I don't run into many issues. Though these two don't come unexpected,
I don't know how to solve the latter one, because systemd shutdown and shutdown
initramfs are still a little miracle to me...

I'd really appreciate any help!

This is all on an up-to-date vanilla 4.8.10-1-ARCH.
I attached two shutdown logs with debugging enabled: one with and one without
the shutdown hook applied. They look very similar though. (I made sure to reboot
twice after building the initramfs before taking the shutdown log.)
My HOOKS array is:
   HOOKS="base udev autodetect modconf block keyboard keymap encrypt pp \
   filesystems fsck shutdown"
(pp being the hook which runs partprobe against the mapped LUKS container)


Best Regards,

Merlin



Hi Merlin,

I'd set up two partitions: Your EFI system partition and the LUKS 
container. Then inside LUKS, format the whole thing as LVM and then set 
up from there, rather than make the LUKS container another GPT "disk." 
Then you just use the crypt and lvm2 hooks.


You should only really use partition tables on a physical disk, in my 
opinion, not a LUKS container.


The reason for this is that LVM works with a lot more flexibility and is 
more readily automated than trying to get the system to re-read 
partition tables.


If you were on a system where you could add disks, I'd even suggest 
reversing it: LVM on the metal and LUKS on a logical volume spanning the 
whole VG, that way you could grow the whole thing across multiple disks 
pretty easily without having to make any dramatic changes. I know btrfs 
can do multiple disks, but I've always preferred how LVM does it, honestly.


Yaro

Re: [arch-general] Opinions on PowerShell?

[Yaro Kasear]

Consider also that getting PowerShell doesn't solve the "how do I" 
problem. People who don't know PS would still have to look up how to do 
the same thing on there. If you're already familiar with Linux, and 
chances are you are if you're using Archlinux, then PowerShell won't 
solve any problems for you in almost every case.


It's neat that PowerShell is ported now, but I do scratch my head and 
wonder what niche it will fill that would merit anything more than 
placement on the AUR.


Conrad

On Fri, Aug 19, 2016 at 4:33 PM, Ralf Mardorf  
wrote:

www.my-favoured-search-engine.com

Search term:

  linux shell how to do this and that

If you don't know how to find the size and name of the three largest
files in a directory, but only of those files that have a size value
that is a prime number in MiB and a file name that does contain the
letters "a" and "f", but does not include the numbers "3" and "6", you
more likely will find hints how to do this by common used Linux and 
BSD

tools, than hints how to do this with a Microsoft shell.

This is not an argument pro or con PowerShell. I don't care
if it is in a repo or not. I just wonder about arguing pro PowerShell
by providing examples that are solvable by either already having the
Linux knowledge or by using a search engine with the keyword Linux, to
get Linux knowledge.

Re: [arch-general] Error message with full disk encryption

[Yaro Kasear]

On Sat, 2016-02-13 at 13:47 +0100, Carsten Mattner wrote:
> On Sat, Feb 13, 2016 at 10:49 AM, PeLo L  wrote:
> > 
> > Hi,
> > 
> > 
> > I've followed the arch wiki and deployed a full disk encrypted
> > install.
> > Everything works fine and am able to boot properly into the
> > install.
> > While trying to shutdown my system, systemd displays an error
> > which says "systemd: stopped (with error)  /dev/mapper/crypt-boot".
> > 'crypt-boot' is the device mapper name for the encrypted boot
> > partition. Could someone explain this. Do I need to be concerned
> > of any data loss in the boot partition?
> 
> I've seen this on old and newly installed root-luks systems myself.
> Here it's always dm1 and I'm not sure if it's luks-root or luks-swap,
> but it looks like a bug in systemd or one of the units because this
> appeared sometime in the last 6 months or less.

I have also seen this issue come up on my system. It doesn't seem to
affect anything except causing a slightly longer shutdown time. Still,
would be good to see this fixed.

Re: [arch-general] Alternative init system proposal

[Yaro Kasear]

I still don't get what makes OpenRC so great. Doesn't it still depend
entirely on SysV Init? That ALONE makes me want to keep it off my system.
If it makes us fall back on an init system that is frankly backward and was
badly in need of replacement then I don't see why it should be considered
an alternative.

Systemd ain't perfect, but when the best alternative is something that
relIes on dated components bona fide Unix systems don't even use anymore,
then they simply aren't alternatives.
On Feb 7, 2016 11:36 PM, "Leonid Isaev" 
wrote:

> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> > Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> > process that does not happen overnight. Through time, solutions will
> > surface. I'm not a magic lamp genie that has all the answers.
>
> Then you have to ask yourself, what defines a distribution. If you are
> going to
> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce
> customizations
> to lots of other packages, isn't it easier to start from gentoo or alpine
> and
> maintain pacman for those distros? I am asking because you are going to
> duplicate a fair share of official repos...
>
> Cheers,
> --
> Leonid Isaev
> GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
>   C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
>

Re: [arch-general] libreoffice not work

[Yaro Kasear]

It seems like bad form to enable unstable features for a package in
[extra]. Shouldn't it be set to enable the GTK2 VCL by default?

Yaro

On Tue, 2015-10-13 at 11:51 +0800, mudongliang wrote:
> 
> On 10/13/2015 11:38 AM, Jens Adam wrote:
> > Tue, 13 Oct 2015 11:29:18 +0800
> > mudongliang :
> > 
> > > $ libreoffice
> > Have you read the note from the last update?
> > https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h
> > =packages/libreoffice-
> > fresh=dad0330304d72dcc0cb01b209dad0e83308bfdc0
> I have seen this url, it's great tip. I have uncommented the gtk2 in 
> /etc/profile.d/libreoffice-fresh.sh.
> 
> #export SAL_USE_VCLPLUGIN=gen
> #export SAL_USE_VCLPLUGIN=kde4
> export SAL_USE_VCLPLUGIN=gtk
> #export SAL_USE_VCLPLUGIN=gtk3
> 
> Is this right?
> > 
> > > version not matchs here.
> > What?
> > 
> > > There are no enough error tips
> > The forum is full of libreoffice threads:
> > https://bbs.archlinux.org/search.php?action=search=libreof
> > fice=_in=-1_by=0_dir=DESC_as=topics
> I don't frequently go to the forum, only subscribe the mailing list. 
> Maybe I should go there often.
> Thanks.
> 
>   - mudongliang
> > 
> > --byte
> > 
> > 
> > 
> > 

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

On Jul 3, 2015 6:10 AM, LoneVVolf lonew...@xs4all.nl wrote:

 Some general comments :

 - Openrc is a replacement for sysv init, not an addition.


OpenRC runs on SysV Init last I checked, as OpenRC is just highly polished
initscripts. How is that a replacement instead of an addition?

 - openrc has it's own equivalent of .service files, they are simpler then
systemd servicefiles.

I admit I have not looked at OpenRC service files. But systemd units are
barely even 6 lines not counting empty lines.

 - my personal opinion about openrc is that it's not mature enough yet for
majority of linux users to replace systemd

My opinion is because it stoll relies on things Linux desperately needs to
be rid of. Systemd has the advantages of both actually ridding us of SysV
Init snd ysing vsrious kernel features OpenRC simply can't do to being
initscripts.

 The majority of Arch users however should be capable enough to use it
efficiently.


I have no argumemt here. But I still feel systemd is the better option.

 - systemd has many good things, but also many flaws.


OpenRC does too. Not the least of which is that it is not actually an init
replacement. Make OpenRC an independent init system then it will be a
serious contender.

 This blog post gives the best description of systemd flaws i am aware of :
 http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

I will look this over. But I have already seen a bunch of systemd rants
over the years snd they always boil down to the same points:

1. Unix philosophy, as if it was some sort of gospel when even most bona
fide Unix systems don't even follow it any more.
2. Feature creep, about the only legitimate gripe I have seen.
3. Blaming the decisions of other projects bad decisionmaking on systemd.
GNOME 3 is a classic example.
4. Change Is Bad (tm), usually taking the form of the commentator wanting
to cling to initscripts.


 LVV

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

I can't overtly fault the logic in that blog post for the most part.
However he does still basically toe the Unix philosophy line (Talking
about modularity and such.)

The thing that bothers me most about this document though is how he
dismisses systemd's legitimate, if not unique, features as propaganda. He
also tends to talk about flaws in how systemd is written but doesn't seem
to explain that, go into rants about Poettering not long after dismissing
one of the common statements being you just hate systemd because
Poeterring, etc.

I must be that rare breed of systemd supporter who actually actively
DISLIKES Poettering. When he started Pulseaudio and it started breaking
everyone's sound, he went into a mantra of ALSA's broken instead, despite
the fact ALSA, even standalone, worked just fine without PA. That said I
now use Pulseaudio, because once it matured it stopped breaking sound as
much. I'm not a fan of how it demands to own all sound on the system, but
I can get over that.

Add point 5, though, to the typical anti-systemd rants when boiled down: 5:
I hate Lennart Poeterring.

Re: [arch-general] systemd new dependencies impede using OpenRC

[Yaro Kasear]

I personally prefer systemd over the alternatives. I grant there's
considerable feature creep, but the people who complain a lot either don't
offer an alternative, or the one alternative they offer is the frankly
broken system Linux had been using since the dawn of time.

I wouldn't mind some spiritual successor to systemd where its entire
purpose is to be init, without sacrificing some of the more useful/powerful
features like cgroups, concurrency, and the like. Systemd went wrong when
it started going into stuff that init itself really doesn't need to manage
on its own.

SysV Init needs to die, let's move on. OpenRC is not enough to save it.

On Thu, Jul 2, 2015 at 10:49 PM, Bardur Arantsson s...@scientician.net
wrote:

 On 07/03/2015 12:19 AM, Daniel Micay wrote:
  WHAT? The opinion of users has no weight here ?!?!?!
 
 [--snip--]

 Just to add a little bit to what Daniel said: Can we please calm down a
 bit here?

 It's not like there's no overlap between what developers want and what
 ordinary users want -- in fact there seems to be rather a lot of overlap
 given the number of users Arch has. Remember that developers are users too!

 (P.S. I'm not a developer/packager just an ordinary user.)

Re: [arch-general] Problems using AUR since upgrade of pacman db version

[Yaro Kasear]

On 01/01/2015 10:41 AM, Rich wrote:



On 01/01/2015 10:27 AM, Troy Engel wrote:

On Thu, Jan 1, 2015 at 10:12 AM, Geoff capstho...@yahoo.co.uk wrote:
Not intending to contradict, but rebuilding cower worked for me.  I 
used a
clean tarball and did makepackage --skipinteg (see the discussion 
under cower

in the AUR)


Same here on multiple systems. The pacman upgrade replaced libalpm.so
from .8 to .9, you'll probably need to run 'pacman-db-upgrade', then
rebuild/reinstall cower (another thread also mentioned package-query,
which backs yaourt). If you're using pacaur there's an update for that
as well which adds the prevent-as-root check to align with the new
pacman 4.2 restriction.

hth,
-te


The procedure described here, 
https://aur.archlinux.org/packages/package-query/ worked for package 
-query and pkgbrowser.


yaourt users will need to rebuild package-query as well, even though 
yaourt itself is a shell wrapper.

Re: [arch-general] bacman failed to set file flags bsdtar error

[Yaro Kasear]

On 07/16/2014 02:50 AM, Ralf Mardorf wrote:
 What's the meaning of this [1]?

 Regards,
 Ralf

 [1]
 $ bacman ardour
 == Entering fakeroot environment
 == Package: ardour-2.8.16-1
   - Copying package files...
 etc/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/bin/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/lib/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/applications/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/cs/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/de/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/el/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/es/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/eu/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/fr/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/it/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/pl/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/pt/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/ru/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
 usr/share/locale/sv/LC_MESSAGES/: Failed to set file flags
 bsdtar: Error exit delayed from previous errors.
   - Generating .PKGINFO metadata...
   - Generating the package...
 == Done.

Wild guess? This needs to be run with root priviliges, such as through sudo.

Conrad

Re: [arch-general] Troubles with ALSA

[Yaro Kasear]

On 12/31/2012 11:07 AM, Jack Stanek wrote:

Hello all,
I've been having problems with ALSA recently. Whenever I reboot my computer or 
wake it up from sleep, ALSA sets the volume of the speakers (and only the 
speakers) to zero. The headphones and master volume remain normal, but no sound 
will come from the speakers until I manually go into alsamixer and turn up the 
speaker's individual volume. I have an Intel integrated audio card, the 82801H 
HD Audio Controller.
This only started recently and I am at a loss as to what is going on. Any help 
would be greatly appreciated.
Many thanks,
J. Stanek
I believe you have to use the command alsactl store as root. Your 
volume levels are not usually automatically saved.

Re: [arch-general] Archlinux is for everyone

[Yaro Kasear]

On Saturday, July 09, 2011 01:11:22 PM Kyle wrote:
 Apple devices stopped looking appealing to me when people around me
 started getting them and I found out how much control Apple has over
 what people do with their devices, especially i-devices, iPod, iPad,
 iPhone, etc. And now that they have brought their twisted concept of an
 app store to MacOS, they will start controlling desktops and notebooks
 in the same way most likely. Heck, even Microsoft doesn't try to take so
 much control of a computer as Apple does.
 

(snip)

For me it was that, and the fact Apple has a ridiculous markup on products 
that bring less features and capability. I never bought into the iPhone hype, 
finding I could do more with my ancient Treo and now, my Droid. 

The macs are a disgrace. Why should mid-range PCs be priced like top-of-the-
line gaming rigs? 

 ~Kyle

Re: [arch-general] fbsplash fails to start after pacman -Syu

[Yaro Kasear]

On Tuesday, July 05, 2011 09:31:56 PM Madhurya Kakati wrote:
 Hi,
 After a recent system upgrade fbsplash fails to run during boot. However
 while shutting down i can see the splash. Its only during the start up
 that I can't see it.
 This is the /var/log/boot some days before the upgrade
 http://pastebin.com/EbdYYb32
 and this is the log after the upgrade http://pastebin.com/MkxLbRsT
 
 Please notice the
 /etc/rc.d/functions.d/fbsplash-extras.sh: line 780:
 /lib/splash/cache/steps_sysinit: No such file or directory
 and
 /etc/rc.d/functions.d/fbsplash-extras.sh: line 795:
 /lib/splash/cache/steps_sysinit: No such file or directory
 and
 /etc/rc.d/functions.d/fbsplash-extras.sh: line 796:
 /lib/splash/cache/steps_bootup: No such file or directory
 errors that occur during boot(after upgrade). These didn't occur before.
 Also after booting i did ls in the /lib/splash/cache dir and found that
 the files are already there in the dir.
 Thanks.

When is the last time, as root, you ran mkinitcpio on your kernel?

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 05:33:50 PM Oon-Ee Ng wrote:
 On Wed, Jun 22, 2011 at 4:01 AM, Dan McGee dpmc...@gmail.com wrote:
  Please welcome Dave to our development team. He has been a frequent
  contributor (and reviewer of patches!) to Pacman, has been a TU for a
  little bit, and has taken initiative on a lot of
  initscripts/mkinitcpio/systemd type stuff. I think I've given him all
  the right permissions and such, and signed him up for the relevant
  mailing lists.
  
  -Dan
 
 Systemd to come? =)

Having given systemd a try, I hope not. For some reason it wouldn't make sure 
my /home was mounted. I can't count on that.

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 06:08:03 PM Thomas S Hatch wrote:
 On Tue, Jun 21, 2011 at 5:07 PM, Yaro Kasear y...@marupa.net wrote:
  On Tuesday, June 21, 2011 05:33:50 PM Oon-Ee Ng wrote:
   On Wed, Jun 22, 2011 at 4:01 AM, Dan McGee dpmc...@gmail.com wrote:
Please welcome Dave to our development team. He has been a frequent
contributor (and reviewer of patches!) to Pacman, has been a TU for a
little bit, and has taken initiative on a lot of
initscripts/mkinitcpio/systemd type stuff. I think I've given him all
the right permissions and such, and signed him up for the relevant
mailing lists.

-Dan
   
   Systemd to come? =)
  
  Having given systemd a try, I hope not. For some reason it wouldn't make
  sure
  my /home was mounted. I can't count on that.
 
 systemd is awesome, but I think the core should stay as lean as possible.
 In the future systemd may replace the systemV stuff, but for the time
 being I think there is little motivation to add it by default, Keep It
 Simple Silly

I also agree with this, but I wanted to avoid saying it lest we get into 
another debate about systemd on here. But yes, systemd does seem to go against 
the grain of the UNIX Philosophy and the Arch Way.

Re: [arch-general] Systemd! [WAS: arch-dev-public] Welcoming Dave Reisner to the dev staff

[Yaro Kasear]

On Tuesday, June 21, 2011 07:56:25 PM Bernardo Barros wrote:
 here too :-)

+700 on this.

Re: [arch-general] weird problem

[Yaro Kasear]

On Sunday, June 19, 2011 11:59:00 AM Madhurya Kakati wrote:
 On 06/19/2011 10:13 PM, Mauro Santos wrote:
  Really silly questions:
  - Are you using any repos other than [core], [extra], [community] and
  [multilib]?
  - Are you using any pacman wrappers?
  
  I'm asking because pacman can't find anything to do with catalyst here
  and I'm using all the above mentioned repos so I don't see how using the
  official repos could cause that. If you are using other repos (or pacman
  wrappers, that as far as I know are not supported) you should know what
  you are doing so you how know how to deal with these kind of conflicts
  and possible breakage that might happen.
 
 Yes I am using catalyst repo.
 I use yaourt but thats not a pacman wrapper I guess.

yaourt is a pacman wrapper. Specifically it's a pacman/abs/aur/makepkg 
wrapper.

Re: [arch-general] netcfg 2.6 release

[Yaro Kasear]

On Sunday, June 19, 2011 04:23:45 PM Rémy Oudompheng wrote:
 Hello,
 
 netcfg 2.6 has been released and pushed in [testing].
 
 The following features has been added since the last release:
 - add support for IPv6 configuration (FS#18699)
 - add support for static routes configuration (FS#18700)
 - add support for creating tun/tap interfaces (FS#15049)
 - add configuration file /etc/conf.d/netcfg for net-auto-wireless
 - add support for restricting automatic startup of profiles (FS#23169)
 - bridge: add support for several brctl options (FS#16625)
 - wireless: add support for explicit BSSID (FS#24582)
 - wireless: add support for ad-hoc connections (FS#19683)
 - wireless: no longer require wireless_tools to work
 - use /run instead of /var/run
 - drops hard dependency on net-tools package
 - drops hard dependency on wireless_tools package
 
 Most importantly:
 - netcfg no longer puts no files in /run (dhcpcd still puts files there)
 - netcfg only depends on iproute2 and dhcpcd : wpa_supplicant is
 optional (required for wireless), wpa_actiond, ifplugd are required
 for net-auto* scripts
 - net-tools, wireless_tools are needed if you use legacy options
 IFOPTS and IWCONFIG, but this is strongly discouraged
 - /etc/conf.d/netcfg is a new configuration file, currently only used
 by net-auto-wireless: it is used to configure the name of the wireless
 interface you want to use (also possible in /etc/rc.conf, but
 discouraged), and to configure a list of preferred networks you want
 wpa_actiond to manage (FS#23169)
 - IPv6 is supported: no address configuration (even
 auto-configuration) will be done unless you say IP6=something in your
 profile. See the examples to see how it works
 - dhclient is needed if you want to support DHCPv6: this is expected
 to be an uncommon case, since auto-configuration exists.
 - netcfg can create tun/tap interfaces: it currently does not do
 anything with these (FS#15049)
 
 Regards,

I'd like a minor clarification here... I've never seen a directory called run 
on /. Is netcfg expected to create that? Does the FHS support that?

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Saturday, June 18, 2011 04:57:07 AM Richard Schütz wrote:
 Am 18.06.2011 11:29, schrieb Martti Kühne:
  On Sat, Jun 18, 2011 at 10:03 AM, Richard Schützr.sc...@t-online.de  
wrote:
  Am 18.06.2011 09:08, schrieb Dan Vratil:
  I don't think so. Epiphany is based on WebKit these days. And because I
  can trigger the bug in EOG (Eye of GNOME) it doesn't look like a
  browser problem for me at all.
  
  Perhaps it is a problem of GTK together with nvidia 275.09.07. I tried
  feh (a simple X11 image viewer that doesn't use GTK or Qt) and it works
  fine without flickering, artifacts or something else strange.
  
  --
  Regards,
  Richard Schütz
  
  Update, I also see anything but the picture when the bug occurs,
  namely random garbage. I can confirm that feh, launched the regular
  way does not trigger the bug, although, also I have to confirm that
  display (imagemagick-6.6.9.8-1) actually does trigger the bug.
  Actually my guess is feh restricts itself to become larger than the
  screen's resolution (which is smaller than 2047 here) and thus is just
  not storing the full resolution image in video memory. I just managed
  to something like trigger the bug, X hang for about 4 seconds here and
  will display some garbage, with
  
  $ feh --geometry 2047x1529 nvbugy7cd.jpg
  
  heh, after trying this several times, the hang disappears. Might this
  be related to caching?
  
  cheers!
 
 Yes, you are right: display crashed my X server right now. So this seems
 to be even unrelated to the toolkit.

Okay, so, has anyone filed a bug report with nVidia?

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Friday, June 17, 2011 12:55:01 PM Ionut Biru wrote:
 On 06/17/2011 08:46 PM, Pico Geyer wrote:
  Hi all,
  
  As the title of this email suggests I'm having trouble with the new
  Nvidia driver.
  I've attached my Xorg log, as I'm sure that there are a log of people
  who understand the ouput better than I do.
 
 attachments doesn't work on this list
 
  I've had to revert to the previous driver (270.41.19-3) to get my
  system up and running again.
  What seems odd to me from the log is that it doesn't even try to load
  the nvidia driver.
 
 if it doesn't load the driver it means you don't use our xorg-server.
 
 for 275.09.07 i dropped the configuration that comes with it because now
 is loaded by xorg-server
 
 !next

Would be nice if you could actually be specific about your problem. Is Xorg 
not working? Is it freezing? Also, no attachments on here.

Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)

[Yaro Kasear]

On Friday, June 17, 2011 05:35:06 PM Martti Kühne wrote:
 snip
 
  Are we sure ths is a bug with the nVidia driver? Can someone load that
  image
  who isn't using it?
 
 confirming display screwage with firefox on an onboard nvidia chip. nasty.
 02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce
 8200] (rev a2)
 
 cheers!

Unfortunately I can confirm, though X didn't crash or flicker. What I saw was 
visual data from everything else *but* the image.

I hope that might help with a bug report to nVidia besides flicker and 
crash.

Using latest nVidia driver with a GeForec GT 240.

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Thursday, June 09, 2011 21:22:50 Timothy L. wrote:
 On Thu, Jun 9, 2011 at 9:25 PM, C Anthony Risinger anth...@xtfx.me wrote:
  On Jun 9, 2011 5:50 PM, Heiko Baums li...@baums-on-web.de wrote:
   Am Thu, 9 Jun 2011 17:36:21 -0500
   
   schrieb C Anthony Risinger anth...@xtfx.me:
   does this sound genius or completely insane? some insanely genius guy
   once said they are only separated by a fine line ...
   
   Sounds completely insane.
  
  ook ... and ... why?
  
  ) initramfs is not very big (fallback on my sys is only 13MB + 2MB kern)
  ) keeps the whole thing in mkinitcpio
  ) does not affect any current images and is even backward compat
  ) small chance of absolute failure (i think :-)
  ) only small changes to mkinitcpio, if any at all
  ) ...
  ) ... KISS BABY!
  ) oh yeah and ... PROFIT!
  
  im pretty sure it could be implemented as a hook (possibly 2) to the
  current system ... this might even be the best way.  `install` hook
  would unpack the current image to a known location (prob
  `/lib/initcpio` somewhere), copy the kernel to the same place, and
  then add the directory to the image (after removing the old-old image
  if existed :-).  the real `hook` would then check for one of two
  flags:
  
  ) kexec.flag ... kexec the old kernel with the boot.flag
  ) boot.flag ... chroot to previous, run old hooks/mods/etc, exit
  chroot, switch_root like normal
  
  i thought it was pretty succinct ... elegant even :-)  ... with some
  sprinkles of insanity that give it the funny but mildly enjoyable
  aftertaste.  i don't have any free time for a couple days, but i'm
  *pretty* sure this could be done as a hook to the current mkinitcpio
  in a couple hours -- might take a whack at it this weekend, would be
  useful, as i've personally mucked my boot more than once, and though i
  can recover easily enough, i'm liking this more and more ...
  
  ... though i could very well be missing something obvious, certainly
  wouldn't be the first time ... surely someone out there reads this and
  thinks why not?
  
  C Anthony
 
 Keeping the previous kernel after upgrading sounds sane to me. For the
 apprehensive, couldn't we just include a simple configuration option/check
 somewhere?
 
 /etc/mkinitcpio.conf
 KEEP_PREVIOUS_KERNEL=yes
 
 I've read most of this thread but please excuse me if this has already been
 mentioned.

I'd accept that solution just so long as the default is set to no and not 
yes. Most Arch people don't want old kernels. 

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Friday, June 10, 2011 04:26:21 Robert Howard wrote:
 Why not just copy the old kernel image, modules and initrd image somewhere
 by hand before you upgrade kernels. If we try to make this automated it
 isn't going to be kiss. I used to do this way back in the day by including
 the entire kernel version in the pkgver and giving the images longer names.
 It was possible to have concurrently installed kernels. Check out how some
 of the AUR kernels manage to be the same kernel version as the official
 without causing issues.

+1 on this. If you really need the old kernel, why not make sure you back up 
the old one and its image before upgrading instead of inconveniencing other 
users and the developers for a feature only a minority even wants?

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Friday, June 10, 2011 05:48:57 Vic Demuzere wrote:
 On Jun 10, 2011 12:43 PM, Martti Kühne mysat...@gmail.com wrote:
  On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger anth...@xtfx.me
 
 wrote:
  snip
  
   what if we (optionally) stored the original images _inside_ the new
   one?  the new/bad kernel would boot, and via some bootloader entry eg.
   kernel param the new initcpio script would kexec the old kernel, with
   another (different) kernel param ... when the old kernel booted it
   would load the exact same initramfs image, except it would use an
   alternate tree, ie. instead of /init it would chroot to /previous and
   run /previous/init ...
  
  eh, for the priority of known sources of error: an UPDATE image could
  contain the NEW kernel in an alternate tree /new/init, because the OLD
  kernel is KNOWN to boot that far...
  
  Anything else would be insane.
 
 Having multiple kernels is insane. I don't get why it's needed. There is a
 live cd to rescue your system if needed.
 
 Vic

Another agreement from me here. Also, may I also add that a great deal of Arch 
users have /boot in a (tiny) partition to start with and can't really KEEP 
that much stuff in there? Keeping old kernels would definitely screw their 
systems up and keep them from upgrading with any ease.

Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)

[Yaro Kasear]

On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote:
 On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos
 
 registo.maill...@gmail.com wrote:
  Arch users have lived without the last good known kernel so far and
  without an -lts kernel until recently.
 
 this applies to technology in general -- we don't need any of it, but
 forward we move nonetheless.
 
  IMHO it is a lot more advisable
  to have an install cd/usb, or even better, a custom install in some
  external media that can be used to boot the system in case something
  goes wrong or in case of emergency. Then you can just chroot into the
  broken install and fix the problem or tell pacman where the root and
  cache are located and fix things.
 
 why is that simpler/advisable?  now you need to mount everything
 properly by hand else things like autodetection fail in mkinitcpio,
 etc.  i don't think it's hard to recover, and i would never have any
 of these issues, but i think a *real* recovery shell is not a bad idea
 ... why add more work for me the human when the machine could get me
 95% the way there?  and offer some options even?
 
 On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook jtw...@ttlc.net 
wrote:
  The only reason to even consider keeping an old kernel around with Arch
  was just in case the new kernel is effectively borked... (possibly due
  to a hardware incompatibility...) And if I remember right, you said
  something about this not working if the new kernel can't boot...
 
 you wouldn't want to boot it past the final step, ie. you don't want
 to actually switch_root into your / device and continue the boot
 process ... however, at that moment, you have:
 
 ) booted a good kernel
 ) have all autodetected modules available (possibly not loaded tho)
 ) ... and (IIRC) -fallback version has the full module tree if needed
 ) loaded your last configuration of initcpio hooks/etc
 ) ... which means your / is probably mounted properly, even with
 encryption and other exotics
 ) other filesystems like /dev /sys are mounted, --move'd, and ready to
 go on the new_root
 ) the whole system is poised for regular boot
 
 ... so initcpio script *could*, if aware of your dilemma:
 
 ) drop to shell immediately with some helpful info
 ) chroot for you into /new_root (your real system)
 ) ... maybe bind mount the module hierarchy into new_root to prevent
 accidental loading of wrong mods (if that's even possible, not sure)
 
 ... basically just bring you 95% the way there, then let you fix it
 and reboot ... done.
 
 On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook jtw...@ttlc.net 
wrote:
  It would appear that on Jun 10, Robert Howard did say:
  Why not just copy the old kernel image, modules and initrd image
  somewhere by hand before you upgrade kernels.
  
  That wouldn't be such a bad idea. And in fact I already do that with the
  kernel and initrd image.
 
 and that option will always be available ... but any trivially
 repetitive procedure requiring consistent user interaction is a poor
 solution IMO, if even worthy of being called a solution.  definitely
 an exaggeration, but why even have timed scripts a la cron, or a
 packaging system at all, when we could just remember to do stuff?  why
 not boot the system by hand :-)?  probably because these automata
 improve consistency and reduce the likelihood of errors ... we suck at
 being computers :-)
 
 http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm
 
  * CRS : Can't Remember Sh^Htuff
 
 ha nice ... i've never heard anyone else say/use this (CRS acronym)
 ... my grandmother has been telling me that since i was a kid -- i
 always thought she made it up :-) -- one of those independently
 discoverable things i suppose.
 
 On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums li...@baums-on-web.de wrote:
  Am Fri, 10 Jun 2011 21:21:17 -0400
  
  schrieb Joe(theWordy)Philbrook jtw...@ttlc.net:
  Now that, Heiko, is a good idea. And one that I could actually do.
  I'd just have to decide which of my other Linux distributions to
  sacrifice to make room for it... Keeping in mind that as you say:
  those cases in which an updated kernel is unbootable are very, very
  rare. I think I'd rather learn how to use the pacman -U method...
  
  Would at least be less work.
 
 how is installing another distro that you may never use easier?  you'd
 still have to go thru the whole manual recovery process.  LiveCD beats
 this any day for me -- i rarely install anything these days because my
 distro-hopping abruptly ended with Arch :-) (though i do check them
 out from time to time, or for work related things)
 
 --
 
 and the end of the day people just want to reinstate a useable system
 as rapidly as possible.  we can yammer on and argue that the user
 should not be using testing then, should be making full backups,
 should have/know an alternate recovery plan, should be manually
 backing up kernel related stuff, should be awesomely l33t with linux
 by 

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Thursday, June 09, 2011 05:31:06 Paul Gideon Dann wrote:
 On Thursday 09 June 2011 00:04:09 Heiko Baums wrote:
  schrieb Oon-Ee Ng ngoonee.t...@gmail.com:
   Such a patch would also have to copy the modules (which aren't under
   kernel26's 'purview'). For example, nvidia gets upgraded on a major
   version kernel update, the old kernel which has been renamed doesn't
   'work' graphically anymore.
 
 Yeah, I think this is starting to go beyond what can sensibly be
 implemented in the install script.  I'm putting my voice behind versioned
 kernels.  If we can define the number of old kernels to keep in rc.conf,
 that idea is actually a superset of my desire to keep a pre-upgrade
 kernel, without cluttering /boot too much.
 

Keeping a single old kernel non-lts, clutters /boot in my opinion. 

  The old kernel image is just to get the system
  booted to being able to repair the system (downgrading the kernel
  package again or whatever). The modules shouldn't be necessary for this.
 
 I'm afraid I don't agree with this; I'd like to be able to boot to a fully-
 usable system from the pre-upgrade kernel, in case the new kernel is
 broken.
 

The fallback image and LTS kernels cover this base well enough that we don't 
need 'pre-upgrade' anything. 

  I'm using Arch Linux for about 4 years now and before then I was using
  Gentoo for about 6 years. I never had one single issue with a kernel
  upgrade particularly not such an issue which caused a boot failure.
 
 Well, it's happened to me, and it *could* happen to you.  Better to prevent
 the situation, don't you think?
 

Again: Purpose of fallback image and lts kernel. Jacking up /boot with dozens 
of old kernels is not a needed or desirable solution.

  If this really happens - in the very rare cases - then it's always
  possible to boot from a LiveCD.
 
 This is what I've always had to do, but I don't like the idea of relying on
 always having my LiveCD handy.  LTS gets around this, but it doesn't feel
 like the correct solution to a failed upgrade; more of a workaround.
 

Keeping old kernels is more of a workaround than officially supported lts 
kernels or using a LiveCD.

  If someone is really so afraid he can easily install kernel26-lts or
  another kernel package and, of course, he definitely shouldn't use the
  [testing] repo.
 
 Unfortunately, my new laptop has a buggy UEFI implementation and will only
 boot 3.0.rc1 or newer.  Who knows if my hardware will fail to boot with the
 next release?  This worries me, so I'd like to have known-to-work kernels
 lying around just in case.
 
 Paul

Arch development should never be centered around compensating for users' 
crappy hardware. There are ways to fix UEFI without annoying the other users 
of Arch with cluttered boot partitions. If you want old kernels that badly, 
use lts or go to a distribution that implements this bad feature.

Re: [arch-general] After the recent linux kernel update booting fails if usb disks are present in /etc/fstab

[Yaro Kasear]

On Monday, June 06, 2011 07:39:03 Hector Martinez-Seara wrote:
 Thanks Tom for taking your time to answer,
 I will follow your advises to try to stabilize my system. I will try
 to downgrade my system also. If I see that this helps I will let you
 know, just in case this is a bug an not a simple speeding problem.
 Thanks again,
 Hector
 
 On 6 June 2011 15:25, Tom Gundersen t...@jklm.no wrote:
  On Mon, Jun 6, 2011 at 1:49 PM, Hector Martinez-Seara hse...@gmail.com 
wrote:
  Which information exactly do you need? I can provide you any
  information you may require if you explain me how to gather it (I'm
  not as good as most of you).
  
  As far as I can tell, the problem is as described below (i.e., this is
  not a bug), so no need to look for more info. However, if you disagree
  with my analysis and think there really is a bug somewhere then I
  would need to know what version of what package (probably udev or
  initscripts) made the problem worse. To figure this out you would have
  to downgrade the package you think it is, verify that one version
  works fine and that the next does not (without changing anything else
  on your system).
  
  Regarding testing. I don't want to use testing in this computer as it
  has some sensitive data.
  
  That's ok. The packages will move to [core] soon.
  
  Regarding non mounting at boot it is rather not a good option. First,
  I like my disks to be check up periodically, this is fairly well done
  at boot. Second, This is a file server besides a desktop, so not
  always kde/gnome... are in use. I really think it is redundant to have
  to use another tool than fstab to mount disks only for the seek of
  speeding up the boot process.
  
  Hopefully there should be some daemon out there that does not require
  a gui, and can work with fstab (I haven't used such a thing before,
  but I'm sure they exist). As mentioned below systemd certainly would
  fix this issue, but that is a rather intrusive change, as it replaces
  your whole init system.
  
  I really don't see the point of speeding the things up if they make
  everything else unstable. I honestly think that we are trying to build
  a house starting from the roof. First stability and then if possible
  speed.
  
  I agree in principle that stability comes before speed. In this case
  however, it was never stable in the first place. It just so happened
  that it worked for you.
  
  The way it works at boot is that we wait for all disk devices (and
  other devices) to be enumerated before we start fsck'ing and mounting
  (this is the call to udevadm settle you can see in rc.sysinit).
  However, settle will not wait for your usb devices to become read.
  This is why:
  
  The problem is that we do not know how many usb devices you have
  attached to your computer, so we don't know how many to wait for
  before continuing (this is not the case for other kinds of devices
  like pci). Furthermore, we don't know how long it will take to
  enumerate all usb devices. In other words there is never a point in
  time when we know that all usb devices are ready.
  
  Obviously, the slower your boot, the more likely you are to be lucky
  and have all your usb devices ready when you need them. While I don't
  want to randomly slow down boot for everyone on the off-chance that it
  might make some usb devices work more often, there is a way you can do
  this yourself:
  
  You can make rc.sysinit wait an arbitrary amount of time after udev
  has settled (how long to wait you should figure out by
  experimentation, I would suggest adding a few seconds to what you
  think is needed to make room for future boot speedups). If you put the
  attached (untested) file in /etc/rc.d/functions.d/ it should do the
  trick (for more details how this works look at the commens in
  /etc/rc.d/functions), though you might wan to adjust the sleep time.
  
  
  
  Lastly: initscripts fundamentally relies on your system being
  statically configured with no devices coming and going. USB is
  fundamentally dynamic, in that there is no difference between having a
  devices plugged before boot, or plugging it after your machine is up
  (except for timing). This cannot work well together. The only way to
  make this reliable is to have a daemon that can deal (fsck and mount)
  devices appearing at arbitrary points in time. systemd (from
  community) should do this well, though it is a relatively new project,
  so maybe you don't want to put it on your production systems quite yet
  (it is standard in Fedora 15 though, so it can't be that bad).

There's no reason to ever, ever, put USB drives in the fstab. Look at the top 
of the fstab file, it reads static file system information. Unless you're 
guaranteed to have your thumbdrive plugged into your computer 24/7 and never 
remove it, it doesn't really belong in there, use consolekit or whatever KDE 
SC or GNOME use. Use pmount, whatever.

Otherwise you'll get problems like this one that you're 

Re: [arch-general] Reboot - Versioned Kernel Installs

[Yaro Kasear]

On Monday, June 06, 2011 11:34:53 Thomas Dziedzic wrote:
 On Mon, Jun 6, 2011 at 11:22 AM, Tavian Barnes
 
 taviana...@tavianator.com wrote:
  On 6 June 2011 10:02, KESHAV P.R. skodab...@gmail.com wrote:
  Hi all,
  Since the next kernel will be 3.0 , the kernel26 naming is
  meaningless from the next kernel. I think this is also a good time to
  consider implementing versioned kernel install. Agreed arch has a
  policy of 1 package per software in the official repos. While this
  attitude is acceptable for Xorg or windows managers or even some low
  level utilities, problems with those can be corrected if the system
  can boot to a shell atleast (init 1 or 3). But if the kernel fails to
  boot and under the assumption that the user hdoes not have any rescue
  system/distro handy he/she cannot boot into the system (atleast not at
  that moment). Without a working kernel it is not possible to boot to a
  shell to run any damn command.
 While this topic has already been discussed at [1] the
  discussion was slow and has not lead to any fruitful result. This post
  is mainly to reach out to a larger audience and decide on how to go
  about since the upsteam version change provides the right time for
  Arch to reconsider the same. Another discussion at [2] is about
  removing the word kernel from the initramfs image. If in case
  versioned kernel proposal is accepted then the initramfs also
  (automatically) becomes versioned to match the kernel. Atleast Dave
  Reisner (falconindy) took the first step by making the change in his
  geninit program. I understand this might require changes in the way
  mkinitcpio (or geninit if at all it becomes default) and the way
  pacman handles different versions of same packages. Please join in.
  
  [1] https://bugs.archlinux.org/task/16702
  [2] https://bugs.archlinux.org/task/18719
  
  Regards.
  
  keshav
  
  I have kernel26-lts installed as a backup kernel, and this is all
  that's really necessary for rolling back broken kernel updates.  I've
  been bitten by a BTRFS bug once and rolled back with -lts no problem.
  -1 from me on keeping multiple kernel versions installed; I really
  like that arch doesn't keep 6 old kernels around.
  
  While we're at it, +1 for calling the kernel package linux for version
  3.0.
  
  --
  Tavian Barnes
 
 Agreed with Tavian Barnes.
 Also, don't call it linux30 just call it linux

Or just 'kernel.'

And yes, -1 on multiple kernels. That was one of the more idiotic brain-
damaged practices of Ubuntu that drove me away in the first place.

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Thursday, May 26, 2011 02:57:49 Thomas Bächler wrote:
 Am 26.05.2011 06:28, schrieb XeCycle:
  Perhaps we may provide alternative kernels? With names like
  these, we may get a brand new project named Arch Operating
  System, providing Linux, BSD, Hurd or even more as kernels,
  and users are free to choose any one. Well, this is really
  interesting. It'd be the first OS to provide multiple
  kernels!
 
 You know why nobody has done it before? Because it's not possible.

I'm sure it's possible.

I'd like to it's bloody pointless as my reason. We're Arch, not Debian. 
Notice how Arch officially only supports x86 and x86_64. Are people going to 
start wasting our time with requests to support PPC, SPARC, ARM, SH*, what 
have you, now?

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Wednesday, May 25, 2011 10:20:46 Bernardo Barros wrote:
 Hi there,
 
 There are rumors that the next version number of the Linux Kernel is
 going to be 3.0.
 Since we choosed 'kernel26' as the package name, we will have to
 modify it anyway.
 Why not just 'linux 3.0'? Just an idea.. since we have the fellow
 project 'Arch Hurd' providing 'hurd' as an alternative different
 kernel already.
 
 Best,
 Bernardo

What rumors are these? A quick Google search shows nothing of the sort aside 
from idle speculation from years ago.

Re: [arch-general] Future of 'kernel26'

[Yaro Kasear]

On Wednesday, May 25, 2011 11:14:55 Sander Jansen wrote:
 On Wed, May 25, 2011 at 10:53 AM, Thomas Bächler tho...@archlinux.org 
wrote:
  Am 25.05.2011 17:43, schrieb jesse jaara:
  This is from recent kerbel mailing list post. A voice inside Torvals
  head is telling hin that it would be time to go for 3.0 versioning
  
  Everyone, don't get too excited. The reasons for Linux 3.0 are
  - the numbers are getting too big (2.6.40)
  - the 2.6 prefix has no meaning, and 3.0 for a release and 3.0.1 for a
  bugfix release is shorter than 2.6.40 anf 2.6.40.1
 
 Of course, the 3. would still have no meaning :P
 
 Sander

I heard from several reliable sources it'll be 2.8, not 3.0.

Why not just call the package kernel?

Re: [arch-general] Cannot Find Desktop in GNOME3

[Yaro Kasear]

On Monday, May 09, 2011 12:53:55 Mauro Santos wrote:
 On 09-05-2011 18:45, Filip Filipov wrote:
  [...] from what i see accessibility, is broken a lot in gnome 3 and i
  hope they will fix that in 3.2
  
  A little bit off-topic, but how often is the 'Fun statistics' [1]
  changing .  I ask because I think it is interesting what impact  Gnome3
  has.
  
  
  [1] https://www.archlinux.de/?page=FunStatistics
 
 Even more off-topic, aren't percentages supposed to add to 100%? :p

How conformist of you! :O

Re: [arch-general] Cannot Find Desktop in GNOME3

[Yaro Kasear]

On Monday, May 09, 2011 14:46:11 Steve Holmes wrote:
 Thanks for telling me about the desktop being gone.  I really wondered
 and am a bit surprised as I thought most people valued and used a
 desktop area quite a bit.  Yes, I opened up my home directory from the
 places and then opened the desktop folder from there.  Actually, I
 think my desktop was actually a top level folder in my places menu but
 still, not the same.  In fact, I have had launchers on the desktop in
 the past but I guess I could get them on there again if I wanted.
 It's just that the desktop was typically addressable from a single
 keystroke before.  Well whatever...
 
 I've heard comments like that before about gnome getting less and less
 configurable; pretty soon, it will be like that other windows
 operating system out there.

Though the direction of GNOME where it's getting less and less features and 
functions isn't something Arch can fix, I agree. It's part of why I like KDE, 
which is incredibly flexible and loaded. A bit large, though.

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Yaro Kasear]

On Saturday, May 07, 2011 12:26:54 Philipp Überbacher wrote:
 Excerpts from C Anthony Risinger's message of 2011-05-07 18:24:38 +0200:
  On Sat, May 7, 2011 at 11:18 AM, Pierre Schmitz pie...@archlinux.de 
wrote:
   On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
   On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
   On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
   Is faac support in ffmpeg causing trouble to other applications or
   was changed for licensing reasons?
   
   licensing. if you need faac you should use abs to recompile it
   
   Gah. All this licensing stuff is starting to get really annoying.
   Did Arch receive a patent license violation notice or something?
   
   What is Arch's official policies when it comes to patents?
   It could have some widespread implications for the distro.
   
   Or the distro could purchase or otherwise aquire licenses to all
   claimed patents...  ha...  ha...
   
   Licenses and patents are different things. Some stuff cannot legally
   distributed and we respect that. This is usually proprietary/non-free
   software or packages like the Microsoft fonts. (Wasn't there also some
   mplayer codec pack that included some Windows dlls?)
   
   On the other hand there are software patents valid in some countries
   which apply also to a completely free implementation. This means there
   are a bunch of packages which you are not allowed to use in the US for
   example even though they are licensed under e.g. the GPL.
  
  a bit of a divergence ... but as i think about next-gen packaging
  quite a bit i've often considered if a most advanced distribution
  system would negate issues like this ... for example, what if a
  nonfree package _knew_ it was nonfree, and therefore would only be
  distributed from servers in countries that do not deem it an issue?
  when user went to to sync it, their IP would be geolocated (or just a
  setting, eg. RESIDENT) and if need be the user would be warned that
  the package they are synced may have unknown legal implications.
  
  would something like that work?
  
  C Anthony
 
 Too complicated, error prone and not really adding anything.

In my not so humble opinion, I don't think we should waste time kowtowing to 
the annoying politics of what's free or not when it comes to actual 
implementation of something. Keep the nonfree stuff there. No one is forcing 
users to have them, and most Linux users don't give a damn if something is 
nonfree.

Re: [arch-general] Change Arch's default crond

[Yaro Kasear]

On Thursday, April 21, 2011 01:48:04 Sven-Hendrik Haase wrote:
 On 21.04.2011 08:32, Kaiting Chen wrote:
  On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
  
  drankina...@suddenlinkmail.com wrote:
  On 04/06/2011 10:34 PM, Heiko Baums wrote:
  Upstream stability makes sense. If redhat is behind cronie, then that
  
   seems like the logical choice.
  
  Why is this logical? Is it the developer what makes a software good or
  is it the features and the stability? If Redhat's cronie has less
  features than fcron then fcron is the logical choice, of course.
  
   You are correct. The long term stability was just my thought. Like I
   said
  
  earlier in my message -- It doesn't matter to me which cron we have --
  as long as we have one that works :)  I have no say in the matter, so I
  will, of course, defer to whatever decision you guys reach. I just want
  to make sure we have a cron by default :)
  
  So what's the status here? I pulled cronie into [community-testing] a
  couple of days ago and will probably merge it into [community] soon. So
  that's the one I vote.
  
  But regardless of which one we choose in my opinion the sooner we get rid
  of dcron the better. --Kaiting.
 
 I second this suggestion. cronie upstream isn't dead at all. cronie is a
 drop-in unlike fcron which was favored earlier. Kaiting said he would
 even be willing to become a developer to maintain this in [core] himself
 in case no other developer was  interested.
 
 Is there anything that would keep us from making it default and also
 replace dcron?
 
 -- Sven-Hendrik

I'm still trying to understand WHY we suddenly feel the need to replace dcron 
when its not even broken. Replacing packages with other packages purely 
because they're new is something Fedora and Ubuntu would do, I though Arch 
wasn't about arbitrarily replacing its defaults but using what was simple and 
what works.

Can someone explain to me why we think we need a new crond?

Re: [arch-general] What are people's opinions about this?

[Yaro Kasear]

On Wednesday, April 13, 2011 20:45:32 Grigorios Bouzakis wrote:
 This feature request: https://bugs.archlinux.org/task/23747
 
 
 Greg

Is this some sort of configuration utility for Xorg? A little background would 
be nice.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 14:50:41 Dennis Beekman wrote:
 I use linux becuase i think that windows is just to bloated to even be
 considered ... but lately Linux has been going in the same direction
 when it comes to the desktop enviroments Gnome 3  KDE 4.
 

This is all a matter of opinion. I like KDE 4 a lot. It's big, but I doubt 
there isn't a hard disk made within the last 15 years that can't fit it. It's 
definitely not bloated nearly as much as Windows is. KDE 4.6 is still 
downright lightweight compared to Windows 7.

My chief complaint against GNOME 3 is that it requires Pulse Audio.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 Gnome 2 was brilliant just a simple easy to use system with load off
 good looking features, gnome 3 however is useless in all respects as far
 as i can tell from whats in testing.
 

Look, if you like a simple desktop with fewer features and a more 
straightforware approach and less eye candy, all the power to you. Just don't 
assume that's what EVERYONE wants in a desktop. I like the eye candy 
and almost ridiculous amount of options and settings KDE SC 4 gives me.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 1. You cannot change the panels anymore you stuck with the 2 given by
 gnome 3.

You could alter the themes, get more themes. I don't know how close to 
Plasma the new GNOME desktop is, but even KDE SC 4 offered ways to 
configure its panel look and feel.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 2. Changing themes also is inpossible.. or so it seems.

Just sounds like you haven't figured out how to change the themes yet. 
GNOME 3 *is* a major change over GNOME 2, after all.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 3. Why do we need a system settings menu with all the options in one
 menu ? where are my seperate icons i love so much ? why can we choose
 wich icons or options we want ?

I don't understand this complaint. Didn't GNOME 2 also offer settings all in 
one or two menus before?

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 4. What about the people ho don't have or don't wich to use they're
 video hardware to run the these stupid graphics ... are we stuck with
 fallback mode wich is even more stupid and backward ?

I'm fairly certain that GNOME 3 doesn't force you to use visual effects. If 
you turn that off it'd likely speed right up.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 5 Where did all the nice applets go ? and why can i not add them to my
 taskbar anymore
 

Aforementioned GNOME developers stripping away nice features because 
they erroneously think they confuse users.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 [flaming]
 I though KDE 4 was bad  and bloated and that i couldn't get any worse...
 it seems i was wrong.

KDE SC 4 is only really bloated when you install all its packages. And it's 
bloat is still nowehre near comparable to Windows Vista or 7. If you can't fit 
KDE SC 4 on a hard disk even an old SMALL one, you need a new hard 
disk, because its a wonder you can fit anything on there.

Also, KDE SC 4 hasn't been nearly that bad since 4.3 came out, and it's 
pretty solid as of 4.6.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 Boy this new Gnome version is even more bloated and buggy then KDE 4
 wich is quite the atchievement from the gnome team...
 

This is a matter of opinion and experience. As I said. Post-KDE SC 2.3 is 
pretty stable, and bloat is overstated when it's not even clearing a GiB of 
hard disk space.

This is not something the Arch developers have any power over. So this is 
not the place to complain about it.

 Now i finnaly understand why the Ubuntu guys decided to use they're
 netbook unity system rather then this shit, eventhough unity sucks it
 better then Gnome 3 in all respects.

I personally believe Ubuntu moving over to Unity was a mistake. And I fear th 
whining that will come when the planned move to Wayland happens due to it 
not having nearly as good support as Xorg. My opinion is that a lot of people 
overestimate KMS support in Linux. I would have waited a couple more years 
for KMS to mature before planning my desktop around it.

Also, we're Arch, not Ubuntu. We're not forcing you to use GNOME 3 or 
Unity. Not forcing you to use KDE SC 4, either. Instead of bitching on Arch 
general and wasting space on our inboxes, you could have just switched to 
Xfce or LXDE if you wanted a lightweight desktop environment. Or you could 
have switched to the dozens of 

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 15:07:27 Dennis Beekman wrote:
 On 04/10/2011 03:50 PM, Jelle van der Waa wrote:
  On Sun, 2011-04-10 at 21:50 +0200, Dennis Beekman wrote:
  I use linux becuase i think that windows is just to bloated to even be
  considered ... but lately Linux has been going in the same direction
  when it comes to the desktop enviroments Gnome 3  KDE 4.
  
  Gnome 2 was brilliant just a simple easy to use system with load off
  good looking features, gnome 3 however is useless in all respects as 
far
  as i can tell from whats in testing.
  
  1. You cannot change the panels anymore you stuck with the 2 given 
by
  gnome 3.
  2. Changing themes also is inpossible.. or so it seems.
  
  It's not.
  
  3. Why do we need a system settings menu with all the options in one
  menu ? where are my seperate icons i love so much ? why can we 
choose
  wich icons or options we want ?
  4. What about the people ho don't have or don't wich to use they're
  video hardware to run the these stupid graphics ... are we stuck with
  fallback mode wich is even more stupid and backward ?
  5 Where did all the nice applets go ? and why can i not add them to 
my
  taskbar anymore
  [flaming]
  I though KDE 4 was bad  and bloated and that i couldn't get any 
worse...
  it seems i was wrong.
  Boy this new Gnome version is even more bloated and buggy then 
KDE 4
  wich is quite the atchievement from the gnome team...
  
  Now i finnaly understand why the Ubuntu guys decided to use they're
  netbook unity system rather then this shit, eventhough unity sucks it
  better then Gnome 3 in all respects.
  
  [/flaming]
  
  Can we not just keeps using the old version and ignore the new version
  of gnome for now until they get they act together ? or hopefully decide
  to go back to the old interface and develop that further instead ...
  
  You probably want to read more about GNOME3 and how it breaks with
  GNOME2. This is not our discussion, but upstreams and we just 
package
  vanilla packages. So this 'flame' post is useless.
 
 Well it might be my imagination but it seems Desktop Enviroments on
 linux are more bloated and buggy now then Windows is.
 
 We are being forced to use de's like openbox or xfce wich is the primary
 reason people shy away from unix/linux when changing from Windows to
 another OS.
 It just becomes to confusing and complicated from they point of view and
 they choose MAC or another Windows versions instead.
 
 Even i as a seasoned linux user ho switched over from ubuntu to arch a
 while ago it doesn't make any sense to me why they would do this i
 tell you the amount of Gnome users in my point is view in going to halve
 if not drop any further then that.
 
 But ofcourse it is Gnome at fault here and not ARCH but still, can we
 not keeps the latest old version from before the release in the nomal
 repo's until they update 3.0 a couple of times ?

GNOME 2's probably not even going to LAST that long. Once some libraries 
staart getting new releases and feature changes to them, GNOME 2's going 
to find itself simply *not* working due to a library not being what it needs.

And, as you said, it's not Arch's fault, so stop wasting inbox space with 
useless flamebait, please.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 12:42:57 Arthur Titeica wrote:
  On Sun, 10 Apr 2011 21:50:41 +0200, Dennis Beekman wrote:
  [flaming]
  I though KDE 4 was bad and bloated and that i couldn't get any
  worse...
  it seems i was wrong.
  Boy this new Gnome version is even more bloated and buggy then KDE 
4
  wich is quite the atchievement from the gnome team...
 
  Please stop calling KDE bloated. As a former Windows user I find both
  Gnome and KDE over simplistic and both lack some kind of bonding 
between
  various parts like Windows does.
  In that regard tough, KDE SC is doing much better than Gnome and I
  guess that's what the SC part means.

The SC part is the KDE devs realizing that KDE has gone way beyond being 
a desktop environment and went on to be a full-scale software compendium 
and community. It's almost become the Microsoft of Linux (But in a good 
way.) in that it covers almost everything.

 
  What you may find bloated is the fact that the two major video card
  makers do a terrible job in supporting their
  over-heating-barely-2D-60euro-windows-only-cards and rely on the FOSS
  devs to build drivers for them.

I dunno. nVidia seems to do a good job, driver-wise, for their cards on Linux. 
Keep it up to date, don't leave out new Xorg/OpenGL features. ATI's not too 
great at Linux support, unfortunately.

  Both NVIDIA and AMD do a semi-lousy job with drivers in the Windows
  world and I don't expect better anytime soon.

Again, I've had no issues with drivers in Windows or Linux nVidia-wise. 

  Add this to the fact that the kernel isn't exactly desktop optimized
  (stuff like let me move the mouse while I extract that damn 4G archive)
  and you'll probably get what feels like a slow system.

This is largely because the kernel devs (accurately) figure that the typical 
application for Linux is more for servers and high-performance computing. 
Desktop optimization is pretty low-priority. When kernel 38 comes out (Might 
be tonight, I think.) we'll have the Wonder Patch which will make a desktop 
speedy, or so I am told.

 
  Now what could a DE could do in this situation? I know that kwin does
  extensive checks in regards to video driver capabilities and maybe Gnome
  just isn't that far on this.
 

They're generally pretty good functionality checks, though sometimes I don;t 
like KDE to turn off my eye candy when things get slow.

  That said, KDE SC with the free radeon driver in 2.6.38 is
  outperforming the catalyst driver with 2.6.37 in regards to desktop
  effects (I can't say anything about nouveau).
 

I couldn't even get Nouveau's Gallium driver to work with OpenGL. nVidia's 
proprietary driver is still way ahead of Nouveau on this. Pretty much the 
chief feature of Nouveau is KMS for nVidia users. Personally, I'd rather have 
good OpenGL support than KMS.

  IMHO!

My humble opinion, too.

Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.

[Yaro Kasear]

On Sunday, April 10, 2011 13:13:42 Jelle van der Waa wrote:
 On Sun, 2011-04-10 at 19:40 +0300, Alper Kanat wrote:
  s/failback/fallback/g
  
  sorry for the typo..
  
  ---
  Quis custodiet ipsos custodes?
  
  On Sun, Apr 10, 2011 at 19:39, Alper Kanat tu...@raptiye.org wrote:
   Hello Fellow Archers,
   
   Most people say that Arch is cutting edge and saving GNOME2 as 
gnome2
   is not the the Arch way. I know that packaging and maintaining 
GNOME2
   is a hard task that no devs would want to take care of and that we'll
   most likely be seeing unofficial repositories but what about python?
   Despite the upstream python is 3.x, we still have python2 for
   failback? So is that the Arch way?
 
 quote from python.org
 The current production versions are Python 2.7.1 and Python 3.2.
 
 Start with one of these versions for learning Python or if you
 want the most stability; they're both considered stable
 production releases.now.
 
 While with GNOME it's the case that GNOME2 is dead , SO LONG LIVE
 GNOME3!!
 
 *jelly drinks beer with his gnome friends

That was the point I was trying to make. GNOME 2 is being dropped not just 
because GNOME 3 is here, but because upstream is dropping it and 
nobody wants to go through the trouble to try to maintain something entirely 
unsupported upstream.

And, for the millionth time, when a shared library GNOME 2 uses gets a 
major version bump, there goes any semblance of compatibility it would 
have.

Re: [arch-general] base stuff

[Yaro Kasear]

On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
 Am Fri, 8 Apr 2011 10:55:16 -0600
 
 schrieb Thomas S Hatch thatc...@gmail.com:
  Yaro makes many good points, I think that my recommendation would 
be
  to allow someone to maintain support for SELinux in community. If
  SELinux support is deemed something that would be a good idea to 
move
  to core in the future than do so, otherwise leave it in community.
 
 I'd prefer a separate [selinux] repo. So that people know what they are
 doing.
 
 I know, packages with SELinux support could and should be named
 something like selinux-XXX or XXX-selinux, but I think a new repo would
 be better and more secure - not only from SELinux' view.
 
 This way SELinux users can just add [selinux] to pacman.conf above
 [core]. For the other users it should be deactivated by default.
 
 Heiko

Here's another question. Isn't it general packaging policy to not fully 
support packages that have unofficial upstream patches applied? Isn't 
SELinux unofficial to all the upstream?

Re: [arch-general] base stuff

[Yaro Kasear]

On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:
 On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net wrote:
  On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
   Am Fri, 8 Apr 2011 10:55:16 -0600
   
   schrieb Thomas S Hatch thatc...@gmail.com:
Yaro makes many good points, I think that my recommendation 
would
  
  be
  
to allow someone to maintain support for SELinux in community. If
SELinux support is deemed something that would be a good idea to
  
  move
  
to core in the future than do so, otherwise leave it in community.
   
   I'd prefer a separate [selinux] repo. So that people know what they are
   doing.
   
   I know, packages with SELinux support could and should be named
   something like selinux-XXX or XXX-selinux, but I think a new repo 
would
   be better and more secure - not only from SELinux' view.
   
   This way SELinux users can just add [selinux] to pacman.conf above
   [core]. For the other users it should be deactivated by default.
   
   Heiko
  
  Here's another question. Isn't it general packaging policy to not fully
  support packages that have unofficial upstream patches applied? Isn't
  SELinux unofficial to all the upstream?
 
 SELinux has been in the vanilla kernel for quite some time, say the 2.6.20
 ish realm, and the majority of the core utils have had SELinux support
 built in for years. SELinux is official upstream.
 
 But I don't want to argue about this anymore :) I think that we have a
 solution, I will be putting up an SELinux third party repo for testing in
 the next month or two and then once we have an assurance that it is 
working
 well we look into moving SELinux support into community.
 
 This has been a great discussion, and I am excited to get some work done 
on
 improving SELinux support on Arch!
 
 -Thomas S Hatch

What about the SELinux patches for things other than the kernel? Are those 
official to upstream? This is not for an argument, now I'm just genuinely 
curious.

Re: [arch-general] base stuff

[Yaro Kasear]

On Saturday, April 09, 2011 12:54:23 Thomas S Hatch wrote:
 On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear y...@marupa.net wrote:
  On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:
   On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear y...@marupa.net 
wrote:
On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:
 Am Fri, 8 Apr 2011 10:55:16 -0600
 
 schrieb Thomas S Hatch thatc...@gmail.com:
  Yaro makes many good points, I think that my recommendation
  
  would
  
be

  to allow someone to maintain support for SELinux in 
community. If
  SELinux support is deemed something that would be a good 
idea to

move

  to core in the future than do so, otherwise leave it in
  community.
 
 I'd prefer a separate [selinux] repo. So that people know what they
  
  are
  
 doing.
 
 I know, packages with SELinux support could and should be 
named
 something like selinux-XXX or XXX-selinux, but I think a new repo
  
  would
  
 be better and more secure - not only from SELinux' view.
 
 This way SELinux users can just add [selinux] to pacman.conf 
above
 [core]. For the other users it should be deactivated by default.
 
 Heiko

Here's another question. Isn't it general packaging policy to not
fully support packages that have unofficial upstream patches
applied? Isn't SELinux unofficial to all the upstream?
   
   SELinux has been in the vanilla kernel for quite some time, say the
  
  2.6.20
  
   ish realm, and the majority of the core utils have had SELinux support
   built in for years. SELinux is official upstream.
   
   But I don't want to argue about this anymore :) I think that we have a
   solution, I will be putting up an SELinux third party repo for testing
   in the next month or two and then once we have an assurance that it 
is
  
  working
  
   well we look into moving SELinux support into community.
   
   This has been a great discussion, and I am excited to get some work
   done
  
  on
  
   improving SELinux support on Arch!
   
   -Thomas S Hatch
  
  What about the SELinux patches for things other than the kernel? Are
  those official to upstream? This is not for an argument, now I'm just
  genuinely curious.
 
 The vast majority are, but there are a few places where patches are 
needed,
 like in pam and ssh.
 
 So yes, there is a half and half going on. Basic SELinux support works
 without patches, but adding some of the more advanced features to some 
of
 the core applications require a few patches.
 
 -Thomas S Hatch

Great! Well, I look forward to maybe testing out your repository. Maybe I'll 
actually get SELinux working.

Re: [arch-general] base stuff

[Yaro Kasear]

On Friday, April 08, 2011 05:43:51 Kaiting Chen wrote:
 On Fri, Apr 8, 2011 at 3:44 AM, Jelle van der Waa je...@vdwaa.nl wrote:
  And on a side note, I don't like archlinux forcing users to use SELinux
  because users should have a choice to use any MAC software they want.
  That's why AppArmor /Tomoyo are nicer solutions cause they don't require
  recompiling of packages - increasing bugs/problems.
 
 If we compile our packages with SELinux support, does that force users to
 use SELinux? I was under the impression that these changes would be
 completely benign on non-SELinux enabled systems. --Kaiting.

No, SELinux-patched tools do not force one to use SELinux. But they can 
potentially have plenty of bugs introduced by the patches. And there's the 
fact that SELinux is not necessary and there's not point in putting it in the 
default Arch install just for the minority who'll actually use it. At most, it 
should be in [core]. At the very least, [community]. I definitely see no good 
reason to make it part of the base install, though.

Re: [arch-general] Change Arch's default crond

[Yaro Kasear]

On Wednesday, April 06, 2011 15:27:27 Thomas Bächler wrote:
 Am 05.04.2011 09:19, schrieb Thomas S Hatch:
  I can think of three considerations for a cron daemon:
  1 . Minimal - its a cron daemon, it does not need to be complex
  2. Active development
  3. Anacron functionality
  
  As far as I can see this leaves us with fcron, dcron and cronie. Cronie
  probably has the highest assurance for upstream development because 
it is
  backed by redhat.
  But I think that having a cron daemon as default that has issues
  executing jobs on time and as they are defined is highly questionable.
 
 Before the current maintainer took over dcron, we had that same
 discussion. Aaron even contacted the fcron maintainer (he posted the
 reply to arch-general or arch-dev-public, if anyone could find the link
 in the archives, please post it). The author responded that he
 considered fcron feature-complete, so didn't develop it anymore.
 However, he would fix bugs when they are reported, and I think there are
 no known bugs right now.
 
 That said, fcron lacks /etc/cron.d/ functionality which was the most
 important argument against it. I personally don't need that and I like
 fcron a lot.
 
 As for your conditions:
 1) It is very small software, 1.2MB installed, and it has lots of
 features. It is by no means minimal though.
 2) I commented on that above.
 3) dcron has @daily, @hourly and so on. In fcron, you can use standard
 crontab entries and add bootrun to the beginning of the line to repeat
 missed cronjobs.
 
 I don't know cronie, so maybe you can elaborate more.

Losing /etc/cron.d support is a bit of a dealbreaker for me. I think that's a 
rather huge feature to leave out of a crond.

Re: [arch-general] base stuff (was: Change Arch's default crond)

[Yaro Kasear]

On Wednesday, April 06, 2011 18:13:04 Grigorios Bouzakis wrote:
 Thomas S Hatch thatc...@gmail.com wrote:
  On Wed, Apr 6, 2011 at 4:16 PM, Grigorios Bouzakis 
grb...@xsmail.comwrote:
  Thomas S Hatch wrote:
   I am saving the include SELINUX support in base for a latter date
   
   my understanding though is that the stated position of Arch was no
   systemd
  
  s/was/is/g
  
  That is also my understanding in regards to selinux. Although i am not
  familiar with stated positions about either.
  
  PS. Ntp is fine application that will keep your clock synchronised.
  It seems to be 5 days off. :)
  
  Yes the systemd topic keeps popping up, right now we don't know
  if certain upstream changes are going to force Arch into using systemd 
or
  not.
 
 I dont think such a topic keeps popping up.
 In fact I dont remember reading a discussion between Arch developers 
about
 it, ever.
 I could probably go on ranting about stuff thats been shoved down users
 mouths the last years for months but its futile and a waste of time.
 

It was a discussion that popped up here, a debate between users who felt 
replacing sysvinit was completely unneeded to those who seemed to want to 
use systemd for some useless, unneeded feature maybe less than 1% of 
Arch users were going to actually use.

  As for adding SELinux support in base but keeping it turned off by
  default, +1
 
 Although this isnt a vote, mine was for no selinux at all, so its just 1.
 :)

Selinux is another unneeded thing, but even worse is that it practically 
requires a doctorate in computer science to manipulate. Can't deny its 
security, though. +1 to leaving it out of Arch, not that anyone's asking Arch 
to.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:00:55 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  The fact he called it racism smells of a troll to me. Trolls are worse
  than
  spammers.
 
 Meeku:  No.  The person who did not wish me to participate on this mailing
 list tactically made his personal opinion to be representative for others
 also by using the 'our' word.

I don't want you advertising your crap on this mailing list either. He's not 
alone, and likely I'm not, either. Post something actually relevant to Arch 
Linux or leave it out.

 
 I also want to research the correlation between your opinion-judgement in
 this case and the lines of evidenced based productive Arch Linux coding
 you have written first hand and I would be grateful for this statistic and
 evidence.


Programmers write code fine without your font, we don't need you trying to 
spam us with it. If you want people to try your font, put it on the AUR, stop 
spamming the mailing list.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:03:25 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  I'm racist against trolls. Am I  a horrible person?
 
 Meeku:  If the spam allegation is motivated by seeing spiritual email
 addresses on a public mailing list rather than contents or the on-topic
 contents are ignored, then it is not spam.

You're not seriously suggesting it's religious persecution?

Now I KNOW you're a troll and a spammer. Get the hell off my mailing list.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:05:15 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  Can somebody ban him?
 
 Meeku:  Well then I question your opinion-judgement because font, coding
 and operating systems are related.  If the spam allegation is motivated by
 seeing spiritual email addresses on a public mailing list rather than
 contents or the on-topic contents are ignored, then it is not spam.

It's spam because your promoting your font on a mailing list where such a 
thing is not just rude, but very unwelcome.

 
 I also want to research the correlation between your opinion-judgement in
 this case and the lines of evidenced based productive Arch Linux coding
 you have written first hand and I would be grateful for this statistic and
 evidence.

Stop repeating your nonsense over and over, that, too, is spam.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:08:59 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  .stop spamming the mailing list.
 
 Meeku:  I respond to silly accusations and now I get hounded also.

It's not a silly accusation when you're doing exactly what you're accused off. 
You're spamming the mailing list trying to get people to use your font.

If by hounding you mean not letting you get away with spam then yes, 
that's what we're doing.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:13:19 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  .you're a troll and a spammer. Get the hell off my mailing list.
 
 Meeku:  This attitude does not do the reputation of your o/s any good.  If
 you don't want to use the font fine.

I don't want to use your font, but I don't want you wasting space on my inbox 
or on the mailing list with your spam. Stop now.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:15:59 pm 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  .trying to get people to use your font.spam.we're.
 
 Meeku:  If you don't want to use the font fine.

I don't want you spamming your idiot font on the mailing list, either. My 
issue isn't not wanting to use your font, its you wasting our time and mailing 
list with it.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:17:54 pm o...@deathbycomputers.co.uk wrote:
 Been lurking here for a while and I'm now really considering dropping this
 list.  Please do not feed the troll it will only make it worse.
 
 Cani
 Sent from my BlackBerry® wireless device
 
 -Original Message-
 From:
 hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_
 hare_h...@lavabit.com Sender: arch-general-bounces@archlinux.orgDate: Sun,
 23 Jan 2011 13:15:59 To: General Discussion about Arch
 Linuxarch-general@archlinux.org Reply-To: General Discussion about Arch
 Linux arch-general@archlinux.org Subject: Re: [arch-general] Rail Model
 font for coders
 
  .trying to get people to use your font.spam.we're.
 
 Meeku:  If you don't want to use the font fine.

I'll stop. Added the troll to my KMail filter. Anything he sends goes straight 
to my trash.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Sunday, January 23, 2011 12:20:17 pm Nathan Wayde wrote:
 On 23/01/11 18:13,
 hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_h
 are_h...@lavabit.com
 
 wrote:
  .you're a troll and a spammer. Get the hell off my mailing list.
  
  Meeku:  This attitude does not do the reputation of your o/s any good. 
  If you don't want to use the font fine.
 
 just so you know, your silly overly long email address alone qualifies
 you for spamming and the first mail sent by your was immediately flagged
 as such. It also doesn't help that your messages appear somewhat like it
 was written by a spammer and the you proceed to argue about it as-if
 your original mail was relevant to this ML.

I googled his e-mail. Seems he spammed the debian-user list, too.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 05:23:13 am 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
  Can someone stop him from spamming our inboxes ?
 
 Meeku:  our means the whole mailing list.  You should have used the word
 my and if you are a closet racist by condemning me from participating on
 this open mailing list then it does not do Arch Linux's reputation any
 good.

How does pointing you out to be a spammer make him a racist all of a sudden?

I smell troll.

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 09:09:22 am Ng Oon-Ee wrote:
 On Sat, 2011-01-22 at 06:23 -0500,
 
 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 
wrote:
   Can someone stop him from spamming our inboxes ?
  
  Meeku:  our means the whole mailing list.  You should have used the
  word
  my and if you are a closet racist by condemning me from
  participating on
  this open mailing list then it does not do Arch Linux's reputation any
  good.
 
 Up to this point this thread has been ignore-able, but what sort of
 nonsense is this? Accusations of racism simply because your spam is
 being identified as such?
 
 What 'spam' is is decided by the recipients. I personally think this
 whole thread is spam. I'm pretty sure I'm not alone on this list in
 thinking that.

The fact he called it racism smells of a troll to me. Trolls are worse than 
spammers.

Re: [arch-general] Gnome Sound Events and Settings

[Yaro Kasear]

On Saturday, January 22, 2011 09:28:35 am Steve Holmes wrote:
 What tools are needed in Arch to configure the login and logout sounds
 for GNOME?
 
 When I go into the Volume control, I can only change the alert sounds
 and that, I can do OK but right now, I cannot get any sounds to work
 for Login, Logout, e-mail, etc.  I've seen references in google for
 other distros having something called Sound-Preferences or something
 but I don't see anything like that for Arch.  Google also pulled up
 some forum references to this same question but no answers were ever
 given.
 
 What do other GNOME users do about this in Arch? I'm not aware of how
 to specify the paths for the right files.  Ifound the sound files
 themselves in /usr/share/sounds but can't figure out where to go from
 here.
 
 Any ideas?

I encountered this issue a few years ago, when for whatever reason the GNOME 
developers stripped away sound theming for no reason.

Perhaps the option is buried deep within the gconf-editor?

Re: [arch-general] Rail Model font for coders

[Yaro Kasear]

On Saturday, January 22, 2011 01:28:50 pm Geoffrey Teale wrote:
 2011/1/22 Yaro Kasear y...@marupa.net
 
  On Saturday, January 22, 2011 09:09:22 am Ng Oon-Ee wrote:
   On Sat, 2011-01-22 at 06:23 -0500,
  
  hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama
  _hare_h...@lavabit.com
  
  wrote:
 Can someone stop him from spamming our inboxes ?

Meeku:  our means the whole mailing list.  You should have used the
word
my and if you are a closet racist by condemning me from
participating on
this open mailing list then it does not do Arch Linux's reputation
any good.
   
   Up to this point this thread has been ignore-able, but what sort of
   nonsense is this? Accusations of racism simply because your spam is
   being identified as such?
   
   What 'spam' is is decided by the recipients. I personally think this
   whole thread is spam. I'm pretty sure I'm not alone on this list in
   thinking that.
  
  The fact he called it racism smells of a troll to me. Trolls are worse
  than spammers.
 
 Isn't that a little bit trollist?  We have to be tolerant of other
 cultures, if we oppress trollish people they will organise and rise up
 against us. See this interesting documentary for what I mean:
 http://www.youtube.com/watch?v=TGlSAtb-SDw

I'm racist against trolls. Am I  a horrible person?

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 11:53:22 am C Anthony Risinger wrote:
 oh... my.  there is too much expletive deleted to respond properly
 so i'll try touch a couple [several] things ...
 
 ... why the resistance at all? let me reiterate this nce and slow:
 

Because it's completely unnecessary.

 SYSVINIT HAS NO POWER, NO FUNCTIONALITY, AND ABSOLUTELY ZERO
 USEFULNESS ON IT'S OWN.
 
 the unix philosophy (debatable in itself...) of doing one thing
 doesn't usually translate to LITERALLY DOING ONE THING.
 
 please please please, please, read that several times until it sinks
 in nice and deep; every single argument about sysvinit's simplicity,
 maturity, blah blah, woka woka, etc etc, and anything else related
 to it's stability is complete nonsense because ...
 
 YOUR BOOT PROCESS IS A MEGAMATRON SHELL SCRIPT, AND HAS PEANUTS TO DO
 WITH INIT; IN FACT, INIT IS NOT EVEN NEEDED.
 

Some form of init is still needed even if the initscripts are glorified shell 
scripts. What do you think has to RUN those shell scripts for them to be of 
any use at all?

Hell, even without a single initscript, an init system STILL needs to be in 
place. That's just how UNIX works

SysV Init is simple, which is what Arch is all about.

 capisce?  good.  now we can move on and give up this pointless cling
 to something that provides us nothing WHATSOEVER.

It provides us with a solid reliable way to boot our system and manage what 
runs at boot time. Anything more than that is luxury and unnecessary.

 
 systemd is superior in every single way imaginable.

This is a matter of opinion. Not fact.

 that is the pure
 and simple truth; it's not even an arguable point. 

I am arguing it, therefore it is arguable.

 many of the
 concerns here are already answered/clarified higher up in the
 thread, or are nothing more than FUD and personal grudges against a
 guy who seems to SIMPLY WANTS TO IMPROVE THINGS AND DOESN'T CARE IF
 YOU WANT TO USE SYSVINIT FOR 60 MORE YEARS.

I doubt that. Again, to use Pulse Audio as an exabmple, he's stated he wanted 
it to take ALSA's place many times. He may not have said it about systemd, but 
there's no reason, none, to believe he doesn't expect it to replace SysV init 
on most Linux distributions.

 systemd solves real
 user/business problems, and whether or not you/me/us make personal use
 of every single possible feature is irrelevant.

And those problems are...? So far even those further up in this thread haven't 
described any real problems aside from certain inconvient things about the 
Arch Initscripts, which are fixable without introduce a needlessly complex 
init replacement.

 
 these sentiments are echoed throughout most of community.

Are they? Please back up this assertion with facts instead of unsubstantiated 
rants.

 
 systemd has whatever number binaries?? yeah, and?  so what?  take a
 hard look at the precious sysvinit suite; you'll find 1700 external
 calls to grep, sed, awk, cut, ..., ... 

Those are core utilities, not the sysvinit suite. They're gonna be there 
whether or not we use SysV Init. And I bet even systemd would end up using 
them too in its units. 

 even if it mattered one tiny
 little bit, i'm pretty sure you'll exceed systemd's count in the first
 file or two.

Again, they're core utilities you'll find in ANY POSIX system. Just because 
SysV Init's scripts uses them is misleading and irrelevant and pointing this 
out is a blatant red herring.

 i've been thru the init scripts several times and ramfs
 init; i know.  just believe me.
 

So am I. Your point has absolutely no value at all, as those utilities are not 
there for init's sake, but to make scripting at all useful. Switching to 
systemd wouldn't fix that one bit.

 why should init do do almost nothing??

Init decides what is run in what circumstances. That's ALL it needs to be. 
This is not a problem that needs to be fixed. Your argument is invalid.

 how many other applications
 do we slick developers write where the goal is to do a whole 'lotta
 nothing?  come on.  systemd doesn't step out of scope one bit;

Yes it does. Almost every one of systemd's features are completely unneeded 
for a fully functional boot process. Nothing systemd offers isn't already done 
with SysV Init and simple bootscripts.

 it's
 job is to reliably start, stop, and babysit processes with the
 parameters, environment, and constraints WE DEFINE. 

SysV Init does that too. Or have you not noticed the existence of 
/etc/inittab, /etc/rc.conf, or /etc.rc.local. Those three files alone already 
grant a finer amount of control over how Arch's boot process than systemd 
does. Let's not even touch on the magical things you can do with mkinitcpio.

Your rant stinks of someone who doesn't understand the first thing of how the 
Arch boot process actually works.

 that's it; feels
 pretty dang simple/kiss to me.  actually take a look at your boot
 process someday... then come back and drone on about how slick systemd
 is.

It's not KISS at 

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 05:42:17 pm Ray Rashif wrote:
(snip)
  indeed, and i'd mostly agree.  however while im not a developer for
  archlinux, i wouldnt waste time on obsolete systems when a better
  alternative saves me time; you may end up maintaining the initscripts
  yourself.  keep that in mind.
  
  the point of systemd is to make ALL of our lives easier, not more
  difficult.
 
 Right. Anyway, you might want to realise that nobody who matters has
 had - up to this point - anything to say about switching to systemd.
 Mostly because none of them have the time (so there is still hope).
 You can always file an FR in the tracker if you want to gain some
 progress for your enthusiasm, or even get an ultimatum.

I should also point out that simplicity as defined by Arch is not about making 
the life of the user easier, but for making the SYSTEM simpler. Again, systemd 
doesn't fit with that model at all.

You can read that right on the wiki.

You think SysV Init is a pile? Fine, install systemd. I think it belongs in 
[extra] in the best of times. There's really no good reason to make it part of 
base in [core] when all it does is something udev and hal do already, and a 
feature only a minority of Arch users are likely to actually use 
(RAID/LVM/Encryption support, while useful or even popular, can't honestly be 
in the majority of Arch installs.) 

This wasn't aimed at you, Ray, but the guy you were responding, but you were 
makign some good points on your own?

Have I also mentioned that despite all the features systemd might bring, it's 
still unnecessary in light of the fact that SysVInit with initscripts STILL 
works perfectly fine?

If it isn't broken, don't fix it. We put grub2 in [extra], not [core], for the 
same reason we really should put systemd in [extra] and not [core].

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

I was ALMOST behind a switch to systemd until I found out the guy behind it is 
Lennart Poettering. Now we can expect a half-broken init system that'll be in 
perpetual beta, and more passing off the buck on bug reports to 
distributions/drivers/whatever.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

Never mind about what I said. I'm just having a bad day.

Can someone give me a more clear idea on why we might need systemd? It doesn't 
look like it'd fit with the Arch Way, and, well, SysV Init isn't exactly 
broken, and if it isn't broken, why fix it?

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 05:45:46 pm Tom Gundersen wrote:

(snip)

 @Yaro:
 
 1) In my experience Lennart has been a pleasure to work with.
 

I, personally, have never worked with him. I have seen enough criticism of 
Pulse Audio, for example, getting handwaved and pinned on someone else's 
project. I think about it logically: 

If it works fine with ALSA, why did it inexplicably stop working fine with 
Pulse Audio running? Why, when he claims that PA not working is the fault of 
some distribution doing it wrong that it's busted no matter what system I try 
it on?

Lennart has never, in his explanations of how PA actually screws up, actually 
explained to my satisfaction. And with PA being as flawed as it seems to me, 
systemd really worries me. From my perspective he couldn't get a sound daemon 
written that couldn't get sound working right on my system, why am I to 
believe systemd would fare any better.

Let me put it another way, it seems like Lennart's great on new ideas on how 
to do things, poor on execution. From where I am sitting, anyway

This is getting off-topic, and I don't mean to start a Lennart sucks flame 
war.

 2) Regarding systemd and The Arch Way, I guess this is a matter of
 opinion, but the way I see it, systemd fits perfecttly. For two
 reasons (off the top of my head, there might be more):
 
 Firstly, while systemd is more complex (due to more features) than
 sysvinit, the arch-specific parts of systemd are much simpler than the
 arch-specific parts of sysvinit (since systemd does most of what
 rc.sysinit and rc.shutdown do for sysvinit).

Isn't the fact that systemd is more complex already makes it more or less 
against Arch's KISS principles? Or am I confused?

 In fact, by pushing as
 much as our boot process upstream and sharing it with other
 distributions, we simplify our lives significantly due to the free
 testing and development effort we receive (especially the integration
 of the init system and related packages like udev and util-linux).


I certainly can't fault that part. That's probably open source's greatest 
strength. ESR called it Linus' Law and he explained it succinctly in the 
CatB paper. My concern is about how cooperative and willing to fix known 
issues upstream will have. You can write patches, but only one person (Or 
possibly, a group of people.) can approve it for an official inclusion with 
upstream. How many patches has Lennart rejected on systemd? How many has he 
accepted? Of those has he rejected has he given a verifiable reason?

 Secondly, in a world where devices might come and go and their
 dependencies might be arbitrarily complex, the sysvinit architecture
 cannot work in a clean way. SysVinit was created when all setups could
 be assumed to be static, and this is simply no longer the case (this
 can best be seen in a setup with lots of raid/lvm/encrypted devices).
 

I admit to never using RAID/LVM/ENCRYPTION. But last I checked init had 
nothing whatsoever to do with how /dev is populated or managed. We have udev 
for that, and udev doesn't care what init system we use. All inits do is call 
udev when their scripts tell them to. I don't see how this makes systemd more 
viable than SysV when udev is what controls this instead, as udev works the 
same no matter if its SysV, Upstart, or systemd.

Perhaps you can clarify init's role in device population besides running udev 
when appropriate, as SysV is already capable of that?

 Cheers,
 
 Tom

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 06:27:04 pm Ng Oon-Ee wrote:
 On Thu, 2011-01-20 at 15:52 -0600, Yaro Kasear wrote:
  I was ALMOST behind a switch to systemd until I found out the guy behind
  it is Lennart Poettering. Now we can expect a half-broken init system
  that'll be in perpetual beta, and more passing off the buck on bug
  reports to
  distributions/drivers/whatever.
 
 I can see you already responded again to this thread, but my immediate
 reaction to this mail was o.0!

Lennart is the same person behind Pulse Audio, a known problematic sound 
daemon. What worries me is that systemd is much closer to the system, which 
might be potential for general all-around system breakage if systemd gets as 
bad as PA.

NOTE: I don't want to start a flame war here about PA or anything. I'm just 
concerned.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:03:23 pm Ng Oon-Ee wrote:
(snip)
 This talk is probably a year or so out of date however. Try pulseaudio
 now, I think you'll be pleasantly surprised. You'd also have noticed
 that actual bug reports on our forums/ML etc. concerning pulseaudio have
 dropped to close to nil.

I am currently using OSSv4. I don't know how accurate a reading of PA I'd get 
while using it.

Maybe I might temporarily switch to ALSA to give it a whirl.

At any rate, lets not go too far off topic here.

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:05:23 pm Ng Oon-Ee wrote:
 On Thu, 2011-01-20 at 18:55 -0600, Yaro Kasear wrote:
  On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote:
  (snip)
  
   - It's nice you can install it next to sysv-init. This makes it really
   easy to test without breaking the system.
  
  You can do this? I might try it out. If it works as expected in its stage
  of development, I'll quick being a jerk about it.
 
 I think you meant 'quit' =p. Freudian slip?

Actually, not sure how that typo got in there. Thanks for catching it. Yes, I 
did mean 'quit.'

 
  Also, how does that work? Do you choose an init at some point?
 
 I believe its been mentioned that you'd just alter the boot parameters
 in grub (or lilo if you use that).

Is this in the wiki?

Re: [arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Thursday, January 20, 2011 07:09:43 pm Sander Jansen wrote:
 On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear y...@marupa.net wrote:
  On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote:
  (snip)
  
  - It's nice you can install it next to sysv-init. This makes it really
  easy to test without breaking the system.
  
  You can do this? I might try it out. If it works as expected in its stage
  of development, I'll quick being a jerk about it.
  
  Also, how does that work? Do you choose an init at some point?
 
 See the wiki, it's a kernel boot parameter.
 
  - If you installed vala 0.10, systemd-git won't build, even though gtk
  is disabled. This is a bug in the configure script of systemd.
  Solution would be either to install vala-0.11 or remove vala from your
  system.
  
  I'm confused by this. Do you mean that vala's conflicting something out
  of the system or just causing a breakage in some way?
 
 There's a bug in configure script. It works fine if you don't have
 vala installed, but if you do have it installed it will bark at you if
 you have the wrong version.
 
  - I guess the initscripts-systemd is listed as an optional dependency
  of systemd, but I'm not sure how usefull systemd is without it...?
  
  Though I don't 100% know how systemd is, don't all init systems need
  scripts to be useful? I would think that installing systemd's
  initscripts would be important for it to do its work.
 
 Yeah, this is more a packaging issue.
 
  - The login console seems to be slightly messed up. I can login, but
  error/log messages keep being send to the terminal as well.
  
  What are the messages? Is there a bug in the bug tracker about this or is
  this purely an upstream concern?
 
 Just stderr output from the various daemons running. I'm guessing it
 goes to the wrong terminal.
 
  - I know how I can change the default target on the boot line, but can
  I set it anywhere else?
  
  Is that how you would run one init system over another?
 
 systemd has a concept of runlevels, but calls them targets. You can
 override the default on the kernel boot line.
 
  - sshd has listed network.service as a dependency, but what if you use
  NetworkManager instead?
  
  Would this be cause for a seperate set of daemon scripts just for systemd
  or are there plans to make it work with rc.conf in much the same way
  SysV does?
 
 systemd has unit files that replace the traditional sysv daemon
 scripts. They're much shorter and sweeter. The question was related to
 whether sshd should list network which is arch's /etc/rc.d/network
 script as a dependency.
 
 Cheers,
 
 Sander

I think I'll try this out. I'll be sure to file bug reports as necessary.

Re: [arch-general] When will Arch switch to Upstart

[Yaro Kasear]

On Wednesday, January 19, 2011 04:29:02 am Laurent Carlier wrote:
 Le mercredi 19 janvier 2011 11:16:41, Jelle van der Waa a écrit :
  On Wed, 2011-01-19 at 14:50 +0700, Madhur Ahuja wrote:
   Ubuntu and Fedora has already embraced it.
   
   Any ideas when will Arch switch to upstart based booting system ?
   
   http://upstart.ubuntu.com/
   
   Thanks,
   Madhur
  
  For the nex time, first try to implement this feature/thing in AUR and
  get it documented via the archwiki.
  
  If you want the devs to get interested in a new feature, atleast provide
  them with something to test and with arguments, cause you gave none...
 
 And ubuntu use it is not enough as an argument :-)
 
 ++

In my opinion: Ubuntu uses it is a very strong reason NOT to use Upstart.

Ubuntu may be a very user friendly distribution, but take that away and you 
get a distribution that's mediocre at the best of times. And its largely 
because the Ubuntu devs have no clue how to actually do a Linux system 
properly.

Upstart may be fast but I much prefer Arch's init system (With SysV 
pretending to act like BSD Init.) which is a lot more flexible and much 
simpler.

At the risk of sounding like a dick, sometimes I wish there was a way to flag 
ideas on this mailing list as Stupid Ideas(tm). Switching Arch to Upstart 
would be one of them.

Re: [arch-general] When will Arch switch to Upstart

[Yaro Kasear]

On Wednesday, January 19, 2011 12:53:44 pm C Anthony Risinger wrote:
 On Wed, Jan 19, 2011 at 12:35 PM, Yaro Kasear y...@marupa.net wrote:
  On Wednesday, January 19, 2011 04:29:02 am Laurent Carlier wrote:
  Le mercredi 19 janvier 2011 11:16:41, Jelle van der Waa a écrit :
   On Wed, 2011-01-19 at 14:50 +0700, Madhur Ahuja wrote:
   
   If you want the devs to get interested in a new feature, atleast
   provide them with something to test and with arguments, cause you
   gave none...
  
  And ubuntu use it is not enough as an argument :-)
  
  In my opinion: Ubuntu uses it is a very strong reason NOT to use
  Upstart.
 
 you are trolling? comments related to Ubuntu or their competence are
 wholly unrelated and highly irrelevant.
 
 i would guess that many of Arch's users began with Ubuntu, and then
 decided they were too l33t and wanted to try something more bare metal
 (probably to learn/grow); myself included.
 
 please try to restrict information output to quality discussion of
 sysvinit, upstart, systemd, or other init solutions and their merits.
 
 C Anthony

No, I'm not trolling. I don't see how my statement is really all that 
different than all the other one-line god, I hope not responses in this 
thread. I just gave my reasons, that's the only difference between my post and 
theirs.

And comments about Ubuntu and their competence are entirely relevant to this 
discussion, as Upstart is entirely their creation. Would you rather I talk 
about people who had nothing to do with its code? The Ubuntu devs are behind 
Upstart, they're not that great at what they do when it comes to the actual 
system side of Ubuntu. Therefore why should we consider Upstart an 
improvement.

How was that not relevant? It was entirely about the quality of Upstart as it 
was about the quality of Upstart's developers. And any programmer worth his 
salt could tell you that if you suck at programming or even just design, your 
software is going to suck, too.

You may not LIKE that I pointed this out about Ubuntu and Upstart, but it is 
absolutely 100% relevant.

I was one of those users who switched from Ubuntu to Arch. I didn't do it 
because I felt I was too l33t but because Ubuntu's many flaws started getting 
to me. Upstart was one of those flaws.

As I said before being falsely accused of being a troll by someone who 
couldn't make the connection between Ubuntu's developers and Upstart: Arch's 
current init system is perfectly fine, it's simple, easy to work with, 
flexible, and its fast enough. I can EASILY set up entirely new bootlevels 
with SysV on Arch (I did it with XBMC and I bet you my next lunch Upstart 
can't do it.), something Upstart goes out of its way to avoid.

So I'll say it again:

Arch switching to Upstart by default is a stupid idea. You want to use 
Upstart? Put a PKGBUILD on the AUR and use that. Don't crappify Arch just 
because you miss Ubuntu or think Arch should jump on some misguided bandwagon 
that takes Linux ass-backwards.

Re: [arch-general] When will Arch switch to Upstart

[Yaro Kasear]

On Wednesday, January 19, 2011 02:25:28 pm Isaac Dupree wrote:
 On 01/19/11 14:03, Yaro Kasear wrote:
  And comments about Ubuntu and their competence are entirely relevant to
  this discussion, as Upstart is entirely their creation. Would you rather
  I talk about people who had nothing to do with its code? The Ubuntu devs
  are behind Upstart, they're not that great at what they do when it comes
  to the actual system side of Ubuntu. Therefore why should we consider
  Upstart an improvement.
 
 Argument ad hominem.

This was not argument ad hominem. I didn't call you names or insult you. Learn 
what it means before using that phrase. 

 We can be precise; it's more obviously rude that
 way.  Scott James Remnant wrote Upstart.

For Ubuntu. As an Ubuntu developer. Why do you think upstart's main page is on 
the Ubuntu web site, and not just Launchpad?

 I can't speak for Ubuntu, but
 I've seen Remnant presenting and he seemed quite competent.  Software is
 hard; Upstart was the first attempt at changing 'init' in decades, so
 there was little experiential knowledge of Linux 'init' development when
 it started in 2006. 

And that leads to my next question: What makes Upstart necessary?

Nothing. Boot speed is a trivial reason to overhaul the way UNIX/Linux boots, 
especially for an init system that is needlessly complex and far less 
accessible than what we already had. If we switch to upstart, simply beign 
able to edit a file like /etc/rc.conf will be gone, and setting up daemons 
The Arch Way would become unnecessarily difficult.

The fact that init hasn't been changed in decades like you claim is because 
nobody worth their UNIX development skill felt init actually NEEDED a change. 
It still doesn't. Just because you CAN change it doesn't mean you NEED to 
change it. SysV Init is fine for Arch, maybe systemd might be a pleasant 
change, but it's not a necessary change either.

 In fact, in the process of writing Upstart, Remnant
 and his co-workers made Ubuntu boot faster largely by working with Xorg
 and Linux kernel developers.

Boot times are an incredibly trivial reason to upheave the actual system 
process of a system like Arch. Rarely does someone actually need to get to 
their desktop in such a hurry, and it's far less important than the system 
being stable or fast during actual runtime. Upstart moves things in the 
opposite direction of that.

 There are now upstream changes due to the
 risk Ubuntu took with Upstart.  *Arch* therefore now boots faster
 because of Remnant.

First I ever heard of Upstart being important enough for something MUCH bigger 
and MUCH more important changing how they work JUST for the sake of something 
MUCH smaller and MUCH less important to work correctly. I'm going to have to 
see official upstream patches or it didn't happen.

 He's a pretty smart guy who knows what he's doing
 even if some of us disagree with what he's doing; I was at his
 presentation How We Made Ubuntu Boot Faster
 http://events.linuxfoundation.org/linuxcon2010/remnant

Again, booting faster is a luxury. People talk about it as if its very 
important, but it's trivial compared to a system running and running well, two 
things Upstart's known for not promoting.

 
 That is equally no reason to switch to Upstart.

There is NO reason to switch to Upstart at all, except that the OP seems to 
think that just because Ubuntu and Fedora did it, we should too, and plenty of 
reasons NOT to switch to Upstart.

 We can be grateful to
 Remnant and choose the best (technically  socially) solution *for Arch*
 *in 2011*.  Of course he's enthusiastic about Upstart but I'm sure he
 wouldn't mind.

Again, Remnant made WHAT contributions to Arch to date? You plan on pulling 
him from his place as an Ubuntu dev where mediocre code is praised to make 
Arch run worse just for the sake of a couple seconds less boot time? Here's an 
idea, how about we just rewrute the initscripts to be more efficient. That'd 
be much less of a trouble.

 (I don't pretend to know which solution this is, though
 it sounds like Arch's current init system, or systemd, are likely to be
 default in the next year or two.)

Sounds like you already have done this. Blindly singing the praises of an 
Ubuntu developer just because he is a good public speaker and that he seems 
competent. Have you ever even tried configuring upstart manually? It fights 
you. Every step of the way. IT takes away that much flexibility from the 
system just for the sake of taking off a few seconds of boot time.

I have no opinion on systemd as an init system, as I have no experience with 
it. But I have used upstart enough to know that it'll take more than its 
developer acting like he's a good programmer for me to take it seriously.

 
 After writing the above, I checked my assumptions and Google found me
 Remnant's entirely reasonable blog post about systemd.
 http://netsplit.com/2010/04/30/on-systemd/

I'm talking about Upstart, not systemd. I'm not against

Re: [arch-general] kernel 2.6.37 BKL

[Yaro Kasear]

On Wednesday, January 05, 2011 05:51:02 pm Matthew Monaco wrote:
 Devs,
 
 Any plans about the BKL setting in .37? I've been running the rc's without
 it for a while now.

What is BKL?

Re: [arch-general] PulseAudio in [testing]

[Yaro Kasear]

On Sun, 2010-11-28 at 12:11 +0200, Χρήστος Κώτσαρης wrote:
 I believe this was the right choice. Pulseaudio should be in extra and all 
 applications build with pulse support.

Except for the fact that Pulse Audio is an incredible REGRESSION in
Linux sound and causes far more problems than it solves. Do a google
search on it sometime, you'd be surprised what a huge headache Pulse
Audio actually is.

 Regarding phonon, i believe KDE intends to drop it at some point, not sure 
 were i read that. I remember reading something about KDE 5 not including 
 phonon, but it may be FUD. Anyone more informed on the issue?

KDE has no intention of dropping Phonon. Largely because they just
implemented it as new in KDE 4. And they wouldn't drop it in favor of
something as low quality and unstable as Pulse Audio. GNOME might, but
their developers are idiots.

 In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to 
 target for all apps. The kind of functionality it provides it is needed if 
 modern distros are to compete with Windows 7. Windows 7 now provide the 
 functionality to switch sound cards on the fly without restaring the app 
 playing sound. This is possible only with Pulseaudio as far as i can tell in 
 the Linux world. And this is just one example.

Linux has no need for Pulse. ALSA works perfectly fine. Pulse is a
regression in Linux sound. If you think PA will catch Linux up to
Windows 7 (It should be noted Linux is way ahead of Windows 7 in all the
ways that actually count.), you're going to get a painful bite of
reality when countless Windows 7 users correctly point ou ttheir sound
Just Works where Linux USED TO before Pulse Audio came around and broke
absolutely everything. Besides, both KDE and GNOME already provide
user-friendly audio utilities that are easier to handle with Pulse Audio
and, here's the killer feature, don't break sound AT ALL.

 Imagine if you have a headset with included sound card, for example a 5.1 
 headset. Without Pulseaudio, it is a chore to switch sound to it, with 
 Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine 
 if a user tries to do it in Linux without pulse, he will be frustrated. Of 
 course, Arch users should be knowledgable enough to switch sound cards in 
 ALSA, but it still is a chore. And it is not the point.

Actually, ALSA has a pretty simple and easy means to switch to USB audio
devices. The Arch wiki even says so. Pulse might provide an easy way to
switch to it, but it's completely outweighed by the fact that there's a
70% chance Pulse Audio will break most (If not all.) your sound.

 The point is, Linux needs a sound daemon to provide modern user friendliness. 
 So it is a matter of time for GNOME and KDE to support it natively. KDE tried 
 it with phonon, but it seems phonon is more problematic than pulseaudio, with 
 less features. At least for me, when phonon sits on top of ALSA, i get all 
 sorts of messages informing me that some interface should be disabled, it is 
 annoying. Plus when i change a sound card, the app needs restarting.

Phonon is far less problematic than PA. HAving actually used both
extensively. Largely because Phonon doesn't hijack ALL sound on the
system it runs on like Pulse Audio, so that even if Phonon breaks (Has
yet to happen with me.) you can STILL use SOME sound, whereas in the
inevitable eventuality Pulse Audio breaks, ALL your sound goes with it,
even if you manage to kill it, because it took it on itself to take all
your sound over, which no other sound daemon does, and for damn good
reason.

 So yes, in time pulseaudio should become the default linux api for Linux/GNU, 
 if not already. If there are bugs, they could be solved if all those geniuses 
 bitching about it and use ALSA could be bothered to help a little.
 

First off, Pulse Audio is not a sound API like ALSA or OSS, it's a
Daemon, and a very crappy one at that. In fact, it's a crappy sound
daemon that breaks sound that it and its developers somehow convinced
themselves was a legit sound API akin to ALSA and OSS.

Second off, no, it should NOT become a universal default for Linux
because its a horrendous regression running on top of ALSA. Even the
Linux kernel developers themselves have said so, even the ALSA developer
suggested rewriting ALSA would be a far better alternative to Pulse
Audio.

Finally, the problems introduced in Pulse audio are NOT the fault of
ALSA, drivers, OR distributions no matter how much PA's upstream loves
to clamor for it to be true. The sad cold fact is Pulse Audio is buggy,
unstable, unnecessary, slow, bloated, and causes WAY more problems than
it solves.

In fact, there's no problems actually PRESENT in ALSA Pulse is actually
solving. Before Pulse came along, ALSA was doing very well.

If you were to ask the opinion of myself and my colleagues, I'd
recommend abandoning to idiotic sound daemon idea altogether and instead
use or create an audio abstraction library akin to libao. That would

Re: [arch-general] PulseAudio in [testing]

[Yaro Kasear]

On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
 On 29 November 2010 00:08, Yaro Kasear y...@marupa.net wrote:
  Once again, I say PA is far from the kind of quality I'd expect from a
  package in [extra], and I'm surprised the Arch devs are even considering
  it, especially in light of the fact that there's far more stable and
  useful packages in [community] getting passed up.
 
 Once again, nobody asked for opinions on PulseAudio, the software. If
 it does affect you directly, do report that here or the bugtracker. It
 was moved to [extra] for package-specific reasons, not just on a whim
 as you would like to think.

What packages actually REQUIRE Pulse Audio? I don't know of a single
Linux app to date that actually NEEDS it over what already exists in
ALSA itself.

Re: [arch-general] PulseAudio in [testing]

[Yaro Kasear]

On Mon, 2010-11-29 at 00:19 +0800, Ng Oon-Ee wrote:
 On Sun, 2010-11-28 at 17:49 +0800, Ray Rashif wrote:
  On 28 November 2010 11:24, Yaro Kasear y...@marupa.net wrote:
   On Sun, 2010-11-28 at 11:17 +0800, Ng Oon-Ee wrote:
   On Sat, 2010-11-27 at 18:21 -0600, Yaro Kasear wrote:
I don't see KDE upstream doing that. They have Phonon. What's more, 
most
KDE apps today count on Phonon being there. KDE upstream won't do that
without expecting to break KDE.
  
   Admittedly my view on this is skewed, since I follow PA's development
   pretty closely, but one of the devs on PA (Colin Guthrie) has mentioned
   getting various patches he's done for Mandriva's KDE implementation such
   that KDE's mixer and such supports pulseaudio natively. Phonon would
   output directly to pulse in that case, I believe.
  
  
   The point of which would be what exactly? All due respect, Phonon is
   already a sound daemon. To output sound through a sound daemon into
   ANOTHER sound daemon, particularly one as poor as Pulse Audio, is
   begging for latency and who knows how many other problems.
  
   And, again, it's redundant and unnecessary since Phonon's already a good
   sound daemon on its own merits.
  
  In fact, it handles all my audio pretty well, and even lets JACK take
  over when needed without my intervention. There's no PulseAudio or a
  kill command in that equation.
 
 I'll take both your words on it. Its worth noting that Pulseaudio
 automatically corks when JACK wants a sound-device (jack2 that is, not
 jack1). Running phonon atop pulseaudio wouldn't make sense if every app
 uses phonon. Due to other considerations (for example that all the major
 distros are pushing pulse), this may not be the case in the future.
  
  Anyway, Jan, everything works great, no troubles (with libpulse and
  without pulseaudio) on KDE. Good job.
 
 Yes, the lack of complaints (about actual problems) is really
 surprising.
 

It's probably because the masses of people who already know Pulse Audio
will break their sound aren't bothering to try it. I have a whole IRC
channel filled with people who, if they were to actually test this,
would FLOOD this entire discussion with problems that would make the
Arch devs reconsider this decision.

Re: [arch-general] Opinions on pulseaudio [WAS: PulseAudio in [testing]]

[Yaro Kasear]

On Mon, 2010-11-29 at 00:27 +0800, Ng Oon-Ee wrote:
 On Sun, 2010-11-28 at 10:18 -0600, Yaro Kasear wrote:
  On Mon, 2010-11-29 at 00:15 +0800, Ray Rashif wrote:
   On 29 November 2010 00:08, Yaro Kasear y...@marupa.net wrote:
Once again, I say PA is far from the kind of quality I'd expect from a
package in [extra], and I'm surprised the Arch devs are even considering
it, especially in light of the fact that there's far more stable and
useful packages in [community] getting passed up.
   
   Once again, nobody asked for opinions on PulseAudio, the software. If
   it does affect you directly, do report that here or the bugtracker. It
   was moved to [extra] for package-specific reasons, not just on a whim
   as you would like to think.
  
  What packages actually REQUIRE Pulse Audio? I don't know of a single
  Linux app to date that actually NEEDS it over what already exists in
  ALSA itself.
  
 Gnome. But as you've already stated yourself, their devs are idiots.
 Since you obviously use KDE, as all other enlightened souls do.
 
 I'm unsure on why you're directing such vitriolic hate on pulseaudio.
 70% sound system breakage? Regression which causes more problems than it
 solves? Perhaps you should specify[1] what you're talking about rather
 than generalizing. That is, if you're interested in being taken
 seriously.
 
 Split this off, its just noise to most, so I think many would just want
 to mute this new thread.
 
 [1] - note, a 'google about pulseaudio problems' doesn't count as
 specifying. Googling 'linux problems' gives far more, but we don't take
 that seriously, do we? Or 'KDE problems', or 'some-piece-of-software
 problems'
 

GNOME 3 isn't even released yet. There's no CURRENT dependency in Arch,
in [extra], for Pulse Audio.

Fine, Then I'll list all of its problems right here:

- It's unstable.
- It's got far too many unresolved bugs the upstream developers defer
INCORRECTLY elsewhere simply because they can't be bothered to fix their
software.
- It wastes a lot of RAM.
- It wastes a lot of CPU.
- It causes noticeable audio latency.
- It DOES NOT release sound to other daemons as your erroneously claim.
It will not turn itself off for JACK just as it won't turn itself off
for ESD or Phonon.
- It actually doesn't support ALSA that well, it's ALSA module is stuck
at 70% completion, with a lot of critical ALSA support stuck on that
missing 30%. Again, further upstream blame gets laid on ALSA or drivers
where it doesn't belong.
- It's not really necessary for any actual Linux audio needs, where
things like ESD and Phonon had already fixed the problems Pulse Audio
has no use for.
- Even the Pulse Audio devs at one point admitted it breaks Linux audio.
- A great deal of Linux applications have problems working with it, far
more than any other daemon to date. Upstream, rather than making Pulse
Audio abstract itself like ESD or Phonon does, seems to want app
developers to write their code SPECIFICALLY for Pulse Audio, which is
NOT how its done.
- An incredible array of utterly useless features (Like networking sound
in a day and age where all PCs have sound systems they can use
themselves. Never count on networking where an actual local system will
do.) that Pulse Audio fans never use bt love to brag about so they can
distract from Pulse Audio's obvious problems, just like you are doing
right now.
- Much, much more, but you get my point.

Maybe wait until GNOME 3 actually gets released before put something
unstable and useless in [extra] needlessly.

Re: [arch-general] Opinions on pulseaudio [WAS: PulseAudio in [testing]]

[Yaro Kasear]

On Sun, 2010-11-28 at 18:44 +0200, Ionuț Bîru wrote:
 On 11/28/2010 06:38 PM, Yaro Kasear wrote:
 
 
  Maybe wait until GNOME 3 actually gets released before put something
  unstable and useless in [extra] needlessly.
 
 
 our experience in packaging software, fixing bugs and debugging is far 
 superior than yours.
 
 we have just made a small step in adding default support in gnome, 
 instead of doing everything when gnome 3 is released.
 
 In this way we can ensure that everything works before pushing this 
 permanently.
 
 Just understand, Pulseaudio is optionally
 

I do. Most my response is to the people who think Pulse Audio is the
end-all Audio solution when it's far from actually being so (With the
fact it's clearly not stable or mature enough for [extra] as part of
this.). The opinion it should be a default for Arch, for example, or
that it should be the standard for Linux are idiotic, since, as I stated
many times before, Pulse Audio is crap that solves nothing and breaks
everything. I'll stop posting on this topic now.