New user and group name for inadyn package
Hello Debian Developers, I'm packaging new version of inadyn package [1]. inadyn can run as daemon, therefore I created init.d script. Daemon supports dropping its privileges on start as well. I chose inadyn for the user name and inadyn for the group name with dynamically allocated system IDs. Are there any comments/suggestions please? 1. http://packages.debian.org/sid/inadyn Thanks, -- Timur -- 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/idl1hn$up...@dough.gmane.org
Bug#606189: ITP: owfs -- 1-Wire File System
Package: wnpp Severity: wishlist Owner: Vincent Danjean * Package name: owfs Version : 2.8p4 Upstream Author : Paul H Allfille * URL : http://owfs.org * License : GPL-2, LGPL-2, BSD (depending on components) Programming Lang: C, C++, C#, Perl, Python, java, ruby (lots of bindings) Description : 1-Wire File System Global description: 1-wire is a communication protocol, wiring scheme and system of devices and "iButtons". The design and control of the protocol is from Dallas Semi (part of Maxim Semiconductor). The 1-wire protocol uses in fact 2 wires: one for ground and the active wire for data *and* power! . OWFS is an easy way to use the powerful 1-wire system of Dallas/Maxim. It is a simple and flexible program to monitor and control the physical environment. You can write scripts to read temperature, flash lights, write to an LCD, log and graph, ... Then, there will be a short paragraph for each package (langage bindings, main library, documentation, ...) If some people with knowledge in Python and php packaging are interrested to help, they are welcome. Let me know. Java, C# and ruby bindings are not yet ready but I will ask for help when they will be. If some people want to co-maintain this package, there are also welcome. -- 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/20101207101624.17249.38588.report...@localhost.localdomain
Re: List of FTBFS in Ubuntu
On Mon, Dec 06, 2010, Lucas Nussbaum wrote: > As I already told you on IRC, given that I could make apport fail two > times on both i386 and amd64, and provided the build log, I think that > the next step is for you to provide a build log, so we can diff them. The apport failure as bugged me for a while, I tried to reproduce it multiple times in the past and even just understanding the failure from the source and error message, but couldn't figure it out in the past; I'm attaching an amd64 build log, result of: sbuild -A -d natty apport_1.16-0ubuntu1.dsc (it built fine) This is using Ubuntu's .tar.bz2 chroots as downloaded from Launchpad and a moderately configured sbuild 0.60.5-1ubuntu2; maybe your chroot is constructed in a specific way? If you have notes on how you create your chroots, these would be interesting -- Loïc Minier apport_1.16-0ubuntu1-amd64-20101207-1117.gz Description: Binary data
Re: List of FTBFS in Ubuntu
On Tue, Dec 07, 2010, Loïc Minier wrote: > The apport failure as bugged me for a while, I tried to reproduce it > multiple times in the past and even just understanding the failure from > the source and error message, but couldn't figure it out in the past; Maybe the difference is in the order in which files are returned when scanning directories, perhaps because we're using different filesystems. I can see that different code pathes are being used, but install_auto() is supposed to iterate over data/icons symlinks and create target directories even before the install subcommands are run; I don't understand why it isn't run in your case -- Loïc Minier -- 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/20101207121711.ga14...@bee.dooz.org
Re: List of FTBFS in Ubuntu
On 07/12/10 at 13:17 +0100, Loïc Minier wrote: > On Tue, Dec 07, 2010, Loïc Minier wrote: > > The apport failure as bugged me for a while, I tried to reproduce it > > multiple times in the past and even just understanding the failure from > > the source and error message, but couldn't figure it out in the past; > > Maybe the difference is in the order in which files are returned when > scanning directories, perhaps because we're using different > filesystems. > > I can see that different code pathes are being used, but install_auto() > is supposed to iterate over data/icons symlinks and create target > directories even before the install subcommands are run; I don't > understand why it isn't run in your case I'm building on tmpfs, FWIW. If the build process involves creating temporary files on a filesystem without sub-second granularity (like ext3 on /tmp), then copying them back on tmpfs, and comparing their mtimes, it can cause problems. All packages in Debian are currently fine with this, but in the past, there were some packages with configure scripts from broken autoconf versions, I think. It's possible that something similar is happening here. Are you building on ext3 or ext4? - Lucas -- 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/20101207125600.ga16...@xanadu.blop.info
Re: List of FTBFS in Ubuntu
On Tue, Dec 07, 2010, Lucas Nussbaum wrote: > Are you building on ext3 or ext4? ext4 -- Loïc Minier -- 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/20101207131552.ge16...@bee.dooz.org
Re: List of FTBFS in Ubuntu
On 07/12/10 at 14:15 +0100, Loïc Minier wrote: > On Tue, Dec 07, 2010, Lucas Nussbaum wrote: > > Are you building on ext3 or ext4? > > ext4 I could reproduce the failure in a clean chroot generated with debootstrap --variant=buildd. on IRC, Michael Bienia also said that he was able to reproduce the failure using pbuilder. Lucas -- 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/20101207192656.ga16...@xanadu.blop.info
Re: strange failures on lxdebian and asdfasdf.debian.net for cmor
On 2010-12-04 12:02, Michael Tautschnig wrote: Hi Alastair, I'm by no means a bsd expert and you actually might want to redirect your question to debian-...@l.d.o instead. I've a strange issue: I've a perfectly ordinary package, cmor, which fails to build on s390 and kfreebsd-amd64. In both cases it fails while trying to build a test executable, ipcc_test_code, in the test target, but with different errors in ld, segfault and abort. Now, outside the buildds (lxdebian and asdfasdf) the package builds fine on s390 and kfreebsd-amd64 (it fails on kfreebsd-i386, also in building ./ipcc_test_code, but that appears to be different. While I don't understand the failure yet, it is at least reproducible). [...] Could you maybe, as first measure, try to make the build (or the build of tests at least) way more verbose? Surely it's not ln -sf that aborts, but that is about all that can be found in the build logs. I guess it would be nice to see the full command line that is being executed such that precisely this step can be investigated in more detail. As the tests (once they run) seem to be very verbose, this should (a) help to nail down the error and (b) could possibly be some problem with the terminal!? (The latter is a wild guess as I have no idea what cmor really does.) Hope this helps, Michael Ok, I've enabled further debugging on these. Builds on s390 seem to be working fine; its now building on zandonai ; all previous failures appear to have been on lxdebian and i'm assuming issues there (memory, tmpfs, etc.). I'm down to a build issue on kfreebsd-i386, with an abort (Error 134). The FTBFS on kfreebsd-amd64 at the same point seems to have gone away (it was also an abort, error 134); Perhaps a different memory-related error? With debugging (gcc --verbose) the error looks like: ln -sf TestTables Tables rm -f ./ipcc_test_code ; gcc --verbose -lnetcdf -Iinclude -Iinclude/cdTime Test/ipcc_test_code.c -L/usr/lib -I/usr/include -L. -lcmor -lnetcdf -ludunits2 -lossp-uuid -I/usr/include/ossp -lm -o ipcc_test_code ; ./ipcc_test_code Using built-in specs. Target: i486-kfreebsd-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-10' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-kfreebsd-gnu --host=i486-kfreebsd-gnu --target=i486-kfreebsd-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-10) COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'ipcc_test_code' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/cc1 -quiet -v -Iinclude -Iinclude/cdTime -I/usr/include -I/usr/include/ossp Test/ipcc_test_code.c -quiet -dumpbase ipcc_test_code.c -mtune=generic -march=i586 -auxbase ipcc_test_code -version -o /tmp/cc2yyWnV.s ignoring nonexistent directory "/usr/local/include/i486-kfreebsd-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/../../../../i486-kfreebsd-gnu/include" ignoring nonexistent directory "/usr/include/i486-kfreebsd-gnu" ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include<...> search starts here: include include/cdTime /usr/include/ossp /usr/local/include /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/include /usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/include-fixed /usr/include End of search list. GNU C (Debian 4.4.5-10) version 4.4.5 (i486-kfreebsd-gnu) compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ac5ecb32b9a1ba1edd331ac3e5f20c5d COLLECT_GCC_OPTIONS='-v' '-Iinclude' '-Iinclude/cdTime' '-L/usr/lib' '-I/usr/include' '-L.' '-I/usr/include/ossp' '-o' 'ipcc_test_code' '-mtune=generic' '-march=i586' as -V -Qy -o /tmp/ccgbAyMN.o /tmp/cc2yyWnV.s GNU assembler version 2.20.1 (i486-kfreebsd-gnu) using BFD version (GNU Binutils for Debian) 2.20.1-system.20100303 COMPILER_PATH=/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/:/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/:/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/:/usr/lib/gcc/i486-kfreebsd-gnu/4.4.5/.
apt-diff: a tool to diff filesystem content against APT
(I'm not subscribed to this list, please CC me on replies.) I have recently written a tool I call "apt-diff" to compare filesystem content against APT. It is intended for investigating problems where packaged files get modified/deleted after installing them from APT (e.g., by user customization, accidental deletion, etc.). I originally wrote it after clobbering the packaged ALSA installation on my computer with "make install" and needing a good way to detect which packaged files had been modified so that I could restore them. I also find it useful for figuring out what customizations I have made to my system after I have forgotten about them. Conceptually apt-diff is meant to act like "svn diff", "git diff", etc., except that instead of comparing to a source code repository it compares to the APT repositories. I've designed it for processing many files/packages in batch, so diff'ing the entire filesystem is doable. It's sort of like an APT-aware version of debsums. The code is at https://github.com/TristanSchmelcher/apt-diff My hope is for this to become part of the APT stack in Debian and I'm posting here to see if there is any interest in that from the Debian developer community. I think it might be helpful for it to be invoked from reportbug to diagnose/triage issues where files or configurations have been changed. Plus I think it's just a nice tool to have available for power users. -- 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=xrf33uwabvtcgxg1jdazubkuz77exf4g3y...@mail.gmail.com
Re: apt-diff: a tool to diff filesystem content against APT
Hello, > I also > find it useful for figuring out what customizations I have made to my > system after I have forgotten about them. how does it deal with configurations generated in postinstall? Bye -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Re: Re: apt-diff: a tool to diff filesystem content against APT
> how does it deal with configurations generated in postinstall? Only files shipped by a package (i.e., appear in its .list file) can be diff'ed, so if a configuration file was generated from scratch in a postinst then apt-diff can't show a diff for it. But it does keep track of how many files it has seen that aren't owned by any package, and there is an option to print the list, so you can use that to see what generated files are present in a directory tree. But at that point you sort of have to know what you're looking for. Sort of analogous to an untracked file in a VCS system. -- 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/1291782138.22848.16.ca...@tinygod3
Re: apt-diff: a tool to diff filesystem content against APT
Tristan Schmelcher writes: >> how does it deal with configurations generated in postinstall? > > Only files shipped by a package (i.e., appear in its .list file) can be > diff'ed, so if a configuration file was generated from scratch in a > postinst then apt-diff can't show a diff for it. But it does keep track > of how many files it has seen that aren't owned by any package, and > there is an option to print the list, so you can use that to see what > generated files are present in a directory tree. But at that point you > sort of have to know what you're looking for. > > Sort of analogous to an untracked file in a VCS system. Isn't debsums already filling that nieche? MfG Goswin -- 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/877hfken73@frosties.localnet
Re: apt-diff: a tool to diff filesystem content against APT
On 07/12/10 at 17:45 -0800, Tristan Schmelcher wrote: > (I'm not subscribed to this list, please CC me on replies.) > > I have recently written a tool I call "apt-diff" to compare filesystem > content against APT. It is intended for investigating problems where > packaged files get modified/deleted after installing them from APT > (e.g., by user customization, accidental deletion, etc.). I originally > wrote it after clobbering the packaged ALSA installation on my > computer with "make install" and needing a good way to detect which > packaged files had been modified so that I could restore them. I also > find it useful for figuring out what customizations I have made to my > system after I have forgotten about them. > > Conceptually apt-diff is meant to act like "svn diff", "git diff", > etc., except that instead of comparing to a source code repository it > compares to the APT repositories. I've designed it for processing many > files/packages in batch, so diff'ing the entire filesystem is doable. > It's sort of like an APT-aware version of debsums. The code is at > https://github.com/TristanSchmelcher/apt-diff > > My hope is for this to become part of the APT stack in Debian and I'm > posting here to see if there is any interest in that from the Debian > developer community. I think it might be helpful for it to be invoked > from reportbug to diagnose/triage issues where files or configurations > have been changed. Plus I think it's just a nice tool to have > available for power users. Hi, How does it compare to the cruft package? - Lucas -- 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/20101208070533.ga28...@xanadu.blop.info
