Re: [Cooker] gaim-0.55-1mdk in /incoming
On Sat, 2002-03-30 at 03:08, Geoffrey Lee wrote: > On Sat, Mar 30, 2002 at 01:30:20AM -0600, Bryan Paxton wrote: > > b88c6b7ca2500790aa08e002d86498b9 gaim-0.55-1mdk.src.rpm > > > > %changelog > > * Mon Mar 30 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-1mdk > > - New release > > - s/libpanel-applet0-devel/libpanelapplet-applet0-devel/ in Build > > requires. > > > > > another one? ;) Yup : ) > btw is there a way to make it work by default for existing gnome and artsd > users .. > gaim will work for everyone (or should), applet will only work for only Gnome users (or those running a gnome panel). I think that's what you were asking? But like I said before, if people who use KDE really like arts, re-enable, it doesn't disrupt any functionality in GNOME, just adds a little bit more binary : ) So, just knock out the --disable-artsc Tashi Delek : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] gaim-0.55-1mdk in /incoming
On Sat, 2002-03-30 at 03:08, Geoffrey Lee wrote: > On Sat, Mar 30, 2002 at 01:30:20AM -0600, Bryan Paxton wrote: > > b88c6b7ca2500790aa08e002d86498b9 gaim-0.55-1mdk.src.rpm > > > > %changelog > > * Mon Mar 30 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-1mdk > > - New release > > - s/libpanel-applet0-devel/libpanelapplet-applet0-devel/ in Build > > requires. > > > > > another one? ;) Yup : ) > btw is there a way to make it work by default for existing gnome and artsd > users .. > gaim will work for everyone (or should), applet will only work for only Gnome users (or those running a gnome panel). I think that's what you were asking? But like I said before, if people who use KDE really like arts, re-enable, it doesn't disrupt any functionality in GNOME, just adds a little bit more binary : ) So, just knock out the --disable-artsc Tashi Delek : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] gaim-0.55-1mdk in /incoming
b88c6b7ca2500790aa08e002d86498b9 gaim-0.55-1mdk.src.rpm %changelog * Mon Mar 30 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-1mdk - New release - s/libpanel-applet0-devel/libpanelapplet-applet0-devel/ in Build requires. Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] postfix 1.1.6, need help -- spec and program
On Thu, 2002-03-28 at 20:28, David Walser wrote:
> Have you read the postfix changelog for versions
> between what Mandrake is shipping and 1.1.6? There's
> a whole bunch of changes that will entail some prep
> work for packagers, it's not just gonna be a simple
> keep your spec update the source kind of switch. I
> suggest reading their ChangeLog and you should get an
> idea of the kinds of things the spec file is going to
> have to do to be able to package current versions of
> Postfix.
Of course I read the Changelog, but the new post install (no pun
intended) is documented horribly.
Regarding prep work, no, nothing really needs to be done, it's all at
%post where the work needs to be done.
>
> There's a way to keep the rpm version comparison thing
> working when you change naming schemes, the Mandrake
> developers were discussing it on this list when
> contemplating the change to an x.x (eg 1.0) versioning
> scheme for OpenOffice. I think it has to do with the
> word epoch.
>
This is in response to Geoffrey Lee as well.
Yes, sadly Epoch will have to be used : P
I've actually got it sorta running now... The error I listed before was
due to a missing file (%{_sysconfdir}/postfix/postfix-files). So now,
'post-install create-missing'
'post-install set-permissions mail_owner=postfix setgid_group=postdrop'
Both need to be run, of course there's the easier but seems dirtier way
is 'post-install upgrade-package'
Regardless, it seems like this script is going to gripe about missing
files anyway (e.g, fails if a pcre table is not found), but doesn't
error out abnormally.
So right now, I'm actually only left with two errors, those being in
the log/main/error file:
fatal: master_spawn: exec /usr/lib/postfix/tlsmgr: No such file or
directory
--
Hmm, not installed...
second (more serious):
fatal: connect #11 to subsystem public/cleanup: Connection refused
--
Haven't a clue... Yet : )
Anyway, that's where I'm at, when I feel like messing around with it
all again, I shall : ) Which will probably be sooner than I even think :
P
Tashi Delek
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
[Cooker] postfix 1.1.6, need help -- spec and program
Ahhh, so this morning I thought it was time to upgrade postfix,
snaged the files, hacked up the spec file, removed and updated patches,
etc... However, there's a fatal within trying to start postfix, which I
didn't have time to figure out.
The spec file is, well, complete. However, there's a few quirks... I
decided in my spec file to go with the new (actually old) version scheme
that postfix is now using, mmddblabla is just e. The only
problem you'll run into here is that when upgrading rpm spits out the
lovely message postfix-20010228-20mdk which is newer than 1.1.6-1mdk is
already installed, *sigh*. So, if someone can figure out a way around
this (other than the suggestions in the mdk-rpm-howto), great.
Furthermore, the fatal. I think this might have to do with the perl
patch which I did not remove. Reason being is that postfix start,
executes postfix-script, which in return attempts to execute
/etc/postfix/post-install, and this is where it errors out.
I don't have the exact error message off hand, and don't particularly
feel like fscking up my MTA again, but it's something along the lines of
/etc/postfix/post-install: fatal: can not open
/etc/postfix/post-install::
The :: at the end really made me go "huh?", but like I said, I don't
get paid to do this, and had/have other things to attend to : p
So, that's pretty much it AFAIK, other than that, I think a switch to
1.1.6 is ready.
Attached is the 1.1.6-1mdk spec file, a diff between the 1.1.6-1mdk spec
file and 20010228-20mdk, and finally an updated main.cf patch.
Bed time now : )
Tashi Delek
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
%define namepostfix
%define version 1.1.6
%define release 1mdk
%define pfixtls_ver 0.8.6
# Note this is onl for pfixtls so you can probably get away with it by
# rebuilding against a new openssl.
%define openssl_ver 0.9.6c
Name: %{name}
Summary:Postfix Mail Transport Agent
Version:%{version}
Release:%{release}
URL:http://www.postfix.org/
#Source0: ftp://postfix.cloud9.net/official/release-%{version}.tar.bz2
Source0:ftp://postfix.cloud9.net/official/postfix-%{version}.tar.bz2
Source1:postfix.aliases
Source2:postfix.cron
Source3:postfix.init
Source4:http://www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix.tar.bz2
Source5:
ftp://ftp.aet.tu-cottbus.de/pub/postfix_tls/pfixtls-%{pfixtls_ver}-%{version}-%{openssl_ver}.tar.bz2
Source6:postfix.pam
Source7:Postfix.conf
Patch: postfix-main.cf.patch.bz2
Patch2: postfix-perlpath.patch.bz2
License:IBM Public License
Group: System/Servers
Provides: smtpdaemon
Provides: MailTransportAgent
Conflicts: sendmail qmail
Requires: procmail
Prereq: /sbin/chkconfig, /usr/bin/wc
BuildRequires: libopenssl0-devel
BuildRequires: libldap2-devel
BuildRequires: libsasl-devel
BuildRequires: db3-devel
BuildConflicts: BerkeleyDB-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
%description
Postfix aims to be an alternative to the widely-used sendmail
program. Sendmail is responsible for 70 percent of all e-mail delivered
on the Internet. With an estimated 100 million users, that's an
estimated 10 billion (10^10) messages daily. A stunning number.
Although IBM supported the Postfix development, it abstains from
control over its evolution. The goal is to have Postfix installed
on as many systems as possible. To this end, the software is given
away with no strings attached to it, so that it can evolve with
input from and under control by its users.
%prep
%setup -q -n postfix-%{version}
tar -jxvf %{SOURCE4}
tar -jxvf %{SOURCE5}
%patch -p1
%patch2 -p1
%build
%serverbuild
make tidy
make makefiles CCARGS="-I/usr/include/openssl -I/usr/include/db3 -DUSE_SASL_AUTH
-DHAS_LDAP -DHAS_DB -DHAS_SSL" AUXLIBS="-lsasl -lldap -llber -ldb -L/usr/lib/ssl
-lssl -lcrypto"
#CCARGS="-I/usr/include/mysql -DHAS_MYSQL" AUXLIBS="-L/usr/lib/mysql -lmysqlclient -lm"
make DEBUG="" OPT="$RPM_OPT_FLAGS"
mv pfixtls-%{pfixtls_ver}-%{version}-%{openssl_ver}/ pfixtls
%install
rm -rf $RPM_BUILD_ROOT
rm -f html/Makefile.in
install -d $RPM_BUILD_ROOT%{_sysconfdir}/cron.daily
install -d $RPM_BUILD_ROOT%{_sysconfdir}/postfix
install -d $RPM_BUILD_ROOT%{_sysconfdir}/pam.d
install -d $RPM_BUILD_ROOT%{_initrddir}
install -d $RPM_BUILD_ROOT%{_bindir}
install -d $RPM_BUILD_ROOT%{_libdir}/postfix
install -d $RPM_BUILD_ROOT%{_libdir}/sasl
install -d $RPM_BUILD_
Re: [Cooker] Bleeding edge stuff is for Mandrake ?
On Wed, 2002-03-27 at 16:30, Geoffrey Lee wrote: > > actually I don't see a problem with using rc software if it's proven to be > more stable and better than the last known "stable" version of the software. > That's what I said : ) "Yet, at the core, it's all software, and it all sucks, sorry to break the bad news : P A stable release can be just as unstable as a cvs snapshot. So, in that respect, it would seem logical that you should simply go with what's working (fcrozat@ demonstrated this well with the Mozilla 0.9.9 dispute before 8.2 was slated final) and not based on the version number (sometimes, a new digit on a version scheme doesn't mean anything *cough* MS *cough*)." Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] Bleeding edge stuff is for Mandrake ?
On Wed, 2002-03-27 at 12:18, Gwenole Beauchesne wrote: > Hi, > > I'm not willing to troll but the following comment is funny: > <https://listman.redhat.com/pipermail/skipjack-list/2002-March/000338.html> > > I wonder who includes Mozilla 0.9.9 and kde3 cvs... > > The comment made in the link above, about "That bleeding edge stuff is for Mandrake.", well... First of all, Mandrake does have a rep for including "unstable" software in production releases. I think as of 8.2 this has vastly changed, and Mandrake is going to show it's stability face to the rest of the world. Second, I don't believe there's one distro (major) who has never included some sort of "unstable" or "pre" || "rc" software in a production release, if someone can think of one, lemme know : ) Take a look at the scandal regarding pretty much all of the major distributions and gcc-2.96... That wasn't even an official version. So, from that view, I think it's very ill on that person's behalf to say that, in what seemed to be a derogatory way. Also, keep in mind that this single individual does not speak for Redhat, and I don't think anyone on this list or any other should be throwing flames at either one. Then you also have to look at who the Redhat audience and their target is, and the same for Mandrake, then you can see why a lot of this done. Yet, at the core, it's all software, and it all sucks, sorry to break the bad news : P A stable release can be just as unstable as a cvs snapshot. So, in that respect, it would seem logical that you should simply go with what's working (fcrozat@ demonstrated this well with the Mozilla 0.9.9 dispute before 8.2 was slated final) and not based on the version number (sometimes, a new digit on a version scheme doesn't mean anything *cough* MS *cough*). I've already spoken too much on the matter, the matter is simply void of that, it doesn't matter. Yet, I will say, GNU/Linux Mandrake is on the right path, and that does matter... -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] Re: [CHRPM] gaim-0.54-3mdk
Too quick for me! : )
And the mirrors take too long to update, so I have no diff : P
>From another email (posting for the list):
/* Begin */
On Wed, 2002-03-27 at 06:17, Geoffrey Lee wrote:
>
> patch is largely ok, just some quick comments on the filelist
Figured as much : )
> gaim_applet should be in applet, that's ok but for the previous main
> filelist we have %_bindir/* so we need to changed that. FIXED.
>
> %doc is redundant.
See below
> %prefix/lib/gaim/* is redundant since we already have that in previous
file
> list. FIXED.
Thought about this further, and the fact remains they are completely
separate packages. However, main does provide just about everything that
gaim_applet needs.
So, I've tuned some things in the spec file (attached), so main (gaim)
is now the core package, and gaim_applet requires gaim to be installed.
# rpm -Uhv gaim-applet-0.54-2mdk.i686.rpm
error: failed dependencies:
gaim >= 0.54 is needed by gaim-applet-0.54-2mdk
: )
> ditto for pixmaps and gnome/apps/Internet/gaim.desktop
Yup : )
> I think for the CORBA server it should belong in the main filelist no?
Got your second email : )
> the Network applets should be ok.
>
>
> the %prefix/share/locale is redundant since we have %find_lang already
> in the main package.
>
Hmmm missed that one : ) Regardless, I stripped the locales from the
applet package, since they'll be provided by gaim.
> btw, just to make a quick comment is that you shouldn't really need to
> define prefix to /usr -- that was the old way of doing it, these days
> there are macros to do this for you like _bindir or _libdir, to see
the
> full list, you can refer back to the rpm rc files. They're actually
> shamelessly ripped from autoconf :)
HAHA
And I just checked 'em out ;)
There's surely some things (see the ChangeLog about the description for
applet : p) that still need cleaning, but here it is!: )
Now I'm off to bed... Yes, I sleep sometimes : )
Tashi Delek
/* EOF */
Now I'm reaaaly off to bed, Tashi Delek to you all! : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
%define name gaim
%define version 0.54
%define release 2mdk
%define perl_version %(rpm -q --qf '%%{VERSION}' perl)
Summary: A GTK+ based multiprotocol instant messaging client
Name: %{name}
Version: %{version}
Release: %{release}
Group: Networking/Instant messaging
BuildRequires: esound-devel gtk+-devel perl-devel
Requires: common-licenses, perl-base = %{perl_version}
License: GPL
Epoch: 1
Url: http://gaim.sourceforge.net
Source: http://download.sourceforge.net/gaim/%{name}-%{version}.tar.bz2
Source1: %{name}_icons.tar.bz2
Patch0: gaim-0.50-smiley.patch.bz2
Patch1: gaim-0.50-autoadd.patch.bz2
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
Gaim allows you to talk to anyone using AOL's
Instant Messenger service (you can sign up at http://www.aim.aol.com).
It uses the TOC version of the AOL protocol, so your buddy list is
stored on AOL's servers and can be retrieved from anywhere.
It contains many of the same features as AOL's IM client while at
the same time incorporating many new features.
Gaim also contains a multiple connection feature which consists of
protocol plugins. These plugins allow you to use gaim to connect
to other chat services such as Yahoo!, ICQ, and IRC.
%package applet
Summary:A GNOME based multiprotocol instant messaging client
Group: Applications/Internet
Requires: gtk+ >= 1.2.5 libpanel-applet0 >= 1.4.0.6 gaim >= %{version}
BuildRequires: gtk+-devel libpanel_applet0-devel esound-devel perl-devel
%description applet
This is the Gnome Gaim applet, see Gaim for details of it's capabilities.
The Gnome Gaim applet sits in your Gnome panel. It has all the same functionality
as the regular application but takes up less desktop space.
%prep
%setup -q -n %name-%version
%patch0 -p1 -b .smiley
%patch1 -p1 -b .autoadd
bzcat %{SOURCE1} | tar xvf -
%build
%configure2_5x --disable-gnome --disable-artsc
%make
if [ -d $RPM_BUILD_ROOT ]; then rm -r $RPM_BUILD_ROOT; fi;
mkdir -p $RPM_BUILD_ROOT%{_prefix}
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
%make -C src mostlyclean-compile
%configure2_5x --enable-distrib --disable-artsc
%make -C src gaim_applet
%install
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
#icons
mkdir -p $RPM_BUILD_ROOT/%{_miconsdir}
mkdir -p $RPM_BUILD_ROOT/%{_liconsdir}
cd $RPM_BUILD
Re: [Cooker] bad $USER in Mandrake 8.2
On Tue, 2002-03-26 at 00:57, Ben Reser wrote: > On Mon, Mar 25, 2002 at 10:54:59PM -0600, Bryan Paxton wrote: > > BTW: Never send out your real username(s) to mailing list, it's a bad > > idea(tm). > > Considering that your username is the same as the first part of your > email address in most cases I don't see how hiding it does that much > good for you. B Always uses aliases on mailing list : ) Night Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] bad $USER in Mandrake 8.2
On Mon, 2002-03-25 at 14:22, Ron Stodden wrote: > Got the answer: > > An su to root creates the environment variable $USERNAME=root. The value > of $USER is not changed. Leaving the superuser state (exit or ^D) > removes $USERNAME. > > This is a change in 8.2 which Mandrake users have NOT been responsibly > notified of beforehand. > > What others are there? > > [user@sQa user]$ su Password: [user@sQa user]# echo $USER root [root@sQa user]# echo $USERNAME root [root@sQa user]# echo $LOGNAME root [root@sQa evil7]# I have no comments, or griefs about any of this, just sending in some form of reproduction. Tashi Delek BTW: Never send out your real username(s) to mailing list, it's a bad idea(tm). -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] gaim-0.54-0.1mdk deposited into incoming
On Sun, 2002-03-24 at 23:34, Geoffrey Lee wrote:
>
> Sorry for the late reply.
n/p : )
>
> I just uploaded the latest version because I can't find yours in
> /incoming
Odd...
First the diff, this is diff between 0.54-mdk1 in cooker and my
0.54-0.3mdk (re-added the smiley patch) spec
diffstat gaim.patch
gaim.spec | 85
+-
1 files changed, 74 insertions(+), 11 deletions(-)
--- gaim.orig.spec Sun Mar 24 23:01:35 2002
+++ gaim.spec Mon Mar 25 00:53:23 2002
@@ -1,11 +1,12 @@
%define name gaim
%define version 0.54
-%define release 1mdk
+%define release 0.3mdk
%define prefix /usr
+%define sysconfdir /etc
%define perl_version %(rpm -q --qf '%%{VERSION}' perl)
-Summary: A client compatible with AOL's 'Instant Messenger'
+Summary: A GTK+ based multiprotocol instant messaging client
Name: %{name}
Version: %{version}
@@ -23,14 +24,41 @@
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
-Gaim allows you to talk to anyone using AOL's Instant Messenger service (you
-can sign up at http://www.aim.aol.com).
+Gaim allows you to talk to anyone using AOL's
+Instant Messenger service (you can sign up at http://www.aim.aol.com).
-It uses the TOC version of the AOL protocol, so your buddy list is stored on
-AOL's servers and can be retrieved from anywhere.
+It uses the TOC version of the AOL protocol, so your buddy list is
+stored on AOL's servers and can be retrieved from anywhere.
-It contains many of the same features as AOL's IM client while at the same time
-incorporating many new features.
+It contains many of the same features as AOL's IM client while at
+the same time incorporating many new features.
+
+Gaim also contains a multiple connection feature which consists of
+protocol plugins. These plugins allow you to use gaim to connect
+to other chat services such as Yahoo!, ICQ, and IRC.
+
+%package applet
+Summary:A GNOME based multiprotocol instant messaging client
+Group: Applications/Internet
+Requires: gtk+ >= 1.2.5 libpanel-applet0 >= 1.4.0.6
+BuildRequires: gtk+-devel libpanel_applet0-devel esound-devel perl-devel
+
+%description applet
+Gaim allows you to talk to anyone using AOL's
+Instant Messenger service (you can sign up at http://www.aim.aol.com).
+
+It uses the TOC version of the AOL protocol, so your buddy list is
+stored on AOL's servers and can be retrieved from anywhere.
+
+It contains many of the same features as AOL's IM client while at
+the same time incorporating many new features.
+
+Gaim also contains a multiple connection feature which consists of
+protocol plugins. These plugins allow you to use gaim to connect
+to other chat services such as Yahoo!, ICQ, and IRC.
+
+The applet sits in your Gnome panel. It has all the same functionality
+as the regular application but takes less desktop space.
%prep
@@ -40,11 +68,16 @@
bzcat %{SOURCE1} | tar xvf -
%build
-%configure --disable-static
+%configure2_5x --disable-gnome --disable-artsc
%make
+if [ -d $RPM_BUILD_ROOT ]; then rm -r $RPM_BUILD_ROOT; fi;
+mkdir -p $RPM_BUILD_ROOT%{prefix}
+%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
+bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
+%make -C src mostlyclean-compile
+%configure2_5x --enable-distrib --disable-artsc
+%make -C src gaim_applet
%install
-rm -rf $RPM_BUILD_ROOT
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
#icons
@@ -88,12 +121,41 @@
%{_miconsdir}/%{name}.xpm
%{_liconsdir}/%{name}.xpm
+%files applet
+%defattr(-,root,root)
+%attr(755,root,root) %{prefix}/bin/gaim_applet
+%doc doc/the_penguin.txt doc/CREDITS NEWS COPYING AUTHORS doc/FAQ README ChangeLog
+plugins/PERL-HOWTO HACKING
+%{prefix}/lib/gaim/*
+%{prefix}/share/locale/*/*/*
+%{prefix}/share/pixmaps/gaim.xpm
+%{prefix}/share/pixmaps/gaim/*
+%{prefix}/share/gnome/apps/Internet/gaim.desktop
+%{sysconfdir}/CORBA/servers/*
+%{prefix}/share/applets/Network/*
+
%clean
rm -r $RPM_BUILD_ROOT
%changelog
-* Mon Mar 25 2002 Geoffrey Lee <[EMAIL PROTECTED]> 0.54-1mdk
-- New and shiny 0.54.
+* Mon Mar 25 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-0.3mdk
+- Place smiley patch back in
+
+* Tue Mar 19 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-0.2mdk
+- Change summary for main && applet (Thx to David Walser)
+- Add Requires libpanel-applet0 >= 1.4.0.6 for applet
+- Add BuildRequires for applet
+
+* Mon Mar 18 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-0.1mdk
+- Updated gaim
+- Changed summary
+- Changed description
+- Added sub package applet (gaim_applet)
+- Use --disable-gnome --disable-artsc for compatibility reasons on %configure
+ in main
+- Remove smiley-patch (broken anyway)
+- use %configure2_5x
+- Removed --disable-static from %configure2_5x (breaks gaim_applet)
+- Define sysconfdir /etc
* Fri Feb 1 200
[Cooker] Re: [CHRPM] gaim-0.54-1mdk
On Sun, 2002-03-24 at 23:16, Geoffrey Lee wrote:
> --=-=-=
> Name: gaim Relocations: (not relocateable)
> Version : 0.54 Vendor: MandrakeSoft
Ahhh, well, I was hoping my new spec file would be used... Curious as
to why it's not?
Below is the spec file cut:
%define name gaim
%define version 0.54
%define release 0.2mdk
%define prefix /usr
%define sysconfdir /etc
%define perl_version %(rpm -q --qf '%%{VERSION}' perl)
Summary: A GTK+ based multiprotocol instant messaging client
Name: %{name}
Version: %{version}
Release: %{release}
Group: Networking/Instant messaging
BuildRequires: esound-devel gtk+-devel perl-devel
Requires: common-licenses, perl-base = %{perl_version}
License: GPL
Epoch: 1
Url: http://gaim.sourceforge.net
Source: http://download.sourceforge.net/gaim/%{name}-%{version}.tar.bz2
Source1: %{name}_icons.tar.bz2
Patch1: gaim-0.50-autoadd.patch.bz2
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
Gaim allows you to talk to anyone using AOL's
Instant Messenger service (you can sign up at http://www.aim.aol.com).
It uses the TOC version of the AOL protocol, so your buddy list is
stored on AOL's servers and can be retrieved from anywhere.
It contains many of the same features as AOL's IM client while at
the same time incorporating many new features.
Gaim also contains a multiple connection feature which consists of
protocol plugins. These plugins allow you to use gaim to connect
to other chat services such as Yahoo!, ICQ, and IRC.
%package applet
Summary:A GNOME based multiprotocol instant messaging client
Group: Applications/Internet
Requires: gtk+ >= 1.2.5 libpanel-applet0 >= 1.4.0.6
BuildRequires: gtk+-devel libpanel_applet0-devel esound-devel perl-devel
%description applet
Gaim allows you to talk to anyone using AOL's
Instant Messenger service (you can sign up at http://www.aim.aol.com).
It uses the TOC version of the AOL protocol, so your buddy list is
stored on AOL's servers and can be retrieved from anywhere.
It contains many of the same features as AOL's IM client while at
the same time incorporating many new features.
Gaim also contains a multiple connection feature which consists of
protocol plugins. These plugins allow you to use gaim to connect
to other chat services such as Yahoo!, ICQ, and IRC.
The applet sits in your Gnome panel. It has all the same functionality
as the regular application but takes less desktop space.
%prep
%setup -q -n %name-%version
%patch1 -p1 -b .autoadd
bzcat %{SOURCE1} | tar xvf -
%build
%configure2_5x --disable-gnome --disable-artsc
%make
if [ -d $RPM_BUILD_ROOT ]; then rm -r $RPM_BUILD_ROOT; fi;
mkdir -p $RPM_BUILD_ROOT%{prefix}
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
%make -C src mostlyclean-compile
%configure2_5x --enable-distrib --disable-artsc
%make -C src gaim_applet
%install
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
#icons
mkdir -p $RPM_BUILD_ROOT/%{_miconsdir}
mkdir -p $RPM_BUILD_ROOT/%{_liconsdir}
cd $RPM_BUILD_DIR/%{name}-%{version}
install -m 644 %{name}_16.xpm $RPM_BUILD_ROOT/%{_miconsdir}/%{name}.xpm
install -m 644 %{name}_32.xpm $RPM_BUILD_ROOT/%{_iconsdir}/%{name}.xpm
install -m 644 %{name}_48.xpm $RPM_BUILD_ROOT/%{_liconsdir}/%{name}.xpm
install -m755 licq2gaim.pl $RPM_BUILD_ROOT/%{_bindir}/licq2gaim
# Menu
mkdir -p $RPM_BUILD_ROOT/usr/lib/menu
cat >$RPM_BUILD_ROOT/usr/lib/menu/gaim < 0.54-0.2mdk
- Change summary for main && applet (Thx to David Walser)
- Add Requires libpanel-applet0 >= 1.4.0.6 for applet
- Add BuildRequires for applet
* Mon Mar 18 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-0.1mdk
- Updated gaim
- Changed summary
- Changed description
- Added sub package applet (gaim_applet)
- Use --disable-gnome --disable-artsc for compatibility reasons on %configure
in main
- Remove smiley-patch (broken anyway)
- use %configure2_5x
- Removed --disable-static from %configure2_5x (breaks gaim_applet)
- Define sysconfdir /etc
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
[Cooker] gaim-0.54-0.2mdk deposited into incoming
45a25a3dfc7fadd0712c754c1c460794 gaim-0.54-0.2mdk.src.rpm * Tue Mar 19 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-0.2mdk - Change summary for main && applet (Thx to David Walser) - Add Requires libpanel-applet0 >= 1.4.0.6 for applet - Add BuildRequires for applet -- Extra info -- For main: Summary: A GTK+ based multiprotocol instant messaging client For applet: Summary: A GNOME based multiprotocol instant messaging client Tashi Delek ; ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] rpm assistance needed (tricky one)
On Tue, 2002-03-19 at 06:29, David Walser wrote: > > --- Bryan Paxton <[EMAIL PROTECTED]> wrote: > > Summary: A Gnome client compatible with AOL's > > 'Instant Messenger' > > Actually, the summary I have on their (the Gaim > people) RPM is more accurate. > > A Gtk+ based multiprotocol instant messaging client > > It's a Gtk+ client, not a gnome one. > I actually thought this is what I had put in (gaim srpm you'll find in cooker 8.x gives that summary), slight error, fixed with one command. I'll leave that up to Lenny and the mdk team to decide on... However, this raises a question, the summary for the applet package should be "A GNOME based multiprotocol instant messaging client." Since, the applet is a GNOME application. P.S. Now that I think about it, requires for the applet Hm, gimme one moment : ) Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] gaim-0.54-0.1mdk deposited into incoming
897fbac80b4aa86fadf3d67a391051bb gaim-0.54-0.1mdk.src.rpm * Mon Mar 18 2002 Bryan Paxton <[EMAIL PROTECTED]> 0.54-1mdk - Updated gaim - Changed summary - Changed description - Added sub package applet (gaim_applet) - Use --disable-gnome --disable-artsc for compatibility reasons on %configure in main - Remove smiley-patch (broken anyway) - use %configure2_5x - Removed --disable-static from %configure2_5x (breaks gaim_applet) - Define sysconfdir /etc [ Yeah yeah, it says 1mdk in the ChangeLog : p] Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] Problem found (rpm build errors on gaim)
Use %makeinstall in the build section... Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] rpm assistance needed (tricky one)
On Tue, 2002-03-19 at 01:08, Bryan Paxton wrote: Forgot to include ~/.rpm* .rpmrc %_topdir /home/evil7/rpm/ %_tmppath /home/evil7/rpm/tmp %_signaturegpg %_gpg_name Mandrake Linux %_gpg_path ~/.gnupg %distribution Mandrake Linux %vendorMandrakeSoft .rpmmacros buildarchtranslate: i386: i586 buildarchtranslate: i486: i586 buildarchtranslate: i586: i586 buildarchtranslate: i686: i586 -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] rpm assistance needed (tricky one)
On Tue, 2002-03-19 at 00:47, civileme wrote:
> >
> Let's see the .spec file and your .rpmrc and .rpmmacros files (that is,
> the ones in /home/evil7
>
> Civileme
>
%define name gaim
%define version 0.54
%define release 1mdk
%define prefix /usr
%define perl_version %(rpm -q --qf '%%{VERSION}' perl)
Summary: A Gnome client compatible with AOL's 'Instant Messenger'
Name: %{name}
Version: %{version}
Release: %{release}
Group: Networking/Instant messaging
BuildRequires: esound-devel gtk+-devel perl-devel
Requires: common-licenses, perl-base = %{perl_version}
License: GPL
Epoch: 1
Url: http://gaim.sourceforge.net
Source: http://download.sourceforge.net/gaim/%{name}-%{version}.tar.bz2
Source1: %{name}_icons.tar.bz2
Patch1: gaim-0.50-autoadd.patch.bz2
BuildRoot: %{_tmppath}/%{name}-buildroot
%description
Gaim allows you to talk to anyone using AOL's
Instant Messenger service (you can sign up at http://www.aim.aol.com).
It uses the TOC version of the AOL protocol, so your buddy list is
stored on AOL's servers and can be retrieved from anywhere.
It contains many of the same features as AOL's IM client while at
the same time incorporating many new features.
Gaim also contains a multiple connection feature which consists of
protocol plugins. These plugins allow you to use gaim to connect
to other chat services such as Yahoo!, ICQ, and IRC.
%package applet
Summary:A Gnome client compatible with AOL's 'Instant Messenger'
Group: Applications/Internet
Requires: gtk+ >= 1.2.5
%description applet
Gaim allows you to talk to anyone using AOL's
Instant Messenger service (you can sign up at http://www.aim.aol.com).
It uses the TOC version of the AOL protocol, so your buddy list is
stored on AOL's servers and can be retrieved from anywhere.
It contains many of the same features as AOL's IM client while at
the same time incorporating many new features.
Gaim also contains a multiple connection feature which consists of
protocol plugins. These plugins allow you to use gaim to connect
to other chat services such as Yahoo!, ICQ, and IRC.
The applet sits in your Gnome panel. It has all the same functionality
as the regular application but takes less desktop space.
%prep
%setup -q -n %name-%version
%patch1 -p1 -b .autoadd
bzcat %{SOURCE1} | tar xvf -
%build
%configure2_5x --disable-static -disable-gnome --disable-artsc
%make
if [ -d $RPM_BUILD_ROOT ]; then rm -r $RPM_BUILD_ROOT; fi;
mkdir -p $RPM_BUILD_ROOT%{prefix}
%make prefix=$RPM_BUILD_ROOT%{prefix} install
%make -C src mostlyclean-compile
%make -C src gaim_applet
%install
%makeinstall bitsdata=$RPM_BUILD_ROOT/%{_datadir}
bitssysconf=$RPM_BUILD_ROOT/%{_sysconfdir}
#icons
mkdir -p $RPM_BUILD_ROOT/%{_miconsdir}
mkdir -p $RPM_BUILD_ROOT/%{_liconsdir}
cd $RPM_BUILD_DIR/%{name}-%{version}
install -m 644 %{name}_16.xpm $RPM_BUILD_ROOT/%{_miconsdir}/%{name}.xpm
install -m 644 %{name}_32.xpm $RPM_BUILD_ROOT/%{_iconsdir}/%{name}.xpm
install -m 644 %{name}_48.xpm $RPM_BUILD_ROOT/%{_liconsdir}/%{name}.xpm
install -m755 licq2gaim.pl $RPM_BUILD_ROOT/%{_bindir}/licq2gaim
# Menu
mkdir -p $RPM_BUILD_ROOT/usr/lib/menu
cat >$RPM_BUILD_ROOT/usr/lib/menu/gaim < 0.54-1mdk
- Updated gaim
- Changed summary
- Changed description
- Added sub package applet
- Use --disable-gnome --disable-artsc for compatibility reasons on %configure
- Remove smiley-patch (broken anyway)
- use %configure2_5x
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
Re: [Cooker] rpm assistance needed (tricky one)
On Tue, 2002-03-19 at 00:43, Anthony Symons wrote: > > Check the permissions on /usr/lib/ and /usr/lib/gaim, then check those > files exist and the permissions on them What user are you? You should > probably be installing as root. Owned by moi, and when I say %install, I mean install to the virtual system for packaging. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] rpm assistance needed (tricky one)
I'm getting a permission denied on %install, problem is finding out where the permission denied is coming from. Can't strace as a normal user, so that's out of site : ) No it's not my kernel patches (ruled that out by booting into the default mdk kernel). And finally, no it's not the permissions on ~/rpm/* dev tools? Maybe, but I have full access on my system to them, further more, I had no problem building and installing garnome the other day to ~/garnome So, here is what happens at %install + '[' -d /home/evil7/rpm/tmp/gaim-buildroot ']' + make -j2 prefix=/home/evil7/rpm/tmp/gaim-buildroot/usr install Making install in m4 make[1]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/m4' make[2]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/m4' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/m4' make[1]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/m4' Making install in sounds make[1]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/sounds' make[2]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/sounds' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/sounds' make[1]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/sounds' Making install in plugins make[1]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/plugins' make[2]: Entering directory `/home/evil7/rpm/BUILD/gaim-0.54/plugins' make[2]: Nothing to be done for `install-exec-am'. /bin/sh ../mkinstalldirs /usr/lib/gaim /usr/bin/install -c -m 644 ./autorecon.so /usr/lib/gaim/autorecon.so /usr/bin/install: cannot remove `/usr/lib/gaim/autorecon.so': Permission denied /usr/bin/install -c -m 644 ./autoadd.so /usr/lib/gaim/autoadd.so /usr/bin/install: cannot remove `/usr/lib/gaim/autoadd.so': Permission denied /usr/bin/install -c -m 644 ./chatlist.so /usr/lib/gaim/chatlist.so /usr/bin/install: cannot remove `/usr/lib/gaim/chatlist.so': Permission denied /usr/bin/install -c -m 644 ./iconaway.so /usr/lib/gaim/iconaway.so /usr/bin/install: cannot remove `/usr/lib/gaim/iconaway.so': Permission denied /usr/bin/install -c -m 644 ./notify.so /usr/lib/gaim/notify.so /usr/bin/install: cannot remove `/usr/lib/gaim/notify.so': Permission denied /usr/bin/install -c -m 644 ./spellchk.so /usr/lib/gaim/spellchk.so /usr/bin/install: cannot remove `/usr/lib/gaim/spellchk.so': Permission denied make[2]: *** [install-pluginDATA] Error 1 make[2]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/plugins' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/evil7/rpm/BUILD/gaim-0.54/plugins' make: *** [install-recursive] Error 1 error: Bad exit status from /home/evil7/rpm/tmp/rpm-tmp.98467 (%build) Any ideas? Shoot 'em my way : ) Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] Back to fixing bugs
Ok! So here we go... For some reason, which I'm oblivious to, the native gaim pixmaps are not being installed into the build root when --enable-panel is passed to configure. >From %install /bin/sh ../mkinstalldirs `/usr/bin/gnome-config --datadir`/pixmaps/gaim /usr/bin/install -c -m 644 away.png /usr/share/pixmaps/gaim/away.png /usr/bin/install -c -m 644 connect.png /usr/share/pixmaps/gaim/connect.png /usr/bin/install -c -m 644 msgpend.png /usr/share/pixmaps/gaim/msgpend.png /usr/bin/install -c -m 644 offline.png /usr/share/pixmaps/gaim/offline.png /usr/bin/install -c -m 644 online.png /usr/share/pixmaps/gaim/online.png /bin/sh ../mkinstalldirs `/usr/bin/gnome-config --datadir`/pixmaps /usr/bin/install -c -m 644 gaim.xpm /usr/share/pixmaps/gaim.xpm /bin/sh ../mkinstalldirs make[2]: Leaving directory `/usr/src/RPM/BUILD/gaim-0.51/pixmaps' make[1]: Leaving directory `/usr/src/RPM/BUILD/gaim-0.51/pixmaps' Finally at the end of it all we get our lovely error and exit message. RPM build errors: File not found by glob: /var/tmp/gaim-buildroot/usr/share/pixmaps/* My question is, does some prep work need to be done? If not, what then? If I can find the answer to this question (which I'm sure is quite simple), I believe I can go in and fix quite a few spec files (spec files without my adjustments that flake out like this). Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] Frustration
On Mon, 2002-03-18 at 13:41, Ben Reser wrote: > That's my 2 cents on the issue and all I'm going to say... > Much agreed... So much, that I really don't have anything to add. As I said before, cooker used to be lots of fun (e.g., prior to 8.x). That fun has seemed to be stripped... Then again, you have to look at it from the mdksoft perspective, that they do have a deadline to meet, and I think there's quite a bit of frustration on both ends. Where does my frustration lie? Ideas that I expounded that I have never gotten credit for, fixes I have never gotten credit for, fixes/idea that were never even acknowledged, etc... However I buried the hatchet, so to speak, what's done is done. On 8.2 devel... As I said in a private email with one of the mdksoft developers, I do admit during this release, I came in a bit late, emailing in quite a few false-positives, this surely caused frustration on the mdksoft side (e.g., hunting for bugs that were not there). For this I apologize... With that said, we begin again... A clean slate. I think one thing needs to always be kept in mind... Management especially should heed to this... This is a community. Each side depends upon each other, one can not, in no way, in a right way, co-exist without the other. Understanding that development of any open-source/free software is mutual can only speed up, quality, intuitiveness, and integrity of the project. Now, let the games begin : ) (after a short break of course : p) Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] Odd, but good
ImageMagick now compiles without a hitch now... (all files found). I assume it's because of the last change " - removed rpath in perl Magick.so library.", yet I seem to recall this being an old ChangeLog entry? Oh well, it's a working now : ) Secondly, hdf5 now compiles (compile time error previously). What's odd about this is that there's been no update to the hdf5 spec (patches, sources, etc..) AFAIK. The only thing I can conclude is that I went down for a reboot this morning. Please say this isn't what fixed the build : P Also! armagetron now compiles (compile time error previously as well), and once again no update to the source or spec AFAIK. The only thing I can conclude is that I went down for a reboot this morning. Please say this isn't what fixed the build : P So, that leaves two packages on my list that won't compile: locales -- core dumps locally, I'm sure you've seen the posts, and this would be a glibc problem; and perl-DB_File -- fails test 86. That's all for now : ) Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] zlib in cooker
On Wed, 2002-03-13 at 11:25, Gwenole Beauchesne wrote: > On 13 Mar 2002, Bryan Paxton wrote: > > > (GC noted correctly that gcc may/may not honor the env var) > > Again, MALLOC_CHECK_ (note the trailing '_'!) doesn't have anything to do > with gcc. > > [gb@no vrac]$ MALLOC_CHECK_=1 ./2free > malloc: using debugging hooks > free(): invalid pointer 0x8049678! > Program ran to completion. > > Expected result. Note the trailing '_' in MALLOC_CHECK_ env var name. > : ) Sleep is good : ) Night -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] zlib in cooker
On Wed, 2002-03-13 at 10:48, Guillaume Cottenceau wrote: > Bryan Paxton <[EMAIL PROTECTED]> writes: > > > I think you misunderstood the problem. The patch doesn't fix the > fact that doing a double free will segfault your program. The > patch removes a double-free in zlib, which could lead to segfault > and/or compromise in zlib and in programs using zlib. Ahhh, I see... The intention of the email was to get everyone to shut up about zlib not being patched : ) The extra was > > The fact that MALLOC_CHECK may no be honoured by gcc is a very > different thing in fact! See the next email for that (a.k.a patch working)... -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
[Cooker] zlib in cooker
Ok, here's the dealio (don't know if internal knows, so apologies if
this is known):
zlib in cooker is patched to fix the double free() sec bug...
However, this patch has not fixed (at least from my end) the problem...
First of all, never count on WUIs for up-to-date info!
To the point:
$ bzcat ../SOURCES/zlib-1.1.3-zfree.patch.bz2
diff -ruN zlib-1.1.3.orig/infblock.c zlib-1.1.3/infblock.c
--- zlib-1.1.3.orig/infblock.c Mon Jun 8 19:06:16 1998
+++ zlib-1.1.3/infblock.c Thu Feb 7 11:41:57 2002
@@ -249,10 +249,11 @@
&s->sub.trees.tb, s->hufts, z);
if (t != Z_OK)
{
-ZFREE(z, s->sub.trees.blens);
r = t;
-if (r == Z_DATA_ERROR)
+if (r == Z_DATA_ERROR) {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BAD;
+ }
LEAVE
}
s->sub.trees.index = 0;
@@ -313,11 +314,12 @@
t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) &
0x1f),
s->sub.trees.blens, &bl, &bd, &tl,
&td,
s->hufts, z);
-ZFREE(z, s->sub.trees.blens);
if (t != Z_OK)
{
- if (t == (uInt)Z_DATA_ERROR)
+ if (t == (uInt)Z_DATA_ERROR) {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BAD;
+ }
r = t;
LEAVE
}
@@ -329,6 +331,7 @@
}
s->sub.decode.codes = c;
}
+ ZFREE(z, s->sub.trees.blens);
s->mode = CODES;
case CODES:
UPDATE
$
Patch is there, has been for a while... (since Feb FYI).
However, as stated above the patch does not fix (REPEAT: This is from my
end, my system) the hole:
$ rpm -q zlib1
zlib1-1.1.3-19mdk
$ cat 2free.c
#include
#include
int main(int argc, char* argv[]) {
void* foo = malloc(16);
free(foo);
free(foo);
printf("Program ran to completion.\n");
}
$ export MALLOC_CHECK=2 && gcc -o 2free 2free.c && ./2free
Segmentation fault (core dumped)
$
So, that is the "dealio" : )
Tashi Delek : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
Trying, the volition devoid of action, this is idleness.
Doing, the volition replete in motion, a process.
Being that all things are impermanent, this process is constant.
If one realizes such, the process is in all actuality, one step.
A motion that can not be reversed, but may be halted.
Both ways does this sway.
Re: [Cooker] Suggestion - devtools group
On Wed, 2002-03-13 at 02:16, Kevin Krumwiede wrote: > I love the way access to network utilities is controlled by assigning them > to the ntools group. I think the same should be done with development > tools. > > Krum > Thank you :) It does (or at least it's supposed to, I'm not touching the new msec port until I understand it good and well... and after this freeze) ctools group. Of course, this still leaves perl at users disposal, but there's not much of a safe way of disabling perl to normal users, since it's needed by so many programs (not to mention cgi), this would be like preventing users from executing bash || tcsh || ksh || sh. Tashi Delek : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] Money
On Wed, 2002-03-13 at 01:14, Levi Ramsey wrote: > On Wed Mar 13 10:51 +0800, Leon Brooks wrote: > > Re the article on Mandrake's home page at the moment, just how much does > > Mandrake need to take in so that they stay afloat for the few months needed > > to reach profitability? > > The figure I've heard is that 10,000 members is the goal. Since I think > 2000 or so were members before, that implies a minimum of $480,000. > 8,000 members : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg Trying, the volition devoid of action, this is idleness. Doing, the volition replete in motion, a process. Being that all things are impermanent, this process is constant. If one realizes such, the process is in all actuality, one step. A motion that can not be reversed, but may be halted. Both ways does this sway.
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
This was _NOT_ meant to go to the list. Please do not get involved or respond, or even acknowledge this email. Much apologies. On Tue, 2002-03-12 at 04:34, Bryan Paxton wrote: > Hey, > Is there some problem you have with me? > I mean if there is, I'd like to get it straightened out. > There _seems_ to be a lot of hostility coming from you to me... > Especially in reply to all this mozilla crap. You did see the email I > had sent out _RIGHT_ after the first one, no? > -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
Hey, Is there some problem you have with me? I mean if there is, I'd like to get it straightened out. There _seems_ to be a lot of hostility coming from you to me... Especially in reply to all this mozilla crap. You did see the email I had sent out _RIGHT_ after the first one, no? I honestly do not care if mozilla 0.9.9 would go in 8.2 or not, I build all my software from source anyway... I sent that email in to let users know a) 0.9.9 had been released and b) it fixed Flash (among numerous other things). While, I don't see any harm in putting 0.9.9 into 8.2, since 0.9.8 is fscked up to hell anyway, the fact remains I did not mean to cause any disruption (if you read my other mail, you'll see that I can be quite conservative in freezes). Anyway, I would like that we got along, I don't remember you and I ever having any kind of hostility between the two of us. I do admit I can be quite hasty when it comes to squashing bugs, but I'm usually like so for a reason, and it usually gets things fixed (if I'm not able to put together a fix myself). Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Tonight: rebuilding an entire Mandrake distro fromscratch!
On Tue, 2002-03-12 at 02:47, R.I.P. Deaddog wrote: > On 12 Mar 2002, Bryan Paxton wrote: > Seems it's only you who faces problem here. If RPM fails to find > *-config scripts, then it's usually because installation already fails, > not because the perl regex caused them to disappear. Did you check the > whole build log? > I checked the friggin build dir, the files are there. No errors during build, it goes just fine. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
On Tue, 2002-03-12 at 02:45, Buchan Milne wrote: > The other issue with Mozilla, is that an upgrade normally breaks > Nautilus. I think most would agree that messing with nautilus while > we're in RC is not a good idea. > > Nevertheless, I will probably put together a mozilla rpm for myself, and > post a url for the brave later ... > Rebuild nautilus against moz 0.9.9, all is fine. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
On Tue, 2002-03-12 at 00:37, Frédéric Crozat wrote: > Le Tue, 12 Mar 2002 05:37:14 +0100, Bryan Paxton a écrit : > These bugs are OPEN !!! They are known ISSSUES !! > > Meaning, they are NOT fixed.. (not even on 1-0 branch..) My other email obviously didn't get through, see the one in reply to Byron Poland. Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
On Mon, 2002-03-11 at 22:41, Byron Poland wrote: > fixes > > SEVERAL bugs. The most important to any user: > > > > Linux: Flash may crash with exported X display. (Bug 58937) > > > > Linux: On Linux, there may be problems with ESD Audio and Flash. (Bugs > > 85772) > > I think you mis-read the rel-notes, those are known issues, that are > unresolved.. I check on Bug 58937 all the time because I use a diskless > X terminal in my bedroom, and have lots of trouble with certian sites > because of this bug. As of tonight Bug 58937 is still listed as > assigned. > > still it would be nice to have the new release in 8.2 but if not, it > will be one of the first things to change when cooker is thawed so it > should be easy to update. Yes yes, I was in a hurry to get out the news. I sent in another email, I've been so busy I'm not sure if it got through or not, in case it didn't: On Mon, 2002-03-11 at 22:37, Bryan Paxton wrote: > > http://mozilla.org/releases/mozilla0.9.9/ > > It's xmas for me every time a mozilla release rolls out : ) > > Anyway, to the point... > > In a freeze? Yes, but this is a critical update. > This release aside from tuning and enabling some nice features, fixes > SEVERAL bugs. The most important to any user: > I get ahead of myself some times : ) Flash plugin is now working again, never mind the assigned bugs I posted. This was the important fix I was trying to say (aside from the fix regarding the zlib double free() hole). I simply was in a rush to get the news to this list ; ) > > I think that speaks for itself... > > : ) > Fear the dragon! /* EOF */ : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Tonight: rebuilding an entire Mandrake distro fromscratch!
On Tue, 2002-03-12 at 00:18, Leon Brooks wrote: > On Tuesday 12 March 2002 13:26, Bryan Paxton wrote: > > On Mon, 2002-03-11 at 23:07, Leon Brooks wrote: > >> Do I need anything else to completely rebuild an installable Cooker CD > >> set from source? See below > > One thing I forgot to ask you about is a step-by-step thingy. I was planning > on first reconstructing a set of CDs from binary-scratch, then trying it > again from source-scratch. What scripts etc did you use? Do you have a little > list? A howto would indeed be nice : ) But there's not one. The building, well I did it by hand, but this was for debugging reasons. I'm sure someone on the mdk team has a kind of 'make world' script? Aside from that, I think everything you need is in i586/ There was a long thread about making your own cd, search the archives on that. > I seem to remember a message between Mandrake-employee list members (maybe > Warly?) about having a 'bot which rebuilds stuff regularly. Is that kicking > around anywhere? > Hmmm yeah, I think so, I don't know what it is, and what it does though : P, back to that 'make world' type script I was talking about : P If one exists. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Tonight: rebuilding an entire Mandrake distro fromscratch!
On Mon, 2002-03-11 at 23:40, Leon Brooks wrote: > > > I sucessfully built 771 packages (the ones I use : p), only a few I > > could not build, these being the following: > > armagetron-i586 => armagetron-0.1.4.9-6mdk.src.rpm > > ImageMagick-i586 => ImageMagick-5.4.2.3-1mdk.src.rpm > > libhdf5_0-devel-i586 => hdf5-1.4.2p1-1mdk.src.rpm > > libhdf5_0-i586 => hdf5-1.4.2p1-1mdk.src.rpm > > libMagick5-i586 => ImageMagick-5.4.2.3-1mdk.src.rpm > > locales-en-i586 => locales-2.3.1.2-8mdk.src.rpm > > locales-i586 => locales-2.3.1.2-8mdk.src.rpm > > perl-DB_File-i586 => perl-DB_File-1.802-1mdk.src.rpm > > > If you would like reasons why these packages couldn't build, shout out : > > ) (locales is being looked into...) > > Off-list would be good, thanks! locales: localedef is hrm broken (at least from my end), segfaults, reason unknown. Search the mail archives, I made a few posts about this. armagetron: eh, bad code or patch iirc ImageMagick: Compiles fine, but there's some wierd perl regex going on inside that spec file which makes it impossible for RPM to find Magick++-config and other scripts/programs/whatever in the devel package. perl-DB: Fails during tests, thus it exits : ) hdf5: Hmm I don't remember why on this one > This should probably be fixed for posterior^H^H^Herity. Yup, it should... Whether it does or not remains to be seen : p > > P.S. Results afterwards please? : ) > > Hokay! : ) > Cheers; Leon > Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] msec: excessive assumptions in networked environment,and solution
On Mon, 2002-03-11 at 22:45, Ben Reser wrote:
>
> While this is probably too late for 8.2. Why don't we make msec do the
> following. Use getpwent to enumarte the passwd file and enforce
> permissions on home directories? And something similar for NIS and ldap
> users (I'm not sure if getpwent() returns these users)?
>
> This prevents hosing peoples setups but still achieves the security
> protections that msec is trying to achieve.
>
I tried to stay out of this, since I have my own little tid bits with
msec and it's course of development, but like you said. It is rather
late for any changes like that.
Anyway, getpwent() surely does...
Example in C
char_dest[80];
struct passwd *_home;
struct stat _dest_stat;
struct stat _bin_stat;
int
main(void)
{
clearenv();
setenv("PATH", "/bin:/usr/bin:/usr/local/bin", 1);
setenv("IFS", " \t\n", 1);
_home = getpwent();
strncat(_dest, _home->pw_dir, 30);
printf(" You live in %s\n", _dest);
exit(0);
}
Just have it loop(for i...) and pull a chmod() on i
> What difference does it make to the dead, the orphans, and the homeless,
> whether the mad destruction is wrought under the name of totalitarianism
> or the holy name of liberty and democracy? - Ghandi
>
Great quote : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Now, smell the rain of london, it still insists...
That we bed for our purity.
As if we are pure in the rain of our contentment!
As if I can think of this no more!"
-- Jeff Buckley
[Cooker] Join! http://www.linux-mandrake.com/en/mdkfuture.php3
I was opposed to joining this membership club thing (It wasn't appealing to me), but as said right here: "Entry-level membership to the Mandrake Users Club is only $5 per month, which is less than one ticket to the movies. Is the future of the Mandrake Linux distribution worth that much to you? If yes, then don't delay -- join the Club today." Mandrakesoft (Linux-Mandrake) and its employees are well worth that much... I'm signing up now, join me! : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Tonight: rebuilding an entire Mandrake distro fromscratch!
On Mon, 2002-03-11 at 23:07, Leon Brooks wrote: > Tonight, I'm going to come over all ambitious and download a fresh Cooker > (presumably rc1) binary directory tree at tonight's bandwidth party (starts > at 19:30+08), plus a copy of all of the SRPMs. > > Do I need anything else to completely rebuild an installable Cooker CD set > from source? > > To clarify: I want to install Cooker on an otherwise bare machine, and build > two specialised cooker CD sets, one optimised for PentiumIII and the other > capable of installing, booting and running on 486es. > > I'd be very interested in your results I sucessfully built 771 packages (the ones I use : p), only a few I could not build, these being the following: armagetron-i586 => armagetron-0.1.4.9-6mdk.src.rpm ImageMagick-i586 => ImageMagick-5.4.2.3-1mdk.src.rpm libhdf5_0-devel-i586 => hdf5-1.4.2p1-1mdk.src.rpm libhdf5_0-i586 => hdf5-1.4.2p1-1mdk.src.rpm libMagick5-i586 => ImageMagick-5.4.2.3-1mdk.src.rpm locales-en-i586 => locales-2.3.1.2-8mdk.src.rpm locales-i586 => locales-2.3.1.2-8mdk.src.rpm perl-DB_File-i586 => perl-DB_File-1.802-1mdk.src.rpm If you would like reasons why these packages couldn't build, shout out : ) (locales is being looked into...) A few tips: SAFE FLAGS! For your PIII opts I would recommend the default flags for i586, but simply s/i586\/i686/ on the -march switch Also, you will (I'm pretty sure) run into a few hicups here and there... For example: Take out the man page entries in the glibc.spec , otherwise the build will error out with file not found by glob bla bla... The reason for this? I have Noo idea! : ) GB says it's because it's not building for the default mdk arch (i586), which doesn't make sense to me, but he knows more about RPM than I do : p Other than that, enjoy! P.S. Results afterwards please? : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] mozilla 0.9.9 released! (but we're in freeze...)
On Mon, 2002-03-11 at 22:37, Bryan Paxton wrote: > > http://mozilla.org/releases/mozilla0.9.9/ > > It's xmas for me every time a mozilla release rolls out : ) > > Anyway, to the point... > > In a freeze? Yes, but this is a critical update. > This release aside from tuning and enabling some nice features, fixes > SEVERAL bugs. The most important to any user: > I get ahead of myself some times : ) Flash plugin is now working again, never mind the assigned bugs I posted. This was the important fix I was trying to say (aside from the fix regarding the zlib double free() hole). I simply was in a rush to get the news to this list ; ) > > I think that speaks for itself... > > : ) > Fear the dragon! -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
[Cooker] mozilla 0.9.9 released! (but we're in freeze...)
http://mozilla.org/releases/mozilla0.9.9/ It's xmas for me every time a mozilla release rolls out : ) Anyway, to the point... In a freeze? Yes, but this is a critical update. This release aside from tuning and enabling some nice features, fixes SEVERAL bugs. The most important to any user: Linux: Flash may crash with exported X display. (Bug 58937) Linux: On Linux, there may be problems with ESD Audio and Flash. (Bugs 85772) I think that speaks for itself... : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Default Samba config too insecure (CUPS too)
On Mon, 2002-03-11 at 22:04, David Walser wrote: > But then most end-users aren't on a LAN, and those > that are probably make use of this. > Yes : ) However, the majority of Mandrake users are not on a LAN, or need networked printing. This all leads to my ideas... But I shall not expound them now : ) It's much too busy, and devel discussion should be at a minimum during a freeze, so bugs can get fixed : ) I will soon put together a nice long and detailed paper together that I will send to this list, the subject will be entitled "Let's make everyone happy!" It's quite easy to see that no matter what choice you make right now for defaults and so forth, someone is going to end up unhappy with them... With any distribution... But for now, let's squash some fscking bugs! Tashi Delek! : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Default Samba config too insecure (CUPS too)
On Mon, 2002-03-11 at 21:22, Brad Felmey wrote: > On Mon, 2002-03-11 at 20:59, David Walser wrote: > > > You should probably add the line CUPS_CONFIG=manual to > > the /ustc/sysconfig/printing file. > > Thanks, that solves an immediate problem, but the defaults are still > terrible. > -- > Brad Felmey > I agree, the default for cups in an end-user install should be that it is binded to lo. Most people do not need the feature of network printing. Among other things... -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Default Samba config too insecure
On Mon, 2002-03-11 at 20:02, David Walluck wrote: > Are we sure we want the printer to default to being accessible by the > guest account? Samba also doesn't appear to use tcpwrappers, and since > no hosts are blocked by default in the config file, this leaves the > printer open to everyone on the net by default. That can't be good. > > -- Speaking on the behalf of good security practices: 1. tcp_wrappers should never be seen as a filtering solution, it should be seen as a compliment to existing ip filtering features, which lies in the kernel (netfilter). 2. It is always bad practice to leave services such as NFS, samba, and so forth listening on external interfaces. Binding these types of services to an internal interface not only makes these services more manageable, but it can/does dramatically lower the risk factor in regards to these otherwise not so safe(tm) services. 3. While I'm usually in agreement about guest accounts and so forth, this one I will have to say I am not. For three reasons: 1a. Not much can be done if a printer is accessible by "everyone", unless we're talking about corporate printers, but even then, only trivial attacks may be performed (e.g, DoS attacks). 2a. Samba from a windows user's perspective is non-existent, they just want print and are used to being able to do so (in most setups I've experienced) without a second auth scheme (login/pass for access to the printer). However, _I_ do feel it is best to have a second auth scheme for such things, but this doesn't change the fact that you'll find a lot of unhappy people complaining about the new SMB server. 3a. The process of disabling access to the printer via the guest account is beyond mundane. Of course, since mdk in the moment is aimed at end-users, it might not be such a mundane task... This is where our UI config tools come into play : ) Which plenty exist, making it, even for the most naive Linux user to disable such a feature. I have a whole _LOT_ of ideas that I will be pitching here and there to make things like this smoother (e.g, if samba-server is installed, at post-install, ask the user if he would like to disable the guest account for X or all shares, if answers equals yes; regexp and comment the lines out... This, I'm pretty sure would be fairly easy to implement into DrakX). But, that's two cents : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
[Cooker] Re: [patch] for make_versionh.sh (source11 glibc)
heh, ok, I feel dumb now : p The problem was not with the source, but the program I wrote to do build. Sorry for the time wasted on that one : ) Time to refine the script : ) Mucho props to GB, quite the tolerant individual : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Now, smell the rain of london, it still insists... That we bed for our purity. As if we are pure in the rain of our contentment! As if I can think of this no more!" -- Jeff Buckley
Re: [Cooker] Re: [patch] for make_versionh.sh (source11 glibc)
On Sun, 2002-03-10 at 08:13, Gwenole Beauchesne wrote:
> Hi,
>
> > It's frustrating when the obvious blind sides you : p
> >
> > Really s/kheaders/kheaders_ver : )
>
> Huh, what do I do if this is already the case in -25mdk? You sure
> haven't grabbed the 2.2.4-25mdk SRPM.
>
> Bye,
> Gwenole.
>
>
Yup that's the sh from 25 (I sync up every hour).
Well, the patch was there for reasons simply so you/others could see the
diff.
All that needs to be done is change %{kheaders} to %{kheaders_ver} in
make_versionh.sh
Or could do it right through the spec file (kind of a silly for a one
liner though):
perl -pi -e s'/\%\{kheaders\}/\%\{kheaders_ver\}/' %{source11}
Before %{source11} is called in the spec file (via %expand)
But yeah, that's kind of silly, just change the the variable in the
shell script : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Re: [CHRPM] acl-2.0.0-1mdk
Am I the only one that tests to see if these build ok? :)
--- acl.specThu Mar 7 21:53:10 2002
+++ acl.spec.sqaSun Mar 10 08:13:20 2002
@@ -18,6 +18,7 @@
Prefix: %{_prefix}
URL: http://oss.sgi.com/projects/xfs/
Requires: %{lib_name}
+BuildRequires: %{lib_name}-devel
%description
A command (chacl) to manipulate POSIX access control lists
On Fri, 2002-03-08 at 12:14, Frederic Lepied wrote:
> --=-=-=
> Name: acl Relocations: (not relocateable)
> Version : 2.0.0 Vendor: MandrakeSoft
> Release : 1mdk Build Date: Fri Mar 8 04:54:02 2002
>
> * Thu Mar 07 2002 Frederic Lepied <[EMAIL PROTECTED]> 2.0.0-1mdk
Tashi Delek
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
[Cooker] [patch] for make_versionh.sh (source11 glibc)
It's frustrating when the obvious blind sides you : p Really s/kheaders/kheaders_ver : ) --- make_versionh.sh.orgThu Nov 29 09:18:55 2001 +++ make_versionh.shSun Mar 10 03:51:50 2002 @@ -1,6 +1,6 @@ echo $PWD read VERSION PATCHLEVEL SUBLEVEL
[Cooker] glibc build (bad syntax during prep)
echo $PWD
read VERSION PATCHLEVEL SUBLEVEL <From build:
+ read VERSION PATCHLEVEL SUBLEVEL
++ echo '%{kheaders}'
++ awk -F. '{print $1, " ", $2, " ", $3}'
++ expr '%{kheaders}' '*' 65536 + '*' 256 +
expr: non-numeric argument
+ LINUX_VERSION_CODE=
error: Bad exit status from /var/tmp/rpm-tmp.51821 (%prep)
%{source11}
* must be quoted (double quotes should be used:
So it'd look like...
LINUX_VERSION_CODE=$(expr $VERSION \"*\" 65536 + $PATCHLEVEL \"*\" 256 +
$SUBLEVEL)
So you see:
$ expr 2 + 4 + 18 "*" 65536 "*" 256
301989894
$ expr 2 + 4 + 18 * 65536 * 256
expr: syntax error
So that's been squashed out : )
Thing is, these variables are not getting passed to the shell script,
that much is obvious.
I'm sorry I have no patch for this, but I'm not an RPM warrior : )
BTW: This has haulted on my double checking on man pages from the glibc
build not being found, so this probably should be checked to.
Specifically:
%{_mandir}/man8/ldconfig*
and
%{_mandir}/man1/*
%{_mandir}/man3/*
%{_mandir}/man8/ld.so*
%{_mandir}/man8/rpcinfo*
Reported before that none of these files are found by 'glob'.
(yes it will error out on that and not continue the packaging).
I've experienced this with a few packages during build, and once again
I'd say it's our friend the wildcard again causing problems : )
Tashi Delek
And it's break time for me! : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Back to building locales (localedef core dumping)
Ok, I've finally given up on finding the problem here.
During a build I get:
+ '[' '!' -r /usr/share/i18n/charmaps/UTF-8 ']'
+ '[' '!' -r /usr/share/i18n/charmaps/UTF-8.gz ']'
++ basename UTF-8
+ localedef -c -f UTF-8 -i en_US
/var/tmp/locales-root/usr/share/locale/UTF-8
/var/tmp/rpm-tmp.69528: line 71: 17937 Segmentation fault (core
dumped) localedef -c -f $DEF_CHARSET -i en_US $LOCALEDIR/`basename
$DEF_CHARSET`
+ :
Core dumps on every file, thus an unsuccessful build.
Running from the CLI:
$ localedef -c -f ISO-8859-8 -i en_US /usr/share/locale/ISO-8859-8
Segmentation fault (core dumped)
$
This is a showstopper IMHO, since it's a core package, and is
reproducible every time... However, confirmation of all this is needed.
If no one is able to reproduce this, any insight to where the problem
could be would be lovely.
Attached is a beautiful strace, if anyone would like an strace with
forking, you'll have to ask since that would be a rather large file to
send on the list :)
On to other bugs now :)
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
execve("/usr/bin/localedef", ["localedef", "-c", "-f", "ISO-8859-8", "-i", "en_US",
"/var/tmp/locales-root/usr/share/locale/ISO-8859-8"], [/* 56 vars */]) = 0
uname({sys="Linux", node="sQa.deadhorse.net", ...}) = 0
brk(0) = 0x8086960
open("/etc/ld.so.preload", O_RDONLY)= 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)= 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=64846, ...}) = 0
old_mmap(NULL, 64846, PROT_READ, MAP_PRIVATE, 3, 0) = 0x126000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\203"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1275300, ...}) = 0
old_mmap(NULL, 1292000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x136000
mprotect(0x268000, 38624, PROT_NONE)= 0
old_mmap(0x268000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x131000) =
0x268000
old_mmap(0x26e000, 14048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x26e000
close(3)= 0
munmap(0x126000, 64846) = 0
brk(0) = 0x8086960
brk(0x8086980) = 0x8086980
brk(0x8087000) = 0x8087000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x126000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
brk(0x8088000) = 0x8088000
read(3, "", 4096) = 0
close(3)= 0
munmap(0x126000, 4096) = 0
open("/usr/share/locale/en_US/LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)= 0
open("/usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0
old_mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0x126000
close(3)= 0
open("/usr/share/locale/en_US/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=173408, ...}) = 0
old_mmap(NULL, 173408, PROT_READ, MAP_PRIVATE, 3, 0) = 0x272000
close(3)= 0
access("/var/tmp/locales-root/usr/share/locale/ISO-8859-8", W_OK) = 0
open("ISO-8859-8", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/usr/share/i18n/charmaps/ISO-8859-8", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/share/i18n/charmaps/ISO-8859-8.gz", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2781, ...}) = 0
pipe([4, 5])= 0
getrlimit(0x7, 0xb368) = 0
getrlimit(0x7, 0xb368) = 0
getrlimit(0x7, 0xb368) = 0
getrlimit(0x7, 0xb368) = 0
getrlimit(0x7, 0xb368) = 0
fork() = 25652
close(5)= 0
close(3)= 0
fcntl64(4, F_GETFL) = 0 (flags O_RDONLY)
fstat64(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x127000
_llseek(4, 0, 0x
[Cooker] libstdc++ and the flag that breaks it
So, I played around with out libstdc++/core dumping problem.
The flag that really seems to break libstdc++ is -malign-double.
I didn't get too analytical with my tests, but I'm pretty sure that's
the one...
So, I compiled gcc with the following (spec file snip)
CC="$CC" CFLAGS="$OPT_FLAGS" CXXFLAGS="-O3 -funroll-loops -ffast-math
-mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer
-fno-strength-reduce"
XCFLAGS="$OPT_FLAGS" \
TCFLAGS="$OPT_FLAGS" \
../configure --prefix=%{_prefix} --mandir=%{_mandir}
--infodir=%{_infodir} --datadir=%{gcc_datadir} \
--enable-shared --enable-threads=posix --enable-haifa
--disable-checking $ENABLE_LIBSTDCXX_V3 \
--enable-languages="$LANGUAGES" \
In other words, explicitly assigns the values for CXXFLAGS so libstdc++
will compile fine/run fine and/or applications that use libstdc++ will
run ok on their own.
Keep in mind, I'm simply posting this for those who wish to optimize
gcc, and for those curious as to what broke libstdc++ (causing the core
dumps). The default flags bundled in your rpmrc and macros files in the
mdk rpm package are perfectly fine : )
(also keep in mind this is an SMP machine)
Anyway, that's taken care of... Now time to figure out why I localedef
core dumps when compiling locales : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] update-menus core dumping
On Sat, 2002-03-09 at 05:13, R.I.P. Deaddog wrote: > I've encountered quite a few 'risky' programs that segfaults with > too much optimization, turning off -ffast-math and/or > -fno-strength-reduce usually helps. Just my experience. > *nod*, like I said in another email, I'll be playing around with flags. -fno-exceptions is the first one I'm stripping : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] update-menus core dumping
On Sat, 2002-03-09 at 02:45, Frédéric Crozat wrote: > Le Sat, 09 Mar 2002 09:14:12 +0100, Bryan Paxton a écrit : > > > On Sat, 2002-03-09 at 01:14, Frédéric Crozat wrote: > >> Le Sat, 09 Mar 2002 01:28:53 +0100, Bryan Paxton a écrit : > >> > >> > Hmmm this is odd... > >> > update-menus is core dumping (along with 'mysql' and 'localedef'). > >> > >> Strange.. > >> > >> Try running update-menus -n -v -d to see where it stops.. > >> > >> > > Hmm just in case my other email didn't get through here it was: > > > > On Fri, 2002-03-08 at 18:57, Bryan Paxton wrote: > >> It perhaps might be the latest gcc, specifically libstdc++, but it > >> could be my optimizations that made something in libstdc++ fubar... > > I'm > >> going to compile for i686, but with the default rpm opt flags and see > >> what's what : ) > >> > >> I'll email back with results : ) > > > > Those being that either libstdc doesn't like compiling with the below > > flags, or gcc is happy with them (2.9.6 from cooker): i686 -03 > > -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro > > -march=pentiumpro -fomit-frame-pointer -fno-exceptions > > -fno-strength-reduce > > You didn't check menu specfile, didn't you ? > > Menu is always compiled with -O3 (nothing more) on ix86 because it core dumps >otherwise ... > > > And I don't have your problem with the menu-2.1.5-99mdk.. > Of course, I it compile with simple -O3, it's libstdc++ when compiled with those above flags. I'm gonna be spending this morning playing around with gcc/libstdc++ and figure some good safe i686 SMP C*FLAGS. Any suggestions are welcomed, and I'll be on #mdk-cooker throughout the day (as basilica)... Tashi Delek, -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Re: Problem found: core dump related (mysql,update-menus
On Sat, 2002-03-09 at 02:27, Gwenole Beauchesne wrote: > Hi, > > > Those being that either libstdc doesn't like compiling with the below > > flags, or gcc is happy with them (2.9.6 from cooker): > > i686 -03 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro > > -march=pentiumpro -fomit-frame-pointer -fno-exceptions > > -fno-strength-reduce > > Huh, do you mean the default rpm opt flags produce a working > update-menus (which is good) for you or are only those you mentioned > above? > Yes, default flags on libstc++ really, but the above flags are MY opt flags, which results in a broken libstc++ . : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] update-menus core dumping
On Sat, 2002-03-09 at 01:14, Frédéric Crozat wrote: > Le Sat, 09 Mar 2002 01:28:53 +0100, Bryan Paxton a écrit : > > > Hmmm this is odd... > > update-menus is core dumping (along with 'mysql' and 'localedef'). > > Strange.. > > Try running update-menus -n -v -d to see where it stops.. > Hmm just in case my other email didn't get through here it was: On Fri, 2002-03-08 at 18:57, Bryan Paxton wrote: > It perhaps might be the latest gcc, specifically libstdc++, but it > could be my optimizations that made something in libstdc++ fubar... I'm > going to compile for i686, but with the default rpm opt flags and see > what's what : ) > > I'll email back with results : ) Those being that either libstdc doesn't like compiling with the below flags, or gcc is happy with them (2.9.6 from cooker): i686 -03 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions -fno-strength-reduce (PIII - 850) Anyway, so no problem with libstdc++ : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Re: Problem found: core dump related (mysql, update-menus
On Fri, 2002-03-08 at 18:57, Bryan Paxton wrote: > It perhaps might be the latest gcc, specifically libstdc++, but it > could be my optimizations that made something in libstdc++ fubar... I'm > going to compile for i686, but with the default rpm opt flags and see > what's what : ) > > I'll email back with results : ) Those being that either libstdc doesn't like compiling with the below flags, or gcc is happy with them (2.9.6 from cooker): i686 -03 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions -fno-strength-reduce (PIII - 850) Anyway, so no problem with libstdc++ : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Problem found: core dump related (mysql, update-menus
It perhaps might be the latest gcc, specifically libstdc++, but it could be my optimizations that made something in libstdc++ fubar... I'm going to compile for i686, but with the default rpm opt flags and see what's what : ) I'll email back with results : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] update-menus core dumping
Hmmm this is odd...
update-menus is core dumping (along with 'mysql' and 'localedef').
strace is short and sweet:
execve("/usr/bin/update-menus", ["update-menus"], [/* 56 vars */]) = 0
uname({sys="Linux", node="sQa.deadhorse.net", ...}) = 0
brk(0) = 0x808e1d8
open("/etc/ld.so.preload", O_RDONLY)= 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)= 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=64988, ...}) = 0
old_mmap(NULL, 64988, PROT_READ, MAP_PRIVATE, 3, 0) = 0x127000
close(3)= 0
open("/usr/lib/libstdc++-libc6.2-2.so.3", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\177"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0555, st_size=303980, ...}) = 0
old_mmap(NULL, 316456, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x137000
mprotect(0x171000, 7, PROT_NONE)= 0
old_mmap(0x171000, 69632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x39000) =
0x171000
old_mmap(0x182000, 9256, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x182000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P7\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=135640, ...}) = 0
old_mmap(NULL, 138228, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x185000
mprotect(0x1a6000, 3060, PROT_NONE) = 0
old_mmap(0x1a6000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2) =
0x1a6000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\203"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1274308, ...}) = 0
old_mmap(NULL, 1291008, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x1a7000
mprotect(0x2d9000, 37632, PROT_NONE)= 0
old_mmap(0x2d9000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x131000) =
0x2d9000
old_mmap(0x2df000, 13056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x2df000
close(3)= 0
munmap(0x127000, 64988) = 0
brk(0) = 0x808e1d8
brk(0x808e5b0) = 0x808e5b0
brk(0x808f000) = 0x808f000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x127000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
brk(0x809) = 0x809
read(3, "", 4096) = 0
close(3)= 0
munmap(0x127000, 4096) = 0
open("/usr/share/locale/en_US/LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)= 0
open("/usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0
old_mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 3, 0) = 0x127000
close(3)= 0
open("/etc/menu-methods/menu.config", O_RDONLY|O_LARGEFILE) = 3
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Latest MySQL dropping hella core :)
e(3)= 0
munmap(0x127000, 64917) = 0
open("/etc/services", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=11344, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x127000
read(3, "# /etc/services:\n# $Id: services"..., 4096) = 4096
read(3, "\t\t# Protocol v3\nrpc2portmap\t369/"..., 4096) = 4096
close(3)= 0
munmap(0x127000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
connect(3, {sin_family=AF_UNIX, path="/var/lib/mysql/mysql.sock"}, 110) = 0
brk(0x807b000) = 0x807b000
setsockopt(3, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
read(3, "(\0\0\0", 4) = 4
read(3, "\n3.23.47\0\10\0\0\0s_bN@7/(\0, \10\2\0\0\0\0\0\0"..., 40) = 40
open("/usr/share/mysql/charsets/Index", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=549, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x127000
read(4, "# sql/share/charsets/Index\n#\n# T"..., 4096) = 549
read(4, "", 4096) = 0
close(4)= 0
munmap(0x127000, 4096) = 0
write(3, "\23\0\0\1\205$\0\0\0user\0_BK[UGWK", 23) = 23
read(3, "B\0\0\2", 4) = 4
read(3, "\377\25\4Access denied for user: \'user"..., 66) = 66
shutdown(3, 2 /* send and receive */) = 0
close(3)= 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
I know, reading straces is about as fun as pouring salt in your eyes : P
Tashi Delek
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Wed, 2002-03-06 at 00:42, Frédéric Crozat wrote: > Le Wed, 06 Mar 2002 02:07:43 +0100, Bryan Paxton a écrit : > > If you were reading the result of the rpmfind query, you'll see that the > ximian package is a GNOME 2 snapshot. It has nothing to do with Mandrake ! > > And if you are following GNOME2 development, you can see that the entire > GNOME2 platform will no longer have big metapackage like gnome-core and > so on.. > So, it seems GNOME community is moving to a "libification like process".. We only > began to work on that before others.. > I stand corrected here (in looking again I see those are redhat packages for gnome 2 preview). I have not be avidly following GNOME 2 devel, However, I do point to this ftp://ftp.gnome.org/pub/gnome/pre-gnome2/redhat/specs/gnome-core.spec so, I'll go over to talk with Ximian folks about their package : ) > Our GNOME packages are compatible with RedHat package at the binary > level.. They have never been supposed to be compatible at the source > level.. Same thing between distro version : an old distro package should > compile on a newer distro... An old package should install on a newer distro as well, easy and clean, IMHO > > Old packages? I'm only concerned with 8.2 and Ximian compatibility. > > The way the spec file is now (requires and provides) makes xmms > > incompatible... Of course you can always simply do a rpm -b$1 --nodeps > > xmms.spec, but that breaks the "cleanliness" of interruptibility between > > the two distributions of GNOME (mdk's implementation and ximian's > > distro). > > Yes, I continue to say old package.. Ximian is still 8.1 only compatible > so when you said you want "Ximian compatibility", in fact, you ask for > 8.1 compatibility.. Actually, no. Cooker is pretty damn compatible with Ximian GNOME for 8.1 mdk. I won't go into why, however. But pretty much, just to let everyone who is interested, Ximian rpms for 8.1 installed on this cooker machine without a hitch (except for a --nodeps on concerns with conflicts from libpng3). Just needs to be rebuilt against libpng3, imlib2, and libxml2. So I was pretty impressed by this. > GNOME dependencies/requires/provides are correct in cooker.. > > If you have a problem with xmms, see with xmms maintainer.. There is > nothing wrong with GNOME packages.. When xmms depends on various GNOME libs, this makes no sense. And to be honest, I don't use mdk's GNOME packages, for reasons which I will not go into (yet again). I just want a good percentage of users to have the best experience possible with foo. > > For me, there has never been a debate on that, so I won't post any > more message on this topic.. I prefer to concentrate my time on fixing > GNOME.. > Indeed, useless chatter this has evolved into... Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Tue, 2002-03-05 at 18:22, Ben Reser wrote: > On Tue, Mar 05, 2002 at 05:52:26PM -0600, Bryan Paxton wrote: > > However, this does bring up in an interesting point. You say Mandrake > > packages are not "supposed" to be backward compatible with older > > versions of the distro. At a glance, that sounds harmless and logical > > (I'm sure there are reasons for this). > > But isn't this the exact same reason, or one of them anyway, why we fled > > from the world of Windows to begin with? > > e.g., MS Office backward compatibility > > He probably should have said aren't necessarily backwards compatible. > Sometimes they use newer libraries. Names of required packages change > (e.g. the new lib name scheme) and other changes in the distribution > make the RPMS incompatible. Yes yes, but I think more thought needs to be put in changing the lib name scheme each time a new version is pumped out. For example, if you go to rpmfind.net and do a search on libpanel-applet, you will pull up two that carry that package. The first and obvious being mandrake, the second being Ximian (name is Helix on the page however). So it appears Ximian has already begun work on supporting 8.2 (hopefully shortly after 8.2 freeze, ximian will have an announcement). Now, why is ximian using this scheme? To simply support 8.2 (speculating, I'll probably go talk with some ximian folks tonight). Yet, if you query for gnome-core-devel you will see just about every single distribution packages these libraries under this name, including Red Hat (which in the past it has been mdk routine to stay compatible with them). So you see all these conflicts between virtual packages and so forth. This is very frustrating for the end-user, as well as the power user. For too long this has been a problem in the Linux community, I call it mini-forking. It's use is self-orientated, to make, maintain, and distribute packages to your users, keeping flexibility and ease with your development and it's respective cycles. However, at the same time, each distro is doing this (more or less), digging that compatibility hole a little further. I think some time in the near future organization of such is going to be needed. In the same way the LSB covers the _base_ of a system, there should probably be a unified scheme for GNOME, as well as kde, and other high user-land environments and software. (sorry, I got off on a rant : P This is out-of-scope :) ) > > However, I'd argue the reasons many of us fled Windows is preciously the > opposite. Microsoft has held onto DOS/Win3.1 compatiblity at the cost > of stability forever. Things have to progress and sometimes the only > way to do that is to make things incompatible. I'd argue that it wasn't compatibility they kept for the sake of stability (stability and MS don't belong in the same sentence period IMHO : p), I'd say it was for the sake of re-using code. Less cost, less development, faster product out the door, but poor software == more tech support == $$ ? : ) Anyway... MS is renown for it's internal compatibility "problems", it's a brilliant (though not positive) marketing scheme. > > However, I routinely borrow cooker packages and compile them under older > Mandrake distributions. Just yesterday I took the cooker everybuddy > package and rebuilt it under 7.2. > : ) As do I and several others :) However, this is all out of the scope of the original email, but does make for interesting conversation : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Tue, 2002-03-05 at 09:13, Frederic Crozat wrote: > > Hrmmm, this is why I was looking for some type of logical OR to use > > in a rpm spec file. It appears, there simply isn't (from what I've > > researched), but someone did have a kind of ad hoc way of reaching the > > same goal, and that is to simply use virtual packages, so gnome-core, > > should provide gnome-core, and gnome-core-devel vs. providing > > libpanel_applet and libpanel_applet-devel (it seems silly to call them > > these packages anyway, since defacto standard from GNOME is gnome-core, > > no need to be anal about what libs and files it actually provides and > > obfuscate things more.). > > It seems you have never seen debian packages.. Actually, I'm a bit familiar with the Debian packaging system (logical ORs etc...) That doesn't change the fact that I was looking for some similar method in RPM. > > There should be NO problem recompiling old packages on cooker/8.2. Old packages? I'm only concerned with 8.2 and Ximian compatibility. The way the spec file is now (requires and provides) makes xmms incompatible... Of course you can always simply do a rpm -b$1 --nodeps xmms.spec, but that breaks the "cleanliness" of interruptibility between the two distributions of GNOME (mdk's implementation and ximian's distro). > But cooker package are not supposed to be backward compatible with old > version of the distro.. > Well, once again, this has nothing to do with what I was talking about. I'm not speaking of backwards compat, simply clean and friendly compatibility with Ximian GNOME (as much as allows for the moment). However, this does bring up in an interesting point. You say Mandrake packages are not "supposed" to be backward compatible with older versions of the distro. At a glance, that sounds harmless and logical (I'm sure there are reasons for this). But isn't this the exact same reason, or one of them anyway, why we fled from the world of Windows to begin with? e.g., MS Office backward compatibility I know this is on a different level, since the software, in general, will always be in some way backward compatible (and if one wishes to hack to make it that way, they can), but this is very much along the same lines. I could have read into that too much, but it would seem to be this scheme needs to be given review after 8.2 freeze (I know we're too close for any major changes). Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Mon, 2002-03-04 at 05:39, Daouda LO wrote: > ... because we were a more lot young :) heh! This is true! : ) > > Hey, don't be silly guys! We always accept patches when they are > relevant. For the patch on xmms.spec, gc (as the maintainer of xmms) > have the full right to accept/reject your changes. Now he's on > one-day-vacation that's why you received no response. > I wasn't really fretting to begin with :) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Re: [CHRPM] ImageMagick-5.4.2.3-3mdk
On Sun, 2002-03-03 at 18:43, Bryan Paxton wrote:
> s'/3mdk/4mdk/' : )
>
Damn enter key again : p
Anyway, still can't find Magik++ etc... at %install on a build.
It still seems to be in the same area of the %install section.
The bins are there in BUILD/ImageMagickblablabla, so it's simply a
problem at %install...
Once again, it's these commands that fubars the %install
perl -pi -e \
's|-L/.*magick/\.libs ||' \
$RPM_BUILD_ROOT%{_bindir}/Magick-config \
$RPM_BUILD_ROOT%{_bindir}/Magick++-config
Cheers
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Re: [CHRPM] ImageMagick-5.4.2.3-3mdk
s'/3mdk/4mdk/' : ) On Sun, 2002-03-03 at 12:02, Giuseppe Ghibò wrote: > --=-=-= > Name: ImageMagick Relocations: (not relocateable) > Version : 5.4.2.3 Vendor: MandrakeSoft > Release : 3mdk Build Date: Sun Mar 3 18:39:44 2002 -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] hd5 build error
H5Exception.cpp: In function `void H5::Exception::setAutoPrint (herr_t (*) (void *), void *)': H5Exception.cpp:76: exception handling disabled, use -fexceptions to enable H5IdComponent.cpp: In method `H5::IdComponent &H5::IdComponent::operator= (const H5::IdComponent &)': H5IdComponent.cpp:68: exception handling disabled, use -fexceptions to enable H5IdComponent.cpp:69: `close_error' undeclared (first use this function) H5IdComponent.cpp:69: (Each undeclared identifier is reported only once for each function it appears in.) H5IdComponent.cpp:70: confused by earlier errors, bailing out make[3]: *** [H5IdComponent.lo] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: *** [H5Exception.lo] Error 1 make[3]: Leaving directory `/usr/src/RPM/BUILD/hdf5-1.4.2-patch1/c++/src' make[2]: *** [lib] Error 1 make[2]: Leaving directory `/usr/src/RPM/BUILD/hdf5-1.4.2-patch1/c++' make[1]: *** [lib] Error 1 make[1]: Leaving directory `/usr/src/RPM/BUILD/hdf5-1.4.2-patch1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.40634 (%build) Sorry, no patch again : p -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] ImageMagick %Install error on build
Can't find Magic++-config || Magic-config
The problem seems to be here in the %install section
perl -pi -e \
's|-L/.*magick/\.libs ||' \
$RPM_BUILD_ROOT%{_bindir}/Magick-config \
$RPM_BUILD_ROOT%{_bindir}/Magick++-config
No patch for this one : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Sun, 2002-03-03 at 00:45, David Walser wrote: > I know how you feel. I recently posted a patch for > rpmrc which they won't accept because they think it's > "wrong," but I'm willing to bet almost every Mandrake > Linux user would disagree with them. Apparently they > don't care. > Hmmm I will say this: mdk-devel used to be a lot more fun, and a lot more accepting : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] ugh ugh gross for pam.spec (requires)
I had brought this up back in 7.0 (I think) devel. That is, the use of glib-devel for BuildRequires. IIRC, a hash routine within glib-devel was/is used in lieu of writing, or finding another hash routine that is suffice for the build. I'm not even sure where the hash routine is used during the build. Regardless, a base system package should not require glib-devel for a build, since it is simple a _base_ package. What can be done? Let's make things clean! -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] [patch] xmms.spec
On Sat, 2002-03-02 at 10:16, R.I.P. Deaddog wrote: > > If you want to work on reverting the BR, then I guess you can > clean up the BuildRequires completely? It sounds to me that > there are so many unnecessary BuildRequires. > > Abel > Easier said than done. A few things would need to be put in motion. 1. Is that the patches are accepted and plugged 2. Figuring out what needs to be "cleaned up" for compatibility reasons 3. Help from other people There's no sense in anyone doing such a thing unless the patches will be accepted and intergrated, thus far I feel doubtful that any of them will be. Prior patches I've submitted not regarding GNOME (mpg123, msec, etc...) were never accepted and intergrated, you're the only one who has responded to to this xmms.spec patch, that says enough there. How I'm going about this right now as from a pure "loner" method. I'm simply building cooker packages that I use (except for GNOME and the kernel), if I run into an oops, I make a patch : ) As far as help, it would be nice if others would get involved, but simply voicing yourself for compatibility is a good step. Thus, I'm still on that "loner" method until I see otherwise. Compatibility is this sense has to be mutual. Where does this leave us? : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] [patch] xmms.spec
I'm tired, so I won't go on a _real_ long rant here : )
This patch changes part of the buildrequires in the latest xmms.spec.
This change is to keep compatibility with Ximian GNOME.
Ximian GNOME is a popular _distribution_ of GNOME. Mandrake is also a
popular distribution of GNU/Linux. Distributions that have such
popularity should not have a granular compatibility issue IMHO, and IMHO
it does. It has gotten better on both sides over the few years, but it
needs to get smooth IMHO.
Some people love Mandrake GNU/Linux, but they also prefer Ximian gnome.
Installation and removal of both sets of packages (libs and all) that
consist of that desktop should be a breeze, and so should building
packages that depend around those desktop packages (libs and all).
Anyway, here's the patch, nice and small : )
/* Begin Patch */
--- xmms.spec Fri Jan 11 00:46:46 2002
+++ xmms.spec.sqa Sat Mar 2 07:44:03 2002
@@ -4,10 +4,11 @@
%define lib_major 1
%define lib_name %{lib_name_orig}%{lib_major}
+
Name: xmms
Summary: The Sound player with the WinAmp GUI
Version: 1.2.6
-Release: 2mdk
+Release: 3mdk
License: GPL
Group: Sound
Icon: xmms-logo.xpm
@@ -44,7 +45,8 @@
Packager: Guillaume Cottenceau <[EMAIL PROTECTED]>
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
-BuildRequires: libpanel_applet-devel libglib-devel libgtk+-devel libxml-devel
libvorbis-devel libogg-devel
+BuildRequires: gnome-core-devel
+BuildRequires: libglib-devel libgtk+-devel libxml-devel libvorbis-devel libogg-devel
BuildRequires: db1-devel libmikmod-devel XFree86-devel XFree86-static-libs
libesound-devel
BuildRequires: gettext ORBit-devel gnome-libs-devel
Requires: %{lib_name} = %{version}-%{release}
@@ -325,6 +327,10 @@
%endif
%changelog
+* Sat Mar 2 2002 Bryan Paxton <[EMAIL PROTECTED]> 1.2.6-3mdk
+- Revert from libpanel_applet0-devel to gnome-core-devel on Build Requires.
+ (Keep it Ximian GNOME friendly)
+
* Fri Jan 11 2002 Geoffrey Lee <[EMAIL PROTECTED]> 1.2.6-2mdk
- Quick Hack: Put all of the locales back into 1.2.6 (gc is a sucker ;p).
- Really no more rpath (nuked the final one in opengl_spectrum).
/* End of patch */
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Heedfulness: the path to the Deathless.
Heedlessness: the path to death.
The heedful do not die.
The heedless are as if already dead." -- Dhp. 21-24
--- xmms.spec Fri Jan 11 00:46:46 2002
+++ xmms.spec.sqa Sat Mar 2 07:44:03 2002
@@ -4,10 +4,11 @@
%define lib_major 1
%define lib_name %{lib_name_orig}%{lib_major}
+
Name: xmms
Summary: The Sound player with the WinAmp GUI
Version: 1.2.6
-Release: 2mdk
+Release: 3mdk
License: GPL
Group: Sound
Icon: xmms-logo.xpm
@@ -44,7 +45,8 @@
Packager: Guillaume Cottenceau <[EMAIL PROTECTED]>
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
-BuildRequires: libpanel_applet-devel libglib-devel libgtk+-devel libxml-devel
libvorbis-devel libogg-devel
+BuildRequires: gnome-core-devel
+BuildRequires: libglib-devel libgtk+-devel libxml-devel libvorbis-devel libogg-devel
BuildRequires: db1-devel libmikmod-devel XFree86-devel XFree86-static-libs
libesound-devel
BuildRequires: gettext ORBit-devel gnome-libs-devel
Requires: %{lib_name} = %{version}-%{release}
@@ -325,6 +327,10 @@
%endif
%changelog
+* Sat Mar 2 2002 Bryan Paxton <[EMAIL PROTECTED]> 1.2.6-3mdk
+- Revert from libpanel_applet0-devel to gnome-core-devel on Build Requires.
+ (Keep it Ximian GNOME friendly)
+
* Fri Jan 11 2002 Geoffrey Lee <[EMAIL PROTECTED]> 1.2.6-2mdk
- Quick Hack: Put all of the locales back into 1.2.6 (gc is a sucker ;p).
- Really no more rpath (nuked the final one in opengl_spectrum).
[Cooker] Logical ORs in RPM spec?
Is this possible, specifically in the BuildRequires? If so, how? : ) Cheers -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: Ya know what would be nice [was Re: [Cooker] urpmi optionneeded]
That damn enter key : P Anyway... A build option would be nice in urpmi, for the power users. ala `make world` on *BSD. Yet, you could either say something like urpmi --build packagename And it would locate the src rpm that the package came from... It would then build the package ( rpm -bb) After a _sucessful_ build, have it ask if you would like to remove the source (rpm --clean --rmsource --rmspec). Then ask if you would like to install/upgrade said package that was argv[2] from the inital call, use urpmi package name here, for depedency || conflict || whatever handling. Then finally have it ask if you would like to delete or keep the built packages. Just an idea : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Ya know what would be nice [was Re: [Cooker] urpmi option needed]
On Fri, 2002-03-01 at 20:43, garrick wrote: > ctrl-c kills it just fine for me. > > On Wed, Feb 27, 2002 at 12:04:37PM -0800, Todd Lyons alleged: > > I was going to install a new kernel and decided not to: > > > > [root@fiji ~]# urpmi kernel > > One of the following packages is needed: > > 1- kernel-enterprise-2.4.17.22mdk-1-1mdk > > 2- kernel-linus2.4-2.4.18-1mdk > > 3- kernel-secure-2.4.17.22mdk-1-1mdk > > 4- kernel-smp-2.4.17.22mdk-1-1mdk > > 5- kernel-2.4.17.22mdk-1-1mdk > > What is your choice? (1-5) > > > > There's no easy way to get out. 0 doesn't cancel it. Ctrl-C doesn't > > kill it immediately, but I did get it to coredump after Ctrl-C'ing for a > > while. > > > > What do you think about adding an option "0 => Abort installtion" when > > it prompts for multiple packages or when it prompts for multiple > > fulfillment of dependencies. > > > > Blue skies... Todd > > -- > >Todd Lyons -- MandrakeSoft, Inc. > > http://www.mandrakesoft.com/ > > UNIX was not designed to stop you from doing stupid things, because > > that would also stop you from doing clever things. -- Doug Gwyn > > > -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Wrong arch builds on all systems with new RPM
On Thu, 2002-02-28 at 10:01, David Walser wrote: > > --- Bryan Paxton <[EMAIL PROTECTED]> wrote: > > So, what exactly am I missing ? : ) > > Something :o) I thought I explained it pretty well. > Before the latest RPM package, all arches translated > to themselves, ie: > > buildarchtranslate: athlon: athlon > buildarchtranslate: i686: i686 > buildarchtranslate: i586: i586 > buildarchtranslate: i486: i486 > buildarchtranslate: i386: i386 > > which is how it should look. It was changed so that > they all translate to i386, which makes them use the > i386 optflags and build .i386.rpm packages. > > Make sense? > HAHA duhh! : ) This was obvious since I had to make some changes in other parts of /usr/lib/rpm/* to agree with the new rpmrc file. But why? That's the question, why the change? I just don't see any logic in it other than it being a good safe default. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] 2.4.18.1 - still builds rpm as i386
On Thu, 2002-02-28 at 09:40, guran wrote: snippet from rpmrc from the latest rpm package in cooker: # # For a given uname().machine, the default build arch buildarchtranslate: osfmach3_i686: i386 buildarchtranslate: osfmach3_i586: i386 /* all this is a problem */ buildarchtranslate: osfmach3_i486: i386 buildarchtranslate: osfmach3_i386: i386 buildarchtranslate: ia64: ia64 buildarchtranslate: athlon: i386 buildarchtranslate: i686: i386 buildarchtranslate: i586: i386 buildarchtranslate: k6: i386/* all this is a problem */ buildarchtranslate: i486: i386 buildarchtranslate: i386: i386 buildarchtranslate: alphaev5: alpha buildarchtranslate: alphaev56: alpha buildarchtranslate: alphapca56: alpha buildarchtranslate: alphaev6: alpha buildarchtranslate: alphaev67: alpha buildarchtranslate: sun4c: sparc buildarchtranslate: sun4d: sparc buildarchtranslate: sun4m: sparc buildarchtranslate: sparcv9: sparc buildarchtranslate: sun4u: sparc64 buildarchtranslate: osfmach3_ppc: ppc buildarchtranslate: powerpc: ppc buildarchtranslate: powerppc: ppc buildarchtranslate: ppciseries: ppc buildarchtranslate: ppcpseries: ppc buildarchtranslate: atarist: m68kmint buildarchtranslate: atariste: m68kmint buildarchtranslate: ataritt: m68kmint buildarchtranslate: falcon: m68kmint buildarchtranslate: atariclone: m68kmint buildarchtranslate: milan: m68kmint buildarchtranslate: hades: m68kmint buildarchtranslate: s390: s390 buildarchtranslate: s390x: s390x # The arch compat seems ok (probably not for amd proc users). Now, as the header of the file says, you really should go into /etc/rpmrc or ~/.rpmrc... And, these are good defaults. However, it doesn't make much sense to me to have these global defaults, especially on an i586 distribution that is built around optimizations. If this to conform to a standard (I don't remember this in the LSB)? Does someone have the magical answer? : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Wrong arch builds on all systems with new RPM
On Thu, 2002-02-28 at 09:02, Jeff Johnson wrote: > > On Wed, 2002-02-27 at 11:14, David Walser wrote: Well, this all beyond athlon arch, seeing that after I upgraded to the lastest rpm in cooker, the builds were all wrong. I'm actually quite confused (even after reading the linked message). With the latest rpm, the rpmrc file comes with a buildarchtranslates (arch_compat as well) foo_arch i386, for all of them. That just makes no sense to me what so ever. My knowledge of RPM (lack of interest in the past) is just know starting to get grainy, so I may be missing something here. But why bundle, so that no matter what arch you're on, you're going to build for i386... Obviously, if you're building rpms, you're usually doing it for yourself (i.e., optimization volition). So, what exactly am I missing ? : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Wrong arch builds on Athlon
On Thu, 2002-02-28 at 08:46, Mike Calloway wrote: > When I look in /usr/lib/rpm/macros, all I find is: > > %_arch i386 > %_build_archi386 > > When I change these to i686 on my Athlon, I still get packages sent to i386 > but built with -march=i386 -mcpu=i686 flags. What do I need to change, > please? > That's gross.. And the problem needs to be fixed, it lies within the /usr/lib/rpm/rpmrc file. Specifically, it seems to be somewhere in the 'buildarchtranslate' section of the file. Back up your rpmrc before messing with things in here. buildarchtranslate: osfmach3_i686: i386 Is this what's in your rpmrc file? If so, change it, try to build a package, then reply back letting us all know if that fixed the problem... : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] slicing up optflags - easiest way?
Getting more in tune with mdk spec files, I'm looking for the easiest and yet clean way to remove a flag from all RPM_OPT_FLAGS (CFLAGS, CXXFLAGS, FFLAGS, etc...) within the spec file... Example, knocking out -fno-exceptions from the optflags, so that certain apps will compile (e.g, openjade). This also provides a fail safe, for those who have -fno-exceptions as part of their optflags. I'm sure the answer to this is quite easy, but I don't feel like searching through spec files for a good example : ) Cheers ; ) Sama Sama! -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Core dump(s) building locales
This is quite odd, and the problem completely eludes me. A snipet from the build: + '[' '!' -r /usr/share/i18n/charmaps/UTF-8 ']' + '[' '!' -r /usr/share/i18n/charmaps/UTF-8.gz ']' ++ basename UTF-8 + localedef -c -f UTF-8 -i en_US /var/tmp/locales-root/usr/share/locale/UTF-8 /var/tmp/rpm-tmp.11939: line 71: 12021 Segmentation fault (core dumped) localedef -c -f $DEF_CHARSET -i en_US $LOCALEDIR/`basename $DEF_CHARSET` It seg faults for every single one (though the build does continue). However, this is not normal behavior (to say the least). Does anyone have any idea what could be causing this? NOTE: glibc 2.2.4 is build for my arch i686 -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Wrong arch builds on Athlon
On Wed, 2002-02-27 at 11:59, Charles A Edwards wrote: > rpmrebuilds on an Athlon (650mhz) using any kernel source are being done as i386 and >Not as the proper i686. > > See also thread '[Cooker] 2.4.17.22 - Install report' I was also going to report this, but for i686 though. The latest rpm package will default to arch i386 on my i686 system (no problem, change the default arch in /usr/lib/rpm/macros). However, it is annoying... Like I said I was going to report this, that is waiting 'till I had time to further look into it. In other words: Reproduced! : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] kdelibs-devel conflicts with kdelibs
Preparing... ## file /usr/share/doc/HTML/en/kspell/KSpell.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/KSpellConfig.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/KSpellDlg.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/all-globals.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/full-list-KSpell.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/full-list-KSpellConfig.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/full-list-KSpellDlg.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/header-list.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/hier.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/index-long.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/index.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/ksconfig_h.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/kspell_h.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/kspelldlg_h.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk file /usr/share/doc/HTML/en/kspell/version_h.html from install of kdelibs-devel-2.2.2-41mdk conflicts with file from package kdelibs-2.2.2-41mdk No, this isn't one of my personalized packages : ) Name: kdelibs Relocations: (not relocateable) Version : 2.2.2 Vendor: MandrakeSoft Release : 41mdk Build Date: Wed 20 Feb 2002 02:50:43 AM CST Install date: Wed 20 Feb 2002 09:48:08 PM CST Build Host: ke.mandrakesoft.com Group : Graphical desktop/KDE Source RPM: kdelibs-2.2.2-41mdk.src.rpm Size: 21164675 License: ARTISTIC BSD GPL_V2 LGPL_V2 QPL_V1.0 Packager: Mandrake Linux KDE Team <[EMAIL PROTECTED]> URL : http://www.kde.org/ Summary : K Desktop Environment - Libraries Description : Libraries for the K Desktop Environment. Tashi Delek! -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] [patch] mpg123.spec
Patch against mpg123.spec (mpg123-0.59r-16mdk): Current spec using only allows building on two platforms (i386 and i486). If default arch == i586 || i686 || whatever then you get nasty exit status : p (maybe an ifarch for i486). --- mpg123.spec Tue Oct 2 14:36:10 2001 +++ mpg123.spec.sqa Wed Feb 27 05:30:37 2002 @@ -37,7 +37,7 @@ %patch3 -p1 %build -%make linux-$RPM_ARCH-esd +%make linux-i386-esd %install rm -rf $RPM_BUILD_ROOT/ -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24 --- mpg123.spec Tue Oct 2 14:36:10 2001 +++ mpg123.spec.sqa Wed Feb 27 05:30:37 2002 @@ -37,7 +37,7 @@ %patch3 -p1 %build -%make linux-$RPM_ARCH-esd +%make linux-i386-esd %install rm -rf $RPM_BUILD_ROOT/
Re: [Cooker] Why no root ssh logins in high security?
On Mon, 2002-02-25 at 02:20, Alexander Skwar wrote: > Hallo. > > When I installed my new machine I've chosen the "high" security level. > I suppose that's the reason that in /etc/ssh/sshd.config root logins are > disabled, correct? > > If so, why are root ssh logins disabled? I further suppose that is, > because root ssh logins are "bad". Correct? Well, but why are they > "bad"? In how far is it more secure to first ssh to a normal user > account and then do a su to become root? > root login via a remote service (even secure shell) is _very_ high risk. Why is it a high risk? There are a number of scenarios which are possible, I will only name a few. One would be someone sniffing traffic on your network with a tool such as dsniff (http://www.monkey.org/~dugsong/dsniff/), which could be used for a MITM attack or simply sniff out your root password. It's very possible in the future that a Common Vulnerablity will be found in sshd (present versions and future), for example a brute force exploit against sshd, or perhaps a buffer overflow of some sort that allows you to bypass password auth, and simply login. Another way which is always overlooked is social engineering. It's quite easy to get passwords from a tech. monkey. And so on and so on... Further more, not only good security practice, but sys admin practice, is to use the root account as less as possible. Not only do you open yourself up to "possible" attacks, but you also give chance for a nasty mistake (e.g, cd /. && rm -rf *). On top of that, you're showing that your system is not tight, and you are naive to the potentials waiting (can't count how many people i've seen irc as root and get rooted by some jerk). I notice some of the earlier messages, the advice was to give no password. This is very bad practice. root should have a password, a good one too : ) People assume that because pam is in place, a password is required to login, thus not giving root a password is the ultimate security. Well, let's just say you boot to run level one, or boot the kernel with init=/bin/sh (or bash or csh). This circumvents that idea (though this moves on to local/physical security). Also, bugs have been found in pam in the past, as well as in the future. Your normal users should have good strong passwords as well, particularly ones with root access. 'su' IMHO is obsolete. Use sudo instead, it's a much more secure way of maintaining the system when need be with root access. Why is it more secure? In one perspective you can wipe out most of the possibility of having your root and/or other passwords sniffed out by using the optional NOPASSWD (man sudoers), this can then be restricted to only certain commands, coming from certain addresses, etc... There's much much more that sudo can do for you, but that's what the man page is for : ) There are many many many other arguments, opinions, and so forth that could be put in motion here, but I think the above should suffice : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Package wish!
On Sun, 2002-02-24 at 23:21, Murray J. Root wrote: > You're wrong. You're quite late in your reply... (see another message in the thread) Well, technically, I'm not wrong. It's in contribs, which is not part of the distribution. Yes, if you order a *pack you'll get the contribs. Yes, you can also download this single package. But is it part of the _main_ distro? No. Your voice for no "personal war" I'm sure is in good faith. Yet, there is no "personal war", war takes two parties... Oh, and keep your spam out of your sig, it doesn't belong on a mailing list. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Package wish!
On Sun, 2002-02-24 at 23:10, Quel Qun wrote: > On Sun, 2002-02-24 at 20:59, Bryan Paxton wrote: > > > In contrib: > > contrib/RPMS/linux_logo-3.9b5-5mdk.i586.rpm > > =-= > kk1 : ) But that's no good. It should be in main. I mean, there's nothing more comforting then moving your mouse to find an ascii tux sitting at your tty. Remove a package , put linux_logo back, it's our friend : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
Re: [Cooker] Package wish!
On Sun, 2002-02-24 at 21:00, Han wrote: > Bryan Paxton ([EMAIL PROTECTED]) wrote: > > > > I was sad to see that our little friend linux_logo is gone :( > > Maybe it can be slipped back in ? :) > > He is hidding somewhere. Use the --help function or something like that > to find him. > Rght I only assume this is more of your unjustifiable, vacant, unneeded, and primitive bitterness tor-wards myself But for the sake of argument, and that I'm assuming wrong: # pwd /usr/src/cooker/i586/Mandrake/RPMS # for i in *.rpm; do rpm -qps $i; done | grep linux_logo (no state)/usr/include/asm/linux_logo.h (no state)/usr/include/linux/linux_logo.h (no state)/usr/src/linux-2.4.17-21mdk/include/asm-i386/linux_logo.h (no state)/usr/src/linux-2.4.17-21mdk/include/linux/linux_logo.h (no state)/usr/src/linux-2.2.20/drivers/sgi/char/linux_logo.h (no state)/usr/src/linux-2.2.20/include/asm-i386/linux_logo.h (no state)/usr/src/linux-2.2.20/include/linux/linux_logo.h (no state)/usr/src/linux-2.2.20/include/linux/linux_logo.h.oldlogo (no state)/usr/lib/perl5/5.6.1/i386-linux/asm/linux_logo.ph (no state)/usr/lib/perl5/5.6.1/i386-linux/linux/linux_logo.ph No linux_logo. More specifically: # linux_logo -v Linux Logo Version 3.04 -- by Vince Weaver ([EMAIL PROTECTED]) Newest Versions at: http://www.glue.umd.edu/~weave/vmwprod http://metalab.unc.edu/pub/Linux/logos/penguins # file /usr/bin/linux_logo /usr/bin/linux_logo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped So yeah, it's not there, it's been stripped from mdk. My request remains, and I don't particularly think you should have replied to this, being that you have no control over such a thing. Tashi Delek -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Heedfulness: the path to the Deathless. Heedlessness: the path to death. The heedful do not die. The heedless are as if already dead." -- Dhp. 21-24
[Cooker] Package wish!
I was sad to see that our little friend linux_logo is gone :( Maybe it can be slipped back in ? :) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] New ver of modutils
On Sun, 2002-02-24 at 14:29, Borsenkow Andrej wrote:
>
> {pts/3}% rpm -q modutils
> modutils-2.4.13-1mdk
>
> {pts/3}% LC_TIME=en rpm -qi modutils
> Name: modutils Relocations: /usr
> Version : 2.4.13Vendor: MandrakeSoft
> Release : 1mdk Build Date: Wed 13 Feb 2002
> 11:34:38 PM MSK
> Install date: Sat 16 Feb 2002 12:00:47 AM MSK Build Host:
> montreal.mandrakesoft.com
O well , I need to do some catching up : )
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Winning gives birth to hostility. Losing, one lies down in pain. The
calmed
lie down with ease, having set winning & losing aside."
Dhp. 201
[Cooker] New ver of modutils
I usually don't post this crap because I know the dev team tries to keep a close eye on what's new... However, it's sunday : ) And this new ver of modutils comes with some nice bug fixes : ) From freshmeat: modutils 2.4.13 by Jürgen Nagel - Sunday, February 24th 2002 14:36 EST About: The modutils package contains utilities that are intended to make a Linux modular kernel manageable for all users, administrators, and distribution maintainers. Changes: This release has PPC64 changes, adds --quick to depmod, cleans up multiple man pages, fixes a relocation problem in insmod for IA64 IMM64 types, makes obj_gpl_license combined 32/64 bit aware, fixes a compilation problem with 32/64 and separate insmod/kallsyms, fdatasync() after writing to /var/log/ksymoops, fixes an abortion problem with insmod options longer than 2000 characters, and fixes an early exit due to depmod having problems. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] Draksec (was draksec needs improvement or something)
On Sun, 2002-02-24 at 11:25, Fabrice FACORAT wrote: > > > First keep in mind, when I say it was to be a replacement for Bastille > > Linux and msec, this was true at one time, but not so anymore. > > BUS, is still now, an orphan project. > > I think the name would need to be changed. > > > > Well, I think that firewall configuration is moot. From what I > > understand wizdrake does a pretty good job. > > don't talk about that ! I hate wizard since last time i test them ! On > top of that they need java a > HA I did not know that. That is pretty gross IMHO. However, I still, wouldn't like to focus on having BUS do firewall config, it needs a good stable base : ) And this is all in the context that BUS (whatever it would be renamed to) brought back to life : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] Draksec (was draksec needs improvement or something)
On Sun, 2002-02-24 at 10:11, Fabrice FACORAT wrote: > > > A bit dusty, yet still doormant, in cooker cvs is a project that was > > designed to replace msec. BUS, which stands for Bastille Unix Security > > was an idea put in action via Yoann Vandoorselaere, Jay Beale (Bastille > > Linux), and myself. > > The backend is simply beautiful IMHO. Let me shortly explain (as best I > > can). > > The core of BUS is written in C, > > sweet > > > perl modules can be used for routines, > > sweet > no need to install python. 1 package less This is true. > > > > and the configuration is done in xml. > > future. > just a joke : use openoffice format so that you can edit it in > openoffice with color ... > it's a joke. everything tend to be in xml nowadays ... xml is great for configuration :) > > > This makes up the backend. There are two main configuration files, > > actions.xml and secdb.xml. > > A look at secdb/pam.xml: > > /* SNIP */ > > > > Would you like to set a maximum file size a user is allowed > > via PAM ? > > > > If so what shall be the maximum file size(default it 4 == > > 40MB)? > > > > 4 > > Maxium File Size > > no > > > > / * SNIP * / > > this remind me some of the config file of Bastille > Do you mean the xml? Or the actual question? If it's the ladder, that is because this question is asked in Bastille. If it's the former, then that would be most likely due to that Jay implemented ideas in Bastille, that were spawned during BUS devel. > > > > > (See the README for more info) > > > > Here's a screenshot of what a custom session looks like. > > This is a gtk+ frontend (pre-alpha beautifully written by Renaud > > Chaillat). > > fine so can be easily integrate with mdk tools Yup! > > (ncurses frontend, as well as the basic CLI frontend (done) were in > > place) > > nice for servers config ( no need of a GUI ) Yup! > > Now of course, BUS, was being worked on not only to replace msec, but > > Bastille Linux as well, and not only for Linux, but Solaris, HP-UX, and > > so on... > > concerning the replacement of Bastille what are its features concerning > firewalling ? First keep in mind, when I say it was to be a replacement for Bastille Linux and msec, this was true at one time, but not so anymore. BUS, is still now, an orphan project. I think the name would need to be changed. Well, I think that firewall configuration is moot. From what I understand wizdrake does a pretty good job. > > BUS has rollbacks > > really good : ) > > > One particular thing that I always pointed out about BUS was that you > > didn't have to hack to your system, it learned your system on it's own > > (this is due to a lot of great code by Yoann, e.g., xml function check). > > great! there's not enough config tools that use the variables of your > system ? : ) BTW: BUS source code is obtainable via mdk's cvs repos. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] Draksec (was draksec needs improvement or something)
On Sun, 2002-02-24 at 10:32, Pixel wrote:
> Fabrice FACORAT <[EMAIL PROTECTED]> writes:
>
> > > One particular thing that I always pointed out about BUS was that you
> > > didn't have to hack to your system, it learned your system on it's own
> > > (this is due to a lot of great code by Yoann, e.g., xml function check).
> >
> > great! there's not enough config tools that use the variables of your
> > system
>
> boarf, drakxtools manages this
> (at least when it's easy, handling all the lilo and XF86Config options is *hard* :)
>
> in the given example, the pam_filesize seems to be written, but not read? ;)
>
> my $s =
> 'in any case, I much prefer the "interactive" solution used in DrakX and the
> drakxtools... though it lacks the XML buzzword. But you hate XML, don't you?';
>
> use lib '/usr/lib/libDrakX';
> use interactive;
> 'interactive'->vnew->ask_yesorno('', $s, 1);
: )
All environment variables for BUS, do not go outside of BUS, they are
simply used to for the action (actions.xml), and to make dependencies
for other questions.
See doc/devel.txt for a pretty detailed description on all the xml stuff
(I spent a good deal of time writing that up, about time someone reads
it! : p)
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Winning gives birth to hostility. Losing, one lies down in pain. The
calmed
lie down with ease, having set winning & losing aside."
Dhp. 201
Re: [Cooker] Re: Draksec (was draksec needs improvement orsomething)
On Sun, 2002-02-24 at 09:30, Pixel wrote: > Bryan Paxton <[EMAIL PROTECTED]> writes: > > > > > > > Here's a screenshot of what a custom session looks like. > > > This is a gtk+ frontend (pre-alpha beautifully written by Renaud > > > Chaillat). > > > (ncurses frontend, as well as the basic CLI frontend (done) were in > > > place) > > > > > > > heh, hate it when I forget things like this... > > Screenshot is here http://deadhorse.net/bus.png > > i love dialog boxes ending with a yes/no question and only having an "Ok" > button ;p > hehehehe That was the help dialog : ) Yes/no wasn't selected yet : p -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
[Cooker] Re: Draksec (was draksec needs improvement or something)
> > Here's a screenshot of what a custom session looks like. > This is a gtk+ frontend (pre-alpha beautifully written by Renaud > Chaillat). > (ncurses frontend, as well as the basic CLI frontend (done) were in > place) > heh, hate it when I forget things like this... Screenshot is here http://deadhorse.net/bus.png -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
[Cooker] Draksec (was draksec needs improvement or something)
I've been looking at all the threads regarding draksec, and msec, and so forth... All these questions are old, and the answers were answered before... A bit dusty, yet still doormant, in cooker cvs is a project that was designed to replace msec. BUS, which stands for Bastille Unix Security was an idea put in action via Yoann Vandoorselaere, Jay Beale (Bastille Linux), and myself. The backend is simply beautiful IMHO. Let me shortly explain (as best I can). The core of BUS is written in C, perl modules can be used for routines, and the configuration is done in xml. This makes up the backend. There are two main configuration files, actions.xml and secdb.xml. secdb.xml: /* SNIP */ isec.xml secure_inetd.xml pam.xml /* SNIP */ A look at secdb/pam.xml: /* SNIP */ Would you like to set a maximum file size a user is allowed via PAM ? If so what shall be the maximum file size(default it 4 == 40MB)? 4 Maxium File Size no / * SNIP * / And finally, a look at actions.xml: /* SNIP */ * hard 4 * hard __answer__ /* SNIP */ (See the README for more info) Here's a screenshot of what a custom session looks like. This is a gtk+ frontend (pre-alpha beautifully written by Renaud Chaillat). (ncurses frontend, as well as the basic CLI frontend (done) were in place) Now of course, BUS, was being worked on not only to replace msec, but Bastille Linux as well, and not only for Linux, but Solaris, HP-UX, and so on... BUS is pretty friggin scalable, has rollbacks ( I think that was finished : p), etc... One particular thing that I always pointed out about BUS was that you didn't have to hack to your system, it learned your system on it's own (this is due to a lot of great code by Yoann, e.g., xml function check). What and what is not needed: I think the focus needs to be pinched a bit. That is, backing out a lot of operations that Bastille Linux did/does, and it be wrapped around operations that msec currently performs (most of those are already there : p). Regardless of whether anyone would like to wipe the dust off of BUS and put it back into spin... I think a good look over of BUS, it's arch, it's operational character, it's scablility, and so forth. However, if someone (Yoann? I know you're busy with prelude, but maybe?) want to dive into src/ and hack away, I'd be willing to take back up the "principal DB maintainer" title and clean up that config in a heart beat. Anywho... Food for thought : ) -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
[Cooker] bind.spec (html cp(s))
The following causes build to exit 1..
--- bind-9.2.0.spec Thu Feb 14 18:02:36 2002
+++ bind.spec Thu Feb 14 18:02:17 2002
@@ -125,8 +125,6 @@
cp %{SOURCE4} $RPM_BUILD_ROOT/etc/sysconfig/named
cd $RPM_BUILD_DIR/%{name}-%{their_version}
-mkdir -p doc/html
-cp -a `find . -type f |grep html |sed -e 's#\/bind-9.2.0rc10##'`
${RPM_BUILD_DIR}/%{name}-%{their_version}/doc/html
%post
%_post_service named
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Winning gives birth to hostility. Losing, one lies down in pain. The
calmed
lie down with ease, having set winning & losing aside."
Dhp. 201
Re: [Cooker] openssh agent forwarding
On Fri, 2002-02-08 at 21:26, SI Reasoning wrote: > However, I think that SSH forwarding is the lessor of > 2 evils. I feel much better about people forwarding > into the office through ssh as opposed to port > forwarding directly to the internal server/workstation > from the firewall. This is true, but also depends on circumstance, not everyone has the same setup. But the point is simply secure defaults. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] Default msec level low?
On Fri, 2002-02-08 at 21:31, Quel Qun wrote: > On Fri, 2002-02-08 at 02:20, Pixel wrote: > > Bryan Paxton <[EMAIL PROTECTED]> writes: > > > > > On Thu, 2002-02-07 at 23:05, Steve Fox wrote: > > > > Sorry if this has been discussed before, but why is the default security > > > > level low? I would think medium should be default since the help text > > > > recommends it for any Internet connected computer. I'm doing an expert > > > > install. > > > > > > I agree it should be at level 3 (medium)... Haven't actually installed > > > mdk in a while (update manually), this is disappointing to hear that > > > it's been at level 2 (a very insecure level). > > > > level 2 is not a very insecure level > > > > AFAIK, there's not much difference between level 2 and 3 with current msec. > > The major differences: > > - X port 6000 is closed in level 3 (and i won't accept a default install which > > breaks xhost +foobox) > > - ssh-server allows login as root in level 2 > > Error in msec or you overwrote your sshd_config file when updating. -- Bryan Paxton Public PGP key: http://www.deadhorse.net/bpaxton.gpg "Winning gives birth to hostility. Losing, one lies down in pain. The calmed lie down with ease, having set winning & losing aside." Dhp. 201
Re: [Cooker] Samba upgrade & running on boot
On Fri, 2002-02-08 at 17:37, Denis Pelletier wrote:
> On 8 Feb 2002, Bryan Paxton wrote:
>
> { On Fri, 2002-02-08 at 17:09, Denis Pelletier wrote:
> { > Hi,
> { >
> { > I want samba to start on boot. So to do this I use drakxservices and I
> { > choose the option "run on boot". Everything is ok. But everytime I upgrade
> { > samba the option "run on boot" is turned off.
> {
> { This is most likely due to your secure level
> { If the secure level is 4 =< then 'chkconfig whatever_service on' is not
> { executed at post execution of the rpm script.
>
> But what about the general principle of "if you install a server you want
> to run it"?
>
Thus why you would want to be in a more lax security level, such as 3 or
below, but I see the need for a new option/env var (i.e,
INSTALL_SERVER=yes/no).
>
--
Bryan Paxton
Public PGP key: http://www.deadhorse.net/bpaxton.gpg
"Winning gives birth to hostility. Losing, one lies down in pain. The
calmed
lie down with ease, having set winning & losing aside."
Dhp. 201
