On Tue, Sep 2, 2014 at 2:11 PM, Pat Riehecky wrote:
>
> The sources were taken from git. They were then compared to the sources
> from the public Release Candidate provided by upstream on April 22 2014.
> There were very few changes from this Release Candidate to the official
> release.
Nice wor
Elaborating on Oleg Sadov's suggestion...
On Fri, Aug 29, 2014 at 9:16 PM, Yasha Karant wrote:
>
> ykarant@jb344 Downloads]$ /usr/bin/AfterShotPro2X64
> Install Path: /opt/AfterShotPro2(64-bit)
> LD_PATH:/opt/AfterShotPro2(64-bit)/lib:
> XLIB_SKIP_ARGB_VISUALS: 1
> ./Aft
On Tue, Jul 15, 2014 at 11:11 AM, ToddAndMargo wrote:
>
>> Who would this differ from the "sync" command?
>
>
> "who" should have been "how"
As someone else said, "sync" just synchronizes the copy on disk with
the copy in memory; i.e. it forces a flush of dirty pages to disk. The
kernel will stil
On Tue, Jul 15, 2014 at 10:44 AM, Paul Robert Marino
wrote:
> I have a question about your test did you unmount the stick between
> runs of rsync. if not you may have already had all of the information
> about the filesystem cached in memory instead of having to search the
> FAT table for informat
On Fri, Jul 11, 2014 at 10:24 PM, ToddAndMargo wrote:
>
> Hi Pat,
>
> --modify-window=1
> 3 hr - 9 sec
>
> --modify-window=10
> 3 hr - 8 sec
>
> Rat! I really though this sounded right
Oh, well...
> Any way to turn of the check sum testing?
Well, there is the "--whole-file" option.
On Fri, Jul 11, 2014 at 1:40 PM, Patrick J. LoPresti wrote:
>
> Try giving the "--size-only" option to rsync.
Better yet, try "--modify-window=1". From the rsync man page:
--modify-window
When comparing two timestamps, rsync treats the timestamps as
On Fri, Jul 11, 2014 at 1:20 PM, ToddAndMargo wrote:
> On 07/11/2014 01:04 PM, Stephen John Smoogen wrote:
>>
>> So rsync is going to have to read every file on target and host and see
>> if various things have changed.
Not true, at least by default... rsync assumes that if the files'
names, time
On Wed, Jul 9, 2014 at 1:27 PM, Lamar Owen wrote:
>
> I don't recall if I had to specify that option or not with CentOS 5.10:
> +++
> [root@backup-rdc ~]# df -h
> FilesystemSize Used Avail Use% Mounted on
> ...
> /dev/mapper/plates-cx3--80
>
On Tue, Jul 8, 2014 at 8:06 AM, Lamar Owen wrote:
>
> It's 'let's silently stop working when you pass 16TB of occupied space on
> your 24TB filesystem and no longer even mount it on bootup.'
You get a similar problem even on 64-bit systems unless you use the
"inode64" mount option.
"Similar prob
On Tue, Jul 1, 2014 at 1:28 PM, Andras Horvath wrote:
> On Tue, 1 Jul 2014 13:19:10 -0700
>> Something like this is more sane:
>>
>> sysctl -w vm.dirty_background_bytes=67108864
>> sysctl -w vm.dirty_background_bytes=134217728
Cut&paste error there. That second line should read
"vm.dirty_byte
On Tue, Jul 1, 2014 at 11:29 AM, Andras Horvath wrote:
>
> I restarted copying again, and in a minute the CPU hung again with 100% I/O
> wait. The "iotop" output shows absolutely nothing, as if there was no load on
> the disks at all. Interrupt and context switch is around 20-50, so almost
> no
On Thu, Jun 19, 2014 at 6:52 AM, Lamar Owen wrote:
>
> Have you read the RHEL subscription terms of service? There have been
> numerous articles, written by attorneys, on this issue.
I do not care what any lawyer has to say on this topic, because this
is not a legal question.
Absolutely everyon
On Thu, Jun 19, 2014 at 6:00 AM, Lamar Owen wrote:
>
> If the spec, patches, and sources are all committed with the same commit ID
Has Red Hat made any commitment to operate in this fashion?
If not, why would you assume this?
> for a particular package, you can grab the updated spec file (using
(different topic, different reply)
On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen wrote:
> The various spec files include the release numbers, and you can track
> the spec files with their commit IDs.
Could you be more specific? In particular, is there a reliable,
automated procedure to obtain a gi
On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen wrote:
> On 06/14/2014 12:58 AM, Patrick J. LoPresti wrote:
>>
>> The reason to release them at all is to comply with the GPL. Such
>> encumbrances would thwart that compliance.
>
>
> Red Hat only has to directly distribu
On Tue, Jun 17, 2014 at 1:25 AM, Andras Horvath wrote:
>
> I'm having problem with the latest kernel version for some time now. The
> previous kernel version boots fine and everything works just well, but the
> latest kernel (v2.6.32-431.17.1.el6.x86_64) cannot boot and Grub says
> something li
On Fri, Jun 13, 2014 at 7:46 PM, Jamie Duncan wrote:
>
> If they're not released to the public, they are almost guaranteed to be
> encumbered in a manner similar to the binary RPMs, which would make that
> illegal.
> I haven't looked for changes to the EULA with RHEL7 yet, but I would imagine
>
On Fri, Jun 13, 2014 at 6:31 PM, Akemi Yagi wrote:
>
> Just wanted to make a short note to say that source DVDs are available
> to RH customers.
>
In that case, why should Scientific Linux bother with any of this git
stuff? All the SL maintainers need is one (1) Red Hat customer,
anywhere on the
On Fri, Jun 13, 2014 at 6:00 PM, Nico Kadel-Garcia wrote:
>
> Nope. They're entirely distinct repositories with straight imports
> applied as step one, no cloning of the upstream RHEL git repos.
Not exactly what I meant; see below.
>> This seems a minimal requirement for sanity. Are you saying t
On Thu, Jun 12, 2014 at 9:11 PM, Nico Kadel-Garcia wrote:
>
> git repositories *can* be as easy to use as SRPM's, *if* they are
> tagged, and *if* there is a way to obtain an index of the relevant
> tags of a particular point release. So the risk isn't in using git:
> it's in the lack, so far, of
On Tue, Apr 8, 2014 at 10:36 AM, Jeffrey Anderson wrote:
> Is SL5 vulnerable, and will there be a patch?
RHEL / CentOS / SL 5.x ship with OpenSSL 0.9.8(x), which is NOT vulnerable.
- Pat
You can use a bind mount to make an ext4 directory appear in the VFAT tree.
Do "man mount" and search for "bind", and/or search the web for "bind mount".
- Pat
On Thu, Apr 3, 2014 at 8:40 PM, ToddAndMargo wrote:
> Hi All,
>
> I have a file that is going to be too big to
> fit on a VFAT partit
I do not suppose there is any chance of the RHEL 5.x version of the
Developer Toolset being released for Scientific Linux (?)
Not every development environment is living in 2014. Nor 2013. Nor 2012. Nor...
Thanks.
- Pat
On Thu, Jan 23, 2014 at 11:51 AM, Pat Riehecky wrote:
> This release only
Red Hat has released a compilation environment supporting C++11 as
part of the "Red Hat Developer Toolset" for RHEL 6.x:
https://access.redhat.com/knowledge/docs/Red_Hat_Developer_Toolset/
I am curious to know whether anybody has recompiled this for
Scientific Linux, whether anybody has an in
24 matches
Mail list logo
