Re: Linuxconf

[Philip Hands]

"matthew.r.pavlovich.1" <[EMAIL PROTECTED]> wrote:
> what is the current status of linuxconf and debian?

I made a package up, which is currently in experimental because it breaks 
booting, and doesn't understand includes in /etc/named, among other things.

If people would like to have a look at it, with an eye to working out how 
we're going to get it to sit alongside all our normal stuff, I'd appreciate 
suggestions.

The problem is that it is too all encompassing, and wants to be in charge of 
things that it has no rights over on a Debian system.  For it to work well in 
a debian environment, much of it needs to be split into separate modules 
which depend upon the thing they configure.

For example, by default it assumes that you are running sendmail, and tries
to make sure that files that should be present if sendmail were installed,
are present and set to the right permissions.

I've disabled (some of) this in the Debian package, but really it needs to
be put in a linuxconf- sub-package.

There's loads of this sort of thing, and it's a little difficult to work out 
where to start, especially when it's not entirely clear what the original 
intent was, not being a RedHat user.

I could do with someone who knows how the RedHat init scripts work to tell
me what the original intent behind some of the boot menu setup is, so that
we can look at translating it into something worthwhile under debian.

Anyone that's interested, and has a machine they don't mind trashing just a 
little, feel free to grab a copy and see if you can work out what we need to 
do with it.

Remember though, there's a reason its in project/experimental.

Cheers, Phil.

Re: Removing Packages in Slink for Debian 2.1

[Marcus Brinkmann]

Hello,

On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:
> strace26065  strace confused about sigaction flags [51]  (Wichert 
> Akkerman <[EMAIL PROTECTED]>)

Hmm. Why is this bug important anyway? I've looked at the bug report and
found no explanation.

I think strace is too useful for debugging and should not be removed.
Imagine later bug reports, where the developers wants the user to run
strace. And then try to explain them why strace is not included in the
Debian distribution.

Looking at the bug report, I see no reason why strace should be
undistributable. It works okay in many situations and does not break the
system.

Unless Raul or someone else can provide some rationale for the importance of
the bug, I vote for downgrading it to severity normal.

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[James Troup]

Joey Hess <[EMAIL PROTECTED]> writes:

> James Troup wrote:
> > They don't compile from freshly unpacked source.
> 
> How odd. Other maintainer must work substantially differently than I, then.

If you're building foobar 1.1-3, do you really recompile from a
freshly unpacked foobar_1.1-3.dsc?

> > Another thing is that i386 maintainers _won't_ notice is two of our
> > most common problems: YAFHIC386 in debian/control's Architecture and
> > debian/files not being removed during debian/rules clean.
> 
> I can see the first, but I've certianly ran into the second before I
> modified debhelper to delete debian/files.

debian/files being present in freshly unpacked source is rarely a
problem on i386; it's *always* a problem on non-i386.

[ ... ]
 
> Why does a binary-only NMU give you the right to skip waiting, while
> a normal NMU does not? Why are they different?

Because I'm not forcing my changes on anyone but the architecture I'm
uploading for.  If I'm wrong in some drastic way, only m68k suffers.

You're also forgetting the vast majority of our fixes fall into two
categories:

1) Fixing lame packaging bugs.
2) Portability fixes.

In both cases it's hard for a maintainer to turn round and say, "No,
your fix is wrong, I wanted the package to be unbuildable from source"
or "No, get some real hardware, I don't want this package to be
portable", or "No, that's not the right fix for $ARCH, you should do
this instead".

> Binary-only and normal NMU's are the same thing,

No they're not.  Why do you insist on this obvious falsehood?

[ ... ]

> Do you want the ports to remain forever second class citizens, or do you
> want them to eventually mature to be equal with i386?

Will you please get off your high horse and stop being so incredibly
condescending?  It doesn't help in anyway whatsoever and without some
facts to back up your anti-non-i386 rants, it's really rather
pointless.  What exactly makes us second class citizens (your wishes
aside)?

> > All ports needs to make a lot of changes because so many source
> > packages are broken.  It's got little or nothing to do with the
> > newness of the port (if you look at the {binary-,}NMU's and bug
> > reports, they aren't predominantly from the new ports, but rather the
> > older ones (m68k && alpha)).
> 
> Broken source package has nothing to do with a port at all.

Of course they bloody do; we have to build them.  And the breakage I'm
talking about, is the sort of breakage which doesn't show up for 99.5%
of i386/source maintainers.

> > Eh?  Define ``standard'', please?  I rather hope you don't mean "what
> > i386 uses".
> 
> I mean that we should converge on using the same build environment and build
> mechanisms (and NMU mechanisms) for all architectures, and until we do, the
> ports are going to remain second class citizens.

Ehm, so all the architectures using glibc 2.1 are second class
citizens?  If I didn't know better, I'd think you were just using this
issue as an excuse to vent some anti-non-i386 feelings you seem to
have.

-- 
James

Re: Intend to package, create OSS/Free

[Hamish Moffatt]

On Wed, Oct 14, 1998 at 05:09:54PM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
> 
>  >> /usr/src/modules//, and runs ./debian/rules . 
>  >> Additionally, the following information is provided in the
>  >> environment:
>  >> a) KVERS  Contains the kernel version
>  >> b) KSRC   Contains the location of the kernel sources 
>  >> c) KMAINT Contains the Name of the maintainer to pass to PGP
>  >> d) KEMAIL Caontains the email address of the maintainer
> 
>  Hamish> How is the package version number passed?
> 
>What package are you talking about here? 

I assume KVERS contains only the kernel version, eg 2.0.35.
make-kpkg modules_image allows you to specify a revision, which pcmcia
for example uses as part of the file .deb's version number. How
is the revision number passed?

>  Hamish> Also, I'm terrible with make. Is there an easy way to test that
>  Hamish> the four variables above have been provided and abort if not?
> 
>   Hmm, there are several ways. Off the top of my head:

Thanks.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: Bug#27753: libpgjava: depends on jdk1.1-runtime, which is now included in jdk1.1

[Hamish Moffatt]

On Mon, Oct 12, 1998 at 02:22:53PM -0700, Stephen Zander wrote:
> > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Hamish> Why doesn't jdk1.1 provide java-virtual-machine? That's an
> Hamish> officially listed virtual package and would have avoided
> Hamish> this problem, and would also solve two bug reports filed
> Hamish> against guavac.
> 
> Because I wasn't sure if that was still a valid virtual package name? :)
> 
> We've gone round the issue of virtual packages for jvm's a couple of
> times & I'm still not certain anything got decided.  Next release will
> comply.

I agree, there is some confusion. Some jdk 1.1 specific names were
proposed too but I don't know if they are official or not. Is there any
traffic on debian-java? I subscribed but haven't seen anything.

I have reassigned you my two finest bug reports about java-virtual-machine :-)

thanks,

Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: Removing Packages in Slink for Debian 2.1

[Hamish Moffatt]

On Wed, Oct 14, 1998 at 09:52:33PM +, [EMAIL PROTECTED] wrote:
> I have to take a look at bug #27395 because pcmcia-modules works for
> me.

The report says not that they don't work, but that some things are not
so good. They seem to be valid concerns although I'm not sure they
are release-critical; Manoj may disagree.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: Slink not installable from CDs

[Hamish Moffatt]

On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote:
> Are we going to include "apt" in the base system? Its package
> ordering feature (and a few others) obsoletes the other methods, but
> currently apt doesn't work with mountable media. A "multi-cdrom-apt"
> method should be added quick.

Hmmm; file:// URLs are supported, are they not?


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Hartmut Koptein]

> But you're missing my point. Why does a binary-only NMU give you the right
> to skip waiting, while a normal NMU does not? Why are they different? Why
> does one let you circumvent the rules, for however noble a purpose?
> 
> Binary-only and normal NMU's are the same thing, and if you can do a
> binary-only NMU w/o waiting, you should be able to do a normal NMU w/o
> waiting. And if you can do that, it follows you should, since a normal NMU
> is better.


How will you feal, if i get one of your packages, make necessary patches for
kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_
source (without asking you for permission) to master. And then you notice
that this new source-package is broken on your system?

binary-only MNU hits only one arch
normal NMU hits possible all archs 

Another story:

I patched a debian binary in february, forwarded the patch directly to the
maintainer (not to the BTS) and uploaded this package as a binary-only
MNU. This package (with the patch) is always not yet available, because
the maintainer is very busy to make a new release. This is more then a
1/2 year !

Greetings,

  Hartmut

PS: we talk no about two or three packages, porters means 100 or 200 packages 
:-)


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]

Re: Upcoming 2.1 Release Architectures

[warp]

On Wed, Oct 14, 1998 at 12:04:29PM -0400, Christopher C Chimelis wrote:
> 
> On Wed, 14 Oct 1998, Brian White wrote:
> 
> > Could I get some official word on which architectures wish to be included
> > in the 2.1 release of Debian?  Thanks!
> 
> So far, Alpha is looking "near" ready and we are shooting to release with
> slink/i386.  A caveat, however, is that we need to resolve some big egcs
> issues SOON or else we can't release (as is, 1.1b will not compile two or
> three vital packages correctly).

There is one, MAJOR, huge, massive, 'program' which egcs will not
properly compile, this is the kernel, 2.0.x is officially not going to
operate 100% correctly when compiled with gcc 2.8.x or egcs..

Any suggestions?

Zephaniah E, Hull..
> 
> I'll keep you updated on this.  How long do we expect the freeze to last
> (ballpark guess)?
> 
> C
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpFVfYJTsbs0.pgp
Description: PGP signature

Intent to package: slocate

[Robert Woodcock]

As featured on Bugtraq and recently Freshmeat, slocate is a replacement for
locate/updatedb. It keeps track of UID's for files so that people can't see
other people's hidden stuff, while still seeing their own.

I'll have it create a diversion for /usr/bin/locate and
/etc/cron.daily/find, and create a system user for `slocate'.

I'm not sure if it's a good idea to divert a config file, if not I'll have
to rethink things a little.

If by some miracle I can get this done tonight (yeah right), it'll be in
slink.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel

.xsessions

[Michael Stone]

I keep seeing questions about getting .xsession's to work, the common
problem being failure to set +x. Wasn't someone going to tweak the
Xsession script to allow non-executable .xsessions?

Mike Stone

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Manoj Srivastava]

Hi,
>>"James" == James Troup <[EMAIL PROTECTED]> writes:

 James> Joey Hess <[EMAIL PROTECTED]> writes:
 >> James Troup wrote:
 >> > They don't compile from freshly unpacked source.
 >> 
 >> How odd. Other maintainer must work substantially differently than I, then.

 James> If you're building foobar 1.1-3, do you really recompile from a
 James> freshly unpacked foobar_1.1-3.dsc?

Close. I work from a freshly exported version. (rm -rf old
 dir, export again, dpkg-buildpackage). That is what cvs-buildpackage
 does.

Why is that so surprising?

manoj
-- 
 No one gets sick on Wednesdays.
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Manoj Srivastava]

Hi,
>>"James" == James Troup <[EMAIL PROTECTED]> writes:


 James> They don't compile from freshly unpacked source.  Problems which
 James> aren't noticed are, for example, a debian/rules clean which depends on
 James> debian/rules build having at least partially run, or a debian/rules
 James> which depends on something in debian/* being executable (when
 James> dpkg-source -x only makes debian/rules executable).

Really? I use cvs, and hence all my packages are indeed built
 from scratch. I was under the impression that more and more people
 are etting converted to CVS, but I guess that is wishful thinking.

manoj
-- 
 The Kosher Dill was invented in 1723 by Joe Kosher and Sam Dill.  It
 is the single most popular pickle variety today, enjoyed throughout
 the free world by man, woman and child alike.  An astounding 350
 billion kosher dills are eaten each year, averaging out to almost 1/4
 pickle per person per day.  New York Times food critic Mimi Sheraton
 says "The kosher dill really changed my life.  I used to enjoy eating
 McDonald's hamburgers and drinking Iron City Lite, and then I
 encountered the kosher dill pickle. I realized that there was far
 more to haute cuisine then I'd ever imagined. And now, just look at
 me."
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Intend to package, create OSS/Free

[Manoj Srivastava]

Hi,
>>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:

 Hamish> On Wed, Oct 14, 1998 at 05:09:54PM -0500, Manoj Srivastava wrote:
 >> Hi,
 >> >>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
 >> 
 >> 
 >> >> /usr/src/modules//, and runs ./debian/rules . 
 >> >> Additionally, the following information is provided in the
 >> >> environment:
 >> >> a) KVERS  Contains the kernel version
 >> >> b) KSRC   Contains the location of the kernel sources 
 >> >> c) KMAINT Contains the Name of the maintainer to pass to PGP
 >> >> d) KEMAIL Caontains the email address of the maintainer
 >> 

 Hamish> I assume KVERS contains only the kernel version, eg 2.0.35.
 Hamish> make-kpkg modules_image allows you to specify a revision,
 Hamish> which pcmcia for example uses as part of the file .deb's
 Hamish> version number. How is the revision number passed?

Hmm. The revision can be passed through the env var
 DEBIAN_REVISION, and possibly pcmcia is aware of that and uses that?
 Or internally $(debian) is used to hold the revision, but I do not
 know if that is exported by make by default 

In short, I don't know -- I'll have to look into pcmcia rules
 file to see what they do.

manoj
-- 
 Nezvannyi gost'--khuzhe tatarina. [An uninvited guest is worse than
 the Mongol invasion] Russian proverb
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Gnome 0.30 fix?

[Chris McKillop]

Quick One...

I know that the gnome 0.30 deb files are alittle messed up,
but I don't remeber every seeing a "fix" to the segv problems.  Was
it a gtk/gdk problem with 1.0.x vs 1.1.x?  I am trying to get eeyes
to work and not having much luck...nor any of the other gnome apps
in gnome-base.

Thanks,
Chris

-
[EMAIL PROTECTED]  "December 24th, 9pm, EST, from here on in I
Waterloo Aerial Robotics Groupshoot without a script..."
http://ece.uwaterloo.ca/~warg/  - Rent - 

Re: [] Bug#27841: apt: apt depends on a missing library

[Dan Jacobowitz]

On Mon, Oct 12, 1998 at 10:05:09PM -0700, Ben Gertzfield wrote:
> Nobody has moved on getting libstdc++2.8 back in slink, even without
> a -dev. 
> 
> Is anyone going to do this?
> 
> Ben

See, it's not "Is anyone going to?" or "Do we agree we should?" right
now.  It's "does anyone but Dan have the time to look at
http://master.debian.org/~dan and figure out why the compiled
libstdc++2.8 package whose source is there is missing a lot of
important symbols".  I can't figure it out.

Dan

Re: Removing Packages in Slink for Debian 2.1

[Jim Pick]

Brian White <[EMAIL PROTECTED]> writes:

> Okay, everybody...  It's that time again.  I've gone through the bug logs
> and made my list of packages to keep/remove should they still have
> release-critical (i.e. critical, grave, or important) bugs at ship time.

What do you think we should do with the Gnome stuff?

The Gnome 0.30 stuff is still under rather heavy development.  The
current packages in Slink are pretty much alpha-quality.  Lots of
things don't work.  It sounds like there will probably be a 1.0
release coming up in a few months that will be thoroughly tested and
stable.

I'm not sure if it's a good idea to release them as a part of a
"stable" distribution, as they really aren't.  There aren't any
guarantees that the stuff that runs today is going to run tomorrow.

Cheers,

 - Jim

Re: Gnome 0.30 fix?

[Jim Pick]

Chris McKillop <[EMAIL PROTECTED]> writes:

> Quick One...
> 
>   I know that the gnome 0.30 deb files are alittle messed up,
> but I don't remeber every seeing a "fix" to the segv problems.  Was
> it a gtk/gdk problem with 1.0.x vs 1.1.x?  I am trying to get eeyes
> to work and not having much luck...nor any of the other gnome apps
> in gnome-base.

I have the same problem here.  I spent a little time trying to debug
it, but never finished due to a lack of time.  It might have something
to do with gtk and themes, but I'm not sure.

If anybody can send me a patch, I'd be eternally grateful.

Cheers,

 - Jim

Re: Perl 5.005.02

[Darren/Torin/Who Ever...]

-BEGIN PGP SIGNED MESSAGE-

Roderick Schertler, in an immanent manifestation of deity, wrote:
>I don't think Andy is taking into account your plan of allowing both
>threaded and non-threaded Perls present on the system at the same time.

That's okay since a) threaded Perl has it's own architecture b)
experimental Perl releases will be in a completely different directory.


>It seems to me that the only real problem we've got with the current
>layout is that the *.pm files for extensions which have XS portions are
>placed in /usr/lib/perl5 rather than in /usr/lib/perl5//.

It used to do that before 5.004 I think.  It doesn't do that anymore.  I 
had to fix perl-base's list of file to deal with this...

>Further, if the  part of that didn't necessarily track
>every new version, but only changed when a new version was binary
>incompatible, that would save even more recompilation.  That is, if

Hmm.  Maybe but that might be too dangerous.

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNiWEpY4wrq++1Ls5AQH5owP/dpatyU9ZSiN60gWq3SSq7zFhXjmcWcmH
G8EwruuDMJKUIQCIuNE/nbzO0eoSlFTS944HV0h0ww7IWbzxk7VMZDx2Z2oy31hf
KfIM6fcNH6zGEgvXe1fUVuvFv300X5nffuQKCywvob3vswR1m+C2rxrDueb3mhmz
jybFZ/W9PEQ=
=tRkI
-END PGP SIGNATURE-

New packages that might cause X to lock up?

[David Welton]

... with a card (Matrox Mystique 4meg) that should be supported quite
well?  This is making me nuts (luckily the computer doesn't die, I can
still ssh in and shut it down), and I can't finish up packages, or
code at all for that matter.  Dejanews returns almost nothing with
matrox mystique (crash|lock) linux (no, I didn't use the regexps).
At the time, I was running netscape and emacs from another box, via X,
emacs and some rxvt's locally, all in fvwm2.

I suppose this is maybe not the best place for this question, but if I
am to have my packages ready for slink, I need to figure this out
quickly.  I kind of wonder if the motherboard is wacked... I don't
need more stress:-(

Thanks,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Buddha Buck]

James Troup said:
> Joey Hess <[EMAIL PROTECTED]> writes:
> 
> > James Troup wrote:
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
> 
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for.  If I'm wrong in some drastic way, only m68k suffers.

How does that differ from -any- binary-only NMU, regardless of 
architechture?  If binary-only NMU's for i386 are bad, why are 
binary-only NMUs for m68k OK?

The only -real- problem I see with normal NMUs is that then the i386 
and m68k binaries are built from different source packages, and I don't 
know if our archiving system has a way of dealing with that.
 
> You're also forgetting the vast majority of our fixes fall into two
> categories:
> 
> 1) Fixing lame packaging bugs.
> 2) Portability fixes.

Both of which, regardless of architecture, are bugs.  If there is a 
lame packaging bug that prevents easy porting, it should be dealt with 
as a bug -- and if that calls for a NMU, then it should be a normal NMU.

Portability fixes are the same way.

> In both cases it's hard for a maintainer to turn round and say, "No,
> your fix is wrong, I wanted the package to be unbuildable from source"
> or "No, get some real hardware, I don't want this package to be
> portable", or "No, that's not the right fix for $ARCH, you should do
> this instead".

Then they probably won't, and if you are lucky, the next Maintainer 
Upload will include the changes made for your NMU.

What is the procedure for normal NMU's in place to ensure that 
necessary bug-fixes get rolled into the next MU anyway?

> > Binary-only and normal NMU's are the same thing,
> 
> No they're not.  Why do you insist on this obvious falsehood?

Why are the different?  Aside from Binary-only apparantly breaking 
current policy?
 
> [ ... ]
> 
> > Do you want the ports to remain forever second class citizens, or do you
> > want them to eventually mature to be equal with i386?
> 
> Will you please get off your high horse and stop being so incredibly
> condescending?  It doesn't help in anyway whatsoever and without some
> facts to back up your anti-non-i386 rants, it's really rather
> pointless.  What exactly makes us second class citizens (your wishes
> aside)?

The only think that I know of that makes ports second-class citizens is 
you claiming that because you are different, you should follow 
different rules.

I don't think Joey is anti-non-i386, but that he instead wants everyone 
to play by the same rules.

> > > All ports needs to make a lot of changes because so many source
> > > packages are broken.  It's got little or nothing to do with the
> > > newness of the port (if you look at the {binary-,}NMU's and bug
> > > reports, they aren't predominantly from the new ports, but rather the
> > > older ones (m68k && alpha)).
> > 
> > Broken source package has nothing to do with a port at all.
> 
> Of course they bloody do; we have to build them.  And the breakage I'm
> talking about, is the sort of breakage which doesn't show up for 99.5%
> of i386/source maintainers.

Just because they don't show up most of the time, they are still 
broken.  And they should be fixed, regardless of if it was found by the 
m68k people, the PPC people, the PalmPilot people, or the i386 people.

> > > Eh?  Define ``standard'', please?  I rather hope you don't mean "what
> > > i386 uses".
> > 
> > I mean that we should converge on using the same build environment and build
> > mechanisms (and NMU mechanisms) for all architectures, and until we do, the
> > ports are going to remain second class citizens.
> 
> Ehm, so all the architectures using glibc 2.1 are second class
> citizens?  If I didn't know better, I'd think you were just using this
> issue as an excuse to vent some anti-non-i386 feelings you seem to
> have.

I think he was referring to Procedures and Policy, not which 
compiler/libraries you use.

A source package which doesn't compile out-of-the-box in the standard 
Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc 
for i386, glibc2.1 plus whatever compiler/libraries/binutils is used 
for m86k, and so forth) has a bug -- unless it is specifically 
architechture dependent.  It's not a bug with the m68k version only, 
it's a bug, plain and simple.  If it fails on m68k because the 
maintainer unconsiously thought that All The World's an i386, then the 
source package still needs to be changed -- and Procedures and Policy 
should allow that.

I don't think that the non-i386 ports are second-class citizens.  I 
think that they should be treated as equally, under Procedures and 
Policies, as possible.  If you claim, as I do, that non-i386 ports 
shouldn't be treated as second-class citizens, why do you ask for 
special treatment?

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

-- 
 Buddha Buck

Re: [] Bug#27841: apt: apt depends on a missing library

[Ben Gertzfield]

> "Dan" == Dan Jacobowitz <[EMAIL PROTECTED]> writes:

Dan> See, it's not "Is anyone going to?" or "Do we agree we
Dan> should?" right now.  It's "does anyone but Dan have the time
Dan> to look at http://master.debian.org/~dan and figure out why
Dan> the compiled libstdc++2.8 package whose source is there is
Dan> missing a lot of important symbols".  I can't figure it out.

The source in http://master.debian.org/~dan in the libstdc sir
is for 2.9. Could this be the problem?

Ben

-- 
Brought to you by the letters Q and S and the number 19.
"The spiraling shape will make you go insane!" -- They Might Be Giants
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: New packages that might cause X to lock up?

[Turbo Fredriksson]

David Welton <[EMAIL PROTECTED]> wrote:

> I suppose this is maybe not the best place for this question, but if I
> am to have my packages ready for slink, I need to figure this out
> quickly.  I kind of wonder if the motherboard is wacked... I don't
> need more stress:-(

I don't know about the video card, or what mother board you have. I have
a 'S3 Trio32/Trio64' video card, a ABit PH5 motherboard, and I have the
_EXACT_ same problem... With a little load on the machine, X vanishes,
leaving the static X image left... Usually I can log in from the outside,
and shut it down (or restart X again, but closing that, just returns me
to the static X image...)

I was recomended on linux-kernel to try some VGA programs, to reset the
display, but so far none have helped.

I've also been told (on the same list) that I have a crappy motherboard...

You could try 'restoretextmode' and 'savetextmode' to restore the VGA
display... It didn't help me, but you might be luckier :)


I have an average uptime for about 2 days, then it krashes... This sucks,
but hey! It's better than Windows :)

-- 
Unix _IS_ user friendly - it's just selective about who its friends are
 / \ / \ / \ / \ / \ / \  Turbo Fredriksson <[EMAIL PROTECTED]>
( D | e | b | i | a | n ) Debian Certified Linux Developer
 \_/ \_/ \_/ \_/ \_/ \_/  Surrey/B.C./Canada
-- 
nuclear spy arrangements security Honduras Peking Semtex Treasury
Panama DES Qaddafi Cocaine FSF Nazi counter-intelligence


pgpB8toYjCa6l.pgp
Description: PGP signature

Re: Slink not installable from CDs

[Enrique Zanardi]

On Wed, Oct 14, 1998 at 10:37:07PM +0200, Bart Schuller wrote:
> On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote:
> > Are we going to include "apt" in the base system? Its package
> > ordering feature (and a few others) obsoletes the other methods, but
> > currently apt doesn't work with mountable media. A "multi-cdrom-apt"
> > method should be added quick.
> 
> Not multiple media, but it works perfectly with file:// urls. What do
> you mean with "mountable media"?
 
I mean apt can't mount a CD, NFS volume or disk partition. To use those
media with apt's dselect method, the user has to mount them before
starting dselect, and umount them after the install. It would be nice if
the user could enter "my CD is in /dev/hdc" and then the apt method do the
mounting/umounting thing automatically. 

--
Enrique Zanardi[EMAIL PROTECTED]

Re: Removing Packages in Slink for Debian 2.1

[Paul Slootman]

On Thu 15 Oct 1998, Marcus Brinkmann wrote:
> On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:
> > strace26065  strace confused about sigaction flags [51]  
> > (Wichert Akkerman <[EMAIL PROTECTED]>)
> 
> Hmm. Why is this bug important anyway? I've looked at the bug report and
> found no explanation.
> 
> I think strace is too useful for debugging and should not be removed.

Seconded! I agree fully.


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: latest sysklogd broken?

[Paul Slootman]

On Wed 14 Oct 1998, Martin Schulze wrote:
> Thomas Lakofski wrote:
> > 
> > Seems that the latest sysklogd package breaks sendmail's (and cron's, just
> > checked) logging to syslog -- it works for a few minutes, and then no more
> > logs.  I don't know if this is universal (only checked 2 daemons), but it
> > looks like it.
> 
> What do you mean by "break"?  If you restart syslogd you have to restart
> some other programs as well (squid, teergrube, inn, named come to my
> mind.)

Can you explain this?  This doesn't sound very "normal" to me.


> Unix is user friendly ...  It's just picky about it's friends.

To be picky  "it's" should be "its" :-)  Otherwise it says
"about it is friends" ("it's" is short for "it is").
Besides that I agree.


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

octave-plplot: intention to package

[Rafael Laboissiere]

Hurrying before the slink freeze, here is my intention to package:

===
 Package: octave-plplot
 Version: 0.3-1
 Section: math
 Priority: optional
 Architecture: i386
 Depends: libc6 (>= 2.0.7u), libstdc++2.9, tcl8.0 (>=8.0.3), tk8.0 (>=8.0.3), 
xlib6g (>= 3.3-5), octave, plplot-tcl (>= 4.99j-5)
 Installed-Size: 520
 Maintainer: Rafael Laboissiere <[EMAIL PROTECTED]>
 Description: PLplot interface for Octave
  This package enables you to use PLplot from within Octave.  When this
  package is installed, all the plotting funtions of octave are
  replaced by corresponding PLplot ones.
  .
  Using it instead of the regular gnuplot interface, you have the
  following advantages:
  .
  - Use a superior plotting package, having access to dozens of
plotting commands, enabling you to customize your plots at your
will.
  - Still use the same plot commands that you are familiarized, if you
really want to.
  - Have some new and long waited ploting command scripts.
  .
  Besides having acess to all PLplot API commands, and all Octave usual
  commands, some with some improvements, new commands are
  available. They are: autostyle, ginput, grid, gtext, legend, cmap,
  pldef, save_fig, set_view, shade, contour, stripc, stripc_add,
  stripc_del, tdeblank, text, xticks, and zoom.
===

[This will be a great improvement for Octave, IMHO.]

Actually, I already packaged it.  It is lintian-clean and all the demos
are working.  I have just a problem with the copyright, as there is no
copyright notice in the upstream source.  I obtained it from the
octave-sources mailing list, so I am assuming that it is in the public
domain.  I will upload it to slink/main, if nobody objects.  (This
message is being Cc;'d to the author, so he can react if I am not doing
the right thing).

--
Rafael Laboissiere
Institut de la Communication Parlee | Email: [EMAIL PROTECTED]
UPRESS A CNRS 5009 / INPG   | Voice: +33 4.76.57.48.49
46, av. Felix Viallet   |   Fax: +33 4.76.57.47.10
F-38031 Grenoble CEDEX 1 France |   URL: http://www.icp.inpg.fr/~rafael

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Christopher C. Chimelis]

Buddha Buck wrote:
> 
> How does that differ from -any- binary-only NMU, regardless of
> architechture?  If binary-only NMU's for i386 are bad, why are
> binary-only NMUs for m68k OK?
> 
> The only -real- problem I see with normal NMUs is that then the i386
> and m68k binaries are built from different source packages, and I don't
> know if our archiving system has a way of dealing with that.

This is true, and this should be fixed, IMO.  If "Debian", as an entity,
is making a decision to become multi-arch supportive, then maybe it's
time to update the older rules that were made when x86 was the only
arch, and time to implement some rules and methods that are more
consistent with multi-architecture development.  In short, instead of
arguing here, let's try to learn to work together on this.


> Both of which, regardless of architecture, are bugs.  If there is a
> lame packaging bug that prevents easy porting, it should be dealt with
> as a bug -- and if that calls for a NMU, then it should be a normal NMU.
> Portability fixes are the same way.

Well, I've got mixed emotions on this.  Yes, technically, we should be
waiting for the maintainer to handle it, BUT most of the bugs I've filed
haven't even gotten a responce from the maintainer save the automated
one.  It would be one thing if it was A bug in A package, but it's
usually five fixes in 100 packages.  If there were 100 of me doing
this, I wouldn't have a problem waiting, but in the meantime, I'm
watching 5 new revisions of these packages come out WITHOUT fixes.
Plus, I've got 30 new package to compile, all of which need fixes...
it's a viscious circle.  It seems like alot of the maintainers just
don't care sometimes too.  In short, it gets frustrating when things
aren't addressed and your problem keeps mounting and compounding like
that.

Ideally, ALL maintainers would have access to a machine of every arch
to compile their own packages on it, but I still have a feeling that
alot of maintainers wouldn't bother compiling their packages on any
other arch than x86.

> Then they probably won't, and if you are lucky, the next Maintainer
> Upload will include the changes made for your NMU.

Yeah, right.  I hate to be nasty, but I've got at least three bugs
that have been sitting in the BTS for over 110 days.  These are
fixes that are NEEDED to compile on Alphas (one of them is netstd,
so it's not like I'm talking about some dumb game here).  Also,
one of them is an improvement that the upstream author had made
a note to change "one day", but that hasn't even made its way into
the package.  If 110 days is "not alot of time to wait" on an
important package, then I might as well stop trying to port ANYTHING
anymore because it's becoming obvious to me that not many maintainers
really care how portable their packages are.

> Why are the different?  Aside from Binary-only apparantly breaking
> current policy?

Because we're trying to walk both sides of the line in doing a
binary-only NMU.  For one, it takes care of a problem that isn't
being taken care of otherwise (because nobody else seems to care)
and also, we file diffs in the BTS.  I have to give alot of the
maintainers good credit for incorporating the patches in a timely
manner, but there are still quite a few that remain outstanding.

How would *you* deal with it?  Would you wait 110+ days while your
machine doesn't run right because of a broken package or would you
do a binary NMU to help yourself and others WHILE waiting for the
maintainer to get around to fixing their package?

On the x86, it's not much of a problem because usually maintainers
can test and easily incorporate patches easily (not to mention how
much easier it is to diagnose bugs on their native arch).  When it
comes to porters, we end up having to make our patches "drop-in"
easily because we want to make it as easy as possible for the
maintainer or else it'll take another three weeks to make the patches
friendly to all archs.

> The only think that I know of that makes ports second-class citizens is
> you claiming that because you are different, you should follow
> different rules.
> I don't think Joey is anti-non-i386, but that he instead wants everyone
> to play by the same rules.

I think that other archs ARE being treated like second-class citizens in
more regards than just NMUs.  I *wish* I had more interest from
maintainers as to whether their packages compile ok on Alphas or not.
To date, I've only had three maintainers actually ask me to test build
their packages on Alphas and run some tests (which they provided)
to make sure things worked ok.  I was more than willing to do this.
However, on the flip side, I've also received feedback from a couple of
maintainers that basically said that they don't really care about us.

In short, if *you* think the current rules are multi-arch-friendly, then
I might as well stop porting to the Alpha totally.  Like it or not,
other archs have to get some latitude because of the problems that come
w

Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]

[Brian White]

> What do you think we should do with the Gnome stuff?
> 
> The Gnome 0.30 stuff is still under rather heavy development.  The
> current packages in Slink are pretty much alpha-quality.  Lots of
> things don't work.  It sounds like there will probably be a 1.0
> release coming up in a few months that will be thoroughly tested and
> stable.
> 
> I'm not sure if it's a good idea to release them as a part of a
> "stable" distribution, as they really aren't.  There aren't any
> guarantees that the stuff that runs today is going to run tomorrow.

I would agree with you.  They should probably be removed from slink
at the time of the freeze.  Do you have a list of these packages?

  Brian
 ( [EMAIL PROTECTED] )

---
Debian GNU/Linux!  Search it at  http://insite.verisim.com/search/debian/simple

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[James Troup]

Buddha Buck <[EMAIL PROTECTED]> writes:

> James Troup said:
> > Joey Hess <[EMAIL PROTECTED]> writes:
> > 
> > > James Troup wrote:
> > > Why does a binary-only NMU give you the right to skip waiting, while
> > > a normal NMU does not? Why are they different?
> > 
> > Because I'm not forcing my changes on anyone but the architecture I'm
> > uploading for.  If I'm wrong in some drastic way, only m68k suffers.
> 
> How does that differ from -any- binary-only NMU, regardless of 
> architechture?  If binary-only NMU's for i386 are bad, why are 
> binary-only NMUs for m68k OK?

Who said they were bad?  They are very rarely necessary however, since
99.5% of the time (the only exception I know of is Hartmut's packages)
i386 packages are already compiled for i386 and don't need to be
compiled by someone other than the maintainer.  That's when
binary-only-NMUs occur on non-i386.

> > You're also forgetting the vast majority of our fixes fall into two
> > categories:
> > 
> > 1) Fixing lame packaging bugs.
> > 2) Portability fixes.
> 
> Both of which, regardless of architecture, are bugs. 

Well, duh.  [ Actually, if, e.g. postgresql plain lacks m68k support
upstream, that's hardly a bug on the part of the postgresql maintainer
or upstream.  Some packages are non-trivial to port and require good
knowledge of the architecture in question. ]

> If there is a lame packaging bug that prevents easy porting, it
> should be dealt with as a bug -- and if that calls for a NMU, then
> it should be a normal NMU.

Why?  

> Portability fixes are the same way.

Again, why?
 
> What is the procedure for normal NMU's in place to ensure that 
> necessary bug-fixes get rolled into the next MU anyway?

Good God, why the hell are you taking part in this discussion, if you
need to ask a question like that?
 
> > > Binary-only and normal NMU's are the same thing,
> > 
> > No they're not.  Why do you insist on this obvious falsehood?
> 
> Why are the different? 

Because one includes source and one does not.  And because one only
affects one architecture, and one affects all architectures.  And
because binary-only NMU's have a distinct and clear purpose aside from
the current issue of fixing bugs in the source which everyone seems
willing to forget[1].

> Aside from Binary-only apparantly current policy?

Ehm, please show me which part of policy binary-only-NMUs break?  Stop
the FUD!

> I don't think Joey is anti-non-i386, but that he instead wants
> everyone to play by the same rules.

You don't even know the damn rules, so what the hell are you talking
about?  But in case you hadn't noticed "playing by the same rules"
doesn't work, because i386 is not the be all and end all of
architectures.

[...]

> > > Broken source package has nothing to do with a port at all.
> > 
> > Of course they bloody do; we have to build them.  And the breakage I'm
> > talking about, is the sort of breakage which doesn't show up for 99.5%
> > of i386/source maintainers.
> 
> Just because they don't show up most of the time, they are still 
> broken. 

So?

> And they should be fixed, regardless of if it was found by the 
> m68k people, the PPC people, the PalmPilot people, or the i386 people.

Again, so?  Both your statements are highly irrelevant to what I said,
please try to stick to the point.

[...]

> > Ehm, so all the architectures using glibc 2.1 are second class
> > citizens?  If I didn't know better, I'd think you were just using this
> > issue as an excuse to vent some anti-non-i386 feelings you seem to
> > have.
> 
> I think he was referring to Procedures and Policy, not which 
> compiler/libraries you use.

Rubbish.  Read what he wrote:

| > >and your build environment may be non-standard. 
   ^^^
| 
| > Eh?  Define ``standard'', please?  I rather hope you don't mean "what
| > i386 uses".

> A source package which doesn't compile out-of-the-box in the standard 
> Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc 
> for i386, glibc2.1 plus whatever compiler/libraries/binutils is used 
> for m86k, and so forth) has a bug -- unless it is specifically 
> architechture dependent. 

Yes, it's a bug.  So what?  I know it's a bug.  That's why I always
file a _bug_ in the _bug_ tracking system.

> It's not a bug with the m68k version only, it's a bug, plain and
> simple. 

Your talent for stating the obvious blows me away.

> If you claim, as I do, that non-i386 ports shouldn't be treated as
> second-class citizens, why do you ask for special treatment?

I don't... actually all I want for Debian is more maintainers with a
clue.  But I don't think, I'll being seeing too much of that in this
lifetime.

[1] Everyone seems to be forgetting the indisputably valid forms of
binary-NMUs where a simple recompile with no source changes (other
than an entry to debian/changelog) occur.  Real life example: some
lamer (i.e. me) compiled bash on an m68k box without ncurses3.0-altdev
installed; end

Re: Bug#26065: Removing Packages in Slink for Debian 2.1

[Wichert Akkerman]

Previously Marcus Brinkmann wrote:
> 
> Hello,
> 
> On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:
> > strace26065  strace confused about sigaction flags [51]  
> > (Wichert Akkerman <[EMAIL PROTECTED]>)
> 
> Hmm. Why is this bug important anyway? I've looked at the bug report and
> found no explanation.

It was important because Raul Miller made it that. He needed strace to
debug a problem with one of his packages and found that bug. Since he
hasn't responded to my failure to reproduce the problem I was going to
downgrade the severity, but apparently someone beat me to that.

> And then try to explain them why strace is not included in the Debian
> distribution.

I'm still amazed by the development of strace.. basically it's a nightmare
to work on. Upstream version are _extremely_ rare and there are literaly
dozens of patches floating around, but nobody collects them. I think
Debian actually has one of the most featureful strace's that exist :)

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgprv4SjhxuOD.pgp
Description: PGP signature

Test

[M.C. Vernon]

Sorry to spam you guys, but I my inbox is uncharactaristically empty

Matthew

-- 
Elen sila lumenn' omentielvo

Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.geocities.com/Area51/Chamber/8841/
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Paul Slootman]

On Thu 15 Oct 1998, James Troup wrote:
> Joey Hess <[EMAIL PROTECTED]> writes:
>  
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
> 
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for.  If I'm wrong in some drastic way, only m68k suffers.

Additionally, a "normal" NMU is to fix generic problems with the workings
of the package itself, not the building process; at least, *I* have never
seen an NMU (with source) done for i386 to fix a build problem.

Hmmm, we should make it policy that i386 packages aren't allowed to be
directly uploaded into Debian; instead, the source should be uploaded,
and then another maintainer (not related in any way to the uploader)
must download the source, build the package, and upload the resulting
binary. If the build fails, either don't upload or upload a complete
NMU with source.  That should equalize things between i386 and the rest :-)
Also, the speed at which updates come would be slowed to acceptable
rates...

> > Binary-only and normal NMU's are the same thing,
> 
> No they're not.  Why do you insist on this obvious falsehood?

IMO the difference is that a binary-only NMU fixes building difficulties,
and a normal NMU fixes the functionality or problems with installing.
A binary-only NMU package should function that same way in all respects
to the original binary.

> > Do you want the ports to remain forever second class citizens, or do you
> > want them to eventually mature to be equal with i386?
> 
> Will you please get off your high horse and stop being so incredibly
> condescending?  It doesn't help in anyway whatsoever and without some

I have to agree that I fail to see any added value in Joey's comment
here.

> > Broken source package has nothing to do with a port at all.
> 
> Of course they bloody do; we have to build them.  And the breakage I'm
> talking about, is the sort of breakage which doesn't show up for 99.5%
> of i386/source maintainers.

Precisely; couldn't the QA team check that packages build correctly
for third parties? What's the point of supplying source packages if
they're useless.

> > I mean that we should converge on using the same build environment and build

Source dependencies would be a *big* help.


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Removing Packages in Slink for Debian 2.1

[Michael Bramer]

On Wed, Oct 14, 1998 at 09:33:22PM -0700, Jim Pick wrote:
> Brian White <[EMAIL PROTECTED]> writes:
> 
> > Okay, everybody...  It's that time again.  I've gone through the bug logs
> > and made my list of packages to keep/remove should they still have
> > release-critical (i.e. critical, grave, or important) bugs at ship time.
> 
> What do you think we should do with the Gnome stuff?
> 
> The Gnome 0.30 stuff is still under rather heavy development.  The
> current packages in Slink are pretty much alpha-quality.  Lots of
> things don't work.  It sounds like there will probably be a 1.0
> release coming up in a few months that will be thoroughly tested and
> stable.
> 
> I'm not sure if it's a good idea to release them as a part of a
> "stable" distribution, as they really aren't.  There aren't any
> guarantees that the stuff that runs today is going to run tomorrow.

This is right, but please don't remove gnome from slink.

If gnome on CD-Rom the user can play with it and can write bug-reports and/or
pachtes. Change only the description with a first Line like
 '** This is alpha software. It can run but it can destroy the system too **'
and you can move it to extra. 

Grisu
-- 
Michael Bramer - a Debian Certified Linux Developerhttp://www.debian.org
PGP: finger [EMAIL PROTECTED]   --   Linux Sysadmin   --  Use Debian Linux
"The Box said 'Windows NT or better', so I installed Debian Linux"


pgpyV7Exfk3yQ.pgp
Description: PGP signature

Re: sendmail logging disappeared

[Russell Coker]

On Thu, 15 Oct 1998, Thomas Lakofski wrote:
>hmmm, just rebooted for the first time in 20 days and my sendmail daemon
>isn't doing any logging.  no problems in /etc/syslog.conf, and sendmail
>invoked by pine drops logs in the right places.  daemon logs its
>invocation and then goes about its business (correctly), but doesn't log
>anything as far as i can see anywhere.
>
>i'm running slink current as of today.
>
>ideas?

Not an idea, but I had syslogd freeze up on me.  Some parts of it were
working, but it was just blocking when qmail tried to write to the logs.  I
noticed this when I didn't receive email for 8 hours.  Since I restarted it
this morning everything has been fine.

--
I'll be in Denver from 30 Oct 1998 to 7 Nov 1998 (or maybe a few days longer).
I'll be in London from ~9 Nov 1998.  I'd like to meet any Linux users or
users groups in these places at these times.
I plan to work in London for 3 - 6 months...

Re: Upcoming 2.1 Release Architectures

[Christopher C Chimelis]

On Wed, 14 Oct 1998 [EMAIL PROTECTED] wrote:

> There is one, MAJOR, huge, massive, 'program' which egcs will not
> properly compile, this is the kernel, 2.0.x is officially not going to
> operate 100% correctly when compiled with gcc 2.8.x or egcs..
> 
> Any suggestions?

On the Alpha?  I've had nothing but success with all 2.0.x kernels on the
Alpha using egcs and moderate success with 2.1.x kernels (but only because
alot of the kernels had broken Alpha support...no fault of egcs).

C

Re: Removing Packages in Slink for Debian 2.1

[Brian White]

> smb2www   27641  perl 5.005-02 breaks smb2www [0]  (Craig Small
> <[EMAIL PROTECTED]>)
> 
> This one also refers to the version of perl which has been
> removed. (It broke every module, so there are several such bug reports)

I knew about it, but not which bugs it affected.  I'll disable this bug
on my side so it won't affect anything.

  Brian
 ( [EMAIL PROTECTED] )

---
   Touch passion when it comes your way.  It's rare enough as it is;
   don't walk away when it calls you by name.  -- Marcus (Babylon 5)

Re: Screenshots (Re: gdselect alpha 3)

[Martin Schulze]

Nils Rennebarth wrote:
> On Wed, Oct 14, 1998 at 05:03:22PM +0200, Martin Schulze wrote:
> > I was told recently that people might be interested in some screenshots
> > of the program.  The following page contains three images.
> > 
> > http://www.infodrom.north.de/~joey/Linux/Debian/gdselect.html
> Does anyone else has the problem of netscape 4.07 segfaulting on the second
> and third screenshot?

Args.  I've not converted them into .jpg.  This increases their size up
to >100kB.  I thought .jpg would contain compression.

Regards,

Joey

-- 
Install joe (Joey's Own Editor) correct: Joe's Own Editor

Re: Upcoming 2.1 Release Architectures

[Brian White]

> > So far, Alpha is looking "near" ready and we are shooting to release with
> > slink/i386.  A caveat, however, is that we need to resolve some big egcs
> > issues SOON or else we can't release (as is, 1.1b will not compile two or
> > three vital packages correctly).
> 
> There is one, MAJOR, huge, massive, 'program' which egcs will not
> properly compile, this is the kernel, 2.0.x is officially not going to
> operate 100% correctly when compiled with gcc 2.8.x or egcs..
> 
> Any suggestions?

Yeah.  Ship kernel v2.1 if v2.0 won't work.  I don't have a problem with
that (but only if v2.0 won't work on that arch).

  Brian
 ( [EMAIL PROTECTED] )

---
Debian GNU/Linux!  Search it at  http://insite.verisim.com/search/debian/simple

Re: Upcoming 2.1 Release Architectures

[Paul Slootman]

On Wed 14 Oct 1998, [EMAIL PROTECTED] wrote:
> On Wed, Oct 14, 1998 at 12:04:29PM -0400, Christopher C Chimelis wrote:
> > 
> > slink/i386.  A caveat, however, is that we need to resolve some big egcs
> > issues SOON or else we can't release (as is, 1.1b will not compile two or
> > three vital packages correctly).
> 
> There is one, MAJOR, huge, massive, 'program' which egcs will not
> properly compile, this is the kernel, 2.0.x is officially not going to
> operate 100% correctly when compiled with gcc 2.8.x or egcs..

I last compiled (with success) 2.0.36pre2 with "gcc version egcs-2.90.29
980515 (egcs 1.0.3 release)" (according to /proc/version).  That works
perfectly with ISDN and all, and stayed up for a month until I upgraded
sysvinit which then decided to run through all the init scripts etc ;-(


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[warp]

I don't really want to get into this, I've got enough people mad at me
for filing some bug reports, but I think this needs to be said, anyways.
On Thu, Oct 15, 1998 at 02:54:02AM +0200, Hartmut Koptein wrote:
> 
> > But you're missing my point. Why does a binary-only NMU give you the right
> > to skip waiting, while a normal NMU does not? Why are they different? Why
> > does one let you circumvent the rules, for however noble a purpose?
> > 
> > Binary-only and normal NMU's are the same thing, and if you can do a
> > binary-only NMU w/o waiting, you should be able to do a normal NMU w/o
> > waiting. And if you can do that, it follows you should, since a normal NMU
> > is better.
> 
> 
> How will you feal, if i get one of your packages, make necessary patches for
> kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_
> source (without asking you for permission) to master. And then you notice
> that this new source-package is broken on your system?

There is a reason libc's have version #defs, and that gcc and alike have
version #defs, and *gasps* kernels too..

Basicly, use #if and #ifdef, if your changes blindly assume a arch then
your no better then the programmers who assume ix86, if not worse
because you KNOW how important the issues are..

> 
> binary-only MNU hits only one arch
> normal NMU hits possible all archs 

A binary-only MNU violates the GPL, end of story.

> 
> Another story:
> 
> I patched a debian binary in february, forwarded the patch directly to the
> maintainer (not to the BTS) and uploaded this package as a binary-only
> MNU. This package (with the patch) is always not yet available, because
> the maintainer is very busy to make a new release. This is more then a
> 1/2 year !

This is why you should include source with the NMU!!!

Zephaniah E, Hull.
> 
> Greetings,
> 
>   Hartmut
> 
> PS: we talk no about two or three packages, porters means 100 or 200 packages 
> :-)
> 
> 
> -- 
>  Hartmut Koptein   EMail:
>  Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
>  26603 Aurich   
>  Tel.: +49-4941-10390  [EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpO2UrqfrDvo.pgp
Description: PGP signature

Re: Slink not installable from CDs

[Kenneth Scharf]

If main is split into two cd's then no packages in main1 should depend
on any in main2.  (packages in main2 could depend on main1, then you
would be told to go back and install them from main1?)


_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Slink not installable from CDs

[Kevin Dalley]

Can apt handle a situation where there is not enough room in the /var
partition for a complete download?  Last time I check, about a month
ago, it could not handle this case.  The ftp method can handle too
small /var.

Manoj Srivastava <[EMAIL PROTECTED]> writes:
>   Apt has a builtin ftp method. I coded the interim ftp method
>  for APT (though my code is no longer used ;-(, and let me assure you,
>  APT had all the functionality (if not more) of the method it
>  replaced.
> 
>   I think APT does indeed make most of the other methods
>  obsolete, and we should indeed be replacing the other methods with
>  apt (no matter how mad it makes certain individuals ;-)
> 

Re: Screenshots (Re: gdselect alpha 3)

[Greg Vence]

Martin Schulze wrote:
> 
> Nils Rennebarth wrote:
> > On Wed, Oct 14, 1998 at 05:03:22PM +0200, Martin Schulze wrote:
> > > I was told recently that people might be interested in some screenshots
> > > of the program.  The following page contains three images.
> > >
> > > http://www.infodrom.north.de/~joey/Linux/Debian/gdselect.html
> > Does anyone else has the problem of netscape 4.07 segfaulting on the second
> > and third screenshot?
> 
> Args.  I've not converted them into .jpg.  This increases their size up
> to >100kB.  I thought .jpg would contain compression.
> 
JPEG is compression based on the change in value from one pixel to the
surounding ones.  This is better for photography than graphic art.  Fast
color change wrecks the compression...
--
What do you want to spend today?
Debian GNU/Linux  (Free for an UNLIMITED time) 
http://www.debian.org/social_contract.html
Greg VenceKH2EA/4

Possible serious problem with the newest sysklogd?

[Seth M. Landsman]

Hmm, so I just updated the syslogd on my system yesterday (using
dselect, slink 2.1 i386 system).  Then I stopped receiving mail completely
via qmail.  About 4 hours later I realized I hadn't received any mail for
the day and saw no qmail entries in my logs.
I restarted qmail and received tons of mail, which trickled down
and eventually stopped.  Within 30 minutes, I couldn't receive any more
mail.
I've traced the problem to splogger blocking.  If I kill splogger,
everything is happy, but no qmail messages get logged.
Furthermore, I've found that qmail writes to the log for the first
n messages, and then just stops writing, even though messages get through
in the 30 minutes or so that splogger is happy.  Also, I've found that the
initial qmail : starting message is not written to logs via this version
of syslogd.

If no one has a definite clue or course of action, can someone
tell me where I can find the previous version of syslogd?  If I can get
the previous version, I think I could probably figure out what is going
on. 

-Seth

--
"It is by will alone I set my mind in motion"

Re: Upcoming 2.1 Release Architectures

[J.H.M. Dassen \(Ray\)]

On Thu, Oct 15, 1998 at 01:50:33PM +0200, Paul Slootman wrote:
> I last compiled (with success) 2.0.36pre2 with "gcc version egcs-2.90.29
> 980515 (egcs 1.0.3 release)" (according to /proc/version).  That works
> perfectly with ISDN and all, and stayed up for a month until I upgraded
> sysvinit which then decided to run through all the init scripts etc ;-(

Still, personally I wouldn't trust it. If I needed/wanted to compile a 2.0.x
kernel with egcs, I'd apply the patches at 
http://www.suse.de/~florian/
first.

Ray
-- 
J.H.M. Dassen | RUMOUR  Believe all you hear. Your world may  
[EMAIL PROTECTED]  | not be a better one than the one the blocks   
  | live in but it'll be a sight more vivid.  
  | - The Hipcrime Vocab by Chad C. Mulligan  

Re: .xsessions

[Ole J. Tetlie]

*-Michael Stone <[EMAIL PROTECTED]>
|
| I keep seeing questions about getting .xsession's to work, the common
| problem being failure to set +x. Wasn't someone going to tweak the
| Xsession script to allow non-executable .xsessions?

I'll file a wishlist bug with a patch to xbase.

-- 
The only way tcsh "rocks" is when the rocks are attached to it's feet
in the deepest part of a very deep lake. (Linus Torvalds)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Re: Removing Packages in Slink for Debian 2.1

[Stephane Bortzmeyer]

On Wednesday 14 October 1998, at 12 h 19, the keyboard of Brian White 
<[EMAIL PROTECTED]> wrote:

> The following are packages I feel we can remove:
...
> netatalk  25598  netalk: several problems (and the solution) [64]  
> (Joel Klecker <[EMAIL PROTECTED]>)

As a new developer, I just want to be sure. Does it mean we can ship 2.1 with 
*less* packages than 2.0 and important packages like this one? If so, why would 
people upgrade to slink?

Re: Bug#26065: Removing Packages in Slink for Debian 2.1

[Marcus . Brinkmann]

On Thu, Oct 15, 1998 at 04:26:21PM +0200, Wichert Akkerman wrote:
> 
> It was important because Raul Miller made it that. He needed strace to
> debug a problem with one of his packages and found that bug. Since he
> hasn't responded to my failure to reproduce the problem I was going to
> downgrade the severity, but apparently someone beat me to that.

Yep, Brian was faster, nice to hear. The web pages didnt reflect
this change yesterday, this is why I acted fast.

> 
> > And then try to explain them why strace is not included in the Debian
> > distribution.
> 
> I'm still amazed by the development of strace.. basically it's a nightmare
> to work on. Upstream version are _extremely_ rare and there are literaly
> dozens of patches floating around, but nobody collects them. I think
> Debian actually has one of the most featureful strace's that exist :)

Thank you for your great work on it! I consider it as a very important
and fast debugging tool. KUTGW.

Marcus


-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: Possible serious problem with the newest sysklogd?

[Martin Schulze]

Seth M. Landsman wrote:
>   Hmm, so I just updated the syslogd on my system yesterday (using
> dselect, slink 2.1 i386 system).  Then I stopped receiving mail completely
> via qmail.  About 4 hours later I realized I hadn't received any mail for
> the day and saw no qmail entries in my logs.
>   I restarted qmail and received tons of mail, which trickled down
> and eventually stopped.  Within 30 minutes, I couldn't receive any more
> mail.
>   I've traced the problem to splogger blocking.  If I kill splogger,
> everything is happy, but no qmail messages get logged.
>   Furthermore, I've found that qmail writes to the log for the first
> n messages, and then just stops writing, even though messages get through
> in the 30 minutes or so that splogger is happy.  Also, I've found that the
> initial qmail : starting message is not written to logs via this version
> of syslogd.
> 
>   If no one has a definite clue or course of action, can someone
> tell me where I can find the previous version of syslogd?  If I can get
> the previous version, I think I could probably figure out what is going
> on. 

I guess that I've identified the offending part of the code.  However
i don't know why it didn't work.  Mainly it is described in the bug
wrt OpenBSD `-a' feature.  After disabling that one syslogd runs
perfectly on my loghost again, and there are lots  of messages through
syslog, so I guess it works again.

I'll upload it later.

Regards,

Joey

-- 
Install joe (Joey's Own Editor) correct: Joe's Own Editor

Re: Removing Packages in Slink for Debian 2.1

[Martin Schulze]

Jim Pick wrote:
> 
> Brian White <[EMAIL PROTECTED]> writes:
> 
> > Okay, everybody...  It's that time again.  I've gone through the bug logs
> > and made my list of packages to keep/remove should they still have
> > release-critical (i.e. critical, grave, or important) bugs at ship time.
> 
> What do you think we should do with the Gnome stuff?
> 
> The Gnome 0.30 stuff is still under rather heavy development.  The
> current packages in Slink are pretty much alpha-quality.  Lots of
> things don't work.  It sounds like there will probably be a 1.0
> release coming up in a few months that will be thoroughly tested and
> stable.

I vote for "leave them in".  I feel much in favour of presenting
them to the world.  Basically they work.  There are bugs and some
pieces don't work.  I don't consider this as a problem.

Regards,

Joey

-- 
Install joe (Joey's Own Editor) correct: Joe's Own Editor

Re: PROPOSAL: one debian list for all porting efforts

[Joel Klecker]

At 12:30 +0200 1998-10-14, Paul Slootman wrote:
On Mon 12 Oct 1998, Hartmut Koptein wrote:
:-)   debian/i386 is also a port!
No. For 90% (I think more) of the packages it is the primary architecture.
The word "port" implies carrying to _another_ architecture. Hence the
package on the primary architecture is _not_ a port.
To me it is a port, a port of Debian GNU/Linux.
--
Joel Klecker (aka Espy)
mailto:[EMAIL PROTECTED]>http://web.espy.org/>
  Debian GNU/Linux user/developer on i386 and powerpc.
mailto:[EMAIL PROTECTED]>  http://www.debian.org/>

Re: Possible serious problem with the newest sysklogd?

[Martin Schulze]

Seth M. Landsman wrote:
> On Thu, Oct 15, 1998 at 04:59:42PM +0200, Martin Schulze wrote:
> > Seth M. Landsman wrote:
> > >   Hmm, so I just updated the syslogd on my system yesterday (using
> > > dselect, slink 2.1 i386 system).  Then I stopped receiving mail completely
> > > via qmail.  About 4 hours later I realized I hadn't received any mail for
> > > the day and saw no qmail entries in my logs.
> > >   I restarted qmail and received tons of mail, which trickled down
> > > and eventually stopped.  Within 30 minutes, I couldn't receive any more
> > > mail.
> > >   I've traced the problem to splogger blocking.  If I kill splogger,
> > > everything is happy, but no qmail messages get logged.
> > >   Furthermore, I've found that qmail writes to the log for the first
> > > n messages, and then just stops writing, even though messages get through
> > > in the 30 minutes or so that splogger is happy.  Also, I've found that the
> > > initial qmail : starting message is not written to logs via this version
> > > of syslogd.
> > > 
> > >   If no one has a definite clue or course of action, can someone
> > > tell me where I can find the previous version of syslogd?  If I can get
> > > the previous version, I think I could probably figure out what is going
> > > on. 
> > 
> > I guess that I've identified the offending part of the code.  However
> > i don't know why it didn't work.  Mainly it is described in the bug
> > wrt OpenBSD `-a' feature.  After disabling that one syslogd runs
> > perfectly on my loghost again, and there are lots  of messages through
> > syslog, so I guess it works again.
> > 
> > I'll upload it later.
> 
>   Great.  If you want me to give it a shakedown first, I'd be happy
> to.

Please find a snapshot at

ftp://ftp.infodrom.north.de/pub/people/joey/debian/

The source package of -27.1 might be broken, I got some errors.

Regards,

Joey

> -Seth
> 
> --
> "It is by will alone I set my mind in motion"

-- 
Install joe (Joey's Own Editor) correct: Joe's Own Editor

Re: Upcoming 2.1 Release Architectures

[Brian White]

> > > Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source
> > > and dsc files and upload it to master, but will you and the other arch
> > > maintainer agree with this??
> >
> > If it's a powerpc package only, I don't see why there would be a problem.
> > It should get installed automatically without ever coming to my attention.
> > Or is there something I don't understand?
> 
> Great news. But uploading a *.deb package without source?? I think this will
> be rejected!? And you mean uploading to unstable, not to experimental?

Oh, I see what you mean.  Personally, I don't mind if the source exists,
too.  I'd rather that all arches that can run of the 2.0 kernel ship with
that, but having the source available for the 2.1 kernel shouldn't cause
any problems.

  Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Re: Removing Packages in Slink for Debian 2.1

[Brian White]

> On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:
> > strace26065  strace confused about sigaction flags [51]  
> > (Wichert Akkerman <[EMAIL PROTECTED]>)
> 
> Hmm. Why is this bug important anyway? I've looked at the bug report and
> found no explanation.

Darn.  I downgraded that one to "normal" yesterday.  I must have missed it
going over the list, since the severity hadn't propogated to the bug-list
when I generated the reports.  If it isn't "normal" by now, please change
it again.

  Brian
 ( [EMAIL PROTECTED] )

---
If you have a 50% chance of guessing right, you'll guess wrong 75% of the time.

Re: login time limits in slink???

[Craig Sanders]

On 15 Oct 1998, Paul Crowley wrote:

> Craig Sanders <[EMAIL PROTECTED]> writes:
> 
> > anyone know what it is in slink which is enforcing idle-timeout and daily
> > time limits on serial lines?
> 
> I don't have this problem, and I haven't installed idled:
> 
> Description: Idle Daemon. Removes idle users.
>  Idled is a "daemon" that runs on a machine to keep an eye on current
>  users.  If users have been idle for too long, or have been logged on
>  for too long, it will warn them and log them out appropriately.

yeah, i know about idled.  i even package a similar daemon for debian
(timeoutd).

i don't have idled or timeoutd or anything similar installed on the machine
in question.  that was the first thing i thought of.

this idle timeout only seems to occur for logins on a serial line (both
terminal and ppp logins), never on console or a pty.

thanks for the suggestion, but it doesn't help.  this problem seems
specific to slink...perhaps a new login binary does it.


craig


--
craig sanders

Re: Upcoming 2.1 Release Architectures

[Jules Bean]

--On Thu, Oct 15, 1998 1:12 pm +0200 "Christian Meder"
<[EMAIL PROTECTED]> wrote: 
>> > * if there's a stabilized snapshot newbies will get (hopefully) a
>> > softer introduction in the wonders of the Linux-Sparc/Powerpc/Arm/...
>> world
>> 
>> 
>> I see your argument.  I'm worried that we might be perceived as giving
the
>> message that debian-sparc is ready for primetime, which, alas, it is
not..
> 
> Right. I would like to see a freeze on Sparc the result of which we should
> call _development_ snapshot instead of release to distinguish them.
> 
> Remember the article of Alan Cox recently on slashdot.
> 
> * Release early to get other people jump on the wagon.
> 
> The ports tend to drag along because newbies don't know where to start.

If we call it something like a 'developer' release, or an 'early-access'
release, then it sounds like a great idea, yes...  as long as people don't
get the impression that it is a full 2.1 release.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Upcoming 2.1 Release Architectures

[Christian Meder]

On Wed, Oct 14, 1998 at 11:49:59PM +0100, Jules Bean wrote:
> --On Thu, Oct 15, 1998 12:14 am +0200 "Christian Meder"
> <[EMAIL PROTECTED]> wrote: 
> 
> > On Wed, Oct 14, 1998 at 10:05:25AM -0700, Stephen Zander wrote:
> >> > "Brian" == Brian White <[EMAIL PROTECTED]> writes:
> >> 
> >> Brian> Could I get some official word on which architectures wish
> >> Brian> to be included in the 2.1 release of Debian?  Thanks!
> >> 
> >> I don't think sparc is ready to go, though Johnnie or Eric may see it
> >> differently.
> >> 
> > I'm neither Johnnie nor Eric but I think the basic tools on sparc are
> > stabilizing (compiler, glibc2.1, kernel). I don't think Sparc is ready
> > for a full blown quality release like i386.
> > 
> > Does it make sense to go for a stabilized developer snapshot, i.e.
> > a Sparc port which has base, required, standard and parts of the
> > optional packages (sources based on the slink dist of i386) ? 
> > Kind of a official _development_ release with a big disclaimer about
> > the development character of the port. Powerpc probably would be a
> > second candidate for such a release.
> > 
> > 2 reasons in favour:
> > 
> > * we ease the work of the CD producers to provide a _reasonable_ 
> > (installable) snapshot of the ports
> > 
> 
> We don't have installable CDs, do we?

No.

> 
> Our disks don't work on all models... although our netboot is better.

I will work on the boot-floppies soonish

> 
> AFAICS, there are still serious bugs in X - and also the 2.0 series kernels
> don't work well on SS2s, at least - but the 2.1 series kernels don't work at
> all with our bash.

I know there are bugs left. But we get probably 4 to 6 weeks to fix at 
least some of them.

> 
> > * if there's a stabilized snapshot newbies will get (hopefully) a
> > softer introduction in the wonders of the Linux-Sparc/Powerpc/Arm/...
> world
> 
> 
> I see your argument.  I'm worried that we might be perceived as giving the
> message that debian-sparc is ready for primetime, which, alas, it is not..

Right. I would like to see a freeze on Sparc the result of which we should
call _development_ snapshot instead of release to distinguish them.

Remember the article of Alan Cox recently on slashdot.

* Release early to get other people jump on the wagon.

The ports tend to drag along because newbies don't know where to start.

Greetings,


Christian

-- 
Christian Meder, email: [EMAIL PROTECTED]
 
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
  (Henry David Thoreau)
 

Re: login time limits in slink???

[Paul Crowley]

Craig Sanders <[EMAIL PROTECTED]> writes:

> anyone know what it is in slink which is enforcing idle-timeout and daily
> time limits on serial lines?
> 
> i've hunted all over (even to the point of grepping every file in /etc, 
> /bin, /usr/bin, /sbin, /usr/sbin) for it and can't find it anywhere.
> 
> how do i turn it off?  i don't want time limits.

I don't have this problem, and I haven't installed idled:

Description: Idle Daemon. Removes idle users.
 Idled is a "daemon" that runs on a machine to keep an eye on current
 users.  If users have been idle for too long, or have been logged on
 for too long, it will warn them and log them out appropriately.
-- 
  __
\/ o\ [EMAIL PROTECTED] Edinburgh fetish club Permission \ /
/\__/ Paul Crowley  Nov 8 http://www.hedonism.demon.co.uk/permission /~\

Re: Closing bugs

[Santiago Vila]

On 14 Oct 1998, Ole J. Tetlie wrote:

> Quick question: When two bugs are merged, do I need to close both
> or will one closing close both, and send a message to both the
> submittors?

The documentation for the bug system says:

  [...] When reports are merged
  opening, closing, marking or unmarking as forwarded and
  reassigning any of the bugs to a new package will have an
  identical effect on all of the merged reports.

So if it does not work, it is a bug in the bug system :-)

(Yes, the bug system does also have bugs, in particular X-Debian-Cc does
not work but it is documented, is anyone working on this?)

-- 
 "290c211429c22878215ef9e74bdc39b7" (a truly random sig)

Re: Upcoming 2.1 Release Architectures

[Paul Slootman]

On Thu 15 Oct 1998, J.H.M. Dassen Ray" wrote:
> On Thu, Oct 15, 1998 at 01:50:33PM +0200, Paul Slootman wrote:
> > I last compiled (with success) 2.0.36pre2 with "gcc version egcs-2.90.29
> > 980515 (egcs 1.0.3 release)" (according to /proc/version).  That works
> > perfectly with ISDN and all, and stayed up for a month until I upgraded
> > sysvinit which then decided to run through all the init scripts etc ;-(
> 
> Still, personally I wouldn't trust it. If I needed/wanted to compile a 2.0.x
> kernel with egcs, I'd apply the patches at 
>   http://www.suse.de/~florian/
> first.

I don't see how patching arch/i386/kernel/ioport.c and
arch/i386/kernel/ksyms.c will help the stability of a kernel running
on Alpha (which was the point here).  If you do, please enlighten me :-)


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Upcoming 2.1 Release Architectures

[Paul Slootman]

On Thu 15 Oct 1998, Christopher C Chimelis wrote:
> On Wed, 14 Oct 1998 [EMAIL PROTECTED] wrote:
> 
> > There is one, MAJOR, huge, massive, 'program' which egcs will not
> > properly compile, this is the kernel, 2.0.x is officially not going to
> > operate 100% correctly when compiled with gcc 2.8.x or egcs..
> > 
> > Any suggestions?
> 
> On the Alpha?  I've had nothing but success with all 2.0.x kernels on the
> Alpha using egcs and moderate success with 2.1.x kernels (but only because
> alot of the kernels had broken Alpha support...no fault of egcs).

The last time I tried (about 10 sec. ago, on a.d.nl :-):

make[2]: Entering directory `/extra/home/debian/psl/kernel/linux/drivers/net'
gcc -D__KERNEL__ -I/extra/home/debian/psl/kernel/linux/include -Wall 
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe 
-mno-fp-regs -Wa,-m21164a -DBWX_USABLE -DMODULE -DMODVERSIONS -include 
/extra/home/debian/psl/kernel/linux/include/linux/modversions.h -DEXPORT_SYMTAB 
-c slhc.c
gcc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [slhc.o] Error 1

$ gcc -v
Reading specs from /usr/lib/gcc-lib/alpha-linux/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Screenshots (Re: gdselect alpha 3)

[Nils Rennebarth]

On Wed, Oct 14, 1998 at 05:03:22PM +0200, Martin Schulze wrote:
> I was told recently that people might be interested in some screenshots
> of the program.  The following page contains three images.
> 
> http://www.infodrom.north.de/~joey/Linux/Debian/gdselect.html
Does anyone else has the problem of netscape 4.07 segfaulting on the second
and third screenshot?

Nils

--
*-*
| Quotes from the net:  L> Linus Torvalds, W> Winfried Truemper   |
| L>this is the special easter release of linux, more mundanely called 1.3.84 |
| W>Umh, oh. What do you mean by "special easter release"?. Will it quit  |
* W>working today and rise on easter? *


pgpVbcNhdCN8u.pgp
Description: PGP signature

Re: Gnome 0.30 fix?

[Martin Alonso Soto]

Jim Pick <[EMAIL PROTECTED]> wrote:
> I have the same problem here.  I spent a little time trying to debug
> it, but never finished due to a lack of time.  It might have something
> to do with gtk and themes, but I'm not sure.

Where are the segfaults happening?  I found a pretty nasty one with
the session manager (gsm), that was preventing my session info from
being saved.  I spent many hours trying to catch it, but I wasn't able
to find anything wrong in the code.  However, at a given time I added
some printf statements to the code (to print certain values the
debugger was not getting right) and the problem disappeared (!).

Here is the patch for the printf statements.  It is not a real fix but
may help someone to find the bug (and is a workaround anyway :-).

---
diff -u --recursive gsm/prop.c ../gnome-core-0.30.modif/gsm/prop.c
--- gsm/prop.c  Thu Jul 23 19:12:54 1998
+++ ../gnome-core-0.30.modif/gsm/prop.c Wed Sep 30 17:20:55 1998
@@ -62,12 +62,15 @@
   SmProp *prop;
 
   prop = find_property_by_name (client, name);
-  if (! prop || strcmp (prop->type, SmARRAY8))
+  if (! prop || strcmp (prop->type, SmARRAY8)) {
+printf( "find_string_property: %s not found\n", name );
 return FALSE;
+  }
 
   *result = malloc (prop->vals[0].length + 1);
   memcpy (*result, prop->vals[0].value, prop->vals[0].length);
   result[prop->vals[0].length] = '\0';
+  printf( "find_string_property: %s = %s\n", name, *result );
 
   return TRUE;
 }
@@ -80,17 +83,22 @@
   int i;
 
   prop = find_property_by_name (client, name);
-  if (! prop || strcmp (prop->type, SmLISTofARRAY8))
+  if (! prop || strcmp (prop->type, SmLISTofARRAY8)) {
+printf( "find_vector_property: %s not found\n", name );
 return FALSE;
+  }
 
   *argcp = prop->num_vals;
   *argvp = (char **) malloc (*argcp * sizeof (char *));
+  printf ( "find_vector_property: %s = ", name );
   for (i = 0; i < *argcp; ++i)
 {
   (*argvp)[i] = malloc (prop->vals[i].length + 1);
   memcpy ((*argvp)[i], prop->vals[i].value, prop->vals[i].length);
   (*argvp)[i][prop->vals[i].length] = '\0';
+  printf( " %s", (*argvp)[i] );
 }
+  printf( "\n" );
 
   return TRUE;
 }
Only in ../gnome-core-0.30.modif/gsm/: prop.c~
diff -u --recursive gsm/save.c ../gnome-core-0.30.modif/gsm/save.c
--- gsm/save.c  Thu Jul 23 19:12:54 1998
+++ ../gnome-core-0.30.modif/gsm/save.c Wed Sep 30 19:49:45 1998
@@ -66,8 +66,9 @@
 write_one_client (int number, const Client *client)
 {
   /* We over-allocate; it doesn't matter.  */
-  int i, vec_count, string_count, argcs[NUM_PROPERTIES], failure;
-  char **argvs[NUM_PROPERTIES];
+  int i, vec_count, string_count, argcs[NUM_PROPERTIES], 
+/*argcs2[NUM_PROPERTIES],*/ failure;
+  char **argvs[NUM_PROPERTIES]/*, **argvs2[NUM_PROPERTIES]*/;
   char *strings[NUM_PROPERTIES];
   const char *argv_names[NUM_PROPERTIES];
   const char *string_names[NUM_PROPERTIES];
@@ -77,6 +78,9 @@
   if (find_card8_property (client, SmRestartStyleHint, &style)
   && style == SmRestartNever)
 return 0;
+
+  /*  find_vector_property (client, "RestartCommand",
+  &argcs2[0], &argvs2[0]); */
 
   /* Read each property we care to save.  */
   failure = 0;
---

Regards,

M. S.


Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]

Re: Deleting uncompressed Info/Doc files at upgrades

[Stephane Bortzmeyer]

On Friday 2 October 1998, at 11 h 55, the keyboard of Peter S Galbraith 
<[EMAIL PROTECTED]> wrote:

> To me, a uncompressed version of a file is still the same file.
> To me, copying an uncompressed info file to /usr/local/info *is* leaving
> crud all over the disk.

Yes, the current Debian system is really inconvenient. Each time you want to 
do something useful with a documentation (print it, grep it, glimpse it, vi 
it, remember that not every program is able to read compressed files and "zcat 
file.gz | program" is not always the simplest thing to do), you have to copy 
it to an /usr/local. If the purpose of compressing documenattion was to save 
disk space, this failed! We have now the compressed and the uncompressed 
version on the disk.

And it does not follow the principle of least surprise, judging by the number 
of beginners (including myself) who had the surprise reported by Peter.

In the mean time, as a packager, I prefer to leave documentation uncompressed.

> Sure, it's a special case.  Sure dpkg should have to be changed, or maybe
> /var/lib/dpkg/info/*.list file could have regular expressions, like:
> 
> /usr/info/emacs-e20-2(.gz)?

It seems a good idea and it will work with bzip2 as well.

PGP question

[M.C. Vernon]

I have a slight problem with PGP: I do my development on pick and can post
from there (but don't) - all my email is done from cus (and I'm not sure
if it can cope with PGP)

So do I:

post from pick, and hope no-one sends me encrypted mail
or what?

I need to sort this out before I do pgpkeygen and apply to be a
developer...


Matthew

-- 
Elen sila lumenn' omentielvo

Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.geocities.com/Area51/Chamber/8841/
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

Corporate Visibility for Linux

[Bob Hilliard]

 The following is quoted from the column Business Bulletin on the
front page of today's Wall Street journal, which is probably the most
widely read newspaper by corporate America:

 'FREEWARE' STIRS debate while entrepreneurs find a nice niche.

 Advocates prefer to call the free software from developers "open
source software", stressing the fact that the source code used for
programming is open and constantly improved.  Skeptics fear hackers
and the lack of support offered by commercial firms.  Enter "value
added outfits like Caldera Systems, Inc. and Red Hat Software.  They
package and offer support services for Linux, a popular open-source
software version of the Unix operating system created in1991 by
Finnish graduate student Linus Torvalds.

 O'Reilly & Associates, a publisher in Sebastopol, Calif., expects
about half of is $40 million in revenue this year to come from the
sale of open source books.  Even the big firms are involved: IBM, for
instance, licensed Apache, an open-source product for Web sites.
Potential corporate users have a mixed view.  Many firms, such as
Virginia Power, Wells Fargo & Co., Ipalco Enterprises, Inc. and Boeing
Co. discourage use of freeware, although some allow special use.  Some
fear viruses.

 The City of Garden Grove, Calif. has used a Linux-based network
since 1995.

Bob
-- 
   _
  |_)  _  |_   Robert D. Hilliard<[EMAIL PROTECTED]>
  |_) (_) |_)  Palm City, FL  USAPGP Key ID: A8E40EB9

Re: Removing Packages in Slink for Debian 2.1

[Michael Meskes]

On Wed, Oct 14, 1998 at 09:33:22PM -0700, Jim Pick wrote:
> What do you think we should do with the Gnome stuff?

Keep it in!

> The Gnome 0.30 stuff is still under rather heavy development.  The
> current packages in Slink are pretty much alpha-quality.  Lots of
> things don't work.  It sounds like there will probably be a 1.0
> release coming up in a few months that will be thoroughly tested and
> stable.

Declare the packages alpha if you want but keep it in please. Let's give the
people a chance to use gnome. BTW I use it and found parts to be pretty
stable.

Michael

-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: Removing Packages in Slink for Debian 2.1

[Ben Armstrong]

On Thu, 15 Oct 1998, Martin Schulze wrote:
> > What do you think we should do with the Gnome stuff?
> > 
> > The Gnome 0.30 stuff is still under rather heavy development.  The
> > current packages in Slink are pretty much alpha-quality.  Lots of
> > things don't work.  It sounds like there will probably be a 1.0
> > release coming up in a few months that will be thoroughly tested and
> > stable.
> 
> I vote for "leave them in".  I feel much in favour of presenting
> them to the world.  Basically they work.  There are bugs and some
> pieces don't work.  I don't consider this as a problem.

Also, slashdot says slink includes Gnome.  It would be a disappointment
to many if we pulled it.

Ben
--
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
Chebuctohttp://www.chebucto.ns.ca   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]

Re: login time limits in slink???

[Tom Lear]

On Thu, 15 Oct 1998, Craig Sanders wrote:

> On 15 Oct 1998, Paul Crowley wrote:
> 
> > Craig Sanders <[EMAIL PROTECTED]> writes:
> > 
> > > anyone know what it is in slink which is enforcing idle-timeout and daily
> > > time limits on serial lines?
> > 
> > I don't have this problem, and I haven't installed idled:
> > 
> > Description: Idle Daemon. Removes idle users.
> >  Idled is a "daemon" that runs on a machine to keep an eye on current
> >  users.  If users have been idle for too long, or have been logged on
> >  for too long, it will warn them and log them out appropriately.
> 
> yeah, i know about idled.  i even package a similar daemon for debian
> (timeoutd).
> 
> i don't have idled or timeoutd or anything similar installed on the machine
> in question.  that was the first thing i thought of.

Maybe autolog, it's in hamm too though.
autolog - Terminates connections for idle users
- Tom

Re: login time limits in slink???

[Mitch Blevins]

Craig Sanders wrote:
> On 15 Oct 1998, Paul Crowley wrote:
> 
> > Craig Sanders <[EMAIL PROTECTED]> writes:
> > 
> > > anyone know what it is in slink which is enforcing idle-timeout and daily
> > > time limits on serial lines?
> > 
> > I don't have this problem, and I haven't installed idled:
> > 
> > Description: Idle Daemon. Removes idle users.
> >  Idled is a "daemon" that runs on a machine to keep an eye on current
> >  users.  If users have been idle for too long, or have been logged on
> >  for too long, it will warn them and log them out appropriately.
> 
> yeah, i know about idled.  i even package a similar daemon for debian
> (timeoutd).
> 
> i don't have idled or timeoutd or anything similar installed on the machine
> in question.  that was the first thing i thought of.
> 
> this idle timeout only seems to occur for logins on a serial line (both
> terminal and ppp logins), never on console or a pty.
> 
> thanks for the suggestion, but it doesn't help.  this problem seems
> specific to slink...perhaps a new login binary does it.
> 

FWIW - I have the same problem.  No idled.  No logoutd.
No lines in /etc/porttime.  Still get booted off the console
after several hours.

-Mitch


pgpGqV4sGPNWH.pgp
Description: PGP signature

Re: Removing Packages in Slink for Debian 2.1

[Marc Singer]

On Wed, Oct 14, 1998 at 09:33:22PM -0700, Jim Pick wrote:
> 
> Brian White <[EMAIL PROTECTED]> writes:
> 
> > Okay, everybody...  It's that time again.  I've gone through the bug logs
> > and made my list of packages to keep/remove should they still have
> > release-critical (i.e. critical, grave, or important) bugs at ship time.
> 
> What do you think we should do with the Gnome stuff?
> 
> The Gnome 0.30 stuff is still under rather heavy development.  The
> current packages in Slink are pretty much alpha-quality.  Lots of
> things don't work.  It sounds like there will probably be a 1.0
> release coming up in a few months that will be thoroughly tested and
> stable.
> 
> I'm not sure if it's a good idea to release them as a part of a
> "stable" distribution, as they really aren't.  There aren't any
> guarantees that the stuff that runs today is going to run tomorrow.

I installed it yesterday to get a glimpse at what they are doing.  I'd
say it should be left out because it doesn't really work.  It is a
fine demonstration, but it doesn't add value to Debian until it can be
used either a) to hack against, or b) to provide a workable desktop
environment. 

Re: Upcoming 2.1 Release Architectures

[Christopher C. Chimelis]

Paul Slootman wrote:
> 
> The last time I tried (about 10 sec. ago, on a.d.nl :-):
> 
> make[2]: Entering directory `/extra/home/debian/psl/kernel/linux/drivers/net'
> gcc -D__KERNEL__ -I/extra/home/debian/psl/kernel/linux/include -Wall 
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe 
> -mno-fp-regs -Wa,-m21164a -DBWX_USABLE -DMODULE -DMODVERSIONS -include 
> /extra/home/debian/psl/kernel/linux/include/linux/modversions.h 
> -DEXPORT_SYMTAB -c slhc.c
> gcc: Internal compiler error: program cc1 got fatal signal 11
> make[2]: *** [slhc.o] Error 1
> 
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/alpha-linux/egcs-2.91.57/specs
> gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

We both know what this is about.  I just got ahold of the egcs-snapshot
packager and we're going to try again on that today.  Hopefully, if I
can get the snapshot to bootstrap, we should have a package really soon
that works (instead of being as brain-dead as 1.1b is).

C

Re: Slink not installable from CDs

[Marcelo E. Magallon]

On Wed, Oct 14, 1998 at 05:56:42PM +0100, Philip Hands wrote:

> Is something like ``Anything with a priority of extra gets put on the second 
> CD'' a reasonable guess ?  or should we make a list of stuff to go on the 
> second CD based on some sensible criteria (if anyone can think of some 
> without 
> starting a flame war ;-)

As I said before, extra is not enough. The CD 1 has to contain less than 600
MB worth of .debs to make room for disks-i386, doc (is that included on the
CD, I think it should), tools (is that redistributable?) and the
Contents-whatever files (that would help to keep the number of "which
package contains xxx file?" type of questions down) and well as the Packages
files. override files ought to be included, too (those would be useful for
some fellows that for any reason want/have to rebuild Packages)

disks-i386 35 MB
tools   1 MB
doc 2 MB
indices 6 MB  (this is Packages + Contents + overrides; approx) 
cdfs slack  5 MB

   49 MB

Last time I looked (about two weeks ago), extra was about 90 MB and slink is
about 770 MB right now. That's 670 MB, 70 MB over the limit.

> The second CD might then be main2 + contrib + X11-source, and the third
> could be the source, assuming that all fits (which it probably doesn't
> anymore)

Contrib is ~ 100 MB. Plus 170 MB from main that's 270 MB for .deb's in CD 2.

contrib/source  120 MB
main/source 996 MB (this is wrong, I think, but that's what I have here)
   sans x11 867 MB

CD 2 can hold source/x11, source/devel and source/math (this is a random
pick). Those sections add up to 370 MB.

> Has anyone been making slink CDs BTW ?  If so, how big is it all ?

I chopped off extra, a few more things by hand (don't remember which ones;
mostly things from devel and games)... the result fitted a single CD.

What we need badly now is an apt-based method to be able to cope with this
situation (multiple CD's -- I think Jason said he was working on this, I may
be mistaken), and a little modification to apt to make it install extra at
the end of the run (iff it doesn't do it this way right now... Jason?)



Marcelo

Re: PGP question

[Jules Bean]

--On Thu, Oct 15, 1998 4:46 pm +0100 "M.C. Vernon" <[EMAIL PROTECTED]>
wrote: 

> 
> I have a slight problem with PGP: I do my development on pick and can post
> from there (but don't) - all my email is done from cus (and I'm not sure
> if it can cope with PGP)
> 
>   So do I:
> 
>   post from pick, and hope no-one sends me encrypted mail
> or what?
> 
> I need to sort this out before I do pgpkeygen and apply to be a
> developer...

Hehe.

I'm guessing those question won't make sense to 90% of all debian
developers, since they're not at cambridge..

Here's what I do..

Hermes for mail (but you could use cus), with PGP support.

Developement on my personal machine.  PGP signing there.

If I need to do PGP+mail, then I run PINE on my local machine (CUS does
support IMAP, doesn't it?).  Then I can use the local PGP key on the remote
mail server...

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: PGP question

[Jules Bean]

--On Thu, Oct 15, 1998 5:43 pm +0100 "Jules Bean" <[EMAIL PROTECTED]>
wrote: 
> Hermes for mail (but you could use cus), with PGP support.

Doh.

Hermes *without* PGP support, I meant.

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: PROPOSAL: one debian list for all porting efforts

[Marcus . Brinkmann]

On Thu, Oct 15, 1998 at 08:15:02AM -0700, Joel Klecker wrote:
> At 12:30 +0200 1998-10-14, Paul Slootman wrote:
> >On Mon 12 Oct 1998, Hartmut Koptein wrote:
> >> :-)   debian/i386 is also a port!
> >
> >No. For 90% (I think more) of the packages it is the primary architecture.
> >The word "port" implies carrying to _another_ architecture. Hence the
> >package on the primary architecture is _not_ a port.
> 
> To me it is a port, a port of Debian GNU/Linux.

To me, too. At the time I made the suggestion, I had in mind also i386
people who are interested in porting, but do not have any specific
architecture in mind. This would also help the communication
between the i386 folks and the porter "subset".

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Hartmut Koptein]

Ok, 

  let us a little bit summarize:


  1. binary-only NMUs breaks policity
  2. every NMU must be with source
  3. Porters needn't to ask maintainers for permission
  4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer

ok for all ?   

   If the answer is 'yes'  i agree !


If so, we (porters) increment always the debian package minor number +1 .


  MfG,

 Hartmut



-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]

Re: Bug#26065: Removing Packages in Slink for Debian 2.1

[David Welton]

On Thu, Oct 15, 1998 at 04:26:21PM +0200, Wichert Akkerman wrote:

> I'm still amazed by the development of strace.. basically it's a nightmare
> to work on. Upstream version are _extremely_ rare and there are literaly
> dozens of patches floating around, but nobody collects them. I think
> Debian actually has one of the most featureful strace's that exist :)

I think that, with my porting the arm stuff from corel's redhat based
version to ours, we may have the most architectures... I don't recall
seeing POWERPC in theirs, based off of 3.1.  I agree though, it seems
like a big ugly mess:->

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: latest sysklogd broken?

[Stephen Zander]

> "Michael" == Michael Sobolev <[EMAIL PROTECTED]> writes:
Michael> Same things happens to me.  Today I upgraded two things
Michael> sendmail and syslogd (what a coincidence! :).  After few
Michael> minutes I found that `ps ax' shows a lot of sendmail
Michael> processes.  Everything looks like that after restarting
Michael> *syslogd* information goes into appropriate files for few
Michael> minutes.  Then it stops, what results in sendmail (and, I
Michael> believe, other processes that make us of syslog) to wait
Michael> forever.

An additional data point: I also upgraded yesterday and have had
similar syslogd problems.  In my case, however, exim is the MTA and it
runs from inetd, so starting/stopping syslogd should be irrelevant.

Killing the odd process (exim IIRC), has returned my mail delivery to
usefulness.  I'll let you know if it breaks again.

-- 
Stephen
---
Perl is really designed more for the guys that will hack Perl at least
20 minutes a day for the rest of their career.  TCL/Python is more a
"20 minutes a week", and VB is probably in that "20 minutes a month"
group. :) -- Randal Schwartz

Re: octave-plplot: intention to package

[Joao Cardoso]

Rafael Laboissiere wrote:
Hurrying before the slink freeze, here is my intention
to package:
===
 Package: octave-plplot
 Version: 0.3-1
 Section: math
 Priority: optional
 Architecture: i386
 Depends: libc6 (>= 2.0.7u), libstdc++2.9, tcl8.0 (>=8.0.3), tk8.0
(>=8.0.3), xlib6g (>= 3.3-5), octave, plplot-tcl (>= 4.99j-5)
 Installed-Size: 520
 Maintainer: Rafael Laboissiere <[EMAIL PROTECTED]>
 Description: PLplot interface for Octave
  This package enables you to use PLplot from within Octave. 
When this
  package is installed, all the plotting funtions of octave are
  replaced by corresponding PLplot ones.
  .
  Using it instead of the regular gnuplot interface, you have
the
  following advantages:
  .
  - Use a superior plotting package, having access to dozens of
    plotting commands, enabling you to customize your
plots at your
    will.
  - Still use the same plot commands that you are familiarized,
if you
    really want to.
  - Have some new and long waited ploting command scripts.
  .
  Besides having acess to all PLplot API commands, and all Octave
usual
  commands, some with some improvements, new commands are
  available. They are: autostyle, ginput, grid, gtext, legend,
cmap,
  pldef, save_fig, set_view, shade, contour, stripc, stripc_add,
  stripc_del, tdeblank, text, xticks, and zoom.
===
[This will be a great improvement for Octave, IMHO.]
Actually, I already packaged it.  It is lintian-clean and all the
demos
are working.  I have just a problem with the copyright, as there
is no
copyright notice in the upstream source.  I obtained it from the
octave-sources mailing list, so I am assuming that it is in the public
domain.
I know nothing about copyrights, so I  include none in the sources.
My intention is that plplot_octave could be available in a future release
of
Octave, if Octave's author wants to. If including it in a Debian release
disallows my intention, than I would not approve it.
As I told before, my intention is to enable it to be used as Octave
is, with
a GNU General Public License (which I have never fully read :-)) .
If you want to add/include in all modified sources or scripts the GNU
licence
header, I will be happy (if this is still possible after I have put
the package
un-intentionally in the public domain).
Anyway, I already have latter versions, but they are not packaged for
public usage.
Thanks,
Joao
PS- John Eaton: do you have any comments?
I will upload it to slink/main, if nobody objects. 
(This
message is being Cc;'d to the author, so he can react if I am not doing
the right thing).
--
Rafael Laboissiere
Institut de la Communication Parlee | Email: [EMAIL PROTECTED]
UPRESS A CNRS 5009 / INPG  
| Voice: +33 4.76.57.48.49
46, av. Felix Viallet  
|   Fax: +33 4.76.57.47.10
F-38031 Grenoble CEDEX 1 France |  
URL: http://www.icp.inpg.fr/~rafael

-- 
Joao Cardoso    |   e-mail: [EMAIL PROTECTED]
INESC, R. Jose Falcao 110   |   tel:    + 351 2 2094322
4050 Porto, Portugal    |   fax:    + 351 2 2008487
 

Anyone packaging snes9x?

[Dave Swegen]

I've been considering packaging snes9x, and was just wondering whether it
had already been done.

Also, are there any developers in the Southampton (UK) area? I could do
with someone to sign for me (no, I don't have access to a scanner).

Cheers
Dave

Which PGP?

[Dave Swegen]

Out of curiosity, which version of PGP is the debian de facto standard.
I'm currently using v5, but I've seen a number of people use 2.6...

Cheers
Dave

Re: Upcoming 2.1 Release Architectures

[Hartmut Koptein]

 
> If we call it something like a 'developer' release, or an 'early-access'
> release, then it sounds like a great idea, yes...  as long as people don't
> get the impression that it is a full 2.1 release.

Ok, under this impression powerpc is ready to go. 

I'll upload 2.1 kernel source and images for powerpc in three or four days
to master. Possible we can have only _one_ source and not as for glibc-2.1
many source-packages available (2.0.93, 2.0.95). 

I'm not sure, if i should upload the cvs tree or the normal linus tree. 
Powerpc is nearly perfect with the official linux 2.1 tree, what about 
sparc?

Thanks,

Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]

Re: Slink not installable from CDs

[Santiago Vila]

On Wed, 14 Oct 1998, Philip Hands wrote:

> Is something like ``Anything with a priority of extra gets put on the second 
> CD'' a reasonable guess ?

Only in part.

Some packages should definitely be on the first CD even if they are extra,
namely the ones that are extra because they conflict with the "standard"
one. For example, I don't think putting a "popular" package like sendmail
in the second CD would be a good idea.

I mean: Just because smail is the current standard MTA does not mean that
putting sendmail in the second CD is a good idea. I'm sure there are a lot
of optional packages that are much less used than the "just extra" 
sendmail.

> or should we make a list of stuff to go on the 
> second CD based on some sensible criteria (if anyone can think of some 
> without 
> starting a flame war ;-)

I would like to let the users to vote on this.
Something like a survey, or a poll.

"What would you like to see on the first CD"?

-- 
 "c63f759c37d03eeccbe40a0ab8092398" (a truly random sig)

Re: Anyone packaging snes9x?

[Ben Gertzfield]

> "Dave" == Dave Swegen <[EMAIL PROTECTED]> writes:

Dave> I've been considering packaging snes9x, and was just
Dave> wondering whether it had already been done.

It's been done. :)

-- 
Brought to you by the letters Q and Z and the number 1.
"Ha ha! I have evaded you with the aid of these pasty white mints!"
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: Which PGP?

[Ben Gertzfield]

> "Dave" == Dave Swegen <[EMAIL PROTECTED]> writes:

Dave> Out of curiosity, which version of PGP is the debian de
Dave> facto standard.  I'm currently using v5, but I've seen a
Dave> number of people use 2.6...

Debian uses 2.6 for now. 5 is a bit incompatible with other versions,
and it includes sneaky key escrow systems that people don't trust.

We're actually moving to gpg soon, so this will all be moot. :)

-- 
Brought to you by the letters N and S and the number 17.
"Moshimoshi. Kikoemasu ka?" "Kakenaoshimasu kara ne! 1-do kitte kudasai."
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Hartmut Koptein]

Hi James,

> Who said they were bad?  They are very rarely necessary however, since
> 99.5% of the time (the only exception I know of is Hartmut's packages)

yes, my packages are the only one that test masters scripts for non-i386
maintainer source uploads. :-)

This is now possible but it was not always the case in the past. 



Its time to remember: 
 
- multi archs cds are comming 
- work is in progress for downloading serveral arch binaries from our web 
pages
- documentation will be better and better
- debian is always free

but:  we have always no consens for an easy installation - what means: (new) 
users have
  not the choice to select for a base- , middle- or big-installing 
procedure.

This is more important then a x11 installation (for boot-floppies). 

[joda filter off] :-)


   Hartmut

-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]

Re: Slink not installable from CDs

[David Welton]

On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote:
> 
> "What would you like to see on the first CD"?

Why don't we look at what the most popular downloads have been?  Some
Perl/Python type person ought to be able to parse them nicely, include
information about relative sizes of things, and then output something
based on that.  I don't have time for this, so feel free to can the
idea of no one is interested in doing it.

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Gnome 0.30 fix?

[John Lapeyre]

On Thu, 15 Oct 1998, Martin Alonso Soto wrote:

masoto>to find anything wrong in the code.  However, at a given time I added
masoto>some printf statements to the code (to print certain values the
masoto>debugger was not getting right) and the problem disappeared (!).

This is characteristic of reading and writing outside of array
bounds. (as determined by malloc)

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Slink not installable from CDs

[Santiago Vila]

On Thu, 15 Oct 1998, David Welton wrote:
> On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote:
> > "What would you like to see on the first CD"?
> 
> Why don't we look at what the most popular downloads have been? [...]

Good idea!

-- 
 "1df9795f6d2984efc8f37c0f0fda9b32" (a truly random sig)

Re: Debian 2.[01] -- Only rudimentary support for Laptops?

[Alexander Kushnirenko]

Hi,

> I have an IBM ThinkPad 380XD.  I have found that 2.0.x kernels just don't
> work properly, my machine will crash or shutdown during boot.  I believe that
> the best thing that can be done to support laptops is to create boot disks
> with 2.1.125 kernels.  2.1.125 works well on my laptop in every way and has
> fixed the problems with RAM disks that older 2.1.x kernels had.
> 

Sorry to jump into discussion... Well, I ABSOLUTELYU agree with Russel.   I 
also installed linux on IBM ThinkPad 380XD.  It's my 6-th Debian installation 
around and definitly the most embarrasing one.  I DO agree that ThinkPad 380XD 
is quite new piece of hardware, and don't want to blame anyone or anything, 
but perhaps we may pay closer attention to Laptop instalation problems.

1. Official booting disketes - DOES NOT work (tecra also!)
2. Official kernel 2.0.34 - DOES NOT work (constant reboot)

The only thing that work was loadlin thru Win95 :(

Sasha.

Re: Removing Packages in Slink for Debian 2.1

[Javier Fdz-Sanguino Pen~a]

On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:

> vrwave23436  vrwave should maybe go in contrib? [124]  (Javier 
> Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>)
> xswallow  25932  Xswallow should be in contrib [55]  (Javier 
> Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>)

OK. These two are mine, sorry for not answering before.

- vrwave

Vrwave should go into non-free, because the license does not permit
commercial use without prior consent of IICM. This is a pity, since it means
there will not be a VRML browser for slink in main. A real pity.
This is my fault, I should have had more time to fix this (move it
into non-free) with a new upload, but I don't know how to do this? File a
bug against ftp.debian.org?

Anyhow, there is another point here I would like to be cleared. Bug
#23436 states it should go into contrib because it depends on jdk1.1
I am not suscribed to debian-java (nor have time to read it), but I think it
is a pity that ALL java software (even *real* free ones) should go into
contrib just because there is not of now a java virtual machine that will
really work. This is not to say that I do not appreciate developer's efforts
on guavac, kaffe, or similar software.

- xswallow

It depends on netscape since it is a plugin for it, I will try it
with mozilla though, if it works I might rename the depends to
to Depends: netscape | mozilla. If not it could be moved onto contrib.
This is ok for main?

Regards

Javi

Re: Which PGP?

[Stephen J. Carpenter]

On Thu, Oct 15, 1998 at 11:36:47AM -0700, Ben Gertzfield wrote:
> > "Dave" == Dave Swegen <[EMAIL PROTECTED]> writes:
> 
> Dave> Out of curiosity, which version of PGP is the debian de
> Dave> facto standard.  I'm currently using v5, but I've seen a
> Dave> number of people use 2.6...
> 
> Debian uses 2.6 for now. 5 is a bit incompatible with other versions,
> and it includes sneaky key escrow systems that people don't trust.

AFAIK those "Key Escrow" sneakness systems are only in the comercial
version and are optional.

(kind o fmakes sense to have a "Company Key" for buisness related stuff
so that if you die tomorow, the company can still recover its data)

> We're actually moving to gpg soon, so this will all be moot. :)

How soon? last I heard it wasn't quite ready yet. 
I would personally lovce to start using gpg at least as a test now...
as long as it wont interfere with my current pgp use too...

any pointers? does mutt support it? I take it it doesn''t use idea/rsa 
lik ePGP does by default?

-Steve

-- 
/* -- Stephen Carpenter <[EMAIL PROTECTED]> --- <[EMAIL PROTECTED]> 
*/
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"

Re: Debian 2.[01] -- Only rudimentary support for Laptops?

[Nathan E Norman]

On Thu, 15 Oct 1998, Alexander Kushnirenko wrote:

 : Hi,
 : 
 : > I have an IBM ThinkPad 380XD.  I have found that 2.0.x kernels just don't
 : > work properly, my machine will crash or shutdown during boot.  I believe 
that
 : > the best thing that can be done to support laptops is to create boot disks
 : > with 2.1.125 kernels.  2.1.125 works well on my laptop in every way and has
 : > fixed the problems with RAM disks that older 2.1.x kernels had.
 : > 
 : 
 : Sorry to jump into discussion... Well, I ABSOLUTELYU agree with Russel.   I 
 : also installed linux on IBM ThinkPad 380XD.  It's my 6-th Debian 
installation 
 : around and definitly the most embarrasing one.  I DO agree that ThinkPad 
380XD 
 : is quite new piece of hardware, and don't want to blame anyone or anything, 
 : but perhaps we may pay closer attention to Laptop instalation problems.
 : 
 : 1. Official booting disketes - DOES NOT work (tecra also!)
 : 2. Official kernel 2.0.34 - DOES NOT work (constant reboot)

I've got a 380Z - a zImage kernel worked for me.  Of course, there is no
official zImage rescue disk :/

--
Nathan Norman
MidcoNet  410 South Phillips Avenue  Sioux Falls, SD
mailto:[EMAIL PROTECTED]   http://www.midco.net
finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9)

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[James Troup]

[EMAIL PROTECTED] writes:

> > binary-only MNU hits only one arch
> > normal NMU hits possible all archs=20
> 
> A binary-only MNU violates the GPL, end of story.

FUD, FUD, FUD and more FUD.  The source changes for our binary-only
NMUs are _always_ sent to the BTS.

Also, please get over this GPL obsession, there is *plenty* of
software in main _not_ covered by the GPL.

-- 
James

[Want to know how Debian violates the GPL all the time?  Check how
many GPLed packages in Debian have modifications yet don't obey 2(a).]

Re: Which PGP?

[James Troup]

Dave Swegen <[EMAIL PROTECTED]> writes:

> Out of curiosity, which version of PGP is the debian de facto standard.
> I'm currently using v5, but I've seen a number of people use 2.6...

2.x; we don't accept later stuff.

-- 
James

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[James Troup]

Hartmut Koptein <[EMAIL PROTECTED]> writes:

>   1. binary-only NMUs breaks policity
>   2. every NMU must be with source
>   3. Porters needn't to ask maintainers for permission
>   4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer
> 
> ok for all ?   

That would be a big fat no.  (1) is patently untrue, (2) is not
happening any time ever and (4) is, with all due respect, stupid
beyond belief.

-- 
James

Re: Removing Packages in Slink for Debian 2.1

[Richard Braakman]

Javier Fdz-Sanguino Pen~a wrote:
>   This is my fault, I should have had more time to fix this (move it
> into non-free) with a new upload, but I don't know how to do this? File a
> bug against ftp.debian.org?

Just upload the package with section non-free/whatever, and it will be
taken care of.

> - xswallow
> 
>   It depends on netscape since it is a plugin for it, I will try it
> with mozilla though, if it works I might rename the depends to
> to Depends: netscape | mozilla. If not it could be moved onto contrib.
>   This is ok for main?

"Depends: mozilla | netscape" would be better for main, particularly since
mozilla is a real package and netscape is virtual.

Note that mozilla itself is listed for removal, because it won't run with
libc6 2.0.7u.  I think it's likely that the bug is in libc6, though.

Richard Braakman

Re: Debian 2.[01] -- Only rudimentary support for Laptops?

[Seth M. Landsman]

On Thu, Oct 15, 1998 at 02:49:19PM -0500, Nathan E Norman wrote:
> On Thu, 15 Oct 1998, Alexander Kushnirenko wrote:
> 
>  : Hi,
>  : 
>  : > I have an IBM ThinkPad 380XD.  I have found that 2.0.x kernels just don't
>  : > work properly, my machine will crash or shutdown during boot.  I believe 
> that
>  : > the best thing that can be done to support laptops is to create boot 
> disks
>  : > with 2.1.125 kernels.  2.1.125 works well on my laptop in every way and 
> has
>  : > fixed the problems with RAM disks that older 2.1.x kernels had.
>  : > 
>  : 
>  : Sorry to jump into discussion... Well, I ABSOLUTELYU agree with Russel.   
> I 
>  : also installed linux on IBM ThinkPad 380XD.  It's my 6-th Debian 
> installation 
>  : around and definitly the most embarrasing one.  I DO agree that ThinkPad 
> 380XD 
>  : is quite new piece of hardware, and don't want to blame anyone or 
> anything, 
>  : but perhaps we may pay closer attention to Laptop instalation problems.
>  : 
>  : 1. Official booting disketes - DOES NOT work (tecra also!)
>  : 2. Official kernel 2.0.34 - DOES NOT work (constant reboot)
> 
> I've got a 380Z - a zImage kernel worked for me.  Of course, there is no
> official zImage rescue disk :/

Hmm, I'm going to have to add a negative data point here.  Debian
installed almost perfectly on my laptop (a Gateway 2300SE) right off of a
CD.  I did have to recompile the kernel for APM stuff and pcmcia
utilities, which was exceedingly painless (for me, that is, YMMV).  I also
had to get and install the NeoMagic X Server manually, but this was before
a package for it existed.

Therefore, I don't think this is laptop installation problems in
general.  I think that this may be specific to some laptops, but not all.

-Seth

--
"It is by will alone I set my mind in motion"