|
Home > Archive > Debian Developers > July 2005 > "How to recognise different ETCH wishlists from quite a long way away" (revi
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"How to recognise different ETCH wishlists from quite a long way away" (revi
|
|
| Javier Fernández-Sanguino Peña 2005-07-08, 7:49 am |
| Well, since the thread I started has calmed down and since there's a lot of
people at HEL [1] with (probably) a lot of spare time in their hands that
would be better spent hacking than in the sauna here's my (revised)
wishlist for Etch.
I've added additional items pointed out in the thread (including who
"claimed" them) as well as some new stuff. This wishlist is not necessarily
(sp?) aligned with the Etch Release Goals [2] it probably has more "pets"
but, if you have spare time to work on any of these items I'm sure that the
whole Debian community will appreciate it!
TODO: Add information from previous (older) discussions at
http://lists.debian.org/debian-deve...8/msg02243.html
or
http://lists.debian.org/debian-deve...5/msg02497.html
TODO: Should this be in http://wiki.debian.net/index.cgi?ReleaseProposals?
[ Overall improvements ]
- _No_ bugs in base packages (well, at least no old bugs). Base system
should be upgraded to latest upstream (forward patches!) this includes
PAM, modutils...
* Base packages should be co-maintained and maintainers should be
open to help (not always the case currently)
- Review and fix or remove very old bugs: http://master.debian.org/~ajt/oldbugs.html
- Updates to base packages: many base packages are in a bug-fix only cycle,
we are mostly doing a very good job keeping up-to-date with upstream
but some need to be updated and might introduce major changes.
Example:
Package Current Upstream Bug
pam 0.76-22 0.79 #284954
cron 3.0pl1-87 4.1 -
dhcp 2.0pl5-19.1 3.0.2 [None, dhcp3 package available]
[jfs] Will work on cron (co-maintain) and already provided new pam packages to
the Debian maintainer.
- [rfrancoise] Libpcap0.9 transition
- [doko] Toolchain update to gcc/g++ 4.0
- Review patches developed by other distros to base packages. Many of the
bug fixes / improvements there apply to us too.
Note: The fact that Fedora's CVS is now open helps in this quite a lot
Other that should be reviewed include OpenBSD's CVS and Mandrake source RPMs.
[jfs] Doing so for pam and cron
- Implement some package reorganizations that have been postponed over
several releases; example:
#100332: tetex-bin: please move xdvi to its own package
- [rleigh] Transition to UTF-8 locales
Message-ID: <873bru53o3.fsf@hardknott.home.whinlatter.ukfsn.org>
* The locale codeset could be UTF-8 for some new installs by default
(depending on locale?)
* Existing installations should be unaffected, but it might be nice to
offer to generate the equivalent UTF-8 locales for the locales in use.
Also see #99933 and #99324?
- [joss] Drop libpng2/libpng10-0/libpng3 packages
- [adconrad] Drop libmysqlclient10/libmysqlclient12 packages
- [vorlon] Consistent LFS support
- [zobel] IPv6 readiness: make sure all packages support IPv6 completely
- [ballombe] Get rid of circular dependancies
- [jfs] Get rid of useless dummy packages (pending review of the find-dummies
script result)
[ Installation improvements ]
- Firewall configuration during installation (ala Fedora Core or SuSE):
module for d-i. Currently, the system is exposed just during installation
on some systems (empty root password?)
* [joeyh] D-i needs to protect the system
* [joeyh] Firewall task in d-i?
- Reduced standard installation (no gcc or development tools!, see
#301138 or #301273)
* [joeyh] Will happen with a new d-i 'standard' task (selected by default)
- More "tasks" (grouped packages) for installation: automatic detection
of user needs and automatic task selection?
* [joeyh] Will be added to tasksel, help needed0
- Encrypted root/swap on the d-i installation.
- Booting from the d-i and not need a reboot ?
[ Security improvements ]
- Proper signature detection (apt-secure, currently on experimental)
- ExecShield or PaX in stock kernel - buffer overflow protection
- SELinux support - Mandatory Access Control (RSBAC?)
- Possibility to recompile the distro with SPP (apt-build?). New
i386-spp architecture?
- Proper source code audit by maintainers to detect stupid security
bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
too often. Automatic source code audit ala lintian.debian.org?
- MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis
see #303961)
- [zobel] Packages should document what should be added to
hosts.{allow,deny} if using tcp-wrappers
- (policy) Only support a subset of our current packages, meaning to support
the full archive when there's so many things is insane, does not scale
and is against us. Better do what *BSD do explicitly (ports are supported
in a "best effort basis") or what others do implicitly (distros with less
packages provide less security support). Maybe introduce a priority between
standard - optional to include non-standard packages that are security
supported ('common'?) or move most packages from optional to extra and
support only priority <= optional.
Note: a common request is "Do not start daemon by default". This is
already possible: see policy-rc.d However not all packages support it currently. ]
[ Admin improvements ]
- hardware changes detection: system detects after a reboot when
a new SVGA card, new Ethernet card, etc. has been installed and prompts
for new confguration.
Note: Of course, should be possible to disable by sysadmin.
- inetd begone! -> xinetd (better mechanism to control DoS, privilege
separation, etc.)
Note: Or no inetd at all, or openbsd's inetd.
Note2: There's preliminary implementation for the switch but the management tools
(i.e. netbase's update-inetd IIRC) need to be handle xinetd too (see
#8927, #10059 and #25816).
- Checksecurity -> live up to its name and merge changes from other distros
and BSDs
- Security / Update managements of multiple servers from a single point.
There's no single tool to do check the security status of many servers
at once (like done in RedHat's support) network. Use OVAL agents?
See #253097
- Better OS backup management (use of /var/backups/)
See #12203
- Better tools for system monitoring and review, see #132505
[ jfs ] Preparing a 'cron-standard' package to package all the cron scripts
currently in cron. This would mean taking over the tasks currently
handled by cron and managing them in a separate package, will
also reuse other tools developed for other distributions (like FreeBSD's
periodic).
- Package upgrade rollback?
Note: See http://www.linuxjournal.com/article/7034, would mean supporting
downgrades as well. Might not be possible near-term
- Using dpkg as an audit tool to detect changes in the system, not as
a security mechanism but to detect broken stuff (includes #155799 and #34194)
- [zobel] Packages should use logrotate instead of savelog so that admins
can configure it at will
[ Runlevel / Init.d improvements ]
- Possibility to startup the system in "control" mode: select which init
scripts will run, this provides a way to work-around hardware issues after
d-i has installed the base system (sample: #301112)
* [jesus.climent] Even select which modules from /etc/modules are loaded
Note: This is an improvement over 'linux single' or 'linux emergency' since
it allows debugging of init scripts in a more user-friendly way.
- Add 'Status' in init.d scripts (#291148)
- [liw] Switch to dependency-based init.d handling
Note:
* if this is not done probably parallel init.d handling will break
think: X manager started before authentication daemons are when using
LDAP?
* currently we overuse the 'default' 20 level with not proper dependencies
of who should be first.
See Message-ID: <m3y89bwi63.fsf@shadow.org.uk>
* See Solaris 10 (or Open Solaris) new scheme or
http://www.atnf.csiro.au/people/rgo...x/boot-scripts/
- Paralell (faster) init.d execution
Note: probably will not work without dependency-based stuff
http://www-106.ibm.com/developerwor...nxw04BootFaster
http://initng.thinktux.net/index.php/Main_Page
http://comas.linux-aktivaattori.org...al/proposals/55
http://people.debian.org/~hmh/debconf2/initscripts/
- [filippo] Some functions for consistent output when starting/stopping init.d
scripts (verbose as default and/or simple as [ok]/[notok] (ok, this is
really needed only on a desktop, in production you are supposed to read
and debug error messages yourself))
Note: This is defined in the LSB
Also see #169600 and #208010
- Separate runlevels: 2 for multi no net, 3 for multi, 4=3, 5 = 3+{x,g,k}dm
* some people don't like this (takes away customisation possibility?)
* not required by LSB but most others do this :
http://refspecs.freestandards.org/L.../runlevels.html
* Many users from other distributions expect this too
http://www.slackware.com/config/init.php
* some DDs and users point out that this would allow a way to debug issues
when X freezes the system (bad hw, note that this is not "fixed" by gdm
detecting it since once frozen there is no recovery). Also, init 1 is not
an option for remote managed systems (nor is 'linux single' or 'linux
emergency'
[ End user improvements ]
- Proper User/Sysadmin documentation guides
* Note: Fedora has recently release part of the RH guides with a
(possible) DFSG free license, lots of content can be reused from
guides of other distributions (including Ubuntu)
- Better in-system help/documentation search (better use of doc-base,
dwww sucks, dhelp needs improvement)
Provide a "Debian documentation center" with search functions to
detect information in READMEs, html files, manuals ?
- Provide more translated documentation in CD-ROMs
* Note: Need to handle this outside of byhand files
- Better package search mechanism (tags?) allowing free text search
in package management interfaces: "I want a program that does X"
(i.e. dpkg-iasearch)
For detailed description see Message-ID: <20050607174051.GC7112@dat.etsit.upm.es>
- [avbidder] Better support for displaying as many languages as possible without
having to search for corresponding font packages. From what I can see
gnome is slightly better than KDE in replacing missing characters, but I
think both still can't display the http://www.wikipedia.org titlepage with
all characters. I think a font metapackage that depends on a set of fonts
that cover most of unicode would be a great thing.
- [jesus.climent] Ability to select if the system is multiuser targetted and
allow users to log while a previous user is logged in by default. Single
user systems could have it disabled.
- [liw] Work on getting suspend-to-disk (swsusp or whatever) working properly
with screensavers.
- i18n of packages, both support of this in the package management frontends
(from apt-get to synaptic) and proper infraestructure for package description
translation (see DDTP)
[ Other system improvements ]
- Allow users to exclude a full directory (/usr/share/doc, /usr/share/man)
from being installed, this can be done through apt.conf currently (rm
on postinstall) but it would be best to have dpkg handle this somehow.
[ Infraestructure improvements ]
- Provide a MD5sum /permission listing for all files in the archive for system forensic
analysis (See #268658).
* Note: People should not rely on external stuff like NIST's CRL or
http://www.knowngoods.org/ or http://setuid.org/
- Provide a documentation page search utility on debian.org, allowing searching on
a per distribution basis of manpages, info, and package documentation
(http://manpages.debian.net/cgi-bin/search_man.cgi not useful and people
should not rely on stuff like http://www.fifi.org/cgi-bin/man2html)
[ Release improvements ]
- Prune packages from release based on popularity, packages which are not
used by anyone should not go in!
- Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
Note: Almost done by ftp-masters, some pending and needs to be reviewed
to remove woody->sarge which are not applicable to ->etch
Feel free to add any other wishlists (or discuss any one of them). I'll try
to track the subsequent thread and keep the list current somewhere...
Regards
Javier
[1] http://www.debconf.org/debconf5/
[2] http://lists.debian.org/debian-rele...6/msg00241.html
| |
| Marco d'Itri 2005-07-08, 7:49 am |
| On Jul 08, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
> Feel free to add any other wishlists (or discuss any one of them). I'll try
> to track the subsequent thread and keep the list current somewhere...
Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
--
ciao,
Marco
| |
| Olaf van der Spek 2005-07-08, 5:54 pm |
| On 7/8/05, Santiago Vila <sanvila@unex.es> wrote:
> Sure, old bugs may be the symptom that the maintainer is MIA, that the
> upstream maintainer is MIA, and similar things that we should of
> course track as well, but it does not mean that an old bug is "worse"
> in any way than a new bug (eveything else being the same).
What's the proper way to deal with maintainers that kinda 'ignore'
bugs (in whatever way)?
| |
| Wouter Verhelst 2005-07-08, 5:54 pm |
| On Fri, Jul 08, 2005 at 02:40:55PM +0200, Marco d'Itri wrote:
> On Jul 08, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
>
> Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
No you don't.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-07-08, 5:54 pm |
| On Jul 08, Wouter Verhelst <wouter@debian.org> wrote:
> No you don't.
If you really feel strongly about this then you will have to provide
some arguments too, considering the higly positive side effects that
such a change would have (and that at some point in the future udev will
be mandatory anyway).
--
ciao,
Marco
| |
| Wouter Verhelst 2005-07-08, 5:54 pm |
| On Fri, Jul 08, 2005 at 07:07:20PM +0200, Marco d'Itri wrote:
> On Jul 08, Wouter Verhelst <wouter@debian.org> wrote:
>
> If you really feel strongly about this then you will have to provide
> some arguments too, considering the higly positive side effects that
> such a change would have (and that at some point in the future udev will
> be mandatory anyway).
This was said about DevFS too, when it was introduced.
My gripe with udev is that, last I tried, it
* was far too fragile, with races all over the place which make some
things work correctly some of the time and not at all on the next
reboot,
* requires way too much configuration for a system which only exists to
access my hardware, with documentation in /usr/share/doc/udev which
blatantly states that some things *will not* work out of the box, and
*will* require you to manually configure stuff.
In contrast, static /dev stuff Just Works. It might not have the same
features as udev does; but what it does, it does well, with next to *no*
configuration and *no* races.
Of course, if the situation has been improved since, so much the better;
but 'last I tried' was only two months ago, IIRC.
In that light, I urge you not to make udev usage mandatory for hotplug
in the near future. If the problems with udev are fixed (in that the
races are gone and stuff will just work out of the box), then perhaps.
Not just yet.
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-07-08, 5:54 pm |
| On Jul 08, Wouter Verhelst <wouter@debian.org> wrote:
> * was far too fragile, with races all over the place which make some
> things work correctly some of the time and not at all on the next
> reboot,
The solution to these problems is to use RUN rules (what once were dev.d
scripts).
> * requires way too much configuration for a system which only exists to
> access my hardware, with documentation in /usr/share/doc/udev which
> blatantly states that some things *will not* work out of the box, and
> *will* require you to manually configure stuff.
With the recent serio and ieee1394 sysfs kernel fixes all the common
situations should be handled correctly with the exception of
non-autostarted RAID volumes.
(Other distributions ship udev by default, so it can't be so bad...)
--
ciao,
Marco
| |
| Steve Langasek 2005-07-08, 5:54 pm |
| On Fri, Jul 08, 2005 at 03:49:36PM +0200, Santiago Vila wrote:
> On Fri, 8 Jul 2005, Javier Fernández-Sanguino Peña wrote:
[vbcol=seagreen]
> IMHO, we should keep dummy packages around for at least two releases,
> to support upgrades which skip one release.
In practice, upgrades that skip a release are not supported. There was no
way at all that upgrades from potato->sarge could have been supported, and
it's not a goal of the release team to support direct upgrades from
woody->etch.
So keeping these dummy packages around is simply needless overhead, IMHO,
both in the archive and in the Packages files.
> Instead of a crusade against dummy packages (some of which are not old
> enough so that removing them does any good), I would like to see a
> crusade *for* dummy packages, so that a package which changes name
> without a dummy package is considered a RC bug and we are forced to
> fix it
While I don't think the release should block on having dummy packages for
all such upgrades, I certainly agree quite strongly that maintainers should
be doing whatever possible to support automated upgrade paths in these
cases.
--
Steve Langasek
postmodern programmer
| |
| Brian May 2005-07-09, 7:47 am |
| >>>>> "Santiago" == Santiago Vila <sanvila@unex.es> writes:
Santiago> Well, I consider the idea that old bugs deserve more
Santiago> attention than new bugs (or non-old bugs) completely
Santiago> flawed.
I wonder how many old bugs are either fixed (but not marked as fixed)
or irrelevant (if another solution was used).
I suspect that there would be a high percentage of such bugs.
Santiago> Bugs do not increase their severity by age. A wishlist
Santiago> bug which is ten years old is still a wishlist bug. A
Santiago> normal bug which is ten years old is still a normal
Santiago> bug. An important bug which is ten years old is still an
Santiago> important bug (well, modulo the fact that the important
Santiago> severity might not exist ten years ago :-).
True. However, I think it is easy to forget about old bugs and
concentrate only on the new.
After all who wants to spend considerable time gong over old bugs,
attempting to work out if they are still relevant, for situations that
you are never likely to encounter yourself, when you could be fixing
"real" problems (as in problems that effect you)?
Maybe the process of reviewing old bugs could be improved. I find the
current process very clumsy:
1. Review bugs in web browser.
2. Identify questionably bug that you haven't already looked at before
today.
3. Inspect bug report, in new window, install package, install source,
inspect as required. Open up new browser windows to find
information as required.
4. Make changes as required to source code.
5. Enter one/more emails to either forward bug upstream, change tags,
or close the bug.
6. Go back to step 3.
7. Fix up the all the silly typos made in every BTS email sent so far
and retransmit. (note: this is after the BTS has decided to
respond).
8. upload the changes to source code.
9. realize that I forgot to sign the upload due to a bug in by
pbuilder wrapper script, create a *.commands file to send to the
upload queue to delete the old upload and reupload again.
It would be good if this process could be simplified and/or made more
error resistant. For example:
1. Client program that lists all bugs and has the ability to mark
bugs. Ability to sort bugs in order of when you last looked it one.
This information should be stored on maintainers computer, not the
BTS.
Even better, if you could attach a short summary/note to each one
for your use, e.g. "need to talk to XYZ about this", "this user is
an idiot", "I think this has been solved but I need to check X
first", or "as of 1/1/2005 this bug is still waiting on X" that
you don't want to appear in the BTS. This should be immediately
visibly without having to select the bug and scrolling to the
bottom.
This way you can get a clear picture of which bugs require
immediate attention, and which bugs you consider "too-hard" or
"too-time consuming" right now, or are waiting on other outside
events.
2. Client program with provision for sending updates to the BTS, but
caching the updates until they finally appear in the BTS. Either
that or fast response time from the BTS.
3. Environment/scripts to enable better testing, updating, and
recompiling packages even if it is based on a non-preferred
distribution, e.g. if you use stable, but the bug report is against
unstable or vice versa.
pbuilder is good and building packages against other distributions,
it is not so good (at the moment anyway) for testing arbitrary
packages in arbitrary distributions (except via pre-written
scripts), because it was designed for building not interactive
testing. There is the "pbuilder login" operation, but it doesn't
give you access to your newly created package.
4. Make dupload obsolete, and replace with dput. Make dput the default
in debrelease. I think dput would have prevented me uploading my
unsigned package.
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-09, 5:50 pm |
| Hi,
This is a huge list, with probably 0 chances of getting
accomplished. How about this: remove every single item from the
list, and only add items when there are people who sign up to be
responsible for the work involved in actually seeing that item come
to fruition?
Mere wishlists by random bystanders are no help to anyone.
manoj
--
A gift of flower will soon be made to you.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-09, 5:50 pm |
| On Sat, 09 Jul 2005 20:13:57 +1000, Brian May <bam@debian.org> said:
> 1. Review bugs in web browser.
> 2. Identify questionably bug that you haven't already looked at
> before today.
Hint: have a local notebook that you mark bugs you look at.
> 3. Inspect bug report, in new window, install package, install
> source, inspect as required. Open up new browser windows to find
> information as required.
There is a download bug reports as mailbox feature.
> 4. Make changes as required to source code.
> 5. Enter one/more emails to either forward bug upstream, change
> tags, or close the bug.
> 6. Go back to step 3.
> 7. Fix up the all the silly typos made in every BTS email sent so
> far and retransmit. (note: this is after the BTS has decided to
> respond).
!!!!! [1]
> 8. upload the changes to source code.
> 9. realize that I forgot to sign the upload due to a bug in by
> pbuilder wrapper script, create a *.commands file to send to the
> upload queue to delete the old upload and reupload again.
!!!!! [2]
Are we sure we want someone who is routinely this incompetent
to help with bug triage? Seems to me we would be bette off without
such substandard help; anyone this incompetent is probably creating
more problems than they are solving.
> 4. Make dupload obsolete, and replace with dput. Make dput the
> default in debrelease. I think dput would have prevented me
> uploading my unsigned package.
~/.dupload.conf:
$preupload{'changes'} = 'gpg --verify %1';
$preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify "$j.dsc"';
$preupload{'deb'} = 'lintian -v -i %1';
Just this point (not knowing ones tools) makes this message
highly suspect.
manoj
--
Only the hypocrite is really rotten to the core. Hannah Arendt
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christian Perrier 2005-07-09, 5:50 pm |
| Dunno which section of your list this should pertain but "Enforce the
use of po-debconf for debconf templates" is in my mind.
This probably needs a few s/SHOULD/MUST in the policy so that we can
file RC bugs on packages which still use the "old style" debconf l10n
system.
There are few of these and, IIRC, none of them are really critical
packages. Some work was done a few months ago, including NMUs, but the
release priorities have stopped it.
I also think think about enforcing the use of debconf for packages
during config step so that NO package prompts users outside debconf
and interrupts installs/upgrades (wvdial comes to my mind).
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-09, 5:50 pm |
| On Sat, 9 Jul 2005 07:28:47 +0200, Christian Perrier <bubulle@debian.org> said:
> Dunno which section of your list this should pertain but "Enforce
> the use of po-debconf for debconf templates" is in my mind.
> This probably needs a few s/SHOULD/MUST in the policy so that we can
> file RC bugs on packages which still use the "old style" debconf
> l10n system.
Why do we need to beat peope on the head with policy before
they do this? Could we have a list of people who are resisting this
change?
> There are few of these and, IIRC, none of them are really critical
> packages. Some work was done a few months ago, including NMUs, but
> the release priorities have stopped it.
Do you have a (perhaps partial) list f packages still using
the old mechanism? An idea of the magnitude of the impact of this
policy change would be helpful in deciding whether or not to change
policy.
> I also think think about enforcing the use of debconf for packages
> during config step so that NO package prompts users outside debconf
> and interrupts installs/upgrades (wvdial comes to my mind).
It is not possible in all cases to ask all the questions
before a package is unpacked.
manoj
--
"Mr. Spock succumbs to a powerful mating urge and nearly kills Captain
Kirk." TV Guide, describing the Star Trek episode _Amok_Time_
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petter Reinholdtsen 2005-07-09, 5:50 pm |
| [Manoj Srivastava]
>
> ~/.dupload.conf:
> $preupload{'changes'} = 'gpg --verify %1';
> $preupload{'sourcepackage'} = 'j=$(echo %1 | tr " " "_"); gpg --verify "$j.dsc"';
> $preupload{'deb'} = 'lintian -v -i %1';
>
>
> Just this point (not knowing ones tools) makes this message
> highly suspect.
If these are good settings for dupload, why is it not included in the
package as the default configuration for dupload?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-09, 5:50 pm |
| On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <pere@hungry.com> said:
> If these are good settings for dupload, why is it not included in
> the package as the default configuration for dupload?
Good by whose criteria? Yours? Mine? Joe random Developer's?
What is more important -- speed, not seeing garbage on the screen
when uploading, or ensuring one always signs stuff? What if I use
pbuilder and it always signs stuff for me, so the check is just a
waste of time? What if I wanna upload even when linda crashes (as it
does periodically for me)?
Why are people so darned allergic to looking up the
documentation and configuring packages to suit their needs? Why must
one always be spoon fed pap from the maintainer, straight out of the
box, so one does not ever have to think an iota for one self?
What if there is no One True Way To Configure Everything?
The settings I provided suited the needs of the parent
poster -- but may or may not suit the needs of everyone else (the
linda afficianados would not like the settings, nor would people who
always ensure their packages are signed by other means).
manoj
--
The bureaucracy is expanding to meet the needs of an expanding
bureaucracy.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-07-09, 5:50 pm |
| On 7/9/05, Manoj Srivastava va, manoj <srivasta@debian.org> wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <pere@hungry.com> =
said:
>=20
>=20
> Good by whose criteria? Yours? Mine? Joe random Developer's?
> What is more important -- speed, not seeing garbage on the screen
> when uploading, or ensuring one always signs stuff? What if I use
> pbuilder and it always signs stuff for me, so the check is just a
> waste of time? What if I wanna upload even when linda crashes (as it
> does periodically for me)?
Wouldn't it be better to have a 'safe' default then a fast one?
| |
| Brian May 2005-07-10, 8:48 pm |
| >>>>> "Manoj" == Manoj Srivastava <srivasta@debian.org (va, manoj)> writes:
Manoj> !!!!! [1]
???
Manoj> !!!!! [2]
???
Manoj> Are we sure we want someone who is routinely this
Manoj> incompetent to help with bug triage? Seems to me we would
Manoj> be bette off without such substandard help; anyone this
Manoj> incompetent is probably creating more problems than they
Manoj> are solving.
Are you implying that if I cannot write and maintain a pbuilder
wrapper script that produces perfect results every time, regardless of
regular interruptions, that I am incompetent?
You must be perfect!
Which means the fact I could not have any definitions of [1] or [2] in
your message must be my fault.
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-10, 8:48 pm |
| On Mon, 11 Jul 2005 09:55:23 +1000, Brian May <bam@debian.org> said:
Manoj> !!!!! [1]
: 7. Fix up the all the silly typos made in every BTS email sent so
: far and retransmit. (note: this is after the BTS has decided to
: respond).
[vbcol=seagreen]
> ???
The context, which is where your answer lies, is exactly what
you elided. I guess that stands to reason. You routinely and
consistently are unable to handle sending email?
Manoj> !!!!! [2]
> ???
: 9. realize that I forgot to sign the upload due to a bug in by
: pbuilder wrapper script, create a *.commands file to send to the
: upload queue to delete the old upload and reupload again.
So, you can't read documentation to figure out how to make
your uploader check that you have forgotten to sign things -- which
also implies that your test/build/upload process leaves a lot to be
desired, if this happens very often.
Manoj> Are we sure we want someone who is routinely this incompetent
Manoj> to help with bug triage? Seems to me we would be bette off
Manoj> without such substandard help; anyone this incompetent is
Manoj> probably creating more problems than they are solving.
> Are you implying that if I cannot write and maintain a pbuilder
> wrapper script that produces perfect results every time, regardless
> of regular interruptions, that I am incompetent?
Yes. This would be a bare modicum of competence,
really. Building packages correctly and consistently is not rocket
science. If you find it so, are you sure Gentoo is not more to your
liking?
> You must be perfect!
Jesus Christ. I hope to hell you are kidding. Is sending email
correctly, or crafting a build process so you do not forget to sign a
sign of perfection? Is this wat the quality of the membership has
deteriorated to?
Maybe /. is right after all. Perhaps Debian has grown too big
to be a quality distribution, and we should all head over to Fedora
Core 4.
> Which means the fact I could not have any definitions of [1] or [2]
> in your message must be my fault. -- Brian May <bam@debian.org>
Yeah. I should have realized the level of audience I was
trying to talk to. I'll try to speak in words of fewer syllables the
next time around.
manoj
--
Are you making all this up as you go along?
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2005-07-11, 2:49 am |
| On Sat, Jul 09, 2005 at 04:16:40PM -0500, Manoj Srivastava wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <pere@hungry.com> said:
>
>
> Good by whose criteria? Yours? Mine? Joe random Developer's?
> What is more important -- speed, not seeing garbage on the screen
> when uploading, or ensuring one always signs stuff? What if I use
> pbuilder and it always signs stuff for me, so the check is just a
> waste of time? What if I wanna upload even when linda crashes (as it
> does periodically for me)?
>
>
> Why are people so darned allergic to looking up the
> documentation and configuring packages to suit their needs? Why must
> one always be spoon fed pap from the maintainer, straight out of the
> box, so one does not ever have to think an iota for one self?
Hi Manoj,
Read docs? Programmers are lazy, by design ;-) And if some programmer
streamlines his/her debian programming tool workflow, would it not be
advantageous if this was know? While is may or may not be THE default,
could it be put into /examples or noted in some dev-docs (or wiki.d.n)?
Anyway to reduce errors like un-signed uploads is good, no?
any way, happy hacking!
Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
`$' $'
$ $ _
,d$$$g$ ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P' `$ ,$P' `Y$ $$' `$ $ "' `$ $$' `$
$$ $ $$ggggg$ $ $ $ ,$P"" $ $ $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $
`Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
| |
| Manoj Srivastava 2005-07-11, 2:49 am |
| On Sun, 10 Jul 2005 04:19:55 -0400, Kevin Mark <kmark+debian-devel@pipeline.com> said:
> On Sat, Jul 09, 2005 at 04:16:40PM -0500, Manoj Srivastava wrote:
This posting is very incoherent, but I'll attempt a response
anyway.
[vbcol=seagreen]
> Hi Manoj, Read docs? Programmers are lazy, by design ;-)
If this compromises their effectiveness, then they deserve
every consequence of their laziness. A programmer being lazy does not
mean sloppy, unprofessional, incompetence. I think you do not have a
concept of what that statement was meant to convey in the first
place -- laziness means that programmers automate away common tasks
Indeed, the original poster was the antoithesis of the
effective lazy programmer, for such a lazy programmer would never
ever manually check that the packages were signed -- the lazy
programmer would have used the mechanism I provided, or written their
own coede to do so were it not possible already.
See, the lazy programmer shall spend hours coding away in an
one time effort not to have to manually do a repetitice task over and
over again -- something the OP failed to do.
> And if some programmer streamlines his/her debian programming tool
> workflow, would it not be advantageous if this was know?
How would your incompetent programmer ever know? The
documentation already includes the config details, which you
evidently don't think people nbeed to read. If they don't read, how
do you intend to convey these best practices to them? Sit on they
chest and yell it into their ears as you pound their heads with a
hammer?
> While is may or may not be THE default, could it be put into
> /examples or noted in some dev-docs (or wiki.d.n)?
I see. You have no clue what is being talked about, and you
just want to jump in to hear your own voice. What makes you think
this is not documented? Ever looked at man dupload.conf ?
> Anyway to reduce errors like un-signed uploads is good, no?
You are prime example of why even documenting it, as it has
been done, is not much help at all.
> any way, happy hacking! Kev
You realize your sig in 9 lines long, and has zero information
content? It causes me usually to skip over your messages, since
anyone rude enough to so blatantly ignore nettiquette rarely anything
important to contribute.
Cut down your sig, and I would urge you to exercise brevity in
your messages, unless you have something of substance to say.
manoj
--
Seek simplicity -- and distrust it. Alfred North Whitehead
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bernd Eckenfels 2005-07-11, 2:49 am |
| In article <87eka57wd9.fsf@glaurung.internal.golden-gryphon.com> you wrote:
> If this compromises their effectiveness, then they deserve
> every consequence of their laziness. A programmer being lazy does not
> mean sloppy, unprofessional, incompetence. I think you do not have a
> concept of what that statement was meant to convey in the first
> place -- laziness means that programmers automate away common tasks
however expecting a programmer to read docs does not mean it is ok to ship
outdated and confusing (example) config files. I had to track down the
correct upload queses multiple times (before dupload was fixed). This is
just awaste of time if it does not work with sane defaults.
bernd
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Javier Fernández-Sanguino Peña 2005-07-11, 2:49 am |
| On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote:
> This is a huge list, with probably 0 chances of getting
> accomplished. How about this: remove every single item from the list,
> and only add items when there are people who sign up to be responsible
> for the work involved in actually seeing that item come to fruition?
Errr.. the wishlists with names within brackets are those that have been
taken over by somebody, the ones that don't are up for grabs. This list is
meant as a stimuli for those that do not know what to do with their spare
time (yes, there's a number of DDs in that situation, believe me).
Providing a list of things that need to be worked on, even if not Release
Critical, is a good thing IMHO. It is actually something we have been
lacking for previous releases in which the Release Goals were either
undefined or too vague. I find this list complementary with the pet release
goals set for etch by the release team [1]
> Mere wishlists by random bystanders are no help to anyone.
Thanks, but I'm not a random bystander. Even if I were, I don't see how a
compiled TODO for the distribution hinders development or rather, as seen
in the previous thread, encourages discussion between developers.
I don't know if the majority of developers thinks, like you do, that these
list is not useful at all. But I can bet you a beer or two that many of the
casual bystanders attending at Debconf5 were not even aware of the
relevance of some of the items in the TODO.
In any case, thanks for your constructive criticism. Ahem.
Javier
[1] http://lists.debian.org/debian-rele...6/msg00241.html
| |
| Jochen Voss 2005-07-11, 7:48 am |
| On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
>
> !!!!! [1]
>
>
>
> !!!!! [2]
>
> Are we sure we want someone who is routinely this incompetent
> to help with bug triage? Seems to me we would be bette off without
> such substandard help; anyone this incompetent is probably creating
> more problems than they are solving.
Great idea! We can even get mor out of this, if we install some
kind of challenge response system: every time you upload a package
it mails you a set of three technical questions, and the upload is
only permitted if all three answers are correct ;-) The same goes
for the mail interface of the BTS of course.
Jochen
--
http://seehuhn.de/
| |
| Jochen Voss 2005-07-11, 7:48 am |
| Hello Manoj,
On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
> Yeah. I should have realized the level of audience I was
> trying to talk to. I'll try to speak in words of fewer syllables the
> next time around.
You are actively damaging the project with remarks like this.
Agression and unwillingness to play in a team are not helpful
for us. Please stop this!
Jochen
--
http://seehuhn.de/
| |
| Manoj Srivastava 2005-07-11, 7:48 am |
| On Mon, 11 Jul 2005 10:17:56 +0100, Jochen Voss <voss@seehuhn.de> said:
> On Sat, Jul 09, 2005 at 08:33:42AM -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
> Great idea! We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package
> it mails you a set of three technical questions, and the upload is
> only permitted if all three answers are correct ;-) The same goes
> for the mail interface of the BTS of course.
Wonderful binary world you live in. If something can't be made
dead simple, it is the same as making it as difficult as possible,
eh?
Though the idea does have merit. The distribution is groaning
under the sheer size, and often substandard quality of packages; a
measure like this may kill two birds with one stone.
manoj
--
Any sufficiently advanced technology is indistinguishable from a
rigged demo. Andy Finkel, computer guy
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-11, 7:48 am |
| On Mon, 11 Jul 2005 10:29:46 +0100, Jochen Voss <voss@seehuhn.de> said:
> Hello Manoj,
> On Sun, Jul 10, 2005 at 08:30:57PM -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
> You are actively damaging the project with remarks like this.
> Agression and unwillingness to play in a team are not helpful for
> us. Please stop this!
And I think you are doing far worse by not giving short shrift
to unworthy ideas and lack of critical analysis of views presented,
but hey. Who is listening to anyone else any more?
manoj
--
Anything worth doing is worth overdoing.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-07-11, 7:48 am |
| On Mon, 11 Jul 2005 09:59:52 +0200, Javier Fernández-Sanguino Peña <jfs@computer.org> said:
> Providing a list of things that need to be worked on, even if not
> Release Critical, is a good thing IMHO.
Umm. I think that such a list has already grown too large to
be of value; I can come up with a few hundred items along the lines
of "would be nice if ..".
[vbcol=seagreen]
> Thanks, but I'm not a random bystander. Even if I were, I don't see
> how a compiled TODO for the distribution hinders development or
> rather, as seen in the previous thread, encourages discussion
> between developers.
Read http://www.livejournal.com/users/gravityboy/15401.html
In essence, this is akin to what Andrew Suffield calls "Voting
for more money". A reasonable list of reasonable, achievabel goals
for Etch is of real value. However, that requires thought, judgement,
and triaging out marginal and unrealistic ideas out of the list; and
that appears not to have been done.
> In any case, thanks for your constructive criticism. Ahem.
Well, I have said my piece, Feel free to ignore it.
manoj
--
Never call a man a fool. Borrow from him.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Max Vozeler 2005-07-11, 5:54 pm |
| On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña wrote:
> - Encrypted root/swap on the d-i installation.
I'm planning to work on this- probably during the next few weeks. I hope
to also get together with Wesley Terpstra and talk about how we can make
the framework usable for both loop-AES and dm-crypt based setups.
> [ Security improvements ]
>
> - Proper source code audit by maintainers to detect stupid security
> bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
> too often. Automatic source code audit ala lintian.debian.org?
I'd be happy to help with this effort.
A first step could be to make the lintian.d.o scripts run on a lintian.d
style directory of scripts, if that sounds reasonable to the people who
run that service (Josip Rodin?). That would make it pretty easy to build
lists of privileged files, plug in source code scanners, greps for /tmp/
and everything else we can come up with.
cheers,
Max
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eduard Bloch 2005-07-11, 5:54 pm |
| #include <hallo.h>
* Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:
>
> Great idea! We can even get mor out of this, if we install some
> kind of challenge response system: every time you upload a package
To be honest, I had a similar idea before: every upload has to be
approved by at least one additional Debian developer. This would
decrease the probability for really broken uploads (because of stupid
mistakes or beeing on drugs or whatever).
The work itself can be automated well, I imagine an IRC channel
#debian-uploads-looking-for-approval.
Regards,
Eduard.
--
Emperor Turhan: How will this end?
Kosh Naranek: In fire.
-- Quotes from Babylon 5 --
| |
| Frank Lichtenheld 2005-07-11, 5:54 pm |
| On Mon, Jul 11, 2005 at 06:58:15PM +0200, Max Vozeler wrote:
> A first step could be to make the lintian.d.o scripts run on a lintian.d
> style directory of scripts, if that sounds reasonable to the people who
> run that service (Josip Rodin?). That would make it pretty easy to build
> lists of privileged files, plug in source code scanners, greps for /tmp/
> and everything else we can come up with.
lintian.d.o is currently maintained by jeroen and me (kind of, it's
currently somewhat broken and I'm not yet able to find out exactly why,
but that's another story). But that code is really lintian specific.
Nevertheless, we're indeed currently working on such a framework as
you mention. On our list of tests to run are currently install tests
(with liw's piuparts), rebuild tests (with pbuilder I think) and
lintian (perhaps linda, too?). Adding new tests should be not a
great problem once we have the infrastructure up.
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian von Bidder 2005-07-11, 5:54 pm |
| | |
| Adrian von Bidder 2005-07-11, 5:54 pm |
| | |
| Adrian von Bidder 2005-07-11, 5:54 pm |
| | |
| Jonas Meurer 2005-07-11, 5:54 pm |
| On 11/07/2005 Max Vozeler wrote:
> On Fri, Jul 08, 2005 at 02:33:12PM +0200, Javier Fernández-Sanguino Peña wrote:
>
> I'm planning to work on this- probably during the next few weeks. I hope
> to also get together with Wesley Terpstra and talk about how we can make
> the framework usable for both loop-AES and dm-crypt based setups.
please consider to support luks too. the current cryptsetup package
supports only dm-crypt from christophe saout. luks from clemens
fruhwirth has many advantages over plain dm-crypt, and i guess that it's
quite more common for encrypted disks.
bye
jonas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-11, 5:54 pm |
| On Mon, Jul 11, 2005 at 07:40:23PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> * Jochen Voss [Mon, Jul 11 2005, 10:17:56AM]:
[vbcol=seagreen]
[vbcol=seagreen]
> To be honest, I had a similar idea before: every upload has to be
> approved by at least one additional Debian developer. This would
> decrease the probability for really broken uploads (because of stupid
> mistakes or beeing on drugs or whatever).
> The work itself can be automated well, I imagine an IRC channel
> #debian-uploads-looking-for-approval.
Why is this a better option than revoking the upload rights of developers
make sloppy uploads? I don't expect that *requiring* a second set of
eyeballs on uploads will be any more effective than our NM advocate process
currently is.
--
Steve Langasek
postmodern programmer
| |
| Max Vozeler 2005-07-12, 7:56 am |
| On Mon, Jul 11, 2005 at 08:06:29PM +0200, Frank Lichtenheld wrote:
> Nevertheless, we're indeed currently working on such a framework as
> you mention. On our list of tests to run are currently install tests
> (with liw's piuparts), rebuild tests (with pbuilder I think) and
> lintian (perhaps linda, too?). Adding new tests should be not a
> great problem once we have the infrastructure up.
Sweet!
Let me know if you could use help with this. I did a small POC patch
against the scripts to see whether the switch to lintian.d directory
would be feasible, but then didn't finish it for submission.
I have a small script ready that checks packages for setuid/setgid
files. There are some other things that would IMHO be interesting to
check from a security perspective - we can probably get some good
information from this once the infrastructure in in place.
cheers,
Max
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Max Vozeler 2005-07-12, 5:57 pm |
| On Mon, Jul 11, 2005 at 09:44:07PM +0200, Jonas Meurer wrote:
> On 11/07/2005 Max Vozeler wrote:
>
> please consider to support luks too. the current cryptsetup package
> supports only dm-crypt from christophe saout. luks from clemens
> fruhwirth has many advantages over plain dm-crypt, and i guess that it's
> quite more common for encrypted disks.
Is there already support for LUKS in Debian?
I'm very open for this and will keep it in mind, but I have to plead
ignorance about the practical side of using the luks implementations.
(I've only read Fruhwirth Clemens' LUKS paper)
The framework should allow to use LUKS in principle, but input from
people who use it would be required for the actual implementation. If
you are interested, or know of someone who is, please let me know.
cheers,
Max
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jonas Meurer 2005-07-12, 5:57 pm |
| On 12/07/2005 Max Vozeler wrote:
> On Mon, Jul 11, 2005 at 09:44:07PM +0200, Jonas Meurer wrote:
>
> Is there already support for LUKS in Debian?
no, not officially. but Michael Gebetsroither <michael.geb@gmx.at>
provides cryptsetup-luks debs at his own repositority here:
deb http://einsteinmg.dyndns.org/debian unstable/
> I'm very open for this and will keep it in mind, but I have to plead
> ignorance about the practical side of using the luks implementations.
> (I've only read Fruhwirth Clemens' LUKS paper)
unfortunately it's the same for me. i still use cryptsetup from wesley
as i'm too lazy to upgrade my encrypted partitions to luks.
but i have this on my todo list since many months *g*
> The framework should allow to use LUKS in principle, but input from
> people who use it would be required for the actual implementation. If
> you are interested, or know of someone who is, please let me know.
i think the best person to contact is Michael Gebetsroither. you can
reach him at michael.geb@gmx.at. i had some conversation about his
packages with him, and it seems to me that he has quite a good
understanding of luks.
bye
jonas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jon Dowland 2005-07-14, 7:48 am |
| X-Original-Sender: Jon Dowland <jon@dowland.name>
Xref: number1.nntp.dca.giganews.com linux.debian.devel:174076
On Mon, Jul 11, 2005 at 11:50:14AM -0400, David Nusinow wrote:
> What I'd like to see is no more new items added to that list without
> someone signing up and taking responsibility for them. What I really want
> to see more than anything with that list is for each and every item to have
> at least one person signed up, taking responsibility for it. That way, it
> becomes a real TODO list, rather than just a stupid wishlist.
I think the TODO list is an incredibly useful tool and I agree that it
shouldn't be clogged up by wishlist items (i.e. items someone thinks
are worthy enough to add, but nobody is up for working on them yet).
However I do think wishlist items serve a purpose too: They demonstrate
a desire from users for a feature that could be picked up on and
converted into a TODO list item by an interested party.
I suggest having __two__ lists: a wishlist and a worklist (with the
latter being the existing TODOlist)
--
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jon Dowland 2005-07-14, 6:01 pm |
| On Thu, Jul 14, 2005 at 02:55:48PM +0200, Stig Sandbeck Mathisen wrote:
> Jon Dowland <lists@alcopop.org> writes:
>
>
> A decent idea, since items can be moved back and forth as needed.
I've suggested as such at <http://wiki.debian.net/?EtchTODOList> and put
a stub page at <http://wiki.debian.net/?EtchWishList>.
--
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|