=Бухгалтерский журнал= debian-devel@lists.debian.org
Предлагаем Вашему вниманию бесплатное получение электронного журнала "Всё о бухгалтерском учёте" Вышлите данные предприятия, ФИО бухгалтера и получите бесплатный полугодовой доступ!!! ezbazay -- 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/000201cba9e8$e86aed57$2e87e...@sjuclsxfhfo
Bug#608560: ITP: libcps-perl -- module to manage flow of control in Continuation Passing Style
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcps-perl Version : 0.11 Upstream Author : Paul Evans * URL : http://search.cpan.org/dist/CPS/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to manage flow of control in Continuation Passing Style CPS is a Perl module that enables developers to write code in Continuation Passing Style, which is a style of writing code where the normal call/return mechanism is replaced by explicit "continuations". It is useful whenever some form of asynchronous or event-based programming is in use. This module is required for upgrading IO::Async (libio-async-perl) to version 0.34 -- 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/aanlkti=80soh16qak1asbokryqawdsmtbriqcxrpj...@mail.gmail.com
Bug#608562: ITP: libcatalyst-engine-psgi-perl -- Catalyst engine for the PSGI protocol
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-engine-psgi-perl Version : 0.11 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Catalyst-Engine-PSGI/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Catalyst engine for the PSGI protocol Catalyst::Engine::PSGI is a Perl module that provides backend support for the Catalyst MVC framework on any of a multitude of web servers that comply with the Perl Web Server Gateway Interface (PSGI) specification. It is commonly used with the Plack middleware (see libplack-perl). -- 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/aanlktinydg1rlovbufbkztwhkfw7i=0+ym7xxryf7...@mail.gmail.com
Bug#608565: ITP: libmath-symbolic-perl -- module for performing symbolic calculations
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmath-symbolic-perl Version : 0.606 Upstream Author : Steffen Müller * URL : http://search.cpan.org/dist/Math-Symbolic/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for performing symbolic calculations Math::Symbolic is a Perl module for performing symbolic calculations, similar to Computer Algebra Systems (CAS) like Maxima, Maple and Mathematica. Using this software, algebraic expressions can be parsed from strings, manipulated in Perl and even compiled into code references. -- 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/aanlktinbu+qdkpy6rb9x3k=-hqrecda2=z3oehtvd...@mail.gmail.com
Bug#608567: ITP: libanyevent-http-perl -- simple non-blocking HTTP/HTTPS client
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libanyevent-http-perl Version : 1.5 Upstream Author : Marc Lehmann * URL : http://search.cpan.org/dist/AnyEvent-HTTP/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : simple non-blocking HTTP/HTTPS client AnyEvent::HTTP is an simple non-blocking HTTP/HTTPS client implementation, which uses AnyEvent under the hood for asynchronous I/O. It supports GET, POST and other request methods, cookies and more. It is well suited to most HTTP tasks, while retaining fine-grained control over request and response headers to cater to more complex requirements. -- 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/aanlktimi_s6vsy8q_wk_s23078j0e+ykoxzokaos6...@mail.gmail.com
devel files and libraries in /lib
Happy new year everyone. First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error updated and moved to /lib. There is one remaining issue though about the devel files, I'd like to raise. 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 and kept all devel related files in /usr/lib. This looked like the right way to me. Afaicr I've never seen this documentented somewhere to do it this way and I'm wondering if this is indeed the agreed upon best practice and if we should document it somehow (policy, devref, whatever). Opinions? Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=move-libcryptsetup-to-lib.patch;att=1;bug=604936 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: devel files and libraries in /lib
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 and kept all devel related files in > /usr/lib. This looked like the right way to me. > > Afaicr I've never seen this documentented somewhere to do it this way and I'm > wondering if this is indeed the agreed upon best practice and if we should > document it somehow (policy, devref, whatever). Isn't /lib only for files that should be available before /usr is mounted? 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/aanlktik8tg4vrrj6ame_hwcvg0mb+=tmeamuy-gkf...@mail.gmail.com
Re: Safe File Update (atomic)
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 designing an new (overlay'ing) filesystem for that ? >> >> >> >> Increased complexity, lower performance, little benefit. >> > >> > Why that ? Currently applications (try to) implement that all on >> > their own, which needs great efforts for multiprocess synchronization. >> > Having that in a little fileserver eases this sychronization and >> > moves the complexity to a single point. >> >> I mean compared to implementing it properly in the kernel. > > Doing it in the kernel would be fine (maybe DLM could be used here), What's DLM? > but would be a nonportable solution for quite a long time ;-o Since it's the only proper solution I don't think that's a problem. 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/aanlktinzgo=u85r4mjaxuslkzdha7_yhbfz2ylfu7...@mail.gmail.com
Re: devel files and libraries in /lib
On 2011-01-01 Michael Biebl wrote: > First of all, thanks Andreas and Jonas for getting libgcrypt and > libgpg-error updated and moved to /lib. > There is one remaining issue though about the devel files, I'd like to raise. > 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 and kept all devel > related files in /usr/lib. This looked like the right way to me. > Afaicr I've never seen this documentented somewhere to do it this > way and I'm wondering if this is indeed the agreed upon best > practice and if we should document it somehow (policy, devref, > whatever). [...] Hello, In the latest upload to experimental (-3 which is the NEW queue) I have synced with Ubuntu. They also install everything to /lib (since Nov. 2008 afaict from the changelog) with one exception: The la file stays in /usr/lib and gets a symlink in /lib. (I think the rationale is to not break existing la files that list /usr/lib/libgcrypt.la in deplibs.) cu andreas -- 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/20110101164035.gc2...@downhill.g.la
Re: devel files and libraries in /lib
On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote: > Afaicr I've never seen this documentented somewhere to do it this way and I'm > wondering if this is indeed the agreed upon best practice and if we should > document it somehow (policy, devref, whatever). > Yes. Arguably it's covered under http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN Cheers, Julien signature.asc Description: Digital signature
Re: devel files and libraries in /lib
Hello, On 01/01/2011 Michael Biebl wrote: > First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error > updated and moved to /lib. > > There is one remaining issue though about the devel files, I'd like to raise. > > 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 and kept all devel related files in > /usr/lib. This looked like the right way to me. > > Afaicr I've never seen this documentented somewhere to do it this way and I'm > wondering if this is indeed the agreed upon best practice and if we should > document it somehow (policy, devref, whatever). > > Opinions? funny enough, I raised this topic on #debian-devel at the same time. I didn't find documentation about it as well, and thus where not sure whether the development files for libraries in /lib belong to /usr/lib or /lib. A quick look at some packages gave the impression that there is no standard way: - most libdevel packages store the development .la files in /usr/lib - a few store them in /usr/lib and link them from /lib (libacl1-dev, libattr1-dev, libdm0-dev, xfslibs-dev) - a few store them in /lib (libnih-dev, libnih-dbus-dev, libsplashy1-dev) a problem with storing the libdevel files in /usr/lib, is that you cannot build the library with --libdir=/lib. If you do, the .la file has libdir set to /lib, which is wrong if it is stored in /usr/lib. Thus I guess the following is best practise: - build with --prefix=/usr - install .la file (if required due to reverse dependencies) and .so link to /usr/lib (just like the build system will do) - install .so.X.X.X library file and .so.X link to /lib (other than the build system does) Whatever the best practise may be, I agree with Michael that we should document it somewhere (Policy and Debian Library Packaging Guide) and fix the packages which don't do it correct yet. greetings, jonas signature.asc Description: Digital signature
Re: devel files and libraries in /lib
On 01.01.2011 17:58, Jonas Meurer wrote: > Thus I guess the following is best practise: > > - build with --prefix=/usr > - install .la file (if required due to reverse dependencies) and .so > link to /usr/lib (just like the build system will do) I would add, that if there are no rdeps yet of this library and the package ships a pkg-config file, I wouldn't install the *.la file at all. > - install .so.X.X.X library file and .so.X link to /lib (other than the > build system does) Please note here, that you need to "fix" the *.so symlink if you build with --prefix=/usr and move the libfoo.so.* files to /lib, as the libfoo.so symlink will point to the libfoo.so.* file in the same directory. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Safe File Update (atomic)
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. KiBi. signature.asc Description: Digital signature
Re: Safe File Update (atomic)
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 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/aanlktim5=w67itcnx7fkrmsuddstt=05zggbuwq32...@mail.gmail.com
Packaging LetoDMS (mydms)
Hello all, I am trying to package the new upstream version of mydms [1]. This Debian package is removed from the archive, and it won't be present in Squeeze [2]. The upstream package is renamed to letodms [3]. Last versions have a lot of changes (database, code) and improvements. I'm not sure if it is better to rename the package, creating a dummy transitional package (mydms) with the new package letodms. Or maybe, as the old mydms is removed from archive, just doing as a new package, and upload it with an ITP. In case of rename the package, maybe it could be needed to keep some paths (user data in /var/lib/mydms must remain, instead /var/lib/letodms), and Apache config to be compatible with old instances of mydms (for example, the old URL http:///mydms must kept, maybe add the new http:///letomds). The old mysql database name, named mydms, must be ketp to in new package to compatibilize with old instances of mydms. Maybe, the best way to rename the package is doing it with a new Debian revision with no database changes (on the same upstream version), and later package new upstream versions with database changes (db is managed with dbconfig-common). But, I am not sure if keep old /var/lib/mydms (for mydms upgrades) and create /var/lib/letodms (for new installs) is a good idea (it isn't). I would like to know what do you think about these points. Thank you. Regards, Francisco [1] http://packages.qa.debian.org/m/mydms.html [2] http://packages.qa.debian.org/m/mydms/news/20100929T163914Z.html [3] http://www.letodms.com/ -- Francisco M. García Claramonte Debian GNU/Linux Developer GPG: public key ID 556ABA51 signature.asc Description: This is a digitally signed message part
Re: devel files and libraries in /lib
On Sat, Jan 01, 2011 at 05:11:17PM +0100, 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 and kept all > devel related files in /usr/lib. This looked like the right way > to me. For these cases moving the SONAME and the actual file to /lib and keeping the development symlink (.so) along with the static library (.a) in /usr/lib makes sense, particularly if you take into account that the static library might be a large file. Also, note the FHS says "shared library images", not simply "libraries", so no static libraries should be there in the first place. My hunch is "put the .la file in /usr/lib, too" but I haven't looked at libtool internals in a while, so I have no clue as to the effect of having the SONAME and the .la file in different directories. Do note that the .la file does contain information about where the library was meant to be installed. I guess some scripts will break because of this, since it's not usual to have the SONAME in a different directory. My ₡0.02, Marcelo -- 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/20110101221737.ga17...@esk
Re: Safe File Update (atomic)
* Olaf van der Spek schrieb: > > Doing it in the kernel would be fine (maybe DLM could be used here), > > What's DLM? Distributed lock manager. > > but would be a nonportable solution for quite a long time ;-o > > Since it's the only proper solution I don't think that's a problem. I doubt that the only proper solution. As said, an (userland) filesystem could also do fine. 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/20110101230343.gd10...@nibiru.local
Re: Safe File Update (atomic)
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.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinsexfkrcdzf1d1ia44z=logx0cic46z39vf...@mail.gmail.com
Bug#608609: ITP: libpackage-pkg-perl -- collection of package manipulation utilities
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpackage-pkg-perl Version : 0.0019 Upstream Author : Robert Krimen * URL : http://search.cpan.org/dist/Package-Pkg/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : collection of package manipulation utilities Package::Pkg is Perl module that provides several utility functions useful for manipulating packages and their subroutines. You can install arbitrary code references as functions in a given namespace, alias functions from one package to another, and set up an exporter. In many respects, this package provides functionality similar to Sub::Install (see libsub-install-perl) and Sub::Exporter (see libsub-exporter-perl). NOTE: this package is required for Getopt::Usaginator (libgetopt-usaginator-perl), which in turn is required for an upgraded Config::JFDI (libconfig-jfdi-perl). -- 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/aanlktimvaqxotah8qn+76u2nuhg30541kpm+7_xof...@mail.gmail.com
Re: devel files and libraries in /lib
On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote: > On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote: > > Afaicr I've never seen this documentented somewhere to do it this way and > > I'm > > wondering if this is indeed the agreed upon best practice and if we should > > document it somehow (policy, devref, whatever). > Yes. Arguably it's covered under > http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN 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 and /lib isn't directly supported by automake. A burden we must bear, unless someone wants to fix automake. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: devel files and libraries in /lib
On 01/01/2011 Steve Langasek wrote: > On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote: > > On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote: > > > > Afaicr I've never seen this documentented somewhere to do it this way and > > > I'm > > > wondering if this is indeed the agreed upon best practice and if we should > > > document it somehow (policy, devref, whatever). > > > Yes. Arguably it's covered under > > http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN > > 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 and /lib isn't > directly supported by automake. A burden we must bear, unless someone wants > to fix automake. In case that the situation is clear, some Ubuntu packages seem to be wrong. At least the Ubuntu libgcrypt11-dev[1] and libgpg-error-dev[2] packages seem to install the development files to /lib. In Debian, at least the following three packages need to be fixed: libnih-dev, libnih-dbus-dev, libsplashy1-dev greetings, jonas [1] http://packages.ubuntu.com/natty/i386/libgcrypt11-dev/filelist [2] http://packages.ubuntu.com/natty/i386/libgpg-error-dev/filelist signature.asc Description: Digital signature
Re: devel files and libraries in /lib
On 02/01/2011 Jonas wrote:
> On 01/01/2011 Steve Langasek wrote:
> > On Sat, Jan 01, 2011 at 06:34:30PM +0100, Julien Cristau wrote:
> > > On Sat, Jan 1, 2011 at 17:11:17 +0100, Michael Biebl wrote:
> >
> > > > Afaicr I've never seen this documentented somewhere to do it this way
> > > > and I'm
> > > > wondering if this is indeed the agreed upon best practice and if we
> > > > should
> > > > document it somehow (policy, devref, whatever).
> >
> > > Yes. Arguably it's covered under
> > > http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN
> >
> > 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 and /lib isn't
> > directly supported by automake. A burden we must bear, unless someone wants
> > to fix automake.
>
> In case that the situation is clear, some Ubuntu packages seem to be
> wrong. At least the Ubuntu libgcrypt11-dev[1] and libgpg-error-dev[2]
> packages seem to install the development files to /lib.
I was wrong, both libgcrypt11-dev and libgpg-error-dev from Ubuntu do
install the .la files to /usr/lib, and just link them from /lib. But
according to Ubuntu natty Contents-amd64.gz[1], the following packages
only have .la in /lib:
libnih-dev, libnih-dbus-dev, libupsclient1-dev.
In Debian sid, as already written this is the case for the following
packages (according to amd64 Contents.gz[2]):
libnih-dev, libnih-dbus-dev, libsplashy1-dev
The following packages install development .a library to /lib in Debian
sid[3]:
libcap-dev, libgpib0-dev, libnih-dev, libnih-dbus-dev, plymouth-dev,
libupsclient1-dev
And the following packages install the unversioned .so link to /lib in
Debian sid [4, manually checked]:
libcap-dev, libcgroup-dev, libgpib0-dev, iptables-dev, libnss-lwres,
libnss-sss, plymouth-dev, libsplashy1-dev
greetings,
jonas
[1] while read line; do if ! zgrep -q "^usr/${line}" Contents-amd64.gz; then
echo $line; fi; done < <(zgrep "^lib/lib.*\.la" Contents-amd64.gz | awk '{print
$1}')
[2] while read line; do if ! zgrep -q "^usr/${line}"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz;
then echo $line; fi; done < <(zgrep "^lib/lib.*\.la"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz
| awk '{print $1}')
[3] while read line; do if ! zgrep -q "^usr/${line}"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz;
then echo $line; fi; done < <(zgrep "^lib/lib.*\.a\s"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz
| awk '{print $1}')
[4] while read line; do if ! zgrep -q "^usr/${line}"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz;
then echo $line; fi; done < <(zgrep "^lib/lib.*\.so\s"
/var/cache/apt/apt-file/ftp2.de.debian.org_debian_dists_unstable_Contents-amd64.gz
| grep -v "\-[0-9]" | awk '{print $1}')
signature.asc
Description: Digital signature
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
Hi Stefan, Stefan Fritsch wrote: > I fully agree with you WRT flawfinder and splint. > > OTOH, I think that clang's scan-build has a reasonable signal-to-noise > ratio. It only does C, though. Yes, scan-build is pending some infrastructure work. I've now added a list of known tools to the website: http://qa.debian.org/daca/ > For perl, perlcritic at a sufficiently high warning level may be worth > a thought. I read a bit about Perl::Critic the other day and it seems it might be worth running it and split the results by severity. The results will be very noisy, however. > A question about hardware: How much memory/disk space is needed at the > minimum to be useful? It all depends on the tool that is to be run. cppcheck is CPU and memory- bound, checkbashisms, ohcount, and pyflakes are usually I/O-bound. The minimum fs space requirement is the binary or source package unpacked (multiply that by the number of instances of the tools running on the host.) clang and smatch need more space since they build the code. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/4d201fdc.1e1d640a.2129.8...@mx.google.com
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
Hi, Mohammad Ebrahim Mohammadi Panah wrote: > Out of my curiosity/ignorance, have you considered Dehydra and > Treehydra of Mozilla for inclusion? Is there a readily-available compilation of checks for *hydra? I'm aware of both tools, but just like for coccinelle, the checks need to be written (and/or somehow standardise a way for packages to include private checks that should be run.) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/4d202183.880bec0a.2b29.1...@mx.google.com
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
Stefano Zacchiroli wrote: > On Mon, Dec 20, 2010 at 07:08:59PM -0600, Raphael Geissert wrote: > Starting from Linux 2.6.36, there's a dir scripts/coccinelle/ in > upstream Linux. It contains Coccinelle patterns to find bugs; some of > them propose patches as well, but I'm not sure what is the exact amount > of patches vs report-only. According to Julia, some of those patterns > are kernel-specific and expect a specific contact which is created by > kernel Makefiles; other patterns are OTOH fully generic. I guess the > best way to figure out how many of them are generic is to actually give > them a try. > > What I find very interesting for Coccinelle, is that we can imagine a > growing set of patterns, contributed by users, package maintainers, QA > team, etc. However, that will need some support in DACA to re-run the > analysis of a given tool on the whole archive, which I'm not sure it's > something you had in mind to support. More or less, yes. I had considered running different versions of the tools and they are actually supported by the scripts that run the tools. However, the web interface isn't designed to support multiple versions. If new checks are added and snapshots are released every once in a while, they could easily be run. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/4d2022d6.293eec0a.3627.1...@mx.google.com
Re: Safe File Update (atomic)
On Fri, Dec 31, 2010 at 09:51:50AM -0200, 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
> cannot be implemented for all use cases of the POSIX API, so it will not
> be implemented by the kernel. That's all there is to it, AFAIK.
>
> 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. You could ask for whatever is needed
> to do a (open+write+close) that is atomic if the target already exists.
> Maybe one of those has a better chance than O_ATOMIC.
The O_ATOMIC open flag is highly problematic, and it's not fully
specified. What if the system is under a huge amount of memory
pressure, and the badly behaved application program does:
fd = open("file", O_ATOMIC | O_TRUNC);
write(fd, buf, 2*1024*1024*1024); // write 2 gigs, heh, heh heh
write(fd, buf2, 1024);
close(fd);
What happens if another program opens "file" for reading during the
one day sleep period? Does it get the the old contents of "file"?
The partially written, incomplete new version of "file"? What happens
if the file is currently mmap'ed, as Henrique has asked?
What if another program opens the file O_ATOMIC during the one day
sleep period, so the file is in the middle of getting updated by two
different processes using O_ATOMIC?
How exactly do the semantics for O_ATOMIC work?
And given at the momment ***zero*** file systems implement O_ATOMIC,
what should an application do as a fallback? And given that it is
highly unlikely this could ever be implemented for various file
systems including NFS, I'll observe this won't really reduce
application complexity, since you'll always need to have a fallback
for file systems and kernels that don't support O_ATOMIC.
And what are the use cases where this really makes sense? Will people
really code to this interface, knowing that it only works on Linux
(there are other operating systems, out there, like FreeBSD and
Solaris and AIX, you know, and some application programmers _do_ care
about portability), and the only benefits are (a) a marginal
performance boost for insane people who like to write vast number of
2-4 byte files without any need for atomic updates across a large
number of these small files, and (b) the ability to keep the the file
owner unchanged when someone other than the owner updates said file
(how important is this _really_; what is the use case where this
really matters?).
And of course, Olaf isn't actually offerring to implement this
hypothetical O_ATOMIC. Oh, no! He's just petulently demanding it,
even though he can't give us any concrete use cases where this would
actually be a huge win over a userspace "safe-write" library that
properly uses fsync() and rename().
If someone were to pay me a huge amount of money, and told me what was
the file size range where such a thing would be used, and what sort of
application would need it, and what kind of update frequency it should
be optimized for, and other semantic details about parallel O_ATOMIC
updates, what happens to users who are in the middle of reading the
file, what are the implications for quota, etc., it's certainly
something I can entertain. But at the moment, it's a vague
specification (not even a solution) looking for a problem.
- Ted
--
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/20110102070922.ga6...@thunk.org
Re: devel files and libraries in /lib
* Jonas Meurer schrieb: > In case that the situation is clear, some Ubuntu packages seem to be > wrong. At least the Ubuntu libgcrypt11-dev[1] and libgpg-error-dev[2] > packages seem to install the development files to /lib. > > In Debian, at least the following three packages need to be fixed: > libnih-dev, libnih-dbus-dev, libsplashy1-dev Perhaps it's wise to add some additional checks which issue an warning on that (using a manually maintained whitelist) on package build. 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/20110102074822.ge10...@nibiru.local
