Re: using perl in preinst script
On 2010-12-30, Peter Samuelson wrote: >> On 2010-12-28, Carsten Hey wrote: >> > system. The remaining perl library packages could be removed after >> > installing debconf-english. > [Philipp Kern] >> "You don't care about non-native speakers?" SCNR. > That's not how I read it at all. I think he's just saying, > debconf-i18n requires perl, but that in itself is not a barrier to > removing perl-base from Essential, because debconf-english (its > alternative) does not need it. Obviously the discussion of what > belongs in the Essential set is not at all the same thing as the > discussion of what packages debootstrap should install by default > (a "base system"). I know. It was ironic, thus the "Sorry, could not resist.". I recently listened to a talk where there was a complaint about gdm running a full Gnome session and why the heck this was necessary. It was countered with "so you don't care about disabled people!?" argument because you want screenreader and input method infrastructure available. But that's way off-topic. ;) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnihop2a.afk.tr...@kelgar.0x539.de
[vu...@gnome.org: Cross-distro meeting about application installer]
- Forwarded message from Vincent Untz -
Date: Wed, 29 Dec 2010 18:49:48 +0100
From: Vincent Untz
To: distributi...@lists.freedesktop.org
Subject: Cross-distro meeting about application installer
Hi all,
We're organizing a cross-distro meeting in January to discuss the
"application installer" topic. It's a hot topic in many distros at the
moment, and we believe it's an area where we can collaborate a lot.
I've contacted various people privately already (from Debian, Fedora,
Mageia, openSUSE and Ubuntu), and there's interest in such a meeting.
All the information about the meeting is at
http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011
If you'd like to attend the meeting, or if there's any specific topic
that you'd like to see discussed, please edit the wiki page!
(I'll be away from mails for a few days, but I'll reply to questions
when I come back, if you have any :-))
Cheers,
Vincent
--
Les gens heureux ne sont pas pressés.
___
Distributions mailing list
distributi...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/distributions
- End forwarded message -
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#608364: ITP: dmedia -- A simple distributed media library
Package: wnpp Severity: wishlist Owner: Bilal Akhtar * Package name: dmedia Version : 0.2-1 Upstream Author : Jason Gerard DeRose * URL : http://launchpad.net/dmedia * License : AGPL Programming Lang: Python Description : A simple distributed media library DMedia is a simple distributed media library which greatly facilitates playing of media files and storing their metadata for quick access. It stores the metadata of the media files in CouchDB. Media files can also be loaded remotely over a network connection. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230104439.2991.79377.report...@localhost6
Bug#608371: ITP: libparallel-prefork-perl -- A simple prefork server framework
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves * Package name: libparallel-prefork-perl Version : 0.11 Upstream Author : Kazuho Oku * URL : http://search.cpan.org/dist/Parallel-Prefork/ * License : Perl Programming Lang: Perl Description : A simple prefork server framework This module is intended for use in operations that can be done in parallel where the number of processes to be forked off should be limited, much like Parallel::ForkManager. Parallel::Prefork also supports graceful shutdown and run-time reconfiguration. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230110427.5498.68442.report...@carme.larted.org.uk
Bug#608375: ITP: libserver-starter-perl -- a superdaemon for hot-deploying server programs
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves * Package name: libserver-starter-perl Version : 0.09 Upstream Author : Kazuho Oku * URL : http://search.cpan.org/dist/Server-Starter/ * License : Perl Programming Lang: Perl Description : a superdaemon for hot-deploying server programs Server::Starter supports the deployment of server programs with graceful restarts. It includes a script which works as a superdaemon that binds to zero or more TCP ports, and repeatedly spawns the server program that actually handles the necessary tasks (for example, responding to incoming connections). The spawned server programs under Server::Starter call accept(2) and handle the requests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230111521.5574.81066.report...@carme.larted.org.uk
Re: Safe File Update (atomic)
On Wed, 29 Dec 2010, Olaf van der Spek wrote: > Writing a temp file, fsync, rename is often proposed. However, the It is: write temp file (in same directory as file to be replaced), fsync temp file[1], rename (atomic), fsync directory[2]. [1] Makes sure file data has been commited to backend device before the metadata update [2] Makes sure the metadata has been commited to permantent storage. Can often be ignored when you don't really care to know you will get the new contents (as opposed to the old contents) in case of a crash. MTAs and spools, for example, MUST do it. Which steps you can skip is filesystem-options/filesystem/ kernel-version/kernel dependent. When the rename acts as a barrier, [1] can be skipped, for example. Tracking this is a losing proposition. If we could use some syscall to make [1] into a simple barrier request (guaranteed to degrade to fsync if barriers are not operating), it would be better performance-wise. This is what one should request of libc and the kernels with a non-zero chance of getting it implemented (in fact, it might even already exist). > I've brought this up on linux-fsdevel and linux-ext4 but they (Ted) > claim those exceptions aren't really a problem. Indeed they are not. Code has been dealing with them for years. You name the temp file properly, and teach your program to clean old ones up *safely* (see vim swap file handling for an example) when it starts. vim is a good example: nobody gets surprised by vim swap-files left over when vim/computer crashes. And vim will do something smart with them if it finds them in the current directory when it is started. 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, ownership). unlink it by fd. close the fd. > Is there a code snippet or lib function that handles this properly? I don't know. I'd be interested in the answer, though :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230114655.ga19...@khazad-dum.debian.net
Bug#608377: ITP: libhtml-quoted-perl -- extract structure of quoted HTML mail message
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves * Package name: libhtml-quoted-perl Version : 0.02 Upstream Author : Ruslan Zakirov * URL : http://search.cpan.org/dist/HTML-Quoted/ * License : not yet determined Programming Lang: Perl Description : extract structure of quoted HTML mail message Like Text::Quoted, this module extracts the structure of quoted text in mail messages, but for HTML email. NB: the current CPAN release is marked as experimental and is missing a licence. I will clarify these points with the author before uploading. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230113310.7199.91797.report...@carme.larted.org.uk
Bug#608380: ITP: libregexp-common-net-cidr-perl -- provide patterns for CIDR blocks
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves * Package name: libregexp-common-net-cidr-perl Version : 0.02 Upstream Author : Ruslan U. Zakirov * URL : http://search.cpan.org/dist/Regexp-Common-net-CIDR/ * License : not yet determined Programming Lang: Perl Description : provide patterns for CIDR blocks This module provides regexp patterns for CIDR netblocks. NB: The licence for this software is not yet determined. I will check with the author before uploading. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230113901.7325.38289.report...@carme.larted.org.uk
Re: Safe File Update (atomic)
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 syscall to make [1] into a simple barrier request > (guaranteed to degrade to fsync if barriers are not operating), it would > be better performance-wise. This is what one should request of libc and > the kernels with a non-zero chance of getting it implemented (in fact, > it might even already exist). My proposal was O_ATOMIC: // begin transaction open(fname, O_ATOMIC | O_TRUNC); write; // 0+ times close; Seems like the ideal API from the app's point of view. >> I've brought this up on linux-fsdevel and linux-ext4 but they (Ted) >> claim those exceptions aren't really a problem. > > Indeed they are not. Code has been dealing with them for years. You Code has been wrong for years to, based on the reason reports about file corruption with ext4. > name the temp file properly, and teach your program to clean old ones up > *safely* (see vim swap file handling for an example) when it starts. What about restoring meta-data? File-owner? > vim is a good example: nobody gets surprised by vim swap-files left over > when vim/computer crashes. And vim will do something smart with them if > it finds them in the current directory when it is started. I'm sure the vim code is far from trivial. I think this complexity is part of the reason most apps don't bother. > 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 Exclusive mode? Linux doesn't know about mandatory locking (AFAIK). > expects (regular file, ownership). unlink it by fd. close the fd. > >> Is there a code snippet or lib function that handles this properly? > > I don't know. I'd be interested in the answer, though :-) I'll ask glibc. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikm+dacfnq7lort9vo7p-m-gvn0dgqxup5au...@mail.gmail.com
Bug#608392: ITP: underscore -- functional programming aid for JavaScript working well with jQuery
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: underscore Version : 1.1.3 Upstream Author : Jeremy Ashkenas * URL : http://documentcloud.github.com/underscore/ * License : Expat Programming Lang: JavaScript Description : functional programming aid for JavaScript working well with jQuery Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It's the tie to go along with jQuery's tux. . Underscore provides 60-odd functions that support both the usual functional suspects: map, select, invoke - as well as more specialized helpers: function binding, javascript templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern browsers will use the native implementations of forEach, map, reduce, filter, every, some and indexOf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230142859.15188.13649.report...@localhost.localdomain
Re: Safe File Update (atomic)
On 30/12/10 13:46, Henrique de Moraes Holschuh wrote: Is there a code snippet or lib function that handles this properly? I don't know. I'd be interested in the answer, though :-) 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. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1c9d3b.6060...@debian.org
Bug#608395: ITP: varnisnncsa-vhost -- Wrapper around 'varnishncsa' tool to save varnish logs with virtualhost
Package: wnpp Severity: wishlist Owner: Joenio Costa * Package name: varnisnncsa-vhost Version : 0.1 Upstream Author : Joenio Costa * URL : http://gitorious.org/varnisnncsa-vhost * License : GPL2 Programming Lang: Perl Description : Wrapper around 'varnishncsa' tool to save varnish logs with virtualhost This simple script uses varnishncsa tool to provide a way to store varnish logs with vhost, cause varnish by default until version 2.1.5 not allow to customize log formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230143644.28765.80997.report...@case.neuromancer
Re: Safe File Update (atomic)
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-data (ACL)? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-o2mu47dfdvm8kedobjfhw7swkxcwy9fwh...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, Dec 30, 2010 at 03:30:29PM +0100, Olaf van der Spek wrote: > > name the temp file properly, and teach your program to clean old ones up > > *safely* (see vim swap file handling for an example) when it starts. > > What about restoring meta-data? File-owner? owner, permissions, acl, xattrs, and whatever other future stuff can be stored about files, which then all applications should be made aware of? Yay for simplicity. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230151011.ga12...@glandium.org
Re: Safe File Update (atomic)
On 30/12/10 17:02, Olaf van der Spek wrote: 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? 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 is not trivial. There is an extremely simple way to do it on Linux, but it will not work on all platforms (the *BSD platforms, including Mac, do not have /proc by default). What aboue file owner? Meta-data (ACL)? Olaf The current code (I'm still working on it, or I would have released it already, but it's about 80% done) does copy owner data over (but ignores failures), but does not handle ACLs. I decided to postpone this particular hot potato until I can get a chance to see how to do it (i.e. - never had a chance on Linux) AND how to do it in a cross-platform way (the code is designed to work on any Posix). Pointers/patches once released are, of course, welcome :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1ca143.9020...@debian.org
Re: Safe File Update (atomic)
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 is not trivial. There is an extremely simple way to do it on > Linux, but it will not work on all platforms (the *BSD platforms, including > Mac, do not have /proc by default). Depending on /proc is probably not reasonable. Are you sure it will be atomic? ;) >> What aboue file owner? Meta-data (ACL)? >> >> Olaf >> > > The current code (I'm still working on it, or I would have released it > already, but it's about 80% done) does copy owner data over (but ignores > failures), but does not handle ACLs. I decided to postpone this particular How do you preserve owner (as non-root)? > hot potato until I can get a chance to see how to do it (i.e. - never had a > chance on Linux) AND how to do it in a cross-platform way (the code is > designed to work on any Posix). Pointers/patches once released are, of > course, welcome :-) 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 others) don't agree. They reason that the desire to preserve all meta-data isn't reasonable by itself. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik93zn1yjf5xyq_+rhaonrj1bszcafpnmkrt...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, 30 Dec 2010, Olaf van der Spek wrote: > 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? Indeed. You have to check that first, of course :-( This is about safe handling of such functions, symlinks always have to be derreferenced and their target checked. After that, you operate on the target, if the symlink changes, your operations will not. > What if you're not allowed to create a file in that dir. You fail the write. Or the user has to request the unsafe handling (truncate + write). Or you have to detect it will happen and switch modes if you're allowed to. > > If we could use some syscall to make [1] into a simple barrier request > > (guaranteed to degrade to fsync if barriers are not operating), it would > > be better performance-wise. This is what one should request of libc and > > the kernels with a non-zero chance of getting it implemented (in fact, > > it might even already exist). > > My proposal was O_ATOMIC: > // begin transaction > open(fname, O_ATOMIC | O_TRUNC); > write; // 0+ times > close; > > Seems like the ideal API from the app's point of view. POSIX filesystems do not support it, so you'd need glibc to do everything your application would have to get that atomicity. I.e. it should go in a separate lib, anyway, and you will have to code for it in the app :( It is not transparent. It cannot be. What about mmap()? What about read+write patterns? At most you could have an "open+write+close" function that encapsulate most of the crap, with a few options to tell it what to do if it finds a symlink or mismatched owner, what to do if it cannot do it in an atomic way, etc. I suppose one could actually ask for a non-posix interface to do all those three operations in one syscall, but I don't think the kernel people will want to implement it. It would make sense only if object stores become commonplace (where this thing is likely an object store primitive, anyway). > >> I've brought this up on linux-fsdevel and linux-ext4 but they (Ted) > >> claim those exceptions aren't really a problem. > > > > Indeed they are not. Code has been dealing with them for years. You > > Code has been wrong for years to, based on the reason reports about > file corruption with ext4. Code written to *deal with files safely* by people who wanted to get it right and actually checked what needs to be done, has been right for years. And has piss-poor performance. Code written by random joe which has no clue about the braindamages of POSIX and Unix, well... this thread shows how much crap is really needed. One can, obviously, have most filesystems be super-safe, and create a new fadvise or something to say "this is crap, be unsafe if you can". Performance will be poor, everything will be safe, and the extra fsyncs() will not hurt much because the fs would do it anyway. > > name the temp file properly, and teach your program to clean old ones up > > *safely* (see vim swap file handling for an example) when it starts. > > What about restoring meta-data? File-owner? Hmm, yes, more steps if you want to do something like that, as you must do it with the target open in exclusive mode. close target only after the rename went ok. But if the file owner is not yourself, you really should change it, not to mention you might not want to complete the operation in the first place. A lib for this is a really good idea :p > > vim is a good example: nobody gets surprised by vim swap-files left over > > when vim/computer crashes. And vim will do something smart with them if > > it finds them in the current directory when it is started. > > I'm sure the vim code is far from trivial. I think this complexity is > part of the reason most apps don't bother. That I agree with completely. > > 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 > > Exclusive mode? Linux doesn't know about mandatory locking (AFAIK). Yeah... races everywhere... > > expects (regular file, ownership). unlink it by fd. close the fd. > > > >> Is there a code snippet or lib function that handles this properly? > > > > I don't know. I'd be interested in the answer, though :-) > > I'll ask glibc. This really should be in a separate lib. You want it to be usable outside of glibc systems, and you CAN implement it (slow that it will be) on anything POSIX. You need only some help of the kernel to speed it up, and that has to be detected at compile time (support) and runtime (availability of the feature) anyway. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-deve
Re: Safe File Update (atomic)
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 others) don't agree. They reason that the desire to preserve all > meta-data isn't reasonable by itself. It isn't. And you can do it anyway: 1. open target, keep it open. 2. do the safe open+write dance on the temp target. 3. get metadata from target by fd 4. apply metadata to temp target by fd 5. atomic rename 6. close both fds 7. sync parent dir. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230152401.gb4...@khazad-dum.debian.net
Re: Safe File Update (atomic)
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 > their target checked. After that, you operate on the target, if the symlink > changes, your operations will not. That's not really atomic. >> What if you're not allowed to create a file in that dir. > > You fail the write. That's a regression from the non-atomic case. > Or the user has to request the unsafe handling > (truncate + write). Or you have to detect it will happen and switch modes > if you're allowed to. > >> > If we could use some syscall to make [1] into a simple barrier request >> > (guaranteed to degrade to fsync if barriers are not operating), it would >> > be better performance-wise. This is what one should request of libc and >> > the kernels with a non-zero chance of getting it implemented (in fact, >> > it might even already exist). >> >> My proposal was O_ATOMIC: >> // begin transaction >> open(fname, O_ATOMIC | O_TRUNC); >> write; // 0+ times >> close; >> >> Seems like the ideal API from the app's point of view. > > POSIX filesystems do not support it, so you'd need glibc to do everything Not yet, but I assume it'll be added when there's enough demand. > your application would have to get that atomicity. I.e. it should go in a > separate lib, anyway, and you will have to code for it in the app :( Why would it have to go in a separate lib? > It is not transparent. It cannot be. What about mmap()? What about > read+write patterns? They either happen before or after this atomic transaction. Comparable to the rename workaround. > At most you could have an "open+write+close" function that encapsulate most > of the crap, with a few options to tell it what to do if it finds a symlink > or mismatched owner, what to do if it cannot do it in an atomic way, etc. > > I suppose one could actually ask for a non-posix interface to do all those > three operations in one syscall, but I don't think the kernel people will There's no need for a single syscall. > want to implement it. It would make sense only if object stores become > commonplace (where this thing is likely an object store primitive, anyway). Nah. Tons of files are written in one go. All could use this atomic flag. >> >> I've brought this up on linux-fsdevel and linux-ext4 but they (Ted) >> >> claim those exceptions aren't really a problem. >> > >> > Indeed they are not. Code has been dealing with them for years. You >> >> Code has been wrong for years to, based on the reason reports about >> file corruption with ext4. > > Code written to *deal with files safely* by people who wanted to get it > right and actually checked what needs to be done, has been right for years. > And has piss-poor performance. Isn't fixing / improving that a good thing? > Code written by random joe which has no clue about the braindamages of POSIX > and Unix, well... this thread shows how much crap is really needed. So you agree that this should be improved? > One can, obviously, have most filesystems be super-safe, and create a new > fadvise or something to say "this is crap, be unsafe if you can". > Performance will be poor, everything will be safe, and the extra fsyncs() > will not hurt much because the fs would do it anyway. I actually think this can be done with better performance then the rename workaround. >> > name the temp file properly, and teach your program to clean old ones up >> > *safely* (see vim swap file handling for an example) when it starts. >> >> What about restoring meta-data? File-owner? > > Hmm, yes, more steps if you want to do something like that, as you must do > it with the target open in exclusive mode. close target only after the > rename went ok. > > But if the file owner is not yourself, you really should change it, not to > mention you might not want to complete the operation in the first place. Why? Of course write access to the file is required. >> I'll ask glibc. > > This really should be in a separate lib. You want it to be usable outside > of glibc systems, and you CAN implement it (slow that it will be) on > anything POSIX. You need only some help of the kernel to speed it up, and > that has to be detected at compile time (support) and runtime (availability > of the feature) anyway. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinhoftnychhjsd6og04jrvyube8ul55szyyl...@mail.gmail.com
Re: Safe File Update (atomic)
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 others) don't agree. They reason that the desire to preserve all >> meta-data isn't reasonable by itself. > > It isn't. Why not? > And you can do it anyway: > > 1. open target, keep it open. > 2. do the safe open+write dance on the temp target. > 3. get metadata from target by fd > 4. apply metadata to temp target by fd > 5. atomic rename > 6. close both fds > 7. sync parent dir. Doesn't work for file-owner. How does it handle meta-data you don't know about yet? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimgqaavbzgwndr6bf87=1bvb1au++qje29d+...@mail.gmail.com
Re: Safe File Update (atomic)
On 30/12/10 13:46, Henrique de Moraes Holschuh wrote: Is there a code snippet or lib function that handles this properly? I don't know. I'd be interested in the answer, though :-) 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. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1c9c74.2050...@shemesh.biz
Bug#608409: ITP: diaspora-x2 -- web-based client for XMPP-based decentral social networking
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: diaspora-x2 Version : 0~git20101222 Upstream Author : Ben Nolan * URL : https://github.com/bnolan/diaspora-x2 * License : Expat (maybe - still working on resolving that) Programming Lang: CoffeeScript Description : web-based client for XMPP-based decentral social networking Diaspora x² is a web-based client for XMPP-based decentral social networking. . Diaspora x² is based on the frontend part of Diaspora (the Ruby on Rails project launched early fall of 2010 at much attention), reimplemented in CoffeeScript and redesigned to connect to use XMPP as developed at http://open.buddycloud.com/ . -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230170807.11041.14691.report...@localhost.localdomain
Bug#608410: ITP: libmodule-starter-smart-perl -- Module::Starter plugin to add new modules into existing distributions
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: libmodule-starter-smart-perl Version : 0.0.2 Upstream Author : Ruey-Cheng Chen * URL : http://search.cpan.org/dist/Module-Starter-Smart/ * License : Artistic or GPL-1+ (same as Perl) Programming Lang: Perl Description : Module::Starter plugin to add new modules into existing distributions Module::Starter::Smart is a simple helper plugin for Module::Starter. It overrides the create_distro, create_modules, and create_t subroutines defined in whichever engine plugin in use (say, Module::Starter::Simple). . When invoked with an existing distribution, the plugin may bypass the create_basedir subroutine, pull in a list of existing modules as well as test files, create new modules, and recreate the manifest file accordingly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230171048.24235.55172.report...@pc-ale.rete
Re: Safe File Update (atomic)
On Thu, 30 Dec 2010, Olaf van der Spek wrote: > 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 others) don't agree. They reason that the desire to preserve all > >> meta-data isn't reasonable by itself. > > > > It isn't. > > Why not? You touched it, it is not the same file/inode anymore. > How does it handle meta-data you don't know about yet? It doesn't. You need a "copy inode without the file data" filesystem interface to be able to do that in the first place. It might exist, but I never heard of it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230174822.ga20...@khazad-dum.debian.net
Re: Safe File Update (atomic)
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 the file data" filesystem > interface to be able to do that in the first place. It might exist, but I > never heard of it. You wouldn't need that with O_ATOMIC. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimyynyyyw2osbkbg8wxgv2ybrdotzymzlu83...@mail.gmail.com
Re: Safe File Update (atomic)
On 30/12/10 19:48, Henrique de Moraes Holschuh wrote: It doesn't. You need a "copy inode without the file data" filesystem interface to be able to do that in the first place. It might exist, but I never heard of it. 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 (yes, this feature is time based) rename a different file to the same name, the new file will receive all metadata information the old file had (including owner, permissions etc.) Just thought I'd share this little nugget to show you how much worse non-posix has it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1ccc38.6000...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 17:17, Olaf van der Spek wrote: 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 is not trivial. There is an extremely simple way to do it on Linux, but it will not work on all platforms (the *BSD platforms, including Mac, do not have /proc by default). 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, in the sense that the determining point in time is the point in which you opened the old file. How do you preserve owner (as non-root)? I thought I answered that. Best effort. You perform the chown, but do not bother with the return code. If it succeeded, great. If not, well, you did your best. 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 others) don't agree. They reason that the desire to preserve all meta-data isn't reasonable by itself. I'm with Henrique on that one. I am more concerned with the amount of non-Posix code that needs to go into this than preserving all attributes. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1ccd81.3010...@debian.org
Re: Safe File Update (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 (yes, this feature is time based) rename a > different file to the same name, the new file will receive all metadata > information the old file had (including owner, permissions etc.) > > Just thought I'd share this little nugget to show you how much worse > non-posix has it. You're kidding me. Got any source to back this up? Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik8ywzth67auoukrxmt2w1urmpgahnbg4k9s...@mail.gmail.com
Re: Safe File Update (atomic)
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, in the > sense that the determining point in time is the point in which you opened > the old file. >> >> How do you preserve owner (as non-root)? >> >> > > I thought I answered that. Best effort. You perform the chown, but do not > bother with the return code. If it succeeded, great. If not, well, you did > your best. Ah. Another regression. >> >> 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 others) don't agree. They reason that the desire to preserve all >> meta-data isn't reasonable by itself. >> > > I'm with Henrique on that one. I am more concerned with the amount of > non-Posix code that needs to go into this than preserving all attributes. With kernel support you would only need a single non-POSIX flag. Please be sure to document all assumptions / limitations of your variant. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimzgfzwpj8phtevdycbxwwd5s7pp+enlcpi+...@mail.gmail.com
Re: Safe File Update (atomic)
On Thu, 2010-12-30 at 19:29 +0100, Olaf van der Spek wrote: > 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 (yes, this feature is time based) rename a > > different file to the same name, the new file will receive all metadata > > information the old file had (including owner, permissions etc.) > > > > Just thought I'd share this little nugget to show you how much worse > > non-posix has it. > > You're kidding me. Got any source to back this up? http://support.microsoft.com/?kbid=172190 Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Safe File Update (atomic)
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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinuqjcgdg0aazqkiomfthqyorfzc89y7xquu...@mail.gmail.com
Bitcoin donation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear friends, I have been looking in your site for any reference to Bitcoin for making a small donation. As you probably know, Bitcoin (bitcoin.org) is a new kind of a P2P crypto-currency in which the general public can make donations, macro or micropayments in a secure and anonymous way usually without any transaction fee involved. You can change Bitcoins for real Dollars (eg: https://mtgox.com) or purchase services or goods in an increasing number of sites. In order to receive donations you only have to publish one of your accounts as generated by the bitcoin client or any specialized bitcoin trader (eg: mybitcoin.com) Currently some projects as www.i2p2.de, www.torrentservers.net and organizations like the EFF are accepting donations. In my opinion this kind of decentralized solution without the need to trust any middlemen is much better than Paypal (Visa, Mastercard ...) for security-minded people as most of your donors are. If you are interested in pushing Bitcoin forward, do not hesitate to contact me if you have any doubt. Yours, Cyclonite -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJNFp4aAAoJEL/jfnFwT5SQ2wEQAK7s6wGleGBcY7VkioSnqv4I 92JlZqG1QU3N9PRVDWl9ZNpEEdg7In16HvBhctsUSS+MfuaIgRQWjV3bN1a10oVW BQtc2zcNExeNAHKBVea2niqEPxutQkoxvMv3wgTb5NiOzQBjTydQ7TNjmOxSrg0q MKUyuhux94bM3r/+QrEWqcy6z+62IZhSceyIP6hnC+Lb4CA/RBVLMpsMnno/YvFB mhTldfhIwJExmZf77C979aCwbeKDyGd2EVsKO6sPNFD6Fke8H3PXwW7Stp48lnfg YIn0kMbJS7YXvP8C0qhJhOi/eMETGmmLEy9CmFlTUgfLbM4qjfzz+vX8NP3zrLJO G7nHKWNrLv3WneemrSpo9uVfrxKyLSO8H/X7XTKjrfnDB3L6S1Yp/Nk23nb30jmj lVx+9Elu5wOWG2CDel1MWiDIBrLUl7km+h4JmR0hSzOt2DJMw62IPT0aFwOAZVt/ 4EPKF0CzxwjIaK5q2CC1FzbM47wBAQqJ7Ua0HcCx71i0YJuGy4GkZapOwm3+zuSn kBcOVBZB2PnseZ1f3ntF+Y77Lvqz4JyZa5cPTHevvnqw0No/IJsJp4+2mduE7HOR JRqLDM1NuXSfinTE4x+H/144efiZuTV8YcAnuZD1+DPuyv4xjwrrD4H1rnjs7HW/ FsLmo9yPZDRvfUZKEVYe =52Cw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/n1r-_s5jd0o...@safe-mail.net
Bug#608424: ITP: backbone -- some Backbone for JS Apps with Models, Views, Collections, and Events
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: backbone Version : 0.3.3 Upstream Author : Jeremy Ashkenas * URL : http://documentcloud.github.com/backbone/ * License : Expat Programming Lang: JavaScript Description : some Backbone for JS Apps with Models, Views, Collections, and Events Backbone supplies structure to JavaScript-heavy applications by providing models key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing application over a RESTful JSON interface. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230194600.29119.55004.report...@localhost.localdomain
Re: Bug#608377: ITP: libhtml-quoted-perl -- extract structure of quoted HTML mail message
On Thu, Dec 30, 2010 at 11:33:10AM +, Dominic Hargreaves wrote: > NB: the current CPAN release is marked as experimental and is missing > a licence. I will clarify these points with the author before uploading. This was a mistake; this module does in fact come with a Free licence but I failed to spot it at the search.cpan.org listing. With regards to the 'experimental' description, I will initially upload this to Debian experimental, along with the RT package which requires it. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230212525.go4...@urchin.earth.li
Re: Bug#608395: ITP: varnisnncsa-vhost -- Wrapper around 'varnishncsa' tool to save varnish logs with virtualhost
On Thu, Dec 30, 2010 at 07:48:16PM +0100, Tollef Fog Heen wrote: > This is fairly pointless as 3.0 supports user-specifiable formats and > filtering and will be out in 2011Q1 so varnishncsa-vhost won't ever be > in a stable release where it makes sense to have it. I figured it out. I had packaged it and uploaded to my personal repository, maybe can be usefull to someone: http://sede.colivre.coop.br/~joenio/debian/ -- Joenio Costa - www.Colivre.coop.br - www.Perl.org.br - Salvador.pm.org GNU/Linux User #431067 http://counter.li.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230214119.ga30...@debian
Re: Bitcoin donation
[Cyclonite]
> Dear friends,
>
> I have been looking in your site for any reference to Bitcoin for
> making a small donation.
As far as I know, none of the organisations accepting donations on
behalf of the Debian project accept bitcoin.
We are considering it for the SLX Debian Labs foundation which accept
donations for the Debian Edu/Skolelinux project, but have not
concluded yet. I am the chair of the SLX Debianc Labs foundation. I
believe there are some accounting and legal issues as well as some
practical issues to consider before we can accept it.
Given that the EFF with its privacy sensitive target group so far has
only received 2483.8 bitcoins[1] to its bitcoin donation address, it
seem unlikely that Debian will receive much money this way any time
soon.
But it might be interesting to support the bitcoin system by accepting
donations, and give users of bitcoin more to spend their bitcoins
on. :)
1 Extracted using "lynx -dump
http://blockexplorer.com/address/1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt|grep
Received:|grep Block|awk '{sum = sum + $6} END { print sum}'".
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2flr5cy5398@login1.uio.no
Re: securing/monitoring Debian devel environment
On 12/22/2010 05:10 PM, Yaroslav Halchenko wrote: > May be there is a lightweight utility which could be used for > monitoring, e.g. it would report suspicious actions being taken from > within a monitored environment? e.g., it would > > * sanitize environment variables > * monitor open/socket/... syscalls and report abnormal activities > (e.g. opening network connection, writing to a file outside of > build-tree,/tmp/, etc) > * provide a summary at the end on the invoked actions by the target > command > > I guess a possible solution which would not only monitor but > guarantee would be SELinux, but I am afraid it might be somewhat > cumbersome to setup policies across the variety of packages I maintain. > So I just wanted to monitor to start with. In private communication, Yaroslav and I have been bouncing some crude ideas around, which I'm going to summarize here. Of the possible approaches we discussed, two seem to fulfill the requirements above: * SystemTap [0,1] * auditd [2,3] [0] http://sourceware.org/systemtap/ [1] http://packages.debian.org/sid/systemtap [2] http://people.redhat.com/sgrubb/audit/ [3] http://packages.debian.org/sid/auditd note that SELinux was excluded for the reasons Yaroslav mentioned above. SYSTEMTAP: The SystemTap approach appeared the most promising at first glance, as it is fully scriptable and the Beginner's Guide contains ready-to-use scripts covering basically all the requirements mentioned above. Yaroslav also discussed this with #systemtap, they pointed out some issues WRT fork()s etc but otherwise had no major objections. SystemTap has one drawback: it requires a kernel with debugging stuff enabled (see #568866), which AFAIUI is only available on i386/amd64 and requires 1.5GB disk space. AUDITD: Seeing that SystemTap's purpose goes way beyond simple auditing, I took a shot at auditd -- which is supported by the standard kernel -- with the goal of producing a simple wrapper script for debuild. My initial optimism and success was dampened as I gained more experience with auditd and it's goals. To elaborate, it is quite simple to create auditing rules achieving the goals above, however an approach "tailored" 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). Furthermore, generating sensible reports from the data above wasn't all too easy as well. ausearch and aureport are very useful, but one must still pre- or postprocess their respective outputs to get the desired results. Finally, it appears -- at least to me -- that Prelude IDS (already packaged) is the way to go. It is a full-scale, real-time IDS (using the auditing subsystem) with numerous features including plugin support for sensors and also good reporting. The initial objective is just a subset of Prelude's goal, and seeing as there is a lot of weight thrown behind Prelude, the merit of a custom solution (based on the raw auditing data) is probably debatable. Anyway, I'm at my limits here -- even though the idea and the available technology is highly interesting, I do not have the necessary time available ATM to go deeper. If there's anyone security-minded with time on his/her hands, the ball is yours... Regards, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1d0e7d.5030...@kvr.at
Re: securing/monitoring Debian devel environment
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 process run as root? If so, I think it shouldn't. If not, it can't read /etc/shadow. About elevation via sudo: don't enable/use ssh/sudo/etc from the account you use to build. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikh_rvdsjy+2_=lut0qcqggersg=ebnwv2-5...@mail.gmail.com
Re: Static linking: pkgconfig vs libtool
* Russ Allbery schrieb: > pkg-config is much superior to libtool, since libtool includes all the > libraries on dynamic links as well, which creates unwanted shared library > dependencies and causes other problems. Because of that, the trend in > Debian is to empty that information from libtool *.la files or not ship > them at all, making them useless for static linking information. Gentoo is also in process of getting rid of .la files. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101230233959.ga10...@nibiru.local
Re: using perl in preinst script
* Philipp Kern [2010-12-29 05:38 +]: > On 2010-12-28, Carsten Hey wrote: > > ... One reason for this is that dpkg's perl scripts were rewritten > > in C. > > I know you phrased it differently but wasn't the motivation for this > rewrite to be more robust in the base system on upgrades? I.e. do not > rely on Perl and thus avoid adding more contraints on how the base > upgrade must be performed to keep dpkg working properly. I don't know what the main motivation was, although making upgrades more robust seems to be a possible and a good one. http://wiki.debian.org/Teams/Dpkg/RoadMap says: | Make dpkg.deb contain only sh and C programs (to help embedded | distros, to make it possible to remove perl-base from essential) Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231005641.ga6...@furrball.stateful.de
Re: Safe File Update (atomic)
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, ownership). unlink it by fd. close the fd. Eh, as it was pointed to me by private mail, this is obviously a load of crap :p There is no unlink by fd. Sorry about that. The attacks here are races by messing with intermediate path components, which are either not worth bothering with, or have to be avoided in a much more convoluted manner. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231021723.ga9...@khazad-dum.debian.net
Bug#608460: ITP: pev -- Utility to get Product Version of PE32 executables
Package: wnpp Severity: wishlist Owner: "Fernando Mercês" * Package name: pev Version : 0.22 Upstream Author : Fernando Mercês * URL : http://coding40.mentebinaria.com.br * License : GPL Programming Lang: C Description : Utility to get Product Version of PE32 executables pev is a little text-based tool to get the Product Version field of PE32 executables (EXE, DLL, OCX etc). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231041516.8420.58585.report...@brussels
Re: Safe File Update (atomic)
On 30/12/10 17:02, Olaf van der Spek wrote: Got a project page already? Watch this space. Actual code coming soon(tm). https://github.com/Shachar/safewrite Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1d743b.8080...@shemesh.biz
