search for: onuser

> -----Original Message----- > > I've tried to use the pam_krb5 module, but as pam modules > validate the user as given, pam_krb5 is trying to match the > password to adsdomain.adsuser@ADSDOMAIN.REALM.... so it fails. > Pam_krb5 can be configured to convert winbind usernames back into principal names, by means of some regexp matching and template filling magic. It it

> On Sat, 3 Mar 2007, Aaron Gray wrote: >>> What is the motivation for this? The Win32 directory doesn't have >>> VS2003 >>> source code AFAIK, >> >> No just the VS2003 project and solution files and a about 30 sub >> directories >> which are not required on *nix platforms. So it would be good to have the >> "win32" files

On Sat, 3 Mar 2007, Aaron Gray wrote: >> We also have xcode projects. If you don't want to check them out and >> update them, with svn, you can use 'svn switch' on those directories. > > Okay. Still think a separate repository would be a good idea. A bit of work > to implement but would be a good idea as every *nix user has to implement a > 'svn switch'

Good morning Does R (or R users) have a formal training workshop/facility? Or do open-source softwares generally put the onus on the user to learn programming techniques? Are the workshops generally offered for the masses or is there one-on-one training available? Does one "go to" R for programming training ... or do R workshops travel around the country? Thanks for your

TL;DR: It's okay to close a bug, if you can justify it properly. Recently there has been a spate of bug-closing with what I would call inadequate documentation. Comments such as "Obsolete?" or "I assume it's fixed" could be applied to nearly every open bug we have. While this does reduce the open bug count--something I have been watching with morbid fascination

Chris wrote: > On Sat, 3 Mar 2007, Aaron Gray wrote: > > Okay. Still think a separate repository would be a good idea. A bit > > of work to implement but would be a good idea as every *nix user has > > to implement a 'svn switch' putting the onus on them rather than on > > the Windows user. > > I think you are mistakenly assuming that we aim to serve UNIX

Hello everyone, In an effort to get a better handle on nouveau's outstanding issues, I'm going to close all bugs that haven't seen any updates since 2011. I asked a core group of nouveau developers about this, and none of them seemed to object. Depending on how this goes, we may do the same thing up to the end of 2012, but that was more contentious. A lot of these bugs are pre-KMS,

Ok, maybe its a short walk, not a drive... I have it working just fine using smtp in development env from my OSX machine. When I deploy it to the server (which happens to be the same box where the smtp server lives), no email, no errors, nothing in the Postfix logs. I''ve double checked that my production and development action mailer settings are identical. Here''s whats in the

Isn't svn set up to auto-parse and post to the bug so you can just say "fixes bug 44444" and it parses it out? I mean, i added that to gcc like 15 years ago, i'm surprised we don't do this :) Nobody should have to add this info manually unless someone forgot to put it in a commit message. On Tue, Jun 12, 2018 at 1:36 PM, Tom Stellard via llvm-dev < llvm-dev at

I built R form source succesfully on my Fedora 22 box. No errors. I can read there is an issue with some manuals at build time when running makeinfo, especially these two: doc/manual/R-exts.texi cp doc/manual/R-intro.texi Some distro have hacks about makeinfo 5 in their build script. I wonder if some manuals are broken but couldn't see it when running make. May someone tells me more about

Here is a diff which should allow applying batch updates remotely ( as apposed to copying the batch files to the remote server and running rsync there ). Eg rsync --write-batch=test src dst1::dst rsync --read-batch=test dst2::dst Oli Dewdney diff -E -B -c -r rsync-2.5.6/flist.c rsync-2.5.6-remotebatch/flist.c *** rsync-2.5.6/flist.c Sat Jan 18 18:00:23 2003 ---

Well, NUT does "since forever" have reference docs on packaging into 8 or so entities each with its dependency tree, so heavy stuff can be pulled in on a need-to-have basis. As anything, it can be improved and updated, but it is there and many systems follow it. Those who missed the memo... the onus is on them. The `nut-scanner` tool (and its lib) design using run-time `dlopen()` of

Hi, Given David's comments about an echo-chamber, I thought I might as well throw my oar in and say I'm strongly in favour of this. I'm not particularly fussed on the wordsmithing or the verbosity. In fact one of the (unfortunate) primary uses of this document surely will be as reference when a misbehavior occurs, so spelling at least some things out in full might be useful in that

A. This RFC outlines a proposal regarding non-8-bit-byte support that got positive reception at a Round Table at EuroLLVM19. The general topic has been brought up several times before and one good overview can be found in a FOSDEM 2017 presentation by Jones and Cook: https://archive.fosdem.org/2017/schedule/event/llvm_16_bit/ In a nutshell, the proposal is for the llvm community

https://gcc.gnu.org/viewvc/gcc/hooks/ is how it was done. This used the incoming email handling for bugzilla i set up. These days, you could just use bugzilla's rest API IE a simple variant of https://github.com/mozilla/github-bugzilla-pr-linker/blob/master/app/app.py should work as a commit hook. That thing is written as a service, you just need the find/add parts of the rest api, rip

Hi, this does sound like a useful idea - although for the principle of least surprise and for variation in deployments, I'd rather have it as a (non-default state of a) configuration toggle that can be set via `upsmon.conf`: whether this particular client exits after processing FSD or not. The onus for the rest would be on general systems integration - e.g. ensure that init scripts `K*`ill the

On Wed, Apr 3, 2013 at 5:44 PM, Tom Stellard <tom at stellard.net> wrote: > On Wed, Apr 03, 2013 at 05:12:42PM -0400, Sean Silva wrote: > > On Wed, Apr 3, 2013 at 4:09 PM, Tom Stellard <tom at stellard.net> wrote: > > > > > > > > > > How many customers out there are shipping their LLVM-based products > > > > without actually including

Sanjoy, The point is this, you have to take a stand one way or the other on the function-inlining issue: [1. this function *always* executes statement S, F(a) { If (a == a) S; } but in llvm if you inline it and “a” happens to be “undef” then nothing can be said about whether statement S is executed. This is indefensible.] My belief is this: that llvm exists for a

Is it possible to have a slightly more elaborate description, such as: BackwardCompatibleTo: x.x-x and if the new version is _not_ backward compatible, this would be the current version number? Just my $0.02... Andy -----Original Message----- From: Torsten Hothorn [mailto:Torsten.Hothorn@rzmail.uni-erlangen.de] Sent: Monday, October 28, 2002 7:25 AM To: ripley@stats.ox.ac.uk Cc:

> On Jun 16, 2017, at 8:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Peter, > > On Tue, Jun 13, 2017 at 10:27 AM, Peter Lawrence via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Here’s what seems to really be going on >> >> “undef” === models an uninitialized register, but > > No, it specifically does