Re: Problems to upload

[Thomas Viehmann]

[didn't sent to the list...]
Andreas Tille wrote:
On Fri, 17 Dec 2004, Andreas Metzler wrote:
first place.   Especially the hint to "PASSIV MODE" smells like 
something
has changed to the situation before.
| dput (0.9.2.15) unstable; urgency=low
Perhaps this was the reason but I should probably reopen the bug which
claimed more verbose error messages.  The failure was caused because
only passive mode seems to work - at least I was asked by manual ftp-client
to switch to passive mode (I do not know until know what passive excatly
is).  Also dupload caused a passive mode related error message.  In
contrast to this dput just stopped with a Python error.
Your analysis is correct, my apologies. As non-DD, I really don't get to
test ftp uploads as thoroughly as I should.
There is a bug report (and I've just sent a (corrected) fix), #283370,
which concerning this problem.
Sorry for leaving this open for so long.
Kind regards
Thomas
(dput comaintainer)
--
Thomas Viehmann, <http://thomas.viehmann.net/>

Re: dehs will stop

[Thomas Viehmann]

Hi Stefano,
Bluefuture wrote:
I know that there are a little bit group of people that think that the
"old" use of watch file could be converted in a Qa tools, but actually
i'm the only one that is trying to find a solution that could fix that
lack of watch file. 
But without maintainers interest, the project still lack in an usable
status. 
There is no reason to put more work and effort on a community tool that
community itself consider useless.
I hope that something could change. But i don't belive it.
I know that I thougt dehs per se not too useful, but the watch section 
on qa.d.o has inspired me to write watch files for two of my packages. 
Not much (2 out of 7), admittedly, but I think that it's fairly useful. 
I think the experimental columns are overkill (as people packaging 
experimental stuff probably monitor upstream releases even more closely).
If 25% of the packages can be watched, hey, that's a fair share.

Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Thomas Viehmann]

Josselin Mouette wrote:
2.6 kernel, alsa-base doesn't end up being installed. The result is that
for most sound cards, both OSS and ALSA modules end up installed,
resulting in various and random problems. To avoid that, shouldn't the
kernel-image packages for 2.6 depend on alsa-base?
Please not. There's people running kernels without needing sound or 
alsa-base. I wouldn't mind recommends/suggests, but depends is a litte 
bit strong IMO.

Kind regards
Thomas
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug #298195: ITP: tinywm -- Ridiculously tiny window manager

[Thomas Viehmann]

Hi.
Nick Welch wrote:
(not sure if i can post to this list, but what the hey)
Hey, thanks for joining the discussion.
It's the fair license, which is OSI approved:
http://opensource.org/licenses/fair.php
Yet it seems that the BSD license's
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
is much more explicit than the fair license on use and modifications.
Also I'm not sure about the "notification" bit, so I'll leave that to 
the experts.

Thomas
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Thomas Viehmann]

Hi.
Josselin Mouette wrote:
As long as the linux26 installation ends up with both sound modules
loaded, that's a bug that needs to be fixed, though. Another option
would be to put the alsa modules in separate packages, just like pcmcia
modules.
That definetly sounds much better ;).
Kind regards
Thomas
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Key management using a USB key

[Thomas Viehmann]

Eric Dorland wrote:
An arguably more secure approach would be to use a cryptographic smart
card in a usb key form factor with OpenSC. Unfortunately integration
with ssh and gpg is lacking at this point, but I hope to be able to do
something about that post-sarge (ssh has support but doesn't compile
it in, and gnupg support will come with gnupg 2.0).
gnupg 1.4 (as in sid) supports OpenPGP cards like the one I'm presently 
using (bought from g10code). The form factor is 
Chipcard-Reader+Chipcard, but it's there.

Kind regards
Thomas
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: State of gcc 2.95 use in Debian unstable

[Thomas Viehmann]

Dave Carrigan wrote:
> On Wed, Nov 16, 2005 at 04:12:45PM +0100, Thiemo Seufer wrote:
>>>The situation is: gcc-2.95 is no longer needed to compile debian packages,
>>>but it is still needed for other tasks, by many people.

>>By whom, and for what? So far I haven't heard a specific project's
>>name.

[...]
> I am quite sure that there are Debian *users* out there that have legacy
> code that only builds under gcc 2.95 (or more likely g++ 2.95) and they
> haven't ported it to a newer C compiler because there is no business
> case for it. 

Dave, we're not working on the removal of gcc 2.95 for the fun of it.
Sarge ships with gcc 3.3 as default and supports gcc 2.95. More than one
year from now, Debian will release its next stable release and the
balance of the costs of continued support of gcc 2.95 versus its
benefits is shifting to a point where the effort of keeping 2.95 is
undesirable. Support for old compilers is quite an effort and it's in
the best interest of Debian and its users by dropping it so that Debian
can retain its high quality standard.
Debian is not rushing to drop gcc 2.95, but in the long run, it's
inevitable. Or, to put it in your words, there is a business case for
dropping gcc 2.95 support in etch.

> Removing a package simply because the Debian developers don't need it
> any more is the kind of arrogance that drives users away from Debian to
> other distributions.

Well, Debian is a fairly large sample of (free) software. If reliance on
gcc 2.95 is a vanishing characteristic of Debian packages, this suggests
that the general usage has diminished to a point where it is
unreasonable to continue support. this is why Thiemo asks for evidance
of the contrary. This has nothing to do with arrogance or developers
disregarding the interests of its users. It is about sustaining quality
by allocating resources appropriately.

Kind regards

T.

-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: Using Enhances a bit more?

[Thomas Viehmann]

Hi,

Enrico Zini suggested something like:
>   Package: phpgroupware-foobar
>   Enhances: phpgroupware

Good idea, will do.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mixing different upstream sources in one package

[Thomas Viehmann]

Hello Jay,

Jay Berkenbilt wrote:
> My inclination would be decline requests to add unrelated packages to
> psutils, but I thought I'd solicit input from others in case someone
> has some perl (oops, pearl) of wisdom that I have overlooked.  Thanks!

IMHO (and I have suggested this particulary for 'sed through a postscipt
file' packages on d-mentors) this is about the users and free software.
Both are greatly helped by putting the stuff providing
yet-another-postscript-manipulation-scriptlet in the psutils package
where users have a chance to find it.

OTOH if upstream is actively opposing such additions, you might
reconsider to keep them happy.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to deal with screwed up package

[Thomas Viehmann]

Hi Bartosz,

Bartosz Fenski aka fEnIo wrote:
> Let's say I'm going to remove debconf questions at all. To keep user's
> system clean I should remove chosen group, but... because of some
> bugs[3][4][5] it's possible to leave system non-working after that.

How about just leaving the old group rot?

Basically, the question is very similar to the ever-recurring should
system users be removed one. It is my impression that both scenarios
aren't the end of the world, but not removing seems to have the stronger
support in numbers and possibly the better arguments in general and here
it seems to be the prudent option by far.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: petsc_2.3.0-1_i386.changes REJECTED

[Thomas Viehmann]

Hi,

Adam C Powell IV wrote:
>   * There is broad consensus for versioned -dev packages (e.g.
> Thomas Viehmann's precedent, Junichi's libpkg-guide),
> particularly for this case where both the Debian alternatives
> system and PETSC_DIR mechanism allow users to select between
> multiple versions or multiple builds of the same version (LAM,
> single precision or complex, -contrib linked vs parmetis and
> hypre, -dec with HPaq alpha tools, etc.)
Eh. I only said that versioned -dev packages seem tolerable to most
people. In particular, I don't really like the idea of my name being
mentioned so close to petsc's use of the alternative system. IMHO it's a
genuine example of a very bad idea.

>   * There is a very strong consistency argument for keeping
> petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though
I don't really think that any of these packages have too much in common
with petsc-dev - octave and linux-image-2.6-xxx aren't even -dev
packages. Python and the notion of a default-python-version and it's
implementation seems rather special to me, and TBH, I don't think anyone
claims that the python dependency construction is without problems.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thomas Viehmann]

[I've dropped some CCs...]

Norbert Preining wrote:
>>What about texlive-bin-base?

> As I said, it is true that I can arbitrary hyphens, but there was a
> decisison behind these names: Keeping the collections of TeX live (this
> is what users see when they use the installer) and the debian packages
> namewise in sync.

> I have no problem introducing different names, but only if I see good
> reasons other than "I like it" or "it is usual like this". To me, the
> argument on name-sync collection-debiannames is strong enough to keep
> the current names.

Well, Debian as a project has effectively standardized (by practice) on
the hyphenation that has been suggested all over the place in this
thread. Debian users will and should be able to expect a Debian-style
package naming.
Dismissing comments favoring this hyphenation - in unison - as
expressions of personal taste doesn't really reflect the fact that
consistency is a quality Debian users look for in packages.

If you provide the TeX live names in the long description, people will
be able to find stuff by the usual package search functions.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic closing of bugs

[Thomas Viehmann]

Hi Matt,

if that would help, I'd include a (n option that allows to) check via
bts2ldap + the attached script into dput.
That'd be less intrusive than changing the behaviour of Closes:, for
better or worse.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/
#!/usr/bin/python
import sys, rfc822, ldap
from apt_listchanges import ttyconfirm

def parse_changes(changes):
chg_fd = open(changes)
check = chg_fd.read(5)
if check != '-':
chg_fd.seek(0)
else: # found a PGP header, gonna ditch the next 3 lines
chg_fd.readline() # eat the rest of the line
chg_fd.readline() # Hash: SHA1
chg_fd.readline() # empty line
if not chg_fd.readline().find('Format') != -1:
chg_fd.readline()
changes = rfc822.Message(chg_fd)
return changes


ch = parse_changes(sys.argv[1])

closedbugs = map(int, ch.get('Closes','').split())
pkgs = ch.get('Binary','').split()+[ch.get('Source','')]

if closedbugs:
 print "Querying ldap..."
 l = ldap.open("bts2ldap.debian.net", 10101)
 l.simple_bind()
 resid = l.search("dc=current,dc=bugs,dc=debian,dc=org",
		 ldap.SCOPE_SUBTREE,
		 "(|%s)"%(''.join(map(lambda x: "(debbugsID=%d)"%x, closedbugs))),
		 ["debbugsPackage","debbugsID","debbugsTitle"])
 res = []
 r = l.result(resid, 0)
 while r and r[1]:
   res.append(r[1][0][1])
   r = l.result(resid, 0)

 otherpkgsbugstouched = filter(lambda a: a['debbugsPackage'][0] not in pkgs, res)
 if otherpkgsbugstouched:
  print 'Changelog closes bugs of other packages:'
  print '  '+'\n  '.join(map(lambda y:
			 ' '.join(map(lambda x: ' '.join(y[x]),['debbugsID','debbugsPackage','debbugsTitle'])),
  otherpkgsbugstouched))
  print "Do you want to continue? [y/N]",
  if sys.stdin.readline()[1:] not in ['y','Y']:
sys.exit(1)

Re: Automatic closing of bugs

[Thomas Viehmann]

Thomas Viehmann wrote:
>   if sys.stdin.readline()[1:] not in ['y','Y']:
For added utility I might want to improve on that.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/

'What'll we drink to?' Nick asked, holding up the glass.
'Let's drink to testing,' Bill said.
'All right,' Nick said. 'Gentlemen, I give you testing.'
'All testing,' Bill said. 'Everywhere.'
'Testing,' Nick said. 'That's what we drink to.'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

Hi,

Vincent Sanders wrote:
> [1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm

taking a "random" (end of alphabet) sample from maybe-failed:

twinkle: requeue (probably libccrtp was stuck in NEW)
wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
xchm: retry (needed libchm-dev)

xmms-openspc: arch specific (says maintainer in control)
zinc-compiler: arch specific dependency (ghc6)

visualboyadvance: buggy, could requeue to get #334727
weechat: don't know, error on dh-strip on 5 archs, no bug filed

That's 2 out of 7 which need actual debugging, both not arm-specific.

If you're deperate for people looking at build-failures, that's OK, but
only few of them seem really arm-specific.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

Kurt Roeckx wrote:
>>twinkle: requeue (probably libccrtp was stuck in NEW)
> The problem is that libccrtp1-1.3-0 is still linked to
> libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a.
Hm. Sorry.

>>wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
>>xchm: retry (needed libchm-dev)

> This can probably be requeued indeed.  But it would help if the
> maintainer uploaded xchm after libchm was in installed state
> on all arches, so buildd admins don't have to look at this.
Yeah. That would help. But so there's a lot of packages that need
attention by buildd-admins.

>>xmms-openspc: arch specific (says maintainer in control)
>>zinc-compiler: arch specific dependency (ghc6)

> So those should get added to P-a-s instead.
Well, but that'd be something for the buildd-admin to collect.
(Or maintainers of the packages, but that doesn't seem to fashionable
nowadays...)

>>visualboyadvance: buggy, could requeue to get #334727
> What's the point to requeue if this bug isn't fixed?
There isn't, thats why it says "buggy, could requeue", not "needs
retry". Also if you had a lot of cycles to spare, the last build log
would actually reflect the current problem...

>>weechat: don't know, error on dh-strip on 5 archs, no bug filed

>>That's 2 out of 7 which need actual debugging, both not arm-specific.

> And only 1/7 where some action of the buildd maintainer is needed
> at this time to get something build.
The dep-wait is well inside the "some action of the buildd maintainer is
needed". The needed P-a-s entries could be handeled centrally if the
problem description is "pile of maybe-failed packages".

OTOH above sample is biased: There's only ~57 Packages where apt-get
fails or dpkg complains about wrong arch.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

Hi,

[Steve's comments seem to suggest that patches to P-a-s might be OK, so
I'm CCing Lamont and Adam who seem to have done the last couple of
commits to P-a-s.]

Steve Langasek wrote:
>>Well, but that'd be something for the buildd-admin to collect.
>>(Or maintainers of the packages, but that doesn't seem to fashionable
>>nowadays...)

> Um... no.  This is *porter* work; one does not have to be a buildd admin to
> analyze a build failure to see whether the package belongs in P-a-s, and
> there's no reason that the buildd admins alone should bear the
> responsibility for figuring out whether a permanent build failure should be
> fixed or ignored.  (Maintainers probably need to be involved in this
> process, but usually maintainers don't have the requisite knowledge about
> all our ports to make informed decisions on their own.)

Sorry, then I must have misunderstood the nature of the P-a-s file.
But then, I always thought of it as a relict that probably should be
gotten rid of once one believes that porters and maintainers can sort it
out by themselves.

>>The dep-wait is well inside the "some action of the buildd maintainer is
>>needed". The needed P-a-s entries could be handeled centrally if the
>>problem description is "pile of maybe-failed packages".

> Wonderful.  Nice to see that you think P-a-s entries are somebody else's
> problem that should be "handled centrally".
Well, that certainly is the impression I get. After all, sombody has to
commit the changes.
As for "somebody else": Attached is a patch for the build stuff that I
think I have figured out.

Thinks I don't know:

helix-player: don't know.
hotkey-setup: might also work on amd64 ia64 (depends on dmidecode)
  OTOH, maintainer usually seems to know what he's doing...
libpam-encfs: isn't arch-specific, see #340575. Maybe random arch
  disabling should be RC...
%ogre-contrib: i386 amd64 # don't know, in contrib
prj2make-sharp: i386 powerpc s390
  # amd64: #314517 without maintainer comment
  # ia64 arm unknown, others disabled in P-a-s

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/
--- Packages-arch-specific.orig 2005-12-06 10:25:15.0 +0100
+++ Packages-arch-specific  2005-12-06 11:37:06.0 +0100
@@ -23,11 +23,14 @@
 
 3c5x9utils: i386 # PC 
hardware specific
 855resolution: i386  # i386 
chipset specific
+915resolution: i386 amd64 kfreebsd-i386  # 
[?] *-i386? i386/amd64 chipset specific
 aboot: alpha # alpha 
boot loader
 %aboot-installer: alpha  # 
alpha boot loader installer 
 acpi: i386 ia64amd64 # 
acpi is i386/ia64 specific
 %acpi-support: i386 amd64 ia64   # [ANAIS]
+%acpica-unix: i386 ia64 amd64 kfreebsd-i386  # [?] 
*-i386?  acpi is i386/ia64 specific
 acpid: i386 ia64 amd64   # acpi is 
i386/ia64 specific
+acpidump: i386 ia64 amd64# [?] 
*-i386?  acpi is i386/ia64 specific
 %afbinit: sparc  # 
Sparc gfx card firmware loader
 %alleyoop: i386 amd64# [ANAIS] 
- Depends valgrind
 %alsadriver: i386 # i386 
specifc
@@ -92,6 +95,7 @@
 %cvsup: i386 # i386 
specifc (needs modula-3 )
 %detect: alpha i386  # 
build-depend on isapnptools binary
 %delo-installer: mipsel  # 
mipsel specific
+dfsbuild: i386 alpha powerpc amd64   # [ANAIS] 
debian from scratch installer
 %dmidecode: i386 ia64 amd64  # [ANAIS]
 %drdsl: i386 amd64   # [ANAIS]
 %drscheme: alpha amd64 hppa i386 m68k mips mipsel powerpc sparc  # 
[ANAIS]
@@ -151,12 +155,15 @@
 %gpart: i386 hurd-i386 ia64 alpha arm mipsel amd64   # little 
endian specific
 gprolog: i386 mips mipsel sparc alpha powerpc# from 
source
 %grub: i386 hurd-i386 amd64   # i386 
boot loader
-grub2: !hppa !ia64 m68k  # 
bootloader
+grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc   # 
bootloader for i386/powerpc [?]
 grubconf: i386 hurd-i386 freebsd-i

Re: StrongARM tactics

[Thomas Viehmann]

Hi Steve,

Steve Langasek wrote:
> Ok.  Here's some feedback on some that I either disagree with, or don't see
> enough rationale for.  (This is why, ideally, the process should involve the
> porters and the maintainers...)
Thanks. Doesn't hurt do get educated...

>>+dfsbuild: i386 alpha powerpc amd64 # [ANAIS] 
>>debian from scratch installer
> Seems like it should be portable without too much trouble to other
> architectures, if there was porter interest?
Yes, OTOH it clearly needs to be adapted to whatever it's ported to, and
there haven't been any arch additions for well over a year, so it seems
interest is limited.

For ree:
How portable is scaning /dev/mem between position 0xc and 0xf in
512 byte blocks for some magic number as a concept?
The code probably compiles on anything, after all an implementation as a
shell script plus unix utils is provided along with the c implementation.

> Just because it's only built for these archs now doesn't mean this has to be
> true long-term.
So, how long term should something be to be included?
It looks like the file is changed every two weeks or so. My guess was
that then if changes are submitted in bulk, declaring something seeing
no porter attention for a year is OK to list in P-a-s.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd administration [was Re: StrongARM tactics]

[Thomas Viehmann]

Steve Langasek wrote:
> Er, did you even *read* this thread?  We got on the topic of buildds because
> *someone refused to help diagnose build failures because they consider it the
> buildd admin's job*.

Maybe it's not entirely impossible that the other subthread starting at

| Wonderful.  Nice to see that you think P-a-s entries are somebody
| else's problem that should be "handled centrally".

and containing a few reports similar to Thiemo's

| FWIW, I started to send mips patches for P-a-s, following the
| procedure outlined at the top of this file. There was neither a
| response nor any other discernable action.

could have contributed to the "buildd administration" complaints?

The reaction to my (admittedly less than optimal) attempt at an analysis
that followed was not "oh, do check these with porters and maintainers
and then get back to me" from someone who could then change the file,
but half dozen people saying something to the effect "I'm a
porter/maintainer and were utterly unsucessful at my attempts to get
anything done".
I do appreciate your comments of proposed P-a-s additions that you think
problematic but the rest of the thread rather spells "don't bother".

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

Wouter Verhelst wrote:
> That's still a bit of time wasted, but it's not really bad. The really
> problematic version is when a package is downloaded, build-deps are
> installed, and /then/ sbuild figures out that some version isn't recent
> enough.
According to the intersection of the debcheck build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, see e.g. gnucash.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: StrongARM tactics

[Thomas Viehmann]

Wouter Verhelst wrote:
> That's still a bit of time wasted, but it's not really bad. The really
> problematic version is when a package is downloaded, build-deps are
> installed, and /then/ sbuild figures out that some version isn't recent
> enough.
According to the intersection of the debcheck build-depends test and
m86k's Needs-Build [1], this will likely affect gnomesword bibletime
knoda asterisk k3d loop-aes-modules or are these already caught by the
buildds?

Inaccuracies are caused (at least) by debcheck only using packages
unstable (not incoming etc.) and not treating conflicts.
The latter also leads to the list of packages that could be retried
(i.e. failed for insatisfiable dependencies but this isn't the case
anymore) [2] to be not useful yet, as gnucash shows.

Kind regards

T.

1. http://people.debian.org/~tviehmann/fail-predictions.txt
   (NOT automatically updated though, scripts in my ~ on p.d.o)
2. http://people.debian.org/~tviehmann/couldretry.txt
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian and the desktop

[Thomas Viehmann]

Bill Allombert wrote:
>> ... generic menu entries ... SuSE ...

> What is needed at this point is a draft policy defining what will be
> the new layout and what will be the generic titles.

KDE seems to use the GenericName .desktop entry.
Probably a good starting point would be to cannibalize these, maybe?
Are there technical issues, too, or is it just the naming?

I'm sorry, but my vage recollection is that someone somewhere wanted to
have menu transitioned to desktop, but I don't think that this has ever
been done...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian and the desktop

[Thomas Viehmann]

Hi,

thanks for your comments.

Bill Allombert wrote:
> But there are another way: KDE and GNOME provide a non-Debian menu.
> However there are no clear definition about what should go in this menu.
> Maybe the policy could be to only put in this menu the applications
> relevant to "Bob User" and keep the Debian menu to "Bob Hacker". This
> might be a simpler way to get the same results.
This could be a very good idea.

One of the things that are probably impossible without a decider (which
is one of the things that many Debian derivatives have and Debian does)
to single out one package for a purpose (e.g. one word processor) to
include in a simple default install/menu. Having a dozen entries with
"Text Editor" denoting applications from gedit to emacs is probably not
too cool.

As I'm into specific and possible things, though (and have two 1-item
categories in my gnome menu which I can file bugs about but maybe
maintainers should be helped to get this right):
- how about linda/lintian check for empty longtitle in menu files
  and comment in .desktop files.
  (this is used as a hint (shown when the mouse hovers over the menu
  entry) in the Debian/Gnome/KDE(?) menu)
- a linda/lintian check for categories in .desktop to match
  with freedesktop.org's register [1]
- mention .desktops in some Debian packaging documentation (which one)
  to point people to the freedesktop.org documents [2] (I missed the
  category register at first), saying something about how binding
  that is and implement some further checks in lintian
- maybe standardize on the .desktop locations

Kind regards

T.

P.S.: Could someone give me a pointer about moving to .desktop and why
it is/was considered a bad idea? (Or if it's just a not worth it/noone
has time issue...) It seems burdenful for maintainers to provide both
and they're not always well synced (I noticed that emacs21's .desktop
comment used as hint in the Gnome menu was meaningful whereas the menu
file lacked a longtitle that is used as hint in the Debian menu.)

1. http://standards.freedesktop.org/menu-spec/latest/apa.html
2. http://standards.freedesktop.org/desktop-entry-spec/latest/
   http://standards.freedesktop.org/menu-spec/latest/
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: APT public key updates?

[Thomas Viehmann]

Joey Hess wrote:
> BTW, has anyone thought about what will happen when we have a stable
> release that has the 200n key in it and 200n+1 rolls around[1]? Will stable
> even be installable anymore? How will the updated key be pushed out to
> stable quickly enough? Will we have to rebuild CDs and obsolete all the
> old ones then too? Is the current scheme of having overlapping
> signatures for 1 month long enough, given that stable users might well
> only update their machines quarterly or so?

Given that stable is stable, wouldn't it be possible to sign each stable
release with a special key kept offline without causing too much trouble?
That doesn't solve security updates though, so the key for that would
need to be updated as necessary.

Alternatively, a two link process with a role key kept offline signing
the archive key might be OK as well, but that leaves the question how
not to have that key compromised.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Need for launchpad

[Thomas Viehmann]

Romain Francoise wrote:
> Automatic import of the Debian LDAP data?
I don't think Debian'd give the data away.
Also, the accounts correspond to package maintainers rather then Debian
developers (I don't use my @d.o address for packages). If it was the
latter, surely they could have done better with identification of DDs [1].

Kind regards

T.

1. https://launchpad.net/people/debiandevelopers
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: APT public key updates?

[Thomas Viehmann]

Frans Pop wrote:
> On Saturday 20 February 2010 09:15, Joey Hess wrote:
>>Nonzero exit; odd, it doesn't seem to notice that the key is expired at
>>all. But apt won't use gpgv like that, I suppose, but instead like
>>this:

> Note though that other packages, like debmirror, do:
> 
> my $GPG="gpg --no-tty -q";
> [...]
> if (!-f "$tempdir/dists/$dist/Release.gpg" || \
> !-f "$tempdir/dists/$dist/Release" || \
> system("$GPG --verify $tempdir/dists/$dist/Release.gpg 
> $tempdir/dists/$dist/Release")) {
Well, anyone using the mirror can then verify.
If you're just trying to determine whether or not Release corresponds to
Release.gpg this behaviour is much saner than assuming Release invalid,
because debmirror would attempt to fix that by regetting.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Hi,

first of all, thanks for taking the initiative I think the matter is too
important to be left alone just for avoiding to step on anyones toes.

Anthony Towns wrote:
> Random ideas for negative consequences might include forced
> orphaning by overriding maintainer fields to debian-qa, removal of
Maybe this should not only be limited to packages with RC bugs... For a
lot of packages with inactive maintainers, it might be best to not
release them in etch.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Thijs Kinkhorst wrote:
> I very much agree that we should strive to make packages as good as
> possible, but if users depend on a package and there are no real
> showstoppers in it, we might do our users a better service with shipping
> than with not shipping the package.
No. Shipping unsupported packages no developer cares about is a bad idea.
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?

Kind regards

T.

[1] And yes, I'd maintain a list if it's considered a good idea.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Frank Küster wrote:
> Hm, well, no.  I do particularly care for one orphaned package,
> lmodern.  But since it currently doesn't have any (real) RC bugs, I have
> more important things to do than adopt it on behalf of the
> debian-tetex-maint list (or talking Norbert Preining into creating it
> from his texlive sources).  If any work is really badly needed, someone
> of us will for sure step in;  but that doesn't mean that we're happy to
> have the additional burden.  I'd rather have it marked as orphaned, so
> that a new maintainer "candidate" can clearly see that it needs care,
> than formally adopt it while we can in fact only care for RC bugs[1].

Well, maybe the actual situation would be better reflected if one of the
interested parties adopted the package and retitled the O bug to RFA?

> Therefore I don't think that merely being orphaned is a good criterion
> for removal; especially not until we make sure that all unmaintained or
> badly maintained packages are in fact orphaned.

Can you elaborate on this? I'm not sure how the existence of more
packages that should be orphaned invalidates dealing with those that
presently are.
There's 169 orphaned packages today, why not do something about them?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Russ Allbery wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> writes:
> 
> 
>>Can you elaborate on this? I'm not sure how the existence of more
>>packages that should be orphaned invalidates dealing with those that
>>presently are.
> 
> 
>>There's 169 orphaned packages today, why not do something about them?
> 
> 
> The thing is... most of the orphaned packages are in fairly good shape.

How do you know?

> Most of the orphaned packages are orphaned because they're obscure and the
> person who cared about the package has left the project or run out of
> time.  However, they are probably still working fine for people with those
> obscure needs, and as such there isn't an obvious significant gain for
> Debian by getting rid of them.

I think that not shipping unmaintained and unsupported packages is a
benefit. Packages need a maintainer to enter, I think they should need
one to stay.

Look at dcl as a random example. I think that not having a maintainer is
quite a burden when security bugs such as the one fixed shortly before
sarge release occur after release and this is when the upstream seems up
to speed and people (here Joey Hess) in Debian track security reports
globally, otherwise, security bugs might even go unnoticed.

Also, I'm not sure how much the important bug impedes the functioning of
the package, IMHO it would be rather bad if new installation was
impossible with postgresql without documenting it beforehand.
Using dbconfig-common probably would also be on a maintainer's todo list.
So really, while the QA maintenance is certainly fine ATM, the package
probably isn't as well supported as we would expect from a designated
maintainer.

Note that dcl was deliberately kept out of woody for being unmaintained...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Raphael Hertzog wrote:
>>I think that not shipping unmaintained and unsupported packages is a
>>benefit. Packages need a maintainer to enter, I think they should need
>>one to stay.

> You wouldn't say that if you were a user using an orphaned package ...

Well, I've been in the situation to dig out an old package from an old
stable release a couple of times. I think this is far preferable than
making unfounded claims that the packages is properly supported.

> I'm sorry, there's no "global answer" to orphaned packages. Sometimes they are
> obsolete and should be dropped. Sometimes they're not and we should try to
> find maintainers for them.

We do try. We send mail about them every week.
The question is: is it worthwile for Debian to ship and support these
packages? I'd say for packages with no maintainer for, say, three
months, we just need to say no. Just like RFPs being closed if noone
picks them up, orphaned packages should go. Mere consumers can only have
limited influence on volunteer projects.
A large part of what makes Debian great is that packages are maintianed
by people taking an interest in them.
So yes, I claim that "drop them after three months with no interest" is
an appropriate answer to orphaned packages.

> If we can't find maintainers inside Debian, we
> should look in the upstream community around the software and use
> adequate infrastructure :
> http://wiki.debian.org/CollaborativeMaintenance
> Of course, it's easier to say than to do and I have only 24 hours per day.

Sorry, Raphael, I appreciate you're effort to promote and enable
collaborative maintenance very much, but it's not the holy grail solving
all maintenance problems. Packages need maintainers in the same way that
an architecture needs porters.

Kind regards

T.

-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Development standards for unstable

[Thomas Viehmann]

Russ Allbery wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> writes:
>>Russ Allbery wrote:
>>>The thing is... most of the orphaned packages are in fairly good shape.
>>How do you know?
> Well, because at one point I went through the PTS for each one of them,
> checked for filed bugs, checked lintian reports, etc.  I haven't
> specifically *used* each of them, but I think the choices are no one is
> using them (popcon seems to say no), no one is reporting problems
> (possible, but statistically I'd expect someone to notice), or they're in
> fairly good shape.

Well, given that several people with more QA experience than myself
objecting to this, I guess I'll yield to experience. Maybe I'll just
discuss a manual selection of packages first.

Thanks for your input.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Thomas Viehmann]

Hi,

I'm seeking advice on the following problem:
- xvfb-run bails out on nonexistant / not root-owned /tmp/.X11-unix,
- a/my pbuilder chroot won't have /tmp/.X11-unix,
- I need some X (xvfb is fine) to build libaqbanking (glade-2 code
  generation needs X bug).

A working work-around is build-depending on fakeroot and calling
fakeroot xvfb-run.

Any better ideas?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Thomas Viehmann]

Hi Daniel,

thank you!

Daniel Schepler wrote:
> Have you tried just recreating base.tgz with an up-to-date pbuilder?
Ah, no. Cool. I'll have to file a wishlist item against pbuilder to
update its configuration upon update.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pbuilder-maint] pbuilder, xvfb and nonexisting /tmp/.X11-unix

[Thomas Viehmann]

Junichi Uekawa wrote:
> Please recreate base.tgz for this to take effect.

> What's the issue?
Sorry, I missed the changelog entry (it took a while for me to trigger
that bug and someone else using a newer chroot but probably
pbuilder/stable had the same problem but I didn't think of him not using
unstable).
I like your idea of customizing pbuilder chroots with debs. I'm not fond
of recreating the base.tgz because I have some customizations
(editor...) in my chroot.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PROPOSAL: debian/control file to include new License: field

[Thomas Viehmann]

Kevin Mark wrote:
> You mean they check ever single time $RANDOM_PACKAGE enter NEW and don't
> assume its correct until someone raises an objections? I'd at least
> think you could create a sub-queue in NEW so that already tagged
> standard licenses would get processed faster and others would be in a
> location to allow for special license processing.
Well, de facto a package that only has a soname bump will likely not be
license-reexamined.
For truly new packages, though, there is no way to get around a thorough
examination by someone paying careful attention and the ftpmasters are
really doing a good job at this.
Unfortunately there are enough maintainers that are sloppy in the
fulfillment/ignorant of the requirements of the debian/copyright file[1]
to lessen the ftpmasters' burden. dh-make's brokenness[2] doesn't help.
In fact, a random new package mentioned on debian-mentors will likely
not have a correct copyright file. At the time of writing this, the last
open RFS for a new package is stegosnow[3]. It does display this problem.

Kind regards

T.

1. http://lists.debian.org/debian-devel-announce/2003/12/msg7.html
2. http://bugs.debian.org/336982
3. http://sponsors.debian.net/viewpkg.php?id=218
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: May a package assume that builds are performed with root-like rights?

[Thomas Viehmann]

Daniel Schepler wrote:
> Here's a thought: how hard would it be to make TeX fall back to caching in a 
> directory under the user's home directory (maybe $HOME/.fonts/texmf or so) if 
> it can't write to /var/cache/fonts?  pbuilder does have $HOME set up to work 
> all right with BUILDUSER{ID,NAME}.
Well, some people think that writing outside the build-dir is a FTBFS
bug as well[1].

Kind regards

T.

1. http://bugs.debian.org/336014
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems found by piuparts

[Thomas Viehmann]

Thijs Kinkhorst wrote:
> On Mon, 2006-02-27 at 18:40 +0200, Lars Wirzenius wrote:
>>If we are to start doing checks on packages before accepting uploads, I
>>think it would be best to start with some subset of lintian and linda
>>errors. 

Note that individual maintainers can already configure dput to stop the
upload on lintian/linda errors. You can also add hooks to that end to
pbuilder.

> Since these tools can already differentiate between errors and warnings,
> it would make sense to define the subset for rejection as "all errors".

I'm afraid I have to disagree here. An old FSF address doesn't warrant a
reject. Neither do false positives in lintian, they do happen (e.g. the
last C++ transition would have been impeded, in fact l.d.o still shows
lintian errors for "libfoo0c2a").
Effectively, this would only foster an increase in questionable
overrides. Lintian is a useful tool, but it's results need to be subject
to review before filing bugs or doing rejects.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW queue backing up again -- ftpmasters, any explanation or comment?

[Thomas Viehmann]

Martin Michlmayr wrote:
> 20:38 < Ganneff> the archive grow too fast too big. so i should not process
>   NEW so fast to not grow much more in a short term. something like that more.

Well, if that's the reason, are updates to existing source packages
still allowed? I'd really like to fix my RC bugs and sync with upstream
at the same time but the latter would involve so-version changes.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW queue backing up again -- ftpmasters, any explanation or comment?

[Thomas Viehmann]

Jeroen van Wolffelaar wrote:
>>Well, if that's the reason, are updates to existing source packages
>>still allowed? I'd really like to fix my RC bugs and sync with upstream
>>at the same time but the latter would involve so-version changes.

> This is not the reason for any backlog, although it does limit amount of
> NEW accepts per day, but there's still plenty of room in each day to do
> a lot of NEW. The bigger bottleneck is simply human processing time.

Well, I won't try to convince you to prioritize the "new binary packages
from known source package" because last I heard (some 360 days ago), you
didn't need convincing. Assuming that those 40-some packages affected
are easier to process, it'd still be nice, though.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: aqbanking -- generic library for home banking

[Thomas Viehmann]

Package: wnpp
Severity: wishlist
  Package name: aqbanking
  Version : 1.0.2 beta
  Upstream Author : Martin Preuß
  URL : http://www.aqmainiac.de/aqbanking/
  License : GPL (maybe parts LGPL)
  Description : generic library for home banking
AqBanking provides a generic API for home banking applications. It 
supports various file formats and protocols with plugins, e.g. OFX, 
DTAUS, and HBCI. Note that for the latter AqHBCI is required.

Hi,
I'm pleased to announce the intention to package aqbanking.
Some notes on this ITP:
- This is a group effort. I'll not list anyone to avoid forgetting
  people, but anyone following the openhbci-general list at sf will
  probably have seen them in action.
- aqbanking is part of the dependencies of the GnuCash HBCI module
  starting with version 1.8.10, so we're trying to put stuff back
  into Debian which we have grown to like when we had it.
- The ITP covers the aqbanking library itself as well as the other
  (optional) modules distributed alongside aqbanking (such as kbanking
  and qbankmanager).
- A seperate ITP will be filed for aqhbci.
- (Very) preliminary packages are at
  http://vman.de/debian/unstable/
- The package names will probably change.
Kind regards
Thomas
--
Thomas Viehmann, <http://thomas.viehmann.net/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: aqhbci -- library for HBCI home banking

[Thomas Viehmann]

Package: wnpp
Severity: wishlist
  Package name: aqhbci
  Version : 0.9.19 beta
  Upstream Author : Martin Preuß
  URL : http://www.aqmainiac.de/aqbanking/
  License : GPL (maybe parts LGPL)
  Description : library for HBCI home banking
AqHBCI provides plugins to AqBanking for implementing the Home Banking
Computer Interface protocol (popular with German banks). It supports
various security mechanisms, e.g. key files, PIN/TAN, and DDV chipcards.
Support for RSA chipcards is in an experimental stage.
Hi,
I'm pleased to announce the intention to package aqhbci.
Some notes on this ITP:
- This is a group effort. I'll not list anyone to avoid forgetting
  people, but anyone following the openhbci-general list at sf will
  probably have seen them in action.
- aqhbci is part of the dependencies of the GnuCash HBCI module
  starting with version 1.8.10, so we're trying to put stuff back
  into Debian which we have grown to like when we had it.
- It covers the aqhbci library itself as well as the other (optional)
  modules distributed alongside aqbanking (such as the setup wizard
  and chipcard plugins).
- A seperate ITP will be filed for aqbanking.
- (Very) preliminary packages are at
  http://vman.de/debian/unstable/
- The package names will probably change relative to the preliminary
  packages.
Kind regards
Thomas
--
Thomas Viehmann, <http://thomas.viehmann.net/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A new arch support proposal, hopefully consensual (?)

[Thomas Viehmann]

Sven Luther wrote:
Problems with many arches:
  - same for the security team.
Hmm. I only saw Joey's message on the subject, which basically seemed to 
say "as long as it's only one source compiling on all arches, it's OK"

 7) the porter team has the possibility to providing arch-specific overrides
 to solve the issue of a package not passing from unstable into testing due to
 a tier1-specific RC bug or whatever. Should be used sparingly though.
This seems problematic in this respect.
I might have missed the previous suggestions or the obvious flaws of the 
idea, but why not have something along the lines of "releasing all 
'tier2' arches with the packages they have", i.e. agressive per-arch 
removal for uninstallable/unusable/not-up-to-date packages. Those arches 
that have something worth releasing at release time (installer, all 
priority >= important, x% of optional in usual release quality) do that. 
This way, the security support of the additional arches would stay 
largely the same. One could have the present testing rules up to some 
point and switch to "if arch-specific RC bugs/testing delays pop up, 
stuff get removed" for release.

Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A new arch support proposal, hopefully consensual (?)

[Thomas Viehmann]

Sven Luther wrote:
The idea is that we don't want to hold up release, but we still want to allow
for a future release at a later point, in a stable point release. Especially
now that we are told that security is not an issue.

This way, the security support of the additional arches would stay 
largely the same. One could have the present testing rules up to some 
point and switch to "if arch-specific RC bugs/testing delays pop up, 
stuff get removed" for release.

Not sure if this is a good idea. The main point will be for the arch-specific
fix to get in in a timely fashion, and it being blocked by unrelated
tier1-breakage, not to remove the package and thus remove the fix. If you are
saying that we should in this case remove the tier1 packages from testing
though :)
Well, you'll at most get "classic" Security-Support for those sources 
that match the "regular ones" and I doubt that the policy for point 
release will - or should - be weakened to allow arch-fixes. My 
impression was that a split into supported / less supported (yeah, 
reminiscent of a popular derivative) of the ports would reduce the total 
amount of work while not overburdening the general process.

Kind regards
T.
P.S.: I'll not necessarily need CCs for all mails of this thread to read 
them.
--
Thomas Viehmann, http://thomas.viehmann.net/

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why does Ubuntu have all the ideas?

[Thomas Viehmann]

Marco d'Itri wrote:
>>  * xen integration
> Everybody that matters is doing this.
> BTW, where is this integration visible?
> Do we have a VM provisioning system?
Are you looking for something like xen-tools by Steve Kemp, Debian
packages maintained by Radu Spineanu?

Cheers

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: package ownership in Debian

[Thomas Viehmann]

Gustavo Franco wrote:
> * Are you working on the package foo ?
> 
> In a scenario when anybody or tons of people can upload the package foo,
> it's necessary to tag somewhere that you're working on the package foo.
> Groups do it using IRC or wiki articles today. We could do it using the
> NEWS in the PTS. It won't break the current groups approach since
> these groups can point the wiki articles or irc channels for
coordination there.

For larger stuff, I think people could just mail the maintainer/submit a
bug and wait a day or two. I usually try to comment on patches rather
quick with something along the lines "will upload this soon" or "please
don't NMU with this just yet" and some rationale.

> * Where are you working on the package foo ?
> 
> You could send the vcs information about the package to the PTS that
If that is wanted, I'd consider it important enough information to have
it in debian/control. In particular, URLs seem to be readily available,
so this should be really easy to do.
For repositories updated with {svn,...}-buildpackage, you could even do
some more magic (like easy checking of whether something newer than the
last upload is in unstable, check out the latest source based on sources
list + package repository, etc.).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: package ownership in Debian

[Thomas Viehmann]

Simon Richter wrote:
> I propose that under that policy, if someone NMUs a package without
> clearing the patch with the maintainer first, that person is responsible
> for the package until the maintainer acknowledges or reverts the NMU.

Isn't that more or less the status quo already?

As in:

Follow what happens, you're responsible for any bug that you introduced
with your NMU. You should probably use The Package Tracking System,
Section 4.10 (PTS) to stay informed of the state of the package after
your NMU.

Cheers

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

seeking advice on device ownership

[Thomas Viehmann]

tag 373595 + help
thanks

Hi everyone,

can someone help me with chown-ing a device in udev (or something better)?
I'm packaging libchipcard2 which includes a daemon (in
libchipcard-tools) run under a non-root uid. As it needs to access card
readers, I its user, chipcard, is automatically added to dialout. This
lets the daemon access serial readers and those USB readers working via
ttyUSB.
As there are other USB readers, accessed directly, I guess I now need to
write udev rules changing ownership.
Some questions:

- is it OK to chown the devices to user chipcard? (other chipcard
  software, e.g. pcscd from pcsc-lite seems to run as rood)
  via a provided udev script?
- can somebody help me write/test this? (I've got the USB vendor/product
  ID)?

Kind regards and thanks in advance

T.
-- 
Thomas Viehmann, <http://beamnet.de/tv/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]

[Thomas Viehmann]

Marcin Owsiany wrote:
> Who decided that we should just drop them all? After all generating a
> non-UTF locale and setting an environment variable isn't a very
> difficult workaround? I mean, when has lack of UTF support become an
> RC-bug? Charset support is not even mentioned in the policy, other than
> for debian/changelog.
There's quite a way from "not properly supporting UTF, possibly mangling
characters" to "needs workaround for most installs otherwise being
completely unusable with opaque error message". The latter doesn't
really sound like a releasable state to me.
I think looking at the issue with the criterium "the distribution better
not have a lot of packages with this type of fault or it's a completly
useless junk collection of packages" one can see a big red blinking RC
bug sign for this specific bug (as opposed to all UTF problems being RC).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Accepted lynx 2.8.5-2sarge2 (source i386)

[Thomas Viehmann]

Thomas Dickey wrote:
>> Date: Sat, 13 May 2006 07:47:40 +0200
[...]
> After the second time, there is no plausible excuse.
> Do you have an excuse?

Why do you ask if you know there isn't?
Hint: You could always look at the date of the actual update.

Maybe you just file a minor bug, that would help people noticing and
correcting the error.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#387926: ITP: eaccelerator -- PHP opcode cacher and compilation optimizer

[Thomas Viehmann]

Pierre Habouzit wrote:
> here is the link that explains that: 
> http://archive.eaccelerator.net/OldNews

> and that has been achieved since, if I'm correct. so if this is just a 
> matter of exception to be done to the GPL, I'm really sure we can work 
> on it nicely.

>> so basically, what has to be done? they must just explain that they
>> allow anyone to build their GPL software against php, is that it ?

>> the situations changed in the sense that we are not tied because of
>> the past anymore.

The CVS seems to tell a quite different story.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Public discussion time for Creative Commons 3.0 license draft coming to a close

[Thomas Viehmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

first, thanks Evan for your work and the update.

Eric Dorland wrote:
> * Evan Prodromou ([EMAIL PROTECTED]) wrote:
>> So, for those of you who want to see Creative Commons licenses that meet
>> our standard of Freedom, this is the time to act. Please, if you haven't
>> already, take a few minutes to send an email message to the Creative
>> Commons public review mailing list [6] letting CC know that you support
>> a Debian-compatible version of the license. "I want a Debian-compatible
>> Creative Commons license, signed John Q. Hacker" is probably plenty.
> 
> I'd very much like to see this happen, but I feel kind of
> uncomfortable sending an "AOL" to a list I'm not subscribed to and a
> discussion I haven't participated in. Maybe some sort of signature
> collection would make more sense, then send batches in a single email
> to the list. Seems more polite that way. 

If you do, please count me in.

Kind regards

T.
- --
Thomas Viehmann, http://thomas.viehmann.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: GnuPG key at <http://thomas.viehmann.net/>
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRSGQcUqbsiUXPcVvAQLfSQQAoKgrS53DBb0zvXcFNEoYhsZ+ywthgq2F
fiCXtZrtGKZ79ZdZc7J/i++lGzs+J9TWnMsLReYMQ4+U7nS+yXWeRo/uSle6xI21
OxGPOlw9uXPPhsv4lz2btLHPm7PF82eQ6gAVHvY9DSr1jtbf4/a5qbCljOtY3Ojj
qlx5GzVtnso=
=T0ZY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Thomas Viehmann]

Wouter Verhelst wrote:
> Or we could mimic FreeBSD behaviour: create a fortune-file with helpful
> tips for newbies, and add a line in the default initialization files
> (i.e., those in /etc/skel) for different shells that calls fortune for
> those tips.

You mean like fortunes-debian-hints[1]?

Kind regards

T.

1. http://packages.debian.org/fortunes-debian-hints
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Two questions on package quality

[Thomas Viehmann]

Nikita V. Youshchenko wrote:
>   (2) binary-without-manpage/no-manual-for-binary should not be added, so 
> linda/lintian complains remind that manual page should be written one day,
Lintian overrides are intended for false positives. Unsing them to
suppress reports of valid packaging problems is completely frivolous and
degrades Debian's overall quality.

> So .orig.tar.gz got repackaged, and now it differs from upstream.
> Should then 'upstream' version string be changed from x.y.z to 
> x.y.z.debian? Or not? Or it does not matter?
If you change the orig.tar.gz, the 'upstream' version should indicate
that. You'd probally want to check with the best packaging practices
suggested by the Developer's Reference[1].

Kind regards

T.

1.
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-repackagedorigtargz

-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations

[Thomas Viehmann]

Package: wnpp
Severity: wishlist

I'd be very thankful if the following could be packaged. I'd be able to
sponsor non-DDs if the packages are good.

* Package name: python-wavelets
  Version : 0.1.6
  Upstream Author : Filip Wasilewski <[EMAIL PROTECTED]>
* URL : http://cheeseshop.python.org/pypi/PyWavelets/
http://www.pybytes.com/pywavelets/
* License : MIT
  Description : python extension implementing of wavelet transformations

PyWavelets implements the discrete wavelet transform (DWT) popular in
numerical harmonic analysis for numerous families of wavelets, including
Haar, Daubechies, Symlet, Coiflet, biorthogonal wavelets in one and two
dimensions.
.
PyWavelets is implemented as a python extension for speed and uses NumPy
numeric arrays.


The supported python versions seem to be thoe >= 2.4, the python-numpy
dependency is stated as >= 0.9.8.

Kind regards and TIA

T.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-023stab033.6-enterprise
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW queue backing up again -- ftpmasters, any explanation or comment?

[Thomas Viehmann]

Thomas Viehmann, http://thomas.viehmann.net/
> Well, I won't try to convince you to prioritize the "new binary packages
> from known source package" because last I heard (some 360 days ago), you
> didn't need convincing. Assuming that those 40-some packages affected
> are easier to process, it'd still be nice, though.
I'm not sure whether this is done, but thanks for dramatically reducing
the number of packages in NEW and processing particular
so-version-renamed packages so quickly.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MIA Christoph Wegscheider?

[Thomas Viehmann]

MJ Ray wrote:
> Does anyone know the current status of maintainer Christoph Wegscheider?
> Last maintainer uploads:
> * qiv 2005-05-23 (sponsor Thomas Viehmann cc'd)
I sponsored Justin Pryzby's qiv C++ transition NMU in January and
haven't had any interaction with Christoph, sorry. Christoph's only
upload was sponsered by the previous qiv maintainer Martin Pitt (CCed).

Kind regards

T.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW queue backlog

[Thomas Viehmann]

[apologies for the blank reply]

Michael Banck wrote:
> Both Jörg and Jeroen (who are usually doing the NEW processing AFAIK)
> are travelling in Mexico for another two weeks I believe.  Maybe one of
> the regular ftp-masters steps in and does some processing for the more
> important stuff in the meanwhile, though.
Are you sure that this isn't done? I had the impression that fixes for
RC bugs that only are soname changes or something were processed a
couple of days ago...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW queue backlog

[Thomas Viehmann]

Michael Banck wrote:
> On Mon, May 22, 2006 at 10:39:36AM +0200, Wouter Verhelst wrote:
>> Debconf is over now, so I fully expect the NEW queue to be handled again
>> as good as it used to be in a few weeks. Which would hopefully mean that
>> emile, a package that I uploaded and which is stuck in NEW as well, will
>> be accepted into the archive.
> 
> Both Jörg and Jeroen (who are usually doing the NEW processing AFAIK)
> are travelling in Mexico for another two weeks I believe.  Maybe one of
> the regular ftp-masters steps in and does some processing for the more
> important stuff in the meanwhile, though.
> 
> 
> Michael
> 


-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uploading packages built against testing?

[Thomas Viehmann]

Hendrik Sattler wrote:
> Am Montag, 29. Mai 2006 10:27 schrieb Frank Küster:
>> Would it be acceptable to build bacula (or any other package with that
>> problem) in an etch environment, or on sid with manually installed
>> libssl from etch, and upload that to unstable?  After checking that it
>> works in unstable, of course.
How about waiting for openssl? As has been pointed out, openssl is
frozen for technical reasons and the new version will enter testing all
right[1].

> No, but you could manually set all stuff in Depends to the needed versions. 
> That would also work for the buildds, I guess.
And break at the next opportunity (binNMU, recompile, update in a
hurry...). Such hacks are almost certainly a bad idea, in fact John had
a complaint of similar type about the bacula packaging from before he
took over.

> PS: I bravely accept some flames for this suggestion...
Oh, if you insist: To be frank, maintainers having such ideas are bad
enough, but you'd better have a good excuse for handing them out as advice.

Kind regards

T.

1. http://bjorn.haxx.se/debian/testing.pl?package=openssl
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Renaming a package

[Thomas Viehmann]

Andreas Fester wrote:
> Is this the correct approach? Anything I missed?

I think the usual way is to provide the dummy binary package immediately
from the new source package and file a bug for removal of the old source
package.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Uploading packages built against testing?

[Thomas Viehmann]

Hendrik Sattler wrote:
> Am Montag, 29. Mai 2006 21:16 schrieb Thomas Viehmann:
>> Hendrik Sattler wrote:
>>> No, but you could manually set all stuff in Depends to the needed
>>> versions. That would also work for the buildds, I guess.
>> And break at the next opportunity (binNMU, recompile, update in a
>> hurry...).

>  he automated shared lib dependency calculation surely works but does not 
> always give optiomal results, e.g. it will pin to a specific libc (building 
> packages of non-free apps is sometimes better done with setting the depends 
> manually).
>From a Debian point of view, correct and minimal dependencies is a
(very) global problem, with correctness being a hard condition and
minimal not. In particular, local optimization towards minimal that
raise the probability of incorrect over package life time, are not a way
to go.
Experience shows automatism is asked for because the problem rate is far
lower. It doesn't any harm, either, does it?
Don't take my word for it, but do trust Steve's expert opinion. Debian
is large enough to predict "there will be N errors" in every "the
maintainer will have to be careful here", so your arguments are void...

> binNMU & recompilation: won't break if the app really works with this older 
> version and the lib must be ABI-compatible anyway.
... and this one is plainly wrong. binNMUs for rebuild against
dependency libs which have changed ABI are not only possible but
routinely done. Transition NMUs would be hard to get correct as well.

> Automatism is good but not the only way to do stuff.
For Debian packages taking clever shortcuts that are almost certain to
fire back is inacceptable. We all do the "create a Debian package using
ar" thing once, but we all agree that this isn't the way to do it.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LSB init scripts and multiple lines of output

[Thomas Viehmann]

martin f krafft wrote:
> also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.01.2122 +0200]:
>>> Starting RAID device md0 ... 3 drives, done
>>> Starting RAID device md1 ... 3 drives, done
>>> Starting RAID device md2 ... 2/3 drives, degraded
>>> Starting RAID device md3 ... 1/3 drives, failed
>>> Starting RAID device md4 ... 3 drives, done
>> What do people think about that?

Would combining the drives that went well make sense?
Starting RAID devices...  md0, md1, md4 done
Starting RAID device md2 ... 2/3 drives, degraded
Starting RAID device md3 ... 1/3 drives, failed

The "Starting RAID devices..." could be put before the startup.
I guess the gain I see is that on normal operation only one line is
printed while providing more detailed and still legible information in
case of a failure.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dak changes (names, version control, mail headers)

[Thomas Viehmann]

Hi,

thanks for the update.

James Troup wrote:
> merkel (DD accessible mirror of spohr)

A propos: The mirroring in /org/ftp.debian.org/ had been reduced/turned
off last fall (due to load problems on spohr[1]), is there any chance to
turn it back on (possibly with a larger interval for updates or somesuch)?

Kind regards

T.

1. http://wiki.debian.org/DebianAdminFoo
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why does doc packages need to contain gzipped files?

[Thomas Viehmann]

Frank Küster wrote:
> There was.  It ended with no conclusion.  Here's my view of the outcome,
> from pure recollection without looking anything up:
> 
> - gzipping PDF files does save some space; bz2 compression would save
>   even more.  Naturally, compressing files that are internally
>   uncompressed gives better results.
> 
> - among the people that maintain packages with lots of pdf.gz files, no
>   one seems really opposed to shipping them uncompressed.  But also
>   nobody seemd to be willing to do the first step, especially since
>   there is no consensus about not compressing them.

I think that a notable addition (by Olaf v.d.S. IIRC) was that it could
be worthwhile to improve viewers. E.g. kghostview will correctly open
.pdf.gz while gnome-gv will not. Similarly kdvi opens .dvi.gz.
Altough I'm not using KDE in general, my preference for kdvi is
precisely because of that (and reverse search, but that seems to be more
standard nowadays).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies, stage 5

[Thomas Viehmann]

David Weinehall wrote:
> Well, if foo depends on foo-data, and foo-data depends on foo, I find
> it really hard to see the point of splitting the two into distinctive
> packages...
Because libfoo7 bumps sonames and foo-data will have files in the same
location.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#379673: ITP: pybridge-common -- A free online bridge game. (common files)

[Thomas Viehmann]

Hi David,

David Watson wrote:
> * Package name: pybridge-common

are you planning to ship three different *source* packages?
If so, why?
(ITPs are filed per source package, but on a first glance, a single
source package with multiple binaries should be more appropriate.)

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Two versions of pan in etch?

[Thomas Viehmann]

Hi,

I'd advise against more than one version, that'll make you support two
versions with very limited upstream support. Do ship the one you're
comfortable with supporting until etch+1 and security supporting
somewhat longer largely by yourself: Upstream will tell you 'not to use
beta software' for the new one and that 'you should upgrade from the
"way old and bitrotten" version' for the old one.[1]

Having beta software in stable is a major headache (ha!) for all parties
involved (I've seen something like that with
phpGroupWare/woody.), so I'd vote for the old version over the new.

As a third option - and this is no joke - you could[2] consider to ship
none at all (have an external repo or somesuch). I did opt against
AqBanking support for sarge (and am very glad I made the right choice
with that) and most users are happy with the repository of backports
maintained on alioth by Micha Lenk. As much as we wish to provide users
with software in Debian, sometimes, this is not the ideal way of doing
things.

Kind regards

T.

1. And there is nothing wrong with that, either.
2. And indeed, please do consider this seriously. It's OK if you decide
   to ship a version with stable, but do ship great software and not
   just the version that is available at freeze time that sucks the
   least.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd logs for experimental

[Thomas Viehmann]

Drew Parsons wrote:
> As I understand it, buildds (or is it a separate set of servers?) are
> now autocompiling packages in experimental.  Where are the logs for
> these builds?
http://experimental.ftbfs.de/

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#380173: ITP: deb822 -- Read and manipulate RFC822-like files (e.g. .dsc and .changes)

[Thomas Viehmann]

The copyright file is broken. cf. #336982

>  deb822 abstractifies the RFC822 format used in Debian's control files.  You
>  can use a deb822 object like a Python dictionary, referring to control fields
>  as dictionary keys.

Is it really worth doing this?
Python readily has rfc822 parsing and the added value seems marginal to
the point where I'd not be looking for a module when I had a task to do
that could use it.
Additionally, shipping python modules without documentation seems a bad
idea if you want it to be useful.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#195313: ITP: libopenhbci-plugin-ddvcard -- DDV Chipcard Plugin for libopenhbci

[Thomas Viehmann]

Package: wnpp
Version: N/A; reported 2003-05-29
Severity: wishlist

* Package name: libopenhbci-plugin-ddvcard
  Version : 0.9.11
  Upstream Authors:
Fabian Kaiser <[EMAIL PROTECTED]>
Martin Preuss <[EMAIL PROTECTED]>
Christian Stimming <[EMAIL PROTECTED]>
* URL : http://www.openhbci.de/
* License : LGPL
  Description : DDV Chipcard Plugin for libopenhbci
This plugin for libopenhbci enables libopenhbci to work with ddv
HBCI chipcards (i.e. most cards save rsa). See libopenhbci and/or
libchipcard for further details and check with chipcard-tools'
"hbcicard type" whether you need this.

Supplementary Information:
- Many users of libopenhbci (e.g. via gnucash-hbci or aqmoney (to be
  packaged)) will need this plugin which was split from libopenhbci.
- I'm presently maintaining the libchipcard package.
- I've checked with James, the libopenhbci debian maintainer about this ITP.
  (As libchipcard is rather closely related with libopenhbci and I'm
   heavily using it, we're coordinating anyway.)

Cheers

T.

Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.

[Thomas Viehmann]

Hi.

Sven Luther wrote:
>>   Also, you could remove the leading "an" from the short description,
>>as recommended by the developer's reference.
> Description: audio player, for geeks, by geeks.
> Mmm, doesn't sound all that descriptive.
But hardly because of the removal of the "an".
(i.e. what business has "by geeks for geeks" rather than something informative
in the short description?)

Cheers

T.


pgpRvsU0FJp1F.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Thomas Viehmann]

Andreas Barth wrote:
> * "Martin v. Löwis" ([EMAIL PROTECTED]) [030622 11:50]:
> 
>>problem here (C++ ABI compatibility with other Linux distributions). The 
>>discussion is now about *how* to fix this bug:
>>1. just bump minimum supported i386-family processor to i486
> 
> 1a. like 1, but just for c++-packages.
As has been pointed out many times before and in this thread, dropping c++
support for i386 is much like dropping support completely, as important base
packages (e.g. apt [0]) depend on it.

Cheers

T.

0. According to the priority and section, of course.


pgpwGTXt3rchh.pgp
Description: PGP signature

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Thomas Viehmann]

Johannes Rohr wrote:
> I'd say that writing a meaningful package description is certainly the
> duty of the individual package maintainer. A package maintainer should
> usually have an idea of what his/her package is good for, while Javier
> would probably have to spend a lot more time to figure that out, at
> least for lesser known packages.
However, not providing a better description will (likely) not get anything done.

> I don't think that filing a bug saying that "Your extended package
> description does not meet Debian policy requirements. Please consider
> writing 4-5 lines to give sysadmins an idea what your package can do
> for them." means asking too much from a Debian maintainer.
You don't. But I can't help but think that there are a lot of obvious
maintainer's duties more or less neglected - often by simple obmission, but
sometimes patterns show.

Cheers

T.


pgpbUT5AjVPEd.pgp
Description: PGP signature

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Thomas Viehmann]

Josip Rodin wrote:
> On Tue, Jun 24, 2003 at 06:41:21PM +0200, Thomas Viehmann wrote:
> 
>>>I'd say that writing a meaningful package description is certainly the
>>>duty of the individual package maintainer. A package maintainer should
>>>usually have an idea of what his/her package is good for, while Javier
>>>would probably have to spend a lot more time to figure that out, at
>>>least for lesser known packages.
>>However, not providing a better description will (likely) not get anything
>>done.
> You don't know that. If we agreed to such a sweeping generalization, we
> would not have the vast majority of bug reports in the BTS.
Admittedly, I don't know that. Only one way to find out.

Cheers

T.


pgpTI9QfTmq27.pgp
Description: PGP signature

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Thomas Viehmann]

Benj. Mako Hill wrote:
>>>I don't think that filing a bug saying that "Your extended package
>>>description does not meet Debian policy requirements. Please consider
>>>writing 4-5 lines to give sysadmins an idea what your package can do
>>>for them." means asking too much from a Debian maintainer.
>>You don't. But I can't help but think that there are a lot of
>>obvious maintainer's duties more or less neglected - often by simple
>>obmission, but sometimes patterns show.
> Often, as in this case, those lapses in obvious (and documented)
> maintainer duties, constitute bugs in a package. Maybe I'm
> misunderstanding something in your argument here.

My argument was based on a matrix lintian error tags <-> maintainers.
There's lintian tags practically "owned" by maintainers. That's what I meant
with patterns. In those cases, pointing things out directly will help more.
In some cases, description deficiencies may be related to English skills (I'm
not a native speaker myself). In those cases patches can achieve much more than
bugs without patches.

Cheers

T.


pgpxwD0sISNKF.pgp
Description: PGP signature

Re: Packages: an average 66321 bytes per line of description

[Thomas Viehmann]

Daniel Burrows wrote:
> On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek <[EMAIL PROTECTED]> 
> was heard to say:
> 
>>>Not all of it, but you can't object to duplicating a single sentence saying
>>>what it is.
>>
>>When the sentence in question is the one that goes in the short
>>description, and already fills the available space without prepending
>>"runtime files for foo "?  Is the concern here with the short descs (I
>>don't expect much from short descs of affiliate packages), or with the
>>long descs?
>   Long descriptions.  See, eg,
>   libchipcard20-dev
So this should read like:
 libchipcard20 provides an API for accessing smartcards. Examples are memory
 cards, as well as HBCI (home banking), German GeldKarte (electronic
 small change), and KVK (health insurance) cards. This package contains
 all you need to develop for libchipcard20, namely includes etc.
 Upstream homepage is .
?

I'll update the description, but I don't know what get's said there that hasn't
been said before.

Cheers

T.


pgpE3wa7ipwlT.pgp
Description: PGP signature

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Thomas Viehmann]

Benj. Mako Hill wrote:
> On Tue, Jun 24, 2003 at 10:49:13PM +0200, Thomas Viehmann wrote:
> Writing and maintaining a package description seems to clearly be the
> package maintainers job. In reference to Branden's message in this
> thread, one would hope that the maintainers are also particularly well
> suited to writing this (i.e., better suited than someone that doesn't
> know the package).
As I'm one of the bad examples in the other current thread on the subject, my
assumptions are thoroughly disproven, so I'll just shut up and fix my 
description.

Cheers

T.


pgpMaIZbY4JEz.pgp
Description: PGP signature

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

[Thomas Viehmann]

Millis Miller wrote:
> I've already spoken to the upstream author, and he does not see mwilling to 
> convert to a DFSG license. Probably the only thing I can do is to make it 
> suitable for the non-free section for the time being. Can you indicate to me 
> how the license shoudl be changed to be suitable for the non-free section?
I don't think that the program provides enough value to be included in Debian
only based on the social contract's "support users" clause. (I.e. nonfree+only
substitute for small shell shell script = not worthy.)

Especially, having a package "email" in non-free tastes way to much like
endorsement of non-free software. (Especially since it's a particulary nasty
variant of non-free-ness.) If the package was called
silly-little-nonfree-email-tool, that might be different...

If you really want something like this in Debian, go write a free substitute.

Cheers

T.


pgpKbvQovrubl.pgp
Description: PGP signature

Re: Debconf or not debconf

[Thomas Viehmann]

Mark Brown wrote:
> What makes you think that a debconf note is inappropriate for this?  It
> appears to be quite a common thing to do and seems helpful.
Because it's documented and has been discussed to death on devel that debconf
neither is a registry nor system for displaying random notes. [0]

Cheers

T.

0. e.g.:



pgpcgIiQZS5mJ.pgp
Description: PGP signature

Re: Debconf or not debconf

[Thomas Viehmann]

Julien LEMOINE wrote:
> Not exactly, there is a variable ENABLED which is set to 0 at installation. 
> So 
> the service will not start while variable is not set to 1.
Well the user should notice this then and look in the README.Debian and
changelog. If it's the only problem, however, it might be worth considering
detecting whether or not the user configured stunnel in a way that it should be
enabled and doing so automatically.

Cheers

T.



pgpJLKOsFDdbE.pgp
Description: PGP signature

Re: debootstrapping and sysvinit

[Thomas Viehmann]

Julian Mehnle wrote:
> Miquel van Smoorenburg wrote:
>>Tobias Wolter wrote:
>>>I still haven't seen any bugfix from you. How about you go stop
>>>ranting about being treated unfair and DOING YOUR WORK?
>>And you think an attitude like this is going to make me work
>>harder? For *you* ?? Get real.
> Regardless of whether it was right to NMU sysvinit without you being
> notified:  I get the impression maybe you should think over why you have
> accepted maintainership of the package.  If you are maintaining it for your
> own sake only, then maybe you should give up maintainership and use a
> self-maintained, forked copy of the package.

How about putting things back into proportion.
There was quite an annying bug in the required base package sysvinit and we all
thought it was bad to have it around for a week. (And yes, my pbuilder chroot
broke, too, and so I had to make my own 4.1 which looked pretty much the same as
the NMU.) This has been duely expressed in the fourfold bug report and on the
-devel list.
And yes, the NMU did not follow the recommended procedures and upset the
maintainer. And many thought that was bad and it, too, was thoroughly discussed
on the list. However, it should also be noted that this has been the only
complaint about the NMU.
So why is there the need of telling people to orphan their packages? After all,
there's little indication that there is a severe and persistent problem at 
issue.

Cheers

T.


pgpiJdK2BAluv.pgp
Description: PGP signature

Re: Debconf or not debconf

[Thomas Viehmann]

Jim Penny wrote:
> Now, this breakage happens to be somewhat benign, in that without
> configuration, it does not function at all. But it is also somewhat 
> difficult to test for many uses.  Further,  when the unconfigured
> system fails to start, the failure is completely silent. This adds 
> to the problems.
What is difficult to test in ssl connections fail? I routinely test mine with
telnet-ssl or python scripts (though I remember something about python and IMAP
SSL not too long ago)...
Also, the silentness would IMHO be better fixed by adding a big fat NOT to the
init script (although anything more than a NOT will be controversial as
well...). Reminds me of something I should fix for my packages...

Cheers

T.


pgp8GOTOWRxD5.pgp
Description: PGP signature

Re: postrm::downgrade?

[Thomas Viehmann]

Andreas Metzler wrote:
> possible anyway, new packages, might use new file-formats which can be
> converted from the old-version but not back again.
Strictly speaking, any automatic conversion done during upgrades needs to be
injective and thus (theoretically) reversible for being correct.
Of course, that's only before the user changes the files generated during the
upgrade.

Cheers

T.


pgplJWLDDxIGK.pgp
Description: PGP signature

Re: Ein paar Fragen zu meinem Mailserver

[Thomas Viehmann]

Kai Timmer wrote:
> Stelle ich nun die Zeile mydomain = kaitimmer.local funktioniert das
Schon mal daran gedacht, das local.kaitimmer.de zu nennen?
Dann sollte es dem Relay egal sein.

Gruss

T.


pgpQd9BwbMqix.pgp
Description: PGP signature

Re: Debconf or not debconf

[Thomas Viehmann]

Marc Haber wrote:
> On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu
> <[EMAIL PROTECTED]> wrote:
>>I for one am sick and tired of useless Debconf messages popping up
>>during installation or being sent to me via email when I'm upgrading
>>hundreds of machines automatically.
> Just go ahead and pre-seed your debconf database appropriately before
> upgrading.

Funnily, Russel Coker explained something about this while explaining why he
turned away from Micro$oft in the Interview mentioned on debian-planet today...

Excessive usage of debconf notices is a bug which should be avoided/fixed, not
worked around.

Cheers

T.


pgpvFTqoLkhJL.pgp
Description: PGP signature

Sorry.

[Thomas Viehmann]

Sorry, I will try to learn to reply to the correct list.
(Incidentally, on my first attempt, I claimed that I will learn but wrote only
to myself...)
Cheers

T.


pgpqgdnAkSlw7.pgp
Description: PGP signature

NEW packages policy.

[Thomas Viehmann]

Hi.

(My apologies if -devel is the wrong place to put this - hints for better
locations are appreciated.)

While I understand that new packages need to be checked, I wondered whether this
rule could be relaxed somewhat for soversion-changing of libraries (i.e. the
advance from lib(.*)\d+ to lib\1\d+. Is the current policy of treating advances
of the soversion as new package a question of principle or implementation?

TIA for your answers.

Cheers

T.


pgpkHaJFJn2LG.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Thomas Viehmann]

Hi.

Julien LEMOINE wrote:
>   First of all, I present my excuses for having started a new debate
> about debconf in debian-devel.

But then, the last one didn't favor your opinion.

>   Secondly, to reply to every person who thinks I should have created a 
> more "user friendly" migration who did not break backwards compatibility. 
> My answer is that I have no time to implement command line support for 
> stunnel 4.x.

Yes. But you still have the options of:
- Publically asking if someone else has time and skill to do it.
- Putting off the update and/or packaging the interface incompatible stunnel
  under a new name.

>   Finally, since there is not really a policy about when to use debconf, 
> I will respect the DFSG [1] and add a debconf warning [2] in the 
> stunnel package.
There is a difference between the social contract and the DFSG.

As a user of stunnel: Your warning will not help me as it does not keep stunnel
from breaking. *Not* installing a totally incompatible program where the stunnel
I wanted when I said "apt-get install stunnel" would.

Cheers

T.


pgpSSwZtIe7kk.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Cameron Patrick wrote:
> On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote:
> | Well, once you folks have come up with a definition of "software", you
> | be sure and let us know.
> How about "anything included in Debian"?  That way we won't be in danger
> of violating the Social Contract #1.

Oh, cool. How about changing in DFSG to "Anything that can go in main or 
contrib."

Cheers

T.


pgpK5FoJovULU.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Joe Wreschnig wrote:
> On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote:
> 
>>Cameron Patrick wrote:
>>
>>>On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote:
>>Oh, cool. How about changing in DFSG to "Anything that can go in main or 
>>contrib."
> Because that's a circular definition. Saying everything in Debian is
> software, is not.
Given that in practice the ftp-masters get the final say, it isn't.
If you don't count that, saying "Anything in debian is software because debian
only distributes software" is as well.
I tend to agree with the probable conclusion of applying DFSG to determine the
freeness of anything in debian. However, the reasoning is fundamentally flawed.
David Harris' explanation is much better.

Cheers

T.


pgpnR7isj7ppg.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Andrew Suffield wrote:
>>people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
> This claims the GNU FDL is acceptable, so it's worse than useless.
It claims that GNU FDL sans cover texts and invariant sections is acceptable.

Cheers

T.


pgpFhyQTZaH4d.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Thomas Viehmann]

Andrew Suffield wrote:
> On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote:
> 
>>Andrew Suffield wrote:
>>
>>>>people to  http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
>>>This claims the GNU FDL is acceptable, so it's worse than useless.
>>It claims that GNU FDL sans cover texts and invariant sections is acceptable.
> Which is grossly out of date (read: wrong). This has been discussed to
> death on -legal.
... which is much more interesting than your initial statement. Thanks for
clairfying this.

Cheers

T.


pgpN0teLrrdhr.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Marc Haber wrote:
>>Well that's the purpose of ITP-bugs against wnpp I think, because
>>they are CC'd to debian-devel for public review.
> Please show me a single ITP bug number where ftpmaster has said "this
> package will not go into the archive, I will reject it on upload".
There's numerous ITPs where e.g. licensing (seems to be a main issue with
ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03).
If you're too cool to do proper ITPs then don't complain about the debian
processing for new packages not working for you.

>>And since ftpmaster sent you to -devel he would obey the opinion
>>of the list.
> The list does not seem to have an opinion yet.
Hmm. No?

Cheers

T.


pgpMCnkQQyKPe.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Marc Haber wrote:
> Because it makes debugging anti-virus software harder, and forces
> maintainers of anti-virus packages to have their own means of
> obtaining eicar.com for testing purposes
Debugging anti-virus software should be done by the maintainers thereof.
Why would a user need this?

> Saying a package is "silly" is a valid rejection reason in your
> opinion? Another reason is that a package depending on and
> recommending eicar-testfile would have to go into contrib. Yes, right,
> but there is Suggests: which allows a package suggesting
> eicar-testfile to stay in main.
Having an installer just because some organization is too lazy to provide a
license with a 68 bytes is plainly wrong (since eicar seems to be located in
Germany it might even be questionable whether they can claim copyright for
something of that size - but then they just could put it into the public 
domain).

> Well, _I_ find it impolite to say work that has been done by a
> volunteer is "silly". Actually, I find it discouraging to do any more
> future work for Debian
What did you want to package next? An installer that has a debconf prompt for
asking whether eicar.com, eicar.com.txt, eicar_com.zip, or eicarcom2.zip should
be downloaded?

Seriously, you're more substantial contributions have been accepted haven't
they? And that in spite of the fact that not having a legal name in deamon's
copyright file is questionable. And the package in question is just about the
silliest package I've ever seen (aside from those announced April 1st).


Cheers

T.


pgpwOyC9gFD84.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Andreas Barth wrote:
> * Thomas Viehmann ([EMAIL PROTECTED]) [030705 09:35]:
> 
>>Marc Haber wrote:
>>
>>>>Well that's the purpose of ITP-bugs against wnpp I think, because
>>>>they are CC'd to debian-devel for public review.
>>>Please show me a single ITP bug number where ftpmaster has said "this
>>>package will not go into the archive, I will reject it on upload".
>>There's numerous ITPs where e.g. licensing (seems to be a main issue with
>>ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03).
> Andreas Tille, who critized the license in #199874 is according to
> http://www.debian.org/intro/organization not ftpmaster. So ...
>>If you're too cool to do proper ITPs then don't complain about the debian
>>processing for new packages not working for you.
> ... is not right.

The point is that the public review of ITPs (which is part of the process of
submitting a new package) seems cover most of the concerns that may cause
rejection by ftpmaster (which is the final part of a new packages' way to
debian). At least that's my impression of the way this is supposed to work.
What I'm saying is that basically the discussion on devel would have addressed
the limited merit alledged by ftpmaster.
Marc's complaint (or at least one of the more clear items he complained about)
was that he received ftpmasters feedback after his work is done. Had he ITPd
(properly), he might have been told before.
So why is the recommendation against skipping the ITP to aviod problems in
ftpmaster review "not right"?

Cheers

T.


pgptTkx8JCola.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Bernd Eckenfels wrote:
> On Sat, Jul 05, 2003 at 10:14:10AM +0200, Thomas Viehmann wrote:
> 
>>Debugging anti-virus software should be done by the maintainers thereof.
>>Why would a user need this?

> i used it many times, for example to find out which archives are checked and
> which not. In fact I even already wrote bugs for AV scan software because it
> did not recognized eicar signature inside archives, which where announced.
> #155485 is such an example.

So, how much of the debugging work was downloading the signature file?

> Thomas, actually I wonder if you talk about Linux or Debian, or if you
> confuse this with commercial windows packages, which can only be debugged by
> their vendor.

Oh, I thought the advantage of open source was that you could debug by other
means than just testing. Indeed, one could claim that the eicar test file is
needed particulary when you don't have access to the source.

Relly, I'd not make a package of single HTML document for testing browsers'
rendering of tables (or whatever), either.

Cheers

T.

P.S.: I don't need CCs.


pgpWtpDgiOpaG.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Andreas Barth wrote:
> Marc is doing it the other way: He want an interface to reject a
> package before substantial work has been spent on it. So there
> shouldn't be this conflict any more, which would be a good thing.

Isn't this why ITPs are usually CCed to debian-devel?
Look what has been done to the email ITP, to the mplayer ITP, ...
I don't know what that "directory name" deal is, but basically I have the
feeling that ftpmaster is predicatble (in fact reasonable) enough for the public
review on -devel to anticipate decisions. No need to bother the ftpmasters with
every package where -devel or -mentors or whoever would very accurately identify
the problems it would have once it was uploaded.

Cheers

T.


pgpKkXfFPfE6y.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Andreas Barth wrote:
> * Thomas Viehmann ([EMAIL PROTECTED]) [030705 23:50]:
> 
>>So why is the recommendation against skipping the ITP to aviod problems in
>>ftpmaster review "not right"?
> A (strong) recommendation for doing ITPs right is right and usefull.
> But - all foreseeable problems should be handeled at ITP-time, and
> that's not the case. So the recommendation is right, but it doesn't
> solve the problem Marc spoke of.

I doubt that an eicar-installer ITP would have survived the scrutiny of devel.
So it may not solve the general problem Marc about but it solves a very good
share of it, most likely *including* the very specific instance he had problems
with.

If you can't come up with a case where the ITP review was positive and ftpmaster
rejected the package in itself with a unforseeable reason (regarding a problem
that cannot be fixed), I fail to see any merit in your argument.
There's no point in establishing VIP review for people who are think they are
too important for  undergoing peer review.

*Look* at #198311 and search for debian-devel and then ask yourself why Marc
thinks that -devel should only be used as a forum to discredit ftpmasters work,
and not as a place where ITPs should be reviewed.

Cheers

T.


pgp0n7r2FptNY.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Marc Haber wrote:
> On Sun, 06 Jul 2003 11:03:37 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
> wrote:
>>*Look* at #198311 and search for debian-devel and then ask yourself why Marc
>>thinks that -devel should only be used as a forum to discredit ftpmasters 
>>work,
>>and not as a place where ITPs should be reviewed.
> That was indeed an omission, caused by the fact that I filed an RFP
> first and later retitled the bug to ITP. Surely you never make any
> mistakes.
I make a lot of mistakes. (That's why I prefer working on computers/math over
things like medicine.)

In fact, I made a similar mistake with the ITP of libchipcard (IIRC) because the
X-Debbugs-CC got lost because I usually call reportbug -p and copy stuff into my
mailclient when reporting bugs. (And it might be a reasonable idea to
investigate posting ITPs on debian-devel by other means than the
X-Debbug-CC-Header so such obmissions are impossible).

However, I sincerely believe that without this obmission, the ITP might have
been shot down (or held reasonable) before the upload (and possibly before the
creation) of the package. Thus (leaving the style issue that upset you aside) I
think that the (technical) merit of your complaint is somewhat limited.

As far as the eicar license is concerned: Is it really that difficult to obtain
a statement from eicar on whether or not they believe that the test file is
copyrightable and maybe a general permission to distribute the file? From your
comment I guess you tried, but quite possibly they understand better Debian's
concern about licensing with all the publicity the SCO lawsuit has.

That said, I see additional issues with the inclusion of the eicar file (aside
from the obvious point that probably it'd rest just as well in another package
containing a virus scanner): Debian mirrors and CDs will be quite possibly be
identified as carrying virii.
Quite possibly, it's reasonable to "obfuscate" (in a documented way) the file
(e.g. xor it and provide a program for decryption) or include a script or
download instructions rather than the file itself. Possibly, even the original
installer package looks a lot less silly on second thought.

Cheers

T.


pgpIIa5GHxRAZ.pgp
Description: PGP signature