dpkg-reconfigure and postinst
Hi! I am having a problem, and I guess I might not be the only one who might stumble into it. When one wants to do something in new installs of the package, they usually check for $2 != "" in the postinst and put the stuff in there. So far, so good, and policy friendly because you might not create ill side effects about user expectations to no changes during upgrades. When though the stuff in between that condition is also guided by some debconf questions, people might want to have it also being run on a dpkg-reconfigure. That makes it somewhat tricky, because from what I see the postinst is called just the same way like a reinstall of the very same package version, that is, with the version number prior installed in $2. Left aside that I don't see a real chance currently to differentiate between a dpkg-reconfigure and a reinstall of the same version, it still leaves me with the problem that I would need to dynamically generate the postinst on package build to contain the exact version of the package I am building. Is my analysis flawed? Is there a way to differentiate between a reconfigure and a reinstall that I didn't see? Is there a cleaner approach to this problem than dynamically generating the postinst? Thank in advance for your thoughts, and a Cc might be nice, though I'm checking with the list archives. So long, Alfie -- char *strstr(const char *haystack, const char *needle); -- STRSTR(3) Linux Programmer's Manual signature.asc Description: Digital signature
Re: dpkg-reconfigure and postinst
On Wed, Jul 05, 2006 at 02:35:44AM -0500, Gerfried Fuchs wrote: > Is my analysis flawed? Is there a way to differentiate between a > reconfigure and a reinstall that I didn't see? Is there a cleaner > approach to this problem than dynamically generating the postinst? take a look at $1 as passed to the config script in installs vs reinstalls. in installs/reinstalls it will be "configure", and in reconfigurations, it will be "reconfigure". of course this isn't completely solving the problem, as you have to pass this information on to the postinst script. i've had to do this before, and solved it by using the above knowledge plus a debconf "question" specifically purposed for passing the info from config to postinst. something like: = = = = config: = = = = if [ "$1" = "reconfigure" ]; then db_set package/reconfiguring true fi = = = = postinst: = = = = db_get package/reconfiguring && reconfiguring="$RET" db_reset package/reconfiguring = = = = and the template: = = = = Template: package/reconfiguring Type: boolean Default: false = = = = it's not the *cleanest* solution out there, but it works, and there's nothing wrong with it from a technical/policy perspective. the real solution would be for dpkg to finally get around to implementing "reconfigure" being passed to postinst (istr docs mentioning that this would "some day" happen), but this will break many, many things. sean signature.asc Description: Digital signature
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 04:39:12PM +1000, Matthew Palmer wrote: > dpkg-statoverride is a tool for the system administrator to specify a > different mode or ownership for a file to that which is provided in the > package. It is not meant to be used by the package. there are cases where it's appropriate for a package to use it. for example, if the package creates the user that is supposed to own a file, and later changes the ownership to that user in the maintscripts. in this case it would be appropriate to use this tool to check if the local admin has overrided the permissions, and if so, keep the permissions respected. but otherwise: > The correct answer, in this case, is to ensure that the file in the package > has the appropriate permissions, and then use the -X option to dh_fixperms > to ensure that fixperms doesn't turn the permissions back to the default. this would be the reasonable approach if the user already exists. sean -- signature.asc Description: Digital signature
Re: A question on setting setuid bit
On Tue, Jul 04, 2006 at 08:37:52PM -0400, LEE, Yui-wah (Clement) wrote: > I am building a package in which one of the binary has > to have the setuid and setgid bits set. I wonder which > one of the following two is the more appropriate method > to use? It looks like you've got the answer to this already, but it is worth considering whether the bit needs to be set by default. Perhaps a debconf question like man-db, or cdrecord, could allow the user to disable/enable this. I'd want to be extremely sure that the package had no buggy code before installing it setuid/setgid. If you'd like somebody to check over the code for you, or as a second pair of eyes, then please consider asking the auditing people: http://shellcode.org/mailman/listinfo/debian-audit Steve -- signature.asc Description: Digital signature
Re: BTS tag proposal "faq"
also sprach Filipus Klutiero <[EMAIL PROTECTED]> [2006.07.04.1935 +0200]: > Bugs that were fixed or are to be fixed (even in unstable) > shouldn't be tagged wontfix. They aren't. > What's the problem with simply marking the bugs as fixed in the right version? That's what's happening, or should be. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "solange man nicht die moral des christentums als kapitalverbrechen am leben empfindet, haben dessen verteidiger gutes spiel." - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Re: Copyright on Debian Wiki?
also sprach Daniel Dickinson <[EMAIL PROTECTED]> [2006.07.05.0825 +0200]: > The copyright link is missing (http://wiki.debian.net/copyright.html) > but the copyright was broken anyway (see > http://wiki.debian.org/DebianWikiIsNotGFDL). What is the copyright > on the wiki, and where is the correct link to the copyright notice, > that I might fix the wiki? This is a work in progress. Unfortunately, we do not have a consistent copyright or licence for wiki content. The plan is to relicence all pages under an acceptable free licence, but this takes time. Why do you ask? Do you need to use content? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system a friend is someone with whom you can dare to be yourself signature.asc Description: Digital signature (GPG/PGP)
Re: doc compilations: build-time or pre-built?
[EMAIL PROTECTED] wrote: > tony mancill <[EMAIL PROTECTED]> writes: > >> Steinar H. Gunderson wrote: >>> On Tue, Jul 04, 2006 at 07:25:16PM -0300, [EMAIL PROTECTED] wrote: 1) compile docs pre-build-time; or 2) compile docs in build-time >>> >>> Definitely the latter. We build stuff at build time for a reason, >>> architecture-specific or -independent alike. >> >> Is this the consensus/best-practice on this question? >> >> It seems like it would be quite taxing on the autobuilders to have to pull >> something like docbook (and its chain of dependencies) into a pbuilder just >> to recompile a manpage that doesn't change between architectures. >> >> I'm interested in this because I've typically done (2), but have recently >> started to think that (1) is more appropriate, particularly for packages >> where the documentation is a simple manpage. > > And It's exactly this the case in question, for me. I think that if upstream ships pre-built docs, then it is not necessary to rebuild them (but you should verify that it's possible...). In all other cases, I would argue for generating the docs at build-time. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#376825: ITP: haskell-newcgi -- Enhanced CGI library for Haskell
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: haskell-newcgi Version : 2006.6.5 Upstream Author : Bjorn Bringert et al * URL : http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ * License : BSD Programming Lang: Haskell Description : Enhanced CGI library for Haskell This is a Haskell library for writing CGI web applications. It provides a number of features not found in the CGI implementation in the standard Haskell libraries. . This library supports setting arbitrary response headers, support for cookies, efficient file upload support, integration with Data.ByteString, and other useful features. . It also provides wrapper functions for compatibility with the existing Network.CGI module. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376829: ITP: haskell-bytestring -- Extremely fast Haskell I/O library using packed strings
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: haskell-bytestring Version : 0.6 Upstream Author : Don Stewart * URL : http://www.cse.unsw.edu.au/~dons/fps.html * License : BSD Programming Lang: Haskell Description : Extremely fast Haskell I/O library using packed strings Data.ByteString (formerly FastPackedString/FPS) provides packed strings (byte arrays held by a ForeignPtr), along with a list interface to these strings. It lets you do extremely fast IO in Haskell; in some cases, even faster than typical C implementations, and much faster than [Char]. It uses a flexible "foreign pointer" representation, allowing the transparent use of Haskell or C code to manipulate the strings. . Data.ByteString is written in Haskell98 + the foreign function interface and cpp. It has been tested succesfully with GHC 6.4 and 6.5, and hugs March 2005. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376830: ITP: haxml -- XML framework for Haskell
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: haxml Version : 1.13.1 Upstream Author : Malcolm Wallace et al * URL : http://www.cs.york.ac.uk/fp/HaXml/ * License : Library LGPL plus relaxation, tools GPL Programming Lang: Haskell Description : XML framework for Haskell HaXml is a collection of utilities for parsing, filtering, transforming, and generating XML documents using Haskell. Its basic facilities include a parser for XML, a separate error-correcting parser for HTML, an XML validator, and pretty-printers for XML and HTML. . In addition to this, Haskell2Xml is a replacement class for Haskell's Show/Read classes. It allows you to read and write ordinary Haskell data as XML documents. DtdToHaskell is a tool for translating any valid XML DTD into equivalent Haskell types. Xtract is a grep-like tool for XML documents, based loosely on the XPath and XQL query languages. It can be used either from the command line, or within your own code as part of the library. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
greylisting on debian.org?
Hi all, this is maybe the wrong group for it (sorry in that case), but: Do we use greylisting on the @debian.org domain and especially on @lists.debian.org? If not, then we should probably try it - for my private stuff, that works just nice. The only things which still come through are spams which were sent over debian.org and such, which obviously use real mail servers. Just my thoughts, when I read the recent posting from JB (Jeff) on the planet. -- cheers, +---+ | wjl aka Wolfgang Lonien | GPG key: 728D9BD0 | |-| Fingerprint: | | Mail: | a923 2294 b7ed eb3e 2f18 | | wolfgang - at - lonien.de | ae56 aab8 d36a 728d 9bd0 | +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
* sean finney | On Wed, Jul 05, 2006 at 04:39:12PM +1000, Matthew Palmer wrote: | > dpkg-statoverride is a tool for the system administrator to specify a | > different mode or ownership for a file to that which is provided in the | > package. It is not meant to be used by the package. | | there are cases where it's appropriate for a package to use it. for | example, if the package creates the user that is supposed to own a file, | and later changes the ownership to that user in the maintscripts. If so, create the user in preinst and it'll work just fine. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 03:25:37PM +0200, Tollef Fog Heen wrote: > | On Wed, Jul 05, 2006 at 04:39:12PM +1000, Matthew Palmer wrote: > | > dpkg-statoverride is a tool for the system administrator to specify a > | > different mode or ownership for a file to that which is provided in the > | > package. It is not meant to be used by the package. > | > | there are cases where it's appropriate for a package to use it. for > | example, if the package creates the user that is supposed to own a file, > | and later changes the ownership to that user in the maintscripts. > > If so, create the user in preinst and it'll work just fine. the next sentence, which you conveniently cut out, explains exactly why this won't work just fine :) sean signature.asc Description: Digital signature
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 04:02:43AM -0400, sean finney wrote: >On Wed, Jul 05, 2006 at 04:39:12PM +1000, Matthew Palmer wrote: >> dpkg-statoverride is a tool for the system administrator to specify a >> different mode or ownership for a file to that which is provided in the >> package. It is not meant to be used by the package. > >there are cases where it's appropriate for a package to use it. for >example, if the package creates the user that is supposed to own a file, >and later changes the ownership to that user in the maintscripts. in >this case it would be appropriate to use this tool to check if the >local admin has overrided the permissions, and if so, keep the >permissions respected. There are two cases where shipping the binary with the correct ownership or permission is not possible: * the user meant to own the files is dynamically created, or * the permissions for a file are a debconf option In such cases it is necessary in the postinst to do: if ! dpkg-statoverride --list $file >/dev/null 2>&1 then chown $user:$group $file # and/or chmod $mode $file fi Which will only set the permissions if the local administrator has not supplied other values. Just looking at various postinst scripts now, I note that some packages use dpkg-statoverride to apply the changes rather than chown/chmod. Not quite sure of the rationale behind this. In my opinion, setting permissions via dpkg-statoverride should be limited to the local admin only. It also means that you need to remove the override in the postrm and complicates the case where you wish to change the default values used. In both cases you need to compare the values returned by --list and only remove/change if those values match what was previously set by the package. Even with this test, there is *no way to be sure* that the override was originally set by the package. Could be that the administrator set the override with those values to ensure they didn't change. Summary for maintainer scripts: * Don't use chown/chmod in without first testing dpkg-statoverride --list. * Don't use dpkg-statoverride to apply owner/group/mode changes. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-reconfigure and postinst
On Wed, Jul 05, 2006 at 02:35:44AM -0500, Gerfried Fuchs wrote:
> Hi!
hi,
> I am having a problem, and I guess I might not be the only one who
> might stumble into it. When one wants to do something in new installs
> of the package, they usually check for $2 != "" in the postinst and put
> the stuff in there. So far, so good, and policy friendly because you
> might not create ill side effects about user expectations to no changes
> during upgrades.
this is what i do in the postinst of libapache-mod-ssl package:
# we do not want to bother the user with useless questions at install time
if [ "$1" = "reconfigure" ] || [ "${DEBCONF_RECONFIGURE}" = "1" ]; then
mod-ssl-makecert
fi
this is documented in debconf-devel manpage.
cheers
domenico
-[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
Well, I think, we first should think about, what aim this CD or DVD should be. Which people we want to reach ? In the time, where are so many other live-cds, like Knoppix, kanotix, Grml, DSL and so on, it is very difficult to create an "all-in-wonder-"-stuff. So my thougts are these: People, who like KDE and GNOME want to have a fully graphic environment and a an easy system. So pack on it all the stuff, which is useful for people and what has graphical tools i.e. synaptics, openoffice, browsers and all the other graphical stuff, whithout those people cannot work. The other profile are people, who like the shell, and who are well known with it. So put all the important things, which make life easier upon this CD. X should be packed on it, too, and a small wm (I suggest fluxbox or XFCE) Then, there are the professionels, they just need all the tools. For these people there should be a multiboot-CD. I think of all the tools, they are in i.e. GRML. X should be there natuarally as some tools are really better to use in X. QTParted is such a tool. But thats not all. Thjese tools should fit about 250MB at all, so it would be nice to have the same tools for the most used architectures on this CD or DVD, too (AMD32, AMD64, PPC, Sparc etc.) I suppose, there will be other groups of people, but for those, the other live cds on the market should be good enough. Ah, I will not forget: Please, no Installer on these CDs !!! IMO people shall do a real installation, not a "rsync" like Knoppix does. Reason is: People, who make a real installation will understand their system, and those people will bring the Debian forward. Best regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc compilations: build-time or pre-built?
> >> 1) compile docs pre-build-time; or > >> 2) compile docs in build-time > > > > Definitely the latter. We build stuff at build time for a reason, > > architecture-specific or -independent alike. > > That depends a bit on the stuff. A lot of maintainers think running > auto* to generate configure and Makefile.in at build-time is to be > avoided. Another lot of maintainers disagree with them. Really, someone should actually start talking with numbers, to answer the following question: How much time is used installing/running those auto* toolchain, and docbook toolchain. It's not too difficult to use oprofile, it just needs some work. Another aspect is maintenance cost. Auto* tools and docbook toolchain, and tex toolchain may break, which means packages no longer build. This, I believe, shouldn't really be considered a reason not to build-depend; because it will be the users who will suffer from a broken package that doesn't really build. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376315: ITP: hydrogen-drumkits -- drumkits for Hydrogen
At 04 Jul 2006 17:57:29 +0200, Paul Seelig wrote: > > [EMAIL PROTECTED] (Free Ekanayaka) writes: > > > This package contains a collection of drumkits for Hydrogen, a > > sample based drum machine/step sequencer. > > > This is not a single package but actually a collection of various > packages. I once packaged Erny's Percussion for private purposes and > noted the absense of a suitable license. This has to be evaluated for > every single collection before packaging it for Debian. Although it will be a painful task, I welcome such a progress, which will improve Debian multimedia as a whole. Similar could be said about MIDI synth patterns. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
also sprach Wolfgang Lonien <[EMAIL PROTECTED]> [2006.07.05.1519 +0200]: > Do we use greylisting on the @debian.org domain and especially on > @lists.debian.org? > > If not, then we should probably try it - for my private stuff, that > works just nice. The only things which still come through are spams > which were sent over debian.org and such, which obviously use real mail > servers. This has been brought up. Basically I don't think people were opposed to it, but there was noone available to implement it. So if you really want it, log in to the hosts, copy the exim configuration, implement greylisting, test it, then contact [EMAIL PROTECTED] with patches. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system i've not lost my mind. it's backed up on tape somewhere. signature.asc Description: Digital signature (GPG/PGP)
Bug#376857: ITP: curlftpfs -- filesystem to access FTP hosts based on FUSE and cURL
Package: wnpp Severity: wishlist Owner: "Frank S. Thomas" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: curlftpfs Version : 0.8 Upstream Author : Robson Braga Araujo <[EMAIL PROTECTED]> * URL : http://curlftpfs.sourceforge.net * License : GPL Programming Lang: C Description : filesystem to access FTP hosts based on FUSE and cURL CurlFtpFS is a tool to mount FTP hosts as local directories. It connects to a FTP server and maps its directory structure to the local filesystem. . Based on FUSE (filesystem in userspace) and the cURL library, CurlFtpFS has some features that distinguish it over other FTP filesystems: * support for SSLv3 and TLSv1 * connecting through tunneling HTTP proxies * automatic reconnection if the server times out * conversion of absolute symlinks to point back into the FTP filesystem . Homepage: http://curlftpfs.sourceforge.net Preliminary packages for testing are at: http://frank.thomas-alfeld.de/download/debian/curlftpfs/ If someone is interested in sposoring this package please drop me a note. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEq8KTft6HNdxCZCkRAo8cAJ9jN1wFS1yIqUyInM2Z46kVvgZA8ACfcxlA GiIl4dSz3uK8VNmAeUThGl4= =eI08 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Le mer 5 juillet 2006 16:45, martin f krafft a écrit : > also sprach Wolfgang Lonien <[EMAIL PROTECTED]> [2006.07.05.1519 +0200]: > > Do we use greylisting on the @debian.org domain and especially on > > @lists.debian.org? > > > > If not, then we should probably try it - for my private stuff, that > > works just nice. The only things which still come through are spams > > which were sent over debian.org and such, which obviously use real > > mail servers. > > This has been brought up. Basically I don't think people were > opposed to it, but there was noone available to implement it. > > So if you really want it, log in to the hosts, copy the exim > configuration, implement greylisting, test it, then contact > [EMAIL PROTECTED] with patches. the patches exists, and I already did that. the setup is in production on alioth FWIW, thanks to raphael hertzog. basically, on alioth the greylisting is a selective greylist: we only use greylisting on hosts that are awkward (like listed on rbl's, reverse IP do not resolve, ...). greylist is inneficient if the remote host is a real smtp server, and real smtp server likely : - are not listed on rbl's - uses a correct reverse dns - ... I had a couple of posts on the subject on my blog[1]. FWIW I also have written a policy daemon, used with postgrey (or any other existant greylister) called whitelister[2], in order to implement the same thing on postfix. Configuration is pretty straightforward. [1] http://blog.madism.org/index.php/2006/03/25/79-debianorg-and-spam http://blog.madism.org/index.php/2006/03/28/80-debianorg-and-spam-2 http://blog.madism.org/index.php/2006/04/03/81-debianorg-and-spam-3-alioth [2] http://packages.qa.debian.org/w/whitelister.html http://backports.org/package.php?search=whitelister -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPj7XP1XLYq.pgp Description: PGP signature
Re: doc compilations: build-time or pre-built?
On Tue, Jul 04, 2006 at 09:04:48PM -0300, [EMAIL PROTECTED] wrote: > tony mancill <[EMAIL PROTECTED]> writes: > > > Steinar H. Gunderson wrote: > >> On Tue, Jul 04, 2006 at 07:25:16PM -0300, [EMAIL PROTECTED] wrote: > >>> 1) compile docs pre-build-time; or > >>> 2) compile docs in build-time > >> > >> Definitely the latter. We build stuff at build time for a reason, > >> architecture-specific or -independent alike. > > > > Is this the consensus/best-practice on this question? > > > > It seems like it would be quite taxing on the autobuilders to have to pull > > something like docbook (and its chain of dependencies) into a pbuilder just > > to recompile a manpage that doesn't change between architectures. > > > > I'm interested in this because I've typically done (2), but have recently > > started to think that (1) is more appropriate, particularly for packages > > where the documentation is a simple manpage. > > And It's exactly this the case in question, for me. The SGML template for manpage is there to help producing decent usable manpage for novice packager. I think it is useful only for intial packaging. I usually erase SGML file and update groff source of the manpage. NM guide states; 5.8 manpage.1.ex, manpage.sgml.ex Your program(s) should have a manual page. If they don't, each of these files is a template that you can fill out. Manual pages are normally written in nroff(1). The manpage.1.ex example is written in nroff, too. See the man(7) manual page for a brief description of how to edit such a file. If on the other hand you prefer writing SGML instead of nroff, you can use the manpage.sgml.ex template. If you do this, you have to: * install the docbook-to-man package * add docbook-to-man to the Build-Depends line in the control file * remove the comment from the docbook-to-man invocation in the * `build' rule of your rules file Note here of "normally written in nroff". So use of nroff source is better. Osamu PS: This section was not touched by me :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
Well, I think, we first should think about, what aim this CD or DVD should be. Which people we want to reach ? In the time, where are so many other live-cds, like Knoppix, kanotix, Grml, DSL and so on, it is very difficult to create an "all-in-wonder-"-stuff. So my thougts are these: People, who like KDE and GNOME want to have a fully graphic environment and a an easy system. So pack on it all the stuff, which is useful for people and what has graphical tools i.e. synaptics, openoffice, browsers and all the other graphical stuff, whithout those people cannot work. The other profile are people, who like the shell, and who are well known with it. So put all the important things, which make life easier upon this CD. X should be packed on it, too, and a small wm (I suggest fluxbox or XFCE) Then, there are the professionels, they just need all the tools. For these people there should be a multiboot-CD. I think of all the tools, they are in i.e. GRML. X should be there natuarally as some tools are really better to use in X. QTParted is such a tool. But thats not all. Thjese tools should fit about 250MB at all, so it would be nice to have the same tools for the most used architectures on this CD or DVD, too (AMD32, AMD64, PPC, Sparc etc.) I suppose, there will be other groups of people, but for those, the other live cds on the market should be good enough. Ah, I will not forget: Please, no Installer on these CDs !!! IMO people shall do a real installation, not a "rsync" like Knoppix does. Reason is: People, who make a real installation will understand their system, and those people will bring the Debian forward. Best regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2006.07.05.1733 +0200]:
> the patches exists, and I already did that. the setup is in production
> on alioth FWIW, thanks to raphael hertzog.
ah! have you submitted them to debian-admin?
> basically, on alioth the greylisting is a selective greylist: we only
> use greylisting on hosts that are awkward (like listed on rbl's,
> reverse IP do not resolve, ...).
>
> greylist is inneficient if the remote host is a real smtp server, and
> real smtp server likely :
> - are not listed on rbl's
> - uses a correct reverse dns
> - ...
FWIW, I do the same now, but I just use a regexp:
/(\-.+){4}$/ greylisting
/(\..+){4}$/ greylisting
/unknown/ greylisting
and these two:
http://sqlgrey.bouton.name/dyn_fqdn.regexp
http://sqlgrey.bouton.name/smtp_server.regexp
Now, about whitelister, would you consider backporting that to
sarge?
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
"we should have a volleyballocracy.
we elect a six-pack of presidents.
each one serves until they screw up,
at which point they rotate."
-- dennis miller
signature.asc
Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
On Jul 05, Wolfgang Lonien <[EMAIL PROTECTED]> wrote: > Do we use greylisting on the @debian.org domain and especially on > @lists.debian.org? No, we prefer to silently junk messages to mailing lists which appear to be spam. The @debian.org addreses have no filtering at all, so I implemented some myself, which so far has been working very well: [EMAIL PROTECTED]:~$cat .forward | /home/md/bin/I-do-not-use-this-address [EMAIL PROTECTED]:~$cat /home/md/bin/I-do-not-use-this-address #!/bin/sh echo "***" echo "** PLEASE MAIL ME AT [EMAIL PROTECTED] **" echo "***" echo "" echo "I never used my @debian.org address and I had to disable it because" echo "it delivers a huge quantity of spam and almost no legitimate mail." echo "If you want to send me mail you can use my usual [EMAIL PROTECTED] address." echo "" echo "If your address was forged by a spammer and you received this" echo "backscatter bounce, feel free to report it to [EMAIL PROTECTED]" exit 1 [EMAIL PROTECTED]:~$ -- ciao, Marco signature.asc Description: Digital signature
Re: greylisting on debian.org?
also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.07.05.1807 +0200]: > echo "If your address was forged by a spammer and you received this" > echo "backscatter bounce, feel free to report it to [EMAIL PROTECTED]" Very productive and cooperative. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system i've not lost my mind. it's backed up on tape somewhere. signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
On Wed, Jul 05, 2006, martin f krafft wrote: > Now, about whitelister, would you consider backporting that to > sarge? Isn't it already? whitelister: Installed: (none) Candidate: (none) Version Table: 0.8-2 0 -1 http://ftp.fr.debian.org unstable/main Packages 0.8-0bpo1 0 -1 http://ftp.de.debian.org sarge-backports/main Packages -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
also sprach Loïc Minier <[EMAIL PROTECTED]> [2006.07.05.1824 +0200]: > Isn't it already? Mhh *something* here is broken then. Sorry. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "common sense is the collection of prejudices acquired by age eighteen" -- albert einstein signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
(Is debian-devel the correct list for this?) On Wed, Jul 05, 2006 at 03:19:08PM +0200, Wolfgang Lonien wrote: > If not, then we should probably try it Can it be limited to suspected spam (e.g. mail with a high smtp-time spamassassin score)? Others may disagree, but I prefer the small amount of spam that does plague Debian's mailing lists to graylisting's obnoxious delays for legitimate mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#376588: ITP: cryptomount -- a utility for accessing encrypted filesystems
On 03/07/2006 Baruch Even wrote: > * Package name: cryptomount > Version : 1.0.1 > Upstream Author : rwpenney«AT»users«DOT»sourceforge«DOT»net > * URL : http://cryptmount.sourceforge.net/ > * License : GPLv2 or later > Programming Lang: C > Description : a utility for accessing encrypted filesystems > > cryptomount enables the user to simply create and mount an encrypted > device based on dm-crypt. It can handle either a raw device or a loop > mounted file as the base for dm-crypt. > > It offers the following advantage: > > * access to improved functionality in the kernel > * transparent support for filesystems stored on either raw disk > partitions or loopback files > * separate encryption of filesystem access keys, allowing access > passwords to be changed without re-encrypting the entire > filesystem > * storing multiple encrypted filesystems within a single disk > partition, using a designated subset of blocks for each > * rarely used filesystems do not need to be mounted at system > startup > * un-mounting of each filesystem is locked so that this can only be > performed by the user that mounted it, or the superuser > * encrypted filesystems compatible with cryptsetup > * encrypted access-keys are compatible with openssl hello Baruch, i like the idea of cryptomount, as it seems to have advantages over cryptsetup. for example cryptsetup does not support to store multiple filesystems on one disk out of the box. nevertheless most of cryptmount seems like a reinvention of cryptsetup, or cryptdisks. do you know the cryptsetup package from debian? we have a rather complex initscript called cryptdisks there, which implements lots of additional features for encrypted disks. additional, cryptsetup has support for LUKS devices, which cryptomount doesn't have. maybe you're interested in joining the maintainer group: Debian Cryptsetup Team <[EMAIL PROTECTED]> we could maintain cryptomount as an additional package or discuss the possibility to merge the advantages into cryptsetup/cryptdisks. David Härdeman currently tries to reimplement cryptdisks (the initscript) as a standalone wrapper for cryptsetup, written in c. the idea is to implement a system similar to mount, with a /etc/crypttab and similar syntax. maybe we can join our efforts to develop a good implementation for encrypted harddisks in debian :-) greetings jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[NACTT-1783399] Delivery reports about your e-mail (Auto response From Net Access Corporation)
Your Message entitled "Delivery reports about your e-mail" has been received. It is being tracked under Trouble Ticket ID : 1783399. Thank You for contacting Net Access Corporation -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
On Tue, May 30, 2006 at 09:51:18PM +0200, Daniel Baumann wrote: > [ crosspost to live, -devel and -edu; replies please to -devel ] > > Hi all, > > at the moment, we have two types of Live CD images: > > * the small one which contains only packages of standard priority, > * and three larger ones, each of which contains one of the common > desktop-environments on it (gnome, kde, xfce). > > Now, we would like to create a decent package selection which reflects, > as well as possible, the users' desires. There should be one package > selection for a 700MB CD-ROM, and one for a 4.5GB DVD-ROM. With the > current squashfs compression, the actual filesystem size is about 3 > times bigger than the packed one. This means that there can be quite a > few packages on it :) I'm open for your suggestions... Just checking: are you already aware of Debian From Scratch (DFS), which already does this? http://people.debian.org/~jgoerzen/dfs/ -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote: > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote: > > Additionally, it puzzles me how you think a maintainer will be able to > > accurately predict how much RAM a certain build is going to use. There > > are so many variables, that I think anything but 'this is the fastest > > way to build it on my machine' is going to be unfeasible. > > Let's say: > program X consist of a number of C files; it seems like compiling > every file takes around 24MB, In the maintainer's environment... yes, we're all running Debian Unstable to do our builds, but that's not enough to be sure that the build needs indeed so and so much RAM. For examle, you may be using ccache, or you may be doing stuff on an architecture which just happens to allocate 64 bits for a pointer instead of 32. Or the buildd may have just finished the compiler transition while you're a few days outdated on your local unstable chroot. Like I said, there's just too many variables. Also, I wouldn't be interested in figuring out how much RAM the build takes if I were to maintain a package like, say, X or so. You're not convincing me that you can indeed accurately predict for every compiled language out there how much RAM you're going to need during the build. Before you've proven that this is indeed possible, I don't think there's much point in this whole exercise; otherwise there *is* going to be a problem with you overloading build machines, and you *will* get bugs filed about that (from me, at the very least). -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc compilations: build-time or pre-built?
On Tue, Jul 04, 2006 at 04:45:21PM -0700, tony mancill wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Steinar H. Gunderson wrote: > > On Tue, Jul 04, 2006 at 07:25:16PM -0300, [EMAIL PROTECTED] wrote: > >> 1) compile docs pre-build-time; or > >> 2) compile docs in build-time > > > > Definitely the latter. We build stuff at build time for a reason, > > architecture-specific or -independent alike. > > Is this the consensus/best-practice on this question? > > It seems like it would be quite taxing on the autobuilders to have to pull > something like docbook (and its chain of dependencies) into a pbuilder just > to recompile a manpage that doesn't change between architectures. autobuilders don't use pbuilder :-) > I'm interested in this because I've typically done (2), but have recently > started to think that (1) is more appropriate, particularly for packages > where the documentation is a simple manpage. That's not the issue. If someone updates the code for a local change, then the sgml source file of the manpage, they want to be able to use "dpkg-buildpackage" to produce a working package with the included fixes. Pulling in docbook isn't really much of a problem; if many packages start doing it, we can easily preinstall that particular package in the buildd chroot (e.g., I do this for debhelper already on my buildd hosts). -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 signature.asc Description: Digital signature
Re: doc compilations: build-time or pre-built?
On Tue, Jul 04, 2006 at 09:18:20PM -0400, Roberto C. Sanchez wrote: > tony mancill wrote: > > > > It seems like it would be quite taxing on the autobuilders to have to pull > > something like docbook (and its chain of dependencies) into a pbuilder just > > to recompile a manpage that doesn't change between architectures. > > > AIUI, the autobuilders use sbuild and don't purge the installed packages > unless the admins do so manually. At least, that is what I have been > told on the subject. No, that's not true; packages that are installed at the beginning of a build run are removed at the end. The main difference between pbuilder and sbuild is the fact that sbuild uses an existing chroot on which it works (or even builds in your "main" system if you have no chroot configured), while pbuilder creates a clean chroot environment based on a tarball with the required files before beginning a build, which it removes entirely afterwards. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 signature.asc Description: Digital signature
Re: doc compilations: build-time or pre-built?
On Wed, Jul 05, 2006 at 09:45:16PM +0900, Junichi Uekawa wrote: > Another aspect is maintenance cost. Auto* tools and docbook toolchain, > and tex toolchain may break, which means packages no longer > build. This, I believe, shouldn't really be considered a reason not to > build-depend; because it will be the users who will suffer from a > broken package that doesn't really build. So do compilers. And libraries. And kernel-header packages. It's not much of an argument to avoid running arch-indep toolchains at package build time, IMO. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
On Wed, Jul 05, 2006 at 08:41:26PM +0200, Daniel Baumann wrote: > John Goerzen wrote: > > Just checking: are you already aware of Debian From Scratch (DFS), which > > already does this? http://people.debian.org/~jgoerzen/dfs/ > > yep. How do you expect your project to be different? I'm just interested in avoiding duplicate effort if possible. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re:%20debian flash group launched
Hello, > debian-flash aims to support the free/open source flash community in a > manner similar to debian-java does for Classpath/GCJ/Kaffe/etc. The > debian flash email list, alioth project, svn repository and wiki pages > are now setup, lets get to work! > free flash community: mainly http://osflash.org I'ts kind of strange to use word "free" to describe a project, which has the following info on their site: (http://osflash.org/free_does_not_mean_open_source): " The words “free” and “open-source” are sometimes (incorrectly) used interchangeably when in reality there is a big difference between the two. “Free” refers to whether or not the developer of a piece of software wants financial renumeration (ie., money) for it. If the developer (individual, company, etc.) does not want money or other form of financial compensation for their software, that software is said to be free. Nothing is implied as to whether the source code is “open” or “closed”. " They are using the word "free" (as beer) almost all of the time. It seems that noone has educated them on free (as in freedom) software, so maybe they should be announced as open-source project. Regards, Kamil Czy zostaną wprowadzone jednomandatowe okręgi wyborcze w wyborach samorządowych? Poprzyj nową ordynację wyborczą: http://klik.wp.pl/?adr=http%3A%2F%2Fwiadomosci.wp.pl%2Fwiadomosc.html%3Fkat%3D1342%26wid%3D8366222&sid=807 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
On Wed, Jul 05, 2006 at 08:58:41PM +0200, Daniel Baumann wrote: > John Goerzen wrote: > > How do you expect your project to be different? I'm just interested in > > avoiding duplicate effort if possible. > > wrt/ the package selection/lists, we're heading for a "desktop" one > (more or less what knoppix is; but with both gnome and kde on it), and > some smaller, different ones e.g. for sysadmins (more or less like grml). > > However, as I'm aware of your package list for DFS, I'm sure that there > will be not much doubled efforts. I'm just doing some ordering and > selection and I'll come up again with congrete suggestions in a few days.. Well, the thing about DFS is that dfsbuild is very flexible as far as package selection goes -- it has a cfg file where you list your preferred mirror and the debs you want to include. All those debs, plus their deps, will be included on the generated ISO. I've found it much easier to customize than Knoppix. Not trying to force you into any one solution or anything, but I'd hate for you to have to go to the effort to re-engineer a live CD build system if what's out there already would work for you. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
John Goerzen wrote: > Just checking: are you already aware of Debian From Scratch (DFS), which > already does this? http://people.debian.org/~jgoerzen/dfs/ yep. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
John Goerzen wrote: > How do you expect your project to be different? I'm just interested in > avoiding duplicate effort if possible. wrt/ the package selection/lists, we're heading for a "desktop" one (more or less what knoppix is; but with both gnome and kde on it), and some smaller, different ones e.g. for sysadmins (more or less like grml). However, as I'm aware of your package list for DFS, I'm sure that there will be not much doubled efforts. I'm just doing some ordering and selection and I'll come up again with congrete suggestions in a few days.. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
John Goerzen wrote: > Not trying to force you into any one solution or anything, but I'd hate > for you to have to go to the effort to re-engineer a live CD build > system if what's out there already would work for you. Sure.. I appreciate much that you share your experiences, I and Marco will definitely look at it, thanks for that. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Poor quality of multipath-tools
[John Goerzen] > I'm quite concerned about the poor quality of multipath-tools. This > is an absolutely vital application for many, required to even get a > machine to *boot*. Well, I do not even know what multipath _is_, nor why it is important. If that is representative, I suspect the people interested in multipath have some work to do to raise the awareness of the problem. This email is a very good start, but it seem to assume that everyone know what multipart is and why it is important. Is multipath machines as common as the ppc64 machines, or is the problem affecting a lot of users? > I am gravely concerned, though, about the lack of attention this > package is receiving. Does anyone intend to give it some TLC > anytime soon? Perhaps you could give it some tender loving care, and talk to the people maintaining the affected packages using IRC and email, and hopefully get them to realize why they should fix it in time for etch. :) I suspect you might wait in wane if you expect someone else to do it. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Poor quality of multipath-tools
On Wed, Jul 05, 2006 at 10:34:41PM +0200, Petter Reinholdtsen wrote: > Well, I do not even know what multipath _is_, nor why it is important. > If that is representative, I suspect the people interested in > multipath have some work to do to raise the awareness of the problem. Multipath is for when you have multiple paths from your machine to the same data -- say, redundant FC controllers. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Poor quality of multipath-tools
On Wed, Jul 05, 2006 at 10:34:41PM +0200, Petter Reinholdtsen wrote: > Well, I do not even know what multipath _is_, nor why it is important. > If that is representative, I suspect the people interested in > multipath have some work to do to raise the awareness of the problem. > > This email is a very good start, but it seem to assume that everyone > know what multipart is and why it is important. Is multipath machines > as common as the ppc64 machines, or is the problem affecting a lot of > users? Let me give a brief explanation of multipath. Let's say you want a bunch of disk space. A whole lot -- maybe terabytes worth. So you buy a SAN, which is a device that might have dozens or hundreds of disks in it. And you can hook multiple servers to this SAN. So you have a SAN controller, a bunch of disks in whatever RAID configurations you like hooked to it, a fibre channel switch, and each server hooked to the FC switch. Suddenly you have a lot of really important single points of failure that could take down not just one but many servers -- the FC switch, the SAN controller, the FC cables, etc. So the solution is to build two distinct I/O paths for any server to reach the disks. The SAN will have two controllers (each with access to disk enclosures). You'll have two FC switches, one controller cabled to each. And each server will have two FC links, one to each switch. Now, when you bring up this system, Linux will assign *two* /dev/sdx devices for each RAID LUN (basically looks like a disk). At any given time, exactly one will be readable and useful. That is, the disk can be probed on both controllers, but only one path will support I/O at any given time. Adding to the complexity, which one to use can vary while the system runs. For instance, if a SAN controller dies, everybody switches over to the backup path. The multipath-tools package is the userland support necessary to make all this work in a sane fashion. It uses the dm-multipath kernel module to do that. But it's got some problems: 1) It doesn't properly scan partition tables in multipath devices 2) It doesn't integrate with initramfs, so it's not possible to boot off a multipath device unless more work is done 3) Some other general bugs and issues BTW, multipath is often called MPIO (MultiPath I/O) > > I am gravely concerned, though, about the lack of attention this > > package is receiving. Does anyone intend to give it some TLC > > anytime soon? > > Perhaps you could give it some tender loving care, and talk to the > people maintaining the affected packages using IRC and email, and > hopefully get them to realize why they should fix it in time for > etch. :) That's what I intend to do. It's maintained by the LVM folks, though, and seems to be tied reasonably closely to that somehow. I'm not as familiar with all this as they are. But it seems like the package is not really being looked after, given its bug reports. I have already uploaded multipath-tools-initramfs to Incoming, which simply installs initramfs hooks and scripts to make it possible to boot from multipath. We are successfully using it with these scripts at our site. > I suspect you might wait in wane if you expect someone else to do > it. :) I understand. I'm just trying to figure out if there are interested parties out here to pitch in, if the LVM folks have plans for it, etc. I'm brand-new at this and wouldn't be at all surprised if someone else was more capable at it than I am. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTWCA Policy Section 7.6 (Build-Depends/Build-Depends-Indep)
Le mer 5 juillet 2006 23:28, Ola Lundqvist a écrit : > Hi > > If this is the case, then I think lintian should be updated to tell > people this. It is in fact lintian that have made me do this kind > of change for all the Arch: all packages that I maintain. afaict lintian does shout if you use cdbs or debhelper in B-D-I... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoYE5fF2sdC.pgp Description: PGP signature
Re: FTWCA Policy Section 7.6 (Build-Depends/Build-Depends-Indep)
Hi If this is the case, then I think lintian should be updated to tell people this. It is in fact lintian that have made me do this kind of change for all the Arch: all packages that I maintain. Please CC me as I'm not on this list anymore if you have comments on my post. Regards, // Ola On Thu, Jun 15, 2006 at 07:42:42PM +0200, Pierre Habouzit wrote: > Dear fellow developers, > > > Section 7.6[1] is an often misunderstood/forgotten part of the Policy > that explains how Build-Depends and Build-Depends-Indep are used to > build a package. Here is almost a copy&paste: > >The dependencies and conflicts they define must be satisfied >in order to invoke the targets in debian/rules, as follows: > >The Build-Depends and Build-Conflicts fields must be satisfied >when any of the following targets is invoked: > build, clean, binary, binary-arch, build-arch, > build-indep, binary-indep.· > >The Build-Depends-Indep and Build-Conflicts-Indep fields >must be satisfied when any of the following targets is invoked: > build, build-indep, binary and binary-indep. > > > In particular, it means that having cdbs, yada, dbs, dh-make-php and > other packaging helpers that are included from your debian/rules in > B-D-I is wrong, and that having debhelper in B-D-I is wrong as soon as > you use dh_clean in your clean target. > > Such issues generally trigger FTBFSes as soon as the source generates > one arch:any package. Though, as autobuilders do not rebuild source > packages that only build arch:all binary packages, a lot of them are > missed. In fact, it breaks pbuilder[2] and some other autobuilding > tools. > > > I've listed all the packages that list dbs, cdbs, dh-make-php, > debhelper, yada, dpatch or quilt in their Build-Depends-Indep, and ... > 2106 source packages are affected, which rules out any mass bug filing. > I've instead setup a dynamic (regenerated once a day) list of the > packages with this bug on people.d.o[3]. Also note that most of those > problems are already reported by lintian (at least for the usual patch > helpers, debhelper and cdbs). > > Greetings, > > > [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps > > [2] pbuilder asks you to install Build-Depends if you miss them, but do > not ask for B-D-I (and it *is* the right behaviour), and then > builds can fail. > > [3] http://people.debian.org/~madcoder/policy_7.6_violation.txt > > --· > ·O· Pierre Habouzit > ··O[EMAIL PROTECTED] > OOOhttp://www.madism.org -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 09:36:37AM +0100, Steve Kemp wrote: > On Tue, Jul 04, 2006 at 08:37:52PM -0400, LEE, Yui-wah (Clement) wrote: > > > I am building a package in which one of the binary has > > to have the setuid and setgid bits set. I wonder which > > one of the following two is the more appropriate method > > to use? > > It looks like you've got the answer to this already, but > it is worth considering whether the bit needs to be set > by default. > > Perhaps a debconf question like man-db, or cdrecord, could > allow the user to disable/enable this. Ugh, please don't. Seriously, as a regular user of those packages, I have no idea whether it's *really* a good idea for those to be setuid or not -- I vaguely know the risk/benefit from general knowledge, but assessing the risk intelligently? No way. I'd bet that 99% of installations have whatever the maintainer recommended setting (either recommended by default or perhaps the wording of the question). My personal preference would be for the maintainer to just take a stand, set it or not, and let people who actually know what's going on to use dpkg-statoverride to fix the problem to their satisfaction. (This actually also applies to man-db and cdrecord, as it happens, but there's a lot of inertia to overcome there). > I'd want to be extremely sure that the package had no > buggy code before installing it setuid/setgid. If you'd > like somebody to check over the code for you, or as a > second pair of eyes, then please consider asking the auditing > people: > > http://shellcode.org/mailman/listinfo/debian-audit This is good advice. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTWCA Policy Section 7.6 (Build-Depends/Build-Depends-Indep)
Hi On Wed, Jul 05, 2006 at 11:50:28PM +0200, Pierre Habouzit wrote: > Le mer 5 juillet 2006 23:28, Ola Lundqvist a écrit : > > Hi > > > > If this is the case, then I think lintian should be updated to tell > > people this. It is in fact lintian that have made me do this kind > > of change for all the Arch: all packages that I maintain. > > afaict lintian does shout if you use cdbs or debhelper in B-D-I... I noticed that it have been updated recently, thanks. Regards, // Ola > > -- > ·O· Pierre Habouzit > ··O[EMAIL PROTECTED] > OOOhttp://www.madism.org -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 654 65 KARLSTAD| | http://www.opal.dhs.org Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
MacBook graphics support
Hi, MacBook has a i945 integrated graphic device. To configure, I chose 'intelfb' (not imacfb driver, which seems only to garble the screen for me) driver for the kernel. For X, I managed to make a dual-screen setup, so that I can do presentation on projector and stuff. Here's my xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"i2c" Load"bitmap" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "XkbOptions""ctrl:nocaps" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents""true" Option "Device""/dev/psaux" Option "Protocol" "auto-dev" Option "HorizScrollDelta" "0" EndSection Section "Device" Identifier "Generic Video Card" Driver "i810" Screen 0 Option "MonitorLayout" "CRT,LFP" BusID "PCI:0:2:0" EndSection Section "Device" Identifier "Device1" Driver "i810" Screen 1 Option "MonitorLayout" "CRT,LFP" BusID "PCI:0:2:0" EndSection Section "Monitor" Identifier "Generic Monitor" Option "DPMS" HorizSync 28-64 VertRefresh 43-60 EndSection Section "Monitor" Identifier "External Monitor" Option "DPMS" HorizSync 28-64 VertRefresh 43-60 EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth24 SubSection "Display" Depth 1 Modes "1280x800" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1280x800" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1280x800" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1280x800" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1280x800" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1280x800" "1024x768" "800x600"
Re: doc compilations: build-time or pre-built?
Wouter Verhelst wrote: > > No, that's not true; packages that are installed at the beginning of a > build run are removed at the end. The main difference between pbuilder > and sbuild is the fact that sbuild uses an existing chroot on which it > works (or even builds in your "main" system if you have no chroot > configured), while pbuilder creates a clean chroot environment based on > a tarball with the required files before beginning a build, which it > removes entirely afterwards. > Thanks for the further clarification. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Bug#376993: ITP: tcpser -- emulate a Hayes compatible modem
Package: wnpp Severity: wishlist Owner: Peter Collingbourne <[EMAIL PROTECTED]> * Package name: tcpser Version : 1.0rc10 Upstream Author : Jim Brain <[EMAIL PROTECTED]> * URL : http://www.jbrain.com/pub/linux/serial * License : GPL Programming Lang: C Description : emulate a Hayes compatible modem TCPSER turns a PC serial port into an emulated Hayes compatible modem that uses TCP/IP for incoming and outgoing connections. It can be used to allow older applications and systems designed for modem use to operate on the Internet. TCPSER supports all standard Hayes commands, and understands extended and vendor proprietary commands (though it does not implement many of them). TCPSER can be used for both inbound and outbound connections. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
- Original Message - From: "John Goerzen" <[EMAIL PROTECTED]> To: Cc: ; Sent: Wednesday, July 05, 2006 7:42 PM Subject: Re: Package Selection for Debian Live On Tue, May 30, 2006 at 09:51:18PM +0200, Daniel Baumann wrote: [ crosspost to live, -devel and -edu; replies please to -devel ] Hi all, at the moment, we have two types of Live CD images: * the small one which contains only packages of standard priority, * and three larger ones, each of which contains one of the common desktop-environments on it (gnome, kde, xfce). And Window managers... Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
