Re: iproute transitional package going away...
On Wed, Sep 25, 2013 at 05:02:58PM +0200, Andreas Henriksson wrote: > Hello! > > I intend to drop the iproute transitional packages in Jessie+1. > > This message is here to give all 68 packages depending/recommending/suggesting > the old iproute package time to simply update their dependencies to use > the new iproute2 package name. Thanks for the heads up. >ifupdown-extra Fixed in GIT, version 0.23 containing this fix hast just been uploaded >snort Fixed in GIT. I'm preparing a version with a debconf review and debconf translation updates, the fix will go in with that version (this week probably) Regards Javier signature.asc Description: Digital signature
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 12:11:40AM +0100, Adam Borowski wrote: > > > > Package: netselect-apt > > > > Description: speed tester for choosing a fast Debian mirror > > Does it actually work for anyone? I just tried it from machines at four > different locations on 3½ ISPs; two with IPv6+IPv4, two IPv4 only; two with > no NAT; all with full UDP/ICMP connectivity -- getting an empty result every > single time (#23, #582976). From my experience, netselect-apt failed to work if UDP probes are blocked. Since version 0.3.ds1-15 in unstable netselect-apt uses ICMP probes only as most Debian mirrors do not have full UDP connectivity (i.e. UDP probes are blocked). > > netselect-apt somehow requires root, I got none on a machine outside of > northern Poland so I can't test if it's something caused by a specific > mirror. netselect-apt requires root because netselect requires it for its UDP (or ICMP) probes. It is documented in its README.Debian file. If you have not installed netselect setuid root this it what will happen: $ netselect-apt sid Sorry, you need to be root to run /usr/bin/netselect-apt since the netselect binary we will use (/usr/bin/netselect) is not setuid. Regards Javier signature.asc Description: Digital signature
Re: Introducing the "Debian's Automated Code Analysis" (DACA) project
On Thu, Dec 16, 2010 at 12:00:21PM -0600, Raphael Geissert wrote: > = What is there for everyone? = > > At the moment there are only partial reports from two tools, but the list of > tools to be evaluated and possibly included goes over twenty. I would be glad if the tools included some security auditing tools such as: + Available as Debian packages - RATS: security auditing utility for C, C++, PHP, Perl, and Python code - Flawfinder: securty flaw search tool for C/C++ source code - Split: a tool for statically checking C programs for bugs - Jlint: Tool to check Java code for bugs, inconsistencies and synchronization problems + There are some other static security analysis currently not available in Debian, such as: - FindBugs: a tool for static analysis of Java code http://findbugs.sourceforge.net/ - JCSC: Java source code checker - http://jcsc.sourceforge.net/ - PMD: Tool to review Java code for bugs - http://pmd.sourceforge.net/ As Debian is getting more java code in now it would be worth it to have some Jave tools in the toolbox too. Just my 2cents. Regards Javier signature.asc Description: Digital signature
Re: Bug#597202: ITP: kstars-data-extra-tycho2 -- Contains the Tycho2 star catalog for centralized install, avoiding per-user install
On Sun, Sep 19, 2010 at 05:24:38PM +0100, Noel David Torres Taño wrote: > > > * License : GPL > > > > This license is *not* the license the Tycho2 catalog was distributed > > with 10 years ago (8th february 2000). It might be worth clarifying with > > Erik Høg, original author of the catalog from the Niels Bohr Institute > > under which license this catalog can be distribued. > > > > Please note that other catalogues distributed by international > > organisations (ESA, NASA) have had a 'please do not modify these files' > > strings attached and have thus fallen into non-free (see gliese and > > yale catalogues). > > That is the license of the file I'm distributing. Should I contact Simha and > Harris to see if THEY are violating the Tycho-2 catalog license? Please confirm with them that this *derived* data from the Tycho-2 can be indeed GPL-licensed. I would be very surprised if this is the case (I've had contact with some producers of star data catalogues in the past) but if it is fine. We packaged the Gliese and Yale packages as they are right now (in non-free and including the original sources with data files for starplot generated on install) as the upstream authors would not allow for modification of the star data catalogs. Throughout the years maintainers (both Debian and upstream's) have learnt of this "the hard way", i.e. bugs in celestia: #174456, stellarium #198495, kstars #198499, xephem 225002 and stars: #246047, gstar #246048, openuniverse #246049. Some upstream developers (kstars') were very helpful in the past. When we took this issue up with them, the kstars team (Jason Harris mainly) digged up contacts with the catalog providers. This is what someone from CDS replied (when asked about Hipparcos and SAO catalogs): : Catalogues available at CDS contain scientific data distributed : for free, for a scientific usage. Only the expenses related to : copying and mailing are charged if relevant. : Companies including such data in their commercial products cannot : charge their clients for the data. Furthermore, users must be informed : of the origin of the data: this means an explicit reference to the service : provided by the CDS and also to the original author(s) of each catalogue. : So this initially made the catalogs used by kstars non-free, they then contacted people at ESA which confirmed that Hipparcos was in the public-domain: : Hello Jason, : : The Hipparcos data is in the public domain and may be used : by anyone. We do request however that use of the catalogue data : is acknowledged. Something similar to "This application : makes use of the Hipparcos and Tycho catalogues (ESA, 1997)" : could be appropriate, and a link to the ESA Hipparcos web pages : (http://sci.esa.int/hipparcos) would also be appreciated. : : Can I enquire what you would like to use the catalogue for? : : Regards, : Karen O'Flaherty As a consequence kstars switch to the Hypparcos catalog (and many other astronomy packages too). Since the main author of the Tycho2 catalog is Erik Høg I suggest asking the kstars developed if they have contacted him regarding the catalog and, if not, get clarification from him > > Actually, I believe that the fact that the catalog is not provided *within* > > the kstars program is certainly because it is not considered free. > > I believe instead that the fact that the catalog is not provided *within* the (...) > own set of predefined stars up to the visual magnitude. Datafile authors > (which are, by the way, two of the same authors of the program itself) say > the datafile is GPL, so I can not think they decided not to include it > because of it being not free. Please, take this up with upstream for clarification because in the past other upstreams have made the same assumptions which turned out not to be valid with other catalogs (i.e. yale). It would be best to seek clarification from the author. I don't see GPL anywhere at http://www.astro.ku.dk/~erik/Tycho-2/, in fact, I don't see any reference to licenses at all so I'm quite sure the original author do not stamped a GPL license to the data. Since upstream developers (kstars) where very open to discussion and where really helpful when we brought to them this issue 7 years ago, they probably have researched this issue, but a statement from the original author of the catalog (to be used in debian/copyright) would be good to have. Regards Javier signature.asc Description: Digital signature
Re: Bug#597202: ITP: kstars-data-extra-tycho2 -- Contains the Tycho2 star catalog for centralized install, avoiding per-user install
Hi, First of all, please first note there is an informal policy for Stars data catalogues which is available in the 'stardata-common' package (more info at http://alioth.debian.org/projects/stardata-common/). We already provide some star data catalogues (Gliese and Yale which are both non-free) in Debian and we should strive to follow the same rules for any star data catalogues we provide. > Actually kstars offer each user to download some data, from the net, which > causes bandwith and disk waste (See #596007). I will package one of those > datafiles (one of the catalogs) to avoid that, and I want to package the > remaining afterwards. If you are packaging datfile it would be best if they follow the policy above so that other astronomy packages (stellarium, stardata, etc.) can use them. This means using the original (unmodified) files and providing scripts/tools (which probably the Kstars team has developed) to convert them into files usable for other software. > * Package name: kstars-data-extra-tycho2 > Version : 1.1r1 > Upstream Author : Akarsh Simha, Jason Harris The 'upstream authors' of the Tychos2 catalog are not some KDE developers (with all my respect to their work). Please see http://www.astro.ku.dk/~erik/Tycho-2/ From http://www.astro.ku.dk/~erik/Tycho-2/Tenyears.eml the autors are E. Høg, C. Fabricius, V.V. Makarov, S. Urban, T. Corbin, G. Wycoff, U. Bastian, P. Schwekendiek, and A. Wicenec. > * URL : > http://edu.kde.org/kstars/downloads/tycho2_mag_12.5-1.1.tar.bz2 The URL for the upstream catalog is not correct. This is the URL for the files distributed by KDE which are maybe *not* the original files. > * License : GPL This license is *not* the license the Tycho2 catalog was distributed with 10 years ago (8th february 2000). It might be worth clarifying with Erik Høg, original author of the catalog from the Niels Bohr Institute under which license this catalog can be distribued. Please note that other catalogues distributed by international organisations (ESA, NASA) have had a 'please do not modify these files' strings attached and have thus fallen into non-free (see gliese and yale catalogues). > Programming Lang: N/A > Description : Contains the Tycho2 star catalog for centralized install, > avoiding per-user install If the package provides the Tycho2 star data catalogue it should provide the *original* catalogue as available in http://tdc-www.harvard.edu/catalogs/tycho2.html and not a "pre-cooked" file for kstars. If it provides a pre-cooked file for kstars then it should note it. As for the license, I do not agree with the license you set up for this package. If you review http://cdsarc.u-strasbg.fr/cgi-bin/myqcat3?I/259/, the Tychos star data catalogue files are certainly *not* GPL. There is no mention to the license the catalog can be used with in the README file, and certainly there is no mention to the GPL. As such, it can only be considered 'non-free'. Actually, I believe that the fact that the catalog is not provided *within* the kstars program is certainly because it is not considered free. Please review the licensing status of the original data files before you make an upload of this package to Debian. If you are interested in astronomy packages, I encourage you to subscribe to the stardata-common-devel mailing list to seek assistance on how to (properly) package star data catalogues in Debian. Regards Javier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100919120303.gb9...@javifsp.no-ip.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Sun, May 10, 2009 at 06:14:34PM -0400, Travis Crump wrote: > If the documentation is something designed to be viewed in a web browser > and the user has broadband, it is arguably easier to find it on the web. > Even knowing precisely where it is[/usr/share/doc/aptitude is it -doc > or just aptitude, oops I already found it online google aptitude doc > first result], it is still arguably faster to find it online and once > you bookmark it is virtually identical. You are assuming all our user-base has high-speed broadband Internet access which is certainly not the case. High speed Internet access is still a luxury in some countries of the world. Regards Javier signature.asc Description: Digital signature
Re: Override changes standard -> optional
On Fri, Jan 02, 2009 at 01:02:55PM -0800, Russ Allbery wrote: > > ethtool doesn't seem particularly related to tcpdump? > > Oh, sorry, I confused it with a different program. Hm, ethtool I'd put > into the borderline category -- one argument in its favor is that you may > need it in order to fix your networking so that you can get somewhere to > install more packages. Actually, having installed my share of network systems (both hosts and switches) I've found that most issues are related to ethernet misconfiguration (forced configuration in switch, auto in network card or viceversa) and 'ethtool' would be really useful to debug these issues. Regards Javier signature.asc Description: Digital signature
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
On Tue, Aug 12, 2008 at 03:52:14PM -0700, John H. Robinson, IV wrote: > As mktemp and tempfile are both essential[2], they can be relied upon. Essential in Debian, not in other systems. > Is there any scenario where using mktemp or tempfile fails, and sing > $TMPDIR succeeds? Scripts that are written with portability to other OSes in mind (or have been originally written for these OSes and are now used in Linux). Some might even try to use mktemp/tempfile and fallback to $TMPDIR (or just plain /tmp) if unavailable. These scripts show up as false positives when looking for tmp race conditions using simple tools (such as 'grep' :) Regards Javier signature.asc Description: Digital signature
Re: What should be on a rescue CD ? (was Re: Debian Live Lenny Beta1)
On Fri, Aug 29, 2008 at 12:58:42AM +0200, Daniel Baumann wrote: > Ian Jackson wrote: > > The current list (which I haven't added even my suggestions to yet) > > is at > > http://git.debian.net/?p=live-helper.git;a=blob;f=lists/rescue > > (I am told - I can't check right now because alioth seems to be down) > > for the records: git.debian.net is not alioth, and it (g.d.n) is not > down, so feel free to have a look at it. I did, and that url it gives out a '403 Forbidden - No such project' In any case, it would be worthwhile to see what other people have included in a Forensic live-cd, one that comes to mind is FIRE: http://fire.dmzs.com/ (slightly out of date, but its lists of pacakges at at http://fire.dmzs.com/?section=tools and forensics packages at http://fire.dmzs.com/?section=tools&subsection=F might be handy) or HELIX (http://www.e-fense.com/helix/, list of tools included at http://www.e-fense.com/helix/contents.php) IMHO, the basic tools in any forensics live-cd would be: recover (only for ext2), tct, sleuthkit and its frontend autopsy. Regards Javier signature.asc Description: Digital signature
Re: Bug#474602: ITP: nikto -- web server security scanner
On Sun, Apr 06, 2008 at 07:29:09PM +0200, Vincent Bernat wrote: > * Package name: nikto Nikto was already packaged for Debian (etch provided version 1.35). It was removed from Debian (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434392). Please, include the debian information (including changelog history) from the old Debian packages and use that as a starting point. I'm not sure how many of the patches introduced in the Debian package are current, but it would be best if you evolved from that instead of making new packages from scratch. Regards Javier signature.asc Description: Digital signature
Re: [RFC] Changing priority of selinux back to optional
On Wed, Feb 06, 2008 at 12:27:45PM +0100, maximilian attems wrote: > > > The priority of selinux packages was changed from optional to standard, > > fairly shortly before the release of Etch. > > > > I propose to revert that change before Lenny. The basic reason is that > > the selinux packages have basically been unmaintained since the release > > of Etch. > > I'd like to work on SELinux packages and bugs. Good, I'll let you play with this one: cron: http://bugs.debian.org/333837 I asked for help in the bug report, and still need someone to do the grunt work in breaking off the cron tasks from cron in a clean way (the problem being that those are conffiles that have to move from one package to another one). I actually developed cron-standard [1] but my energy has been devoted in other Debian-related tasks which seem to be higher priority requirements to our users. Regards Javier [1] http://lists.debian.org/debian-devel/2005/03/msg00384.html signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:58:24PM -0600, Raphael Geissert wrote: >clips-common Fixed now, I'm going to upload a new version (6.24-2) making it arch: all Javier signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
On Mon, Aug 27, 2007 at 12:04:51PM +0200, A Mennucc wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stefano Zacchiroli ha scritto: > > In an attempt to prevent drift to a well-known counter argument: > > DEBIAN/md5sums (used by debsums) are *not* intended as a mean to counter > > security attacks, since they can be easily altered. > > If md5sums become part of the policy, then this brings me to an old idea > of mine. (... idea related to forensic use of md5sums ...) This we could do already. We don't need md5sums in files, a script could just generate this for a stable release and publish that file (signed). Even better, that file could ship whatever hashes we believed were "good enough" for forensics (MD5? SHA-1? SHA-256?). I think I already pointed people interested in this to #268658. If ftpmasters where given the tools to implement this seamlessly then you could have aside tools that downloaded that file from the FTP site, and locally checked the md5sums. Regards Javier PS: BTW, if you do this with a searchable web interface you also have to ensure that you have a trust path to it, that means using SSL with a "good" certificate.. signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
On Fri, Aug 24, 2007 at 03:16:28PM +0200, Goswin von Brederlow wrote: > I fail to see any reason to HAVE a md5sums file. It looks like you have not read all the thread, other's have made some good points as to why it's good. Just in case I'm going to voice my opinion here again and see if I can convicen you (and other's listening) :) > The md5sum file in / var/lib/dpkg/info/ (or wherever you put it on the > users system) is not protected and therefore useless as a security > device. Fetching a md5sum file you can trust means fetching (at least > partially) the deb and then you can just compare the files one by one. "Useless sercurity device" is an overstatemente here. One of security's fundamental corner stones is 'integrity'. System integrity can be lost due to: - a person without a malicious intent accidentally or on purpose changes the system, e.g. a novice admin that modified a script at /usr/bin installed by a package or redirected his stderr to a file he shouldn't have after mistyping a command. - uncontrolled accidents or disasters, e.g. hard disk / memory corruption in a system which makes it incorrectly write to disk a binary unpackaged from a package. - somebody with malicious intent, e.g. an unautorised user that elevates privileges and installs a trojan I do agree that the last case is probably only handled well with a signed hash database in a read only media (the Debian Security Manual gives some examples) but the two others can be served quite well just by including md5sum files in packages. So, md5sums *do* serve a security purpose even if they are not able to stop a determined cracker from violating the system's integrity in a way we cannot detect it. FWIW, IMHO the forst type of integrity losses are more common than the last. > Also the md5sum file can be generated at install time if wanted. The > cost of computing the md5sum on the fly is quite insignificant on most > systems. Some computing systems cannot incur the cost (please read the thread). What do you think is (globally) more CPU-concious: compute once (in the buildds) and put in a file for everybody to use or compute once in every system the package is installed on. There might be hundreds of build systems (including the developer's Debian systems where packages are built) but there are thousands of users. It is quite obvious to me that we are saving energy if we just distribute them instead of forcing our end-users to recompute them. Energy is a scarse resources, save the planet! :) > So why waste all the mirror space and bandwith for something rather > useless? "Waste all" seems like a very bad phrase. The impact in our archive of mandating md5sums or sha1sums in packages when most *already* do that is neligible. From http://blog.orebokech.com/2007/08/debian-packages-without-md5sums.html: "Random testing of my local Debian mirror shows that 644 binary packages out of 20774 (3.1%) are missing the DEBIAN/md5sums control file." If you want to go through the "space and bandwidth" road please provide some data to back it up. How much space do we munge if we *add* md5sums to packages that don't have that information already? Also: How much space do we save if we *remove* md5sums from all packages? Just my 2c, Javier signature.asc Description: Digital signature
Re: proposed release goal: DEBIAN/md5sums for all packages
On Fri, Aug 17, 2007 at 04:47:38PM -0700, Russ Allbery wrote: > Peter Samuelson <[EMAIL PROTECTED]> writes: > > > I'd opt for dpkg generating the checksums upon _extracting_ the .deb > > file. We already claim that the md5sums file isn't supposed to be any > > kind of security thing. Why bother to ship it? It is redundant > > information which can easily be regenerated on the user's system. > > While it's not the be-all and end-all of security, other OS vendors (Sun > in particular) have found it useful to make available a central database > of MD5 checksums of known-good versions of various binaries. This has > proven invaluable in not a few breakins and compromises when doing > forensics. Since we have such a database essentially for free now in the > form of the md5sums control files, I'd rather not take an approach that > gets rid of it, even if it isn't a horribly effective security measure. Actually, we should have this information as part of the information for a Release (as asked for in #268658), alongside the Contents and Packages files. Local Md5sums can be useful to detect hardware breakage but not so much for forensic analysis (unless taken from an external trusted sourced, not the system which was compromised) BTW, NIST provides a very handy information called the National Software Reference Library (NSRL, http://www.nsrl.nist.gov/) which comes also very handy for either forensic analysis or setting up a baseline of known files (when using an integrity checking tool such as tripwire or samhain) for a large number of servers. If we provided such information they could possibly easily include it there too which would be an improvement, since they currently only carry information on ancient versions of Linux distributions (and Debian is not one of them) Regards Javier signature.asc Description: Digital signature
Md5/sha1sums for all the Release (was Re: proposed release goal: DEBIAN/md5sums for all packages)
On Fri, Aug 17, 2007 at 07:04:39PM -0500, Peter Samuelson wrote: > > [Russ Allbery] > > While it's not the be-all and end-all of security, other OS vendors > > (Sun in particular) have found it useful to make available a central > > database of MD5 checksums of known-good versions of various binaries. > > H. As far as being authoritative (and cryptographically secure), > we already have $MIRROR/dists/stable/main/binary-i386/Packages.bz2. I actually would like to have a file similar to the Contents that provided the MD5/SHA1/whatever_hash of all the files distributed in Debian and have that file included in the Release file (so that it's GPG signed and we have a chain of trust). This has been discussed at #268658 but so far FTP maintainers have remain silent on this issue. Such a per Release file with all the MD5sums could be really useful to do forensic analysis of a system to detected corrupted (or locally modified) contents. It could also complement the md5sums provided by packages and serve as an additional reference to validate them if they are believed to be tampered with. Regards Javier signature.asc Description: Digital signature
Re: adduser/deluser on postinst
On Fri, Aug 03, 2007 at 07:39:58AM +0200, Vincent Bernat wrote: > What do you think ? I think that we should standarise user creation/deletion in maintainer scripts. For some code examples which do work (and are used in several packages) see: http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-bpp-lower-privs Regards Javier signature.asc Description: Digital signature
MD5sum failure of dpkg 1.14.5 (i386)
I was just doing a pbuider --update, it surprisingly failed due to a mismatch MD5 sum in dpkg. From the Release file: MD5sum: 7f4c3b629592a0ab17c924eff9795c4c SHA1: 40841d015920902a9b0051f1a4296113cc474490 SHA256: 4911981eaaee82b381b513ca0f41dc63a8be2b5c7bf0ba8f6cd6454ee8f3acf0 From the downloaded file [1]: $ md5sum dpkg_1.14.5_i386.deb fc1091a81caee1bdab8dcb0c61f55e6e dpkg_1.14.5_i386.deb $ sha1sum dpkg_1.14.5_i386.deb 38b69116a6d817c37400c9c5b4fc3eff241fa648 dpkg_1.14.5_i386.deb Is this a known problem? Javier [1] Tested http://ulises.hostalia.com/debian/pool/main/d/dpkg/dpkg_1.14.5_i386.deb (the Debian Spanish mirror: ftp.es.debian.org) and http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5_i386.deb signature.asc Description: Digital signature
Re: adding desktop files to misc packages
On Tue, Jul 17, 2007 at 09:02:33AM -0500, Manoj Srivastava wrote: > How easy is it for users to add/remove the debian menu hierarchy > to their GNOME menus? Very easy (if using alacarte). Not possible if using the barebones menu editor (the one you get with gnome-core, don't know the application's name) > Can different users on the same machine have > different customized menus easily? Ditto. I think the following question is also relevant: "Can the system administrator edit system-wide menus for all users?" (add/remove Debian menu hierarchy) A: AFAIK not (in GNOME) currently, even when using alacarte (see http://bugzilla.gnome.org/show_bug.cgi?id=372861). I believe the only way currently is editing /etc/xdg/menus/ manually. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Tue, Jul 17, 2007 at 09:36:53AM +0200, Josselin Mouette wrote: > Le lundi 16 juillet 2007 à 20:44 +0200, Javier Fernández-Sanguino Peña a > écrit : > > It looks to me like they are properly categorised and its the GNOME menu > > which is misbehaving > > I have indeed to back out my previous claim. I'm going to work on fixing > this issue in gnome-menus. Thanks for looking into this. Surprisingly, this thread seems to have sparked some good things :) Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Tue, Jul 17, 2007 at 09:42:48AM +0200, Josselin Mouette wrote: > > Okay, as long as it can easily be configured, I see no problem in > > disabling it by default. But there should be either a prominent menu > > entry which is easy to find, or a README.Debian in an obvious package. > > If disabled with NoDisplay=true, you can easily re-enable the Debian > menu in alacarte (accessible with a right click and "edit menus"). Would > that suit you? Please note that 'alacarte' is not part of gnome-core. I'm not very into GNOME but a *different* application seems to get executed for editing menus if you don't have the 'gnome-desktop-environment' meta-package (which pulls in alacarte) but just have gnome-core. If alacarte should be a core tool (as you seem to imply) maybe it should be pulled in by gnome-core. Otherwise users will get different behaviours depending on their package selection (full GNOME desktop vs. minimalistic GNOME desktop). Don't you think? Regards Javier signature.asc Description: Digital signature
Lintian test for desktop files (was Re: adding desktop files to misc packages)
On Mon, Jul 16, 2007 at 08:54:47PM +0200, Frans Pop wrote:
> On Monday 16 July 2007 20:44, Javier Fernández-Sanguino Peña wrote:
> > There are some typos there too ('GameAction', 'ActionGame') which I'm
> > going to file bugs now.
>
> The use of plurals for both seems to be a bug too, looking at other
> categories.
True. It looks like there is only one culprit (in my system, at least):
armagetronad. Bug filed (#433372).
I've just coded in a test for Lintian to implement validation of desktop
files. After implementing it (and sending it to the BTS, see #433411), I've
noticed that there was an outstanding bug report (#277441) which has been
open for over 3 years asking for just this feature.
My lintian tests do less than 'desktop-file-validate' (a tool I didn't know
about, until I read #277441) but can be easily extended based on the code of
that tool to avoid adding too many dependencies to lintian if needed.
Might be interesting to add the test I submitted into lintian and see which
packages fail it specially if we want to promote the use of desktop vs.
menu entries.
Regards
Javier
signature.asc
Description: Digital signature
Re: adding desktop files to misc packages
On Mon, Jul 16, 2007 at 08:09:28PM +0200, Josselin Mouette wrote:
> Le lundi 16 juillet 2007 à 20:01 +0200, Javier Fernández-Sanguino Peña a
> écrit :
> > Check this:
> > $ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | wc -l
> > 54
> >
> > I get all these 54 items in GNOME's Game menu with no category division.
> > And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there.
>
> You should probably file bugs against game packages that provide
> uncategorized desktop entries. The GNOME menu should sort them out in
> submenus if this is done correctly.
It looks to me like they are properly categorised and its the GNOME menu
which is misbehaving:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | \
perl -ne 'while ($_ ne "") {if (/([\-\w]+);(.*)/) {print "$1\n"; $_=$2;} \
else { $_= ""; }}' | sort | uniq -c |sort -nr
55 Game
31 Qt
31 KDE
18 GNOME
15 GTK
13 ArcadeGame
11 StrategyGame
11 BoardGame
7 LogicGame
6 Application
5 CardGame
1 X-KDE-KidsGame
1 GamesAction
1 GameAction
1 BlocksGame
1 ActionGames
1 ActionGame
There are some typos there too ('GameAction', 'ActionGame') which I'm going
to file bugs now.
Javier
signature.asc
Description: Digital signature
Re: adding desktop files to misc packages
On Mon, Jul 16, 2007 at 04:12:02AM -0700, Don Armstrong wrote: > So it seems like we should do the following: (...) 4. Add i18n support to menu so that it can generate localised menu names, entries and tooltips both when converting desktop -> menu (for WM != KDE/GNOME/Xfce) and when converting menu -> desktop (for WM == KDE/GNOME/Xfce). As WM might not have i18n support for their menu, this should be based on the system's /etc/default/locale setting when converting from desktop -> menu to select a single text string there. > The other issue that was brought up was improving the hierarchical > organization of the menus, but how to do that hasn't been made clear > in this thread. Maybe some of the people that claim that the hierarchical organization is broken should open up a wiki page and do a side-to-side comparison of Debian's menu vs. Freedesktop's menu structure. Just my 2c, Javier signature.asc Description: Digital signature
Re: adding desktop files to misc packages
On Fri, Jul 13, 2007 at 10:10:09PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > We can use additional keywords in the desktop entries to get them sorted
> > in sub-menus when appropriate, but many desktop files are not tagged
> > correctly. As you can see in the specification [0], all categories we
> > need should be here, so if we tag desktop files appropriately, the
> > generated menu should be usable.
>
> Oddly, the specification nearly exactly mirrors the despised
> Debian menu system, as far as the categorisation of games goes:
(...)
Just a few thoughts based on my personal experience. I present you my home
system: sid, GNOME 2.18, but not with the full gnome-desktop-environment
metapackage installed, as it's rather huge, but with gnome-core and an
assorted collection of gnome-specific packages as well as many games.
In my case the Debian menu properly introduces these games in their proper
submenu but the GNOME menu does *not* create submenu for any of the
categories, all games are presented in a flat menu which overflows the
screen. Is this a feature only available when installing a particular
package?
Check this:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | wc -l
54
I get all these 54 items in GNOME's Game menu with no category division.
And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there.
Not that I'm completely in favour of submenus (a submenu with a single entry
does not seem useful to me). However, having a list of items that cannot be
seen on screen without browsing through it does not seem very user-friendly
to me. Specially as I don't play all games often (just a few of them)
What I would like to see implement (in the UI side?=
update-menus could also):
a- if # items in a menu are < THRESHOLD then present them in a flat list
b- if # items in a menu are > THRESHOLD then use submenus to categorise
but, if there is a submenu that has < THRESHOLD_B items (say 1) then
do not create a submenu for it.
c- "learn" which items the user uses most and present those hiding others
(there's people which despise this feature from other OSes, I actually
find it useful)
This could be implemented in the UI side, but maybe update-menus could
also implement this (specially a and b) to prevent having submenus with just
1 item.
I don't see any of this being mentioned in GNOME's Menu Usability wiki
(http://live.gnome.org/UsabilityTeam/Menu) which seems to imply that a flat
hierarchy is prefered by GNOME (but it is quite useless in Debian, as we do
carry much more applications if you install both GNOME and KDE). But maybe it
is because it works (better) in other (heavier) GNOME environments.
BTW. If I use GNOME's built-in menu editor (the one you get when you
right-clink on the footprint with just gnome-panel installed, not alacarte,
as it is not installed) I'm not able to create submenus and, even, to see the
categories the different desktop files assign to each Game. That isn't too
user-friendly to me.
I know I can install alacarte (pulled in by gnome-desktop-environment) but
IMHO a *proper menu editor should be an essential part of the GNOME desktop.
However, even if I install alacarte I don't get the option to create
submenus automatically based on the Game categories (which, again, are not
shown). Which means I have to automatically sort games byhand into menus when
there is already information in the desktop files to do this!
Just my 2c,
Javier
signature.asc
Description: Digital signature
Re: Official presentation template
On Mon, Jun 25, 2007 at 08:52:15AM +0200, Andreas Tille wrote: > [Vor DebConf visitors: I'm just replying into a thread that was started in > Debian-devel list and which concerns more or less the LaTeX beamer BOF > https://penta.debconf.org/~joerg/events/34.en.html ] It would be nice if you uploaded also the files (TeX+figs) you used in your presentation. That way people could still use them as a template, or as a starting point for their own presentations just in case no "official" template ends up being available. Oh, and if a design was settled, it would be really nice to have the design implemented in some other presentation toolkits (besides beamer) such as OO's impress or Kpresenter. For the benefit of those that do not like LaTeX (I'm not one of them :) Regards Javier signature.asc Description: Digital signature
Re: Official presentation template
On Sat, Jun 23, 2007 at 03:41:19PM +0100, Mario Iseli wrote: > in a few weeks I will go to give a little talk about Debian packaging > on a swiss CCC event. Having presentations and tell the people > anything about a special Debian topic is a common task for many people > on this list, I think. Now my question: Is there an official template > for Debian related presentations which is open to use? If not, are > there maybe any volunteers which would create one? The problem is that > I'm not very creative in relation to such things and you would safe me > a lot of time. There's no "official" template, but past presentations, like the ones available at http://www.debian.org/events/talks might be useful for you as a starting point to have your own template. Regards Javier PS: There's many talks missing from that page, but people don't seem to be inclined to provide information to -www about their talks so that they can get linked to. signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 08, 2007 at 09:33:26AM +, Peter Makholm wrote: > But I have no idea where these information come from. According to > /etc/debian_version I'm running'lenny/sid'. This was discussed previously in the thread... > Hmmm, lsb_release seems to parse 'apt-cache policy' and hardcodes the > 'testing is etch' connection. And this is an ugly hack since it forces the *program* to be changed for each release instead of the *data* which leads to #425646 and similar bugs. Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Mon, Jun 04, 2007 at 04:16:29PM -0400, Lennart Sorensen wrote: > On Sun, Jun 03, 2007 at 11:16:08PM +0200, Javier Fern?ndez-Sanguino Pe?a > wrote: > > Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, > > Remedy... Do you expect vendors of this software to understand^Wimplement > > package management based dependencies for *all* Linux distributions? > > LSB tries to simplify the Linux environment for such software. Lsb_release > > is defined as the an answer to the question "which distribution am I running > > in and which release is it?" > > For the kind of cash the enterprise vendors tend to charge, yes actually > now that you ask, I think I can expect them to figure out dependancies > and making proper packages. Opera seems to manage, and they are giving > away their non-free software for free. Managing to package and test > your code on most major distributions is actually a good way to ensure > the programmers didn't go do something stupid that is going to cause > problems later. I'm afraid you're comparing apples and oranges here. Opera is a rather small product and codebase when compared to the products of any of the Enterprise software players I placed above. In some of the examples I placed above a software release of a given version of their product is made up of 4-5 CDs of binary software. Opera is, what, a 4-7 MB download? Believe me, people running Linux and using this kind of software will, in most cases, not get a package integrated into their $distribution package's management system but an installation program from the vendor that works by its own rules. The funny thing is, some of these installation systems actually installs a package management system of itself which is completely unrelated to the system's. That's the case of HP's depots, the package management system for HP-UX, which is also used in software like HP Openview when installed in other operating systems too (at least I know of Sun's Solaris and IBM's AIX) And, even funnier, those that *do* provide packages (RPM packages in all the cases I've stumbled upon) don't setup proper dependencies so even if they install fine on a system they were not prepared for (think SuSE vs. RedHat) they just don't run. Vendors just use the package management system as an archiver (a 'bigger' tar.gz or zip file if you will). Many organisations I've worked with in Spain (including Telcos and Banks) pay large amounts of cash in licenses to these (overseas) software vendors and no, they are not pushing them to get packages for their favorite distribution. They just push them to make it *works* (i.e. run and be supported) in $distribution and are not always succesful (which means they have to install the vendor software in the official/supported/approved platforms the vendor has decided upon). Long-term, the fact that the software was installed using a .deb, .rpm, an installation script or a tar.gz is not important at all. Having the vendor support your environment is. Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sun, Jun 03, 2007 at 05:28:24PM -0500, Manoj Srivastava wrote: > Frankly, helping vendors of non-free software lies far below the > ability to provide our users the option to do partial upgrades, > apt-pinning, etc. How does /etc/debian_version of lsb_release hinder that? I'm not suggesting we ditch partial upgrades or apt-pinning. Please reread my email. > If we are not going to impact the utility to the users; I am > indifferent to adding things to help non-free software vendors. How are we going to impact our users? I really don't understand your email. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 07:14:16PM +0200, Santiago Vila wrote: > On Fri, 1 Jun 2007, Javier Fernández-Sanguino Peña wrote: > > We are not telling the user, we are telling *programs* what environment they > > are in. > > That's the fundamental mistake I see here: We should not be telling > programs what "release" they are running to begin with. We do not try > to make packages to work under the assumption that they will run > "on a sarge system" or "an etch system". Instead, we try to make them work > as far as their dependencies are met. Since when do programs == package? You don't seem to understand that I'm talking in a generic way about software. Actually, I'm mainly talking about software which is *not* part of the package management system [1]. I agree with you that packages *in* Debian should not use /etc/debian_version or lsb_release, but what of software (not packages) *outside* Debian. Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli, Remedy... Do you expect vendors of this software to understand^Wimplement package management based dependencies for *all* Linux distributions? LSB tries to simplify the Linux environment for such software. Lsb_release is defined as the an answer to the question "which distribution am I running in and which release is it?" Developers of such software, taking the LSB as a reference, can use lsb_release to determine where they are in. However, if we "lie" [2] to these tools we are actually making this software break. Lsb_release should *always* provide correct information, I've sent some patches already (and a new bug with a patch) to try to fix the current issues, but without /etc/debian_version having correct contents throughout *all* the release in our non-releases (sid, testing) it might be the case that it will provide incorrect information in an unpredicable timeframe. I.e. the time between your upload of base-files for a release that is not yet so and between your upload of a new 'testing/unstable' base-files package. Let's look back: For the 'etch' release this was: - From 2006-10-28 (base-files-4) to 2007-04-03 (base-files-4.0) in sid --> Over 5 months - From 2006-11-10 to 2007-04-10 in testing --> Exactly 5 months For the 'sarge' release this was: - From 2004-07-26 (base-files-3.1) to 2005-06-06 (base-files-3.1.3) in sid --> Almost 1 YEAR What will happen will 'lenny'? Can external software rely on being able to properly determine which distribution is it running it without digging into the package management information and deriving it from there? I hope I've made my point clear. Regards Javier [1] I brought up the fact that some of the sofware in *our* package management system uses /etc/debian_version because you thought the instances of packages using that was zero, not to imply that every package should. [2] We "lie" to it when lsb_release fails to provide the correct information of what system the program is running in. This happens in a number of situations as I already stated including when we are approaching a release and the contents of /etc/debian_version are bogus (in sid and testing). signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 02:26:34PM +0200, Morten Kjeldgaard wrote: > PS: To address the original question: Being a molecular biologist, my > initial idea was to use an approach similar to that used in gene > analysis: look at the entire set of packages installed on a specific > system (package name and version), and then determine what known distro > the set is closest related to. You can check only a subset of packages (most popular ones, for example or core packages) and compare with data you extracted the data beforehand or somebody provides. For example, see the package data sets at http://distrowatch.com/debian (these can be easily generated with the Packages files from the different releases, but you have to have access to mirrors with old releases too) Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Fri, Jun 01, 2007 at 12:55:57AM +0200, Santiago Vila wrote:
> I wonder why do we need a file to tell the user about the contents of
> his /etc/apt/sources.list file. Have you read "How do I know which
> distribution I'm running?" in base-files FAQ? The answer is still
> valid for *any* file which is part of an installed package.
We are not telling the user, we are telling *programs* what environment they
are in. Reading /etc/apt/sources.list is useless. Let me give you some use
cases:
- a sysadmin running 'woody', upgraded to 'sarge' by changing his
/etc/apt/sources.list to point to 'stable'. But has not upgraded the system
after etch was released
/etc/debian_version -> CORRECT info
/etc/apt/sources.list -> INCORRECT info
- a sysadmin running 'sarge' modifies his /etc/apt/sources.list to point to
'etch', but never upgrades the system.
/etc/debian_version -> CORRECT info
/etc/apt/sources.list -> INCORRECT info
- a sysadmin installed 'etch' using d-i, and upgraded it after December 11th
but has not upgraded it before April 10th.
/etc/debian_version -> INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list -> CORRECT info
- a sysadmin installs 'lenny' using d-i, April 9th. But never upgraded
before that.
/etc/debian_version -> INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list -> CORRECT info ('testing')
Sources.list does not indicate the release the system is running but,
actually, the release the system would be running *if* it was up-to-date and
upgraded.
Moreso, it's completely useless for (some) systems that have been installed from
CD-ROM and do not point to the security mirrors.
It is useful *in*addition* to /etc/debian_version to make a guess and try to
tell apart testing vs. unstable.
> I really don't understand what you guys want to achieve that might be both
> necessary and really useful (as opposed to just "being a nice thing").
We are trying to simplify the problem some applications might have (not
necessarily those shipped in Debian proper, maybe even for applications that
are for other vendors) in order to determine which system they are in and
take proper action. The problem that was originally stated at the start of
the thread.
The best approach we can provide ('use lsb_release') is prone to errors if
used in the timeframe of a release and, even for some other situations.
In any case, you said [1] there was some (programmatic) way to determine
which Debian release (or even 'non-release') an application is running one
which does not depend on /etc/debian_release. I would be happy to know which
one that is (so that it can be implemented in lsb_release).
Regards
Javier
[1] Message-ID: <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: http://utnubu.alioth.debian.org/scottish/ still used?
On Thu, May 31, 2007 at 02:46:32PM +0200, Daniel Baumann wrote: > In order to find the Debian maintainer, we'd have to have an additional > pass to extract that information -- which would actually be quite > expensive (unpacking 16,000 source packages every hour!)" That's bogus, the maintainer field is in the Packages file. You just have to parse it (not necessarily every hour) to extract that info and map Ubuntu packages to Debian maintainers. Actually, guess what, that's already done in Launchpad! Regards Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, May 31, 2007 at 02:06:28PM +0200, Santiago Vila wrote: > That would "bless" the abuse of /etc/debian_version. IMHO, it would be > good for Debian if we continue to discourage its use. LSB compliance (which is a release goal) obliges us to provide proper versioning information for releases. That means we have to have a (standard) way for other software to determine which version of our distribution they are running in. The lsb_release scripts relies on /etc/debian_version. It also uses of /etc/apt/sources.list is a -bad- hack to work around the testing/unstable problem (and introduces some bugs). As you are the maintainer for base-files, and it provides /etc/debian_version, what do you suggest we do for LSB compliance? Quite frankly, if you are actively opposing its use I would like to suggest release managers to get involved and help fix this ambiguous situation for the next release. Friendly, Javier signature.asc Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, May 31, 2007 at 12:35:06AM +0200, Santiago Vila wrote:
> Hi.
>
> I believe there is something fundamentally wrong if you *have* to rely
> on /etc/debian_version for anything. The number of Debian packages
> actually using such file is probably zero (but I could be wrong).
Bastille uses it to distinguish releases. There seems to be others:
$ grep -l /etc/debian_version /*/bin/* 2>/dev/null
/usr/bin/binstats
/usr/bin/bug-buddy
/usr/bin/euro-test
/usr/bin/gnome-bug
/usr/bin/gst-feedback-0.8
/usr/bin/imake
/usr/bin/lsb_release
/usr/bin/xine-bugreport
/usr/bin/xine-check
/usr/bin/xminicom
And this is NOT surprising for people who use linuxlogo:
$ find /var/lib/dpkg/info/ -type f -exec grep -l /etc/debian_version \{\} \;
[ .. snip base-files .. ]
/var/lib/dpkg/info/linuxlogo.preinst
/var/lib/dpkg/info/linuxlogo.postrm
> Try using dependencies or run-time tests. Really.
Which runtime tests do you suggest? If there is a programatic way to
implement the test then lsb_release is the way to do it.
I actually think we should ship a *distinct* /etc/debian_version
in testing and not make it follow the "sid->testing->stable" dance. Otherwise
there is a timeframe in which sid's or testing's base-files say's it is
stable, when it's not.
Could there be a distinct package per distribution repository? One
(cumbersome?) way to do this is to have base-files maintainer (ehem, you)
upload new versions of the package to the proper distribituion. That way, the
contents of /etc/debian_version in the package in sid are never changed, and
the contents of the file in testing depend on its status:
a) during development /etc/debian_version reads 'CODENAME/testing'
b) during freeze /etc/debian_verion reads 'CODENAME/stable'
(this way, when testing is released, it will ship with that content,
right after the release a new package has to be uploaded to 'testing' to
go back to a)
The only issue with this is that you have to maintain always two branches
(sid and the next release) and whenever changes to other files in base-fles
are done you have to upload them to both releases.
However, this opens the possibility of introducing /etc/lsb-release in Debian
(not required by lsb, but nice to have for people who do not want to rely on
the lsb_release script) with properly structured content like:
DISTRIB_ID=Debian
DISTRIB_RELEASE=4.0
DISTRIB_CODENAME=etch
DISTRIB_DESCRIPTION="Debian GNU/Linux 4.0 'etch'"
and
DISTRIB_ID=Debian
DISTRIB_RELEASE=testing
DISTRIB_CODENAME=lenny
DISTRIB_DESCRIPTION="Debian GNU/Linux testing 'lenny' (UNRELEASED)"
Another (easier?, but "strange") way to have this is to have base-files
depend: on a package like 'release-info' which only contained
/etc/debian_version and have different packages for each distribution which
are *not* transitioned from unstable->testing.
Similary to the solution above, its maintainer (the RMs?) would have to
upload a new package in *testing* just before a release (for example, during
the freeze) and upload a new package version to *testing* just after a
release. The contents of the package in sid would never change. However,
having a package just to handle a file looks like an overkill to me.
Either ways make the hacks introduced in lsb_release unnecesary.
Regards
Javier
signature.asc
Description: Digital signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wed, May 30, 2007 at 10:12:38PM +0100, Stephen Gran wrote: > The closest we ship is /etc/debian_version. I use it for several > similar tests at work, you just need to keep a mental map between the > number and the version string. If you can count lsb-release being > installed, that will give you more information, or you could just look > at the tests it performs to get an idea of how it distinguishes > releases. Only problem with /etc/debian_version is that you cannot distinguish testing from sid and there's a timeframe (when base-files is updated, in which you will confuse a 'sid' system with the next release). You can run 'lsb_release -a' a better estimate. Actually, it should be able to cope derived distributions that have adapted /etc/lsb-release. The script is provided by package lsb-release, but it's extra priority, so not bound to be installed in most systems. The script originally did not cope with the testing/unstable issue, see #341231. Right now it should cope with most common cases but there might be some weird situations in which it does not provide the correct answer. For example: if a system's /etc/apt/sources.list is not properly configured, if the system was installed ages ago with the 'testing' version of the installer for the a current release (and has never been updated) or because of weird setups (see #417145) It also hardcodes the codename for testing, that's why bugs like #425646 popup just after a release. I wonder if we should be shipping an /etc/lsb-release file? It was removed from the lsb package (in 3.0-6, september 2005) but did not move over to base-files... Regards Javier signature.asc Description: Digital signature
Re: Better documenting what does not work in Etch.
On Wed, May 30, 2007 at 04:33:59PM +0200, Petter Reinholdtsen wrote: > Very good points, and I believe you have a good point. What about > making an errata wiki page for the etch release on > http://wiki.debian.org/>, and add links to the etch bugs in BTS? > It migth form the basis for updating packages and/or the release > notes. Actually, the website has errata pages for each release work at the wiki could be a basis for an updated page at the website. The release notes should document major changes not minor behaviour changes in the underlying system. Regards Javier signature.asc Description: Digital signature
Re: A sane guess at default Debian mirror for pbuilder
On Tue, May 29, 2007 at 07:48:59PM +0200, Josip Rodin wrote: > Well, at least it was different... ftp.debian.org is an even more horrible > default, because that's burdering one single machine maxing out its FE card, > where we have a network of >300 mirrors out there that are mostly happy > to share the load. I have to ask: why isn't ftp.debian.org a RR DNS entry? Or even better, wouldn't it be possible to setup a load balancer in front of ftp.debian.org (with a GE card) to share the load amongst more than one system? Regards Javier signature.asc Description: Digital signature
Re: The number of etch installations is rocketing...
On Thu, Apr 12, 2007 at 07:25:02PM +0200, Tshepang Lekhonkhobe wrote: > Please keep on sending these interesting stats, perhaps once-per-week, > to some blog or some mailing list. I'll be real glad. Thanks... Better yet, set up a MRTG-like graph. Everybody loves fancy graphs and they are really useful in presentations at conferences :) Javie signature.asc Description: Digital signature
Re: The number of etch installations is rocketing...
On Thu, Apr 12, 2007 at 05:29:13AM -0400, Joey Hess wrote: > Petter Reinholdtsen wrote: > > Looking at the submission numbers from > > http://popcon.debian.org/>, I am happy to report that the number > > of Etch installations is increasing fast. Here are the number of > > submissions collected by popularity-contest, with the increment. It > > is easy to see when Etch was released. > > Now if we only knew what percentage of users take the manual action > needed to answer Yes to the "enable popcon" question... IMHO there are some ways we could track get some better numbers for that. Given the fact that "many" users are using security.debian.org as the default security mirror, that etch enables it by default (there were some previous releases that didn't IIRC) and that *we* have control over those servers' logs we could count the number of downloads of the Packages files from the official security mirrors [1]. That would give us an estimate of new installations (or upgrades to etch), since apt will not download the Package file after installation (it will go for the pdiffs as the security archive should not change that much, at least not for a few months) [2]. This could be useful to have better estimates on how many installations have been "recently" made. Track this after the release, correlate with popcon submissions and you have better data to get an approximate percentage of users not registering for popcon. You can even get approximate results of *real* systems and number of systems behind NATed addresses. The only caveat I can think of (but there might be others) is that it would not be possible to properly count installations that are using corporate (or ISP's) caching proxies (in somecases those are transparent to the end users) You would still will not be able to count installations that are not Internet connected. But you are not going to be able to count them through any other mechanisms (not even through the "report once" mechanism that Lars suggested) Regards Javier [1] Official mirrors could also be used, but getting the logs from the different admins would be rather difficult. [2] Unless he removes the Packages file manually from his system, however, in which case it would be downloaded again. signature.asc Description: Digital signature
Re: Ethernet interface numbering in etch
On Sun, Apr 01, 2007 at 10:24:26AM +1100, Russell Coker wrote: > > I disagree. Not only because the bug is not RC, but because you could say > > the same for users running other virtualization technologies (UML? Vmware?) > > with similar behaviours. > > Do they behave in the same way? Well, not the same way, but udev will interfere in this scenarios: - Uml assigns MAC addresses automatically so MAC address will depend on when the interface was started and whether it was configured before it was started. In any case MAC addresses change when the interface is 'up'ped (from '00:00:00:00:00:00' to something else) or connected to different uml-switches (without changing the UML machine itself). You can staticly assign them, however, See http://edeca.net/articles/bridging/questions.html#macproblems2 - Vmware can be used to run linux already installed in a local hard disk (instead of using a virtual disk). In this case, the MAC address given by Vmware for its bridged network interfaces (sharing the system's network interfaces with the host) will be within Vmware's assigned OID MAC addresses, which is different from the network interface's MAC address when the system boots (without virtualization) and uses the real network interface directly. There might be some other situations in which MAC addresses change (changing an interface from bridged-mode to host-only or so), but are more similar to the device renaming in udev when ethernet cards are removed or replaced. - When you "move around" a Vmware virtual image (to a different host or to a different directory, or clone it) MAC addresses might also change: http://www.vmware.com/support/ws55/doc/ws_net_advanced_mac_address.html and http://kb.vmware.com/KanisaPlatform/Publishing/476/507_f.SAL_Public.html Google for "mac address vmware udev" and you'll find many users having problems with udev in these cases. For example http://www.vmware.com/community/thread.jspa?threadID=46069&tstart=0 (go down the thread and you will see comments about people cloning Debian systems) Regards Javier signature.asc Description: Digital signature
Re: Ethernet interface numbering in etch
On Fri, Mar 30, 2007 at 05:19:25AM -0400, Nathanael Nerode wrote: > Anyone have any thoughts on where and how this should be documented? > Which documents do we need to make patches for and how detailed should > the description in each document be? I think the appropiate location is the Release Notes' chapter "Issues to be aware of for etch": http://www.debian.org/releases/etch/i386/release-notes/index.en.html#contents More specifically the subsection "Switching to 2.6 may activate udev" under section "5.2 Upgrading to a 2.6 kernel": http://www.debian.org/releases/etch/i386/release-notes/ch-information.en.html#s-2.6-udev (the subsection title needs to be fixed: s/may/will/) Regards Javier signature.asc Description: Digital signature
Re: Ethernet interface numbering in etch
On Thu, Mar 29, 2007 at 11:34:53AM +1100, Russell Coker wrote: > The current functionality in regard to Xen is seriously broken. A reasonable > person will expect that when a Xen virtual machine is configured with a > single Ethernet interface then it can be restarted at any time and get the > same name - eth0. The current functionality for Xen breaks user expectations > and does not provide any benefit that I can imagine. If this is so important, why, after so many many months of freeze, no Xen users found this and submited a bug report? (Now its #413601, filed 24 days ago) > I believe that this fix is worthy of inclusion at this time. I disagree. Not only because the bug is not RC, but because you could say the same for users running other virtualization technologies (UML? Vmware?) with similar behaviours. I'm in favor of adding a note in the Release Notes but I think we should not delay the release (*again*) by modifying such a critical element as udev right now. Regards Javier signature.asc Description: Digital signature
Re: Ethernet interface numbering in etch
On Wed, Mar 28, 2007 at 11:51:15PM +0200, Gabor Gombas wrote: > If you do not have physical access to the machine then serial access is > a must (or some alternative, like IPMI-emulated serial console if you > have the hardware). For example if you have to update the kernel and > something goes wrong, a seral console can be _very_ handy (you can > configure a once-only boot with the new kernel but that does not help to > diagnose _why_ it does not boot). Updating with a serial console through the network is something now recommended in the Release Notes: http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.en.html I would be interested in documenting how you can do a once-only boot with the kernel (or linking to available documentation) for the Release Notes. Regards Javier signature.asc Description: Digital signature
Re: Bug#416397: ITP: haproxy -- fast and reliable load balancing reverse proxy
On Wed, Mar 28, 2007 at 10:11:51AM +1100, Russell Coker wrote: > Has this problem been solved for a protocol other than HTTP? In theory you > could have a user-space TCP stack that sends data to the back-end server with > a source address that is the same as that of the origin. Has anyone done > this? If it has, I've not seen it in any RFCs nor in any of the most common load-balancing solutions for Enterprises (all products I know of are closed-sourced so I will not provide names) I've worked with. Most of them avoid this issue by working inline and NATting the destination IP of incoming requests transparently. That way they original IP address is preserved. Including the "standard" X-Forwarded-For HTTP header when working with transparents proxy is somewhat common for those devices not working inline with the traffic flow. Although that is rarely used for more than log statistics (visitors, etc) since authentication is typically application-level based. Just my 2c. Javier signature.asc Description: Digital signature
Re: More stuff the installer does which isn't done on upgrade
On Mon, Mar 26, 2007 at 10:45:46AM +0200, Javier Fernández-Sanguino Peña wrote: > On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote: > > (I would add this to the Wiki page > > http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...) > > The information you posted belongs to release-notes's BTS, not to the wiki > (as the wiki tries to track a sarge->etch upgrade). Agg.. sorry, I read http://wiki.debian.org/Sarge2EtchUpgradeBlackboard instead of Sarge2EtchUpgrade, my fault. BTW, I intend to move all the information in http://wiki.debian.org/Sarge2EtchUpgrade over to the Release Notes (to the setions mentioned in my last email) Regards Javier signature.asc Description: Digital signature
Re: More stuff the installer does which isn't done on upgrade
On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote: > (I would add this to the Wiki page > http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...) The information you posted belongs to release-notes's BTS, not to the wiki (as the wiki tries to track a sarge->etch upgrade). Please see http://www.debian.org/releases/etch/i386/release-notes/ch-installing.en.html which will document major differences between etch installs and sarge installs some of which are NOT available for sarge+upgrade systems (the distinction hasn't been introduced yet, but I will try to do so this week) The section is called "System improvements" but it could be relabeled to something else (since not all are "improvements") Regards Javier signature.asc Description: Digital signature
Re: future keys
On Mon, Mar 19, 2007 at 10:49:47AM +0100, Adam Borowski wrote: > Whee?! > > While testing Etch upgrades on some old boxes, I noticed that key management > issues get worse and worse, especially if some time happens between upgrades. > Even when ignoring all users of "testing", upgrades between stable releases > kind of _have_ to work well. So, here's my idea: Could you please fill an 'upgrade-report' bug describing those issues? That way we could document them in the Release Notes (if we want to support the upgrade paths you are using). Regards Javier signature.asc Description: Digital signature
Re: Archive signing key for 2007?
On Fri, Jan 19, 2007 at 01:55:06AM +1100, Anthony Towns wrote: > The key we'll be using (and indeed are already using) is available as: > > http://ftp-master.debian.org/archive-key-4.0.asc Thanks for the info. Maybe I've missed something, but I though there was going to be one key per year (indeed, that's what I documented in the Securing Debian Manual [1]) : "The Debian archive signing key is available at http://ftp-master.debian.org/ziyi_key_2006.asc (replace 2006 with current year)." Using a different naming convention from last year is certainly confusing. Why the 4.0? Because of etch? Could it be possible to properly define what naming convention will be used so that users can have a guideline where to download the latest key from? It might be necessary for users that are do not have the latest version of debian-archive-keyring installed, find issues when upgrading and have to take manual steps to include the latest key. Regards Javier [1] http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-check-releases > > It's expected to be valid until sometime after lenny is released. > > If you've upgraded a testing/unstable system in the past month or two, > you'll find that key has been automatically added to your apt key list, > after being verified by the normal trust path for upgraded packages -- > namely the current archive key you've been using, then the sha1sum of > the Packages file and finally the md5sum of the apt package containing > the updated key. > > Debian developers can obtain the key from merkel over ssh, by looking > in /srv/ftp.debian.org/web/archive-key-4.0.asc. The key id is 6070D3A1 > which can be obtained from the key servers with signatures from both me > and Steve Langasek. > > Cheers, > aj > signature.asc Description: Digital signature
Archive signing key for 2007?
There seems not to be any 2007 archive signing key in the archive yet. That is http://ftp-master.debian.org/ziyi_key_2007.asc does not exist. I thought that the 2007 key was (based on [1]) supposed to be available early in January and available in the debian-archive-keyring package. Which doesn't seem to be the case. Could the ftpmaster team, after creating the key, do any (or all) of the following? - Generate an SSL certificate for ftp-master.debian.org (or maybe db.debian.org) preferably a certificate signed by a common CA (I guess that any certificate included in ca-certificates would be OK) - Put the key up at the above site (in addition to at ftp-master) - Send a (signed) announcement to debian-announce providing the location for the key. Regards Javier [1] http://wiki.debian.org/SecureApt signature.asc Description: Digital signature
Re: RFC: Proposal for official screenshot repo
On Fri, Jan 05, 2007 at 11:55:02AM +0100, Andrea Bolognani wrote: > On Wed, 3 Jan 2007 17:32:52 -0500 > "Roberto C. Sanchez" <[EMAIL PROTECTED]> wrote: > > > I would really appreciate any comments and suggestions on this. > > What I don't really get is, why would we want a similar service in Debian? For several reasons: 1.- Debian is "upstream" for a number of programs 2.- There is software that has no "upstream" to speak of 3.- Some upstream sites do not carry screenshots, why force them do it? 4.- The screenshots for a particular version (i.e. the one shipped in stable) for some software (say, an e-mail client) might be quite different than the latest eye-candy produced by upstream with the latest release (because of different functionality being available). 5.- If the location is fixed, it is easier to integrate with package managers and other tools. > We should already be pointing to the upstream site with the Homepage: > pseudo-header, and in case of GUI programs or games there are usually plenty > of screenshots there. Not in all programs, not for all games. > I really se no point in doing this. Everyone is entitled to his own opinion. If there's somebody (Roberto) that thinks it is a worthwhile idea I say we let him do it and, if it turns out to be a good idea (like I think it is) it will keep momentum and will find its own space in the universe of ideas, if it's not, it will die [1] Regards Javier [1] Harsh, but it's Charles Darwin's evolutionist theory applied to software :) signature.asc Description: Digital signature
Re: RFC: Proposal for official screenshot repo
On Fri, Jan 05, 2007 at 01:02:35PM +0100, Andrea Bolognani wrote: > And BTW, I think no one would ever want to upload screenshots of CLI > software ;) Why not? There is some cli software (links, mutt and mp3blaster come to mind) that have nice text-based UIs which can be presented to the user to show him: "*yes*, you can do lots of stuff without a graphical frontend in Debian" [1]. Not that all CLI software fits in the category of having "nice text-based UIs", however. Regards Javier [1] Think of a bandwith-limited ssh connection, for example. signature.asc Description: Digital signature
Re: RFC: Proposal for official screenshot repo
On Thu, Jan 04, 2007 at 12:37:53PM -0500, Roberto C. Sanchez wrote: > > - Provide an HTML interface to the pool > > > > If the packages names are the same I don't see the need to add yet another > > line to the debian/control file, packages.debian.org would just need to > > point > > to http://screenshots.debian.org/ and that's it. > > > Good idea. I'd not though about it that way. We would then only need a > default place holder for packages without screenshots. Which would be easy to code if the screenshots access was governed by a CGI. > > Do you mean server requirements? I guess that it's disk and bandwidth. > > As for limitations, if you are restricting this to DD uploads there is a > > severe limitation (i.e. users cannot 'contribute' screenshots) > > > What about my suggestion for user contributed screenshots via bug > reports? The BTS accepts attachments to emails, so I think that would > work. I think it would be best to follow backports.org here (read its 'contribution' page) and have users upload just like developers, using FTP since that makes it fully automated. Maybe provide a mechanism for DDs to be notified when a screenshot for their package has been uploaded (just like with binary packages) so they can veto it (with a new upload). Going through the BTS route means both clogging the BTS and also needing somebody to manually review the submissions. > > I say that is a good idea, but I'm not sure how screenshots.debian.org would > > help your friend. If you are talking about one-five screenshot per package > > (or per package version) that is hardly sufficient to explain how a package > > manager works. Better yet if someone wrote a package management document > > using DocBook and including screenshots and that was published in the > > website. > > > Here is how it would help. He wants an email client and so he searches > for one. The list includes icedove, sylpheed, mutt, kmail, evolution > and others. They all have descriptions, but he can't visualize what > they look like, especially not being familiar with them. Having > screenshots available makes it so that he can compare them, at least > based on how they look. Ok. I didn't understand your use case. The use of the descriptions in the packages + screenshots for this use case is certainly something that would help him get idea of wether a given package does (or does not) fit his needs. Regards Javier PS: And after screenshots.debian.org we could go with video-demos.debian.org which provided small animations or videos of the programs *being*used* which is cooler (and could be easy to implement provided there is an infraestructrure for static images) :) signature.asc Description: Digital signature
Re: RFC: Proposal for official screenshot repo
On Thu, Jan 04, 2007 at 12:05:03AM +0100, Nico Golde wrote: > Hi, > > this idea has been discussed recently, I just can't remember when > > exactly though, I'd say in the late 6 monthes. Maybe you can grab some > > names of people that were involved in the first proposal there. It may > > have been proposed on -project rather than devel. But I suppose google > > will know about it. > > Maybe the following? > http://lists.debian.org/debian-devel/2006/04/msg00915.html It's not exactly the same idea. The proposer (Gonéri Le Bouder [0]) focused on what the layout and distribution of images [1] should be, but not on: - who provides the screenshots? how are they uploaded and validated? (is there an upload queue who manages all this automatically?) - is there a web interface to that information or it will just be used by package managers? The Alioth project was named 'apt-pixmap' [1] there has been no activity in its mailing list [2] and the original location of the "proof of concept" [3] does not exist any longer. So I guess the project did not spark enough attention. Some of the information in the project as well as the threads can be used to draft a new proposal, however. I think that something similar to backports.org (a service where both DDs and non-DDs could upload screenshots to) and provided a web interface to view screenshots by package version would be really cool. Regards Javier [0] Who, BTS is now the proud father of a little girl: http://orniere-du-globe.net/blog/?p=312 :-) [1] Based on Debian packages or TAR files so the user could download *all* the screenshots using a specific tool. Which, BTW, I don't think is a good idea. [2] http://alioth.debian.org/projects/apt-pixmap/ [3] http://lists.alioth.debian.org/mailman/listinfo/apt-pixmap-repo [4] http://gloria.rulezlan.org/debian2/ signature.asc Description: Digital signature
Re: RFC: Proposal for official screenshot repo
On Wed, Jan 03, 2007 at 05:32:52PM -0500, Roberto C. Sanchez wrote: > I'd be interested in knowing: > > * Would such an idea be feasible? Yes, it only requires somebody to code in the missing pieces (i.e. all of them) > * Would maintainers be willing to occasionally upload screenshots? I would. > * What would be a good way to get started? (*) - Code in an upload queue implementing something akin to master (i.e. upload through anonymous ftp and put the screenshots in a pool, define a changes file format to describe which version is being screenshotted etc.) - Provide an HTML interface to the pool If the packages names are the same I don't see the need to add yet another line to the debian/control file, packages.debian.org would just need to point to http://screenshots.debian.org/ and that's it. > As far as getting started: > > * Would this need to start on debian.net? Probably, until a proof of concept is working and an official domain is provided. > * What would be the requirements/limitations/guidelines? Do you mean server requirements? I guess that it's disk and bandwidth. As for limitations, if you are restricting this to DD uploads there is a severe limitation (i.e. users cannot 'contribute' screenshots) > I would really appreciate any comments and suggestions on this. I say that is a good idea, but I'm not sure how screenshots.debian.org would help your friend. If you are talking about one-five screenshot per package (or per package version) that is hardly sufficient to explain how a package manager works. Better yet if someone wrote a package management document using DocBook and including screenshots and that was published in the website. Regards Javier signature.asc Description: Digital signature
Documentation CD (was Re: Bits from the debian-cd team; more CD/DVDs being built regularly)
On Fri, Dec 22, 2006 at 01:21:01PM +0100, Holger Levsen wrote: > Hi, > > On Friday 22 December 2006 11:07, Javier Fernández-Sanguino Peña wrote: > > I'm not sure if this is done (I assume it's not) but I would really like > > the DVDs / CDs to have a 'documentation media' which could be used to read > > documentation without having to install the system. > > I like the idea. Should we file a bug against debian-cd so this doesnt get > lost? Bug submitted In the past I tried to tackle this through ftp.debian.org, since the Debian CD scripts would mirror all the content under /debian/doc/ in the mirrors to the '/doc/' directory in the CDs. Unfortunately, the Ftp masters have ignored #172482 completely. Currently the only way to put stuff under that directory si through BYHAND processing [1] which is a p* in the a* (for them and for package maintainers, just look at http://ftp-master.debian.org/new.html and check out the status of doc-debian). Regards Javier [1] Which, incidentally, means that documentation needs to be provided in a Debian package which is not always the case and also introduces a gap between publishing in the website (through CVS, which is automatically build) to publishing in the ftp site (need to make a package from the CVS sources, sign and upload). signature.asc Description: Digital signature
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
On Wed, Dec 20, 2006 at 06:29:04PM +, Steve McIntyre wrote:
> I'm still expecting to add Live CDs to the list here before we
> release. Otherwise, I think we're about set. If there's anything else
> you'd like us to do or anything you'd like to ask about, please reply
> to this mail - note the Reply-To to the debian-cd list.
I'm not sure if this is done (I assume it's not) but I would really like the
DVDs / CDs to have a 'documentation media' which could be used to read
documentation without having to install the system. That documentation media
would contain both the english and available translations of:
- The Release Notes
- The Installation Guide
- The Refence Guide
- The User Guide
- The Project History
- The FAQ
- The Securing Debian Manual
- The Reference Card
- The Quick Reference
- The APT Howto
Content could be extracted (in an automatic way) from both the website [1]
and/or from the Debian packages providing them [2].
By providing all that content in easily printable format it would make it
easier for users that do not have good broadband access and have not yet
installed Debian to go through or print those manuals before even starting
installation.
Having all that content in one place makes it more easier for users to find
and take profit of (you'll see below that the document to package mapping is
not at all evident for a novice user).
Just my wishlist :)
Javier
[1] Some of these are available under http://www.debian.org/doc/manuals/, or,
more
precisely, from /org/www.debian.org/www/doc/manuals , and the
release-specific info is at http://www.debian.org/releases/etch/
(/org/www.debian.org/www/releases/etch)
The Reference Card is at http://people.debian.org/~debacle/refcard/
[2] By extracing all of /usr/share/doc/${package} to the CD.
The FAQ = doc-debian
The Installation Guide = installation-guide-XXX
The Refence Guide = debian-reference-XX
The Quick Refence = quick-reference-XX
The Project History =
The APT HOWTO = apt-howto-XX
The Securing Debian Manual = harden-doc
signature.asc
Description: Digital signature
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 08:12:52AM +0100, SZALAY Attila wrote:
> > Why would you *not* want a locale? If the program has l10n support and it
> > provides messages (even in a non-interactive way) there's chances some users
> > will benefit from the translated messages.
>
> In log files, localized messages may hurt more, than what gain with it.
>
> For example some (semi)automatic log analyzing programs couldn't (and I
> think don't want to) handle localized log messages.
IMHO, either that software should be modified to support i18n text or the
admin would have to choose wether he prefers to *understand* the logfile or
to be able to parse it with automatic programs (I believe you are talking
about tools such as logcheck or log-analysis [1][2]).
In any case, it would not be too difficult to adjust programas that parse
logs to be able to parse translated messages. Take in account that all
translated text messages would be available in a message catalog (typically a
PO file).
So it could be realy straightforward to convert a text mesage like this
(from logcheck's kernel violation.d rules):
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: media error \(bad
sector\): status=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
to the Spanish equivalent of:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: error en el medio
\(sector defectuoso\): estado=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
if the kernel's Spanish PO file has something like:
msgstr "media error (bad sector): status="
msgstr "error en el medio (sector defectuoso): estado="
Or even have logcheck use those PO files directly by introducing some tokens
in its regexps.
For those logparsing programs that would not had i18n support, the user (or
admin) would at least have the *option* to make a decission.
Consider this situation: a user that can not even *read* english (since he
doesn't understand the written language as he uses different script) should
be able to weight which option is more important to him:
a.- be able to use software that generates reports from logfiles with english
messages, and not being able to understand the logfiles themselves and
(probably) not the reports either (if the reporting software is not i18nised)
b.- be able to read the non-english logfiles, but unable to use software to
geenrate reports or summarise logs (until such a software is adapted to
support non-english messages).
What would you chose?
Regards
Javier
[1] There is other more domain-specific log analysis tools (for webservers,
firewalls and mail servers) in Debian but many of that software users
logfiles in a standarised (or propietary) format that is not (typically?
easily?) parseable by humans.
[2] Or Sawmill (but, even if it's a really good and cheap log analysis tool
it still is not free and, consequently, out of our scope)
signature.asc
Description: Digital signature
Re: Downgrading the priority of nfs-utils
On Thu, Dec 21, 2006 at 06:51:58PM +0100, Michelle Konzack wrote: > Am 2006-11-07 04:40:21, schrieb Goswin von Brederlow: > > But wouldn't you be surprised if "mount -tnfs server:/path > > /local/path" suddenly wouldn't work anymore in a fresh install? > > No, it works, but since "portmap" is not more (since Sarge) > installed by default it need arround 60-300 seconds to mount > but after this time, it is there. Are you sure it's not installed? It's Priority: standard so if the user (in tasksel) selects 'standard' he *will* get the portmapper. Not sure right now what happens if he selects another task but, at least in Sarge, since fam (installed because of dependencies in the GNOME task [1]) depended on the portmapper it would get installed in that case too. From what I see in tasksel's sources, the same should be true for Etch too. Right? Regards Javier [1] More precisely the dependency of gnome-desktop-environment which is part of the 'gnome-desktop' task signature.asc Description: Digital signature
Re: localisation in system wide daemons
On Wed, Nov 29, 2006 at 07:33:20PM +0100, Nico Golde wrote: > Hi, > Adam Cécile reported #400719[0] to the fetchmail package. > > The question is wheter a system wide daemon should care > about the system wide locale configurations or not. I'd say yes, since if the daemon spits out messages (either error or logs) the admin will want it to use the system's locale. BTW, IIRC currently the system's wide locale is set only by the locales package and introduced in either /etc/default/locale (glibc 2.3.6-5 and later, which means etch or later) or /etc/environment (woody or earlier) by it's postinst. Only a few (in my system) init.d scripts read this one in. > Fetchmail currently does, we are not calling it with > LC_MESSAGES=C or something similar. But are you sourcing the system's locale or are you depending on the locale of the user *starting* fetchmail? > I can't find anything about this in the policy but to me it > doesnt make sense to use a locale if you dont want it for > some programs. Why would you *not* want a locale? If the program has l10n support and it provides messages (even in a non-interactive way) there's chances some users will benefit from the translated messages. > Since it would be also possible to adjust the settings with > LC_ALL=C in /etc/default/fetchmail I just closed the bug but > reopened it now cause I want to hear some other opinions. > What do you think what is the best way here? I suggest you introduce a variable in /etc/default/fetchmail named "USE_SYSTEM_LOCALE" and do that (source the system locale if it exists) if set to 'Y'. That's better than forcing users to introduce the system locale in every /etc/default/XXX file and it also makes it easier to switch a system's locale (no need to touch in many different /etc/default/ files, just the 'locale' itself). Set the default to whatever you feel comfortable with. Just my few cents. Regards Javier signature.asc Description: Digital signature
Re: Ifupdown 'extra' package with network ({pre,post}) testing scripts
On Tue, Aug 15, 2006 at 07:41:54PM +0200, Javier Fernández-Sanguino Peña wrote:
>
> I have written and collected some network testing scripts in a new
> 'ifupdown-extra' package which is right now available in
> http://people.debian.org/~jfs/ifupdown-extra
>
> This package provides additional scripts for ifupdown to test for some common
> problems when setting up interfaces:
(...)
I wrote this email a long time ago and I've finally decided to make this
package available at 'experimental'. The latest releases even fixes some bugs
(:-O). I would really appreciate other's testing the network-test script as
well as the other scripts provided (which run when an interface is ifup'd)
If anyone (beside Loïc Minier, which already offered some scripts of the
'vlan' packag) wants to move over network-related scripts to ifupdown-extra
to make them available post-etch [1] please contact me (or file a bug
report).
'Network-test' [2] could, of course, be rewritten into a more user-friendly
application (and even provide a {G,}UI) instead of being an ugly text-only
undecipherable application. If somebody feels like rewriting it in Perl or
Python by all means, do so! :)
Regards
Javier
[1] I will not put it into stable until then
[2] No project page at Alioth yet, if there's enough interest I'll put it all
up in a repo there.
signature.asc
Description: Digital signature
Re: Bug#398793: [Adduser-devel] Bug#398793: adduser: Non system wide readable (home) directories should not be 751
On Fri, Nov 17, 2006 at 01:04:31PM +, Stephen Gran wrote: > > As others have pointed out, umask is probably the correct way to make > sure that your files are not world readable. This could trivially be > added to /etc/profile or something. Yes, there are multiple ways to change Debian's default umask, all of those are listed in the "Securing Debian Manual": 4.11.11 Setting users umasks http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.11.11 If there any alternatives I've missed please say so. Regards Javier signature.asc Description: Digital signature
Re: Bash /dev/tcp and /dev/udp
On Thu, Nov 23, 2006 at 11:02:15PM +0100, Julien Cristau wrote: > On Thu, Nov 23, 2006 at 22:54:59 +0100, Javier Fernández-Sanguino Peña wrote: > > > Then the manpage should be ammended and those things removed. It does not > > make sense to disable things and ship a manpage that implies that they do > > work. > > > Did you look at the bash manpage? > >NOTE: Bash, as packaged for Debian, does not support using the /dev/tcp >and /dev/udp files. Yes, but I missed that paragraph. Javier signature.asc Description: Digital signature
Re: Bash /dev/tcp and /dev/udp
On Thu, Nov 23, 2006 at 02:09:33PM +0100, Jan C. Nordholz wrote: > Hi Klaus, > > > >from the bash manpage: > > /dev/tcp/host/port > > /dev/udp/host/port > > This has been discussed several times [1][2], and the outcome was every time > that this should not be a feature of the shell, but of more specialized > tools like nc. Use those or recompile your bash. Then the manpage should be ammended and those things removed. It does not make sense to disable things and ship a manpage that implies that they do work. Regards Javier signature.asc Description: Digital signature
Re: Debian Archive Automatic Signing Key (4.0/etch)?
On Wed, Nov 22, 2006 at 07:22:35AM +0100, Andreas Tille wrote: > But Hendrik Sattler is perfectly right and this knowledge has to be stored > at prominant places like: > >a) installation manual >b) apt-key.8 >c) perhaps somewhere else It is already at the "Securing Debian Manual", see section 7.4 'Package signing in Debian': http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign I guess that qualifies for c). Of course, it could be improved, that's what patches are for. /me goes to waiting mode :) Regards Javier signature.asc Description: Digital signature
Re: Lots of (easily recognisible) spam sent to the BTS today
On Wed, Nov 01, 2006 at 03:43:06PM -0800, Don Armstrong wrote: > On Thu, 02 Nov 2006, Javier Fernández-Sanguino Peña wrote: > > a) for mails to -close or to [EMAIL PROTECTED] to prevent a > >spammer/malicious person from closing all the bugs or mangling > >with the BTS in such a way that would take us some effort to > >recover > > There's no reason to restrict control; spam sent there doesn't really > do anything at all. Indeed, to this point, we have only occasionally > had problems with control, generally of the BTS ping-pong variety > which tends to be best dealt with with a bit of social engineering. I was not only suggesting closing it to spammers, I was also suggesting blocking it to non-legitimate users which might mangle with control in insane ways (on purpose). True, I have not yet seen that before, but I'm afraid our BTS would have little resilience if it was targeted by some Debian-hater due, precisely, to it's openness. > Messages to -close are slightly more annoying; we could increase the > default score of messages to control, and rely on the negative scoring > rules to keep legitimate messages but that would, again, result in > more false positives. I (and AFAIK, the rest of the BTS admins) are > rather wary of gratitously increasing the numbers of false positives. > [And yes, messages sent by scripts or people who haven't learned to > jump through the right hoops are clearly false positives.] Still, there could be a "warning period" before starting to reject those mails sent to -close that lacked whatever we decided on (be it a GPG signature or a Pseudo-header). And even in aggresive mode I guess that it would be possible to send bounces based on the scoring of messages (those that 'look' like they are legitimate but fail the checks are bounced with a warning, those that do not look like they are *and* fail the checks go to the bit bucket). Just my few cents. Javier signature.asc Description: Digital signature
Re: Lots of (easily recognisible) spam sent to the BTS today
On Tue, Oct 31, 2006 at 11:51:16PM -0700, Bruce Sass wrote: > > Decreasing the score at which we ignore messages is trivial, but it > > means increasing the number of false positives. [And because > > backscatter is bad, these will be messages which just "disappear", > > unless some (massochistic) person actually goes through the spam > > mailboxes.] > > Ya. I generally don't like anti-spam techniques because they require > either the sender or recipient to jump through hoops, or are prone to > false positives... but limiting interaction with the BTS to > pre-verified users (as requiring signed messages by DD's would do) is > an even smaller (as in harder to jump through) hoop than requiring a > specific, easily reproduced with any MUA, format for messages sent to > the BTS. When I have suggested that (sending signed messages to the BTS to be accepted for processing) it was a) for mails to -close or to [EMAIL PROTECTED] to prevent a spammer/malicious person from closing all the bugs or mangling with the BTS in such a way that would take us some effort to recover b) restricted to providing a signed mail, not necessarily with a signature in the DD keyring. (this could be added later on to prevent abuse, if needed be and could still have a 'whitelist' of valid keys which could include non-DDs) If there's a non-DD playing with the BTS (closing bugs or using control@) I guess it's not really too much to ask for them to use signed e-mails when fiddling with it. Is it? Regards Javier signature.asc Description: Digital signature
Re: Lots of (easily recognisible) spam sent to the BTS today
On Mon, Oct 30, 2006 at 10:50:51PM +0100, Kurt Roeckx wrote: > > If you have an idea for a new spamassassin rule that will get a > > current spam run without triggering on non-spam, send it to > > [EMAIL PROTECTED] Unfortunatly, much spam is now using anti-bayes tecniques > > and is hard to catch without also getting non-spam. > > > > I do see each message with a SA score >= -1, but at times I've been > > days behind slogging through them. > > Does that mean that we shouldn't report spam we see in the BTS? If I > now see spam going to a bugreport of mine, I always go and press the > "this bug log contains spam". Should I just not bother with it? BTW, could it be possible to provide an alternate interface to submit spam? (like the 'report-listspam AT lists.debian.org' we can bounce spam from the mailing lists to) I do get a lot of spam for BTS entries (mainly for www.debian.org entries) and the quantity has increased somewhat recently. I've found that when I go to bugs.debian.org/#Bugnumber to report it the spam has been already removed (good). However, confirming each spam I have in my mailbox vs. the web interface is time consuming and slightly frustating when you find that the spam had no opportunity to get in (the bug was archived) or it was already removed (bad). Would it be possible to have a 'bounce spam' mail address that could use the Message-ID in it to add it to the list of spams you already process? If not it would be nice to at least, have an interface to submit a bunch of Message-IDs that have already been determined to be spam (by a human being that has received the backscatter) Thanks for your efforts in pruning spam off the BTS. Regards Javier PS: If abuse of that (e-mail) interface was of concern it could be implemented so as to only consider GPG/PGP signed mail from DDs (I don't see that the web interface takes any precaution against being abused, from what I can tell, but a e-mail gateway is slightly more easier to abuse) signature.asc Description: Digital signature
Re: Lots of (easily recognisible) spam sent to the BTS today
On Fri, Oct 20, 2006 at 07:10:20PM -0400, Kevin Mark wrote: > Hi Javier, > On Sat, Oct 21, 2006 at 12:05:58AM +0200, Javier Fernández-Sanguino Peña > wrote: > > > > I'm not sure if anybody else is seeing this but I have seen (just today) 28 > > spam messages sent to the BTS. I've received them because they were all sent > > I've seen BTS spam before and ask the list admins about it. I have seen it too, it's just that yesterday it blew out of proportion. > Does BTS mail have identifiable header and/or body characteristics to > determine what is legitimate? Does all mail to the bts come from: debian.org > mailers, reportbugs or some identifable sources that would make > legitimate email identifable? Currently, anyone with a legitimate e-mail address can send a bug report (properly formatted, so it's more difficult for SPAM to open bugs) to [EMAIL PROTECTED] or append information to a bug (no formatting required, so it's rather easy for SPAM to get there) by sending it to [EMAIL PROTECTED] I'm more concerned by the fact that spam can close bugs, for reference read: http://lists.debian.org/debian-devel/2002/05/msg00113.html http://lists.debian.org/debian-devel/2004/03/msg00847.html http://lists.debian.org/debian-devel/2005/07/msg01106.html AFAIK, here's currently no technical measure in place (X-Header required, whitelist of valid senders, GPG signature) that prevents spammers from hitting [EMAIL PROTECTED], so when that happens it has to be delt with manually (like it recently happened with [1], but there have been occassions where it has been more aggresive) Regards Javier [1] http://lists.debian.org/debian-policy/2005/09/msg00064.html signature.asc Description: Digital signature
Lots of (easily recognisible) spam sent to the BTS today
I'm not sure if anybody else is seeing this but I have seen (just today) 28 spam messages sent to the BTS. I've received them because they were all sent to (at least) the 'www.debian.org' pseudo-package, and I have reported all of them in the BTS' spam interface [1] They also seem to share common carachteristics: a) Subject fits the regexp: ".* note|letter|message\. You .* read\." b) The MTA it claims to be: "X-Mailer: Microsoft Office Outlook, Build 11.0.*" c) The first two lines of the body fit these regexps: The great .* are .*\. The increase is up to 70%.* I'm pretty sure this spam has probably found a place in many other BTS entries, I was just wondering if the BTS admins have noticed and placed appropiate measures in place (I'm sure they have, but just in case). Regards Javier [1] In Bugs #184006, #183585, #189173, #189157, #188865, #188617, #100363, #99160, #193540, #193106, #177897, #177523, #258918, #263535, #180196, #180118, #10520, #103975, #182337, #182700, #151147, #150474, #153701, #153644, #204105, #203950, #182773, #183585, #177215, #177200, #99156, #98811, #99438, #99160, #131338, #130325, #168601, #168695, #152955, #152609, #118834, #118592, #100148, #100148, #197674, #197392, #147575, #147164, #101772, #102186, #101772, #101870, #180196, #180118 signature.asc Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
On Wed, Oct 18, 2006 at 03:57:26AM -0400, Roberto C. Sanchez wrote: > I agree that a help command and a set of DOS-friendly aliases *should* > be enough, but since MS neutered the command.com interface a long time > ago to the point where it ceased to be useful, I don't see how having > such things would be helpful to any but a diminishingly small minority > of users. You are confusing "interface" and "content". Let me explain how 'ayuda' worked again, maybe that can help see why Jason's idea. 'Ayuda' had two things: - a shell script using dialog(1) to display a set of menu options - newbie-oriented documentation (some of it Debian-specific) in /usr/share/ The shell-script read the documentation and provided the interface when 'ayuda' was written in the CLI. Now, considering the *need* to have newbie-oriented Debian-specific documentation for users (regardless of their environment) how about a package that provides: [1] newbie-oriented documentation (most of it Debian-specific) in /usr/share (Of course, i18n/l10nized) [2] an integration layer (an index file pointing to the HTML files?) with GNOME's yelp and KDE's 'khelpcenter' so that the information is show along the main Help topics and can be browsed when people go to their Desktop and select 'Help' [3] a stand-alone 'helpme' program that, when executed, would detect if the user was running in a console (no $DISPLAY) or not and provide an interface to the topics in the provided documentation. The 'Newbiedoc' package does not cut it, it just does [1] and it is not even Debian-specific. The 'doc-debian' (the Debian FAQ), 'debian-reference' or 'quick-reference' packages do not cut it either, they do most of the things needed for [1] but they only integrate with doc-central/dwww/dhelp which most (newbie) users will not even be aware they exist. There is no (easy?) way to access that documentation (if installed locally) from the Desktop (i.e. no [2]). For Bonus points, the user (if in an Internet-connected system) using [3] should be able to send "questions" not covered in the documentation through the same UI that could be collected somewhere and used by the maintainer(s) to decide which unwritten topics should be taken care of since they are most demanded by users. If someone wrote the package providing [1], [2] and [3] and it was made part of a standard installation we could ask Santiago (base-files' maintainer) to change /etc/motd and point to it. How does that sound? Anyone up to the challenge? Regards Javier signature.asc Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 11:48:33PM -0400, Jason Spiro wrote:
> >I remember back in 2000 providing a Debian package called 'ayuda' ('help',
> >in
> >Spanish) developed by members of my local IEEE Student Branch. This
> >package
> >included just a simple shell script ('ayuda') and a number of text files.
> >When the script was called it would show up a dialog(1) menu a user could
> >navigate and use to access the manuals included. ...
> >I guess it would be nice to have something similar.
>
> Interesting idea. But, since a) most people have web access nowadays
> and b) people with no web access in a new Linux install can reboot
> into Windows if they need web access, therefore I personally wouldn't
> want to maintain such a package. Of course, you could get such a
> script into Debian yourself (maybe in package debian-goodies or
> elsewhere) if you wanted.
If you do a Debian install and, for some reason, don't get X configured you
don't want to tell people "reboot into Windows and look for help". I, for
example, don't have a Windows partition available. As for the script, I
already provided it in Debian (5 years ago) but it was
a) Spanish-specific
b) not supported by a community
All that I'm saying is that it would be great to start a Debian community
project that was not language-specific and supported and get *that* into
Debian.
> >Since there is no package providing that tool I would say 'general'.
> >However,
> >filing bugs vs. general doesn't mean they will get fixed by themselves. I
> >think that it would be much better if somebody sat down and wrote a "Debian
> >help" system that provided some Debian-specific things and integrated
> >properly with both gnome-help and khelpcenter.
>
> Is more Debian-specific help really needed for KDE/Gnome users? IIRC
> Synaptic comes with Gnome help files. Also, there are already lots of
> HTML-format manuals for Debian.
What I'm saying is that users using GNOME's help system or KDE's help system
cannot find a single bit of advice specific to Debian since *our* help system
(dwww/dhelp/doc-central) does not mesh in with theirs. So if a user (in
GNOME) goes to the task bar and selects 'Desktop->Help' he can, at most,
access the local manpages but there is no 'Debian' section there.
Try running 'yelp', look at the topics and try searching for 'Debian'. You'll
see what I mean. This is not GNOME-specific, BTW, IIRC the same happens with
KDE help center. I'm just saying that a Debian-specific help should be added
to both systems (and should provide the same contents).
Regards
Javier
signature.asc
Description: Digital signature
Re: How can the OS autodetect that a user is a newbie and offer help?
On Tue, Oct 17, 2006 at 01:02:45PM +, Jason Spiro wrote:
> Hi all,
Hi there.
> For example, when a person types newbie commands like "help" or "kde"
> (which is bound to something already) or the DOS commands "del" or "ren"
> (which are not), we should point them to more help. (In case anyone here
> has ever watched a real clueless newbie struggle: What are other
> commands that 100% clueless newbies often type?)
I think 'help' is by far the most common one ('?' might be close too).
Currently 'help' brings bash's help which might not be what a newbie
expected. Some (older?) people might even try pressing F1 and see what
happens [0].
I remember back in 2000 providing a Debian package called 'ayuda' ('help', in
Spanish) developed by members of my local IEEE Student Branch. This package
included just a simple shell script ('ayuda') and a number of text files.
When the script was called it would show up a dialog(1) menu a user could
navigate and use to access the manuals included. Manuals were ordered in
'user', 'admin' and 'programming' topics. The 'user' topic would tell him how
to use shell commands, read e-mail, use a text editor (Joe, Vi or Emacs), and
configure his environment.
It would also tell the users how to use the system's proper documentation
(manpages and info) and it would also point to more documentation (HOWTOs and
locally installed documentation).
The tool was abandoned and, after trying to get some community development, I
removed it from Debian.
I guess it would be nice to have something similar. You cannot replace 'help'
(if using Bash, Bash will answer) but a package could provide a 'helpme'
command [1][2] which did something similar.
Right now such a help program should work both in a console and in an X
display (if it detects one) should point users also to the documentation
available in Desktop environments (if available), to (Debian-specific)
documentation packages (like 'doc-debian' or the 'quick-reference') and to
(Debian-specific) use of dwww/dhelp/doc-central.
> What would be a good help text to offer when a user types a command that
> indicates he/she is a newbie? Also, what package should I file a
> wishlist against to request that such help be added?
Since there is no package providing that tool I would say 'general'. However,
filing bugs vs. general doesn't mean they will get fixed by themselves. I
think that it would be much better if somebody sat down and wrote a "Debian
help" system that provided some Debian-specific things and integrated
properly with both gnome-help and khelpcenter.
Regards
Javier
[0] Many MS-DOS programs (such as Wordperfect, Lotus 1-2-3 and the like)
mapped F1 was always mapped to the 'help' key. This is still true in many
(desktop) environments and applications.
[1] At the very least:
$ cat helpme
#!/bin/sh
echo "Don't panic!"
[2] Bonus points if someone figures a way to l10n that 'help' call, since
non-english spearkers might write something different such as: 'ayuda',
'hilfe', 'aide', 'aiuto', 'ajuda', etc.
signature.asc
Description: Digital signature
Re: Orphan party, relax...
On Sun, Oct 15, 2006 at 06:38:16AM -0400, Roberto C. Sanchez wrote: > > > > But now, I can stop! There will be people doing my work! And they will > > win money! They will do my translations on debian installation manual, > > on the debconf templates, they are going to close my RC bugs and other > > non important bugs. > > > > > Well, if your translations are the Spanish translations (I am guessing > by your name), please email me off-list. I would gladly take them over. AFAIK he has not contributed to the Spanish translation at all. Anyone reading over http://d-i.alioth.debian.org/l10n-stats/translation-status.html would not have any trouble finding who is taking care of that one. Regards Javier signature.asc Description: Digital signature
Re: Help offered
On Fri, Oct 13, 2006 at 12:00:00AM +0200, Daniel Leidert wrote: > HXC wrote: > > > I would like to help with the debian.org website. I have a bachelor > > degree in communication management. Is there help needed and if so where > > do I start / who do I contact? > > A starting point could be to send bug-reports against the www.debian.org > (or similar: bugs.debian.org, lists.debian.org, ...) pseudo package(s): > http://bugs.debian.org/www.debian.org No need to file bugs, you can subscribe to the debian-www mailing list and start throwing out ideas there and sparking discussion. Getting consensus on future changes from the people involved in the website development is much better than opening bugs IMHO. Regards Javier signature.asc Description: Digital signature
Re: debian-policy: New virtual package: cron-daemon
On Sun, Oct 08, 2006 at 09:48:01PM +0200, Clément Stenac wrote:
> Hi,
>
> > [ Debian-specific feature ]
> > - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
>
> Don't we support these by using entries in /etc/crontab and run-parts
> for all cron systems, which would make this requirement void ?
'We' as in Vixie Cron? Yes, but I want to list it explicitly since
/etc/crontab is shipped by cron and I would not consider a replacement that
did not execute the scripts there (imagine a replacement that shipped an
empty /etc/crontab or did not ship one at all [1]). Notice that there's is
nothing preventing a cron replacement to handling those directories by itself
natively (i.e. without using /etc/crontab lines).
Regards
Javier
[1] Of course, if /etc/crontab were provided as a configuration file of a
different (standard) package this issue would be side-stepped.
signature.asc
Description: Digital signature
debian-policy: New virtual package: cron-daemon
Package: debian-policy
Priority: wishlist
Hi all,
It was suggested to me (#349170) that we should use a virtual package
'cron-service' to make it easier to people to switch between different cron
implementations. Currently in Debian there are three of them available:
vixie-cron, which is our current standard, fcron and bcron (Bruce's cron).
Many packages that currently depend on 'cron' depend on 'cron | bcron', if a
new cron replacement (such as mcron, xcron, chronic or upstart) gets into
Debian all those packages need to be modified to Depend on: 'cron | bcron |
fcron | mcron | upstart | chronic', making transitions a pain and forcing
admins to play with the package system to satisfy dependancies.
Now, we *used* to have a 'cron-daemon' virtual package but it was removed
from Debian policy (in version 3.6.2.2) since the previous cron maintainer
wanted policy to clarify what it should 'mean' (see #257726)
I propose re-adding 'cron-daemon' with the following requirements (that will
need to be written down similarly to the 11.6. section "Mail transport,
delivery and user agents"):
[ POSIX ]
- Has to provide /usr/bin/crontab and support crontab entries
[ Implemented in most Linux / BSD distributions, including Debian, but not
in Solaris, HP-UX or AIX's cron ]
- Correct execution of /etc/cron.d
- Correct support of /etc/crontab
- Correct support of /etc/cron.{allow,deny}
- Has to support 'crontab -u'
- Support of crontab entries with extended features (i.e. those in Vixie
Cron need to be supported), these include names for days and months,
ranges, step values and the 'special strings' (@reboot, @yearly..)
[ Debian-specific feature ]
- Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
Does anyone oppose this new virtual package?
Javier
PS: Debian-policy people, please CC: me on replies
signature.asc
Description: Digital signature
Re: apt-findremovable v0.4
On Tue, Oct 03, 2006 at 11:24:14PM +0200, Jan Kechel wrote: > Ron Johnson wrote: > >>> have fun trying it. > > > > Thanks. Is a single perl script worth packaging, though? > > since v0.4 its even seems to be working correctly :) > http://prevalent-digest.de/apt-findremovable/ > > I guess that's also the final version (at least until somebody finds a > bug or sends me a patch/feature request). Maybe this tool could go into the 'debian-goodies' package. If you send me that (or better, to the BTS) together with a manpage I will include it there. Regards Javier signature.asc Description: Digital signature
Re: Debian Women Wiki (was: No Config-Files state even though postrm purge failed while purging an installed package?)
On Tue, Oct 03, 2006 at 10:54:02AM -0300, Margarita Manterola wrote: > If you think they are useful, by all means go ahead and put them > somewhere else. It's free documentation, you can do with it whatever > you like. > > I do not feel that it is my duty to put these diagrams in the main > Debian wiki, just because I made them. Not picking on you but... The fact that Developer's do not consider their duty to contribute effort to improve to the status of documentation in the Debian project is one of the reasons why http://www.debian.org/doc/ is not as good (in breadth and scope of available, up-to-date and maintained documentation) as Gentoo's [1], FreeBSD's [2], RedHat's [3] or (gasp) Ubuntu's [4] available (i.e. official) documentation. At least we are better off than Fedora's [5] or OpenBSD's [6] (Although our (unofficial) manpage search engine [7] is worst than OpenBSD's [8]) Regards Javier [1] http://www.gentoo.org/doc/ [2] http://www.freebsd.org/docs.html [3] http://www.redhat.com/docs/ [4] http://www.ubuntu.com/support/documentation [5] http://fedora.redhat.com/docs/ [6] http://www.openbsd.org/docum.html [7] http://manpages.debian.net/cgi-bin/search_man.cgi [8] http://www.openbsd.org/cgi-bin/man.cgi signature.asc Description: Digital signature
Re: Debian Women Wiki (was: No Config-Files state even though postrm purge failed while purging an installed package?)
On Mon, Oct 02, 2006 at 10:32:23AM -0300, Margarita Manterola wrote: > >May I ask why information this important is not on the main Debian > >wiki, wiki.debian.org? > > It was born in the Debian Women wiki, because I felt much more > comfortable doing this documenting process inside the Debian Women > than doing it in the main Debian project wiki. It could be copied to > the main wiki now, but I'm not sure if it would make any differences. It would be more visible, please might search wiki.debian.org for that information. > Also, as to the question of why is it a wiki, it's because wikis are > easier to edit and update than established documentation. The > documentation that can only be edited by a few is bound to get > outdated quickly. I wonder why do we then have a CVS any developer can get access to that provides all the Debian documentation (DDP) as well as a CVS for all the website any Debian developer (and even non-DD) can easily contribute to. I would urge to go read http://www.debian.org/doc/ddp, if you have not done so already. If you dislike the current documentation development system in Debian, by all means, go ahead and improve it or make suggestions of how it fails in the appropiate mailing list, but do not actively work against it just because you don't like it. The former, if enough people worked on it, might eventually get us a better documentation system in the long term with up-to-date documentation that is maintained and current, the later will just lead to fragmented documentation all over the world wide web, disconnected, unmaintained and is a disservice to our users. Regards Javier PD: Notice that I'm not implying that a wiki is not a good resource for a OSS documentation system (my opinion is quite the opposite), I'm just saying that writting up documentation in two different wikis, at people.debian.org, at people's blogs and what not is not the best way for us (as a group) to provide documentation to our users. signature.asc Description: Digital signature
Re: Why are all packages getting so much bigger?
On Fri, Sep 22, 2006 at 02:30:36PM -0400, Nathanael Nerode wrote: > I'm guessing translations. They eat up space really fast. > Is there a way to compare packages after localepurge runs? I would bet on translations and documentation. Maybe it could be possible to automate that analysis and see which filesystem location increased in size? Regards Javier signature.asc Description: Digital signature
Re: transitioning config files between two packages
On Tue, Sep 12, 2006 at 05:21:50PM -0700, Steve Langasek wrote: > After an upgrade and answering all of the conffile prompts, does > /var/lib/dpkg/info/nagios-plugins.conffiles still exist and reference these > files? Depending on what dpkg is really doing here, it may well be possible > to handle the conffile transfer in maintainer scripts. (And I thought > dpkg.org once had recipes for exactly this, but unfortunately the site has > been down for some time now. :/) Are you looking for http://wiki.debian.org/DpkgConffileHandling ? (just found it googling). I guess this information (if current) should be moved over to the developer's reference. Regards Javier signature.asc Description: Digital signature
Re: Manpages in language-specific packages
On Wed, Sep 13, 2006 at 12:46:19PM -0500, Gunnar Wolf wrote: > Hi, > > I'm adopting liblingua-es-numeros-perl, a Perl module for translating > numbers into their Spanish string representation. One of the first > things I noticed is that the manpage is completely (and only) written > in Spanish. So, besides sending any changes I do to the upstream > author (although the module looks unmaintained, with only version 0.01 > existing since 2001), what would be wisest? Translate the manpage to English, distribute that in /usr/share/man/man[1-9] and put the Spanish manpage at /usr/share/man/es/man[1-9] (where it should be). That way non-Spanish users installing the program will have a manual page and Spanish users will be able to read it properly (if their locale is configured properly) > - I18N in manpages? Sorry, haven't been there, haven't done that It's not that difficult, just put the (english) manpage in /usr/share/man/ and the i18n manpage in /usr/share/man/XX. Man takes care of the rest. Regards Javier signature.asc Description: Digital signature
Re: Status of inetd for etch
On Tue, Aug 15, 2006 at 10:29:46AM -0400, Jim Crilly wrote: > On 08/15/06 09:49:54AM +0200, Andreas Metzler wrote: > > Hello, > > This seems to be totally overengineered. Having MTA a provide sendmail > > which uses MTA b for remote deliveries is no common usage scenario on > > which any effort should be spent in the Debian packaging > > infrastructure. It is a common usage scenario for e-mail delivery in bastion hosts. > > Actually the only sane explanation for wanting to install two MTAs I > > ever heard of was "I am running X now and want to switch to Y. - I'd like > > to test Y in the real system before going live." > > > > I know of at least one firewall product that includes 2 copies of sendmail, > one for accepting messages from the Internet and one for processing and > sending them to the internal servers. They do this along with an RBAC > system like SELinux so that break into the network via sendmail is > virtually impossible since even if you break into the externally accessible > sendmail you can't go any farther. Whether Debian should work on making > this possible too or not, I can't say. Actually, the first firewall product that implement that was TIS' Firewall Toolkit (fwtk), the first open source firewall (later converted into the commercial Gauntlet firewall), probably the most ancient firewall, used in the first connection of the White House to the Internet [1]. It was actually a really good design decision to use sendmail for delivery and smapd for e-mail reception [2], unlike sendmail, not that many (security) bugs were found in smapd [3]. The same type of good design that has postfix have multiple different daemons to isolate errors and contain damanage. I'd say that Debian should make it possible to have that kind of setup. Just my 2c. Javier [1] http://en.wikipedia.org/wiki/Trusted_Information_Systems [2] http://www.fwtk.org/fwtk/docs/mjr-slides/sld073.htm [3] AFAIK, only CVE-2001-1456 (which was severe, however, since at the time no RBAC or MAC system was implemented in Gauntlet) signature.asc Description: Digital signature
Re: Ifupdown 'extra' package with network ({pre,post}) testing scripts
On Wed, Aug 16, 2006 at 02:36:52PM +0200, Emanuele Rocca wrote: > Hello Javier, Hi there. > > This package provides additional scripts for ifupdown to test for some > > common > > problems when setting up interfaces: > > > > - interfaces without a link (admin can have that condition abort interface > >setup if he wants the behaviour described in #120382) > > Very nice. > The test could be added to ping-places.sh (provided by ifupdown as an > example), otherwise mapping stanzas using it to choose a logical > interface will try to ping addresses using an interface which may be > down. Could do. > What about putting the code which checks the link status in a separate > script, so that it can be used elsewhere? It's pretty standalone right now. You just have to run it as root as this: # IFACE=eth0 /etc/network/if-pre-up.d/check-network-cable The meat is, however, in the check_status() functions so they could move elsewhere and create a script that used $1 instead. > > This package also provides 'network-test', a script to test the network > > configuration status by checking: > > - Interface status > > This feature is not working properly here. Yep, sorry, the network-cable test in that one is still flacky, it should reuse the code in the 'check-network-cable' script (i.e. use 'ip link show' and look for NO-CARRIER, or use mii-tool or ethtool). I've fixed and made available a new version up at people.debian.org (package version 0.2 now) Regard Javier signature.asc Description: Digital signature
Ifupdown 'extra' package with network ({pre,post}) testing scripts
I have written and collected some network testing scripts in a new 'ifupdown-extra' package which is right now available in http://people.debian.org/~jfs/ifupdown-extra This package provides additional scripts for ifupdown to test for some common problems when setting up interfaces: - interfaces without a link (admin can have that condition abort interface setup if he wants the behaviour described in #120382) - duplicate IP addresses in the network - setup static routes - detect unreachable network gateways (could be expanded to detect unreachable local network servers) These scripts will run when you ifup an interface and will warn you of these issues (standard error and/or syslog). It also provides the network-test script which currently resides in the debian-goodies package. The main reason for this package is that, even if I took over debian-goodies and introduced 'network-test' there, I don't want to pollute its dependencies with lots of IP utilities just to have that testing script work. I've thought that the best way is to move it over to some other package even if that means adding a (versioned) Conflict: to debian-goodies. Here's the control file: Package: ifupdown-extra Architecture: all Depends: iproute, iputils-ping, netcat, arping, ethtool, net-tools, bind9-host Conflicts: debian-goodies (<= 0.25) Description: Network scripts for ifupdown This package provides a set of network testing scripts to be used together with the ifupdown package. These scripts can: - check the network cable before an interface is configured - test if an assigned IP address is already in use in the network - test if default network gateways are reachable - setup default static routes for interfaces . This package also provides 'network-test', a script to test the network configuration status by checking: - Interface status - Availability of configured gateway routes - Proper host resolution (DNS checks) - Proper network connectivity, including ICMP and web connections to remote web servers. Could some of you test this package and tell me what you think of it? Javier PS: Funnily, it seems that SuSE does have the ARP ping test in their if-up.d directory whilease Fedora/Red Hat does not have anything like that. Even though that test will introduce a small delay on bootup I think it's worth it (and users can easily disable it through /etc/default/network-test) signature.asc Description: Digital signature
Re: New desktop features provided by new version of update-notifier
On Sat, Aug 12, 2006 at 08:29:13PM -0300, Gustavo Noronha Silva wrote: > The second feature is quite cool; update-notifier uses hal to detect > that a new CD/DVD was inserted and tries to figure out whether that is > a Ubuntu CD; I patched the program to also look for Debian CDs, and to > avoid messing with translations, the messages have Ubuntu replaced by > Debian in runtime, after the translation is got from gettext if the CD > that was inserted is a Debian CD. Please don't mess with gettext this way. You should ask Ubuntu people to rewrite the lines so that the 'branding' is removed or, at most, is handled by a variable that *is* replaced at runtime (this is what was introduced in Debian Installer). If you do string-based replacement you are going to miss (or break) non-ASCII based languages (think Japanese or Chinese). Regards Javier signature.asc Description: Digital signature
Re: Proposal: searchable d.o/security/
On Sat, Aug 12, 2006 at 12:02:31AM +0200, Nico Golde wrote: > Hi, > today I searched for a specific DSA and its really pain if > you just know the package but no DSA number (correct me if I missed > something). What kind of search are you trying to do? Package to DSA? Bug to DSA? If so, it would not be difficult to have a page listing all packages and the DSAs issued to them (it might be a little bit large though). Would that cover your need? Regards Javier signature.asc Description: Digital signature
Re: Status of inetd for etch
On Fri, Aug 11, 2006 at 12:46:44AM +0200, Adam Borowski wrote: > > netbase: > critical network configuration. > It has some ancient cruft like /etc/services (which does more ill > than good), but /etc/init.d/networking is not something one wants to > skip. Why do you believe that /etc/services in netbase does more ill than good? > It would be good to get rid of inetd from the basic install at all. Those (...) I agree with that, many installs do not actually need inetd, actually, few need some of the default services (identd) provided in stock inetd. IMHO netkit-inetd should be moved from 'important' priority to 'standard'. Regards Javier signature.asc Description: Digital signature
Re: A question on setting setuid bit
On Fri, Jul 07, 2006 at 04:42:47PM -0400, LEE, Yui-wah (Clement) wrote: > Hi, > > This is an experimental package that we built and > evaluate internally (up to this moment). The program > that needs setuid is a cgi-bin program that is invoked > by apache2, which runs as a regular user www-data. The > cgi-bin program however needs to interact with > iptables. You are setting up an iptables interface through a setuid *root* cgi-bin? If so: ! > I know setuid programs are risky but I haven't got the > time to address the security risk yet (one thing at a > time ... :-) I can do the security risk analysis for you: granting remote root through a web server application is a recipe for disaster, those tactics where (or should have been) abandoned ages ago. Either you make really damn sure that the cgi-bin is not exploitable through fascist input data validation and a tight SELinux policy or you remove the setuid bit and try to make the functionality you need through other mechanisms. For example: a cgi-bin that locally communicates with a separate daemon and asks it to "pretty please" setup an iptable rule, if you do this the separate daemon can be very strict in which it permits and can do additional data validation, additionaly, a failure in the cgi-bin (i.e. a buffer overflow or similar programming mistake) does not equal to a remote root compromise (at most a remote www-data although that's bad enough already). Just my 2c. Javier signature.asc Description: Digital signature
Re: Hidden files
On Tue, Jun 06, 2006 at 05:00:26PM +0300, Linas ??virblis wrote: > Mike Hommey wrote: > > > Could you tell us what kind of harm can do a "hidden" empty file in /usr ? > > First of all, false positives in rootkit and security scanners. And too > many false positives lead to false negatives sooner or later. That's a bug in the rootkit and/or host-based scanner. A "hidden" file is in no way indication of a rootkit or malicious software installed. Sure, some rootkits do use hidden files, but if you have a rootkit-detector software you don't want to flag a *big* alarm [1] if you see any of those. Regards Javier [1] Tiger, which could be considered a host-based security scanner, will flag a *medium* alarm in some instances of hidden files but will not inmediately say that's a security issue. signature.asc Description: Digital signature
Re: Summary of Debconf i18n/l10n activities
On Tue, Jun 06, 2006 at 03:21:45PM -0300, Gustavo Franco wrote: > Nice, thanks. While we're at this subject, what's your view on the > Ubuntu language packs? Are we going to extract the translations from > the packages creating language packs? It has pros and cons, and > the best thing i see is the possibility to keep translating stuff after > release. Thoughts? I don't know if people have a wrong impression of what language packs in Ubuntu are, I sure did until I looked at the Spanish language pack. It (language-pack-XX) actually is a package that pulls in: - a package (language-pack-XX-base) that provides update locales for *some* applications under /usr/share/locale-langpack/ and uses '/usr/sbin/install-language-locales' in postinst. [ This package Recommends: ] - a meta-package (language-support-XX) that pulls in translations for OpenOffice, Mozilla (Firefox) and the proper dictionary information (aspell-es, wspanish) Glibc is patched in Ubuntu (./debian/patches/ubuntu-altlocaledir.dpatch) to use /usr/share/locale-langpack/ as an alternate PO location. Now, if we wanted to do that in Debian we would need to: - have translation teams be able to check, review and update locales for *sarge* packages (Ubuntu uses Rosetta). This infraestructure we don't have yet. - Create the said packages (and maintain them). This maybe needs to be through an automated procedure, since the new translations are probably in the main package too. - Relax our policy regarding proposed-updates (since that's where translation packs would go to). I don't know if the Stable release managers are open to this (but we could try) - Patch glibc like Ubuntu did (I don't know if that patch would get approved by our glibc maintainers) to use that location. We already cover the meta-package idea (depending on OpenOffice, Mozilla and dictionaries) through tasksel at installation. And we abandoned the idea of using meta-packages Depending: on translations because of all the interdependencies issues (see [1]) If we don't do all of this we are stuck with only being to provide translation-packs (during or post release) with ugly hacks like overwritting files under /usr/share/locale/ (or wherever the program's localised information is) *after* a package installation (and not because of it) [2] Quite sincerely, I don't see that feasible for etch right now. If someone wants to start the ball rolling, however, it's worth a try. Regards Javier PS: We could even do better than Ubuntu and provide proper (c) statements in language-pack-XX-base, since that package's copyright states is (c) Canonical but the translations in those packages are, quite sincerely, not (c) them. They are (c) their translators in most cases (I know, I've done some of them myself!) [1] http://people.debian.org/~jfs/debconf6/html/x321.html#packages Although I need to update that section quite a bit [2] That is, unless you have packages that have a setup similar to KDE's (a main package with the code and separate kde-i18n-XX packages with their translation), Mozilla or OpenOffice (localised information in separate -XX packages). That's probably why Ubuntu's localised-packs packages just Depend: on them to get the updated translations. signature.asc Description: Digital signature
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
On Wed, Jun 07, 2006 at 01:22:56AM +0100, Wookey wrote: > I have no idea what it would take to persuade you that I am who I say I am, > but if you _only_ accept National Passports then it would appear to be > impossible in my case (which I realise is something of a corner-case). I would probably need to interact more with you than just be face to face in a KSP. As I said in my posts to the thread, that is a "generic" rule I apply with people I don't know. If I get to know people, talk to them, interact on- and offline then the ID checks might be more permissive as I have other ways to confirm that they are the real person that has access to the private key I'm going to sign. HTH, Javier signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, Jun 04, 2006 at 04:52:22PM +0200, Wouter Verhelst wrote: > > - something it already had (admins who really wanted Sun's Java could > > always go to java.sun.com and install it themselves or use java-package) > > Well, see, *this* is not true. Sure, it's possible to install Java on a > Debian system; one can even turn a non-free binary java distribution > into a Debian package and install that by using java-package. However, > this is a far cry from > * Being able to install non-free Java on your Debian system, even if the > oldest Java binaries being distributed by the original authors are > more recent than the ones java-package is ready for > * Being able to just install non-free Java by running "apt-get install". > * Being able to upgrade to a newer (fixed) version of Java by just > running "apt-get upgrade" Please RTFM [1], Blackdown has been distributing java packages for Debian through their own APT repositories and mirror network for quite some time. For example check this: # Blackdown Java deb ftp://ftp.gwdg.de/pub/languages/java/linux/debian unstable non-free > But you knew that already, I'm sure. You don't see to be very good at straightening the facts. Thank you. Regards Javier [1] http://www.debian.org/doc/manuals/debian-java-faq/ question "11.1 How can I get Debian packages from Blackdown?" signature.asc Description: Digital signature
Re: Please revoke your signatures from Martin Kraff's keys
On Mon, May 29, 2006 at 02:48:33PM +0200, Wouter Verhelst wrote: > Then there's the issue of tracing who did an actual upload into the real > world. A name on a GPG key is not, by any means, an effective way to do > that, since it does not contain enough information to get out the black > helicopters. Case in point: (...) Useless case, you seem to believe that police officers can only trace and obtain information from people through Google ! I do not know how many cases related to "digital crimes" have you been involved with or know of, so please allow me to enlighten you how it could possiby work: - somebody named X gets a trojan in the Debian archive through a GPG key - SPI (not Debian as it does not have a legal entity in itself) brings the case to a law agency claiming that X has committed a crime - the Police traces X to A, B and C (same names != same people) - the Police gathers evidence that A and B *might* be in possession of the GPG key and might have done the attack (this includes things like information from ISPs linking a telecommunications contract to a name, data from their communication either publicly available or requested to ISPs or servers) - the Police asks for a search warrant, gets into A and B's house and seizes their computers - the Police finds the private key associated with the GPG key in A's computer (maybe even evidences of the trojan itself) Guess who is going to get prosecuted regardless of whether they have the same name? If you think that's science fiction, maybe a tv series plot, or think that law agencies (or judges) are stupid and cannot gather evidence for a case in the digital age then think again [1] Law agencies (in many countries) have enough budget and laws backing them to do that (and more). Given enough damage done by X (=A) through the trojan introduced in the archive or enough money layed down by SPI you bet there would be a thorough investigation of the case. Regards Javier [1] Virus and worm writers have been busted with even less information (when the investigation started) than the information I leak while writting this e-mail. signature.asc Description: Digital signature
Re: Red team attacks vs. cracking
On Tue, May 30, 2006 at 01:40:39PM -0400, Joe Smith wrote: > Is this really a bad thing? He proved that KSP are bad for the web of trust. > A legitimate attacker could abuse the KSP just as easilly as Martin, but > would result in actual damage, and would most likely not have been caught. Ask yourself: is it a good thing to covertly attack X? Is it good to then publish of the results [1] claiming^Wboasting that you have broken X? Do you really need to be proven that X can be broken? Now change X to "KSP" or "Web server of company Y" or "(your country's) national security servers". What are your answers? In the place I work at, attacks are only done either on your head (that's what attack trees [0] and risk analysis are for) or with the keyboard (or phone) after whomever is in charge of X has asked for, acknowledged and *approved* the attack. Why? Because given enough resources (money, time, you name it) most attacks will succeed against X. So the question is not *if* you can break X but *when* and *how* can you break it. The attack is introduced to see if there could be changes implemented to make it more difficult for a wannabe attacker or to detect an ongoing attack and, consequently, minimise the risk. We are not talking about national security or public safety here, if Martin wanted to prove that attacks against KSPs can happen he could have managed his attack in an open way (as Manoj said "contact management and get their approval") and then use that to enlighten us all. What he did is wrong (and dishonest), even if the end result is "good": these long threads, knowledgeable people discussing the effectiveness of KSPs and non-knowledgeable people getting a clue. You might think that "the ends justify the means" [2], I don't. Regards Javier [0] http://www.schneier.com/paper-attacktrees-ddj-ft.html [1] I will call it "publish" even if it was done in a rather obscure way. Not all developers are required to read Martin's blog, they are only required to read d-devel-announce [2] Google found this Wired article for me, which is nice: http://www.wired.com/news/politics/0,1283,58082,00.html signature.asc Description: Digital signature
Re: Red team attacks vs. cracking
On Tue, May 30, 2006 at 10:32:15AM -0700, Thomas Bushnell BSG wrote: > I am actually quite ambivalent about whether I think what he did was > wrong; I think to determine that I would need to read carefully what > the KSP organizers said. Martin certainly should follow the protocols > established, but I would only count "established" as being what is > actually written down by the KSP organizers, and not just some kind of > general unspoken expectation. (Where can I read about those written > protocols, if there are any?) From http://debconf6.debconf.org/ksp/ksp-dc6.html: " The next step is to verify each participant's identity by checking preferably a passport or, alternatively, some other form of government issued ID. Please don't show very old, doubtful or easy-to-fake documents as people will not sign your key if you do so. " I guess that answers the questions you brought up in your e-mail. An ID from a political party is *not* a government issued ID and *is* a doubtful document. Regards Javier signature.asc Description: Digital signature
Re: Red team attacks vs. cracking
On Tue, May 30, 2006 at 09:28:19AM -0700, Thomas Bushnell BSG wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > > This is to forestall those of you who seem to be be arguing > > that the debconf6 KSP crack was a red team attack -- here is how that > > attack differed from a legitimate red team effort (I have been a > > member of red teams before, and have lead a number of red team > > attacks in my time). > > I haven't heard anyone make such a claim. Claiming that what Martin did was good since he was showing something useful for our community is equivalent to saying it was a "red team attack". Nobody used that term explicitly probably because they are unfamiliar with it. I know what it means, I've done my share of pen-testing to companies. I do agree with Manoj that this was *not* a legitimate experiment (i.e. not a "red team" test) and that Martin *did* abuse our [0] trust [1] I find this akin to people finding and exploiting web app vulnerabilities (without being payed for by the company and without their approval). To "show" that webapps are vulnerable. Regards Javier [0] The assistants to the KSP [1] By not providing a *proper* ID as required by the KSP organisers (and all KSPs protocols I've read ). Notice that he himself has described his ID as not being *proper* and that it was the whole point of his excercise. signature.asc Description: Digital signature
Re: Please revoke your signatures from Martin Kraff's keys
On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
> Dear Manoj, dear fellow DDs,
Hi, I'm just going to address the question you made that was directed to me.
> also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
> [2006.05.25.1300 -0500]:
> > FWIW, I noted down those keys I would *not* sign and didn't tell
> > the people at the KSP that I would not sign them. I guess his
> > experiment "only one in ten said that they would *not* sign it" is
> > moot unless he backs it up with the signatures he eventually got
> > sent from those he showed a wrong ID to.
>
> Out of curiosity, did you mark my key to be "questionable"?
Yes. But then again, you have to trust that I did since you cannot
see the (2) I added next to your name and the ID check :-)
(on a scale of 1-5 with 5 being the highest). You got a (2) (and
not a (1) like others did) not because of your ID but because we actually
talked throughout the Debconf.
> The point you raise is a valid one. However, given how many people
> just don't sign keys after keysignings, the data would be skewed in
> the other direction.
True. But skew is always present in lies^statistics :-)
> I do not yet understand why some people do not confront those with
> questionable IDs. Maybe you can shine some light on that.
For two reasons:
1.- People might not have a better ID (I guess I trust people to bring
their best ID to the KSP) and that means that:
a) they will be ashamed that they cannot provide a better ID
b) they will be offended that I don't trust their national ID
c) they will not understand why I'm asking for a better ID
2.- Lack of time and peer pressure ("you are taking too long!")
The only case in which I would bother explaining is 1-b, but with 2) taken
into account I did not had time to explain why their ID was not sufficient
for me. And I can actually do that (with a canned e-mail) after the KSP.
Hope that explains it.
Javier
signature.asc
Description: Digital signature
