Re: XEmacs/GTK 21.1.11

[Karl M. Hegbloom]

> "Joachim" == Joachim Trinkwitz <[EMAIL PROTECTED]> writes:

Joachim> Juhapekka Tolvanen <[EMAIL PROTECTED]> writes:
>> I fear, that it will take so much time, that we must have separately
>> packaged XEmacs/Gtk meanwhile. And I fear, that latest upstream sources
>> of XEmacs will ship with too old version of XEmacs/Gtk. Just check out,
>> how old version of Gnus and Auctex ships with latest XEmacs, if you
>> don't believe me.

Joachim> The strategy of the emacs{19|20} Debian packages, which have much 
more
Joachim> separate lisp packages, though born of need, results in much 
fresher
Joachim> modules and quicker update cycles, which would be nice to have for
Joachim> XEmacs too (never mind my english, I hope you understand what I 
mean).

Joachim> Maybe all those Debian packages like psgml, auctex, gnus etc. 
should
Joachim> be made for XEmacs too.

 I began work on this, but do not have time to finish it.  I must work
 on college instead.

 I have code in my CVS repository for packaging XEmacs 21.2, the
 current development version.  I've not finished it; It's only
 partially complete and doesn't completely work yet.  It may be
 suffering some bit rot as well; it's been a year since I did anything
 with it.

 Because of school, I will likely not have time for it until next
 summer.  If anyone out there would like to try and take over where I
 left off, let me know, and I'll set you up with my repository.

 You MUST work with the XEmacs beta team to do it right.  The debian/*
 stuff ought to be right in the repository.  The `rules' there ought
 to be set up so that Red Hat and whoever else can use them also.
 (That is why I made it modular like it is...)

 Since the XEmacs Lisp stuff is all separated out now into packages
 (in their xemacs-packages CVS repository), it should be shipped as
 debian packages also.  There's a lot of work to do there.  XEmacs has
 its own package system setup, and so there are files with package
 data in the repository.  Those should be augmented with description
 and long description, etc., to facilitate their use in
 auto-generating debian/control snippets, etc.

 There is an offlist discussion that I was CC'd on about creating a
 package setup for Emacs/XEmacs lisp...  I suggested they start a
 mailing list for it.  I've not heard anything more.


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

Re: ITP enhydra

[Andreas Tille]

On Thu, 31 Aug 2000, Matt Zimmerman wrote:

> I intend to package Enhydra, an open source Java/XML application server
Fine!

Because I'm currently in the process of searching a reasonable content
management system.  Is there anybody who could draw a short comparison
between enhydra and zope aor may be any other such system.

Well, it's off-topic here, but may be there is some general interest...

Kind regards

   Andreas.


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

Re: Security of Debian SuX0r?

[Simon Richter]

On Thu, 31 Aug 2000, Joey Hess wrote:

>  Shadow passwords make your system more secure because nobody is able to
>  view even encrypted passwords. Passwords are stored in a separate file
>  that can only be read by special programs. We recommend the use of shadow
>  passwords. If you're going to use NIS you could run into trouble.

>  Shall I install shadow passwords?

> I'm very confused how someone can skim something like "'Shadow passwords
> make your system more secure'  'Shall I install shadow passwords?'",
> and then pick no if they want a secure box.

Yup, this question is senseless. If you happen to have encrypted passwords
in the passwd file, the shadow file is not looked at for these
accounts. So having shadow passwords will not break NIS.

   Simon

-- 
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


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

Re: Security of Debian SuX0r?

[Joey Hess]

Simon Richter wrote:
> Yup, this question is senseless. If you happen to have encrypted passwords
> in the passwd file, the shadow file is not looked at for these
> accounts. So having shadow passwords will not break NIS.

The question is about the default setting.

-- 
see shy jo


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

Re: gpm and X problem investigated

[Rainer Dorsch]

We discussed this previously (I think on debian-testing). The odd thing with 
the configuration is, that the user has to specify twice the mouse type 
(during gpm and during X setup). Even worse, if the user decides to use a PS/2 
instead of a serial mouse, he has to change it at several places. Thus to me 
it seemed to be a good idea to configure the real mouse at gpm setup and reuse 
the settings within X by this repeat feature.

The middle mouse button works flawless, if you select the Intellimouse 
protocol:

Section "Pointer"
Protocol"IntelliMouse"
Device  "/dev/gpmdata"
...


Rainer.
-- 
Rainer Dorsch
Abt. Rechnerarchitektur  e-mail:[EMAIL PROTECTED]
Uni StuttgartTel.: +49-711-7816-215 / Fax: +49-711-7816-288
Breitwiesenstr. 20-22D-70565 Stuttgart



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

Re: My recent bug's and continuing effort to debconf-ize Debian

[Colin Watson]

"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote:
>I started this afternoon submitting bugs against packages which print
>verbose output in their maintainer scripts.  The future that Debian
>must take is to fully support debconf.  To further this goal I will
>continue submitting patches to any package which prompts the user in a
>maintainer script.

Are you also reporting bugs against packages whose priority is higher
than that of debconf? Is the plan eventually to raise debconf's priority
to 'standard' or higher?

-- 
Colin Watson [EMAIL PROTECTED]


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

va.debian.org is down?

[Paul Slootman]

I can't ssh to it, and www.debian.org doesn't work either.


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]   http://www.isdn4linux.de/


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

Re: va.debian.org is down?

[Joey Hess]

Paul Slootman wrote:
> I can't ssh to it, and www.debian.org doesn't work either.

Yes, it's down. I'll reboot it as soon as I can tomorrow morning.

-- 
see shy jo


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

Re: Security of Debian SuX0r?

[Simon Richter]

On Thu, 31 Aug 2000, Joey Hess wrote:

> > Yup, this question is senseless. If you happen to have encrypted passwords
> > in the passwd file, the shadow file is not looked at for these
> > accounts. So having shadow passwords will not break NIS.

> The question is about the default setting.

Maybe, but I don't understand why the question is asked at all, since you
have absolutely no advantage by choosing the insecure variant.

   Simon

-- 
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


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

Re: Free Pine?

[Joseph Carter]

Richard,

I am comfortable speaking for the group at large when I say we appreciate
your advice and input on this matter.  I myself appreciate the ends you're
trying to accomplish here.  Nevertheless, the methods you're using to go
about this cause me to question whether or not your means justify your
ends.  This message exemplifies my concern, so I shall respond to it
directly rather than making vague half-accusations.


On Thu, Aug 31, 2000 at 02:46:40PM -0600, Richard Stallman wrote:
> I've an outstanding, unanswered question which I've sent to UW in a
> related context (IMAPD): what specific clause of the copyright is being
> violated, when modified versions are distributed.
> 
> Their position was that the words "permission to copy, distribute and
> modify" do not grant permission to distribute a modified version.  In
> other words, they say you can distribute the software, and you can
> modify the software, but you can't modify it and then distribute the
> result.

If memory serves me, I do indeed recall reading a message forwarded to
this effect.  The issue I am seeing rests with those words, which Debian
and indeed you yourself have accepted those words and at least half a
dozen variations of them as free software.  Someone at UW decided to tell
you that the license didn't say what it said.  Based on the language and
your interpretations of that language in all contexts not related to
software written by UW, I have to conclude that it is your belief that
regardless of their stated position, the license itself is free (if
perhaps not the clearest of wording...)



> I think that, until we get a decent answer, this should be the question
> asked by anyone who gets a threat under these conditions: ask what
> specific terms of the license are being violated.
> 
> You may never get an answer from the U of W, because right now the U
> of W can achieve its goals by saying nothing.  If they have the
> feeling that you will let the issue slide if they let it drop,
> they are likely to let it drop.

Actually, we did get an answer - from Lori (Lori's last name escapes my
memory, but it was the person who sent the message you forwarded) - saying
that what we are doing with imapd is not against its license and if it
turned out that it actually was, we were being given permission to do so.
Of course, if the latter were necessary, imapd would still be non-free
according to our guidelines.  The former appears to be the case in our
opinion, in Lori's, and from what I gather, yours in other contexts.


> However, you now do have an answer to that question, so I hope you can
> proceed to take the appropriate action, and remove IMAPD from Main.

Unless I missed something important (I have had some mail problems in the
past day or two) our answer was that imapd belongs in main.


> The message I forwarded you shows clearly that they treat IMAPD as
> non-free software, that their position is that people must ASK for
> permission to release a modified version, and that the license does
> not give permission.  That message does not give all the details.  It
> makes sense to want to know more about the situation, but it makes no
> sense to let the issue slide unless and until they give you a full
> explanation.  That is not the way to make the DFSG something that the
> users can rely on.
> 
> If Debian decides to reject IMAPD and tells the U of W so, that will
> put some pressure on them to clarify the license.  Otherwise they
> may prefer to leave it unclear in order to to "have it both ways".

And here we get into those means I do not feel justify the ends you're
after.  In order to force UW into the uncomfortable position of admitting
that what you wanted to do with pine is acceptable or telling Debian and
everyone else that UW imapd is non-free, you want Debian to take a
position you do not yourself agree with for purely political reasons.  And
that's what these are---political reasons.  There is no legal problem
here.  And there was no legal problem with pine 3.91 either, regardless of
what they said at the time.

I feel you are attempting to manipulate Debian into fighting a political
battle for you that may cost at least some of our users in the end.  Call
it taking a stand for freedom or whatever you like, but the software IS
free according to our best interpretations (and according to the
clarification we received from UW..)  I don't see an issue that Debian
needs to pursue here.  There are enough license battles for Debian to
fight as it is (I should know!) and we really don't need to look for
another one over software that everyone agrees is already free.


Trying to get someone to do something by trying to make it sound like what
you want is exactly what they want?  That sounds more like ESR's forté to
me what with all of his jedi-robed Tear Down the (Redmond-based) System
rhetoric and promises of dollar signs to anyone in a suit who pays homage
to a silly little penguin logo.  Freedom i

Re: gpm and X problem investigated

[mattyt]

> We discussed this previously (I think on debian-testing). The odd thing
> with 
> the configuration is, that the user has to specify twice the mouse type 
> (during gpm and during X setup). Even worse, if the user decides to use
> a PS/2 
> instead of a serial mouse, he has to change it at several places. Thus
> to me 
> it seemed to be a good idea to configure the real mouse at gpm setup and
> reuse 
> the settings within X by this repeat feature.
> 
> The middle mouse button works flawless, if you select the Intellimouse 
> protocol:
> 
> Section "Pointer"
> Protocol"IntelliMouse"
> Device  "/dev/gpmdata"

Curiously, everything was working for me just fine until my latest (woody) 
upgrade today.  This was both on my homebrew box and my ThinkPad 560, both with 
ps2.

I solved it by manually editing both the gpm.conf and XF86Config files.  Could 
be kind of a pain for the less experienced..

Cheers

Matthew Thompson   https://mattyt.net/webmail
[EMAIL PROTECTED]  http://www.oz.net/~mattyt
"Seriousness is the only refuge of the shallow."
--Oscar Wilde


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

Re: gpm and X problem investigated

[Mark Brown]

On Fri, Sep 01, 2000 at 08:58:24AM +0200, Rainer Dorsch wrote:

> The middle mouse button works flawless, if you select the Intellimouse 
> protocol:

Of course, it's rather non-obvious that you need to select anything
other than the protocol your physical mouse supports (or it was when I
tried a Potato install).

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/


pgpwyn7TBTOB2.pgp
Description: PGP signature

Re: ANNOUNCE: First official release of "apt-show-source"

[Robert Ramiega]

On Wed, Aug 30, 2000 at 05:11:52PM +0200, Dennis Schoen wrote:
> ANNOUNCE: First official release of "apt-show-source"
> 
> What is it?
> 
>  It's a perl script that parses the dpkg status file and that APT
>  list files that end with Sources, without any options it prints out all
>  installed packages and versions were a different version is available
>  through your sources-list. The generated output looks like:


 IMHO this script/package is very usefull for people working with/on Debian
on platforms different that intel (build daemons are sometimes lagged). It's
very tedious task to lookup if there is newer  version of Debian package
available in sources. 
 At least i find it very usefull (well right now i'm judging only on the
basis of this mail <>)


-- 
 Robert Ramiega  | [EMAIL PROTECTED]  IRC: _Jedi_ | Don't underestimate 
 UIN: 13201047   | http://www.plukwa.net/ | the power of Source


pgpDf9nRSLMXJ.pgp
Description: PGP signature

Re: Bug#70269: automatic build fails for potato

[Branden Robinson]

On Fri, Sep 01, 2000 at 12:04:23AM +1100, Hamish Moffatt wrote:
> On Tue, Aug 29, 2000 at 10:37:01PM -0500, Branden Robinson wrote:
> > Purists happen to be whoever disagrees with Hamish Moffat.  Cf. his
> > rhetoric here with his rhetoric in the great Social Contract amendment
> > flamewar.
> 
> Perhaps you should stick with your one liners, Branden. Your
> three-liners aren't much better, and take more effort to read.

I do apologize for distracting you from contemplating your own greatness.

> By the way, please watch your spelling.

If you'd proofread all my package descriptions for me I'd appreciate it.
Be sure to check them factual accuracy and ideological adherence to your
principles as well; after all, you would do me too much credit to think I
can do so effectively on my own.

-- 
G. Branden Robinson |
Debian GNU/Linux|"Bother," said Pooh, as he was
[EMAIL PROTECTED]  |assimilated by the Borg.
http://www.debian.org/~branden/ |


pgpQopWV5kORw.pgp
Description: PGP signature

Re: Free Pine?

[Branden Robinson]

On Thu, Aug 31, 2000 at 02:46:40PM -0600, Richard Stallman wrote:
> Their position was that the words "permission to copy, distribute and
> modify" do not grant permission to distribute a modified version.  In
> other words, they say you can distribute the software, and you can
> modify the software, but you can't modify it and then distribute the
> result.

Then it must also be true that one cannot copy and then distribute, or
distribute and then copy.  Have you attempted to challenge them on this
point?  Do they have English professors at UWash, or just semioticians?

(Sorry this mail is so short; I didn't have the time to waste yours with an
additional 1000 lines of babbling.)

-- 
G. Branden Robinson |Suffer before God and ye shall be
Debian GNU/Linux|redeemed.  God loves us, so He makes us
[EMAIL PROTECTED]  |suffer Christianity.
http://www.debian.org/~branden/ |-- Aaron Dunsmore


pgpz2bP33fVH2.pgp
Description: PGP signature

Re: imap mailbox killer

[Branden Robinson]

On Thu, Aug 31, 2000 at 10:35:40AM +0300, Juhapekka Tolvanen wrote:
> There might be bug in either Pine or IMAP(D) or both.

There is.  The license.  (See debian-legal.)

-- 
G. Branden Robinson |A committee is a life form with six or
Debian GNU/Linux|more legs and no brain.
[EMAIL PROTECTED]  |-- Robert Heinlein
http://www.debian.org/~branden/ |


pgpa5MGXJxBDM.pgp
Description: PGP signature

Re: Bug#70269: automatic build fails for potato

[Anand Kumria]

On Wed, Aug 30, 2000 at 10:10:27PM +0200, Wichert Akkerman wrote:
> Previously Richard Braakman wrote:
> > I don't know how the decision ended up being made, but the argument
> > I presented at the time is that a dependency on debhelper is far more
> > likely to be versioned than the others are.  A package that makes use
> > of a new feature of debhelper is going to have to declare its own
> > build-depends anyway.

Likewise a package that makes use of a particular feature of dpkg-dev.

But it is listed in the dependancy line of build-essential. What you are
saying is that rather than file bug reports on the (I assume) small set
of packages whic require a particular feature/verion of debhelper it
makes more sense to force everyone who uses it to declare a build-dependancy
upon it.

> Very much agreed, excellent point
> 
> Wichert (who has grown very tired of debhelper changes making building
> security fixes a painful job at times)

Presumably you also get just as tired when dpkg-dev changes happen but
the maintainer has not declared a version dependancy, yes?

Anand


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

Re: Bug#70269: automatic build fails for potato

[Anand Kumria]

On Thu, Aug 31, 2000 at 04:49:31PM +0200, Wichert Akkerman wrote:
> Previously Manoj Srivastava wrote:
> > I think that since every package using a helper package seems
> >  to need a versioned dependency, addign debhelper to build essential
> >  shall not remove the burden from the packages. And auto build daemons
> >  can also augment the build environment beyond build essential, as
> >  they already do. 
> 
> Right. In fact it makes things worse since people will just assume that
> their helper is already essential and they don't need to bother to
> to check if they need to specify a versioned dependency for it as well.

So file a bug. They can do exactly the same thing with dpkg-dev.

Anand


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

why can't mc open /dev/gpmctl?

[Ulf Jaenicke-Roessler]

Hi,

 found something like this in my logs for every start of mc:
 
Sep  1 12:13:48 pkfp20 mc: /dev/gpmctl: No such file or directory

 I wonder why. Maybe a bug in mc? In fact, /dev/gpmctl exists:

srwxrwxrwx1 root root0 Sep  1 12:16 gpmctl=

 The '=' is an indication of the file type (socket?).
 Furthermore, the strace lines look good (or not?):
 
...
socket(PF_UNIX, SOCK_STREAM, 0) = 10
connect(10, {sin_family=AF_UNIX, path="/dev/gpmctl"}, 13) = 0
write(10, "\376\377\1\0\0\0\0\0nI\0\0\1\0\0\0", 16) = 16
...

 Any idea what's wrong here?


 Thanks,

  Ulf


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

Re: why can't mc open /dev/gpmctl?

[Martijn van de Streek]

On Fri, 01 Sep 2000, Ulf Jaenicke-Roessler wrote:

> Sep  1 12:13:48 pkfp20 mc: /dev/gpmctl: No such file or directory
> 
>  I wonder why. Maybe a bug in mc? In fact, /dev/gpmctl exists:

I got these too, with both mc and links. I guess it's a libgpm0-bug.
Installing (and running) gpm fixed it for me (gpm can't listen() on
it's AF_UNIX socket when it's not installed/running :).

Martijn
-- 
You can go anywhere you want if you look serious and carry a clipboard.


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

Re: Bug#70269: automatic build fails for potato

[Anthony Towns]

On Fri, Sep 01, 2000 at 04:35:53AM -0500, Branden Robinson wrote:
> On Fri, Sep 01, 2000 at 12:04:23AM +1100, Hamish Moffatt wrote:
> > On Tue, Aug 29, 2000 at 10:37:01PM -0500, Branden Robinson wrote:
> > > Purists happen to be whoever disagrees with Hamish Moffat.  Cf. his
> > > rhetoric here with his rhetoric in the great Social Contract amendment
> > > flamewar.
> > Perhaps you should stick with your one liners, Branden. Your
> > three-liners aren't much better, and take more effort to read.
> I do apologize for distracting you from contemplating your own greatness.

Would you two just get a room already?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark


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

Re: why can't mc open /dev/gpmctl?

[Ulf Jaenicke-Roessler]

On Fri, 1 Sep 2000, Martijn van de Streek wrote:

> > Sep  1 12:13:48 pkfp20 mc: /dev/gpmctl: No such file or directory
> > 
> >  I wonder why. Maybe a bug in mc? In fact, /dev/gpmctl exists:
> 
> I got these too, with both mc and links. I guess it's a libgpm0-bug.
> Installing (and running) gpm fixed it for me (gpm can't listen() on
> it's AF_UNIX socket when it's not installed/running :).

I have gpm, and it runs as a daemon. I thought that /dev/gpmctl would
not exist if gpm doesn't run. But it is there, although mc insists
it isn't. Strange.

  Ulf



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

Re: My recent bug's and continuing effort to debconf-ize Debian

[Julian Gilbey]

On Thu, Aug 31, 2000 at 04:59:27PM -0700, Joey Hess wrote:
> Julian Gilbey wrote:
> > A thread came up here a little while back about installation scripts
> > sometimes not being able to use debconf for security or other
> > reasons.
> 
> That's not particularly accurate. 

Sorry ;-)

> > So what about introducing a dpkg-postconfigure program which runs
> > package.postconfig files after any dpkg run has finished, in an
> > analagous way to dpkg-preconfigure.  Only this time, it will be only
> > for things that *must* wait till post-installation, and cannot use
> > debconf for whatever reason.  There shouldn't be that many of these,
> > but it would probably be a good idea to introduce this soon as we move
> > to non-interactive installs.
> 
> This is not necessary, it is perfectly possible to prompt for passwords
> or anything else in the postinst, using debconf, if you feel that is
> necessary for security reasons or whatever other reason.

But then it might interrupt the installation process.  Just as debconf
asks all of the preinst questions before any of the packages have
started unpacking, it would be nice to be able to defer any questions
that *have* to wait for the postinst until the very end, when all of
the packages have been installed.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/


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

Re: Where's the prc-tools package?

[Michael Beattie]

On Thu, Aug 31, 2000 at 10:38:25AM -0400, Brian Almeida wrote:
> 
> dinstall has a bug where if it gets uploaded to frozen it gets removed from 
> unstable...  Someone just needs to re-uploaded a recompiled version for woody.
> 

I *really* should get around to reviewing that patch I did, and apply it.

-- 

   Michael Beattie ([EMAIL PROTECTED])

 -
  WinErr: 005 Multitasking attempted - System confused
 -
Debian GNU/Linux  Ooohh You are missing out!



pgpC11wtQCOUD.pgp
Description: PGP signature

Re: Free Pine? Fsck Pine!

[Sven Guckes]

* Richard Stallman <[EMAIL PROTECTED]> [000831 20:47]:
> If Debian decides to reject IMAPD and tells the U of W so,
> that will put some pressure on them to clarify the license.
> Otherwise they may prefer to leave it
> unclear in order to to "have it both ways".

I don't see why Debian (or GNU, or "Linux")
bothers with the IMAPD of UofW so much at all.
Aren't there quite some replacements by now?

Sure, "pine" has become a popular mailer -
but it still is not capable of threading.
But the IMAPD fgives us the nice "internal
message - dont delete", and "pico" cannot
be downlaoded and installed by itself.
Sheesh.

I hope that mutt will ship with some tools soon
(eg a nice frontend for managing aliases) and
then the admins can set it up for the users
together with "nano" replacing pico.

And we'll kiss pine and its IMAPD goodbye.
RIP, UofW!

Sven

PS:  Non-MailList Addresses BCCed..

-- 
Sven [EMAIL PROTECTED]  - RTF FAQ at http://www.washington.edu/pine/
PINE http://socha.net/pine-tips.html - Read Robin's Tips!
PINE http://www.math.washington.edu/~chappa/pine - Chappa's Patches!
PINE http://www.math.fu-berlin.de/~guckes/pine/  - More info.


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

Re: Bug#70269: automatic build fails for potato

[Wichert Akkerman]

Previously Anand Kumria wrote:
> So file a bug. They can do exactly the same thing with dpkg-dev.

dpkg-dev is an extremely stable interface, something you can not
say for debhelper.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpF3GLi25I07.pgp
Description: PGP signature

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 31-Aug-00, 12:43 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote: 
> On Thu, Aug 31, 2000 at 08:29:30PM +0300, Antti-Juhani Kaijanaho wrote:
> > > > Which is just a stupid pain in the ass. I had to track through three
> > > > different references and finally install the "build-depends" package to
> > > > find out what I could leave out of by "Build-Depends" stanza. It would
> > > > *much* easier for developers, if less ideologically pure, to just list
> > > > the damn packages on the Developers Corner part of the website.
> > > 
> > > Could we add this as a footnote to the relevant section in policy or
> > > the packaging manual (can't remember which offhand)?
> > 
> > Um, the current note in policy manual is not sufficient?  (It explicitly
> > mentions the package "build-essential".)
> 
> I guess.  Maybe he didn't look in the right place ;-)


That would be cute if "the right place" wasn't so fucking hard to
find. The policy manual says look in build-essential. The control
file for Build-essential says look in policy manual, and includes two
different list files, one of which is completely pointless, the other of
which has the needed info buried in the middle of a bunch of definitions
and syntax. This is all needless run-around. Just put the list on the
website, and in the policy manual as a footnote. I *understand* that the
list is not the "official definition". Feel free to post the official
definition, and the say "the current list x, y, and z. But stop making
people spend 15 minutes hunting for information that should be listed
everywhere that that "build-depends" is mentioned.


Why are people determined to make information so hard to find?

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


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

Re: Machine-specific optimizations

[Arthur Korn]

Hello.

Alisdair McDiarmid schrieb:
> On Thu, Aug 31, 2000 at 01:49:13PM -0700, Sean 'Shaleh' Perry wrote:

> > you always have the option of using 'apt-get source' to recompile a package,
> > then place it on hold and we wont touch it.
> 
> I've tried doing this occasionally -- more often to change a
> compile-time feature than optimise for CPU -- and it's not very
> convenient. I mean, the apt-get source couldn't be easier, but unless
> I put the package on hold, apt `upgrades' to the *same* version on
> the very next apt-get upgrade.

Is there a convenient way to put a package on hold? I couldn't
figure anything out form the dpkg and apt-get manpages. If I
have to start dselect every time I want to put something on hold
this is certainly not how it should be. (Ever used dselect on a
9600 serial console? It's fun ;).

ciao, 2ri
-- 
"Siddhartha tut nichts, er wartet, er denkt, er fastet, aber er geht durch die
Dinge der Welt hindurch wie der Stein durchs Wasser, ohne etwas zu tun, ohne
sich zu rühren; er wird gezogen, er lässt sich fallen. [...] Es ist das, was die
Toren Zauber nennen und wovon sie meinen, es werde durch die Dämonen bewirkt."
-- Hermann Hesse, "Siddhartha"


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

Re: Free Pine?

[Raul Miller]

> I've an outstanding, unanswered question which I've sent to UW in a
> related context (IMAPD): what specific clause of the copyright is being
> violated, when modified versions are distributed.

On Thu, Aug 31, 2000 at 02:46:40PM -0600, Richard Stallman wrote:
> Their position was that the words "permission to copy, distribute and
> modify" do not grant permission to distribute a modified version.  In
> other words, they say you can distribute the software, and you can
> modify the software, but you can't modify it and then distribute the
> result.

I don't see anything in that language which indicates that special
permission is required to modify and distribute the software.

Anyways, Lori said she's busy this week, but would try to have an
answer for me next week.

-- 
Raul


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

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 31-Aug-00, 16:52 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote: 
> I think that you start with a particular version dependency, and then
> only update the dependency if you use new features not present in
> older helper packages.

This can be tricky, as it is easy to use a new feature without
realizing it, unless one digs through the changelog everytime one edits
debian/rules. Arguably, though, that's a reasonable cost for using the
helper package, so I'll concede.

>   Actually, I do have versioned dependencies on dpkg-dev, and
>  the process works as I outlined above -- older version of dpkg-dev
>  broke for my packages, and I created a versioned dependency -- and
>  have never had to change that, really. 

That's fine -- if there is a need for the dependency, add it. But
forcing many developers to add a build-depends line solely in order to
specify "debhelper" seems unnecessary.


>   Well, I think that these customers are so few, and need to be
>  quite competent, often have to have a list of packages that goes
>  beyon just the build essentials. We should not need a policy and a
>  package for just these consumers. 

The whole Build-Depends stuff originated from the need of the large
scale auto-builders and architecture porters to be able to reliably
build packages.

>   Our differences seem to stem from this basic difference in
>  opinion: whom is the build essentials package primarily for?  And my
>  take is that the primary consumers are the developers of the 5000+
>  packages, and additionally, a few buld daemons, most of whom need a
>  core set that may not be reflected in build essentials. Your opinion,
>  obviously, differs.

I think I miswrote earlier: I wrote "build-essentials" when I should
have written "Build-Depends". And I'd wager that the vast majority
of the Debian developers have no need at all for Build-Depends. The
"build-essentials" list *is* needed to prevent them from going crazy
*supporting* Build-Depends. But that's the only reason build-essentials
exists -- without Build-Depends, there's no need. And if the
auto-builder core set is not represented buy build-essentials, then I
think there's something wrong.

Note that I'm *not* saying Build-Depends is a bad thing: the porters do
a incredible job, and anything that makes their lives easier is worth
doing. But we ought to also minimize the cost to the other developers.

Steve
-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


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

Re: Free Pine? Fsck Pine!

[Jaldhar H. Vyas]

On Fri, 1 Sep 2000, Sven Guckes wrote:

> 
> I don't see why Debian (or GNU, or "Linux")
> bothers with the IMAPD of UofW so much at all.
> Aren't there quite some replacements by now?
> 

Nope. Not that are free software and/or full-featured.  Yet we're up to
our armpits in crappy POP3 servers with more coming out all the time.  I
wonder why no one cares about IMAP?

> Sure, "pine" has become a popular mailer -
> but it still is not capable of threading.
> But the IMAPD fgives us the nice "internal
> message - dont delete", and "pico" cannot
> be downlaoded and installed by itself.
> Sheesh.
> 

Btw, IMAP 2000 (currently at release candidate 5) finally gets rid of the
pseudo-message.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>




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

Re: Free Pine? Fsck Pine!

[Raul Miller]

On Fri, Sep 01, 2000 at 03:39:05PM +0200, Sven Guckes wrote:
> I don't see why Debian (or GNU, or "Linux") bothers with the IMAPD of
> UofW so much at all. Aren't there quite some replacements by now?

[1] The copyright appears to meet our standards (DFSG).

[2] The only alternative imap daemon doesn't support mail stored in
mbox format.  [Which makes a certain amount of sense, considering the
reliability issues associated with mbox, but still...]

We might indeed drop all UW software -- either because we decide that
we want better relations with their developers (though that seems a bit
self-contradictory), or because we decide it's too much of a headache.
But that's a decision for the individual package maintainers.

Also, note that I'm waiting for some clarification from UW on this
"copyright issue".

-- 
Raul


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

Re: Machine-specific optimizations

[Robert D. Hilliard]

Arthur Korn <[EMAIL PROTECTED]> writes:

> Is there a convenient way to put a package on hold? I couldn't


 Craig Sanders <[EMAIL PROTECTED]> included the following in a
message dated Tue, 4 Apr 2000 10:43:53 +1000:

>  #! /bin/bash
>  
>  # dpkg-hold  --  command line tool to flag package(s) as held.
>  #
>  # by Craig Sanders, 1998-10-26.  This script is hereby placed into the 
>  # public domain.
>  #
>  # BUGS: this script has absolutely no error checking.  this is not good.
>  
>  if [ -z "$*" ] ; then
>  echo "Usage:"
>  echo "  dpkg-hold "
>  exit 1
>  fi
>  
>  for i in $@ ; do
>  echo "$ihold"
>  done | dpkg --set-selections
  
 Despite the disclaimer about error checking, I have had good
results with it.  I have also reversed it to make dpkg-unhold.

Bob
-- 
   _
  |_)  _  |_   Robert D. Hilliard  <[EMAIL PROTECTED]>
  |_) (_) |_)  1294 S.W. Seagull Way   <[EMAIL PROTECTED]>
   Palm City, FL  USA   PGP Key ID: A8E40EB9


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

Re: Bug#70269: automatic build fails for potato

[Jaldhar H. Vyas]

On Fri, 1 Sep 2000, Steve Greenland wrote:

[...]

> I think I miswrote earlier: I wrote "build-essentials" when I should
> have written "Build-Depends". And I'd wager that the vast majority
> of the Debian developers have no need at all for Build-Depends.

What about for users who want to rebuild the package for whatever
reasons?  Many times you get half way through some huge package and it
craps out because you didn't have some esoteric header file or
library.  Build-depends is invluable for avoiding those kinds of
annoyances.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>


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

RFC/ITP: everybuddy-cvs

[michael d. ivey]

I started making personal debs of the everybuddy CVS snapshots because EB
releases tend to lag pretty far behind the code in CVS.  I called my
package ebsnap, and made it conflict with everybuddy.  I put it on my
site, and that was that.

Now, I've adopted everybuddy and gotten through the NM process.  I'd like
to add the CVS version to unstable...but I don't know what to call it.
My current idea is everybuddy-cvs, and make it conflict with everybuddy,
and conflict/replace ebsnap, for the people who may have downloaded
ebsnap.  Is that the correct way to proceed?

I'll be doing the rename and the upload sometime early next week.

-- 
michael d. ivey[McQ] : "Yo ho, it's hot, the sun is not a place
   <[EMAIL PROTECTED]> : where we could live."
http://gweezlebur.com/~ivey/ :  -- TMBG
 encrypted email preferred   :


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

Re: RFC/ITP: everybuddy-cvs

[Peter Makholm]

"michael d. ivey" <[EMAIL PROTECTED]> writes:

> My current idea is everybuddy-cvs, and make it conflict with everybuddy,
> and conflict/replace ebsnap, for the people who may have downloaded
> ebsnap.  Is that the correct way to proceed?

People using unofficial packages should be aware about the
dificulties. So I wouldn't mention the unofficial packages in control
files for official Debian packages.

I also don't like the idea of having special packages for cvs-versions
of software. It is cruft.

Just my 0.02 of whatever currency you prefere.

-- 
Peter


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

Re: RFC/ITP: everybuddy-cvs

[michael d. ivey]

On Fri, Sep 01, 2000 at 06:24:55PM +0200, Peter Makholm wrote:
> People using unofficial packages should be aware about the
> dificulties. So I wouldn't mention the unofficial packages in control
> files for official Debian packages.

OK.  I'll mention it on the website for the unofficial ones.

> I also don't like the idea of having special packages for cvs-versions
> of software. It is cruft.

In this case, the CVS version is usually pretty far ahead of released, and
is just as stable.  Do you think I should switch the main package to using
CVS code?  Or just continue to do my unofficial CVS packages and have the
official ones be the released version?  I know the EB authors would prefer
that we not switch to CVS code, so I think that's a bad idea...but on the
other hand, the CVS code would be a "better" package for some debian
users.

-- 
michael d. ivey[McQ] : "It is a miracle that curiosity survives
   <[EMAIL PROTECTED]> : formal education."
http://gweezlebur.com/~ivey/ :   -- Albert Einstein
 encrypted email preferred   :


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

Re: RFC/ITP: everybuddy-cvs

[Ben Collins]

On Fri, Sep 01, 2000 at 04:06:33PM +, michael d. ivey wrote:
> I started making personal debs of the everybuddy CVS snapshots because EB
> releases tend to lag pretty far behind the code in CVS.  I called my
> package ebsnap, and made it conflict with everybuddy.  I put it on my
> site, and that was that.
> 
> Now, I've adopted everybuddy and gotten through the NM process.  I'd like
> to add the CVS version to unstable...but I don't know what to call it.
> My current idea is everybuddy-cvs, and make it conflict with everybuddy,
> and conflict/replace ebsnap, for the people who may have downloaded
> ebsnap.  Is that the correct way to proceed?
> 
> I'll be doing the rename and the upload sometime early next week.

Keep it the same name. Woody is unstable right now, there are a lot of
packages that are pre-release just for the sake of testing and working out
bugs. So, IMO, keep it the same name, and version it appropriately. Also
might add "This is a CVS build" at the bottom of the description.

Note, you can't break much anyway. I'm about ready to upload glibc 2.1.93
(pre-2.2) to woody anyway, so if anything is going to break, it's most
likely going to be my fault :)

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


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

Re: gpm and X problem investigated

[Adrian Bridgett]

On Fri, Sep  1, 2000 at 00:22:23 +0200 (+), J.A. Bezemer wrote:
> a. Let gpm default to repeating in raw mode (to solve 6.), and add a very
>clear notice that X should be (re)configured with /dev/gpmdata but using
>the real protocol -- but when gpm is either stopped or removed/purged, that
>the X config should be changed again (!! I don't know any package that
>requires _another_ package to be _manually_ reconfigured on install/
>remove).
> 
> b. Let gpm default to not repeating at all, without needing any further
>documentation (AFAIK; I don't remember questions on gpm <-> X behaviour
>in slink).

Raw mode just repeats what's coming in?

How about  "ln -s mouse /dev/gpmdata" on removal and
recreating a device on install. Watching the upgrades of course.

Just an idea - don't shoot me, yet.

Adrian

Email: [EMAIL PROTECTED]
Windows NT - Unix in beta-testing. GPG/PGP keys available on public key servers
Debian GNU/Linux  -*-  By professionals for professionals  -*-  www.debian.org


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

Re: Help

[tony mancill]

On Tue, 29 Aug 2000, Hamish Moffatt wrote:

> On Mon, Aug 28, 2000 at 03:18:26PM +, Dale Scheetz wrote:
> > I checked and all the permissions are like they are supposed to be. (BTW,
> > what is the "t" in the permission string "drwxrwxrwt" anyway?)
> 
> 't' is the sticky bit. On a directory, it means a user can only delete
> their own files, despite having write access to the entire directory.

Just a point of clarification - if the user owns the directory where the
sticky bit is set, then the user can delete anybody's files, regardless of
the sticky bit.

If the user doesn't own the directory where the sticky bit is set then
Hamish's statement is correct (and quite useful!), even if that user does
have write permission to the directory.

  [EMAIL PROTECTED] |  I am a concientious man. 
http://www.debian.org  |  When I throw rocks at seabirds,
   |  I leave no tern unstoned.  (Ogden Nash)


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

Re: Free Pine?

[Adam McKenna]

On Fri, Sep 01, 2000 at 11:57:50AM -0400, Raul Miller wrote:
> > I've an outstanding, unanswered question which I've sent to UW in a
> > related context (IMAPD): what specific clause of the copyright is being
> > violated, when modified versions are distributed.
> 
> On Thu, Aug 31, 2000 at 02:46:40PM -0600, Richard Stallman wrote:
> > Their position was that the words "permission to copy, distribute and
> > modify" do not grant permission to distribute a modified version.  In
> > other words, they say you can distribute the software, and you can
> > modify the software, but you can't modify it and then distribute the
> > result.
> 
> I don't see anything in that language which indicates that special
> permission is required to modify and distribute the software.

I believe DFSG/OSD say that the license must *explicitly* allow distribution 
of modified binaries.

--Adam


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

Re: Free Pine?

[Steve Greenland]

On 01-Sep-00, 02:50 (CDT), Joseph Carter <[EMAIL PROTECTED]> wrote: 
> 
> Actually, we did get an answer - from Lori (Lori's last name escapes my
> memory, but it was the person who sent the message you forwarded) - saying
> that what we are doing with imapd is not against its license and if it
> turned out that it actually was, we were being given permission to do so.
> Of course, if the latter were necessary, imapd would still be non-free
> according to our guidelines.  The former appears to be the case in our
> opinion, in Lori's, and from what I gather, yours in other contexts.

I disagree with your last sentence; here's what Lori wrote:

> UW's intent has always been to allow others to modify the UW IMAPD
> for their own needs, or to redistribute the original version,
> without having to ask for permission.  We do expect and appreciate
> folks to ask before re-distributing derivative works, but obtaining
> permission is not onerous. Many have asked and they've all received
> permission. We are happy and willing to work with Debian so that
> Debian may continue to distribute UW's IMAPD.
>
> First of all, by this message you have our permission to distribute a
> modified version of IMAPD.

That to me says Debian has permission to re-distribute our modified
version, but that people who recieve it from us do not, unless they too
ask permission ("We do expect and appreciate..."). Non-free. If she had
written just "We appreciate..." I'd be comfortable putting it in free.

Steve



-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


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

Re: My recent bug's and continuing effort to debconf-ize Debian

[Sean 'Shaleh' Perry]

On 01-Sep-2000 Colin Watson wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote:
>>I started this afternoon submitting bugs against packages which print
>>verbose output in their maintainer scripts.  The future that Debian
>>must take is to fully support debconf.  To further this goal I will
>>continue submitting patches to any package which prompts the user in a
>>maintainer script.
> 
> Are you also reporting bugs against packages whose priority is higher
> than that of debconf? Is the plan eventually to raise debconf's priority
> to 'standard' or higher?
> 

currently, any package which uses debconf depends on it.  Since most packages
need it in their postinst, this is perfectly reasonable. Once debconf gains
majority usage, I suspect joey will have it moved up.


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

Re: My recent bug's and continuing effort to debconf-ize Debian

[Sean 'Shaleh' Perry]

> 
> But then it might interrupt the installation process.  Just as debconf
> asks all of the preinst questions before any of the packages have
> started unpacking, it would be nice to be able to defer any questions
> that *have* to wait for the postinst until the very end, when all of
> the packages have been installed.
> 

a) choose non-interactive and no debconf questions get asked.  You can
dpkg-reconfigure any package you need to
b) supply debconf with the answers ahead of time
c) *eventually* there will be a debconf server(right word?) which network
admins can install.  This will have the answers stored in it and then when
boxes need to know an asnwer, they query debconf and it queries the server.
This way, you can do unattended installs of an entire computer lab.


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

Re: RFC/ITP: everybuddy-cvs

[Ben Pfaff]

"michael d. ivey" <[EMAIL PROTECTED]> writes:

> I started making personal debs of the everybuddy CVS snapshots because EB
> releases tend to lag pretty far behind the code in CVS.  I called my
> package ebsnap, and made it conflict with everybuddy.  I put it on my
> site, and that was that.
> 
> Now, I've adopted everybuddy and gotten through the NM process.  I'd like
> to add the CVS version to unstable...but I don't know what to call it.
> My current idea is everybuddy-cvs, and make it conflict with everybuddy,
> and conflict/replace ebsnap, for the people who may have downloaded
> ebsnap.  Is that the correct way to proceed?

I would keep the same name for both the released and CVS
versions, but upload the released version to unstable and the CVS
version to project/experimental.


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

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 01-Sep-00, 12:10 (CDT), "Jaldhar H. Vyas" <[EMAIL PROTECTED]> wrote: 
> On Fri, 1 Sep 2000, Steve Greenland wrote:
> > I think I miswrote earlier: I wrote "build-essentials" when I should
> > have written "Build-Depends". And I'd wager that the vast majority
> > of the Debian developers have no need at all for Build-Depends.
> 
> What about for users who want to rebuild the package for whatever
> reasons?  Many times you get half way through some huge package and it
> craps out because you didn't have some esoteric header file or
> library.  Build-depends is invluable for avoiding those kinds of
> annoyances.

Those people would be equally well served by a note or check at the
beginning of the debian/rules file; we didn't need policy and a new
control file headers for that.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


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

Re: Bug#70269: automatic build fails for potato

[Jaldhar H. Vyas]

On Fri, 1 Sep 2000, Steve Greenland wrote:

> Those people would be equally well served by a note or check at the
> beginning of the debian/rules file; we didn't need policy and a new
> control file headers for that.
> 

Alright.  What if apt-get source was enhanced so it would pull down any
packages needed to build?  If you didn't have build-depends where would it
get that information from?

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>


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

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 01-Sep-00, 15:04 (CDT), "Jaldhar H. Vyas" <[EMAIL PROTECTED]> wrote: 
> On Fri, 1 Sep 2000, Steve Greenland wrote:
> 
> > Those people would be equally well served by a note or check at the
> > beginning of the debian/rules file; we didn't need policy and a new
> > control file headers for that.
> > 
> 
> Alright.  What if apt-get source was enhanced so it would pull down any
> packages needed to build?  If you didn't have build-depends where would it
> get that information from?

I didn't say that individual users couldn't benefit from Build-Depends,
only that it isn't *necessary*. Once you've implemented it, yeah,
enhancing other tools to support it makes good sense. But I don't
think it would have been worth doing except (primarily) to support the
porters/auto-builders. They (or at least some of them, I forget the
details) were trying to maintain similar info in a central repository,
which was a pain when the requirements of package changed. Requiring the
individual maintainers to track this makes sense.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


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

Strange rsync issue

[Aigars Mahinovs]

Hi all,

A starnge thing happened while I was rsyncing Debian
binary-i386-1_NONUS.iso from ceu.fi.udc.es .
At first I made a pseudo-image, then I rsynced it using this:

rsync --verbose --progress --stats --block-size=8192 
ceu.fi.udc.es::debian-cd/potato/current-iso-images/binary-i386-1_NONUS.iso .

This took more than 12 hours and the progress indicator never came over 2% done.
Then I checked md5sum using this:

md5sum -b binary-i386-1_NONUS.iso

The md5sum differed from that one that appeared in MD5SUMS file.
That's why I tryed rsyncing again using this: 
(I'm not sure about this as I typed it 'over the phone')

rsync --verbose --progress --stats --block-size=131072 
ceu.fi.udc.es::debian-cd/potato/current-iso-images/binary-i386-1_NONUS.iso .

(The directory didn't change)
MD5SUMing other two iso was succesfull after first rsync.
But this last rsync command is running for > 30 hours as for now and 
the progress indicator is showing 14% .

Can someone please tell me what could be the bottleneck and why the second
rsync took longer that the first one.

Are there any 2.2r0 binary-i386-1_NONUS.iso 's in Latvia (.lv)?

-- 
Mail You Later!

Aigarius
[EMAIL PROTECTED]

---
Origin: Not enough hard drive space... please delete windows. PLEASE!!!
---


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

Re: Strange rsync issue

[Mattias Wadenstein]

On Fri, 1 Sep 2000, Aigars Mahinovs wrote:

[snip, commands seem correct]
> This took more than 12 hours and the progress indicator never came
> over 2% done.

> Can someone please tell me what could be the bottleneck and why the second
> rsync took longer that the first one.

If you never got to the full 100% (or perhaps 99%), it is a good
posibility that you never synced the entire image.

I don't know why this would happen, but at least the versions of rsync I
have run have been sensitive to network problems. We had big problems with
the connectivity from here to cdimage.debian.org right after the release
of 2.2, and it is possible for the rsync to get fatal errors and not sync
the entire image.

> Are there any 2.2r0 binary-i386-1_NONUS.iso 's in Latvia (.lv)?

Well, ftp.se.debian.org is 15 hops away (30-40 ms roundtrip time), and I
don't see any network bottleneck on "this" side of lattelekom.lv. You
could try our mirror. The md5sums should be checked on the server at
least.

/Mattias Wadenstein


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

Re: multiple dependancies on the same package?

[Wichert Akkerman]

Previously Richard A Nelson wrote:
> Would the following work as expected:
> Depends: sendmail (>= 8.9.3), sendmail (<< 8.9.4)

Yes.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


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

Re: My recent bug's and continuing effort to debconf-ize Debian

[Joey Hess]

Sean 'Shaleh' Perry wrote:
> > Are you also reporting bugs against packages whose priority is higher
> > than that of debconf? Is the plan eventually to raise debconf's priority
> > to 'standard' or higher?
> > 
> 
> currently, any package which uses debconf depends on it.  Since most packages
> need it in their postinst, this is perfectly reasonable. Once debconf gains
> majority usage, I suspect joey will have it moved up.

Debconf is already in standard. Three packages of > standard priority
use debconf (console-tools, console-data, setserial). All are priority
required.

All three of them are set up so they will work without debconf, and only
suggest or recommend it.

We could continue this trend, though I suspect writing a package to work
that way is rather annoying.

-- 
see shy jo


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

Map on debian website - bug in apache?

[Miquel van Smoorenburg]

On http://www.nl.debian.org/devel/developers.loc , there's supposed
to be a jpeg of a world map with debian developers. On the main
website, www.debian.org, there is.

It seems that the .nl webserver is interpreting the filename
"developers.map.jpeg" as a .map image-map file according to this error:

[Fri Sep  1 22:35:18 2000] [error] [client 195.64.66.217] map file 
/devel/developers.map.jpeg, line 1 syntax error: requires at least two fields

I do have this in srm.conf:

# If you wish to use server-parsed imagemap files, use
AddHandler imap-file map

Is that a (known) bug in Apache ? (apache_1.3.9-10)

Mike.


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