Sections - especially section:kde and section:gnome

[Sune Vuorela]

Hi!

I have been wondering over the last months about Section: kde.
What is the correct usage of this section?

Is it for packages that is related to the desktop itself or is it for
packages that links against kdelibs ?

Should a game using kdelibs go to section:games or section:kde?
should a web browser using kdelibs go to section:web or section:kde?

If section:kde is for anything linking against kdelibs, I think the
seperation is wrong.
If section:kde is for the kde desktop itself, I_think it is useless as a
section, as it is gonig to be mostly empty.

Currently, packages seems to be more or less randomly placed either in
section:kde or in some section for the application type.

I would personally like to move almost all packages out of section:kde.

I wonder if gnome people have it the same way.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510476: ITP: LinuxCallRouter - an ISDN based PBX for Linux

[Joerg Dorchain]

Package: wnpp
Severity: wishlist

Package: lcr LinuxCallRouter - an ISDN based PBX for Linux
Version: 1.3 (20081124)
Upstream Author: Andreas Eversberg 
URL: http://isdn.eversberg.eu/download/lcr-1.3/
Licence: GPL
Description:
  Formerly known as "PBX4Linux", Linux-Call-Router is not only a router,
  it is a real ISDN PBX which interconnects ISDN telephones and ISDN lines.
  It is possible to connect telephones to a Linux box. It is a pure software
  solution except for the ISDN cards and telephones. The great benefit is
  the NT-mode that allows to connect telephones to an ISDN card.  Special
  cards are needed and a little bit of different cabeling. It supports lots
  of features, that only expensive PBXs have. It include a channel driver
  that can link LCR to Asterisk PBX.

Now that the underlying misdn driver has made it into the mainstream
kernel and asterisk has a debian package for some time, this
package fills the gap of combining both into a very scalable PBX.


signature.asc
Description: Digital signature

Re: Override changes standard -> optional

[Petter Reinholdtsen]

[Steve Langasek]
> Hmm, come to think of it, we ought to replace the 'ftp' package in
> standard with something more usable, such as lftp or ncftp...

In Debian Edu, we concluded that more packages than the Debian
Standard packages are needed in all installations, and install these
packages by default for any profile:

  apt-listchanges, bc, bind9-host, cfengine2, consolekit,
  cpufrequtils, dash, debconf-utils, debian-archive-keyring,
  debian-edu-archive-keyring, debian-edu-artwork-usplash,
  debian-edu-config, debian-edu-doc, debian-edu-install, debsecan,
  dmidecode, eject, etherwake, ethtool, finger, fping, gdebi, hdparm,
  hwinfo, iftop, insserv, iotop, iproute, iputils-arping | arping,
  less, libpam-ck-connector, libpam-foreground, libpam-ssh,
  libwww-perl, localization-config, lsscsi, lvm2, man-db, manpages,
  mdetect, memtest86, mii-diag, mlocate, mtools, mtr-tiny | mtr,
  ncftp, nictools-pci, nmap, nscd, nullidentd, openssh-client,
  pciutils, popularity-contest, procinfo, procmail, psmisc, read-edid,
  readahead, reportbug, resolvconf, rsync, rsyslog, scsiadd, strace,
  sudo, sysfsutils, tcpdump, tcptraceroute, traceroute, udev, usplash,
  wget

Some of these will be removed when we drop some leftovers from Etch
(like libpam-foreground replaced by consolekid).  Others are installed
by default on some archs or hardware types automatically by
debian-installer already.

Of these, I would strongly recommend consolekit, dmidecode, ethtool,
finger, fping, gdebi, hdparm, iftop, iotop, less, libpam-ck-connector,
lsscsi, memtest86, mtr-tiny, ncftp, nmap, nullidentd (replacing
pidentd), pciutils, procinfo, psmisc, strace, tcpdump, tcptraceroute,
traceroute and wget to be part of the normal Debian installation, and
suggest making most of them priority Standard.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Michael Goetze]

Petter Reinholdtsen wrote:
> In Debian Edu, we concluded that more packages than the Debian
> Standard packages are needed in all installations, and install these
> packages by default for any profile:

> ... nscd ...

I think that's a bad idea. It can cause some confusion when people make
config changes that don't take effect immediately, and is hard to debug.

Regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Sections - especially section:kde and section:gnome

[Joerg Jaspert]

> What is the correct usage of this section?
> Is it for packages that is related to the desktop itself or is it for
> packages that links against kdelibs ?

> Should a game using kdelibs go to section:games or section:kde?

games.

> should a web browser using kdelibs go to section:web or section:kde?

Is it usable without large parts of KDE installed? web. Does it need
lots of KDE? kde. (Where lots is debatable, but kdelibs, kicker, and
some of the central parts of it would probably be a good guess)

> I would personally like to move almost all packages out of section:kde.
> I wonder if gnome people have it the same way.

For "right after lenny" we plan to add more sections to the archive. Feel
free to look at ftp.debian.org bugs and propose more, in case the one
you would want isn't there - or if you want to have one removed.

-- 
bye, Joerg
Could you please add me to the mirr...@debian.org alias. I'm not receiving
enough spam.
  -- Andrew Pollock


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

dcut

[Nikita V. Youshchenko]

Hi

I've got an interrupted upload to ftp.upload.debian.org, leaving stale 
files in the queue.

I tried to clean up those using
dcut -kyo...@debian.org rm stale_files

but that was silently ignored.

I was then able to remove stale files by setting DEBEMAIL and DEBFULLNAME 
and then running 'dcut rm stale_files'.

But what was wrong in the first try ?


signature.asc
Description: This is a digitally signed message part.

Re: Sections - especially section:kde and section:gnome

[Sune Vuorela]

On 2009-01-02, Joerg Jaspert  wrote:
>
>> What is the correct usage of this section?
>> Is it for packages that is related to the desktop itself or is it for
>> packages that links against kdelibs ?
>
>> Should a game using kdelibs go to section:games or section:kde?
>
> games.
>
>> should a web browser using kdelibs go to section:web or section:kde?
>
> Is it usable without large parts of KDE installed? web. Does it need
> lots of KDE? kde. (Where lots is debatable, but kdelibs, kicker, and
> some of the central parts of it would probably be a good guess)

a web browser requires the same standard components from kde as a game.
(Core libs and such)

>
>> I would personally like to move almost all packages out of section:kde.
>> I wonder if gnome people have it the same way.
>
> For "right after lenny" we plan to add more sections to the archive. Feel
> free to look at ftp.debian.org bugs and propose more, in case the one
> you would want isn't there - or if you want to have one removed.

I guess we actually need to consider what the sections are good for.
Asking in a random irc channel at least didn't reveal any real answers.
So what about killing the concept of sections entirely ?

Currently, I wouldn't mind losing section:kde though.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Sections - especially section:kde and section:gnome

[William Pitcock]

On Fri, 2009-01-02 at 13:43 +, Sune Vuorela wrote:
> I guess we actually need to consider what the sections are good for.
> Asking in a random irc channel at least didn't reveal any real
> answers.
> So what about killing the concept of sections entirely ?

The primary user of section: is packages.debian.org, as far as I can
tell.

I also believe that dselect/aptitude/synaptic use them to organize it's
package browser. But I don't use those tools.

William


signature.asc
Description: This is a digitally signed message part

Re: dcut

[Emilio Pozuelo Monfort]

Nikita V. Youshchenko wrote:
> Hi

Hello,

> I've got an interrupted upload to ftp.upload.debian.org, leaving stale 
> files in the queue.
> 
> I tried to clean up those using
> dcut -kyo...@debian.org rm stale_files
> 
> but that was silently ignored.
> 
> I was then able to remove stale files by setting DEBEMAIL and DEBFULLNAME 
> and then running 'dcut rm stale_files'.
> 
> But what was wrong in the first try ?

the -k option takes the key ID, which should have been C9132DDB in your case.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes: LSB Commands and Utilities

[Frank Lin PIAT]

On Tue, 2008-12-30 at 13:34 +0100, Joerg Jaspert wrote:
> Hi
> 
> after some discussion within the ftpteam we just modified a few override
> entries (15 to be exact). The following packages moved from standard to
> optional:

I have had a look at the "LSB Core" specification version 3.2. The
section "Commands and Utilities" states that:
> [..]An LSB conforming implementation shall provide the commands and
> utilities[..]:
> ar, at, awk, basename, batch, bc, cat, chfn, chgrp, chmod, chown,
> chsh, cksum, cmp, col, comm, cp, cpio, crontab, csplit, cut, date, dd,
> df, diff, dirname, dmesg, du, echo, ed, egrep, env, expand, expr,
> false, fgrep, file, find, fold, fuser, gencat, getconf, gettext, grep,
> groupadd, groupdel, groupmod, groups, gunzip, gzip, head, hostname,
> iconv, id, install, install_initd, ipcrm, ipcs, join, kill, killall,
> liTies, ln, locale, localedef, logger, logname, lp, lpr, ls,
> lsb_release, m4, mailx, make, man, md5sum, mkdir, mkfifo, mknod,
> mktemp, more, mount, msgfmt, mv, newgrp, nice, nl, nohup, od, passwd,
> paste, patch, pathchk, pax, pidof, pr, printf, ps, pwd, remove_initd,
> renice, rm, rmdir, sed, sendmail, sh, shutdown, sleep, sort, split,
> strip, stty, su, sync, tail, tar, tee, test, time, touch, tr, true,
> tsort, tty, umount, uname, unexpand, uniq, useradd, userdel, usermod,
> wc, xargs, zcat

Most of them are already provided by standard/important/required
packages:
at  standard 
bashrequired 
bc  standard 
bsd-mailx   standard 
bsdmainutilsimportant
bsdutilsrequired 
coreutils   required 
cpioimportant
cronimportant
diffrequired 
ed  important
exim4   standard
filestandard 
findutils   required 
mawkrequired
gettext-basestandard 
greprequired 
gziprequired 
hostnamerequired 
libc6   required 
login   required 
m4  standard 
man-db  important
mktemp  required 
mount   required 
passwd  required 
patch   standard 
procps  required 
sed required 
sysvinitrequired
sysvinit-utils  required
timestandard
tar required 
util-linux  required 


But the following packages/commands have lower priority... 

binutilsoptional
 * binaries: ar, strip
 * Depends: No new Dependencies.
 * Size: 2686k/7717k

cups-bsdextra
cups-client optional
 * binaries: lp, lpr
 * Depends: cups-common, libcups2, libcupsimage2, libjpeg62, 
libpng12-0, libtiff4
 * Size: 115+164+166+86+169+1175+37 = 1912k
 * InstalledSize: 393+426+295+168+369+5460+168 = 7279k

gettext optional
 * binaries: msgfmt
 * Depends: libgomp1
 * Size (.deb/installed) => 2672k+14k / 7274k+62k
 => Postpone in Squeeze: move the binary msgfmt to gettext-base?

psmisc  optional
 * binaries: fuser, killall
 * Depends: No new Dependencies.
 * Size (.deb/installed) => 85k/504k

libc6-dev   optional 
 * binaries: gencat
 * Depends: linux-libc-dev
 * Size (.deb/installed) =>3377k+756k/13.3M+3957k

lsb-release extra
 * binary: lsb_release
 * Depends: No new Dependencies.
 * Size (.deb/installed) =>20k/90k

makeoptional 
 * binary: make
 * Depends: No new Dependencies.
 * Size (.deb/installed) =>382k/992k

pax optional
 * binary: pax
 * Depends: No new Dependencies.
 * Size (.deb/installed) => 52k/147k

install_initd
remove_initd
 * Not is Debian so it's another story.


So, none of the important core commands are missing(!)
lsb-release, psmisc and pax could be candidate could be upgraded to
standard (IMHO).

Happy new year,

Franklin

[1]
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/command.html#TBL-CMDS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510493: ITP: s3sync-ruby -- Sync and command tool for managing S3 Amazon buckets

[juanrossi]

Package: wnpp
Severity: wishlist
Owner: juanro...@gmail.com


* Package name: s3sync-ruby
  Version : 1.2.6
  Upstream Author : s3sync.net
* URL : http://s3sync.net/
* License : Other
  Programming Lang: Ruby
  Description : Sync and command tool for managing S3 Amazon buckets

s3sync-ruby is a ruby program that easily transfers directories between a local
directory and an S3 bucket:prefix. It behaves somewhat, but not precisely, like
the rsync program.
s3cmd-ruby is a ruby program that wraps S3 operations into a simple 
command-line tool.
It is inspired by things like rsh3ll, #sh3ll, etc., but shares no code from
them.

-- System Information:
Debian Release: 4.0
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#510476: ITP: LinuxCallRouter - an ISDN based PBX for Linux

[Faidon Liambotis]

Joerg Dorchain wrote:
> Package: lcr LinuxCallRouter - an ISDN based PBX for Linux
> Version: 1.3 (20081124)
> Upstream Author: Andreas Eversberg 
> URL: http://isdn.eversberg.eu/download/lcr-1.3/
> Licence: GPL
> Description:
>   Formerly known as "PBX4Linux", Linux-Call-Router is not only a router,
>   it is a real ISDN PBX which interconnects ISDN telephones and ISDN lines.
>   It is possible to connect telephones to a Linux box. It is a pure software
>   solution except for the ISDN cards and telephones. The great benefit is
>   the NT-mode that allows to connect telephones to an ISDN card.  Special
>   cards are needed and a little bit of different cabeling. It supports lots
>   of features, that only expensive PBXs have. It include a channel driver
>   that can link LCR to Asterisk PBX.
> 
> Now that the underlying misdn driver has made it into the mainstream
> kernel and asterisk has a debian package for some time, this
> package fills the gap of combining both into a very scalable PBX.
You're welcome to join pkg-voip-maintainers and coordinate with us about
this :)

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Sections - especially section:kde and section:gnome

[Joerg Jaspert]

> I guess we actually need to consider what the sections are good for.
> Asking in a random irc channel at least didn't reveal any real answers.
> So what about killing the concept of sections entirely ?

Sure, if at some point a replacement is suitable and *well integrated*
into those Debian tools that currently have sections.

Which means, when we are lucky, that squeeze *could* have the tools,
enabling us for squeeze+1 to get rid of them.

-- 
bye, Joerg
 bignachos: the famous pornview maintainer?
 Christian: *don't* ask why he's typing so slowly
 hey, at least i thoroughly test my packages


pgplgDkbGBIaG.pgp
Description: PGP signature

Re: Override changes standard -> optional

[Petter Reinholdtsen]

[Michael Goetze]
>> ... nscd ...
>
> I think that's a bad idea. It can cause some confusion when people make
> config changes that don't take effect immediately, and is hard to debug.

It reduces the load on the LDAP server when using LDAP for PAM/NSS,
and has proven to be required to avoid overloading the server and
prompt response on the clients.  The new nss-ldapd package help, but
caching LDAP results is needed too.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Russ Allbery]

Petter Reinholdtsen  writes:
> [Michael Goetze]

>>> ... nscd ...

>> I think that's a bad idea. It can cause some confusion when people make
>> config changes that don't take effect immediately, and is hard to debug.

> It reduces the load on the LDAP server when using LDAP for PAM/NSS,
> and has proven to be required to avoid overloading the server and
> prompt response on the clients.  The new nss-ldapd package help, but
> caching LDAP results is needed too.

The vast majority of Debian installations don't use LDAP NSS maps, though.
I know that Debian-Edu does heavily, which makes it quite reasonable for
you to want to install it, but I'm not sure it makes sense for Debian as
a whole.

(Does nscd honor DNS TTLs properly yet?  Last time I looked at it, its DNS
caching was horribly broken, but it's been quite a while.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Henrique de Moraes Holschuh]

On Fri, 02 Jan 2009, Russ Allbery wrote:
> (Does nscd honor DNS TTLs properly yet?  Last time I looked at it, its DNS
> caching was horribly broken, but it's been quite a while.)

It can't, it would be a layering violation.  What one would need is to
selectively apply nscd only to some maps (and *definately* not to the hosts
map).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Russ Allbery]

I think a lot of the ones you listed already are priority: standard or
higher.  debian-archive-keyring, less, man-db, manpages, and wget, for
example.  I stopped checking after spot-checking a few; you may want to
filter your list some more.

Here are some I definitely disagree with that jumped out at me.

Petter Reinholdtsen  writes:

>  cfengine2

I think that's rather hard to justify as priority: standard.  There are a
lot of other configuration management systems in the world (and IMO much
better ones).

>  fping

The difference between ping and fping is not significant enough to install
both of them as standard.  I'm a big fan of fping, but ping will do for
most non-scripted applications and ping does a bunch of stuff that fping
doesn't.

>  libpam-ssh

Er.  With a Popcon vote of 56?

>  nullidentd

Isn't the ident protocol dead yet?

Here are ones that I agree with:

>  apt-listchanges
>  sudo
>  psmisc
>  rsync
>  tcpdump

Those are all things we install routinely on every system that we build
(except tcpdump, which we'll probably start installing soon, and sudo,
which we only don't use because we use ksu, which most sites won't), and I
have a hard time imagining not having them.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510515: ITP: libdatetime-format-excel-perl -- Perl library to convert between DateTime and Excel dates.

[Ivan Kohler]

Package: wnpp
Severity: wishlist
Owner: Ivan Kohler 

* Package name: libdatetime-format-excel-perl
  Version : 0.2901
  Upstream Author : Dave Rolsky 
* URL : http://search.cpan.org/dist/DateTime-Format-Excel/
* License : Perl
  Programming Lang: Perl
  Description : Perl library to convert between DateTime and Excel dates.

 Excel uses a different system for its dates than most Unix programs.
 DateTime::Format::Excel allows you to convert between a few of the Excel raw
 formats and DateTime objects, which can then be further converted via any of
 the other DateTime::Format::* modules, or just with DateTime's methods.

 If you're wanting to handle actual spreadsheet files, you may find
 Spreadsheet::WriteExcel and Spreadsheet::ParseExcel of use.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Russ Allbery]

Russ Allbery  writes:
> Petter Reinholdtsen  writes:

>>  cfengine2

> I think that's rather hard to justify as priority: standard.  There are a
> lot of other configuration management systems in the world (and IMO much
> better ones).

Ah, sorry, I see this isn't in your recommended list.  This is probably
used internally by Debian-Edu; sorry about the noise.

Going through the recommended list in more detail, I agree with all of the
following:

> dmidecode
> pciutils
> psmisc (as mentioned)
> tcpdump (as mentioned)

and as mentioned would add apt-listchanges, rsync, and sudo to that list.
The following are already priority: standard or higher:

> less
> traceroute
> wget

I don't think that we need to install, in standard, all of these hardware
detection programs; it really seems like overkill to me:

> lsscsi
> memtest86
> procinfo

Surely these are things people can install if and when they need them?

I'm honestly mystified as to why any of the following should be in
standard, given how obscure what they do seems to be:

> consolekit
> gdebi
> libpam-ck-connector
> nullidentd (and, for that matter, pidentd)

I've not seen an ident server in years.  I don't use IRC, though, which
seems to be the last bastion of people who think ident is useful.

I think installing tcpdump is sufficient; adding ethtool on top of it
seems like overkill to me.

As mentioned before, I think ping and fping have enough overlap that
having both of them seems pointless.  Similarly, I think we should pick
*one* traceroute program; if the existing traceroute package isn't
sufficient, we should *replace* it in standard with mtr-tiny or with
tcptraceroute, but not add a new package.

I agree with the decision to remove finger, and I'm not sure why you'd
strongly recommend it.

I think the following are borderline:

> hdparm
> iftop
> iotop
> ncftp
> nmap
> strace

They're useful tools, many of which I use, but I'm not sure they're so
useful to warrant installing them on every system by default.  You can
generally install them when you need them, and ncftp is kind of weird and
heavy-weight to be the default ftp client (as useful as it is once you're
used to it).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Sune Vuorela]

On 2009-01-02, Russ Allbery  wrote:
> I'm honestly mystified as to why any of the following should be in
> standard, given how obscure what they do seems to be:
>
>> consolekit
>> libpam-ck-connector

Consolekit will be more and more used, at least for desktop installs in
squeeze, they will probably be impossible to avoid.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Russ Allbery]

Sune Vuorela  writes:
> On 2009-01-02, Russ Allbery  wrote:

>> I'm honestly mystified as to why any of the following should be in
>> standard, given how obscure what they do seems to be:

>>> consolekit
>>> libpam-ck-connector

> Consolekit will be more and more used, at least for desktop installs in
> squeeze, they will probably be impossible to avoid.

I'm not sure what you mean by "desktop installs" and therefore don't
understand what consolekit would do that makes it standard.

If you mean desktop systems such as GNOME or KDE, they're not in standard
and would never be by the definition of standard (standard does not
include X), so if they're what use consolekit, that's not an argument for
making it standard.  However, it may be a good argument for why it's not
obscure.  I did check a current unstable GNOME system and saw no sign of
consolekit, but that may not mean anything.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Sune Vuorela]

On 2009-01-02, Russ Allbery  wrote:
> include X), so if they're what use consolekit, that's not an argument for
> making it standard.  However, it may be a good argument for why it's not
> obscure.  I did check a current unstable GNOME system and saw no sign of

It was mostly the obscure part I wanted to comment on.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Steve Langasek]

On Fri, Jan 02, 2009 at 10:29:26AM -0800, Russ Allbery wrote:
> I'm honestly mystified as to why any of the following should be in
> standard, given how obscure what they do seems to be:

> > consolekit
> > gdebi
> > libpam-ck-connector

Going forward, consolekit is the "standard" way to grant local users access
to hardware devices for the duration of their session.  That doesn't imply
that it should be part of standard, but it's not terribly obscure anymore.

> I think installing tcpdump is sufficient; adding ethtool on top of it
> seems like overkill to me.

ethtool doesn't seem particularly related to tcpdump?

> As mentioned before, I think ping and fping have enough overlap that
> having both of them seems pointless.  Similarly, I think we should pick
> *one* traceroute program; if the existing traceroute package isn't
> sufficient, we should *replace* it in standard with mtr-tiny or with
> tcptraceroute, but not add a new package.

I agree, there's no reason we should have multiple tools providing this same
functionality in standard.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jan 02, 2009 at 10:29:26AM -0800, Russ Allbery wrote:

>> I think installing tcpdump is sufficient; adding ethtool on top of it
>> seems like overkill to me.

> ethtool doesn't seem particularly related to tcpdump?

Oh, sorry, I confused it with a different program.  Hm, ethtool I'd put
into the borderline category -- one argument in its favor is that you may
need it in order to fix your networking so that you can get somewhere to
install more packages.

(This, for me, is the argument for tcpdump.  You may need it installed in
order to figure out why you can't install packages.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Ben Hutchings]

On Fri, 2009-01-02 at 13:02 -0800, Russ Allbery wrote:
> Steve Langasek  writes:
> > On Fri, Jan 02, 2009 at 10:29:26AM -0800, Russ Allbery wrote:
> 
> >> I think installing tcpdump is sufficient; adding ethtool on top of it
> >> seems like overkill to me.
> 
> > ethtool doesn't seem particularly related to tcpdump?
> 
> Oh, sorry, I confused it with a different program.  Hm, ethtool I'd put
> into the borderline category -- one argument in its favor is that you may
> need it in order to fix your networking so that you can get somewhere to
> install more packages.
[...]

ethtool is also part of a standard RHEL or SLE installation.  It is
important for network diagnostics and performance tuning, and
occasionally for working around driver/hardware bugs.  For these reasons
I recently requested that ethtool be made standard.  (For historical
reasons it used to be extra; it has now been upgraded to optional.)

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


signature.asc
Description: This is a digitally signed message part

Re: Override changes standard -> optional

[The Fungi]

On Fri, Jan 02, 2009 at 10:29:26AM -0800, Russ Allbery wrote:
[...]
> I think installing tcpdump is sufficient; adding ethtool on top of
> it seems like overkill to me.
[...]

It seems mii-tool from the net-tools started falling by the wayside
for a while, as gigabit Ethernet had become standard in servers and
yet mii-tool didn't support it. I have ethtool installed on
basically all my Debian servers so I can more easily trouboeshoot
interface link status and speed/duplex autonegotiation. If these
issues have been resolved in more recent versions of mii-tool, then
I would probably switch back to it...
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Petter Reinholdtsen]

[Russ Allbery]
> The vast majority of Debian installations don't use LDAP NSS maps,
> though.  I know that Debian-Edu does heavily, which makes it quite
> reasonable for you to want to install it, but I'm not sure it makes
> sense for Debian as a whole.

Note that I did not propose to install nscd on all Debian systems.
The list of packages I proposed to add for Debian as a whole was this
shorter list:

  consolekit, dmidecode, ethtool, finger, fping, gdebi, hdparm, iftop,
  iotop, less, libpam-ck-connector, lsscsi, memtest86, mtr-tiny,
  ncftp, nmap, nullidentd (replacing pidentd), pciutils, procinfo,
  psmisc, strace, tcpdump, tcptraceroute, traceroute, wget

> (Does nscd honor DNS TTLs properly yet?  Last time I looked at it,
> its DNS caching was horribly broken, but it's been quite a while.)

I would recommend making sure nscd do not cache DNS entries.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Changes to the DM code

[Joerg Jaspert]

Hey,

if you are a DM uploading your packages, please pay extra attention in
the next few days. We just changed the underlying code in our archive
software to be less awkward. While we did test that (using the help from
Eugene V. Lyubimkin (thanks)) there might be cases not covered by our
tests.

This also fixes on of the other bugs the old implementation had - DMs
should now be able to upload to experimental too. Or
proposed-updates. Basically anywhere. :)
For those interested, the *highest* available version in our archive has
to have the DM-Upload-Allowed flag to allow the DM upload to happen, we
no longer blindly assume that unstable is the suite to look in.

(If you want to blame someone, try ftpmaster. If you want to say thanks
for the changes, try Michael Casadevall, he got most of the headache
rewriting the code, and then ftpmaster for merging it.)

-- 
bye, Joerg
 anyone from the MIA team around? tbm?
 sounds nice. how long do you have to be MIA to get into that team? :)
 you need to have a pgp key, I suppose. and no gpg one, and only a bo box
 yes, but it must be expired


pgp1aAWTPJk4e.pgp
Description: PGP signature

Re: Override changes standard -> optional

[Ben Finney]

Petter Reinholdtsen  writes:

> The list of packages I proposed to add for Debian as a whole was this
> shorter list:
> 
>   consolekit, […]

‘consolekit’ currently (as of version 0.2.10-3) ‘Depends: libx11-6’. I
usually regard that dependency as an indicator of a package I don't
want installed on a host that won't normally be interacting with a
user at a console (e.g. server hosts). So I don't think it's suitable
for a minimal installation of Debian.

Is there another package, not depending on X11, that you could
substitute in that list?

-- 
 \  “I can picture in my mind a world without war, a world without |
  `\   hate. And I can picture us attacking that world, because they'd |
_o__)   never expect it.” —Jack Handey |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Sections - especially section:kde and section:gnome

[Josselin Mouette]

Le vendredi 02 janvier 2009 à 14:17 +0100, Joerg Jaspert a écrit :
> Is it usable without large parts of KDE installed? web. Does it need
> lots of KDE? kde. (Where lots is debatable, but kdelibs, kicker, and
> some of the central parts of it would probably be a good guess)

Using such criteria is going to be more and more dubious in GNOME. With
more and more modules only depending on Glib and GTK+, will we
eventually move the core desktop itself outside of this section?

Actually I agree with Sune that we need to entirely kick the concept of
sections.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#510558: ITP: sion -- frontend to manage connections to remote filesystems using GIO/GVFS

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: sion
  Version : 0.1.0
  Upstream Author : Enrico Tröger 
* URL : http://goodies.xfce.org/projects/applications/sion/
* License : GPL-2
  Programming Lang: C
  Description : frontend to manage connections to remote filesystems using 
GIO/GVFS

 Sion is a frontend to easily manage connections to remote filesystems
 using GIO/GVFS. It allows you to quickly connect/mount a remote filesystem
 and manage bookmarks of such.


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Josselin Mouette]

Le vendredi 02 janvier 2009 à 18:05 +0100, Petter Reinholdtsen a écrit :
> [Michael Goetze]
> >> ... nscd ...
> >
> > I think that's a bad idea. It can cause some confusion when people make
> > config changes that don't take effect immediately, and is hard to debug.
> 
> It reduces the load on the LDAP server when using LDAP for PAM/NSS,
> and has proven to be required to avoid overloading the server and
> prompt response on the clients.  The new nss-ldapd package help, but
> caching LDAP results is needed too.

NSCD has many bugs, most of which seen when using it on top of LDAP. You
should not use it unless you know what you’re doing, and I’d certainly
recommend against installing it by default.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Override changes standard -> optional

[Josselin Mouette]

Le vendredi 02 janvier 2009 à 13:02 -0800, Russ Allbery a écrit :
> Oh, sorry, I confused it with a different program.  Hm, ethtool I'd put
> into the borderline category -- one argument in its favor is that you may
> need it in order to fix your networking so that you can get somewhere to
> install more packages.
> 
> (This, for me, is the argument for tcpdump.  You may need it installed in
> order to figure out why you can't install packages.)

ethtool looks much more crucial than tcpdump to me, especially since
mii-tool isn’t able to set gigabit rates.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Override changes standard -> optional

[Ben Hutchings]

On Fri, 2009-01-02 at 19:02 +, The Fungi wrote:
> On Fri, Jan 02, 2009 at 10:29:26AM -0800, Russ Allbery wrote:
> [...]
> > I think installing tcpdump is sufficient; adding ethtool on top of
> > it seems like overkill to me.
> [...]
> 
> It seems mii-tool from the net-tools started falling by the wayside
> for a while, as gigabit Ethernet had become standard in servers and
> yet mii-tool didn't support it.
[...]

mii-tool communicates with the PHY (physical interface) using MDIO
whereas ethtool uses a much higher level API (also called ethtool).
mii-tool ought to be extensible to the gigabit MII (there are only a few
new register fields) but the 10-gigabit MII has a greatly extended MDIO
register set and the Linux ioctl() interface to this has not yet been
standardised.  Furthermore not all interfaces (not even all Ethernet
interfaces) use MDIO.  So I would suggest you stick with ethtool.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

"Semantic" shell? (for lack of better name)

[Bryan Bishop]

Hi all,

I'd like to work on a method to search for packages based off of
recognized input file formats and recognized output file formats of
the contained program(s). Maybe by MIME-type (RFC 2046), such as:

image/gif
image/jpeg
image/png
image/tiff
video/mp4
video/mpeg
application/x-latex

Here's the list of MIME-type assignments:
http://www.iana.org/assignments/media-types/

However, I am by no means permanently attached to MIME. It would also
be interesting to revise the typical --help message with some
standardized markup for formally specifying which parameters would
prefer what type of information. Typically, when I write my quick
scripts, I just do a few print statements and spit out some text for
help messages, and sometimes clean it up a bit, so to replace that
laziness I'd have to write a tool to make that less of a pain, maybe
throw it in next to autoproject or something.

So, this might just mean an extra file in a package, with two lines,
the first one for input recognized, the second one for types of
output, but this of course isn't a good map for what each parameter
will trigger in terms of output, esp. in programs that change output
dependent on what it discovers about the input. Also, this only really
works for single-program packages, otherwise this needs to be done at
some other level, i.e. a file next to each binary? Is that where this
should go??

Personally this seems kind of an obvious thing to do, but it hasn't
happened yet, so I'm posting to ask specifically--

(1) Has this been proposed before? Can anyone give me names, links,
addresses, or what went wrong?

(2) Anything better than MIME for these purposes?

(3) Search terms other than 'semantic shell', anyone?

(4) What should I be asking?

I've basically written up this email on a site as well-
http://heybryan.org/shell.html

Happy new year,

- Bryan
1 512 203 0507


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes standard -> optional

[Michael Goetze]

Russ Allbery wrote:

I think the following are borderline:


hdparm
iftop
iotop
ncftp
nmap
strace


They're useful tools, many of which I use, but I'm not sure they're so
useful to warrant installing them on every system by default.  You can
generally install them when you need them, [...]


While I agree with you regarding the bottom 5 items on this list, hdparm 
might be quite useful (via its init script) to a lot of people who have 
no idea that it even exists. As far as I can see it currently does 
nothing by default, but if that changes, it might be useful to make it 
standard.


Regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Semantic" shell? (for lack of better name)

[Guus Sliepen]

On Fri, Jan 02, 2009 at 08:51:12PM -0600, Bryan Bishop wrote:

> I've basically written up this email on a site as well-
> http://heybryan.org/shell.html

I do not see what this has to do with Debian Development. It also sounds
awfully similar to what doxygen does. However, most manuals generated with
doxygen are absolutely worthless: first and foremost they describe the syntax,
not the semantics. It's up to the programmer to describe the semantics, and most
of them forget.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature