Re: New virtual package x-image-viewer?
On Wed, 2009-07-08 at 17:59 -0700, Steve Langasek wrote: > On Wed, Jul 08, 2009 at 09:07:54PM +0200, Jan Hauke Rahm wrote: > > Basically > > > egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' > > /etc/mailcap > > > > A virtual package only makes sense if it will also provide a standard > > > interface that other packages will invoke. > > > It doesn't have such, it just chooses one out the list provided by the > > command above (it's actually perl but anyways). > > Well, a mailcap entry would qualify as such a standard interface - though > you ought to be using 'see' (or 'run-mailcap') instead of parsing the file > directly, indeed. Freedesktop has a similar tool (less portable than mailcap, but it's database probably more accurate... for instance my mailcap isn't aware of image/x-xcf files). $apropos xdg-open > xdg-open (1)- opens a file or URL in the user's preferred application $aptitude show xdg-utils | awk /^Descr/,/^$/ > Description: desktop integration utilities from freedesktop.org > xdg-utils contains utilities for integrating applications with the > desktop environment, regardless of which desktop environment is used. > They are part of freedesktop.org's Portland project. > . > The following utilities are included: > . > * xdg-desktop-menu - Install desktop menu items > * xdg-desktop-icon - Install icons on the user's desktop > * xdg-icon-resource - Install icon resources > * xdg-mime - Gather MIME information about a file > * xdg-open - Open a URL in the user's preferred application that >handles the respective URL or file type > * xdg-email - Open the user's preferred email client, potentially with > subject and other info filled in > * xdg-screensaver - Enable, disable, or suspend the screensaver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian, universal operating system?
## BANNER { http://www.debian.org/banners/3.1/sarge-ban1-6.png }
Universal operating system #...@!
First of all, let's make it clear, Debian is not THE universal operating
system. I mean it is definitely not the one and only OS.
Is Debian an universal operating system?
Before answering this question, we need to define what would it means to
be an universal OS?
Does it mean that in runs many architecture?
yes, Debian support a dozen of them, of all kinds.
Does it means that it can run on different type of platforms?
yes, Debian can run on mainframes, on clusters, servers, desktop,
laptop, palmtop, embedded system, telephones and probably on
some "nailtop" some days.
Does it means that it provides a wide range of applications for a
wide range of customers?
yes, Debian probably provides applications for any purpose you
can think of. Well, may be not all of them yet.
Does it means that it ships many software for the same purpose, to fit
various needs?
yes, Debian provides dozens of webservers, database, CMS,
wordprocessing... some tiny and simple, some large with rich set of
features, etc (But don't worry, Debian can choose a default one for
you)
Does it means Debian runs run various kernels?
yes, Debian provides support for Linux and we may soon provide
support for GNU/kFreeBSD. There are other derivative works to support
Darwin and OpenSolaris kernel.
Does it means that we support multiple user environment?
yes, Debian provides 4 main Desktop environment (KDE, XFCE, LXDE and
the default one Gnome). It also has some user interface for other
type of device, like Hildon for embedded devices.
But it certainly doesn't means that all the packages and all the
features must be available on all the above variants. It doesn't make
sense to run a DVD player on a mobile phone or on a mainframe. It
doesn't make sense to do massive parallel computation on a tiny embedded
devices.
Does it means that Debian is a commodity thing?
no, Debian is a very specialized OS, which specific positioning IS to
be universal. (Not to mention that it's free as in [free beer|freedom],
open-source, community-driven, etc)
Why many Debian users and Developers are really happy with this Univeral
OS concept?
Well I suppose it has do with our social contract and the DFSG.
That's what I like in Debian(1),
Franklin
Side note about derivative distributions.
Yes, any one is allowed to fork Debian and make a derivative
distribution, and that's fine, I like that.
All of these forks have one thing in common: they have a different
specialization than Debian. Some are specialized for a specific
language, for end-user, for embedded, for palmtops, for a given kernel,
for a special field of endeavor, etc. Of course, those distributions put
lots of effort in their specialized domain and they are well ahead of
us. Some of those distribution are very successful and it is great,
because it is also our success.
Because we live in open-source world, most of them are merging their
patch, so we progress as quickly as them (even if we are "lagging")
In the end, it's the whole open-source ecosystem that grows quickly, and
that's great.
(1) I like that I am free to use Debian on my Laptop, on my PS3, on my
Nokia N810, on my wireless access point or NAS device. My
organisation could use the same OS on it a mainframe, on clusters,
on computers, on desktops, on smart phones. One single OS that can
be adapted for each use.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Sun, 2009-09-06 at 05:01 +0200, Marco d'Itri wrote: > On Sep 06, Steve Langasek wrote: > > It's normal that in the process of drafting a standard, people will take > > into account the prevailing real-world practices, to ensure that the > > standard will be useful. Once something *is a standard*, you don't > > arbitrarily change what you're doing and claim that it still complies with > > the standard because "the standard follows what Red Hat does". > I am not claiming that this complies with the standard, just that it > does not matter because if there is a wide consensus (which does not > need to be unanimous) about this then eventually the standard will be > updated to reflect it. > Anyway, FHS also has examples of things changed long after they were > adopted by everybody, like /var/spool/mail/ vs. /var/mail/. I would ask a question to [FHS|udev-upstream|whoever] : What "smooth" migration path do you offer for those millions systems that are installed with a standalone /usr? I am grateful to udev developers and maintainers. I remember what was Linux before udev... (far too many "vim /etc/modules", MAKEDEV, chown and chmod ) FWIW, I did some statistics on installation-reports (in my debian-boot mailing list backlog). 48 reports has the string "% /dev" 18 reports has the string "% /usr" That's 37% ! This statistics are probably biased, because people with a single partition layout probably don't bother reporting their disk partitioning. My 2¢, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /var/www is depracated, which directory to use?
On Sun, 2009-09-27 at 01:45 -0700, Russ Allbery wrote: > Holger Levsen writes: > > > I think having munin working out-of-the-box is a very neat feature. > > I think we need better support in the Apache package for adding particular > aliases and similar URL configuration into the default site, so that those > who want to do things like this can add the necessary URL mappings to the > default site and those of us who are doing anything more complex and who > are therefore disabling the default site anyway don't have random packages > suddenly taking over portions of our URL space. The URL namespace isn't "suddenly" taken over: 1. The admin deliberately install the package. 2. The admin choose to use the default settings of the package. (editing the conf files is usually trivial) Personally, on my modest production websites, I always disable the default website (a2dissite 000-default), then disable the "Include" lines in /etc/apache2/apache2.conf... So I can cherry pick (Include or copy) the configuration files snippets in my vhosts. On some other machines, I am often very happy to just "apt-get install" and simply _read_ the fine manual. I would be really annoyed I had to manually configure and enable ssh-server on every machine (generating the host key, configure sshd, enabling sshd in /etc/default/ssh, then start the service). Same applies to most webapps. Regards -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
On Tue, 2009-09-29 at 13:37 -0700, Russ Allbery wrote: > Andreas Tscharner writes: > > > This is true for Unix/Posix systems, but unfortunately not for Windows > > systems. And if the maintainer of a great Perl script wants his script > > to work on both platforms, he'll probably will name it > > GreatPerlScript.pl If the extension .pl is linked with a Perl > > interpreter in Windows, he'll be able to run it on both systems without > > a prepending "perl" > > If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows, > he'll be able to run it on both systems as GreatPerlScript. This is another interesting point... Should we also preserve the CamelCase names? This is merely a decoration under Windows, but is important under $unix! ...just kidding. Seriously, the developer had to[1] add a file extension to distribute the file to windows, it doesn't means that such bad practice should be carried-on on other platforms. As an alternative to [1], if a perl/python/$language developer wants windows users to be able to start a command easily, it is best to provide a windows "foo.cmd" file which merely launch the interpreter and command. As a benefit, the command can be launched by executing "foo". Franklin [1] On doesn't actually "have to" specify the file extension. I can only speculate on why Python/Perl installer don't set PATHEXT properly... http://docs.activestate.com/activeperl/5.8/faq/Windows/ActivePerl-Winfaq4.html#What_s_the_equivalent_of_the_she -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Submitting bugs for manpage improvements
Hi all, I have written a small script to make it easy to submit manpage improvements (it's attached). I believe that it much more effective to submit a patch, rather than explaining what needs to be improved. The tool works like quilt, dpatch & co. One would just invoke: $man-reportbug chfn The script simply invoke man to dump the manpage as plain text, then open it in the user's prefered text editor. After editing the text, report-bug is automatically launched against the appropriate package, and a diff of the manpage is attached. (By mistake, I have submitted http://bugs.debian.org/551681, so you can have a look:-/ ) There is one issue: most of the bugs will have to be forwarded upstream. (I suppose that in a perfect world, each upstream would have a vcs which could be used to pull/commit pages...) I would get your opinions on how to make this useful/convenient. Thanks, Franklin man-reportbug Description: application/shellscript signature.asc Description: This is a digitally signed message part
Re: Submitting bugs for manpage improvements
On Tue, 2009-10-20 at 07:17 +0200, Frank Lin PIAT wrote: > > I have written a small script to make it easy to submit manpage > improvements (it's attached). > I believe that it much more effective to submit a patch, rather than > explaining what needs to be improved. The tool works like quilt... [..] > There is one issue: most of the bugs will have to be forwarded > upstream.[..] > > I would get your opinions on how to make this useful/convenient. I have received some feedback from a developer who is concerned about having to deal with the contribution from "nitpickers". I must admit that I am concern with bikeshedding and nitpicking too. I had a few ideas... (so far) A. We could have a different work-flow for (non)-native package: - For non-native package, we could instruct people to submit the diff-file to the upstream maintainer. - For native package, we could file a bug in Debian BTS. B. We could provide a way so maintainer could declare whether the bug should be filed upstream or to the BTS. C. We could ship the tool in a package that is usually installed by developers only (shipping the script in a package like devscripts, rather than installing it by default) Option A and C looks interesting... Regards, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: usplash-theme-debian uploaded to sid
On Sat, 2009-10-24 at 16:24 +0300, Eugene V. Lyubimkin wrote: > Holger Levsen wrote: > > [...] Currently supported resolutions are > > 640x400, 640x480, 800x600, 1024x768, 1365x768 and 1600x1200. 1024x600, 1366 ? > > 1280x1024, 1440x1050 and 1900x1200 are already on my list of what's nice to > > have, what other resolutions are there you need to have? :-) > Would be nice to see also 1280x800. There are probably three set of defacto-stantards. Those extra format could be interesting * VESA: 2560×1600 (on 30 inches monitors... lucky guys) * Laptops: 1280×800 (as noted by Eugene), 1440×900, 1680×1050 * LCD TVs: 1920×1080 * Notebook: not much to add. There are many other weird/uncommon formats (like 1024x600) I have no clue which format would be supported by the console. Regards, Franklin For reference... http://en.wikipedia.org/wiki/Display_resolution http://en.wikipedia.org/wiki/Computer_display_standard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: usplash-theme-debian uploaded to sid
On Sat, 2009-10-24 at 16:29 +0200, Holger Levsen wrote: > On Samstag, 24. Oktober 2009, Ben Hutchings wrote: > > > > Add 800x480 and 1024x600 for the EeePC and similar netbooks. > > regards, > Holger (not sure yet how to deal with 20 different resolutions sanely) A while ago, I gave a try drawing wallpapers[1], grub splash screen[2] and grub template[3]. SVG are extremely convenient, because it is possible to automatically generate XPM/PNG bitmaps of various size (!) The next problem is to address different aspect ratio. I suppose there are two solutions: 1. Designed the image so it can be tiled/cropped horizontally (especially between 4/3 <-> 16/9) 2. Draw one "source" image per aspect ratio. My 2¢ Franklin [1] http://www.klabs.be/~fpiat/linux/debian/art/ [2] http://wiki.debian.org/Grub/SplashImage [3] http://www.klabs.be/~fpiat/linux/boot/grub/fp-debian%28grub2%29-shines.svg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Submitting bugs for manpage improvements
On Thu, 2009-10-29 at 09:26 +, Stefano Zacchiroli wrote: > On Tue, Oct 20, 2009 at 07:17:53AM +0200, Frank Lin PIAT wrote: > > I have written a small script to make it easy to submit manpage > > improvements (it's attached). > > Hi Franklin, > in the end, have you decided where/how to ship this script? I'd > personally would like to see it in devscripts ... and I was just going > to need it to submit a manpage fix :-), so I thought to ping here to > avoid loosing track of where to ship these very useful software bits. Since the proof of concept was fairly well accepted, I intend to polish my script a little bit before submitting it. * I like Simon's patch/idea to handle I18n, and I would like to improve it a bit further. * Also the script needs to handle dpkg's alternatives. * Last but not least, the script shouldn't discard the diff when somehting fails or reportbug isn't configured. I hope I can make it by this week-end (humm, I am not so sure actually). Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
DEP-5: binary package affected by license $foo
Hello, As I was updating the copyright file in a package, I wondered if it would be useful to add an optional header (named "Binary-Package" or whatever), to state which binary package is using that file and license. The rational is that sooner or later, we will want to use the machine-interpretable copyright file to validate packages freeness, license compatibilities and so on. Some sample scenario: Exemple 1: > File: doc/info/* > License: GFDL-NON-FREE > Binary-Package: none The package contains a file covered by a not-so-free license, but that file isn't used to build the binary file. And the file isn't shipped in the binary files. Exemple 2: > File: foo.c > License: GPL-2 > Binary-Package: foo > > File: bar.c > License: GPL-3 > Binary-Package: bar The source package contains some files covered by two incompatible license, but it isn't a problem because the binary aren't combined at build nor at link time (or example). Exemple 2: > File: foo.c > License: GPL-2 > Binary-Package: foo > > File: doc/info/* > License: GFDL-NON-FREE > Binary-Package: foo-doc-is-non-free The source package produces both a free and non-free package. This extra header would be completely optional, and only useful to white-list some specific situation. That's just an idea (a foolish idea?) Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27 (update bug #549710)
retitle 549710 release-notes: [SQUEEZE] udev drops support for kernels < 2.6.22 (or <2.6.27) thanks The requirement might be raised to 2.6.27 (which is higher that the one in Lenny). See udev maintainer announcement and thread[1]: On Tue, 2009-11-10 at 18:08 +0100, Marco d'Itri wrote in: > Due to changes in udev 147, squeeze will not support kernels earlier > than 2.6.27. > > If your packages have code needed to support old kernels, this is the > right time to clean it up. > > This means that lenny->squeeze upgrades will use the same lockstep > kernel/udev upgrade method used for etch->lenny upgrades. [1] http://lists.debian.org/debian-devel/2009/11/msg00392.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Russell Coker wrote: > On Thu, 12 Nov 2009, Wouter Verhelst wrote: >> First, network protocols that "do not allow to display" anything are >> abundant, since no network protocol "displays" anything -- clients that >> use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot. > > If you connect to my SMTP server you will see a legal disclaimer (which I > claim to be as valid as any that you may see in a .sig). [..] > Now in terms of granting rights, if my mail server contained AGPL code > and this was displayed in the SMTP protocol then a user could connect > to it and discover whether I was using code for which they could demand > the source. I disagree with your interpretation. The AGPL states "prominently offer all users", displaying at protocol level doesn't comply with either "prominently" nor with "all users" (because only a few sysadmins will telnet to port 25.) Such offer should be on SMTP *and* on the website offering this service. (Would you consider it valid if the offer were included in HTTP headers?) /me don't like AGPL, especially due to the way linked/combined code is contaminated. I hate the way FSF made an exception for GPL-v3, and not for "any compatible license". That's proprietary sh*t. Regards, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27
Marco d'Itri wrote: > On Nov 10, Marco d'Itri wrote: > >> Due to changes in udev 147, squeeze will not support kernels earlier >> than 2.6.27. > I uploaded a 147-2 package which reverts the O_CLOEXEC change and allows > 2.6.26, let's see if it works. Big thanks for working on this issue. I hope it's gonna work. (I can test it today) Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
On Sun, 2009-11-29 at 13:56 +0100, Marco d'Itri wrote:
> On Nov 28, Bastian Blank wrote:
>
> > The Linux image packages needs to do some modifications to core
> > configuration files like fstab in the future to allow newer kernels to
> > work. To do this and the planned further extension I intend to make all
> > linux image packages depend on python.
> This is not justified.
> I will be happy to rewrite in perl whatever you need.
Find attached an initial attempt to use shell only. Let me know if you
are interested.
The script is configurable, so a sysadmin can decide to re-rewrite fstab
using DM/LVM names rather than UUID, or volume LABEL, or legacy /dev/hd*
names.
Known bugs/limitation:
* Should accept command line arguments
* Some devices may need to be blacklisted
* What about removable media? (UUID of media in CDROM? ouch)
* Should actually write fstab ;)
I have hesitated to probe the current /dev or to use blkid... I can
change that easily.
I think this script should have a companion, to insert/update a comments
line above each fstab entry (à-la Debian-Installer)
Franklin
#!/bin/sh
set -e
# update-fstab-persistent-names - Rewrite current fstab
# (Using your prefered device naming).
#
# Copyright 2009, Frank Lin PIAT
# Licensed under GPLv2 or later
#
# Known bugs/limitation
# * Should actually _write_ fstab ;)
# * Doesn't accept command line arguments
# * Some devices may need to be blacklisted
# * What about removable media?
# == User configurable variables == #
# Prefered device naming scheme to use in fstab. **Order matters**.
#dm : use /dev/grpname/logvolname for LVM volumes
# : or /dev/mapper/dmname for CRYPT and other.
#uuid : use UUID=cafecafe (based on the FS's volume UUID)
#label : use LABEL=foo (based on the FS's volume name)
#plaindev : use legacy /dev/ devices.
PREFERED_NAME='dm uuid label plaindev'
# Rewrite existing LABEL=foo lines in fstab
REWRITE_LABELS=1
# Rewrite existing UUID=foo lines in fstab
REWRITE_UUIDS=1
# == End of user configurable variables == #
# Let's declare some functions...
# Initialise a sed file to rewrite fstab, based on device major/minor IDs.
# (this temporary sed file search and replace all possible names for the
# local devices, with a fake unique ID "#DEVICE=X.Y" where X and Y are
# the device's major and minor numbers)
generate_simple_fstab_sed() {
# Sed rule to rewrite /dev/* entry as #DEVICE=X:Y
find /dev/ \( -type b -o -type l \) \
\! -path '/dev/.udev/*' \! -path '/dev/.static/*' \
-iregex '^[a-z0-9./_-]*$' -printf '%Y\t%p\n' \
| sed -n -e 's/^b\t\(.*\)/\1/p' \
| while read s ; do
printf 's\t^%s\>\t#DEVICE=%d:%d\t\n' \
"$s" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done
# Sed rule to rewrite existing LABELS=* entry as #DEVICE=X:Y
if [ "$REWRITE_LABELS" = "1" -a -d /dev/disk/by-label ]; then
find /dev/disk/by-label/ -type l -iregex '^[a-z0-9./_-]*$' \
| while read s ; do \
printf 's\t^%s\>\t#DEVICE=%d:%d\t\n' \
"LABEL=$(basename $s)" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done
fi
# Sed rule to rewrite existing UUID=* entry as #DEVICE=X:Y
if [ "$REWRITE_UUIDS" = "1" -a -d /dev/disk/by-uuid ]; then
find /dev/disk/by-uuid/ -type l -iregex '^[a-z0-9./_-]*$' \
| while read s ; do \
printf 's\t^%s\>\t#DEVICE=%d:%d\tg\n' \
"UUID=$(basename $s)" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done
fi
}
# create a list of device-major-minor -> /dev/vg/lv for LVM.
use_dm_legacy() {
which vgs 2>&1 > /dev/null || return 0
LVM_VGS="$(vgs --all -o vg_name --noheadings | sed -e 's#^\s*#/dev/#')"
[ ! "$LVM_VGS" ] && return 0
find $LVM_VGS -maxdepth 1 -type l -iregex '^[a-z0-9./_-]*$' \
Re: Linux image packages going to depend on python
On Sun, 2009-11-29 at 20:56 +0100, Frank Lin PIAT wrote: > On Sun, 2009-11-29 at 13:56 +0100, Marco d'Itri wrote: > > On Nov 28, Bastian Blank wrote: > > > > > The Linux image packages needs to do some modifications to core > > > configuration files like fstab in the future to allow newer kernels to > > > work. To do this and the planned further extension I intend to make all > > > linux image packages depend on python. FYI As I were investigating an issue about volumes UUID, I noticed that Ubuntu already had such transition, with this tool: volumeid[1] It needed a minor update to use blkid instead of vol_id. Franklin [1] https://launchpad.net/ubuntu/gutsy/i386/volumeid/113-0ubuntu17.2 https://launchpad.net/ubuntu/+source/udev/113-0ubuntu17.2 #!/bin/sh -e # Rewrite /etc/fstab so that filesystems are mounted by UUID if [ -e /etc/fstab.pre-uuid ]; then echo "/etc/fstab.pre-uuid already exists" 1>&2 echo "remove this file before running the script again" 1>&2 exit 1 fi cp -a /etc/fstab /etc/fstab.pre-uuid exec 9<&0 8>&1 /etc/fstab.new trap "rm -f /etc/fstab.new" 0 uuids="" old_IFS="$IFS" IFS=" " while read LINE do IFS="$old_IFS" set -- $LINE IFS=" " DEV=$1 MTPT=$2 FSTYPE=$3 OPTS=$4 # Check the device is sane for conversion case "$DEV" in ""|\#*) # Preserve blank lines and user comments echo "$LINE" continue ;; LABEL=*|UUID=*) # Already mounting by LABEL or UUID echo "$LINE" continue ;; /dev/mapper/*_crypt)# DM-Crypt devices echo "$LINE" continue ;; /dev/disk/*)# Already mounting by particulars echo "$LINE" continue ;; /dev/fd[0-9]*) # Floppy devices, not mounted by filesystem echo "$LINE" continue ;; /dev/*) # Ordinary devices -- we want to convert if [ ! -b "$DEV" ]; then echo "$LINE" continue fi ;; *) # Anything else gets left alone echo "$LINE" continue ;; esac # Don't convert filesystem types that don't make sense case "$FSTYPE" in auto) # Auto detection -- implies non-fixed fs echo "$LINE" continue ;; esac # Check filesystem options also case "$OPTS" in noauto|*,noauto|noauto,*|*,noauto,*)# Implies non-fixed echo "$LINE" continue ;; esac # If we reach this point, we think we want to move the fstab # entry over to mount-by-UUID. The first check is that the # filesystem on the device *has* a uuid UUID=$(/sbin/vol_id -u "$DEV" || true) if [ -z "$UUID" ]; then # Can we generate one? if [ "$FSTYPE" = "swap" ]; then REAL_FSTYPE=$(/sbin/vol_id -t "$DEV" || true) case "$REAL_FSTYPE" in swap) # is a swap device, add a UUID to it UUID=$(uuidgen) echo -n "$UUID" | perl -ne 's/-//g;chomp;print pack "H*",$_' | dd conv=notrunc "of=$DEV" obs=1 seek=1036 2>/dev/null ;; swsusp) # contains a suspended image, mkswap it! if ! mkswap "$DEV" >/dev/null; then echo "Warning: unable to make swap $DEV" 1>&2 echo "$LINE" continue fi UUID=$(/sbin/vol_id -u "$DEV" || true) if [ -z "$UUID" ]; then echo "Warning: unable to generate uuid for $DEV" 1>&2 echo "$LINE" continue fi ;; *) echo "Warning: $DEV is not a swap partition" 1>&2 echo "$LINE" continue ;; esac else echo "Warning: unable to find a UUID for $DEV" 1>&2 echo "$LINE" continue fi fi # Check for duplicates case "$uuids" in "$UUID" | "$UUID "* | *" $UUID" | *" $UUID "*) echo
Re: bug #551926: python-pip and pip: error when trying to install together
On Sun, 2009-11-29 at 21:17 -0500, Jonathan Yu wrote:
> Hi:
>
> [Cc'ing Adam Kennedy since I'm not sure if he's subscribed to debian-devel]
>
> Since Adam mentions that Perl's pip predates Python's pip by a
> significant margin, I think we should close this issue by renaming
> Python's installer back to pyinstall. It doesn't seem fair for someone
> who came on the scene later (who didn't do the appropriate research,
> and who, when prompted with the problem, decided to proceed with pip
> anyway) to be able to usurp the namespace from Perl.
Some facts:
---
pip
- It's in the archive since 2002-08
- It never entered testing or stable
- It's average popcon since 2004 is about 10 (out of 7)
- It's popularity suddenly increased in Octobre (reaching 68)
python-pip
- It's in the archive since 2009-04
- It is in testing
- It's popcon is slowly and constantly increasing, reaching 57/7
Why (perl) pip popcon suddenly[1] reached 68? Is it due to the new
version, or is it due to people installing it by mistake?
Non-factual!
WTF?
1. Can't perl and python upstream just talk together, this is not
just about Debian. Having two ${p}-installer-program it just so
convenient, what ever the platform!
2.
Don't we use apt/dpkg in Debian?
Do those $pip install stuffs outside /usr/local?
Shouldn't those packages description mention that users should
ITP/RFP desired modules? and that modules installed "manually" are
guaranteed to:
- Never be upgraded by Debian on upgrade/security updates
- Conflict with some properly installed packages
- Download untrusted/unsigned material (?)
- Download stuffs with unknown license (?)
- Never be supported by Debian
/usr/bin/pip should be a wrapper to invoke perl-pip and python-pop
randomly, in order to be really fair.
My 2¢
Franklin
popcon data:
2009-05: python-pip 3 0 0 3 0
2009-05: pip 8 1 7 0 0
2009-06: python-pip 180 612 0
2009-06: pip 8 1 7 0 0
2009-07: python-pip 19115 3 0
2009-07: pip 8 0 8 0 0
2009-08: python-pip 25115 9 0
2009-08: pip 8 0 8 0 0
2009-09: python-pip 32620 6 0
2009-09: pip 9 0 9 0 0
2009-10: python-pip 421125 6 0
2009-10: pip 9 0 9 0 0
2009-11: python-pip 51 934 8 0
2009-11: pip19 4 7 8 0
2009-12: python-pip 551434 7 0
2009-12: pip68151043 0
[1] http://qa.debian.org/popcon.php?package=pip
http://qa.debian.org/popcon.php?package=python-pip
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559761: ITP: release -- provides information about the current releases
On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
>
> * Package name: release
The tool isn't about releasing, but about to querying the release. Also,
it's about distribution release (not package...). May be a name like
{get|query}-distr[o]?-release... or something completely different like
"supported-distro" would be more explicit.
> Description : provides information about the current releases
>
> This package contains information about all releases of Debian and Ubuntu.
> The
> release script will give you the codename for e.g. the latest stable release
> of
> your distribution.
There was some discussions about a similar tool & issues:
http://lists.debian.org/debian-devel/2007/05/msg01138.html
and to query Debian point release.
http://lists.debian.org/debian-devel/2007/12/msg00742.html
> To get information about a specific distribution there are
> the debian-release and the ubuntu-release scripts.
I suppose you mean that there will be different back-end script.
(I suppose that you don't mean that each program will have to implement
a select/case algorithm?)
> It's based on the idea posted on the ubuntu-devel-discuss mailing list
> [1]. Comments, suggestions and feature requests are highly welcome.
>
> For Debian I need some informations: Until when were following
> releases supported: buzz, rex, bo, hamm, slink, and potato?
See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
information for bo/rex/buzz. Anyone ?
AFAIK, Debian have never supported more than two stable distributions
(stable + old-stable), therefore, you can assume that a distribution end
of life is "lower than" distribution N+2 release.
Franklin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559761: ITP: release -- provides information about the current releases
On Fri, 2009-12-11 at 00:09 +0100, Benjamin Drung wrote: > To sum up the naming discussion, there are two possible package names: > > * distro-release-info > * release-info > > The two distro-specific script will be named debian-release-info and > ubuntu-release-info. I tend to name the package distro-release-info and > the symlinked script release-info. The distro specific script should be in /usr/share/release-info/. If the distribution specific scripts are in the path, people may tend to use them, which isn't portable because one needs to know the local distribution before invoking the script. Also, it you be nice if your script was easily extensible by Debian and Ubuntu derivatives. BTW, did you notice that the DebianRelease[1] wiki page has a link per distribution release, with EOL dates (?) I just have a feature request: add some "--foobar-url" options, which would return some official urls about that distribution: * Info and support (http://www.debian.org/releases/lenny/ ) * Release Notes (http://www.debian.org/releases/lenny/releasenotes ) * Errata (http://www.debian.org/releases/stable/errata ) * Installation Guide (http://www.debian.org/releases/lenny/installmanual ) Franklin [1] http://wiki.debian.org/DebianReleases -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#558684: ITP: envstore -- save and restore environment variables
Hi all, Do April Fools' Day occur in November in some part of the world? On Sun, 2009-11-29 at 21:01 +0100, Maximilian Gass wrote: > Package: wnpp > > * Package name: envstore > Version : 2.0 > Upstream Author : Daniel Friesel > * URL : https://derf.homelinux.org/~derf/projects/envstore/ > * License : WTFPL WTF? Please Sam, drop your F* webpage. The [Open-Source] world don't need yet another license. Or make it clear that no one should actually use it. > Description : save and restore environment variables > > envstore allows you to save environment variables into a seperate store, list > them, and reload them into the shell again. In most situation, this packaged can be replaced with: echo $FOO > ~/.var_FOO then FOO=$(cat ~/.var_FOO) In some exceptional situation, where the variable variables and escape code should be preserved, one can use: export | grep " PS4=" > ~/.var_FOO then . ~/.var_FOO (No, it isn't guaranteed to be portable, and there might even be easier ways to achieve all this). I wonder how Unix could survive 30 years without such command. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561448: libpam-alreadyloggedin: Fake sense of security?
Package: libpam-alreadyloggedin Version: 0.3-1 Severity: important Hello, I am seriously concerned by the fake sense of security that such tool provides (I must say that some other pam modules are scarry). For instance, using vlock and libpam-alreadyloggedin on the same machine provides the same level of security as a blank password, if not less. As of 2009, where most people use either XWindow/ssh/screen, I see little benefit using this tool (YMMV). Please, add appropriate warning to this package description and README. Thank you for your effort. Franklin BTW, It is recommended to submit an ITP bug before uploading a new package in the archive, so other DDs can provide feed-back. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560863: ITP: lamson -- The Python SMTP Server
On Tue, 2009-12-15 at 12:20 +0100, Heiko Schlittermann wrote: > Sebastian Otaegui (Sa 12 Dez 2009 22:26:56 CET): > > Package: wnpp > > > > * Package name: lamson > > FYI, from the FAQ of lamson: > http://lamsonproject.org/docs/faq.html > --- > Debian and CentOS are notorious for being dinosaurs. Both distributions of > Linux suffer from the false rationale that older software is more stable > and > secure. The reality is that the stability or security of a piece of > software is > not a function of its age, and in many cases the newer versions of > software > will typically fix many stability and performance problems. I often find it amazing how upstream don't seems to have a clue of what releasing a distribution is all about (i.e integration of components, testing, documentation, long term support, easy security update during that period, easy installation...). Organisations and end-users just want to install an application and then use it (i.e not spending their time upgrading it, adjusting the configuration, migrating data...). And we can't really blame them, most of these stuffs aren't their job anyway. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501157: linux-image-2.6.26: New Intel Wifi Link 5100 and 5300.
Package: linux-image-2.6.26-1-686 Version: 2.6.26-5 Severity: wishlist Hello, Intel has a new wireless chipset. Laptops with those chipset are currently hitting the market, and we can assume they will replace the 3965/4965 soon. Are there any plan (and any chance) to have them supported in Lenny ? It seems that the driver is getting merged in upstream kernel 2.6.27. On August 13, 2008 Tomas Winkler Wrote (on linux-kernel[1] ): > Intel would like to announce Linux support for Wifi Link 5000 and > 5100 Series Adapters under iwlwifi driver (iwlagn.ko) > > The Intel(R) WiFi Link 5100 Series and 5300 is a families of IEEE > 802.11a/b/g/Draft-N1 wireless network > adapters that operate in both the 2.4 GHz and 5.0 GHz spectra. These > adapters, available > in both PCIe* Mini Card and Half Mini Card form factor > 5100 1x2 MIMO up to 300Mbps > 5300 3x3 MIMO up to 450Mbps A summary of this discussion will be available in the wiki page : http://wiki.debian.org/iwlwifi Thanks, Franklin -- [1] http://marc.info/?l=linux-wireless&m=121866189316587&w=2 For reference, the models supported by iwl5000: > 8086:4232 Wifi Link 5100 Wireless Adapter > 8086 1201 5100ABGN Mini Card > 8086 1205 5100BG Mini Card > 8086 1206 5100ABG Mini Card > 8086 1301 5100ABGN Half Mini Card > 8086 1305 5100BG Half Mini Card > 8086 1306 5100ABG Half Mini Card > 8086 1321 5100ABGN Half Mini Card Dell > 8086 1326 5100ABG Half Mini Card Dell > 8086:4235 Wifi Link 5300 Wireless Adapter > 8086 1001 5300ABGN Mini Card > 8086 1101 5300ABGN Half Mini Card > 8086 1121 5300ABGN Half Mini Card Dell > 8086:4236 Wifi Link 5300 Wireless Adapter > 8086 1011 5300ABGN Mini Card Lenovo > 8086:4237 Wifi Link 5100 Wireless Adapter > 8086 1211 5100ABGN Mini Card Lenovo > 8086 1216 5100ABG Mini Card Lenovo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations / buyers guide.
On Thu, 2008-10-30 at 11:29 +, Robert Lemmen wrote: > On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote: > > Wrong. You can help Ben Finney testing his packages. That would be much > > more useful than useless babbling on mailing lists. > > if you are talking about these [0], i certainly do not own any of these > pieces of hardware... I would be very pleased to have a "Buyers guide" on the wiki (i.e list devices that are current, supported and dfsg-free). I would push to make such page in no more than "2 clicks" from the frontpage. Franklin -- /me wonders how many laptops are 100% free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations / buyers guide.
On Mon, 2008-11-03 at 08:42 +0100, Rémi Vanicat wrote: > Frank Lin PIAT <[EMAIL PROTECTED]> writes: > > > On Thu, 2008-10-30 at 11:29 +, Robert Lemmen wrote: > >> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote: > >> > Wrong. You can help Ben Finney testing his packages. That would be much > >> > more useful than useless babbling on mailing lists. > >> > >> if you are talking about these [0], i certainly do not own any of these > >> pieces of hardware... > > > > I would be very pleased to have a "Buyers guide" on the wiki (i.e list > > devices that are current, supported and dfsg-free). > > the problem with those list is that they often become outdated and > incomplete Such buyer guide could list the supported-and-free chipsets (not laptop model or device name). Also, it should be limited to DebianLenny devices... Such page would quiet "stable". Depending on the device type, it could be either be a white-list or a black list : - All LAN adapter, except X,Y - Only the X and Y Wifi adapter. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: [not] Summarizing the choices
On Sun, 2008-11-09 at 00:39 -0500, Theodore Tso wrote: > On Sat, Nov 08, 2008 at 05:05:50PM -0800, Thomas Bushnell BSG wrote: > > > > But now we have this claim that the FCC's well-understood rule about > > hardware does not apply to software: that software modifications *are* > > traceable back to the manufacturer, even though hardware modifications > > are not. Oddly, however, in all these conversations, we've never seen > > any indication that this is really the FCC's policy. > [..] > So if people think that they are going to be able to get firmware in > source form so that popular wireless chips can be driven using 100% > DFSG pure firmware, I suspect they will have a very long wait ahead of > them. The issue is that software controlled radios are cheaper, and > that drives the mass market, so that will be what most manufacturers > will use. Having the firmware stored in flash memory would actually be a regression as far as quality is concerned: - ipw2100 firmware was updated 4 times (current version is 1.3) - ipw2200 firmware was updated about 7 times (v3.0) - ipw3945 firmware probably had multiple updates (v1.14.2). - iwl3945 firmware had multiple updates (v15.28.1.8). - iwl4965 firmware probably had multiple updates (v228.57.2.21). You can look for others. See http://wiki.debian.org/Firmware If we ever "succeed" in getting hardware manufacturer to ship their firmware on flash memory, that would mean that 99% of users will use outdated/buggy firmware. (How many of you regularly check their laptop manufacturer for firmware upgrade?) > > And none of this is really relevent: the DFSG and the Social Contract do > > not contain an exception for dishonest or scared hardware manufacturers, > > or stupid FCC policies. > > Neither does it (currently) contain an exception for debian.org > machines, or very popular Dell machines with Broadcom ethernet > firmware. Great! Cut them off!! Let's see how quickly we can get > users moving to non-official kernels and installers when the official > ones don't work for them. Then we can stop fighting about it. The > DFSG hard liners can go on using the DFSG free kernels, and everyone > else can either move to another distribution or use an unofficially > forked kernel package and installer. That's exactly the current situation: If one don't want non-free firmwares, he/she just don't use them. BTW, I have just checked... In order to install Windows Vista on my laptop, I would have to download about 20 different drivers. By asking users to download one single tarball with non-free firmware we provide a much easier experience. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who owns /etc/default/locale?
On Sun, 2008-11-09 at 09:43 -0600, Steve M. Robbins wrote: > I have two systems. Both track unstable, and have package > locales at version 2.0.16. > > On one system, package locales owns /etc/default/locale, on the other, > it doesn't. Should the file be owned by locales or not? I have question which is directly related: shouldn't a package own and declare all the configuration files that it uses, even if it doesn't install or modify it? * If one purges a package, then reinstall it, then he/she wants to have a maintainer's behavior. * Two packages that uses the same configuration files should either : - agree on the file's format, and know who manage the file (so the second program [Depends|Recommend|Suggest] on the first package, that own the file), - or "Conflict" with each other. /me put on my post-lenny TODO list to send a patch for the policy, and submit a patch for lintian. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who owns /etc/default/locale?
On Sun, 2008-11-09 at 18:43 +0100, Andreas Metzler wrote:
> Frank Lin PIAT wrote:
> []
> > I have question which is directly related: shouldn't a package own and
> > declare all the configuration files that it uses, even if it doesn't
> > install or modify it?
> [...]
>
> No. Not all configuration files can be managed as dpkg conffiles.
I did not wrote that all configuration file should be conffiles : I
wrote that all (well known) configuration files should be tracked.
Some configuration files are used by packages but they aren't declared
anywhere. Also, as I mentioned, those file aren't necessarily removed by
the package when it is purged.
For example, on my laptop I've used a quick script to check
if /etc/default/* files are declared by the scripts located
in /etc/{init.d,cron.*}... as you can see, almost half of them don't
belong to any package.
apache2.2-common uses /etc/default/apache2 owned by apache2.2-common
exim4-base uses /etc/default/exim4 NOT OWNED
live-helper uses /etc/default/live-helper_autobuild owned by
live-helper
acpid uses /etc/default/acpid owned by acpid
apache2.2-common uses /etc/default/apache2 owned by apache2.2-common
apt-proxy uses /etc/default/apt-proxy owned by apt-proxy
atftpd uses /etc/default/atftpd NOT OWNED
avahi-daemon uses /etc/default/avahi-daemon owned by avahi-daemon
bluez-utils uses /etc/default/bluetooth owned by bluez-utils
initscripts uses /etc/default/bootlogd owned by initscripts
clamav-daemon uses /etc/default/clamav-daemon owned by clamav-daemon
console-tools uses /etc/default/locale NOT OWNED
cpufrequtils uses /etc/default/cpufrequtils owned by cpufrequtils
cron uses /etc/default/cron owned by cron
cron uses /etc/default/locale NOT OWNED
cups uses /etc/default/cups owned by cups
dbus uses /etc/default/dbus owned by dbus
dhcp3-server uses /etc/default/dhcp3-server NOT OWNED
dnsmasq uses /etc/default/dnsmasq owned by dnsmasq
exim4-base uses /etc/default/exim4 NOT OWNED
gdm uses /etc/default/locale NOT OWNED
hal uses /etc/default/hal owned by hal
initscripts uses /etc/default/halt owned by initscripts
hdparm uses /etc/default/hdparm owned by hdparm
ifupdown uses /etc/default/ifupdown owned by ifupdown
ifupdown uses /etc/default/ifupdown owned by ifupdown
irda-utils uses /etc/default/irda-utils NOT OWNED
console-common uses /etc/default/locale NOT OWNED
klogd uses /etc/default/klogd owned by klogd
cpufrequtils uses /etc/default/loadcpufreq NOT OWNED
cpufrequtils uses /etc/default/powernowd NOT OWNED
initscripts uses /etc/default/locale NOT OWNED
initscripts uses /etc/default/devpts owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
initscripts uses /etc/default/mountoverflowtmp NOT OWNED
initscripts uses /etc/default/devpts owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
network-manager uses /etc/default/NetworkManagerDispatcher NOT OWNED
network-manager uses /etc/default/NetworkManager NOT OWNED
nfs-common uses /etc/default/nfs-common NOT OWNED
nfs-kernel-server uses /etc/default/nfs-kernel-server NOT OWNED
openbsd-inetd uses /etc/default/openbsd-inetd NOT OWNED
partimage-server uses /etc/default/partimaged owned by partimage-server
pcmciautils uses /etc/default/pcmciautils NOT OWNED
portmap uses /etc/default/portmap NOT OWNED
rsync uses /etc/default/rsync owned by rsync
sane-utils uses /etc/default/saned owned by sane-utils
sl-modem-daemon uses /etc/default/slmodemd NOT OWNED
sl-modem-daemon uses /etc/default/sl-modem-daemon owned by
sl-modem-daemon
openssh-server uses /etc/default/ssh owned by openssh-server
sysklogd uses /etc/default/syslogd owned by sysklogd
udftools uses /etc/default/udftools owned by udftools
acpi-support uses /etc/default/acpi-support owned by acpi-support
The scriptlet I used:
for x in $(grep --binary-files=without-match -R -E "/etc/default/[^
$].*[^~]" /etc/{init.d,cron.*} | sed -e 's#\([^:]*\):.*
\(/etc/default/[[:alnum:]_-]*\).*#\1:\2#' | sort -u | grep -v
':/etc/default/rcS' ) ; do script="${x##*:}"; cfg="${x%%:*}" ; pkg=
$(dpkg -S "$cfg" | sed -e 's/:.*//') ; owner=$(dpkg -S $script
2>/dev/null | sed -e 's/:.*//' ) ; echo -n "$pkg uses ${x##*:} " ; if
[ "$owner" ] ; then echo "owned by $owner" ; else echo "NOT OWNED" ;
fi ; done
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release plans? Bits from the RMs?
On Fri, 2008-12-12 at 15:06 -0700, JD. Brown wrote: > On Thu, Dec 11, 2008 at 11:15 PM, Christian Perrier > wrote: > > (-release is not a discussion list, therefore setting followup to > > -devel) > > > > Dear release managers, > > > > I feel like being in the dark right now. And I feel like I'm not alone... > > I agree and would like to know as well? > > It seems as if the communication fell apart after September and trying > to track down any such information around the web is getting to be a > chore. I started a wiki page to track such schedule a few weeks ago. I keep it up to date (people in charge are welcome to contribute directly). http://wiki.debian.org/Schedule Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, 2008-12-16 at 13:38 +0100, Holger Levsen wrote: > Hi, > > On Montag, 15. Dezember 2008, Bastian Venthur wrote: > > Something like that, I don't really care about the name. The important > > thing is, that unstable is never frozen, but temporarily disconnected > > from the unstable > testing > stable flow. > Have you fixed an RC bug today or at least this week? I mean, are you > contributing that this _temporarily disconnect_ is really temporarily? +1 > /me shakes head. +1 Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, 2008-12-16 at 18:07 +0100, Lucas Nussbaum wrote: > On 16/12/08 at 14:34 +, Neil McGovern wrote: > > On Tue, Dec 16, 2008 at 03:07:12PM +0100, Lucas Nussbaum wrote: > > > On 16/12/08 at 14:21 +0100, Bastian Venthur wrote: > > > > I think this question is nonsense. While the bug-fix rate was more or > > > > less the same since the last two releases, it looks like in this release > > > > we actually started the freeze with much more RC-bugs than before. So it > > > > was foreseeable that the freeze will take longer this time. We can't > > > > solve the problem by fixing bugs faster (that won't work anyways). So > > > > what's the point of asking how many RC-bugs one has fixed? Does that > > > > mean only those are allowed to make suggestions, who fixed an RC bug? > > > > > > I agree. It's clear that most people don't work on RC bugs instead of > > ^ > > > working on their packages: during freezes, they just stop working on > > > Debian, since it's judged socially incorrect to work on one's packages > > > in unstable or experimental during the freeze. > > > > > > Could you justify those two please? I've seen no evidence, let alone > > any degree of clarity that supports the statement. > > "clear that most people don't work on RC bugs instead of working on their > packages": I don't have any data on that, it's mostly based on > perception. Let's try to gather data on something relevant: > > Number of distinct posters per month on debian-bugs...@lists.d.o: > 200801 944 > 200802 997 > 200803 1390 > 200804 1238 > 200805 1070 > 200806 1013 > 200807 1068 > 200808 1032 > 200809 975 > 200810 946 > 200811 724 > 200812 401 (partial results, obviously) > > So, the number of people working on RC bugs has significantly decreased > since the beginning of the freeze. Or there are fewer and fewer bugs in Lenny ? Or have we returned to [winter|regular] bug rate ? Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes: LSB Commands and Utilities
On Tue, 2008-12-30 at 13:34 +0100, Joerg Jaspert wrote: > Hi > > after some discussion within the ftpteam we just modified a few override > entries (15 to be exact). The following packages moved from standard to > optional: I have had a look at the "LSB Core" specification version 3.2. The section "Commands and Utilities" states that: > [..]An LSB conforming implementation shall provide the commands and > utilities[..]: > ar, at, awk, basename, batch, bc, cat, chfn, chgrp, chmod, chown, > chsh, cksum, cmp, col, comm, cp, cpio, crontab, csplit, cut, date, dd, > df, diff, dirname, dmesg, du, echo, ed, egrep, env, expand, expr, > false, fgrep, file, find, fold, fuser, gencat, getconf, gettext, grep, > groupadd, groupdel, groupmod, groups, gunzip, gzip, head, hostname, > iconv, id, install, install_initd, ipcrm, ipcs, join, kill, killall, > liTies, ln, locale, localedef, logger, logname, lp, lpr, ls, > lsb_release, m4, mailx, make, man, md5sum, mkdir, mkfifo, mknod, > mktemp, more, mount, msgfmt, mv, newgrp, nice, nl, nohup, od, passwd, > paste, patch, pathchk, pax, pidof, pr, printf, ps, pwd, remove_initd, > renice, rm, rmdir, sed, sendmail, sh, shutdown, sleep, sort, split, > strip, stty, su, sync, tail, tar, tee, test, time, touch, tr, true, > tsort, tty, umount, uname, unexpand, uniq, useradd, userdel, usermod, > wc, xargs, zcat Most of them are already provided by standard/important/required packages: at standard bashrequired bc standard bsd-mailx standard bsdmainutilsimportant bsdutilsrequired coreutils required cpioimportant cronimportant diffrequired ed important exim4 standard filestandard findutils required mawkrequired gettext-basestandard greprequired gziprequired hostnamerequired libc6 required login required m4 standard man-db important mktemp required mount required passwd required patch standard procps required sed required sysvinitrequired sysvinit-utils required timestandard tar required util-linux required But the following packages/commands have lower priority... binutilsoptional * binaries: ar, strip * Depends: No new Dependencies. * Size: 2686k/7717k cups-bsdextra cups-client optional * binaries: lp, lpr * Depends: cups-common, libcups2, libcupsimage2, libjpeg62, libpng12-0, libtiff4 * Size: 115+164+166+86+169+1175+37 = 1912k * InstalledSize: 393+426+295+168+369+5460+168 = 7279k gettext optional * binaries: msgfmt * Depends: libgomp1 * Size (.deb/installed) => 2672k+14k / 7274k+62k => Postpone in Squeeze: move the binary msgfmt to gettext-base? psmisc optional * binaries: fuser, killall * Depends: No new Dependencies. * Size (.deb/installed) => 85k/504k libc6-dev optional * binaries: gencat * Depends: linux-libc-dev * Size (.deb/installed) =>3377k+756k/13.3M+3957k lsb-release extra * binary: lsb_release * Depends: No new Dependencies. * Size (.deb/installed) =>20k/90k makeoptional * binary: make * Depends: No new Dependencies. * Size (.deb/installed) =>382k/992k pax optional * binary: pax * Depends: No new Dependencies. * Size (.deb/installed) => 52k/147k install_initd remove_initd * Not is Debian so it's another story. So, none of the important core commands are missing(!) lsb-release, psmisc and pax could be candidate could be upgraded to standard (IMHO). Happy new year, Franklin [1] http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/command.html#TBL-CMDS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sections - especially section:kde and section:gnome
On Fri, 2009-01-02 at 09:34 +, Sune Vuorela wrote: > Hi! > > I have been wondering over the last months about Section: kde. > What is the correct usage of this section? .. I have tried to summarised some of the ideas of this thread in http://wiki.debian.org/DiscussionsAfterLenny/Sections Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511522: general: Man pages should say what package a program belongs to
Hi, On Sun, 2009-01-11 at 19:56 +, Jack Grahl wrote: > If some program belongs to a package which does not have the same name > as the program, the man page for that command should say which package > the program is part of. Assuming that one can run: dpkg -S $(man -w hostname) manpages: /usr/share/man/man1/hostname.1.gz or dpkg -S $(man -s 7 -w hostname) manpages: /usr/share/man/man7/hostname.7.gz What would be the benefit of writing this information in each and every page? (with the risk of errors) Of course, man could be modified to look for that information, but I wonder if that's so useful. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512136: Acknowledgement (ITP: nox -- nox -- Meta package)
I forgot to 'X-Debbugs-CC: debian-devel'... so I'm forwarding it. Subject: ITP: nox -- nox -- Meta package Package: wnpp Owner: Frank Lin PIAT Severity: wishlist * Package name: nox Version : 0.1 Upstream Author : Frank Lin PIAT * URL : http://www.klabs.be/~fpiat/linux/debian/proposals/2009-01-17_nox/ * License : GPL Programming Lang: n.a Description : nox -- Meta packages No-X is a suite of shell tools, either command line or Curses based, that are useful for people that don't use X-Window. Binary packages: - nox-base, depends on the most common command line tools, that are suitable for most systems (desktop and servers). - nox-desktop-environment, which is very complete No-X metapackage for desktop user. It attempts to provides many functionality provided by graphical desktop environnements, but only text and ncurse based. - fb-desktop-environment is similar to above, but also have some graphical progams (using framebuffer... not for vt100 terminals ;-) - nox-base provides a reduced set of tools that many users might want to add to a standard system. - nox-system-tools provides a large set of tools, suitable on both end-users systems and servers. - nox-server-tools provides a set of tools, that one probably want on a servers. - nox-network-clients depends on many usual network tools and clients. The idea comes from wiki pages like http://wiki.debian.org/Console where visitors/contributors seems to like to install some extra command-line tools. The current debian/control draft is included below[1]. The current dependencies on package with priority=standard are going to go away (like "less"), unless there are useful alternatives in which case It might depends on either (?). Franklin [1] http://bugs.debian.org/512136 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#512136: Acknowledgement (ITP: nox -- nox -- Meta package)
On Sun, 2009-01-18 at 10:21 -0800, Daniel Moerner wrote: > On Sun, Jan 18, 2009 at 12:25 AM, Frank Lin PIAT wrote: > > The current debian/control draft is included below[1]. The current > > dependencies > > on package with priority=standard are going to go away (like "less"), unless > > there are useful alternatives in which case It might depends on either (?). > > Most is a nice color alternative to less. > > I also presume that we would want vim-nox | emacs22-nox | editor. Thanks, will do. > Something I don't quite understand is the target audience: most people > who run a command line install will know exactly what they want > installed, and won't need a metapackage to do it or to bring in > extraneous stuff. The point of those package is to provide an easy way to install _popular_ package (that aren't suitable for priority=standard). > Something that might also be useful would be a nox-debian-devel > package which would include tools that everyone needs for packaging > (lintian, build-essentials, devscripts, dput | dupload, fakeroot, etc) This could be added, but the source would have to be renamed. There are many more packages to make a deb-devel-environment, like doc-debian, debian-policy, maint-guide developers-reference, git, svn, cvs, hg, debhelper, dpatch|cdbs, ssh-client... Anyone interested to collaborating is welcome (I will probably ping the tasksel maintainers myself, as it's closely related). Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#562848: RFP: pencil -- animation/drawing software
Hello Nick, Nick Shaforostoff wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > > --- Please fill out the fields below. --- It is a best practice to fill all the fields below (they wouldn't be in the template otherwise ;) >Package name: pencil > Version: 0.4.4 > Upstream Author: NAME > URL: http://www.pencil-animation.org/ > License: GPL > Description: animation/drawing software Usually, it is a good idea to write the full package description that you would use for the upload... so people can give feed back. Otherwise, that looks like a funny pice of software. Thanks, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#563004: ITP: procserv -- A process server with telnet console and log access
Hello, On Tue, 2009-12-29 at 17:35 -0500, Ralph Lange wrote: > > * Package name: procserv > * URL : http://sourceforge.net/projects/procserv/ > Description : A process server with telnet console and log access > > procServ is a wrapper that starts an arbitrary command as a child process in > the background, connecting its standard input and output to a TCP port for > telnet access. It supports logging, child restart (manual or automatic on > exit), and more. I am curious why ssh+screen can't do the job? It would be much more secure than telnet. It would be nice to add a note in the package description. Also it is much more "à la unix" to use two tools together to do one job, each one doing one thing well. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Allow package bug scripts to unconditionally stop reportbug
On Thu, 2010-01-07 at 14:35 +0100, Sandro Tosi wrote: > Hello, > since version 4.10, reportbug checks the return code of the package > bug scripts and, it != 0, ask the user if to continue or stop. This is > the way we decided to fix #382010 . > But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . This is odd... it sounds like "You wanted to file a bug, well... don't!" How can a package script know what a user want to report? On what basis is it going to prevent the user from reporting a bug? I can think of lots of bad reasons to use such feature, but I can't think of any sensible one. Some bad reasons: * Your version isn't supported * Your version is outdated * Your configuration is broken * The package is half-installed * You are not using Debian * You have mixed distribution version* * PEBKAC > If a relevant number of you prefers to have this "fast way out", I'm > going and code it, else we can go on with the solution currently in > place. If you do implement it, please, provide a way to override it with a command line option. Thanks Franklin -- Can you master Open-source software? Prove it, write documentation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564562: stdeb - update description
package: stdeb version: 0.5.0-1 Severity: wishlist On Fri, 2009-10-09 at 14:21 +0200, Piotr Ożarowski wrote: > Package: wnpp > * Package name: stdeb > Description : Python to Debian source package conversion utility > > stdeb produces Debian source packages from Python packages via a new > distutils command, sdist_dsc. Automatic defaults are provided for the > Debian package, but many aspects of the resulting package can be > customized via a configuration file. An additional command, bdist_deb, > creates a Debian binary package, a .deb file. The new version 0.5 [1] contains some nice new(?) feature to create .deb packages. The package description should be updated accordingly, I suggest the one below. Also, I think it is important that stdeb package description should explicitly mention that .deb from Debian archive are preferred and supported(2). I am not completely happy with the note I provided. If the downloaded files aren't gpg/ssl signed, the package description should mention it. ,--( proposed package description )--- | This package provide some tools to produces Debian packages | from Python packages via a new distutils command, sdist_dsc. Automatic | defaults are provided for the Debian package, but many aspects of the | resulting package can be customized via a configuration file. | | * pypi-install will query the Python Package Index (PyPI) for a | package, download it, create a .deb from it, and then install | the .deb. | * py2dsc will convert a distutils-built source tarball into a Debian | source package. | Note: Only Python modules downloaded from Debian archive are supported | by Debian. Auto-converted packages may not install/work and may | requires manual fine tuning to reach Debian standards. `- Thanks, Franklin [1] http://mail.python.org/pipermail/python-announce-list/2009-December/008031.html (2) This is why I CC'ed debien-devel -- Can you master Open-source software? Prove it, write documentation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Optimus Gnu-Linux
Hello, [This is my personal opinion...] On Sun, 2010-01-10 at 06:17 -0300, Jonatan Dimotta wrote: > This project is basically an interactive free online service where the > user enters the website, run a wizard and it automatically detects the > computer's hardware, then the user chooses basic options such as > programs, orientation of the final operating system and optimized low, > with the specific software for your pc and the kernel compiled > automatically. So that the final size of the discharge may be much > less than the current distrubuciones, more efficient and easier. The recommended way to install Debian is to download the "Netinst", which is 180MB. The webpage says: | _Download_a_minimal_bootable_CD_image_: | Are you sure you really need the full CDs? You can just get the basic | installation system - it will download the rest of the distribution | if and when needed during the installation. > Also users who want to enter the world of GNU / Linux instead of > spending hours figuring out which distribution you choose, down one to > your specifications and ready. Quite off topic here. Debian only provide Debian material ;) Jounalists, bloggers and Wikipedia could/should help choosing. A dedicated website may help. You could suggest people at distrowatch.com > In broader aspects is not only lower the kernel compiled automatically > on your pc, if not adjust and specify various areas to leverage > resources to maximum, point to Programs, Web browsers, desktop, disk > partition, orientation, etc. . This would include a program to install > everything automatically and an integrated program to this Web > service, which can be updated, recompiling the kernel if you purchase > new hardware and see new style similar to iTunes (say an example). Keep in mind that changing a computer isn't always planned. In real life, people tend to change computer when the old one fails. Debian provides flexible kernel, XWindow... that can adapt to lots of different configuration without a change. Usually, you can simply move the hard disk from the old machine to the new one, and voilà. This is a feature I wouldn't give up, not even if I know that my computer could be 10% faster with specifically crafted software. (Observation/Myth: If you compare two computers, the faster being 10% faster than the other, it means that that take 1 second on a slow computer would take 0.9 second on the faster computer... Personally, I wouldn't notice the difference. See Moore's law[1]) > In the following site: > http://www.debian-mx.com/2008/07/linux-kernel-hasta-que-punto-monolitico-hasta-que-punto-microkernel/ > can now see how the Linux kernel is growing to a critical point where it is > becoming big, slow and heavy, even Linus Trovals believes that every day is > worse. Well, ok. Linus and kernel developers are facing a new challenge. I am pretty sure they will face and fix it. For the rest of your email, there are many good ideas. You are welcome to implement it ;-) Franklin [1] http://en.wikipedia.org/wiki/Moore%27s_law -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#566364: RFH: doc-central
On Sat, 2010-01-23 at 12:53 +, Neil Williams wrote: > On Sat, 23 Jan 2010 12:50:38 +0100 > Stefano Zacchiroli wrote: > > > On Sat, Jan 23, 2010 at 11:18:57AM +, Neil Williams wrote: > > > Just out of interest, what's the difference between doc-central and > > > dwww ? > > > > That's a pretty damn good question :-) > > > > I've made the choice between dwww and doc-central several years > > ago. _IIRC_ , back then dwww was missing decent browsing of the doc-base > > sections which is my main access path to documentation; more generally, > > I liked dwww more back then. FWIW I've just re-looked at dwww after > > your prod, and it seems that it has improved a lot over time. > > Agreed - and as dwww has progressed, doc-central appears to have > stalled. The Documentation Menu in dwww covers all I need from doc-base > and the addition of man page browsing, info document browsing, viewing > any file in any /use/share/doc/ directory and automatic linking from > changelog.Debian.gz to the BTS and similar - it's all really neat. Add > in the dpkg-www package to link to the Packages / apt cache data and > doc-central could have a lot of catching up to do. > > The only thing missing (for me) from dwww is an area covered by devhelp > - and even then a simple symlink is enough to make things like the > gtk2.0 reference manual available in dwww. > > devhelp has useful integration with some IDEs so that's why I use that > one as well. > > > If the point of yours, beside curiosity, was also to phase out > > doc-central in favor of dwww, that might be an option, but then > > agreement should be sought between the two packages maintainer and a bit > > of smooth upgrade path should be provided. > > There are plenty of situations in Debian where users have a choice of > options that have pros-and-cons. Personally, I don't see a need to > migrate - yet - as long as doc-central is usable and does the smaller > task of just the doc-base files, it is probably worth having both. I don't use either. I gave a quick-try to both of them. If I where to use one of them, I would probably use doc-central, because it doesn't depends on any indexing tools (dlocate, squish...). > If there is any particular content that advises doc-central over dwww > (on www.debian.org or on the Wiki) I'm not aware of it, so it's left to > user choice. It's best if packages pros/cons are summarized in package description. Here's a page for g**glers (contributions are welcome): http://wiki.debian.org/doc-base Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Flag images
On Wed, 2010-02-17 at 17:28 +0100, sean finney wrote: > On Wed, Feb 17, 2010 at 08:53:56AM +0100, Yves-Alexis Perez wrote: > > On lun., 2010-02-15 at 12:03 -0800, Don Armstrong wrote: > > > Flags are a poor representation of a particular language, and language > > > selection is better handled using locales and content-negotiation > > > anyway. [There are many examples where a country speaks many > > > languages, and examples where multiple countries have the same > > > language, but different dialects.] > > > > But flags (as an image) /are/ a quick way to identify a locale. Sometime > > they don't exactly overlap, thus the above problem, but they are still > > useful. Maybe not in content-negotiation, but for example to switch > > between locales easily, to switch keyboard mapping, to ask for some > > content different from the current locales, etc. > > And fwiw major software vendors have managed to overcome this trepidation > and include flag icons for such purposes. I would love to get some comments from: - people leaving in a country with many official languages. - people leaving in a country which official language is the same to the one spoken in another language (or at least quite similar). Think of Ireland and UK ; Canada and USA ; Canada and France ; Spain and Argentina/Peru/Uruguay/Chile... People from Belgium are really nice people, but they certainly don't want to spend their life licking on one of the Dutch/French/German flag. Using flag for language can be perceived as arrogant for those country who use the same language as another [larger] country. > I for one would love to get little flag icons back for displaying my > keyboard layouts, as it's visually much quicker/easier to identify than > looking for a two/three character piece of text on my task bar. Keyboards seems to be quite country-specific (not completely though). http://en.wikipedia.org/wiki/Keyboard_layout -- 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/1266448275.4493.2670.ca...@solid.paris.klabs.be
Re: Status of systemtap in Debian
On Tue, 2010-02-16 at 22:47 +0100, Lucas Nussbaum wrote: > On 16/02/10 at 22:27 +0100, Bastian Blank wrote: > > On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > > > - disk space on buildds: at least 2 GiB are required to build a kernel > > > with debuginfo. (that doesn't sound too hard to satisfy) > > > > A typical build includes between 2 and 10 of them. > > Ah, I missed that. Provided the build of the different are sequential, > the tree is not cleaned up between builds? > > So that means at most 20 GiB, which probably excludes more buildds. > > > > - mirror space: each debug .deb would use ~ 450 MB (see > > > http://ddebs.ubuntu.com/pool/main/l/linux/) > > > > Our archive does not support ddebs. > > Why couldn't it be done using a normal deb? Noob question... Aren't there some alternatives so people don't have to download all the MegaBytes ? (iSCSI ; DRDB ; FUSE/HTTP... whatever) Especially for fast moving targets, like unstable. Franklin -- 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/1266448721.4493.2684.ca...@solid.paris.klabs.be
Re: Flag images
Thanks to Kibi for notifying some mistakes... On Thu, 2010-02-18 at 00:11 +0100, Frank Lin PIAT wrote: > I would love to get some comments from: > - people leaving in a country with many official languages. > - people leaving in a country which official language is the same >to the one spoken in another language (or at least quite similar). s/leaving/living/ > Think of Ireland and UK ; Canada and USA ; Canada and France ; > Spain and Argentina/Peru/Uruguay/Chile... > > People from Belgium are really nice people, but they certainly don't > want to spend their life licking on one of the Dutch/French/German flag. ^^^ clicking ! Oops sorry, Franklin -- /me is French living in France, despite the email address. -- 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/1266449477.4493.2701.ca...@solid.paris.klabs.be
Re: Removing the manpage requirement for GUI programs?
On Sat, 2010-02-27 at 11:14 -0800, Russ Allbery wrote: > Josselin Mouette writes: > > > GUI applications usually take only a few simple command-line options, > > and more importantly, when you use a modern development framework, these > > options will always be documented correctly with the --help switch. > > Manual pages, OTOH, are not maintained properly by upstream developers. > > > I think it is a waste of time to write manual pages that won’t be > > maintained upstream, and that won’t contain more useful information than > > --help. The purpose of a manual page is to document precisely the > > behavior of a program, and for GUI applications there is usually an > > associated GUI documentation instead. manpages can prove to be useful in many situation and they have a few nice features: 1. "man" offer a consistent API. (as opposed to -h/--help/-help/--usage/ --help-foo, --help-bar, etc). 2. whatis foo 3. apropos bar 4. reading the manpage doesn't require to execute the program - it's safe to be run as root - it's doesn't create dummy .foo files - it never spawns any background process > If the flags are properly documented with --help, isn't it usually fairly > trivial to generate a man page using help2man? And if it isn't trivial, it probably isn't trivial for humans either. Franklin -- 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/1267304202.7886.2868.ca...@solid.paris.klabs.be
Re: md5sums files
On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > > Or is it useful to be able to say "if it doesn't check out, it's > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > > think so. > > I don't understand why you say this. Cryptographic attacks on MD5 aren't > going to happen as a result of random file corruption. The MD5 checksums > are still very effective at finding file corruption or modification from > what's in the Debian package unless that modification was done by a > sophisticated attacker (MD5 preimage attacks are still not exactly easy). > Detecting compromises is useful, but only a small part of what the MD5 > checksums are useful for. I'd more frequently use them to detect > well-intentioned but misguided meddling by a local sysadmin. > > I certainly don't object to replacing them with SHA1 hashes, although > signed deb packages would still be my preferred solution to this problem. Signed debs may introduce a fake sense of security (Only apt repository provide security updates). By signing packages, user may assume that a package is safe when it isn't. Debian is 15/20 years ahead of commercial operating system on that point. Franklin -- 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/1267649891.8266.233.ca...@solid.paris.klabs.be
Re: md5sums files
On Wed, 2010-03-03 at 11:37 +, Philipp Kern wrote: > On 2010-03-03, Wouter Verhelst wrote: > > This is where I disagree. When a checksum algorithm is compromised (and > > MD5 *is* compromised), things only ever get worse, not better. Indeed, > > MD5 preimage attacks are pretty hard *today*. But switching to something > > more secure in preparation for the day when MD5 will be easily cracked > > by every script kiddo around is *not* overkill. > > Sure, but to be honest, not even all packages managed to generate md5sums > 'till now (with some quite core, omnipresent packages missing) so it seems out > of scope for squeeze. Maybe squeeze+1. What about a transitional dh_md5sums that would produce md5sum AND invoke dh_sha ? Franklin -- 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/1267650344.8266.262.ca...@solid.paris.klabs.be
Re: Removing the manpage requirement for GUI programs?
On Fri, 2010-03-05 at 15:53 +0800, Paul Wise wrote: > On Fri, Mar 5, 2010 at 3:41 PM, Daniel Leidert > wrote: > > > What's the problem, to write a short manual page, that points to the > > --help switch? All the maintainer would have to do is to provide the > > intention of the command, point to the help/usage switch, relevant > > commands and to locally installed documentation. Such a manual page > > won't unlikely become outdated and it doesn't need much maintenance. > > This goes for both: authors and maintainers. But it still provides the > > necessary information to the user. > An outdated/unmaintained manual page or one that just points at --help > or existing documentation isn't useful or acceptable. I get to wonder how many DD/DM even ping their upstream about this issue. A short manpage, pointing to "native" documentation have proven to be useful (see GNU programs, and info pages). Wouldn't it be possible to build a manpage the docbook file (because the command lines are documented there, right ?) At the risk of repeating myself, "man $foo" is a unified "Interface" for humans. Franklin -- 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/126763.10430.160.ca...@solid.paris.klabs.be
Re: including full package source code in the debian release
On Sat, 2010-03-06 at 19:29 -0800, Jamie Morken wrote: > > Debian releases have 25,000 or so packages and don't include the > source to them This is not completely accurate. The most frequently downloaded CD/DVD/BD don't include the source, but the debian-cd team does release some media that fulfill that need: - The "multi-architecture" DVD contains the binaries and the source for the usual installation (Gnome, KDE, XFCE and LXDE), for both i386 and amd64 platforms (as far as Lenny is concerned). see http://cdimage.debian.org/debian-cd/current/multi-arch/jigdo-dvd/ file debian-504-i386-amd64-source-DVD-1.jigdo - Alongside DVD #1, #2, #3... you can download the CD/DVD/BD with the sources, see http://cdimage.debian.org/debian-cd/current/source/ > So to recompile the package you use apt-get to connect to the internet > and download the source to one package at a time if you want the > source code. There is nothing wrong with that, if you downloaded the binaries "as packages", you can download the source "as packages". This probably involves something like: cd /tmp apt-get source $(aptitude search ~i -F '%p') aptitude build-dep ~i Franklin -- 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/1267955928.21347.3559.ca...@solid.paris.klabs.be
Re: [Rant] Re: Removing the manpage requirement for GUI programs?
On Sun, 2010-03-07 at 09:50 +0100, Josselin Mouette wrote: > Le vendredi 05 mars 2010 à 17:41 +, brian m. carlson a écrit : > > This still has the problem that I don't know immediately where to get > > the documentation. Do I use the GNOME help system? KDE's? man? info? > > a DVI? a PDF? The benefit of manual pages is that there is one uniform > > way to get basic documentation on a command and how it is to be run. > > Other documentation can be referenced from that manual page. > > This discussion is running into circles. > > GNOME, Xfce and KDE maintainers all explained that we have no interest > in working on manual pages, and our upstreams don’t either. This is an important information that many people weren't aware of (at least, myself). > I will personally just sit on policy §12.1, mark manpage-related bugs as > wontfix, and, to plagiarize Yves-Alexis, it won’t prevent me from > sleeping at night. Your conclusion sounds very similar to the policy's statement: ``[programs] should have an associated manual'' (my definition of "SHOULD" is RFC2119 compliant) Franklin -- 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/1267966889.21347.4303.ca...@solid.paris.klabs.be
Re: [Rant] Re: Removing the manpage requirement for GUI programs?
On Sun, 2010-03-07 at 13:09 +, Sune Vuorela wrote: > On 2010-03-07, Frank Lin PIAT wrote: > >> GNOME, Xfce and KDE maintainers all explained that we have no interest > >> in working on manual pages, and our upstreams don???t either. > > > > This is an important information that many people weren't aware of (at > > least, myself). > > So you didn't read the full thread that was initiated by Josselin (gnome > maint) and had comments by me (one of the kde maints) and Yves-Alexis (XFCE > maint) ? "people were not aware" is past tense. I did read this thread with interest, and learned from it. > I normally don't tag such bug wontfix, but asks the submitter to provide > one. Submitters often dont. This tool is meant to help improving manpages: http://bugs.debian.org/559697 (were people easily submit a kind of patch, rather than just describing the problem) Franklin -- 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/1267968886.21347.4446.ca...@solid.paris.klabs.be
Re: Submitting bugs for manpage improvements
Dear devscripts maintainers, On Tue, 2009-10-20 at 07:17 +0200, Frank Lin PIAT wrote: > > I have written a small script to make it easy to submit manpage > improvements (it's attached). > I believe that it much more effective to submit a patch, rather than > explaining what needs to be improved. The tool works like quilt, dpatch > & co. One would just invoke: > > % man-reportbug chfn Are you interested in shipping this tool in devscripts? (Let me know if you aren't, I would consider an alternative way to ship it). Thanks, Franklin -- 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/1267969982.21347.4536.ca...@solid.paris.klabs.be
Bug#540215: Introduce dh_checksums
retitle 540215 Introduce dh_checksums
tag 540215 +patch
thanks
On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
> Frank Lin PIAT wrote:
> > What about a transitional dh_md5sums that would produce md5sum AND
> > invoke dh_sha ?
>
> Or call it dh_checksums or something so we don't have to change the tool
> name each time we decide to change the algorithm.
Hello,
Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
recent checksum.
The way it is implemented, is that the dh_md5sums is a symlink to the
new dh_checksums. The new helper computes both md5sum (for
compatibility/transition) and a new checksum (SHA256, which was already
chosen by FTP-masters as a remplacement for md5sum for signed files)
Note regarding the patch:
I have tried to make the patch so it isn't too intrusive (for
instance, dh_checksums is a symlink to dh_md5sums even though it
should be the other way around).
Your comments on the patch are obviously welcome (feel free to hack
it your self if you want)
Any chance to merge it before squeeze Freeze?
Franklin
>From 69799a95b470c19cd395c532356eeaa64bc1bac8 Mon Sep 17 00:00:00 2001
From: Frank Lin PIAT
Date: Mon, 8 Mar 2010 16:35:39 +0100
Subject: [PATCH] Implement dh_checksums.
---
debian/copyright |2 +-
debian/links |3 +++
dh |2 +-
dh_md5sums | 41 +
4 files changed, 38 insertions(+), 10 deletions(-)
create mode 100644 debian/links
diff --git a/debian/copyright b/debian/copyright
index a9f950d..162bfc0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -48,7 +48,7 @@ Copyright: Steve Robbins
License: GPL-2+
Files: dh_md5sums
-Copyright: Charles Briscoe-Smith
+Copyright: Charles Briscoe-Smith , Frank Lin PIAT
License: GPL-2+
Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..3e7d603
--- /dev/null
+++ b/debian/links
@@ -0,0 +1,3 @@
+usr/share/man/man1/dh_md5sums.1.gz usr/share/man/man1/dh_checksums.1.gz
+usr/bin/dh_md5sums usr/bin/dh_checksums
+
diff --git a/dh b/dh
index bcac8da..0aa9bc3 100755
--- a/dh
+++ b/dh
@@ -322,7 +322,7 @@ $sequences{install} = [...@{$sequences{build}}, qw{
my @b=qw{
dh_installdeb
dh_gencontrol
- dh_md5sums
+ dh_checksums
dh_builddeb
};
$sequences{'binary-indep'} = [...@{$sequences{install}}, @b];
diff --git a/dh_md5sums b/dh_md5sums
index da00090..33bf561 100755
--- a/dh_md5sums
+++ b/dh_md5sums
@@ -2,7 +2,7 @@
=head1 NAME
-dh_md5sums - generate DEBIAN/md5sums file
+dh_checksums - generate DEBIAN/*sums files (md5, sha256)
=cut
@@ -12,18 +12,24 @@ use Debian::Debhelper::Dh_Lib;
=head1 SYNOPSIS
+B [S>] [B<-x>] [B<-X>I]
[B<--include-conffiles>]
+
B [S>] [B<-x>] [B<-X>I]
[B<--include-conffiles>]
=head1 DESCRIPTION
-dh_md5sums is a debhelper program that is responsible for generating
-a DEBIAN/md5sums file, which lists the md5sums of each file in the package.
-These files are used by the debsums package.
+dh_checksums is a debhelper program that is responsible for generating
+a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
+md5sums and sha256sums of each file in the package. These files are used
+by the debsums package.
-All files in DEBIAN/ are omitted from the md5sums file, as are all
+All files in DEBIAN/ are omitted from the checksums files, as are all
conffiles (unless you use the --include-conffiles switch).
-The md5sums file is installed with proper permissions and ownerships.
+The checksums files are installed with proper permissions and ownerships.
+
+dh_md5sums is deprecated, you should use dh_checksums instead, which generates
the
+type of checksums files recommended by the Debian policy.
=head1 OPTIONS
@@ -37,7 +43,7 @@ redundant since it is included elsewhere in debian packages.
=item B<-X>I, B<--exclude=>I
Exclude files that contain "item" anywhere in their filename from
-being listed in the md5sums file.
+being listed in the checkums file.
=back
@@ -48,15 +54,26 @@ init(options => {
"include-conffiles" => \$dh{INCLUDE_CONFFILES},
});
+my ($basename) = $0=~m:.*/(.+):;
+
foreach my $package (@{$dh{DOPACKAGES}}) {
next if is_udeb($package);
-
+
+ if (basename($0) == 'dh_md5sums') {
+ warning("This program should no longer be used. Please read the
dh_checksums(1) man page.");
+ }
+
my $tmp=tmpdir($package);
if (! -d "$tmp/DEBIAN") {
doit("install","-d","$tmp/DEBIAN");
}
+ # Detect if this is run multiple times (calling both dh_md5sums and
dh_checksums?)
+ if (-f "$tmp/DEBIAN/md5sums" or -f "$tmp/DEBIAN/sha256sums") {
+ warning(&quo
Re: Bug#540215: Introduce dh_checksums
On Mon, 2010-03-08 at 12:21 -0500, Joey Hess wrote:
> Frank Lin PIAT wrote:
> > Note regarding the patch:
> > I have tried to make the patch so it isn't too intrusive (for
> > instance, dh_checksums is a symlink to dh_md5sums even though it
> > should be the other way around).
>
> Symlink direction seems irrelevant.
>
> I'd probably just make dh_md5sums call dh_checksums, and later add
> a deprecation warning message.
>
> > Your comments on the patch are obviously welcome (feel free to hack
> > it your self if you want)
> >
> > Any chance to merge it before squeeze Freeze?
>
> Is debsums ready to handle other checksums types?
Currently, debsums silently ignores sha256 checksums, so it won't break
if we start shipping those checksums.
I intend to submit a patch (see the TODO list[1])
> > +a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
>
> So this doubles the amount of work that's done on build. Is there any
> reason to generate md5sums files, aside from keeping old debsums
> working?
Yes, this is for transition.
We still have to decide how long that transition would be.
> > + if (basename($0) == 'dh_md5sums') {
> > + warning("This program should no longer be used. Please read the
> > dh_checksums(1) man page.");
> > + }
>
> It's probably too early for this warning, I prefer to give people some
> time before starting to nag.
I agree,
Thank you for your quick review. I'll keep you informed about
lintian/debsums patch.
Franklin
[1] http://wiki.debian.org/Sha256sumsInPackages
--
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/1268070281.21347.10033.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote: > Frank Lin PIAT writes: > > > Find a patch attached, for a smooth transition from DEBIAN/md5sums to a > > recent checksum. > > > The way it is implemented, is that the dh_md5sums is a symlink to the > > new dh_checksums. The new helper computes both md5sum (for > > compatibility/transition) and a new checksum (SHA256, which was already > > chosen by FTP-masters as a remplacement for md5sum for signed files) > > 1. Strengthen the integrity check so that it could potentially be useful >for security purposes as well as for simple integrity checking. Yes, this is the intended goal. Imagine the following scenario: 1. You boot a trusted device with Debian Live or D-I 2. A helper mounts the root, usr and var partitions of the inspected system 3. It then fetches the list of installed package and version 4. It then fetches the list of signatures for the installed system, from your trusted mirror. 5. Then it validates the installed files on the inspected system. 6. You just have to trust one GPG key (per repository). All that relies on the current infrastructure and chain of trust (Repository's Releases.gpg->Packages.gpg->checksum). Alternatively, what I am currently doing is to periodically export my md5sums to a trusted system. It would be much easier if a signed list of check-sums for current packages in our archive were published (basically, when we create Packages.gpg, we would need to extract the checksums contained in those packages, then sign it. This list could also included the recently updated packages, which is useful for point-releases, and unstable). The benefit is that you can quickly audit if installed binaries are pristine AND current. > If we take option 1, going to a stronger hash is strictly less useful in > every respect than going to embedded PGP signatures Can you elaborate? checksums are currently signed, no? > which apparently only require active maintenance and a plan to be > acceptable in the archive and which would need a different format > anyway. I see some problems with signed packages: 1. Software developers and vendors will start distributing standalone binary packages, and pretend they are "safe" because they are signed. This is not safe: only an APT-like mechanism provides security updates. 2. You still need an infrastructure to publish valid packages version. 3. What do we do when we want to change a GPG key? we re-sign all the packages, probably breaking existing packages checksums? Last but not least: 4. How long is it going to implement it? Does it seems realistic to implement your proposal before Squeeze +1 (or event Squeeze +2)? What do we do in-between? > If we take option 2, SHA256 offers no benefits over MD5 and just takes > longer to compute. Why is that everyone seems to move away from MD5? > There is essentially zero chance that random file corruption or > typical local modification will result in a successful MD5 preimage > attack. An attacker has plenty of time to pre-compute a valid replacement for, let say, a library in Debian Stable. > I therefore have to question what utility there is in switching to SHA256. > It doesn't seem to achieve either possible goal, unless I'm missing some > way in which it's a step towards option 1? As a bottom line: 1. A package is not safe because it is signed, but because it is up-to-date. 2. I am completely ok go for GPG packages, *if* it can be implemented by squeeze. Otherwise, let's move on to sha*** for squeeze, which can be quite transparent, and move to GPG post squeeze. Regards, Franklin -- 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/1268085864.21347.11498.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
On Mon, 2010-03-08 at 19:57 -0800, Russ Allbery wrote: > Joey Hess writes: > > Russ Allbery wrote: > > >> It's also always worth bearing in mind that while a really good > >> attacker can do all sorts of complex things that make them very hard to > >> find, most attackers are stupid and straightforward. > > > It's stupid and straightforward to install /usr/local/bin/ls. debsums > > will not detect it. > > True. Adding new binaries is, in my experience, more common than > modifying binaries already on the system. > > I don't really mean to be arguing for debsums as a security mechanism, > more just commenting on the general question. I'm on the side that thinks > that debsums isn't a horribly useful direction to go for full-blown > intrusion detection, and that for what it's really useful for right now > MD5 remains entirely adequate. How do people know which binaries are still pristine, so they can keep looking for issues elsewhere? (like added binaries and modified and insecure configuration file...) Not everyone uses aide (popcon: 0.49%). What solution do we have for Joe user (whom did not install aide)? What's the agenda for squeeze and squeeze+1? Who is actually stepping up to do the Job? Please, let's do the easy move *now* for Squeeze, using shasums, and go ahead later with an even better solution. This transition can be quick, it will remain quite unnoticed by people that aren't interested, but it will be appreciated by people who want to use it. Regards, -- Franklin Piat | The better is the enemy of the good. (Voltaire) -- 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/1268123295.21347.12099.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
Hello,
On Mon, 2010-03-08 at 17:36 +0100, Frank Lin PIAT wrote:
> On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
> > Frank Lin PIAT wrote:
> > > What about a transitional dh_md5sums that would produce md5sum AND
> > > invoke dh_sha ?
> >
> > Or call it dh_checksums or something so we don't have to change the tool
> > name each time we decide to change the algorithm.
>
> Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> recent checksum.
Since SHA algorithms is a family, tools and API usually implement
multiple variants. Wouter's initial email suggested to use the name
shasums. I must admit I find this quite sensible for future
improvements. People should be encourage to detect and support SHA-224
and better hash, even though we should only accept sha256 in the archive
for now.
I have still named the helper "dh_checksums", because it we ever want to
ship a different algorithm, we would probably still use the same
(updated) helper to generate that file.
Find an updated patch attached.
Regards,
diff --git a/debian/copyright b/debian/copyright
index a9f950d..162bfc0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -48,7 +48,7 @@ Copyright: Steve Robbins
License: GPL-2+
Files: dh_md5sums
-Copyright: Charles Briscoe-Smith
+Copyright: Charles Briscoe-Smith , Frank Lin PIAT
License: GPL-2+
Files: dh_bugfiles
diff --git a/debian/links b/debian/links
new file mode 100644
index 000..3e7d603
--- /dev/null
+++ b/debian/links
@@ -0,0 +1,3 @@
+usr/share/man/man1/dh_md5sums.1.gz usr/share/man/man1/dh_checksums.1.gz
+usr/bin/dh_md5sums usr/bin/dh_checksums
+
diff --git a/dh b/dh
index bcac8da..0aa9bc3 100755
--- a/dh
+++ b/dh
@@ -322,7 +322,7 @@ $sequences{install} = [...@{$sequences{build}}, qw{
my @b=qw{
dh_installdeb
dh_gencontrol
- dh_md5sums
+ dh_checksums
dh_builddeb
};
$sequences{'binary-indep'} = [...@{$sequences{install}}, @b];
diff --git a/dh_md5sums b/dh_md5sums
index da00090..33bf561 100755
--- a/dh_md5sums
+++ b/dh_md5sums
@@ -2,7 +2,7 @@
=head1 NAME
-dh_md5sums - generate DEBIAN/md5sums file
+dh_checksums - generate DEBIAN/*sums files (md5, sha256)
=cut
@@ -12,18 +12,24 @@ use Debian::Debhelper::Dh_Lib;
=head1 SYNOPSIS
+B [S>] [B<-x>] [B<-X>I]
[B<--include-conffiles>]
+
B [S>] [B<-x>] [B<-X>I]
[B<--include-conffiles>]
=head1 DESCRIPTION
-dh_md5sums is a debhelper program that is responsible for generating
-a DEBIAN/md5sums file, which lists the md5sums of each file in the package.
-These files are used by the debsums package.
+dh_checksums is a debhelper program that is responsible for generating
+a DEBIAN/md5sums and DEBIAN/sha256sums files, which respectively lists the
+md5sums and sha256sums of each file in the package. These files are used
+by the debsums package.
-All files in DEBIAN/ are omitted from the md5sums file, as are all
+All files in DEBIAN/ are omitted from the checksums files, as are all
conffiles (unless you use the --include-conffiles switch).
-The md5sums file is installed with proper permissions and ownerships.
+The checksums files are installed with proper permissions and ownerships.
+
+dh_md5sums is deprecated, you should use dh_checksums instead, which generates
the
+type of checksums files recommended by the Debian policy.
=head1 OPTIONS
@@ -37,7 +43,7 @@ redundant since it is included elsewhere in debian packages.
=item B<-X>I, B<--exclude=>I
Exclude files that contain "item" anywhere in their filename from
-being listed in the md5sums file.
+being listed in the checkums file.
=back
@@ -48,15 +54,26 @@ init(options => {
"include-conffiles" => \$dh{INCLUDE_CONFFILES},
});
+my ($basename) = $0=~m:.*/(.+):;
+
foreach my $package (@{$dh{DOPACKAGES}}) {
next if is_udeb($package);
-
+
+ if (basename($0) == 'dh_md5sums') {
+ warning("This program should no longer be used. Please read the
dh_checksums(1) man page.");
+ }
+
my $tmp=tmpdir($package);
if (! -d "$tmp/DEBIAN") {
doit("install","-d","$tmp/DEBIAN");
}
+ # Detect if this is run multiple times (calling both dh_md5sums and
dh_checksums?)
+ if (-f "$tmp/DEBIAN/md5sums" or -f "$tmp/DEBIAN/sha256sums") {
+ warning("Re-computing checksum file (even though md5sums and/or
sha256sums exists)");
+ }
+
# Check if we should exclude conffiles.
my $exclude="";
if (! $dh{INCLUDE_CONFFILES} && -r "$tmp/DEBIAN/conffiles") {
@@ -76,6 +93,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
}
complex_doit("(cd $tmp >/dev/null ; find . -type f $e
Re: Bug#540215: Introduce dh_checksums, clear-signed checksum
On Wed, 2010-03-10 at 10:52 -0800, Russ Allbery wrote: > Peter Samuelson writes: > > [Wouter Verhelst] > > >> At any rate, a PGP signature takes a lot of data; much more so than > >> a checksum. It's therefore more economical to produce a signed > >> package.checksums file than it is to produce a package.pgpsigs. > > > Huh? Since asymmetric cryptography is so computationally expensive, > > PGP never signs the payload directly. Instead, the payload is hashed > > and then the hash is signed. So it is not (noticeably) more economical > > to sign foo.md5sums than to sign the whole data.tar.gz. > > However, since the most common verification action is probably going to be > to check whether a specific file installed on the system has been > modified, Wouter's approach is probably the best implementation strategy. > It's more efficient to compute the checksum of a file, check that it > matches the checksum in the signed file, and verify the signature on that > file than it is to verify the data.tar.gz signature and then extract the > relevant file from it and compare it to the file on disk. Among other > things, you can use the first algorithm with nothing but the signed > checksum files, which are a lot smaller than keeping the whole package > around. GPG clear-signed messages ¨ I made some tests, and it seems that we could allow,but not require, GPG signed checksum-file. sha256sum will ignore invalid lines by default (unless you specify --warn option). Similarly, the policy could state that GPG clear-signed shasum files are allowed. Tools using shasum should still strip the signature, especially when using the checksum for security purpose. Let me know you find this feature useful (or over engineered). Regards, Franklin -- 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/1268259720.3291.3261.ca...@solid.paris.klabs.be
Re: md5sums files
On Wed, 2010-03-03 at 03:06 +0100, Wouter Verhelst wrote:
>
> I must say I was somewhat surprised by these numbers. Out of 2483
> packages installed on my laptop, 2340 install md5sums. While that
> might've been useful at some point, I don't think it still is.
Hi all,
Can you think of any sensible reason for not including md5sums of
control files, especially the {pre,post}{inst,rm} scripts ?
In the shasum file, those files could be either:
1. inserted, with the patch rewritten to match their expected
location on the target system.
or
2. inserted as a *comment* in the shasum file, like:
#68b329da9893e34099c7d8ad5cb9c940 CONTROL.TAR:postinst
Thanks,
Franklin
--
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/1268264672.3291.3654.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums, clear-signed checksum
On Thu, 2010-03-11 at 00:37 +, The Fungi wrote:
> On Wed, Mar 10, 2010 at 11:22:00PM +0100, Frank Lin PIAT wrote:
> > I made some tests, and it seems that we could allow,but not require, GPG
> > signed checksum-file. sha256sum will ignore invalid lines by default
> > (unless you specify --warn option).
> >
> > Similarly, the policy could state that GPG clear-signed shasum files are
> > allowed. Tools using shasum should still strip the signature, especially
> > when using the checksum for security purpose.
>
> Is there any good reason not to use a detached signature in a
> separate file instead? I know that doubles the number of files, but
> it also reduces the raw size by around 47 bytes and simplifies
> parsing of the checksum files themselves.
My real first question was to know if that can be useful. Plus, not
every one uses gpg-agent, and they may not like to sign each package
twice.
Regarding clearsign-versus-detached, I have no strong preference myself.
clearsigned are nice because they are self-contained, but... see your
rational.
That being said...
Stripping signature:
Stripping the gpg signature is not needed for sha256sum command line,
and it is "trivial", for bash/perl...
sed -n -e '/^-\(BEGIN PGP SIGNED
MESSAGE\)-/,/^-[^\1]/s/^[[:xdigit:]]\{32,\}\s/\0/p' testfile.asc
On disk usage:
¨¨
> echo "" > testfile
> gpg -b testfile
> gpg --clearsign testfile
> ls -l testfile*
> -rw-r--r--. 1 fpiat fpiat 1 2010-03-11 09:55 testfile
> -rw-r--r--. 1 fpiat fpiat 886 2010-03-11 09:55 testfile.asc
> -rw-r--r--. 1 fpiat fpiat 543 2010-03-11 09:55 testfile.sig
but...
> du testfile*
> 4 testfile
> 4 testfile.asc
> 4 testfile.sig
The actual on disk usage is increased, up to one disk block
Tarfile usage
¨
> tar -zcvf detached.tar.gz testfile testfile.sig
> testfile
> testfile.sig
> tar -zcvf clearsign.tar.gz testfile.asc
> testfile.asc
> ls -l *.gz
> -rw-r--r--. 1 fpiat fpiat 815 2010-03-11 10:00 clearsign.tar.gz
> -rw-r--r--. 1 fpiat fpiat 759 2010-03-11 10:00 detached.tar.gz
The archive file is increased by 47, which is marginal, compared to the
increase in size of sha256 <> md5 hash size :-(
--
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/1268298752.3959.161.ca...@solid.paris.klabs.be
Re: source.debian.net
On Sat, 2010-03-13 at 20:37 +0100, Julien Cristau wrote: > On Sat, Mar 13, 2010 at 14:28:38 -0500, Michael Gilbert wrote: > > > Does anyone know who maintains source.debian.net? It's a really great > > service, but its been down for about a month now. I would like to > > to make sure they're aware of the problem. Thanks. > > > from a debian machine, > ldapsearch -LLL -x 'dnszoneentry=source *' uid > will tell you who owns the dns entry. There is also: http://wiki.debian.org/DebianNetDomains Regards, Franklin -- 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/1268517752.4643.4157.ca...@solid.paris.klabs.be
Re: Invite to join the Release Team
Hi dear Teams, A few weeks ago, someone posted a link on planet.d.o, on how to demotivate contributors (a wikipedia page)... unfortunately I can't find the page anymore... On Sun, 2010-03-14 at 00:02 +0100, Joerg Jaspert wrote: > On 12053 March 1977, Luk Claes wrote: > > > You seem to send the message that you can judge from the sideline how > > things should be run, so I hereby invite you to join the Release Team > > and do a proper job. > > [..] The first was him taking the FTP team as an example for good > communication I have listed the announcements made by the Release team, and they seem to spend quite some time doing it, as are quite a few entries (see below or [1]) Yes, the FTP team is trying to be transparent, and that's great. That's no reason to pick on other teams. As usually, "patch welcome" applies (I guess;) My 2¢, Franklin Some announcements made by the release team... 2008-07 : Etch updated (4.0r4) aka etch-and-a-half 2008-10 : Etch updated (4.0r5) 2008-12 : Etch updated (4.0r6) 2009-02 : Lenny Release update: deep freeze, planned dates, and remaining bugs 2009-02 : Etch updated (4.0r7) 2009-02 : Etch becomes old-stable. 2009-02 : Initial released : 5.0.0 2009-03 : Kicking off Squeeze: initial tidbits from the RMs 2009-04 : Etch updated (4.0r8) 2009-04 : Lenny updated (5.0.1) 2009-06 : Lenny updated (5.0.2) 2009-07 : Debian decides to adopt time-based release freezes 2009-07 : Bits from the release team and request for discussion 2009-07 : Debian GNU/Linux 6.0 "Squeeze" release goals 2009-08 : Bits from the release team: Release goals, schedule, state of the union 2009-09 : Lenny updated (5.0.3) 2009-09 : Release Team, BTS, and debian-release@ policy. 2009-10 : Bits from the release team: Planning, request for help]] 2010-01 : Lenny updated (5.0.4) 2010-02 : Release architectures 2010-02 : End of security updates / End of life. 2010-02 : Bits from the Stable Release Team [1] http://wiki.debian.org/Teams/ReleaseTeam#News -- 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/1268567928.3788.1380.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
On Wed, 2010-03-17 at 11:31 +0100, Wouter Verhelst wrote: > On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote: > > Wouter Verhelst writes: > > > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote: > > >> Harald Braumann writes: > > >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote: > > >> >> > > >> >> Having package.checksums be GPG-signed will take a significant change > > >> >> in > > >> >> our infrastructure (buildd hosts, for instance, would need to have a > > >> >> way > > >> >> to sign checksums files as well), so it's not going to happen > > >> >> tomorrow. > > >> > > >> That can be avoided by including a hash of the checksum file in the > > >> Packages files. > > > > > > That doesn't help for the problem we're trying to fix here: having a > > > path to a GPG signature from an individual binary on the hard disk, > > > months or years after the package was installed. > > > > > > With your proposal, you lose the signatures once the package is out of > > > the archive and you run 'apt-get update'. > > > > Then don't do that. :) > > We can hardly say to our users "if you want to be able to check > signatures, never run run apt-get update"... Not necessarily. I assume that it would be easy (and cheap) to preserve a copy of the previous: http://ftp.debian.org/debian/dists/testing/InRelease http://ftp.debian.org/debian/dists/testing/main/binary-i386/Packages.diff/* It would then be possible to reverse apply the diff, and validate the packages when needed. The disk-space cost would be quite low. Currently, that's 448K for 6 days (27MB/year), which is quite cheap compared to cached binaries that have to be preserved too. (And it comes to my mind that it might be possible to implement some roll-back feature... If we were supporting to downgrade packages to some extend;) I have no strong preferences between signed APT and SIGNED DEBs... it is just that the remaining of the thread showed that signed DEBs are quite tough to implement. (and I still wonder how we could preserve the current deb format with "tar.gz in ar", while signing the debs) That's 2 more cents from me, Franklin -- 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/1268956013.11872.58.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote: > On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: > > Russ Allbery writes: > > > Simon McVittie writes: > > > > >> Most packages (in terms of proportion of the archive, in particular for > > >> architectures other than i386 and amd64) are built by a buildd, so each > > >> buildd would have to have a signing key that could sign the checksums > > >> file during build. > > Self-contained packages, where the signature is included and installed > along with the checksum file, would have a lot of > advantages. You wouldn't need access to a lot of infrastructure just > to verify a signature. It would be very simple. It could be used for > packages, that are not part of Debian. For instance, I could produce a > package and send it to a friend and he could later use my key for > verification. Oh please no. Don't advocate sending individual .deb files, ever. This practice should be strongly discouraged. One brilliant part of Debian packaging *is* the APT infrastructure, some key features: 1. Security updates 2. Bug fixes 4. Dependency resolution 5. Smoother dist-upgrades because: 5a. The APT repository provides newer version, with updated dependencies (libraries transitions...) 5b. The user don't have to visit each web site to dist-upgrade 6. Single GPG key to manage (revocation ; update...) 7. Single GPG key to trust (per repository) If people and ISV start publishing individual .deb, they (and we) will have to face the same problem as Windows/Mac/whatever had to solve: each application will need to embed a feature to "Check for update", etc. I am spending about 2 hours every two month on my parents computer, just update all the damned Windows applications. Who really wants Debian to go down that say. I must say that if someone can't "setup" an APT repository to publish packages, you should reconsider the installation of any package from that person/ISV. (Reminder the Debian Policy has 135 pages, whom ever can read and use it to create a proper package can also read a few manpages to setup a repository). The same stand for RPM & co. cat < /home/fpiat/2¢ >> debian-devel Regards, Franklin -- 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/1268986453.3488.183.ca...@solid.paris.klabs.be
Re: Bug#540215: Introduce dh_checksums
Wouter Verhelst wrote: > On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote: >> On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote: >> > On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: >> > > Russ Allbery writes: >> > > > Simon McVittie writes: >> > > >> > > >> Most packages (in terms of proportion of the archive, in >> particular for >> > > >> architectures other than i386 and amd64) are built by a buildd, >> so each >> > > >> buildd would have to have a signing key that could sign the >> checksums >> > > >> file during build. >> > >> > Self-contained packages, where the signature is included and installed >> > along with the checksum file, would have a lot of >> > advantages. You wouldn't need access to a lot of infrastructure just >> > to verify a signature. It would be very simple. It could be used for >> > packages, that are not part of Debian. For instance, I could produce a >> > package and send it to a friend and he could later use my key for >> > verification. >> >> Oh please no. Don't advocate sending individual .deb files, ever. > > That already happens, will always happen, and it cannot be avoided. I wish we could avoid it for end-users & "consumer products". > There are perfectly valid use cases for using "individual .deb files". > To give but one example that comes directly from my day job: I build an > image for an embedded system that boots off a read-only /. You build, you deploy, you trust your self. Is is the best example out there ? I must admit it is still a valid example. > Since we > can't modify our filesystem after booting, the way an update is done is > through "regenerate the image and boot off a USB stick", rather than > "apt-get update". Since the latter doesn't work anyway, setting up a > full repository with Packages file and whatnot is vast overkill, so the > software that was written specifically for this system is packaged as a > .deb file that is not in a repository, anywhere. > >> This practice should be strongly discouraged. One brilliant part of >> Debian packaging *is* the APT infrastructure, some key features: > > In the above example: > >> 1. Security updates > > Does not apply (when the devices are connected to a network, that means > they're either undergoing maintenance or someone is trying to break into > the system) In your scenario, the system adminitrator fetch the source from the distributor (That can/should be done through an APT mirror), then deploy the managed systems. >> 2. Bug fixes > > "If it ain't broken, don't fix it" applies even more to this kind of > embedded systems than it does to servers. In my organisation, we do deploy service pack and point release, Even though the perceived state would suggest "If it ain't broken, don't fix it" >> 4. Dependency resolution > > "apt-get -f install" > >> 5. Smoother dist-upgrades because: >> 5a. The APT repository provides newer version, with updated >> dependencies (libraries transitions...) > > the custom software does not include libraries Don't they include libraries? Don't they depend on Debian libraries? Wouldn't that prevent smooth upgrades? And more important, who the users are going to blame? The broken package or Debian (my conviction is that people will blame the OS vendor) >> 6. Single GPG key to manage (revocation ; update...) > > I don't understand what you mean by that. If each package is signed by a DD, a system admin have to manage multiple public keys. >> 7. Single GPG key to trust (per repository) > > Well, signatures on .deb files would also have a "single" GPG key to > manage, per source. There's no difference here, really. > > It's important to remember that whatever environment you're using Debian > in, is not necessarily the *only* environment Debian is used in. This is a very valid point. > Since a method that will work for individual .debs will also > work for archive-wide installations, there really is no problem > in doing it in such a way that it will work for both ways. Yes, I am really concerned with the "consumer products" users. (and the usual "do the easiet and faster way, long term consequences doesn't matter", see teh banner on [1]) BTW in 12 days, I will send a "AUTORUN.DEB" proposal: Any package named AUTORUN.DEB present on a removable media should be automatically installed when that media in inserted. ;-) Regards, Franklin [1] http://packages.debian.org/lenny/i386/dash/download -- 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/7bf34c766afd2f66985ae7f17b3028cc.squir...@www.klabs.be
Re: Bug#540215: Introduce dh_checksums
On Fri, 2010-03-19 at 17:40 +0100, Wouter Verhelst wrote: > On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote: > > You add an additional ar member that contains the signed checksums of all > > of the files in data.tar.gz, possibly another additional member that > > contains the signed checksums for control.tar.gz, or you document some > > convention so that you can combine both into the same signed checksum > > document. > > That'd work pretty well, indeed. It would also have the advantage of > making it theoretically possible to reverse the addition of the > signatures again, should one want to re-verify against the original > .changes file for some reason. That's of course assuming that the > combination of "ar a" and "ar d" in whatever way dpkg does that is > idempotent, but I don't see why it couldn't be. > > And as you say, this can be implemented in dak. That would have the > advantage of not requiring keys on the buildds. > > So now that it's been reduced to a technical problem, who's going to do > the implementation? Yes, this solution is elegant. It shouldn't break anything, it is self-contained in the package. > I'm prepared to look at a dpkg patch, but Python > just does not work for me. My priority is the md5sum replacement, but I'll be happy to help if/when I can. Regards, Franklin -- 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/1269031779.4361.259.ca...@solid.paris.klabs.be
Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory
[re-sending, with proper debian-devel address, sorry for the noise] Hello Christopher and all, This ITP was stalled, so I packaged this tool. I am looking for one or more co-maintainer (read more at the bottom). On Fri, 2009-06-19 at 15:18 -0700, Simmons, Christopher wrote: > Package: wnpp > > I wish to work on creating a debian package for libhugetlbfs-2.4 * Package name: libhugetlbfs Version : 2.7 Upstream Authors: Eric B Munson : Adam Litke : David Gibson * URL : http://libhugetlbfs.sourceforge.net/ * License : LGPL-2.1 Programming Lang: C Description : Tools and Library access huge pages of memory ::libhugetlbfs:: Description: A library which provides access to huge pages of memory libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. Alternatively, applications can be linked against libhugetlbfs without source modifications to load BSS or BSS, data, and text segments into large pages. ::hugepages:: Description: A set of tools to configure huge pages of memory This package contains a number of utilities that will help administrate the use of huge pages on your system. hugeedit modifies binaries to set default segment remapping behavior. hugectl sets environment variables for using huge pages and then execs the target program. hugeadm gives easy access to huge page pool size control. pagesize lists page sizes available on the machine. My current work is available from: http://git.debian.org/?p=collab-maint/libhugetlbfs.git Co-maintainer wanted I am looking for a co-maintainer for this package. There are two reasons for that: 1) I can't write C, well not really. 2) I believe that every package should be co-maintained (in a perfect world anyway). You should be prepared to handle all the aspects of the packaging which are specific to C and/or library handling. I can help for other aspects of packaging, bug handling, backporting patches, etc... Current Lintian : > P: libhuge*: no-upstream-changelog > W: libhugetlbfs*: shlib-without-versioned-soname ... > E: libhugetlbfs: postinst-must-call-ldconfig Regards, Franklin -- 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/1269330984.3587.23.ca...@solid.paris.klabs.be
Group for hugepages / libhugetlbfs
[re-sending, with proper debian-devel address, sorry for the noise] Hello, On Tue, 2010-03-23 at 01:20 +0100, Frank Lin PIAT wrote: > This ITP was stalled, so I packaged this tool... > > * Package name: libhugetlbfs > Description : Tools and Library access huge pages of memory > > ::hugepages:: > Description: A set of tools to configure huge pages of memory > This package contains a number of utilities that will help administrate > the use of huge pages on your system. hugeedit modifies binaries to > set default segment remapping behavior. hugectl sets environment > variables for using huge pages and then execs the target program. > hugeadm gives easy access to huge page pool size control. pagesize > lists page sizes available on the machine. I would like some advices on how to handle group for granting permission to use HugePage/HugeTlbFs. I wonder If I should request a fixed GID... That group can be used in the following places: 1. Sysctl's vm.hugetlb_shm_group = GIDNUMBER 2. hugetlbfs mount-points permissions 3. /etc/security/limits.conf's memlock For #2 and #3, it is possible to use the group name. But unfortunately, sysctl only accept GID number. Is this reason sufficient to request a fixed GID? Alternatively, we could use an init script to do the conversion. I don't like that option very much, because I think it would be better to let /etc/sysctl handle it. What do you think about it? Franklin [1] http://wiki.debian.org/Hugepages -- 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/1269331457.3587.55.ca...@solid.paris.klabs.be
Re: md5sums files... and beyond
Hi,
In case anyone wonders about the status of replacing md5sums with
something stronger _in_ the binary packages, this should be considered
to be suspended until the next development cycle. (at least, from my
PoV).
It have been pointed out that those current checksum aren't sufficient
to validate that an installed package is secure (quoting Joey Hess:
"there are innumerable ways for an attacker to inject bad
behavior/backdoors onto a system without touching binaries originating
from dpkg."[1] and "it's also fairly easy to modify a file in /etc to
provide a backdoor" ...)
Therefore, it should be clear that there is no urgency in replacing
DEBIAN/md5sums as they are "useful for corruption and local (benign)
modification checksumming." (quoting Russ Allbery[2]).
The initial proposal to replace md5sum with ${better}sum:
http://wiki.debian.org/Sha256sumsInPackages
should be enhanced with further meta-data. A very early draft is:
http://wiki.debian.org/Proposals/BinaryPackageDescriptor
Regards,
Franklin
On Thu, 2010-03-11 at 00:44 +0100, Frank Lin PIAT wrote:
> On Wed, 2010-03-03 at 03:06 +0100, Wouter Verhelst wrote:
> >
> > I must say I was somewhat surprised by these numbers. Out of 2483
> > packages installed on my laptop, 2340 install md5sums. While that
> > might've been useful at some point, I don't think it still is.
>
> Hi all,
>
> Can you think of any sensible reason for not including md5sums of
> control files, especially the {pre,post}{inst,rm} scripts ?
>
> In the shasum file, those files could be either:
> 1. inserted, with the patch rewritten to match their expected
> location on the target system.
> or
> 2. inserted as a *comment* in the shasum file, like:
> #68b329da9893e34099c7d8ad5cb9c940 CONTROL.TAR:postinst
[1] http://lists.debian.org/msgid-search/20100308225913.ga25...@gnu.kitenet.net
[2] http://lists.debian.org/msgid-search/87wrxmbkdn@windlord.stanford.edu
--
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/1269982677.3574.252.ca...@solid.paris.klabs.be
Re: deb.li - the Debian ShortURL Service - beta test
Hi, On Sat, 2010-04-03 at 10:10 +0800, Paul Wise wrote: > On Sat, Apr 3, 2010 at 7:52 AM, Bernd Zeimetz wrote: > > > Comments, bugreports and patches are welcome! > > Please add an announcement to DeveloperNews: > > http://wiki.debian.org/DeveloperNews How can we make sure that all URL don't become broken once Bernd's attention move away from Debian (this may happen)? Franklin -- 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/1270308548.3434.2063.ca...@solid.paris.klabs.be
Re: deb.li - the Debian ShortURL Service - beta test
On Sun, 2010-04-04 at 00:30 +0200, Bernd Zeimetz wrote: > On 04/03/2010 05:29 PM, Frank Lin PIAT wrote: > > How can we make sure that all URL don't become broken once Bernd's > > attention move away from Debian (this may happen)? > > If the service is used I'd like to give it into the hands of DSA and have it > runnign on DSA hardware, transfer the domain into the hands of SPI anf just > take > care of the software... I like the plan, Thank you, Franklin -- 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/1270381519.3705.883.ca...@solid.paris.klabs.be
Package description review (in ITP)
Hi, A good package description is important, because sysadmin often decide to install a package (or not), base on it's description. Shouldn't we suggest/require that the descriptions in ITP bugs includes the intended description for the package? (as opposed to a mere copy of upstream description) If debian-devel readers knew for that the submitted description is the one intended to be uploaded, they wouldn't hesitate to provide feedback (spell checking, grammar, lack of context, clarity issues, etc.) Current ITP look likes this: > * Package name: test > Version : x.y.z > Upstream Author : Name > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) > Programming Lang: (C, C++, C#, Perl, Python, etc.) > Description : test > > (Include the long description here.) I suggest to replace the last line with: > (Include the intended long description of the package here.) A few other ressources needs to be changed too: In http://www.debian.org/devel/wnpp/ : Before: > submit a bug report against the pseudo-package wnpp describing your > plan to create a new package, including, but not limiting yourself to, > a description of the package, the license of the prospective package, > and the current URL where it can be downloaded from. New: > submit a bug report against the pseudo-package wnpp describing your > plan to create a new package, including, but not limiting yourself to, > the intended package description, the license of the prospective > package, and the current URL where it can be downloaded from. * http://www.debian.org/doc/developers-reference/pkgs.html In paragraph «Adding new entries with "reportbug"», replace: > Below the "Description" line you should give more information about > the package. By: > Below the "Description" line you should write the description you > intend for the package so other can review it. (If you Request For > Package, you can just give more information about the package). Voilà, Franklin -- 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/1271591288.3364.932.ca...@solid.paris.klabs.be
Re: Bug#579373: ITP: zthreads -- A platform-independent, multi-threading and synchronization library for C++
On Tue, 2010-04-27 at 14:07 +0200, Cleto Martin Angelina wrote: > Package: wnpp > Severity: wishlist > Owner: Cleto Martin Angelina > Owner: Cleto Martin Angelina > > * Package name: zthreads libzthreads? > Version : 2.3.2 > Upstream Author : Eric Crahen > * URL : http://zthread.sourceforge.net/ > * License : MIT > Programming Lang: C++ > Description : A platform-independent, multi-threading, object-oriented > and synchronization library for C++ This is a pretty long "short description". I would suggest something like: "synchronization library" or "synchronization library for C++" > Zthreads is an advanced platform-independant, object-oriented > threading and synchronization library. Designed and tested under POSIX > & Win32 systems. Not just another thread wrapper. > .. > It provides several structures for concurrent programming like > PoolExecutor, MonitoredQueue, Barriers and much more. Futhermore, ^^ My spell checker suggest: Furthermore > structures like Task and Thread are provided for creating threading > applications in C++ easier. > This library is used in Bruce Eckel's book "Thinking in > C++" as a good framework for concurrent programming. This last paragraph could/should be dropped. (IMHO, this sounds like advertising, and it isn't a useful information about what the package is doing / why it is useful / when it it should be used) Thanks, Franklin -- 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/1272437077.3308.1117.ca...@solid.paris.klabs.be
Re: Bug#579076: ITP: bitfrost -- Python library for BIOS security on the OLPC XO laptop
On Sat, 2010-04-24 at 23:17 -0400, Luke Faraone wrote: > > * Package name: bitfrost > Description : Python library for BIOS security on the OLPC XO laptop > > Bitfrost is the OLPC security platform. This package contains tools to > handle securing the early boot stages of the system running on the XO > laptop. Hello, The package description could be improved, to mention what the package is doing : Is it executed at boot time (I doubt so), or is it use to configure the bootload and/or the firmware? Also, what kind of security does it configures? (define a boot password, protect the access to the firmware? configure the boot sequence, etc.) If it configures the firmware, does one needs that tool to revert the changes, or can it be done from the firmware itself? Thanks, Franklin -- 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/1272438297.3308.1242.ca...@solid.paris.klabs.be
Re: Bug#578750: ITP: kmid -- MIDI/Karaoke player for KDE
Hello Lisandro, On Thu, 2010-04-22 at 10:40 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > > * Package name: kmid is it kmid or kmid2? > Description : MIDI/Karaoke player for KDE > KMid is a rewrite from scratch of the original KDE midi player. Not so useful for end-user > It plays MIDI and karaoke files. I would suggest: > This package provides a MIDI and karaoke player for KDE. KMid2 is a > rewrite of kmid for KDE4, with a new architecture and also some new > features. Upstream description also list some interesting features, which could de included (I have dropped some bullets, it could be shorted further to only list the nice features of this MID player). > Some major features: > * Playback to external hardware MIDI devices. > * Allows to use software synths as well. > * Tempo and volume controls. > * Pitch (transpose) control. > * Rhythm view (visual metronome). > * Configurable character encoding, font and color for lyrics. > * MIDI Mapper. > * Channels window, with solo/muting controls and instrument selectors. > * MIDI sequencing is implemented on pluggable backends. Does it just play .MID files, or does it also plays some similar files? Regards, Franklin -- 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/1272439504.3308.1361.ca...@solid.paris.klabs.be
Re: Bug#579675: ITP: goban -- Goban screensaver
Hello, On Thu, 2010-04-29 at 22:36 +0400, Al Nikolov wrote: > Package: wnpp > Severity: wishlist > Owner: Al Nikolov > > > * Package name: goban > Version : 1.1 > Upstream Author : Scott Draves > * URL : http://draves.org/goban/ > * License : GPL > Programming Lang: C > Description : Goban screensaver The short description should not include the package name, maybe something like: "screen saver replaying games of Go" > Replays historical games of go (aka wei-chi and baduk) on the screen. The long description could/should also mention: - that it's a screen-saver. - that it is "Designed to work with xscreensaver and Gnome." - which "historical games of go" are replayed? (the game played using cgoban, right?) Franklin -- 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/1272832135.5782.2121.ca...@solid.paris.klabs.be
Re: Bug#579569: ITP: ants -- advanced normalization tools for brain and image mapping
On Wed, 2010-04-28 at 13:23 -0400, Yaroslav Halchenko wrote: > > * Package name: ants > Description : advanced normalization tools for brain and image mapping > > The ANTS package is designed to enable researchers with advanced tools for > brain and image mapping. ^^ This paragraph could be written in a way to clarify that this tool analyses brain images (i.e it has nothing to do with organizing mind/ideas) > Many of the ANTS registration tools are > diffeomorphic, but deformation (elastic and BSpline) transformations are > available. Unique components of ANTS include multivariate similarity metrics, > landmark guidance, the ability to use label images to guide the mapping and > both greedy and space-time optimal implementations of diffeomorphisms. The > symmetric normalization (SyN) strategy is a part of the ANTS toolkit as is > directly manipulated free form deformation (DMFFD). Thanks, Franklin -- 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/1272833573.5782.2283.ca...@solid.paris.klabs.be
Re: Bug#579600: ITP: sigrok -- Crossplatform logic analyzer and protocol decoder software
On Thu, 2010-04-29 at 00:41 +0200, Uwe Hermann wrote: > Owner: Uwe Hermann > > * Package name: sigrok > Version : 0.1 Version is 0.1... the package description could mention that the software is an early release (alpha/experimental), to avoid deception (and encourage feed-back). > Description : Crossplatform logic analyzer and protocol decoder software Some suggestions to improve the description: > sigrok is a portable, cross-platform, Free/Libre/Open-Source logic analyzer > software This paragraph applies to the whole Debian archive, so it could be dropped. > that supports various logic analyzer hardware products. So, the description could start with: "sigrok is a logic analyzer and protocol decoder software..." Then "This is used by [whom] to help doing [what]." > Design goals: Those features could be written as text, rather than bullets. > - Broad hardware support. Supports a wide variety of logic analyzers >from various vendors with different capabilities. Isn't that implicit, from the list below? > - Cross-platform. Works on Linux, Mac OS X and Windows, Does this really matter to Debian users? > and on many architectures including x86, ARM, Sparc and PowerPC. Unless this feature is unique to this tool, it can be dropped. > - Scriptable protocol decoding. Extendable with protocol decoders >and analyzers written in Python. > - Format support. Supports various input and output formats (raw, >ASCII, hex, CSV, gnuplot, VCD, others). > > Supported (and/or work-in-progress) logic analyzer devices: (A list is fine here.) > - Saleae Logic > - EE Electronics XLA/ESLA100 > - ASIX SIGMA > - Openbench Logic Sniffer > - ZEROPLUS Logic Cube LAP-C series > - CWAV USBee SX > - Braintechnology USB-LPS > - Buspirate (v3) > - Intronix Logicport My cents, Franklin -- 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/1272834584.5782.2402.ca...@solid.paris.klabs.be
Re: Bug#579692: ITP: libtest-inter-perl -- framework for more readable interactive test scripts
On Thu, 2010-04-29 at 22:03 +0100, Chris Butler wrote: > Package: wnpp > Owner: Chris Butler > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org > > * Package name: libtest-inter-perl > Version : 1.01 > Upstream Author : Sullivan Beck > * URL : http://search.cpan.org/dist/Test-Inter/ > * License : Artistic or GPL-1+ > Programming Lang: Perl > Description : framework for more readable interactive test scripts Just a quick suggestion to improve the description: > Test::Inter is another framework for writing test scripts. It is loosely ^ insert "for perl developers". which clarifies: - the programming language - who are the intended users (i.e the developers) > inspired by Test::More, and has most of it's functionality, but it is > not a drop-in replacement. > > This framework offers the ability to write the tests in a more readable > format, and you can access specific tests in a reasonably interactive fashion. My 2¢, Franklin -- 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/1272834588.5782.2403.ca...@solid.paris.klabs.be
Re: Bug#579147: ITP: libapp-cpanminus-perl -- Get, unpack, build and install modules from CPAN
On Sun, 2010-04-25 at 18:12 +, Jeremiah C. Foster wrote: > > * Package name: libapp-cpanminus-perl > Description : Get, unpack, build and install modules from CPAN > > A dependency free, zero configuration, and stand alone CPAN module > installer. Maintainable and extensible with plugins and friendly > to shell scripting. When running, it requires only 10MB of RAM. The package description should mention that the modules aren't integrated with Debian packaging (no resolution dependency ; some conflicts may happens ; security updates aren't handled by apt***, etc). Also, installing the same module on 2 systems at a few days interval does not guarantee to install the the version (isn't it?) So the preferred way to install a perl module in Debian is to use package from Debian) My 2 cents, Franklin -- 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/1272835062.5782.2452.ca...@solid.paris.klabs.be
Re: Bug#579177: ITP: xul-ext-monkeysphere -- Iceweasel/Firefox extension for using Monkeysphere on the web
On Sun, 2010-04-25 at 18:44 -0400, Jameson Graef Rollins wrote: > * Package name: xul-ext-monkeysphere > Version : 0.1 The package description could mention that this is an early/alpha/experimental release, to avoid deception (and encourage feed-back) > Description : Iceweasel/Firefox extension for using Monkeysphere on the > web > > Monkeysphere is a system for using the OpenPGP web of trust > as a PKI for rsa keys. ^^^ Is it appropriate to name those keys "RSA" Wouldn't it be better to state that it's a replacement for X509 certificates? (there is probably an even better wording, but I can't find it). > This extensions enables Monkeysphere checking of X.509 certificates > from https hosts whose keys are in the web of trust. The long description should mention that this package contains an Iceweasel extensions, maybe: "This package contains an Iceweasel/Firefox extensions to use Monkeysphere for checking of X.509 certificates from https hosts whose keys are in the web of trust." My 2 cents, Franklin -- 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/1272836217.5782.2566.ca...@solid.paris.klabs.be
Re: Bug#579177: ITP: xul-ext-monkeysphere -- Iceweasel/Firefox extension for using Monkeysphere on the web
On Mon, 2010-05-03 at 12:13 -0400, Jameson Rollins wrote: > Hi, Frank. Thanks so much for the feedback. Responses below. > > On Sun, 02 May 2010 23:36:57 +0200, Frank Lin PIAT wrote: > > On Sun, 2010-04-25 at 18:44 -0400, Jameson Graef Rollins wrote: > > > * Package name: xul-ext-monkeysphere > > > Version : 0.1 > > > > The package description could mention that this is an > > early/alpha/experimental release, to avoid deception (and encourage > > feed-back) > > This extension definitely is in the early stages of development, but it > is working for most cases now, and the developers are using it > routinely. I'm also not sure how we would indicate that it's "alpha" or > "experimental" in the Package: or Version: fields of the control file, > which I think is what you're implying. Do you have a suggestion for > that? I have gathered some existing "excuses", but none seems to fit your need. http://wiki.debian.org/PackagesDescriptions/Fragments Based on what you told, upstream might want to number it 0.9 ;) Still, let me give a try: "Although the program is still in development stage, It already have some useful features, and it is quite stable" Feel free to adjust or rewrite it. > > Wouldn't it be better to state that it's a replacement for X509 > > certificates? (there is probably an even better wording, but I can't > > find it). > > Monkeysphere is not actually a replacement for X.509, at least not in > the sense of using Monkeysphere *or* X.509. The goal of Monkeysphere, > broadly, is to expand the usage of OpenPGP for authentication on the > net. In the context of the web, the Monkeysphere xul extension can be > used to validate sites that have put their host keys on the OpenPGP Web > of Trust (WOT). However, the extension actually currently relies upon > sites providing an X.509 certificate through normal TLS channels. We > provide a fallback validation check using the WOT when the standard > X.509 validation fails. Our goal is not to disrupt standard X.509 > validation if the user wishes to continue to rely upon it, but to > instead provide an alternative to standard X.509 validation that uses > OpenPGP and the WOT. ok we "just" have to figure out how to write that in 4 or 5 lines ;) "Monkeysphere uses OpenPGP's « Web of Trust » to validate X509 certificates that aren't signed by a known certificate authorities (CA)." We could also something like this: "In regular public key infrastructure (PKI), X509 certificates are signed by a third party organisations, that are considered to be trusted by both the webserver-admin and the web-browser vendor." > I agree, though, that it is relevant to mention X.509 in the package > description, at least in the sense of providing an alternative, but I > feel like we're currently doing that with this bit: > > > > This extensions enables Monkeysphere checking of X.509 certificates > > > from https hosts whose keys are in the web of trust. > > Does this not seem clear enough? Or is there something else that we're > missing in the description to make things clearer? > > > The long description should mention that this package contains an > > Iceweasel extensions, maybe: > > "This package contains an Iceweasel/Firefox extensions to use > > Monkeysphere for checking of X.509 certificates from https hosts > > whose keys are in the web of trust." > > Good point. We'll fix that. Again, just my 2 cents ;) Franklin -- 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/1272924329.3999.930.ca...@solid.paris.klabs.be
Re: Bug#579675: ITP: goban -- Goban screensaver
On Mon, 2010-05-03 at 17:01 +0400, Al Nikolov wrote: > On Monday 03 May 2010 00:28:55 Frank Lin PIAT wrote: > > > Description : Goban screensaver > > > > The short description should not include the package name, maybe > > something like: > > "screen saver replaying games of Go" > > > Replays historical games of go (aka wei-chi and baduk) on the screen. > > > > The long description could/should also mention: > > - that it's a screen-saver. > > If this is mentioned in the short description? The short description is like the subject of an email. see developper-reference[1]. > > - that it is "Designed to work with xscreensaver and Gnome." > > I don't think it should be linked with Gnome somehow. I suppose it should only mention Gnome if it actually uses Gnome libs, or if integrates with gnome properly. (My suggestion was based on my understanding of upstream's website). > Xscreensaver is almost standard part of every usual desktop > installation, at least for Gnome/KDE, and it is in Required. xscreensaver is not part of Lenny/Gnome desktop. I would file a bug if Squeeze/Gnome were recommending xscreensaver. Anyway, it doesn't matter to mention xscreensaver in the description, the package will depend on it, isn't it? > >- which "historical games of go" are replayed? (the game played > > using cgoban, right?) > > Well, no. Actually the original source tarball is consisting of some set of > historic games which can be easily extended/replaced by user. Even though this is possible, I suppose that very few users will do it, so it isn't the main feature. So, maybe something like: "This is a screen saver that replays some games of go (aka wei-chi and baduk). The pre-recorded games shipped in the packages were recorded during various tournaments" (please review this description carefully, especially the statement in the second sentence). Feel free to improve/rewrite my suggestions. Franklin [1] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis -- 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/1272926149.3999.1115.ca...@solid.paris.klabs.be
Re: Bug#579675: ITP: goban -- Goban screensaver / copyright issue
On Thu, 2010-04-29 at 22:36 +0400, Al Nikolov wrote: > > * Package name: goban > * URL : http://draves.org/goban/ > * License : GPL >From what I understood, the package contains a copy of some games that were recorded during some tournaments. The records are retrieved from [1], but the website mention: « The databases on this site are a service to the Go Community:"The databases have been compiled by Jan van Rongen and are his copyright. They can be distributed freely, as long as this copyright statement is distributed with them. The databases shall not be made part of any [non] commercially available database collection of games of go without the written permission of Jan van Rongen." » 1. Do you think Jan van Rongen actually owns some copyright on those files (I am not sure if he played any of those games) 2. If Jan van Rongen owns some copyright, I am afraid the games are non-free (are they). > Description : Goban screensaver > > Replays historical games of go (aka wei-chi and baduk) on the screen. Regards, Franklin [1] http://www.xs4all.nl/~rongen17/ -- 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/1272926518.3999.1152.ca...@solid.paris.klabs.be
Re: Bug#579284: ITP: voxbo -- processing, statistical analysis, and display of brain imaging data
On Mon, 2010-04-26 at 15:05 -0400, Michael Hanke wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Hanke > > * Package name: voxbo > Version : 1.8.5 > Upstream Author : Daniel Kimberg > * URL : http://www.voxbo.org > * License : GPL-3 > Programming Lang: C++ > Description : processing, statistical analysis, and display of brain > imaging data This is a pretty long short-description, I suggest: "analysis, and display of brain imaging data" > This is a toolkit for analysis of functional neuroimaging (chiefly > fMRI) experiments and voxel-based lesion-behavior mapping. VoxBo > supports the modified GLM (for autocorrelated data), as well as the > standard GLM for non-autocorrelated data. The toolkit is designed to be > interoperable with AFNI, FSL, SPM and others. The package description could mention that it is targeted for medical field. Regards, Franklin -- 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/1272926615.3999.1164.ca...@solid.paris.klabs.be
Re: Bug#579284: ITP: voxbo -- processing, statistical analysis, and display of brain imaging data
On Mon, 2010-05-03 at 19:11 -0400, Michael Hanke wrote: > On Tue, May 04, 2010 at 12:43:35AM +0200, Frank Lin PIAT wrote: > > On Mon, 2010-04-26 at 15:05 -0400, Michael Hanke wrote: > > > > > > * Package name: voxbo > > > Description : processing, statistical analysis, and display of > > > brain imaging data > > > > This is a toolkit for analysis of functional neuroimaging (chiefly > > > fMRI) experiments and voxel-based lesion-behavior mapping. VoxBo > > > supports the modified GLM (for autocorrelated data), as well as the > > > standard GLM for non-autocorrelated data. The toolkit is designed to be > > > interoperable with AFNI, FSL, SPM and others. > > > > The package description could mention that it is targeted for medical > > field. > > Do you have any specific phrase in mind. Voxbo is not limited to medical > usecases, but first and foremost neuroimaging/cognitive neuroscience research. May be something like: --- This is a toolkit for analysis of functional neuroimaging (chiefly fMRI) experiments and voxel-based lesion-behavior mapping. It is primarily used in neuroimaging and cognitive neuroscience research. . VoxBo supports the modified GLM (for autocorrelated data), as well as the standard GLM for non-autocorrelated data. The toolkit is designed to be interoperable with AFNI, FSL, SPM and others. --- Regards, Franklin -- 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/1272952261.3068.243.ca...@solid.paris.klabs.be
Re: Bug#579796: ITP: othman -- electronic Quran browser in Python
On Fri, 2010-04-30 at 23:18 +0300, أحمد المحمودي wrote: > * Package name: othman > * License : Waqf Public License > Description : electronic Quran browser > > Othman electronic Quran browser displays Quranic text in Othmani script style > as written under authority of Othman ibn Affan the companion of prophet > Muhammad (Peace Be Upon Him). Regarding the long description, Not everyone knows that "Othmani script" is a script for Arabic. (I didn't know it anyway;) So it might be worth mentioning that the text is in Arabic only (is it?). > Othman project features fast search, autoscrolling I suggest "Othman brower features fast search and autoscrolling" > copy Quranic text to clipboard. Copy/Paste is a trivial feature. You might want to drop it from the description (except if this feature is fairly unique for Quran readers) I wonder who many people use the word "Coran" for Qur'an in English. If this is quite frequent, you might want insert this synonym somewhere in the description. My 2 cents, Franklin -- 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/1273001942.3088.553.ca...@solid.paris.klabs.be
Re: Bug#580221: ITP: python-libssh2 -- python-libssh2 is a python binding for libssh2 library.
On Tue, 2010-05-04 at 15:47 +0200, fabien.dot.bouc...@gmail.com wrote: > > * Package name: python-libssh2 > Description : python-libssh2 is a python binding for libssh2 library. The short description should not contain the package name, so: "python binding for libssh2 library." > python-libssh2 is a python binding for libssh2 library. > It was forked and rewrote from scratch using old org.keyphrene > (http://sourceforge.net/projects/orgkeyphrene/) bindings. It is usually a good idea to insert the original library's description, so I suggest the following long description: - libssh2 is the thin library implementing client side of SSH2 protocol as defined by Internet Drafts SECSH-TRANS, SECSH-USERAUTH, SECSH-CONNECTION, SECSH-ARCH, SECSH-FILEXFER, SECSH-DHGEX, SECSH-NUMBERS, and SECSH-PUBLICKEY . This boils down to the regular terminal, scp and SFTP sessions; port forwarding; password, key-based and keyboard-interactive authentication. . This package contains the python bindings libssh2. It is a fork and rewrite of org.keyphrene. - Note that the two first paragraph are a pristine copy of libssh2 description... the I18N teams should appreciate ;) Regards Frankli n -- 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/1273002350.3088.600.ca...@solid.paris.klabs.be
Re: Bug#580176: ITP: obdgpslogger -- Suite of tools to log OBDII and GPS data
On Mon, 2010-05-03 at 20:39 -0700, Gary Briggs wrote: > Package: wnpp > Severity: wishlist > Owner: Gary Briggs > > * Package name: obdgpslogger > * URL : http://icculus.org/obdgpsloger/ wrong URL: http://icculus.org/obdgpslogger/ > Description : Suite of tools to log OBDII and GPS data > > Tools to log OBDII and GPS data in your car and convert to CSV or google > earth > Includes a modular OBDII Simulator This package contain a suite of tools to log OBDII and GPS data in your car and convert to CSV or google earth KML file. OBD-II (On-Board Diagnostics) are vehicle's self-diagnostic and reporting capability, which can be use to monitor vehicle speed, engine RPM, throttle position, oil temperatures and much more. The package also includes a modular OBDII Simulator The description could certainly be described further. -- 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/1273003539.3088.737.ca...@solid.paris.klabs.be
Re: Bug#579871: ITP: libnet-https-any-perl -- A perl module for HTTPS GET and POST using any available SSL module
On Sat, 2010-05-01 at 15:25 -0700, Ivan Kohler wrote: > > * Package name: libnet-https-any-perl > Description : A perl module for HTTPS GET and POST using any available > SSL module Short description is too long. May be just: "Perl module for HTTPS GET and POST" > This is a simple wrapper around either of the two available SSL > modules. It offers a unified API for sending GET and POST requests > over HTTPS and receiving responses. I suggest a few improvements: "Net::HTTPS::Any library is a simple wrapper around either of the two available SSL/TLS perl modules. It offers a unified API for sending simple GET and POST requests over HTTPS and receiving responses." > It depends on Net::SSLeay _or_ ( Crypt::SSLeay and LWP::UserAgent ). I suppose that this last sentence is not part of the description. My two cents, Franklin -- 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/1273004357.3088.834.ca...@solid.paris.klabs.be
Re: Bug#580221: ITP: python-libssh2 -- python-libssh2 is a python binding for libssh2 library.
On Tue, 2010-05-04 at 22:40 +0200, Simon Josefsson wrote: > Frank Lin PIAT writes: > > > > Note that the two first paragraph are a pristine copy of libssh2 > > description... the I18N teams should appreciate ;) > > On the other hand, I don't think the libssh2 description is particularly > useful for a user. The uppercase acronyms aren't friendly. How about > something like this: > > libssh2 is a client-side C library implementing the SSH2 protocol > with support for regular terminal, scp and SFTP sessions; port > forwarding; password, key-based and keyboard-interactive > authentication. Yes, it looks better. We could file a bug against libssh2 now ;) > This package contains the python bindings libssh2. It is a fork and > rewrite of org.keyphrene. Regards, Franklin -- 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/1273006927.3088.1114.ca...@solid.paris.klabs.be
Re: Bug#579569: ITP: ants -- advanced normalization tools for brain and image mapping
On Sun, 2010-05-09 at 12:36 -0400, Yaroslav Halchenko wrote: > Thanks Frank! > > On Sun, 02 May 2010, Frank Lin PIAT wrote: > > > Description : advanced normalization tools for brain and image > > > mapping > > > The ANTS package is designed to enable researchers with advanced tools for > > > brain and image mapping. > > This paragraph could be written in a way to clarify that this tool > > analyses brain images (i.e it has nothing to do with organizing > > mind/ideas) > it never used 'mind' in the description ;) but lets indeed make it more > descriptive/less confusing: thanks > Description: advanced normalization tools for brain and image analysis > Advanced Normalization Tools (ANTS) is an ITK-based suite of > normalization, segmentation and template-building tools for quantitative > morphometric analysis. > > better? The concept of "brain and image mapping" seems to be gone, I don't know how important it is. At the risk of being picky... ITK is quite technical. GUI might be more explicit. Thanks, Franklin -- 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/1273437377.7507.118.ca...@solid.paris.klabs.be
Re: ITP: gnome-media-player -- GNOME Media Player is a simple media player for GNOME that supports playing media using the vlc, xine and gstreamer engines.
On Sun, 2010-05-09 at 17:58 +0200, Julien Cristau wrote: > On Sun, May 9, 2010 at 18:25:15 +0300, Bilal Akhtar wrote: > > > Package name: gnome-media-player I find the package name extremely misleading: There is already a "Gnome Media Player": Gnome's Totem. BTW, do we really need yet another media player? If you follow GNOME HID (like Totem) and use the same back-ends as Totem, the two applications are very likely to be pretty identical (?) Why not contributing to totem directly? > > Version : 0.1.2 > > Description : GNOME Media Player is a simple media player for > > GNOME that supports playing media using the vlc, xine and gstreamer > > engines. > > This is not a short description. Try to make it fit in a line. I suggest: "simple media player for GNOME and Gtk+." Actually, I don't get the impression that "simple" is appropriate. The launchpad page mention: | The goal is to combine multiple engines into a consistent user | interface so users can switch between engines without having to | retrain themselves to use a different UI." That seems to be the "unique" feature of the tool. > > GNOME Media Player is a simple media player for GNOME that supports > > playing media using the vlc, xine and gstreamer engines. > It has the ability to switch between the engines in the GUI, This statement is strange for a package which is advertized as "GNOME Media Player". You could drop this statement and just mention that it's for GNOME and Gtk+ > > ... and features an engine Auto-select mode, which automatically > > selects the best engine for playing the selected file. I am not a native English speaker, but that could be worded in a simpler way. > And this makes it sounds like a pretty pointless piece of software... * The description should state that it is "a replacement for GNOME's official media player (totem)" (or something similar, to mention that it isn't the "official media player") * The description should mention that the software is still in "early development stage", then mention the consequences (missing feature, unstable, ...) my 2 cents, Franklin -- 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/1273647338.3588.2787.ca...@solid.paris.klabs.be
Re: APT do not work with Squid as a proxy because of pipelining default
On Tue, 2010-05-18 at 14:02 +1200, Robert Collins wrote: > Given that pipelining is broken by design, that the HTTP WG has > increased the number of concurrent connections that are recommended, > and removed the upper limit - no. I don't think that disabling > pipelining hurts anyone - just use a couple more concurrent > connections. Lots of [new] users are using Debian in Non-Debian infrastructure, which may use unpatched squid. They would get a bad initial perception of Debian, if it wasn't working with standard setup. My 2cents, Franklin -- 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/1274160733.4972.94.ca...@solid.paris.klabs.be
Re: file-roller: Can't open .deb by default (aka should recommend binutils)
Hi Folks, I filed the following bug (515175), which raises 2 questions: In Bug 515175, Frank Lin PIAT wrote: > Package: file-roller > Version: 2.22.4-2 > Severity: normal > > On a default gnome-desktop system (Lenny), .deb files (application/x-deb) > are associated with file-roller, but it can't open it. > > Please recommend or depend on the package binutils (which provides > /bin/ar). 1. Should file-roller (and similar programs) use /bin/ar or dpkg-deb to extract the contents of archives? If it should use /bin/ar, then wouldn't it be sensible to move ar to another package than binutils, so we don't need to install on all gnome dsktops? On the other hand, if (Gnome) file-roller were to use dpkg-deb, it would be probably be broken on rpm based distributions. 2. Wouldn't it be more sensible to have .deb files associated to a user friendly package information viewer, like gdeb or gdebi? Franklin P.S. Obviously, this is a post-lenny discussion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
On Thu, 2009-02-26 at 21:07 +0100, Joerg Jaspert wrote: > The new sections are: [..] > videoVideo viewers, editors, recording, streaming What about renaming sound as audio? (if we introduce the video one, ) Since the (perl|python|ruby|...) sections should contains libraries, modules, engines but not end-users applications, should they be renamed? (perl-lib, or something better) Some sections are hardly used and could be removed, especially "news" (~35 pkg). Also "shells" has only 25 pkg. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
DebianWiki migrated
Hi all,
Wiki engine migrated
The DebianWiki team is pleased to announce that the wiki is now running
moinmoin 1.7, which brings many new features (see [1] and [2]).
The syntax on how to make links and use attachments have changed in
moinmoin 1.6, see:
http://wiki.debian.org/HelpOnMoinWikiSyntax
http://wiki.debian.org/HelpOnEditing
Also, the GUI editor is now disabled, because moinmoin 1.7 use an old
version of fckeditor which would have been a security problem. We are
working to find a solution.
Hosting sponsor
===
The wiki is hosted on a new machine. The hardware and bandwith are
sponsored by Dembach Goo Informatics [3].
Secure https access
===
You can now use https to securely sign into the wiki.
When you publish an URL (in mailing list, bug reports...), we recommend
that you do not post https URL (to avoid "untrusted" SSL certificates
problems)
Misc Hints and Tips
===
* The wiki.debian.org/Teams/${team} is a good place to get new
contributors...
A "News" section is a good idea (with links to "Bits
from $FooBar team" and some interesting threads on the mailing
list, like squeeze road-map)
* If you link to your wiki page from some Debian material (alioth,
documentation, package...), then add the page to the category
"CategoryPermaLink" so we can prevent 404s, also make sure use
use http link (i.e not https).
* Subscribe to the pages that matters to you, so you are notified
of contributions.
Thanks to the DDs that handled the hard work migrating the wiki (pabs,
luca and zobel).
... Stay tuned for more bits from DebianWiki, regarding the theme (CSS)
and License.
Franklin
[1] http://moinmo.in/MoinMoinRelease1.6
[2] http://moinmo.in/MoinMoinRelease1.7
[3] http://www.dg-i.net/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DebianWiki migrated
On Mon, 2009-03-16 at 21:29 +0100, Frank Lin PIAT wrote: > > Wiki engine migrated > I completely forgot to thanks and give credits to Valessio Brito for his DebianWiki logo. http://wiki.debian.org/htdocs/WikiDebianLogo_B.png This is now fixed. Regards, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DebianWiki migrated
On Mon, 2009-03-16 at 23:33 +0100, Bernd Zeimetz wrote: > Frank Lin PIAT wrote: > > Hi all, > > > > Wiki engine migrated > > > > Thanks for the work! > > > Also, the GUI editor is now disabled, because moinmoin 1.7 use an old > > version of fckeditor which would have been a security problem. We are > > working to find a solution. > > If I remember right, the GUI editor messed up several pages, so it was > recommended not to use it (and I always hated it with a passion) Quite a few users choose moinmoin because it have a gui editor. > so the question is if it is really needed to have it enabled again. Finding bugs and fixing bugs... that's the game. Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
