Re: Important Note On Source-Only Uploads

[Joey Hess]

Anthony Towns wrote:
> Basically: don't do them.

Gack. I know several people have counted on this working in the past.
Moreover, it's really a *good* thing, if you don't have a lot of control
over your build environment. Let the autobuilders do it.

> The most important problem this has is how katie (the new dinstall)
> processes it. It goes through the following motions:
>   * check source's md5sums etc
>   * install source into archive
>   * add source to sid
>   * notice source has no binaries in any suite
>   * remove source

Bug in katie, yes?

> Another significant problem with source-only uploads is that (afaik,
> anyway) none of the autobuilders will attempt to build any arch: all
> packages, which would have left both the source only uploads I've noticed
> recently to break anyway.

Hm maybe we need an autobuilder that does arch-all then?

-- 
see shy jo

Re: dpkg-statoverride vs. suidmanager

[Joey Hess]

Aj and I were talking about this, and here's an alternative:

* Make a new suidmanager package that predepends on the new line of dpkg
  packages and, in its preinst, converts everything to use statoverride.
* Dpkg doesn't need any support for suidmanager conversion stuff at all.
* Any package that once used suidmanager and is updated to no longer use
  it, needs to conflict with old version of suidmanager, since installing 
  it on an older system with the old suidmanager will cause it to trample
  over the permissions the user has set.

There's still the problem of how I get packages that call
dh_suidregister to have a versioned conflicts, but I guess that's my
problem, not your problem. :-)

-- 
see shy jo

Re: bugs + rant + constructive criticism (long)

[Adam Heath]

On Tue, 2 Jan 2001, Jim Lynch wrote:

> Hi Eric.
> 
> One of the things you said, is:
> 
> Some packages refuse to install, and of course, break apt in the process.
> Right now, I'm *hopefully* going to be able to repair a totally hosed
> server that failed an apt-get because MAN AND GROFF failed to install
> properly, ending the upgrade process and therefore stopping the install of
> all the perl/debian-perl packages except the binary, rendering apt
> practically useless.
> 

This is more a response to Eric.

On my local system, I have a mostly functioning dpkg --command-pipe.  This
allows apt to start dpkg once, then feed it a series of --install, --unpack,
--configure, --purge, --remove commands, and have dpkg run them in
sequence.  The natural extension to that is --status-pipe, which I have
thought about previously, and will be doing coding on tonight.  See
debian-dpkg@lists.debian.org(or the archives there of) for an actual simulated
apt run using --command-pipe.

BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

Re: bugs + rant + constructive criticism (long)

[Jim Lynch]

One more thing...

You are correct, that developers need to test and not cause syntax errors
before uploading packages, even to unstable or woody. But people do, and
-if- you're using unstable or woody in production, errors and problems you
get are your responsability. If not, file appropriate bugs against the 
relevent packages.

-Jim

Re: bugs + rant + constructive criticism (long)

[Jim Lynch]

Hi Eric.

One of the things you said, is:

Some packages refuse to install, and of course, break apt in the process.
Right now, I'm *hopefully* going to be able to repair a totally hosed
server that failed an apt-get because MAN AND GROFF failed to install
properly, ending the upgrade process and therefore stopping the install of
all the perl/debian-perl packages except the binary, rendering apt
practically useless.


Excuse my tone, but turnabout is fair play...

If this is a potato box, none of the following apply.

But... if you are using woody for -production-, I'm sorry again, but that's
an idiot move... and you know that if you have spent -any- time at all on
OPN, much less enough to get familiar enough to help others on channel.

And if you're talking about -sid-... rotflmao :)

Now being serious: I hope you NEVER advise people on #debian to use
anything not released for production. If I see it, you get devoiced
QUICKLY.

-Jim

Re: bugs + rant + constructive criticism (long)

[Eray Ozkural \(exa\)]

Branden Robinson wrote:
> 
>  You know, kinda like the way I went nuclear on Wichert when he broke vim.

You use vi? Emacs rules.

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Anyone get Evolution 0.8 working?

[Bob Bernstein]

On Tue, Jan 02, 2001 at 05:51:52PM -0800, Bruce Perens wrote:

> Ettore set me straight. The problem is that "oaf" is not looking in
> /usr/local/share/oaf , and if you do the default installation, CORBA
> won't work. Move the contents of /usr/local/share/oaf to /usr/share/oaf .
> Run oaf-slay.  Various GNOME applications die. Start evolution.

Yes, that does it.

It is a continual pain trying to get the prefixes straight with gnome,
mixing and matching Helix stuff and source code.

> There may be a policy question here regarding "/usr/local" and oaf.

I'll be staying tuned! 

Thanks,

-- 
Bob Bernstein
at
Esmond, Rhode Island, USA  

Important Note On Source-Only Uploads

[Anthony Towns]

Hello world,

Basically: don't do them.

In more detail: it's possible, even easy with the recent versions of dpkg,
to do source-only uploads to the archive. That is only upload a diff and a
dsc (and maybe an orig.tgz), without any .debs at all.

The most important problem this has is how katie (the new dinstall)
processes it. It goes through the following motions:
* check source's md5sums etc
* install source into archive
* add source to sid
* notice source has no binaries in any suite
* remove source

The only good thing about the way katie handles this is that it doesn't
delete the old source. It does remove any reference to that source from
the sid Sources.gz file though.

Another significant problem with source-only uploads is that (afaik,
anyway) none of the autobuilders will attempt to build any arch: all
packages, which would have left both the source only uploads I've noticed
recently to break anyway.

There may be other problems, but those are probably showstoppers enough.

Ob!Nike: Just don't do it.

Cheers,
aj

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

 ``Thanks to all avid pokers out there''
   -- linux.conf.au, 17-20 January 2001


pgp7D3mEmxm41.pgp
Description: PGP signature

Re: autodetecting MBR location

[Stephen Zander]

> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes:
Russell> Right.  The s/[0-9]+$// should do it.



s/\d+$// not s/[0-9]+$//.  The former will continue to work in Unicode
capable file-systems (assuming Linux ever supports such).



Nothing to see here, move along...

-- 
Stephen

"And what do we burn apart from witches?"... "More witches!"

Re: IPv6 support in Debian

[Anthony Towns]

On Wed, Jan 03, 2001 at 01:30:50PM +1100, Brian May wrote:
> Is IPv6 a release goal for any future release of Debian ?

Debian doesn't do "release goals" per se. I for one would love to have
Debian work out of the box with IPv6, but the only way for that to happen
is for someone to actually do the work and make various network tools
(all the stuff in standard and above, for a start) work with IPv6...

> The reason I ask is because in bug #80503, one of the responses was
> that IPv6 is not a release goal.

Which isn't at all relevant. If there's a problem with enabling IPv6
support by default (which it sounds like there probably is) then that
needs to be fixed. If there's not, then there's no reason not to change
it. This seems obvious.

But breaking things for ordinary use, just to have IPv6 out of the box
wouldn't be right either.

> However, I consider this attitude wrong, and think that the sooner
> that all packages support IPv6, the better. 

The IPv6 people probably should think about submitting some of their
patches to the real Debian packages at some point then. There still
isn't a bug report against netkit-inetd with an IPv6 patch, for example...

Cheers,
aj

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

 ``Thanks to all avid pokers out there''
   -- linux.conf.au, 17-20 January 2001


pgpS5DlLr3C1w.pgp
Description: PGP signature

Re: IPv6 support in Debian

[Dancer Vesperman]

I was under the impression that ipv6 was a release goal for woody. Not 
necessarily a _total_ showstopper, but more on the 'extremely desirable' 
sort of priority range.

Certainly we have things like exim, lftp, ssh that work 'out of the box' 
with v6...and apps that work with v6 work (equally) flawlessly in 
v4-only environments.

Therefore, my vote for a goal (assuming it counts for anything, which 
point is moot) is that woody itself should include all of those 
v6-out-of-the-box tools, _configured_and_built_that_way_, since the v4 
users will have no trouble with them (at least no more than bugs 
independent of either protocol).

Where we have third-party patches and whatnot (eg KAME), I'm a lot less 
vociferous. This is upstream territory. I wouldn't push a debian 
maintainer to put third-party v6 patches into v4 software. If they WANT 
to do that, well that's dandy, but that confers some responsibility, and 
not everyone will want to do that.

So, in my mind:
1) Upstream apps that support can both v4 and v6 should be configured 
and built as packages to do that as a matter of policy. Good for v6, and 
no loss for v4.
2) Upstream apps that require additional patching for this functionality 
are at the discretion of the maintainer. They can patch it, or bug 
upstream to do it, or just sit on their thumbs.

D
Brian May wrote:
Hello,
I have posted this to both -ipv6 and -devel mailing lists, as I think
it is an important issue to Debian as a whole.
Is IPv6 a release goal for any future release of Debian ?
The reason I ask is because in bug #80503, one of the responses was
that IPv6 is not a release goal.
However, I consider this attitude wrong, and think that the sooner
that all packages support IPv6, the better. This will allow current
IPv6 people more time to fix important IPv6 problems instead of
debating whether or not a change is important enough to be included in
unstable.
Comments?

IPv6 support in Debian

[Brian May]

Hello,

I have posted this to both -ipv6 and -devel mailing lists, as I think
it is an important issue to Debian as a whole.

Is IPv6 a release goal for any future release of Debian ?

The reason I ask is because in bug #80503, one of the responses was
that IPv6 is not a release goal.

However, I consider this attitude wrong, and think that the sooner
that all packages support IPv6, the better. This will allow current
IPv6 people more time to fix important IPv6 problems instead of
debating whether or not a change is important enough to be included in
unstable.

Comments?
-- 
Brian May <[EMAIL PROTECTED]>

Re: ITP: ttf-xtt, xfonts-xtt

[ISHIKAWA Mutsumi]

> In <[EMAIL PROTECTED]> 
>   Arthur Korn <[EMAIL PROTECTED]> wrote:
>> ISHIKAWA Mutsumi schrieb:
>> >  For example, if ttf-xtt-* includes meta datas(fonts.alias,
>> > fonts.scale, tfm and so on) and when only fonts.alias update and
>> > upload. A user would download ttf-xtt-* package (include other files,
>> > they are not updated), if the user use the package only for TeX (not
>> > using for X).This update perhaps would not need the user.

>> How often will the xfonts-* package change without the ttf-*
>> package changing as well? Probably never, at least not the
>> stable packages.

 xfonts-xtt-* packages will change more freqently than ttf-xtt-*
packages(from my experience.)

 For example, ttf-arphic-bkai00mp (this package provide Chinese
TrueType font) was released only once, but xfonts-arphic-bkai00mp
package (X related meta datas to use ttf-arphic-bkai00mp on X)was
released 4th times.

>> The cost of having some bytes more in the Packages.gz that
>> _every_ user has to download (even ppl who don't know japanese)
>> and greater resource usage of apt is much greater than the
>> advantage of not having to download 3.6M once every total
>> eclipse (only for ppl using these packages).

 Yes, this cost is big. But this is not related that `ttf-xtt-*
packages will include fonts.scale, fonts.alias, tfm and other meta
datas' or `proveide separate packages.'

-- 
ISHIKAWA Mutsumi
 <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

Re: Anyone get Evolution 0.8 working?

[Bruce Perens]

Ettore set me straight. The problem is that "oaf" is not looking in
/usr/local/share/oaf , and if you do the default installation, CORBA
won't work. Move the contents of /usr/local/share/oaf to /usr/share/oaf .
Run oaf-slay.  Various GNOME applications die. Start evolution.

There may be a policy question here regarding "/usr/local" and oaf.

Thanks

Bruce

Re: Problem with start-stop-daemon and pidfile

[Adam Heath]

On 3 Jan 2001, Goswin Brederlow wrote:

> set -e
> 
> test -x /usr/sbin/debian-mirror || exit 0
> 
> touch /var/run/debian-mirror.pid
> chown mirror.nogroup /var/run/debian-mirror.pid
> 
> touch /var/log/debian-mirror.log
> chown mirror.nogroup /var/log/debian-mirror.log
> 
> start-stop-daemon -S -m -c mirror:nogroup -u mirror -p 
> /var/run/debian-mirror.pid -x /usr/sbin/debian-mirror 
> >>/var/log/debian-mirror.log &
> --

  -x|--exec program to start/check if it is running

sh is the executable, not /usr/sbin/debian-mirror.

BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

Re: Anyone get Evolution 0.8 working?

[Federico Di Gregorio]

Scavenging the mail folder uncovered Frank Belew's letter:
> -- snip--
> 
> I'm using the debs from
> deb http://spidermonkey.helixcode.com/evolution/distributions/Debian ./
> 
> And evolution runs for me. Can you try these debs and see if they fix 
> any problems for you?

i am using the helix debs on a clean woody install (by clean i mean that
all the gnome packages come from debian apart from the 2-3 not yet in
woody, like gtkhtml, that are from helix.) it works. i won't use it as
my main mua but it works pretty well.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
   Don't dream it. Be it. -- Dr. Frank'n'further

Re: Problem with start-stop-daemon and pidfile

[Goswin Brederlow]

> " " == Adam Heath <[EMAIL PROTECTED]> writes:

 > On 3 Jan 2001, Goswin Brederlow wrote:
>> Hi,
>> 
>> I want to use start-stop-daemon to start the debian-mirror
>> script if its not already running. I don't trust the script, so
>> I run it as user mirror:nogroup.
>> 
>> But then start-stop-daemon can't write a pidfile to /var/run.
>> 
>> Whats the right[tm] way for this?
>> 
>> root:~% start-stop-daemon -S -m -c mirror:nogroup -u mirror -p
>> /var/run/debian-mirror.pid -x /usr/sbin/debian-mirror
>> start-stop-daemon: Unable to open pidfile
>> `/var/run/debian-mirror.pid' for writing: Permission denied

 > Touch the file first, then chown it, before calling s-s-d.


Ok, that helps somewhat. But now start-stop-daemon allways starts the
script.

--
#!/bin/sh
#
# debian-mirror cron script
#
# This will start the debian-mirror script to update the local debian
# mirror, unless its still running.

set -e

test -x /usr/sbin/debian-mirror || exit 0

touch /var/run/debian-mirror.pid
chown mirror.nogroup /var/run/debian-mirror.pid

touch /var/log/debian-mirror.log
chown mirror.nogroup /var/log/debian-mirror.log

start-stop-daemon -S -m -c mirror:nogroup -u mirror -p 
/var/run/debian-mirror.pid -x /usr/sbin/debian-mirror 
>>/var/log/debian-mirror.log &
--

Thats how I start the script know and "ps aux" shows:

mirror   20123  0.5  0.4  2076 1044 pts/3S02:07   0:00 sh -e 
/usr/sbin/debian-mirror
mirror   20125  0.2  0.2  1516  640 pts/3S02:07   0:00 rsync -rlpt 
--partial -v --progress --exclude Packages --delete ftp.de.debian.org 
:debian/dists/sid/Contents-i386.gz /mnt/raid/rsync-mirror/debian/dists/sid/

and cat /var/run/debian-mirror.pid:
20123

But running the script again starts a new instance:

mirror   20123  0.0  0.4  2076 1044 pts/3S02:07   0:00 sh -e 
/usr/sbin/debian-mirror
mirror   20135  0.1  0.4  2076 1044 pts/3S02:07   0:00 sh -e 
/usr/sbin/debian-mirror
mirror   20137  0.0  0.2  1516  696 pts/3S02:07   0:00 rsync -rlpt 
--partial -v --progress --exclude Packages --delete ftp.de.debian.org 
:debian/dists/sid/Contents-i386.gz /mnt/raid/rsync-mirror/debian/dists/sid/
mirror   20143  0.0  0.2  1516  668 pts/3S02:08   0:00 rsync -rlpt 
--partial -v --progress --exclude Packages --delete ftp.de.debian.org 
:debian-non-US/dists/sid/non-US/Contents-i386.gz 
/mnt/raid/rsync-mirror/debian/non-US/dists/sid/non-US/

and cat /var/run/debian-mirror.pid:
20135



So what am I doing wrong there?

MfG
Goswin

Re: Anyone get Evolution 0.8 working?

[Frank Belew]

-- snip--
I'm using the debs from
deb http://spidermonkey.helixcode.com/evolution/distributions/Debian ./
And evolution runs for me. Can you try these debs and see if they fix 
any problems for you?

--
Frank Belew
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Problem with start-stop-daemon and pidfile

[Adam Heath]

On 3 Jan 2001, Goswin Brederlow wrote:

> Hi,
> 
> I want to use start-stop-daemon to start the debian-mirror script if
> its not already running. I don't trust the script, so I run it as user
> mirror:nogroup.
> 
> But then start-stop-daemon can't write a pidfile to /var/run.
> 
> Whats the right[tm] way for this?
> 
> root:~% start-stop-daemon -S -m -c mirror:nogroup -u mirror -p 
> /var/run/debian-mirror.pid -x /usr/sbin/debian-mirror
> start-stop-daemon: Unable to open pidfile `/var/run/debian-mirror.pid' for 
> writing: Permission denied

Touch the file first, then chown it, before calling s-s-d.


BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

Re: Linux Progress Patch for Debian available!

[Paul Hedderly]

On Mon, Jan 01, 2001 at 11:37:17AM -0800, [EMAIL PROTECTED] wrote:
> -- Ferret
> 
> Who recalls a cddb access program designed for blind people where
> cddb.com DENIED a certification because the program couldn't display a
> graphical logo where the blind people could see it.

Presumably no blind person is allowed to use any cddb.com certified
program then. Hmm :O)

-- 
Regards, Paul

Re: upstream packages with bad version number

[Brian May]

> "Ingo" == Ingo Saitz <[EMAIL PROTECTED]> writes:

Ingo> MoiN I just found that some (398) packages which seem to be
Ingo> build from upstream sources contain a bad version
Ingo> string. e.g.:

Ingo> adolc_1.8.7-3.tar.gz an_0.93-1.2.tar.gz an_0.93-2.tar.gz
Ingo> animals_19991226-4.1.tar.gz aolserver_3.0rc2-4.tar.gz
Ingo> apache-perl_1.3.12-1-1.24-2.tar.gz
Ingo> apache-perl_1.3.9-13.1-1.21.2309-1.tar.gz
Ingo> apmd_3.0final-1.tar.gz apt-show-source_0.02-1.tar.gz
Ingo> autobook_1.1-2.tar.gz [...]

Ingo> According to the packaging manual, chapter 5, "the
Ingo> upstream-version may contain only alphanumerics and the
Ingo> characters . + - : [...] if there is no debian-revision then
Ingo> hyphens are not allowed".

Ingo> Because the above packages are upstream sources (really? At
Ingo> least the .tar.gz doesn't contain an .orig in its name)
Ingo> either the version of those packages or the packaging manual
Ingo> needs to be changed.

>From the packaging manual in potato:

"If there is no original source code - for example, if the package is
specially prepared for Debian or the Debian maintainer is the same as
the upstream maintainer - the format is slightly different: then there
is no diff, and the tarfile is named package_version.tar.gz and
contains a directory package-version."

Somewhere just recently I saw someone posting a message saying it was
a good idea if these packages contain a debian revision number - as it
allows distinguishing between a potato build and a woody build for
instance, without changing the upstream version number. As no diff is
used, the full version (including debian revision) must be included in
the tar.gz file.

I would argue that there are two cases:

1. debian revision number is changed because package is rebuilt on a
different system. In which case, why require a new tar.gz file to be
uploaded too?

2. debian revision number is changed because package is changed, for
Debian specific reasons.  In which case, why shouldn't this be
represented as a diff? This has the benefit of using pristine source,
based on the upstream version number.

therefore, I don't see why tar.gz packages should ever contain debian
revision numbers.
-- 
Brian May <[EMAIL PROTECTED]>

Problem with start-stop-daemon and pidfile

[Goswin Brederlow]

Hi,

I want to use start-stop-daemon to start the debian-mirror script if
its not already running. I don't trust the script, so I run it as user
mirror:nogroup.

But then start-stop-daemon can't write a pidfile to /var/run.

Whats the right[tm] way for this?

root:~% start-stop-daemon -S -m -c mirror:nogroup -u mirror -p 
/var/run/debian-mirror.pid -x /usr/sbin/debian-mirror
start-stop-daemon: Unable to open pidfile `/var/run/debian-mirror.pid' for 
writing: Permission denied

May the Source be with you.
Goswin

upstream packages with bad version number

[Ingo Saitz]

MoiN

I just found that some (398) packages which seem to be build from
upstream sources contain a bad version string. e.g.:

adolc_1.8.7-3.tar.gz
an_0.93-1.2.tar.gz
an_0.93-2.tar.gz
animals_19991226-4.1.tar.gz
aolserver_3.0rc2-4.tar.gz
apache-perl_1.3.12-1-1.24-2.tar.gz
apache-perl_1.3.9-13.1-1.21.2309-1.tar.gz
apmd_3.0final-1.tar.gz
apt-show-source_0.02-1.tar.gz
autobook_1.1-2.tar.gz
[...]

According to the packaging manual, chapter 5, "the
upstream-version may contain only alphanumerics and the
characters . + - :  [...] if there is no debian-revision then
hyphens are not allowed".

Because the above packages are upstream sources (really? At least
the .tar.gz doesn't contain an .orig in its name) either the
version of those packages or the packaging manual needs to be
changed.

Ingo
-- 
"Disclosed Source" programs mean software for which the source code is
available without confidential or trade secret restrictions and for which 
the source code and object code are available for distribution without
license charges.

Re: RFC: pools and catagories of packages

[Eray Ozkural \(exa\)]

[EMAIL PROTECTED] wrote:
> 
> I don't know about freshmeat (I only use it for the software search engine),
> but IMHO Sourceforge suffers just as much or probably even more so from the
> current Debian hierarchy problem: too generic or just overcrowded categories.

That's two of the problems I'm trying to address. Another is the structure
of ontology: a single inheritance tree doesn't seem to be sufficient.
Plus, we need a part-of hierarchy as well I'm sure...

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Huh, gcc 2.95.3?

[Toni Mueller]

Hello,

On Mon, Jan 01, 2001 at 07:49:55PM -0500, Ben Collins wrote:
> On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:
> > Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We
> are talking about a stable release here, not a dripping wet development
> snapshot.

fwiw, people I also trust to know what they are doing are shipping
GCC 2.95.3 as their default C compiler _now_ ... in OpenBSD 2.8.
This discussion has happened over there, too, and also led to
the same clarification... rh7 apparently shipped some 2.96 beta.


Best Regards,
--Toni++

Re: Anyone get Evolution 0.8 working?

[Bob Bernstein]

On Tue, Jan 02, 2001 at 09:56:58AM -0800, Bruce Perens wrote:

> I built gtkhtml 0.8 and evolution 0.8 on unstable. Evolution says "Can't 
> initialize the Evolution shell".
> This appears to be a CORBA problem. Before I dive in, has anyone else dealt 
> with it?

Only to the extent you are duplicating _exactly_ my experience with
evolution 0.8 and gtkhtml 0.8, where both are built from source on unstable!

Sorry. 

If you are vouchsafed a solution (by your, or anyone else's, hand) could you
post a heads-up hereabouts?


-- 
Bob Bernstein
at
Esmond, Rhode Island, USA  

Re: X broken after yesterdays dist-upgrade (sid)

[Martin Maciaszek]

On Tue, Jan 02, 2001 at 01:32:00PM +0100, Petr Cech wrote:
> On Tue, Jan 02, 2001 at 12:37:05PM +0100 , Martin Maciaszek wrote:
> > When booting my workstation today I noticed that xdm won't come
> > up. I tried starting X by hand and got the following error
> > messages:
> > 
> > Symbol drmMap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
> > unresolved!
> > Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
> > unresolved!
> > Symbol DRIGetDrawableStamp from module 
> > /usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved!
> > Symbol DRIGetDrawableInfo from module 
> > /usr/X11R6/lib/modues/drivers/mga_drv.o is unresolved!
> > 
> > Can someone explain what happened?
> 
> enable dri in XF86Config - don't know why that's needed.
> 
Duh! That was it. I had to reenable drm and glx to get it working
again.

Cheers
Martin
-- 
This dungeon is owned and operated by Frobozz Magic Co., Ltd.


pgpkW3SbZ9QvN.pgp
Description: PGP signature

Re: ITP: ttf-xtt, xfonts-xtt

[Arthur Korn]

ISHIKAWA Mutsumi schrieb:
>  For example, if ttf-xtt-* includes meta datas(fonts.alias,
> fonts.scale, tfm and so on) and when only fonts.alias update and
> upload. A user would download ttf-xtt-* package (include other files,
> they are not updated), if the user use the package only for TeX (not
> using for X).This update perhaps would not need the user.

How often will the xfonts-* package change without the ttf-*
package changing as well? Probably never, at least not the
stable packages.

The cost of having some bytes more in the Packages.gz that
_every_ user has to download (even ppl who don't know japanese)
and greater resource usage of apt is much greater than the
advantage of not having to download 3.6M once every total
eclipse (only for ppl using these packages).

ciao, 2ri
-- 
"I didn't know it was impossible when I did it."

Re: finishing up the /usr/share/doc transition

[Adrian Bridgett]

On Mon, Jan  1, 2001 at 12:20:32 -0800 (+), Joey Hess wrote:
> Ben Collins wrote:
[snip]
> So it will need to:
> 
> 1. Remove all symlinks in /usr/doc that correspond to
>symlinks or directories with the same names in /usr/share/doc
> 2. If there are any directories with the same names in /usr/doc and
>/usr/share/doc, merge them. (And probably whine about it, since
>that's a bug.)
> 3. Move any remaining directories and symlinks that are in /usr/doc to
>/usr/share/doc
> 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
>but just in case). 
> 5. Remove /usr/doc
> 6. Link /usr/doc to /usr/share/doc

1,3,5,6 need doing (for instance dh_installdocs will install symlinks in
/usr/doc if  /usr/doc exists if /usr/doc/ doesn't exist).  However do
we really need the rest?  It'd be nice I guess, but why not just fix the
packages? 

Adrian

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

ITP ilisp

[Craig Brozefsky]

ILISP is a emacs interface to various lisp-like systems, including
CMUCL and guile (which are already packaged for Debian).

I've already coordinated with the upstream maintainer to have the
debian subdir in the upstream CVS archive.

Anyone get Evolution 0.8 working?

[Bruce Perens]

I built gtkhtml 0.8 and evolution 0.8 on unstable. Evolution says "Can't 
initialize the Evolution shell".
This appears to be a CORBA problem. Before I dive in, has anyone else dealt 
with it?

Thanks

Bruce

Re: POSIX regular expressions (was: autodetecting MBR location)

[Tollef Fog Heen]

*  (Colin Watson)

| >For a non-POSIX regex, that is.
| 
| Could you point me to some documentation about this? regex(7) claims to
| describe POSIX 1003.2 regular expressions, and describes leftmost-first
| behaviour.

Hmm.  Strange.  Mastering Regular Expressions by O'Reilly has
something about this, where they claim otherwise.  I don't have the
POSIX specification so I can check myself, though.

| So is there no correct POSIX regex library in Debian?

No, not if MRE is right.  Which I suppose it is, but am not 100% sure
of, as I haven't read the specs.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: ITP: ttf-xtt, xfonts-xtt

[ISHIKAWA Mutsumi]

> In <[EMAIL PROTECTED]> 
>   Arthur Korn <[EMAIL PROTECTED]> wrote:
>> ISHIKAWA Mutsumi schrieb:
>> >  So, I want to separate TrueType fonts and meta datas such that
>> > fonts.scale and fonts.alias included in xfonts-xtt-*.
>>
>> C'mon, it wont do any harm to ppl who are using LaTeX but not
>> X11 if they have fonts.scale and fonts.alias installed but
>> unused. They are not larger than 100k, are they?

 Yes, they are. xfonts-xtt-* packages are very small.
 And perhaps tfm files will be small too.
 So, if will not inclease meta data files (for other parpus),
these size are no problem, I think too.

 But one more reasen I think better to separate these packages.
ttf-xtt-* includes Japanese TrueType fonts, they are big. these
packages are about 1.4Mbytes each.

 For example, if ttf-xtt-* includes meta datas(fonts.alias,
fonts.scale, tfm and so on) and when only fonts.alias update and
upload. A user would download ttf-xtt-* package (include other files,
they are not updated), if the user use the package only for TeX (not
using for X).This update perhaps would not need the user.


--
ISHIKAWA Mutsumi
 <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

POSIX regular expressions (was: autodetecting MBR location)

[Colin Watson]

Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
>*  (Colin Watson)
>| Contrary to the subconscious assumption many people make, the first
>| priority for a regex is to match earliest, not to match longest.
>| regex(7) specifically mentions this:
>
>For a non-POSIX regex, that is.

Could you point me to some documentation about this? regex(7) claims to
describe POSIX 1003.2 regular expressions, and describes leftmost-first
behaviour. regcomp(3) claims to describe POSIX regex compilation and
execution, and refers to regex(7) and the GNU regex manual for further
documentation. The GNU regex manual (assuming this means the
documentation in librx1g-dev) is ambiguous: it says "In every case like
this, the longer match is preferred", but the example it gives is one of
alternative subexpressions rather than an earliest vs. longest issue.

Furthermore, a brief test program produces output consistent with
earliest matches against both libc6 and librx1g, both of which claim to
provide POSIX regex engines. So is there no correct POSIX regex library
in Debian?

Thanks,

-- 
Colin Watson [EMAIL PROTECTED]

Re: autodetecting MBR location

[Russell Coker]

On Wednesday 03 January 2001 00:24, Tollef Fog Heen wrote:
> | My lilo configuration scripts need to be able to infer the correct
> | location for the MBR.  I am currently using the following algorithm:
> | take root fs device from /etc/fstab and do the following:
> | s/[0-9]*//
> | s/part$/disc/
>
> What is the use of the first s/?  Unless your first letter is a digit,
> it will just remove the zero-width string '' between the first / and
> the beginning of the string.
>
> A better solution will probably be to
>
> s/[0-9]$//
>
> which will remove 5 from /dev/hda5.

Correct.  In my code I have s/[0-9]*$//.  That part of my email was re-typed 
from memory and I missed a character.

The discussion this generated was enlightening though.


On Wednesday 03 January 2001 01:00, Bart Schuller wrote:
> However, stylistically s/[0-9]*// is better written as s/[0-9]+//
> because the case where no digits match is better classified as
> "not a match".

Good point!  I have changed my code accordingly.

On Wednesday 03 January 2001 02:33, Tollef Fog Heen wrote:
> s/\d+// on devfs devices is dangerous, you'll get rid of the host
> number:
>
> perl -e '$_ = "/dev/ide/host0/bus0/target0/lun0/part1"; s/[0-9]+//; print
> $_,"\n"' /dev/ide/host/bus0/target0/lun0/part1

Right.  The s/[0-9]+$// should do it.


Now does anyone have suggestions about what file name I should give to my 
mini-perl program or what else I should do to make it generally usable?

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Huh, gcc 2.95.3?

[zhaoway]

On Tue, Jan 02, 2001 at 12:18:51AM +0100, Matthijs Melchior wrote:
>   Yes, OK,  I was expecting a method that did not require to
> download the full package, just the index and a specific file

then ask a mirror admin to provide the service (i.e. parse deb to get
changelog etc. and post them, oops does package.debian.org do this already?) ;-)

Re: finishing up the /usr/share/doc transition

[Ingo Saitz]

MoiN

On Mon, Jan 01, 2001 at 11:21:42PM +0100, Goswin Brederlow wrote:
> Maybe I have architecure dependent documentation that should not be in
> share.

Architecture dependent files go to /usr/lib, so I'd put them into
/usr/lib//doc. You can symlink them from
/usr/share/doc/package, too. If your documentation are examples,
they go to /usr/lib//examples, as suggested by policy.

Ingo
-- 
"Disclosed Source" programs mean software for which the source code is
available without confidential or trade secret restrictions and for which 
the source code and object code are available for distribution without
license charges.

Re: ITO: zope-popyda, python-popy

[eric]

Dear Debian developers,

We regret to disturb this mailing list, but we feel that the previous
email by Federico di Gregorio was an act of defamation towards PoPy
and ZPoPyDA authors.  We think that our problems with Federico di
Gregorio as a member of Mixadlive S.r.l. board should be independent
with his role as a debian developer, and we can't understand why
internal problems of Federico's society ended up here.  This is a
"private" affair and we think it's questionable behaviour for him to
say these things here, because the Debian community doesn't know and
doesn't supposedly care about our case.

Now, we'd like to get some  points clear.

First of all, we have moved our software to Sourceforge after talking
to Mixadlive CEO, who gave us his agreement.

Furthemore, nobody in Mixadlive ever wrote a line of code, with the
sole exception of autotools code, which was written by Federico. We
didn't request the copyright to be assigned to us, and in fact we'd be
happy to grant all copyright for our work to the Free Software
Foundation if asked to do so.

After the move to Sourceforge, we expressed our anxiety to Federico
about the fact that PoPy and ZPoPyDA latest versions weren't being
uploaded to the Debian distribution.  We emailed him, asking what he
wanted to do with both packages and asking for the possibility to do a
NMU in order to speed up the process of upload.  We didn't get any
response, and we discovered yesterday that Federico had decided to
orphan PoPy and ZPoPyDA without telling us anything.  We have never
asked him to orphan those packages and we have never thought that a
developer reputation was linked solely to having debian packages of
his software around - despite what Federico says, we think that PoPy
and ZPoPyDA would still be some nice software even if packaged with
rpm.

As regards the french debian developers, their unhappiness doesn't
come from the lack of upstreaming  but from Federico's response to
them...

I'm sorry to have to post this here, but enough is enough and I felt a
clarification on our part was needed.

Eric Bianchi
Thierry Michel

Re: autodetecting MBR location

[Tollef Fog Heen]

*  (Colin Watson)

| Contrary to the subconscious assumption many people make, the first
| priority for a regex is to match earliest, not to match longest.
| regex(7) specifically mentions this:

For a non-POSIX regex, that is.

| >However, stylistically s/[0-9]*// is better written as s/[0-9]+//
| >because the case where no digits match is better classified as
| >"not a match".
| 
| True; even s/\d+// or s/\d+$// (assuming that the partition numbers are
| always at the end, even in devfs - I'm not familiar with that).

s/\d+// on devfs devices is dangerous, you'll get rid of the host
number:

perl -e '$_ = "/dev/ide/host0/bus0/target0/lun0/part1"; s/[0-9]+//; print 
$_,"\n"'
/dev/ide/host/bus0/target0/lun0/part1

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

RFP:postgresql 7.1beta1 SGBD

[Christian BAYLE FTRD/DTL/ASR]

Hello

Postgresql 7.1beta1 is now available at
ftp://ftp.postgresql.org/pub/dev/
It is said to be stable
What are your plans to release the package?
Do you have any available version for testing?

Do you have some advice to build this package?

This package is needed to package sourceforge2.5

Thanks

Christian BAYLE

--
E-mail: [EMAIL PROTECTED]
==
P-mail: 28, Chemin du Vieux Chene BP 98 38243 MEYLAN CEDEX
Telephone/Phone : (33) 4 76 76 41 01 Piece/Room A156



begin:vcard 
n:Bayle;Christian
tel;fax:(33/0)476764557
tel;home:(33/0)476541392
tel;work:(33/0)476764101
x-mozilla-html:FALSE
org:FRANCE TELECOM;CNET/DTL/ASR
version:2.1
email;internet:[EMAIL PROTECTED]
title:Research Engineer
adr;quoted-printable:;;28 Chemin du Vieux Chene=0D=0ABP 98;MEYLAN;;38243 CEDEX;FRANCE
x-mozilla-cpt:;27136
fn:Christian Bayle
end:vcard

Re: ITP: ttf-xtt, xfonts-xtt

[Arthur Korn]

ISHIKAWA Mutsumi schrieb:
>  So, I want to separate TrueType fonts and meta datas such that
> fonts.scale and fonts.alias included in xfonts-xtt-*.

C'mon, it wont do any harm to ppl who are using LaTeX but not
X11 if they have fonts.scale and fonts.alias installed but
unused. They are not larger than 100k, are they?

ciao, 2ri

Re: lynx 2.8.4dev.16 --with-ssl

[Colin Watson]

Christoph Martin <[EMAIL PROTECTED]> wrote:
>Since ssl support (configure --with-ssl) is now integrated in the main
>lynx source, will lynx-ssl be obsolete? And will lynx has to go to
>non-US? Or do we still need separate version?

Since lynx is GPLed, surely we shouldn't be linking it to OpenSSL at
all? :( (Unless there's an exception I'm not aware of ...)

-- 
Colin Watson [EMAIL PROTECTED]

Re: autodetecting MBR location

[Colin Watson]

Bart Schuller <[EMAIL PROTECTED]> wrote:
>On Tue, Jan 02, 2001 at 02:24:22PM +0100, Tollef Fog Heen wrote:
>> | s/[0-9]*//
>> | s/part$/disc/
>> 
>> What is the use of the first s/?  Unless your first letter is a digit,
>> it will just remove the zero-width string '' between the first / and
>> the beginning of the string.
>> 
>> A better solution will probably be to 
>> 
>> s/[0-9]$//
>> 
>> which will remove 5 from /dev/hda5.
>
>You seem to know that $ and ^ anchor a match to the end or the beginning
>of a string. So you should also know that in the absence of one of
>these characters, the match may start anywhere in the string. So the
>statement works fine as it is.

That's not true; try it.

  [EMAIL PROTECTED] ~]$ echo /dev/hda1 | perl -pe 's/[0-9]*//'
  /dev/hda1
  [EMAIL PROTECTED] ~]$ echo /dev/hda1 | perl -pe 's/[0-9]+//'
  /dev/hda

Contrary to the subconscious assumption many people make, the first
priority for a regex is to match earliest, not to match longest.
regex(7) specifically mentions this:

   In  the  event  that  an RE could match more than one sub-
   string of a given string, the RE matches the one  starting
   earliest  in  the string.  If the RE could match more than
   one substring starting  at  that  point,  it  matches  the
   longest.

>However, stylistically s/[0-9]*// is better written as s/[0-9]+//
>because the case where no digits match is better classified as
>"not a match".

True; even s/\d+// or s/\d+$// (assuming that the partition numbers are
always at the end, even in devfs - I'm not familiar with that).

-- 
Colin Watson [EMAIL PROTECTED]

Re: autodetecting MBR location

[Tollef Fog Heen]

* Goswin Brederlow 

|  > s/[0-9]$//
| 
|  > which will remove 5 from /dev/hda5.
| 
| You forgot /dev/hda17, which would become /dev/hda1 with your syntax.

you are right.

make that regexp a s/[0-9]+$// instead.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: autodetecting MBR location

[Tollef Fog Heen]

* Bart Schuller 

| On Tue, Jan 02, 2001 at 02:24:22PM +0100, Tollef Fog Heen wrote:
| > | s/[0-9]*//
| > | s/part$/disc/
| > 
| > What is the use of the first s/?  Unless your first letter is a digit,
| > it will just remove the zero-width string '' between the first / and
| > the beginning of the string.
| > 
| > A better solution will probably be to 
| > 
| > s/[0-9]$//
| > 
| > which will remove 5 from /dev/hda5.
| 
| You seem to know that $ and ^ anchor a match to the end or the beginning
| of a string. So you should also know that in the absence of one of
| these characters, the match may start anywhere in the string. So the
| statement works fine as it is.

Not on my box:
$perl -e '$_ = "/dev/hda5" ; s/[0-9]*//; print '; echo
/dev/hda5
$perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
[snip]

It will match the zero-width string between ^ and the first slash.
Leftmost is preferred over longer strings, unless you are using a
POSIX regex engine, where you are required to match the longest
overall.

| However, stylistically s/[0-9]*// is better written as s/[0-9]+//
| because the case where no digits match is better classified as
| "not a match".

No, it is classified as 'match a zero width string' which is a
perfectly acceptable match and a very much different thing than a
non-match.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

lynx 2.8.4dev.16 --with-ssl

[Christoph Martin]

Since ssl support (configure --with-ssl) is now integrated in the main
lynx source, will lynx-ssl be obsolete? And will lynx has to go to
non-US? Or do we still need separate version?

Christoph

-- 

Christoph Martin, Uni-Mainz, Germany
 Internet-Mail:  [EMAIL PROTECTED]
--export-a-crypto-system-sig -RSA-3-lines-PERL--
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/

Re: autodetecting MBR location

[Goswin Brederlow]

> " " == Tollef Fog Heen <[EMAIL PROTECTED]> writes:

 > * Russell Coker | My lilo configuration scripts need to be able
 > to infer the correct location | for the MBR.  I am currently
 > using the following algorithm: | take root fs device from
 > /etc/fstab and do the following: | s/[0-9]*// | s/part$/disc/

 > What is the use of the first s/?  Unless your first letter is a
 > digit, it will just remove the zero-width string '' between the
 > first / and the beginning of the string.

 > A better solution will probably be to

 > s/[0-9]$//

 > which will remove 5 from /dev/hda5.

You forgot /dev/hda17, which would become /dev/hda1 with your syntax.

MfG
Goswin

Re: autodetecting MBR location

[Bart Schuller]

On Tue, Jan 02, 2001 at 02:24:22PM +0100, Tollef Fog Heen wrote:
> | s/[0-9]*//
> | s/part$/disc/
> 
> What is the use of the first s/?  Unless your first letter is a digit,
> it will just remove the zero-width string '' between the first / and
> the beginning of the string.
> 
> A better solution will probably be to 
> 
> s/[0-9]$//
> 
> which will remove 5 from /dev/hda5.

You seem to know that $ and ^ anchor a match to the end or the beginning
of a string. So you should also know that in the absence of one of
these characters, the match may start anywhere in the string. So the
statement works fine as it is.

However, stylistically s/[0-9]*// is better written as s/[0-9]+//
because the case where no digits match is better classified as
"not a match".

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]

Re: autodetecting MBR location

[Tollef Fog Heen]

* Russell Coker 

| My lilo configuration scripts need to be able to infer the correct location 
| for the MBR.  I am currently using the following algorithm:
| take root fs device from /etc/fstab and do the following:
| s/[0-9]*//
| s/part$/disc/

What is the use of the first s/?  Unless your first letter is a digit,
it will just remove the zero-width string '' between the first / and
the beginning of the string.

A better solution will probably be to 

s/[0-9]$//

which will remove 5 from /dev/hda5.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: X broken after yesterdays dist-upgrade (sid)

[Petr Cech]

On Tue, Jan 02, 2001 at 12:37:05PM +0100 , Martin Maciaszek wrote:
> When booting my workstation today I noticed that xdm won't come
> up. I tried starting X by hand and got the following error
> messages:
> 
> Symbol drmMap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
> unresolved!
> Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
> unresolved!
> Symbol DRIGetDrawableStamp from module 
> /usr/X11R6/lib/modules/drivers/mga_drv.o is unresolved!
> Symbol DRIGetDrawableInfo from module /usr/X11R6/lib/modues/drivers/mga_drv.o 
> is unresolved!
> 
> Can someone explain what happened?

enable dri in XF86Config - don't know why that's needed.

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

<_Anarchy_> telsa: rommable debian will be potato chips

autodetecting MBR location

[Russell Coker]

My lilo configuration scripts need to be able to infer the correct location 
for the MBR.  I am currently using the following algorithm:
take root fs device from /etc/fstab and do the following:
s/[0-9]*//
s/part$/disc/

The latter is for devfs.

Now for the benefit of RAID systems I need to do:
if($device =~ /\/dev\/md/)
{
  my $mdname = $device;
  $mdname =~ s/\/dev\///;
  $mdname =~ s/\///;
  my $md = `grep $mdname /proc/mdstat`;
  my @devices = split(" ", $md);
  @devices = sort(@devices[4..$#devices]);
  $root = "/dev/" . $devices[0];
  $root =~ s/\[.*$//;
}

Before the part of:
s/[0-9]*//
s/part$/disc/

The debconf code that Gergely Risko <[EMAIL PROTECTED]> wrote is what I'm 
building on.  Gergely's code has essentially s/[0-9]*// inlined which is ok 
for a non-RAID non-devfs system.  But I want to work with all combinations of 
RAID and non-RAID, devfs and non-devfs and also expand to LVM in the near 
future.  So I can't do that.  I currently plan to put a program to do this 
under /usr/sbin.

Now I have the following questions:
1)  Does anyone have any similar code for doing this that I can merge my code 
with?
2)  Does anyone else need the same code?  If so please tell me what you need 
and I'll make my code as generic as I can.
3)  Can anyone see any obvious bugs in the above?

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

maybe ITP rsync mirror script for pools

[Goswin Brederlow]

Hi,

I've been asked about my rsync mirror script, which is an extension
from Joey Hess's one, on irc and here several times.

So would there be intrest in a deb of the script coming with a debconf
interface for configuration, cronjob or ip-up support and whatever else
is needed to keep an uptodate mirror.

Or do you all prefer to do it your own way? I don't want to package
something just for 2 or 3 people.

MfG
Goswin

PS: Just send me a yes I want privately if you want such a package.

X broken after yesterdays dist-upgrade (sid)

[Martin Maciaszek]

When booting my workstation today I noticed that xdm won't come
up. I tried starting X by hand and got the following error
messages:

Symbol drmMap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
unresolved!
Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/mga_drv.o is 
unresolved!
Symbol DRIGetDrawableStamp from module /usr/X11R6/lib/modules/drivers/mga_drv.o 
is unresolved!
Symbol DRIGetDrawableInfo from module /usr/X11R6/lib/modues/drivers/mga_drv.o 
is unresolved!

Can someone explain what happened?

Cheers
Martin
-- 
If Machiavelli were a hacker, he'd have worked for the CSSG.
-- Phil Lapsley


pgpS1DSoOx9yd.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Goswin Brederlow]

> " " == Erik Hollensbe <[EMAIL PROTECTED]> writes:

 > Some packages refuse to install, and of course, break apt in
 > the process.  Right now, I'm *hopefully* going to be able to
 > repair a totally hosed server that failed an apt-get because
 > MAN AND GROFF failed to install properly, ending the upgrade
 > process and therefore stopping the install of all the
 > perl/debian-perl packages except the binary, rendering apt
 > practically useless.

Try to configure the unpacked packages with "dpkg --configure
--pending". Helps a lot most of the time. Apart from that have a look
at what gets updatet. If you update 200 Packages of unstable in one go
you will kill your system with 99% certainty. Be a bit selective and
do "apt-get install " for the major components like libc,
perl, apt, dpkg before updating all the other stuff.

I know that should not be neccessary, but with unstable, being unstable,
I found that a good way to reduce the likelyhood of unneccessary
packages breaking vital once.

 > No doubt the failure of man and groff has to do with the
 > problem that i've been having with many other packages, which I
 > will detail below.

 > Please, please, please, please... Checking your shell scripts
 > for SYNTAX ERRORS is not a bad idea before you submit it to the
 > package repository!  You have no idea how many times, that I
 > have helped people in #debian on OPN fix shell script errors
 > for packages like mysql-server, which, could have easily
 > rendered a semi-production system completely dead (hopefully
 > they compile from source, but that's not the point, is it?)
 > simply because someone forgot a bracket or used the wrong 'set'
 > parameters in their script.

 > Other issues with apt in general - there is no OBVIOUS way
 > (short of reading the APT/DPKG perl classes) to force certain
 > flags.

RTFM

 > For instance - install package 'realplayer', then, upgrade your
 > copy of xfree86-server or xfree86-common, and watch them fail
 > as it tries to write to a file in /etc/X11. I don't think I
 > need to go into detail about how much stuff like this pisses
 > off the average user. rpm anyone? (no, apt-get -f install does
 > not work, so don't even bother)

Did you file a bugreport?

 > And why are packages being REMOVED (lib-pg-perl for example)
 > when I dist upgrade?

RTFM, thats what dist-upgrade is for. probably a conflicts of some
package updated.

 > apt-get and it's kin need more simple getopt-style flags that
 > allow overriding of certain things, mainly conflicts. Also, an
 > option to actually view what's being upgraded before you
 > download 250 packages that are only going to break your system
 > would be nice as well.

RTFM:

apt-get -u dist-upgrade

Also do an "apt-get -u update" first. That won't change wich packages
are installed, but only update whats possible.

 > I dunno - I was using debian back when hamm was released, and I
 > have never seen such an utter mess of incompatibilities and
 > stupid human error even in the worst mess of unstable upgrades
 > (which happens, and is understandable). Almost all of this is
 > due to a significant lack of adequate testing by package
 > maintainers.

Your are the tester, keep testing and FILE BUGREPORTS.

Alltogether I must say that unstable has become better and better. For
the last 3 years I never had to reinstall stable after an unstable
update. For the last year I didn't need a rescue disk after an
unstable update. For the last month I didn't even had an error on
update (but I haven't updatetd for the last 3 weeks, so that might
explain it).

MfG
Goswin

Re: bugs + rant + constructive criticism (long)

[Paul van Tilburg]

On Tue, Jan 02, 2001 at 02:21:50AM -0500, Mark W. Eichin wrote:
> > actually view what's being upgraded before you download 250 packages that
> 
> That would be "-u", and has been there for a long time (forever?)  My
> only issue is that it isn't the default, really :-)

put:

Apt::Get::Show-Upgraded "true";

in /etc/apt/apt.conf and it IS default.. :)

Paul

~~
Student @ Eindhoven | ICQ: 8678828
University of Technology, The Netherlands   | email: [EMAIL PROTECTED]
>>> Using the Power of Debian GNU/Linux <<< | GPG: finger [EMAIL PROTECTED]

Re: bugs + rant + constructive criticism (long)

[Hamish Moffatt]

On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote:
> However, around the time of the potato release, things in woody especially
> started falling to shit, mainly in stupid QC that could have been easily
> prevented.

[...]

> have easily rendered a semi-production system completely dead (hopefully
> they compile from source, but that's not the point, is it?) simply because
> someone forgot a bracket or used the wrong 'set' parameters in their
> script.

You're running unstable on a production system? Sure, you can do
that, but things might break. We've never pretended otherwise.
Write to us for a full refund.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: bugs + rant + constructive criticism (long)

[Adam Heath]

On Tue, 2 Jan 2001, Branden Robinson wrote:

>  You know, kinda like the way I went nuclear on Wichert when he broke vim.

Just use abiword, who's maintainer never updates it(hi gecko).

BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

Re: finishing up the /usr/share/doc transition

[Hamish Moffatt]

On Mon, Jan 01, 2001 at 02:32:18PM -0800, Joey Hess wrote:
> On the other hand, if we use a script now, we can be done tomorrow.

When will the script be run, and which package will it belong to?
Obviously it cannot be something which must be run manually,
as the update script for Debian 1.3 to 2.0 was.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: bugs + rant + constructive criticism (long)

[Branden Robinson]

On Tue, Jan 02, 2001 at 12:16:21AM -0800, Joey Hess wrote:
> Branden Robinson wrote:
> > Eh?  XFree86 4.x packages weren't held back at all.  I released them to
> > unstable as soon as they were ready.
> 
> This waiting until things are ready before they are released is exactly
> the disturbing trend I was referring to. :-P

By "ready" I don't mean perfect, as a glance at my changelog since 4.0.1-1
will reveal.  I wanted packages that:

  1) had stabilized in their layout (number of packages, their names, and
 contents) so that the package relationship control data didn't stretch
 into the gigabytes
  2) were stable enough that I didn't have wankers filing hundreds upon
 hundreds of redundant bugs in an onanistic frenzy everytime I made some
 little slip-up

 You know, kinda like the way I went nuclear on Wichert when he broke vim.

-- 
G. Branden Robinson |   If you have the slightest bit of
Debian GNU/Linux|   intellectual integrity you cannot
[EMAIL PROTECTED]  |   support the government.
http://www.debian.org/~branden/ |   -- anonymous


pgprCUAqT5UKq.pgp
Description: PGP signature

Re: Boxed Penguin Prototype showcases customization of Debian to build infrastructure server

[Sam Hartman]

> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes:

Bernd> Hello Sam, On Sat, Dec 30, 2000 at 11:27:44PM -0500, Sam
Bernd> Hartman wrote:
>> In order to actually get something done in an electronic
>> office, we need a certain amount of infrastructure.

Bernd> Thanks for your work. I'm now looking into it. I think
Bernd> besides the packages you are working on, for a prototype,
Bernd> most of the work which needs to be done, is have some
Bernd> documentation. Background info and so on. This is at least
Bernd> needed, until your System is truely Plug+Play.

Agreed.  We have finite time and wanted to make stuff available for
people who were interested in looking at it as soon as was reasonable.
We will be working on documentation.  My priorities for documentation
are explaining enough AFS and Kerberos that Debian people can
understand what is going on.  It would also be important to document
exactly what the packages do.




Bernd> Since I currently need to set up a shared Account System on
Bernd> a Few Linux Servers (CVS File Server, SourceForge Project
Bernd> Management and Bugzilla Tracker) I may have a deeper look
Bernd> into writing some docu about it.

Let me know if you have any questions.

Re: Questions about testing

[Anthony Towns]

On Tue, Jan 02, 2001 at 07:03:44AM +, John O Sullivan wrote:
> On Tue, 02 Jan 2001 05:38:36 Branden Robinson wrote:
> > I don't have any concrete recommendations for how to take this into
> > account, but I certainly think that a 14-day waiting period for
> > packages like these is excessive.

I'm not seeing the "excessive"-ness, here, I guess. "testing" isn't a
replacement for unstable: if you want the latest and greatest stuff, and
you don't want to wait for it, you go with unstable.

At the moment, X is a bad example to be using: you're still in the
middle of a huge update and reorganisation with both arm and m68k still
"broken" as far as X is concerned. If you're still updating once a week
or more often by the time everything's stable and working, then... Well,
I dunno, but something.

> I agree with you. Lots of popular packages shouldn't need 2 weeks for
> obvious bugs to be noticed, but I think that most packages should wait
> 2 weeks to get reasonable quality in testing. That means that not all
> packages should have the same waiting time. Is there some way that
> maintainers could take responsibility for deciding how long the
> waiting period should be? 

And again, if the maintainer's got a version done that they think's
suitable for testing, and they're sure it doesn't have any lurking bugs,
they can just set the urgency to 'medium' or 'high'. It's probably not too
unreasonable to treat urgency as "how sure I am this package is fine". For
most packages, you're not too sure; for security updates one would hope the
security team are quite sure that the update is safe.

But really, we're in the first couple of weeks of using this, can we at
least try it as is before worrying about how to tweak it?

> On a slightly related topic, packages that are updated everyday are a
> big headache for those of us that are living at the end of a modem,
> because we have to update many 10's of packages a day == lots of
> downloading. 

You'll note the 14 day rule has the cute property that once a package is
placed in testing, it'll be at least 14 days before it's replaced. (On
the day it gets included in testing, it's also the latest version
uploaded to unstable; if the very next day a new version is uploaded,
it'll still take 14 days before that version is considered for testing
and until then the existing version will just sit there).

Cheers,
aj

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

 ``Thanks to all avid pokers out there''
   -- linux.conf.au, 17-20 January 2001


pgpX4xwVjIdlk.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Joey Hess]

Branden Robinson wrote:
> Eh?  XFree86 4.x packages weren't held back at all.  I released them to
> unstable as soon as they were ready.

This waiting until things are ready before they are released is exactly
the disturbing trend I was referring to. :-P

-- 
see shy jo

Re: bugs + rant + constructive criticism (long)

[Branden Robinson]

On Mon, Jan 01, 2001 at 11:52:16PM -0800, Joey Hess wrote:
> That's not my experience. I've seen breakage, but no more than is
> typical in unstable. In fact I've noticed a degree of holding back on
> releasing major upgrades (X 4, apt 0.4, etc) into unstable that is
> either commendable or a PITA depending on who you ask.

Eh?  XFree86 4.x packages weren't held back at all.  I released them to
unstable as soon as they were ready.  A little before, in fact, since Sean
Perry accused me of "pulling a SuSE" at putting them in Progeny's
distribution at Debian's expense (despite the fact that my pre-release
.debs were available for the whole world to download from the X Strike
Force repository, quite unlike SuSE's pre-releases of yore).

-- 
G. Branden Robinson |
Debian GNU/Linux|Please do not look directly into laser
[EMAIL PROTECTED]  |with remaining eye.
http://www.debian.org/~branden/ |


pgpXPjodqZvRi.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Bernd Eckenfels]

On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote:
> And why are packages being REMOVED (lib-pg-perl for example) when I dist
> upgrade?

Because thats what dist- stands for. If you dont want to remove conflicting
or sperseeded packages, then dont use dist-upgrade but upgrade.

> apt-get and it's kin need more simple getopt-style flags that allow
> overriding of certain things, mainly conflicts. Also, an option to
> actually view what's being upgraded before you download 250 packages that
> are only going to break your system would be nice as well.

you mean -u?

i use "apt-get -ufm". 

But I agree whith you, that essential packages like perl should be checked a
bit more before they shoot you in the foot, but those days are gone! since
they wont pass unstable->testing anymore. So, just dont run 'sid' but woody
and you are fine.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: bugs + rant + constructive criticism (long)

[Joey Hess]

Erik Hollensbe wrote:
> However, around the time of the potato release, things in woody especially
> started falling to shit, mainly in stupid QC that could have been easily
> prevented.

That's not my experience. I've seen breakage, but no more than is
typical in unstable. In fact I've noticed a degree of holding back on
releasing major upgrades (X 4, apt 0.4, etc) into unstable that is
either commendable or a PITA depending on who you ask.

> Some packages refuse to install, and of course, break apt in the process.
> Right now, I'm *hopefully* going to be able to repair a totally hosed
> server that failed an apt-get because MAN AND GROFF failed to install
> properly, ending the upgrade process and therefore stopping the install of
> all the perl/debian-perl packages except the binary, rendering apt
> practically useless.

File a bug. Once you have filed a comprehensive bug report with a log of
the failure and all the information you can think of, page down.









































mv /etc/apt/apt.conf /tmp; dpkg --configure -a ; apt-get upgrade

(This is supposedly fixed in unstable already, so I am eagerly awaiting
that bug report.)

> Please, please, please, please... Checking your shell scripts for SYNTAX
> ERRORS is not a bad idea before you submit it to the package repository!

Joey's law: If you're sure you broke something in your pending upload,
and take the time to test it, it will probably work fine. If you don't,
that one innocuous character change to the postinst is going to hose debian 
and net you 30 bug reports in one day (BTDT).

But you're running unstable, so _you_are_our_QA_. If you don't like it,
use testing.

> Also, an option to
> actually view what's being upgraded before you download 250 packages that
> are only going to break your system would be nice as well.

apt-listchanges

> I dunno - I was using debian back when hamm was released, and I have never
> seen such an utter mess of incompatibilities and stupid human error
> even in the worst mess of unstable upgrades (which happens, and is
> understandable). Almost all of this is due to a significant lack of
> adequate testing by package maintainers.

We're (mostly) human and we only have so much time. Believe me, we do
appreciate unstable users who take the time to make sure a bug has not
been filed already and file a clear and detailed bug report. The rants
I can personally do without.

-- 
see shy jo

Re: bugs + rant + constructive criticism (long)

[Mark W. Eichin]

> actually view what's being upgraded before you download 250 packages that

That would be "-u", and has been there for a long time (forever?)  My
only issue is that it isn't the default, really :-)

> And why are packages being REMOVED (lib-pg-perl for example) when I dist 
> upgrade? 

Because that's specifically what dist-upgrade permits?  If you're
tracking unstable, why not use upgrade?

Frankly, if you're tracking unstable, why are you *ranting* instead of
*submitting bug reports*?  Which part of the word "unstable" didn't
you understand?  (if you were complaining about the "testing" release,
that's a little different, but only a little...)

Re: Questions about testing

[Adam Heath]

On Tue, 2 Jan 2001, John O Sullivan wrote:

> On a slightly related topic, packages that are updated everyday are a
> big headache for those of us that are living at the end of a modem,
> because we have to update many 10's of packages a day == lots of
> downloading. Its not a problem these days, but it was awkward just
> after kde and xfree4 were added to woody. (I'm not trying to dictate
> how people do their job, just pointing out my experiences.) I'd like
> to see some kind of policy that says that in general packages
> shouldn't be updated more than twice a week. I know I'm probably in a
> minority here though and I'll be told to apt-get update twice a week
> ;) but I'd like to hear if there are good reasons why this would be
> bad policy.

So don't upgrade those packages every day.

BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-

bugs + rant + constructive criticism (long)

[Erik Hollensbe]

Sorry for the crosspost, but I wanted to get this to those involved as
such. Hopefully my tone won't sway you, if you read on I think you'll
understand why.

First, I regard debian as the 'best' linux distro out there. I recommend
it to everyone.

However, around the time of the potato release, things in woody especially
started falling to shit, mainly in stupid QC that could have been easily
prevented.

Some packages refuse to install, and of course, break apt in the process.
Right now, I'm *hopefully* going to be able to repair a totally hosed
server that failed an apt-get because MAN AND GROFF failed to install
properly, ending the upgrade process and therefore stopping the install of
all the perl/debian-perl packages except the binary, rendering apt
practically useless.

No doubt the failure of man and groff has to do with the problem that i've
been having with many other packages, which I will detail below.

Please, please, please, please... Checking your shell scripts for SYNTAX
ERRORS is not a bad idea before you submit it to the package repository!
You have no idea how many times, that I have helped people in #debian on
OPN fix shell script errors for packages like mysql-server, which, could
have easily rendered a semi-production system completely dead (hopefully
they compile from source, but that's not the point, is it?) simply because
someone forgot a bracket or used the wrong 'set' parameters in their
script.

Other issues with apt in general - there is no OBVIOUS way (short of
reading the APT/DPKG perl classes) to force certain flags.

For instance - install package 'realplayer', then, upgrade your copy of
xfree86-server or xfree86-common, and watch them fail as it tries to
write to a file in /etc/X11. I don't think I need to go into detail about
how much stuff like this pisses off the average user. rpm anyone? (no,
apt-get -f install does not work, so don't even bother)

And why are packages being REMOVED (lib-pg-perl for example) when I dist
upgrade?

apt-get and it's kin need more simple getopt-style flags that allow
overriding of certain things, mainly conflicts. Also, an option to
actually view what's being upgraded before you download 250 packages that
are only going to break your system would be nice as well.

I dunno - I was using debian back when hamm was released, and I have never
seen such an utter mess of incompatibilities and stupid human error
even in the worst mess of unstable upgrades (which happens, and is
understandable). Almost all of this is due to a significant lack of
adequate testing by package maintainers.

My apologies for anyone I offended.

-- 
Erik Hollensbe <[EMAIL PROTECTED]>
Programmer, Powells Internet Division
"I respect a man who lets me know where he stands, even if he is wrong."
- Malcolm X

Re: Questions about testing

[John O Sullivan]

On Tue, 02 Jan 2001 05:38:36 Branden Robinson wrote:
> 
> Consider that when I manage to hork up X, I know about it within
> hours of
> dinstall.  Likewise, a few days ago when Wichert busted the vim
> postinst,
> he was told about it quite fast indeed.
> 
> I don't have any concrete recommendations for how to take this into
> account, but I certainly think that a 14-day waiting period for
> packages
> like these is excessive.

I agree with you. Lots of popular packages shouldn't need 2 weeks for
obvious bugs to be noticed, but I think that most packages should wait
2 weeks to get reasonable quality in testing. That means that not all
packages should have the same waiting time. Is there some way that
maintainers could take responsibility for deciding how long the
waiting period should be? I don't know very much about the details of
how the archive is managed. I'd suggest a default of 14 days and
probably some minimum time period as well.

On a slightly related topic, packages that are updated everyday are a
big headache for those of us that are living at the end of a modem,
because we have to update many 10's of packages a day == lots of
downloading. Its not a problem these days, but it was awkward just
after kde and xfree4 were added to woody. (I'm not trying to dictate
how people do their job, just pointing out my experiences.) I'd like
to see some kind of policy that says that in general packages
shouldn't be updated more than twice a week. I know I'm probably in a
minority here though and I'll be told to apt-get update twice a week
;) but I'd like to hear if there are good reasons why this would be
bad policy.

cheers,
johno