On Sat, 2010-01-23 at 14:31 -0500, Ivan Jager wrote:
> Hi,
>
> Do you guys know where the openvz sparc kernels are, or why they
> weren't built if they don't exist?
[...]

This is an error in the release notes. Kernel packages with OpenVZ are
only built for amd64 and i386.

Ben.

--
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

For quite a while now we have been asking for people to adopt the
orphans in the [community] repo. Some of us have readopted packages that
belonged to us prior to the server move, and a few have even picked up
some of the leftovers. However, as of now there are 634 orphaned
packages in [community]. Therefore... any packages not adopted within
the next week that are not explicitly required by another package in
[community] will be dropped to AUR.


If you intend to adopt a package, please be sure that you adopt for both
architectures, if applicable. Additionally, please ensure you have
adopted both architectures for any packages you already maintain. There
are a handful of orphaned packages that only have one architecture.


Next Saturday (01/30/2010), I will go through the leftovers, adopt
anything that is required by another package in [community] myself, and
drop whatever is left to AUR.



Daniel J Griffiths (Ghost1227)

On Sat, Jan 23, 2010 at 21:31, Daniel J Griffiths
<ghost1227@archlinux.us> wrote:
> Next Saturday (01/30/2010), I will go through the leftovers, adopt anything
> that is required by another package in [community] myself, and drop whatever
> is left to AUR.
Is this really needed? I can understand if it's out of date or has
bugs that are not being fixed, but if there is a working binary, why
should we drop it?

On 24/01/10 12:40, Daenyth Blank wrote:

On Sat, Jan 23, 2010 at 21:31, Daniel J Griffiths
<ghost1227@archlinux.us> wrote:

Next Saturday (01/30/2010), I will go through the leftovers, adopt anything
that is required by another package in [community] myself, and drop whatever
is left to AUR.

Is this really needed? I can understand if it's out of date or has
bugs that are not being fixed, but if there is a working binary, why
should we drop it?


So... who takes the bugs or does the update when needed? If someone is
prepared to do that, then they should adopt the package.


Start adopting.

Allan

Hi,

'~$ lspci; 00:1e.2 Multimedia audio controller: Intel Corporation
82801FB/FBM/FR/FW/FRW(ICH6 Family) AC'97 Audio Controller (rev 03)'.
'~$ lsmod | grep snd; snd_intel8x0; ac97_bus; snd_pcm_oss;
snd_mixer_oss; snd_pcm; snd_seq_dummy; snd_seq_oss; snd_seq_midi;
snd_rawmidi; snd_seq_midi_event; snd_seq; snd_timer; snd_seq_device;
snd; soundcore; snd_page_alloc'.

What module of this set controls and displays the volume slider bars,
which I can see in alsamixer?
I grepped /usr/src/linux-source-2.6.31/sound/pci/intel8x0.c for "Master"
and obtained no hit. Neither for "Headphone".
What should I grep the output of '~$ strace alsamixer' for in order to
answer the question put?
I would like to know exactly what is controlled by the ALSAMixer volume
slider bar settings Master, MasterM, Headphone, PCM, Line, CD, Mic, Mic
Boos, Mic Sele, Phone, Aux, Mono Out, External, and Stereo M.
My sound chip is Analog Devices AD1981B. The circuit diagram of the
AD1981B does not mention these sliders.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Sat, January 23, 2010 20:21, Robert Nichols wrote:
> Robert Heller wrote:

>
> Gosh, then I guess the manpage for 'find' must be totally wrong
> where it
> says:
>
> -exec command ;
> ...
> The specified command is run once for each matched
> file.
>

Not wrong, just not very explicit regarding process. The man page
does not say that find acts upon each file as it is found, only that
it acts upon each file that is found. Neither does the man page
speak to the limits of the kernel configuration (MAX_ARG_PAGES)
implicitly used by cp, find, ls, etc.

The problem you have is that the selection of all qualified files is
completed before any are acted on by find. So, in your case of an
overlarge collection, the page limit is exceeded before any are
deleted. Taking each file as it is found and piping it to an
external rm command explicitly defines the process as find, delete
and find again, and thereby avoids hitting the page limit.

CentOS-5.3 was supposed to address this issue:

> Previously, the MAX_ARG_PAGES limit that is set in the kernel
> was too low, and may have resulted in the following error:
>
> execve: Argument list too long
>
> In this update, this limit has been increased to 25 percent of
> the stack size, which resolves this issue.

So, perhaps if you update to 5.3+ the problem might go away?
Although, in my opinion, piping find results through xargs is far
more reliable and portable.

Regards,

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

James B. Byrne wrote:
> On Sat, January 23, 2010 20:21, Robert Nichols wrote:
>> Robert Heller wrote:
>
>> Gosh, then I guess the manpage for 'find' must be totally wrong
>> where it
>> says:
>>
>> -exec command ;
>> ...
>> The specified command is run once for each matched
>> file.
>>
>
> Not wrong. The man page on find simply does not speak to the limits
> of the kernal configuration (MAX_ARG_PAGES) implicitly used by cp,
> find, ls, etc. It just lives within its means and fails when these
> do not suffice.
>
> The problem you have is that the selection of all qualified files is
> completed before any are acted on by find. So, in the case of
> overlarge collections, the page limit is exceeded before any are
> deleted. Taking each file as it is found and piping it to an
> external rm command avoids hitting the page limit.

When using the -exec action with the ";" terminator, the constructed
command line always contains the path for exactly one matched file.
Try it. Run "find /usr -exec echo {} ;" and see that you get one
path per line and output begins almost instantly. Do you really
believe that 'find' searched the entire /usr tree in that time?

Now if the "{}" string appears more than once then the command line
contains that path more than once, but it is essentially impossible
to exceed the kernel's MAX_ARG_PAGES this way.

The only issue with using "-exec command {} ;" for a huge number of
files is one of performance. If there are 100,000 matched files,
the command will be invoked 100,000 times.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On 1/25/10 9:33 AM, Robert Nichols wrote:
>
> When using the -exec action with the ";" terminator, the constructed
> command line always contains the path for exactly one matched file.
> Try it. Run "find /usr -exec echo {} ;" and see that you get one
> path per line and output begins almost instantly.

Don't forget to backspace delimit the semicolon; the proper way to get
data out of this example would be:

find /usr -exec echo {} ;


-- Corey / KB1JWQ

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Jan 25, 2010, at 10:48 AM, Corey Chandler <lists@sequestered.net>
wrote:

> On 1/25/10 9:33 AM, Robert Nichols wrote:
>>
>> When using the -exec action with the ";" terminator, the constructed
>> command line always contains the path for exactly one matched file.
>> Try it. Run "find /usr -exec echo {} ;" and see that you get one
>> path per line and output begins almost instantly.
>
> Don't forget to backspace delimit the semicolon; the proper way to get
> data out of this example would be:
>
> find /usr -exec echo {} ;

And don't forget to escape the curly braces which are expanded in some
shells:

# find /usr -exec echo {} ;

-Ross

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

unsubscribe