On Thu, Jan 16, 2014 at 08:23:52PM +0100, Tobias Stoeckmann wrote:
> Hi,
>
> the library function getusershell(3) assumes that the smallest possible
> line in /etc/shells would be 3 chars (slash, a char, new line):
> In that case, there are at max sb.st_size / 3 of lines. Well, that is not
> enti
Are you using NTFS? Probably not. So why have you reserved 16K for the
NTFS hash table?
We can postpone nthashinit() until mount and save memory for people
who aren't using ntfs. Also, the other init function, toupper_init,
doesn't do anything at all.
Index: ntfs_ihash.c
=
Hi,
the library function getusershell(3) assumes that the smallest possible
line in /etc/shells would be 3 chars (slash, a char, new line):
In that case, there are at max sb.st_size / 3 of lines. Well, that is not
entirely correct. The last line could be just 2 chars, skipping the
trailing new l
Hello,
the following diff addresses CVE-2013-4353
(OpenSSL - TLS record tampering bug).
Index: src/ssl/s3_both.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/s3_both.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 s3_both.c
--- src
On Wed, Jan 15, 2014 at 11:41:05PM -0800, Philip Guenther wrote:
> On Wed, Jan 15, 2014 at 11:07 PM, patrick keshishian
> wrote:
> > Now here, I need an expert's help. I must be looking at
> > this upside down or sideways, because I don't see where
> > ulpt_do_write() is called, well, it is calle
On 2014/01/16 08:53, Sébastien Marie wrote:
> Hi,
>
> Does it make sens to have an option to require package to be signed ?
It makes more sense to just enable that by default, when we are happy
with the infrastructure and usage.
On Thu, Jan 16, 2014 at 09:02:21AM +, Stuart Henderson wrote:
> But if this code is to do some necessary initialization for a particular
> printer that can be matched by IDs, adding support right in the ulpt(4)
> driver would probably be better,
Agreed.
> there's already some framework for ma
On 2014/01/15 23:07, patrick keshishian wrote:
> Setting that aside, it doesn't look like I can use ulpt device
> to write a dedicated "driver" for this printer. Is this correct?
> Do I need to "fudge" the kernel to not attach this device to
> ulpt but instead as ugen? Is there a better way? I rath