Nabble - Debian Devel

Re: For those who care about pam-ssh: RFC

2008-12-05T00:26:36Z

On Thu, 04 Dec 2008, Jens Peter Secher wrote:

> 2008/12/4 Vincent Zweije <vzweije@...>:
> > It probably would be fine if there were a (documented) ~/.ssh/id.d/
> > directory containing keys to be used (and nothing else).
> >
>
> That is a very good idea. But the id.d directory should probably
> contain soft links to the actual keys to not interfere with the
> standard location. Are the other packages which does something
> similar?

It should probably also be called something that describes its purpose
accurately. like login-keys.d or pam-key.d or something like that.
id.d is just too generic.
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Work-needing packages report for Dec 5, 2008

2008-12-04T23:27:11Z

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 482 (new: 3)
Total number of packages offered up for adoption: 114 (new: 0)
Total number of packages requested help for: 46 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.

------------------------------------------------------------------------

The following packages have been orphaned:

libaudio-flac-decoder-perl (#507386), orphaned 4 days ago
Description: Perl module providing an object-oriented FLAC decoder
Installations reported by Popcon: 85

libdata-compare-perl (#507388), orphaned 4 days ago
Description: perl module to compare perl data structures recursively
Reverse Depends: libtest-simpleunit-perl
Installations reported by Popcon: 139

libscalar-properties-perl (#507389), orphaned 4 days ago
Description: perl module to add run-time properties on scalar
variables
Installations reported by Popcon: 48

479 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.

------------------------------------------------------------------------

No new packages have been given up for adoption, but a total of 114 packages
are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.

------------------------------------------------------------------------

For the following packages help is requested:

apache2 (#470795), requested 266 days ago
Description: Co-maintainer wanted
Reverse Depends: achims-guestbook ampache apache2 apache2-dbg
apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork
apache2-mpm-worker apache2-prefork-dev apache2-suexec (151 more
omitted)
Installations reported by Popcon: 40520

ara (#450876), requested 389 days ago
Description: utility for searching the Debian package database
Installations reported by Popcon: 124

athcool (#278442), requested 1500 days ago
Description: Enable powersaving mode for Athlon/Duron processors
Installations reported by Popcon: 231

bash-completion (#472468), requested 255 days ago
Description: programmable completion for the bash shell
Installations reported by Popcon: 19259

cvs (#354176), requested 1015 days ago
Description: Concurrent Versions System
Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
omitted)
Installations reported by Popcon: 22224

dctrl-tools (#448284), requested 404 days ago
Description: Command-line tools to process Debian package
information
Reverse Depends: aptfs debian-goodies dlocate feta
haskell-devscripts hg-buildpackage ia32-archive ia32-libs-tools
mlmmj sbuild (1 more omitted)
Installations reported by Popcon: 9400

dpkg (#282283), requested 1475 days ago
Description: dselect: a user tool to manage Debian packages
Reverse Depends: alien alsa-source apt-build apt-cross apt-src
backuppc build-essential bzr-builddeb cacao-oj6-dbg cacao-oj6-jdk
(118 more omitted)
Installations reported by Popcon: 79592

drscheme (#402589), requested 724 days ago
Description: PLT scheme programming environment
Reverse Depends: drscheme minlog proofgeneral-minlog
Installations reported by Popcon: 345

elvis (#432298), requested 514 days ago
Description: powerful clone of the vi/ex text editor (with X11
support)
Reverse Depends: elvis elvis-console elvis-tools
Installations reported by Popcon: 374

fglrx-driver (#454993), requested 362 days ago (non-free)
Description: non-free AMD/ATI r5xx, r6xx display driver
Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
Installations reported by Popcon: 2163

flightgear (#487388), requested 166 days ago
Description: Flight Gear Flight Simulator
Installations reported by Popcon: 967

gentoo (#422498), requested 578 days ago
Description: a fully GUI-configurable, two-pane X file manager
Installations reported by Popcon: 256

gnat-4.3 (#475374), requested 238 days ago
Description: help needed to execute test cases
Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
gnat gnat-4.3 gnat-gps libadasockets-dev libahven13 (45 more
omitted)
Installations reported by Popcon: 605

gnat-gps (#496905), requested 98 days ago
Description: co-maintainer needed
Installations reported by Popcon: 123

grub (#248397), requested 1669 days ago
Description: GRand Unified Bootloader
Reverse Depends: brdesktop-artwork-grub dfsbuild grub-choose-default
grub-doc replicator startupmanager
Installations reported by Popcon: 72943

hotkey-setup (#483107), requested 192 days ago
Description: auto-configures laptop hotkeys
Installations reported by Popcon: 35878

imagemagick (#452314), requested 379 days ago
Description: Image manipulation programs
Reverse Depends: advi-examples afterstep album ale ascd asymptote
bins cimg-dev docbook2odf drgeo (83 more omitted)
Installations reported by Popcon: 24888

ispell-et (#391105), requested 792 days ago
Description: Estonian dictionary for Aspell/Ispell/MySpell
Installations reported by Popcon: 114

jove (#470185), requested 270 days ago
Description: Jonathan's Own Version of Emacs - a compact, powerful
editor
Reverse Depends: xjove
Installations reported by Popcon: 327

kvm (#479951), requested 211 days ago
Description: Full virtualization on x86 hardware
Reverse Depends: qemubuilder
Installations reported by Popcon: 1367

loop-aes-utils (#385614), requested 826 days ago
Description: Tools for mounting and manipulating filesystems
Reverse Depends: partman-crypto-loop
Installations reported by Popcon: 701

mantis (#471094), requested 264 days ago
Description: web-based bug tracking system
Installations reported by Popcon: 76

mediawiki-extensions (#484545), requested 183 days ago
Description: set of extensions for MediaWiki
Reverse Depends: mediawiki-semediawiki
Installations reported by Popcon: 384

mol (#436450), requested 485 days ago
Description: The Mac-on-Linux emulator
Reverse Depends: mol-drivers-linux mol-drivers-macos
mol-drivers-macosx mol-modules-source
Installations reported by Popcon: 62

mwavem (#313369), requested 1270 days ago (non-free)
Description: Mwave/ACP modem support software
Installations reported by Popcon: 4

nas (#354174), requested 1015 days ago
Description: The Network Audio System
Reverse Depends: acm acm4 alsaplayer-nas amor apollon atlantik
audiooss bibletime camstream celestia-kde (236 more omitted)
Installations reported by Popcon: 51180

nn (#470187), requested 270 days ago
Description: Heavy-duty USENET news reader (curses-based client)
Installations reported by Popcon: 113

openoffice.org (#419523), requested 598 days ago
Description: OpenOffice.org Office suite
Reverse Depends: brdesktop-common brdesktop-gnome broffice.org
cli-uno-bridge docvert-openoffice.org libuno-cli-cppuhelper1.0-cil
libuno-cli-types1.1-cil libuno-cli-ure1.0-cil mozilla-openoffice.org
openoffice.org (90 more omitted)
Installations reported by Popcon: 44923

openscenegraph (#392266), requested 786 days ago
Description: 3d scenegraph
Reverse Depends: libopenscenegraph-dev libopenscenegraph7
libopenthreads-dev libosgal1 openscenegraph osgcal
Installations reported by Popcon: 169

openssl (#332498), requested 1155 days ago
Description: Secure Socket Layer (SSL) binary and related
cryptographic tools
Reverse Depends: 3270-common afbackup afbackup-client aircrack-ng
alpine anon-proxy aolserver4-nsimap aolserver4-nsopenssl
apache2-prefork-dev apache2-threaded-dev (585 more omitted)
Installations reported by Popcon: 78882

resolvconf (#477723), requested 224 days ago
Description: name server information handler
Reverse Depends: debian-edu-config
Installations reported by Popcon: 7373

rt2400 (#411791), requested 653 days ago
Description: RT2400 wireless network drivers
Installations reported by Popcon: 146

rt2570 (#411790), requested 653 days ago
Description: RT2570 wireless network drivers
Installations reported by Popcon: 220

rus-ispell (#391104), requested 792 days ago
Description: Russian dictionary for Aspell/Ispell/MySpell
Installations reported by Popcon: 1692

sepolgen (#483641), requested 189 days ago
Description: A Python module used in SELinux policy generation
Reverse Depends: policycoreutils
Installations reported by Popcon: 17621

sgml-data (#358521), requested 988 days ago
Description: common SGML and XML data
Reverse Depends: debiandoc-sgml debiandoc2dbxml docbook
docbook-simple docbook-xml epiphany-extensions linuxdoc-tools psgml
stardict-common w3c-dtd-xhtml (3 more omitted)
Installations reported by Popcon: 47617

smlnj (#428273), requested 543 days ago
Description: Standard ML of New Jersey interactive compiler
Reverse Depends: libckit-smlnj libcml-smlnj libcmlutil-smlnj
libexene-smlnj libmlnlffi-smlnj libmlrisctools-smlnj
libpgraphutil-smlnj libsmlnj-smlnj ml-burg ml-lex (5 more omitted)
Installations reported by Popcon: 91

spamassassin (#469124), requested 276 days ago
Description: Perl-based spam filter using text analysis
Reverse Depends: claws-mail-spamassassin dtc-common fuzzyocr
mailscanner sa-exim sa-learn-cyrus spamass-milter spampd
Installations reported by Popcon: 12593

sql-ledger (#472709), requested 254 days ago
Description: A web based double-entry accounting program
Installations reported by Popcon: 102

stlport4.6 (#263052), requested 1585 days ago
Description: STLport C++ class library
Reverse Depends: cli-uno-bridge libstlport4.6-dev
mozilla-openoffice.org openoffice.org-base openoffice.org-base-core
openoffice.org-calc openoffice.org-core openoffice.org-dev
openoffice.org-draw openoffice.org-evolution (14 more omitted)
Installations reported by Popcon: 12604

svn-buildpackage (#377467), requested 879 days ago
Description: helper programs to maintain Debian packages with
Subversion
Reverse Depends: svn-autoreleasedeb
Installations reported by Popcon: 1305

torrus (#433223), requested 508 days ago
Description: Universal front-end for Round-Robin Databases
Reverse Depends: torrus-apache torrus-apache2
Installations reported by Popcon: 25

unicorn (#345547), requested 1068 days ago (non-free)
Description: comaintainer with x86 hardware searched.
Installations reported by Popcon: 61

update-inetd (#472470), requested 255 days ago
Description: inetd.conf updater
Reverse Depends: amanda-common bootp cfingerd cups-bsd cvs ebhttpd
ebnetd ebnetd-common efingerd fam (35 more omitted)
Installations reported by Popcon: 78356

wine (#479659), requested 213 days ago
Description: Windows API implementation
Reverse Depends: libwine-alsa libwine-capi libwine-cms libwine-dbg
libwine-dev libwine-esd libwine-gl libwine-gphoto2 libwine-jack
libwine-ldap (10 more omitted)
Installations reported by Popcon: 12194

wxwidgets2.8 (#463807), requested 305 days ago
Description: help for wxwidgets2.8 is appreciated
Reverse Depends: amaya amule amule-daemon amule-utils
amule-utils-gui bittornado-gui crystalspace drpython esteidutil
extrema (30 more omitted)
Installations reported by Popcon: 7263

See http://www.debian.org/devel/wnpp/help_requested for more information.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T19:19:23Z

Paul Wise wrote:

> The best solution would just be to drop most -dbg packages, drop
> maintainer-uploaded binary packages (using the buildd built packages
> instead), install the dh_strip from debug.d.n on all the buildds and
> get people to use -dbgsym packages from debug.d.n.
>

a) That doesn't solve the dependencies problem.

b) There are lots of packages missing at debug.d.n, and they only keep one
package version. It isn't a drop-in replacement.

c) What's the point on using a separate server when we have mirrors?

d) We don't need debug symbols for every package out there.

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T18:39:12Z

The best solution would just be to drop most -dbg packages, drop
maintainer-uploaded binary packages (using the buildd built packages
instead), install the dh_strip from debug.d.n on all the buildds and
get people to use -dbgsym packages from debug.d.n.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T17:28:52Z

Tzafrir Cohen wrote:

> On Wed, Dec 03, 2008 at 08:48:20PM -0600, Raphael Geissert wrote:
[...]
>>
>> What about encouraging those impatient folks (please don't be just exclusive
>> to DDs) to track down (at times from mentors.d.n) the source package and
>> review it themselves. Any finding should be notified to the maintainer and
>> CCed to ftpmasters so that they can REJECT the package if deserved, helping
>> out instead of just pestering.
>
> How do you track that down?
[...]

Check the ITP? mentors.d.n? contact the maintainer? contact ftp-master?

That's exactly why I said "track down".

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T17:26:24Z

Faidon Liambotis wrote:

> Quality assurance of existing packages is a job for the QA team.

And since everybody makes part of the QA team what you are really saying
is: "Quality assurance of existing packages is a job for me".

ftp-masters are doing a great, often thankless, job. Instead of just saying what
they should or should not do why don't you volunteer and actually do something
about it? (e.g. the QA check part).

Cheers,
Raphael Geisser

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T14:21:20Z

Sune Vuorela <nospam@...> writes:

> How would OR'ed depends work?
>
> let us look at a example:
>
> package: kdepim-dbg
> depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
> version: 4.1.3-1
>
> now, I install korganizer 4.1.3-1 and kdepim-dbg.
> later, 4.1.3-2 gets uploadde and I install kaddressbook.
> korganizer still fulfills the kdepim-dbg version.
> thus, the user is not anywhere better satisfied than before.
>
> The only thing that would work would be if dpkg and apt supported
> Conflicts: korganizer (!= $binary:Version), but that is as far as I can
> read in policy not valid, so I also don't expect the tools to support
> it.

Your case is somewhat unusual in that you're providing debugging symbols
for a bunch of packages that are otherwise fairly unrelated and can be
installed with a mix of version numbers. Most of the time, this is not
the case. In your case, this is only marginally useful; it does ensure
that the user has at least one relevant package installed, but no more
than that.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T13:25:42Z

On 2008-12-04, Raphael Geissert <atomo64+debian@...> wrote:
> Using ORed depends, I forgot to say.

How would OR'ed depends work?

let us look at a example:

package: kdepim-dbg
depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
version: 4.1.3-1

now, I install korganizer 4.1.3-1 and kdepim-dbg.
later, 4.1.3-2 gets uploadde and I install kaddressbook.
korganizer still fulfills the kdepim-dbg version.
thus, the user is not anywhere better satisfied than before.

The only thing that would work would be if dpkg and apt supported
Conflicts: korganizer (!= $binary:Version), but that is as far as I can
read in policy not valid, so I also don't expect the tools to support
it.

/Sune

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Promoting free PDF readers (was Re: Popular packages in Ubuntu that is missing in Debian/main)

2008-12-04T13:20:35Z

Hi there!

On Mon, 01 Dec 2008 11:12:55 +0100, Johannes Wiedersich wrote:

> Gunnar Wolf wrote:
>> But anyway, and knowing this is not an Ubuntu list... Does anybody
>> know why on Earth is Acroread popular? Why isn't a PDF regularly
>> handled in a saner way with Evince (or kde-based lookalike) in some
>> distributions?
>
> Zillions of websites promote acroread via links and thumbnails. I've yet
> failed to find a site with a pdf and that 'download envince|kpdf|okular
> for free' button. Don't forget that many people use an inferior OS just
> out of convenience/marketing/whatever.

FYI, the FSFE has started such initiative:

http://wiki.fsfe.org/Free-PDF-Readers-Campaign

The discussion started in July 2008 on the FSFE discussion mailing list,
but unfortunately the archive is available to subscribers only:

https://lists.fsfe.org/mailman/listinfo/discussion

Recently, a dedicated mailing list was setup:

http://lists.fsfe.org/mailman/listinfo/pdfreaders

Thx, bye,
Gismo / Luca

attachment0 (322 bytes) Download Attachment

Re: NEW processing

2008-12-04T13:19:07Z

Steve Langasek <vorlon@...> writes:
> On Wed, Dec 03, 2008 at 05:03:49PM -0800, Russ Allbery wrote:

>> There should be no minor-severity bugs that result in lintian errors.
>> If there are, that's a bug in Lintian. Please report it. The lowest
>> threshold that produces an E tag is severity: important, likelihood:
>> possible.

> I know this is the current lintian policy on E vs. W, but that this
> wasn't the case historically. Is this the case for lintian 1.24? I
> believe that's the version in use on ftp-master currently. (It also
> appears to be the version that will be shipping with lenny?)

It's been the rough goal for a while, although we've become much clearer
about it recently. I think 1.24 should generally be okay, although of
course bugs have been fixed since then.

> And even under the new classification, "possibly important" bugs are
> still a far cry from things that should be treated as reasons for
> rejects, IMHO.

Sure, which is why ftp-master is only going to use a specific list of
tags. Joerg came to us and asked for the facility for exactly that
reason....

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T13:17:21Z

Sune Vuorela wrote:

> On 2008-12-04, Raphael Geissert <atomo64+debian@...> wrote:
>> Will try to work on a dh-like command (or maybe a patch against dh_strip,
>> depends on what Joey prefers) that will basically scan
>> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
>> matching the subgrouped expression, to automagically generate the Depends
>> field (say ${dbg:Depends}).

Using ORed depends, I forgot to say.

>>
>> Once that's done it would be just a matter of adjusting a couple of lines in
>> debian/control and you are done with dealing with -dbg packages.
>
> No. it actually wouldn't work.
>
> In kde, for example kdepim, contains applications like
> - korganizer
> - kaddressbook
> - kmail
> - kpilot
>
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.
>
> That is not desired.
> Bloating the archive with seperated -dbg packages is ttbomk not desired
> as well.

Of course.

>
> The current approach is currently the least bad, and lintian should not
> complain.

I don't agree, -dbg packages all by themselves are completely useless, they MUST
depend on something that will actually make them meaningful. Otherwise they
should not be built/shipped.

>
> /Sune

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T13:12:48Z

Sune Vuorela <nospam@...> writes:

> No. it actually wouldn't work.
>
> In kde, for example kdepim, contains applications like
> - korganizer
> - kaddressbook
> - kmail
> - kpilot
>
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.

That's why the recommendation (which Lintian currently doesn't talk about;
will fix that) is that the debug package depend on the all of the
corresponding packages as alternatives. (korganizer | kaddressbook
| kmail ...) That way, you still get the checking that the version of the
debug package matches the version of the package for which it has debug
symbols, without the problem you cite. This is what I've done for other
packages and it seems to work reasonably well.

(Lintian may still be confused due to the lack of similarity between the
package name and the debug package name, but we may be able to fix that.)

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T13:12:31Z

Hi Charles,

Charles Plessy wrote:

> Le Wed, Dec 03, 2008 at 08:40:12PM -0600, Raphael Geissert a écrit :
>>
>> I of course do not want to say that reviewing packages in -mentors is always
>> useless, but here again we need to deal with yet another social problem which
>> is the lack of willingness by some people to work on their package to get it
>> in shape.
>
> Hi Raphael,
>
> I think that the workflow on -mentors does not discourage enough maintainers
> from working alone. Co-maintainance, work in a packaging team and use of VCS
> should be more often proposed after ITPs are filed (and of course, ITPs should
> be filed earlier).

Yes, I've seen some of those as well; those make me happy, actually. It is
always nice to work with someone who is willing to keep working to get it the
best way as possible. I love that.

That reminds me that another problem (probably the original source of these
issues) is that the documentation is not explicit enough or doesn't say all it
needs to/should say.

And before anyone tells me to stop complaining instead of working on it: I will,
I just have too many items on my todo list that should be done before.

>
> Have a nice day,
>

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T13:09:03Z

"Adam D. Barratt" <adam@...> writes:

> ... and did that an hour ago. Apologies for not waiting a little longer
> for objections / consensus.

Oh, no, it's no problem. I was being too conservative. Thank you!

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T13:07:32Z

Neil Williams wrote:

> d) fix as many other lintian errors as possible throughout the archive.
> (Quite a lot of lintian errors - some that I would consider quite
> serious - affect several hundred packages.)

Actually, that's on my list of proposed QA RGs for squeeze, and am willing to
work on it (together with the no bashisms one [not just whatever dash doesn't
support], and others). But lets talk about that when the cal for proposals is
made.

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T13:04:54Z

On Thu, 2008-12-04 at 12:51 -0800, Russ Allbery wrote:

> "Adam D. Barratt" <adam@...> writes:
>
> > As I mentioned to Sune on IRC last night, the quilt tag's severity was
> > copied from the equivalent dpatch tag (which was originally implemented
> > as a warning and then moved to minor/certain during the transition).
> >
> > I've no problem with downgrading the severity, although we should make a
> > corresponding change to the dpatch tag at the same time, unless there's
> > some reason it's particularly worse for a dpatch to be missing a
> > description.
>
> I think they're equivalent cases. Personally, I vote for downgrading them
> both.

I agree...

> Unless there are any objections, I'll do that in a bit.

... and did that an hour ago. Apologies for not waiting a little longer
for objections / consensus.

Adam

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T12:58:20Z

On 2008-12-04, Raphael Geissert <atomo64+debian@...> wrote:
> Will try to work on a dh-like command (or maybe a patch against dh_strip,
> depends on what Joey prefers) that will basically scan
> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
> matching the subgrouped expression, to automagically generate the Depends field
> (say ${dbg:Depends}).
>
> Once that's done it would be just a matter of adjusting a couple of lines in
> debian/control and you are done with dealing with -dbg packages.

No. it actually wouldn't work.

In kde, for example kdepim, contains applications like
- korganizer
- kaddressbook
- kmail
- kpilot

With a -dbg package depending on all apps, the user will have to install
all apps just for getting a backtrace for one application.

That is not desired.
Bloating the archive with seperated -dbg packages is ttbomk not desired
as well.

The current approach is currently the least bad, and lintian should not
complain.

/Sune

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T12:51:24Z

"Adam D. Barratt" <adam@...> writes:

> As I mentioned to Sune on IRC last night, the quilt tag's severity was
> copied from the equivalent dpatch tag (which was originally implemented
> as a warning and then moved to minor/certain during the transition).
>
> I've no problem with downgrading the severity, although we should make a
> corresponding change to the dpatch tag at the same time, unless there's
> some reason it's particularly worse for a dpatch to be missing a
> description.

I think they're equivalent cases. Personally, I vote for downgrading them
both. Unless there are any objections, I'll do that in a bit.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings (was: NEW processing)

2008-12-04T12:49:43Z

Sune Vuorela wrote:
[...]
>
> And other warnings that could be changed:
> dbg-package-missing-depends - if there 1 dbg package and multiple
> arch depending packages beside that.
>

Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends field
(say ${dbg:Depends}).

Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.

Cheers,
Raphael Geissert

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T12:28:53Z

Thomas Viehmann wrote:

> The particular pass through NEW that has been used to demonstrate the
> deficiency of NEW processing was necessitated by the rename
> iceweasel-l10n-hi to iceweasel-l10n-hi-in introduced in the previous
> upload (and processed in 3-4 days or so). This rename took place after
> uninstallability of iceweasel-l10n-all had been pointed out to the
> maintainer after he asked for an unblock on release. In essence, this
> whole trip through NEW would not have happened if the maintainer would
> actually routinely install his packages before uploading. I am all in
> favor of fast-tracking urgent stuff, but the deal should involve the
> maintainer making extra-sure to get things right, too.

Because we all know that uninstabillity problems can only occur when you
change the package name...

Or undistributable/illegal stuff. Or lintian errors.
In that sense, you should perform quality checks and moderate _every_
upload as well.

I'm all for doing legal checks and semi-automated quality/sanity checks
on the *first* upload.
But what's the point on doing it on binary package renames?
Crap can be introduced into the archive just as easily without it /ever/
processing NEW.

If the source package existed in the archive before it shouldn't pass
through NEW!

Quality assurance of existing packages is a job for the QA team.
The two teams should definitely cooperate, share common patterns and
possibly scripts.
In that way, all packages can be automatically or semi-automatically
checked, even those that don't ever change their package names.

Am I the only one that finds all of the above obvious?

Regards,
Faidon

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T11:32:47Z

>> I have a list of tags. In Extremadura I had other ftpteam members and a
>> lintian maintainer look at it. Whenever this gets implemented this list will
>> be made public and then have a place on ftp-master.d.o webpage
>> somewhere. And everyone can comment on it.
> So it was already decided that it was going to be implemented in
> Extremadura meeting?

We already talked about it in Mar del Plata, and there lintian already
got a feature we want for it.

--
bye, Joerg
> What would you do if you wanted to retire from the project?
This is far easier than to get in! ;)

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T11:10:14Z

On Thu, Dec 04, 2008 at 09:50:04AM +0100, Lucas Nussbaum wrote:
> As you can see, there are short times where the buildds for one arch
> have problem keeping up with the load, but that's often caused by :
> - one of the buildds being temporarily unavailable
> - one of the buildds building a very big package

- one of the buildd maintainers temporarily unavailable

Kurt

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T10:52:30Z

2008/12/4 Joerg Jaspert <joerg@...>:

> I have a list of tags. In Extremadura I had other ftpteam members and a
> lintian maintainer look at it. Whenever this gets implemented this list will
> be made public and then have a place on ftp-master.d.o webpage
> somewhere. And everyone can comment on it.

So it was already decided that it was going to be implemented in
Extremadura meeting?

Greetings,
Miry

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T10:49:26Z

>> By what process will the selection of lintian tags be submitted to the
>> project for review and approval prior to implementation as a hard
>> reject?

> I think that's a pretty good question. I don't think we need a very
> formal process, but as a Lintian maintainer, I'd kind of like people to
> sanity check them before we start doing that just so that we don't get
> flooded with complaints if we missed something obvious.

I have a list of tags. In Extremadura I had other ftpteam members and a
lintian maintainer look at it. Whenever this gets implemented this list will
be made public and then have a place on ftp-master.d.o webpage
somewhere. And everyone can comment on it.

--
bye, Joerg
Ich will ein anderes Telefon, das hier klingelt immer!

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Possibly excessive lintian warnings

2008-12-04T10:45:28Z

>> The only thing that's been seriously discussed with an eye to
>> implementation, so far as I know, is to automatically reject on the basis
>> of a hand-selected and very limited subset of Lintian tags, which would
>> probably not affect anything that you're doing and which would certainly
>> not automatically block packages with proper overrides. I don't think
>> this is going to hurt you as much as you think it would.
> Some people in this thread are suggesting automatic rejecting based on any E: tag.

Those people won't be the ones who implement it.

Those who will implement it will, of course, make sure to crawl through
lintian.debian.org making sure to only reject on tags that hit the most
packages possible as they don't have any better things to do than
pointlessly rejecting packages just for fun.

One of the sentences is a joke.

--
bye, Joerg
Some NM:
> 3. How do you manage new upstream releases?
yes i manage them.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: For those who care about pam-ssh: RFC

2008-12-04T10:32:52Z

2008/12/4 Luca Niccoli <lultimouomo@...>:
> 2008/12/4 Jens Peter Secher <jps@...>:
>
>> To do that you will need to change /etc/pam.d/ssh-auth to
>>
>> auth sufficient pam_ssh.so
>
> I know, that's why I'm not complaining =)
> May writing it in the README.Debian could be a good idea.
>

OK, will do.

Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: For those who care about pam-ssh: RFC

2008-12-04T10:19:08Z

2008/12/4 Jens Peter Secher <jps@...>:

> To do that you will need to change /etc/pam.d/ssh-auth to
>
> auth sufficient pam_ssh.so

I know, that's why I'm not complaining =)
May writing it in the README.Debian could be a good idea.

> Hmm, if noone else has access to the computer (including remote
> access) then the passphrase on the SSH keys do not need to be more
> secure than the login password. On the other hand, if there is remote
> access to the computer, then a weak password will enable an evil
> hacker to get into you account, copy your SSH key and brute-force
> attack the key elsewhere. So I do not really see your point.

If someone has physical access to my computer, the only security is
encryption. No sense for a strong login password, he could boot with
an other OS or take out the HD and directly read the key (both options
will take far less time then brute-forcing an even weak password by
typing tries by hand).
Brute forcing a strong encryption password would take a lot of time
instead (I guess), which at least keeps safe computers not accessible
to anyone else (I'm thinking about a laptop and a home server, if I
get stolen of the laptop I can delete the public key on the server).
Please correct me if I'm completely mistaken...
Cheers,
Luca

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Dropping multisync-0.8x for lenny

2008-12-04T09:15:41Z

Hi,

recently a user made me aware that multisync_0.82-8.1 is still shipping
in lenny currently.

The 0.8x series of multisync has been abandoned upstream for several
years now, and I think the opensync-0.22 packages together with
kitchensync should give at least the same user experience for lenny.
However, looking at popcon, it looks like multisync-0.8x is still quite
popular AFAICT, and it might work better for some users on older
devices, so I am a bit hesitant to get it removed.

Personally, I do not want to maintain (well, reply to bug reports mostly
I guess) multisync-0.8x for lenny, so I think removing it from
testing/unstable is a sensible approach even though we cannot provide a
migration path to kitchensync/opensync. Users will still be able to use
it when upgrading to lenny, but new users should rather turn to
kitchensync (even though the opensync-0.22 packages are not perfect
either, e.g. Windows Mobile syncing will not work very well with lenny
on kitchensync due to #484130).

If somebody is really fond of multisync-0.8x and wants to
retain/maintain it for lenny, please let me know; otherwise, I'll ask
for its removal from testing/unstable soonish.

cheers,

Michael

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T07:01:19Z

On Wed, Dec 03, 2008 at 10:09:37AM -0800, Don Armstrong wrote:
> It shouldn't need to be more than this, because packages shouldn't be
> uploaded with problems that can be trivially identified at NEW
> processing time.

Agreed.

> However, considering some of the rejects which have
> recently been discussed here, that appears not to be the case.

That seems irrelevant.

> This is the minimum required check, I think; if ftpmasters want to
> check more things and/or find more issues as they're doing this check,
> more power to them.

No, not more power to them. Conflating unnecessary tasks with privileged
roles is a bad idea.

If the project needed to moderate all BTS mails to ensure that nothing
insulting was said about the King, it wouldn't be rational to let the
BTS moderation team task themselves with ensuring that the message tone
was polite enough, that any submissions with spelling errors were
hard-rejected, and so on. This would clearly improve the quality of
the information in the BTS. Having the stewards of the archive do
QA work in a bottleneck is even more ludicrous because, unlike a bug
report, which is practically eternal, bugs in packages can actually be
fixed by subsequent uploads.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: For those who care about pam-ssh: RFC

2008-12-04T06:55:40Z

2008/12/4 Luca Niccoli <lultimouomo@...>:

> 2008/12/3 Jens Peter Secher <jpsecher.noreply@...>:
>
>> Because of the security implications of changing a PAM module, I would
>> welcome some peer reviewing of the changes I have made. The new package
>> has been uploaded to experimental, and the NEWS.Debian is as follows.
>> Also, I would like comments in general about the whether there are
>> better ways to solve the problems.
>
> As a user, I see a regression: I have @include (pam)-ssh-auth before
> @include common-auth in my confguration, and I use two different
> passwords for my local account and my ssh key; this way if I know
> I'll be networking I take the bother to type the long-and-very-secure
> password to unlock my key and get acces to the computer, otherwise I
> just hit enter and I'm asked for the simpler local password

To do that you will need to change /etc/pam.d/ssh-auth to

auth sufficient pam_ssh.so

such that the SSH passphrase is always asked, and, if it unlocks any
of the SSH keys, it will be sufficient to login.

> (I don't
> think there's really a point in a strong password if someone has
> physical access to the computer).

Hmm, if noone else has access to the computer (including remote
access) then the passphrase on the SSH keys do not need to be more
secure than the login password. On the other hand, if there is remote
access to the computer, then a weak password will enable an evil
hacker to get into you account, copy your SSH key and brute-force
attack the key elsewhere. So I do not really see your point.

Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Upcoming events in Japan

2008-12-04T06:37:08Z

Hi,

This is a short note to tell you all about what kind of events are
happening in Japan.

Upcoming events before the end of this year:

1. Kansai Debian Meeting

14 Dec 2008 in Osaka
http://wiki.debian.org/KansaiDebianMeeting

2. Tokyo Area Debian Meeting

20 Dec 2008 in Ogikubo
http://tokyodebian.alioth.debian.org/2008-12.html

I hope I haven't missed anything.

regards,
junichi
--
dancer@{netfort.gr.jp,debian.org}

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: For those who care about pam-ssh: RFC

2008-12-04T06:09:03Z

2008/12/4 Vincent Zweije <vzweije@...>:

> On Thu, Dec 04, 2008 at 02:03:52AM -0800, Steve Langasek wrote:
>
> || On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote:
> ||
> || > * The 'keyfiles' option is now obsolete. Instead the authentication
> || > module will automatically locate all files matching the pattern 'id_*'
> || > (the idea for this came from a patch from Javier Serrano Polo).
> ||
> || That doesn't sound like a good idea to me. What if a user has extra ssh
> || keys lying around that multiple people have the passphrase to, which prior
> || to this change would have been perfectly safe?
> ||
> || Also, why is the pattern id_*? ssh also recognizes 'identity' by default.
> || Shouldn't this really use the same pattern as ssh itself, i.e.,
> || (identity|id_dsa|id_rsa)?
>
> In addition I, and probably some others, have the habit of disabling
> files by adding a .OFF extension to it.
>
> This practice is based on the (in my view) reasonable assumption that
> programs should not be scanning directories for files to use unless
> those directories are specially intended for that purpose.
>
> It probably would be fine if there were a (documented) ~/.ssh/id.d/
> directory containing keys to be used (and nothing else).
>

That is a very good idea. But the id.d directory should probably
contain soft links to the actual keys to not interfere with the
standard location. Are the other packages which does something
similar?

If there are no objections, I will implement such a behaviour.

Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: NEW processing

2008-12-04T04:58:53Z

* Lucas Nussbaum <lucas@...> [081203 18:19]:

> > I completely disagree. It's a welcome benefit if packages of inferior
> > quality are prevented from entering the archive in the first place imo.
>
> We currently have a long reviewing process before packages get into the
> archive. But once they are in, maintainers are free to do whatever they
> want with their packages, without any review happening.
>
> I'm not advocating that we just stop doing reviews. But IMHO, NEW
> processing should be about the legal problems, not about the random
> lintian warning/errors, and the various other packaging malpractices.
> What we should do instead is encourage reviews (either on mentors, or
> inside teams), because that's also a much more scalable solution.

I think package general reviews are a good idea. But checking packages
upon entering is still the best point. Removing packages that users
already user is not something most people take lightly. Rejecting
packages not having some minimal quality to begin with is easy, though.

> Of course, if ftpmasters come across random problems in the package
> while reviewing legal stuff and mention that to the maintainer, it's
> great. But having other things checked by ftpmasters just reduces their
> bandwidth and causes longer queues.

I think splitting that in two teams and having packages only leave NEW
when both ftp-masters have agreed on the legal aspects and an other
group of people have checked for other problems will not improve the
time packages are in NEW in my eyes.

And suggesting that things are not checked first time will only make
things having less quality. In my eyes there are rather too few checks.
Having things like packages with unneedingly repackaged upstream sources
and things like that entering which are not possible to undo even by
some later maintainer before the next upstream version and things like
that do not benefit the project at all...

Hochachtungsvoll,
Bernhard R. Link

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: For those who care about pam-ssh: RFC

2008-12-04T04:25:08Z

On Thu, Dec 04, 2008 at 02:03:52AM -0800, Steve Langasek wrote:

|| On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote:
||
|| > * The 'keyfiles' option is now obsolete. Instead the authentication
|| > module will automatically locate all files matching the pattern 'id_*'
|| > (the idea for this came from a patch from Javier Serrano Polo).
||
|| That doesn't sound like a good idea to me. What if a user has extra ssh
|| keys lying around that multiple people have the passphrase to, which prior
|| to this change would have been perfectly safe?
||
|| Also, why is the pattern id_*? ssh also recognizes 'identity' by default.
|| Shouldn't this really use the same pattern as ssh itself, i.e.,
|| (identity|id_dsa|id_rsa)?

In addition I, and probably some others, have the habit of disabling
files by adding a .OFF extension to it.

This practice is based on the (in my view) reasonable assumption that
programs should not be scanning directories for files to use unless
those directories are specially intended for that purpose.

It probably would be fine if there were a (documented) ~/.ssh/id.d/
directory containing keys to be used (and nothing else).

Ciao. Vincent.
--
Vincent Zweije <zweije@...> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.

signature.asc (196 bytes) Download Attachment

Re: Packaging IKVM: inclusion of 3rd-party sources

2008-12-04T04:17:48Z

On Thu, Dec 4, 2008 at 8:01 PM, Cyril Brulebois <kibi@...> wrote:
> David Paleino <d.paleino@...> (04/12/2008):
>> Any suggestion is very welcome.
>
> 3) Run away.

4) Prepare asbestos suit. Then build-depend on openjdk-6-source and
notify the release team about the need to binNMU every time openjdk
gets updated. Notify the security team of this requirement so that
they can fix ikvm when/if OpenJDK requires a DSA/DTSA.

5) Some kinda mono -> Java runtime bridge instead of converting the
code at build time?

6 ) see #3

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...