On Mon, Jan 3, 2011 at 3:43 PM, Ted Ts'o wrote:
> On Mon, Jan 03, 2011 at 12:26:29PM +0100, Olaf van der Spek wrote:
>>
>> Given that the issue has come up before so often, I expected there to
>> be a FAQ about it.
>
> Your asking the question over (and over... an
On Mon, Jan 3, 2011 at 11:35 AM, Shachar Shemesh wrote:
> BTW - feedback welcome.
Where are the regressions vs the non-atomic variant listed?
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ar
On Mon, Jan 3, 2011 at 11:35 AM, Shachar Shemesh wrote:
> On 02/01/11 17:37, Olaf van der Spek wrote:
>>
>> A userspace lib is fine with me. In fact, I've been asking for it
>> multiple times. Result: no response.
>>
>>
>
> Excuse me?
>
> You (we
On Mon, Jan 3, 2011 at 6:28 AM, Enrico Weigelt wrote:
> * Ted Ts'o schrieb:
>
>> This is possible. It would be specific only to file systems that
>> support inodes (i.e., ix-nay for NFS, FAT, etc.).
>
> FAT supports inodes ?
ix-nay: no/except
Olaf
--
To UNSUBSCRIBE, email to debian-devel-req
On Mon, Jan 3, 2011 at 2:59 PM, Shachar Shemesh wrote:
> On 03/01/11 14:54, Olaf van der Spek wrote:
>
>>
>> That's one of the more interesting parts.
>>
>
> It sure is to you. I'm not sure about other users. I'll tell you what - I'll
Does
On Mon, Jan 3, 2011 at 12:53 PM, Shachar Shemesh wrote:
>> Where are the regressions vs the non-atomic variant listed?
>
> nowhere, yet. It's not released.
That's one of the more interesting parts.
Does it destroy ACLs? Didn't see any code to preserve them.
Olaf
--
To UNSUBSCRIBE, email to de
On Mon, Jan 3, 2011 at 4:25 AM, Ted Ts'o wrote:
> On Sun, Jan 02, 2011 at 04:14:15PM +0100, Olaf van der Spek wrote:
>>
>> Last time you ignored my response, but let's try again.
>> The implementation would be comparable to using a temp file, so
>> there'
On Sun, Jan 2, 2011 at 7:55 PM, Adam Borowski wrote:
> Note that on the other side of the fence there's something called TxF
Not GA AFAIK.
> And what if you're changing one byte inside a 50 GB file?
> I see an easy implementation on btrfs/ocfs2 (assuming no other writers),
> but on ext3/4, that'
On Sun, Jan 2, 2011 at 6:14 PM, Henrique de Moraes Holschuh >> Maybe I
wasn't clear, in that case I'm sorry. To me, O_ATOMIC is
> Whether this should map to O_ATOMIC in glibc or be something new, I don't
> care. But if it is a flag, I'd highly suggest naming it O_CREATEUNLINKED or
> something else
On Sun, Jan 2, 2011 at 1:52 PM, Henrique de Moraes Holschuh
wrote:
> Olaf, O_ATOMIC is "difficult" in the kernel sense and in the long run. It
> is an API that is too hard to implement in a sane way, with too many
> boundary conditions.
>
> OTOH, you don't need O_ATOMIC. You need a way for easy
On Sun, Jan 2, 2011 at 8:09 AM, Ted Ts'o wrote:
>> You could ask for a new (non-POSIX?) API that does not ask of a
>> POSIX-like filesystem something it cannot provide (i.e. don't ask for
>> something that requires inode->path reverse mappings). You could ask
>> for syscalls to copy inodes, etc.
On Sun, Jan 2, 2011 at 1:37 AM, Steve Langasek wrote:
> I don't think there's much room for argument at all, the FHS definition of
> /lib is pretty clear. :)
>
> Yes, this does cause problems for autotools and the like when it comes time
> to install, since this FHS-mandated split between /usr/lib
On Sun, Jan 2, 2011 at 12:03 AM, Enrico Weigelt wrote:
> I doubt that the only proper solution. As said, an (userland)
> filesystem could also do fine.
Do you think distros like Debian would install such a setup by default?
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
On Sat, Jan 1, 2011 at 7:13 PM, Cyril Brulebois wrote:
> Olaf van der Spek (01/01/2011):
>> > Doing it in the kernel would be fine (maybe DLM could be used here),
>>
>> What's DLM?
>
> CONFIG_DLM.
DLM seems independent of atomic updates.
Olaf
--
To UNSU
On Fri, Dec 31, 2010 at 5:08 PM, Enrico Weigelt wrote:
>> Not true. Renaming a running executable works just fine, for example.
>
> Well, has been quite a while since I last used Windows, but IIRC
> renaming an running executable was denied.
Maybe on FAT. However, that's OT.
>> >> > Why not desi
On Sat, Jan 1, 2011 at 5:11 PM, Michael Biebl wrote:
> For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the
> *.a
> and *.la libtool files to /lib too.
>
> My original patch [1] for libcryptsetup (#604936) handled this diffently. It
> only moved the *.so.* files to /lib an
On Fri, Dec 31, 2010 at 3:58 PM, brian m. carlson
wrote:
>> These cases aren't that rare. Windows, for example, tends to deny
>> renames on open files, as they're also identified by the filename.
>> (yes, there're other solutions for this problem, eg. having some
>> internal-only inode numbering,
On Fri, Dec 31, 2010 at 3:44 PM, Enrico Weigelt wrote:
> * Olaf van der Spek schrieb:
>
>> > Well, they're an fundamental concept which sometimes *IS* significant
>> > to the applications. It's very different from systems where each
>> > file has
On Fri, Dec 31, 2010 at 2:57 PM, Enrico Weigelt wrote:
>> To me, inodes are an implementation detail that shouldn't be exposed.
>
> Well, they're an fundamental concept which sometimes *IS* significant
> to the applications. It's very different from systems where each
> file has exactly one name (
On Fri, Dec 31, 2010 at 12:51 PM, Henrique de Moraes Holschuh
wrote:
> On Fri, 31 Dec 2010, Olaf van der Spek wrote:
>> Ah, hehe. BTW, care to respond to the mail I send to you?
>
> There is nothing more I can add to this thread. You want O_ATOMIC. It
That's a shame.
On Fri, Dec 31, 2010 at 3:17 AM, Henrique de Moraes Holschuh
wrote:
> On Thu, 30 Dec 2010, Henrique de Moraes Holschuh wrote:
>> BTW: safely removing a file is also tricky. AFAIK, one must open it RW,
>> in exclusive mode. stat it by fd and check whether it is what one
>> expects (regular file, o
On Thu, Dec 30, 2010 at 11:58 PM, Christian Kastner wrote:
> to package-build-audit *only* is a pain. For example, it is easy to
> monitor *all* access to /etc/shadow or changes to /bin/login, it is
> quite hard to limit the monitoring to a *process tree* (our building
> process).
Does the build
On Thu, Dec 30, 2010 at 7:46 PM, Ben Hutchings wrote:
>> You're kidding me. Got any source to back this up?
>
> http://support.microsoft.com/?kbid=172190
Interesting. Although no longer available on Vista / 7.
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subje
On Thu, Dec 30, 2010 at 7:20 PM, Shachar Shemesh wrote:
>> Depending on /proc is probably not reasonable.
>> Are you sure it will be atomic? ;)
>>
>>
>
> open old file, get fd (we'll assume it's 5). Do readlink on /proc/self/fd/5,
> and get file's real path. Do everything in said path. It's atomic
On Thu, Dec 30, 2010 at 7:15 PM, Shachar Shemesh wrote:
> If my (extremely leaky) memory serves me right, Windows has it. It's called
> "delete and then rename". It is not atomic (since when do Windows care about
> not breaking stuff), but it does exactly that.
>
> If you delete a file and quickly
On Thu, Dec 30, 2010 at 6:48 PM, Henrique de Moraes Holschuh
wrote:
>> Why not?
>
> You touched it, it is not the same file/inode anymore.
That's again a regression from the non-atomic case.
>> How does it handle meta-data you don't know about yet?
>
> It doesn't. You need a "copy inode without
On Thu, Dec 30, 2010 at 4:24 PM, Henrique de Moraes Holschuh
wrote:
> On Thu, 30 Dec 2010, Olaf van der Spek wrote:
>> The reason I asked for a kernelland solution is because it's hard if
>> not impossible to do properly in userland. But some kernel devs (Ted
>> and
On Thu, Dec 30, 2010 at 4:20 PM, Henrique de Moraes Holschuh
wrote:
>> What if the target name is actually a symlink? To a different volume?
>
> Indeed. You have to check that first, of course :-( This is about safe
> handling of such functions, symlinks always have to be derreferenced and
> thei
On Thu, Dec 30, 2010 at 4:12 PM, Shachar Shemesh wrote:
> No. I was doing it as code to accompany an article on my company's site
> about how it should be done. I was originally out to write the article, and
> then decided to add code. A good thing, too, as recursively resolving
> symbolic links i
On Thu, Dec 30, 2010 at 3:51 PM, Shachar Shemesh wrote:
> I'm working on one under the MIT license. Will probably release it by the
> end of this week. Will also handle copying the permissions over and
> following symlinks.
Sounds great!
Got a project page already?
What aboue file owner? Meta-dat
On Thu, Dec 30, 2010 at 12:46 PM, Henrique de Moraes Holschuh
wrote:
> write temp file (in same directory as file to be replaced), fsync temp
What if the target name is actually a symlink? To a different volume?
What if you're not allowed to create a file in that dir.
> If we could use some sys
Since the introduction of ext4, some apps/users have had issues with
file corruption after a system crash. It's not a bug in the FS AFAIK
and it's not exclusive to ext4.
Writing a temp file, fsync, rename is often proposed. However, the
durable aspect of fsync isn't always required and this way has
On Fri, Dec 24, 2010 at 3:05 PM, Hans-J. Ullrich wrote:
> Yeah, the bug was reported, the bug was fixed, but the version with the fix is
> not beein updated in testing.
Link to bug report?
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
On Mon, Dec 13, 2010 at 11:42 PM, Vincent Danjean wrote:
> On 12/12/2010 20:27, Olaf van der Spek wrote:
>> On Sat, Dec 11, 2010 at 6:25 PM, Lars Wirzenius wrote:
>>> On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
>>>> I agree it's not opti
On Mon, Dec 13, 2010 at 12:06 AM, David Weinehall wrote:
>> I agree it's not optimal, hence my push for auto linking.
>
> So, let me get this straight:
>
> Either Debian, and all other distributions that are to support boost,
> patch gcc (one of the most complex and most important codebases in the
On Sat, Dec 11, 2010 at 6:25 PM, Lars Wirzenius wrote:
> On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
>> I agree it's not optimal, hence my push for auto linking.
>
> Can you provide a link to a page giving a description of this
> auto-linking stu
On Fri, Dec 10, 2010 at 7:52 PM, Vincent Danjean wrote:
> Here, you are wrong. If I want to use the 'filesystem' part of boost,
> I (as a user of the library) must be able to find all required info
> only from the part of boost that I want to use.
> "pkg-config --libs boost_filesystem" is one stan
On Fri, Dec 10, 2010 at 3:28 PM, Vincent Danjean wrote:
> [C] selection of the "tool chain"
> Comment: this seems to be very boost specific!
Not necessary at the moment.
> For what I saw, there is the MT/no thread choice. Are there others ?
> It is possible that boost will be used by differ
On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh wrote:
>> So?
>
> When we write code, we write it with the intention and expectation
> that it will be built using a standards-conforming compiler. I.e.
> one which implements the C and/or C++ language specification, and
> which also implements standar
On Fri, Dec 10, 2010 at 11:00 AM, Paul Martin wrote:
> On Fri, Dec 10, 2010 at 10:17:53AM +0100, Sandro Tosi wrote:
>
>> If you really care about this problem, which is nice, try to get
>> logrotate fixed.
>
> As I have said before, I do welcome patches that don't break existing
> functionality or
On Fri, Dec 10, 2010 at 9:43 AM, Michael Tautschnig wrote:
>> These lines from this package's maintainer scripts suggest that it likely
>> is affected by the vulnerability:
>>
>> ---
>> chmod 640 $FRESHCLAMLOGFILE
>> chown "$d
On Fri, Dec 10, 2010 at 2:38 AM, Fernando Lemos wrote:
> Hi Olaf, Roger
>
> On Thu, Dec 9, 2010 at 11:00 AM, Olaf van der Spek
> wrote:
> [...]
>>> Now, pkg-config isn't standardised /either/, but it's useful because
>>> it will work with any
On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh wrote:
>> I was wondering why you considered the auto linking stuff to be so horrible.
>> IMO the best solution would be to get auto link support into GCC too.
>
> It's non standard
> - it's not specified by ISO C
> - it's not specified by SUS/POSIX
So?
On Wed, Dec 8, 2010 at 9:52 PM, Tristan Schmelcher
wrote:
>> Isn't debsums already filling that nieche?
>>
>> MfG
>> Goswin
>>
>
> I find debsums to be too basic for my needs. apt-diff is my attempt to
> improve upon it. I often want to answer the question "how does package
> X on my machin
On Wed, Dec 8, 2010 at 10:05 AM, Petter Reinholdtsen wrote:
>
> [Marc Haber]
>> Many Debian-Packages use Debian-packagename as an account name to
>> avoid naming clashes. This is disputed though, so you may choose
>> differently. I'd name the account Debian-inadyn and live with the
>> fact that so
On Wed, Dec 8, 2010 at 1:09 PM, Osamu Aoki wrote:
> Previously here, people has suggested that in some other unix distro
> (FreeBSD?) naming of such account as _inadyn with preceding underscore
> are used to avoid such name crash. Although this seems more elegant
> than Debian-inadyn, it is not y
On Mon, Dec 6, 2010 at 2:50 PM, Roger Leigh wrote:
>> >> These are using proprietary vendor-specific #pragmas. It's pretty
>> >
>> > True, but IMO the concept seems pretty useful.
>> >
>> > Why do you think it's horrible? It appears to work well.
>> >
>> >> horrible, not to mention fragile--if an
On Fri, Dec 3, 2010 at 11:38 PM, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote:
>>> > The header is just a text file. It doesn't contain any library
>>> > dependency information (or version information) at all, and there's
&g
On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote:
>> > The header is just a text file. It doesn't contain any library
>> > dependency information (or version information) at all, and there's
>>
>> boost/version.hpp
>
> We only care about SONAME versions, not release versions, and we only
> need
On Fri, Dec 3, 2010 at 11:04 PM, Roger Leigh wrote:
>> The header knows what version it is, so it can use that to link to the
>> correct lib.
>
> The header is just a text file. It doesn't contain any library
> dependency information (or version information) at all, and there's
boost/version.hpp
On Fri, Dec 3, 2010 at 10:38 PM, Roger Leigh wrote:
>> Wouldn't this only happen on a major version change of the Boost package?
>> Thus requiring a recompile?
>
> This is hopefully what would happen. But there's no guarantee that
> this would be the case, and that's really down to whatever polic
On Fri, Dec 3, 2010 at 10:27 PM, Roger Leigh wrote:
> Windows is even worse, but developers for that platform are
> masochistic by nature. They install multiple versions in separate
> directories, obviously not in standard locations because there are
> none, and hard code the paths in their sourc
On Fri, Dec 3, 2010 at 10:09 PM, Roger Leigh wrote:
> Now, consider what happens if libboost_filesystem drops its
> libboost_system dependency. NOTE: we're not considering rebuilding
> from source here, we're concerned with BINARY compatibility, i.e.
> our compiled program working with future boo
On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh wrote:
> Why? If you link indirectly today, and later on boost_filesystem
> drops its boost_system dependency, your code will break because
> those inlined functions are in *your* code, not the filesystem
> library. You'll get a link failure. By linki
On Fri, Dec 3, 2010 at 3:28 PM, Roger Leigh wrote:
>> You can't make all application know what headers are doing, since that
>> could change.
>
> pkg-config support for Boost is a long-standing issue. Unfortunately,
> there's no usable alternative that provides this information, TTMOBK.
MSVC has
On Thu, Dec 2, 2010 at 5:57 PM, Thomas Thurman
wrote:
> I am proposing an escape sequence which, when transmitted over SSH or
> telnet, requests the client to display a desktop notification. I have
> written up a description, with some example code, at
>
> http://people.collabora.co.uk/~tthurman/
On Mon, Nov 29, 2010 at 8:23 PM, Raphael Hertzog wrote:
> (Dropping bug report)
>
> On Mon, 29 Nov 2010, Olaf van der Spek wrote:
>> > Hence the fact that all file system developers, whether they were
>> > btrfs developers or XFS developers or ext4 developers, mad
On Mon, Nov 29, 2010 at 4:18 PM, Ted Ts'o wrote:
> Lots of users have complained about the desktop performance problem,
> but the reality is we can't really solve that without also taking away
> the magic that made (c) happen. Whether you solve it by using
> data=writeback and stick with ext3, or
On Mon, Nov 29, 2010 at 3:58 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Bug#605009: serious performance regression
> with ext4"):
>> Probably not an issue for dpkg, but in general:
>> Don't you reset meta-data that way?
>
> Yes. If you want to
On Mon, Nov 29, 2010 at 2:56 PM, Bastian Blank wrote:
> Again: Please quote the standard instead of crying. Your view of things
> disallows many of the recent improvements in filesystems, so you have to
> show evidence. All the databases and other reliable data handing tools
> uses fsync since a l
On Mon, Nov 29, 2010 at 2:22 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Bug#605009: serious performance regression
> with ext4"):
>> Are there any plans to provide an API for atomic (non-durable) file
>> updates, not involving fsync?
>
> Yes. Such
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o wrote:
> I am guessing you are doing (a) today --- am I right? (c) or (d)
> would be best.
Are there any plans to provide an API for atomic (non-durable) file
updates, not involving fsync?
Would be simpler (for apps), faster and more general (because it
On Fri, Nov 26, 2010 at 3:53 PM, Raphael Hertzog wrote:
> It all started with report of corrupted (zero-length) files on ext4/ubifs
> (see http://bugs.debian.org/430958). We did the right thing to fix this
> which is to call fsync() on the fly on each file that dpkg unpacks. That
Is durable requi
On Fri, May 21, 2010 at 3:49 AM, Paul Wise wrote:
> Probably the solution to that bug is to read the user from the
> lighttpd configuration instead of hard-coding it. lighttpd -p can
> probably help here. Not sure how you would parse the output though.
That's too hacky, so not a solution.
I thin
Hi,
Please CC me, I'm not on the list.
Who owns /var/log/lighttpd?
Lighttpd (running as www-data) expects to be able to create files in
this dir, so the dir is owned by www-data.
What is the recommended way to chown this? Chown manually in postinst?
In the init script? Is there any support for th
Steve M. Robbins wrote:
On Sat, Apr 19, 2008 at 10:53:35PM +0200, Olaf van der Spek wrote:
Steve M. Robbins wrote:
If we do decide to have co-installable -dev packages, the next
question is how do we handle the current non-versioned includes and
link libraries? Do we follow what gcc and
Steve M. Robbins wrote:
If we do decide to have co-installable -dev packages, the next
question is how do we handle the current non-versioned includes and
link libraries? Do we follow what gcc and python do, providing a
defaults that change from time to time? Or should we not attempt to
provide
Bernd Eckenfels wrote:
> There are a few bugs open, marked as "help needed" it would be nice if
> anybody would help with those, instead of ranting.
Of course that would be nice, but it's not an answer to my question.
Also, more than two years ago I did write code to solve the IPv4/IPv6
truncatio
On Dec 1, 2007 5:53 PM, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 01, 2007 at 12:52:41PM +0100, Guus Sliepen wrote:
> > Hm, looks bad indeed. I'll try to see if Bernd Eckenfels is still alive
> > but if I can't reach him in a week I'll adopt the package.
>
> Sure I am alive.
That's
On Dec 1, 2007 1:48 PM, Roger Leigh <[EMAIL PROTECTED]> wrote:
> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> > The bug count is up to 112.
> > Only two NMU translation uploads have been done in the past two years.
> > No other uploads at all.
>
&
On Aug 2, 2005 6:45 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> Hi,
>
> What's the maintenance status of the net-tools package?
> It has 88 bugs:
>
> A lot older than a year, 17 with patch a lot even without a single response.
Hi list,
I'm sorry to ask
Hi,
On 4/6/07, Martín Ferrari <[EMAIL PROTECTED]> wrote:
Hi again,
On 4/5/07, Martín Ferrari <[EMAIL PROTECTED]> wrote:
> I don't know if I will be able to apply for co-maint, but I started
> working a little on triaging. Hope it helps.
I've spent a lot of hours working on net-tools bugs, 17
On 4/6/07, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
On Fri, Apr 06, 2007 at 09:32:27AM +0200, Olaf van der Spek wrote:
> Well, that's part of the problem, he's basically MIA and doesn't (want
> to) talk about bugs.
thats not true,
You're not basically MIA
On 4/6/07, Martín Ferrari <[EMAIL PROTECTED]> wrote:
I'm copying Olaf, since he asked for it in the OP, and Bernd, since
he's the maintainer.
Thanks.
On 4/3/07, Michael Banck <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, Apr 03, 2007 at 02:09:00PM +0200, Olaf va
On 8/2/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
Hi,
What's the maintenance status of the net-tools package?
It has 88 bugs:
Serious policy violations - outstanding (1 bug)
Important bugs - outstanding (8 bugs)
Normal bugs - outstanding (38 bugs)
Minor bugs - outstand
Gabor Gombas wrote:
On Fri, Nov 17, 2006 at 01:11:26PM +0100, Olaf van der Spek wrote:
Sounds like the wrong definition.
There is no choice as it is enforced by the kernel: if you can open()
the directory, then you can list its contents, otherwise not.
It's like 'it's unre
Gabor Gombas wrote:
On Fri, Nov 17, 2006 at 07:43:20AM +0100, Olaf van der Spek wrote:
I guess that depends on what a user's definition of a directory being
readable means.
There is just one definition for that: whether open(...,
O_RDONLY|O_DIRECTORY) succeeds or not.
Sounds like the
Don Armstrong wrote:
On Thu, 16 Nov 2006, Olaf van der Spek wrote:
Adduser choses 751, which is wrong IMO, as the directories are still
readable, they're just not listable.
The directories aren't readable either; their contents may be, but you
can't see what the contents are.
Lionel Elie Mamane wrote:
On Thu, Nov 16, 2006 at 06:13:38PM +0100, Olaf van der Spek wrote:
Please take ~/public_html into this consideration.
~/public_html (probably) won't work with 751,
Sure it will work. As well as ~/.plan (for finger), your own picture
for the GDM face br
Greetings,
Olaf
Marc Haber wrote:
On Wed, Nov 15, 2006 at 11:07:24PM +0100, Olaf van der Spek wrote:
In that case, could you change the question to a multiselect that also
allows 750 to be chosen?
That is a non-option for etch because it would invalidate translations.
After conferring with ab
On 11/10/06, Don Armstrong <[EMAIL PROTECTED]> wrote:
On Thu, 09 Nov 2006, Olaf van der Spek wrote:
> A default Etch install has Exim configured for local mail only. So
> reportbug mails will end up frozen in a queue somewhere, without any
> direct warning to the user.
Reportbug
it?
Please CC me.
Greetings,
Olaf
On 11/9/06, Marc Haber <[EMAIL PROTECTED]> wrote:
tags #397646 wontfix
user [EMAIL PROTECTED]
usertags #39646 i-dont-like-the-default-config
thanks
On Wed, Nov 08, 2006 at 08:02:58PM +0100, Olaf van der Spek wrote:
> Since exim4 is configured for l
On 6/20/06, Michael Banck <[EMAIL PROTECTED]> wrote:
On Tue, Jun 20, 2006 at 11:37:22AM +0200, Olaf van der Spek wrote:
> How are others supposed to be aware of that if you don't tell them?
Uhm, did you read the thread you're replying to? Or are you just
rehashing the compl
On 6/20/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
* Marc Haber
| On Sun, 18 Jun 2006 07:51:04 +0200, Tollef Fog Heen <[EMAIL PROTECTED]>
| wrote:
| >Useful patches and comments are always welcome.
|
| The apache maintainers' "reaction" to #349716, #349709, #349708 and
| #366124 (the latter
On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
* Josselin Mouette
| Le dimanche 18 juin 2006 à 15:30 +0200, Tollef Fog Heen a écrit :
| > | Tollef, you realise that neither me nor Marc (who has started this thread)
| > | have ever talked about NMUs?
| >
| > Josselin Mouette did. I've ea
On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> Without knowing or having asked Adam, this seems like help might be welcome.
Useful patches and comments are always welcome.
But sending them to /dev/null appears to have the same effect.
Threats of NMUs and
similar aren't.
How about
On 6/15/06, Marc Chantreux <[EMAIL PROTECTED]> wrote:
Hi all,
I've posted a patch to fix #350119, #342008, #350119 139 days ago and
have no news about it. I tried to contact the apache team to know if i
was able to help but i have no news.
I still apply my patch on every server i install, this
On 6/6/06, Mike Hommey <[EMAIL PROTECTED]> wrote:
On Tue, Jun 06, 2006 at 11:47:10AM +0200, Klaus Ethgen <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> more and more packages use hidden files in /usr. I see this as an error.
> But before making a bug report for such packages I wish to ask if this
> is
On 6/4/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
On Sun, Jun 04, 2006 at 12:18:16PM +0200, Olaf van der Spek wrote:
> On 6/4/06, Anthony Towns wrote:
> >On Sun, Jun 04, 2006 at 12:18:39AM -0700, Mike Bird wrote:
> >> Too many excuses. All inadequate.
> >>
On 6/4/06, Anthony Towns wrote:
On Sun, Jun 04, 2006 at 12:18:39AM -0700, Mike Bird wrote:
> Too many excuses. All inadequate.
>
> It is past time that the covert actions of the "small cabal"
> were openly reviewed. The license (for convenience), any
> relevant written promises from Sun (if an
On 5/22/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
On Mon, 2006-05-22 at 10:50 +0200, Michael Meskes wrote:
> Again this logic doesn't seem to work for me. If I was offering warez
> on my server I couldn't become legal again by just removing it. My
> prior action would still get me sued, does
On 5/19/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
> Well, most of those scripts can be fixed quite easily, some require
> a bit more work. I hereby promise to help fixing them to the extent
> of my capability.
Let's see. The
On 5/18/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second boot).
To make this speed up available to everyone, we ha
On 5/18/06, Anthony Towns wrote:
On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote:
> First off, I'm going to completely ignore the FAQ as the FAQ and the
> license both specifies that the FAQ does not have any legal validity.
Repeating frequently asked questions that have already b
On 5/18/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
On Thu, 2006-05-18 at 16:02 +0200, Olaf van der Spek wrote:
> On 5/18/06, Frans Pop <[EMAIL PROTECTED]> wrote:
> > On Thursday 18 May 2006 09:28, Josselin Mouette wrote:
> > > On Wed, May 17, 2006 at 10:21:27
On 5/18/06, Frans Pop <[EMAIL PROTECTED]> wrote:
On Thursday 18 May 2006 09:28, Josselin Mouette wrote:
> On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote:
> > As far as I can tell the packages were accepted from NEW in a very
> > short time frame (~ 5hours).
Could have something
On 5/16/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
Olaf van der Spek wrote:
> That depends on the implementation but I don't think it's not solvable.
There's a bunch of claims from people who have worked on
multiarch-related problems for a few years. You seem t
On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote:
"Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote:
>> > I don't care about the implementation details, but if it requ
On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote:
> I don't care about the implementation details, but if it requires
> kernel support, then yes.
How should the kernel (or any other implementation) know which script
requires which python version without the scripts declaring it?
On 5/16/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
>> See the system calls link(2) and symlink(2). The (Essential) coreutils
>> package provides a userspace binary /bin/ln which makes these calls
>
101 - 200 of 422 matches
Mail list logo
