Re: 37.5% boot time reduction in Lenny is possible (recipe)
On Sun, Jun 15, 2008 at 05:52:19PM +0200, Ulrik Haugen wrote: > As you can see readahead actually increase the boot time for me in > both cases so I uninstalled that package. I get 28 seconds with or without readahead (Thinkpad R50e, P4 1.6GHz, 512 RAM). Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote: > On Saturday 21 June 2008 11:38:07 Roberto C. Sánchez wrote: >> On Sat, Jun 21, 2008 at 07:34:59PM +0200, Holger Levsen wrote: >> > Hi, >> > >> > On Saturday 21 June 2008 15:52, Alexander Wirt wrote: >> > > I'm still not that sure if its a good idea to add a non-offical >> > > debian repo keyring into the archive... >> > >> > Nobody is forced to install it?! >> > >> > And AFAICS we regulary recommend backports.org to users, who need newer >> > software. So I think it should be in. >> >> But backports.org is still unofficial. If it were permitted, then what >> would happen when other unofficial repository maintainers want to >> package their repository keyrings? Will those be allowed or disallowed? > > Maybe a common, group maintained, debian-unofficial-keyring package? Err, no. I might want to trust the maintainers of backports.org to handle their keys well, but not necessarily others. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ODBC, local changes to config files, and policy
Steve Langasek <[EMAIL PROTECTED]> wrote: > Hi all, > However, this has never been enabled by default because the odbcinst > interface is very basic, with the result that on every upgrade any local > modifications to the config for this driver would be lost. The debconf > question is also not shown at the default priority in order to not clutter > the installation process. [...] > Short of rearchitecting odbcinst to require an exact config match before > update/removal (which would lose us the ability to manage driver config > updates in any case), can anyone suggest a way to enable this by default > while still complying with policy? Am I being more cautious than warranted > in this case where local user changes are concerned? I am in a situation which is somewhat (so not completely) similar, and I am thinking about a solution involving ucf. In you case, you would ship a copy of the configuration file in /usr/share, let the driver logic act on a temporary copy this file, and then install it using ucf. If there are no local changes, it will just be installed. If there are some, the user is asked a question they can probably understand (because the differences involve the driver and the changes they made themselves). You could even use ucf's --three-way option for merging changes. Regards, Frank -- Frank Küster Debian Developer (teTeX/TeXLive) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
inotify and symlinks in /etc/udev/rules.d/
I was approached by the maintainer of libmtp in Ubuntu regarding a fix for LP#197968 [1]. The bug reporter cites the file /etc/udev/rules.d/README (which does not exist in Debian), that says: The udev daemon watches this directory with inotify so that changes to these files are automatically picked up, for this reason they must be files and not symlinks to another location as in the case in Debian. Are there plans to enforce files under /etc/udev/rules.d/ being regular files in Debian, as they are in Ubuntu? [1] https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/197968 -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi, On Sat, Jun 21, 2008 at 01:38:07PM -0400, Roberto C. Sánchez wrote: > But backports.org is still unofficial. so what? Its unofficial, but still its of great use for the most Debian users. > If it were permitted, then what > would happen when other unofficial repository maintainers want to > package their repository keyrings? Will those be allowed or disallowed? In my humble opinion they should be allowed to be packaged as if they are normal packages. Don't get me wrong, but Debian is a distribution, so what we basically do is pack up things that are worth distributing and distribute them. This way Debian users can benefit from our work and ofcourse upstreams work. It would be the same for other keyrings. Its for the benefit of a larger audience of Debian users. Ofcourse this is not true for every keyring out there. So my approach isn't to let every keyring into the archive, but decide on case to case. Similar to whats beeing done with usual packages. Its already common for usual packages that they shouldn't be added if they don't provide benefit to *some* Debian users, like tools for a common goal which is already solved well and good by a lot of other tools in the archive. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Michael Banck <[EMAIL PROTECTED]> writes: > On Mon, Jun 16, 2008 at 11:03:10AM +0200, Goswin von Brederlow wrote: >> I don't really see this as a bug, certainly not as grave. The problem >> seems to be that lilo simply can't handle large images and the default >> ramdisk just has now hit that limit on amd64. > > So it's broken on amd64 for the stock Debian kernel, AIUI. > > Looks like a grave bug to me. With the default initramfs-tools.conf. So initramfs-tools has the grave bug. :) It should not be using "MODULES=most" on amd64 or reduce the list of modules. Certainly the floppy module does not have to be in the initrd. > Michael MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Mon, Jun 16, 2008 at 12:31:49AM -0500, William Pitcock wrote: >> Hi, >> >> I am wondering if it is a good idea to remove lilo entirely. At the >> moment, lilo has been pulled from testing, and the code is in a shape >> where a grave bug (bug #479607) is unlikely fixable without severe >> refactoring of the codebase. >> >> With grub being stable and grub2 approaching stability itself, do we >> really need lilo anymore? It's not even installed by default anymore, >> and the only systems I have that are still on lilo are installations of >> Debian I have had since Woody. > > grub doesn't work with root-on-LVM, or other similar cryptic > installations. There, your only option is lilo. grub2 does. Is that going to happen for lenny? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Arch-dependent Depends
Adam C Powell IV <[EMAIL PROTECTED]> writes: > Because hypre upstream doesn't make static libs, and I got tired of > making a new patch with every release, libhypre-dev is arch all without > static libs. However, it needs to depend on openmpi on some arches, and > lam4-dev on others. Using the same syntax as Build-Depends doesn't > work. > > Is there a way to do this, or do I need to make libhypre-dev arch any > and set the dep using substvars, even though its contents are > arch-independent? I notice that Policy section 7.1 provides for > arch-dependent Build-Deps, but there's nothing similar for Depends... There is no such syntax so you have to something else. As you already said you can make libhypre-dev arch any and you must. Further you have the choice of creating libhypre-dev-common containing the shared files. But only do that if libhypre-dev-common will be reasonably large. There is no point in the split for just 100K. ftp-master will veto if it is too small. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: Idea for improved diversions and alternatives handling
Hi, working on dpkg reminded me that I wanted to propose a better diversion and alternatives handling for debian packages. Currently they have to be manually added and removed in the maintainer scripts. This method is prone to errors and can easily leave diversions or alternatives behind. Instead I suggest creating two new control files detailing the diversions and alternatives a package should have. New control file: diversions A package wanting to divert files can list them in the control.tar.gz in a file named "diversions" using the following syntax: Empty lines and lines starting with # are comments. All other lines contain: [dpkg-divert option] ... file Dpkg will automatically add --package and -add or --remove before file. If --rename is used without --divert then --divert . is added as well. On install dpkg will add all listed diversions before unpacking. On removal dpkg will remove all listed diversions after deletion. On updates/downgrades dpkg will add new diversions before unpacking and remove no longer listed diversions after deletion. FIXME: what if a line changes? Only allow certain changes? I think that will cover nearly all diversions from packages. New control file: alternatives == A package containing an alternatives can list them in the control.tar.gz in a file named "alternatives" using the following syntax: Empty lines and lines starting with # are comments. All other lines contain (spaces must be quoted): genname symlink altern priority [--slave genname symlink altern] ... Dpkg will automatically add alternatives after configuration and remove them before removal. On updates all settings are updated if changed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unifont - consensus on dependencies
The Debian unifont package was orphaned in 2006, so I posted an Intent to Adopt it about a month ago. Before submitting the Debian package, I wanted to have complete Unicode 5.1 BMP coverage complete because I was so close to that goal. Now it is done and I can proceed with the package. Anthony Fok said that he could sponsor my Debian package upload when it is ready. A couple of days ago, I posted the latest realease of GNU Unifont on my website: http://unifoundry.com/unifont.html This has a glyph for every printable code point in the Unicode 5.1 Basic Multilingual Plane. It is the culmination of a ten-year effort begun by Roman Czyborra in 1998. I'm tidying up all the sources used to build the latest version (mainly updating man pages for the utilities that I wrote). After I get the sources online I will put together an update for the Debian unifont package. The updated package will have some new dependencies, and the Debian Policy Manual says that any package dependencies should be agreed upon by consensus on the debian-devel list before uploading .deb files. I have some questions about packaging, and hope to get a consensus opinion here: 1) The Debian Policy Manual says that all BDF fonts must be converted to PCF fonts with bdftopcf. The output format of GNU Unifont has always been BDF, using a Perl script that Roman Czyborra wrote. If I must convert that to PCF it will add a dependency (on bdftopcf) that doesn't exist today. Must I never install the BDF font, but add a dependency for bdftopcf and only install a gzipped PCF version? The preferred format of this font is the TrueType format (mentioned below); I don't even think that a PCF version should be used. 2) The Debian Policy Manual does not list a directory under /usr/share/fonts/X11 for TrueType fonts. I plan to have the font be in the "main/x11" Debian section, and so would like the TrueType version of the font installed under the X11 hierarchy. I would like to use a directory like /usr/share/fonts/X11/TrueType for the TrueType font. The "75dpi" and "100dpi" directories have historically contained bitmapped fonts, so I don't see another good alternative for TrueType. Gnome under Solaris uses /usr/lib/X11/fonts/TrueType (so there is a precedent). Any other similar directory will do but I think TrueType fonts are best placed in a directory named "TrueType". This would require an update to the Policy Manual. 3) I'm using scripts originally written by Luis Gonzalez Miranda to convert unifont.hex files into TrueType using FontForge. Therefore I do intend to add a dependency on FontForge. There's no way around that dependency to produce the TrueType version. The TrueType version handles Unicode combining characters as zero-width; the BDF version doesn't. The TrueType version is also scalable to any point size; the BDF version isn't. Thus the TrueType version is preferred over the BDF (or PCF) version. I've been using the TrueType version of the GNU Unifont produced in this way for several months and haven't observed any problems with it. Nobody downloading the TrueType font has replied with problems. Is there any software still in common use that will not handle TrueType fonts? Apparently Debian no longer has support for any software that only supports BDF fonts instead of PCF fonts, so it wouldn't be considered experimental to remove a BDF font. Any recommendations are welcome. Paul Hardy [EMAIL PROTECTED] GPG Fingerprint: E6E6E390 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unifont - consensus on dependencies
Quoth [EMAIL PROTECTED], on 2008-06-22 10:02:15 -0700: > If I must convert that to PCF it will add a dependency (on bdftopcf) > that doesn't exist today. Must I never install the BDF font, but > add a dependency for bdftopcf and only install a gzipped PCF > version? Are you confusing Depends and Build-Depends? I'm not sure why installing PCF versions of fonts would require a Depends link; can the conversion not be done at package build time? A user who wants to use the PCF versions of the fonts wouldn't need bdftopcf, only someone who wanted to modify some glyphs and then rebuild the PCF files, right? I would tend to assume that Build-Depends: xfonts-utils is reasonable if BDF is used as an intermediary format. I see 93 packages (according to [apt-rdepends -r -f Build-Depends xfonts-utils]) that currently have that link, mostly also packages of fonts. > The Debian Policy Manual does not list a directory under > /usr/share/fonts/X11 for TrueType fonts. I plan to have the font be > in the "main/x11" Debian section, and so would like the TrueType > version of the font installed under the X11 hierarchy. FWIW, various ttf-* packages that are also in the x11 section use the /usr/share/fonts/truetype directory for this; see for example ttf-bitstream-vera or ttf-freefont. > 3) I'm using scripts originally written by Luis Gonzalez Miranda to > convert unifont.hex files into TrueType using FontForge. Therefore I do > intend to add a dependency on FontForge. There's no way around that > dependency to produce the TrueType version. Again, an installed package Depends or only a Build-Depends? > Is there any software still in common use that will not handle TrueType > fonts? Apparently Debian no longer has support for any software that > only supports BDF fonts instead of PCF fonts, so it wouldn't be > considered experimental to remove a BDF font. Depending on how large the files are, I wonder whether a split package (from the same source package) with one package containing TrueType fonts and the other containing PCF fonts would be reasonable. Just a thought. ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Arch-dependent Depends
On Sun, 2008-06-22 at 18:31 +0200, Goswin von Brederlow wrote: > Adam C Powell IV <[EMAIL PROTECTED]> writes: > > > Because hypre upstream doesn't make static libs, and I got tired of > > making a new patch with every release, libhypre-dev is arch all without > > static libs. However, it needs to depend on openmpi on some arches, and > > lam4-dev on others. Using the same syntax as Build-Depends doesn't > > work. > > > > Is there a way to do this, or do I need to make libhypre-dev arch any > > and set the dep using substvars, even though its contents are > > arch-independent? I notice that Policy section 7.1 provides for > > arch-dependent Build-Deps, but there's nothing similar for Depends... > > There is no such syntax so you have to something else. > > As you already said you can make libhypre-dev arch any and you must. "Must" is a bit strong. There's nothing in Policy (8.4) stating this; please correct me if I'm wrong. And 8.3 uses "usually" regarding provision of a static library. The bug filed against the package suggests "libopenmpi-dev | lam4-dev". Will this be a problem? > Further you have the choice of creating libhypre-dev-common containing > the shared files. But only do that if libhypre-dev-common will be > reasonably large. There is no point in the split for just > 100K. ftp-master will veto if it is too small. The package is 141K, and it's *all* shared. That is, it consists of header files and .so symlinks. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: unifont - consensus on dependencies
On 22-Jun-08, 12:02 (CDT), [EMAIL PROTECTED] wrote: > The updated package will have some new dependencies, and the Debian > Policy Manual says that any package dependencies should be agreed upon > by consensus on the debian-devel list before uploading .deb files. No, it says that any "Pre-Depends" must be agreed upon. Pre-Depends is a very specific, very strong relationship which can cause problems with the install system and can mostly be avoided, which is why you are encouraged to discuss them here and look for alternatives. Normal Depends and such can be determined by the maintainer; if there's a problem, well, that's what the BTS is for. That said, you can still ask questions about your packaging choices here; that's one of the purposes of d-devel, after all. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Patrick Schoenfeld wrote: > In my humble opinion they should be allowed to be packaged as if they > are normal packages. Don't get me wrong, but Debian is a distribution, > so what we basically do is pack up things that are worth distributing > and distribute them. This way Debian users can benefit from our work and AFAIK, we do not distribute "things", we distribute *software*. Some packages are just composed of data though, but other packages depend on it. Some is just data that is very useful in the *Debian* project. This includes the keyring. Certainly, the backports.org keyring is useful to some people, *but* it is, 1. not free software 2. free software does not depend on it 3. not part of Debian's important data stuff If backports.org keyring get distributed, then I would argue it allows others, non-software data to be packaged as well. For example, some free anime movies, or the Gutenberg project packages. Debian is for *free software* (and some non-free) and stuff that related to Debian. It is not for backports.org, or Ubuntu, or some other stuff. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sunday 22 June 2008 12:08:30 Adam Majer wrote: > AFAIK, we do not distribute "things", we distribute *software*. Some > packages are just composed of data though, but other packages depend on > it. Some is just data that is very useful in the *Debian* project. This > includes the keyring. > > Certainly, the backports.org keyring is useful to some people, *but* it > is, > > 1. not free software Actually, how are debian-keyring and debian-archive-keyring free-software, anyway? Do I get source code for the all GPG keys they contain? The /usr/share/doc/debian-keyring/copyright even says "The keys in the keyrings don't fall under any copyright." Ops! Maybe there are other reasons, but let's not pretend we're keeping debian-backports-keyring out because it's not "free software". (Personally, I think all keyrings are fine.) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
RE: unifont - consensus on dependencies
Drake, I didn't specify...yes, all of these dependencies are only for Build-Depends. Is it best to add "Build-Depends: xfonts-utils" even if all a package needs from xfont-utils is bdftopcf? I am aware of the /usr/share/fonts/truetype directory. I've been running Sarge, and it is there. However, that is not under the X11 fonts tree. If I place a font in /usr/share/fonts/truetype, is it still legitimate to claim a font as being in section "main/x11"? If not, what is the preferred section? The Debian Policy Manual, Chapter 11, doesn't mention TrueType font policy. I could conceivably create multiple packages, for example: - the TrueType font (most people will probably just want this and nothing else); this could be called "unifont-ttf" - All sources to build the unifont.hex, TrueType, PCF, and BDF versions of the font; this package could be called "unifont" The TrueType font is larger than anything else: approximately 16 Megabytes uncompressed. That doesn't include an SBIT table, which I might add in the future. I might work on the outline encoding in the future to reduce that size. The TrueType font is 3 Mbytes compressed. The entire source tree is about 15 Megabytes uncompressed, and less than 3 Megabytes compressed. I could have the "unifont" package contain the pre-built TrueType font plus all sources. It takes about an hour plus 1 Gigabyte of virtual memory to build the TrueType version with FontForge. I could even forego the PCF font, which has never existed for the GNU Unifont, unless there is an application that still must use PCF. In that case there wouldn't be a Build-Depends for "bdftopcf". I put work into getting the combining characters working properly (with zero width) in the TrueType version. The BDF version doesn't have that capability, and so neither would a PCF version. Paul Hardy [EMAIL PROTECTED] GPG Key ID: E6E6E390 Original Message Subject: Re: unifont - consensus on dependencies From: Drake Wilson <[EMAIL PROTECTED]> Date: Sun, June 22, 2008 10:44 am To: debian-devel@lists.debian.org Quoth [EMAIL PROTECTED], on 2008-06-22 10:02:15 -0700: > If I must convert that to PCF it will add a dependency (on bdftopcf) > that doesn't exist today. Must I never install the BDF font, but > add a dependency for bdftopcf and only install a gzipped PCF > version? Are you confusing Depends and Build-Depends? I would tend to assume that Build-Depends: xfonts-utils is reasonable if BDF is used as an intermediary format. I see 93 packages (according to [apt-rdepends -r -f Build-Depends xfonts-utils]) that currently have that link, mostly also packages of fonts. > The Debian Policy Manual does not list a directory under > /usr/share/fonts/X11 for TrueType fonts. I plan to have the font be > in the "main/x11" Debian section, and so would like the TrueType > version of the font installed under the X11 hierarchy. FWIW, various ttf-* packages that are also in the x11 section use the /usr/share/fonts/truetype directory for this; see for example ttf-bitstream-vera or ttf-freefont. > 3) I'm using scripts originally written by Luis Gonzalez Miranda to > convert unifont.hex files into TrueType using FontForge. Therefore I do > intend to add a dependency on FontForge. There's no way around that > dependency to produce the TrueType version. Again, an installed package Depends or only a Build-Depends? > Is there any software still in common use that will not handle TrueType > fonts? Apparently Debian no longer has support for any software that > only supports BDF fonts instead of PCF fonts, so it wouldn't be > considered experimental to remove a BDF font. Depending on how large the files are, I wonder whether a split package (from the same source package) with one package containing TrueType fonts and the other containing PCF fonts would be reasonable. Just a thought. ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Idea for improved diversions and alternatives handling
On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote: > working on dpkg reminded me that I wanted to propose a better > diversion and alternatives handling for debian packages. Currently > they have to be manually added and removed in the maintainer > scripts. This method is prone to errors and can easily leave > diversions or alternatives behind. Instead I suggest creating two new > control files detailing the diversions and alternatives a package > should have. Declarative diversions are a much-needed enhancement to dpkg; there are cases one cannot deal with on upgrade without rm'ing one's own package files in the prerm in order to handle diversion changes, and that's just nasty. I'm happy to see people thinking about this. However, > New control file: diversions > > A package wanting to divert files can list them in the control.tar.gz > in a file named "diversions" using the following syntax: > Empty lines and lines starting with # are comments. All other lines > contain: > [dpkg-divert option] ... file > Dpkg will automatically add --package and -add or --remove > before file. If --rename is used without --divert then > --divert . is added as well. > On install dpkg will add all listed diversions before unpacking. > On removal dpkg will remove all listed diversions after deletion. > On updates/downgrades dpkg will add new diversions before unpacking > and remove no longer listed diversions after deletion. > FIXME: what if a line changes? Only allow certain changes? ... that's a rather large FIXME. Without fixing this, such an implementation of declarative diversions would be pointless churn. You should perhaps discuss this with Ian Jackson, there have already been rumblings from him about implementing declarative diversions. > New control file: alternatives > == The need for declarative alternatives is much less clear because alternatives can always be managed during a normal postinst/prerm stage, and there are definitely cases when update-alternatives from a maintainer script is still the only correct way to handle some alternatives. These two proposals should be handled separately. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Arch-dependent Depends
Adam C Powell IV <[EMAIL PROTECTED]> writes: > On Sun, 2008-06-22 at 18:31 +0200, Goswin von Brederlow wrote: >> Adam C Powell IV <[EMAIL PROTECTED]> writes: >> >> > Because hypre upstream doesn't make static libs, and I got tired of >> > making a new patch with every release, libhypre-dev is arch all without >> > static libs. However, it needs to depend on openmpi on some arches, and >> > lam4-dev on others. Using the same syntax as Build-Depends doesn't >> > work. >> > >> > Is there a way to do this, or do I need to make libhypre-dev arch any >> > and set the dep using substvars, even though its contents are >> > arch-independent? I notice that Policy section 7.1 provides for >> > arch-dependent Build-Deps, but there's nothing similar for Depends... >> >> There is no such syntax so you have to something else. >> >> As you already said you can make libhypre-dev arch any and you must. > > "Must" is a bit strong. There's nothing in Policy (8.4) stating this; > please correct me if I'm wrong. And 8.3 uses "usually" regarding > provision of a static library. I ment must as in the only way to get the right result. But I have to correct myself (below). > The bug filed against the package suggests "libopenmpi-dev | lam4-dev". > Will this be a problem? The an installed lam4-dev would suffice even on systems that need libopenmpi-dev. Doesn't work. >> Further you have the choice of creating libhypre-dev-common containing >> the shared files. But only do that if libhypre-dev-common will be >> reasonably large. There is no point in the split for just >> 100K. ftp-master will veto if it is too small. > > The package is 141K, and it's *all* shared. That is, it consists of > header files and .so symlinks. > > -Adam On a hunch I checked the Packages.gz files on my system and found the following example: Package: libgnomevfs2-dev Architecture: amd64 Source: gnome-vfs Version: 1:2.22.0-4 Depends: libgnomevfs2-0 (= 1:2.22.0-4), libgconf2-dev (>= 2.8.0-1), libgnutls-dev, libxml2-dev, libavahi-client-dev (>= 0.6) | hurd, libavahi-glib-dev (>= 0.6) | hurd, libdbus-1-dev | hurd, libselinux1-dev | not+linux-gnu So there actually is a provision for that and here is the magic: Package: type-handling Architecture: amd64 Version: 0.2.23 Provides: amd64, linux, linux-gnu, not+alpha, not+arm, not+armeb, not+bsd-darwin, not+bsd-freebsd, not+bsd-netbsd, not+bsd-openbsd, not+darwin, not+freebsd, not+gnu, not+gnu-hurd, not+gnu-kfreebsd, not+gnu-knetbsd, not+gnu-linux, not+gnueabi-linux, not+gnulp-linux, not+hppa, not+i386, not+i486, not+ia64, not+kfreebsd-gnu, not+knetbsd-gnu, not+linux-gnueabi, not+linux-gnulp, not+m32r, not+m68k, not+mips, not+mipsel, not+netbsd, not+openbsd, not+powerpc, not+powerpc64, not+ppc64, not+s390, not+s390x, not+sh3, not+sh3eb, not+sh4, not+sh4eb, not+solaris, not+sparc, not+sysv-solaris, x86-64-linux-gnu So you just add Depends: libopenmpi-dev | not+linux, lam4-dev | linux or whatever set you need. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Adam Majer <[EMAIL PROTECTED]> writes: > If backports.org keyring get distributed, then I would argue it allows > others, non-software data to be packaged as well. For example, some free > anime movies, or the Gutenberg project packages. > > Debian is for *free software* (and some non-free) and stuff that related > to Debian. It is not for backports.org, or Ubuntu, or some other stuff. > > - Adam I would argue that backports.org, while not official, is verry much related to Debian and having a secure path to the keyring is to great benefit to debian users. Such a keyring is also verry small. Three things you can't say about free anime movies or the Gutenberg project packages. MfG Goswin PS: I would prefer if apt-get could fetch and verify keyring updates directly from a repository though. Keyring packages are awfull for key rollovers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 2008-06-22 at 21:37 +0200, Goswin von Brederlow wrote: > PS: I would prefer if apt-get could fetch and verify keyring updates > directly from a repository though. Keyring packages are awfull for key > rollovers. As maintainer of the emdebian-archive-keyring package and one of the signatories of the key itself, I think that would be a good idea, Goswin. Probably worth a wishlist bug in apt although support will also need to be implemented in reprepro and dak (support that consists of merely making the key available as ASCII - reprepro already knows the keyid from conf/distributions, don't know about dak). -- Neil Williams <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unifont - consensus on dependencies
Quoth [EMAIL PROTECTED], on 2008-06-22 12:04:53 -0700: > Is it best to add "Build-Depends: xfonts-utils" even if all a package > needs from xfont-utils is bdftopcf? If you need bdftopcf to build, and bdftopcf is in xfonts-utils, I don't see another way to do it than Build-Depending on xfonts-utils unless you want to look for alternative tools or something. > I am aware of the /usr/share/fonts/truetype directory. I've been > running Sarge, and it is there. However, that is not under the X11 > fonts tree. If I place a font in /usr/share/fonts/truetype, is it still > legitimate to claim a font as being in section "main/x11"? If not, then there's a big pile of ttf-* packages in sid that have incorrect packaging. Since the Policy Manual is silent on this, I'd expect that to be the correct place to install TrueType fonts from a package in the x11 section, though I can't find authoritative documentation to that effect from a cursory search. > I could conceivably create multiple packages, for example: > > - the TrueType font (most people will probably just want this and > nothing else); this could be called "unifont-ttf" > > - All sources to build the unifont.hex, TrueType, PCF, and BDF > versions of the font; this package could be called "unifont" De facto practice in the archive suggests that the TrueType package be called "ttf-unifont", the PCF-only package be called "xfonts-unifont", and the source package be called "unifont" (noting that the source package and built package namespaces are somewhat orthogonal to each other). > I could have the "unifont" package contain the pre-built TrueType font > plus all sources. It takes about an hour plus 1 Gigabyte of virtual > memory to build the TrueType version with FontForge. Normally you don't provide sources in built packages unless there's a specific reason for it, as far as I know. Users can get sources using [apt-get source] or similar to retrieve the source packages. I'm not sure what effect a highly-intensive build process like that has on the autobuilder network; presumably that can be answered by someone more knowledgeable than me, but it's something you'd want to consider. > In that case there wouldn't be a Build-Depends for "bdftopcf". (Note that there is no way to Build-Depend on "bdftopcf", because that's not a package nor a Provides that I see anywhere. You once again mean "xfonts-utils", I suppose.) > I put work into getting the combining characters working properly > (with zero width) in the TrueType version. The BDF version doesn't > have that capability, and so neither would a PCF version. That would be useful information for the package descriptions; that doesn't preclude packaging both versions. I would tend to default to packaging both versions, assuming they come from the same source, unless there's a good reason not to package the PCF version. How large are the PCF files? (I didn't see that information in your last message; if it was there, I apologize.) Is there a significant difference in the _source_ size if you reduce it to only the information needed to build the TrueType fonts, or is most of the information shared? I would tend to imagine the latter for a package of this nature. > Paul Hardy > [EMAIL PROTECTED] > GPG Key ID: E6E6E390 ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 22 Jun 2008 12:54:09 -0600 Wesley J. Landaker wrote: [...] > Actually, how are debian-keyring and debian-archive-keyring free-software, > anyway? Do I get source code for the all GPG keys they contain? The most widely accepted definition of source code is the one found in the GNU GPL: the preferred form for making modifications to the work. If you modify a GPG public key, you obtain something that no longer corresponds to the original private key (obviously). You could end up with a different GPG public key or with something that is no longer a GPG public key. OK, that said, if you wanted to modify a public key (in order to obtain something else), what form would you use for making modifications? I think the preferred form would be the one in which the GPG public key is distributed by keyservers or some other equivalent form (which may be losslessly obtained from the distribution form). Hence, if I understand correctly, I think the Debian package does provide source. > The /usr/share/doc/debian-keyring/copyright even says "The keys in the > keyrings don't fall under any copyright." Ops! This could be true, to the extent that the key generation process does not involve any creative input. However, I've seen GPG key pairs generated in such a way that the ascii-armored public key embeds readable text provided by the user. In those cases, the readable text could be creative enough to be copyrighted by its author... Moreover, GPG public keys may be accompanied by photo-ids (small images that represent photo portraits of the key owner): those photo-ids, if present, may constitute other copyrighted material... Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpl4UmqnbD1W.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Robert Millan wrote: > On Sat, Jun 21, 2008 at 03:52:12PM +0200, Alexander Wirt wrote: >> I'm still not that sure if its a good idea to add a non-offical debian repo >> keyring into the archive... But I let the decision to the ftp-masters.. > > Well, currently a problem is the only way to get a trusted path to the bpo > repository is by fetching debian-backports-keyring from it, checking your > signature in its .dsc, etc. So this is what I'm trying to solve. Hmm, are there not 2 other ways documented on backports.org as you can see below? Cheers Luk -- If you are using etch and you want apt to verify the downloaded backports you can import backports.org archive’s key into apt: apt-get install debian-backports-keyring or gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C gpg --export | apt-key add - or wget -O - http://backports.org/debian/archive.key | apt-key add - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi, On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote: > Patrick Schoenfeld wrote: > > In my humble opinion they should be allowed to be packaged as if they > > are normal packages. Don't get me wrong, but Debian is a distribution, > > so what we basically do is pack up things that are worth distributing > > and distribute them. This way Debian users can benefit from our work and > > AFAIK, we do not distribute "things", we distribute *software*. Some to be honest: this definition is just plain wrong. Actually you name the arguments against your definition by yourself. You are right that this is the main goal of a distribution, but its ofcourse not limited to it. I wanted to keep my definition a bit more generic, because thats actually a case. > packages are just composed of data though, but other packages depend on > it. Some is just data that is very useful in the *Debian* project. This > includes the keyring. It also includes documentation packages and alike. Some aren't directly related to packages in the archive and so nothing depends on them. For example our project documentation, like debian-policy, developers-reference but also debian-faq etc. > Certainly, the backports.org keyring is useful to some people, *but* it is, > > 1. not free software Good point, while I need to nitpick a bit: Its about complying with our social contract and therefore the Debian Free Software Guidelines. Its all about the availability of source and yeah, this really seems to be somewhat problematic by the nature of a public-key pair. Probably it would make sense to clarify that a bit more, because that basically applies to a lot of things we already distribute. For example: Whats the source of a wave file or of a bitmap? I would argue that the source of a keypair is either the algorithm used to create it (combined with some "random" factors, but thats true for a bitmap as well) or the key pair itself. Probably not the most accurate definition, I know. > 2. free software does not depend on it Which is not a requirement for something to be in the archive. > 3. not part of Debian's important data stuff Which is also not a requirement for something to be in the archive. Consider debian-faq for example. I agree, that its useful for a greater majority of users, but disagree that this qualifies to be "important data stuff". > If backports.org keyring get distributed, then I would argue it allows > others, non-software data to be packaged as well. For example, some free > anime movies, or the Gutenberg project packages. Probably. If they are as useful to a greater majority of Debian users. If it doesn't explode archive size (because thats a concern that needs to be thought about, too), if source *can not* be available for technical reasons but all other rights are granted. Then it should still be something to think about shared like we do for the bpo keyring, now. > Debian is for *free software* (and some non-free) and stuff that related > to Debian. It is not for backports.org, or Ubuntu, or some other stuff. Hah, thats a good point. But you seem to forgot that backports.org *does* relate to Debian. Its a great enhancement for Debian stable users, a good workaround to the "we have old and sometimes buggy software in our stable release, but cannot fix it, because it does not qualify for SRU"-problem. Its beeing run by Debian developers. Quality aspects are therefore very similar. All these points are not true for Ubuntu, which you mentioned in the same sentence. Please also consider #4 of our social contract. It says that our priorities are our users _and_ free software. But yes, its questionable if a keypair really qualifies for main. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, Jun 22, 2008 at 09:37:46PM +0200, Goswin von Brederlow wrote: > PS: I would prefer if apt-get could fetch and verify keyring updates > directly from a repository though. Keyring packages are awfull for key > rollovers. Do you mean from a central repository, somewhat like a keyserver? :-) How would one check integrity then? Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 2008-06-22 at 22:39 +0200, Patrick Schoenfeld wrote: > On Sun, Jun 22, 2008 at 09:37:46PM +0200, Goswin von Brederlow wrote: > > PS: I would prefer if apt-get could fetch and verify keyring updates > > directly from a repository though. Keyring packages are awfull for key > > rollovers. > > Do you mean from a central repository, somewhat like a keyserver? :-) > How would one check integrity then? Precisely as you do with any key - signatures and gpg integrity checks when the key is imported into apt-key. The repository would simply provide the ASCII armoured GPG key file that would be signed by keys belonging to relevant people - in that respect, it's not that different to any package. The text file is useless without being imported into gpg so the integrity checks in gpg provide the integrity check. -- Neil Williams <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi Neil, On Sun, Jun 22, 2008 at 09:54:43PM +0100, Neil Williams wrote: > > Do you mean from a central repository, somewhat like a keyserver? :-) > > How would one check integrity then? > > Precisely as you do with any key - signatures and gpg integrity checks > when the key is imported into apt-key. well I understood the proposal to do it automatically so it wouldn't happen like I handle it currently. Now I have the possibility to explicit allow and deny certain keys in my setup. I can do this by checking mostly objective standpoints but also because I don't like the nose of the one providing the repository, so to say. Thats an important point, because technical aspects cannot decide weither you trust someone or not (except for the trust level on the key) So the key would needed to be signed by someone who *I* actually trust. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, Jun 22, 2008 at 10:34:15PM +0200, Luk Claes wrote: > Robert Millan wrote: > > On Sat, Jun 21, 2008 at 03:52:12PM +0200, Alexander Wirt wrote: > >> I'm still not that sure if its a good idea to add a non-offical debian repo > >> keyring into the archive... But I let the decision to the ftp-masters.. > > > > Well, currently a problem is the only way to get a trusted path to the bpo > > repository is by fetching debian-backports-keyring from it, checking your > > signature in its .dsc, etc. So this is what I'm trying to solve. > > Hmm, are there not 2 other ways documented on backports.org as you can > see below? > -- > If you are using etch and you want apt to verify the downloaded > backports you can import backports.org archive’s key into apt: > > apt-get install debian-backports-keyring > > or > > gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C > gpg --export | apt-key add - > > or > > wget -O - http://backports.org/debian/archive.key | apt-key add - > -- These examples just add the key to apt's keyring, but they don't provide any trusted path to it. One has to blindly believe that the key being downloaded by apt-get, gpg [1] or wget belongs to its owner. [1] In the gpg example, you could happen to have a trusted key in your database that provides a trusted path to bpo's key, but for the average user this is IMHO not an acceptable solution. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: unifont - consensus on dependencies
Drake, Okay, I'll plan on "ttf-unifont", "xfonts-unifont", and "unifont" package names. The "xfonts-unifont" package will contain a PCF font, but not a BDF font (since BDF fonts now seem forbidden according to the latest Policy Manual). The source package won't contain a pre-built TrueType font or a pre-built PCF font. I'll be replacing Sarge with the latest stable Etch release to build the final Debian packages. I think it is fitting to build a font package under a release named after Etch-a-Sketch. :-) I haven't built the PCF version yet; I've just been using the BDF version for testing (and the TrueType version for daily use). Since PCF is binary whereas BDF is ASCII, and since Debian PCF fonts are gzipped, I would expect a gzipped PCF font to be about the same size or a little smaller than a gzipped BDF font. The gzipped BDF font is about 1.3 Megabytes. The uncompressed BDF font is about 10 Megabytes. Yes, the vast bulk of the source package is shared to produce the BDF and TrueType fonts. There is just one 854 byte script to convert the unifont.hex formatted sources files into BDF, plus lines in a Makefile to invoke that script and then convert with "bdftopcf" -- not worth splitting the source. The Debian Policy Manual does need to add policy on TrueType fonts. TrueType and its derivatives (such as SIL's Graphite) are the foreseeable future direction in font technology, especially for complex scripts. Thanks for your insights. Paul Hardy [EMAIL PROTECTED] GPG Key ID: E6E6E390 Original Message Subject: Re: unifont - consensus on dependencies From: Drake Wilson <[EMAIL PROTECTED]> Date: Sun, June 22, 2008 1:21 pm To: debian-devel@lists.debian.org Cc: Anthony Fok <[EMAIL PROTECTED]> > I am aware of the /usr/share/fonts/truetype directory. I've been > running Sarge, and it is there. However, that is not under the X11 > fonts tree. If I place a font in /usr/share/fonts/truetype, is it still > legitimate to claim a font as being in section "main/x11"? If not, then there's a big pile of ttf-* packages in sid that have incorrect packaging. Since the Policy Manual is silent on this, I'd expect that to be the correct place to install TrueType fonts from a package in the x11 section, though I can't find authoritative documentation to that effect from a cursory search. De facto practice in the archive suggests that the TrueType package be called "ttf-unifont", the PCF-only package be called "xfonts-unifont", and the source package be called "unifont" (noting that the source package and built package namespaces are somewhat orthogonal to each other). > I could have the "unifont" package contain the pre-built TrueType font > plus all sources. It takes about an hour plus 1 Gigabyte of virtual > memory to build the TrueType version with FontForge. Normally you don't provide sources in built packages unless there's a specific reason for it, as far as I know. Users can get sources using [apt-get source] or similar to retrieve the source packages. I'm not sure what effect a highly-intensive build process like that has on the autobuilder network; presumably that can be answered by someone more knowledgeable than me, but it's something you'd want to consider. > I put work into getting the combining characters working properly > (with zero width) in the TrueType version. The BDF version doesn't > have that capability, and so neither would a PCF version. That would be useful information for the package descriptions; that doesn't preclude packaging both versions. I would tend to default to packaging both versions, assuming they come from the same source, unless there's a good reason not to package the PCF version. How large are the PCF files? (I didn't see that information in your last message; if it was there, I apologize.) Is there a significant difference in the _source_ size if you reduce it to only the information needed to build the TrueType fonts, or is most of the information shared? I would tend to imagine the latter for a package of this nature. ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[rt.debian.org #658] Re: NewInEtch / NewInLenny
Hello, On Tue, 2008-04-29 at 18:55 +0200, martin f krafft wrote: > There used to be http://wiki.debian.org/NewInEtch but it's gone > without a trace, and I can't figure out how to ask moin to tell me > where it went. Does anyone know? I have rebuilt the page, based on : http://web.archive.org/web/2007082/http://wiki.debian.org/NewInEtch The page NewInLenny was getting fairly close to it ;) Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487593: ITP: cil -- command line issue tracker
Package: wnpp Severity: wishlist Owner: Francois Marier <[EMAIL PROTECTED]> * Package name: cil Version : 0.2.0 Upstream Author : Andy Chilton <[EMAIL PROTECTED]> * URL : http://www.kapiti.geek.nz/software/cil.html * License : GPL Programming Lang: Perl Description : command line issue tracker 'cil' allows easy command-line creation of an issue tracker. It saves each issue locally and in plain text. Commands are given such that these issues can be added, edited and listed easily. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: ITP: hatools -- The halockrun program provides a simple way to implement locking in shell scripts.
Hi > | On Jun 18, Igshaan Mesias <[EMAIL PROTECTED]> wrote: > | > | > Description : The halockrun program provides a simple way to > | > implement locking in shell scripts. > | > | What does this offer over lockfile (procmail package) or dotlockfile > | (liblockfile1 package)? Aren't those used particularly for mailbox locking? The hatools package provides a wider application set for locking files. > Or even flock(1), which is part of util-linux. The major benefit halockrun has over these tools is that you can't have stale lock files with its implementation. It may seems as though a lot of the parameters for procmails lockfile are just different timeouts to properly handle stale lockfiles. Since the concept of hatimerun comes from the high-availabity context, this aspect is very important. The idea (and also the name) of halockrun as well as for hatimerun comes from the SUN Cluster high availability product, the implementation also takes reliability very serious. If you look at dotlockfile manpage, it SEEMS to implement it in a similar way, but i there's not many timeout parameters, but still seems to rely on the existence of files, while halockrun actually lock's the files by kernel functions. halockrun also works on NFS shares if lockd is running. The node which hosts the halockrun instance which holds the lock will also take care not to stale the lock (the kernel again, not the user space). without having done any deeper checks, ITUMO more robust that dotlockrun. To point out again I think the strength of halockrun is in its implementation is that the lock-cleanup is done by the kernel on process end (no matter how the process ended, it might have had a core-dump) and not by a user-space procedure. This makes stale locks impossible. It might appear that both (lockfile and dotlockfile) are aimd for short living locks the dotlockfile manpage does not mention anything how it handles stale locks, but the lockfile_create(3) manpage does. it says that it might consider a lockfile beeing stale after five minutes. i did not see how dotlockfile would allow a longer timeout, nor do i know if dotlockfile uses lockfile_touch() as described in the lockfile_create manpage. halockrun was implemented in need to prevent multiple cronjobs running concurrently. e.g. we had a cronjobs which runns ever 5 minutes, and _usually_ finishes in less then 5 minutes. if now, we had two jobs running, doing the same, and each was causing the other be become slower (more resources required). This again has decreased the chance that the jobs finish until the next instance will be started by cron. This was the first application of halockrun. i know some cases where this is even used for longer running cron-jobs. I unsure whether lockfile or dotlockfile are suitable tools to use for longer running processes. That might not complete within an hour. Further are people using changed start/stop scripts for server processes like apache or mysqld which are based on halockrun. They start the process with halockrun, and can check if it still running with halockrun -t. if they want to send a signal to that process they can also use halockrun -t to obtain the pid and send a signal (e.g. to stop it again). Again, this implementation is stale-aware and the lock remains valid as long as the process is running. IMHO, the applications of halockrun are also wider then those of the other two tools mentioned. Also, lockfile and dotlockfile do not have funtionalilty of hatimerun. hatimerun was initially required for the cron-job problem. So, If the job which runs every 5 minutes might take sometimes up to 10 minutes, there is definitely something wrong if it takes an hour. For that reason hatimerun was built to kill such processes. hatimerun has the abillity to send multiple signals, to first ask the process himself to quit, or later kill it forcefully. In an environment with countless cronjobs, where sometimes some job just hangs, the hatimerun can make an automatic recover possible. heh, The importance of hatimerun comes with the fact that halockrun's locks are not considered stale as long as the process is not running. Therefore a hanging process could block everything, so that a reliable timeout is a must. lockfile & dotlockfile also seem to implement the concept of timeouts, this might reduce the need for a similar mechanism. howerver, halockrun & hatimerun together make also sure the the process which belongs to a stale lockfile is killed (cleaned up) so that other resources occupied by this process are also freed. -- Regards Igshaan Mesias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Idea for improved diversions and alternatives handling
Steve Langasek <[EMAIL PROTECTED]> writes: >> FIXME: what if a line changes? Only allow certain changes? > > ... that's a rather large FIXME. Without fixing this, such an > implementation of declarative diversions would be pointless churn. > > You should perhaps discuss this with Ian Jackson, there have already been > rumblings from him about implementing declarative diversions. The problem is that changes in --rename will be insane. For example package A 1.0 has diverted /usr/bin/foo from package B with --rename and ships /usr/bin/foo itself. Now imagine package A 2.0 drops the --rename option. A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand A 2.0 expects /usr/bin/foo to come from B in preinst while the actual file is from A 1.0. So you have to move /usr/bin/foo to /usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename /usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in case of errors you have to revert it all back. Would anyone have a problem if dpkgs diversion handling would always use --rename? Because if we eliminate that from being an option the changes become easy. Also a diversion without --rename can not be cleanly removed by dpkg. The original file would be gone for all dpkg knows. Another reason to always use --rename by dpkg. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Policy question - deleting files belonging to another package
It seems to me that it ought to be against policy to use a maintainer script to delete files belonging to another non-conflicting non-replacing package, but I haven't found such a policy. Does anyone have the answer so I can give it to reportbug? TIA, --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Patrick Schoenfeld <[EMAIL PROTECTED]> writes: > Hi Neil, > > On Sun, Jun 22, 2008 at 09:54:43PM +0100, Neil Williams wrote: >> > Do you mean from a central repository, somewhat like a keyserver? :-) >> > How would one check integrity then? >> >> Precisely as you do with any key - signatures and gpg integrity checks >> when the key is imported into apt-key. > > well I understood the proposal to do it automatically so it wouldn't > happen like I handle it currently. Now I have the possibility to > explicit allow and deny certain keys in my setup. I can do this by > checking mostly objective standpoints but also because I don't like the > nose of the one providing the repository, so to say. > > Thats an important point, because technical aspects cannot decide > weither you trust someone or not (except for the trust level on the key) > So the key would needed to be signed by someone who *I* actually trust. > > Regards, > Patrick For example: Each repository puts its keyring into Release.keyring (next to Release and Release.gpg). The Release.keyring could be listed with checksum in Release so frontends know it is there and when it changes. apt-get/aptitude update would automatically fetch Release.keyring into /var/cache/apt/archives/partial/, pick out all changed keys and verify their signatures with the existing apt keyring and possibly some /usr/share/keyrings/*. Depending on what signatures are found I could envision the following next: - Key rollover: changes can be verified with apts own keyring (new key is signed by old key). Accept key without interaction. A simple notice should do fine. - Rollover failure but role-key verifiable: changes can not be verified by apts own keyring but by *-role-keys.gpg. Display the signatures and go interactive. Default should be to accept the key. - No or loose verification: neither apts nor the *-role-keys.gpg keyrings can verify the change. Display the signatures indicating where e.g. debian-keyring.gpg can verify one and go interactive. Default should be NOT to accept the key. Users should really verify the key manually. I'm not proposing that just any key should be silently accepted. Just that it should be automatically fetched and independent of debs. I already did run into a case where I could not update the keyring package because the Release signature required the new keyring package. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy question - deleting files belonging to another package
su, 2008-06-22 kello 16:07 -0700, Mike Bird kirjoitti: > It seems to me that it ought to be against policy to use a > maintainer script to delete files belonging to another > non-conflicting non-replacing package, but I haven't found > such a policy. > > Does anyone have the answer so I can give it to reportbug? I don't think we have an explicit policy rule that prevents packages from faking e-mail to be from "Mike Bird", either. Deleting files belonging to other packages is so obviously wrong, it applies under the "use common sense or we'll LART you" rule. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy question - deleting files belonging to another package
Mike Bird wrote: > It seems to me that it ought to be against policy to use a > maintainer script to delete files belonging to another > non-conflicting non-replacing package, but I haven't found > such a policy. > > Does anyone have the answer so I can give it to reportbug? If I understood your question correctly, I guess you're looking for policy 7.6.1 [0]. Cheers [0]http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1 -- Leo "costela" Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Adam Majer wrote: Certainly, the backports.org keyring is useful to some people, *but* it is, 1. not free software Presumably the following packages would never have made it into Debian if a public key didn't comply with the DFSG. debian-archive-keyring - GnuPG archive keys of the Debian archive debian-edu-archive-keyring - GnuPG archive keys of the Debian Edu archive debian-keyring - GnuPG (and obsolete PGP) keys of Debian Developers debian-maintainers - GPG keys of Debian maintainers emdebian-archive-keyring - GnuPG archive keys for the emdebian repository Having said that, having one entire package for one key file seems like overkill to me; is there not any other way of securely distributing the key? Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Luk Claes wrote: apt-get install debian-backports-keyring or gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C gpg --export | apt-key add - This involves 3 separate commands, and modifies files under /root/.gnupg/ at the same time. Seems overly complicated, especially for non-technical people. Would it be possible to simplify this? or wget -O - http://backports.org/debian/archive.key | apt-key add - Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
