Discussion:
"How to recognise different ETCH wishlists from quite a long way away" (revised)
(too old to reply)
Javier Fernández-Sanguino Peña
2005-07-08 12:33:12 UTC
Permalink
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-devel/2003/08/msg02243.html
or
http://lists.debian.org/debian-devel/2002/05/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: <***@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: <***@shadow.org.uk>
* See Solaris 10 (or Open Solaris) new scheme or
http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

- Paralell (faster) init.d execution
Note: probably will not work without dependency-based stuff
http://www-106.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw04BootFaster
http://initng.thinktux.net/index.php/Main_Page
http://comas.linux-aktivaattori.org/debconf5/general/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/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/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: <***@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-release/2005/06/msg00241.html
Marco d'Itri
2005-07-08 12:40:55 UTC
Permalink
Post by Javier Fernández-Sanguino Peña
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
Wouter Verhelst
2005-07-08 16:45:37 UTC
Permalink
Post by Marco d'Itri
Post by Javier Fernández-Sanguino Peña
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).
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Marco d'Itri
2005-07-08 17:07:20 UTC
Permalink
Post by Wouter Verhelst
Post by Marco d'Itri
Post by Javier Fernández-Sanguino Peña
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).
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 17:40:27 UTC
Permalink
Post by Marco d'Itri
Post by Wouter Verhelst
Post by Marco d'Itri
Post by Javier Fernández-Sanguino Peña
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).
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).
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
Marco d'Itri
2005-07-08 18:52:57 UTC
Permalink
Post by Wouter Verhelst
* 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).
Post by Wouter Verhelst
* 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
Josselin Mouette
2005-07-08 17:52:10 UTC
Permalink
Post by Marco d'Itri
Post by Javier Fernández-Sanguino Peña
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).
But... but... that's a circular dependency !
--
.''`. Josselin Mouette /\./\
: :' : ***@ens-lyon.org
`. `' ***@debian.org
`- Debian GNU/Linux -- The power of freedom
Santiago Vila
2005-07-08 13:49:36 UTC
Permalink
I'm going to disagree with two points here.
Post by Javier Fernández-Sanguino Peña
- _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)
=20
http://master.debian.org/~ajt/oldbugs.html
Well, I consider the idea that old bugs deserve more attention than new
bugs (or non-old bugs) completely flawed.

Bugs do not increase their severity by age. A wishlist bug which is
ten years old is still a wishlist bug. A normal bug which is ten years
old is still a normal bug. An important bug which is ten years old is
still an important bug (well, modulo the fact that the important
severity might not exist ten years ago :-).

While it would be a nice thing not have "old" bugs, it would be even
nicer not to have important bugs, for example, so I think we should
not chase "old" bugs because of them being old.

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).
Post by Javier Fernández-Sanguino Peña
[...]
- 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
IMHO, we should keep dummy packages around for at least two releases,
to support upgrades which skip one release. We can't argue that they
are difficult to maintain, or that they take a lot of space in the
archive. Sure, we can't test upgrades which skip one release as much
as normal upgrades, but if we know for sure that an upgrade will *not*
be smooth when there is a missing dummy package, we do not even have
to test the upgrade to know that it will fail, and there is no point
in gratuitously and knowingly breaking the upgrade.

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 (see Bug#196390 for an example of bug which I think we should
not have released sarge without fixing it).
Olaf van der Spek
2005-07-08 16:22:52 UTC
Permalink
Post by Santiago Vila
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)?
Steve Langasek
2005-07-08 22:39:08 UTC
Permalink
Post by Santiago Vila
Post by Javier Fernández-Sanguino Peña
[...]
- 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
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.
Post by Santiago Vila
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
Adrian von Bidder
2005-07-11 18:54:34 UTC
Permalink
Post by Steve Langasek
Post by Santiago Vila
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.
While it is only sensible to state in bold, big, fat, huge letters that
upgrades over two releases are not supported, breakting these on purpose
does nobody any good when keeping this minor support in doesn't cost more
than 4k on the mirror network.

cheers
-- vbi
--
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion
Brian May
2005-07-09 10:13:57 UTC
Permalink
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 <***@debian.org>
Manoj Srivastava
2005-07-09 13:33:42 UTC
Permalink
Post by Brian May
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.
Post by Brian May
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.
Post by Brian May
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]
Post by Brian May
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.
Post by Brian May
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Petter Reinholdtsen
2005-07-09 20:47:45 UTC
Permalink
[Manoj Srivastava]
Post by Manoj Srivastava
Post by Brian May
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.
$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?
Manoj Srivastava
2005-07-09 21:16:40 UTC
Permalink
Post by Petter Reinholdtsen
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Olaf van der Spek
2005-07-09 21:35:44 UTC
Permalink
Post by Manoj Srivastava
Post by Petter Reinholdtsen
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)?
Wouldn't it be better to have a 'safe' default then a fast one?
Kevin Mark
2005-07-10 08:19:55 UTC
Permalink
Post by Manoj Srivastava
Post by Petter Reinholdtsen
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?
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 05:19:30 UTC
Permalink
On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen
Post by Petter Reinholdtsen
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?
This posting is very incoherent, but I'll attempt a response
anyway.
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bernd Eckenfels
2005-07-11 06:54:49 UTC
Permalink
Post by Manoj Srivastava
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
Brian May
2005-07-10 23:55:23 UTC
Permalink
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 <***@debian.org>
Manoj Srivastava
2005-07-11 01:30:57 UTC
Permalink
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).
Post by Brian May
???
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]
Post by Brian May
???
: 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.
Post by Brian May
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?
Post by Brian May
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.
Post by Brian May
Which means the fact I could not have any definitions of [1] or [2]
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jochen Voss
2005-07-11 09:29:46 UTC
Permalink
Hello Manoj,
Post by Manoj Srivastava
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 09:59:34 UTC
Permalink
Post by Jochen Voss
Hello Manoj,
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!
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jochen Voss
2005-07-11 09:17:56 UTC
Permalink
Post by Manoj Srivastava
Post by Brian May
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]
Post by Brian May
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.
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/
Manoj Srivastava
2005-07-11 09:42:38 UTC
Permalink
Post by Jochen Voss
Post by Manoj Srivastava
Post by Brian May
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]
Post by Brian May
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.
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Eduard Bloch
2005-07-11 17:40:23 UTC
Permalink
#include <hallo.h>
Post by Jochen Voss
Post by Manoj Srivastava
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
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 --
Lars Wirzenius
2005-07-11 18:43:08 UTC
Permalink
Post by Eduard Bloch
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.
That's a lot of manual work and that is, almost by definition, bad.
Create automated checks instead. For example, just to plug my own
current thing, don't accept the upload unless it passes piuparts
checking, that is, can be installed and removed without ill effects.

And, because Steven Kowalik is sitting on my left side right now,
talking loudly to his laptop, run linda on it and see that it doesn't
find any errors. (Add a way to have an override file for the few cases
when linda is wrong and the package is right, or, of course, fix linda.)

But don't make programmers do more manual work than they absolutely have
to. That won't do any good in the long run.
Steve Langasek
2005-07-11 21:39:27 UTC
Permalink
Post by Eduard Bloch
#include <hallo.h>
Post by Jochen Voss
Post by Manoj Srivastava
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
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
Manoj Srivastava
2005-07-09 13:25:11 UTC
Permalink
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Javier Fernández-Sanguino Peña
2005-07-11 07:59:52 UTC
Permalink
Post by Manoj Srivastava
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]
Post by Manoj Srivastava
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-release/2005/06/msg00241.html
Manoj Srivastava
2005-07-11 09:56:15 UTC
Permalink
Post by Javier Fernández-Sanguino Peña
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 ..".
Post by Javier Fernández-Sanguino Peña
Post by Manoj Srivastava
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.
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.
Post by Javier Fernández-Sanguino Peña
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 <***@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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
David Nusinow
2005-07-11 15:50:14 UTC
Permalink
Post by Manoj Srivastava
Post by Javier Fernández-Sanguino Peña
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.
For what it's worth, I've just signed myself and the X Strike Force (me
being the public face of the thing as of late) up for the X.Org transition
item on the EtchTODO page. I also removed two suprious items related to X
that I don't intend to do, and I don't plan on allowing to pass through the
X.Org packages currently. Seeing as I wrote the above blog entry, I can
take a little responsibility for my piece of that TODO list.

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.

For those people out there who want to work on something but aren't sure
what, just sign up for something on that list and get to work! There's some
cool ideas on there, but we need to actually make them happen, since they
won't just materialize on their own. People in NM or looking to get in to
NM, this is a perfect opportunity to do something cool and help shape the
project. Finally, if you're already working on something, like getting the
new KDE or Gnome in to Debian, put it on there with your name by it! Let's
use this page to show people what's actually happening in Debian, so they
don't have to trawl through a zillion bug reports, mailing lists, and irc
channels just to hear what we plan to do.

- David Nusinow
Jon Dowland
2005-07-14 12:09:06 UTC
Permalink
Post by David Nusinow
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
Stig Sandbeck Mathisen
2005-07-14 12:55:48 UTC
Permalink
Post by Jon Dowland
I suggest having __two__ lists: a wishlist and a worklist (with the
latter being the existing TODOlist)
A decent idea, since items can be moved back and forth as needed.
--
Stig Sandbeck Mathisen
Jon Dowland
2005-07-14 15:28:21 UTC
Permalink
Post by Stig Sandbeck Mathisen
Post by Jon Dowland
I suggest having __two__ lists: a wishlist and a worklist (with the
latter being the existing TODOlist)
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
Adrian von Bidder
2005-07-11 18:57:25 UTC
Permalink
Post by Javier Fernández-Sanguino Peña
Post by Manoj Srivastava
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.
Except that it isn't true, exactly. At least in my case - the issue I
suggested is exactly one of the cases that annoys Manoj so much.

cheers
-- vbi
--
"Oh, mi hai uccisa!"
-- Dal film "Quintet"
Christian Perrier
2005-07-09 05:28:47 UTC
Permalink
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).
Manoj Srivastava
2005-07-09 17:42:27 UTC
Permalink
Post by Christian Perrier
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?
Post by Christian Perrier
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.
Post by Christian Perrier
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 <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Max Vozeler
2005-07-11 16:58:15 UTC
Permalink
Post by Javier Fernández-Sanguino Peña
- 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.
Post by Javier Fernández-Sanguino Peña
[ 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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Frank Lichtenheld
2005-07-11 18:06:29 UTC
Permalink
Post by Max Vozeler
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 <***@debian.org>
www: http://www.djpig.de/
Max Vozeler
2005-07-12 12:38:44 UTC
Permalink
Post by Frank Lichtenheld
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
Jonas Meurer
2005-07-11 19:44:07 UTC
Permalink
Post by Max Vozeler
Post by Javier Fernández-Sanguino Peña
- 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.
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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Max Vozeler
2005-07-12 13:18:07 UTC
Permalink
Post by Jonas Meurer
Post by Max Vozeler
Post by Javier Fernández-Sanguino Peña
- 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.
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
Jonas Meurer
2005-07-12 16:09:01 UTC
Permalink
Post by Max Vozeler
Post by Jonas Meurer
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?
no, not officially. but Michael Gebetsroither <***@gmx.at>
provides cryptsetup-luks debs at his own repositority here:
deb http://einsteinmg.dyndns.org/debian unstable/
Post by Max Vozeler
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*
Post by Max Vozeler
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 ***@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
Adrian von Bidder
2005-07-11 18:50:26 UTC
Permalink
TODO: Should this be in  
http://wiki.debian.net/index.cgi?ReleaseProposals ?
It's <http://wiki.debian.net/?EtchTODOList> - which contains a short
disclaimer on its difference vs. ReleaseProposals.
Mere wishlists by random bystanders are no help to anyone.
I think I can agree with your sentiment that they don't get things done.
OTOH I feel it worthwhile to collect these ideas on what people are missing
in Debian - it does help people to find other people with interests in
similar areas, and I'd argue that the list does no harm. If you don't feel
it is helpful to you, just ignore it.

regards
-- vbi
--
Bescheidenheit ist so beliebt, weil sie einem die Arroganz erleichtert.
Continue reading on narkive:
Loading...